最佳数据互操作性标准与 FHIR：首选比较（2026 年）

数据互操作性标准与 FHIR 是架构师应该审慎对待的比较，因为 FHIR 是特定于医疗保健的规范，而不是通用的企业数据模型。 FHIR 定义了 150 多种用于临床交换的“资源”（患者、观察、遭遇、药物请求等），但它没有对制造、金融、零售或供应链实体进行建模，因此将其视为通用互操作性层是一个常见的架构错误。

要点

• FHIR 是医疗保健互操作性标准，而不是企业数据模型。 它擅长通过 RESTful API 和资源进行临床数据交换，但它不会对制造、金融、零售或供应链实体进行建模。
• “标准与 FHIR”通常是错误的框架。 大多数企业需要一种“分层”方法：底层是与领域无关的规范模型，加上边缘的领域标准（FHIR、ISO 20022、X12）。
• FHIR 的优势是真实的： 精细资源、REST + JSON/XML、已发布的一致性层（CapabilityStatement、配置文件、实施指南）以及大型供应商生态系统。
• FHIR 的限制也是真实的： 版本流失（DSTU2 → STU3 → R4 → R5）、配置文件激增、对分析/OLAP 的原生支持较弱以及不覆盖非临床领域。
• 云信息模型 (CIM) 采用不同的方法： 一种开放的、与应用程序无关的、基于 JSON-LD 的模型，旨在位于*系统之间，而不是取代域标准。
• 根据工作负载而不是时尚进行选择。 事务交换、分析和主数据管理各自偏向不同的标准。

为什么“标准与 FHIR”是错误的问题

FHIR（快速医疗保健互操作性资源）由 HL7 International 管理，专为医疗保健信息交换而设计。定义了 150 多个“资源”（患者、观察、遭遇、药物请求等），每个资源都具有 RESTful 交互模式和 JSON/XML 表示形式。

这是一个域标准。它回答：“如何在医院 EHR 和付款人之间转移实验室结果？”它没有回答：“我的 CRM、ERP 和数据仓库中的客户、订单或产品是什么？”

当架构师将决策定义为“FHIR 或其他内容”时，他们通常会合并三个不同的层：

1. 传输/语法 — 字节如何移动（REST、SOAP、消息队列、文件传输）。
2. 领域语义 — 数据在特定行业中的含义（FHIR、ISO 20022、X12、GS1）。
3. 规范/企业模型 — 让各个领域相互交流的共享词汇表（CIM、自定义规范模型、行业本体）。

FHIR 位于第 2 层。大多数企业互操作性故障发生在第 3 层，而 FHIR 的设计目的从来就不是为了解决这一问题。

比较表：主要互操作性标准

标准	主域	数据模型风格	传输	最适合	关键限制
FHIR (R4/R5)	医疗保健临床与管理	资源导向，RESTful	REST/HTTP、JSON、XML	实时临床 API、患者访问、FHIR 应用程序上的 SMART	不覆盖非临床领域；版本流失；配置文件激增
HL7 v2	医疗保健消息	段/字段（管道分隔）	MLLP，文件	传统实验室/ADT 数据馈送在医院中仍占主导地位预协调、脆弱、语义差
HL7 CDA	临床文件	XML 文档	文件，XDS	以文档为中心的交换（出院总结）	冗长，难以查询
开放电子病历	临床电子病历	原型/模板（两级建模）	REST，特定于供应商	临床丰富、长期的记录	陡峭的学习曲线；较小的供应商基础
OMOP CDM	医疗保健分析	关系型、观察型	数据库	人口健康、研究、OHDSI 网络	不用于交易交换
X12 (EDI)	美国医疗保健管理、供应链	交易集（837、835、850）	批处理文件，AS2	索赔、资格、采购订单	刚性、批量导向、以美国为中心
ISO 20022	金融服务	消息定义 (XML)	MX/MT 消息传递	支付、证券、贸易	复杂的;全球迁移正在进行
GS1 / EPCIS	零售、供应链	标识符+事件标准	各种	产品可追溯性、条形码	范围狭窄（身份+事件）
schema.org	网络/搜索引擎优化	词汇表 (JSON-LD)	HTTP	公共网络标记、发现	不是企业合同
云信息模型 (CIM)	跨行业企业	JSON-LD本体	模型工件	跨云/本地应用程序的规范层	生态系统更加年轻化；采用率仍在增长

