FHIR を基盤とした医療システムの相互運用性を Google Cloud で向上

※この投稿は米国時間 2021 年 9 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

相互運用の重要性

2020 年、医療機関のシステムは COVID-19（新型コロナウイルス感染症）への対応に追われていました。患者の流入に備える臨床医だけでなく、インフラストラクチャ チームと分析チームも、わかりにくい電子医療記録（EHR）システムを使いこなそうとしていました。これらの EHR は、デフォルトでは相互運用性がなく、互いに通信できません。よって、「管轄のすべての医療機関に COVID-19 の患者が何人いるか」という比較的簡単な質問に答えるにも、多くの個別調査が必要となる場合があります。

一般的に、データセットが複雑になるほど、これを基に相互運用可能なシステムを構築するのがより難しくなります。臨床データはきわめて複雑であり（1 人の患者に多くの診断記録、治療記録、通院記録、医療提供者、処方箋などが紐づけられています）、EHR ベンダーは、これらのデータの課題に対処するために独自のデータモデルを構築、管理しています。このため、患者が医療機関を変更すると、医療機関が患者の経過を追跡することが（たとえ同じ医療機関システム内であっても）はるかに困難になり、複数の医療機関システムが全国的な流行病（COVID-19 やオピオイド乱用など）の治療に際して連携を取ることが特に困難となります。このため、患者にとっては治療の効果が低下し、医療機関にとっては費用が上昇します。

相互運用性の大幅な向上

相互運用可能なシステムの構築には、以下が必要です。

• （1）共通のデータスキーマ

• （2）医療機関が保有する煩雑な実際のデータを共通のデータスキーマに取り込むための仕組み

• （3）その共通データスキーマに対して問い合わせを行うための仕組み

2011 年には、共通の Fast Healthcare Interoperability Resources（FHIR）データモデルと API 規格によって、業界が同じデータ言語を使用するための単一のデータスキーマという（1）の解決策が提示されました。この 18 か月の間に、Google Cloud は FHIR の力を生かし、（2）と（3）を実現するために以下のテクノロジーを活用しました。

• Google Cloud の Healthcare Data Engine（HDE）は、ストリーミング形式の臨床データ（EHR システムからの HL7v2 メッセージまたは EDW からのレガシー フォーマット）から FHIR レコードを生成します。このテクノロジーにより、Google BigQuery（BQ）で他の用途と分析にデータを利用できるようになりました。

• Google Cloud の Looker を使用すると、医療機関の誰もが Google BigQuery で複雑な FHIR スキーマに対してあらゆる問い合わせを行えます。

今では、医療機関のシステムで複数の EHR システムの記録を一度に参照して、素早く問い合わせと回答を行うことができます。

これまでに確認した実用例

GCP では、18 か月足らずで HDE、BigQuery、Looker が連携して臨床の成果を向上させるための多くの実用例を確認しています。これまでに特に成功している複数の実用例では、以下の問に対する答えが得られています。

• ある医療機関において 30 日間で何件の再入院が想定されるか。

• 各入院患者は、どのくらいの期間、入院するのか。

• 医療機関が患者にオピオイド薬を処方する際に、不正使用と運用上の課題をどのように追跡すればよいか。

• 利用する医療機関のシステムで、医療機関が患者の生命徴候の異常を迅速に把握するにはどうすればよいか。

• 勤務している医療機関で、どのようにして院内感染（CLABSI など）を特定し、これを最小限に抑えることができるか。

• 医療機関は、どのようにして医療機関システム全体で COVID-19 患者への対応に備えることができるか。また、どのように仮説に基づく計画を活用して最悪の事態に備えられるか。

これらのユースケースは、臨床医と医療機関の日常業務を改善するために考えられることのほんの一部にすぎません。

相互運用における主要課題を解決する

レイテンシ: 医療機関では、最新ではない週次報告書から分析結果を得ることがよくあります。ほぼリアルタイムで分析結果を受け取ることで、医療機関ははるかに迅速に問題を特定し、対応を改善できます。COVID-19 の流行によって、分析結果がより速いペースで得られることが特に重要であることがわかりました。GCP の Healthcare Data Engine は、HL7 メッセージの形式でストリーミング臨床データを処理します。メッセージが到着するとすぐに FHIR に変換され、BigQuery データベースに送信されて、照会可能となります。ユーザーは、最小限のレイテンシで、ほぼリアルタイムにデータを照会できます。

規模: 医療機関がより多くの臨床事例を追跡したり、より大きなシステムに統合されるにつれて、医療機関のデータの規模と範囲が急速に拡大しています。医療機関は、医療機関システムのデータセットの増加に伴い、何百万件もの臨床記録を取り込むために必要な大量の計算を処理できるよう自律的に拡張するクラウドベースのシステムの採用を進めています。GCP のサーバーレスのマネージド クラウドは、多くの医療機関システムが現在抱いているこうした要望に応えています。

