# CRA Agent 质控体系全景技术路径（策略评审稿） > **文档性质**：策略与路径评审文档，供团队内部和临床研究专家讨论可行性 > **版本**：V1.0 | 2026-03-01 > **目标读者**：技术团队、产品负责人、临床研究顾问 > **下一步**：经评审认可后，基于本文档形成具体开发计划 --- ## 一、背景与核心问题 ### 1.1 CRA 做什么 临床监查员（CRA）的工作本质上是一个**多维度的数据质量守门人**。参照行业标准（ICH-GCP E6 R2/R3），CRA 在常规监查阶段的工作可以分解为以下 7 个维度： | 维度 | CRA 具体工作 | 输出物 | |------|------------|--------| | **D1 入组质量** | 核查入排标准、知情同意时序、筛选流程 | 筛选与入组日志 | | **D2 数据完整性** | 检查缺失字段、录入时效、分支逻辑完整性 | 数据缺失率报表 | | **D3 变量准确性** | 极值校验、时序逻辑、跨表单关联 | 变量质控清单 | | **D4 数据质疑管理** | 生成 Query、跟踪回复、二次复核、关闭 | eQuery 清单 | | **D5 安全性监测** | AE/SAE 识别、编码、分级、因果判定、时效监管 | AE/SAE 追踪表 | | **D6 方案偏离侦测** | 访视超窗、剂量偏差、操作遗漏、CAPA 跟踪 | 方案偏离记录 | | **D7 药物管理** | 发药/回收核算、依从性计算、批号追踪 | IP 管理明细 | 以上 7 个维度最终汇聚为一张 **项目健康度评分卡**，供 PI 和项目管理层决策。 ### 1.2 我们现在能做什么 当前 CRA Agent 系统已实现的能力： ``` ┌──────────────────────────────────────────┐ │ CRA 工作全景（7 维度） │ │ │ 已实现 ──────► │ ■ D1 入组质量（入排标准规则已有） │ │ □ D2 数据完整性 │ 部分实现 ────► │ ■ D3 变量准确性（基础范围检查） │ │ □ D4 数据质疑管理（eQuery 表已建） │ │ □ D5 安全性监测 │ │ □ D6 方案偏离侦测 │ 未涉及 ─────► │ □ D7 药物管理 │ │ │ │ □ 项目健康度评分卡 │ └──────────────────────────────────────────┘ ■ 已实现 ■ 部分实现 □ 未涉及 ``` **覆盖率估算**：约 20-25%（仅 D1 部分 + D3 基础），距离替代 CRA 70-80% 工作的目标差距明显。 ### 1.3 差距的根源 差距不仅是"规则数量不够"，而是**架构层面的三个结构性问题**： | 问题 | 影响 | |------|------| | **规则体系缺乏分类** | 所有规则混在一起，无法按 CRA 工作维度组织和统计 | | **数据结构粒度不足** | 只有记录级状态，缺少事件级和变量级独立状态表 | | **报告缺乏维度** | 只有一张扁平的"通过/不通过"报告，无法反映 7 个维度的各自状况 | --- ## 二、核心认知：一条完整的链路 ### 2.1 从方案到报告的 1:1 映射链 ``` 研究方案（Protocol） │ │ "年龄 16-35 岁、已签知情同意、无排除标准..." │ ▼ 变量清单（Data Dictionary） │ │ age(数值型)、consent_date(日期型)、exclusion_criteria(选择型)... │ ▼ 质控规则（QC Rules）──── 按 7 大维度分类 │ │ D1: { "and": [{">=": ["age", 16]}, {"<=": ["age", 35]}] } │ D3: { "<": ["consent_date", "screening_date"] } │ D6: { "<=": [{"abs_diff": ["visit_date", "target_date"]}, 3] } │ ▼ 三级质控状态（变量级 → 事件级 → 记录级） │ │ record_3 / baseline / exclusion_criteria → FAIL (D1:排除标准) │ record_3 / baseline → FAIL │ record_3 → FAIL │ ▼ 多维质控报告（7 个维度各自独立汇总） │ │ D1 入组质量: 13/14 通过 (92.9%) │ D3 变量准确性: 98.5% 合格率 │ D5 安全性: 0 例未报告 AE │ ... │ ▼ 项目健康度评分（加权综合） │ │ 综合评分: 87/100 │ 建议: 关注 3 号受试者入组资格 │ ▼ 行动（eQuery 派发 / 告警推送 / 监查报告） ``` **关键洞察**：这条链路中的每一环都需要"维度（category）"这根线串起来。变量清单中的字段属于哪个表单→ 规则属于哪个维度→ 质控结果按维度汇总→ 报告按维度呈现。 ### 2.2 IIT 场景的特殊性 我们的目标用户是 IIT（研究者发起的试验），与注册临床试验有显著区别： | 特征 | 注册试验 | IIT 项目 | |------|---------|---------| | 有无专职 CRA | 有，全职 CRA 团队 | 通常没有，或仅兼职 | | 监管严格度 | 极高（FDA/NMPA 审查） | 中等（伦理委员会审查） | | EDC 系统 | 商业 EDC（Medidata 等） | 多用 REDCap（免费） | | 预算 | 充足 | 有限 | | AI 替代的意义 | 从 100% 提升到 110%（锦上添花） | **从 0% 提升到 70%（雪中送炭）** | **这意味着**： - 我们不需要追求注册试验级别的完美覆盖 - 优先覆盖 IIT 中**最常出问题、最容易被忽视**的维度 - 先做"有胜于无"的基础覆盖，再做精细化提升 --- ## 三、技术路径：三阶段演进 ### 阶段一：数据质量基石（当前 → 近期） **目标**：把已有的能力做扎实，建立正确的数据基础架构。 #### 核心工作 ``` 1. 三级质控数据结构 ├── 变量级状态表（qc_field_status） ├── 事件级状态表（qc_event_status） └── 记录级状态表（record_summary 改造） 2. 规则分类体系 └── 每条规则标注所属维度（D1-D7） 3. 多模式触发 ├── 实时触发（REDCap DET Webhook，已有代码） ├── 定时触发（项目级 Cron 配置，取代全局硬编码） └── 手动触发（一键全量质控 + AI 对话） 4. 报告结构升级 └── 从扁平报告 → 多维度报告框架 ``` #### 覆盖的 CRA 维度 | 维度 | 阶段一目标 | |------|-----------| | D1 入组质量 | 已有入排规则，补充知情同意时序检查 | | D3 变量准确性 | 已有范围检查，补充时序逻辑和跨表单关联 | | D4 数据质疑 | 已有 eQuery 表，补充闭环状态机 | #### 需要确认的问题 > **问临床专家**： > 1. IIT 项目中，入排标准检查和变量范围检查是否是最高优先级？ > 2. 知情同意日期 < 筛选日期 < 基线日期的时序校验，在 IIT 中是否必须？ > 3. 跨表单校验（如性别 vs 妊娠检查）在 IIT 中常见吗？ --- ### 阶段二：方案合规覆盖（中期） **目标**：覆盖 CRA 日常监查中最高频的工作——数据完整性检查和方案偏离侦测。 #### 核心工作 ``` 1. 数据完整性引擎（D2） ├── 按事件/表单统计应填字段 vs 实际已填 ├── 分支逻辑感知（排除不应填的字段） ├── 录入时效统计（REDCap 审计日志 → 计算延迟天数） └── 缺失率阈值告警 2. 方案偏离侦测引擎（D6） ├── 访视窗口检查（目标日 ± 允许天数） ├── 操作遗漏检查（Schedule of Assessment 对照） └── 偏离严重性自动分级（Major / Minor） 3. 报告增强 ├── 新增"数据完整性"章节 ├── 新增"方案偏离"章节 └── 健康度评分初版（D1+D2+D3+D6 加权） ``` #### 覆盖的 CRA 维度 | 维度 | 阶段二目标 | |------|-----------| | D2 数据完整性 | **新增**：缺失率、录入时效、分支逻辑计算 | | D6 方案偏离 | **新增**：超窗检测、操作遗漏、偏离分级 | #### 需要确认的问题 > **问临床专家**： > 1. IIT 项目中最常见的方案偏离类型是什么？（超窗？漏检？用药偏差？） > 2. 访视窗口 ±N 天的 N 值，一般如何确定？是每个方案不同还是有通用标准？ > 3. 数据缺失率到多少算"红灯"？IIT 行业有没有通用标准（如 3%、5%）？ > 4. 分支逻辑的处理——REDCap 中的分支逻辑字段在 Data Dictionary 中是否完整可读？ #### 技术前提 - **依赖阶段一**的三级数据结构和规则分类体系 - 需要从 REDCap 拉取 Schedule of Assessment（表单-事件映射 + 必填字段清单） - 需要从 REDCap 审计日志（Logging API）获取录入时间信息 --- ### 阶段三：安全性与药物管理（远期） **目标**：覆盖 CRA 工作中专业性最强的部分——不良事件监测和药物管理。 #### 核心工作 ``` 1. AE/SAE 安全性引擎（D5） ├── AE 识别触发（实验室异常自动触发 AE 检查） ├── 严重程度分级（CTCAE 标准内嵌） ├── 时序逻辑（AE 起止时间 vs 用药时间） ├── SAE 时效监控（发现后 24h 上报 deadline） └── LLM 辅助：因果关系初步评估（概率性判断） 2. 药物依从性引擎（D7） ├── 发药/回收核算 ├── 依从性 = (发药量 - 回收量) / 预期量 × 100% ├── 80%-120% 合格区间判定 └── 批号有效期交叉比对 3. 实验室预警增强 ├── 绝对值 vs 正常范围 ├── 基线变化率监测（连续升高趋势） └── DILI（药物性肝损伤）早期预警模型 4. 合并用药核查 ├── 方案禁忌药物比对 ├── 新增用药 ↔ AE 关联推断 └── 洗脱期计算 5. 完整健康度评分 └── 7 维度加权综合评分 + AI 建议后续行动 ``` #### 覆盖的 CRA 维度 | 维度 | 阶段三目标 | |------|-----------| | D5 安全性监测 | **新增**：AE/SAE 追踪、时效监控、因果评估 | | D7 药物管理 | **新增**：依从性计算、批号追踪 | #### 需要确认的问题 > **问临床专家**： > 1. IIT 项目中，AE/SAE 的管理是由 PI 团队自行负责还是有外部安全委员会？ > 2. IIT 项目中是否普遍使用 CTCAE 分级？还是只在肿瘤相关 IIT 中常用？ > 3. 药物依从性在 IIT 中的重要性如何？是否每个 IIT 都涉及试验药物管理？ > 4. AI 做因果关系"初步评估"（而非最终判定），这在临床上能否被接受？ > 5. 合并用药的禁忌药物清单，是每个方案自定义还是有标准数据库可以引用？ #### 技术前提 - 依赖阶段一、二的基础设施 - AE/SAE 需要 REDCap 中有对应的 CRF 表单（不是所有 IIT 项目都有） - 因果关系评估涉及 LLM 概率性推理（SoftRuleEngine），需要人类确认机制 - 药物管理需要 IWRS 或 REDCap 药物管理模块的数据接口 --- ## 四、三级数据架构概要 三个阶段共用同一套数据架构，一次设计到位： ``` ┌──────────────────────────────────┐ │ qc_field_status │ │ (变量级，保持最新) │ │ │ │ project × record × event × field │ │ + status + rule_category │ │ + actual_value + expected_value │ └───────────────┬──────────────────┘ │ 聚合 ┌───────────────▼──────────────────┐ │ qc_event_status │ │ (事件级，保持最新) │ │ │ │ project × record × event │ │ + status (所有变量中最严重的) │ │ + 各维度计数 (d1_issues, d2_...) │ └───────────────┬──────────────────┘ │ 聚合 ┌───────────────▼──────────────────┘ │ record_summary │ │ (记录级，保持最新) │ │ │ │ project × record │ │ + overall_status (所有事件最严重) │ │ + events_total / passed / failed │ └───────────────┬──────────────────┘ │ 聚合 ┌───────────────▼──────────────────┐ │ 多维度质控报告 │ │ │ │ D1 入组质量: 92.9% │ │ D2 数据完整性: --（阶段二） │ │ D3 变量准确性: 98.5% │ │ D4 eQuery: 3 Open / 12 Closed │ │ D5 安全性: --（阶段三） │ │ D6 方案偏离: --（阶段二） │ │ D7 药物管理: --（阶段三） │ │ ───────────────────────── │ │ 健康度评分: 87 / 100 │ └──────────────────────────────────┘ ``` **关键设计决策**：`rule_category` 字段贯穿整个体系，阶段一只用到 `inclusion`/`exclusion`/`variable`，阶段二加入 `completeness`/`protocol_deviation`，阶段三加入 `ae_safety`/`ip_compliance`。**表结构不需要改，只是规则类别在扩展**。 --- ## 五、规则类型与引擎匹配 不同维度的规则，其"确定性"不同，需要匹配不同的执行引擎： | 维度 | 规则性质 | 适用引擎 | 举例 | |------|---------|---------|------| | D1 入组质量 | 确定性 100% | HardRuleEngine (JSON Logic) | age ∈ [16,35] | | D2 数据完整性 | 确定性 100% | 专用 CompletenessEngine | 必填字段 A 为空 | | D3 变量准确性 | 确定性 90%+ | HardRuleEngine | consent_date < screening_date | | D4 数据质疑 | 管理流程 | 状态机 (eQuery Workflow) | Open→Answered→Closed | | D5 安全性 | 确定性 60-80% | HardRule + SoftRuleEngine (LLM) | CTCAE 分级确定，因果关系需 LLM | | D6 方案偏离 | 确定性 95% | HardRuleEngine + 日历引擎 | visit_date 超出窗口 ±3 天 | | D7 药物管理 | 确定性 100% | HardRuleEngine | 依从性 = 85% ∈ [80,120] | **核心原则**： - **确定性规则用硬引擎**（HardRuleEngine / JSON Logic）——结果可审计、可复现 - **概率性判断用软引擎**（SoftRuleEngine / LLM）——必须附带"AI 建议 + 人类确认"机制 - **D4 不是规则引擎问题**，而是流程管理问题（状态机） --- ## 六、覆盖率演进预期 ``` 100%─┬───────────────────────────────────────────── │ ┌─────── 80%─┤ ┌────────┤ 阶段三 │ │ D5+D7 │ 70-80% 60%─┤ ┌───────────┤ │ │ │ D2+D6 │ 阶段二 │ 40%─┤ │ │ 50-60% │ │ ┌──────────┤ │ │ 20%─┤ │ D1+D3+D4 │ 阶段一 │ │ │ │ │ 25-35% │ │ 0%─┴──┴──────────┴───────────┴────────┴───────── 现状 阶段一 阶段二 阶段三 ``` **说明**：百分比是估算值，表示对 CRA 可替代工作（70-80%）的覆盖程度。阶段三完成后，系统应能覆盖 CRA 可替代工作的绝大部分。 --- ## 七、与现有四大工具的关系 当前对话层的 4 个工具（`read_report`、`look_up_data`、`check_quality`、`search_knowledge`）在三个阶段中保持稳定，**工具不变，内涵在扩展**： | 工具 | 阶段一 | 阶段二 | 阶段三 | |------|--------|--------|--------| | `read_report` | D1+D3 报告 | + D2+D6 章节 | + D5+D7 章节 + 健康度评分 | | `look_up_data` | 原始数据 + 质控标注 | + 缺失率标注 | + AE/ConMed 数据 | | `check_quality` | 入排 + 变量检查 | + 完整性 + 偏离检查 | + AE + 依从性检查 | | `search_knowledge` | 研究方案/CRF 搜索 | + Schedule of Assessment | + IB（研究者手册） | **这是一个很好的设计**——对 LLM 来说，工具数量和接口不变，它不需要"学习"新工具。内部的规则引擎和报告内容在持续丰富，对 LLM 透明。 --- ## 八、风险与约束 ### 8.1 数据源约束 | 数据需求 | 来源 | 约束 | |---------|------|------| | 变量值 | REDCap Record API | ✅ 已打通 | | 变量定义（Data Dictionary） | REDCap Metadata API | ✅ 已打通 | | 表单-事件映射 | REDCap Form-Event API | ✅ 已打通 | | 录入时间（审计日志） | REDCap Logging API | ✅ 已实现（exportLogging） | | 分支逻辑 | Data Dictionary.branching_logic | ⚠️ 需解析 REDCap 分支逻辑语法 | | Schedule of Assessment | 研究方案 PDF + 人工配置 | ⚠️ 需要项目管理员手动配置 | | AE/SAE 表单 | REDCap CRF | ⚠️ 取决于项目是否建了 AE 表单 | | 药物管理数据 | REDCap CRF 或外部 IWRS | ❌ 可能不在 REDCap 中 | ### 8.2 IIT 场景的现实约束 - **不是所有 IIT 都有 AE 表单**：观察性研究可能没有不良事件采集 - **不是所有 IIT 都涉及试验药物**：非药物干预研究（如手术方案对比）无 D7 - **方案复杂度差异大**：简单的 IIT 可能只有 2 个访视，复杂的可能有 20+ - **REDCap 配置标准化程度低**：不同机构的 REDCap 项目结构差异很大 **应对策略**：系统必须支持"维度可选"——管理员在项目配置时勾选本项目适用的维度，未勾选的维度不执行、不展示。 ### 8.3 LLM 在临床决策中的边界 | 场景 | LLM 角色 | 人类角色 | |------|---------|---------| | 数值范围检查 | 直接判定 | 不需要 | | 时序逻辑检查 | 直接判定 | 不需要 | | 数据缺失统计 | 直接计算 | 不需要 | | AE 严重程度分级 | 根据 CTCAE 标准建议分级 | PI 确认 | | AE 因果关系 | **初步评估（建议）** | **PI 必须确认** | | 方案偏离严重性 | 按规则初分 Major/Minor | PI 可修正 | | 综合健康度建议 | 提供建议行动 | PI 决策 | **铁律**：凡涉及医学判断的结论，AI 只提供建议，必须经人类确认后才能写入正式记录。 --- ## 九、待讨论的关键问题 以下问题需要在技术评审中与临床研究专家确认： ### 优先级与范围 1. **IIT 项目中，以下 7 个维度的重要性排序是什么？** 哪些是"必须有"，哪些是"有了更好"？ 2. **D5（安全性）和 D7（药物管理）在 IIT 中的覆盖率有多高？** 是不是很多 IIT 项目并不涉及？ 3. **三个阶段的划分是否合理？** 是否有维度需要提前或推迟？ ### 规则可行性 4. **时序逻辑的通用性**：知情同意日 < 筛选日 < 基线日，这个时序在所有 IIT 中都成立吗？ 5. **访视窗口**：IIT 中 ±N 天的窗口一般怎么定？是写在方案里的还是有行业惯例？ 6. **数据缺失率的"红线"**：IIT 行业是否有通用的缺失率阈值标准？ 7. **跨表单校验的实用性**：性别 vs 妊娠检查这类跨表单逻辑在 IIT 中常见吗？ ### 临床接受度 8. **AI 做因果关系"初步评估"**，PI 是否愿意参考？还是更倾向完全自行判断？ 9. **自动生成的 eQuery 语气和内容**，是否需要 PI 先审核再发给 CRC？ 10. **健康度评分**：PI 能否接受一个 AI 打分？评分维度和权重怎么定才合理？ ### 数据源 11. **REDCap 中 Schedule of Assessment 的信息**是否足够完整？还是需要额外配置？ 12. **AE 表单在 IIT REDCap 项目中的标准化程度如何？** 字段命名是否有规范？ --- ## 十、总结 ``` ┌──────────────────────────────────────────────────────────────────────┐ │ │ │ 研究方案 ──→ 变量清单 ──→ 质控规则 ──→ 三级质控状态 ──→ 多维报告 │ │ (7大维度) (变量/事件/记录) (7大章节) │ │ │ │ 阶段一：D1 入组 + D3 变量 + D4 eQuery ── 数据质量基石 │ │ 阶段二：D2 完整性 + D6 方案偏离 ── 方案合规覆盖 │ │ 阶段三：D5 安全性 + D7 药物管理 ── 全维度覆盖 │ │ │ │ 确定性规则 → HardRuleEngine（可审计、可复现） │ │ 概率性判断 → SoftRuleEngine + LLM（AI 建议 + 人类确认） │ │ │ │ 工具层不变（4 工具），内涵逐步扩展 │ │ 数据架构一次设计到位（三级状态表 + rule_category 字段） │ │ │ └──────────────────────────────────────────────────────────────────────┘ ``` **本文档的目的不是确定"怎么做"，而是确定"做什么、按什么顺序做、做到什么程度"。** 经团队和临床专家评审认可后，再基于此形成具体的开发计划和技术设计。