概要
医療従事者は、医薬品やワクチンによる有害事象が疑われる場合、FDAに報告する義務があります。 従来は、患者の基本情報や症状を fda.gov上のウェブサイトに入力する必要がありました。 手動で。 退役軍人省（VA）は、それだけでは不十分だと判断しました。 FHIR APIを活用することで、手作業によるプロセスを省き、有害事象の通知を自動的に送信できるようになりました。
この変革を支えているのが「Fast Healthcare Interoperability Resources（FHIR）」という標準規格です。これは、医療機関間で記録全体をコピーする代わりに、医療システムが特定の患者データをリクエストできるようにするRESTful APIです。
自組織の医療システム向けにFHIRの導入を検討している場合でも、開発者としてFHIRを活用している場合でも、ここではFHIRが実運用環境でどのように機能するか、そしてなぜVA（退役軍人省）が誰の予想よりも迅速に導入を進められたのかについて解説します。
VAとFDAがFHIRを活用して構築したもの
このシステムは「プロジェクト・ベスト」と呼ばれています。 このシステムはeHealth Exchange上で稼働しており、国内最大級の医療データネットワークの一つです。 現在、年間250億件以上の取引を処理しており、FHIR APIを活用して、FDAと46州にわたるVAを含む医療提供者の記録を連携させています。
プロジェクトBESTは、以下の2つのモデルをサポートしています：
「ポーリングモデル」 FDAは有害事象（ ）について把握すると、さらなる患者データが必要となります。 eHealth Exchangeを介してFHIR APIリクエストを送信すると、同システムは医療提供者のネットワークに照会を行い、関連する臨床記録をまとめてFDAに返送します。 依頼、応答、完了。手動でのデータ入力も、FAXも、遅延もありません。
プッシュ型モデル 退役軍人省（VA）はさらに一歩踏み込みました。 VAは、FDAからの要請を待つのではなく、有害事象が確認されたその瞬間に、FHIRを通じて自動的に有害事象の報告を行っています。 事後対応ではなく、先手を打つ。
「VAは巨大な組織であり、米国最大の医療システムであり、政府が所有・運営しています。」 「そして、彼らはこれを実装するスピードが、私が今まで見たどの小さなスタートアップよりも早かったと言えます。」
eHealth Exchange社長、ジェイ・ナカシマ氏
Project BESTは、InterSystems IRIS for HealthおよびInterSystems HealthShareを基盤とするeHealth Exchange Hubを通じて運用されており、InterSystemsがクラウド上でホストするマネージドサービスとして提供されています。
しかし、プロジェクトBESTを単なる一過性の成功にとどまらないものにしているのは、次の点です：
「これは、他の公衆衛生のユースケースや、保険者から医療提供者への情報交換などにも活用できる、再現可能なモデルです。」 「そのリストは延々と続く。」 - ジェイ・ナカシマ
このネットワークは、プロバイダー間の情報交換を目的として構築されました。 プロジェクトBESTは、これを公衆衛生の分野で再活用しました。 このパターンは、システムを共有していない組織間でデータのやり取りが必要なあらゆる場面で有効です。
FHIR APIとは何ですか？
HL7 FHIRは、HL7 Internationalによって開発された医療データ規格であり、ジェイ・ナカシマ氏はこれを次のように簡潔に定義している。
「FHIRは、プラグアンドプレイではないものの、今後20年間で実現可能な限りそれに近い、より現代的なAPIに過ぎません。」 ジェイ・ナカシマは、健康情報を「リソース」と呼ばれるモジュール型のデータモデルに整理しており、その例としては「患者」、「薬剤」、「観察」、「診療」などがあります。 これらはそれぞれ、RESTの原則に基づいて構築されたRESTfulアプリケーション・プログラミング・インターフェース（API）を通じて利用可能です。 GETはデータを取得します。 POSTは新しいリソースを作成します。 PUTは既存のものを更新します。 DELETE を実行すると、それが削除されます。 リクエストとレスポンスはJSONまたはXML形式でやり取りされ、成功または失敗は標準のHTTPステータスコードで示されます。
FHIR APIのリクエストは次のようになります：
https://fhir.example.com/Patient/12345/MedicationRequestを入手する
「あなたは、全国の医療データをコピーしているわけではありません。」 この場合、あなたは「FDAはドン・ウッドロックについて知りたいと思っている」と言っていることになります。 「さあ、あのレコードを取得しよう。」 - ドン・ウッドロック、インターシステムズ社長
従来の相互運用性とは、コピー＆ペーストに過ぎず、検査室から電子カルテへ、あるいはある組織から別の組織へとデータが複製されていました。 FHIRでは、これをリクエスト・レスポンス方式に置き換えており、その正確さが重要です：
「患者ジェイに関する300ページ分に相当する情報は必要ありません。 「彼の検査結果さえあればいいんです。」 - ドン・ウッドロック
Systemsは、まさに必要なものだけを要求します。 この精度の高さにより、オーバーヘッドが削減され、正確性が向上し、患者データの不必要な公開が抑制されます。
「 InterSystems IRIS for Health」のようなプラットフォームは、ネイティブなFHIRサーバー機能を提供しており、医療機関は基盤となるシステムを再構築することなく、臨床データをFHIRリソースとして公開することが可能になります。 開発者にとって、これは、HL7 v2、CDA、FHIRを並行して処理できるデータプラットフォームを基盤とした、標準に準拠したFHIRエンドポイントを意味します。
SMART on FHIR とオープンAPIエコシステム
FHIRの相互運用性は、組織間のデータ交換だけに限定されるものではありません。 SMART on FHIR は、OAuth ベースの認証を用いてデータアクセスを制御し、開発者が異なる EHR システム間で動作する医療アプリケーションを構築できるようにするオープンな仕様です。 その開発者たちは、これを「健康のためのアプリストア」と呼んでいます。これは、SMART対応の電子カルテならどれでも動作する、互換性のあるアプリケーションです。
FHIRは、開発者がすでに熟知しているWeb標準、すなわちREST、JSON、HTTPに基づいて構築されています。 独自の医療用ミドルウェアは不要です。 その利便性により、医療業界全体で導入が進んでいます。 SMART on FHIRと組み合わせることで、開発者は一度開発するだけで、複数の医療システムに展開することができます。 また、AIエージェントが医療ツールと連携し始めるにつれ、FHIRは、それらのエージェントが安全に動作するために必要な標準化されたデータ層を提供します。
規制により、その導入が後押しされています。 保健情報技術国家調整官室は、認定された電子健康記録（EHR）プログラムにおいてFHIR APIの使用を義務付けています。 「21世紀治療法」では、セキュリティが確保されたアプリを通じた患者へのアクセスが義務付けられています。 また、CMS-0057-Fでは、支払機関に対し、2027年1月までにFHIRベースの事前承認APIを導入することが義務付けられており、運用要件は2026年から適用されます。
InterSystems HealthShareは、EHR、検査データ、請求プラットフォーム、患者ポータルなど、さまざまな医療システムからのデータを集約して統一された患者記録にまとめ、FHIR APIやSMART on FHIRアプリケーションに対して、標準化されたデータ交換のための一貫性のある基盤を提供します。
FHIRの始め方
医療業界全体でFHIRが自動的に導入されるわけではありません。 多くの旧式のシステムでは、FHIRのネイティブサポートがありません。 EHRベンダーによって実装内容は異なります。 また、FHIR を通じてデータを共有するには、プライバシー、セキュリティ、および患者の同意について慎重な管理が必要です。
実践的な3つの出発点：
- まず、明確に定義されたユースケースから始めましょう。 プロジェクトBESTが成功したのは、すべてを一度にFHIR対応にしようとするのではなく、有害事象の報告という具体的な課題を解決したからです。
- 統合インフラを評価してください。 御社のシステムでは、現在、データをFHIRリソースとして公開できますか？ そうでない場合は、プロトコル変換を処理する統合エンジンへの投資が最優先となります。
- FHIRをネイティブでサポートするベンダーと提携してください。 「FHIR準拠」と「FHIRネイティブ」の違いは重要です。ネイティブ対応であれば、変換レイヤーが少なくなり、障害発生の要因も減ります。
