xDev Asia

HL7 International とは何か、医療データ標準の開発の歴史 (HL7 v2、HL7 v3/RIM、CDA)、医療データの標準化が必要な理由、医療における相互運用性の課題、以前の標準の制限に対処するために FHIR がどのように誕生したかについて学びます。

HL7 FHIR - 基本から高度な医療データ標準

パート 1: HL7 と FHIR プラットフォーム

xdev.asia

1. なぜ医療データを標準化する必要があるのですか?

あなたが病院 A に行って検査を受け、2 型糖尿病と診断され、薬を処方されたと想像してください。来週、あなたは別の理由で病院 B に行きます。病院 B の医師は、病院 A のあなたの医療記録を見ることができません。これは、2 つのシステムが互いに「会話」することがまったくできないためです。

これは珍しい話ではありません。実は、これは、 最も一般的な問題 世界中のデジタルヘルス業界で。各病院と各クリニックは異なるソフトウェアを使用し、異なる方法でデータを保存し、情報を交換するための「共通言語」を持っていません。

相互運用性とは何ですか?

相互運用性 医療における (相互運用性) とは、さまざまな医療情報システムが次のことを行う能力です。

データ交換 (交換) — システム間でデータを送受信します。
データを理解する (解釈) — 受信システムはデータの正しい意味を理解できます。
データ使用量 (使用) — 受信したデータは臨床上の意思決定をサポートするために使用できます。

相互運用性には 4 つのレベルがあります。

レベル	名前	説明	たとえば
1	基礎的な	2つのシステム間でデータを送受信する	検査結果のPDFファイルを送信
2	構造的	データは均一な構造を持っています	テスト結果をHL7 v2メッセージとして送信
3	セマンティクス	双方とも同じ意味を理解している	ICD-10 コード「E11.9」は「2 型糖尿病」として理解されます。
4	組織的	プロセス、ポリシー、法的サポートがある	この回覧により、病院間のデータ共有が可能になります

相互運用性の欠如による影響

テストを繰り返す — 新しい病院では古い結果が得られなかったため、患者は再度検査を受けなければならなかった
医療過誤 — 医師は、患者がどのような薬にアレルギーがあるのか、どのような薬を服用しているのかを知りません。
コストが増加する — 相互運用性の欠如により、米国は年間 300 億ドルを無駄にしていると推定されています
遅延治療 — 紙の転送書類を待たなければなりません
医学研究には限界がある — 多施設データは集約できません

2. HL7 International — 医療データ標準を推進する組織

HL7 (健康レベル 7) International は、年に設立された非営利の標準化団体です。 1987年, 本社は米国ミシガン州アナーバーにあります。「レベル 7」という名前は、OSI モデルの 7 番目の層 (アプリケーション層)、つまりアプリケーションが相互に通信する層を指します。

HL7 インターナショナルにはさらに多くの機能があります 会員数1,600名 もっと言葉を 55か国、医療ソフトウェアベンダー、病院、政府機関、保険会社、研究機関が含まれます。

進化したHL7規格

HL7 は 35 年以上にわたり、時代のニーズに対応する多くのデータ標準を開発してきました。

3. HL7 バージョン 2 (v2) — 世界で最も人気のある標準

歴史

HL7 v2 が今年最初にリリースされました 1989年 そしてすぐに世界で最も人気のある医療データ交換標準となりました。現在までのところ、推定 米国の病院の 95% そして 35か国以上 HL7 v2 を使用します。

HL7 v2 メッセージ構造

HL7 v2 は、パイプ区切り文字を含むテキスト形式を使用します。

MSH|^~\&|HIS|BVBACHMAI|LIS|LABXN|202603301000||ADT^A01|MSG00001|P|2.5
EVN|A01|202603301000
PID|1||MRN12345^^^BVBACHMAI||NGUYEN^VAN^A||19850315|M|||123 Le Loi^^HCM^^700000^VN
PV1|1|I|W4B^401^1|||||||||||||||VN001|||||||||||||||||||||||||202603300800

説明:

MSH — メッセージヘッダー: メッセージに関する情報 (送信元、宛先、タイプ、バージョン)
EVN — イベント: メッセージをトリガーするイベント (A01 = 入院)
PID — 患者識別: 患者情報
PV1 — 患者訪問: 訪問/入院に関する情報

