HaHafeng
4c5bb3d174
- 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)
105 lines
3.8 KiB
Markdown
105 lines
3.8 KiB
Markdown
# **IIT Manager Agent 技术方案审查与补丁 (V1.1)**
|
||
|
||
## **1\. 架构修正：解决医院内网连通性**
|
||
|
||
针对 **风险一 (网络连通性)**，建议在 3.1 REDCap 集成 中增加 **"混合同步模式"**。
|
||
|
||
### **新增模块：SyncManager (同步管理器)**
|
||
|
||
// backend/src/modules/iit-manager/services/SyncManager.ts
|
||
|
||
export class SyncManager {
|
||
/\*\*
|
||
\* 混合同步策略
|
||
\* 1\. 优先监听 Webhook (实时)
|
||
\* 2\. 定时轮询 (兜底，解决内网不通或Webhook丢失问题)
|
||
\*/
|
||
async schedulePolling(projectId: string, intervalMinutes: number \= 10\) {
|
||
await jobQueue.schedule('iit:redcap:poll', { projectId }, {
|
||
every: \`${intervalMinutes} minutes\`
|
||
});
|
||
}
|
||
|
||
/\*\*
|
||
\* 轮询任务处理器
|
||
\*/
|
||
async handlePoll(projectId: string) {
|
||
// 1\. 获取上次同步时间
|
||
const lastSync \= await this.getLastSyncTime(projectId);
|
||
|
||
// 2\. 调用 REDCap API 获取在此之后修改的记录
|
||
// API: 'export', content: 'record', dateRangeBegin: lastSync
|
||
const records \= await this.redcapAdapter.fetchModifiedRecords(projectId, lastSync);
|
||
|
||
// 3\. 触发质控 (复用 Webhook 的逻辑)
|
||
for (const record of records) {
|
||
await jobQueue.push('iit:quality-check', {
|
||
projectId,
|
||
recordId: record.record\_id,
|
||
data: record
|
||
});
|
||
}
|
||
}
|
||
}
|
||
|
||
**修改建议**：
|
||
|
||
* 在 MVP 阶段，**务必实现轮询 (Polling)**。不要赌医院的网络环境。
|
||
|
||
## **2\. 功能补充：历史数据全量扫描**
|
||
|
||
针对 **风险二 (存量数据)**，建议利用现有的 CheckpointService 实现全量扫描。
|
||
|
||
### **新增 API：全量质控触发**
|
||
|
||
**Endpoint**: POST /api/v1/iit/projects/:id/scan-all
|
||
|
||
**逻辑实现 (复用现有 ASL/DC 模块的批处理经验)**：
|
||
|
||
1. 调用 REDCap API 仅下载所有 record\_id (轻量级)。
|
||
2. 将 ID 列表分片 (Chunk)，每片 50 个 ID。
|
||
3. 利用 pg-boss 推送 iit:quality-check:batch 任务。
|
||
4. Worker 逐个拉取完整数据并运行 Agent。
|
||
|
||
## **3\. 前端技术栈明确**
|
||
|
||
方案中提到了 "微信小程序"，但未明确技术栈。考虑到你们现有的 React 基因：
|
||
|
||
* **推荐方案**：使用 **Taro** (React 语法) 开发小程序。
|
||
* **理由**：
|
||
1. 可以让前端团队复用 React 知识（Hooks, Components）。
|
||
2. 可以复用 shared/components 中的部分逻辑（如数据格式化）。
|
||
3. Taro 支持一键编译为 微信小程序 \+ H5 (用于企微侧边栏)，**一鱼两吃**。
|
||
|
||
## **4\. 数据库 Schema 微调**
|
||
|
||
在 IitUserMapping 表中，建议增加 Token 字段，用于小程序 Session 维护。
|
||
|
||
model IitUserMapping {
|
||
// ... 现有字段
|
||
|
||
// 新增：小程序会话密钥 (用于校验 wx.login)
|
||
miniProgramOpenId String? @unique
|
||
sessionKey String? // 微信 session\_key
|
||
|
||
@@index(\[miniProgramOpenId\])
|
||
}
|
||
|
||
## **5\. Dify RAG 性能优化 (预加载)**
|
||
|
||
PRD 提到 "Protocol 往往很长"。
|
||
|
||
* **风险**：每次质控都让 Dify 重新检索整个 PDF，速度慢且 Token 消耗大。
|
||
* **优化**：在 ProtocolService 中增加 **"关键规则缓存"**。
|
||
* 在上传 Protocol 后，让 Agent 预先提取出 "入排标准" (Inclusion/Exclusion Criteria) 并存入 PostgreSQL JSONB 字段。
|
||
* 在做基础质控时，优先匹配 DB 里的规则，匹配不到再由 Agent 去 RAG 检索。
|
||
|
||
## **结论**
|
||
|
||
**此方案 V1.0 可以通过评审，但必须补充上述 "Plan B" (轮询机制)**。
|
||
|
||
**开发优先级调整建议**：
|
||
|
||
1. **Day 1**: 数据库 & 基础架构 (不变)
|
||
2. **Day 2**: **优先实现 REDCap API Adapter (拉取能力)**，而不是 Webhook (推送能力)。因为 API 拉取更可控，且能解决历史数据问题。
|
||
3. **Day 3**: Webhook 补充实现 (作为即时性增强)。 |