📚 课程目录第3章源数据采集与EDC系统对接

3. 源数据采集与EDC系统对接

源数据采集是临床研究数据流水线的起点，也是决定后续清洗、分析和递交质量的关键环节。在纸质CRF时代，数据从受试者访视到最终数据库要经过多次人工转录，错误率高、溯源困难。电子数据采集（Electronic Data Capture，EDC）系统的普及改变了这一局面：研究者直接在系统中录入数据，系统在录入时即执行逻辑校验，数据从产生到入库的链路被大幅缩短。但EDC并非孤立存在，它需要与中心实验室、ePRO、影像判读、随机化系统等多个数据源对接，才能形成完整的源数据集合。

EDC系统接口的基本构成

从工程视角看，EDC系统对外提供的能力通常分为三类：数据录入接口、数据提取接口和元数据接口。数据录入接口面向研究者，提供CRF表单的渲染、保存、校验和签名功能；数据提取接口面向数据管理员和统计程序员，用于按需导出结构化数据；元数据接口则描述表单结构、字段类型、编码列表和访视计划，是自动化映射的基础。

在实际项目中，EDC系统往往还提供Web Service或RESTful API，用于与外部系统实时交互。例如，当受试者在中心实验室完成血样采集后，实验室信息系统（LIS）可通过API将检验结果直接推送到EDC的对应访视表单中，避免人工转录。这种对接方式要求双方预先约定数据格式、字段映射和错误处理策略。

CDASH标准及其作用

CDASH（Clinical Data Acquisition Standards Harmonization）是CDISC发布的数据采集标准，它定义了CRF上应该采集哪些字段、字段的名称和格式。CDASH的核心价值在于统一“采集端”的数据结构，使不同研究、不同EDC系统之间的数据具有可比性，也为后续映射到SDTM（Study Data Tabulation Model）奠定基础。

以不良事件（AE）表单为例，CDASH建议采集的字段包括：AE术语、开始日期、结束日期、严重程度、严重性判断、与试验药物的关系、采取的措施、转归等。每个字段都有推荐的变量名（如AETERM、AESTDTC、AESEV、AESER、AEREL、AEACN、AEOUT）和受控术语。如果EDC建库时直接采用CDASH变量名和编码列表，后续生成SDTM的AE域时，映射工作量会显著降低。

需要注意的是，CDASH是“推荐标准”而非强制标准。实际项目中，申办方可能根据疾病领域或监管要求增加字段，但应尽量保持与CDASH的兼容性，避免自定义字段与标准字段语义冲突。

数据提取方式：API与文件导出

数据提取是数据流水线中频率最高的操作之一。常见方式有两种：文件导出和API调用。

文件导出是最传统的方式。数据管理员在EDC系统中选择访视范围、表单和受试者，导出为CSV、Excel或SAS数据集。导出文件通常包含数据、标签和编码列表三部分。这种方式实现简单，适合一次性提取或批量归档，但存在明显缺点：导出动作是手动的，难以与流水线自动化集成；每次导出可能产生不同的文件命名和列顺序，需要额外的解析逻辑。

API调用则更适合自动化流水线。以RESTful API为例，数据工程师可以编写脚本，按研究、站点、访视等参数请求数据，API返回JSON或XML格式的结构化数据。API通常支持增量提取，即只返回上次提取后发生变化的数据，这对大型研究尤为重要。以下是一个简化的API请求示例：

GET /api/v1/studies/STUDY001/subjects?site=SITE01&visit=V1
Authorization: Bearer <token>
Accept: application/json

响应示例：
{
  "subjectId": "SITE01-001",
  "visit": "V1",
  "forms": [
    {
      "formOid": "AE",
      "items": [
        {"itemOid": "AETERM", "value": "Headache"},
        {"itemOid": "AESEV", "value": "MILD"},
        {"itemOid": "AESTDTC", "value": "2024-03-15"}
      ]
    }
  ]
}

API方式的关键在于认证与限流。多数EDC系统采用OAuth 2.0或API Key认证，数据工程师需要妥善管理凭证，避免硬编码在脚本中。同时，API通常有调用频率限制，批量提取时应设计重试和退避策略。

常见数据质量问题

无论采用哪种提取方式，源数据中都可能存在质量问题。以下是在EDC对接阶段最常遇到的几类问题：

缺失值：必填字段为空，或访视未完成导致整页数据缺失。需区分“未采集”和“未发生”，前者应触发质疑，后者应记录为“NOT DONE”。
日期逻辑错误：AE结束日期早于开始日期，或访视日期晚于数据录入日期。这类问题应在EDC录入时通过动态校验拦截，但导出后仍需二次检查。
编码不一致：同一术语在不同站点录入为不同拼写，如“Hypertension”与“hypertension”。需在提取后统一大小写和空格，再映射到MedDRA或WHO Drug。
重复记录：同一受试者同一访视的表单被重复提交，或API增量提取时因时间戳精度问题导致重复拉取。需在流水线中设计去重键，如“受试者ID+访视+表单OID+记录序号”。
单位缺失或错误：实验室检查结果只录入了数值，未录入单位，或单位与参考范围不匹配。需在提取后与LIS源数据核对。

在EDC对接阶段，建议将“数据提取日志”作为流水线的标准输出之一，记录每次提取的时间、范围、记录数和校验失败数。当后续分析发现异常时，可快速定位是源数据问题还是转换问题。

对接流程中的关键控制点

一个稳健的EDC对接流程通常包含以下控制点：首先，在建库阶段确认CDASH字段映射表，明确每个CRF字段对应的CDASH变量名和编码列表；其次，在提取阶段使用API增量提取，并记录提取水位线（watermark），避免重复或遗漏；再次，在入库前执行结构校验，检查字段类型、长度和必填性；最后，在入库后执行逻辑校验，检查日期顺序、编码有效性和跨表单一致性。

以下SVG展示了从EDC系统到数据仓库的源数据采集与对接链路，包括API提取、文件导出两条路径，以及CDASH映射和常见质量问题的拦截位置。

在实际工程中，API提取和文件导出往往并存：日常增量同步用API，定期全量归档用文件导出。两条路径的输出都应经过同一套质量拦截规则，确保进入数据仓库的数据具有一致的结构和可接受的质量水平。提取日志则作为审计追踪的一部分，记录每次数据流动的完整轨迹。

最后需要强调的是，EDC对接不是一次性的技术任务，而是贯穿研究始终的持续过程。研究方案变更、CRF版本升级、编码列表更新都会影响对接逻辑。因此，在流水线设计中应保留版本标识和变更记录，使每一次数据提取都能追溯到对应的EDC版本和CDASH映射版本，为后续的监管核查和数据分析提供可靠依据。