HaHafeng
66255368b7
Features - User Management (Phase 4.1): - Database: Add user_modules table for fine-grained module permissions - Database: Add 4 user permissions (view/create/edit/delete) to role_permissions - Backend: UserService (780 lines) - CRUD with tenant isolation - Backend: UserController + UserRoutes (648 lines) - 13 API endpoints - Backend: Batch import users from Excel - Frontend: UserListPage (412 lines) - list/filter/search/pagination - Frontend: UserFormPage (341 lines) - create/edit with module config - Frontend: UserDetailPage (393 lines) - details/tenant/module management - Frontend: 3 modal components (592 lines) - import/assign/configure - API: GET/POST/PUT/DELETE /api/admin/users/* endpoints Architecture Upgrade - Module Permission System: - Backend: Add getUserModules() method in auth.service - Backend: Login API returns modules array in user object - Frontend: AuthContext adds hasModule() method - Frontend: Navigation filters modules based on user.modules - Frontend: RouteGuard checks requiredModule instead of requiredVersion - Frontend: Remove deprecated version-based permission system - UX: Only show accessible modules in navigation (clean UI) - UX: Smart redirect after login (avoid 403 for regular users) Fixes: - Fix UTF-8 encoding corruption in ~100 docs files - Fix pageSize type conversion in userService (String to Number) - Fix authUser undefined error in TopNavigation - Fix login redirect logic with role-based access check - Update Git commit guidelines v1.2 with UTF-8 safety rules Database Changes: - CREATE TABLE user_modules (user_id, tenant_id, module_code, is_enabled) - ADD UNIQUE CONSTRAINT (user_id, tenant_id, module_code) - INSERT 4 permissions + role assignments - UPDATE PUBLIC tenant with 8 module subscriptions Technical: - Backend: 5 new files (~2400 lines) - Frontend: 10 new files (~2500 lines) - Docs: 1 development record + 2 status updates + 1 guideline update - Total: ~4900 lines of code Status: User management 100% complete, module permission system operational
112 lines
6.9 KiB
Markdown
112 lines
6.9 KiB
Markdown
# **总体 PRD：医疗科研智能数据清洗平台 (The Data Cleaning Platform)**
|
||
|
||
| 文档版本 | V1.0 (基于工具箱架构) |
|
||
| :---- | :---- |
|
||
| **产品形态** | 企业级 Web SaaS 平台 |
|
||
| **核心价值** | 为临床医生提供 **“一站式”** 的数据治理能力，解决多源异构数据合并难、病历文本提取难、统计前清洗繁琐的三大痛点。 |
|
||
| **技术架构** | Node.js \+ React \+ Python/R (统计服务) \+ LLM |
|
||
|
||
## **一、 项目背景与目标 (Background & Objectives)**
|
||
|
||
### **1.1 核心痛点**
|
||
|
||
临床科研数据的准备过程（Data Preparation）通常占据整个科研周期的 80% 时间。医生面临三大阻碍：
|
||
|
||
1. **乱 (Messy):** HIS 导出的数据分散在多个 Excel（门诊、住院、检验），ID 对不上，时间线混乱。
|
||
2. **杂 (Unstructured):** 大量关键信息（如病理诊断、出院小结）存在于文本段落中，无法直接统计。
|
||
3. **错 (Dirty):** 缺失值、异常值、录入错误频发，不符合统计软件（SPSS/SAS）的格式要求。
|
||
|
||
### **1.2 产品目标**
|
||
|
||
构建一个 **“流程化、智能化、低门槛”** 的数据清洗平台：
|
||
|
||
* **模块化 (Modular):** 将复杂流程拆解为三个独立工具，降低认知负荷。
|
||
* **可信赖 (Trustworthy):** 通过“双模型验证”和“全过程追溯”，解决对 AI 的信任危机。
|
||
* **高性能 (Performant):** 支持 10万+ 行数据的流式处理与实时编辑。
|
||
|
||
## **二、 产品总体架构 (Product Architecture)**
|
||
|
||
平台采用 **“1 \+ 3”** 架构模式：**1 个统一工作台 \+ 3 个垂直效能工具**。
|
||
|
||
### **2.1 架构图**
|
||
|
||
graph TD
|
||
User\[临床医生/科研人员\] \--\> Portal\[智能数据清洗工作台 (Portal)\]
|
||
|
||
subgraph The\_Toolkit \[效能工具箱\]
|
||
Portal \--\> ToolA\[工具 A: 超级合并器\]
|
||
Portal \--\> ToolB\[工具 B: 病历结构化机器人\]
|
||
Portal \--\> ToolC\[工具 C: 科研数据编辑器\]
|
||
end
|
||
|
||
subgraph Data\_Flow \[数据流转\]
|
||
ToolA \--合并后数据--\> ToolB
|
||
ToolB \--结构化数据--\> ToolC
|
||
ToolC \--清洗后数据集--\> Analysis\[智能数据分析模块\]
|
||
end
|
||
|
||
subgraph Core\_Capabilities \[底层能力\]
|
||
Engine1\[流式处理引擎\]
|
||
Engine2\[双盲大模型引擎\]
|
||
Engine3\[浏览器计算引擎\]
|
||
end
|
||
|
||
ToolA \-.-\> Engine1
|
||
ToolB \-.-\> Engine2
|
||
ToolC \-.-\> Engine3
|
||
|
||
### **2.2 模块定义与边界**
|
||
|
||
| 模块名称 | 对应场景 | 核心任务 | 关键产出 | 详细文档 |
|
||
| :---- | :---- | :---- | :---- | :---- |
|
||
| **工作台 (Portal)** | 全局入口 | 任务监控、资产管理、跨工具流转 | 统一仪表盘 | [PRD\_数据清洗工作台](https://www.google.com/search?q=PRD_%E6%95%B0%E6%8D%AE%E6%B8%85%E6%B4%97%E5%B7%A5%E4%BD%9C%E5%8F%B0.md) |
|
||
| **工具 A (Merger)** | 多源合并 | ID 对齐、访视基准合并、时间窗清洗 | 宽表 (Wide Table) | [PRD\_工具A\_超级合并器\_V2](https://www.google.com/search?q=PRD_%E5%B7%A5%E5%85%B7A_%E8%B6%85%E7%BA%A7%E5%90%88%E5%B9%B6%E5%99%A8_V2.md) |
|
||
| **工具 B (AI)** | 文本提取 | OCR、实体提取、隐私脱敏、交叉验证 | 结构化字段 | [PRD\_工具B\_病历结构化机器人\_V2](https://www.google.com/search?q=PRD_%E5%B7%A5%E5%85%B7B_%E7%97%85%E5%8E%86%E7%BB%93%E6%9E%84%E5%8C%96%E6%9C%BA%E5%99%A8%E4%BA%BA_V2.md) |
|
||
| **工具 C (Editor)** | 深度清洗 | 缺失填补、异常处理、变量计算、分箱 | 最终分析集 | [PRD\_工具C\_科研数据编辑器\_V2](https://www.google.com/search?q=PRD_%E5%B7%A5%E5%85%B7C_%E7%A7%91%E7%A0%94%E6%95%B0%E6%8D%AE%E7%BC%96%E8%BE%91%E5%99%A8_V2.md) |
|
||
|
||
## **三、 核心业务流程 (Core Workflows)**
|
||
|
||
### **3.1 典型全链路场景 (The "Happy Path")**
|
||
|
||
场景：医生收集了 100 份患者的住院 Excel 和病理报告 PDF，需要进行生存分析。
|
||
|
||
1. **合并 (Step 1):** 在 **工作台** 启动 **工具 A**。上传“住院记录”为主表，“检验单”为辅表。系统基于“入院日期 ±7天”的时间窗，将检验数据挂载到住院记录上。
|
||
2. **提取 (Step 2):** 合并完成后，点击“流转到工具 B”。**工具 B** 自动加载数据。医生选择“肺癌病理模版”，双模型（DeepSeek & Qwen）并发提取“肿瘤大小”和“淋巴结转移”。医生在全景网格中裁决不一致的数据。
|
||
3. **清洗 (Step 3):** 提取完成后，点击“流转到工具 C”。**工具 C** 打开编辑器。医生通过侧边栏发现“肿瘤大小”有缺失值，一键用均值填补；并新增计算列 BMI。
|
||
4. **分析 (Step 4):** 数据清洗完毕，保存为“分析集\_V1”。一键发送至系统的“智能数据分析”模块进行 Kaplan-Meier 生存分析。
|
||
|
||
## **四、 全局非功能需求 (Non-Functional Requirements)**
|
||
|
||
### **4.1 用户体验策略 (UX Strategy)**
|
||
|
||
* **去可视化 (De-visualization):** 对于工具 A 和 B，不展示全量 Excel 网格，采用 **“向导配置 \-\> 黑盒处理 \-\> 黄金预览”** 的模式，降低浏览器渲染压力，聚焦结果。
|
||
* **反馈补偿 (Feedback Loop):** 既然看不见过程，必须增强结果反馈。每个工具必须提供详细的 **“数据质量报告”**（如：丢弃行数、冲突率、空值率）。
|
||
* **本地优先 (Local-First):** 工具 C 采用 IndexedDB 存储，确保编辑操作（筛选、替换）无网络延迟。
|
||
|
||
### **4.2 数据安全与隐私 (Security & Privacy)**
|
||
|
||
* **PII 脱敏:** 所有发送给 LLM (工具 B) 的数据，**必须**在后端先经过正则脱敏（姓名、身份证、手机号）。
|
||
* **数据隔离:** 不同用户的数据严格物理隔离（S3 路径 / DB Row Level Security）。
|
||
|
||
### **4.3 性能指标 (Performance SLAs)**
|
||
|
||
* **文件支持:** 单个文件支持最大 **50MB** 或 **50万行**。
|
||
* **响应速度:**
|
||
* 工具 A 合并（10万行）：\< 60秒。
|
||
* 工具 B 提取（并发）：取决于 Token 量，需提供进度条。
|
||
* 工具 C 编辑响应：\< 100ms。
|
||
|
||
## **五、 数据标准与流转协议 (Data Standards)**
|
||
|
||
为了保证三个工具能顺畅协作，必须定义统一的数据交换标准：
|
||
|
||
1. **文件格式:** 内部流转统一使用 **CSV (UTF-8 with BOM)** 或 **JSON Lines**。
|
||
2. **日期格式:** 所有工具产出的日期列，强制标准化为 YYYY-MM-DD。
|
||
3. **空值表示:** 统一使用 null 或空字符串 ""，严禁使用 "NA", "-" 等文本混入数值列。
|
||
4. **流转凭证:** 跨工具跳转时，通过 URL 参数传递 assetId (资产ID)，接收方通过 API 获取文件流，无需前端透传大文件。
|
||
|
||
## **六、 附录：版本规划 (Roadmap)**
|
||
|
||
* **Phase 1 (MVP):** 上线工作台 \+ 工具 A (基础合并) \+ 工具 C (基础编辑)。工具 B 暂不上线。
|
||
* **Phase 2 (Intelligence):** 上线 工具 B (单模型提取)。工具 C 增加侧边栏统计。
|
||
* **Phase 3 (Trust):** 工具 B 升级为双模型交叉验证。工具 A 升级为时间窗合并。 |