# **纯数字 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 组装文字。