注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

医療提供者への過払い・過少払いを削減する

業種:ヘルスケア

業務機能:業務運営

契約の変更、州の規制、医療保険プラン固有の要件に対応しながら医療提供者データを管理するのは困難な作業です。ミスが発生すると、大量の医療費請求に対して過払いまたは過少払いが生じるおそれがあります。これらのデータをすべて Palantir Foundry に統合することで、修正が必要な箇所を自動的に特定して提示し、その修正を承認して本番システムに書き戻すことができます。

課題

医療提供者データの管理は、データソースの数が多く、適用しなければならない業務固有のルールが複雑なため困難です。契約の変更、州の規制、医療保険プラン固有の要件に関するすべてのルールを正確に適用するには、多くの場合、長時間の手作業が必要です。このプロセスでは、複数のチームがメールで連絡を取り合い、Excel でデータを共有し、本番システムへの更新を手動で依頼・実施することがあります。

医療提供者データの管理方法は企業によって異なりますが、基本的には、医療提供者(TIN/NPI)に対して、契約と所在する州に基づき、一定期間に適用されるコードが割り当てられます。最終的に、このコードによって各種サービスの支払い単価が決まります。コードは、契約の変更、州による更新、医療提供者の引退などにより、いつでも変更される可能性があります。

ミスが発生すると、医療費請求に対する過払いによって利益が損なわれ、支払いを回収する場合には医療提供者との摩擦が生じるおそれがあります。一方、過少払いが発生した場合も、支払い不足によって医療提供者との摩擦が生じるおそれがあります。深刻なケースでは、州政府が介入し、制裁を科すこともあります。

医療費請求に対する誤った支払いは、支払者にとって重大な問題です。支払いの正確性がわずか1%向上するだけでも、収益、医療提供者の満足度、サービス全体の品質に大きな影響を与える可能性があります。

ソリューション

主要なデータソース(契約、州の規制、制裁など)を Palantir Foundry に統合し、統合されたデータに業務固有のルールを適用します。修正案は、ユーザーが確認できるように業務用アプリケーションに提示されます。

具体的には、医療提供者データを扱う AIP Analyst が、医療費請求の件数または金額への影響が大きい順に更新案を表示するアプリケーションにアクセスします。更新案をクリックすると、提案内容と、その提案の根拠となるデータが表示され、AIP Analyst が更新について判断できます。AIP Analyst は、アプリケーション内で直接、次の3つの判断を行えます。

  • 更新を承認する: 該当する本番システムに更新を直接適用します(書き戻します)。
  • 更新を拒否する: 更新をキューから外し、今後のアルゴリズム改善に向けて拒否理由を記録します。
  • 更新にフラグを付ける: 更新を別のキューに移動します。そのキューでは、別のチームが提案の根拠となるデータを検証したり、それに応じて変更したりできます。

提案用インターフェースには、パフォーマンスメトリクス(承認・拒否された更新の件数、影響を受けた医療費請求、再処理を回避できた医療費請求の金額など)を表示するダッシュボードが付属しています。

医療提供者への過払い・過少払いを削減する

ユーザーとステークホルダー

  • ユーザー:医療提供者データを確認する AIP Analyst。通常、契約を担当する AIP Analyst と医療提供者データを担当する AIP Analyst が含まれます。
  • 窓口 / ステークホルダー:医療費請求業務担当のバイスプレジデントまたはディレクター、医療提供者データ管理担当のバイスプレジデント

効果

  • 誤った医療提供者データによる、数千万件の医療費請求への誤った支払い(過払いと過少払いの両方)を防止しました。
  • 医療提供者データの修正箇所の特定と修正の実施に必要な時間と労力を大幅に削減しました。
  • 医療提供者の満足度が向上しました。

仕組み

主に使用するツールは、Code Repositories、Workshop、Quiver です。

このワークフローの中核となるのは、医療提供者データの設定に対する修正案を提示する堅牢なパイプラインです。データパイプラインでは、各業務ルールの詳細を考慮することが不可欠です。このワークフローは、提示される更新が正確であることを前提としています。

更新は業務用アプリケーションに提示されます。医療提供者データを扱う AIP Analyst は、更新案とその根拠となるデータを確認し、承認、拒否、フラグ付けのいずれを行うかを判断できます。2個目のアプリケーションにはダッシュボードが表示され、ユーザーは自身のパフォーマンスと業務全体への影響を確認できます。

類似のユースケースを実装する

このユースケースでは、次のパターンを実装しています。以下のリンクから、各パターンの詳細と Foundry での実装方法を確認できます。

このユースケースについて詳しく知りたいですか?類似の仕組みの実装を検討していますか?Palantir ではじめる。↗