簡単な回答: ヘルスデータは4つの標準レイヤーを介してやり取りされます。交換標準はシステム間でデータを運びます。例：HL7 v2メッセージ、CDAドキュメント、FHIRリソース、画像用のDICOM。モデリングとストレージ標準は、システム内でレコードがどのように構造化されるかを定義します。例：臨床記録用のopenEHR、研究データベース用のOMOP。ターミノロジーは、両者が理解できる概念にコードを付与します。例：SNOMED CT、LOINC、ICD、ATC、UCUM、RxNorm。アイデンティティとセキュリティ標準は、誰が何を読むことができるかを決定します。例：OAuth 2.0、SMART on FHIR、およびこれらすべてをテスト済みのレシピに組み合わせたIHEプロファイル。単一の標準だけを使用する人はいません。病院は通常、4つのレイヤーすべてを同時に運用しています。
マップ
医療の相互運用性標準は4つのレイヤーで構成されています。交換標準（HL7 v2、CDA、FHIR、DICOM、DICOMweb）はシステム間でデータを移動させ、IHEプロファイルはそれらをテスト済みのレシピにまとめます。openEHRは保存された記録を構造化し、OMOPは研究データベースを構造化します。SNOMED CTやLOINCなどの用語集、SMART on FHIRなどのID標準は、それらすべての中で使用されます。
| レイヤー | 標準 | 内容 | 2026年時点での利用箇所 |
|---|---|---|---|
| 交換 | HL7 v2 | MLLP経由のパイプ区切りメッセージ (ADT, ORU, ORM, SIU) | 病院内：入院、検査結果、オーダー、スケジュール管理。依然として最も一般的なインターフェース |
| 交換 | CDA / C-CDA | 人間が読める部分とコード化されたエントリを持つXML臨床ドキュメント | 退院サマリー、紹介状、米国のC-CDA、MyHealth@EUでのクロスボーダーサマリー |
| 交換 | FHIR (R4, R4B, R5) | RESTとJSON経由のWebリソース (Patient, Observation, Condition…) | 患者アプリ、国内API、EHR API、US Core、IPS、EHDS交換フォーマット |
| 交換 | DICOMとDICOMweb | 埋め込みメタデータを持つ画像オブジェクト。DICOMwebはRESTインターフェース | 全てのスキャナー、PACS、放射線ビューア。WebビューアはDICOMwebを使用 |
| レシピ | IHEプロファイル | 特定のユースケースのための上記標準のテスト済み組み合わせ (XDS, PIX/PDQ, XCA, SWF) | 病院間および地域間のドキュメント共有、患者アイデンティティ、放射線ワークフロー |
| ストレージ | openEHR | レコード自体のためのアーキタイプベースの臨床データモデル | 欧州、スカンジナビア、ブラジルの一部における病院および国内EHRプラットフォーム |
| 研究 | OMOP CDM | 観察研究のための共通リレーショナルモデル | 研究ネットワーク、リアルワールドエビデンス、EHDSの二次利用 |
| ターミノロジー | SNOMED CT, LOINC, ICD-10/11, ATC, RxNorm, UCUM | 所見、検査、診断、医薬品、単位のコード | 上記全ての標準の内部 |
| アイデンティティ | OAuth 2.0, OpenID Connect, SMART on FHIR, IHE XUA | ユーザーが誰であるか、およびアプリが何にアクセスできるか | 全ての患者向けアプリおよび全てのEHRアプリプラットフォーム |
レイヤーの連携方法
医療の相互運用性標準のレイヤーは、同じワークフローでそれぞれ1つのジョブを実行することで組み合わされます。HL7 v2メッセージは検査オーダーを運び、LOINCとUCUMはその結果をコード化し、openEHRプラットフォームがそれを保存し、FHIR APIはSMART on FHIRログイン後に患者アプリに提供し、CDAドキュメントはそれを別の病院と共有します。
血液検査は、1日のうちに4つのレイヤーすべてで処理されます。オーダーは、HL7 v2 ORMメッセージ（交換）として病棟から出されます。分析装置の結果は、HL7 v2 ORUとして返され、検査はLOINCで、単位はUCUM（ターミノロジー）でコード化されます。病院はそれを独自のデータベース、おそらくopenEHRプラットフォーム（ストレージ）に保存します。患者のアプリは、患者がSMART on FHIR（アイデンティティ）でログインした後、FHIR API経由でObservationとして読み取ります。病院が完全なレポートを別の病院と共有する場合、IHE XDSレジストリを介してCDAドキュメントとして行うことがあります。結果が後に研究コホートに参加する場合、それはOMOPに変換されます。
これらの標準は競合するものではありません。それぞれが異なる目的のために構築されており、一方を他方に置き換えることは、通常、既に機能しているものを再構築することを意味します。
どちらが必要ですか？
どの医療相互運用性標準が必要かは、ジョブによります。患者または臨床医アプリにはSMART on FHIRを備えたFHIR R4、既存の病院システムとの接続にはHL7 v2、画像にはDICOMとDICOMweb、ドキュメント全体にはCDAまたはFHIRドキュメント、長期記録保存にはopenEHR、研究にはOMOP、そして2つのシステムが同一に動作する必要がある場合はIHEプロファイルが必要です。
- 患者または臨床医向けのアプリを開発している場合: FHIR R4、市場のプロファイル（実装ガイド）、ログイン用のSMART on FHIRを使用します。
- 病院の既存システムに接続する場合: まずHL7 v2を想定し、ベンダーが提供する場合はFHIRを使用します。HL7 v2メッセージの説明を参照してください。
- 画像を扱う場合: ストレージと転送にはDICOM、ブラウザ内のものにはDICOMweb、メタデータのみにはFHIR ImagingStudyを使用します。DICOMwebの説明とImagingStudy vs DICOMwebを参照してください。
- ドキュメント全体（サマリー、手紙）を交換する場合: 義務付けられている場合はCDA、選択できる場合はFHIRドキュメント（
documentタイプのBundle）を使用します。CDAとC-CDAの説明を参照してください。 - 数十年間のレコードストレージ方法を設計する場合: openEHRを使用し、交換レイヤーとしてFHIRを使用します。openEHR vs FHIRを参照してください。
- 多数のレコードで研究を実行する場合: OMOPを使用し、ソースとしてFHIRを使用します。ヘルスデータの二次利用を参照してください。
- 2つのシステムが同じように動作する必要がある場合: ユースケースのIHEプロファイルを選択し、それに対してテストします。
Anpherosの位置づけ
Anpheros Platformは、標準マップの交換レイヤーに、OAuth 2.0アクセスと変更通知用のWebフックを備えたFHIR R4サーバーとして配置され、HL7 v2 ORU、CSV、またはJSONからのコネクタを介して検査結果を受信します。DICOM画像は保存せず、CDS Hooksサービスも提供しません。これらは病院システムに残ります。
Anpheros Platformは、患者中心のレコードに必要なリソース（Patient, Observation, Condition, MedicationStatement, DocumentReference, DiagnosticReport, Immunization, Consent, Provenanceなど）、アクセス用のOAuth 2.0、および変更通知用のWebフックを備えたFHIR R4サーバーです。検査結果は、ラボコネクタからHL7 v2 ORU、CSV、またはJSONで到着します。DICOM画像は保存せず、CDS Hooksサービスも提供しません。これらは病院のシステム内に留まり、レコードはそれらを指します。
読む順序
医療相互運用性標準の適切な読み順序は、まずFHIRとは何か、そしてHL7 v2との違い、次にFHIR Observationリソース、次にその中で使用されるLOINCとSNOMED CTの用語集、次に画像のためのDICOMweb、ドキュメントのためのCDA、そして最後に記録がどのように保存されるかについてのopenEHRとFHIRの比較から始まります。
この分野に初めて触れる方は：FHIRとは → HL7 vs FHIR → FHIR Observation → LOINCとSNOMED CT → DICOMweb → CDA → openEHR vs FHIR。
関連ページ
- HL7 vs FHIR
- HL7 v2メッセージの説明
- CDAとC-CDAの説明
- DICOMwebの説明
- openEHR vs FHIR
- FHIR実装ガイド
- FHIR R4 vs R5
- LOINCコードとは何ですか？
- SNOMED CTとは何ですか？
- 開発者向けDICOM vs FHIR
- FHIRプロファイルと拡張機能の説明
- FHIRターミノロジーサーバーの説明
- ヘルスデータ規制マップ
- 欧州と米国の国内電子ヘルスレコード
- 病院システム統合の説明
- 医療データにおけるAI
- ヘルスデータの二次利用
- ヘルスアプリにおけるセキュリティとアイデンティティ
ソース
- HL7 International: standards
- HL7 FHIR R4 specification
- DICOM standard, current edition
- IHE technical frameworks
- openEHR specifications
- OHDSI OMOP Common Data Model
- SMART App Launch
よくある質問
FHIRは他のすべての標準を置き換えていますか？
いいえ。FHIRはカスタムAPIを置き換え、徐々に一部のCDAドキュメント交換も置き換えています。HL7 v2は病院内での主要な役割を維持し、DICOMは画像の唯一の標準であり、openEHRとOMOPはFHIRが設計されていない質問（ストレージ、研究）に答えます。
標準とIHEプロファイルの違いは何ですか？
FHIRやDICOMのような標準は、ビルディングブロックを定義します。IHEプロファイルは特定のブロックを選択し、そのオプションを固定し、1つのタスクのためにシステムがどのように使用しなければならないかを正確に指示するため、IHEテストに合格した2つのベンダーはプロジェクトなしで協力できます。
国の医療システムはどの標準を使用していますか？
ほとんどの欧州システムはCDAドキュメントとHL7 v2で始まり、FHIR APIを追加しています。EHDS交換フォーマットはFHIRとIPSに基づいています。米国は患者アクセスにFHIR US Coreを、ドキュメント交換にC-CDAを義務付けています。
SNOMED CTとLOINCはどこに位置づけられますか？
これらは交換標準ではなく、それらすべての中で使用される語彙です。LOINCコードは、HL7 v2 OBXセグメント、CDAエントリ、およびFHIR Observationの検査を同様に識別します。
サンドボックスで無料で試す
5分で最初のFHIR呼び出し. 患者さんの同意が組み込まれたHL7 FHIR R4 APIです。サンドボックスでお試しいただき、ご自身のアプリやクリニックのシステムを接続してください。
無料・合成患者30人・カード不要
Anpherosは、患者が管理し、あらゆるクリニックと共有できる医療記録を、EUを拠点とするHL7 FHIR R4プラットフォーム上で構築しています。これらのガイドは、ご自身の健康を理解し整理するのに役立ちますが、医師の代わりになるものではありません。
Anpherosについて →