最適なタイミングで、最適なケアを。

「適切な時に適切なケア」の理念を理解する
健康プランとプロバイダーは常に、メンバーや患者に対して適切な時に適切なケアを提供するという共通の目標に基づいて活動してきました。健康プランにとっては、中長期的なコストを将来的に削減するようなサービスを承認することが多く、一方のプロバイダーは今日の患者が最善となる行動を追求することが多いです。成熟した相互運用性の時代において、「適切な時に適切なケア」は何を意味するのでしょうか？

今日、これはケアの決定を速く行うために先進的で予測的、そして規定的な分析の力を活用することを意味します。これには、事前の認証、ケアの品質、ケアの調整、またはケアの現場で行われる行動への影響などが含まれます。従来の機械学習（ML）を使用して、データサイエンスチームは、リアルタイムの病院取引を使用して、現在の患者が退院時や病院内での移動ごとに再入院のリスクが高まる可能性や敗血症を発症する可能性を予測するかもしれません。生成的AIエージェントは、医療クリニシャンが会員の医療履歴全体の表現、全ての接点のリアルタイムなやり取り、およびケアマネージャの評価と意思決定を補強するデータからのエビデンスベースの結果を活用することにより、ケア管理にある会員に対するケア計画をより適切に処方できるよう、臨床決定サポートで支援するのに役立ちます。

「適切なケアを適切なタイミングで」を実現するためには、Payer-to-Payer（CMS-9115-F、CMS-0057-F）などの相互運用性要件が、メンバーが健康計画を変更する際のケアの連続性を促進します。HL7 FHIRを使用することにより、プランはクレームや人口統計情報だけでなく、歴史的な臨床データやアクティブなケアプランも交換することができます。新しいプランでは、初日から既存のケアプランを続行するか、新しいプランに登録するかを判断するための情報を揃えることができます。さらに、新しいプランでは、新メンバー人口が算定階層条件カテゴリ、HEDIS、その他の品質スコア、現在の主治医、バリューベースの支払いイニシアチブ、ネットワーク適合性、その他の今日のメンバーに対して健康プランが作成するすべての分析にどのように影響を及ぼすかを学ぶことができます。伝統的には、これを正確に実行するためには大量のクレーム処理が必要でした。

より良いケア、負担の軽減：電子的事前認証から得られるメリット
CMS-0057電子事前認証の要求は、医療提供者と支払者との間でのコラボレーションを改善する大きな機会を提供します。幅広く採用されているEHRシステムとFHIRデータ交換基準を活用することで、医療提供者はEHRから直接サービスや薬物承認のリクエストを送信することができ、それだけでなく、健康保険の認可要件を満たすための全ての根拠となる証拠を含むことができます。

たとえば、GLP-1薬の要求は、以前に数種類の薬が処方されていても、2型糖尿病のHbA1cが大幅に減少していないことが必要かもしれません。これには、まず患者にメトフォルミンが処方され、初回処方前と後の四半期ごとのHbA1c値を尋ねる、調査のような基準フォームが必要な場合があります。これに続いて、変化がほとんどないか、または全くないことを示すスキャンまたはファクスで送った診断レポートの要求、あるいはケースのレビューを行う代わりにプロバイダーと健康計画の医療ディレクターとの直接的なやり取りの要求があるかもしれません。

このような行き来は、支払人の活用管理チームとプロバイダー間で非効率的であり、コストのかかる時間の無駄を生む。FHIRの利用により、処方箋の充填（薬局の請求）、臨床ノート、診断レポートなどを元のGLP-1薬物リクエストの追加のリソースとしてパッケージ化することで、即座に決定を下すための関連データ全てを支払人が手に入れることが可能になります。EHRから直接証拠を提供し、FHIRバンドル内のリクエストとともに提供することで、支払人は患者の真実のデータをより確定的に分析し、承認することができるようになります。これにより、伝統的な調査のような基準がビジネスルールに変わります。

このパラダイムシフトは、医療提供者の管理時間を節約し、エラーを最小限に抑え、透明性を促進し、保険会社の自動承認や大幅に短縮された承認時間を可能にする可能性があります。複雑なケースでは、保険会社はMLと生成AIを利用して、利用管理の看護師や医療ディレクターに情報を補完し、認可プロセスを個別化された患者ケアの機会に変えることが可能です。最終的には、手動レビューの減少と優れたデータと洞察により、承認の迅速化、コストの削減、管理負担の軽減、患者やメンバー、提供者の満足度向上が期待できます。

