Ihr Daten-Template für Revenue Cycle Management

Oracle Health Revenue Cycle
Ihr Daten-Template für Revenue Cycle Management

Ihr Daten-Template für Revenue Cycle Management

Dieses Template führt Sie durch die Erfassung der passenden Daten für eine umfassende Analyse Ihres Revenue-Cycle-Management-Prozesses. Es beschreibt die erforderlichen Datenfelder und zentralen Prozessschritte für den Aufbau eines aussagekräftigen Event Logs. Mit diesen Vorgaben strukturieren Sie Ihre Daten so, dass sie sich für Process Mining eignen.
  • Empfohlene Attribute für die Datenerfassung
  • Wichtige Aktivitäten für die Nachverfolgung
  • Anleitung zur Datenextraktion aus Oracle Health Revenue Cycle
Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Attribute für Revenue Cycle Management

Diese wichtigen Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Ihren Revenue-Cycle-Management-Prozess umfassend analysieren und aussagekräftige Erkenntnisse gewinnen zu können.
3 Erforderlich 7 Empfohlen 9 Optional
Name Beschreibung
Abrechnungsereignis
BillingEvent
Die eindeutige Kennung für die Erbringung einer einzelnen Leistung oder Lieferung eines Produkts, für die eine Gebühr anfällt. Sie dient als Case-ID für den Revenue-Cycle-Prozess.
Beschreibung

Das Abrechnungsereignis dient als primäre Case-ID und verknüpft alle Aktivitäten von der Leistungserfassung bis zum Kontenabschluss für eine bestimmte abrechenbare Position. Jedes Abrechnungsereignis steht für einen einzelnen Revenue-Cycle-Prozess. So lässt sich sein Verlauf durch verschiedene Phasen verfolgen, etwa die Übermittlung des Abrechnungsfalls, die Zahlungsverarbeitung sowie mögliche Ablehnungen oder Anpassungen.

In der Process-Mining-Analyse ist dieses Attribut grundlegend für die Rekonstruktion des durchgängigen Prozessablaufs. Es ermöglicht die Visualisierung von Prozessvarianten, die Berechnung der Zykluszeiten zwischen Aktivitäten und die Ermittlung von Engpässen oder Abweichungen bei bestimmten Abrechnungsereignissen.

Warum das wichtig ist

Dieser Schlüssel ist unverzichtbar, um den gesamten Lebenszyklus einer abrechenbaren Leistung zu verfolgen und Prozessabläufe sowie Leistungskennzahlen zu analysieren.

Woher beziehen

Diese Kennung sollte ein eindeutiger Schlüssel in den zentralen Abrechnungs- oder Transaktionstabellen für Leistungen in Oracle Health Revenue Cycle sein. In der Systemdokumentation finden Sie den Primärschlüssel für Abrechnungsereignisse.

Beispiele
BEVNT-987654321BEVNT-987654322BEVNT-987654323
Aktivitätsname
ActivityName
Der Name des konkreten Schritts oder Ereignisses im Revenue-Cycle-Prozess.
Beschreibung

Dieses Attribut erfasst den Namen jeder Aktivität im Lebenszyklus eines Abrechnungsereignisses. Beispiele sind „Leistungen erfasst“, „Abrechnungsfall an Kostenträger übermittelt“ und „Zahlung verbucht“. Diese Aktivitäten bilden die Knoten der ermittelten Prozesslandkarte.

Die Analyse der Abfolge und Häufigkeit von Aktivitäten ist der Kern von Process Mining. Mit diesem Attribut lassen sich häufige Prozesspfade ermitteln, Abweichungen von der Standardvorgehensweise aufdecken und die Abläufe im Revenue Cycle nachvollziehen.

Warum das wichtig ist

Es definiert die Prozessschritte und ermöglicht so die Visualisierung der Prozesslandkarte und die Analyse von Workflow-Mustern.

Woher beziehen

Wird üblicherweise aus Event Logs, Statusänderungsdatensätzen oder bestimmten Transaktionstabellen abgeleitet, die verschiedenen Phasen des Revenue Cycle in Oracle Health zugeordnet sind.

Beispiele
Abrechnungsfall erstelltZahlungsmitteilung eingegangenAblehnung angefochtenKonto geschlossen
Ereignis-Timestamp
EventTimestamp
Das genaue Datum und die Uhrzeit, zu denen eine Aktivität im System erfasst wurde.
Beschreibung

Dieses Attribut enthält den Timestamp jeder Aktivität und kennzeichnet den genauen Zeitpunkt ihres Auftretens. Es ist wichtig, um den zeitlichen Ablauf und die Reihenfolge der Ereignisse für ein bestimmtes Abrechnungsereignis nachzuvollziehen.

Bei der Analyse dient der Ereignis-Timestamp dazu, Aktivitäten chronologisch zu ordnen, Zeitspannen und Zykluszeiten zwischen einzelnen Schritten zu berechnen und Engpässe zu analysieren. Er bildet die Grundlage für alle zeitbezogenen Process-Mining-Kennzahlen, etwa für die Ermittlung von Verzögerungen zwischen „Abrechnungsfall übermittelt“ und „Zahlungsmitteilung eingegangen“.

