X12の解析を超えて：ヘルスケアの収益サイクルワークフローのギャップを埋める

月曜日の午前8時です。医療請求担当者がキューを開きます。

週末にかけて、金曜日の835レミットファイルがデータレイクに完璧に着地しました。すべての 請求調整理由コード（CARC）と プロバイダーレベル調整（PLB）コードが解析、デコード、正規化されました。ファイル内の412件の請求のうち、38件が過少支払いされています。最も古い却下に対する期限内請求のウィンドウは27日後です。

彼女は必要なすべてのデータを持っています。彼女が持っていないのは、それに基づいて行動する場所です。

代わりに、彼女は午前中を、EDIファイル内のネストされた請求およびサービスラインの詳細である2100および2110ループを手動で確認し、SQLクエリに入力し、過少支払いをスプレッドシートに貼り付け、支払い登録と照合することに費やします。却下に対して電話をかけるのに実際に時間を費やす頃には、一日の半分が終わっています。

KFFによると、保険会社は2023年にHealthCare.govでネットワーク内の請求の5件に1件を却下し、その却下の1％未満しか異議申し立てられなかったため、ほとんどの過少支払いはそのまま過少支払いのままです。

最新のヘルスケアITの現実はこうです： データの問題はほぼ解決されました。ワークフローの問題は解決されていません。

これは、ヘルスケアX12の運用上のギャップ、つまり解析エンジンのすぐ上にある欠けているレイヤーです。それを修正するために、GenpactとDatabricksは、既存のDatabricks環境内に完全に存在する統合運用ワークベンチを構築しました。PHIは安全な境界を離れることはなく、UIはデータをその場でクエリし、行レベルのセキュリティは自動的に強制されます。

請求担当者をスプレッドシートから解放し、請求の処理に戻す方法を説明します。

通常、パイプラインが停止する場所

X12は、米国ヘルスケア支払いのバックボーン（835、834、837）であり続けています。Databricksチームが作成したオープンソースの x12-edi-parser は完璧な出発点です。生のファイルを処理し、ループを理解し、正規化されたレコードをDelta Lakeに書き込みます。

しかし、それはデータアナリストをSQLクエリに導きますが、請求担当者を異議申し立てに導くわけではありません。

生のX12ファイルからReact UIまでのメダリオンパイプライン。Unity CatalogのPHI境界線は、コンプライアンスを示すためにブロンズ/シルバー/ゴールドのデータレイヤーの周りに明確に破線で囲まれています。

構築したもの：運用ワークベンチ

このギャップを埋めるために、2つのレイヤーでソリューションを構築しました。基盤となるパーサーを本番グレードの現実に拡張し、チームのために安全で直感的な運用サーフェスを構築しました。

レイヤー1：エンジンの拡張

実際のRCM（収益サイクル管理）のニーズには、標準的なオープンソースパーサーでは常に捉えられないルックアップが必要です。エンジンを拡張して以下を含めました：

• コンテキストエンロールメント（834）：エンドツーエンドのスポンサーおよび依存関係の追跡。
• デコードされた調整（835）：コードテーブルでデコードされたCASグループ/理由フィールド。これは、請求担当者が「CO-45」を見ているのと、画面に「CO-45：請求額がスケジュール料金を超えています」と表示されるのとの違いです。
• アップストリームへの貢献：コードをフォークしていません。これらのスキーマとテストの拡張機能は、オープンソースコミュニティに直接還元されます。

レイヤー2：請求担当者のデスクトップ

これは運用サーフェスです。Databricks SQLコネクタの直上に配置された安全なWebアプリケーションです。画面上のすべての数値は、Unity Catalogのゴールドビューに対するライブクエリです。 ETLシャドウコピーも同期キャッシュもありません。

ワークベンチには、RCMチームが実際に作業する方法に合わせて設計された6つのコアビューがあります。

請求の処理：

• レミットドロワー（835）：請求担当者は、請求額と支払い額のギャップを引き起こしているCARCコードを正確に確認できます。画面を離れることなく、サービスラインの詳細まで任意の請求を開き、異議申し立てまたは修正案を作成できます。
• 却下ワークベンチ：期限内請求ウィンドウは、年齢を現場で最も重要な指標にします。行は30日を超えると赤く表示されます。支払い者、CARC、またはキューでフィルタリングできます。フィルターの状態はURLにエンコードされるため、マネージャーは優先順位付けされた作業リストをSlackにきれいに貼り付けてチームに配布できます。
• エンロールメント（834）：福利厚生コーディネーターは、新しい加入者、プランの変更、および終了を一目で確認でき、レコードが失敗した場合は、問題のあるセグメントにワンクリックでドリルダウンできます。

却下ワークベンチ。30日を超えた2行が赤く表示され、年齢バッジが重要性を示し、リスクのある金額がステータスバーに表示されて即座に確認できることに注意してください。

請求CL M-4209が選択されています。ドロワーには3つのサービスラインが表示され、CO-45調整を平易な英語でデコードし、「異議申し立てドラフト/修正」アクションボタンを直接表示します。

現場の管理：

• リーダーシップダッシュボード：請求の月次合計、支払い一致率、アクティブメンバー、および未解決の却下を1つのビューで表示します。支払い者のフィードが停止した場合、その日に確認できます。
• 品質ゲート：セグメント数の不一致は、支払い者がファイル全体を拒否することを意味します。品質レイヤーは、ファイルが出荷される前に、取り込み時にこれらの不一致を検出します。
• 監査とセキュリティ：すべてのPHI開示とワークフローの状態変更が記録されます。ユーザーが緊急時のPHIアクセスを必要とする場合、システムは書面による理由を要求し、それは自動的に監査ログに記録されます。

ブレークグラスモーダルは、セキュリティロック、事前入力された理由フィールド、HIPAAコンプライアンス警告、およびアクセスを確認する前のログエントリプレビューを示しています。

展望：GenAI異議申し立てドラフト

請求担当者にデータを提供することは第一歩です。第二歩は、作業を加速することです。

このワークベンチの次のフロンティアは、Databricks Foundation Model APIを介してClaudeモデルを統合することです。すぐに、システムはCARCコードを読み取り、元の837を取得し、臨床文書を確認し、異議申し立てレターを動的に作成します。空白のページから書く代わりに、請求担当者はレビュー担当者および承認者として機能します。

独自のデータで試す

これを環境に展開することは、コードではなく設定の問題です。Databricks X12 EDIアクセラレータとシームレスに連携します。

私たちに 2週間、Unity Catalogスキーマ、およびキューにすでにある20件の却下を提供してください。今日、請求担当者がそれらの却下を処理する時間を計り、次にワークベンチで一致するコホートを処理する時間を計ってください。

あなたはデータ、ストップウォッチ、そして結論を所有します。

組織に合わせてスコープを設定するには、GenpactのNeel Shapur（[email protected]）またはDatabricksのAaron Zavoraにお問い合わせください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事