公開日12 May 2023
最小読み取り時間
Views
2020年以降、バーチャル・ ヘルスケアの需要は 38倍という驚異的な伸びを示している。この前例のない拡大は、世界中のヘルスケアメジャーに大きなチャンスと課題の両方をもたらしている。
急速な成長は、より多くの患者層へのマルチチャネル・アクセスを可能にする一方で、膨大な量の医療関連機密データの生成を引き起こし、サイバー脅威行為者の豊富な狩猟場となっている。同時に、レガシーな異種システムへの依存は、特に遠隔医療アプリケーションと医療モノのインターネット（IoMT）の台頭がデータ拡散に拍車をかけているため、統合性という課題をもたらしている。
メディケア＆メディケイドサービスセンター（CMS）と医療IT国家調整官事務所（ONC）は、進化するシナリオに対応して、現在のサイロ化されたデータシステムの除去を義務付ける政策を導入した。これらの方針は、病院、医師、支払者、 製薬 会社、医療機器・装置メーカー間のシームレスなデータ通信を可能にする試みで あり、それによって全体的な健康アウトカムの向上を促進するものである。
運用面では、新規制により医療機関（HCO）のITチームは、相互運用性を機能的なソフトウェア要件として確立することを余儀なくされている。その焦点は、関連し承認された関係者間で、患者情報を含む医療情報をシームレスかつ完全に双方向に転送することである。
このような相互運用性を実現するためには、今日の医療システムは共通のインターフェイスで通信できなければならない。しかし、医療IT分野には40を超える標準開発組織（SDO）があり、データの相互運用性と保存のために適切な標準化フォーマットを選択する苦労は、HCOにとって差し迫った問題です。そのため、データ量の急速な拡大が業界全体の不安を増大させ、クラウド導入の増加を促している。この移行は、標準的な相互運用ガイドラインに沿った合理的なデータ共有の必要性をさらに際立たせている。
2021年4月に発表された調査論文では、HCOが患者情報をどのように保存しているかが報告されている。その結果、ほとんどのHCOがデータの一元化を進めている一方で、持続可能なハイブリッド・クラウド・インフラを構成することで、将来を見据えた対策を検討しているHCOは全体の約24%に過ぎないことが明らかになりました。
図1：各ストレージソリューションを活用しているHCOの割合
ガートナーが言うように、クラウドベースのヘルスケア・データ・ストレージは、まだ始まったばかりの段階であっても、市場の破壊者として台頭しつつあります。しかし、良いニュースもあります。組織は、潜在的なサイバーセキュリティの問題に対処するために、ハイブリッドクラウドやマルチクラウドを採用することのメリットを認識しつつある。2022年には、単一のプライベート・クラウドまたはパブリック・クラウドを使用している組織は約3%に過ぎず、2019年に最高を記録した29%に比べるとはるかに低くなっている。
また、従来のモノリシックなアーキテクチャから移行し、分散型、共有型、スケーラブルなクラウドアーキテクチャを採用するHCOもメリットを享受している。主な利点の1つは、サーバー間の相互運用性を制限する硬直的なITインフラから独立できることだ。第二の利点は柔軟性である。ハイブリッド／マルチクラウド・アーキテクチャをオンデマンドで使用して医療システムを拡張し、必要に応じてクラウド・ソリューションをいくつでも導入できる自由である。
今後、インテリジェントクラウド統合、クラウド対応ホームオートメーション、自律型マルチクラウド・コンテナプラットフォームなど、クラウド革新の進歩により、HCOはより高い価値、セキュリティ、コネクティビティ機能を約束されます。
しかし、このようなシナリオは、すべての機能が統一的に分類されたデータからの洞察にアクセスできる場合にのみ可能となります。
IEEEは、相互運用性を「2つ以上のシステムまたはコンポーネントが情報を交換し、交換された情報を使用する能力」と正式に定義している。この定義により、2つの概念的なレベルが開かれる、
- 構文論的
- 意味的
構文論的相互運用性とは、システムまたはそのコンポーネント間の基本的な連結と統合を提供するデータ形式と通信の標準化である。ここでは、クロスマッピングのために共通の形式や標準を使用することによって、異種データソースを相互接続するための情報モデルを活用する。
セマンティック相互運用性は、構文的相互運用性によって交換された情報を正確に解釈し、活用するという課題に取り組むものである。ここでは、ユーザーが理解しやすく、計算可能で、拡張可能な知識表現スキームに関する課題に取り組む方法に焦点を当てる。
デジタル・アーキテクチャのマッピングには、統一された保存・アクセス形式を持つ相互運用性標準が必要です。HCOは主にHealth Level 7（HL7）のFast Healthcare Interoperability Resources（FHIR）標準に依存しており、データの読み取りと入力の双方向のデータ交換をサポートしています。FHIRはまた、よりきめ細かいデータタイプやドキュメントを可能にし、プラグアンドプレイのアプリに使用することができる。
Google Healthcare APIなどのヘルスケアAPIは、FHIRを活用してデータのマッピングと転送を行っている。ある例では、このAPIによって、大規模な薬局が運営コストを削減しながら、より深い患者エンゲージメントを実行できるようになった。
ここしばらくの間、FHIRはセマンティックな相互運用性を実現するための標準として使われてきた。しかし、「真の」データ相互運用性にはセマンティック相互運用性も必要であり、これはシステムが電子カルテ（EHR）を活用してデータの正確な意味と文脈を理解するのに役立つ。
しかし、長年にわたり、HL7 のいくつかのバージョンで、FHIR はバージョン間のセマンティック相互運用性を維持することができませんでした。
翻訳によるデータの損失を止めるために、HCOのコンソーシアムは、臨床モデルと仕様を持つドメイン主導の情報システムプラットフォームによって駆動される新しい技術を導入した。openEHRは、ドメインの専門家とIT開発者の間の橋渡しをし、各データタイプの固定された意味を確立するのに役立った。このeヘルス・テクノロジーは、ローコード・ツールによる迅速なアプリケーション開発を可能にし、同時に、あらかじめ構成されたコンポーネント指向のインターフェイスは、費用対効果の高い相互運用性を展開するのに役立った。
このことをよりよく理解するために、FHIRの主要な目的は、システム間（B2B）とシステムからアプリケーション（B2C）への結びつきを作ることにある。B2Bの部分は本質的に情報ベースのアプローチであり、B2Cの部分は最先端の医療システム・アプリケーションを促進するための基本的なニーズを満たすものである。
FHIRはより多くのAPIをカバーし、複雑なタスクのためのAPIを作成する優れた仕事をした最先端のプロジェクトである。
一方、openEHRは患者市民情報の広範なカバレッジと臨床モデル領域の重要なカバレッジを提供する。しかし、APIの互換性は限られている。
openEHRの主な目標は、オープンソースの患者管理システムの中で、耐久性があり計算可能な記録に関する課題に取り組むことである。これは長期的かつ将来を見据えた課題であり、プラットフォームアーキテクチャの原則を活用することで対処される。ここで忘れてはならないのは、openEHR自体はこのプラットフォームのいくつかの要素を提供しているに過ぎず、それ自体が適切な用語集、医薬品データベース、関連するサービスインターフェースにアクセスできなければならないということである。
ほとんどのHCOがFHIRを認識し使用している一方で、openEHRはその堅牢性と適応性で注目を集めています。業界関係者との交流を通じて、FHIRとEHRの使い方に一般的な混乱があることがわかりました。そして、それらの使い方を説明するには、クラウド採用の視点に置くのが一番だ。以下は、openEHRがクラウド環境へのスケールアップや移行を検討しているHCOのために対処できる、特定のFHIRの課題です。
最初の課題は、データモデルの堅牢性である。FHIRは特定のユースケースのためにデータをモデル化し、保存することができる。しかし、データ量が広範で複雑なカテゴリーを構成する場合、openEHRの方がより好ましい標準である。一方openEHRは、体温、血圧、心拍数を含むいくつかのパラメータに基づいて特定の状態を観察するためにあらかじめ設計されたテンプレートを備えている。
2つ目の課題は、ビジネスインテリジェンスと分析である。FHIRには、IT開発者がデータセットを探索するために使用するREST APIがデフォルトで用意されている。openEHRのAQLはネイティブのクエリー言語であり、代わりにデータを探索するためのインターフェースを提供する。しかし、これはデータに対して様々な操作を必要とするすべてのアナリティクスのユースケースでは機能しないかもしれない。
3つ目の課題は、先に少し触れたように、バージョン管理である。HL7標準の新しいバージョンは、モデル化されたデータのセマンティクスを変更しています。例えば、AllergyIntolerance リソースは "assertedData" を "recordedDate" に変更した。これは、FHIRフォーマットでデータをモデリングする際に大きな問題となる。この課題に対処するために、開発者は翻訳レイヤーを導入するか、データ全体を新しいバージョンに移行しなければならない。openEHRでは、データモデル設計は基本参照モデルを通じて変更を受け入れる。これは一般的な基本クラスと型のセットを持つ。これによりプラットフォームは、異なるユースケースで使用するための臨床アーキタイプとテンプレートをモデル化することができる。ヘルスケアITシステム開発者は、アーキタイプとテンプレートから必要なパラメータを選択して参照モデルを作成し、ソフトウェア内にモデリング環境を構築することができる。
以上の議論は、FHIRとopenEHRの両方が、クラウド環境内での効果的な相互運用性を確保する上で重要な役割を果たすという、重要な認識へと私たちを導く。クラウド上の将来を見据えたデジタル・アーキテクチャは、生産性、使いやすさ、柔軟性を大幅に向上させるために、FHIRとopenEHRの両方をマッピングする必要がある（図2）。 FHIRとopenEHRは、特定のユースケースや要件に応じてマッピングすることができる。
図2：FHIRと openEHRの 組み合わせ使用を示す基本的なデジタル・アーキテクチャ
最初の図は、アプリケーション間でサマリー情報を共有するための基本的な相互運用システムを示している。ここでは、FHIRがアプリケーションシステムの接続を支援する一方で、openEHRが複雑なデータセットのより優れた制御を可能にしている。
2番目の図は、開発者がFHIR APIの翻訳インターフェースとしてopenEHRをどのように使用できるかを示している。
3つ目の画像は、openEHRのより詳細な使い方、今回はAPIとしての使い方を示している。いくつかの使用例では、openEHR APIは複雑なデータセットを取得し、広範な相互運用性を可能にするためにFHIR APIと組み合わせて使用される。
FHIRとopenEHRの両方をクラウドアーキテクチャに展開することで、次のような主な利点が得られる：
- openEHRとFHIRの組み合わせにより、医療ITチームは、HL7標準の更新後もクラウド上のデータがそのまま維持されることを保証できる。
- 相互運用性が組み合わされているため、ITチームはデータの損失や意味の喪失を恐れることなく、さまざまなクラウド・ソリューションを使用して拡張することができる。
- EHRとFHIRが定めた標準によって、 医療 企業は患者や医師との遠隔コミュニケーションなど、クラウドが提供する機会を利用できるようになる。
これらの利点の実現は、医療記録の規模、医療機関、患者数、関連する要因によって異なる。
ここで忘れてはならないのは、医療業界は今、成熟した補完的な技術を統合することで、患者の転帰や集団の健康状態をどのように認識するかを変革できる段階にあるということだ。クラウド・コンピューティングが企業のスケーラビリティとアジリティを向上させる中、相互運用性とストレージのための強固な標準が、データの利用と保持に不可欠となっている。
