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
82 lines
4.8 KiB
Markdown
82 lines
4.8 KiB
Markdown
# **PRD：Tool B \- 病历结构化机器人 (The AI Structurer)**
|
||
|
||
| 文档版本 | V2.0 (双模型交叉验证版) |
|
||
| 产品形态 | Web 端工具（批处理 \+ 全景验证网格） |
|
||
| 核心价值 | 利用 双大模型（DeepSeek & Qwen）交叉验证 技术，将非结构化病历文本转化为高可信度的结构化数据，解决 AI 幻觉问题。 |
|
||
| 目标用户 | 需要处理出院小结、病理报告的医生（对数据准确性要求极高） |
|
||
|
||
## **一、 产品流程图 (User Flow)**
|
||
|
||
数据导入(上传/流转) \-\> 健康体检 \-\> 智能模版配置 \-\> 双盲提取与交叉验证 \-\> 全景网格裁决 \-\> 结果导出
|
||
|
||
## **二、 核心功能需求 (Functional Requirements)**
|
||
|
||
### **1\. 步骤一：数据装载与体检 (Injection & Health Check)**
|
||
|
||
* **P0:** **数据源接入：** 支持本地 Excel 上传，或接收来自工具 A 的流转文件。
|
||
* **P0:** **智能体检 (Health Check)：**
|
||
* 用户选定“文本源列”后，系统立即扫描前 100 行。
|
||
* **拦截规则：** 若空值率 \> 80% 或平均字符数 \< 10，提示“该列不适合提取”，防止误操作浪费 Token。
|
||
* **成本预估：** 根据字符数实时预估 Token 消耗量。
|
||
|
||
### **2\. 步骤二：智能模版配置 (Smart Schema) —— V2 核心升级**
|
||
|
||
* **P0:** **场景化模版选择：**
|
||
* **一级分类（疾病）：** 肺癌、高血压、糖尿病等。
|
||
* **二级分类（报告）：** 病理报告、入院记录、门诊病历、手术记录。
|
||
* **P0:** **动态字段定义：**
|
||
* 选择模版后，自动加载预设字段列表（如“肺癌病理”自动加载：肿瘤大小、淋巴结转移、分化程度）。
|
||
* 支持用户手动 **增/删/改** 字段定义。
|
||
* **P1:** **Prompt 预览：** 实时展示系统将发送给 AI 的 Prompt 结构，增强专业用户信任感。
|
||
|
||
### **3\. 步骤三：双盲提取引擎 (Double-Blind Extraction) —— V2 核心升级**
|
||
|
||
* **P0:** **双模型并发：**
|
||
* 系统同时调用 **DeepSeek-V3** (Model A) 和 **Qwen-Max** (Model B) 对同一段文本进行提取。
|
||
* **P0:** **交叉验证算法 (Cross-Validation)：**
|
||
* **完全一致：** 若 A 与 B 结果相同，标记为 Clean (可信)。
|
||
* **冲突：** 若 A 与 B 结果不同，标记为 Conflict (待裁决)。
|
||
* **P0:** **隐私脱敏：** 强制执行 PII 脱敏（正则替换姓名、身份证号）。
|
||
|
||
### **4\. 步骤四：全景验证网格 (Verification Grid) —— 交互重构**
|
||
|
||
*不再使用单条划动的 Tinder 模式，改为更高效的 Excel 列表模式。*
|
||
|
||
* **P0:** **验证列表 (The Grid)：**
|
||
* **列结构：** 序号 | 原文摘要 | \[字段1\] | \[字段2\] ... | 状态。
|
||
* **原文列：** 显示前 50 字，鼠标悬停显示 Tooltip。
|
||
* **P0:** **冲突可视化与裁决：**
|
||
* **一致单元格：** 显示绿色/白色背景，展示单一值。
|
||
* **冲突单元格：** 背景标黄/红。内部并列显示$$DS: 值A$$
|
||
与$$QW: 值B$$
|
||
。
|
||
* **一键采纳：** 用户点击 A 或 B，该值即被采纳，单元格转为已解决状态。支持双击手动输入修正。
|
||
* **P0:** **侧边栏原文 (Context Drawer)：**
|
||
* 点击表格任一行，右侧滑出侧边栏。
|
||
* 展示病历**全文**，方便用户溯源核对。
|
||
* **P1:** **批量操作：** 支持“剩余冲突全部采纳 Model A”或“导出当前进度”。
|
||
|
||
### **5\. 结果输出**
|
||
|
||
* **P0:** **导出 Excel：** 包含最终采纳的结构化数据。
|
||
* **P0:** **流转到编辑器：** 一键发送到 **工具 C** 进行后续清洗（如缺失值填补）。
|
||
|
||
## **三、 界面原型概念 (UI Sketch)**
|
||
|
||
* **体检页：** 选中列后显示红绿灯卡片：“健康度优秀，预计消耗 45k Token”。
|
||
* **配置页：** 下拉选择“肺癌”+“病理报告”，下方自动列出 5 个关键指标。
|
||
* **处理页：** 进度环显示“双模型提取中...”，下方日志滚动“DeepSeek 完成... Qwen 完成... 正在交叉比对”。
|
||
* **验证页 (核心)：**
|
||
* 顶部：统计条“共 100 条，发现 12 条冲突”。
|
||
* 主体：类 Excel 表格。冲突单元格内有两个按钮供选择。
|
||
* 侧边栏：展示当前行的完整病历文本。
|
||
|
||
## **四、 技术可行性与约束**
|
||
|
||
* **模型选型：**
|
||
* **主模型 (Model A)：** DeepSeek-V3 (性价比高，擅长中文医疗)。
|
||
* **辅助模型 (Model B)：** Qwen-Max 或 GPT-4o-mini (用于校验)。
|
||
* **冲突判定逻辑：**
|
||
* 字符串完全匹配或基于语义相似度（Embedding Cosine Similarity \> 0.95）判定为一致。
|
||
* 数值提取需进行单位归一化后再比对（如 3cm vs 3.0 cm 视为一致）。
|
||
* **性能要求：** 双倍 API 调用会导致成本和时间增加，需在界面上明确告知用户并显示进度。 |