Warum das wichtig ist

Dieser Timestamp ist entscheidend, um Ereignisse zu ordnen, alle Leistungskennzahlen wie Zykluszeiten und Zeitspannen zu berechnen und Prozessengpässe zu erkennen.

Woher beziehen

Jede Transaktions- oder Event-Log-Tabelle in Oracle Health Revenue Cycle sollte eine Timestamp-Spalte enthalten, die angibt, wann der Datensatz erstellt oder das Ereignis ausgelöst wurde.

Beispiele
2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z
Ablehnungsgrundcode
DenialReasonCode
Ein standardisierter Code für den Grund, aus dem der Kostenträger einen Anspruch abgelehnt hat.
Beschreibung

Lehnt ein Kostenträger einen Anspruch ab, gibt er einen Grundcode an, zum Beispiel „Nicht abgedeckte Leistung“ oder „Doppelter Anspruch“. Dieses Attribut erfasst den Code und die zugehörige Beschreibung.

Die Analyse der Ablehnungsgründe ist entscheidend, um den Abrechnungszyklus zu verbessern. Sie hilft der Organisation, wiederkehrende Muster zu erkennen, etwa Probleme bei der Kodierung oder der Anspruchsberechtigung von Patienten, und gezielte Korrekturmaßnahmen einzuleiten. So steigt die Quote fehlerfreier Ansprüche und der Aufwand für Nacharbeiten sinkt.

Warum das wichtig ist

Zeigt die Ursachen für abgelehnte Ansprüche auf. So können Sie gezielt Verbesserungen umsetzen, die die Quote fehlerfreier Ansprüche erhöhen und den Zahlungseingang beschleunigen.

Woher beziehen

Diese Informationen gehen vom Kostenträger mit der elektronischen Zahlungsmitteilung (ANSI-835-Datei) ein und sollten in Oracle Health in den Tabellen für Ansprüche oder Zahlungsmitteilungen gespeichert werden.

Beispiele
CO-16: Für die Bearbeitung fehlen Angaben zum Anspruch oder zur Leistung.PR-96: Nicht abgedeckte Abrechnungsposten.CO-18: Doppelter Anspruch oder doppelte Leistung.
Abrechnungsabteilung
BillingDepartment
Die Abteilung oder das zuständige Team, das für die Aktivität verantwortlich ist.
Beschreibung

Dieses Attribut gibt die Abteilung an, die die Aktivität ausgeführt hat, etwa „Leistungserfassung“, „Kodierung“ oder „Forderungseinzug“. Es ordnet den Prozessablauf organisatorisch ein.

Die Analyse nach Abteilungen ist wichtig, um Übergaben zwischen Teams nachzuvollziehen und abteilungsübergreifende Ineffizienzen zu erkennen. Das Dashboard „Arbeitslast der Abrechnungsabteilung“ unterstützt diese Analyse, indem Aktivitäten und Leistungskennzahlen nach Abteilung zusammengefasst werden.

Warum das wichtig ist

Ordnet Aktivitäten Organisationseinheiten zu. Das ist wichtig, um Übergaben zwischen Abteilungen, Arbeitslasten und Teamleistungen zu analysieren.

Woher beziehen

Diese Information ist möglicherweise direkt im Benutzerprofil in Oracle Health gespeichert oder lässt sich anhand des Benutzers oder der Aktivitätsart ableiten.

Beispiele
PatientenaufnahmeKodierungAbrechnungForderungseinzug
Anpassungsbetrag
AdjustmentAmount
Der Geldbetrag aller Anpassungen am Kontostand.
Beschreibung

Dieses Attribut erfasst den Betrag einer finanziellen Anpassung, etwa eines vertraglichen Nachlasses, einer Abschreibung oder einer Korrektur, die auf den Abrechnungsvorgang angewendet wird. Anpassungen verringern unmittelbar die erwarteten Einnahmen aus einer Abrechnung.

Das Dashboard „Auswirkungen von Kontenanpassungen“ stützt sich maßgeblich auf dieses Attribut. Die Analyse der Anpassungsbeträge und der zugehörigen Gründe hilft dabei, Ursachen für Umsatzverluste, Probleme im Vertragsmanagement oder Fehler bei der ursprünglichen Leistungserfassung zu erkennen. Die Kennzahl ist ein wichtiger Indikator für die finanzielle Gesundheit.

Warum das wichtig ist

Beziffert Umsatzverluste durch Abschreibungen oder Korrekturen und hilft, die Ursachen finanzieller Einbußen zu erkennen und zu beheben.

Woher beziehen

In den Finanztransaktionstabellen zu finden, in denen Anpassungen oder Abschreibungen auf ein Patientenkonto erfasst werden.

Beispiele
-50.25-120.0025.00
Benutzer
UserPerformingAction
Die Benutzer-ID oder der Name der Person, die die Aktivität ausgeführt hat.
Beschreibung

Dieses Attribut gibt an, welcher Mitarbeitende oder welches automatisierte System für eine bestimmte Aktivität im Prozess verantwortlich war. Es ist wichtig, um die Arbeitslastverteilung und die Ressourcenleistung zu verstehen und Schulungsbedarf zu erkennen.

