2. 医疗数据源接入与实时采集

医疗湖仓的“批流一体”能力，首先取决于数据源接入层能否把不同协议、不同节奏、不同语义的医疗数据稳定地汇聚到统一通道中。医院信息系统（HIS）、电子病历（EMR）、检验信息系统（LIS）、影像归档与通信系统（PACS）以及 IoT 监护设备，是五类最典型的数据源。它们的数据模型、更新频率、接口方式和实时性要求差异极大，接入策略必须“一源一策”，而不是用同一条管道硬套。

五类数据源的接入特征

HIS 以业务事务为核心，挂号、收费、医嘱、住院、结算等表结构高度规范化，数据以关系型数据库（常见 Oracle、SQL Server、达梦等）为主。它的特点是写入频繁、事务性强、历史数据量大，适合用 CDC（Change Data Capture）捕获增量变更，再以批流一体的方式入湖。CDC 的价值在于不侵入业务库、不依赖应用改造，通过解析数据库日志（如 Oracle Redo Log、MySQL Binlog、SQL Server CDC 表）获得 INSERT/UPDATE/DELETE 事件。

EMR 以临床文档为核心，包含大量半结构化和非结构化内容，如病程记录、护理记录、手术记录、出院小结。EMR 的接入难点不在数据量，而在语义：同一份病历可能以 HL7 v2 消息、CDA 文档或 FHIR 资源三种形态存在。接入时应优先抽取结构化字段（患者标识、就诊号、科室、时间、诊断编码），对自由文本先做元数据登记和对象存储落盘，后续再按需做 NLP 或检索。

LIS 以检验申请、标本、结果、仪器通道为主线，数据节奏是“事件驱动 + 批量回传”。生化、免疫、微生物等不同仪器可能通过 ASTM、HL7 v2 ORU^R01 或厂商私有协议上传结果。接入策略通常是：仪器侧通过接口引擎转为 HL7 消息，经消息队列缓冲后写入湖仓；对历史结果则用批量抽取补齐。

PACS 以 DICOM 影像和检查元数据为主。影像文件体积大（单次 CT 可达数百 MB 至数 GB），不适合直接塞进消息队列。合理做法是“元数据入湖、影像入对象存储”：从 DICOM 头中抽取 PatientID、StudyInstanceUID、SeriesInstanceUID、SOPInstanceUID、Modality、StudyDate、BodyPart 等字段，形成检查-序列-影像三级索引，影像本体以对象存储路径引用。这样既保留可检索性，又避免湖仓被大文件拖垮。

IoT 监护设备 以高频时序信号为特征，如心电、血氧、血压、呼吸、体温，采样率从 1 Hz 到 250 Hz 不等。它要求低延迟、乱序容忍、断点续传。接入通常采用 MQTT 或私有网关，把设备数据转为统一消息格式后进入 Kafka/Pulsar 等消息队列，再按时间窗口写入时序表或湖仓的实时分区。

接入策略的关键设计点

第一，统一消息模型。无论来自 CDC、HL7 还是 MQTT，进入消息队列前都应转换为带统一信封的消息：包含 source_system、event_type、patient_id、visit_id、event_time、ingest_time、payload 等字段。这样下游湖仓只需面对一种消息结构，避免为每个源写一套解析逻辑。

第二，时间语义要分清。医疗数据至少有三个时间：业务发生时间（如医嘱下达时间）、消息产生时间、入湖时间。实时计算窗口应优先使用业务发生时间，并设置允许迟到阈值（例如 5 分钟），配合水位线处理乱序。否则监护数据一旦网络抖动，统计结果就会错位。

第三，幂等与去重。CDC 可能重复投递，HL7 可能重传，IoT 可能断点续传。接入层应为每条消息生成确定性主键（如 source_system + 业务主键 + 版本号），湖仓写入时按主键做 MERGE 或去重，保证同一事件只生效一次。

第四，PACS 的“轻元数据、重引用”。DICOM 元数据抽取后写入湖仓，影像文件写入对象存储，并在湖仓中保存对象路径和校验值。查询时先通过元数据定位 StudyInstanceUID，再按需拉取影像，避免全量影像扫描。

一个可参考的接入参数示例

以下参数属于教学示例，用于说明接入层常见配置项，并非某家医院实测值：

最后，接入策略必须考虑异常与回退。当 CDC 位点丢失时，应能从最近快照加增量重放；当消息队列积压时，应能降级为批量补采；当 PACS 元数据抽取失败时，应记录失败清单并支持按 StudyInstanceUID 重试。只有把正常链路和异常链路都设计清楚，医疗湖仓的实时采集才具备工程可用性。