Ihre Revenue Cycle Management Datenvorlage

Der Aktivitätsname beschreibt eine eigenständige Aktion oder einen Meilenstein im Lebenszyklus des Revenue Cycle. Beispiele sind „Leistung erbracht“, „Anspruch eingereicht“, „Zahlungsavis erhalten“, „Zahlung verbucht“ und „Konto abgeschrieben“. Jede Aktivität stellt einen Schritt im Prozess dar, der Zeit und Ressourcen verbraucht.

Dieses Attribut ist grundlegend für Process Mining, da es die Knoten in der Prozesslandkarte definiert. Die Analyse der Reihenfolge, Häufigkeit und Dauer dieser Aktivitäten ermöglicht die Visualisierung des tatsächlichen Prozessflusses, den Vergleich mit einem entworfenen Modell und die Identifizierung von Abweichungen, Nacharbeits-Schleifen wie Anspruchsablehnungen und Ineffizienzen.

Dieses Attribut definiert die Schritte des Prozesses, was essenziell für die Entdeckung und Visualisierung der Prozesslandkarte, die Identifizierung von Wiederholungsarbeit und die Analyse der Prozesskonformität ist.

Oft in Event Logs, Transaktionstabellen oder aus Statusänderungsdatensätzen im Abrechnungs- oder Anspruchsmodul gefunden.

Der Event Timestamp markiert den Zeitpunkt, zu dem eine Aktivität stattfand oder protokolliert wurde. Er liefert den chronologischen Kontext für alle Events innerhalb eines Cases und bildet eine Zeitlinie vom Beginn bis zum Ende des Revenue Cycle.

Timestamps sind das Rückgrat der Leistungsanalyse im Process Mining. Sie werden verwendet, um kritische KPIs wie die gesamte Zykluszeit, die Dauer zwischen spezifischen Aktivitäten und Wartezeiten zu berechnen. Durch die Analyse von Timestamps können Organisationen Bottlenecks identifizieren, an denen Cases die meiste Zeit verbringen, die Einhaltung von Service Level Agreements messen und die zeitliche Dynamik des Prozesses verstehen.

Es liefert die chronologischen Daten, die zur Berechnung von Durchlaufzeiten, zur Identifizierung von Engpässen und zur Analyse der Performance und Effizienz des Prozesses erforderlich sind.

Diese Informationen sind typischerweise in Transaktionsprotokollen, Audit-Trails oder als Feld 'Erstellungsdatum' oder 'Statusänderungsdatum' in Event-Tabellen verfügbar.

Die Billing Event ID ist ein eindeutiger Schlüssel, der jeder Instanz einer abrechenbaren Leistung zugewiesen wird, von der anfänglichen Kostenerfassung bis zur endgültigen Zahlung oder Abschreibung. Sie fungiert als zentraler Faden, der alle zugehörigen Aktivitäten wie Antragerstellung, -einreichung, -ablehnung und Zahlungsbuchung für eine spezifische Leistungserbringung miteinander verbindet.

Im Process Mining ist dieses Attribut entscheidend, um die End-to-End-Reise jedes Billing Events zu rekonstruieren. Durch die Gruppierung aller zugehörigen Aktivitäten unter einer einzigen Billing Event ID können Analysten Prozessabläufe visualisieren, Bottlenecks identifizieren, Zykluszeiten messen und die Variationen in der Bearbeitung verschiedener Cases verstehen. Sie bildet die Grundlage für alle Case-zentrierten Analysen innerhalb des Revenue Cycle.

Es ist der wesentliche Fall-Identifikator, der alle verwandten Aktivitäten miteinander verknüpft und die Rekonstruktion und Analyse des gesamten Revenue Cycle für jede abrechenbare Leistung ermöglicht.

Dies ist typischerweise ein Primärschlüssel in Abrechnungstransaktions- oder Finanzereignistabellen.

