FHIR の HEDIS スコアで患者ケアの質を向上
Google Cloud Japan Team
※この投稿は米国時間 2022 年 12 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。
メディケア / メディケイド市場に精通していれば、HEDIS（Health Effectiveness Data and Information Set）スコアという言葉を耳にしたことがあるでしょう。これは、国家品質保証委員会（NCQA）で策定された標準で、保険プランの補償範囲、医療ケアへのアクセス、医療機関から提供されるサービスの有効性と利用率を評価することによって、メディケア プランとメディケイド プランの品質を採点します。このスコアは、医療機関や医療制度の補償を促進するだけでなく、医療制度に加入している潜在的会員に保険プランの魅力を伝えるうえでも役立ちます。これは（控えめに言っても）非常に重要です。
医療機関や保険者にとって HEDIS スコアが意味するものとは何でしょうか。医療ケアのギャップを特定して解消するための医師の共同作業や患者の関与が高まります。これにより、医療機関と保険者間のデータ共有と相互運用性に関するニーズに大きな注目が集まります。保険者には、患者が可能な限り質の高いケアが受けられるように、ケアギャップの特定を支援し、その知見を医療機関に提供する責任があります。
これですべてでしょうか。患者が診察室や施設内で医師の前で過ごす時間は限られています。この短いやり取りの中で、保険者がいかにうまく、いかにすばやく医師に知見と機会を提供できるかによって、患者ケアの質の向上とその結果の HEDIS スコアに大きな差が出ます。保険者と医療機関の間でデータと情報をすばやく効果的に交換、分析、要約する能力が不可欠です。
医療ケアの質を向上させるためのデータの使用
多くの場合、かかりつけ医と継続的な関係や履歴を築くことによって、よりパーソナライズされた医療ケアを受けられる可能性は高まります。ただし、ケアギャップに関して言えば、患者の病歴を知ることだけではありません。ケアギャップとは、提供された医療ケアとサービスを比較した結果であり、スクリーニングとテストの結果であり、患者のこれまでの請求データや医療記録に基づく治療の提案です。通常の診療中に、この情報のすべてをすばやく発見、比較、要約し、それをパーソナライズされたケアギャップ提案に変換するのは容易なことではありません。Google Cloud、Exafluence（EXF）、および MongoDB は、これまでよりはるかに効率的、効果的、かつ簡単にケアギャップを特定して解消するために連携してきました。
医療機関は、SMART-on-FHIR のシームレスなユーザー エクスペリエンスのメリットを享受できます。SMART-on-FHIR は、保険者とのシームレスで安全なデータ交換を通じて、より良いケアがより短い時間で提供されるように支援しながら、医療記録をすぐに使えるケアギャップと提案に変換します。
Google Cloud 上の SMART-on-FHIR アプリケーションを使用すれば、医療機関は、患者の外来診療中に Healthcare Data Engine（HDE）から患者の医療記録を安全かつ確実に受け取れます。
医療機関が患者の医療記録からの重要なデータや知見を保険者と共有すると、すぐに保険者にケアギャをリクエストできるようになります。
保険者は、医療機関からケアギャップ リクエストを受け取り、患者の医療記録、保険プランの補償範囲、治療経路を組み合わせた豊富なデータセットを活用して、ケアギャップをリアルタイムで特定し、それを診察中に医療機関に戻せます。
医療機関は、ケアギャップ提案を取り込むことによって患者にパーソナライズされた、知見に富んだ医療ケアを提供できるため、医療ケアの質の向上と HEDIS スコアの上昇の両方を実現できます。
医療機関は、保険者とリアルタイムで対話して情報を交換し、患者や住民のパーソナライズされたケアギャップの情報を得られる。
ケアギャップの算出に対する Google のアプローチとそれを医療ケアの時点で臨床医が入手できるようにする方法
1. ケアギャップを算出するためのデータソースを特定する
ケアギャップ提案が過去の請求データだけから抽出された場合は、正確で時宜を得ているとは言えません。正確なケアギャップ提案を算出するためには、過去の請求データに加えて、患者の現在の臨床データへのアクセスが重要です。医療機関と医療システムは、Google Cloud の Healthcare Data Engine（HDE）を使用して、異種の医療システムからの臨床データを集約し、長期に及ぶ患者記録を作成します。HDE のデータには、明確に定義された REST API を通して、標準準拠の HL7 FHIR 形式でアクセスできます。多くの医療制度が、請求データ、補償データ、メンバーシップ データを保存して管理するために MongoDB Atlas を実装しています。EXF Care-Gap サービスは、MongoDB Atlas データベースの医療制度データを利用して、HDE でホストされる臨床データに基づいてケアギャップ提案を算出します。
2. ケアギャップを算出するためのルールを定義して実装する
EXF Care-Gap サービスは、ほぼリアルタイムでケアギャップ提案を算出し、それを MongoDB Atlas データベースに FHIR リソースとして保存します。Care-Gap サービスは、MongoDB Atlas データベースに保存された集約済みのデータセットと HDE から提供された臨床データに構成可能なルールを適用することによって、ケアギャップ提案を算出します。
3. REST API と SMART-on-FHIR アプリを通してケアギャップを提供する
ケアの時点で使用される臨床システムが SMART-on-FHIR 準拠アプリを起動します。このアプリは、EXF FHIR サーバーからケアギャップ提案を受け取って、それを臨床医に提示します。また、HDE から Apigee HealthAPIx を通じて患者の現在の臨床情報を取得し、それを EXF FHIR サーバーに送信して、Care-Gap サービスからケアギャップ提案を FHIR 形式で受け取ります。
Google Cloud はケアギャップ提案の算出にどのように役立っているか
Apigee HealthAPIx と SMART-on-FHIR
Apigee HealthAPIx は、FHIR®（Fast Healthcare Interoperability Resources）や SMART®（SMART Substitutable Medical Applications and Reusable Technologies）などの標準を通して医療における相互運用性を高めるためのオープンソース ソリューションです。これは、Apigee Edge 上で動作し、Google Cloud の HDE をバックエンドとして使用します。
HealthAPIx ソリューションの主な目的は、医療機関で API プログラムを使用できるようにして、医療データへの API レベルのアクセスを提供することです。HealthAPIx ソリューションには、CMS から発行された相互運用性と患者アクセスに関する最終規則（CMS-9115-F）を満たす既製の相互運用可能な API が付属しています。これを使用すれば、保険者、医療機関、テクノロジー ベンダーは、米国保健福祉省（HHS）国家医療 IT 調整室（ONC）によってまとめられた 21st Century Cures Act（21 世紀の治療に関する法律）に基づいて定義された規制要件とコンプライアンス要件を満たせます。
Apigee HealthAPIx を使用すれば、医療機関と医療システムは次のことが可能になります。
FHIR サーバーに依存しないエンタープライズ クラスのプラットフォームで API を管理、保護、スケール
イノベーションのギャップを迅速に埋め、デジタルの進歩に追随する
組織内、組織外、またはオープンソースの FHIR 対応パートナーからの医療データを簡単に取り込む
Google Cloud Healthcare Data Engine
HDE は、異種の医療システムから臨床データを集約して、相互運用可能な長期に及ぶ患者記録を作成します。HDE は、HL7v2 メッセージ、CSV 形式のフラット ファイル、および FHIR 形式のフラット ファイルからデータを取り込んでマッピングできます。また、バッチと準リアルタイムでのデータの取り込みをサポートします。HDE は、FHIR R4 形式に取り込まれたデータを整合および調整して、フラット化し、BigQuery に保存します。HDE 内の患者の長期に及ぶ医療記録には、トランザクション処理用 FHIR 形式ペイロードを使用して REST API でアクセスできます。同じデータに、分析処理のために BigQuery から SQL フレンドリーなインターフェースを通してアクセスすることもできます。HDE には Google Cloud のセキュリティとプライバシーを拡張する医療用のクラウド構成が組み込まれていて、HIPAA と HITRUST のベスト プラクティスをサポートします。HDE は、Google の Cloud Healthcare API や BigQuery など、Google Cloud の高度にスケーラブルで安全な HIPAA 準拠のマネージド サービスを利用しています。
Apigee X の EXF プロキシを使用した EXF FHIR
FHIR API の管理、保護、スケールに関して言えば、FHIR に依存しないエンタープライズ クラスのプラットフォームは（推奨と言うより）不可欠です。
最も基本的な形式の FHIR サーバーは、受信リクエストを受け取り、基礎となるデータソースとの間で、標準化された FHIR リソースを使用して REST ベースの API 経由でデータを処理、取得、および交換します。これは、データ交換とデータ形式の標準化に関する最も低いレベルのデータ処理を行って、FHIR 指令に対する遵守の維持を可能にする責任を担います。
外部の世界への FHIR API の提供に関して言えば、セキュリティ、スケール、およびパフォーマンスが必須です。API ゲートウェイは必需品で、バックエンド FHIR API と、それとやり取りする外部クライアントの間に設置されます。Google の Apigee X は、医療 IT デリバリー チームによる FHIR API の安全かつ保護された、効率的なデプロイと管理を容易にし、本番環境レベルのソリューションと API ベースのデジタル サービスを使用した迅速な市場開拓を可能にします。
EXF FHIR サーバーは、FHIR API を新しい MongoDB デプロイメントとペア化するのか、既存の MongoDB デプロイメントとペア化するのかを選択できる、前例のない柔軟性を備えています。Community-Server から、Enterprise Advanced、MongoDB Atlas までの MongoDB のすべての選択肢がサポートされます。クラウド、オンプレミス、ハイブリッド モードのどこにでもデプロイできる柔軟性を備えることで、組織が満たさなければならないあらゆる要件に対応する構成を提供することもできます。新しいまたは既存の MongoDB デプロイメントを利用することによって、EXF FHIR サーバーは、複雑さを低減し、既存の組織のデータセットやソースとより迅速に統合できるように支援します。
EXF Care-Gap サービス
医療機関の FHIR リソースからのデータと一緒に既存のプラン、補償範囲、および治療に関するデータを結合、拡充、および集約することによって、EXF Care-Gap サービスは、リアルタイムですぐに使えるケアギャップに関する知見を提供できます。また、既存のデータをマッピングして FHIR ネイティブな形式に変換することで、医療機関が FHIR ベースの最新のアプリケーションを既存のレガシーソースから市場に投入できるように支援することもできます。
Exafluence チームと MongoDB チームは、医療機関と協力して、Care-Gap サービスの実装を定義、計画、および実行します。
FHIR 用の MongoDB
MongoDB は、JSON ベースのドキュメント モデルを実装するドキュメント ベースのデータベースであるため、FHIR リソースのすべてを保存するのに最適です。FHIR リソースは、MongoDB 内にネイティブ形式で保存できるため、スキーマ定義を変更する必要がありません。これにより、アプリケーション配信が高速化され、データ アーキテクチャ戦略全体が簡略化され、FHIR を API をサポートするデータモデルとしてだけでなく、組織で移行可能な新しい正規モデルとしても機能させることができます。また、ドキュメント モデルの拡張性と柔軟性によって FHIR リソースを拡張できるので、ネイティブな FHIR を利用し、組織固有の要件をサポートするために必要な情報を追加できます。
多くの COTS FHIR ソリューションとは異なり、基礎となるデータストアとして MongoDB を使用すれば、技術スタックで必要なデータベースの数を減らせます。通常、FHIR サーバーは、基礎となるデータベースと、FHIR スキーマとは異なるリレーショナル スキーマと一緒に出荷されます。これらの COTS ソリューションの多くが、基礎となるデータベース プラットフォームの変更を許可しておらず、さらに悪いことに、基礎となるデータベースへの直接アクセスを提供していません。MongoDB では、医療機関は、単に外部の FHIR API を提供するだけでなく、FHIR コレクションでそれ以上のことを行えるようにすべきであると考えます。基礎となるデータベースと MongoDB ドキュメント モデルに直接アクセスすると、組織は、ドメイン ドリブン設計の原則へのモダナイズや、FHIR API ニーズへの対処、また、必要な新しいアプリケーションまたはサービスを 1 つの共通データレイヤーから構築できる新しいオペレーショナル データレイヤーを作成することができます。MongoDB と FHIR のオペレーショナル データレイヤーとしての使用に関する詳細は、ここをクリックして、オペレーショナル データレイヤーの実装をお読みください。
よりシームレスで相互運用可能な未来の構築
医療ケアに臨む臨床医がケアギャップにアクセスできるようにするアプローチは、仕様の実装にどのようなテクノロジーが使われていようと、医療制度や医療機関が FHIR や SMART-on-FHIR などの相互運用性標準を利用して重要な医療情報をリアルタイムで交換できることを示す一例です。この例では、医療機関と医療システムは HDE と HealthAPIx 内の Google の FHIR 実装を使用し、一方、医療制度は主要な医療情報をリアルタイムで交換するために EXF と MongoDB からの FHIR 実装を利用します。
このブログ投稿で紹介したソリューションは、医療機関と医療制度が、多くのメディケア奨励金とともに、行政機関からより高いスコアと評価が得られるように支援し、医療機関がパーソナライズされた、状況に応じたケアを提供して、患者の転帰を改善できるようにします。
Google は、医療機関と提携して、医療機関と保険者間のシームレスかつ迅速で安全な情報交換を実現する、相互運用可能で標準に準拠した基盤を構築する取り組みを続けます。
参考資料
GitHub - cqframework/cql-execution: CQL を実行するための JavaScript フレームワーク
GitHub - cqframework/cql-exec-fhir: JavaScript CQL Execution プロジェクト用の FHIR データソース
GitHub - google/medical_claims_tools: バルク FHIR データ（現時点では特に FHIR BCDA 請求）を操作するためのサンプル、ライブラリ、およびツール
- MongoDB 業界別ソリューション、プリンシパル Jeff Needham
