2. 医疗数据源与数据接入工程

医疗数据湖仓的第一道工程关口不是建模，而是把散落在不同业务系统里的数据稳定、可追溯地接进来。医院信息系统的异构程度远超一般行业：HIS 以事务型关系库为主，EMR 大量使用半结构化文档，LIS 产生高频小批量结果，PACS 以 DICOM 影像对象存储为核心，医保结算多为批量对账文件，可穿戴设备则持续推送时序流。若接入层不区分这些差异，后续入湖数据会出现主键冲突、时间语义混乱、影像与报告脱节等问题。

六类数据源的特征与接入策略

HIS 通常承载挂号、收费、医嘱、住院等核心交易，数据以 MySQL、SQL Server 或 Oracle 为主，表结构规范、更新频繁，适合采用基于时间戳或增量日志的批量抽取，抽取频率可设为 5～15 分钟。EMR 的病程记录、入院记录、手术记录多为富文本或 XML，接入时需保留原始文档并抽取结构化字段，建议以文档 ID 与患者主索引关联。LIS 的检验结果表增长快、单条记录小，适合准实时接入，例如通过 CDC 捕获结果表变更，延迟控制在秒级。PACS 的影像文件体积大，不应直接塞入湖仓明细表，而应把 DICOM 元数据入湖、影像对象存入对象存储，通过 StudyInstanceUID 建立索引。医保结算数据一般按批次下发，字段固定、对账要求高，适合文件级批量接入并做金额与条数校验。可穿戴设备数据是典型时序流，采样频率高、设备型号杂，需要先做单位归一和时间对齐。

批量接入与实时接入的边界

批量接入适合对时效要求不高、但需要完整快照或对账的场景。以 HIS 收费明细为例，可每天凌晨 2:00 抽取前一日全量增量，抽取条件为 update_time >= 昨日00:00 AND update_time < 今日00:00，写入 ODS 时保留源表主键、抽取批次号和抽取时间。实时接入适合 LIS 危急值、可穿戴异常心率等需要秒级响应的场景。以 LIS 结果表 CDC 为例，变更事件进入消息队列后，接入程序按 patient_id + test_item + result_time 去重，再写入 DWD 明细表。两类通道并非互斥：同一数据源可以批量做历史回填、实时做增量追平，但必须约定统一的主键和更新时间语义，否则会出现重复或漏数。

接入层设计要点

接入层应至少包含原始层、标准化层、质量校验层和监控层。原始层贴源留存，不做字段裁剪，便于问题回溯；标准化层完成患者主索引匹配、性别/检验单位/时间格式统一；质量校验层检查空值率、主键重复率、时间越界和金额勾稽；监控层记录每批次条数、延迟、失败重试次数。一个可参考的批次校验记录如下：

批次号: HIS_20250612_0200
源表: his_charge_detail
抽取条数: 18432
入湖条数: 18432
主键重复: 0
空值率(patient_id): 0.00%
时间越界: 0
状态: 成功

若入湖条数与抽取条数不一致，或主键重复率超过 0.1%，应暂停后续任务并触发告警。PACS 接入还需额外校验 StudyInstanceUID 是否与 EMR 报告关联，避免出现“有影像无报告”的孤立检查。可穿戴设备接入则要重点处理设备时钟漂移，建议以服务端接收时间作为事件时间，并保留设备上报时间作为参考字段。

常见问题与判断依据

实际接入中最常见的问题有三类：一是增量字段选择错误，例如用 create_time 代替 update_time，导致修改过的记录无法被再次抽取；二是时间语义不统一，HIS 用本地时间、可穿戴设备用 UTC，入湖后必须统一转换为带时区的时间戳；三是医保对账文件与 HIS 收费数据条数不一致，需要按结算批次逐笔核对。判断接入是否成功的依据不是“任务跑完”，而是条数一致、主键唯一、关键字段空值率可控、下游可正常关联。只有这些条件同时满足，接入层才算真正交付。