Dieses Attribut zeichnet auf, wann die Daten zuletzt aus dem Quellsystem abgerufen wurden. Es ist ein Metadatenfeld, das entscheidend für das Verständnis der Aktualität und Zeitgerechtigkeit der analysierten Daten ist. Es spiegelt die Latenz der Datenpipeline wider und zeigt an, wie aktuell die Process Mining Analyse ist.

In Process Mining Dashboards und Analysen liefert der Timestamp der letzten Datenaktualisierung dem Benutzer Kontext zur Aktualität der Daten. Für das operative Monitoring ist es essenziell zu wissen, ob die Ansicht den Prozessstatus von vor fünf Minuten oder von gestern Abend darstellt. Dies hilft, Benutzererwartungen zu verwalten und sicherzustellen, dass Entscheidungen auf Daten eines bekannten Alters basieren.

Es bietet entscheidenden Kontext über die Aktualität und Frische der Daten und stellt sicher, dass Analysen und Entscheidungen auf einem verstandenen Zeitrahmen basieren.

Dies wird typischerweise während des Datenextraktions-, Transformations- und Ladeprozesses (ETL) hinzugefügt und als Metadaten-Spalte im Event Log gespeichert.

Das Attribut „Quellsystem“ identifiziert den Ursprung der Daten für ein spezifisches Event. In einer komplexen IT-Landschaft erstreckt sich der Revenue Cycle Prozess oft über mehrere Systeme, wie z.B. ein elektronisches Gesundheitsaktensystem (EHR) für die Leistungserbringung, ein dediziertes Abrechnungssystem für die Claim-Einreichung und eine separate Inkassoplattform.

Die Kenntnis des Quellsystems ist wertvoll für die Datenvalidierung, Fehlerbehebung und zum Verständnis der Prozessfragmentierung. Sie kann helfen, Inkonsistenzen zwischen Systemen zu identifizieren oder Prozessschritte aufzuzeigen, die in verschiedenen Anwendungen verwaltet werden, was eine Quelle für Datenübertragungsverzögerungen oder -fehler sein kann. Diese Analyse hilft bei der Bewertung der Integration und Effizienz der gesamten IT-Architektur, die den Prozess unterstützt.

Es hilft beim Verständnis der Prozessfragmentierung über verschiedene IT-Systeme hinweg und ist entscheidend für die Datenvalidierung und die Identifizierung systemspezifischer Engpässe.

Diese Informationen sind oft als Standardfeld in Datenextrakten verfügbar oder können basierend auf der Quelltabelle oder -datei abgeleitet werden, aus der die Daten bezogen wurden.

Wenn ein Zahler einen eingereichten Claim ablehnt, gibt er einen Ablehnungsgrundcode an, um zu erklären, warum der Claim nicht bezahlt wurde. Diese Codes folgen oft Industriestandards, wie Claim Adjustment Reason Codes (CARCs), und weisen auf spezifische Probleme hin, wie z.B. 'Leistung nicht abgedeckt', 'Doppelter Claim' oder 'Zusätzliche Informationen erforderlich'.

Dieses Attribut ist eines der mächtigsten für die Ursachenanalyse im Revenue Cycle. Durch die Analyse der Häufigkeit und finanziellen Auswirkungen verschiedener Ablehnungsgründe können Organisationen die vorgelagerten Prozessfehler identifizieren, die zu Ablehnungen führen. Zum Beispiel weist eine hohe Anzahl von Ablehnungen wegen 'Falscher Patienteninformation' auf Probleme im Patientenregistrierungsprozess hin. Dies ermöglicht datengesteuerte Verbesserungen zur Verhinderung zukünftiger Ablehnungen und zur Verbesserung der Erstanforderungs-Zahlungsquote.

Es ist entscheidend für die Ursachenanalyse von Anspruchsablehnungen, da es gezielte Verbesserungen der Front-End- und Mid-Cycle-Prozesse ermöglicht, um zukünftige Umsatzverluste zu verhindern.

Diese Informationen stammen aus den elektronischen Zahlungsavis (ERA)- oder Leistungsabrechnungs (EOB)-Dateien, die von Zahlern erhalten wurden.