Bei der Analyse können Sie die Prozesslandkarte nach Benutzern oder Teams filtern, die Leistung verschiedener Ressourcen vergleichen und die Arbeitslast im Dashboard „Arbeitslast der Abrechnungsabteilung“ untersuchen. So lassen sich besonders leistungsstarke Mitarbeitende sowie Personen ermitteln, die zusätzliche Unterstützung oder Schulungen benötigen.

Warum das wichtig ist

Verknüpft Prozessaktivitäten mit bestimmten Benutzern oder Teams. So lassen sich Arbeitslasten analysieren, Leistungen vergleichen und Schulungsbedarf erkennen.

Woher beziehen

Benutzer-ID-Felder wie „CREATED_BY“ und „USER_ID“ sind üblicherweise in Transaktionstabellen der verschiedenen Oracle-Health-Module vorhanden.

Beispiele
j.doeasmithBillingBot_AUTOk.williams
Name des Kostenträgers
PayerName
Der Name der Versicherung oder des Drittanbieters, der für die Zahlung verantwortlich ist.
Beschreibung

Dieses Attribut gibt die Stelle an, der die Leistung in Rechnung gestellt wird, etwa eine Versicherung oder ein staatliches Programm wie Medicare. Angaben zum Kostenträger sind grundlegend für die Analyse des Revenue Cycle.

Eine Analyse nach Kostenträger kann deutliche Unterschiede bei Zahlungszeiten, Ablehnungsquoten und Erfolgsquoten von Einsprüchen aufzeigen. Sie hilft, Kostenträger zu ermitteln, die Verzögerungen oder Erlösverluste verursachen, und ist wichtig für die wirksame Verwaltung von Verträgen und Beziehungen zu Kostenträgern.

Warum das wichtig ist

Ermöglicht die Aufschlüsselung des Prozesses nach Kostenträger und macht Unterschiede bei Abläufen, Ablehnungsquoten und Zahlungsgeschwindigkeit sichtbar. Das ist wichtig für die finanzielle Leistung.

Woher beziehen

Diese Information ist in den Abrechnungs- oder Versicherungsdaten des Patienten in Oracle Health Revenue Cycle gespeichert.

Beispiele
AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna
Offener Saldo
OutstandingBalance
Der zum jeweiligen Zeitpunkt noch nicht bezahlte Betrag des Abrechnungsvorgangs.
Beschreibung

Dieses Attribut zeigt den aktuell offenen Betrag eines Abrechnungsvorgangs, nachdem alle Zahlungen und Anpassungen berücksichtigt wurden. Er entspricht der noch ausstehenden Forderung für die jeweilige Abrechnung.

Für das Dashboard „Alter offener Salden“ ist dieses Attribut entscheidend. Die Entwicklung des Werts im Zeitverlauf zeigt, wie schnell Geld eingeht und wie wirksam die Forderungseinzüge sind. Außerdem dient er zur Berechnung wichtiger Finanzkennzahlen wie Days Sales Outstanding (DSO).

Warum das wichtig ist

Erfasst die aktuell offenen Forderungen je Case. Das ist wichtig, um den Cashflow zu steuern und die Wirksamkeit des Forderungseinzugs zu analysieren.

Woher beziehen

Dieser Wert wird üblicherweise aus der Summe aller Finanztransaktionen eines Abrechnungsvorgangs berechnet, darunter Abrechnungen, Zahlungen und Anpassungen. Er kann auch als Feld in einer Kontenübersichtstabelle vorliegen.

Beispiele
75.000.00550.80
Patientenklasse
PatientClass
Die Klassifizierung des Patientenkontakts, zum Beispiel stationär oder ambulant.
Beschreibung

Dieses Attribut kategorisiert die Art des Patientenbesuchs oder Patientenkontakts, für den die Abrechnung erstellt wurde. Übliche Kategorien sind stationär, ambulant, Notfall und wiederkehrender Patient. Die Patientenklasse bestimmt häufig den gesamten Abrechnungs- und Einreichungsprozess.

Je nach Patientenklasse gelten unterschiedliche Prozesspfade und Compliance-Anforderungen. Die Analyse anhand dieses Attributs hilft, diese Unterschiede zu verstehen, Verbesserungsmaßnahmen gezielt auszurichten und sicherzustellen, dass für jede Klasse die richtigen Verfahren angewendet werden.

Warum das wichtig ist

Trennt unterschiedliche Prozessabläufe, etwa stationäre und ambulante Behandlungen, die sich hinsichtlich Komplexität, Zeitrahmen und Abrechnungsanforderungen unterscheiden.

Woher beziehen

Dies ist ein Standardfeld, das in Oracle Health einem Patientenkontakt oder Aufnahmedatensatz zugeordnet ist.

Beispiele
StationärAmbulantNotfallWiederkehrend
Abrechnungsbetrag
ChargeAmount
Der Bruttobetrag der abgerechneten Dienstleistung oder des Produkts.
Beschreibung

Dieses Attribut enthält den ursprünglichen, nicht rabattierten Betrag für eine Dienstleistung, bevor Anpassungen, vertragliche Nachlässe oder Zahlungen berücksichtigt werden. Er bildet den finanziellen Ausgangswert des Abrechnungsvorgangs.

