3. 临床数据集成架构模式

临床数据集成不是“把数据搬进仓库”这么简单。医院里同时存在 HIS、LIS、PACS、EMR、护理系统、医保结算、可穿戴设备与区域平台，数据形态从结构化检验值到 DICOM 影像、从 HL7 v2 消息到 FHIR 资源、从批量对账文件到实时监护波形。集成架构模式的选择，直接决定了数据延迟、可追溯性、系统耦合度和后续建模成本。本节围绕五类主流模式展开，并给出批流取舍与湖仓协同的定位方法。

五类集成模式的本质差异

ETL（抽取—转换—加载）：在数据进入目标库之前完成清洗、编码映射和标准化。典型场景是 T+1 的运营报表、病种成本核算、DRG 分组分析。它的优势是目标层干净、口径统一；代价是转换逻辑与源系统强耦合，源结构变更时 ETL 作业容易断裂，且历史明细往往在转换中被聚合掉。

ELT（抽取—加载—转换）：先把原始数据近乎原样落到数据湖或仓库的原始层，再用 SQL/Spark 在目标侧转换。适合源系统多、口径频繁调整、需要保留原始证据链的场景，例如科研队列构建、多院区数据合并。它把“转换”从管道中解耦，但要求目标侧具备足够的存储与算力，并需要严格管理原始层的隐私与访问权限。

CDC（变更数据捕获）：通过解析数据库日志（如 MySQL binlog、Oracle redo log）或触发器，捕获 INSERT/UPDATE/DELETE 的增量变更。它解决的是“只搬变化量”的问题，适合患者主索引、床位状态、医嘱状态这类需要近实时同步且不能全量重刷的表。CDC 的关键难点是删除事件的表达、事务边界一致性和断点续传。

消息队列：以 Kafka、RabbitMQ 等作为缓冲与解耦层，生产者与消费者互不阻塞。适合检验危急值推送、监护设备数据汇聚、多下游同时订阅同一事件流的场景。它提供削峰填谷和回放能力，但需要处理消息顺序、重复消费与死信队列。

FHIR/HL7 接口引擎：面向临床语义的互操作层。HL7 v2 仍是院内 ADT、ORM、ORU 消息的主流；FHIR 则以资源（Patient、Observation、Encounter）和 RESTful API 支撑跨机构、移动端与科研交换。接口引擎负责消息解析、映射、路由与确认（ACK），是把“临床语义”翻译成“集成事件”的关键组件。

批处理与流处理的取舍

批处理与流处理不是二选一，而是按数据时效分层。判断依据可以落到三个问题上：下游多久需要看到这条数据？如果临床决策支持需要在 30 秒内响应危急值，就必须走流；如果只是次日出 DRG 预分组报表，批处理更稳。数据能否重跑？批处理天然支持按时间分区重算，适合口径调整后的回溯；流处理一旦消费位点提交，重放需要依赖消息保留策略或原始层留存。乱序与重复是否可接受？监护设备时间戳可能乱序到达，流处理需要水位线（watermark）和幂等写入；批处理则可在加载后统一排序去重。

实践中常见的混合架构是：CDC 或消息队列负责把变更实时写入数据湖原始层（Kafka + 对象存储），批处理作业按小时或按天从原始层加工到数据仓库主题域，实时服务层则直接消费消息流生成 CDR 视图。这样既保留了原始证据，又让仓库口径可重算。

数据湖与数据仓库的协同定位

数据湖与数据仓库不是替代关系，而是分工关系。数据湖保存原始证据与全量明细：HL7 原始消息、FHIR Bundle、DICOM 元数据、设备波形、CDC 变更日志。它的价值在于可追溯、可重放、可支持探索式分析。数据仓库保存经过治理的一致性口径：患者主索引、就诊事实、检验结果事实、医嘱事实、维度表。它的价值在于查询性能、口径统一和面向主题的分析。

协同的关键是“湖进仓出、仓湖互证”：湖作为唯一原始事实来源，仓作为唯一指标口径来源；当仓库指标异常时，可以回到湖中原始层复算验证。对于科研与 AI 特征工程，通常从湖中抽取明细，在特征库中生成队列与标签，再把稳定特征回流到仓库供报表复用。

一个可参考的模式选择清单

最后需要强调：集成架构的复杂度应当与临床价值匹配。不是所有数据都需要实时，也不是所有数据都需要入湖。对每类数据明确“时效—证据—口径”三个维度的要求，再组合 ETL、ELT、CDC、消息队列与接口引擎，才能既支撑临床实时决策，又保证科研与管理的可追溯、可复算。