電子カルテ(EHR)は現在、ほぼすべての病院に普及していますが、他の医療ITシステムとの真の相互運用性は依然として十分に実現されていません。170万件の患者安全事象報告を対象とした米国の調査では、相互運用性の不具合が数千件の安全上のハザードの原因となっており、その大半は、組織間ではなく、同一の病院システム内で発生していることが明らかになりました。このデータは10年前のものですが、このような分断によるコストが膨大であることは分かっています。
ウエスト・ヘルス研究所の調査では、相互運用可能なシステムによって、有害事象に伴うコストを年間20億ドル削減し、重複検査に伴うコストを年間30億ドル削減するとともに、臨床医の生産性を年間120億ドル向上させることができると推定されています。
同時に、医療機器としてのソフトウェア(SaMD)の市場規模は、2032年までに68億7,000万ドルに達すると予測されています。これらの機器は医療提供を変革する可能性を秘めていますが、その導入には依然として大きな壁があります。それは、病院のワークフローへの統合です。相互運用性の障壁は、その価値を実現する上で依然として最大の課題の一つです。
SaMDメーカーにとって、ビジネス上の利点は明確です。「必要な場所で、必要なときに」データをEHR内に直接提供する機器は、医師から選好されます。医師は、自身のワークフローにシームレスに適合する機器を推奨する可能性がはるかに高くなります。その結果、患者のアウトカムが向上し、機器の売上も増加するため、相互運用性は戦略的な差別化要因となります。
医療におけるFHIR標準とは何ですか?
FHIR(Fast Healthcare Interoperability Resources)は、医療機器、医療ITシステム、アプリケーション間の「相互通信」を可能にする相互運用性の標準です。こちらは、モダンなWeb技術を使用した標準化されたリアルタイムの情報共有に対する業界の需要の高まりに応えるため、HL7(Health Level Seven International)によって開発されました。
FHIRが際立っているのは、HL7 v2やレガシーシステムを長年悩ませてきた統合上のボトルネックを解消し、病院のEHR内で標準化されたデータをリアルタイムに直接交換できる点です。FHIRの設計はモダンなWeb API技術、特に標準的なHTTPメソッド(GET、POST、PUT)を使用して医療データリソースを作成、取得、更新するRESTful APIを中心に構築されています。
患者、観察、薬剤、処置などのFHIRリソースには、明確に定義されたAPIエンドポイントを介してアクセスできるため、システムや機器は安全かつリアルタイムに情報を交換できます。これにより、相互運用性がWeb APIを基盤として構築される新たな時代が到来し、FHIRによる相互運用性は、あらゆるコネクテッドヘルス製品に不可欠なものとみなされています。
FHIRとHL7 v2の違いは何ですか?
HL7 Version 2(v2)は、パイプ区切り形式(フィールドを「|」で区切る形式など)のテキストベースのメッセージを使用して、異なる病院システム(EHR、検査システム、医事会計システムなど)間の通信を可能にする規格です。
これは、過去30年以上にわたり最も広く実装されている規格です。これは1980年代から1990年代にかけて画期的なものでした。すべてのインターフェースを個別に構築する代わりに、病院はHL7 v2メッセージを使用して、入院、オーダー、検査結果、請求などのシステムを接続できるようになりました。この規格の柔軟性と幅広い普及は、その強みであると同時にアキレス腱でもあります。
この規格は意図的にカスタマイズを許容しているため、専門のインターフェースエンジニアや高価なミドルウェアが必要となり、組織間で実装に大きなばらつきが生じました。さらに、HL7 v2は、病院内のポイントツーポイント接続が中心だった時代に向けて設計されたものであり、クラウドやモバイルが広く利用される将来を想定したものではありませんでした。
病院環境でSaMDをFHIR経由で統合すると、機器データを標準化されたAPIを通じて電子カルテに自動的かつ安全に取り込むことができます。SaMDメーカーは、個別の統合をその都度構築したり、カスタムインターフェースを維持したりする代わりに、「Observation」や「Patient」などのFHIRのモジュール型リソースを活用して、臨床的に関連するデータを臨床医のワークフローに直接送信します。
これにより、新しい機器やデータ共有パートナーを導入するための作業負担が大幅に軽減されます。対象ごとに新しいデータフィードを構築する代わりに、同じAPI呼び出しを活用できるためです。最も重要なのは、FHIRが相互運用性を損なうことなく拡張できるように設計されている点です。機器メーカーにとって、従来の統合モデルとFHIR対応モデルの違いは歴然としています。
FHIRのAPI駆動型モデルでは、リアルタイムでのアクセスが可能になり、手作業による記録が最小限に抑えられ、新しい機器の導入に要する時間が短縮されます。そして何よりも、医師や看護師がEHR内で最新の機器測定値を検査結果やバイタルサインと併せて確認できるようになります。その結果、臨床医のワークフローが効率化され、患者のケアコーディネーションが向上します。