メリットとデメリット

利点	短所
広く人気があり、支持されている	オプションが多すぎるため、それぞれの実装が異なります
シンプル、軽量	厳密なモデルはありません (各フィールドは異なる方法で使用できます)
数百万ものインターフェースが稼働中	下位互換性コンプレックス (v2.1 → v2.9)
豊富なサポートツール（Mirth、Rhapsody）	Web/REST をネイティブにサポートしない

4. HL7 バージョン 3 と参照情報モデル (RIM)

抜本的な標準化への野心

v2 の限界を認識し、HL7 の開発が開始されました v3 1990 年代後半以来、ヘルスケア分野全体のための統一された一貫したデータモデルを作成するという野心を抱いてきました。

HL7 v3 の中心となるのは、 RIM（参照情報モデル） — 医療におけるすべての概念を記述する抽象オブジェクトモデル:

行為 — 医療行為（診察、検査、処方など）
エンティティ — エンティティ (患者、医師、薬剤、デバイスなど)
役割 — 役割 (患者、医療従事者、医療提供者...)
参加 — 参加する（誰がどの行動に参加するか）
行為関係 — アクション間の関係
役割リンク — 役割間の関係

HL7 v3 の問題

v3/RIM は理論上は非常にタイトですが、実際には次のようになります。

複雑すぎる — XML メッセージは扱いにくく、実装が困難です
学習が困難 — 導入するには RIM を深く理解する必要があります
高コスト — 導入には膨大な時間とリソースがかかる
導入率が低い — 純粋な HL7 v3 の導入に成功した組織はほとんどありません

5. CDA (臨床文書アーキテクチャ)

CDA 最も成功した HL7 v3 標準であり、臨床文書交換に広く使用されています。 CDA は XML を使用して、次のような医療文書を構造化します。

ヘッダー — メタデータ (患者、著者、施設、作成日)
本体 — 臨床内容、3 つのレベルで可能:
- レベル1：非構造化本文（PDF/テキスト）
- レベル2: 説明文のあるセクション
- レベル3: 完全に構造化されたコード化されたエントリ

CDA は以下の分野で広く使用されています。 C-CDA（統合CDA） 米国では有意義な使用/相互運用性の促進を目的として、ヨーロッパと日本の多くのプロジェクトで使用されています。

CDA の制限

ジャストフィット 文書ベースのやりとり （書類のやり取り）
サポートされていません データレベルの交換 (各データフィールドをクエリ)
XML は複雑なので、RIM を理解する必要があります
最新のモバイル/Web アプリをサポートしていません

6. FHIR の誕生 — 相互運用性のための新しい「Fire」

起源

年 2011年、 グレアム・グリーブ HL7 の最もベテランの開発者の 1 人である彼は、まったく新しいアプローチを提案しています。 (v3 のように) すべてをモデル化しようとする代わりに、彼は次のように提案しました。

「最新の Web テクノロジー (REST、JSON、OAuth) に基づいて、シンプルで動的に構成可能なリソースのセットを構築し、80/20 原則を適用して、20% の複雑さで 80% のユースケースを解決します。」

名前 FHIR （「ファイア」と発音）はの略語です。 高速医療相互運用性リソース、目標を反映しています:

速い — すぐに実装でき、学びやすい
ヘルスケア — 健康に重点を置く
相互運用性 — システム間の相互運用性
リソース — 構成可能なデータの基本単位

FHIR の開発マイルストーン

年	バージョン	優れた機能
2012年	DSTU 0 (ドラフト)	最初のテストバージョン
2014年	DSTU1 (R1)	試用のための標準草案第 1 版
2015年	DSTU2(R2)	採用数が急増し始めた
2017年	STU3(R3)	試用用の標準、多数の新しいリソース
2019年	R4	規範第一 — 患者、観察、バンドル安定
2020年	R4B	R4の小規模アップデート
2023年	R5	現在のバージョン — トピックベースのサブスクリプション、多くの改善
～2026年以降	R6	開発中 — AI/ML 統合、ワークフローの改善

なぜ FHIR は成功するのでしょうか?

