注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。
業界: ヘルスケア
ビジネス機能: オペレーション
契約の修正や州の規制、保険プラン固有の要件など、プロバイダーのデータを管理する作業は困難であり、ミスがあると健康保険の請求が過払いや未払いになることが多いです。これらのデータを Palantir Foundry に統合することで、自動的に修正を特定・表示し、その修正が本番システムに書き戻されるよう承認できます。
プロバイダーデータを管理する難しさは、データソースの数と複雑なビジネス固有のルールが適用されなければならないことに起因しています。契約の修正、州の規制、保険プラン固有の要件のすべてのルールが正確に実装されることを確認するためには、長時間の手作業が必要です。このプロセスでは、複数のチームがメールでやり取りし、Excel でデータを共有し、手作業で本番システムに更新を依頼・実施することがあります。
プロバイダーデータの管理方法は企業ごとに異なりますが、基本的には、プロバイダー(TIN/NPI)は、契約と州に基づいて、ある期間に適用されるコードのセットが割り当てられ、その結果、さまざまなサービスに対する支払い率が決まります。コードは、契約の修正や州の更新、プロバイダーの引退などの理由でいつでも変更されることがあります。
ミスがあると、保険請求が過払いになり、利益が減少し、プロバイダーとの摩擦が生じることがあります。また、保険請求が未払いになると、支払いが滞ることでプロバイダーとの摩擦が生じることがあります。極端な場合には、州政府が関与し、制裁が実施されることもあります。
間違った請求の支払いは、支払い側にとって大きな問題であり、支払いの正確さが1%向上するだけでも、収益やプロバイダーの満足度、サービスの全体的な品質に大きな影響を与えることがあります。
主要なデータソース(契約、州の規制、制裁など)が Palantir Foundry に統合され、統合されたデータに特定のビジネスルールが適用され、提案された修正がユーザーの審査のための運用アプリケーションに表示されます。
具体的には、プロバイダーデータアナリストは、請求量やドル額の影響が最も大きいものから順に、提案された更新のリストを表示するアプリケーションにアクセスします。提案された更新をクリックすると、提案内容とその根拠となるデータが表示され、アナリストが更新に関する判断を下すことができます。アプリケーション内でアナリストは以下の3つの判断を直接行うことができます。
提案のインターフェースは、パフォーマンス指標(承認/拒否された更新の数、影響を受けた請求、再処理を防止した請求の価値など)を表示するダッシュボードでサポートされています。
主に使用されるツールは、Code Repositories、Workshop、および Quiverです。
このワークフローの核心は、プロバイダーデータ設定の提案された修正を表示する強力なパイプラインです。データパイプラインは、各ビジネスルールの特定を考慮することが重要です。このワークフローは、表示される更新が正確であることに依存しています。
更新は、プロバイダーデータアナリストが更新提案やそれを支持するデータを審査し、それを受け入れるか拒否するかフラグするかを判断できる運用アプリケーションで表示されます。2つ目のアプリケーションでは、ユーザーが自分のパフォーマンスとビジネスへの全体的な影響を確認するためのダッシュボードが表示されます。
このユースケースは、以下のパターンを実装しています。以下のリンクをたどって特定のパターンについて詳しく読み、Foundry 内での実装方法を学びます。
このユースケースについてもっと情報が欲しいですか? 類似のものを実装したいですか? Palantir で始めましょう。