2. 数字临床试验数据追溯工程的整体架构

数字临床试验的数据追溯工程，本质上是在“数据从产生到进入监管报告”的整条链路上，建立一套可验证、可定位、可复现的追溯关系。它要回答三个问题：这条数据最初由谁、在什么系统、以什么形式产生；它经过了哪些系统、接口和转换；最终进入分析或报告时，能否反向定位到原始记录。围绕这三个问题，追溯工程的技术边界可以定义为：覆盖从数据采集、传输、存储、处理到报告的全链路，但不替代各业务系统自身的功能，也不替代统计分析与医学判断，而是为这些环节提供“来源可查、去向可追、责任可定”的追溯能力。

从参考架构看，整条链路可以划分为五个层次：采集层、传输层、存储层、处理层和报告层。采集层是追溯的起点，核心对象包括EDC（电子数据采集系统）、eSource（电子源数据）、ePRO（电子患者报告结局）、IRT（交互式响应技术，用于随机化和药物供应）以及CTMS（临床试验管理系统）。这些系统各自产生不同性质的数据：EDC产生病例报告表数据，eSource产生原始诊疗记录，ePRO产生患者自报数据，IRT产生随机号和发药记录，CTMS产生受试者访视和项目管理数据。追溯工程并不要求把这些系统合并成一个系统，而是要求每个系统在产生数据时，同时产生可被下游识别的追溯标识，例如受试者唯一标识、访视标识、表单标识、记录版本号和操作时间戳。

传输层负责把采集层的数据安全、完整地送到存储层。这里的关键不是“传过去”，而是“传过去之后还能证明传的是哪一份”。因此，传输层需要记录数据来源系统、目标系统、传输时间、传输批次、校验值和传输状态。常见方式包括基于API的实时传输、基于文件的批量传输以及基于消息队列的异步传输。无论哪种方式，追溯工程都要求传输日志与业务数据分离保存，避免业务系统修改数据时把传输痕迹一并覆盖。

存储层是追溯工程的“证据底座”。它通常不是单一数据库，而是由原始层、清洗层和汇总层组成。原始层保存从各系统落地的最初数据，原则上不做修改；清洗层保存经过格式统一、编码映射和逻辑核查后的数据；汇总层保存供分析和报告使用的派生数据。三层之间通过数据血缘关系连接：每一条汇总数据都能追溯到清洗层记录，每一条清洗层记录都能追溯到原始层记录。存储层还需要保存元数据，包括数据字典版本、编码版本、衍生规则版本和操作审计日志。

处理层承担数据转换、衍生和核查。例如，将eSource中的实验室检查值转换为标准单位，将ePRO中的症状评分按时间窗归入对应访视，将IRT中的随机号与EDC中的受试者标识进行匹配。处理层的追溯重点是“规则可查、版本可追、结果可复现”。同一个衍生指标在不同时间点可能使用不同规则版本，追溯工程要求记录每次处理所用的规则版本和输入数据集版本，否则报告中的数据无法解释。

报告层是追溯链的终点，也是监管和审计最关注的环节。报告层包括统计分析报告、临床研究报告、数据管理报告和监管递交文档。追溯工程要求报告中的每一个关键数据点都能反向链接到数据源。例如，报告中某受试者的不良事件发生率，应能追溯到EDC中的不良事件表单、eSource中的原始记录以及相关的医学编码版本。

这张参考架构图强调的不是“系统越多越好”，而是“每个系统在链路中承担什么追溯责任”。EDC、eSource、ePRO、IRT、CTMS各自产生数据，但追溯工程要求它们通过统一的标识体系连接起来。例如，受试者唯一标识在EDC中可能是“S001”，在ePRO中可能是“P001”，在IRT中可能是“R001”，追溯工程需要建立映射表，使同一个受试者在不同系统中的记录能够被关联。这个映射表本身也是追溯对象，需要记录映射规则、生效时间和变更历史。

在实际落地时，建议先定义追溯标识规范，再定义接口规范，最后定义存储和处理规则。追溯标识规范应明确：受试者标识、访视标识、表单标识、记录标识、操作标识的格式和生成规则。接口规范应明确：每个系统对外提供哪些追溯字段、以什么频率、通过什么协议、失败如何处理。存储和处理规则应明确：原始层保留多久、清洗层如何映射、汇总层如何衍生、规则版本如何管理。

从技术边界看，追溯工程不负责医学判断，也不负责统计方法选择，但它必须为这些活动提供可验证的数据来源。例如，统计师决定用某次访视的实验室值做分析，追溯工程要能证明这次访视的实验室值来自哪台设备、哪个eSource记录、经过哪些转换。数据管理员决定清理某条异常值，追溯工程要能记录清理前后的值、清理人、清理时间和清理理由。这些记录不是额外负担，而是监管递交和现场核查时的必要证据。

最后需要明确的是，追溯工程不是一次性建设，而是持续运行的能力。系统上线时要有追溯设计，数据产生时要有追溯标识，数据传输时要有追溯日志，数据存储时要有血缘关系，数据处理时要有版本记录，数据报告时要有反向链接。只有这六个环节都落实，整条链路才真正具备可追溯性。