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境界線は、コンプライアンスを示すためにブロンズ/シルバー/ゴールドのデータレイヤーの周りに明確に破線で囲まれています。 構築したもの：運用ワークベンチ...