feat(iit): Initialize IIT Manager Agent MVP - Day 1 complete

- 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)
2025-12-31 18:35:05 +08:00
parent decff0bb1f
commit 4c5bb3d174
154 changed files with 13759 additions and 8 deletions
--- a/技术方案审查与补丁.md
+++ b/技术方案审查与补丁.md
@@ -0,0 +1,105 @@
+# **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 补充实现 (作为即时性增强)。