Der Korrekturbetrag repräsentiert den Teil des abgerechneten Betrags, dessen Einziehung vom Kostenträger oder Patienten aus Gründen wie vertraglichen Vereinbarungen, Rabatten oder Abschreibungen nicht erwartet wird. Diese Korrekturen reduzieren die gesamten Forderungen und sind ein normaler Bestandteil des Revenue Cycle.

Die Analyse von Korrektur-Beträgen und deren zugehörigen Gründen ist entscheidend für das Verständnis der Umsatzintegrität. Hohe oder unerwartete Korrektur-Niveaus können auf Probleme bei der Leistungserfassung, Kodierung oder im Vertragsmanagement hinweisen. Process Mining kann helfen zu identifizieren, welche Prozessvarianten oder spezifischen Aktivitäten zu höheren Korrekturraten führen, was eine gezielte Ursachenanalyse zur Maximierung der Umsatzrealisierung ermöglicht.

Es hilft bei der Analyse von Umsatzverlusten, indem es Abschreibungen und vertragliche Abzüge verfolgt und potenzielle Probleme in den Vertrags- oder Abrechnungsprozessen hervorhebt.

Dieser Wert wird typischerweise in Finanzanpassungstabellen oder Zahlungsbuchungsmodulen aufgezeichnet.

Der Rechnungsbetrag stellt die Gesamtforderung für erbrachte Leistungen dar, wie sie auf einem Antrag oder einer Rechnung eingereicht wurde. Er ist der anfängliche Finanzwert des Abrechnungsereignisses und dient als Grundlage, von der alle nachfolgenden Finanztransaktionen, wie Zahlungen und Anpassungen, gemessen werden.

Im Process Mining ist die Analyse des Rechnungsbetrags grundlegend, um die finanziellen Auswirkungen von Prozessineffizienzen zu verstehen. Sie kann verwendet werden, um Cases in hoch- und geringwertige Kategorien zu segmentieren und aufzudeigen, ob bestimmte Prozessprobleme hochrentable Forderungen überproportional beeinflussen. Die Korrelation dieses Betrags mit Kennzahlen wie Zykluszeit oder Ablehnungsquote hilft, Verbesserungsmaßnahmen bei Problemen mit den größten finanziellen Auswirkungen zu priorisieren.

Es etabliert den initialen finanziellen Wert eines Falls und ermöglicht eine Finanzwirkungsanalyse von Prozessineffizienzen wie Verzögerungen und Ablehnungen.

Dies ist ein zentrales Finanzattribut, das in den Gebührenerfassungs-, Abrechnungs- oder Claim-Transaktionstabellen gefunden wird.

Die Leistungskategorie klassifiziert die Art der Versorgung oder Leistung, die dem Patienten erbracht wird. Dies könnte eine übergeordnete Klassifizierung wie 'stationär' versus 'ambulant' sein oder eine spezifischere Abteilungskategorie wie 'Chirurgie', 'Notfall' oder 'Labor'. Verschiedene Leistungskategorien haben oft eigene Abrechnungsregeln, Zahleranforderungen und Prozessabläufe.

Die Segmentierung des Revenue Cycle Prozesses nach Leistungskategorie ist für eine aussagekräftige Analyse unerlässlich. Sie ermöglicht Organisationen, die Performance verschiedener Service Lines zu vergleichen, beispielsweise um zu sehen, ob die Ablehnungsquote für chirurgische Eingriffe höher ist als für Konsultationen. Dieses Detailniveau hilft, Probleme zu isolieren und Verbesserungsinitiativen an den spezifischen operativen Kontext jedes Leistungsbereichs anzupassen.

Es ermöglicht den Leistungsvergleich über verschiedene Servicepositionen hinweg, wodurch Variationen in Effizienz, Ablehnungsraten und Zahlungszyklen aufgedeckt werden, die spezifisch für bestimmte Pflegearten sind.

Diese Informationen sind in der Regel in den Gebührendetailaufzeichnungen verfügbar oder können aus der Patientenklasse, Abteilung oder den Prozedurcodes abgeleitet werden.