模式很明确：**FHIR 是拥挤领域中的一个强有力的选择，并且它是受领域限制的。**如果您的问题是临床数据，FHIR 通常是正确的答案。如果您的问题是整个企业范围的，FHIR 充其量只是一个数据源，而最坏的情况则是一种干扰。

Related: Fivetran — The fully managed ELT pipeline that just keeps running.

FHIR 真正获胜的地方

值得具体说明 FHIR 的优势，因为全面放弃它就像过度采用它一样懒惰。

• 熟悉 REST + JSON。 了解 HTTP 和 JSON 的集成工程师可以快速提高工作效率，这与 HL7 v2 的管道分隔段或 CDA 的深层 XML 不同。
• 粒度资源。 您可以请求单个“观察”，而不是解析整个文档，这适合微服务和移动应用程序。
• 一致性机制。 CapabilityStatement、StructureDefinition 和已发布的实施指南（例如 US Core、IPS）为您提供机器可读的合同——这在旧标准中很少见。
• 监管顺风。 在美国，ONC 治愈法案最终规则和 CMS 互操作性规则推动基于 FHIR 的 API（特别是患者访问 API）。监管的严格性是在医疗保健领域采用 FHIR 的真正原因。
• 生态系统。 FHIR 应用程序启动上的 SMART、主要 EHR 供应商支持和开源服务器（HAPI FHIR、Microsoft FHIR 服务器）可降低构建成本。

如果您正在构建面向患者的应用程序、支付者-提供者交换或临床决策支持工具，FHIR 通常是正确的默认选择。

FHIR 对企业架构师的影响

当 FHIR 离开其主域时，问题就会浮现出来。

Our pick: Workato — Automation-led iPaaS that business teams can actually build on.

1.不覆盖非临床实体。 没有“发票行项目”、“仓库箱”或“订阅层”的 FHIR 资源。试图将临床资源强行融入商业概念的团队产生的模型既不标准又无用。

2.版本流失是真正的成本。 DSTU2、STU3、R4 和 R5 在资源形状和术语绑定方面有所不同。多供应商环境经常同时运行两个或三个版本，需要转换层。对此的预算。

3.配置文件激增。 由于 FHIR 是可扩展的，因此每个实施指南、区域和供应商都会添加配置文件。两个系统都可以声称“FHIR R4 合规性”，但在没有共享配置文件的情况下仍然无法互操作。这在 FHIR 中相当于“每个人都有自己的方言”问题。

4.分析是事后的想法。 FHIR 针对交易交换进行优化，而不是柱状分析。对于人口健康和研究，OMOP CDM 或扁平仓库模型通常是更好的目标。 FHIR 到 OMOP 的转换是一项众所周知的、重要的工作。

5.它不是主数据模型。 FHIR 不会告诉您如何跨系统解析单个“黄金”患者或提供者身份。这就是 MDM，它高于任何交换标准。

规范层：CIM 和类似模型适合的地方

这是大多数“FHIR 与 X”比较都会跳过的层，也是云信息模型 (CIM) 所在的位置。

Related: Matillion — Push-down ELT built for cloud data warehouses.

CIM 是一种以 JSON-LD 表示的开源应用程序与应用程序无关的数据模型，旨在提供跨云和本地系统的共享词汇表。其设计意图与FHIR不同：

• 与领域无关。 它模拟常见的企业概念（各方、帐户、产品、订单、交互）而不是临床资源。
• 基于本体。 JSON-LD 和链接数据原则让您可以扩展和映射而不是分叉。
• 供应商中立。 它不属于单个 EHR 或云供应商，这在您集成 Salesforce、SAP、Workday 和数据湖时很重要。