複数の臨床的定義を管理する: 現在、医療機関は、複雑な臨床 KPI の定義の管理に苦労しています。たとえば、COVID-19 の陽性判定について、医療機関は（頻繁に変化する実験結果と症状に基づき）多様な定義を定めていたため、分析に不整合が生じていました。また、これらの定義は、多くの場合、調整や変更が難しいスクリプトに埋め込まれています。HDE は、HL7 メッセージをスケーラブルな方式で FHIR ストアに一貫して変換する機能を開発しました。また Looker は、オブジェクト指向でバージョン管理されたセマンティック レイヤで信頼できる唯一の情報源を提供し、臨床 KPI を定義して迅速に更新します。

FHIR をリレーショナルに表現する: FHIR はもともと、スキーマの柔軟性を最大限に引き出すために XML ストレージを想定して策定されました。しかしながら、この形式は通常、リレーショナル データセットを使用した方がパフォーマンスが良い分析クエリには非常に扱いにくいものです。特に、FHIR には、1 件のレコード内に埋もれている（つまり「ネスト」されている）データ行があり（たとえば、1 件の患者レコードには、診断に関する多くの Key-Value ペアがあります）、FHIR に対して問い合わせを行うことが困難となっています。BigQuery は、この「ネスト」構造の FHIR データをネイティブに保存し、これに対してクエリを実行することで、OLAP データベースの分析力と No-SQL データスキーマの柔軟性を組み合わせた分析データベースです。

FHIR に対し迅速にクエリを実行する: FHIR のような複雑なスキーマにネストされていないクエリを記述するのは困難な場合があります。GCP の Looker ソリューションは、BigQuery にネイティブに「ネストされた」クエリを記述するため、新しい問い合わせを行ったりこれに回答するのがはるかに簡単になります。これにより、医療機関が質問に答えるために何百もの簡略化されたデータキューブを構築、管理、維持しなければならないという、医療業界でよく見られる「キューブ - 抽出」問題も防止できます。

臨床転帰を予測する: AI / ML ワークフローによる予測モデリングがかなり成熟しています。医療機関では、患者と医療提供者にとってより良い転帰がもたらされるよう、AI / ML の利用が進んでいます。たとえば、医療機関のシステム全体で 30 日後の患者数、スタッフ数、人工呼吸器の台数を予測することで、治療の中断を最小限に抑えることができます。GCP で FHIR を活用することで、GCP のマネージド AI / ML ツールのフルパッケージ、特に BQML（BigQuery Machine Learning）と AutoML が利用できます。

24 時間 365 日データ可用性を保証する: COVID-19 によって、スタッフが常駐するオンプレミスのデータセンターに依存することの脆弱性が明らかになりましたが、GCP のクラウド インフラストラクチャを利用することで、すべての臨床データの可用性とセキュリティを確保できます。

患者データを保護する: 相互運用の実現には、患者の個人情報を保護することと、医療機関間でデータを共有させることの両立が求められます。特に研究者には、臨床データにアクセスするために細かいセキュリティ ルールが往々にして求められます。現在、医療機関では、データベースの外にデータのコピーを多数必要とする抽出ベースの手法がよく使われていますが、これはセキュリティ上の欠点となる可能性があります。GCP の手法では、医療機関がデータの保存場所、つまり安全なデータ ウェアハウスでデータを照会できます。また、GCP の FHIR ソリューションの各コンポーネント（HDE、BQ、Looker）は、HIPAA に遵守するように構成でき、行レベル、列レベル、フィールド レベルのセキュリティ機能が備わっています。ユーザーは、この機能を設定することで、PHI データに対するセルレベルの制御が可能になります。また、GCP の Cloud Loss Prevention API は、データを自動的に匿名化します。

より迅速に分析情報を入手する: データが複雑なため、分析パイプラインの構築に時間がかかり、医療の改善が遅れることがあります。GCP の FHIR ソリューションは、比較的少ない労力で導入できます。HDE は、ストリーミング HL7 メッセージに対して数か月、数年ではなく、数日、数週間で構築できます。Looker にはあらかじめ構築された FHIR ブロック（Looker Blocks Directory と Marketplace に近日公開予定）があり、医療機関の特定のデータニーズに合わせてインストール、構成できます。

分析情報を広く共有する: 相互運用性を確保するには、複数のシステムにまたがってクエリを実行できるだけでなく、得られた分析情報を複数のプラットフォームで共有する必要もあります。GCP の FHIR ソリューションでは、医療機関システムが FHIR 上で管理されている結果を分析してから、これを Looker のダッシュボード、他の BI ツール、組み込みアプリケーション、モバイル アプリなど、どこにでも送信できます。たとえば、National Response Portal では、医療機関やその他の組織が集約された医療データを共有し、COVID-19 に関する全国的な分析情報を得ることができます。

GCP の Healthcare Data Engine を Azure や AWS のソリューションと比較した技術レビューについては、こちらとこちらをご覧ください。

ニュー フロンティア

この Google Cloud の新しい医療データスタックは、医療業界における相互運用性の実現に向けた大きな一歩となります。医療機関同士のコミュニケーションが容易になり、複雑な分析をより簡単に行えるようになれば、すべての人が助かります。患者はより良い医療的成果を得ることができ、医療機関はより効率的に医療を提供できます。

Google Cloud は、医療業界における最も困難な問題を解決するために、国内最大の医療機関システムと今後も提携を続けることを約束します。それが患者の命を救うことにつながります。