AIclinicalresearch/docs/03-业务模块/IIT Manager Agent/06-开发记录/IIT Manager Agent 技术方案审查与补丁.md

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 补充实现 (作为即时性增强)。