Die Erfassung des Abrechnungsbetrags ist für die Finanzanalyse entscheidend. So lässt sich etwa der Gesamtwert erbrachter Leistungen berechnen und nachvollziehen, wie sich spätere Anpassungen oder Abschreibungen finanziell auswirken. Der Betrag dient als Grundlage, um die Umsatzrealisierung zu messen.

Warum das wichtig ist

Legt den finanziellen Ausgangswert des Falls fest. Dieser ist die Grundlage für alle weiteren Finanzanalysen und die Bewertung finanzieller Auswirkungen.

Woher beziehen

In Oracle Health in den Tabellen mit Abrechnungsdetails oder Abrechnungstransaktionen zu finden.

Beispiele
150.001250.7585.50
Anspruchs-ID
ClaimId
Die eindeutige Kennung des beim Kostenträger eingereichten Versicherungsanspruchs.
Beschreibung

Dieses Attribut enthält die eindeutige ID eines Anspruchs, der erstellt und zur Erstattung an einen Kostenträger übermittelt wurde. Ein Abrechnungsvorgang kann im Laufe der Bearbeitung zu einem oder mehreren Ansprüchen führen, etwa wenn eine Korrektur erforderlich ist.

Mit der Anspruchs-ID lässt sich eine bestimmte Einreichung beim Kostenträger nachverfolgen und direkt mit der Antwort verknüpfen, zum Beispiel einer Zahlung oder Ablehnung. Damit können Sie den übergeordneten Abrechnungszyklus detaillierter analysieren.

Warum das wichtig ist

Ermöglicht die gezielte Nachverfolgung eines Anspruchs beim Kostenträger und bietet damit mehr Details als die Betrachtung des gesamten Abrechnungsvorgangs.

Woher beziehen

Oracle Health erstellt diese ID beim Anlegen eines Anspruchs und speichert sie in der primären Anspruchstabelle.

Beispiele
CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1
Automatisiert
IsAutomated
Kennzeichnet, ob ein automatisiertes System oder ein menschlicher Benutzer die Aktivität ausgeführt hat.
Beschreibung

Dieses boolesche Attribut unterscheidet Aktivitäten, die durch Softwareautomatisierung wie Bots oder System-Batchjobs ausgeführt wurden, von manuell durch einen Benutzer ausgeführten Aktivitäten. „Anspruch erstellt“ kann beispielsweise ein automatisierter Schritt sein, während „Ablehnung angefochten“ wahrscheinlich manuell erfolgt.

Die Analyse dieses Attributs zeigt, wie stark der Prozess automatisiert ist und wie sich das auf Effizienz und Fehlerquoten auswirkt. Sie können automatisierte und manuelle Abläufe vergleichen und weitere Automatisierungsmöglichkeiten erkennen.

Warum das wichtig ist

Unterscheidet zwischen Aktivitäten von Mitarbeitenden und systemgesteuerten Aktivitäten. Das ist entscheidend, um die Wirksamkeit der Automatisierung zu bewerten und weitere Möglichkeiten zu erkennen.

Woher beziehen

Wird üblicherweise aus dem Attribut UserPerformingAction abgeleitet. Aktivitäten von Benutzer-IDs wie „SYSTEM“ oder „RPA_BOT“ werden beispielsweise als automatisiert gekennzeichnet.

Beispiele
truefalse
Endzeit des Ereignisses
EventEndTime
Der Timestamp, der den Abschluss einer Aktivität kennzeichnet, sofern verfügbar.
Beschreibung

Während StartTime den Beginn einer Aktivität kennzeichnet, gibt EventEndTime ihren Abschluss an. Nicht alle Aktivitäten haben eine eigene Endzeit, da viele Ereignisse unmittelbar eintreten. Bei Aktivitäten mit einer Dauer, etwa „Ablehnung angefochten“, deren Bearbeitung Zeit in Anspruch nehmen kann, ist dieses Feld jedoch sehr hilfreich.

Mit diesem Attribut lässt sich die Verarbeitungszeit einzelner Aktivitäten genauer berechnen. Es hilft, Wartezeit, also die Zeit zwischen Aktivitäten, von Verarbeitungszeit, also der für eine Aktivität aufgewendeten Zeit, zu unterscheiden.

Warum das wichtig ist

Ermöglicht die direkte Berechnung der Dauer einer Aktivität und trennt die Verarbeitungszeit von der Wartezeit.

Woher beziehen

Einige Transaktionstabellen in Oracle Health Revenue Cycle enthalten möglicherweise sowohl einen Start- als auch einen End-Timestamp für bestimmte länger laufende Aufgaben.

Beispiele
2023-04-15T09:05:14Z2023-04-18T16:00:00Z
Letzte Datenaktualisierung
LastDataUpdate
Der Timestamp der letzten Aktualisierung oder Extraktion der Daten für dieses Ereignis.
Beschreibung

Dieses Attribut zeigt, wann der Datensatz zuletzt aktualisiert wurde. Es gibt Aufschluss über die Aktualität der analysierten Daten und hilft dabei, die Aktualität der aus der Process-Mining-Analyse gewonnenen Erkenntnisse einzuschätzen.

