3. 医疗数据模型与交换格式

医疗数据交换平台最核心的工程问题之一，是“用什么模型承载数据、用什么格式传输数据、在什么场景下选择哪套标准”。HL7 V2、HL7 CDA、FHIR、DICOM 与 IHE 框架并非互相替代关系，而是分别覆盖消息传输、文档归档、资源化 API、影像对象与集成规范等不同层面。理解它们的适用边界，比记住缩写更重要。

五类标准的定位差异

HL7 V2 是医院内部最广泛使用的消息标准，典型消息如 ADT（入院、出院、转科）、ORM（医嘱）、ORU（检验结果）。它采用段（Segment）、字段（Field）、组件（Component）的竖线分隔结构，例如：

MSH|^~\&|HIS|HOSP_A|LIS|LAB_B|202405121030||ORU^R01|MSG00001|P|2.5
PID|1||P123456^^^HOSP_A^MR||张三||19800101|M
OBR|1|ORD001|LAB001|CBC^血常规|||202405121000
OBX|1|NM|WBC^白细胞||6.8|10^9/L|4.0-10.0|N|||F

V2 的优势是轻量、实时、事件驱动，适合院内系统间点对点或经集成引擎的异步消息交换；局限是版本碎片化、字段语义依赖实现指南、缺乏统一资源模型，跨机构语义一致性弱。

HL7 CDA 是临床文档架构标准，强调“文档”的完整性与法律效力，常用于出院小结、会诊记录、健康档案。CDA 文档由 Header 与 Body 组成，Body 可嵌套 Section 与 Entry，并可通过模板（Template ID）约束为 CCD、QRDA 等具体文档类型。CDA 适合归档、交换、留痕，但不适合高频查询与细粒度资源操作。

FHIR 则把医疗数据抽象为 Resource，如 Patient、Observation、Encounter、MedicationRequest，通过 RESTful API 以 JSON 或 XML 交换，支持查询、创建、更新、批量操作与订阅。FHIR 更适合移动医疗、互联网医院、跨机构数据服务与开放 API 场景，但成熟度依赖 Profile、Implementation Guide 与术语绑定。

DICOM 面向医学影像，定义影像对象、服务类与网络协议，如 C-STORE、C-FIND、C-MOVE、WADO-RS。它解决的是影像采集、存储、查询、调阅与打印，不适合承载普通文本病历。

IHE 框架不是单一格式，而是“集成规范”，通过 XDS、PIX、PDQ、XCA 等 Profile 把 HL7、CDA、DICOM、FHIR 等标准组合成可落地的互操作方案，明确角色、事务与内容格式。

适用边界的工程判断

在平台设计中，常见误区是“用 FHIR 替代一切”或“用 CDA 做实时查询”。更合理的判断是：如果业务是院内系统间高频、事件驱动的状态变更，优先 V2；如果是需要法律留痕、完整语义的文档交换，优先 CDA；如果是面向互联网、移动端或跨机构按资源查询，优先 FHIR；如果是影像及其相关对象，必须走 DICOM；如果涉及跨机构文档共享、患者主索引、影像工作流，则用 IHE Profile 把上述标准组织成端到端事务。

例如，某区域平台需要实现“基层医院上传出院小结，上级医院调阅，并关联患者主索引”。此时内容格式可选 CDA，患者身份交叉索引用 PIX，文档注册与检索用 XDS，跨区域扩展用 XCA。若同时要提供移动端查询检验结果，则可在同一平台中并行暴露 FHIR Observation API，而不是强行把 CDA 文档拆成 FHIR 资源。

平台中的协同方式

实际平台通常不是单选，而是组合。集成引擎可同时接入 V2 消息与 FHIR API，将 V2 ORU 映射为 FHIR Observation 供移动端查询；CDA 文档进入 XDS 仓库后，其元数据可被 FHIR DocumentReference 引用；DICOM 影像通过 WADO-RS 提供 Web 调阅，检查报告则以 CDA 或 FHIR DiagnosticReport 呈现。关键在于明确“主数据模型”和“交换格式”的边界：内部可以统一为 FHIR 资源模型，但对外仍按场景输出 V2、CDA 或 DICOM。

因此，医疗数据交换平台的标准选型应遵循“场景定标准、标准定事务、事务定接口”的顺序，而不是先选技术再找场景。只有把五类标准的适用边界讲清楚，后续的接口设计、映射规则与集成测试才有稳定依据。