Files
AIclinicalresearch/docs/03-业务模块/DC-数据清洗整理/01-需求分析/PRD:Tool B - 病历结构化机器人 (The AI Structurer).md
HaHafeng d4d33528c7 feat(dc): Complete Phase 1 - Portal workbench page development
Summary:
- Implement DC module Portal page with 3 tool cards
- Create ToolCard component with decorative background and hover animations
- Implement TaskList component with table layout and progress bars
- Implement AssetLibrary component with tab switching and file cards
- Complete database verification (4 tables confirmed)
- Complete backend API verification (6 endpoints ready)
- Optimize UI to match prototype design (V2.html)

Frontend Components (~715 lines):
- components/ToolCard.tsx - Tool cards with animations
- components/TaskList.tsx - Recent tasks table view
- components/AssetLibrary.tsx - Data asset library with tabs
- hooks/useRecentTasks.ts - Task state management
- hooks/useAssets.ts - Asset state management
- pages/Portal.tsx - Main portal page
- types/portal.ts - TypeScript type definitions

Backend Verification:
- Backend API: 1495 lines code verified
- Database: dc_schema with 4 tables verified
- API endpoints: 6 endpoints tested (templates API works)

Documentation:
- Database verification report
- Backend API test report
- Phase 1 completion summary
- UI optimization report
- Development task checklist
- Development plan for Tool B

Status: Phase 1 completed (100%), ready for browser testing
Next: Phase 2 - Tool B Step 1 and 2 development
2025-12-02 21:53:24 +08:00

82 lines
4.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# **PRDTool 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 调用会导致成本和时间增加,需在界面上明确告知用户并显示进度。