Benutzer können anhand dieses Attributs prüfen, ob sie die aktuellsten Prozessinformationen sehen. Es hilft, Erwartungen an den Datenstand zu steuern, und ist ein wichtiger Bestandteil von Data Governance und Qualitätssicherung.

Warum das wichtig ist

Zeigt an, wie aktuell die Daten sind. So können Analysen und Entscheidungen auf aktuellen Informationen beruhen.

Woher beziehen

Dieses Metadatenfeld wird üblicherweise während des ETL-Prozesses erzeugt und befüllt, der Daten in die Process-Mining-Plattform lädt.

Beispiele
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Nacharbeit
IsRework
Kennzeichnet Aktivitäten, die Nacharbeit oder wiederholten Aufwand darstellen.
Beschreibung

Dieses berechnete Attribut kennzeichnet Aktivitäten, die vom idealen „Happy Path“ abweichen und Nacharbeit verursachen. Beispiele sind „Korrigierten Anspruch eingereicht“ oder „Ablehnung angefochten“. Diese Aktivitäten wären nicht erforderlich, wenn der Prozess gleich beim ersten Mal korrekt abliefe.

Nacharbeit zu erkennen und zu quantifizieren, ist ein wichtiges Ziel von Process Mining. Mit diesem Kennzeichen lassen sich alle Nacharbeitsschleifen einfach filtern und analysieren. So können Häufigkeit, Kosten und Ursachen ineffizienter Abläufe ermittelt werden. Das ist entscheidend, um die tatsächlichen Kosten mangelnder Qualität im Abrechnungszyklus zu verstehen.

Warum das wichtig ist

Hilft, Häufigkeit und Auswirkungen von Nacharbeitsschleifen zu quantifizieren. So werden ineffiziente Abläufe und die Kosten mangelnder Qualität sichtbar.

Woher beziehen

Dieses Attribut wird abgeleitet. Es wird bei der Datentransformation anhand einer Geschäftslogik berechnet, die bestimmte Aktivitätsnamen als Nacharbeit kennzeichnet.

Beispiele
truefalse
Patienten-ID
PatientId
Die eindeutige Kennung des Patienten, der dem Abrechnungsvorgang zugeordnet ist.
Beschreibung

Dieses Attribut ist die eindeutige Kennung des Patienten, der die Leistung erhalten hat. Häufig wird sie als Medical Record Number (MRN) bezeichnet. Sie verknüpft die Finanztransaktion mit einer bestimmten Person.

Die Patienten-ID ist zwar nicht die Case-ID des Prozesses, eignet sich aber dazu, alle Abrechnungsvorgänge eines Patienten zusammenzuführen und dessen gesamten finanziellen Verlauf zu betrachten. In Verbindung mit den Stammdaten der Patienten ermöglicht sie außerdem eine Segmentierung nach demografischen Merkmalen oder der Vorgeschichte.

Warum das wichtig ist

Verknüpft Finanzvorgänge mit einem bestimmten Patienten. So können Sie die Abrechnung aus Patientensicht analysieren und alle zugehörigen Vorgänge zusammenführen.

Woher beziehen

Diese Kennung ist ein zentraler Bestandteil des Patientenstammsatzes und findet sich in allen zugehörigen Transaktionstabellen, etwa für Abrechnungen, Ansprüche und Zahlungen.

Beispiele
MRN-1002345MRN-1002346MRN-1002347
Quellsystem
SourceSystem
Das System, aus dem die Ereignisdaten extrahiert wurden.
Beschreibung

Dieses Attribut gibt an, aus welcher Quellanwendung oder welchem Modul die Daten stammen. Für diesen Prozess lautet der Wert in der Regel „Oracle Health Revenue Cycle“. Wenn Daten aus mehreren Bereichen zusammengeführt werden, können auch einzelne Module des Systems angegeben sein.

Diese Information ist für Data Governance und die Fehlerbehebung hilfreich. Sie bestätigt die Datenherkunft und ist wichtig, wenn mehrere Systeme zu einem durchgängigen Prozess beitragen.

Warum das wichtig ist

Gibt Aufschluss über die Herkunft der Daten. Das ist wichtig für die Datenvalidierung und Data Governance sowie für das Verständnis von Prozessvarianten, die vom jeweiligen System abhängen können.

Woher beziehen

Häufig handelt es sich um einen statischen Wert, der beim Extrahieren, Transformieren und Laden der Daten (ETL) hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen.

Beispiele
OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD
Widerspruchsgrund
DisputeReason
Der vom Kunden oder Patienten angegebene Grund für den Widerspruch gegen eine Rechnung oder Abrechnung.
Beschreibung

Dieses Attribut erfasst, warum ein Patient oder eine andere verantwortliche Person einer Rechnung widersprochen hat. Gründe können fehlerhafte Abrechnungen, nicht erbrachte Leistungen oder Probleme bei der Versicherungsabwicklung sein.