实际的架构如下所示：

[EHR] --FHIR--> [集成层] --map--> [规范模型（CIM）] --map--> [CRM/ERP/仓库]
[银行] --ISO 20022--> [集成层] --map--> [规范模型 (CIM)] --map--> [...]

FHIR 掌握临床优势。 ISO 20022 处理支付边缘。规范模型处理中间的含义。这是跨行业的模式；试图让 FHIR 完成所有三项工作却行不通。

If you are shopping: Boomi AtomSphere — Enterprise iPaaS for hybrid cloud-to-on-prem integration.

如何决定：标准清单

根据您的特定计划的这些标准对每个候选人标准进行评分：

1. 领域适合 - 标准是否对您的实体进行本机建模，或者您会不断扩展它吗？
2. 监管要求 — 是否强制采用（例如，美国互操作性规则下的 FHIR、支付方面的 ISO 20022）？
3. 生态系统成熟度 — 是否有生产级开源实现和供应商？
4. 版本稳定性 — 规范多久更改一次，迁移成本是多少？
5. 分析支持 — 您可以直接查询吗？还是需要转换管道？
6. 可扩展性模型 — 配置文件、原型或本体扩展 — 哪一个适合您的治理？
7. 治理和许可 - 谁控制规范，你能影响它吗？
8. 总拥有成本 — 包括映射维护，而不仅仅是初始集成。

一个有用的经验法则：如果涉及多个行业，则需要一个规范层；如果只涉及一项，则直接采用该行业标准。

常见的架构模式（和反模式）

模式：具有规范模型的中心辐射型。 每个源系统都映射到规范模型一次。添加一个新系统意味着一个新映射，而不是 N。这是 CIM 样式模型的经典理由。

模式：FHIR 基于传统系统的 FHIR 外观层。 在 HL7 v2 或 CDA 系统前面公开 FHIR API。用途广泛、务实；外观吸收了版本差异。

反模式：FHIR 作为企业总线。 使用 FHIR 资源作为非临床系统的内部契约。导致语义滥用和无法维护的扩展。

**反模式：一个标准可以统治一切。**假设任何单一标准（FHIR、CIM 或其他）都可以消除映射工作。它减少了它；它永远不会删除它。

反模式：忽略术语。 FHIR 的能力取决于编码值（LOINC、SNOMED CT、ICD-10）。如果没有术语治理，FHIR 交换会产生结构有效但语义无用的数据。

治理与人性化

标准因组织原因而失败的情况比技术原因更常见。成功的项目有以下三种做法：

• 分配模型所有权。 有人必须拥有规范模型并批准扩展。不受控制的扩展是概要文件和本体论腐烂的原因。
• 故意版本和弃用。 在需要之前发布映射和配置文件的弃用策略。
• 测试互操作性，不要假设它。 对规范映射运行一致性测试（例如，FHIR 的 Touchstone 或 Inferno 工具）和合同测试。

值得一读的权威资料

• HL7 FHIR 规范和实施指南：hl7.org/fhir
• HL7 International（FHIR、v2、CDA 的母组织）：hl7.org
• OMOP 通用数据模型 (OHDSI)：ohdsi.org
• ISO 20022 金融消息传递标准：iso20022.org
• 云信息模型项目：cloudinformationmodel.org

资料来源和进一步阅读

• 互操作性 — 维基百科：互操作性是产品或系统与其他产品或系统配合使用的特征。虽然该术语最初是为信息技术定义的…
• 快速医疗保健互操作性资源 - 维基百科：快速医疗保健互操作性资源（FHIR，如火）是 HL7 International 用于健康信息交换的技术标准。它是专为…
• 临床数据标准 - 维基百科：临床数据标准用于存储和传达与医疗保健相关的信息，因此其含义明确。它们用于临床实践…

FHIR 在实现语义互操作性方面的作用是什么？

