Au-delà du parsing X12 : Combler le fossé pour les flux de travail du cycle de revenus dans les soins de santé

Nous sommes lundi, 8h. Une facturière médicale ouvre sa file d'attente.

Pendant le week-end, les fichiers de remise 835 de vendredi ont atterri parfaitement dans votre data lake. Chaque code Claim Adjustment Reason Code (CARC) et chaque code Provider Level Adjustment (PLB) a été analysé, décodé et normalisé. Sur les 412 réclamations du fichier, 38 sont sous-payées. La fenêtre de dépôt dans les délais pour le plus ancien refus est dans 27 jours.

Elle a toutes les données dont elle a besoin. Ce qui lui manque, c'est un endroit pour agir.

Au lieu de cela, elle passe sa matinée à parcourir manuellement les boucles 2100 et 2110, les détails imbriqués des réclamations et des lignes de service enfouis dans chaque fichier EDI, dans une requête SQL, à coller les sous-paiements dans une feuille de calcul et à les rapprocher d'un registre de paiement. Au moment où elle décroche son téléphone pour contester un refus, la moitié de sa journée est terminée.

Selon KFF, les assureurs ont refusé 1 réclamation sur 5 en réseau sur HealthCare.gov en 2023, et moins de 1 % de ces refus ont été contestés, ce qui signifie que la plupart des sous-paiements restent simplement sous-payés.

La réalité de l'informatique moderne des soins de santé est la suivante : le problème des données est largement résolu. Le problème des flux de travail ne l'est pas.

C'est là le manque opérationnel dans X12 pour les soins de santé, la couche manquante juste au-dessus du moteur d'analyse. Pour y remédier, Genpact et Databricks ont construit un atelier opérationnel unifié qui vit entièrement à l'intérieur de votre environnement Databricks existant. Les PHI ne quittent jamais votre périmètre sécurisé, l'interface utilisateur interroge les données sur place et la sécurité au niveau des lignes est appliquée automatiquement.

Voici comment nous sortons vos facturières des feuilles de calcul et les ramenons au travail sur les réclamations.

Là où le pipeline s'arrête habituellement

X12 reste l'épine dorsale du paiement des soins de santé aux États-Unis (835, 834, 837). L'analyseur X12-EDI open-source, créé par l'équipe Databricks, est le point de départ idéal. Il prend les fichiers bruts, comprend les boucles et écrit des enregistrements normalisés dans Delta Lake.

Mais si cela permet à un analyste de données d'accéder à une requête SQL, cela ne permet pas à une facturière de faire appel.

Le pipeline médaillon, des fichiers X12 bruts jusqu'à l'interface utilisateur React, avec la frontière PHI de Unity Catalog clairement délimitée autour des couches de données Bronze/Silver/Gold pour montrer la conformité.

Ce que nous avons construit : L'atelier opérationnel

Pour combler ce fossé, nous avons construit une solution en deux couches : étendre l'analyseur sous-jacent pour une réalité de qualité de production et construire une surface opérationnelle sécurisée et intuitive pour votre équipe.

Couche 1 : Extension du moteur

Les besoins réels en RCM nécessitent des recherches que les analyseurs open-source standard ne couvrent pas toujours. Nous avons étendu le moteur pour inclure :

• Inscription contextuelle (834) : Suivi de bout en bout des sponsors et des dépendances.
• Ajustements décodés (835) : Champs CAS de groupe/raison décodés à partir de la table de codes. C'est la différence entre une facturière regardant "CO-45" et lisant "CO-45 : les frais dépassent le barème" sur son écran.
• Contributions en amont : Nous n'avons pas bifurqué le code ; ces extensions de schéma et de test sont directement renvoyées à la communauté open-source.

Couche 2 : Le bureau de la facturière

C'est la surface opérationnelle, une application web sécurisée directement au-dessus de votre connecteur Databricks SQL. Chaque chiffre sur chaque écran est une requête en direct sur une vue or de Unity Catalog. Il n'y a pas de copie fantôme ETL et pas de cache synchronisé.

L'atelier comprend six vues principales conçues pour la manière dont les équipes RCM travaillent réellement :

Traitement des réclamations :

• Le tiroir de remise (835) : Une facturière voit exactement quels codes CARC entraînent l'écart entre le facturé et le payé. Elle peut ouvrir n'importe quelle réclamation jusqu'au détail de la ligne de service et rédiger un appel ou une correction sans quitter l'écran.
• Atelier des refus : Les fenêtres de dépôt dans les délais font de l'âge la métrique la plus critique sur le terrain. Les lignes deviennent rouges lorsqu'elles dépassent 30 jours. Vous pouvez filtrer par payeur, CARC ou file d'attente. L'état du filtre est encodé dans l'URL, ce qui signifie qu'un responsable peut copier une liste de travail priorisée proprement dans Slack pour son équipe.
• Inscription (834) : Les coordinateurs de prestations peuvent voir les nouveaux employés, les changements de plan et les résiliations dans une seule vue, avec des drilled-in en un clic vers le segment exact lorsqu'un enregistrement échoue.

L'atelier des refus. Remarquez les deux lignes dépassant 30 jours qui deviennent rouges, les badges d'âge signalant la criticité, et le total des dollars à risque dans la barre d'état pour une visibilité immédiate.

La réclamation CLM-4209 est sélectionnée. Le tiroir affiche trois lignes de service, décode l'ajustement CO-45 en langage clair et expose des boutons d'action directs pour Rédiger un appel / Correction.

Gestion du terrain :

• Tableau de bord de direction : Réclamations MTD, taux de rapprochement des paiements, membres actifs et refus ouverts dans une seule vue. Si un flux de payeur s'arrête, vous le voyez le même jour.
• Portes de qualité : Les décomptes de segments incorrects entraînent le rejet d'un fichier entier par un payeur. Notre couche de qualité détecte ces décomptes à l'ingestion, avant l'envoi du fichier.
• Audit et sécurité : Chaque révélation de PHI et chaque changement d'état du flux de travail sont enregistrés. Si un utilisateur a besoin d'un accès PHI exceptionnel, le système exige une raison écrite, qui est automatiquement enregistrée dans l'audit.

La modale d'accès exceptionnel montrant le verrou de sécurité, le champ de raison pré-rempli, l'avertissement de conformité HIPAA et l'aperçu de l'entrée de journal avant que la facturière ne confirme l'accès.

Perspectives : Rédaction d'appels avec GenAI

Mettre les données devant la facturière est la première étape. La deuxième étape est d'accélérer le travail.

La prochaine frontière pour cet atelier est l'intégration d'un modèle Claude via les API Databricks Foundation Model. Bientôt, le système lira le code CARC, récupérera le 837 d'origine, examinera la documentation clinique et rédigera dynamiquement la lettre d'appel. Au lieu d'écrire à partir d'une page blanche, votre facturière agira simplement comme réviseur et approbateur.

Essayez-le avec vos propres données

Le déploiement dans votre environnement est une question de configuration, pas de code. Il s'associe parfaitement à l'accélérateur Databricks X12 EDI.

Donnez-nous deux semaines, votre schéma Unity Catalog et vingt refus déjà dans votre file d'attente. Chronométrez votre facturière traitant ces refus aujourd'hui, puis chronométrez-la traitant un cohorte appariée dans l'atelier.

Vous possédez les données, vous possédez le chronomètre et vous possédez la conclusion.

Pour évaluer cela pour votre organisation, contactez Neel Shapur ([email protected]) ou Aaron Zavora chez Databricks.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original