Dieses Attribut identifiziert die Organisationseinheit, die mit einem bestimmten Prozessschritt verbunden ist, wie z.B. 'Patientenzugang', 'Kodierung', 'Abrechnung' oder 'Inkasso'. Es hilft zu verstehen, wie Arbeit verteilt und zwischen verschiedenen Teams übergeben wird.

Die Analyse des Prozesses aus Abteilungsansicht ist entscheidend für das Verständnis funktionsübergreifender Zusammenarbeit und die Identifizierung von Bottlenecks, die an den Übergabepunkten zwischen Teams auftreten. Sie ermöglicht Managern zu sehen, welche Abteilungen an spezifischen Prozessvarianten beteiligt sind, die Abteilungseffizienz zu messen und Ressourcen effektiver zuzuweisen. Diese Analyse kann systemische Probleme innerhalb einer Abteilung hervorheben, die den gesamten Revenue Cycle beeinflussen können.

Es hilft, abteilungsübergreifende Engpässe zu identifizieren und die Leistung nach Funktionsbereich zu analysieren, wodurch Möglichkeiten für eine bessere teamübergreifende Zusammenarbeit aufgedeckt werden.

Diese Informationen können Teil der Transaktionsdaten sein oder aus den Stammdaten des verantwortlichen Benutzers abgeleitet werden.

Das Attribut „Verantwortlicher Benutzer“ verknüpft einen Prozessschritt mit der Person oder dem System, die/das ihn ausgeführt hat. Dies könnte ein Coder sein, der medizinische Kodierung vornimmt, ein Abrechnungsspezialist, der einen Claim einreicht, oder ein automatisierter Bot, der eine Zahlung bucht. Die Nachverfolgung des Benutzers bietet eine menschen- oder systemzentrierte Ebene für die Prozessanalyse.

Die Analyse der Prozessleistung nach Benutzer oder Team kann Schulungsmöglichkeiten aufzeigen, leistungsstarke Personen identifizieren und eine angemessene Arbeitslastverteilung gewährleisten. Sie ist auch entscheidend für Compliance- und Prüfzwecke und ermöglicht eine klare Verantwortlichkeit für jede getroffene Maßnahme. Dieses Attribut ermöglicht eine detaillierte Analyse der Ressourcenleistung und -auslastung.

Es ermöglicht die Analyse der Team- und individuellen Performance, der Arbeitslastverteilung und der Automatisierungsraten, liefert Einblicke in die Ressourceneffizienz und identifiziert Schulungsbedarfe.

Typischerweise in Transaktionsprotokollen oder Audit-Trails als Felder 'Benutzer-ID', 'Mitarbeiter-ID' oder 'Bearbeiter' gefunden.

Der Zahlername identifiziert die primäre Instanz, an die ein Claim zur Erstattung eingereicht wird. Zahler können kommerzielle Versicherer wie Aetna oder UnitedHealthcare, staatliche Programme wie Medicare oder Medicaid oder andere Entitäten sein. Jeder Zahler hat seine eigenen einzigartigen Regeln, Einreichungsanforderungen und Zahlungsverhalten.

Dieses Attribut ist entscheidend für die Analyse der Revenue Cycle Performance. Durch die Segmentierung des Prozesses nach Zahler können Organisationen identifizieren, welche Zahler die höchsten Ablehnungsquoten, längsten Zahlungszyklen oder häufigsten Anforderungen an zusätzliche Informationen haben. Diese Analyse ermöglicht gezielte Interventionen, wie z.B. Vertragsneuverhandlungen, die Anpassung der Einreichungsprozesse für spezifische Zahler und die Konzentration der Ablehnungsverwaltung dort, wo sie am dringendsten benötigt wird.

Es ermöglicht die Segmentierung von Performance-Metriken, wie Ablehnungsraten und Zahlungszeiten, nach Kostenträger, was entscheidend für gezielte Verbesserungen und Vertragsverhandlungen ist.