Diese Informationen sind für das Dashboard „Kennzahlen zur Klärung von Rechnungswidersprüchen“ wichtig. Die häufigsten Widerspruchsgründe zeigen systematische Probleme bei der Leistungserfassung, Kodierung oder Abrechnung auf. Werden diese Ursachen behoben, lassen sich die Widerspruchsquote und der Verwaltungsaufwand für die Klärung deutlich senken.

Warum das wichtig ist

Zeigt, warum Rechnungen beanstandet werden, und macht Probleme bei der Abrechnungsgenauigkeit oder Verständlichkeit sichtbar, die behoben werden müssen.

Woher beziehen

Diese Information ist wahrscheinlich in einem Fallmanagement- oder Kundenservice-Modul von Oracle Health gespeichert und mit dem Patientenkonto verknüpft.

Beispiele
Falsche Leistung abgerechnetDoppelte AbrechnungVersicherung falsch abgerechnetLeistung nicht erbracht
Erforderlich Empfohlen Optional

Aktivitäten im Revenue Cycle Management

Diese entscheidenden Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um Ihren Revenue Cycle präzise darzustellen und zu analysieren.
5 Empfohlen 9 Optional
Aktivität Beschreibung
Abrechnungsfall an Kostenträger übermittelt
Kennzeichnet die elektronische oder postalische Übermittlung des erstellten Abrechnungsfalls an die Versicherung oder den Kostenträger. Das System sollte Datum und Uhrzeit der Übermittlung protokollieren.
Warum das wichtig ist

Mit dieser Aktivität beginnt der Zahlungszyklus. Die Zeit zwischen Übermittlung und Zahlung ist entscheidend, um die Leistung des Kostenträgers und die Days Sales Outstanding (DSO) zu verstehen.

Woher beziehen

Die Daten stammen aus dem Abrechnungsfallmanagement-Modul, das Übermittlungsereignisse protokolliert. Suchen Sie im Verlauf des Abrechnungsfalls nach einem Übermittlungs-Timestamp oder einer Statusänderung zu „Submitted“.

Erfassung

Ereignis, das protokolliert wird, wenn der Abrechnungsfall erfolgreich über die Clearingstelle übermittelt wurde.

Ereignistyp explicit
Abrechnungsfall erstellt
Kennzeichnet den Zeitpunkt, an dem einzelne Leistungen zu einem formellen Abrechnungsfall wie UB-04 oder CMS-1500 zusammengeführt werden. Dieses systemgenerierte Ereignis erstellt die erste Rechnung.
Warum das wichtig ist

Dieser wichtige Meilenstein zeigt an, dass die Abrechnung gegenüber einem Kostenträger erfolgen kann. Er markiert das Ende des Zeitraums, in dem die interne Verzögerung zwischen Leistungserfassung und Abrechnung gemessen wird.

Woher beziehen

Ein explizites Ereignis, das in Protokollen oder Tabellen zur Erstellung von Abrechnungsfällen erfasst wird. Suchen Sie nach dem Erstellungs-Timestamp des primären Abrechnungsfalldatensatzes, der dem Patientenkontakt zugeordnet ist.

Erfassung

Ereignis, das bei der Erstellung des Abrechnungsfalldatensatzes protokolliert wird.

Ereignistyp explicit
Konto geschlossen
Die letzte Aktivität zeigt an, dass der Kontosaldo null beträgt und keine weiteren Aktivitäten zu erwarten sind. Häufig wird dies daraus abgeleitet, dass der Kontosaldo null erreicht.
Warum das wichtig ist

Kennzeichnet den erfolgreichen Abschluss des Revenue Cycle. Die Zeit bis zu diesem Status ist eine wichtige Kennzahl für die Gesamteffizienz des Prozesses.

Woher beziehen

Wird üblicherweise daraus abgeleitet, dass der offene Saldo des Kontos erstmals null erreicht und nach der Verbuchung aller Zahlungen und Anpassungen bei null bleibt.

Erfassung

Wird berechnet, sobald der Kontosaldo nach der Verbuchung aller Leistungen und Zahlungen erstmals null beträgt.

Ereignistyp calculated
Patientenkontakt angelegt
Kennzeichnet die Anlage eines Patientenkontos für einen bestimmten Besuch oder eine bestimmte Leistung. In der Regel handelt es sich um ein explizites Ereignis, das vom Registrierungssystem oder über einen Admit/Discharge/Transfer-Datenfeed (ADT) ausgelöst wird.
Warum das wichtig ist

Dieses Ereignis bildet den Ausgangspunkt des gesamten Revenue Cycle für einen Abrechnungsvorgang. Damit lassen sich die Gesamtdauer des Prozesses und die Genauigkeit der Registrierung analysieren.

Woher beziehen

Die Daten stammen aus den Protokollen des Patient Registration- oder ADT-Moduls. Suchen Sie nach Ereignissen zur Anlage eines Patientenkontakts oder nach dem frühesten Timestamp, der dem Kontakt oder der Finanznummer zugeordnet ist.

Erfassung

Ereignis, das bei der Registrierung oder Aufnahme des Patienten protokolliert wird.