上記のとおり、機器のバックエンドは、HTTPS経由のFHIR APIを介して病院のEHRと直接通信します。実際には、これは機器のクラウドシステムが、標準的なRESTful API呼び出しを通じて、EHRデータベースにデータ(例:血糖値測定の「Observation」リソース)を書き込んだり、EHRから関連する臨床コンテキストを読み取ったりできることを意味します。専用のVPNトンネルやカスタム解析エンジンは必要ありません。データはセキュアなWebプロトコルを介して交換されます。
FHIRでは、病院がAPIを有効化し、機器メーカーがこの標準を実装すれば、その単一の統合を最小限の調整で多くの病院やEHRに適用できます。その結果、新しい施設への導入が大幅に迅速化され、機器から臨床医の既存のワークフローへデータが継続的に流れるようになります。
FHIR対応モデルでは、機器データが医師が通常使用するEHR環境内に表示されます。例えば、遠隔センサーの測定値は、別個のサイロに保存されるのではなく、検査結果やバイタルサインと並んでEHRのチャート上に表示されます。これは非常に大きな意味を持ちます。医師や看護師は、「システムを切り替えたり、データを手入力したり」する必要がなくなるため、時間を節約でき、エラーも削減できます。

実装上の課題を克服する
私は常々、相互運用性は80%が政治的な問題であり、技術的な問題はわずか20%にすぎないと述べています。言い換えれば、最大の障害となるのは、多くの場合、病院スタッフ間でステークホルダー、ワークフロー、インセンティブの足並みをそろえることです。医療機器メーカーが一般的に直面する実装上の課題と、その対処方法を以下に示します。
- HL7のレガシー:ハイブリッド環境の必要性:病院がHL7を一夜にして廃止することはありません。大半の病院ではハイブリッド構成で運用されます。つまり、HL7 v2が引き続きレガシーのデータフィードを支える一方で、最新のユースケースにはFHIR APIが導入されていきます。今からFHIRを中心に機器を設計することで、移行期間中は引き続きHL7との橋渡しを行いつつ、将来にも対応できる体制を整えることができます。FHIRの適用範囲は、年々、また規制の進展に伴って拡大しています(その間のギャップを埋めるため、多くの病院ではミドルウェアが使用されています)。柔軟な統合レイヤーを設計することで、現在の価値を提供しながら、将来的なFHIRへの全面移行にも対応できる体制を整えることができます
- 標準の断片化:FHIRにも、オプションの要素や地域ごとの「プロファイル」が存在します。業界では、米国のすべての認定EHRがサポートすべきUS Coreプロファイルなどの実装ガイドを通じて、この問題への対応を進めています。機器メーカーは、こうしたプロファイルに関する最新情報を把握して準拠することで、システム間の互換性を最大限に高めることができます。例えば、バイタルサインには標準化されたコードやフィールドを使用します。設定変更の柔軟性を組み込んでおくことも重要です。例えば、ある病院のAPIで機器の観察データに若干異なるコード体系が求められる場合に備えて、データフィールドをマッピングできるようにします
- 信頼のギャップとステークホルダーのインセンティブ:相互運用性の標準がどれほど堅牢であっても、その実装には病院側の協力が必要です。病院とEHRベンダーでは、優先事項が競合することがよくあります。EHRベンダーが自社の利益を守るために、高額な料金を請求したり、サードパーティとの統合に抵抗したりする情報ブロックなどの問題に留意してください。機器を統合することで、スタッフの負担が軽減され、ケアが改善し、コストが削減されることを、ケーススタディを用いて病院に示してください。政府による規制要件を受け、先進国の病院には品質および相互運用性に関する目標の達成を求める圧力がかかっています。そのため、統合を単なる技術的な作業ではなく、病院の目標達成を後押しする戦略的な取り組みとして位置付けてください
FHIR標準の今後の展望とは?
こうした課題はあるものの、今後の方向性が接続性の低下ではなく、さらなる向上に向かっていることは明らかです。年々、データ交換にAPIを使用していると報告する病院が増えており、オープン標準を採用する機器も増えています。重要なのは、先を見越して対応することです。技術的な側面と同様に、非技術的な側面についても十分に計画を立てる必要があります。つまり、病院のIT部門や臨床現場の推進役と強固なパートナーシップを築き、標準およびプライバシー/セキュリティ要件を遵守し、ユーザーからのフィードバックに基づいて改善を重ねるということです。
相互運用性を「ミッションクリティカルなインフラ」として位置付け、適切なリソースを投入し、経営陣が十分に関与すれば、効率性と患者ケアの面で大きな成果が得られます。機器メーカーとして、当初からFHIRと統合を推進することは、医療の未来に対応する準備ができていることを示します。
相互運用性戦略を実現する方法について、詳しく知りたいですか?
医療機関およびMedTech向けの相互運用性戦略:ベストプラクティス、ユースケース、ソリューション