Diese Informationen finden sich typischerweise in den Patientenregistrierungs-, Versicherungs- oder Claim-Daten, die mit dem Billing Event verbunden sind.

Ähnlich wie ein Ablehnungsgrund erklärt der Korrektur-Grund, warum ein Teil des abgerechneten Betrags abgeschrieben oder korrigiert wurde. Diese Gründe verdeutlichen, ob eine Korrektur aufgrund einer vertraglichen Verpflichtung mit einem Kostenträger, einer Wohltätigkeitspolitik, einer Abschreibung geringer Beträge oder einer Korrektur eines Abrechnungsfehlers erfolgte.

Die Analyse der Korrektur-Gründe liefert Einblicke in die Umsatzintegrität und Finanzleistung. Sie hilft, zwischen erwarteten, vertraglichen Korrekturen und vermeidbaren Umsatzverlusten aufgrund von Prozessfehlern zu unterscheiden. Durch das Filtern der Prozesslandkarte basierend auf spezifischen Korrektur-Gründen können Analysten Prozessschwächen identifizieren, die zu vermeidbaren Umsatzverlusten führen, und die Verbesserungsbemühungen entsprechend ausrichten.

Es liefert Kontext für finanzielle Korrekturen und hilft, zwischen vertraglichen Verpflichtungen und vermeidbaren Umsatzverlusten aufgrund von Prozessfehlern zu unterscheiden.

Gefunden in Finanztransaktionstabellen innerhalb des Abrechnungs- oder Patientenbuchhaltungssystems, oft verknüpft mit Korrektur- oder Abschreibungstransaktionen.

Der gezahlte Betrag ist die kumulative Summe aller Zahlungen, die einem spezifischen Billing Event zugeordnet wurden. Dies umfasst Zahlungen von primären und sekundären Versicherungszahlern sowie vom Patienten geleistete Zahlungen. Er repräsentiert die tatsächlich erhaltenen Barmittel für die erbrachten Leistungen.

Die Analyse des gezahlten Betrags ist essenziell für die Messung des finanziellen Erfolgs und der Effizienz des Revenue Cycle. Der Vergleich des gezahlten Betrags mit dem Rechnungsbetrag liefert Einblicke in Nettoerlöse und Inkassoquoten. Im Process Mining hilft dieses Attribut, das finanzielle Ergebnis verschiedener Prozesspfade zu quantifizieren, und kann verwendet werden, um Merkmale von Claims zu identifizieren, die vollständig und pünktlich bezahlt werden, im Gegensatz zu denen, die dies nicht tun.

Es misst den tatsächlich für einen Fall eingezogenen Cash, was entscheidend für die Bewertung der Inkassoeffektivität und der gesamten Finanzleistung des Prozesses ist.

Diese Informationen befinden sich in Zahlungsbuchungs- oder Kassenanwendungstransaktionstabellen.

Der Kontostatus bietet eine Momentaufnahme davon, wo sich ein Abrechnungsereignis zu einem bestimmten Zeitpunkt in seinem Lebenszyklus befindet. Dieser Status spiegelt das Ergebnis der jüngsten Aktivität wider und zeigt an, ob das Konto offen ist und auf Zahlung wartet, geschlossen, zum Inkasso gesendet oder in einem anderen Zustand ist.

Während Process Mining den Fluss der Aktivitäten rekonstruiert, ist das Attribut „Kontostatus“ wertvoll für das Filtern und Segmentieren von Fällen basierend auf ihrem aktuellen Zustand. Es ist besonders nützlich für operationale Dashboards, die das Volumen und den Wert von Konten in verschiedenen Stadien anzeigen müssen, wie z.B. die gesamten Forderungen, die derzeit auf die Antwort des Kostenträgers warten, oder die Anzahl der Konten, die kürzlich an ein Inkassobüro gesendet wurden.

Es bietet eine Momentaufnahme des aktuellen Status von Fällen, die nützlich für operationale Dashboards und für die Segmentierung der Analyse basierend darauf ist, wo sich Konten in ihrem Lebenszyklus befinden.

