# **CRA 质控报告自动化生成与 LLM 友好型设计规范**

**文档版本**：V2.1 (5 层架构剪枝与 LLM 实战版)

**设计目标**：利用“五层数据坐标剪枝”与“语义组装”，形成对大模型（LLM）极度友好、绝不产生幻觉的 Payload。

## **核心设计原则：LLM 友好性 (LLM Readiness)**

要让 LLM 稳定输出，必须遵循“三不”原则：

1. **不喂全量数据**：依托 5 层架构执行 JSON 树剪枝，只提取 status \= FAIL 的切片。  
2. **不喂物理字段**：所有的 lb\_alt\_v 必须经过 AutoMapper 映射为 谷丙转氨酶(ALT)。  
3. **不让 LLM 算数**：日期差、缺失率由 Node.js 算好，直接把“结论标签”喂给 LLM。

## **报告生成链路与 LLM 模拟实战 (基于 5 层坐标)**

### **场景一：数据质疑管理 (eQuery Log) \- D3 规则**

**【业务场景】** D3 逻辑发现异常，生成一条像资深 CRA 写的质疑描述。

**【剪枝后的 5层 LLM 友好输入片段 ✅】**

{  
  "system\_instruction": "你是一个严谨的临床数据经理。请根据下方异常数据，生成一条专业的电子质疑（eQuery）。指出矛盾点并给建议，100字以内。",  
  "clinical\_context": {  
    "受试者ID": "P005",  
    "访视阶段": "随访2 (Week 4)",  
    "触发表单": "实验室检查",  
    "数据实例": "Instance 1"  
  },  
  "anomaly\_data": {  
    "异常指标": "谷丙转氨酶 (ALT)",  
    "当前录入值": "150 U/L",  
    "HardRuleEngine\_计算结论": "超出正常上限 (50 U/L) 的 3 倍",  
    "跨表核查结果": "查询《不良事件(AE)表》所有 Instance，当前记录数为 0"  
  }  
}

**【LLM 输出示例】**

“检测到该受试者在「随访2」的「实验室检查」中，谷丙转氨酶(ALT)为 150 U/L，已超出正常上限 3 倍。经跨表核查，未发现对应的《不良事件(AE)》记录。请核实检验结果是否录入无误；若无误，请评估是否需要补充填报 AE。”

### **场景二：不良事件风险评估 (AE Log) \- D5 规则**

**【业务场景】** 提取录入的 AE，结合患者的其他重复表单（如多次服药），提示风险。

**【应对重复表单 (Repeating Forms) 的完美 JSON 结构 ✅】**

系统精确拉取 AE\_Log 和 ConMed\_Log 下的不同 InstanceID：

{  
  "system\_instruction": "作为临床安全评估助手，请分析患者新发的 AE，结合既往病史和用药，提示潜在风险关联。你无权下定论，仅供 PI 参考。",  
  "patient\_context": {  
    "受试者": "P012",  
    "合并用药表 (ConMed\_Log)": \[  
      {"instance\_id": 1, "药物名称": "阿司匹林"},  
      {"instance\_id": 2, "药物名称": "布洛芬"}  
    \]  
  },  
  "不良事件表 (AE\_Log)": \[  
    {"instance\_id": 3, "事件名称": "消化道出血", "严重程度": "CTCAE 3级"}  
  \],  
  "rag\_knowledge\_retrieval": "方案规定：非甾体抗炎药（NSAIDs）如布洛芬、阿司匹林联用会显著增加消化道出血风险。"  
}

**【LLM 输出示例】**

“该受试者新发 3 级「消化道出血」(Instance 3)。系统监测到患者正在同时服用「阿司匹林」(Instance 1)与「布洛芬」(Instance 2)。结合方案提示，非甾体抗炎药联用是高危出血因素。建议 PI 重点关注该 AE 是否与合并用药具有因果关系。”

### **场景三：方案偏离记录 (PD Log) \- D6 规则**

**【喂给 LLM 的切片 ✅】**

{  
  "system\_instruction": "请根据硬逻辑引擎计算出的偏差事实，撰写连贯的方案偏离描述，并提出纠正预防措施(CAPA)。",  
  "deviation\_facts": {  
    "坐标": "Record:P002 \-\> Event:随访3 \-\> Form:访视表 \-\> Instance:1",  
    "偏离类型": "访视超窗",  
    "HardRuleEngine\_计算依据": {  
      "方案允许窗口": "2026-02-15 ±3天",  
      "实际发生日期": "2026-02-25",  
      "计算结果": "延误 10 天"  
    }  
  }  
}

### **场景四：数据缺失率总结 (Missing Rate Log) \- D2 规则**

**【特殊说明：此报告尽量不用 LLM】**

数据缺失率表严禁使用 LLM 计算百分比！完全由 Node.js CompletenessEngine 根据 Instance 和分支逻辑动态计算完成。LLM 仅根据最终聚合数值生成执行摘要。

**【喂给 LLM 的切片 ✅】**

{  
  "report\_type": "数据完整性摘要",  
  "total\_missing\_rate": "5.0%",  
  "top\_missing\_forms": \[  
    {"form": "SF-36 生活质量问卷", "missing\_rate": "40%"}  
  \],  
  "task": "基于以上统计数据，写两句话的执行摘要。"  
}

**技术收益总结**：

五层架构（特别是 InstanceID 实例层）的引入，让发给 LLM 的 JSON 数据结构具备了完美的数组映射能力，彻底消灭了多行数据相互覆盖的 Bug，并最大程度防范了 AI 幻觉！