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
This commit is contained in:
@@ -0,0 +1,131 @@
|
||||
# **PRD：Tool A \- 医疗数据超级合并器 (The Super Merger)**
|
||||
|
||||
| 文档版本 | V2.0 (基准锚定版) |
|
||||
| :---- | :---- |
|
||||
| **产品形态** | Web 端工具（分步向导式 Wizard） |
|
||||
| **核心价值** | **解决临床科研中“一对多”数据对齐难题。** 基于“访视（Visit）”和“时间窗”逻辑，将散乱的化验、检查数据精准挂载到住院/门诊记录上。 |
|
||||
| **目标用户** | 临床医生、科研助理 |
|
||||
|
||||
## **一、 产品流程图 (User Flow)**
|
||||
|
||||
1\. 数据装载 (Payload) \-\> 2\. 定基准 (Anchor & Window) \-\> 3\. 选列与预览 (Schema) \-\> 4\. 智能合并 \-\> 5\. 结果与流转
|
||||
|
||||
## **二、 核心功能需求 (Functional Requirements)**
|
||||
|
||||
### **1\. 步骤一：数据装载 (Payload)**
|
||||
|
||||
* **P0:** **多文件上传：** 支持拖拽上传 .xlsx, .csv。建议大小 \< 50MB/文件。
|
||||
* **P0:** **自动预检 (Pre-flight Check)：**
|
||||
* 上传即解析表头。
|
||||
* **红灯拦截：** 文件加密、表头为空、文件损坏 \-\> 禁止下一步。
|
||||
* **P1:** **加载配置/模板：** 若用户之前保存过“肺癌门诊合并规则”，允许一键加载，跳过后续配置。
|
||||
|
||||
### **2\. 步骤二：定基准 (The Anchor) —— 核心算法逻辑**
|
||||
|
||||
此步骤决定了最终大表的“骨架”（行数）和“归类逻辑”。
|
||||
|
||||
#### **2.1 主表选择 (The Backbone)**
|
||||
|
||||
* **P0:** 用户必须从上传的文件中指定一个作为 **“主表 (Visit Base)”**。
|
||||
* **定义：** 主表的每一行，代表最终大表的一个基准行（一次就诊/访视）。通常是《住院记录》或《门诊挂号》。
|
||||
|
||||
#### **2.2 关键列映射 (Key Mapping)**
|
||||
|
||||
* **P0:** **ID 列对齐：** 用户需指定主表的 Patient\_ID 列。系统自动在辅表中寻找同名列，允许人工修正。
|
||||
* **P0:** **时间基准列：** 用户需指定主表的 Date 列（如“入院日期”）。这将作为时间窗的圆心。
|
||||
|
||||
#### **2.3 辅表匹配策略 (Matching Strategy)**
|
||||
|
||||
* **P0:** **时间窗配置 (Time Window)：**
|
||||
* 设定规则：辅表的检查时间必须在 \[主表时间 \- X天, 主表时间 \+ Y天\] 范围内。
|
||||
* **默认值：** $\\pm 7$ 天。
|
||||
* **P0:** **冲突处理 (Collision Handling)：**
|
||||
* *场景：* 单次时间窗内，辅表有多条记录（如做了两次血常规）。
|
||||
* *选项 A (默认 \- 纵向展开)：* 保留所有记录。主表信息复制，行数增加。
|
||||
* *选项 B (最近匹配)：* 仅保留离主表时间最近的一条，丢弃其他。
|
||||
|
||||
### **3\. 步骤三：选列与预览 (The Schema)**
|
||||
|
||||
此步骤决定了最终大表的“血肉”（列宽）。
|
||||
|
||||
#### **3.1 树状选择器 (Tree Picker)**
|
||||
|
||||
* **P0:** 展示所有文件的列结构。
|
||||
* 📂 主表
|
||||
* ✅ 住院号
|
||||
* ✅ 诊断
|
||||
* 📂 辅表 A (化验)
|
||||
* ✅ 白细胞
|
||||
* ⬜ 审核医生 (不勾选)
|
||||
* **交互：** 支持按文件全选/反选。
|
||||
|
||||
#### **3.2 实时结构预览 (Live Schema Preview)**
|
||||
|
||||
* **P0:** 在屏幕右侧实时展示\*\*“最终表头结构”\*\*（仅表头，不计算数据）。
|
||||
* **价值：** 让用户直观看到：“哦，原来我的表会变成这么长，包含这些列”。
|
||||
|
||||
### **4\. 步骤四：结果与流转 (The Result)**
|
||||
|
||||
* **P0:** **处理进度条：** 显示动态文案（“正在构建哈希索引...”、“正在进行时间窗碰撞...”）。
|
||||
* **P0:** **黄金预览 (Golden Preview)：**
|
||||
* 必须展示合并结果的 **前 5-10 行** 真实数据。
|
||||
* 用于用户肉眼核对 ID 是否对齐。
|
||||
* **P0:** **质量看板：**
|
||||
* 成功生成行数。
|
||||
* 丢弃行数（ID不匹配或时间窗外）。
|
||||
* **P0:** **行动流转：**
|
||||
* \[下载 Excel\]
|
||||
* \[发送到 AI 结构化工具\] (流转 Token)
|
||||
* \[发送到 编辑器清洗\] (流转 Token)
|
||||
|
||||
## **三、 核心算法逻辑 (Technical Logic)**
|
||||
|
||||
### **1\. 算法名称：基于时间窗的哈希流式连接 (Time-Windowed Stream Hash Join)**
|
||||
|
||||
### **2\. 执行伪代码**
|
||||
|
||||
// 1\. 内存构建 (Build Phase)
|
||||
// 将辅表 (Small Tables) 读入内存 Map
|
||||
const lookupMap \= {
|
||||
"patient\_001": \[
|
||||
{ type: "lab", date: "2023-01-02", data: {...} }, // 记录1
|
||||
{ type: "lab", date: "2023-05-01", data: {...} } // 记录2
|
||||
\]
|
||||
};
|
||||
|
||||
// 2\. 流式探测 (Probe Phase)
|
||||
// 逐行读取主表 (Main Table)
|
||||
streamMainTable.on('data', (mainRow) \=\> {
|
||||
const pId \= mainRow.id;
|
||||
const tStart \= mainRow.date \- 7 days;
|
||||
const tEnd \= mainRow.date \+ 7 days;
|
||||
|
||||
// 在辅表中寻找符合时间窗的记录
|
||||
const matchLabs \= lookupMap\[pId\].filter(lab \=\>
|
||||
lab.date \>= tStart && lab.date \<= tEnd
|
||||
);
|
||||
|
||||
if (matchLabs.length \=== 0\) {
|
||||
// 没匹配到，只输出主表信息
|
||||
output.write({ ...mainRow, lab\_data: null });
|
||||
} else {
|
||||
// 匹配到了 (处理一对多)
|
||||
matchLabs.forEach(lab \=\> {
|
||||
output.write({ ...mainRow, ...lab.data }); // 纵向展开
|
||||
});
|
||||
}
|
||||
});
|
||||
|
||||
## **四、 界面原型参考 (UI Reference)**
|
||||
|
||||
请参考 工具A\_超级合并器\_原型设计.tsx (V1.0) 中的 Step 2 和 Step 3 界面。
|
||||
|
||||
* **Step 2 重点：** 主表选择单选框、时间列下拉框、策略单选钮。
|
||||
* **Step 3 重点：** 左右分栏布局（左侧树状勾选，右侧表格骨架预览）。
|
||||
|
||||
## **五、 风险规避检查 (Risk Check)**
|
||||
|
||||
1. **用户选错主表怎么办？**
|
||||
* *对策：* 在 Step 2 界面增加显眼的 **Tip**：“主表通常是包含‘入院日期’或‘诊断信息’的表格”。
|
||||
2. **时间格式乱七八糟怎么办？**
|
||||
* *对策：* 后端在解析时间列时，必须使用强力的 Parser（支持 2023/1/1, 2023-01-01, 44927 等格式）。如果解析失败，归为“时间无效”，不进行匹配。
|
||||
@@ -0,0 +1,82 @@
|
||||
# **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 调用会导致成本和时间增加，需在界面上明确告知用户并显示进度。
|
||||
105
docs/03-业务模块/DC-数据清洗整理/01-需求分析/PRD：Tool C - 科研数据编辑器.md
Normal file
105
docs/03-业务模块/DC-数据清洗整理/01-需求分析/PRD：Tool C - 科研数据编辑器.md
Normal file
@@ -0,0 +1,105 @@
|
||||
# **PRD：Tool C \- 科研数据编辑器 (The Research Editor)**
|
||||
|
||||
| 文档版本 | V2.1 (扁平化 \+ 长宽转换版) |
|
||||
| :---- | :---- |
|
||||
| **产品形态** | Web 端在线编辑器（Local-First 架构，类 Excel 体验） |
|
||||
| **核心价值** | 提供比 Excel 更懂科研的轻量级清洗工具。通过“扁平化工具栏”和“智能侧边栏”，让医生在不写代码的情况下完成变量加工、质量治理和样本筛选。 |
|
||||
| **目标用户** | 对数据质量有洁癖的科研人员、临床医生 |
|
||||
|
||||
## **一、 产品流程图 (User Flow)**
|
||||
|
||||
数据导入(上传/流转) \-\> 性能准入与降采样 \-\> 在线清洗(工具栏全局操作 \+ 侧边栏列操作) \-\> 版本快照 \-\> 导出分析集
|
||||
|
||||
## **二、 核心功能需求 (Functional Requirements)**
|
||||
|
||||
### **1\. 顶部扁平工具栏 (The Flat Toolbar) —— 核心交互**
|
||||
|
||||
*不再使用复杂的 Tab 分组，核心科研功能一字排开，所见即所得。*
|
||||
|
||||
#### **1.1 变量加工 (Variable Processing)**
|
||||
|
||||
* **P0: 生成新变量 (Generate Variable):**
|
||||
* **功能：** 弹窗提供公式构建器。
|
||||
* **支持：** 加减乘除、括号、以及 ln() (对数)、exp() 等医学常用函数。
|
||||
* **场景：** 计算 BMI \= weight / (height/100)^2。
|
||||
* **P0: 计算时间差 (Time Delta):**
|
||||
* **功能：** 选择 起始日期列 和 结束日期列，自动生成差值。
|
||||
* **单位：** 支持按 天、月、年 输出。
|
||||
* **场景：** 计算 年龄、住院天数、PFS/OS。
|
||||
* **P0: 长宽转换 (Reshape/Pivot) —— \[V2.1 新增\]:**
|
||||
* **功能：** 将“一人多行（长表）”转换为“一人一行（宽表）”。
|
||||
* **配置项：**
|
||||
1. **唯一ID (Index):** 如 病人ID。
|
||||
2. **区分列 (Columns):** 如 就诊时间 或 次序 (用于生成后缀)。
|
||||
3. **值列 (Values):** 如 白细胞, B超 (需要铺平的数据)。
|
||||
* **场景：** 处理重复测量数据，为 SPSS 重复测量方差分析做准备。
|
||||
|
||||
#### **1.2 数据治理 (Data Governance)**
|
||||
|
||||
* **P0: 拆分数据集 (Split Dataset):**
|
||||
* **功能：** 按某一列的唯一值（如“中心ID”），将大表拆分为多个 Excel 文件或 Sheet。
|
||||
* **P0: 跨列规则检查 (Cross-column Logic):**
|
||||
* **功能：** 定义逻辑规则（如 IF 性别='男' AND 怀孕='是'），在网格中高亮错误行。
|
||||
|
||||
#### **1.3 样本筛选 (Cohort Selection)**
|
||||
|
||||
* **P0: 构建入排标准 (Cohort Builder):**
|
||||
* **功能：** 高级筛选器。支持多条件组合（AND/OR）。
|
||||
* **输出：** 筛选结果可“另存为新数据集”或“标记为排除”。
|
||||
|
||||
### **2\. 右侧智能侧边栏 (Smart Insight Panel) —— 交互灵魂**
|
||||
|
||||
*当用户点击表格的某一列时，侧边栏自动滑出，根据列类型提供特定的清洗工具。*
|
||||
|
||||
#### **2.1 选中“数值型”列（如年龄、白细胞）**
|
||||
|
||||
* **P0: 统计概览：** 显示分布直方图 (Histogram)、最大值、最小值。
|
||||
* **P0: 异常值检测：**
|
||||
* 自动标记偏离分布（如 \> 3σ）的值。
|
||||
* 提供按钮：处理异常（支持截断或置空）。
|
||||
* **P0: 生成分类变量 (Binning):**
|
||||
* **功能：** 将连续数值转为分类。
|
||||
* **交互：** 设置切点（如 60），生成新列（\<60, \>=60）。
|
||||
* **P0: 缺失值填补：** 提供 均值、中位数 填补选项。
|
||||
|
||||
#### **2.2 选中“文本/分类”列（如性别、诊断）**
|
||||
|
||||
* **P0: 统计概览：** 显示频次图 (Bar Chart)。
|
||||
* **P0: 数值映射 (Recode):**
|
||||
* **功能：** 将文本转为统计数值。
|
||||
* **交互：** 列出所有唯一值（Male, Female），用户输入目标值（1, 0）。
|
||||
* **P0: 设为敏感字段 (Masking):** 一键脱敏（替换为 \*\*\*\*\*\*）。
|
||||
* **P1: 智能纯化 (Smart Clean):** 若检测到 \>10、\<0.01 等含符号数值，提供一键提取数字功能。
|
||||
|
||||
### **3\. 超级网格 (The Grid)**
|
||||
|
||||
* **P0: 视觉反馈：**
|
||||
* **空值：** 背景显示淡红色。
|
||||
* **脏数据：** 类型不匹配的值显示紫色文字。
|
||||
* **列头图标：** 明确标识变量类型（\# 数值, A 文本, 📅 日期）。
|
||||
* **P0: 基础操作：** 列宽拖拽、列排序、双击单元格编辑。
|
||||
|
||||
### **4\. 性能与导出 (System)**
|
||||
|
||||
* **P0: 性能准入 (Guardrails):**
|
||||
* 行数 \< 5万：全量加载。
|
||||
* 行数 \> 5万：提示降采样预览，或引导使用后端批处理。
|
||||
* **P1: 自动快照 (Auto-Save):** 每 10 次操作自动保存到 IndexedDB，防止浏览器崩溃丢失。
|
||||
* **P0: 导出定义：**
|
||||
* 导出 Excel/CSV。
|
||||
* **加分项：** 导出时附带变量类型定义（Metadata）。
|
||||
|
||||
## **三、 界面原型参考 (UI Reference)**
|
||||
|
||||
请参考 工具C\_科研数据编辑器\_原型设计\_V2\_演示.html。
|
||||
|
||||
* **布局：** 顶部单行工具栏 \+ 中间全屏网格 \+ 右侧可折叠侧边栏。
|
||||
* **交互：** 点击“长宽转换”按钮弹出配置模态框。
|
||||
|
||||
## **四、 风险规避 (Risk Mitigation)**
|
||||
|
||||
1. **计算精度丢失：**
|
||||
* *解法：* 必须集成 math.js 库进行所有数学运算。
|
||||
2. **Pivot 导致内存溢出：**
|
||||
* *问题：* 长宽转换可能会导致列数爆炸（Column Explosion）。
|
||||
* *解法：* 在执行 Pivot 前，预计算结果列数。如果列数 \> 1000，阻止操作并提示用户减少“区分列”的唯一值数量。
|
||||
@@ -0,0 +1,89 @@
|
||||
# **PRD：智能数据清洗工作台 (The Data Cleaning Portal)**
|
||||
|
||||
| 文档版本 | V1.0 (基于原型 V2) |
|
||||
| :---- | :---- |
|
||||
| **产品形态** | Web 端综合仪表盘 (Dashboard) |
|
||||
| **核心价值** | 作为数据清洗模块的统一入口，提供工具启动、异步任务监控、数据资产管理及跨工具流转能力。 |
|
||||
| **目标用户** | 临床医生、科研助理 |
|
||||
|
||||
## **一、 产品架构图 (Product Architecture)**
|
||||
|
||||
工作台处于系统的二级导航位置，向下连接三个具体工具，横向连接任务与数据。
|
||||
|
||||
全局导航 \-\> **工作台 (本PRD)** \-\> (工具 A, 工具 B, 工具 C)
|
||||
|
||||
## **二、 核心功能需求 (Functional Requirements)**
|
||||
|
||||
### **1\. 全局导航集成 (Global Navigation)**
|
||||
|
||||
* **P0:** 必须无缝嵌入现有系统顶部导航栏。
|
||||
* **位置：** 位于 知识库 与 智能数据分析 之间。
|
||||
* **状态：** 点击后高亮显示“智能数据清洗”。
|
||||
|
||||
### **2\. 工具启动区 (The Launcher)**
|
||||
|
||||
* **P0:** **三卡片入口：** 醒目展示三个核心工具的入口卡片。
|
||||
* **工具 A (超级合并器):** 强调“多源数据合并、ID对齐”。
|
||||
* **工具 B (病历结构化机器人):** 强调“AI 提取、非结构化转结构化”。
|
||||
* **工具 C (科研数据编辑器):** 强调“在线清洗、缺失值处理”。
|
||||
* **交互：** 点击卡片，以**全屏模态框**或**新页面**形式打开对应工具。
|
||||
|
||||
### **3\. 任务流转中心 (Task Flow Hub) —— 核心交互**
|
||||
|
||||
* **P0:** **最近任务列表：** 展示用户最近发起的 10 条任务。
|
||||
* **字段定义：** 任务名称 | 所属工具(A/B/C) | 状态(处理中/完成/失败) | 进度条 | 操作。
|
||||
* **P0:** **状态实时更新：**
|
||||
* **处理中：** 显示动态进度条（如 45%）。
|
||||
* **失败：** 显示红色警告，支持查看错误日志。
|
||||
* **P0:** **智能流转操作 (Smart Action)：**
|
||||
* 基于任务类型，动态推荐下一步操作：
|
||||
* **工具 A 完成后：** 显示按钮 \[下载\] 和 \[去 AI 提取\] (跳转工具 B)。
|
||||
* **工具 B 完成后：** 显示按钮 \[下载\] 和 \[去清洗\] (跳转工具 C)。
|
||||
* **工具 C 完成后：** 显示按钮 \[下载\]。
|
||||
|
||||
### **4\. 数据资产库 (Data Asset Library) —— V2 核心升级**
|
||||
|
||||
* **P0:** **Tab 分栏视图：**
|
||||
* **\[全部\]**
|
||||
* **\[处理结果\] (Outputs):** 存放工具 A/B/C 生成的最终文件。图标使用绿色/蓝色区分。
|
||||
* **\[原始上传\] (Inputs):** 存放用户直接上传的底表。图标使用灰色区分。
|
||||
* **P0:** **资产卡片信息：**
|
||||
* 文件名、标签（如“已清洗”、“已脱敏”）、行数、修改时间。
|
||||
* **P0:** **快捷操作 (Hover Actions):**
|
||||
* 鼠标悬停在卡片上时，显示操作按钮：
|
||||
* \[下载\]: 下载到本地。
|
||||
* \[去处理\]: 如果是原始文件，点击跳转到工具选择页（或默认工具 A）。
|
||||
* \[分析\]: 如果是处理结果，点击跳转到“智能数据分析”模块（未来规划）。
|
||||
* **P0:** **原始文件上传入口：**
|
||||
* 底部固定按钮 \[+ 上传原始文件到库\]，允许用户将本地 Excel 存入云端备用。
|
||||
|
||||
## **三、 界面原型参考 (UI Reference)**
|
||||
|
||||
请严格参考 智能数据清洗工作台\_原型演示\_V2.html。
|
||||
|
||||
* **布局：** 顶部为 Launcher，下方分为左右两栏（左 2/3 为任务，右 1/3 为资产）。
|
||||
* **视觉风格：**
|
||||
* 工具 A：蓝色系 (Blue)
|
||||
* 工具 B：紫色系 (Purple)
|
||||
* 工具 C：翠绿色系 (Emerald)
|
||||
* 状态色：处理中(蓝)、成功(绿)、失败(红)、警告(橙)。
|
||||
|
||||
## **四、 数据交互逻辑 (Data Logic)**
|
||||
|
||||
1. **任务轮询 (Polling):**
|
||||
* 工作台加载时，调用 GET /api/tasks/recent。
|
||||
* 若列表中有状态为 processing 的任务，每隔 5 秒轮询一次状态更新，直到完成。
|
||||
2. **跨工具流转 (Handoff):**
|
||||
* 当用户点击 \[去 AI 提取\] 时：
|
||||
* 前端获取该任务的 resultFileId。
|
||||
* 跳转路由至 /tools/b?sourceFileId={resultFileId}。
|
||||
* 工具 B 初始化时，自动加载该文件，无需用户重新上传。
|
||||
3. **资产管理:**
|
||||
* 工具 A/B/C 产生的最终结果，需自动注册到 DataAsset 表中，并标记 type='output'。
|
||||
* 用户手动上传的文件，注册为 type='input'。
|
||||
|
||||
## **五、 埋点与统计需求**
|
||||
|
||||
* **UV/PV:** 工作台访问量。
|
||||
* **CTR:** 三个工具卡片的点击率（判断哪个工具最常用）。
|
||||
* **流转率:** 用户点击“去 AI 提取”等流转按钮的比例（判断工作流是否顺畅）。
|
||||
112
docs/03-业务模块/DC-数据清洗整理/01-需求分析/总体 PRD：医疗科研智能数据清洗平台.md
Normal file
112
docs/03-业务模块/DC-数据清洗整理/01-需求分析/总体 PRD：医疗科研智能数据清洗平台.md
Normal file
@@ -0,0 +1,112 @@
|
||||
# **总体 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 升级为时间窗合并。
|
||||
Reference in New Issue
Block a user