Ihr Daten-Template für Revenue Cycle Management
Ihr Daten-Template für Revenue Cycle Management
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten für die Nachverfolgung
- Anleitung zur Datenextraktion aus Oracle Health Revenue Cycle
Attribute für Revenue Cycle Management
| 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 | |||
Aktivitäten im Revenue Cycle Management
| 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 | |||
Anleitungen zur Datenextraktion
Schritte
- Datenbankzugriff beantragen: Lassen Sie sich schreibgeschützte Zugangsdaten für die Oracle-Health-Revenue-Cycle-Datenbank einrichten. Sie benötigen Zugriff auf die Schemas mit Patienten-, Kontakt-, Abrechnungs- und Finanztransaktionsdaten. Dafür ist üblicherweise die Freigabe durch IT-Sicherheit und Datenbankadministration erforderlich.
- Schema- und Tabellennamen ermitteln: Klären Sie mit einer Datenbankadministration oder einer Systemanalyse die genauen Schema- und Tabellennamen Ihrer Oracle-Health-Instanz. Die in der Abfrage verwendeten Namen sind gängige Platzhalter und müssen Ihrer konkreten Umgebung zugeordnet werden.
- SQL-Client installieren: Installieren Sie einen kompatiblen SQL-Client wie Oracle SQL Developer oder DBeaver auf Ihrem Rechner. Damit stellen Sie die Verbindung zur Datenbank her und führen das Extraktionsskript aus.
- Datenbankverbindung einrichten: Konfigurieren Sie im SQL-Client eine neue Datenbankverbindung mit dem angegebenen Host, Port, Servicenamen und den Zugangsdaten. Testen Sie die Verbindung.
- SQL-Abfrage anpassen: Kopieren Sie das bereitgestellte SQL-Skript in ein neues Abfragefenster. Suchen Sie Platzhalter wie
[START_DATE]und[END_DATE]und ersetzen Sie sie durch den gewünschten Analysezeitraum, zum Beispiel'2023-01-01'. Passen Sie Filterbedingungen an Ihre Analyse an, etwa einen Filter für eine bestimmte Patient Class. - Extraktionsskript ausführen: Führen Sie das angepasste SQL-Skript aus. Die Abfrage ist umfassend und kann je nach Zeitraum und Datenbankgröße mehrere Minuten bis Stunden dauern.
- Erste Ergebnisse prüfen: Sehen Sie sich nach Abschluss der Abfrage die ersten Hundert Zeilen im Ergebnisbereich Ihres SQL-Clients an. Achten Sie auf offensichtliche Fehler, etwa ausschließlich leere Spalten oder falsche Datenformate.
- Daten als CSV exportieren: Exportieren Sie das gesamte Ergebnis in eine CSV-Datei. Verwenden Sie UTF-8, um Probleme mit Zeichen zu vermeiden. Die exportierte Datei muss eine Kopfzeile mit den in den Abfragealiasen festgelegten Spaltennamen enthalten, zum Beispiel „BillingEvent“ und „ActivityName“.
- Upload vorbereiten: Öffnen Sie die CSV-Datei vor dem Upload in ein Process-Mining-Tool und prüfen Sie ihre Integrität. Achten Sie auf ein einheitliches Timestamp-Format und darauf, dass die Spaltenüberschriften exakt den erforderlichen Attributen entsprechen. Danach ist die Datei bereit für den Upload.
Konfiguration
- Datumsbereich: Die Abfrage enthält die Platzhalter
[START_DATE]und[END_DATE]. Legen Sie einen konkreten, angemessenen Zeitraum fest, um das Datenvolumen zu begrenzen. Für eine erste Analyse empfiehlt sich ein Zeitraum von drei bis sechs Monaten. - Filterung: Im Abschnitt
RelevantEncounterswird der anfängliche Datensatz nach dem Registrierungsdatum des Kontakts (reg_dt_tm) gefiltert. Ergänzen Sie dort weitereWHERE-Klauseln, um den Umfang einzugrenzen. Mite.patient_class_code IN ('INPATIENT', 'OUTPATIENT')können Sie beispielsweise bestimmte Kontaktarten auswählen. - Leistung: Direkte Abfragen einer Produktionsdatenbank können die Systemleistung beeinträchtigen. Führen Sie die Extraktion möglichst außerhalb der Spitzenzeiten oder, sofern verfügbar, auf einer schreibgeschützten Replik der Produktionsdatenbank aus.
- Voraussetzungen: Für diese Methode benötigen Sie ein Datenbankkonto mit
SELECT-Berechtigungen für alle in der Abfrage referenzierten Tabellen. Dazu gehören Tabellen zu Kontakten, Abrechnung, Gebühren, Forderungen, Zahlungseingängen und Finanztransaktionen. - Zuordnung von Tabellen und Spalten: Das Skript verwendet gängige, beispielhafte Tabellen- und Spaltennamen. Prüfen Sie diese und ordnen Sie sie den tatsächlichen Namen im Oracle-Health-Datenbankschema Ihrer Organisation zu.
FINANCIAL_TRANSACTIONkönnte in Ihrem System beispielsweiseAR_TRANSACTIONSheißen.
Beispielabfrage sql
WITH RelevantEncounters AS (
SELECT
e.billing_event_id
FROM ENCOUNTER e
WHERE e.reg_dt_tm BETWEEN TO_DATE('[START_DATE]', 'YYYY-MM-DD') AND TO_DATE('[END_DATE]', 'YYYY-MM-DD')
)
SELECT
e.billing_event_id AS "BillingEvent",
'Patient Encounter Created' AS "ActivityName",
e.reg_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.reg_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cd.billing_event_id AS "BillingEvent",
'Charges Captured' AS "ActivityName",
cd.charge_entry_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cd.charge_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CHARGE_DETAIL cd
JOIN ENCOUNTER e ON cd.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cd.entry_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cd.performing_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
ch.billing_event_id AS "BillingEvent",
'Charges Coded' AS "ActivityName",
ch.coded_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CODING_HISTORY ch
JOIN ENCOUNTER e ON ch.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ch.coder_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cl.billing_event_id AS "BillingEvent",
'Claim Generated' AS "ActivityName",
cl.create_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM cl
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cl.create_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Claim Submitted To Payer' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'INITIAL'
UNION ALL
SELECT
ra.billing_event_id AS "BillingEvent",
'Remittance Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM REMITTANCE_ADVICE ra
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Payment Posted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'PAYMENT'
UNION ALL
SELECT
rd.billing_event_id AS "BillingEvent",
'Denial Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
rd.denial_reason_code AS "DenialReasonCode"
FROM REMITTANCE_DETAIL rd
JOIN REMITTANCE_ADVICE ra ON rd.remit_id = ra.remit_id
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
WHERE rd.denial_reason_code IS NOT NULL
UNION ALL
SELECT
at.billing_event_id AS "BillingEvent",
'Denial Appealed' AS "ActivityName",
at.appeal_filed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
at.related_denial_code AS "DenialReasonCode"
FROM APPEAL_TRACKING at
JOIN ENCOUNTER e ON at.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON at.appeal_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON at.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Corrected Claim Submitted' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'CORRECTED'
UNION ALL
SELECT
psl.billing_event_id AS "BillingEvent",
'Patient Statement Sent' AS "ActivityName",
psl.statement_sent_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
psl.statement_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM PATIENT_STATEMENT_LOG psl
JOIN ENCOUNTER e ON psl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON psl.sent_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
UNION ALL
SELECT
ash.billing_event_id AS "BillingEvent",
'Collection Activity Started' AS "ActivityName",
ash.status_change_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ash.account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ACCOUNT_STATUS_HISTORY ash
JOIN ENCOUNTER e ON ash.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ash.change_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ash.responsible_org_id = org.organization_id
WHERE ash.new_status_code = 'COLLECTIONS'
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Account Adjusted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
ft.transaction_amount AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
ft.adjustment_reason_code AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'ADJUSTMENT'
UNION ALL
SELECT
e.billing_event_id AS "BillingEvent",
'Account Closed' AS "ActivityName",
e.account_closed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
0 AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.closed_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
WHERE e.total_account_balance = 0 AND e.account_closed_dt_tm IS NOT NULL; 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.
Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.