FHIR 提供了一种以标准方式在临床医生和组织之间表示和共享信息的方法，无论本地 EHR 如何表示或存储数据。 FHIR 结合了 HL7 v2、HL7 v3 和 CDA 产品线的最佳功能，同时利用最新的 Web 标准并严格关注可实施性。 FHIR 解决方案由一组称为“资源”的模块化组件构建，可以轻松组装到解决现实世界临床和管理问题的工作系统中。

来源：ecqi.healthit.gov

EHR 供应商最广泛采用哪种互操作性标准？

HL7 v2 是 EHR 供应商中采用最广泛的互操作性标准。如今，以竖线分隔的 HL7 v2 消息仍然流经几乎每家美国医院，HL7 标准是临床数据交换的基础。 HL7 系列包括 HL7 v2、HL7 v3、临床文档架构 (CDA) 和 FHIR，其中 HL7 v2 是医疗保健 IT 的主力。 HL7 接口用于 Epic、Cerner 和其他主要 EHR，反映出医院、实验室、药房和健康 IT 供应商的广泛行业采用。

来源：medblocks.com

FHIR 等互操作性标准与专有解决方案相比如何？

FHIR 是特定于医疗保健的规范，而不是一般的企业数据模型，因此它不会对制造、金融、零售或供应链实体进行建模。将其视为通用互操作层是一个常见的架构错误。大多数企业需要一种分层方法：底层是与领域无关的规范模型，加上边缘的 FHIR、ISO 20022 和 X12 等领域标准。 FHIR 擅长通过 RESTful API 和资源进行临床数据交换，但其局限性包括版本变动、Profile 激增、原生分析支持薄弱以及不覆盖非临床领域。

常见问题

FHIR 是数据互操作性标准还是数据模型？

它两者都是，但有一个领域边界。 FHIR 是一种医疗保健互操作性标准，包括基于资源的数据模型、RESTful API 规范和一致性框架。它不是通用的企业数据模型，因此不应该用于表示非临床实体，例如产品、发票或订阅。

FHIR 与其他互操作性标准之间的主要区别是什么？

FHIR 是医疗保健特定且 API 优先的，通过 JSON 或 XML 使用 REST 上的精细资源。 HL7 v2 和 CDA 等较旧的医疗保健标准以消息和文档为中心。 ISO 20022 和 X12 等非医疗保健标准针对的是金融和供应链。主要区别在于范围：FHIR 解决的是临床数据交换，而不是跨行业整合。

FHIR 可以取代规范的企业数据模型吗？

不。FHIR 建模的是临床概念，而不是跨越 CRM、ERP 和财务系统的共享商业和运营实体。诸如Cloud Information Model之类的规范模型位于域之间并提供通用词汇表。 FHIR 通常作为源或目标馈入该规范层，而不是替换它。

我应该使用 FHIR R4 还是 R5？

R4 仍然是实施最广泛的版本，并且是许多监管计划和实施指南的基础，因此它通常是当今生产互操作性更安全的默认版本。 R5 添加了更新的功能和改进，但供应商和工具支持滞后。许多组织在试用 R5 的同时在生产中运行 R4，使用转换层来桥接版本。

FHIR 与 HL7 v2 和 CDA 相比如何？

HL7 v2 是一种预先协调的消息传递标准，在医院接口中仍然占主导地位，因其普遍性而受到重视，但因其脆弱、难以解析的语义而受到批评。 CDA 是一种以文档为中心的 XML 标准，适用于临床摘要。 FHIR 更细粒度、API 友好且更易于扩展，这就是为什么新开发通常青睐 FHIR，而 v2 和 CDA 仍保留在旧有系统中中。

跨行业企业应该标准化什么？

大多数跨行业企业应采用分层方法：边缘的领域标准（临床的 FHIR、支付的 ISO 20022、索赔和订单的 X12）和中间的与领域无关的规范模型。这最大限度地减少了点对点映射，并使每个领域标准都按照其设计目的进行工作。