1. 临床试验eSource数据采集工程导论

在临床试验中，源数据（Source Data）是重建和评价试验全过程的第一手依据。传统模式下，源数据记录在纸质病历、检验单、心电图纸或影像报告上，研究者再把这些信息转录到EDC（Electronic Data Capture，电子数据采集）系统中。eSource（electronic Source）要改变的正是这一层：让源数据在产生或采集的当下就以电子形式被记录、留存并具备可追溯性，而不是先落到纸上再二次录入。

从工程视角看，eSource不是“把纸质CRF换成网页表单”，而是一条从数据产生点到监管递交的电子证据链。它至少包含四个要素：数据产生端（如电子病历EMR、实验室信息系统LIS、可穿戴设备、电子患者报告结局ePRO）、采集与录入端（移动端、平板、床旁终端）、源数据存储与审计层（数据库、审计追踪、电子签名）、以及向EDC或递交系统的传输接口。理解这条链路，是后续所有工程决策的基础。

eSource与传统EDC的核心区别

传统EDC的本质是“转录后的数据采集系统”，它的数据入口是研究者阅读源文件后的手工录入，源数据仍在纸质或医院信息系统中。eSource的本质是“源数据的电子化承载”，数据入口前移到临床工作现场，录入即源数据，或由设备/系统直接生成源数据。这一差异带来三个直接后果：

• 数据血缘不同：EDC中一条“收缩压120 mmHg”通常没有原始波形或设备记录；eSource中该值应能关联到设备、时间戳、操作者和原始记录。
• 稽查路径不同：传统稽查需要比对纸质源文件与EDC；eSource稽查直接查看电子源记录及其审计追踪。
• 质量风险点不同：传统模式主要风险是转录错误；eSource主要风险转为系统权限、时间同步、接口映射、审计追踪完整性和数据留存可读性。

需要强调的是，eSource并不排斥EDC。多数项目中，eSource负责“源”，EDC负责“病例报告表（CRF）数据”的汇总与疑问管理，两者通过接口或中间层衔接。工程上必须明确：哪些字段以eSource为源，哪些字段仍以EDC为源，避免同一数据出现两个“真相版本”。

法规背景：21 CFR Part 11与ICH GCP E6(R2)

FDA 21 CFR Part 11解决的是“电子记录和电子签名何时可信”的问题。其核心要求可归纳为：系统验证、审计追踪、权限控制、电子签名与记录绑定、记录留存与可复制。对eSource而言，最容易被检查的是审计追踪：谁、何时、从什么值改到什么值、为什么改。审计追踪必须由系统自动生成，不能由用户关闭或编辑。

ICH GCP E6(R2)则从试验质量角度提出要求：源数据应可归因（Attributable）、可读（Legible）、同步记录（Contemporaneous）、原始（Original）、准确（Accurate）、完整（Complete）、一致（Consistent）、持久（Enduring）、可获取（Available），即ALCOA+原则。eSource系统若不能证明“同步记录”和“持久可获取”，即使功能再丰富，也不满足GCP对源数据的基本要求。

工程化视角下的核心挑战

把eSource从概念做成可运行系统，难点不在页面开发，而在以下五个工程面：

1. 数据模型与映射：EMR中的“体温”可能是字符串、可能是华氏度、可能带单位后缀。eSource必须定义规范字段、单位、精度和缺失值编码，并建立与EDC字段的映射表。例如体温统一为摄氏度、保留一位小数，缺失记为“NOT DONE”而非空字符串。
2. 时间与同步：多设备、多院区、多时区下，时间戳必须统一到UTC或明确记录时区偏移。否则“同步记录”无法证明。
3. 身份与签名：操作者身份必须唯一绑定，电子签名需与具体记录和含义（如“审核”“批准”）绑定，不能只做一个登录密码。
4. 接口与容错：设备断网、LIS接口超时、重复推送是常态。工程上需要幂等键、重试队列和冲突标记，而不是假设接口永远成功。
5. 验证与变更控制：eSource属于GxP系统，任何字段、逻辑、接口变更都要走变更评估和回归验证，不能像普通互联网产品一样热更新。

整体架构：从数据产生到监管可用

下面这张图给出eSource数据采集工程的典型分层架构。它强调的不是“有哪些模块”，而是数据从产生端到监管可用端的流向、审计追踪的贯穿位置，以及eSource与EDC的分工边界。

图中最需要关注的是橙色审计带和紫色传输层。审计追踪不是某个模块的功能，而是贯穿产生、采集、存储、传输的约束；传输层则决定eSource数据能否稳定、可解释地进入EDC和递交链路。工程实践中，很多项目失败并非因为前端不好用，而是因为映射规则未定义、重试机制缺失或审计追踪被绕过。

一个最小可用的工程示例

假设某试验需要在床旁采集受试者体温并作为源数据。合理的eSource实现不是让研究者手填一个数字，而是：设备通过蓝牙将体温读数传入平板应用，应用自动记录设备序列号、测量时间（含时区）、单位（℃）、数值（保留一位小数），研究者确认后签名。若设备未连接，应用允许手工录入，但必须标记“手工录入”并记录原因。该记录写入源数据库时，同时生成审计追踪条目。传输到EDC时，以“受试者编号+访视+测量时间+设备序列号”作为幂等键，避免重复推送。

示例记录（JSON片段，仅用于说明字段结构）：
{
  "subject_id": "S-001-007",
  "visit": "V2",
  "measure_time": "2025-03-11T09:24:00+08:00",
  "device_sn": "TH-8842",
  "value": 36.8,
  "unit": "C",
  "entry_mode": "DEVICE",
  "operator": "nurse_li",
  "audit": {
    "created_by": "nurse_li",
    "created_at": "2025-03-11T09:24:03+08:00",
    "reason": null
  }
}

这个例子说明：eSource的工程价值不在于“电子化”本身，而在于把来源、时间、单位、操作者、修改原因这些监管关心的属性，在数据产生的那一刻就结构化地固定下来。后续无论做稽查、锁库还是递交，都能沿着这条记录回溯。