最良のデータ相互運用性標準と FHIR: 上位の比較 (2026 年)

データ相互運用性標準と FHIR の比較は、アーキテクトが慎重に枠組みを定めるべき問題です。なぜなら、FHIR は汎用的なエンタープライズデータモデルではなく、ヘルスケア固有の仕様だからです。FHIR は臨床的な交換のために 150 を超える「リソース」（患者、観察、診察、投薬リクエストなど）を定義していますが、製造、金融、小売、またはサプライチェーンのエンティティをモデル化してはいません。したがって、FHIR をユニバーサルな相互運用性レイヤーとして扱うことは、よくあるアーキテクチャ上の間違いです。

重要なポイント

• FHIR はヘルスケア相互運用性標準であり、エンタープライズデータモデルではありません。 RESTful API とリソースを介した臨床データ交換には優れていますが、製造、金融、小売、またはサプライチェーンのエンティティをモデル化するものではありません。
• 「標準 vs FHIR」という枠組みは、通常、適切ではありません。 ほとんどの企業が必要としているのは「階層化」アプローチです。つまり、下層にドメインに依存しないカノニカルモデルを置き、エッジにドメイン標準（FHIR、ISO 20022、X12）を配置する構成です。
• FHIR の強みは本物です： 粒度の細かいリソース、REST + JSON/XML、公開された適合レイヤー（CapabilityStatement、プロファイル、実装ガイド）、および大規模なベンダーエコシステムを備えています。
• FHIR の限界も現実的です： バージョンの激しい変動（DSTU2 → STU3 → R4 → R5）、プロファイルの乱立、分析/OLAP へのネイティブサポートの弱さ、および非臨床ドメインのカバー範囲の欠如が挙げられます。
• クラウド情報モデル (CIM) は異なるアプローチを採用しています： オープンでアプリケーションに依存しない JSON-LD ベースのモデルであり、ドメイン標準を置き換えるのではなく、システム「間」に位置することを目的としています。
• 流行ではなく、ワークロードによって選択してください。 トランザクション交換、分析、およびマスターデータ管理は、それぞれ異なる標準が適しています。

なぜ「標準 vs FHIR」が間違った問いなのか

FHIR (Fast Healthcare Interoperability Resources) は HL7 International によって管理されており、医療情報交換のために設計されています。150 を超える「リソース」（患者、観察、診察、投薬リクエストなど）を定義し、それぞれが RESTful なインタラクションパターンと JSON/XML 表現を備えています。

これは「ドメイン」標準です。つまり、「病院の EHR と支払者の間で検査結果をどのように移動させるか」という問いには答えますが、「CRM、ERP、データウェアハウス全体で、顧客、注文、製品とは何か」という問いには答えません。

アーキテクトがこの決定を「FHIR かそれ以外か」という枠組みで捉えるとき、通常は以下の 3 つの異なるレイヤーを混同しています：

1. トランスポート/構文 — バイトをどのように移動させるか（REST、SOAP、メッセージキュー、ファイルドロップ）。
2. ドメインセマンティクス — 特定の業界においてデータが何を「意味」するか（FHIR、ISO 20022、X12、GS1）。
3. カノニカル/エンタープライズモデル — ドメイン間での対話を可能にする共有語彙（CIM、カスタムカノニカルモデル、業界オントロジー）。

FHIR はレイヤー 2 に位置します。企業の相互運用性における失敗の多くはレイヤー 3 で発生しますが、FHIR はそれを解決するように設計されていません。

比較表：主要な相互運用性標準

