Ihr Daten-Template für Revenue Cycle Management
Ihr Daten-Template für Revenue Cycle Management
- Empfohlene zu erfassende Attribute
- Wichtige zu erfassende Aktivitäten
- Hinweise zur Extraktion
Attribute des Umsatzzyklusmanagements
| Name | Beschreibung | ||
|---|---|---|---|
| Abrechnungsvorgang BillingEvent | Die eindeutige Kennung für die Erbringung einer einzelnen Leistung oder Lieferung eines Produkts, die eine Belastung erzeugt und als primäre Case-ID dient. | ||
| Beschreibung Der Billing Event ist die zentrale Kennung, die alle Aktivitäten innerhalb des Abrechnungszyklus für eine bestimmte abrechenbare Position verbindet. Er beginnt mit der Erbringung einer Leistung und endet, sobald das Konto vollständig ausgeglichen oder geschlossen ist. In der Process-Mining-Analyse ist dieses Attribut entscheidend für die Rekonstruktion des durchgängigen Ablaufs jeder Belastung. Es ermöglicht die Nachverfolgung von Aktivitäten wie Belastungserfassung, Claim-Übermittlung, Zahlungsverbuchung und Ablehnungsbearbeitung für einzelne Billing Events. Dadurch wird der Prozessablauf einschließlich seiner Varianten transparent. Warum das wichtig ist Dies ist die grundlegende Case-ID, die alle zusammengehörigen Prozessschritte für die Analyse des vollständigen Lebenszyklus der Umsatzgenerierung und Zahlung für jede Leistung verknüpft. Bezugsquelle Dies ist häufig eine eindeutige Kennung für ein Krankenhauskonto (HAR) oder eine bestimmte Belastungssitzung in Epic Resolute. Einzelheiten zu Tabellen wie HAR oder Charge Session finden Sie in der Dokumentation zu Epic Resolute. Beispiele BE10098765BE20012345BE30054321 | |||
| Aktivitätsname ActivityName | Der Name des spezifischen Ereignisses oder der Aufgabe, die innerhalb des Revenue-Cycle-Management-Prozesses ausgeführt wird. | ||
| Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt im Abrechnungszyklus, etwa „Belastungen erfasst“, „Claim an Kostenträger übermittelt“ oder „Zahlung eingegangen“. Jede Aktivität stellt einen eigenständigen Meilenstein im Prozess der Abrechnung und Zahlungseinziehung für eine Leistung dar. Die Analyse von Aktivitäten bildet die Grundlage für Process Mining. Sie ermöglicht die Visualisierung der Prozesslandkarte, die Identifizierung gängiger Abläufe, das Erkennen von Engpässen zwischen Schritten und die Messung der Konformität mit Standardarbeitsanweisungen. Warum das wichtig ist Definiert die Schritte in der Prozesslandkarte und ermöglicht dadurch, den Arbeitsablauf im Abrechnungszyklus zu visualisieren, zu analysieren und zu optimieren. Bezugsquelle Wird in der Regel aus Event Logs, Audit-Trails oder Statusänderungsdatensätzen innerhalb der Abrechnungs- und Claim-Module von Epic Resolute abgeleitet. Beispiele Gebühren erfasstAnspruch beim Kostenträger eingereichtZahlung eingegangenKonto geschlossen | |||
| Ereignis-Timestamp EventTimestamp | Das genaue Datum und die genaue Uhrzeit, zu denen eine bestimmte Aktivität oder ein Ereignis stattgefunden hat. | ||
| Beschreibung Der Event Timestamp erfasst den Zeitpunkt, an dem eine Aktivität stattgefunden hat. Diese zeitbezogenen Daten sind entscheidend, um Zeitpunkt und Reihenfolge der Ereignisse im Abrechnungszyklus zu verstehen. In der Analyse dienen Timestamps zur Berechnung der Dauer zwischen Aktivitäten, etwa der Verzögerung bei der Belastungserfassung oder der Zeit bis zur Zahlungsverbuchung. Sie ermöglichen das Erkennen von Engpässen, die Messung von Durchlaufzeiten und die Analyse der Prozessleistung über verschiedene Zeiträume. Genaue Timestamps sind für nahezu alle zeitbasierten KPIs und Dashboards unverzichtbar. Warum das wichtig ist Dieses Attribut ist für die Berechnung aller zeitbasierten Kennzahlen einschließlich Durchlaufzeiten und Dauern unverzichtbar. Diese Kennzahlen bilden die Grundlage für das Erkennen von Verzögerungen und Ineffizienzen. Bezugsquelle Zu finden in Transaktions- oder Event-Log-Tabellen innerhalb von Epic Resolute, jeweils einer erfassten Aktivität zugeordnet. Feldnamen enthalten häufig Endungen wie Dt, DTTM oder Time. Beispiele 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Abrechnungsabteilung BillingDepartment | Die Abteilung oder das Funktionsteam, das für den Abrechnungsvorgang oder die Aktivität verantwortlich ist. | ||
| Beschreibung Dieses Attribut bezeichnet die Organisationseinheit, etwa „Stationäre Abrechnung“, „Ambulante Abrechnung“ oder „Team für Ablehnungsmanagement“, die mit dem Abrechnungsvorgang verbunden ist oder eine bestimmte Aktivität ausgeführt hat. Diese Dimension ist für das Dashboard „Leistungskennzahlen der Abrechnungsabteilungen“ entscheidend. Sie ermöglicht den direkten Vergleich zentraler Kennzahlen wie Ablehnungsquoten oder Zeiten der Belastungserfassung. Das Management kann dadurch leistungsstarke Abteilungen erkennen, bewährte Verfahren standardisieren und Ressourcen gezielt zuweisen. Warum das wichtig ist Ermöglicht den Leistungsvergleich zwischen verschiedenen Abteilungen und hilft, bewährte Verfahren sowie Bereiche mit Verbesserungs- oder zusätzlichem Ressourcenbedarf zu erkennen. Bezugsquelle Diese Information kann mit dem Benutzerdatensatz, dem Patientenkonto oder dem Leistungsort in Epic Resolute verknüpft sein. Beispiele Abrechnung der KardiologieRCM der RadiologieZentrale Abrechnungsstelle | |||
| Grund der Anpassung AdjustmentReason | Der Grund für eine manuelle oder automatisierte Anpassung des Kontosaldos eines Patienten. | ||
| Beschreibung Dieses Attribut erklärt, warum ein Kontosaldo außerhalb einer regulären Zahlung oder Belastung geändert wurde. Gründe können vertragliche Vereinbarungen mit Kostenträgern, Ausbuchungen geringfügiger Salden oder Korrekturen von Verbuchungsfehlern sein. Es ist für das Dashboard „Volumen der Kontoanpassungen nach Typ“ entscheidend. Die Analyse der Anpassungsgründe hilft Organisationen, Quellen von Umsatzverlusten zu erkennen, die Auswirkungen von Kostenträgerverträgen zu verstehen und mögliche Ineffizienzen oder Fehler im Abrechnungsprozess aufzudecken. Warum das wichtig ist Liefert Erkenntnisse zu Umsatzverlusten und Abrechnungsgenauigkeit, indem es erklärt, warum Kontosalden geändert werden. Dadurch lassen sich unnötige Ausbuchungen reduzieren. Bezugsquelle Zu finden in den Transaktionsdetails von Anpassungseinträgen innerhalb des Patientenbuchhaltungsmoduls von Epic Resolute. Beispiele Vertraglicher AbzugAbschreibung eines kleinen RestbetragsKorrektur einer doppelten Gebühr | |||
| Leistungsart ServiceType | Die Kategorie oder Art der erbrachten medizinischen Leistung. | ||
| Beschreibung Dieses Attribut klassifiziert die abrechenbare Leistung, etwa als „Radiologie“, „Chirurgie“, „Konsultation“ oder „Notaufnahmebesuch“. Es liefert den klinischen Kontext zu den Finanzdaten. Die Analyse des Abrechnungszyklus nach Leistungsart kann Prozessvarianten aufdecken, die für bestimmte klinische Bereiche typisch sind. Chirurgische Eingriffe können beispielsweise eine komplexere Belastungserfassung und strengere Anforderungen an Genehmigungen haben als ein gewöhnlicher Praxisbesuch. Dadurch entstehen unterschiedliche Prozessabläufe und Herausforderungen. Warum das wichtig ist Liefert den klinischen Kontext zu Finanzdaten und ermöglicht die Analyse, wie unterschiedliche medizinische Leistungen den Abrechnungszyklus und seine Effizienz beeinflussen. Bezugsquelle Abgeleitet aus dem Charge Description Master (CDM), der Leistungszeile oder der Abteilung, die in Epic mit der Belastungstransaktion verknüpft ist. Beispiele Stationäre OperationAmbulante RadiologieNotfallleistungen | |||
| Offener Saldo OutstandingBalance | Der verbleibende Betrag, den der Kostenträger oder Patient für den Abrechnungsvorgang schuldet. | ||
| Beschreibung Dieses Attribut stellt den aktuellen Forderungssaldo für einen bestimmten Abrechnungsvorgang zum Zeitpunkt der Aktivität dar. Es bildet den finanziellen Status des Cases über dessen gesamten Lebenszyklus ab. Der offene Saldo ist für das Finanzreporting und den „Bericht zur Altersstruktur offener Salden“ entscheidend. Die Analyse dieses Werts über die Zeit und nach Dimensionen wie Kostenträger oder Abteilung hilft, Inkassomaßnahmen zu priorisieren, den Cashflow zu steuern und finanzielle Risiken zu bewerten. Warum das wichtig ist Misst unmittelbar die finanziellen Auswirkungen von Prozessverzögerungen und ist entscheidend für die Priorisierung des Inkassos, die Cashflow-Steuerung und das Verständnis der Forderungen. Bezugsquelle Dies ist ein zentrales Feld im Patienten- oder Krankenhauskontodatensatz (HAR) von Epic Resolute. Es handelt sich um einen laufenden Saldo, der durch Finanztransaktionen aktualisiert wird. Beispiele 1500.00250.750.00 | |||
| Ursachencode der Ablehnung DenialReasonCode | Ein standardisierter Code, der den Grund angibt, aus dem ein Kostenträger einen übermittelten Claim abgelehnt hat. | ||
| Beschreibung Wenn ein Kostenträger einen Claim ablehnt, übermittelt er einen Ursachencode, der die Ablehnung erklärt, etwa „Nicht abgedeckte Leistung“, „Doppelter Claim“ oder „Zusätzliche Informationen erforderlich“. Diese Codes sind häufig als Claim Adjustment Reason Codes (CARCs) standardisiert. Dieses Attribut bildet die Grundlage für das Dashboard „Ablehnungsquoten und -gründe von Claims“. Die Analyse der Häufigkeit verschiedener Ablehnungscodes hilft, die Ursachen von Ablehnungen zu erkennen, etwa Probleme bei der Zulassung, Codierungsfehler oder fehlende Vorabgenehmigungen. Dadurch lassen sich gezielte Verbesserungsmaßnahmen einleiten. Warum das wichtig ist Erklärt unmittelbar, warum Claims abgelehnt werden, und liefert verwertbare Erkenntnisse, um Ablehnungsquoten und Umsatzverluste zu senken sowie Zahlungen zu beschleunigen. Bezugsquelle Diese Daten finden sich in den von Kostenträgern empfangenen Claim-Antworttransaktionen, etwa einer ANSI-835-Datei, und werden im Claim-Management-Modul von Epic Resolute gespeichert. Beispiele CO-16: Der Anspruch bzw. die Leistung enthält nicht die erforderlichen InformationenOA-18: Doppelter Anspruch bzw. doppelte LeistungPR-96: Nicht erstattungsfähige Gebühr(en) | |||
| Verantwortlicher Benutzer ResponsibleUser | Die Kennung des Benutzers oder Mitarbeiters, der die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut erfasst die Benutzer-ID, den Namen oder die Mitarbeiternummer der Person, die für die Ausführung einer bestimmten Aufgabe im Abrechnungszyklus verantwortlich ist. Dabei kann es sich um den Kliniker handeln, der Belastungen erfasst, den Abrechnungsmitarbeiter, der einen Claim übermittelt, oder den Sachbearbeiter, der eine Ablehnung nachverfolgt. Die Analyse nach Benutzer hilft, besonders leistungsstarke Mitarbeitende zu erkennen, Schulungsbedarf zu bestimmen und die Arbeitslastverteilung zu verstehen. Sie ist für das Leistungsmanagement sowie für die Untersuchung von Prozessabweichungen einzelner Personen oder Rollen entscheidend. Warum das wichtig ist Ermöglicht die Leistungsanalyse nach Person oder Rolle und hilft, Schulungsmöglichkeiten, unausgewogene Arbeitslasten sowie ressourcenbedingte Engpässe zu erkennen. Bezugsquelle Typischerweise in Audit-Trails oder Transaktionsprotokollen innerhalb von Epic Resolute zu finden, häufig verknüpft mit einer Tabelle für Benutzerm Stammdaten, etwa einem EMP-Datensatz. Beispiele j.doebsmith123User7890 | |||
| Angepasster Betrag AdjustedAmount | Der Geldbetrag einer Anpassungstransaktion. | ||
| Beschreibung Dieses Feld erfasst den konkreten Betrag einer Kontoanpassung. Der Wert kann positiv oder negativ sein und eine Gutschrift oder Belastung des Kontosaldos darstellen. Dieser Betrag ist die zentrale Kennzahl für das Dashboard „Volumen der Kontoanpassungen nach Typ“. Die Summierung nach Anpassungsgrund zeigt die finanziellen Auswirkungen verschiedener Anpassungstypen. So wird beispielsweise sichtbar, wie viel Umsatz aufgrund vertraglicher Verpflichtungen ausgebucht wird und wie viel durch korrigierbare Fehler verloren geht. Warum das wichtig ist Quantifiziert die finanziellen Auswirkungen von Kontoanpassungen und ermöglicht dadurch die Messung von Umsatzverlusten sowie der Kosten von Abrechnungsfehlern. Bezugsquelle Zu finden in den Detailtabellen der Finanztransaktionen von Epic Resolute, verknüpft mit Transaktionen des Typs Anpassung. Beispiele -1250.45-50.0025.10 | |||
| Claim-ID ClaimId | Die eindeutige Kennung eines bei einem Kostenträger eingereichten Versicherungsclaims. | ||
| Beschreibung Dieses Attribut ist die spezifische ID des an einen Kostenträger gesendeten Claim-Formulars, etwa CMS-1500 oder UB-04. Ein einzelner Abrechnungsvorgang kann mehrere Claims umfassen, wenn Leistungen erneut abgerechnet oder Einsprüche eingelegt werden. Die Nachverfolgung anhand der Claim-ID eignet sich für die detaillierte Analyse der Claim-Übermittlung und der Teilprozesse zur Ablehnungsbearbeitung. Sie hilft, Aktivitäten des ursprünglichen Claims von Aktivitäten eines später erneut übermittelten Claims für dieselbe Leistung zu unterscheiden. Warum das wichtig ist Liefert eine detaillierte Kennung zur Nachverfolgung des Lebenszyklus jeder einzelnen Claim-Übermittlung. Das ist entscheidend für die Analyse erneuter Übermittlungen und Einsprüche. Bezugsquelle Wird vom Claim-Management-Modul von Epic Resolute erstellt, sobald ein Claim angelegt wird, und in den Claim-Datentabellen gespeichert. Beispiele CLM-2023-98765CLAIM-0012345623189A4567 | |||
| Endzeit des Ereignisses EventEndTime | Der Timestamp, der angibt, wann eine Aktivität abgeschlossen wurde. Er eignet sich zur Berechnung der Aktivitätsdauer. | ||
| Beschreibung Dieses Attribut erfasst den Abschlusszeitpunkt einer Aktivität. Viele Aktivitäten sind unmittelbare Ereignisse, bei denen StartTime und EndTime identisch sind. Einige Aufgaben haben jedoch eine messbare Dauer, etwa ein Nachfassanruf zu einer Ablehnung. Wenn EndTime verfügbar ist, lässt sich die Bearbeitungszeit einer Aktivität direkt berechnen, nämlich „EndTime“ minus „StartTime“. Das ist genauer, als die Dauer aus der Startzeit der nächsten Aktivität abzuleiten, da die Leerlaufzeit zwischen den Schritten berücksichtigt wird. EndTime ist ein zentraler Bestandteil für die Berechnung des Attributs „ProcessingTime“. Warum das wichtig ist Ermöglicht die präzise Berechnung der Dauer jeder Aktivität. Das ist entscheidend, um ineffiziente Aufgaben zu erkennen und die Produktivität von Ressourcen zu messen. Bezugsquelle Kann in einigen Epic-Resolute-Modulen verfügbar sein, die Start und Ende von Aufgaben erfassen, etwa in Workqueue- oder Aktivitätsmanagement-Protokollen. Häufig wird dieser Wert jedoch nicht ausdrücklich erfasst. Beispiele 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| Gesamtdauer des Abrechnungszyklus TotalRevenueCycleTime | Die insgesamt berechnete Dauer vom ersten Leistungserbringungsereignis bis zur abschließenden Zahlung oder Kontoschließung. | ||
| Beschreibung Dies ist eine KPI auf Case-Ebene, die die durchgängige Dauer des Abrechnungszyklus für einen einzelnen Abrechnungsvorgang misst. Sie wird in der Regel als Zeitdifferenz zwischen der Aktivität „Leistung erbracht“ und der abschließenden Aktivität „Zahlung eingegangen“ oder „Konto geschlossen“ berechnet. Diese übergeordnete Kennzahl bietet einen umfassenden Überblick über die Effizienz des RCM-Prozesses. Die Beobachtung dieser KPI über die Zeit zeigt die Auswirkungen von Prozessverbesserungen und liefert einen wichtigen Indikator für die Geschwindigkeit der Cash-Conversion. Warum das wichtig ist Liefert einen übergeordneten, durchgängigen Blick auf die Prozesseffizienz und misst direkt, wie lange die Umwandlung einer Leistung in Zahlung dauert. Bezugsquelle Diese Kennzahl wird innerhalb des Process-Mining-Tools berechnet, indem für jeden Case das erste und letzte Ereignis gefiltert und die Zeitdifferenz ermittelt wird. Beispiele 259200038880005184000 | |||
| Ist automatisiert IsAutomated | Ein boolesches Kennzeichen, das angibt, ob die Aktivität von einem System oder einem automatisierten Prozess ausgeführt wurde. | ||
| Beschreibung Dieses Kennzeichen unterscheidet automatisch vom System ausgeführte Aufgaben, etwa die automatische Claim-Erstellung oder Berechtigungsprüfungen, von Aufgaben, die manuell durch einen Benutzer ausgeführt werden. Die Analyse dieses Attributs hilft, den Automatisierungsgrad des Prozesses zu verstehen. Sie ermöglicht den Vergleich von Effizienz und Fehlerquoten automatisierter und manueller Aktivitäten, die Identifizierung weiterer Automatisierungsmöglichkeiten sowie die Überwachung bestehender Bots oder Systemregeln. Warum das wichtig ist Unterscheidet systemgesteuerte von menschlich ausgeführten Aktivitäten. Das ist entscheidend, um die Auswirkungen der Automatisierung zu bewerten und weitere Automatisierungsmöglichkeiten zu erkennen. Bezugsquelle Wird häufig daraus abgeleitet, ob es sich beim „ResponsibleUser“ einer Aktivität um ein System- oder Servicekonto handelt, oder indem bestimmte bekanntermaßen automatisierte Aktivitätsnamen gekennzeichnet werden. Beispiele truefalse | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, der angibt, wann die Daten für dieses Ereignis zuletzt aktualisiert oder aus dem Quellsystem extrahiert wurden. | ||
| Beschreibung Dieses Attribut zeigt die Aktualität der Daten. Es gibt an, wann der Datensatz zuletzt aus Epic Resolute in den Process-Mining-Datensatz übernommen wurde. Dies ist wichtig, um die Aktualität der Analyse zu beurteilen und Daten zu validieren. Sie erkennen dadurch, ob Sie die aktuell verfügbaren Informationen betrachten. Außerdem ist das Attribut für die Steuerung von Datenaktualisierungszyklen entscheidend. Warum das wichtig ist Stellt sicher, dass die Aktualität der analysierten Daten nachvollziehbar bleibt. Das ist entscheidend für präzise und aktuelle Geschäftsentscheidungen. Bezugsquelle Dieser Timestamp wird während der Datenaufnahme durch den ETL-Prozess (Extract, Transform, Load) ergänzt. Beispiele 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| Name des Kostenträgers PayerName | Der Name des Versicherungsunternehmens, der staatlichen Stelle oder einer anderen Partei, die für die Zahlung verantwortlich ist. | ||
| Beschreibung Dieses Attribut identifiziert den primären Kostenträger des Abrechnungsvorgangs, etwa „Blue Cross Blue Shield“, „Medicare“ oder „Aetna“. Bei Selbstzahlern kann es den Patienten angeben. Die Segmentierung des Prozesses nach Kostenträger ist eine wirkungsvolle Analysemethode. Sie kann zeigen, dass bestimmte Kostenträger höhere Ablehnungsquoten, längere Zahlungszyklen oder komplexere Anforderungen haben. Diese Erkenntnis ermöglicht es, Abrechnungsstrategien gezielt auf einzelne Kostenträger auszurichten und dadurch Effizienz und Zahlungsgeschwindigkeit zu verbessern. Warum das wichtig ist Ermöglicht die Leistungsanalyse nach Kostenträger und zeigt, welche Kostenträger hohe Ablehnungsquoten oder langsame Zahlungszyklen aufweisen. Dadurch lassen sich gezielte Nachverfolgungsstrategien entwickeln. Bezugsquelle Diese Information ist Bestandteil der Versicherungsdaten des Patienten und in Epic Resolute mit dem Krankenhauskonto (HAR) verknüpft. Beispiele Medicare Teil BUnitedHealthcareAetna PPO | |||
| Patienten-ID PatientId | Die eindeutige Kennung des Patienten, der die Leistung erhält. | ||
| Beschreibung Dieses Attribut ist die Medical Record Number (MRN) oder eine andere eindeutige Patientenkennung. Es verknüpft den finanziellen Abrechnungsvorgang mit einer bestimmten Person. Zum Schutz der Privatsphäre wird es in der Regel nicht als primäre Analysedimension verwendet. Für die Datenvalidierung ist es jedoch unverzichtbar. Außerdem kann es genutzt werden, um alle Abrechnungsvorgänge eines Patienten zusammenzufassen und dessen gesamten finanziellen Verlauf zu verstehen. Auch für eine mögliche Integration klinischer Prozessdaten ist es entscheidend. Warum das wichtig ist Verknüpft Finanzdaten mit einem bestimmten Patienten und ermöglicht dadurch die Datenvalidierung sowie eine umfassendere Analyse des Patientenverlaufs. Aufgrund von Datenschutzanforderungen muss das Attribut jedoch sorgfältig verarbeitet werden. Bezugsquelle Eine grundlegende Kennung, die in Epic an vielen Stellen zu finden und mit den Registrierungs- und Kontodatensätzen des Patienten verknüpft ist. Beispiele MRN-1234567MRN-8765432MRN-5551234 | |||
| Quellsystem SourceSystem | Das Informationssystem, aus dem die Daten stammen. | ||
| Beschreibung Dieses Attribut identifiziert das Quellsystem des Datensatzes, in diesem Kontext Epic Resolute. In Umgebungen mit mehreren integrierten Systemen hilft dieses Feld, die Datenherkunft zu unterscheiden. Auch wenn es in einer Betrachtung mit nur einem System überflüssig erscheinen mag, entspricht es einer bewährten Praxis für Data Governance und Skalierbarkeit. So bleibt die Herkunft eindeutig, wenn später Daten aus anderen Systemen, etwa einer separaten Inkasso-Plattform, integriert werden. Warum das wichtig ist Liefert wichtige Informationen zur Datenherkunft und zum Kontext. Dadurch bleibt der Ursprung der Daten nachvollziehbar, was für Data Governance und die Fehlerbehebung entscheidend ist. Bezugsquelle Dies ist in der Regel ein statischer Wert, der während der Datenextraktion und -transformation ergänzt wird, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Epic ResoluteEpicResolute_V2023 | |||
| Zahlungsziel PaymentDueDate | Das Datum, bis zu dem die Zahlung für die abgerechnete Leistung erwartet wird. | ||
| Beschreibung Dieses Attribut legt die Zahlungsfrist fest, wie sie auf der Rechnung angegeben oder durch Verträge mit Kostenträgern bestimmt wird. Es dient als Referenz für die Messung fristgerechter Zahlungen. Das Zahlungsziel ist für die Erstellung des „Berichts zur Altersstruktur offener Salden“ entscheidend. Durch den Vergleich des aktuellen Datums mit dem Zahlungsziel offener Salden lassen sich Forderungen in Altersklassen einteilen, etwa 0 bis 30 Tage oder 31 bis 60 Tage überfällig. So können Inkassomaßnahmen auf die am längsten überfälligen Konten konzentriert werden. Warum das wichtig ist Dient als Grundlage für die Altersstrukturanalyse von Forderungen. Diese ist entscheidend für die Priorisierung des Inkassos und die Steuerung finanzieller Risiken aus unbezahlten Rechnungen. Bezugsquelle Dieses Datum wird häufig anhand des Rechnungsdatums und der Zahlungsbedingungen berechnet, die im Vertrag mit dem Kostenträger oder in den Kontoinformationen des Patienten in Epic gespeichert sind. Beispiele 2023-05-302023-06-152023-07-01 | |||
Aktivitäten des Umsatzzyklusmanagements
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Anspruch beim Kostenträger eingereicht | Dieses Ereignis kennzeichnet den Zeitpunkt, an dem der Claim offiziell zur Prüfung an den Versicherungskostenträger gesendet wird. In Epic wird es als nachverfolgbares Ereignis protokolliert, sobald die elektronische Claim-Datei an das Clearinghouse oder den Kostenträger übertragen wurde. | ||
| Warum das wichtig ist Dieser Meilenstein ist entscheidend, weil damit die Frist für die Zahlung durch den Kostenträger beginnt. Die Analyse hilft, die Effizienz der Claim-Übermittlung zu messen, und unterstützt die KPI „Invoice to Payer Delivery Time“. Bezugsquelle Dies ist ein explizites Ereignis, das in Resolute erfasst wird. Der Claim-Datensatz enthält einen Übermittlungsstatus und einen Timestamp, der den Versandzeitpunkt angibt. Erfassen Erfassen Sie den Timestamp, der mit der Änderung des Claim-Status in „Submitted“ oder „Transmitted“ verbunden ist. Ereignistyp explicit | |||
| Anspruch vom Kostenträger abgelehnt | Diese Aktivität bezeichnet den Eingang einer Mitteilung des Kostenträgers, dass der Claim abgelehnt wurde. Sie wird erfasst, wenn Epic eine elektronische Zahlungsavis-Datei (835-Datei) verarbeitet oder ein Benutzer eine Ablehnung manuell verbucht. | ||
| Warum das wichtig ist Diese Aktivität leitet eine wichtige Nacharbeitschleife ein. Die Analyse von Ablehnungsgründen und -volumen ist entscheidend, um Ursachen zu erkennen, die Zahlungsquote beim ersten Einreichungsversuch zu verbessern und Verzögerungen bei der Umsatzrealisierung zu reduzieren. Bezugsquelle Explizit als Transaktion oder Statusaktualisierung des Claims erfasst. Informationen zur Ablehnung, einschließlich der Ursachencodes, gehen typischerweise elektronisch ein und werden auf dem Konto verbucht. Erfassen Filtern Sie nach bestimmten Transaktionstypen oder Claim-Statusaktualisierungen, die auf eine Ablehnung hinweisen. Ereignistyp explicit | |||
| Gebühren erfasst | Diese Aktivität bezeichnet die formale Erfassung der abrechenbaren Charges für die erbrachten Leistungen. In Epic handelt es sich dabei typischerweise um eine explizite Transaktion, die auf dem Patientenkonto verbucht wird. Sie wird häufig automatisch aus klinischen Aktivitäten erzeugt oder manuell eingegeben. | ||
| Warum das wichtig ist Dies ist ein entscheidender erster Meilenstein. Die Messung von Geschwindigkeit und Genauigkeit der Charge Capture hilft, den Abrechnungsprozess zu beschleunigen und sicherzustellen, dass alle erbrachten Leistungen abgerechnet werden. Bezugsquelle Explizit in den Transaktions-Logs von Resolute erfasst. Jede Charge ist ein separater Eintrag mit Buchungsdatum, Leistungsdatum und Betrag und findet sich häufig in Tabellen wie ARPB_TRANSACTIONS. Erfassen Erfassen Sie die Buchungstransaktionen der Charges aus dem Finanztransaktions-Log des Systems. Ereignistyp explicit | |||
| Konto geschlossen | Dies ist die abschließende Aktivität. Sie zeigt an, dass der offene Saldo des Abrechnungsvorgangs null erreicht hat und keine weiteren Aktivitäten ausstehen. Ursache können eine vollständige Zahlung, Anpassungen oder eine Ausbuchung sein. | ||
| Warum das wichtig ist Dieses Ereignis kennzeichnet den erfolgreichen Abschluss des Abrechnungszyklus für einen Abrechnungsvorgang. Die Gesamtdauer von der Leistungserbringung bis zum Abschluss ist eine wichtige KPI für die Effizienz des Gesamtprozesses. Bezugsquelle Dies ist in der Regel ein abgeleitetes Ereignis. Es wird anhand des Zeitpunkts bestimmt, an dem der Kontosaldo des Abrechnungsvorgangs null erreicht und null bleibt. Erfassen Abgeleitet durch die Berechnung einer laufenden Summe des Kontosaldos und die Ermittlung des Timestamps der letzten Transaktion, durch die der Saldo null erreicht wurde. Ereignistyp inferred | |||
| Leistung erbracht | Diese Aktivität kennzeichnet den Zeitpunkt, an dem eine klinische Leistung für den Patienten erbracht wird und das Billing Event beginnt. Häufig wird sie aus dem Epic EHR (EpicCare) übernommen, sobald ein Kliniker einen Besuch oder eine Behandlung abschließt. | ||
| Warum das wichtig ist Dies ist das primäre Start-Ereignis des Revenue Cycle. Die Analyse der Zeit von diesem Punkt bis zur Charge Capture ist entscheidend, um Verzögerungen beim Beginn der Abrechnung und mögliche Umsatzverluste zu erkennen. Bezugsquelle Dieses Ereignis wird in der Regel aus Service- oder Besuchs-Timestamps in den klinischen Modulen abgeleitet, die mit dem Abrechnungskonto verknüpft sind. Das Leistungsdatum der Charge-Transaktion ist dabei der zentrale Datenpunkt. Erfassen Abgeleitet aus dem Leistungsdatum der ersten Charge-Transaktion für das Billing Event. Ereignistyp inferred | |||
| Zahlung dem Konto gutgeschrieben | Dies ist das Ereignis, bei dem eine eingegangene Zahlung bestimmten Belastungen auf dem Konto des Patienten zugeordnet wird. Dadurch verringert sich der offene Saldo des Abrechnungsvorgangs. | ||
| Warum das wichtig ist Eine effiziente Verbuchung von Zahlungen ist entscheidend für korrekte Kontosalden und den Abschluss von Abrechnungsvorgängen. Sie ermöglicht die korrekte Ermittlung verbleibender Salden für die sekundäre Abrechnung oder das Inkasso. Bezugsquelle Dies ist eine explizite Transaktion in Resolute. Bei der Zahlungsverbuchung wird eine Zahlungstransaktion mit einer oder mehreren Belastungstransaktionen verknüpft. Diese Zuordnung wird in den Transaktionsdetailtabellen erfasst. Erfassen Erfassen Sie den Transaktionsdatensatz, der eine Zahlung einer Belastung zuordnet. Er ist anhand bestimmter Transaktionstypen identifizierbar. Ereignistyp explicit | |||
| Zahlung eingegangen | Bezeichnet den Eingang einer Zahlung von einem Kostenträger oder Patienten. Dieses Ereignis wird in der Regel erfasst, wenn eine elektronische Zahlungsaviso (ERA) geladen oder ein manueller Scheck im System eingetragen wird. | ||
| Warum das wichtig ist Diese Aktivität ist ein wichtiger Meilenstein und zeigt an, dass Einnahmen eingehen. Die Zeit zwischen der Claim-Übermittlung und dem Zahlungseingang ist eine zentrale Kennzahl für die Leistung der Debitorenbuchhaltung. Bezugsquelle In Resolute ausdrücklich als Zahlungstransaktion erfasst. Diese Transaktionen werden mit Datum, Quelle und Betrag protokolliert, häufig bevor sie einzelnen Belastungen vollständig zugeordnet wurden. Erfassen Erfassen Sie Zahlungstransaktionen aus dem Finanztransaktionsprotokoll, die häufig anhand bestimmter Transaktionstypen identifiziert werden. Ereignistyp explicit | |||
| Anspruch erneut eingereicht | Dieses Ereignis tritt ein, nachdem ein abgelehnter Claim korrigiert und erneut an den Kostenträger gesendet wurde. Es handelt sich um ein eigenständiges Übermittlungsereignis, das mit dem ursprünglichen Claim verknüpft ist. | ||
| Warum das wichtig ist Dies ist ein zentraler Bestandteil der Nachbearbeitungsschleife. Die Messung der Zeit bis zur erneuten Übermittlung und der Erfolgsquote erneut übermittelter Claims ist entscheidend, um die Wirksamkeit des Prozesses zur Bearbeitung von Ablehnungen zu beurteilen. Bezugsquelle Dies ist ein explizites Ereignis, das der ursprünglichen Übermittlung ähnelt, jedoch häufig als erneute Übermittlung gekennzeichnet wird. Der Claim-Datensatz enthält einen neuen Timestamp für die Übermittlung und kann einen Code für die erneute Übermittlung enthalten. Erfassen Erfassen Sie den Timestamp für eine Claim-Übermittlung, die als Korrektur oder erneute Übermittlung gekennzeichnet ist. Ereignistyp explicit | |||
| Anspruch erstellt | Diese Aktivität bezeichnet die Erstellung eines formalen Claims oder einer Rechnung durch das System auf Grundlage der erfassten Charges. Sie ist ein vorbereitender Schritt, bevor der Claim an den Kostenträger oder Patienten gesendet wird. | ||
| Warum das wichtig ist Die Nachverfolgung der Claim-Erstellung hilft, Verzögerungen zwischen der Charge Capture und der Vorbereitung zur Übermittlung einzugrenzen. Dieser interne Schritt kann die Pünktlichkeit der gesamten Abrechnung maßgeblich beeinflussen. Bezugsquelle Dieses Ereignis wird typischerweise protokolliert, wenn ein Batch-Job zur Erstellung von Abrechnungen oder Claims ausgeführt wird. Das System erfasst einen Timestamp, sobald die Claim-Datei, etwa eine 837-Datei, für ein bestimmtes Konto erstellt wurde. Erfassen Identifizieren Sie Log-Einträge oder Statusänderungen, die zeigen, dass der Claim zusammengestellt wurde und zur Übermittlung bereit ist. Ereignistyp explicit | |||
| Kontoanpassung vorgenommen | Diese Aktivität bezeichnet eine Nichtzahlungstransaktion, die den Kontosaldo verändert, etwa eine vertragliche Anpassung, eine Ausbuchung eines geringfügigen Saldos oder einen Kulanzrabatt. Sie wird als bestimmter Transaktionstyp erfasst. | ||
| Warum das wichtig ist Die Analyse von Anpassungen ist entscheidend, um Umsatzverluste zu erkennen. Ein hohes Volumen bestimmter Anpassungstypen kann auf Probleme bei Gebührenordnungen, Verträgen oder internen Richtlinien hinweisen. Bezugsquelle In den Finanzprotokollen von Resolute ausdrücklich als Anpassungstransaktionen erfasst. Jede Anpassung ist mit einem bestimmten Typ oder Ursachencode verknüpft. Erfassen Filtern Sie nach Transaktionstypen, die finanziellen Anpassungen oder Ausbuchungen entsprechen. Ereignistyp explicit | |||
| Nachverfolgung der Ablehnung eingeleitet | Diese Aktivität kennzeichnet den Beginn des internen Prozesses zur Prüfung und Klärung eines abgelehnten Claims. Sie wird häufig erfasst, wenn ein Benutzer den abgelehnten Claim in einer Workqueue übernimmt oder seinen Status ändert. | ||
| Warum das wichtig ist Die Nachverfolgung hilft, die Reaktionsfähigkeit des Teams für das Ablehnungsmanagement zu messen. Verzögerungen zwischen der Ablehnung und dem Beginn der Nachverfolgung können den Revenue Cycle unnötig verlängern. Bezugsquelle Dieses Ereignis wird typischerweise aus Statusänderungen oder dem Zuweisungsverlauf des Claims in den Workqueues von Epic abgeleitet. Beispielsweise kann sich der Status des Claims von „Denied“ zu „In Review“ ändern. Erfassen Leiten Sie das Ereignis aus einer Statusänderung des Claims oder einem Audit-Log-Eintrag ab, der zeigt, dass ein Benutzer mit der Bearbeitung der Ablehnung begonnen hat. Ereignistyp inferred | |||
| Saldo an das Inkasso übergeben | Dies kennzeichnet den Zeitpunkt, an dem ein unbezahlter Kontosaldo an einen internen oder externen Inkassoprozess übergeben wird. Häufig handelt es sich dabei um eine explizite Statusänderung des Kontos oder Abrechnungsvorgangs. | ||
| Warum das wichtig ist Diese Aktivität leitet die letzte Phase der Einziehung offener Salden ein. Die Erfassung von Erfolgsquote und Durchlaufzeit des Inkassoprozesses ist entscheidend, um Forderungsausfälle zu minimieren. Bezugsquelle Dies ist in der Regel ein explizites Ereignis. Epic bietet Funktionen zur Übergabe von Konten an Inkassounternehmen. Dabei wird ein Protokolleintrag oder eine Statusänderung am Konto erzeugt. Erfassen Identifizieren Sie die Statusänderung oder Transaktion, die anzeigt, dass ein Konto an ein Inkassounternehmen übergeben wurde. Ereignistyp explicit | |||
Anleitungen zur Extraktion
Schritte
- Datenbankverbindung herstellen: Beschaffen Sie schreibgeschützte Zugangsdaten für die Epic-Clarity-Datenbank. Verwenden Sie einen Standard-SQL-Client wie DBeaver oder Microsoft SQL Server Management Studio, um eine Verbindung zum Datenbankserver herzustellen.
- Zentrale Tabellen identifizieren: Zu den wichtigsten Tabellen für diese Extraktion gehören
HSP_ACCOUNTfür Falldaten,HSP_TRANSACTIONSfür Finanzereignisse,CLP_CLAIM_INFOfür den Anspruchsstatus undF_ARHB_TX_SET_POST_HXfür Details zur Zahlungsverbuchung. Zusätzlich verknüpfen Sie Stammdatendateien wieCLARITY_EMPmit Benutzerdaten. - Umfang festlegen: Bestimmen Sie vor dem Erstellen der Abfrage den Analyseumfang. Definieren Sie einen konkreten Zeitraum, üblicherweise drei bis sechs Monate, und legen Sie fest, welche Krankenhausleistungsbereiche (
SERV_AREA_ID) oder Kontoklassen Sie ein- oder ausschließen möchten. - SQL-Abfrage entwickeln: Erstellen Sie eine SQL-Abfrage mit einer Common Table Expression (CTE), um zunächst die Menge der
HSP_ACCOUNT_ID-Werte auszuwählen, die in Ihren definierten Umfang fallen. Diese Menge bildet die Grundlage der Abrechnungsereignisse. - Abfragen für einzelne Aktivitäten zusammenführen: Erstellen Sie für jede der zwölf erforderlichen Aktivitäten eine separate
SELECT-Anweisung, die Daten aus den relevanten Tabellen abruft. Verknüpfen Sie jede Abfrage wieder mit Ihrer ursprünglichen CTE, damit nur die vorgesehenen Konten analysiert werden. - Abfragen mit UNION ALL kombinieren: Verwenden Sie den Operator
UNION ALL, um die Ergebnisse aller einzelnen Aktivitätsabfragen zu einem einheitlichen Event Log zusammenzuführen. Dadurch werden die Zeilen der einzelnen Abfragen untereinander angeordnet. - Auf das Standardschema abbilden: Benennen Sie die Spalten in jeder
SELECT-Anweisung so um, dass sie dem erforderlichen ProcessMind-Schema entsprechen:BillingEvent,ActivityName,EventTimestamp,ResponsibleUserusw. Verwenden Sie für Attribute, die auf eine bestimmte Aktivität nicht zutreffen,NULL. - Abfrage ausführen und verfeinern: Führen Sie die vollständige Abfrage in der Clarity-Datenbank aus. Aufgrund des Tabellenumfangs kann dies längere Zeit dauern. Wenn die Leistung nicht ausreicht, schränken Sie den Zeitraum weiter ein oder ergänzen Sie in der initialen CTE spezifischere Filter.
- Ausgabe prüfen: Prüfen Sie nach Abschluss der Abfrage die ersten hundert Zeilen der Ausgabe. Vergewissern Sie sich, dass alle Spalten vorhanden sind, die Timestamps ein einheitliches Format verwenden und die erwarteten
ActivityName-Werte erscheinen. - Als CSV exportieren: Exportieren Sie das vollständige Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Verwenden Sie die UTF-8-Kodierung und eine Kopfzeile mit den korrekten Spaltennamen.
- Upload vorbereiten: Öffnen Sie die CSV-Datei vor dem Upload in ProcessMind, um Formatierungsfehler auszuschließen. Prüfen Sie, ob das Timestamp-Format einheitlich ist, zum Beispiel
YYYY-MM-DD HH:MI:SS. Danach ist die Datei für die Verarbeitung bereit.
Konfiguration
- Datenbankverbindung: Erforderlich ist ein schreibgeschütztes Benutzerkonto mit Zugriff auf die Epic-Clarity-Datenbank.
- Parameter für den Zeitraum: Die bereitgestellte Abfrage verwendet die Variablen
@StartDateund@EndDate. Diese müssen gesetzt werden, um den Analysezeitraum festzulegen. Empfohlen wird ein Zeitraum von drei bis sechs Monaten, um Datenvolumen und Leistung ausgewogen zu berücksichtigen. - Zuordnung von Tabellen und Spalten: Die Abfrage setzt standardmäßige Clarity-Tabellen- und Spaltennamen voraus. Die spezifische Epic-Konfiguration oder Version Ihrer Organisation kann davon abweichen. Passen Sie gegebenenfalls Tabellen, Spalten oder Join-Bedingungen an.
- Transaktions- und Statuscodes: Die Abfrage enthält Platzhalter wie
[Your Denial Tx Type]und[Your Collections Status Code]. Stimmen Sie sich mit den Epic-Systemadministratoren ab oder prüfen Sie die relevanten Stammdatendateien wieZC_TX_TYPEoderZC_ACCOUNT_STATUS, um die korrekten Codes für Ihre Instanz zu ermitteln. - Filterung: Für eine bessere Leistung und eine gezieltere Analyse können Sie der initialen
BaseAccounts-CTE Filter hinzufügen. Häufig verwendet werdenSERV_AREA_IDzur Einschränkung auf einen Krankenhausleistungsbereich oderACCOUNT_CLASS_Czur Fokussierung auf stationäre oder ambulante Abrechnung.
a Beispielabfrage sql
DECLARE @StartDate DATE = '2023-01-01';
DECLARE @EndDate DATE = '2023-06-30';
WITH BaseAccounts AS (
SELECT DISTINCT
HA.HSP_ACCOUNT_ID
FROM
HSP_ACCOUNT HA
WHERE
HA.ADM_DATE_TIME >= @StartDate
AND HA.ADM_DATE_TIME <= @EndDate
-- Add additional filters here if needed, for example:
-- AND HA.SERV_AREA_ID = [Your Service Area ID]
)
-- 1. Service Rendered
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Service Rendered' AS ActivityName,
tx.SERVICE_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
AND tx.ORIG_REV_TX_ID IS NULL -- Not a reversal
UNION ALL
-- 2. Charges Captured
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Charges Captured' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
UNION ALL
-- 3. Claim Generated
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Generated' AS ActivityName,
claim.GENERATED_TIME AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.GENERATED_TIME IS NOT NULL
UNION ALL
-- 4. Claim Submitted to Payer
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
claim.XMIT_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.XMIT_DATE IS NOT NULL
UNION ALL
-- 5. Claim Denied by Payer
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
remit.REMIT_CODE_ID AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN F_ARHB_TX_SET_POST_HX remit ON tx.TX_ID = remit.TX_ID
WHERE tx.TX_TYPE_C IN ([Your Denial Tx Type]) -- Placeholder for denial transaction type codes
UNION ALL
-- 6. Denial Follow-Up Initiated (assumes status change on account)
SELECT
hist.HSP_ACCOUNT_ID AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
NULL AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCT_STATUS_HX hist
INNER JOIN BaseAccounts ba ON hist.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON hist.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE hist.ACCOUNT_STATUS_C = [Your Denial Followup Status Code] -- Placeholder for a status indicating follow-up
UNION ALL
-- 7. Claim Resubmitted
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
claim.RESUBMIT_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON claim.RESUBMIT_USER_ID = emp.USER_ID
WHERE claim.RESUBMIT_DATE IS NOT NULL
UNION ALL
-- 8. Payment Received & 9. Payment Posted to Account (combined for this query)
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE tx.TX_TYPE_C IN ([Your Payer Payment Tx Type], [Your Patient Payment Tx Type]) -- Placeholder for payment transaction types
UNION ALL
-- 10. Account Adjustment Made
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
zcar.NAME AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN ZC_ADJ_REASON zcar ON tx.ADJ_REASON_C = zcar.ADJ_REASON_C
WHERE tx.TX_TYPE_C IN ([Your Adjustment Tx Type]) -- Placeholder for adjustment transaction types
UNION ALL
-- 11. Balance Sent to Collections
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
INNER JOIN HSP_ACCT_STATUS_HX hist ON acct.HSP_ACCOUNT_ID = hist.HSP_ACCOUNT_ID AND hist.ACCOUNT_STATUS_C = [Your Collections Status Code]
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE acct.ACCOUNT_STATUS_C = [Your Collections Status Code] -- Placeholder for collections status
UNION ALL
-- 12. Account Closed
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Account Closed' AS ActivityName,
acct.CLOSED_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- System or Final transaction user
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE acct.ACCT_FIN_BALANCE = 0
AND acct.CLOSED_DATE IS NOT NULL
AND acct.CLOSED_DATE BETWEEN @StartDate and @EndDate
ORDER BY
BillingEvent,
EventTimestamp; Schritte
- Bestätigen Sie, dass autorisierter Zugriff auf den Epic-Clarity-Datensatz für Revenue Cycle Management besteht, einschließlich der für Konto-, Leistungs-, Anspruchs-, Ablehnungs-, Zahlungs-, Anpassungs-, Inkasso- und Abschlussdaten erforderlichen Quelltabellen und Ansichten. Epic-Organisationen unterscheiden sich hinsichtlich verfügbarer Tabellen und Spaltennamen. Ordnen Sie daher jeden Platzhalter in der Abfrage dem entsprechenden Clarity-Objekt in Ihrer Umgebung zu.
- Legen Sie den Extraktionszeitraum mit [Start date parameter] und [End date parameter] fest. Verwenden Sie zunächst einen Zeitraum von drei bis sechs Monaten und erweitern Sie ihn erst, nachdem Sie Abfrageleistung und Vollständigkeit der Ereignisse geprüft haben.
- Legen Sie die Zuordnung von BillingEvent fest. Die Abfrage verwendet, sofern verfügbar,
HSP_ACCOUNT.HSP_ACCOUNT_IDals standardmäßige Fallkennung. Wenn Ihre Organisation ein Abrechnungsereignis auf Leistungs-, Anspruchs- oder Behandlungsebene definiert, ersetzen Sie die Zuordnung durch die freigegebene Kennung und verwenden Sie diese über alle Aktivitätsquellen hinweg konsistent. - Ordnen Sie jede Quellaktivität einem maßgeblichen Timestamp und einem Quellattribut zu. Für Service Rendered sollte der dokumentierte Abschluss-Timestamp der Leistung oder Behandlung verwendet werden. Charges Captured sollte den Timestamp der Verbuchung verwenden. Für Claim Generated und Claim Submitted to Payer sind die entsprechenden Timestamps im Anspruchslebenszyklus heranzuziehen. Ablehnungen, Nachverfolgung, erneute Einreichungen, Zahlungen, Anpassungen, Inkasso und Abschluss müssen ihre dokumentierten Transaktions- oder Status-Timestamps verwenden.
- Ersetzen Sie jeden in eckigen Klammern stehenden Quellplatzhalter in der Abfrage, einschließlich [Your service source table], [Your charge source table], [Your claim source table], [Your denial source table], [Your follow-up source table], [Your payment source table], [Your adjustment source table], [Your collections source table] und [Your account closure source table]. Verwenden Sie keine nicht dokumentierten Transaktionscodes. Setzen Sie die von Ihrem Epic-Reporting-Team freigegebenen Transaktions- oder Statuswerte ein.
- Führen Sie die Abfrage im von der Organisation freigegebenen SQL-Client oder auf der entsprechenden Reporting-Plattform aus. Vergewissern Sie sich, dass alle zwölf Aktivitätsbezeichnungen als eigene Zeilen zurückgegeben werden. ProcessMind leitet fehlende Lebenszyklusereignisse nicht aus Salden, Statuswerten oder der Reihenfolge von Ereignissen ab.
- Prüfen Sie das Ausgabeschema. Das Ergebnis muss BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance und ServiceType enthalten. Bewahren Sie Timestamps mit Zeitzonenangabe oder dokumentierter Ortszeit auf und behalten Sie Quellkennungen in einem internen Audit-Export, sofern dies zulässig ist.
- Validieren Sie die chronologische Reihenfolge innerhalb jedes BillingEvent, das Duplikatverhalten, Nullraten, Aktivitätszahlen und die Abstimmung mit Berichten des Quellsystems. Prüfen Sie Ereignisse außerhalb des angeforderten Zeitraums, wenn diese für die Interpretation von Fällen erforderlich sind, die vor dem Zeitraum beginnen oder danach enden.
- Exportieren Sie das Ergebnis als von ProcessMind unterstützte Datei mit Trennzeichen oder über eine unterstützte Datenbankverbindung. Verwenden Sie eine Zeile pro Ereignis, stabile Spaltennamen, ein einheitliches Timestamp-Format, UTF-8-Kodierung sowie keine verbundenen Zellen oder Darstellungssummen. Konfigurieren Sie BillingEvent beim Upload als Fallkennung, ActivityName als Aktivität und EventTimestamp als Ereignis-Timestamp.
Konfiguration
- Quellzuordnung: Epic-Clarity-Implementierungen unterscheiden sich. Ersetzen Sie jeden Platzhalter für Quellobjekte und Spalten in eckigen Klammern durch eine dokumentierte Tabelle, Ansicht oder freigegebene Reporting-Schicht in Ihrer Umgebung. Gehen Sie nicht davon aus, dass eine Tabelle oder ein Feld vorhanden ist, nur weil es in einer anderen Epic-Implementierung üblich ist.
- Fallkennung: Die Standardzuordnung der Abfrage verwendet HSP_ACCOUNT.HSP_ACCOUNT_ID. Prüfen Sie, ob Ihre Organisation BillingEvent als Konto, Behandlung, Anspruch, Leistung oder einen anderen freigegebenen Geschäftsschlüssel definiert.
- Zeitraum: Beginnen Sie mit drei bis sechs Monaten. Beziehen Sie einen Rückblickzeitraum ein, wenn Fälle vor dem Berichtsfenster beginnen können, und einen Nachlaufzeitraum, wenn Ansprüche, Ablehnungen, Zahlungen oder der Abschluss nach dem Leistungsdatum auftreten können.
- Aktivitäts-Timestamps: Konfigurieren Sie für jede Aktivität einen maßgeblichen Timestamp. Ersetzen Sie die tatsächliche Geschäftsereigniszeit nicht durch Extraktionszeit, Ladezeit der Datei oder aktuelle Statuszeit, es sei denn, dies ist der dokumentierte Ereignis-Timestamp des Quellsystems.
- Filter: Wenden Sie Filter wie [Company Code filter], [Document Type filter], [Department filter], Kostenträger, Leistungsbereich und Kontoklasse nur an, wenn ihre Definitionen dokumentiert sind und die Analyse sie erfordert. Halten Sie die Filter über alle UNION-ALL-Zweige hinweg konsistent.
- Zuordnung von Transaktionen und Statuswerten: Konfigurieren Sie von der Organisation freigegebene Werte für Verbuchung von Leistungen, Anspruchserstellung, Anspruchseinreichung, Ablehnung, Nachverfolgung, erneute Einreichung, Zahlungseingang, Zahlungsverbuchung, Anpassung, Inkasso und Abschluss. Die Abfrage verwendet bewusst Platzhalter, da sich Epic-Transaktionswerte und Quellstrukturen je nach Implementierung unterscheiden.
- Umgang mit NULL: Bewahren Sie NULL für Attribute auf, die auf eine Aktivität nicht zutreffen. Ersetzen Sie fehlende Ablehnungsgründe, Anpassungsgründe, Benutzer, Abteilungen oder Leistungsarten nicht durch erfundene Werte.
- Leistung: Begrenzen Sie Quellzeilen vor dem Join mit HSP_ACCOUNT über indizierte Datumsspalten und freigegebene Organisationsfilter. Wenden Sie in Prädikaten keine Funktionen auf indizierte Timestamp-Spalten an. Bei großen Rohdatenbeständen kann es sinnvoll sein, jede Quellaktivität in einer freigegebenen Reporting-Ansicht zu materialisieren.
- Deduplizierung: Entfernen Sie doppelte Ereignisse nicht ohne dokumentierte Regel. Mehrere Zahlungen, Anpassungen, Einreichungen oder Statusänderungen können für ein BillingEvent gültige Ereignisse sein.
- Voraussetzungen: Erforderlich sein können eine Epic-Clarity-Reporting-Berechtigung, Zugriff auf Daten zu Revenue Cycle Management und Kontohistorie, eine freigegebene SQL-Ausführungsumgebung sowie die organisatorische Genehmigung für geschützte Gesundheitsdaten. Ob Anspruchs-, Zahlungsavis-, Arbeitslisten-, Inkasso- und Abschlusshistorien verfügbar sind, hängt von lizenzierten und implementierten Epic-Modulen und Schnittstellen ab.
a Beispielabfrage sql
WITH
service_rendered AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Service Rendered' AS ActivityName,
CAST(s.[Service rendered timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(s.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(s.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(s.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(s.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your service source table] s
ON s.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE s.[Service rendered timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND s.[Service rendered timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND [Your company code filter]
),
charges_captured AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Charges Captured' AS ActivityName,
CAST(t.[Charge captured timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(t.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(t.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(t.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(t.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN AR_PB_TRANSACTIONS t
ON t.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE t.[Charge captured timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND t.[Charge captured timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND t.[Charge transaction filter]
AND [Your company code filter]
),
claim_generated AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Generated' AS ActivityName,
CAST(c.[Claim generated timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim generated timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim generated timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim generated status filter]
AND [Your company code filter]
),
claim_submitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
CAST(c.[Claim submitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim submitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim submitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim submitted status filter]
AND [Your company code filter]
),
claim_denied AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
CAST(d.[Denial timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(d.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(d.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(d.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(d.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(d.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your denial source table] d
ON d.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE d.[Denial timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND d.[Denial timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND d.[Denial status filter]
AND [Your company code filter]
),
denial_follow_up AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
CAST(f.[Follow-up timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(f.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(f.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(f.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(f.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(f.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your follow-up source table] f
ON f.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE f.[Follow-up timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND f.[Follow-up timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND f.[Follow-up status filter]
AND [Your company code filter]
),
claim_resubmitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
CAST(c.[Claim resubmitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim resubmitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted status filter]
AND [Your company code filter]
),
payment_received AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Received' AS ActivityName,
CAST(p.[Payment received timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment received timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment received timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment received status filter]
AND [Your company code filter]
),
payment_posted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
CAST(p.[Payment posted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment posted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment posted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment posted status filter]
AND [Your company code filter]
),
account_adjustment AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
CAST(x.[Adjustment timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(x.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(x.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(x.[Adjustment reason column] AS VARCHAR(100)) AS AdjustmentReason,
CAST(x.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(x.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your adjustment source table] x
ON x.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE x.[Adjustment timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND x.[Adjustment timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND x.[Adjustment transaction filter]
AND [Your company code filter]
),
balance_collections AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
CAST(k.[Collections timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(k.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(k.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(k.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(k.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your collections source table] k
ON k.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE k.[Collections timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND k.[Collections timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND k.[Collections status filter]
AND [Your company code filter]
),
account_closed AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Closed' AS ActivityName,
CAST(z.[Account closed timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(z.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(z.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(z.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(z.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your account closure source table] z
ON z.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE z.[Account closed timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND z.[Account closed timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND z.[Account closed status filter]
AND [Your company code filter]
)
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM service_rendered
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM charges_captured
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_generated
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_submitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_denied
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM denial_follow_up
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_resubmitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_received
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_posted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_adjustment
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM balance_collections
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_closed
ORDER BY BillingEvent, EventTimestamp, ActivityName; Bereit für den Start?
Nutzen Sie das volle Potenzial Ihres Revenue-Cycle-Management-Prozesses mit präzisen Daten. Beginnen Sie noch heute mit der Verbesserung von Effizienz und finanzieller Leistung.
Maximieren Sie die Effizienz: Optimieren Sie Ihr Revenue Cycle Management jetzt
Ermitteln Sie Ineffizienzen im RCM von Epic Resolute und verkürzen Sie die Durchlaufzeit um 30 %.
Keine Kreditkarte erforderlich. Beginnen Sie noch heute mit der Optimierung.