3. 临床数据源与数据流解析
临床数据核查自动化的第一步，不是写规则，而是把“数据从哪来、以什么形态到达、在哪里落地、以什么键关联”搞清楚。同一个受试者在一次访视中产生的数据，可能同时来自 EDC 表单录入、ePRO 受试者自填、IWRS 随机发药、中心实验室的 LB 传输、影像中心的阅片结论，以及作为源文件的电子源数据（eSource）。这些来源的接口方式、格式特征、到达时延和可核查粒度差异极大，若不加区分地套用同一套核查逻辑，自动化规则会在错误的对象上触发，产生大量假阳性。
六类数据源的接口与格式特征
EDC（电子数据采集）是临床数据的主干。数据以“受试者—访视—表单—字段”四级结构组织，接口通常为 REST API 或数据库直连，格式以 JSON/XML 为主，字段带数据类型、编码列表（codelist）和编辑检查（edit check）状态。核查自动化最关心的是字段级元数据：字段 OID、数据类型、是否必填、关联的访视与表单、以及录入时间戳与修改审计轨迹。EDC 的核查优势在于结构稳定、键明确（SubjectID + Visit + FormOID + ItemOID），适合做跨表单一致性核查。
ePRO（电子患者报告结局）由受试者直接填写，接口多为厂商云平台的增量导出或 API 拉取，格式常见为带时间戳的条目级记录。其关键特征是“填写时间”与“访视窗口”可能不一致，且存在受试者漏填、补填、逻辑跳转导致的空值。核查时需区分“未填”与“不适用”，并关注填写时间是否落在访视窗口内。
IWRS（交互式网络应答系统）负责随机化与药物发放，接口通常为事务型 API 或定期对账文件，格式为随机号、受试者号、发药批次、发药日期等结构化记录。IWRS 数据量小但一致性要求极高，核查重点是随机号与受试者号的一一对应、发药记录与 EDC 中给药表单的一致性、以及随机化日期与知情同意日期的先后关系。
实验室数据（LB）通常由中心实验室以固定宽度的文本文件、CSV 或 SAS 传输文件（如 CDISC LAB 模型）批量送达，按“受试者—访视—采样时间—检验项目—结果—单位—参考范围”组织。其格式特征是长表结构、单位与参考范围随项目变化、存在低于检测限（如 <0.5）等非数值结果。核查需处理单位换算、参考范围区间判断和异常值标记。
影像数据分为影像文件（DICOM）与阅片结论（如 RECIST 评估）。DICOM 以患者 ID、检查日期、序列号标识，文件体积大，通常不进入 EDC，而是通过影像管理系统（如独立阅片中心）提供评估结果表。核查自动化主要针对阅片结论与 EDC 中肿瘤评估表单的一致性、评估日期与访视日期的匹配。
电子源数据与源文件核查是近年监管重点。电子源数据指在源系统（如医院 HIS、电子病历、eSource 平台）中直接生成的原始记录，接口常为只读 API 或数据抽取视图，格式多样且缺乏统一标准。源文件核查（SDV）要求核查者能追溯到原始记录，因此自动化需要保留源数据的定位信息（如病历号、记录时间、页面标识），并支持“EDC 值 ↔ 源值”的逐字段比对。
数据流中的关键关联键
多源数据能否被自动化核查，取决于关联键是否稳定。实践中真正可用的主键组合是：SubjectID + Visit + 时间点。EDC 用 FormOID/ItemOID 定位字段，LB 用检验项目代码与采样时间定位结果，IWRS 用随机号与发药日期定位事务，影像用检查序列号与评估日期定位结论。当这些键在汇聚层被统一映射后，跨源核查才具备可执行性。例如核查“随机化日期是否早于首次给药日期”，需要从 IWRS 取随机化日期、从 EDC 给药表单取给药日期，两者通过 SubjectID 关联；若 IWRS 只提供随机号而未回传受试者号，则关联断裂，规则无法落地。
格式差异带来的核查处理要点
实验室数据的长表结构意味着同一受试者一次访视会产生多行记录，核查规则需按“受试者+访视+检验项目”分组后再判断，而不能逐行独立判断。低于检测限的结果（如 <0.5）在数值比较前必须先识别为非数值，否则单位换算和区间判断都会出错。ePRO 的条目级时间戳需要与 EDC 访视日期做窗口比对，窗口定义应来自方案，例如“访视日 ±3 天”，超出即触发质疑。影像阅片结论与 EDC 肿瘤评估表单的比对，重点在评估日期与靶病灶测量值，而非影像文件本身。
电子源数据与源文件核查的特殊性在于：源数据往往不在 EDC 内，而在医院系统或 eSource 平台。自动化方案需要建立“EDC 字段 → 源系统查询条件”的映射，并保留源记录的定位信息（如病历号、记录时间、页面或接口返回标识），使核查结果可被追溯和复核。若源系统仅提供只读视图且无稳定主键，则应退化为人工抽样核查，而不是强行自动化。
一个可执行的源—目标映射示例
下表给出一个简化的映射配置示例，用于说明自动化核查前必须明确的字段对应关系。示例参数为教学假设，实际项目应按方案与传输规范填写。
| 数据源 | 源字段/定位 | 目标字段（统一模型） | 关联键 | 核查用途 |
|---|---|---|---|---|
| EDC | DM.BRTHDTC | BRTHDTC | SubjectID | 年龄计算与入排核查 |
| IWRS | RANDDT / RANDNO | RANDDT / RANDNO | SubjectID | 随机化日期≤首次给药 |
| LB | LBTESTCD / LBORRES / LBORRESU | TESTCD / ORRES / ORRESU | SubjectID+Visit+采样时间 | 单位换算与参考范围判断 |
| ePRO | ItemOID / 填写时间戳 | ITEM / FILLDT | SubjectID+Visit | 访视窗口内填写核查 |
| 影像 | 检查序列号 / 评估日期 / 靶病灶测量 | IMGDAT / LESION | SubjectID+评估日期 | 与 EDC 肿瘤评估一致性 |
| 电子源数据 | 病历号 / 记录时间 / 源值 | SRCKEY / SRCDT / SRCVAL | SubjectID+字段 | SDV 逐字段比对 |
把这张映射表落到代码层面，核查规则才具备可执行形态。例如一条“随机化日期不得晚于首次给药日期”的规则，其伪代码逻辑为：从 IWRS 取 RANDDT，从 EDC 给药表单取 EXSTDTC，按 SubjectID 关联，若 RANDDT > EXSTDTC 则生成质疑，质疑内容携带两个日期值与来源标识。规则本身简单，难点在于两个日期字段的格式统一（日期 vs 日期时间）和缺失处理（任一为空时不触发，标记为待补）。
综上，六类数据源的接口与格式差异决定了核查自动化的分层设计：源层负责按各自接口稳定采集，汇聚层负责主键对齐与格式标准化，规则层负责跨源一致性与时间逻辑判断，输出层负责携带完整定位信息的结果交付。只有把“数据从哪来、以什么键关联、以什么格式落地”这三件事在工程上固定下来，后续的规则编写与批量核查才有可靠基础。