Mehr als nur X12-Parsing: Die Lücke für Workflows im Revenue Cycle im Gesundheitswesen schließen

Es ist Montagmorgen, 8 Uhr. Eine medizinische Rechnungsstellerin öffnet ihre Warteschlange.

Am Wochenende sind die 835-Zahlungsanweisungsdateien vom Freitag perfekt in Ihrem Data Lake gelandet. Jeder Claim Adjustment Reason Code (CARC) und Provider Level Adjustment (PLB)-Code wurde geparst, dekodiert und normalisiert. Von den 412 Ansprüchen in der Datei sind 38 zu niedrig bezahlt. Das Zeitfenster für die Einreichung der ältesten Ablehnung liegt 27 Tage in der Zukunft.

Sie hat alle Daten, die sie braucht. Was sie nicht hat, ist ein Ort, an dem sie handeln kann.

Stattdessen verbringt sie ihren Vormittag damit, manuell die Schleifen 2100 und 2110, die verschachtelten Anspruchs- und Service-Detaildaten, die in jeder EDI-Datei verborgen sind, in einer SQL-Abfrage durchzugehen, zu niedrig bezahlte Beträge in eine Tabellenkalkulation einzufügen und sie mit einem Zahlungsregister abzugleichen. Bis sie tatsächlich das Telefon in die Hand nimmt, um eine Ablehnung zu bekämpfen, ist die Hälfte ihres Tages vorbei.

Laut KFF haben Versicherer im Jahr 2023 jeden fünften In-Network-Anspruch auf HealthCare.gov abgelehnt, und weniger als 1 % dieser Ablehnungen wurden jemals angefochten, was bedeutet, dass die meisten zu niedrig bezahlten Beträge einfach zu niedrig bleiben.

Die Realität der modernen Healthcare-IT ist diese: Das Datenproblem ist weitgehend gelöst. Das Workflow-Problem nicht.

Dies ist die operative Lücke in der medizinischen X12 – die fehlende Schicht direkt über der Parsing-Engine. Um dies zu beheben, haben Genpact und Databricks eine einheitliche operative Werkbank entwickelt, die vollständig in Ihrer bestehenden Databricks-Umgebung angesiedelt ist. PHI verlässt niemals Ihre sichere Grenze, die Benutzeroberfläche fragt die Daten vor Ort ab und die Sicherheit auf Zeilenebene wird automatisch durchgesetzt.

Hier erfahren Sie, wie wir Ihre Rechnungssteller aus Tabellenkalkulationen herausholen und sie wieder mit der Bearbeitung von Ansprüchen beschäftigen.

Wo die Pipeline normalerweise endet

X12 bleibt das Rückgrat der US-amerikanischen Zahlungsabwicklung im Gesundheitswesen (835, 834, 837). Der Open-Source-x12-edi-parser, der vom Databricks-Team verfasst wurde, ist der perfekte Ausgangspunkt. Er nimmt Rohdateien entgegen, versteht die Schleifen und schreibt normalisierte Datensätze in Delta Lake.

Aber während dies einen Datenanalysten zu einer SQL-Abfrage bringt, bringt es einen Rechnungssteller nicht zu einem Einspruch.

Die Medaillon-Pipeline von rohen X12-Dateien bis zur React-Benutzeroberfläche, wobei die Unity Catalog PHI-Grenze deutlich um die Bronze/Silver/Gold-Datenschichten herum gestrichelt ist, um die Compliance zu zeigen.

Was wir gebaut haben: Die operative Werkbank

Um diese Lücke zu schließen, haben wir eine Lösung in zwei Schichten entwickelt: Erweiterung des zugrunde liegenden Parsers für produktionsreife Realitäten und Aufbau einer sicheren, intuitiven operativen Oberfläche für Ihr Team.

Schicht 1: Erweiterung der Engine

Reale RCM-Anforderungen erfordern Lookups, die Standard-Open-Source-Parser nicht immer erfassen. Wir haben die Engine erweitert, um Folgendes einzuschließen:

• Kontextbezogene Registrierung (834): End-to-End-Sponsor- und Abhängigkeitsverfolgung.
• Dekodierte Anpassungen (835): Code-Tabellen-dekodierte CAS-Gruppen-/Begründungsfelder. Dies ist der Unterschied zwischen einem Rechnungssteller, der "CO-45" betrachtet, und dem Lesen von "CO-45: Gebühr überschreitet den Gebührenplan" auf seinem Bildschirm.
• Upstream-Beiträge: Wir haben den Code nicht geforkt; diese Schema- und Testerweiterungen werden direkt an die Open-Source-Community zurückgegeben.

Schicht 2: Der Desktop des Rechnungsstellers