標準	プライマリドメイン	データモデルスタイル	トランスポート	最適な用途	主な制限
FHIR (R4/R5)	ヘルスケア（臨床および管理）	リソース指向、RESTful	REST/HTTP, JSON, XML	リアルタイム臨床 API、患者アクセス、SMART on FHIR アプリ	非臨床領域をカバーせず、バージョンの変動が激しく、プロファイルが乱立する
HL7 v2	医療メッセージング	セグメント/フィールド（パイプ区切り）	MLLP, ファイル	病院で依然として主流のレガシーなラボ/ADT フィード
HL7 CDA	臨床文書	XML ドキュメント	ファイル, XDS	文書中心の交換（退院サマリーなど）	冗長でクエリが困難
openEHR	臨床 EHR	アーキタイプ/テンプレート（2 レベルモデリング）	REST, ベンダー固有	臨床的に豊かで長期保存される記録	学習曲線が急で、ベンダーベースが小さい
OMOP CDM	ヘルスケア分析	リレーショナル、観察的	データベース	ポピュレーションヘルス、研究、OHDSI ネットワーク	トランザクション交換には不向き
X12 (EDI)	米国医療管理、サプライチェーン	トランザクションセット (837, 835, 850)	バッチファイル, AS2	請求、適格性確認、注文書	厳格でバッチ指向、米国中心
ISO 20022	金融サービス	メッセージ定義 (XML)	MX/MT メッセージング	決済、証券、貿易	複雑であり、世界的に移行が進行中
GS1 / EPCIS	小売、サプライチェーン	識別子 + イベント標準	様々	製品トレーサビリティ、バーコード	範囲が狭い（アイデンティティ + イベント）
schema.org	ウェブ / SEO	語彙 (JSON-LD)	HTTP	パブリックウェブのマークアップ、ディスカバリ	エンタープライズ契約ではない
クラウド情報モデル (CIM)	クロスインダストリー・エンタープライズ	JSON-LD オントロジー	モデルアーティファクト	クラウド/オンプレミスアプリ全体のカノニカルレイヤー	エコシステムが若く、導入が拡大中

パターンは明確です。FHIR は競争の激しい分野における強力な選択肢の一つですが、ドメインに限定されています。 問題が臨床データであるなら、FHIR が正解であることが多いでしょう。しかし、問題がエンタープライズ全体に及ぶ場合、FHIR はせいぜいデータソースの一つであり、最悪の場合は混乱の元となります。

関連: Fivetran — 実行し続けるフルマネージドの ELT パイプライン.

FHIR が真に優れている点

FHIR を完全に切り捨てることは、過剰に採用することと同様に怠慢であるため、その利点を具体的に挙げる価値があります。

• REST + JSON への親しみやすさ。 HTTP と JSON を知っている統合エンジニアは、HL7 v2 のパイプ区切りセグメントや CDA の深い XML とは異なり、すぐに生産性を上げることができます。
• 粒度の細かいリソース。 ドキュメント全体を解析するのではなく、単一の Observation（観察）をリクエストできるため、マイクロサービスやモバイルアプリに適しています。
• 適合性メカニズム。 CapabilityStatement、StructureDefinition、および公開された実装ガイド（US Core、IPS など）により、古い標準では稀な「機械可読な契約」が提供されます。
• 規制の追い風。 米国では、ONC Cures Act Final Rule や CMS 相互運用性規則により、FHIR ベースの API（特に Patient Access API）が推進されています。この規制上の強制力は、医療分野で FHIR を採用する正当な理由となります。
• エコシステム。 SMART on FHIR アプリの起動、主要 EHR ベンダーのサポート、オープンソースサーバー（HAPI FHIR、Microsoft FHIR Server）により、構築コストが削減されます。

患者向けアプリ、支払者とプロバイダー間の交換、または臨床意思決定支援ツールを構築している場合、通常は FHIR が正しいデフォルトとなります。

エンタープライズアーキテクトにとって FHIR が破綻する点

FHIR が本来のドメインを離れた瞬間に問題が表面化します。

私たちの選択: Workato — ビジネスチームが実際に構築できる自動化主導の iPaaS.

1. 非臨床エンティティのカバー範囲がない。 「請求書の明細行」、「倉庫のビン」、または「サブスクリプションプラン」といった FHIR リソースは存在しません。臨床リソースを無理に商用コンセプトに当てはめようとするチームは、非標準的かつ役に立たないモデルを作成することになります。

2. バージョン変動は実質的なコストとなる。 DSTU2、STU3、R4、R5 では、リソースの形状や用語のバインディングが異なります。マルチベンダー環境では、頻繁に 2 つまたは 3 つのバージョンが同時に稼働しており、変換レイヤーが必要になります。このための予算を確保してください。

3. プロファイルの乱立。 FHIR は拡張可能であるため、あらゆる実装ガイド、地域、ベンダーが独自のプロファイルを追加します。2 つのシステムが共に「FHIR R4 準拠」を謳っていても、共有プロファイルがなければ相互運用に失敗することがあります。これは FHIR 版の「誰もが独自の方言を持っている」問題です。

4. 分析は後回しにされている。 FHIR はトランザクション交換に最適化されており、カラム型分析には向いていません。ポピュレーションヘルスや研究目的には、通常 OMOP CDM やフラット化されたウェアハウスモデルの方が適切なターゲットとなります。FHIR から OMOP への変換は、よく知られた困難な作業です。

5. マスターデータモデルではない。 FHIR は、システム間で単一の「ゴールデン」な患者またはプロバイダーの ID をどのように解決するかを教えてはくれません。それは MDM (マスターデータ管理) の役割であり、あらゆる交換標準よりも上位に位置します。

カノニカルレイヤー：CIM と類似モデルの適合場所

これは多くの「FHIR vs X」の比較で飛ばされるレイヤーであり、クラウド情報モデル (CIM) が位置する場所です。

関連: Matillion — クラウド データ ウェアハウス用に構築されたプッシュダウン ELT.

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 にこれら 3 つの役割すべてを担わせようとしてもうまくいきません。

ショッピングの場合: Boomi AtomSphere — ハイブリッドクラウドとオンプレミスの統合のためのエンタープライズ iPaaS.

決定方法：基準チェックリスト

特定のプログラムにおいて、各候補標準を以下の基準でスコア付けしてください：

1. ドメイン適合性 — その標準はエンティティをネイティブにモデル化しているか。それとも絶えず拡張し続けることになるか。
2. 規制要件 — 導入が義務付けられているか（例：米国の相互運用性規則に基づく FHIR、決済用の ISO 20022）。
3. エコシステムの成熟度 — 本番環境で利用可能なオープンソース実装やベンダーが存在するか。
4. バージョンの安定性 — 仕様はどの程度の頻度で変更され、移行コストはどのくらいか。
5. 分析サポート — 直接クエリ可能か。それとも変換パイプラインが必要か。
6. 拡張性モデル — プロファイル、アーキタイプ、またはオントロジー拡張のうち、どれがガバナンスに適合するか。
7. ガバナンスとライセンス — 誰が仕様を管理しており、影響を与えることは可能か。
8. 総所有コスト (TCO) — 初期統合だけでなく、マッピングのメンテナンスコストを含めているか。

有用な経験則：複数の業界が関与している場合はカノニカルレイヤーが必要であり、単一の業界のみが関与している場合は、その業界の標準を直接採用してください。

一般的なアーキテクチャパターン（およびアンチパターン）

パターン：カノニカルモデルを用いたハブアンドスポーク。 各ソースシステムは一度だけカノニカルモデルにマッピングされます。新しいシステムを追加する場合、マッピング作業は N 回ではなく 1 回で済みます。これが CIM スタイルモデルの古典的な正当化理由です。

パターン：レガシー上の FHIR ファサード。 HL7 v2 や CDA システムの前面に FHIR API を公開します。広く普及している実用的な手法であり、ファサードがバージョンの差異を吸収します。

アンチパターン：エンタープライズバスとしての FHIR。 非臨床システムの内部契約として FHIR リソースを使用すること。これはセマンティクスの乱用と、保守不可能な拡張を招きます。

アンチパターン：すべてを支配する唯一の標準。 FHIR や CIM など、単一の標準さえあればマッピング作業がなくなると思い込むこと。標準は作業を「軽減」しますが、「排除」することはありません。

アンチパターン：用語（ターミノロジー）の無視。 FHIR の威力はコード化された値（LOINC、SNOMED CT、ICD-10）に依存しています。用語ガバナンスがなければ、FHIR による交換は構造的に正しくても、意味的には役に立たないデータを生成します。

ガバナンスと人間的な側面

標準が失敗するのは、技術的な理由よりも組織的な理由であることの方が多いです。成功しているプログラムには、以下の 3 つの実践があります：

• モデルの所有権を割り当てる。 誰かがカノニカルモデルを所有し、拡張を承認しなければなりません。制御されていない拡張は、プロファイルやオントロジーを形骸化させます。
• 意図的にバージョン管理し、非推奨化する。 必要になる前に、マッピングとプロファイルの非推奨化ポリシーを公開してください。
• 相互運用性を想定せず、テストする。 カノニカルマッピングに対して、適合性テスト（FHIR の Touchstone や Inferno ツールなど）およびコントラクトテストを実行してください。

読む価値のある信頼できる情報源