双方向データ交換：エコシステム全体でのケアの調整
これらの要件を組み合わせることで、保険会社とプロバイダーは、臨床データ交換を通じて患者のアウトカムについて協調し、調整するためのコミュニケーションチャネルを開くことができます。例えば、機械学習を使用して、保険会社はメンバーに対して健康診断や検査室への訪問を推奨したり、または新規診断の可能性や近期の不利なイベントの予防を確認するために予約を行うことができます。生成AIやAIエージェントフレームを使用して、観察結果は、MLモデルの機能からの付随情報とともにFHIRトランザクションとしてパッケージ化されることがあります。そして、FHIRバンドルは、スケジューリングのために、または価値ベースの支払い契約やイニシアチブをサポートするためのケア現場での洞察を提供するために、プロバイダーのEHRに送信されることがあります。Admit, Discharge & Transfer (ADT) トランザクションのケースでは、この双方向のチャンスはリアルタイムに近い形で患者の結果を改善することができます。

あなたのデータプラットフォームは追いついていますか？
支払い者と提供者のパートナーシップを有効にするために必要なデータは、多くの異なるソースとシステムから来ており、異なる形式で存在します。これは単一の組織内だけでなく、異なる形式の異なるデータを多くの組織間で交換するとき、この複雑さは指数関数的に増大します。

真に、全ての医療組織がデータを素早く交換する能力は、より良い患者結果、予防ケア、そしてそれによるコスト削減の道を開きます。しかし、FHIRで送信されたデータを生成、摂取、解析、および他の潜在的に必要なデータに結合することは依然として課題であるかもしれません。堅牢なペイヤーとプロバイダー間のパートナーシップに参加する主な障害は、ペイヤーのIT組織の中核を成す旧式でしばしば孤立したデータインフラストラクチャです。多くの中核の管理システムはまだオンプレミスであり、より機動性のあるクラウドベースのデータと分析環境にデータを中心化またはスケーリングすることができません。これらのシステムはまた、他のデータタイプと必ずしも相互運用性があるわけではないか、相互運用性のある標準や交換プロトコルをサポートする専有データ構造を利用しています。

FHIR形式の拡張性は、それがすべての臨床データ交換のスーパーセットとして機能することを意味し、これらの組織のそれぞれが一つのデータ形式に変換し、標準化することを可能にします。FHIRバンドルに含める可能性のあるすべてのリソースタイプを成功裏に生成するためには、組織はすべての要素を統合するための良好に管理され、中心化されたレイクハウスアーキテクチャが必要です。これは、臨床判断を下す者が指先で交換される最新の臨床データを持つためには、リアルタイムに近い更新が必要ということを意味します。FHIRの摂取と解析は、アプリケーションで使用するだけでなく、分析および機械学習のためにすぐに利用可能である必要があります。組織間での取引には優れていますが、FHIR形式は、その原形で使用することがアナリストやデータサイエンティストにとって大きな課題となります。

この相互運用性がどのように機能するかの例
FHIRはリソースタイプの形で臨床データの交換のための多くの概念を標準化しますが、どのリソースタイプの要素を一貫して使用する必要があるか、またそれらをどのように解釈すべきかについては開放したままです。例えば、拡張性と柔軟性を達成するために、多くのリソースタイプには、関連性のあるが、リソースタイプ自体では正式にモデル化されていない追加のデータを含めることを可能にする「拡張」要素が含まれています。"拡張"要素には、一貫したスキーマのない深くネストされたデータポイントを許容するために、自身が拡張を含むこともあります。しばしば、これらの拡張には、NCQAの報告に必要な出生時の性別、ジェンダー、人種、または民族などの重要な情報が含まれることがあります。さらに、バンドルの種類やそれを生成する組織により、バンドルに含まれるリソースタイプの順序や数が異なる可能性があります。これらのことを合わせると、標準的な「スキーマ・オン・リード」方法は1つ以上のFHIR JSONファイルには適用できません。なぜなら、それぞれが独自のユニークなスキーマを提示するからです。臨床データの源は多岐にわたり、既存のエンタープライズデータとの統合には課題があります。これらの課題は、組織間でのユニークな人物識別子の変動や、不完全さや、様々なシステム間での情報表現の異なりにより、重複したデータエントリーが異なるものとして見えることで生じます。例えば、あるシステムではSNOMEDを使用し、別のシステムではICD-10を使用して診断を行うなどの場合です。これらの問題のため、多くの組織は、上記のような分析利用事例を行うために、自身の臨床データの力を引き出すことに苦労しています。