Ereignistyp explicit
Zahlung verbucht
Kennzeichnet die Zuordnung einer vom Kostenträger eingegangenen Zahlung zu den entsprechenden Leistungen im Patientenkonto. Dabei handelt es sich um eine Finanztransaktion, die von einem Benutzer oder einem automatisierten Prozess protokolliert wird.
Warum das wichtig ist

Die Effizienz der Zahlungsverarbeitung wirkt sich auf die Genauigkeit der Forderungen aus. Verzögerungen können die finanzielle Lage verzerrt darstellen und die Abrechnung gegenüber nachrangigen Kostenträgern verzögern.

Woher beziehen

Die Daten finden sich in den Zahlungstransaktionstabellen. Jede verbuchte Zahlung hat eine eindeutige Transaktions-ID und einen zugehörigen Timestamp.

Erfassung

Eine Finanztransaktion wird protokolliert, wenn die Zahlung dem Konto zugeordnet wird.

Ereignistyp explicit
Ablehnung angefochten
Eine Benutzer- oder Systemaktion, die anzeigt, dass gegen einen abgelehnten Abrechnungsfall Einspruch eingelegt wird. Dies wird üblicherweise als Statusaktualisierung oder als bestimmte Aufgabe in einer Arbeitswarteschlange erfasst.
Warum das wichtig ist

Diese Aktivität setzt eine Nachbearbeitungsschleife in Gang. Für die Optimierung der Erlösrückgewinnung ist es wichtig, Häufigkeit und Erfolgsquote von Einsprüchen zu analysieren.

Woher beziehen

Dabei kann es sich um ein explizites, von einem Benutzer ausgelöstes Ereignis oder um eine Statusänderung des Abrechnungsfalls handeln, etwa zu „Appealed“ oder „In Review“.

Erfassung

Eine Statusänderung oder ein protokolliertes Ereignis, wenn ein Benutzer das Einspruchsverfahren für einen abgelehnten Abrechnungsfall einleitet.

Ereignistyp explicit
Ablehnung eingegangen
Kennzeichnet das Ereignis, bei dem der Kostenträger einen Abrechnungsfall oder einzelne Positionen ablehnt, wie aus der Zahlungsmitteilung hervorgeht. Häufig wird dieses Ereignis anhand der Ablehnungscodes in den Zahlungsdaten abgeleitet.
Warum das wichtig ist

Die Erfassung von Ablehnungen ist wichtig, um Ursachen wie Kodierungsfehler oder Probleme mit dem Versicherungsanspruch zu ermitteln und die Quote korrekt eingereichter Abrechnungsfälle zu verbessern.

Woher beziehen

Wird aus den Zahlungsmitteilungsdaten (ERA/835) abgeleitet. Dieses Ereignis tritt ein, wenn für einen Abrechnungsfall oder eine Position ein Ablehnungsbetrag ungleich null und ein zugehöriger Ablehnungsgrundcode vorliegen.

Erfassung

Abgeleitet aus Zahlungsmitteilungsdaten mit Ablehnungsgrundcodes (CARCs/RARCs).

Ereignistyp inferred
Forderungseinzug gestartet
Kennzeichnet, dass das Patientenkonto wegen ausbleibender Zahlung in den Forderungseinzug überführt wurde. Dies wird üblicherweise durch eine Änderung der Finanz- oder Statusklasse des Kontos erfasst.
Warum das wichtig ist

Dieser Schritt ist für den Umgang mit uneinbringlichen Forderungen entscheidend. Für die finanzielle Gesundheit ist es wichtig zu analysieren, welche Faktoren zu diesem Stadium führen und wie erfolgreich der Forderungseinzug ist.

Woher beziehen

Abgeleitet aus einer Änderung des Kontostatus zu „Collections“ oder „Bad Debt“. Für diese Statusänderung muss ein Timestamp vorliegen.

Erfassung

Abgeleitet aus einer Änderung des Kontostatus zu „Collections“ oder einem ähnlichen Status.

Ereignistyp inferred
Konto angepasst
Kennzeichnet eine finanzielle Anpassung des Kontosaldos, etwa eine vertragliche Vergünstigung, eine Abschreibung oder einen Rabatt. Jede Anpassung ist eine einzelne Finanztransaktion.
Warum das wichtig ist

Anpassungen wirken sich direkt auf die Erlöse aus. Die Analyse ihrer Häufigkeit, Art und Höhe hilft, Erlösverluste und Abrechnungsfehler zu erkennen.

Woher beziehen

Die Daten finden sich in den Finanztransaktionstabellen. Jede Anpassung wird als separate Position mit einem bestimmten Transaktionscode und Timestamp protokolliert.

Erfassung

Eine Finanztransaktion wird mit einem bestimmten Anpassungscode protokolliert.

Ereignistyp explicit
Korrigierten Abrechnungsfall übermittelt
Kennzeichnet die Übermittlung eines überarbeiteten oder korrigierten Abrechnungsfalls an den Kostenträger, häufig nach einer Ablehnung oder einer Bitte um weitere Informationen. Erkennbar ist dies an einer neuen Übermittlung mit Korrekturkennzeichen.
Warum das wichtig ist

Diese Aktivität ist ein wichtiger Teil der Nachbearbeitungsschleife im Ablehnungsmanagement. Eine hohe Häufigkeit weist auf Probleme mit der Genauigkeit der ursprünglichen Abrechnungsfälle hin.

