4. 医疗数据交换平台总体架构
医疗数据交换平台的总体架构，本质上是在“多机构、多系统、多标准、强合规”的约束下，把数据从产生方安全、可控、可追溯地送到消费方。它既不是单一网关，也不是一个集中式数据库，而是一组按职责分层、通过标准接口协作的逻辑组件，并最终落到具体的部署拓扑上。理解总体架构，关键是同时看清三条线：分层职责线（谁负责什么）、数据流转线（一次交换经过哪些环节）、质量约束线（性能、可用性、安全、可审计如何被满足）。
一、分层设计：从接入到治理的四层职责
推荐将平台划分为接入层、交换层、服务层、治理层四层，每层只解决一类问题，避免职责交叉导致的耦合。
- 接入层：面向医院 HIS、LIS、PACS、公卫系统、区域平台等数据源，提供 HL7 v2、FHIR、DICOM、数据库 CDC、文件/消息队列等适配器。核心职责是协议转换、连接管理、限流与身份初验，把异构输入统一成内部规范消息。
- 交换层：承担路由、转换、编排与可靠投递。它根据患者标识、机构编码、消息类型决定目标端点，完成术语映射（如 ICD-10、LOINC、SNOMED CT 之间的对照），并通过持久化队列保证“至少一次”投递与失败重试。
- 服务层：对外暴露患者主索引（EMPI）、文档共享（XDS/文档注册）、订阅通知、查询检索等能力，是业务系统真正调用的接口面。
- 治理层：负责主数据与术语管理、审计日志、监控告警、权限策略、数据质量规则与脱敏策略，是平台可运营、可合规的基础。
分层的价值在于：接入协议变化只影响接入层，术语标准升级主要影响交换层与治理层，业务接口调整集中在服务层。这样，平台才能在长期演进中保持稳定。
二、逻辑组件与一次交换的完整路径
把分层落到组件，平台通常包含以下关键逻辑组件：协议适配器、消息规范化器、路由引擎、转换与术语映射器、持久化消息队列、患者主索引（EMPI）、文档注册库、审计与追踪服务、策略与配置中心。它们之间通过内部消息总线或 API 协作，而不是彼此直连数据库。
以“某医院向区域平台上传一份出院小结”为例，一次交换的路径是：HIS 通过 HL7 v2 ORU^R01 或 FHIR DocumentReference 提交 → 接入层完成身份校验与格式解析 → 规范化器生成内部统一消息（含机构编码、患者标识、文档类型、时间戳）→ 路由引擎根据“文档类型=出院小结、目标=区域文档库”选择端点 → 术语映射器把本地科室、诊断编码映射到区域标准 → 消息写入持久化队列，获得唯一消息 ID → 服务层调用文档注册接口，写入注册库并返回文档唯一标识 → 审计服务记录发送方、接收方、消息 ID、时间、结果。若目标端暂时不可用，队列保留消息并按退避策略重试；超过重试上限则进入死信队列并告警。
三、部署拓扑：从单中心到多节点
部署拓扑决定平台的可用性与扩展性。常见有三种形态：
- 集中式单中心：所有组件部署在同一机房，接入层与交换层可横向扩展，数据库主备。适合区域平台初期、接入机构较少的场景，运维简单，但存在单点风险。
- 双活/多活：在两个可用区各部署一套交换与服务节点，共享或同步 EMPI 与注册库，通过负载均衡和消息队列镜像实现故障切换。适合对可用性要求高的省级平台。
- 边缘接入 + 中心交换：在大型医院侧部署轻量接入节点，完成协议转换与本地缓存，中心只负责路由、主索引与治理。这样可减少跨网传输压力，也便于医院侧断网时暂存数据。
无论哪种拓扑，网络分区都应遵循“接入区—交换区—数据区—管理区”的划分：接入区面向外部机构，只开放必要端口；交换区部署路由与队列；数据区部署 EMPI、注册库与审计库；管理区部署监控、配置与运维工具。跨区访问必须经过策略校验。
四、关键质量属性与可验证指标
总体架构最终要回答“好不好用、稳不稳、安不安全”。建议把质量属性写成可验证指标，而不是口号：
| 质量属性 | 示例指标 | 观察方式 |
|---|---|---|
| 性能 | 单节点消息处理 ≥ 500 条/秒，P95 端到端时延 ≤ 2 秒 | 压测与生产监控面板 |
| 可靠性 | 消息投递成功率 ≥ 99.9%，死信率 ≤ 0.1% | 队列积压、死信队列统计 |
| 可用性 | 核心交换服务年可用性 ≥ 99.95% | 健康检查与故障切换演练 |
| 安全合规 | 所有访问经鉴权，敏感字段按策略脱敏，审计留存 ≥ 6 个月 | 审计日志抽查与权限复核 |
| 可追溯 | 每条消息可通过消息 ID 还原发送方、接收方、时间与结果 | 追踪查询接口 |
这些指标不是一次性设定，而应随接入机构数量、消息量增长而调整。架构设计时就要预留横向扩展点：接入层无状态可复制，交换层队列可分区，服务层接口可缓存，治理层规则可配置化。这样，平台才能在业务扩张时保持稳定，而不是每次扩容都重构。