HaHafeng
0b29fe88b5
QC System Deep Fix: - HardRuleEngine: add null tolerance + field availability pre-check (skipped status) - SkillRunner: baseline data merge for follow-up events + field availability check - QcReportService: record-level pass rate calculation + accurate LLM XML report - iitBatchController: legacy log cleanup (eventId=null) + upsert RecordSummary - seed-iit-qc-rules: null/empty string tolerance + applicableEvents config V3.1 Architecture Design (docs only, no code changes): - QC engine V3.1 plan: 5-level data structure (CDISC ODM) + D1-D7 dimensions - Three-batch implementation strategy (A: foundation, B: bubbling, C: new engines) - Architecture team review: 4 whitepapers reviewed + feedback doc + 4 critical suggestions - CRA Agent strategy roadmap + CRA 4-tool explanation doc for clinical experts Project Member Management: - Cross-tenant member search and assignment (remove tenant restriction) - IIT project detail page enhancement with tabbed layout (KB + members) - IitProjectContext for business-side project selection - System-KB route access control adjustment for project operators Frontend: - AdminLayout sidebar menu restructure - IitLayout with project context provider - IitMemberManagePage new component - Business-side pages adapt to project context Prisma: - 2 new migrations (user-project RBAC + is_demo flag) - Schema updates for project member management Made-with: Cursor
111 lines
7.5 KiB
Markdown
111 lines
7.5 KiB
Markdown
# **纯数字 CRA 平台：五层数据底座与核心引擎技术白皮书**
|
||
|
||
**文档版本**：V2.1 (CDISC ODM 国际标准 5 层全景版)
|
||
|
||
**核心理念**：以 CDISC ODM 国际标准为底座，彻底解决重复表单问题，打造对人类透明、符合 GCP 规范、对 LLM 友好的临床质控体系。
|
||
|
||
## **第一章 核心数据架构：五层状态级联树 (The 5-Layer Hierarchy)**
|
||
|
||
为了支撑前端的“受试者 × 表单”热力图，并彻底解决重复表单（Repeating Forms，如多次发生的 AE、多次服药记录）的数据覆盖与追踪问题，我们严格对齐 CDISC ODM 标准，采用 **5 层状态级联架构**作为系统的影子质控底座。
|
||
|
||
### **1.1 数据实体定义与 GPS 坐标**
|
||
|
||
系统中的任何一个质控状态、任何一条 eQuery，都必须唯一且绝对精确地绑定在这个五维坐标上：
|
||
|
||
1. **RecordID (受试者级)**：例如 P005。反映该患者的整体健康度。
|
||
2. **EventID (访视/事件级)**：例如 Visit\_2（随访2）。反映特定时间点的数据质量。
|
||
3. **FormID (表单级)**：例如 AE\_Log（不良事件表）。**（前端风险热力图的 X 轴核心来源）**
|
||
4. **InstanceID (实例/行号级)**：例如 1, 2, 3。**（核心突破！用于区分同一患者填写的第 1 个 AE、第 2 个 AE。非重复表单默认值为 1）**
|
||
5. **FieldID (字段/变量级)**：例如 ae\_name（不良事件名称）。最底层的原子数据。
|
||
|
||
### **1.2 状态级联与冒泡机制 (State Bubbling)**
|
||
|
||
当后台的 HardRuleEngine 或 SoftRuleEngine 发现数据异常时：
|
||
|
||
1. **精准打标**：系统首先在最底层的 qc\_field\_status 表中，将坐标 P005 \-\> Visit\_2 \-\> AE\_Log \-\> Instance\_2 \-\> ae\_name 标记为 FAIL，并生成一条 eQuery。
|
||
2. **状态冒泡 (自动向上传递)**：
|
||
* 包含该字段的实例 Instance\_2 (第2条不良事件) 状态变为 FAIL。
|
||
* 包含该实例的表单 AE\_Log 的状态自动变为 FAIL（热力图该格子变红）。
|
||
* 包含该表单的访视 Visit\_2 自动变为 FAIL。
|
||
* 受试者 P005 的全局状态自动变为 FAIL。
|
||
3. **闭环消警**：当 CRC 在 REDCap 修改了该实例 Instance\_2 的值，引擎复核通过，底层 Field 变绿，绿灯逐级向上点亮，直至受试者恢复健康状态。
|
||
|
||
## **第二章 CRA 质控工作优先级策略**
|
||
|
||
面对庞杂的临床规则，我们应遵循\*\*“高频易错、AI 擅长、IIT 痛点”\*\*的原则排定工作优先级：
|
||
|
||
### **📌 优先级一：P0 级（系统上线必须具备的核心基石）**
|
||
|
||
这些是 IIT 试验中最容易崩盘，且传统 CRC 最头疼的硬逻辑工作。AI 处理这些具有 100% 的准确性和碾压级效率。
|
||
|
||
1. **D2 数据完整性 (Completeness)**：扫描 Form、Instance 和 Field 级数据，基于 REDCap 的分支逻辑（Branching Logic）计算真实的缺失率。
|
||
2. **D3 逻辑准确性 (Accuracy \- Edit Checks)**：时序校验（知情同意 \< 筛选 \< 首次用药）、数值极值校验、跨表单关联必填项校验。
|
||
3. **D1 入排合规性 (Eligibility)**：对入选/排除标准表单进行强逻辑逆向校验。
|
||
|
||
### **📌 优先级二：P1 级（建立系统护城河的亮点功能）**
|
||
|
||
1. **D8 核心数据 SDV 强制核对 (AI Vision)**：针对主要研究终点（如肿瘤大小、关键生化指标），强制要求 CRC 在前端上传原始影像/化验单。AI 通过多模态视觉比对。
|
||
2. **D5 安全性事件漏报侦测 (Safety)**：跨表单与跨实例关联。AI 发现化验单达到 3 级毒性，但 AE\_Log 表中没有任何一个 Instance 记录该事件，立刻触发告警。
|
||
|
||
### **📌 优先级三：P2 级（锦上添花的拓展功能）**
|
||
|
||
* **D6 方案偏离 (超窗检测)** 与 **D7 试验药物依从性管理**。由于 IIT 很多是非药物研究且随访不严，可作为可选模块后期加入。
|
||
|
||
## **第三章 以终为始：多维 CRA 质控报告体系设计**
|
||
|
||
结合系统化的 SaaS 管理看板与极其严谨的 GCP 规范要求，我们将最终输出的质控报告划分为两大层级：**“宏观管理驾驶舱层”与“核心业务报表层”**。
|
||
|
||
### **3.1 宏观管理层 (Executive Dashboard)**
|
||
|
||
用于系统前台实时展示，提供全局项目健康度：
|
||
|
||
* **项目综合健康度评分**（基于 D1\~D6 加权计算）。
|
||
* **受试者风险热力图**（直观展示哪位受试者的哪个表单异常）。
|
||
* **CRC 数据录入绩效**（eQuery 平均关闭时间、录入时效）。
|
||
|
||
### **3.2 核心业务报表层 (GCP 规范自动化日志)**
|
||
|
||
这是数字 CRA 真正替代人工的交付物。系统基于“五层数据底座”结合 AI 判定，**自动生成以下 5 张标准化的临床记录表**：
|
||
|
||
#### **表 1：筛选与入选登记表 (对应 D1)**
|
||
|
||
* **涵盖字段**：筛选编号、性别/年龄、诊断、纳入/排除标准是否符合（AI 判定）、筛选结果（入组/失败）、失败原因（AI 自动抓取不符条款）、电子签名。
|
||
|
||
#### **表 2：数据录入率 & 缺失率记录表 (对应 D2)**
|
||
|
||
* **涵盖字段**：表格名称、应录入总字段数（基于 Branching Logic 动态计算）、实际已录入字段数、**数据录入率 & 缺失率 %**、缺失变量与原因、审核时间戳。
|
||
|
||
#### **表 3：数据质疑管理跟踪表 (eQuery Log) (对应 D3/D4)**
|
||
|
||
* **涵盖字段**：质疑编号、5层精确坐标定位、AI 质疑描述（客观描述矛盾点）、发现日期/发现人(AI)、CRC 解释与回复、二次复核状态、关闭日期。
|
||
|
||
#### **表 4：AE 不良事件记录与监查表 (对应 D5 \- 核心合规文件)**
|
||
|
||
* **涵盖字段**：受试者信息、AE 名称/症状、起止日期、严重程度、**与干预的因果关系（AI 提示禁忌，PI 最终定性）**、处理措施与转归、SAE 时效监控、**⚠️ AI 挖掘出的疑似漏报事件高亮**。
|
||
|
||
#### **表 5：方案偏离记录表 (PD Log) (对应 D6)**
|
||
|
||
* **涵盖字段**：偏离编号、发生日期、**偏离类型（AI 自动分类：超窗/禁忌用药/未采集等）**、偏离描述、对安全性影响评估（AI 初判，人工复核）、纠正预防措施(CAPA)。
|
||
|
||
## **第四章 架构的 LLM 友好性设计与优化 (LLM Readiness)**
|
||
|
||
我们的 5 层级联树状架构，天生就是为了喂给 LLM 而设计的最佳结构。采用四大 LLM 优化策略：
|
||
|
||
### **优化 1：语义化映射网关 (AutoMapper) —— 解决 LLM 看不懂**
|
||
|
||
* **痛点**：REDCap 导出的变量名叫 lb\_dt, ae\_yn。
|
||
* **优化**：通过 iit\_field\_mapping 表，将其转换为具有临床语义的键：{"采样日期": "2026-02-25", "是否发生不良事件": "否"}。
|
||
|
||
### **优化 2：基于实例的剪枝 (Instance-Level Pruning) —— 解决 Token 溢出**
|
||
|
||
* **痛点**：写报告时没必要把 95% 正确的数据喂给模型。
|
||
* **优化**：执行 JSON 树剪枝。只 query 出 qc\_field\_status \= 'FAIL' 的那一小块实例分支：
|
||
{"受试者\_P005": {"不良事件表": \[{"Instance\_2": {"事件": "发烧", "质控": "未填严重程度"}}\]}}。
|
||
|
||
### **优化 3：XML 提示词封装 —— 解决上下文幻觉**
|
||
|
||
* 利用 \<record\>, \<event\>, \<form\>, \<instance\> 严格包裹数据，先进的大模型对 XML 层级的理解极佳，能完美规避张冠李戴。
|
||
|
||
### **优化 4：计算下放 (CPU over GPU) —— 解决算术薄弱**
|
||
|
||
* LLM 绝对不做日期和数值计算（如算缺失率百分比、算超窗天数）。所有硬核计算由 Node.js HardRuleEngine 算好，直接把“结论标签”传给 LLM 组装文字。 |