によって アーロン・ザボラ 、 Jonathan Thompson による投稿
医療保険プランのCFOが、いつものデータ抽出、スプレッドシート、手作業による照合を終えて月次決算を行うと、医療費率（MLR）が予想を上回り、財務実績が予算を下回っていることに気づきます。BIダッシュボードを使えば、この差異をすばやく可視化できます。しかし、「MLRが上昇している」というのは本当の答えではありません。それは問いの始まりにすぎないのです。
どの事業部門や市場がそれを引き起こしているのか？
請求コストは上昇しているのか？上昇している場合、それは利用率、単価、あるいはサービス構成の どれに起因するのか？
グループや製品の値付けに誤りがあったのか？
対象集団の罹患率が変化したのか？
そして、どのような是正措置を講じることができるのか？
保険者（ペイヤー）財務におけるAIの真の価値は、差異を特定することではありません。何がその差異を引き起こしたのかを理解し、それに対してどう対処すべきかを明らかにすることにあります。
財務におけるAIトランスフォーメーションは、3つの変化を同時にもたらします。まず、レポート作成サイクルを待つことなく、数分で回答が得られるようになります。リーダーは、定型レポートに頼ったりアナリストを待ったりすることなく、自ら詳細を掘り下げて確認（ダブルクリック）できます。さらに、AIは請求データ、収益、加入者数だけでなく、臨床情報、品質評価指標、リスクスコアまで視野を広げ、これらすべてを同時に読み解いて差異の要因を評価できます。
データと業務知識の双方がサイロ化されていた時代には、このような作業は到底実用的ではありませんでした。そのため、財務部門がAIのインサイトを信頼して行動に移せるほど、AIが医療保険プランのデータやビジネスを十分に理解できるかどうかが課題となります。
そこで、DatabricksとAbacusが力を発揮します。Databricksは、ガバナンスの効いた企業データと新しい方法で対話できるようにするデータおよびAI機能を提供します。Abacusは、医療財務に関する問いに対してこれらの機能が必要とする、保険者特 有 of データ基盤、ビジネスコンテキスト、および業務知識を提供します。
長年にわたり、ビジネスインテリジェンスは「誰かが尋ねたいであろう質問」を予測することで機能してきました。チームはレポートを作成し、アナリストはダッシュボードを構築しました。そしてエグゼクティブは、誰かがそのページに掲載すべきと判断した指標を確認していました。
数値が変動したとき、その理由を突き止めるには、ダッシュボードを離れ、調査を行う適切なアナリストやチームを探し、別のレポートを抽出するか、複数の記録システムを照合する必要がありました。そして、1つの答えが出るたびに、実行すべき別のレポートや、構築・維持すべき別のダッシュボードといった新たな作業が発生していました。次の問いが生まれる頃には、それらはすでに古いものになっていたのです。
チームの作業負担は増える一方で、得られる成果は減少していきました。
対話型AIは、このインタラクションモデルを一変させます。財務リーダーは、ダッシュボードに表示される設計済みの情報で立ち止まることなく、自然な言葉で質問を投げかけ、回答を得て、そこから得た知識に基づいてさらに次の質問を重ねることができます。この体験は、レポートをたどるというよりも、ビジネスの実態を調査していく感覚に近くなります。
ここで真に崩壊するのは、2つの異なる専門知識の間の障壁です。エグゼクティブはビジネスを熟知し、意思決定の権限を持っていますが、データをクエリすることはできません。一方、アナリストはデータがどこにあり、どのように構成され、どう操作するかを知っていますが、どの問いが重要であるかを常に把握しているとは限りません。AIはこの引き継ぎのプロセスを不要にします。答えを必要とする人が、自ら直接問いかけられるようになるのです。
しかし、その対話の質は、AIがその背景にあるものをどれだけ理解しているかにかかっています。
長年、データの近代化における課題は、主にアクセスに関するものでした。つまり、請求、加入者、プロバイダー、契約、臨床、財務のデータを統合し、人々が利用できるようにできるかという点です。これは引き続き不可欠ですが、AIはさらに別の要件を追加します。それには、データが何を意味しているかを理解する必要があります。
プラン加入者の医療ケアに費やされた保険料収入の割合を示す指標であるMLRを例に考えてみましょう。定義は簡単ですが、計算は困難です。請求と保険料は異なる構造とスケジュールで発生し、「医療」経費は実際には、医療請求、調剤請求とリベート、既発生未報告債務（IBNR）、支払整合性回収、リスク調整移転、プロバイダー決済など、多くの要素が積み重なったものです。さらに、これらを事業部門、市場、または製品ごとに分類する必要があり、これらのコホートを定義するには、標準機能だけでは対応できないビジネスロジックが必要になります。
このようなコンテキストがなければ、AIシステムは膨大なデータにアクセスできても、適切なインサイトを生み出すことはできません。
こうしたビジネスコンテキストの多くは、従来、さまざまな場所に分散して存在していました。
AIが財務に関する質問に高い信頼性で回答するためには、こうしたコンテキストをより明確にし、一貫性を持たせ、再利用可能にする必要があります。
だからこそ、保険者特有のデータ基盤が重要になります。医療保険プランのデータは、エグゼクティブが尋ねたい質問に合わせてきれいに整理された状態で届くわけではありません。請求、適格性、プロバイダー、契約、臨床、財務の情報は、異なるシステムから、異なるフォーマット、異なる関係性、異なるタイミングで提供されます。AIがこれらを横断して効果的に推論できるようにするには、医療保険プランの運営実態を反映する方法でデータを接続し、整理する必要があります。
Abacusは、この保険者特有の基盤を提供します。ヘルスケアデータを一貫した構造で統合し、加入者、請求、プロバイダー、契約、臨床情報、財務指標の間の関係性を理解するために必要なビジネスコンテキストを追加します。
同じ基礎データであっても、「同じ」指 標が計算する人によって異なって定義されることがよくあります。あるバージョンはCFOの月次レポートパッケージに収まり、別のバージョンはアドホックな分析リクエストに表示され、最終的に誰かがそれらを照合しなければならなくなります。AIが単独でこの問題を解決することはありません。一貫した定義がなければ、AIはその問題をさらに増幅させてしまいます。
財務リーダーにとって、問題は単なる正確性ではありません。その回答がビジネスの運営実態を反映しているという確信を持てるかどうかです。
財務、アクチュアリー、運用の各チームが一貫したパフォーマンスビューに基づいて業務を行えるようにするのと同じ定義が、AIが質問を正しく解釈するために必要なコンテキストも提供します。ゴールは単にデータが1つの場所にあることではありません。エグゼクティブが対話形式で質問しているか、アナリストが従来のレポートを作成しているかにかかわらず、データが使用されるあらゆる場所で、そのデータが何を意味するのかを一貫して理解することです。
CFOの例に戻りましょう。MLRが予算を上回っています。それはどこで起きているのか？何がそれを引き起こしているのか？どの集団、サービス、またはプロバイダーがその変化の原因となっているのか？そして、組織は次に何をすべきなのか？
それぞれの質問は、前の質問よりも多くのコンテキストを必要とします。最初の質問には財務指標と予算との比較が必要です。2番目の質問には差異の背景にある構成要素 が必要です。3番目の質問は、請求、加入者、プロバイダー、契約、ケアマネジメントのデータを横断します。4番目の質問に達する頃には、会話は財務報告から業務運営へと移行しています。
だからこそ、真の価値はKPIをより良く表示する方法にあるのではありません。エグゼクティブのシグナルから業務の詳細な掘り下げ（ダブルクリック）へとつながる一連の経路であり、財務部門がアナリストに何度も問題を差し戻して別のレポートやデータポイントを照合させることなく進められる経路です。AIは、組織が何をすべきかという判断を代替するものではありません。何かが変化したことを察知してから、行動を起こすのに十分なレベルでそれを理解するまでの距離を縮めるものです。無駄なやり取りがなくなることで、各イテレーションが迅速化され、迅速なイテレーションは意思決定そのものの価値を高めます。ケアマネジメント活動がより早く開始され、新たなトレンドがより早く価格に反映され、結果をまだ変えられる段階で是正措置が講じられるようになります。
MLRは財務と運用の交差点に位置するため有用な例ですが、その基盤となるアーキテクチャはMLRに特化したものではありません。同じように接続された保険者データとビジネスコンテキストは、支払整合性、総医療費、リスク調整、品質、プロバイダーのパフォーマンスにわたる様々な問いをサポートできます。
これにより、ヘルスプランがAI投資について考える方法が変わります。その代替策となるのは、それぞれが独自のデータ、独自の定義、独自のビジネスビューを中心に構築された、分断されたAIユースケースの集まりです。これは、ヘルスプランが長年排除しようと努めてきたものと同じ断片化であり、単にその上にAIインターフェースが載っているだけにすぎません。
共通のペイヤーインテリジェンス基盤は、異なる道を開きます。基盤となるデータとコンテキストを一度正しく整備すれば、新しい質問、ワークフロー、AIエクスペリエンスが登場したときにそれを再利用できます。
ユースケース全体でデータをすでに接続し、コンテキスト化しているヘルスプランは、新たな問いが生じたときに一歩リードしています。単一の基盤の上で、AIは1つずつではなく、複数のドメインを同時に横断して見ることができます。業績不振の原因が、アンダーライティング、ケアマネジメント、リスク調整、品質、ネットワーク、プロバイダーエンゲージメントのいずれであれ、単一の変数であることはめったにありません。重要なのはそれらの間の相互作用ですが、各ドメインが異なるチームやデータセットに分かれているため、今日においてその多面的な問いに答えることは困難です。
DatabricksとAbacusは、この課題の異なる部分を解決します。Databricksは、エンタープライズデータのガバナンスを確立し、ビジネスユーザーが自然言語で組織のデータについて質問できる対話型エクスペリエンスを含む、AIを活用した分析エクスペリエンスを構築するためのデータ＆AIプラットフォーム機能を提供します。
Abacusは、これらのエクスペリエンスが構築されるペイヤー固有の基盤を提供します。これには、標準化され接続されたヘルスケアデータ、ペイヤー固有のモデルとビジネスコンテキスト、そしてヘルスプランの財務および運用ワークフロー全体で情報がどのように移動するかについての深い理解が含まれます。
この違いは重要です。汎用プラットフォームはAIエクスペリエンスを構築するための強力な機能を提供しますが、ヘルスプランのデータには、ペイヤー環境に固有の用語、関係性、ビジネスルール、運用の複雑さが伴います。そのコンテキストを捉えることこそが、ヘルスプランのリーダーが抱える問いにそれらの機能が答えることを可能にするのです。
DatabricksとAbacusが連携することで、AIに対応したテクノロジーから、AIに対応したペイヤーデータ、そして最終的にはヘルスプランの運営実態を反映した回答へと至る道が開かれます。
ペイヤー財務にとって興味深い問いは、もはや「AIが回答を生成できるか」ではありません。「その回答が、有用で信頼できるものとなるほど十分にビジネスを理解しているか」ということです。
CFOがMLRの変動理由を尋ねたとき、テクノロジーは単にその差異を提示する以上のことを行うべきです。財務部門が基盤となるペイヤーデータを通じてその問いを掘り下げ、何が変わったのかを理解し、組織が行動を起こせるよう支援する必要があります。そのためには、インターフェースの下に、ガバナンスの効いたデータ 、共有されたビジネス上の意味、そしてペイヤー固有のコンテキストが必要です。これこそが、DatabricksとAbacusが共同で取り組んでいることです。単にヘルスプランのデータを検索しやすくするだけでなく、行動を起こす責任を持つ人々にとって、その回答をより有用なものにすることを目指しています。
9月17日9AM PTに開催されるウェビナーで、実際の動作をぜひご確認ください。お席の確保はこちらから！
(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事
ブログを購読して、最新の投稿を受信トレイにお届けします。