• HL7 FHIR 仕様および実装ガイド: hl7.org/fhir
• HL7 International (FHIR, v2, CDA の親組織): hl7.org
• OMOP Common Data Model (OHDSI): ohdsi.org
• ISO 20022 金融メッセージング標準: iso20022.org
• クラウド情報モデル プロジェクト: cloudinformationmodel.org

出典および詳細情報

• Interoperability — Wikipedia: 相互運用性とは、ある製品やシステムが他の製品やシステムと連携して動作する特性のことです。この用語は当初、情報技術向けに定義されましたが…
• Fast Healthcare Interoperability Resources — Wikipedia: Fast Healthcare Interoperability Resources (FHIR, 「fire」のように発音) は、医療情報交換のための HL7 International による技術標準です。これは…向けに設計されています。
• Clinical data standards — Wikipedia: 臨床データ標準は、医療に関連する情報を保存および伝達し、その意味を曖昧さなく伝えるために使用されます。これらは臨床現場で…

セマンティックな相互運用性の実現における FHIR の役割は何ですか？

FHIR は、ローカルの EHR がデータをどのように表現または保存しているかに関わらず、標準的な方法で臨床医や組織間で情報を表現し共有するための手段を提供します。FHIR は、HL7 v2、HL7 v3、および CDA 製品ラインの最良の機能を組み合わせつつ、最新のウェブ標準を活用し、実装可能性に重点を置いています。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 およびリソースを介した臨床データ交換に優れていますが、その限界には、バージョン チャーン、プロファイルの急増、ネイティブ分析サポートの弱さ、および非臨床ドメインのカバーがないことが含まれます。

よくある質問

FHIR はデータ相互運用性標準ですか、それともデータ モデルですか?

これは両方ですが、ドメイン境界があります。 FHIR は、リソースベースのデータ モデル、RESTful API 仕様、適合フレームワークを含む医療相互運用性標準です。これは一般的なエンタープライズ データ モデルではないため、製品、請求書、サブスクリプションなどの非臨床エンティティを表すために使用しないでください。

FHIR と他の相互運用性標準の主な違いは何ですか?

FHIR はヘルスケア固有かつ API ファーストであり、JSON または XML を使用した REST 上のきめ細かいリソースを使用します。 HL7 v2 や CDA などの古い医療標準はメッセージとドキュメント中心です。 ISO 20022 や X12 などの非医療規格は、金融とサプライ チェーンを対象としています。主な違いは範囲です。FHIR は業界間の統合ではなく、臨床データの交換を解決します。

FHIR はカノニカルなエンタープライズデータモデルを置き換えることができますか?

いいえ、FHIR は臨床概念をモデル化するものであり、CRM、ERP、および財務システムにまたがる共有の商業および運用エンティティをモデル化するものではありません。クラウド情報モデルなどの標準モデルはドメイン間に位置し、共通の語彙を提供します。 FHIR は通常、正規レイヤーを置き換えるのではなく、ソースまたはターゲットとしてその正規レイヤーにフィードします。

FHIR R4 または R5 を使用する必要がありますか?

R4 は依然として最も広く実装されているバージョンであり、多くの規制プログラムや実装ガイドの基礎となっているため、通常は今日の運用環境の相互運用性においてより安全なデフォルトとなっています。 R5 には新しい機能と改良点が追加されていますが、ベンダーとツールのサポートが遅れています。多くの組織は、バージョンをブリッジするために変換レイヤーを使用して、R5 を試験的に運用しながら R4 を運用環境で実行します。

FHIR は HL7 v2 および CDA とどう比較しますか?

HL7 v2 は、病院のインターフェイスで依然として主流となっている事前調整されたメッセージング標準であり、その普及性が高く評価されていますが、セマンティクスが脆弱で解析が難しいと批判されています。 CDA は、臨床要約に適したドキュメント中心の XML 標準です。 FHIR はより細分性が高く、API に適しており、拡張が容易です。そのため、v2 と CDA が従来の資産に存続する一方で、新規開発では一般に FHIR が好まれるのです。

業界を超えた企業は何を標準化する必要がありますか?

業界を超えた企業のほとんどは、階層化されたアプローチを採用する必要があります。エッジではドメイン標準 (臨床では FHIR、支払いでは ISO 20022、請求と注文では X12)、中間ではドメインに依存しない標準モデルを採用します。これにより、ポイントツーポイント マッピングが最小限に抑えられ、各ドメイン標準が設計どおりに実行され続けます。