3. eSource数据源类型与采集场景分析
eSource并不是单一系统，而是围绕受试者、研究者、实验室、影像中心和设备厂商形成的多源数据采集网络。不同数据源在“数据产生位置、采集触发方式、标准化程度、可追溯性”上差异很大，直接决定了电子源数据（eSource）的工程实现路径。本节按五类典型数据源展开：直接数据捕获（ePRO、eCOA、传感器）、从EHR/EMR提取、实验室数据集成、影像数据采集、可穿戴设备数据流，并给出可落地的采集场景判断与实现要点。
一、直接数据捕获：ePRO、eCOA与传感器
直接数据捕获指数据由受试者、评估者或设备在临床现场直接录入电子系统，不经过纸质转录。ePRO（电子患者报告结局）由受试者本人填写，典型场景是每日症状日记、疼痛评分、服药依从性；eCOA（电子临床结局评估）覆盖更广，包括研究者填写的量表（如CGI-I）、受试者自评量表（如EQ-5D）以及认知测试。传感器则指集成在eCOA设备或独立设备中的生理信号采集，例如电子血压计、肺功能仪、心电贴。
工程实现上，ePRO/eCOA通常采用“设备端离线填写 + 网络恢复后同步”的模式。以某多中心III期哮喘试验为例，受试者每晚通过手持终端填写哮喘日记，包含夜间憋醒次数（0–4）、急救药使用次数、PEF值。终端本地使用SQLite暂存，每条记录带device_id、subject_id、form_oid、collected_at（ISO 8601带时区）、sync_status。同步时通过HTTPS POST到eSource网关，网关校验JWT令牌与受试者状态后写入ODM XML。关键判断依据是：若collected_at与服务器接收时间差超过方案规定的窗口（如日记允许±2小时），系统标记为“超窗”，需数据管理员核查，而不是直接丢弃。
二、从EHR/EMR提取：以事件为锚的增量抽取
EHR/EMR提取的核心难点不是“能不能取”，而是“取什么、何时取、如何证明取全了”。医院EHR通常以就诊、住院、检验、医嘱等事件为中心。eSource集成应优先采用HL7 FHIR资源模型，把受试者映射为Patient，就诊映射为Encounter，检验结果映射为Observation，用药映射为MedicationRequest。
实际工程中推荐“增量抽取 + 事件锚点”策略。以某肿瘤试验为例，筛选期从EHR抽取受试者人口学、诊断、既往治疗；治疗期每次访视前24小时触发一次增量查询，锚点为Encounter.period.start，查询该次就诊产生的生命体征、实验室、合并用药。抽取结果先落入暂存表，再由映射引擎转换为CDASH/SDTM变量。必须保留source_system、source_record_id、extracted_at三个字段，用于稽查轨迹。若EHR中某字段为空，不能默认“未发生”，而应区分“未记录”与“阴性”，否则会引入信息偏倚。
三、实验室数据集成：从PDF到结构化
实验室数据集成通常有三种接口形态：中心实验室提供的HL7 v2 ORU^R01消息、CSV/Excel批量文件、以及PDF报告。ORU消息可直接解析为OBX段，每个检验项对应一个OBX-3编码、OBX-5结果值、OBX-6单位、OBX-7参考范围、OBX-8异常标志。CSV文件则需要约定列名与单位，例如subject_id, visit, test_code, result, unit, ref_low, ref_high, abnormal_flag。
PDF报告是最容易出问题的形态。工程上应优先要求实验室提供结构化接口；若只能提供PDF，则需建立“模板识别 + 人工复核”流程。以某中心实验室的生化报告为例，模板固定包含“分析物、结果、单位、参考区间、异常标记”五列。解析后必须做三项校验：单位是否与方案一致（如ALT应为U/L）、结果是否在生理可能范围内（如钾2.0–7.0 mmol/L）、异常标记是否与参考区间逻辑一致。任何一项不通过，进入人工复核队列，而不是自动写入eSource。
四、影像数据采集：DICOM与评估分离
影像数据采集与常规eSource字段不同，它包含两层：影像文件本身（DICOM）和影像评估结果（如RECIST 1.1靶病灶测量）。DICOM文件通常通过PACS或独立影像网关传输，采用C-STORE或DICOMweb协议。eSource系统需要记录StudyInstanceUID、SeriesInstanceUID、SOPInstanceUID，并与受试者、访视建立关联。评估结果则由放射科医师在阅片系统中填写，再以结构化表单回传。
关键工程点是“影像到达确认”与“评估锁定”。例如某肺癌试验要求基线、第6周、第12周各做一次胸部CT。影像网关收到DICOM后，向eSource发送一条到达通知，包含StudyInstanceUID和subject_id。eSource检查该受试者该访视是否已有影像记录，若无则创建，若有则标记“重复上传”并触发核查。评估结果回传后，系统应锁定该次评估，任何修改都需走稽查轨迹，不能静默覆盖。
五、可穿戴设备数据流：高频、连续、需降采样
可穿戴设备（如Actigraph、心电贴、连续血糖监测）产生的是高频时间序列数据，采样率可能达到25–100 Hz。eSource不能直接存储原始高频流，而应分层处理：设备端或手机端先做本地缓存与压缩，按方案规定的聚合窗口（如每5分钟、每小时、每日）计算汇总指标，再上传至eSource。原始数据可保留在设备厂商云平台，eSource仅保存汇总值与必要的质量标记。
以某帕金森病试验的腕部加速度计为例，设备采样率50 Hz，三轴加速度。上传前计算每日“活动计数”“睡眠时长”“步数”。eSource接收字段包括subject_id、device_id、date、wear_time_hours、activity_count、sleep_hours、data_quality_flag。若wear_time_hours小于方案规定的10小时，该日数据标记为“不充分”，在统计分析时按缺失处理，而不是强行纳入。
六、采集场景判断与工程要点
面对一个具体试验，选择哪种采集方式，应优先看三个维度：数据产生者是谁、数据是否已有结构化系统、数据频率与体量。若数据由受试者主观报告，优先ePRO；若数据已在医院EHR中，优先FHIR增量抽取；若来自中心实验室，优先ORU消息；若为影像，必须走DICOM通道并单独管理评估结果；若为可穿戴设备，必须做聚合降采样与质量标记。
无论哪类数据源，eSource工程都应坚持四条底线：第一，每条数据必须能追溯到来源系统与原始记录标识；第二，时间戳必须带时区且与方案窗口可比；第三，单位与编码必须与方案一致，不一致时进入核查而非自动转换；第四，任何修改必须留痕，不能静默覆盖。只有把“来源可溯、时间可比、单位可验、修改可查”落实到每个数据源，eSource才能真正支撑后续的SDTM转换与统计分析。