アバカスプラットフォームアーキテクチャ

CMS-0057-Fの期限前にペイヤーデータ基盤を近代化する
Abacus InsightsはDatabricksと提携して、相互運用性をスケールでサポートするモダンでクラウドベースのペイヤーデータ管理プラットフォームを提供することで、独特のペイヤーデータの課題に対処します。Abacusのペイヤーデータの利用可能なデータ基盤は、ペイヤーがCMS Interoperability and Prior Authorization要件を完全に満たすことを支援し、コンプライアンスを超えた戦略的なビジネス価値を解放します。Abacusプラットフォームを使用すると、CMS-0057 APIの運用化に必要な主要な臨床および管理データを調整、変換、目的化して、コンプライアンスを超えたビジネス用件 - 品質管理、リスク調整パフォーマンス、財務報告および調整、集団保健/価値ベースのケア分析などを可能にすることができます。

Abacusのミッションは、データのシロを解放し、ペイヤーとプロバイダー組織間でリアルタイムでの協働を可能にすることです。これはCMS-0057-F要件の要求を補完するものです。我々のクラウドベースのデータプラットフォームは、データをそれらの中心管理システムからクラウドに移行し、異なるデータ構造をシ－スケ－スニュ－ト―ルな方法で統一して、ペイヤ－が任意のシ－スケ－スで単一のデータ撮影を使用できるようにすることが可能です。コアとなるのは、ペイヤーのコアインフラストラクチャ内だけでなく、その外部のインサイトシステムやプロバイダーパートナーとの間での多くの異なるシステムの統合です。これらの能力は、今日コンプライアンスを支援し、明日競争力あるイノベーションを可能にする未来を見すえたデータ基盤を創出します。— ヴィニー・トゥミネロ, AVP, ソリューションストラテジー CMS Interoperability, Abacus Insights

Databricksでよく尋ねられることは、高度な分析とAIアプリケーションに必要な分散データソースすべてをどのように摂取し統合するかだけでなく、そのデータをどのようにモデル化するかについてです。AbacusとそのユニークなDatabricksに構築されたソリューションを考えるとき、それはペイヤ－の分析者やデータサイエンティストが臨床データ利用ケースの取り組みを始めるために必要な、85%以上を統合する良好に設計され、メンテナンスされたレイクハウスから一気にスタートすることについてです。それは時間価値についてであり、DatabricksアカウントでAbacusをデプロイするとき、全てのデータとAI資産のための一元化されたガバナンスとセキュリティ、Unity Catalogが得られます。臨床データがあなたのテナントから出ることはありません。— マシュー・ギリア, ソリューションアーキテクト, Databricks

CMSの相互運用性の遵守を戦略的なビジネスアドバンテージに変える
CMS-0057-Fの相互運用性と事前認証の要請の施行日である2027年1月を見るとき、問題は単純に遵守一部ではありません。支払者がCMSのコンプライアンスによって促進される行動への呼びかけの瞬間を捉え、インフラを近代化して、支払者と提供者間の調整ギャップを埋めるより多くのリアルタイムの運用および分析のユースケースを可能にするでしょうか？それとも、これはもう1つの患者アクセス（CMS-9115-F）経験になるのでしょうか - 長期的な実装のタイムライン、最小限の採用、そしてCMSコンプライアンスを超えたビジネス価値が限られている。

我々の使命は、支払者に対する遵守を確認するだけでなく、データの基盤を近代化することを促進し、データから更なる価値を引き出すことを可能にすることです。共に、我々は成果と経験に戦略的に焦点を当ててケアの急速に上昇するコストに対応するビジネスユースケースを可能にするのを支援します。

Databricks上のAbacusが相互運用性の利用モデルをどのように加速させるかを確認するために、お気軽にお問い合わせください。