Dies ist die operative Oberfläche – eine sichere Webanwendung, die direkt auf Ihrem Databricks SQL Connector aufbaut. Jede Zahl auf jedem Bildschirm ist eine Live-Abfrage gegen eine Unity Catalog Gold-Ansicht. Es gibt keine ETL-Shadow-Kopie und keinen synchronisierten Cache.

Die Werkbank verfügt über sechs Kernansichten, die für die tatsächliche Arbeitsweise von RCM-Teams konzipiert sind:

Bearbeitung der Ansprüche:

• Die Zahlungsanweisungs-Schublade (835): Ein Rechnungssteller sieht genau, welche CARC-Codes die Lücke zwischen berechneten und bezahlten Beträgen verursachen. Er kann jeden Anspruch bis ins kleinste Detail der Service-Leitung öffnen und einen Einspruch oder eine Korrektur entwerfen, ohne den Bildschirm zu verlassen.
• Ablehnungs-Werkbank: Zeitfenster für die Einreichung machen das Alter zum kritischsten Metrik auf dem Boden. Zeilen werden rot, wenn sie 30 Tage überschreiten. Sie können nach Zahlungsanbieter, CARC oder Warteschlange filtern. Der Filterzustand wird in der URL kodiert, was bedeutet, dass ein Manager eine priorisierte Arbeitsliste sauber in Slack für sein Team einfügen kann.
• Registrierung (834): Leistungsbeauftragte können neue Mitarbeiter, Planänderungen und Kündigungen in einer Ansicht sehen, mit Ein-Klick-Drill-downs zum exakten beanstandeten Segment, wenn ein Datensatz fehlschlägt.

Die Ablehnungs-Werkbank. Beachten Sie die beiden Zeilen über 30 Tagen, die rot leuchten, die Alters-Badges, die die Kritikalität hervorheben, und die Gesamtsumme der gefährdeten Dollar im Stat-Balken für sofortige Sichtbarkeit.

Anspruch CLM-4209 ist ausgewählt. Die Schublade zeigt drei Service-Leitungen, dekodiert die CO-45-Anpassung in einfacher Sprache und bietet direkte Schaltflächen zum Entwerfen von Einsprüchen/Korrekturen.

Verwaltung des Bodens:

• Führungs-Dashboard: Ansprüche MTD, Zahlungsabgleichsraten, aktive Mitglieder und offene Ablehnungen in einer einzigen Ansicht. Wenn ein Zahlungsanbieter-Feed ausfällt, sehen Sie dies am selben Tag.
• Qualitätstore: Nicht übereinstimmende Segmentanzahlen bedeuten, dass ein Zahlungsanbieter eine ganze Datei ablehnt. Unsere Qualitätsschicht fängt diese Nichtübereinstimmungen beim Erfassen ab, bevor die Datei versendet wird.
• Prüfung & Sicherheit: Jede PHI-Offenlegung und jede Workflow-Statusänderung wird protokolliert. Wenn ein Benutzer einen dringenden PHI-Zugriff benötigt, erfordert das System einen schriftlichen Grund, der automatisch protokolliert wird.

Das Break-Glass-Modal zeigt das Sicherheitsschloss, das vorausgefüllte Begründungsfeld, die HIPAA-Compliance-Warnung und die Vorschau des Protokolleintrags, bevor der Rechnungssteller den Zugriff bestätigt.

Ausblick: GenAI-Entwurf von Einsprüchen

Die Daten dem Rechnungssteller zur Verfügung zu stellen, ist der erste Schritt. Der zweite Schritt ist die Beschleunigung der Arbeit.

Die nächste Grenze für diese Werkbank ist die Integration eines Claude-Modells über die Databricks Foundation Model APIs. Bald wird das System den CARC-Code lesen, den ursprünglichen 837 abrufen, die klinische Dokumentation überprüfen und den Einspruchsbrief dynamisch entwerfen. Anstatt von einer leeren Seite zu schreiben, fungiert Ihr Rechnungssteller einfach als Prüfer und Genehmiger.

Probieren Sie es mit Ihren eigenen Daten aus

Die Bereitstellung in Ihrer Umgebung ist eine Frage der Konfiguration, nicht des Codes. Sie lässt sich nahtlos mit dem Databricks X12 EDI Accelerator. kombinieren.

Geben Sie uns zwei Wochen, Ihr Unity Catalog-Schema und zwanzig Ablehnungen, die bereits in Ihrer Warteschlange liegen. Messen Sie die Zeit, die Ihr Rechnungssteller heute für die Bearbeitung dieser Ablehnungen benötigt – und messen Sie dann die Zeit, die er für die Bearbeitung einer übereinstimmenden Kohorte in der Werkbank benötigt.

Sie besitzen die Daten, Sie besitzen die Stoppuhr und Sie besitzen die Schlussfolgerung.

Um dies für Ihre Organisation zu planen, wenden Sie sich an Neel Shapur ([email protected]) oder Aaron Zavora bei Databricks.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag