Files

HaHafeng 66255368b7 feat(admin): Add user management and upgrade to module permission system

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

2026-01-16 13:42:10 +08:00

6.9 KiB

Raw Blame History

总体 PRD：医疗科研智能数据清洗平台 (The Data Cleaning Platform)

文档版本	V1.0 (基于工具箱架构)
产品形态	企业级 Web SaaS 平台
核心价值	为临床医生提供 “一站式” 的数据治理能力，解决多源异构数据合并难、病历文本提取难、统计前清洗繁琐的三大痛点。
技术架构	Node.js + React + Python/R (统计服务) + LLM

一、项目背景与目标 (Background & Objectives)

1.1 核心痛点

临床科研数据的准备过程（Data Preparation）通常占据整个科研周期的 80% 时间。医生面临三大阻碍：

乱 (Messy): HIS 导出的数据分散在多个 Excel（门诊、住院、检验），ID 对不上，时间线混乱。
杂 (Unstructured): 大量关键信息（如病理诊断、出院小结）存在于文本段落中，无法直接统计。
错 (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_数据清洗工作台
工具 A (Merger)	多源合并	ID 对齐、访视基准合并、时间窗清洗	宽表 (Wide Table)	PRD_工具A_超级合并器_V2
工具 B (AI)	文本提取	OCR、实体提取、隐私脱敏、交叉验证	结构化字段	PRD_工具B_病历结构化机器人_V2
工具 C (Editor)	深度清洗	缺失填补、异常处理、变量计算、分箱	最终分析集	PRD_工具C_科研数据编辑器_V2

三、核心业务流程 (Core Workflows)

3.1 典型全链路场景 (The "Happy Path")

场景：医生收集了 100 份患者的住院 Excel 和病理报告 PDF，需要进行生存分析。

合并 (Step 1): 在 工作台 启动 工具 A。上传“住院记录”为主表，“检验单”为辅表。系统基于“入院日期 ±7天”的时间窗，将检验数据挂载到住院记录上。
提取 (Step 2): 合并完成后，点击“流转到工具 B”。工具 B 自动加载数据。医生选择“肺癌病理模版”，双模型（DeepSeek & Qwen）并发提取“肿瘤大小”和“淋巴结转移”。医生在全景网格中裁决不一致的数据。
清洗 (Step 3): 提取完成后，点击“流转到工具 C”。工具 C 打开编辑器。医生通过侧边栏发现“肿瘤大小”有缺失值，一键用均值填补；并新增计算列 BMI。
分析 (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)

为了保证三个工具能顺畅协作，必须定义统一的数据交换标准：

文件格式: 内部流转统一使用 CSV (UTF-8 with BOM) 或 JSON Lines。
日期格式: 所有工具产出的日期列，强制标准化为 YYYY-MM-DD。
空值表示: 统一使用 null 或空字符串 ""，严禁使用 "NA", "-" 等文本混入数值列。
流转凭证: 跨工具跳转时，通过 URL 参数传递 assetId (资产ID)，接收方通过 API 获取文件流，无需前端透传大文件。

六、附录：版本规划 (Roadmap)

Phase 1 (MVP): 上线工作台 + 工具 A (基础合并) + 工具 C (基础编辑)。工具 B 暂不上线。
Phase 2 (Intelligence): 上线工具 B (单模型提取)。工具 C 增加侧边栏统计。
Phase 3 (Trust): 工具 B 升级为双模型交叉验证。工具 A 升级为时间窗合并。

6.9 KiB Raw Blame History Unescape Escape