Web標準に基づく — REST、JSON、XML、OAuth 2.0、HTTP
実装が簡単 — 多くの開発者は 1 日でインターフェイスを実行できるようになります
仕様は自由です — ライセンス料なし
多くのライブラリがサポートしています — HAPI FHIR (Java)、fhir.js、fhirclient.py、Firely (.NET)
優れた拡張性 — 拡張メカニズムにより、標準を破ることなく拡張が可能
人間が判読できる — 各リソースには HTML の説明セクションがあります
複数のパラダイムをサポート — REST、メッセージング、ドキュメント、サービス
政府が必要とする — 米国 (ONC/CMS)、オーストラリア、英国、EU はすべて委任されています

7. HL7 標準の比較

基準	HL7 v2	HL7 v3	CDA	FHIR
誕生年	1989年	～2000年	2005年	2014年
フォーマット	パイプ区切りのテキスト	XML	XML	JSON、XML、RDF
データモデル	暗黙的 (緩い)	RIM (厳密)	RIM（文書）	リソース (コンポーザブル)
パラダイム	メッセージング	メッセージング	文書	REST + メッセージング + ドキュメント
実装の複雑さ	平均	非常に高い	高	低い
ウェブ/モバイルのサポート	いいえ	いいえ	制限事項	ネイティブ
養子縁組	非常に高い (レガシー)	低い	平均	早く増やす
人間が判読できる	いいえ	いいえ	はい（ナレーションセクション）	はい (リソースの説明)

8. 世界中で FHIR — 誰が使用していますか?

米国

21世紀の治療法 (2020): EHR ベンダーに FHIR API (US Core) のサポートを義務付ける
CMS 相互運用性ルール: 支払者 (保険) に FHIR に基づく患者アクセス API の提供を義務付ける
ONC テフカ: National Data Exchange Framework、FHIR が基盤です
Epic、Cerner (Oracle Health)、Allscripts はすべて FHIR API を備えています

ヨーロッパ

欧州医療データスペース (EHDS): EU規制は国境を越えた健康データにFHIRを使用
国際患者概要 (IPS): FHIR に基づいて、臨床概要の国際共有が可能

オーストラリア

AU ベース実装ガイド: 全国の標準FHIRプロファイル
私の健康記録: FHIR を使用した国民健康記録システム

ベトナム

FHIR に関する正式な義務はありませんが、医療をデジタル化するためのロードマップに含まれています
医療データの相互運用性標準を規制する回覧 54/2017/TT-BYT (FHIR はまだ使用されていません)
電子医療記録に関する回覧 46/2018/TT-BYT
いくつかの先駆的なプロジェクトが FHIR をテストしています
ベトナムFHIR導入ガイドを構築する絶好の機会

9. 最初に知っておく必要がある基本的な FHIR 概念

次の記事に進む前に、いくつかの重要な用語について理解しておきましょう。

用語	説明	たとえば
リソース	FHIR のデータの基本単位	患者、観察、出会い
データ型	リソースで使用されるデータ型	人間名、住所、コード可能なコンセプト
延長	カスタムデータをリソースに追加する方法	患者に「民族」フィールドを追加
プロフィール	リソースを特定のユースケースにバインドする	米国の主な患者プロフィール
用語	医療コード体系	ICD-10、SNOMED CT、LOINC
バンドル	多くのリソースを集める	検索結果、取引
参考資料	リソース間のリンク	観察対象者→患者/123
実装ガイド	コンテキスト固有の FHIR 実装ガイダンス	米国コアIG、IPS IG

10. まとめ

この記事では、次のことを学びました。

相互運用性 デジタルヘルスにおける最大の課題であり、4つのレベルが含まれます
HL7 インターナショナル 1987 年から運営されている大手の医療標準化団体です。
HL7 v2 最も人気があるが一貫性に欠ける
HL7 v3/RIM タイトだが複雑すぎる
CDA 文書交換には成功しましたが、データレベルのアクセスには制限がありました
FHIR Web 標準に基づいており、実装が簡単なすべての利点を組み合わせています
FHIR R5 は現在のバージョン、R4 標準は最もよく使用されている安定バージョンです
多くの国が持っています必須 FHIR を使用して、ベトナムがロードマップに載っています

次回の記事ではさらに深く掘り下げていきます FHIR R5 アーキテクチャ — リソース、データ型、拡張性、および核となる設計原則を理解します。

レッスン 1: HL7 の概要と医療データ標準の歴史