AIclinicalresearch/docs/03-业务模块/IIT Manager Agent/09-技术评审报告/核心数据架构与业务落地白皮书.md

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