Dies ist typischerweise ein Statusfeld auf dem Hauptpatientenkonto- oder Billing Event Record im Patientenbuchhaltungssystem.

Der offene Saldo stellt den Betrag dar, der für ein Billing Event noch einzuziehen ist. Er wird typischerweise als Rechnungsbetrag abzüglich aller gezahlten Beträge und Anpassungsbeträge berechnet. Dieser Wert ändert sich über den Lebenszyklus des Cases, wenn Zahlungen und Anpassungen gebucht werden.

Dieses Attribut ist ein Schlüsselindikator für die Gesundheit der Debitorenbuchhaltung. Im Process Mining hilft die Analyse des offenen Saldos in verschiedenen Prozessphasen bei der Verwaltung der Forderungsalterung und der Priorisierung von Inkassobemühungen. Es kann verwendet werden, um zu identifizieren, welche Arten von Cases oder Prozesspfaden tendenziell hohe Restsalden aufweisen, was auf Probleme bei der Zahlungs- oder Ablehnungsbearbeitung hindeutet.

Es ist eine Schlüsselmetrik für Debitoren und Inkassoeffektivität, die hilft, Nachverfolgungsaktivitäten zu priorisieren und die A/R-Alterung zu analysieren.

Oft berechnet aus fakturierten, bezahlten und korrigierten Beträgen. Es kann auch als Feld in einem Debitoren- oder Patientenbuchhaltungssystem gespeichert sein.

Die Patienten-ID ist ein eindeutiger Schlüssel, der einem einzelnen Patienten innerhalb des zentralen Patientenstamms des Gesundheitssystems zugewiesen wird. Dieser Identifikator verknüpft alle klinischen und finanziellen Begegnungen eines Patienten über die Zeit hinweg.

Während die Billing Event ID den Case für eine einzelne Leistung darstellt, ermöglicht die Patienten-ID eine breitere Analyse über mehrere Begegnungen desselben Patienten hinweg. Dies kann wiederkehrende Probleme aufzeigen, wie z.B. wiederholte Registrierungsfehler oder Muster der Leistungsnutzung. Sie kann auch verwendet werden, um die vollständige finanzielle Reise eines Patienten zu analysieren, was für das Verständnis von Patientenverbindlichkeiten und -loyalität wertvoll ist.

Es ermöglicht die Analyse über mehrere Abrechnungsereignisse für denselben Patienten hinweg und hilft so, wiederkehrende Probleme zu identifizieren und die finanzielle Gesamtsituation des Patienten zu verstehen.

Dies ist ein primärer Identifikator, der in praktisch allen klinischen und finanziellen Systemen gefunden wird und aus dem Patientenregistrierungs- oder EHR-System stammt.

Die Claim ID ist eine spezifische Kennung für die Rechnung, die an eine Versicherungsgesellschaft gesendet wird. Ein einzelnes Billing Event kann zu mehreren Claims führen, wenn es an primäre, sekundäre und tertiäre Zahler abgerechnet werden muss oder wenn ein Claim korrigiert und erneut eingereicht wird.

Die Nachverfolgung der Claim ID ist wichtig, um die Details des Interaktionsprozesses mit dem Zahler zu verstehen. Sie ermöglicht die Analyse von Wiederholungszyklen im Zusammenhang mit erneuten Claim-Einreichungen und hilft, den Status einer spezifischen, an einen Zahler gesendeten Rechnung zu verfolgen. Die Analyse des Prozesses nach Claim ID kann eine granularere Sicht auf den Lebenszyklus der Claim-Einreichung und -Lösung bieten, als die Betrachtung des Billing Events allein.

Es ermöglicht eine detaillierte Verfolgung von Anspruchseinreichungen und -wiedervorlagen, wodurch eine granulare Analyse der Interaktionen mit Kostenträgern und Nacharbeits-Schleifen bereitgestellt wird.

Diese Kennung wird vom Abrechnungssystem bei der Claim-Erstellung generiert und in Claim-Verwaltungstabellen gespeichert.