Ihr Revenue Cycle Management Daten-Template
Ihr Revenue Cycle Management Daten-Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten für das Tracking
- Extraktionsanleitung für Oracle Health Revenue Cycle Management Managementmanagement
Attribute des Revenue Cycle Management
| Name | Beschreibung | ||
|---|---|---|---|
| Abrechnungsereignis BillingEvent | Der eindeutige Bezeichner für eine einzelne Dienstleistungs- oder Produktlieferung, die eine Belastung generiert, und als Case-Bezeichner für den Revenue Cycle Prozess dient. | ||
| Beschreibung Das Abrechnungsereignis fungiert als primärer Case-Bezeichner, der alle Aktivitäten von der Leistungserfassung bis zum Kontenabschluss für einen einzelnen abrechenbaren Posten verknüpft. Jedes Abrechnungsereignis repräsentiert eine einzigartige Instanz des Revenue Cycle Prozesses, was eine vollständige Verfolgung seines Verlaufs durch verschiedene Phasen wie Forderungseinreichung, Zahlungsverarbeitung und potenzielle Ablehnungen oder Anpassungen ermöglicht. In der Process-Mining-Analyse ist dieses Attribut wichtig für die Rekonstruktion des End-to-End-Prozessflusses. Es ermöglicht die Visualisierung von Prozessvarianten, die Berechnung von Durchlaufzeiten zwischen Aktivitäten und die Identifizierung von Engpässe oder Abweichungen, die mit spezifischen abrechenbaren Ereignissen verbunden sind. Bedeutung Dies ist der wesentliche Schlüssel zur Verfolgung des gesamten Lebenszyklus einer abrechenbaren Leistung, der alle Prozessflussanalysen und Leistungsmessungen ermöglicht. Datenquelle Dieser Bezeichner sollte ein eindeutiger Schlüssel sein, der in den Kern-Abrechnungs- oder Leistungstransaktionstabellen innerhalb des Oracle Health Revenue Cycle Management Managementmanagement vorhanden ist. Konsultieren Sie die Systemdokumentation, um den Primärschlüssel für Leistungsereignisse zu identifizieren. Beispiele BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| Aktivitätsname ActivityName | Der Name des spezifischen Schritts oder Ereignisse, das innerhalb des Revenue Cycle Prozesses aufgetreten ist. | ||
| Beschreibung Dieses Attribut zeichnet den Namen jeder Aktivität auf, die innerhalb des Lebenszyklus eines Abrechnungsereignisses durchgeführt wird. Beispiele sind „Leistungen erfasst“, „Forderung an Zahler gesendet“ und „Zahlung gebucht“. Diese Aktivitäten bilden die Knoten der entdeckten Prozesskarte. Die Analyse der Abfolge und Häufigkeit von Aktivitäten ist die Grundlage für Process Mining. Dieses Attribut hilft, die häufigsten Prozesspfade zu identifizieren, Abweichungen vom Standardverfahren zu entdecken und den operativen Fluss des Revenue Cycle zu verstehen. Bedeutung Es definiert die Schritte im Prozess und ermöglicht die Visualisierung der Prozessdarstellung (Process Map) sowie die Analyse von Workflow-Mustern. Datenquelle Typischerweise abgeleitet aus Event-Logs, StatusänderungsDatensätzen oder spezifischen Transaktionstabellen, die mit verschiedenen Phasen des Revenue Cycle in Oracle Health verbunden sind. Beispiele Anspruch generiertÜberweisung erhaltenAblehnung angefochtenKonto geschlossen | |||
| Ereignis-Zeitstempel EventTimestamp | Das präzise Datum und die Uhrzeit, wann eine Aktivität im System erfasst wurde. | ||
| Beschreibung Dieses Attribut liefert den Zeitstempel für jede Aktivität, der den Antrag bearbeitet.en genauen Zeitpunkt ihres Auftretens markiert. Es ist wichtig für das Verständnis des Timings und der Reihenfolge der Ereignisse innerhalb des Revenue Cycle für ein spezifisches Abrechnungsereignis. In der Analyse wird der Event Zeitstempel verwendet, um Aktivitäten chronologisch zu ordnen, Dauern und Durchlaufzeiten zwischen verschiedenen Schritten zu berechnen und Engpassanalysen durchzuführen. Er ist die Grundlage für alle zeitbasierten Process Mining Metriken, wie die Identifizierung von Verzögerungen zwischen „Forderung eingereicht“ und „Zahlungsavis erhalten“. Bedeutung Dieser Zeitstempel ist maßgeblich für die chronologische Anordnung von Ereignisse, die Berechnung aller Leistungsmetriken wie Durchlaufzeiten und Dauern sowie die Identifizierung von Prozess-Engpässe. Datenquelle Jede Transaktions- oder Event-Log-Tabelle im Oracle Health Revenue Cycle Management Managementmanagement sollte eine Zeitstempel-Spalte enthalten, die angibt, wann der Datensatz erstellt oder den Antrag bearbeitet.as Event stattgefunden hat. Beispiele 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| Ablehnungsgrundcode DenialReasonCode | Ein standardisierter Code, der den Antrag bearbeitet.en Grund für die Ablehnung eines Anspruchs durch den Zahler angibt. | ||
| Beschreibung Wenn ein Zahler eine Forderung ablehnt, stellt er einen Ablehnungsgrundcode bereit, der den Antrag bearbeitet.ie Ablehnung erklärt, wie 'Nicht abgedeckte Leistung' oder 'Doppelte Forderung'. Dieses Attribut erfasst diesen Code und seine zugehörige Beschreibung. Die Analyse der Ablehnungsgründe ist die Basis für die Verbesserung des Revenue Cycle. Sie ermöglicht es der Organisation, gemeinsame Muster, wie Probleme bei der Kodierung oder Patientenberechtigung, zu identifizieren und Korrekturmaßnahmen zu implementieren, um zukünftige Ablehnungen zu verhindern. Dies wirkt sich direkt auf die Clean Claim Rate aus und reduziert die Kosten der Nacharbeit. Bedeutung Liefert die Grundursache für Anspruchsablehnungen und ermöglicht gezielte Verbesserungen zur Erhöhung der Quote sauberer Ansprüche und zur Beschleunigung der Umsatzrealisierung. Datenquelle Diese Information wird im elektronischen Zahlungsavis (ANSI 835 Datei) vom Zahler empfangen und sollte in den Forderungs- oder Zahlungsavistabellen in Oracle Health gespeichert werden. Beispiele CO-16: Anspruch/Dienstleistung fehlen für die Bearbeitung notwendige Informationen.PR-96: Nicht gedeckte Gebühr(en).CO-18: Doppelter Anspruch/Dienstleistung. | |||
| Abrechnungsabteilung BillingDepartment | Die Abteilung oder den Antrag bearbeitet.as Funktionsteam, das für die Aktivität verantwortlich ist. | ||
| Beschreibung Dieses Attribut spezifiziert die Abteilung, wie 'Leistungserfassung', 'Kodierung' oder 'Inkasso', die die Aktivität durchgeführt hat. Es liefert einen organisatorischen Kontext zum Prozessfluss. Die Analyse des Prozesses aus Abteilungsansicht ist wichtig für das Verständnis von Übergaben zwischen Teams und die Identifizierung von abteilungsübergreifenden Ineffizienzen. Es unterstützt das Dashboard „Arbeitslast der Abrechnungsabteilung“, indem es die Aggregation von Aktivitäten und Leistungsmetriken auf Abteilungsebene ermöglicht. Bedeutung Ordnet Aktivitäten Organisationseinheiten zu, was wichtig für die Analyse von Übergaben zwischen Abteilungen, Arbeitslast und Teamleistung ist. Datenquelle Diese Information könnte direkt mit den BenutzerprofilDaten in Oracle Health gespeichert oder basierend auf dem Benutzer- oder Aktivitätstyp abgeleitet werden. Beispiele PatientenzugangKodierungAbrechnungInkasso | |||
| Anpassungsbetrag AdjustmentAmount | Der Geldwert aller am Kontostand vorgenommenen Anpassungen. | ||
| Beschreibung Dieses Attribut erfasst den Betrag jeder finanziellen Anpassung, wie vertragliche Rabatte, Abschreibungen oder Korrekturen, die auf das Abrechnungsereignis angewendet wurden. Anpassungen reduzieren direkt die erwarteten Einnahmen aus einer Leistung. Das Dashboard „Auswirkung von Kontenanpassungen“ stützt sich stark auf dieses Attribut. Die Analyse der Anpassungsbeträge und der den Antrag bearbeitet.amit verbundenen Gründe hilft, Quellen von Umsatzverlusten, Probleme im Vertragsmanagement oder Mängel im anfänglichen Leistungserfassungsprozess zu identifizieren. Es ist eine Schlüsselkennzahl für die finanzielle Gesundheit. Bedeutung Quantifiziert Umsatzverluste aufgrund von Abschreibungen oder Korrekturen und hilft, die Grundursachen der finanziellen Erosion zu identifizieren und zu beheben. Datenquelle Zu finden in Finanztransaktionstabellen, die Anpassungen oder Abschreibungen auf ein Patientenkonto protokollieren. Beispiele -50.25-120.0025.00 | |||
| Benutzer UserPerformingAction | Die Benutzer-ID oder den Antrag bearbeitet.er Name der Person, die die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut identifiziert den Mitarbeiter oder den Antrag bearbeitet.en automatisierten Systembenutzer, der für die Ausführung einer spezifischen Aktivität im Prozess verantwortlich ist. Es ist maßgeblich für das Verständnis der Arbeitslastverteilung, der Ressourcenleistung und der Identifizierung von Schulungsbedarf. In der Analyse ermöglicht dieses Attribut das Filtern der Prozesskarte nach Benutzer oder Team, den Vergleich der Leistung verschiedener Ressourcen und die Analyse der Arbeitslast für das Dashboard „Arbeitslast der Abrechnungsabteilung“. Es kann helfen, Top-Performer oder Personen zu identifizieren, die zusätzliche Unterstützung oder Schulung benötigen. Bedeutung Verknüpft Prozessaktivitäten mit spezifischen Benutzern oder Teams, was die Analyse der Arbeitslast, den Leistungsvergleich und die Identifizierung von Schulungsmöglichkeiten ermöglicht. Datenquelle Benutzer-ID-Felder (z.B. 'CREATED_BY', 'USER_ID') sind in der Regel in Transaktionstabellen über alle Oracle Health Module hinweg vorhanden. Beispiele j.doeasmithBillingBot_AUTOk.williams | |||
| Offener Saldo OutstandingBalance | Der verbleibende unbezahlte Saldo für das Abrechnungsereignis zu einem bestimmten Zeitpunkt. | ||
| Beschreibung Dieses Attribut zeigt den aktuell ausstehende Zahlungen identifizieren.enden Betrag, der für ein Abrechnungsereignis geschuldet wird, nachdem alle Zahlungen und Anpassungen angewendet wurden. Es repräsentiert die aktiven Debitorenbuchungen für diese spezifische Leistung. Dies ist ein kritisches Attribut für das Dashboard „Alterung der ausstehende Zahlungen identifizieren.enden Salden“. Die Analyse dieses Werts im Zeitverlauf hilft bei der Überwachung der Cashflow-Geschwindigkeit, der Bewertung der Effektivität von Inkassobemühungen und der Berechnung wichtiger Finanz-KPIs wie Days Sales Outstanding (DSO). Bedeutung Verfolgt die aktuellen Debitorenbuchungen für jeden Case, was für das Cashflow-Management und die Analyse der Effektivität von Einziehungen notwendig ist. Datenquelle Dieser Wert wird in der Regel aus der Summe aller Finanztransaktionen (Leistungen, Zahlungen, Anpassungen) für ein gegebenes Abrechnungsereignis berechnet. Er kann als Feld in einer Kontenzusammenfassungstabelle existieren. Beispiele 75.000.00550.80 | |||
| Patientenklasse PatientClass | Die Klassifizierung des Patientenfalls, z.B. stationär oder ambulant. | ||
| Beschreibung Dieses Attribut kategorisiert die Art des Patientenbesuchs oder -kontakts, der den Antrag bearbeitet.ie Leistungserfassung ausgelöst hat. Gängige Klassifizierungen umfassen stationär, ambulant, Notfall und wiederkehrender Patient. Die Patientenkategorie bestimmt oft den gesamten Abrechnungs- und Forderungseinreichungsprozess. Verschiedene Patientenkategorien folgen unterschiedlichen Prozesspfaden und haben verschiedene Compliance-Anforderungen. Die Analyse des Prozesses basierend auf diesem Attribut hilft, diese Variationen zu verstehen, Verbesserungsinitiativen anzupassen und sicherzustellen, dass für jede Kategorie die korrekten Verfahren eingehalten werden. Bedeutung Trennt unterschiedliche Prozessabläufe (z.B. stationär vs. ambulant), die verschiedene Komplexitäten, Zeitabläufe und Abrechnungsanforderungen aufweisen. Datenquelle Dies ist ein Standardfeld, das mit einem Patientenfall oder einer Aufnahmeakte in Oracle Health verbunden ist. Beispiele StatusonärAmbulantNotfallWiederkehrend | |||
| Zahlername PayerName | Der Name der Versicherungsgesellschaft oder den Antrag bearbeitet.es Drittzahlers, der für die Zahlung verantwortlich ist. | ||
| Beschreibung Dieses Attribut identifiziert die Einheit, wie eine Versicherungsgesellschaft oder ein staatliches Programm wie Medicare, die für die Leistung abgerechnet wird. ZahlerHinweisrmationen sind grundlegend für die Revenue Cycle Analyse. Die Analyse des Prozesses nach Zahler kann signifikante Unterschiede in den Zahlungszeiten, Ablehnungsraten und Erfolgsquoten von Einsprüchen aufzeigen. Es hilft bei der Identifizierung problematischer Zahler, die Verzögerungen oder Umsatzverluste verursachen, und ist unerlässlich für ein effektives Management von Zahlerverträgen und -beziehungen. Bedeutung Ermöglicht die Segmentierung des Prozesses nach Zahlern, wodurch unterschiedliche Verhaltensweisen, Ablehnungsraten und Zahlungsgeschwindigkeiten sichtbar werden, was für die finanzielle Leistungsfähigkeit wichtig ist. Datenquelle Diese Information wird in den Abrechnungs- oder Versicherungsunterlagen des Patienten innerhalb des Oracle Health Revenue Cycle Management Managementmanagement gespeichert. Beispiele AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| `Charge Amount` ChargeAmount | Der Bruttogeldwert der abgerechneten Dienstleistung oder den Antrag bearbeitet.es Produkts. | ||
| Beschreibung Dieses Attribut repräsentiert den anfänglichen, unrabattierten Betrag, der für eine Leistung berechnet wurde, bevor Anpassungen, vertragliche Rabatte oder Zahlungen angewendet werden. Es ist der anfängliche Finanzwert für das Abrechnungsereignis. Die Verfolgung des Leistungsbetrags ist maßgeblich für die Finanzanalyse, wie die Berechnung des Gesamtwerts der erbrachten Leistungen und das Verständnis der finanziellen Auswirkungen nachfolgender Anpassungen oder Abschreibungen. Es dient als Basislinie zur Messung der Umsatzrealisierung. Bedeutung Legt den anfänglichen finanziellen Wert des Falls fest, der für alle nachfolgenden Finanzanalysen und Wirkungsbewertungen grundlegend ist. Datenquelle Befindet sich in den Gebührendetail- oder Gebührentransaktionstabellen in Oracle Health. Beispiele 150.001250.7585.50 | |||
| Endzeit des Ereignisse EventEndTime | Der Zeitstempel, der den Antrag bearbeitet.en Abschluss einer Aktivität markiert, sofern verfügbar. | ||
| Beschreibung Während StartTime den Beginn einer Aktivität markiert, kennzeichnet EventEndTime ihren Abschluss. Nicht alle Aktivitäten haben eine eindeutige Endzeit, da viele augenblickliche Ereignisse sind. Für Aktivitäten, die jedoch eine Dauer haben, wie „Ablehnung angefochten“, deren Bearbeitung Zeit in Anspruch nehmen kann, ist dieses Feld sehr nützlich. Dieses Attribut ermöglicht eine präzisere Berechnung der Bearbeitungszeit für einzelne Aktivitäten. Es hilft, zwischen Wartezeit (Zeit zwischen Aktivitäten) und Bearbeitungszeit (Zeit, die für eine Aktivität aufgewendet wird) zu unterscheiden. Bedeutung Ermöglicht die direkte Berechnung der Dauer einer Aktivität, indem Verarbeitungszeit von Wartezeit getrennt wird. Datenquelle Einige Transaktionstabellen im Oracle Health Revenue Cycle Management Managementmanagement können sowohl einen Start- als auch einen End-Zeitstempel für spezifische, langwierige Aufgaben enthalten. Beispiele 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| Ist automatisiert IsAutomated | Eine `Kennzeichnung`, die angibt, ob die `Activity` von einem automatisierten System oder einem menschlichen Benutzer durchgeführt wurde. | ||
| Beschreibung Dieses boolesche Attribut unterscheidet zwischen Aktivitäten, die durch Software-Automatisierung, wie Bots oder System-Batch-Jobs, ausgeführt werden, und solchen, die manuell von einem Benutzer durchgeführt werden. Zum Beispiel könnte „Forderung generiert“ ein automatisierter Schritt sein, während „Ablehnung angefochten“ wahrscheinlich manuell erfolgt. Die Analyse dieses Attributs hilft, den Automatisierungsgrad im Prozess und dessen Auswirkungen auf Effizienz und Fehlerraten zu verstehen. Es kann verwendet werden, um die Leistung automatisierter versus manueller Pfade zu vergleichen und Möglichkeiten für weitere Automatisierung zu identifizieren. Bedeutung Differenziert zwischen menschlichen und systemgesteuerten Aktivitäten, was wichtig für die Analyse der Automatisierungseffektivität und die Identifizierung neuer Automatisierungsmöglichkeiten ist. Datenquelle Dies wird in der Regel basierend auf dem Attribut BenutzerPerformingAction abgeleitet. Zum Beispiel werden Aktivitäten, die von Benutzer-IDs wie 'SYSTEM' oder 'RPA_BOT' durchgeführt werden, als automatisiert gekennzeichnet. Beispiele JaNein | |||
| Ist Nacharbeit IsRework | Ein Kennzeichen, das Aktivitäten identifiziert, die Nacharbeit oder wiederholte Anstrengungen darstellen. | ||
| Beschreibung Dieses berechnete Attribut kennzeichnet Aktivitäten, die eine Abweichung vom idealen „Happy Path“ darstellen und Nacharbeit bilden. Beispiele sind „Korrigierte Forderung eingereicht“ oder „Ablehnung angefochten“, die nicht auftreten würden, wenn der Prozess beim ersten Mal perfekt verlaufen wäre. Nacharbeit zu identifizieren und zu quantifizieren ist ein Schlüsselziel von Process Mining. Dieses Flag ermöglicht eine einfache Filterung und Analyse aller Nacharbeitsschleifen und hilft, die Häufigkeit, Kosten und Ursachen von Prozessineffizienzen zu messen. Es ist wichtig, um die wahren Qualitätskosten im Revenue Cycle zu verstehen. Bedeutung Hilft, die Häufigkeit und Auswirkungen von Nacharbeitsschleifen zu quantifizieren, wodurch Prozesseffizienzen und die Kosten schlechter Qualität hervorgehoben werden. Datenquelle Dies ist ein abgeleitetes Attribut. Es wird während der Datentransformation berechnet, indem Geschäftslogik angewendet wird, die spezifische Aktivitätsnamen als Nacharbeit kennzeichnet. Beispiele JaNein | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Zeitstempel, der den Antrag bearbeitet.en letzten Zeitpunkt angibt, zu dem die Daten für dieses Event aktualisiert oder extrahiert wurden. | ||
| Beschreibung Dieses Attribut zeigt an, wann der Datensatz zuletzt aktualisiert wurde. Es liefert Kontext zur Aktualität der analysierten Daten, was wichtig ist, um die Aktualität der aus der Process-Mining-Analyse abgeleiteten Erkenntnisse zu verstehen. Benutzer können dieses Attribut überprüfen, um zu bestätigen, dass sie die aktuellsten ProzessHinweisrmationen anzeigen. Es hilft, Erwartungen an die Aktualität der Daten zu managen und ist ein Schlüsselbestandteil der Daten Governance und Qualitätssicherung. Bedeutung Zeigt die Aktualität der Daten an und stellt sicher, dass Analysen und Entscheidungen auf aktuellen Informationen basieren. Datenquelle Dies ist ein MetaDatenfeld, das in der Regel während des ETL-Prozesses generiert und gefüllt wird, der Daten in die Process-Mining-Plattform lädt. Beispiele 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Patienten-ID PatientId | Der eindeutige Bezeichner für den Patienten, der mit dem Abrechnungsereignis verbunden ist. | ||
| Beschreibung Dieses Attribut ist der eindeutige Bezeichner für den Patienten, der den Antrag bearbeitet.ie Leistung erhalten hat, oft als Krankenaktennummer (MRN) bekannt. Es verknüpft die Finanztransaktion mit einer spezifischen Person. Obwohl es nicht die Case-ID für den Prozess ist, ist die Patienten-ID nützlich, um alle Abrechnungsereignisse für einen einzelnen Patienten zu aggregieren und deren gesamten finanziellen Verlauf zu verstehen. Sie ermöglicht auch die Segmentierung basierend auf Patientendemografie oder -historie, wenn sie mit StammDaten des Patienten verknüpft wird. Bedeutung Verknüpft Finanzereignisse mit einem spezifischen Patienten, was eine patientenzentrierte Analyse und Aggregation aller seiner Abrechnungsaktivitäten ermöglicht. Datenquelle Diese ID ist ein Kernelement des Patientenstammsatzes und wird in allen zugehörigen Transaktionstabellen wie Leistungen, Forderungen und Zahlungen vorhanden sein. Beispiele MRN-1002345MRN-1002346MRN-1002347 | |||
| Quellsystem SourceSystem | Das System, aus dem die Event-Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut identifiziert die Quellanwendung oder den Antrag bearbeitet.as Modul, wo die Daten entstanden sind. Für diesen Prozess wird es in der Regel 'Oracle Health Revenue Cycle Management Managementmanagement' sein, es könnte aber auch verschiedene Module innerhalb des Systems angeben, wenn Daten aus mehreren Quellen integriert werden. Diese Information ist wertvoll für Daten Governance und Fehlerbehebung. Sie hilft, die Datenherkunft zu bestätigen, und ist wichtig in Umgebungen, in denen mehrere Systeme zu einem einzigen End-to-End-Prozess beitragen. Bedeutung Bietet Kontext zum Datenursprung, was wesentlich für die Datenvalidierung, Governance und das Verständnis von Prozessvariationen ist, die systemabhängig sein könnten. Datenquelle Dies ist oft ein statischer Wert, der während des ETL-Prozesses (Extraktion, Transformation und Laden von Daten) hinzugefügt wird, um den Ursprung des Datensatzes zu kennzeichnen. Beispiele OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| Schaden-ID ClaimId | Der eindeutige Bezeichner für die an einen Zahler übermittelte Versicherungsforderung. | ||
| Beschreibung Dieses Attribut ist die eindeutige ID, die einer Forderung zugewiesen wird, die generiert und an einen Zahler zur Erstattung gesendet wird. Ein einzelnes Abrechnungsereignis kann im Laufe seines Lebenszyklus zu einer oder mehreren Forderungen führen, zum Beispiel wenn eine Korrektur erforderlich ist. Die Verwendung der Forderungs-ID ermöglicht die Verfolgung einer spezifischen Einreichung an einen Zahler und deren direkte Verknüpfung mit der Antwort, wie einer Zahlung oder Ablehnung. Sie bietet ein granulareres Maß an Verfolgung innerhalb des breiteren Revenue Cycle Prozesses. Bedeutung Bietet einen spezifischen Identifikator, um den Verlauf eines Anspruchs bei einem Zahler zu verfolgen, was granularer ist als das gesamte Abrechnungsereignis. Datenquelle Diese ID wird von Oracle Health generiert, wenn eine Forderung erstellt wird, und in der primären Forderungstabelle gespeichert. Beispiele CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| Streitgrund DisputeReason | Der vom Kunden oder Patienten angegebene Grund für den Einspruch gegen eine Rechnung oder Leistung. | ||
| Beschreibung Dieses Attribut erfasst den Grund, warum ein Patient oder eine andere verantwortliche Partei eine Rechnung angefochten hat. Gründe können Neine Leistungen, nicht erbrachte Dienstleistungen oder Probleme bei der Versicherungsabwicklung sein. Diese Informationen sind für das Dashboard „Metriken zur Rechnungsstreitbeilegung“ unerlässlich. Das Verständnis der häufigsten Streitgründe hilft, systemische Probleme in den Leistungserfassungs-, Kodierungs- oder Abrechnungsprozessen zu identifizieren. Die Behebung dieser Grundursachen kann die Streitquote und den administrativen Aufwand zur Beilegung erheblich reduzieren. Bedeutung Erklärt, warum Rechnungen angefochten werden, und bietet direkten Einblick in Probleme mit der Abrechnungsgenauigkeit oder -klarheit, die behoben werden müssen. Datenquelle Dies wird wahrscheinlich in einem Case Management- oder Kundenservice-Modul innerhalb von Oracle Health gespeichert, verknüpft mit dem Patienten-Konto. Beispiele Falscher Dienst abgerechnetDoppelte GebührVersicherung Nein abgerechnetLeistung nicht erbracht | |||
Aktivitäten im Revenue Cycle Management
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Anspruch an Zahler übermittelt | Stellt die elektronische oder pAPIerbasierte Einreichung des generierten Anspruchs bei der Versicherungsgesellschaft oder den Antrag bearbeitet.em Zahler dar. Das System sollte Datum und Uhrzeit dieser Übermittlung protokollieren. | ||
| Bedeutung Diese Aktivität startet den Zahlungszyklus. Die Analyse der Zeit von der Einreichung bis zur Zahlung ist maßgeblich, um die Leistung des Zahlers und die Days Sales Outstanding (DSO) zu verstehen. Datenquelle Quelle ist das Forderungsmanagement-Modul, das Übertragungsereignisse protokolliert. Achten Sie auf einen Übermittlungs-Zeitstempel oder eine Statusänderung zu 'Eingereicht' in der Forderungshistorie. Erfassen Ereignis, das protokolliert wird, wenn der Anspruch erfolgreich über das Clearinghouse übermittelt wird. Ereignistyp explicit | |||
| Anspruch generiert | Markiert den Punkt, an dem einzelne Gebühren zu einem formalen Abrechnungsanspruch, wie einer UB-04 oder CMS-1500, zusammengefasst werden. Dies ist ein systemgeneriertes Ereignis, das die initiale Rechnung erstellt. | ||
| Bedeutung Dies ist ein wichtiger Meilenstein, der den Antrag bearbeitet.ie Bereitschaft zur Abrechnung gegenüber einem Zahler signalisiert. Es ist der Endpunkt zur Messung der internen Verzögerung von Leistungserfassung bis Abrechnung. Datenquelle Ein explizites Ereignis, das in den Protokollen oder Tabellen der Forderungsgenerierung erfasst wird. Suchen Sie nach dem Erstellungszeitstempel des primären ForderungsDatensatzes, der den Antrag bearbeitet.em Vorfall zugeordnet ist. Erfassen Ereignis, das bei der Erstellung des AnspruchsDatensatzes protokolliert wird. Ereignistyp explicit | |||
| Konto geschlossen | Die finale Aktivität, die anzeigt, dass der Kontostand null ist und keine weiteren Aktivitäten erwartet werden. Dies wird oft abgeleitet, wenn der Kontostand null erreicht. | ||
| Bedeutung Markiert den erfolgreichen Abschluss des Revenue Cycle. Die Zeit, um diesen Zustand zu erreichen, ist ein Schlüsselmaß für die gesamte Prozesseffizienz. Datenquelle Dies wird in der Regel abgeleitet, indem der erste Zeitpunkt identifiziert wird, an dem der ausstehende Zahlungen identifizieren.ende Kontostand null wird und nach allen Zahlungen und Anpassungen null bleibt. Erfassen Berechnet, wenn der Kontostand nach Verbuchung aller Gebühren und Zahlungen erstmals null beträgt. Ereignistyp calculated | |||
| Patientenfall erstellt | Markiert die Erstellung eines Patientenkontos für einen spezifischen Besuch oder eine Dienstleistung. Dies ist in der Regel ein explizites Ereignis, das vom Registrierungssystem oder einem Aufnahme-/Entlassungs-/Transfer (ADT)-Feed ausgelöst wird. | ||
| Bedeutung Es dient als Ausgangspunkt für den gesamten Revenue Cycle eines gegebenen Abrechnungsereignisses und ermöglicht die Analyse der gesamten Prozessdauer und Registrierungsgenauigkeit. Datenquelle Quelle sind die Protokolle des Patientenregistrierungs- oder ADT-Moduls. Suchen Sie nach Ereignissen zur Fallerstellung oder den Antrag bearbeitet.em frühesten Zeitstempel, der mit dem Fall oder den Antrag bearbeitet.er Finanznummer verbunden ist. Erfassen Ereignis, das bei Patientenregistrierung oder -aufnahme protokolliert wird. Ereignistyp explicit | |||
| Zahlung gebucht | Stellt die Anwendung der vom Zahler erhaltenen Zahlung auf die entsprechenden Gebühren des Patientenkontos dar. Dies ist eine Finanztransaktion, die von einem Benutzer oder einem automatisierten Prozess protokolliert wird. | ||
| Bedeutung Die Effizienz der Zahlungsverarbeitung beeinflusst die Genauigkeit der Debitorenbuchhaltung (Accounts Receivable). Verzögerungen hier können das Finanzbild verzerren und die Sekundärabrechnung verzögern. Datenquelle Zu finden in den Zahlungstransaktionstabellen. Jede Zahlungsbuchung hat eine eindeutige Transaktions-ID und einen zugehörigen Zeitstempel. Erfassen Eine Finanztransaktion wird erfasst, sobald die Zahlung dem Konto zugewiesen wird. Ereignistyp explicit | |||
| Ablehnung angefochten | Eine Benutzer- oder Systemaktion, die anzeigt, dass ein abgelehnter Anspruch angefochten wird. Dies wird in der Regel als Statusaktualisierung oder als spezifische Aufgabe in einer Arbeitswarteschlange erfasst. | ||
| Bedeutung Diese Aktivität initiiert eine Nacharbeits-Schleife. Die Analyse der Häufigkeit und Erfolgsquote von Einsprüchen ist maßgeblich für die Optimierung der Umsatzrückgewinnungsbemühungen. Datenquelle Dies könnte ein explizit vom Benutzer initiiertes Event sein oder aus einer Statusänderung der Forderung, wie 'Angefochten' oder 'In Überprüfung', abgeleitet werden. Erfassen Eine Statusänderung oder ein protokolliertes Ereignis, wenn ein Benutzer den Einspruchsprozess für einen abgelehnten Anspruch einleitet. Ereignistyp explicit | |||
| Ablehnung erhalten | Markiert das Ereignis, bei dem der Zahler einen Anspruch oder spezifische Positionen abgelehnt hat, wie im Zahlungsavis angegeben. Dieses Ereignis wird oft aus den Ablehnungscodes in den ÜberweisungsDaten abgeleitet. | ||
| Bedeutung Die Verfolgung von Ablehnungen ist wichtig für die Identifizierung von Grundursachen, wie Kodierungsfehler oder Berechtigungsprobleme, und die Verbesserung der Clean Claim Rate. Datenquelle Abgeleitet aus den ÜberweisungsDaten (ERA/835). Wenn ein Anspruch oder eine Position einen Ablehnungsbetrag ungleich Null und einen entsprechenden Ablehnungsgrundcode aufweist, wird dieses Ereignis ausgelöst. Erfassen Abgeleitet aus ÜberweisungsDaten, die Ablehnungsgrundcodes (CARCs/RARCs) enthalten. Ereignistyp inferred | |||
| Gebühren erfasst | Stellt die Erfassung abrechenbarer Dienstleistungen oder Posten im Patientenkonto dar. Dies kann automatisch aus klinischen Systemen oder den Antrag bearbeitet.urch manuelle Eingabe des Personals erfolgen. | ||
| Bedeutung Diese Aktivität ist maßgeblich für die Messung des „Charge Lag“ (Verzögerung bei der Leistungserfassung), d. h. der Zeit zwischen Leistungserbringung und Abrechnungsbeginn, was sich direkt auf den Cashflow und die Umsatzintegrität auswirkt. Datenquelle Erfasst aus Gebührentransaktionstabellen, identifiziert durch den Erstellungszeitstempel jeder Gebührenposition. In Oracle Health befindet sich dies oft in gebührenbezogenen Tabellen. Erfassen Transaktionsprotokolleintrag für jede neue Leistung erstellt. Ereignistyp explicit | |||
| Gebühren kodiert | Stellt den Prozess dar, bei dem medizinische Kodierer standardisierte Codes, wie CPT oder ICD-10, den erfassten Gebühren zuweisen. Dies wird oft durch eine Statusänderung der Gebühr oder den Antrag bearbeitet.es Falls verfolgt. | ||
| Bedeutung Verzögerungen bei der Kodierung sind ein häufiger Engpass. Die Nachverfolgung dieser Aktivität hilft, Ineffizienzen im Kodierungs-Workflow und deren Auswirkungen auf die Abrechnungsfristen zu identifizieren. Datenquelle Oft abgeleitet aus einer Statusänderung des Patientenfalls oder den Antrag bearbeitet.er Gebührencharge, zum Beispiel von 'Unkodiert' zu 'Kodiert'. Ein Zeitstempel für diese Statusänderung ist erforderlich. Erfassen Abgeleitet aus einer Statusänderung des Falls oder den Antrag bearbeitet.er Gebühr zu 'Kodiert' oder 'Bereit zur Abrechnung'. Ereignistyp inferred | |||
| Inkassoaktivität gestartet | Zeigt an, dass das Patientenkonto aufgrund von Nichtzahlung in einen Inkassoprozess überführt wurde. Dies wird in der Regel durch eine Änderung der Finanz- oder Statusklasse des Kontos erfasst. | ||
| Bedeutung Dies ist ein kritischer Schritt zur Verwaltung von Forderungsausfällen. Die Analyse dessen, was zu diesem Stadium führt, und seine Erfolgsquote sind wichtig für die finanzielle Gesundheit. Datenquelle Abgeleitet aus einer Statusänderung im Kontostatusfeld zu 'Inkasso' oder 'Uneinbringliche Forderung'. Diese Statusänderung sollte einen zugehörigen Zeitstempel haben. Erfassen Abgeleitet aus einer Kontostatusänderung in den Zustand 'Inkasso' oder einen ähnlichen Status. Ereignistyp inferred | |||
| Konto angepasst | Stellt eine finanzielle Anpassung des Kontostands dar, wie z.B. eine vertragliche Zulage, eine Abschreibung oder einen Rabatt. Jede Anpassung ist eine diskrete Finanztransaktion. | ||
| Bedeutung Anpassungen wirken sich direkt auf die Einnahmen aus. Die Analyse ihrer Häufigkeit, Art und Höhe hilft, Umsatzverluste und Abrechnungsfehler zu identifizieren. Datenquelle Zu finden in Finanztransaktionstabellen. Jede Anpassung wird als separate Position mit einem spezifischen Transaktionscode und Zeitstempel protokolliert. Erfassen Eine Finanztransaktion wird mit einem spezifischen Anpassungscode protokolliert. Ereignistyp explicit | |||
| Korrigierter Anspruch eingereicht | Stellt die Einreichung eines überarbeiteten oder korrigierten Anspruchs beim Zahler dar, oft nach einer Ablehnung oder Anforderung weiterer Informationen. Dies wird durch eine neue Anspruchseinreichung mit einem Korrekturindikator identifiziert. | ||
| Bedeutung Diese Aktivität ist ein wichtiger Bestandteil der Nacharbeits-Schleife im Ablehnungsmanagement. Eine hohe Häufigkeit deutet auf Probleme mit der anfänglichen Forderungsgenauigkeit hin. Datenquelle Erfasst aus den Protokollen der Forderungseinreichung. Suchen Sie nach einer neuen Einreichung für einen bestehenden Vorfall, oft gekennzeichnet durch einen Wiedereinreichungscode oder eine höhere Iterationsnummer. Erfassen Protokolliertes Ereignis für eine erneute Anspruchseinreichung, oft erkennbar an einem spezifischen Anspruchsfrequenztypcodes. Ereignistyp explicit | |||
| Patientenübersicht gesendet | Markiert das Ereignis, bei dem eine Rechnung für die verbleibende Patientenverantwortung erstellt und an den Patienten gesendet wird. Dies ist eine explizite Aktion, die vom Patientenabrechnungsmodul protokolliert wird. | ||
| Bedeutung Dies initiiert den Patienten-Zahlungsanteil des Revenue Cycle. Die Verfolgung dessen hilft bei der Analyse der Effektivität von Patienteneinzahlungen. Datenquelle Quelle sind Patientenabrechnungs- oder Korrespondenzprotokolle. Das System sollte das Datum der Generierung oder den Antrag bearbeitet.es Versands jeder Abrechnung erfassen. Erfassen Ereignis, das protokolliert wird, wenn eine Patientenabrechnung erstellt und gedruckt oder elektronisch versendet wird. Ereignistyp explicit | |||
| Überweisung erhalten | Zeigt den Erhalt einer elektronischen Zahlungsmitteilung (ERA) oder einer schriftlichen Leistungsbeschreibung (EOB) vom Zahler an. Dieses Dokument detailliert, welche Gebühren bezahlt, abgelehnt oder angepasst wurden. | ||
| Bedeutung Dies ist die erste Antwort des Zahlers und wichtig für das Verständnis der Zahlungsgeschwindigkeit und die frühzeitige Identifizierung von Ablehnungstrends. Datenquelle Erfasst im Überweisungsverarbeitungsmodul. Suchen Sie nach dem Import- oder Erstellungs-Zeitstempel der ERA-Datei, wie einer 835 Transaktionsdatei, die mit dem Anspruch verknüpft ist. Erfassen Ereignis, das beim Import und der Verarbeitung der Überweisungsdatei des Zahlers (z.B. ANSI 835) protokolliert wird. Ereignistyp explicit | |||
Extraktionsanleitungen
Schritte
- Datenbankzugriff anfordern: Besorgen Sie sich schreibgeschützte AnmeldeHinweisrmationen für die Oracle Health Revenue Cycle Management Managementmanagement Datenbank. Sie benötigen Zugriff auf die Schemata, die Patienten-, Fall-, Abrechnungs- und FinanztransaktionsDaten enthalten. Dies erfordert in der Regel die Genehmigung der IT-Sicherheits- und Datenbankadministrationsteams.
- Schema- und Tabellennamen identifizieren: Arbeiten Sie mit einem Datenbankadministrator oder einem Systemanalysten zusammen, um die genauen Schema- und Tabellennamen für Ihre Oracle Health Instanz zu bestätigen. Die in der Abfrage angegebenen Namen sind gängige Platzhalter und müssen Ihrem spezifischen Umfeld zugeordnet werden.
- SQL-Client installieren: Installieren Sie einen kompatiblen SQL-Client, wie z.B. Oracle SQL Developer oder DBeaver, auf Ihrer Workstation. Dieses Tool wird verwendet, um eine Verbindung zur Datenbank herzustellen und das Extraktionsskript auszuführen.
- Datenbankverbindung herstellen: Konfigurieren Sie eine neue Datenbankverbindung in Ihrem SQL-Client unter Verwendung des bereitgestellten Hosts, Ports, Servicenamens und der AnmeldeHinweisrmationen. Testen Sie die Verbindung, um sicherzustellen, dass sie erfolgreich ist.
- SQL-Abfrage anpassen: Kopieren Sie das bereitgestellte SQL-Skript in ein neues Abfrageeditorfenster. Suchen Sie die Platzhalterwerte, wie
[START_DATE]und[END_DATE], und ersetzen Sie diese durch den gewünschten Datumsbereich für Ihre Analyse (z.B. '2023-01-01'). Passen Sie alle Filterbedingungen an Ihre spezifischen Analyseanforderungen an, z.B. das Filtern nach einer bestimmten Patient Class. - Extraktionsskript ausführen: Führen Sie das angepasste SQL-Skript aus. Die Abfrage ist vollständig konzipiert und kann je nach Datumsbereich und Größe Ihrer Datenbank mehrere Minuten bis Stunden dauern.
- Erste Resultate überprüfen: Sobald die Abfrage abgeschlossen ist, überprüfen Sie die ersten paar hundert Zeilen in der Ergebnistabelle Ihres SQL-Clients. Suchen Sie nach offensichtlichen Fehlern, wie z.B. nur Null-Werten in Spalten oder Neinen Datenformaten, um sicherzustellen, dass das Skript korrekt ausgeführt wurde.
- Daten nach CSV exportieren: Exportieren Sie den gesamten Ergebnissatz in eine CSV-Datei. Verwenden Sie die UTF-8-Kodierung, um Zeichenprobleme zu vermeiden. Stellen Sie sicher, dass die exportierte Datei eine Kopfzeile mit den in den Abfragealiasen angegebenen Spaltennamen enthält (z.B. "BillingEvent", "ActivityName").
- Für den Upload vorbereiten: Bevor Sie die Datei in ein Process-Mining-Tool hochladen, öffnen Sie die CSV-Datei, um ihre Integrität zu überprüfen. Stellen Sie sicher, dass das Zeitstempel-Format konsistent ist und die Spaltenüberschriften exakt mit den erforderlichen Attributen übereinstimmen. Die Datei ist nun bereit für den Upload.
Konfiguration
- Datumsbereich: Die Abfrage verwendet die Platzhalter
[START_DATE]und[END_DATE]. Es ist maßgeblich, einen spezifischen und angemessenen Datumsbereich festzulegen, um das Datenvolumen zu steuern. Für eine erste Analyse wird ein Zeitraum von 3 bis 6 Monaten empfohlen. - Filterung: Der anfängliche Datensatz wird nach dem Registrierungsdatum des Falls (
reg_dt_tm) im AbschnittRelevantEncountersgefiltert. Sie können diesem Abschnitt weitereWHERE-Klauseln hinzufügen, um den Umfang einzugrenzen, z.B.e.patient_class_code IN ('INPATIENT', 'OUTPATIENT'), um sich auf spezifische Falltypen zu konzentrieren. - Leistungsfähigkeit: Direkte Datenbankabfragen auf einem Produktionssystem können die Leistungsfähigkeit beeinträchtigen. Es wird dringend empfohlen, diese Extraktion außerhalb der Spitzenzeiten oder, falls verfügbar, auf einer schreibgeschützten Replik der ProduktionsDatenbank durchzuführen.
- Voraussetzungen: Diese Methode erfordert ein Datenbankbenutzerkonto mit
SELECT-Berechtigungen für alle in der Abfrage referenzierten Tabellen. Zu diesen Tabellen gehören Encounter-, Billing-, Charge-, Claim-, Remittance- und Finanztransaktionstabellen. - Tabellen- und Spaltenzuordnung: Das bereitgestellte Skript verwendet gebräuchliche, repräsentative Namen für Tabellen und Spalten. Sie müssen diese validieren und den tatsächlichen Namen im Oracle Health-Datenbankschema Ihrer Organisation zuordnen. Beispielsweise könnte
FINANCIAL_TRANSACTIONin Ihrem System alsAR_TRANSACTIONSbenannt sein.
a 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;