Woher beziehen

Wird in den Protokollen zur Übermittlung von Abrechnungsfällen erfasst. Suchen Sie nach einer neuen Übermittlung für einen bestehenden Patientenkontakt, die häufig durch einen erneuten Übermittlungscode oder eine höhere Versionsnummer gekennzeichnet ist.

Erfassung

Protokolliertes Ereignis für die erneute Übermittlung eines Abrechnungsfalls, häufig erkennbar an einem bestimmten Code für die Häufigkeit der Einreichung.

Ereignistyp explicit
Leistungen erfasst
Kennzeichnet die Erfassung abrechenbarer Leistungen oder Artikel im Patientenkonto. Dies kann automatisch über klinische Systeme oder manuell durch Mitarbeitende erfolgen.
Warum das wichtig ist

Diese Aktivität ist entscheidend, um den „Charge Lag“ zu messen, also die Zeit zwischen der Leistungserbringung und dem Beginn der Abrechnung. Dieser Zeitraum wirkt sich direkt auf den Cashflow und die Korrektheit der Erlöse aus.

Woher beziehen

Die Daten stammen aus den Tabellen für Abrechnungstransaktionen. Erkennbar sind die Einträge am Erstellungs-Timestamp der einzelnen Abrechnungspositionen. In Oracle Health finden sich diese Daten häufig in abrechnungsbezogenen Tabellen.

Erfassung

Für jede neue Abrechnungsposition wird ein Transaktionseintrag erstellt.

Ereignistyp explicit
Leistungen kodiert
Kennzeichnet den Vorgang, bei dem medizinische Kodierfachkräfte den erfassten Leistungen standardisierte Codes wie CPT oder ICD-10 zuweisen. Häufig wird dies über eine Statusänderung der Leistung oder des Patientenkontakts erfasst.
Warum das wichtig ist

Verzögerungen bei der Kodierung sind ein häufiger Engpass. Wenn Sie diese Aktivität verfolgen, erkennen Sie Ineffizienzen im Kodierungs-Workflow und deren Auswirkungen auf den Abrechnungszeitplan.

Woher beziehen

Wird häufig aus einer Statusänderung des Patientenkontakts oder des Abrechnungslaufs abgeleitet, zum Beispiel von „Uncoded“ zu „Coded“. Der Timestamp dieser Statusänderung muss verfügbar sein.

Erfassung

Abgeleitet aus einer Änderung des Kontakt- oder Abrechnungsstatus zu „Coded“ oder „Ready for Billing“.

Ereignistyp inferred
Patientenrechnung versendet
Kennzeichnet das Ereignis, bei dem eine Rechnung über den verbleibenden Eigenanteil erstellt und an den Patienten gesendet wird. Diese explizite Aktion wird vom Patientenabrechnungsmodul protokolliert.
Warum das wichtig ist

Damit beginnt der Teil des Revenue Cycle, in dem Zahlungen vom Patienten eingezogen werden. Die Erfassung hilft dabei, die Wirksamkeit des Forderungseinzugs bei Patienten zu analysieren.

Woher beziehen

Die Daten stammen aus den Protokollen der Patientenabrechnung oder Korrespondenz. Das System sollte das Datum der Erstellung oder des Versands jeder Rechnung erfassen.

Erfassung

Ereignis, das protokolliert wird, wenn eine Patientenrechnung erstellt und gedruckt oder elektronisch versendet wird.

Ereignistyp explicit
Zahlungsmitteilung eingegangen
Kennzeichnet den Eingang einer elektronischen Zahlungsmitteilung (Electronic Remittance Advice, ERA) oder einer papierbasierten Leistungsabrechnung (Explanation of Benefits, EOB) vom Kostenträger. Das Dokument enthält Angaben dazu, welche Leistungen bezahlt, abgelehnt oder angepasst wurden.
Warum das wichtig ist

Dies ist die erste Rückmeldung des Kostenträgers. Sie ist wichtig, um die Zahlungsgeschwindigkeit zu verstehen und Ablehnungsmuster frühzeitig zu erkennen.

Woher beziehen

Wird im Modul zur Verarbeitung von Zahlungsmitteilungen erfasst. Suchen Sie nach dem Import- oder Erstellungs-Timestamp der ERA-Datei, etwa einer 835-Transaktionsdatei, die mit dem Abrechnungsfall verknüpft ist.

Erfassung

Ereignis, das beim Import und bei der Verarbeitung der Zahlungsmitteilungsdatei des Kostenträgers protokolliert wird, zum Beispiel ANSI 835.

Ereignistyp explicit
Empfohlen Optional

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Oracle Health Revenue Cycle

Möchten Sie loslegen?

Bereiten Sie Ihre Daten mit diesem Template optimal vor. Beginnen Sie noch heute damit, Ihren Revenue-Cycle-Management-Prozess zu verbessern.

Optimieren Sie Ihren Revenue Cycle für schnellere Zahlungseingänge

Beseitigen Sie Engpässe, verkürzen Sie die Zykluszeit um 30 % und verbessern Sie Ihren Cashflow.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.