Ihr Daten-Template für Revenue Cycle Management
Ihr Daten-Template für Revenue Cycle Management
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten zur Nachverfolgung
- Hinweise zur Datenextraktion
Attribute für Revenue Cycle Management
| Name | Beschreibung | ||
|---|---|---|---|
| Abrechnungsereignis BillingEvent | Eindeutige Kennung für die Erbringung einer einzelnen Leistung oder Lieferung eines Produkts, für die eine Gebühr anfällt. Sie dient als primäre Case-ID. | ||
| Beschreibung Das Abrechnungsereignis ist die zentrale Kennung, die alle Aktivitäten im Revenue Cycle für eine bestimmte abrechenbare Leistung miteinander verknüpft. Es beginnt mit der Erbringung einer Leistung und endet, sobald das Konto vollständig ausgeglichen oder geschlossen ist. Bei der Process-Mining-Analyse ist dieses Attribut entscheidend, um den durchgängigen Ablauf für jede abrechenbare Leistung zu rekonstruieren. Damit lassen sich Aktivitäten wie die Erfassung abrechenbarer Leistungen, die Einreichung von Ansprüchen, die Zahlungsbuchung und das Ablehnungsmanagement für einzelne Abrechnungsereignisse verfolgen. So werden der Prozessablauf und seine Varianten sichtbar. Warum das wichtig ist Dies ist die grundlegende Case-ID. Sie ist entscheidend, um alle zugehörigen Prozessschritte zu verknüpfen und den vollständigen Ablauf der Umsatzgenerierung und des Zahlungseinzugs für jede Leistung zu analysieren. Woher beziehen Dies ist häufig eine eindeutige Kennung für ein Krankenhauskonto (HAR) oder eine bestimmte Sitzung zur Erfassung abrechenbarer Leistungen in Epic Resolute. Weitere Informationen zu bestimmten Tabellen, etwa HAR- oder Charge-Session-Datensätzen, finden Sie in der Dokumentation zu Epic Resolute. Beispiele BE10098765BE20012345BE30054321 | |||
| Aktivitätsname ActivityName | Name des konkreten Ereignisses oder der Aufgabe im Revenue-Cycle-Management-Prozess. | ||
| Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt im Revenue Cycle, etwa „Abrechenbare Leistungen erfasst“, „Anspruch beim Kostenträger eingereicht“ oder „Zahlung eingegangen“. Jede Aktivität steht für einen eigenen Meilenstein bei der Abrechnung und dem Einzug der Zahlung für eine Leistung. Die Analyse der Aktivitäten bildet die Grundlage für Process Mining. Sie ermöglicht die Visualisierung der Prozesslandkarte, zeigt häufige Abläufe und Engpässe zwischen den Schritten auf und macht die Einhaltung von Standardvorgehensweisen messbar. Warum das wichtig ist Legt die Schritte in der Prozesslandkarte fest und ermöglicht es, den Arbeitsablauf im Revenue Cycle zu visualisieren, zu analysieren und zu optimieren. Woher beziehen Dieses Attribut wird in der Regel aus Event Logs, Audit-Trails oder Statusänderungen in den Abrechnungs- und Anspruchsmodulen von Epic Resolute abgeleitet. Beispiele Abrechenbare Leistungen erfasstAnspruch beim Kostenträger eingereichtZahlung eingegangenKonto geschlossen | |||
| Ereigniszeitstempel EventTimestamp | Genaues Datum und genaue Uhrzeit, zu denen eine bestimmte Aktivität oder ein Ereignis stattgefunden hat. | ||
| Beschreibung Der Ereigniszeitstempel hält fest, wann eine Aktivität stattgefunden hat. Diese Zeitangabe ist entscheidend, um den zeitlichen Ablauf und die Reihenfolge der Ereignisse im Revenue Cycle zu verstehen. In der Analyse dienen Zeitstempel dazu, Zeitspannen zwischen Aktivitäten zu berechnen, etwa die Verzögerung bei der Erfassung abrechenbarer Leistungen oder die Dauer der Zahlungsbuchung. So lassen sich Engpässe erkennen, Zykluszeiten messen und Prozessleistungen über verschiedene Zeiträume hinweg analysieren. Genaue Zeitstempel sind für fast alle zeitbasierten KPIs und Dashboards unverzichtbar. Warum das wichtig ist Dieses Attribut ist für die Berechnung aller zeitbasierten Kennzahlen unerlässlich, darunter Zykluszeiten und Zeitspannen. Diese Werte sind grundlegend, um Verzögerungen und Ineffizienzen zu erkennen. Woher beziehen In Transaktions- oder Ereignisprotokolltabellen von Epic Resolute zu finden und den einzelnen erfassten Aktivitäten zugeordnet. Feldnamen enden häufig auf Dt, DTTM oder Time. Beispiele 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Abrechnungsabteilung BillingDepartment | Abteilung oder Funktionsteam, das für das Abrechnungsereignis oder die Aktivität verantwortlich ist. | ||
| Beschreibung Dieses Attribut gibt die Organisationseinheit an, etwa „Stationäre Abrechnung“, „Ambulante Abrechnung“ oder „Team für Ablehnungsmanagement“, die mit dem Abrechnungsereignis verknüpft ist oder eine bestimmte Aktivität ausgeführt hat. Diese Dimension ist entscheidend für das Dashboard „Leistungskennzahlen der Abrechnungsabteilungen“. Es ermöglicht den direkten Vergleich wichtiger Kennzahlen wie Ablehnungsquoten oder Erfassungszeiten abrechenbarer Leistungen. So kann das Management leistungsstarke Abteilungen erkennen, bewährte Vorgehensweisen standardisieren und Ressourcen gezielt zuweisen. Warum das wichtig ist Ermöglicht den Leistungsvergleich zwischen Abteilungen. So lassen sich bewährte Vorgehensweisen sowie Bereiche mit Verbesserungs- oder zusätzlichem Ressourcenbedarf erkennen. Woher beziehen Diese Information kann in Epic Resolute mit dem Benutzerdatensatz, dem Patientenkonto oder dem Leistungsstandort verknüpft sein. Beispiele Abrechnung KardiologieRCM RadiologieZentrale Abrechnungsstelle | |||
| Anpassungsgrund AdjustmentReason | Grund für eine manuelle oder automatische Anpassung des Kontostands eines Patienten. | ||
| Beschreibung Dieses Attribut erklärt, warum sich ein Kontostand außerhalb einer regulären Zahlung oder Abrechnung geändert hat. Gründe können vertragliche Vereinbarungen mit Kostenträgern, die Ausbuchung geringer Restbeträge oder Korrekturen von Buchungsfehlern sein. Dieses Attribut ist entscheidend für das Dashboard „Volumen der Kontoanpassungen nach Typ“. Durch die Analyse der Anpassungsgründe können Unternehmen Ursachen für Einnahmeverluste erkennen, die Auswirkungen von Verträgen mit Kostenträgern verstehen und mögliche Ineffizienzen oder Fehler im Abrechnungsprozess aufdecken. Warum das wichtig ist Erklärt, warum sich Kontostände ändern, und liefert damit Erkenntnisse zu Einnahmeverlusten und Abrechnungsgenauigkeit. So lassen sich unnötige Ausbuchungen verringern. Woher beziehen In den Transaktionsdetails zu Anpassungseinträgen im Patientenbuchhaltungsmodul von Epic Resolute zu finden. Beispiele Vertragliche VergünstigungAusbuchung eines geringen RestbetragsKorrektur einer doppelten Abrechnung | |||
| Leistungsart ServiceType | Kategorie oder Art der erbrachten medizinischen Leistung. | ||
| Beschreibung Dieses Attribut ordnet die abrechenbare Leistung einer Kategorie zu, zum Beispiel „Radiologie“, „Chirurgie“, „Beratung“ oder „Notaufnahme“. Es ergänzt die Finanzdaten um den klinischen Kontext. Eine Analyse des Abrechnungszyklus nach Leistungsart kann Prozessabweichungen in bestimmten klinischen Bereichen aufdecken. Bei chirurgischen Eingriffen sind beispielsweise die Leistungserfassung und die erforderlichen Genehmigungen oft komplexer als bei einem regulären Arztbesuch. Das kann zu anderen Prozessabläufen und Herausforderungen führen. Warum das wichtig ist Ergänzt Finanzdaten um den klinischen Kontext und ermöglicht die Analyse, wie sich verschiedene medizinische Leistungen auf den Abrechnungszyklus und dessen Effizienz auswirken. Woher beziehen Abgeleitet aus dem Charge Description Master (CDM), der Leistungsart oder der Abteilung, die in Epic mit der Abrechnungstransaktion verknüpft ist. Beispiele Stationäre ChirurgieAmbulante RadiologieNotfallversorgung | |||
| Offener Saldo OutstandingBalance | Der noch ausstehende Betrag, den der Kostenträger oder Patient für das Abrechnungsereignis schuldet. | ||
| Beschreibung Dieses Attribut gibt den aktuellen Forderungssaldo für ein bestimmtes Abrechnungsereignis zum Zeitpunkt der Aktivität an. Es bildet die finanzielle Situation des Falls während seines gesamten Verlaufs ab. Der offene Saldo ist für die Finanzberichterstattung und den „Bericht zu überfälligen offenen Salden“ entscheidend. Wenn Sie diesen Wert im Zeitverlauf und nach Dimensionen wie Kostenträger oder Abteilung analysieren, können Sie Inkassomaßnahmen priorisieren, den Cashflow steuern und finanzielle Risiken bewerten. Warum das wichtig ist Misst direkt die finanziellen Auswirkungen von Prozessverzögerungen und ist entscheidend, um Inkassomaßnahmen zu priorisieren, den Cashflow zu steuern und Forderungen zu überblicken. Woher beziehen Dies ist ein zentrales Feld im Patienten- oder Krankenhauskontodatensatz (HAR) von Epic Resolute. Es enthält den laufenden Saldo, der durch Finanztransaktionen aktualisiert wird. Beispiele 1500.00250.750.00 | |||
| Ursachencode der Ablehnung DenialReasonCode | Standardisierter Code, der angibt, warum ein Kostenträger einen eingereichten Anspruch abgelehnt hat. | ||
| Beschreibung Wenn ein Kostenträger einen Anspruch zurückweist, gibt er einen Ursachencode an, etwa „Leistung nicht abgedeckt“, „Doppelter Anspruch“ 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 bei Ansprüchen“. Die Analyse der Häufigkeit verschiedener Ablehnungscodes hilft, Ursachen wie Probleme bei der Zulassung, Kodierungsfehler oder fehlende Vorabgenehmigungen zu erkennen und gezielte Verbesserungsmaßnahmen einzuleiten. Warum das wichtig ist Erklärt direkt, warum Ansprüche zurückgewiesen werden. Die daraus gewonnenen Erkenntnisse helfen, Ablehnungsquoten zu senken, Einnahmeverluste zu vermeiden und Zahlungen zu beschleunigen. Woher beziehen Diese Daten finden sich in den Antworttransaktionen zu Ansprüchen, etwa in einer ANSI-835-Datei, die von Kostenträgern eingeht und im Anspruchsverwaltungsmodul von Epic Resolute gespeichert wird. Beispiele CO-16: Angaben zum Anspruch/zur Leistung fehlenOA-18: Doppelter Anspruch/doppelte LeistungPR-96: Nicht abgedeckte Gebühr(en) | |||
| Verantwortlicher Benutzer ResponsibleUser | Kennung des Benutzers oder Mitarbeitenden, der die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut erfasst die Benutzer-ID, den Namen oder die Personalnummer der Person, die eine bestimmte Aufgabe im Revenue Cycle ausgeführt hat. Das kann die klinische Fachkraft sein, die abrechenbare Leistungen erfasst hat, der Abrechnungsmitarbeiter, der einen Anspruch eingereicht hat, oder der Inkassomitarbeiter, der eine Ablehnung nachverfolgt hat. Die Analyse nach Benutzer hilft dabei, besonders leistungsstarke Mitarbeitende zu erkennen, Schulungsbedarf festzustellen und die Arbeitsverteilung zu verstehen. Sie ist wichtig für das Leistungsmanagement und für die Untersuchung von Prozessabweichungen, die bestimmten Personen oder Rollen zugeordnet sind. Warum das wichtig ist Ermöglicht die Analyse der Leistung einzelner Personen oder Rollen. So lassen sich Schulungsbedarf, unausgewogene Arbeitslasten und ressourcenbedingte Engpässe erkennen. Woher beziehen In der Regel in Audit-Trails oder Transaktionsprotokollen von Epic Resolute zu finden und häufig mit einer Benutzerstammdatentabelle verknüpft, etwa einem EMP-Datensatz. Beispiele j.doebsmith123User7890 | |||
| Angepasster Betrag AdjustedAmount | Geldbetrag einer Anpassungstransaktion. | ||
| Beschreibung Dieses Feld enthält den konkreten Betrag einer Kontenanpassung. Ein positiver oder negativer Wert steht für eine Gutschrift beziehungsweise Belastung des Kontos. Der Betrag ist die zentrale Kennzahl im Dashboard „Kontenanpassungsvolumen nach Art“. Werden die Werte nach Anpassungsgrund summiert, wird die finanzielle Auswirkung der verschiedenen Anpassungsarten sichtbar. So lässt sich etwa vergleichen, wie viel Umsatz aufgrund vertraglicher Verpflichtungen abgeschrieben wird und wie viel durch korrigierbare Fehler verloren geht. Warum das wichtig ist Beziffert die finanziellen Auswirkungen von Kontenanpassungen und ermöglicht es, Umsatzverluste sowie die Kosten fehlerhafter Abrechnungen zu messen. Woher beziehen In den Detailtabellen zu Finanztransaktionen in Epic Resolute, verknüpft mit Transaktionen vom Typ Anpassung. Beispiele -1250.45-50.0025.10 | |||
| Anspruchs-ID ClaimId | Eindeutige Kennung eines Versicherungsanspruchs, der bei einem Kostenträger eingereicht wurde. | ||
| Beschreibung Dieses Attribut enthält die spezifische ID des Anspruchsformulars, zum Beispiel eines CMS-1500- oder UB-04-Formulars, das an einen Kostenträger gesendet wurde. Zu einem Abrechnungsvorgang können mehrere Ansprüche gehören, wenn Leistungen erneut abgerechnet oder Einsprüche eingelegt werden. Die Nachverfolgung anhand der Anspruchs-ID erleichtert die detaillierte Analyse der Einreichung und Bearbeitung abgelehnter Ansprüche. Sie hilft dabei, Aktivitäten zum ursprünglichen Anspruch von denen zu unterscheiden, die sich auf einen später erneut eingereichten Anspruch für dieselbe Leistung beziehen. Warum das wichtig ist Ermöglicht die detaillierte Nachverfolgung des Lebenszyklus einzelner Anspruchseinreichungen. Das ist wichtig, um erneute Einreichungen und Einsprüche zu analysieren. Woher beziehen Wird beim Erstellen eines Anspruchs vom Claims-Management-Modul von Epic Resolute generiert und in den Anspruchsdatentabellen gespeichert. Beispiele CLM-2023-98765CLAIM-0012345623189A4567 | |||
| Automatisiert IsAutomated | Boolescher Wert, der angibt, ob ein System oder ein automatisierter Prozess die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Kennzeichen unterscheidet automatisch vom System ausgeführte Aufgaben, etwa die automatische Erstellung von Ansprüchen oder Anspruchsberechtigungsprüfungen, von manuell durch einen Benutzer ausgeführten Aufgaben. Die Analyse dieses Attributs zeigt den Automatisierungsgrad des Prozesses. Sie können damit Effizienz und Fehlerquoten automatisierter und manueller Aktivitäten vergleichen, weitere Automatisierungsmöglichkeiten ermitteln und die Leistung vorhandener Bots oder Systemregeln überwachen. Warum das wichtig ist Unterscheidet systemgesteuerte von manuell ausgeführten Aktivitäten. Das ist wichtig, um die Auswirkungen der Automatisierung zu bewerten und weitere Automatisierungsmöglichkeiten zu erkennen. Woher beziehen Wird häufig daraus abgeleitet, ob für eine Aktivität als „ResponsibleUser“ ein System- oder Dienstkonto eingetragen ist. Alternativ können bestimmte, bekanntermaßen automatisierte Aktivitätsnamen gekennzeichnet werden. Beispiele truefalse | |||
| Endzeit des Ereignisses EventEndTime | Timestamp für den Abschluss einer Aktivität, der zur Berechnung ihrer Dauer verwendet werden kann. | ||
| Beschreibung Dieses Attribut erfasst den Zeitpunkt, zu dem eine Aktivität abgeschlossen wurde. Viele Aktivitäten sind punktuelle Ereignisse, bei denen StartTime und EndTime übereinstimmen. Andere Aufgaben haben eine messbare Dauer, etwa ein Anruf zur Nachverfolgung einer Ablehnung. Wenn EndTime verfügbar ist, lässt sich die Verarbeitungszeit einer Aktivität direkt berechnen: „EndTime“ minus „StartTime“. Das ist genauer, als die Dauer anhand der Startzeit der nächsten Aktivität abzuleiten, da dabei auch Leerlaufzeiten zwischen den Schritten berücksichtigt werden. EndTime ist eine wichtige Grundlage für die Berechnung des Attributs „ProcessingTime“. Warum das wichtig ist Ermöglicht die genaue Berechnung der Dauer einzelner Aktivitäten. Das ist wichtig, um ineffiziente Aufgaben zu erkennen und die Produktivität der eingesetzten Ressourcen zu messen. Woher beziehen In einigen Epic-Resolute-Modulen, die Beginn und Ende von Aufgaben erfassen, können diese Daten verfügbar sein, etwa in Protokollen zu Arbeitswarteschlangen oder zur Aktivitätsverwaltung. Häufig werden sie jedoch nicht ausdrücklich erfasst. Beispiele 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| Gesamtdauer des Abrechnungszyklus TotalRevenueCycleTime | Gesamtdauer vom ersten Leistungsereignis bis zur abschließenden Zahlung oder Kontoschließung. | ||
| Beschreibung Diese KPI auf Case-Ebene misst die Gesamtdauer des Abrechnungszyklus für einen einzelnen Abrechnungsvorgang. Sie wird in der Regel als Zeitspanne zwischen der Aktivität „Leistung erbracht“ und der abschließenden Aktivität „Zahlung eingegangen“ oder „Konto geschlossen“ berechnet. Diese übergeordnete Kennzahl gibt einen Gesamtüberblick über die Effizienz des RCM-Prozesses. Die Entwicklung im Zeitverlauf zeigt, welche Auswirkungen Prozessverbesserungen haben, und gibt Aufschluss darüber, wie schnell Leistungen in Zahlungseingänge umgewandelt werden. Warum das wichtig ist Gibt einen übergeordneten Überblick über die Effizienz des gesamten Prozesses und misst direkt, wie lange es dauert, eine erbrachte Leistung in einen Zahlungseingang umzuwandeln. Woher beziehen Diese Kennzahl wird im Process-Mining-Tool berechnet, indem für jeden Case das erste und das letzte Ereignis ermittelt und die Zeitspanne dazwischen berechnet wird. Beispiele 259200038880005184000 | |||
| Letzte Datenaktualisierung LastDataUpdate | Zeitstempel, der angibt, wann die Daten zu diesem Ereignis zuletzt aus dem Quellsystem aktualisiert oder extrahiert wurden. | ||
| Beschreibung Dieses Attribut zeigt, wie aktuell die Daten sind. Es gibt an, wann der Datensatz zuletzt aus Epic Resolute in den Process-Mining-Datensatz übernommen wurde. Das ist wichtig, um die Aktualität der Analyse einzuschätzen und Daten zu validieren. Benutzer können so erkennen, ob sie mit den aktuellsten verfügbaren Informationen arbeiten. Außerdem ist das Attribut entscheidend für die Verwaltung von Datenaktualisierungen. Warum das wichtig ist Damit können Benutzer die Aktualität der analysierten Daten einschätzen. Das ist entscheidend für fundierte Geschäftsentscheidungen auf Basis aktueller Informationen. Woher beziehen Dieser Zeitstempel wird während der Datenübernahme durch den ETL-Prozess (Extract, Transform, Load) hinzugefügt. Beispiele 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| Name des Kostenträgers PayerName | Name der Versicherung, staatlichen Stelle oder sonstigen Partei, die für die Zahlung verantwortlich ist. | ||
| Beschreibung Dieses Attribut gibt den primären Kostenträger des Abrechnungsereignisses an, etwa „Blue Cross Blue Shield“, „Medicare“ oder „Aetna“. Bei Selbstzahlern kann es den Patienten bezeichnen. 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. Mit diesen Erkenntnissen können Sie Ihre Abrechnungsstrategien gezielt auf einzelne Kostenträger abstimmen und so Effizienz und Zahlungsgeschwindigkeit verbessern. Warum das wichtig ist Ermöglicht die Leistungsanalyse nach Kostenträger. So erkennen Sie, bei welchen Kostenträgern Ablehnungsquoten hoch oder Zahlungszyklen lang sind, und können die Nachverfolgung gezielt ausrichten. Woher beziehen Diese Information gehört zu den Versicherungsdaten des Patienten und ist in Epic Resolute mit dem Krankenhauskonto (HAR) verknüpft. Beispiele Medicare Teil BUnitedHealthcareAetna PPO | |||
| Patienten-ID PatientId | Eindeutige Kennung des Patienten, der die Leistung erhält. | ||
| Beschreibung Dieses Attribut enthält die Krankenaktennummer (MRN) oder eine andere eindeutige Kennung des Patienten. Damit wird der finanzielle Abrechnungsvorgang einer bestimmten Person zugeordnet. Zum Schutz der Privatsphäre wird diese Kennung in der Regel nicht als primäre Analysedimension verwendet. Sie ist jedoch für die Datenvalidierung wichtig und kann dazu dienen, alle Abrechnungsvorgänge eines Patienten zusammenzuführen und dessen gesamten finanziellen Verlauf nachzuvollziehen. Auch für eine mögliche Verknüpfung mit klinischen Prozessdaten ist sie entscheidend. Warum das wichtig ist Verknüpft Finanzdaten mit einem bestimmten Patienten und ermöglicht so die Datenvalidierung sowie weiterführende Analysen des gesamten Patientenverlaufs. Aufgrund des Datenschutzes ist ein sorgfältiger Umgang mit diesen Daten erforderlich. Woher beziehen Eine grundlegende Kennung, die in Epic an vielen Stellen vorkommt und mit den Registrierungs- und Kontodaten des Patienten verknüpft ist. Beispiele MRN-1234567MRN-8765432MRN-5551234 | |||
| Quellsystem SourceSystem | Das Informationssystem, aus dem die Daten stammen. | ||
| Beschreibung Dieses Attribut gibt das Quellsystem des Datensatzes an, in diesem Fall Epic Resolute. In Umgebungen mit mehreren integrierten Systemen hilft das Feld, die Herkunft der Daten zu unterscheiden. Bei einer Betrachtung nur eines Systems mag das überflüssig erscheinen. Für Data Governance und Skalierbarkeit gilt es jedoch als bewährte Praxis. So bleibt die Herkunft eindeutig, falls später Daten aus anderen Systemen, etwa einer separaten Inkassoplattform, hinzukommen. Warum das wichtig ist Liefert wichtige Informationen zur Datenherkunft und zum Kontext. So bleibt nachvollziehbar, woher die Daten stammen, was für Data Governance und die Fehlerbehebung entscheidend ist. Woher beziehen Dies ist in der Regel ein statischer Wert, der während der Datenextraktion und -transformation hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Epic ResoluteEpicResolute_V2023 | |||
| Zahlungsziel PaymentDueDate | Datum, bis zu dem die Zahlung für die abgerechnete Leistung erwartet wird. | ||
| Beschreibung Dieses Attribut gibt die Zahlungsfrist an, die auf der Rechnung steht oder sich aus den Verträgen mit den Kostenträgern ergibt. Sie dient als Maßstab, um pünktliche Zahlungen zu beurteilen. Das Zahlungsziel ist eine wichtige Grundlage für den Bericht „Fälligkeit offener Salden“. Vergleicht man das aktuelle Datum mit dem Zahlungsziel offener Salden, lassen sich Forderungen nach ihrer Überfälligkeit gruppieren, etwa in 0–30 oder 31–60 Tage. So können Sie den Einzug der am längsten überfälligen Forderungen priorisieren. Warum das wichtig ist Dient als Grundlage für die Altersstrukturanalyse der Forderungen. Diese ist entscheidend, um den Forderungseinzug zu priorisieren und finanzielle Risiken durch unbezahlte Rechnungen zu steuern. Woher beziehen 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 hinterlegt sind. Beispiele 2023-05-302023-06-152023-07-01 | |||
Aktivitäten im Revenue Cycle Management
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Abrechenbare Leistungen erfasst | Hier werden die erbrachten Leistungen offiziell als abrechenbare Leistungen erfasst. In Epic geschieht dies in der Regel durch eine explizite Transaktion auf dem Patientenkonto. Sie wird häufig automatisch durch klinische Aktionen erzeugt oder manuell eingegeben. | ||
| Warum das wichtig ist Dies ist ein wichtiger erster Meilenstein. Wenn Sie Geschwindigkeit und Genauigkeit der Leistungserfassung messen, können Sie die Abrechnung beschleunigen und sicherstellen, dass alle erbrachten Leistungen abgerechnet werden. Woher beziehen Explizit in den Transaktionsprotokollen von Resolute erfasst. Jede abrechenbare Leistung wird als eigener Eintrag mit Buchungsdatum, Leistungsdatum und Betrag gespeichert, häufig in Tabellen wie ARPB_TRANSACTIONS. Erfassung Erfassen Sie Buchungstransaktionen abrechenbarer Leistungen aus dem Finanztransaktionsprotokoll des Systems. Ereignistyp explicit | |||
| Anspruch beim Kostenträger eingereicht | Dieses Ereignis kennzeichnet die offizielle Übermittlung des Anspruchs an den Versicherungsträger zur Prüfung. In Epic wird es erfasst, sobald die elektronische Anspruchsdatei an die Clearingstelle oder den Kostenträger übermittelt wird. | ||
| Warum das wichtig ist Dieser Meilenstein ist entscheidend, denn ab diesem Zeitpunkt läuft die Zahlungsfrist des Kostenträgers. Die Analyse zeigt, wie effizient Ansprüche übermittelt werden, und unterstützt die KPI „Zeit von der Rechnung bis zur Zustellung an den Kostenträger“. Woher beziehen Dieses Ereignis wird explizit in Resolute erfasst. Der Anspruchsdatensatz enthält einen Einreichungsstatus und einen Zeitstempel für den Versand. Erfassung Erfassen Sie den Zeitstempel, zu dem sich der Anspruchsstatus in „Eingereicht“ oder „Übermittelt“ ändert. Ereignistyp explicit | |||
| Anspruch vom Kostenträger abgelehnt | Hier geht die Mitteilung des Kostenträgers ein, dass der Anspruch abgelehnt wurde. Erfasst wird dies, wenn Epic eine elektronische Zahlungsmitteilung (835-Datei) verarbeitet oder ein Benutzer die Ablehnung manuell verbucht. | ||
| Warum das wichtig ist Diese Aktivität löst eine wichtige Nachbearbeitungsschleife aus. Die Analyse von Ablehnungsgründen und -volumen ist entscheidend, um Ursachen zu erkennen, die Zahlungsquote beim ersten Einreichen zu verbessern und Verzögerungen beim Zahlungseingang zu verringern. Woher beziehen Explizit als Transaktion oder Statusänderung des Anspruchs erfasst. Informationen zur Ablehnung, einschließlich der Ursachencodes, gehen in der Regel elektronisch ein und werden dem Konto zugeordnet. Erfassung Filtern Sie nach bestimmten Transaktionstypen oder Statusänderungen des Anspruchs, die eine Ablehnung anzeigen. Ereignistyp explicit | |||
| Konto geschlossen | Dies ist die letzte Aktivität. Sie zeigt an, dass der offene Saldo des Abrechnungsereignisses null beträgt und keine weiteren Aktivitäten ausstehen. Der Abschluss kann durch vollständige Zahlung, Anpassungen oder eine Ausbuchung erfolgen. | ||
| Warum das wichtig ist Dieses Ereignis kennzeichnet den erfolgreichen Abschluss des Revenue Cycle für ein Abrechnungsereignis. Die Gesamtdauer von der Leistungserbringung bis zum Abschluss ist eine wichtige KPI für die Effizienz des gesamten Prozesses. Woher beziehen Dieses Ereignis wird in der Regel abgeleitet. Dazu wird der Zeitpunkt ermittelt, an dem der Kontostand des Abrechnungsereignisses null erreicht und bei null bleibt. Erfassung Abgeleitet durch Berechnung des laufenden Kontostands und Ermittlung des Zeitstempels der letzten Transaktion, durch die der Saldo auf null gesunken ist. Ereignistyp inferred | |||
| Leistung erbracht | Diese Aktivität kennzeichnet den Zeitpunkt, zu dem eine klinische Leistung für den Patienten erbracht wird und das Abrechnungsereignis beginnt. Häufig wird sie im Epic EHR (EpicCare) erfasst, wenn eine klinische Fachkraft einen Besuch oder Eingriff abschließt. | ||
| Warum das wichtig ist Dies ist das zentrale Start-Event des Revenue Cycle. Die Zeitspanne bis zur Erfassung der abrechenbaren Leistung ist entscheidend, um Verzögerungen beim Abrechnungsbeginn und mögliche Einnahmeverluste zu erkennen. Woher beziehen Dieses Ereignis wird in der Regel anhand von Zeitstempeln zu Leistungen oder Besuchen in den klinischen Modulen abgeleitet, die mit dem Abrechnungskonto verknüpft sind. Das Leistungsdatum der Abrechnungstransaktion ist dabei der wichtigste Datenpunkt. Erfassung Abgeleitet aus dem Leistungsdatum der ersten Abrechnungstransaktion für das Abrechnungsereignis. Ereignistyp inferred | |||
| Zahlung dem Konto gutgeschrieben | Bei diesem Ereignis wird eine eingegangene Zahlung bestimmten abrechenbaren Leistungen auf dem Patientenkonto zugeordnet. Dadurch verringert sich der offene Saldo des Abrechnungsereignisses. | ||
| Warum das wichtig ist Eine effiziente Zahlungsbuchung ist entscheidend, damit Kontosalden korrekt bleiben und Abrechnungsereignisse abgeschlossen werden können. So lassen sich offene Restbeträge für eine sekundäre Abrechnung oder das Inkasso korrekt ermitteln. Woher beziehen Dies ist eine explizite Transaktion in Resolute. Bei der Zahlungsbuchung wird eine Zahlungstransaktion mit einer oder mehreren Transaktionen abrechenbarer Leistungen verknüpft. Diese Zuordnung wird in den Transaktionsdetailtabellen erfasst. Erfassung Erfassen Sie den Transaktionsdatensatz, der eine Zahlung einer abrechenbaren Leistung zuordnet. Er ist an bestimmten Transaktionstypen erkennbar. Ereignistyp explicit | |||
| Zahlung eingegangen | Hier geht eine Zahlung des Kostenträgers oder Patienten ein. Das Ereignis wird in der Regel erfasst, wenn eine elektronische Zahlungsmitteilung (ERA) geladen oder ein Scheck manuell im System eingegeben wird. | ||
| Warum das wichtig ist Diese Aktivität ist ein wichtiger Meilenstein und zeigt an, dass Zahlungseingänge bevorstehen. Die Zeit zwischen der Einreichung des Anspruchs und dem Zahlungseingang ist eine zentrale Kennzahl für die Leistung des Forderungsmanagements. Woher beziehen Explizit als Zahlungstransaktion in Resolute erfasst. Diese Transaktionen werden mit Datum, Quelle und Betrag protokolliert, häufig bevor sie einzelnen abrechenbaren Leistungen vollständig zugeordnet sind. Erfassung Erfassen Sie Zahlungstransaktionen aus dem Finanztransaktionsprotokoll. Sie sind häufig an bestimmten Transaktionstypen erkennbar. Ereignistyp explicit | |||
| Anspruch erneut eingereicht | Dieses Ereignis tritt ein, nachdem ein abgelehnter Anspruch korrigiert und erneut an den Kostenträger gesendet wurde. Es handelt sich um eine separate Einreichung, die mit dem ursprünglichen Anspruch verknüpft ist. | ||
| Warum das wichtig ist Dies ist ein wichtiger Teil der Nachbearbeitungsschleife. Die Zeit bis zur erneuten Einreichung und die Erfolgsquote erneut eingereichter Ansprüche sind entscheidend, um die Wirksamkeit der Klärung von Ablehnungen zu beurteilen. Woher beziehen Dieses Ereignis wird wie die ursprüngliche Einreichung explizit erfasst, ist jedoch häufig als erneute Einreichung gekennzeichnet. Der Anspruchsdatensatz enthält einen neuen Einreichungszeitstempel und möglicherweise einen Code für die erneute Einreichung. Erfassung Erfassen Sie den Zeitstempel einer Anspruchseinreichung, die als Korrektur oder erneute Einreichung gekennzeichnet ist. Ereignistyp explicit | |||
| Anspruch erstellt | Diese Aktivität kennzeichnet die Erstellung eines formellen Anspruchs oder einer Rechnung durch das System auf Grundlage der erfassten abrechenbaren Leistungen. Sie ist ein vorbereitender Schritt, bevor der Anspruch an den Kostenträger oder Patienten gesendet wird. | ||
| Warum das wichtig ist Die Erfassung der Anspruchserstellung hilft dabei, Verzögerungen zwischen der Erfassung abrechenbarer Leistungen und der Vorbereitung zur Einreichung zu erkennen. Dieser wichtige interne Schritt kann die Pünktlichkeit der gesamten Abrechnung beeinflussen. Woher beziehen Der Vorgang wird in der Regel protokolliert, wenn ein Batch-Job zur Abrechnung oder Anspruchserstellung ausgeführt wird. Das System speichert einen Zeitstempel, sobald die Anspruchsdatei, etwa eine 837-Datei, für ein Konto erstellt wird. Erfassung Ermitteln Sie Protokolleinträge oder Statusänderungen, die anzeigen, dass der Anspruch zusammengestellt wurde und zur Einreichung bereit ist. Ereignistyp explicit | |||
| Konto angepasst | Diese Aktivität bezeichnet eine Transaktion ohne Zahlung, die den Kontostand verändert, etwa eine vertragliche Anpassung, eine Ausbuchung eines geringen Restbetrags oder einen Kulanzrabatt. Sie wird als bestimmter Transaktionstyp erfasst. | ||
| Warum das wichtig ist Die Analyse von Anpassungen hilft dabei, Einnahmeverluste zu erkennen. Ein hohes Volumen bestimmter Anpassungstypen kann auf Probleme mit Gebührenordnungen, Verträgen oder internen Richtlinien hinweisen. Woher beziehen Explizit als Anpassungstransaktionen in den Finanzprotokollen von Resolute erfasst. Jede Anpassung ist einem bestimmten Typ oder Ursachencode zugeordnet. Erfassung Filtern Sie nach Transaktionstypen, die finanziellen Anpassungen oder Ausbuchungen entsprechen. Ereignistyp explicit | |||
| Nachverfolgung einer Ablehnung gestartet | Diese Aktivität kennzeichnet den Beginn des internen Prozesses zur Prüfung und Klärung eines abgelehnten Anspruchs. Sie wird häufig erfasst, wenn ein Benutzer den Anspruch in einer Arbeitsliste übernimmt oder seinen Status ändert. | ||
| Warum das wichtig ist Damit lässt sich die Reaktionsfähigkeit des Teams für das Ablehnungsmanagement messen. Verzögerungen zwischen einer Ablehnung und dem Beginn der Nachverfolgung können den Revenue Cycle unnötig verlängern. Woher beziehen Dies wird in der Regel anhand von Statusänderungen oder des Zuweisungsverlaufs des Anspruchs in den Arbeitslisten von Epic abgeleitet. Beispielsweise kann sich der Status von „Abgelehnt“ zu „In Prüfung“ ändern. Erfassung Leiten Sie den Beginn aus einer Statusänderung des Anspruchs 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 | Hier wird ein unbezahlter Kontosaldo an ein internes oder externes Inkassoverfahren übergeben. Häufig wird dies als explizite Statusänderung des Kontos oder Abrechnungsereignisses erfasst. | ||
| Warum das wichtig ist Diese Aktivität leitet die letzte Phase des Einzugs offener Beträge ein. Die Erfolgsquote und Zykluszeit des Inkassoprozesses zu verfolgen, ist entscheidend, um Forderungsausfälle zu minimieren. Woher beziehen Dies ist in der Regel ein explizites Ereignis. Epic bietet Funktionen zur Übergabe von Konten an Inkassobüros. Dabei wird ein Protokolleintrag oder eine Statusänderung des Kontos erstellt. Erfassung Ermitteln Sie die Statusänderung oder Transaktion, die anzeigt, dass ein Konto an ein Inkassobüro übergeben wurde. Ereignistyp explicit | |||
Anleitungen zur Datenextraktion
Schritte
- Datenbankverbindung einrichten: Beschaffen Sie schreibgeschützte Zugangsdaten für die Epic-Clarity-Datenbank. Stellen Sie mit einem gängigen SQL-Client wie DBeaver oder Microsoft SQL Server Management Studio eine Verbindung zum Datenbankserver her.
- Zentrale Tabellen ermitteln: Zu den wichtigsten Tabellen für diesen Export gehören
HSP_ACCOUNTfür Kontoinformationen,HSP_TRANSACTIONSfür Finanzereignisse,CLP_CLAIM_INFOfür den Anspruchsstatus undF_ARHB_TX_SET_POST_HXfür Details zur Zahlungsbuchung. Verknüpfen Sie außerdem Stammdatendateien wieCLARITY_EMP, um Benutzerdetails abzurufen. - Analyseumfang festlegen: Bestimmen Sie vor dem Schreiben der Abfrage den Umfang Ihrer Analyse. Legen Sie einen konkreten Zeitraum fest, in der Regel 3 bis 6 Monate, und bestimmen Sie, welche Krankenhausversorgungsbereiche (
SERV_AREA_ID) oder Kontoklassen ein- oder ausgeschlossen werden sollen. - SQL-Abfrage erstellen: Erstellen Sie eine SQL-Abfrage mit einem Common Table Expression (CTE). Wählen Sie darin zunächst die Werte für
HSP_ACCOUNT_IDaus, die in den festgelegten Analyseumfang fallen. Diese bilden die Grundgesamtheit der Abrechnungsvorgänge. - Abfragen für einzelne Aktivitäten zusammenführen: Schreiben Sie für jede der 12 erforderlichen Aktivitäten eine eigene
SELECT-Anweisung, die Daten aus den relevanten Tabellen abruft. Verknüpfen Sie jede Abfrage mit dem 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 in einem gemeinsamen Event Log zusammenzuführen. Dabei werden die Zeilen aus den Abfragen untereinander angefügt. - Auf das Standardschema abstimmen: Benennen Sie die Spalten in jeder
SELECT-Anweisung so um, dass sie dem erforderlichen ProcessMind-Schema entsprechen, zum BeispielBillingEvent,ActivityName,EventTimestampundResponsibleUser. Verwenden Sie für Attribute, die auf eine bestimmte Aktivität nicht zutreffen, den WertNULL. - Abfrage ausführen und verfeinern: Führen Sie die vollständige Abfrage für die Clarity-Datenbank aus. Aufgrund der Tabellengröße kann dies längere Zeit dauern. Wenn die Leistung nicht ausreicht, schränken Sie den Zeitraum weiter ein oder ergänzen Sie im ursprünglichen CTE spezifischere Filter.
- Ergebnisse prüfen: Sehen Sie sich nach Abschluss der Abfrage die ersten hundert Zeilen an. Prüfen Sie, ob alle Spalten vorhanden sind, die Timestamps ein einheitliches Format haben und die erwarteten Werte für
ActivityNameangezeigt werden. - Als CSV exportieren: Exportieren Sie das gesamte Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Achten Sie auf UTF-8-Kodierung und eine Kopfzeile mit den korrekten Spaltennamen.
- Upload vorbereiten: Öffnen Sie die CSV-Datei vor dem Upload zu ProcessMind und prüfen Sie sie auf Formatierungsfehler. Kontrollieren Sie, ob die Timestamps einheitlich formatiert sind, zum Beispiel als
YYYY-MM-DD HH:MI:SS. Anschließend ist die Datei bereit für den Import.
Konfiguration
- Datenbankverbindung: Sie benötigen ein schreibgeschütztes Benutzerkonto mit Zugriff auf die Epic-Clarity-Datenbank.
- Parameter für den Zeitraum: Die Abfrage verwendet die Variablen
@StartDateund@EndDate. Legen Sie damit den Analysezeitraum fest. Empfohlen werden 3 bis 6 Monate, um Datenvolumen und Leistung in einem ausgewogenen Verhältnis zu halten. - Zuordnung von Tabellen und Spalten: Die Abfrage setzt die üblichen Namen von Clarity-Tabellen und -Spalten voraus. Je nach Epic-Konfiguration oder Version Ihrer Organisation können diese abweichen. Passen Sie gegebenenfalls Tabellen- und Spaltennamen sowie Verknüpfungsbedingungen an.
- Transaktions- und Statuscodes: Die Abfrage enthält Platzhalter wie
[Your Denial Tx Type]und[Your Collections Status Code]. Fragen Sie Ihre Epic-Systemadministratoren oder prüfen Sie die entsprechenden Stammdatendateien, etwaZC_TX_TYPEoderZC_ACCOUNT_STATUS, um die für Ihre Instanz gültigen Codes zu ermitteln. - Filter: Ergänzen Sie im ursprünglichen CTE
BaseAccountsFilter, um die Leistung zu verbessern und die Analyse einzugrenzen. Häufige Filter sindSERV_AREA_IDzur Auswahl eines Krankenhausversorgungsbereichs oderACCOUNT_CLASS_Czur Beschränkung auf stationäre oder ambulante Abrechnungen.
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
- Prüfen Sie, ob Sie über autorisierten Zugriff auf den Epic-Clarity-Datensatz zum Abrechnungszyklus verfügen. Dazu gehören die Quelltabellen und Ansichten für Konten, Gebühren, Ansprüche, Ablehnungen, Zahlungen, Anpassungen, Forderungseinzug und Kontoschließungen. Da sich Tabellenverfügbarkeit und Spaltennamen zwischen Epic-Organisationen unterscheiden, ordnen Sie 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. Beginnen Sie mit einem Zeitraum von drei bis sechs Monaten und erweitern Sie ihn erst, nachdem Sie die Abfrageleistung und Vollständigkeit der Ereignisse geprüft haben.
- Legen Sie die Zuordnung für
BillingEventfest. Wenn verfügbar, verwendet die Abfrage standardmäßigHSP_ACCOUNT.HSP_ACCOUNT_IDals Case-Kennung. Definiert Ihre Organisation einen Abrechnungsvorgang auf Ebene einer Gebühr, eines Anspruchs oder eines Kontakts, ersetzen Sie die Zuordnung durch die freigegebene Kennung. Verwenden Sie diese Kennung durchgängig für alle Aktivitätsquellen. - Ordnen Sie jeder Quellaktivität einen maßgeblichen Timestamp und ein Quellattribut zu. Für „Leistung erbracht“ sollte der dokumentierte Timestamp für den Abschluss der Leistung oder des Kontakts verwendet werden. Für „Gebühren erfasst“ ist der Buchungs-Timestamp der Gebühr maßgeblich. Für „Anspruch erstellt“ und „Anspruch beim Kostenträger eingereicht“ sind die entsprechenden Timestamps im Lebenszyklus des Anspruchs zu verwenden. Für Ablehnungen, Nachverfolgung, erneute Einreichungen, Zahlungen, Anpassungen, Forderungseinzug und Kontoschließungen müssen die dokumentierten Transaktions- oder Status-Timestamps verwendet werden.
- Ersetzen Sie alle in eckigen Klammern stehenden Platzhalter für Quelltabellen in der Abfrage, darunter [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 undokumentierten Transaktionscodes. Nutzen Sie die Transaktions- oder Statuswerte, die Ihr Epic-Reporting-Team freigegeben hat.
- Führen Sie die Abfrage im von Ihrer Organisation freigegebenen SQL-Client oder auf der Reporting-Plattform aus. Prüfen Sie, ob alle zwölf Aktivitätsbezeichnungen als eigene Zeilen ausgegeben werden. ProcessMind leitet fehlende Ereignisse im Lebenszyklus nicht aus Salden, Statuswerten oder der Ereignisreihenfolge ab.
- Prüfen Sie das Ausgabeschema. Das Ergebnis muss
BillingEvent,ActivityName,EventTimestamp,ResponsibleUser,BillingDepartment,DenialReasonCode,AdjustmentReason,OutstandingBalanceundServiceTypeenthalten. Dokumentieren Sie, ob Timestamps eine Zeitzone oder Ortszeit verwenden. Bewahren Sie Quellkennungen in einem internen Audit-Export auf, sofern dies zulässig ist. - Prüfen Sie die chronologische Reihenfolge innerhalb jedes
BillingEvent, den Umgang mit Duplikaten, Nullwerte, Aktivitätszahlen und den Abgleich mit Berichten aus dem Quellsystem. Untersuchen Sie Ereignisse außerhalb des angeforderten Zeitraums, wenn sie für die Interpretation von Cases erforderlich sind, die vor diesem Zeitraum beginnen oder danach enden. - Exportieren Sie das Ergebnis als Trennzeichen-Datei oder über eine von ProcessMind unterstützte Datenbankverbindung. Verwenden Sie eine Zeile pro Ereignis, stabile Spaltennamen, ein einheitliches Timestamp-Format und UTF-8-Kodierung. Fügen Sie keine verbundenen Zellen oder Summen für die Darstellung ein. Legen Sie beim Upload
BillingEventals Case-Kennung,ActivityNameals Aktivität undEventTimestampals Ereignis-Timestamp fest.
Konfiguration
- Quellzuordnung: Epic-Clarity-Implementierungen unterscheiden sich. Ersetzen Sie jeden Platzhalter für Quellobjekte und Spalten in eckigen Klammern durch eine dokumentierte Tabelle, Sicht oder freigegebene Berichtsebene in Ihrer Umgebung. Gehen Sie nicht davon aus, dass eine Tabelle oder ein Feld vorhanden ist, nur weil es in einer anderen Epic-Implementierung häufig vorkommt.
- Case-ID: Die Standardzuordnung der Abfrage verwendet HSP_ACCOUNT.HSP_ACCOUNT_ID. Klären Sie, ob Ihre Organisation BillingEvent als Konto, Begegnung, Anspruch, Gebühr oder einen anderen freigegebenen Geschäftsschlüssel definiert.
- Datumsbereich: Beginnen Sie mit drei bis sechs Monaten. Berücksichtigen Sie einen Rückblickzeitraum, wenn Cases vor Beginn des Berichtszeitraums starten können, sowie einen Nachlaufzeitraum, wenn Ansprüche, Ablehnungen, Zahlungen oder Abschlüsse erst nach dem Leistungsdatum erfolgen können.
- Aktivitätszeitstempel: Legen Sie für jede Aktivität einen maßgeblichen Zeitstempel fest. Verwenden Sie nicht die Extraktionszeit, den Zeitpunkt des Dateiimports oder den Zeitstempel des aktuellen Status anstelle des tatsächlichen Ereigniszeitpunkts, es sei denn, dieser ist laut Dokumentation der Ereigniszeitstempel des Quellsystems.
- Filter: Wenden Sie Filter für [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. Verwenden Sie in allen UNION ALL-Zweigen dieselben Filter.
- Zuordnung von Transaktionen und Status: Richten Sie die von Ihrer Organisation freigegebenen Werte für Gebührenbuchung, Anspruchserstellung, Anspruchsübermittlung, Ablehnung, Nachverfolgung, erneute Übermittlung, Zahlungseingang, Zahlungsbuchung, Anpassung, Inkasso und Abschluss ein. Die Abfrage enthält bewusst Platzhalter, da sich Epic-Transaktionswerte und Quellstrukturen je nach Implementierung unterscheiden.
- Umgang mit NULL-Werten: Bewahren Sie NULL für Attribute, 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 anhand indizierter Datumsspalten und freigegebener Organisationsfilter. Verwenden Sie in Prädikaten keine Funktionen auf indizierten Zeitstempelspalten. Bei umfangreichen Rohdaten können Sie die einzelnen Quellaktivitäten in einer freigegebenen Berichtssicht materialisieren.
- Deduplizierung: Entfernen Sie keine doppelten Ereignisse ohne dokumentierte Regel. Mehrere Zahlungen, Anpassungen, Übermittlungen oder Statusänderungen können für ein BillingEvent gültige Ereignisse sein.
- Voraussetzungen: Erforderlich sein können eine Berechtigung für Epic-Clarity-Berichte, Zugriff auf Daten zum Abrechnungszyklus und zur Kontohistorie, eine freigegebene SQL-Ausführungsumgebung sowie die Zustimmung Ihrer Organisation zur Verarbeitung geschützter Gesundheitsdaten. Ob die Historie zu Ansprüchen, Zahlungsavisen, Arbeitswarteschlangen, Inkasso und Abschlüssen verfügbar ist, hängt von den lizenzierten und implementierten Epic-Modulen und Schnittstellen ab.
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; Möchten Sie loslegen?
Mit präzisen Daten können Sie das volle Potenzial Ihres Revenue-Cycle-Management-Prozesses ausschöpfen. Beginnen Sie noch heute, Effizienz und finanzielle Ergebnisse zu verbessern.
Mehr Effizienz: Optimieren Sie jetzt Ihr Revenue Cycle Management
Ermitteln Sie Ineffizienzen im RCM-Prozess in Epic Resolute und verkürzen Sie die Zykluszeit um 30 %.
Keine Kreditkarte erforderlich. Beginnen Sie noch heute mit der Optimierung.