- Add iit_schema with 5 tables - Create module structure and types (223 lines) - WeChat integration verified (Access Token success) - Update system docs to v2.4 - Add REDCap source folders to .gitignore - Day 1/14 complete (11/11 tasks)
47 lines
2.9 KiB
Markdown
47 lines
2.9 KiB
Markdown
# **REDCap 原生录入与 AI Workbench 操作边界划分**
|
||
|
||
针对您的关键问题:“CRC 到底在哪里录入数据?”,我们采取\*\*“双轨并行,场景区分”\*\*的原则。
|
||
|
||
## **1\. 核心策略:尊重“数据真理源”**
|
||
|
||
* **原则**:为了确保 GxP 合规性和维护用户的既有习惯,**REDCap 始终是主要的数据录入入口**。
|
||
* **逻辑**:我们不应该重新发明一个录入界面,而是要在录入时通过 AI 进行“实时监护”。
|
||
|
||
## **2\. 详细场景划分**
|
||
|
||
| 场景 | 操作位置 | AI 的角色 | 理由 |
|
||
| :---- | :---- | :---- | :---- |
|
||
| **常规数据录入** | **REDCap 界面** | **实时监护** | 保持 CRC 习惯,降低迁移成本。AI 通过 Webhook 实时质控。 |
|
||
| **大批量数据导入** | **AI Workbench** | **智能搬运** | 外部 Excel 或多张化验单。AI 清洗后,CRC 确认一次,一键注入。 |
|
||
| **图像/PDF 提取录入** | **AI Workbench** | **OCR 提取** | REDCap 原生不支持复杂的 OCR 解析。在 Workbench 完成提取比对最顺手。 |
|
||
| **质疑(Query)处理** | **AI Workbench** | **冲突展示** | 在 Workbench 可以同屏看“证据原文”和“建议值”,体验远好于 REDCap。 |
|
||
| **项目初始化配置** | **AI Workbench** | **架构定义** | 复杂的 RAG 知识库上传、映射表配置,属于 AI 平台的特有逻辑。 |
|
||
|
||
## **3\. 典型流程对比**
|
||
|
||
### **流程 A:常规录入 (CRC 在 REDCap 操作)**
|
||
|
||
1. CRC 登录 REDCap,打开患者表单。
|
||
2. 输入血红蛋白值:8.0(单位录错)。
|
||
3. 点击保存 \-\> REDCap 写入 MySQL \-\> 触发 Webhook。
|
||
4. 我们的后端感知后,QC Agent 发现逻辑错误。
|
||
5. **反馈**:
|
||
* **低延时提醒**:通过 EM 插件在 REDCap 页面上方显示:“AI 提示:该值偏离历史均值,请确认单位”。
|
||
* **异步质疑**:在我们的 Workbench 生成一条 Pending Action。
|
||
|
||
### **流程 B:AI 增强录入 (CRC 在 Workbench 操作)**
|
||
|
||
1. CRC 收到一张化验单照片。
|
||
2. CRC 登录我们的 Workbench,上传照片。
|
||
3. AI 提取出 10 个指标。
|
||
4. **预览比对**:界面左侧是照片,右侧是提取的表格,高亮显示不确定的值。
|
||
5. **一键注入**:CRC 确认无误,点击“同步”。系统自动调用 REDCap API 将这 10 个值一次性填满 REDCap 表单。
|
||
|
||
## **4\. 结论与思路总结**
|
||
|
||
* **REDCap 登录**:用于\*\*“手动、少量、常规”\*\*的临床记录。
|
||
* **AI Workbench 登录**:用于\*\*“大批量、文档提取、质控确认、方案解析”\*\*的高级任务。
|
||
|
||
这种设计的优势在于:**不强制改变用户习惯,但用 AI 让任务变得更轻松。** 我们不需要做一个完整的 EDC,我们要做的是 EDC 的“智能加速器”。
|
||
|
||
**您认可这个“双轨制”吗?** 特别是关于“大批量和文档提取才去 Workbench”的设定。 |