Ihre Revenue Cycle Management Daten-Template
Ihre Revenue Cycle Management Daten-Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Extraktionsanleitung
Revenue Cycle Management Attribute
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der Name des spezifischen Ereignisses oder der Aufgabe, die innerhalb des Revenue Cycle Management Prozesses durchgeführt wurde. | ||
| Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt im Revenue Cycle, wie z.B. 'Leistungen erfasst', 'Forderung an Kostenträger übermittelt' oder 'Zahlung erhalten'. Jede Aktivität stellt einen eigenen Meilenstein im Prozess der Abrechnung und Zahlungseintreibung für eine Leistung dar. Die Analyse von Aktivitäten ist die Grundlage des Process Mining. Sie ermöglicht die Visualisierung der Prozesslandkarte, die Identifizierung gängiger Pfade, die Entdeckung von Bottlenecks zwischen den Schritten und die Messung der Konformität mit Standardarbeitsanweisungen. Bedeutung Definiert die Schritte in der Prozesslandkarte, wodurch es möglich wird, den Arbeitsfluss im Revenue Cycle zu visualisieren, zu analysieren und zu optimieren. Datenquelle Dies wird typischerweise aus Event Logs, Audit Trails oder Statusänderungsdatensätzen innerhalb der Abrechnungs- und Forderungsmodule von Epic Resolute abgeleitet. Beispiele Leistungen erfasstForderung an Zahler übermittelt`Zahlung erhalten`Konto abgeschlossen | |||
| Billing Event BillingEvent | Der eindeutige Identifikator für eine einzelne Service- oder Produktlieferung, die eine Gebühr generiert und als primärer Case-Identifikator dient. | ||
| Beschreibung Das Billing Event ist der zentrale Identifikator, der alle Aktivitäten innerhalb des Revenue Cycle für einen bestimmten abrechenbaren Posten verbindet. Es beginnt, wenn eine Leistung erbracht wird, und endet, wenn das Konto vollständig beglichen oder geschlossen ist. In der Process Mining Analyse ist dieses Attribut unerlässlich, um den End-to-End-Verlauf jeder Leistungsposition zu rekonstruieren. Es ermöglicht die Verfolgung von Aktivitäten wie Leistungserfassung, Forderungseinreichung, Zahlungsbuchung und Ablehnungsmanagement für einzelne Billing Events und bietet eine klare Sicht auf den Prozessfluss und seine Variationen. Bedeutung Dies ist die grundlegende Case ID, entscheidend für die Verknüpfung aller zusammenhängenden Prozessschritte, um den gesamten Lebenszyklus der Umsatzgenerierung und -erfassung für jede Leistung zu analysieren. Datenquelle Dies ist oft ein eindeutiger Identifikator für ein Krankenhaus-Konto (HAR) oder eine spezifische Leistungserfassungssitzung in Epic Resolute. Konsultieren Sie die Epic Resolute Dokumentation für spezifische Tabellen wie HAR oder Charge Session Datensätze. Beispiele BE10098765BE20012345BE30054321 | |||
| Ereignis-Timestamp EventTimestamp | Das genaue Datum und die Uhrzeit, zu der eine Aktivität bzw. ein Ereignis stattgefunden hat. | ||
| Beschreibung Der Event Timestamp erfasst den Zeitpunkt, zu dem eine Aktivität stattfand. Diese temporären Daten sind entscheidend für das Verständnis des Timings und der Reihenfolge der Ereignisse im Revenue Cycle. In der Analyse werden Timestamps verwendet, um Dauern zwischen Aktivitäten zu berechnen, wie z.B. die Verzögerung bei der Leistungserfassung oder die Zahlungsbuchungszeit. Sie ermöglichen die Entdeckung von Bottlenecks, die Messung von Zykluszeiten und die Analyse der Prozessleistung über verschiedene Zeiträume hinweg. Genaue Timestamps sind für nahezu alle zeitbasierten KPIs und Dashboards unerlässlich. Bedeutung Dieses Attribut ist unerlässlich für die Berechnung aller zeitbasierten Metriken, einschließlich Zykluszeiten und Dauern, die grundlegend für die Identifizierung von Verzögerungen und Ineffizienzen sind. Datenquelle In Transaction- oder Event Log-Tabellen innerhalb von Epic Resolute zu finden, Associated with Each Recorded Activity. Fields are Often Named with Suffixes like Dt, DTTM, oder Time. Beispiele 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Ablehnungsgrundcode DenialReasonCode | Ein standardisierter Code, der den Grund angibt, warum ein Zahler eine eingereichte Forderung abgelehnt hat. | ||
| Beschreibung Wenn ein Kostenträger eine Forderung ablehnt, gibt er einen Grundcode an, der die Ablehnung erklärt, wie z.B. 'Nicht abgedeckter Service', 'Doppelte Forderung' oder 'Benötigt zusätzliche Informationen'. Diese Codes sind oft als Claim Adjustment Reason Codes (CARCs) standardisiert. Dieses Attribut ist der Eckpfeiler des Dashboards 'Claim Denial Rates And Reasons'. Die Analyse der Häufigkeit verschiedener Ablehnungscodes hilft, die Ursachen von Ablehnungen zu identifizieren, wie z.B. Berechtigungsprobleme, Kodierungsfehler oder fehlende Vorabgenehmigungen, was gezielte Verbesserungsinitiativen ermöglicht. Bedeutung Erklärt direkt, warum Forderungen abgelehnt werden, und liefert umsetzbare Erkenntnisse, die erforderlich sind, um Ablehnungsquoten zu reduzieren, Umsatzverluste zu verhindern und Zahlungen zu beschleunigen. Datenquelle Diese Daten finden sich in den Forderungsantworttransaktionen (wie einer ANSI 835-Datei), die von Kostenträgern empfangen und im Forderungsmanagementmodul von Epic Resolute gespeichert werden. Beispiele CO-16: Claim/Service fehlen InformationenOA-18: Doppelte Claim/ServicePR-96: Non-Covered Charge(s) | |||
| Abrechnungsabteilung BillingDepartment | Die Abteilung oder das Funktionsteam, das für das Billing Event oder die Aktivität verantwortlich ist. | ||
| Beschreibung Dieses Attribut gibt die Organisationseinheit an, wie z.B. 'Stationäre Abrechnung', 'Ambulante Abrechnung' oder 'Denial Management Team', die mit dem Billing Event verbunden ist oder eine bestimmte Aktivität durchgeführt hat. Diese Dimension ist entscheidend für das Dashboard 'Billing Department Performance Metrics', das einen direkten Vergleich von Schlüsselkennzahlen wie Ablehnungsraten oder Leistungserfassungszeiten ermöglicht. Es hilft dem Management, leistungsstarke Abteilungen zu identifizieren, Best Practices zu standardisieren und Ressourcen effektiv zuzuweisen. Bedeutung Ermöglicht Performance Benchmarking Across Different Departments, Helping to Identify Best Practices und Areas Needing Improvement oder Additional Resources. Datenquelle Diese Informationen könnten mit dem Benutzerdatensatz, dem Patientenkonto oder dem Serviceort innerhalb von Epic Resolute verknüpft sein. Beispiele Kardiologie-AbrechnungRadiologie RCMZentrale Abrechnungsstelle | |||
| Anpassungsgrund AdjustmentReason | Der Grund für eine manuelle oder automatisierte Anpassung des Patientenkontostands. | ||
| Beschreibung Dieses Attribut erklärt, warum ein Kontostand außerhalb einer Standardzahlung oder -leistung geändert wurde. Gründe können vertragliche Vereinbarungen mit Kostenträgern, Abschreibungen geringfügiger Restbeträge oder Korrekturen von Buchungsfehlern sein. Dies ist unerlässlich für das Dashboard 'Account Adjustment Volume By Type'. Durch die Analyse der Anpassungsgründe können Organisationen Quellen für Umsatzverluste identifizieren, die Auswirkungen von Kostenträgerverträgen verstehen und potenzielle Ineffizienzen oder Fehler im Abrechnungsprozess erkennen. Bedeutung Bietet Einblicke in Umsatzverluste und die Abrechnungsgenauigkeit, indem erklärt wird, warum Kontostände geändert werden, was dazu beiträgt, unnötige Abschreibungen zu reduzieren. Datenquelle Located in the Transaction Details for Adjustment Entries within Epic Resolute's Patient Accounting Module. Beispiele Vertragliche ZulageGeringfügige RestbetragsabschreibungKorrektur doppelter Leistungen | |||
| Ausstehender Saldo OutstandingBalance | Der verbleibende Geldbetrag, der vom Kostenträger oder Patienten für das Billing Event geschuldet wird. | ||
| Beschreibung Dieses Attribut repräsentiert den aktuellen Debitorensaldo für ein spezifisches Billing Event zum Zeitpunkt der Aktivität. Es spiegelt den finanziellen Status des Case während seines gesamten Lebenszyklus wider. Der ausstehende Saldo ist entscheidend für die Finanzberichterstattung und für den 'Outstanding Balance Aging Report'. Die Analyse dieses Werts über die Zeit und nach verschiedenen Dimensionen wie Kostenträger oder Abteilung hilft, Inkassoanstrengungen zu priorisieren, den Cashflow zu steuern und das finanzielle Risiko zu bewerten. Bedeutung Misst direkt die finanziellen Auswirkungen von Prozessverzögerungen und ist unerlässlich für die Priorisierung von Inkassoaktivitäten, das Management des Cashflows und das Verständnis der Debitoren. Datenquelle Dies ist ein Kernfeld im Patientenkonto oder Krankenhausaccount (HAR) Datensatz in Epic Resolute. Es ist ein fortlaufender Saldo, der durch Finanztransaktionen aktualisiert wird. Beispiele 1500.00250.750.00 | |||
| Serviceart ServiceType | Die Kategorie oder Art der erbrachten medizinischen Leistung. | ||
| Beschreibung Dieses Attribut klassifiziert die abrechenbare Leistung, zum Beispiel als 'Radiologie', 'Chirurgie', 'Konsultation' oder 'Notaufnahmebesuch'. Es liefert klinischen Kontext zu den Finanzdaten. Die Analyse des Revenue Cycle nach Servicetyp kann prozessuale Variationen aufdecken, die für bestimmte klinische Bereiche spezifisch sind. Chirurgische Eingriffe können beispielsweise komplexere Anforderungen an die Leistungserfassung und Genehmigung haben als ein Standard-Arztbesuch, was zu unterschiedlichem Prozessverhalten und Herausforderungen führt. Bedeutung Bietet klinischen Kontext zu Finanzdaten und ermöglicht die Analyse, wie verschiedene Arten medizinischer Leistungen den Revenue Cycle Prozess und seine Effizienz beeinflussen. Datenquelle Abgeleitet aus dem Leistungsverzeichnis (CDM), der Servicezeile oder der Abteilung, die mit der Charge Transaction in Epic verbunden ist. Beispiele Stationäre ChirurgieAmbulante RadiologieNotfalldienste | |||
| Verantwortlicher Benutzer ResponsibleUser | Der Identifikator des Benutzers oder Mitarbeiters, der die Aktivität durchgeführt hat. | ||
| Beschreibung Dieses Attribut erfasst die Benutzer-ID, den Namen oder die Personalnummer der Person, die für die Durchführung einer bestimmten Aufgabe im Revenue Cycle verantwortlich ist. Dies könnte der Kliniker sein, der Leistungen eingegeben hat, der Abrechner, der eine Forderung eingereicht hat, oder der Inkassomitarbeiter, der eine Ablehnung nachverfolgt hat. Die Analyse nach Benutzern hilft, Top-Performer zu identifizieren, Schulungsbedarfe zu lokalisieren und die Arbeitslastverteilung zu verstehen. Sie ist entscheidend für das Performance Management und die Untersuchung von Prozessabweichungen, die mit bestimmten Personen oder Rollen verbunden sind. Bedeutung Ermöglicht eine Leistungsanalyse nach Person oder Rolle, was hilft, Schulungsmöglichkeiten, unausgeglichene Arbeitslasten und ressourcenbedingte Engpässe zu identifizieren. Datenquelle Typischerweise in Audit Trails oder Transaktionsprotokollen innerhalb von Epic Resolute zu finden, oft verknüpft mit einer Benutzer-Stammdatentabelle (z.B. EMP-Datensatz). Beispiele j.doebsmith123User7890 | |||
| Angepasster Betrag AdjustedAmount | Der monetäre Wert einer Anpassungstransaktion. | ||
| Beschreibung Dieses Feld erfasst den spezifischen Dollarbetrag einer Kontenanpassung. Es kann ein positiver oder negativer Wert sein, der eine Gutschrift oder Belastung des Kontostands darstellt. Dieser Betrag ist die primäre Metrik für das Dashboard 'Account Adjustment Volume By Type'. Die Summe dieses Werts nach Anpassungsgrund liefert ein klares Bild der finanziellen Auswirkungen verschiedener Anpassungsarten, z.B. wie viele Einnahmen aufgrund vertraglicher Verpflichtungen abgeschrieben werden im Vergleich zu Verlusten durch korrigierbare Fehler. Bedeutung Quantifiziert die finanziellen Auswirkungen von Kontokorrekturen und ermöglicht so die Messung von Umsatzverlusten und den Kosten von Abrechnungsfehlern. Datenquelle Located in the Financial Transaction Detail Tables in Epic Resolute, Associated with Adjustment-Type Transactions. Beispiele -1250.45-50.0025.10 | |||
| Bearbeitungszeit ProcessingTime | Die berechnete Dauer der aktiv auf eine Activity verwendeten Zeit. | ||
| Beschreibung Die Bearbeitungszeit, auch bekannt als Handhabungszeit, misst die Dauer einer Aktivität von ihrem Beginn bis zu ihrem Ende. Sie stellt die Zeit dar, in der eine Ressource aktiv mit der Aufgabe beschäftigt war. Diese Kennzahl wird als Differenz zwischen 'EventEndTime' und 'EventTimestamp' berechnet. Die Analyse der Bearbeitungszeit hilft zu identifizieren, welche spezifischen Aufgaben am zeitaufwändigsten sind, und ermöglicht gezielte Anstrengungen zur Straffung und Effizienzsteigerung. Es ist ein grundlegendes Maß für die Ressourcenproduktivität. Bedeutung Misst die Actual Work Duration of Activities, Helping to Identify Time-Consuming Tasks und Evaluate the Efficiency of Resources. Datenquelle Dies ist kein Feld im Quellsystem. Es wird während der Datentransformation mit der Formel: EventEndTime - EventTimestamp berechnet. Beispiele 900605120 | |||
| Endzeit des Events EventEndTime | Der Timestamp, der anzeigt, wann eine Aktivität abgeschlossen wurde, nützlich zur Berechnung der Aktivitätsdauer. | ||
| Beschreibung Dieses Attribut erfasst die Abschlusszeit einer Aktivität. Während viele Aktivitäten sofortige Ereignisse sind, bei denen StartTime gleich EndTime ist, haben einige Aufgaben eine messbare Dauer, wie z.B. ein Anruf zur Ablehnungsnachverfolgung. Wenn verfügbar, ermöglicht EndTime die direkte Berechnung der Aktivitätsbearbeitungszeit ('EndTime' - 'StartTime'). Dies ist genauer als die Ableitung der Dauer aus der Startzeit der nächsten Aktivität, da es Leerlaufzeiten zwischen den Schritten berücksichtigt. Es ist eine Schlüsselkomponente für die Berechnung des 'ProcessingTime'-Attributs. Bedeutung Ermöglicht die präzise Berechnung der Dauer jeder Aktivität, was entscheidend ist, um ineffiziente Aufgaben zu identifizieren und die Ressourcenproduktivität zu messen. Datenquelle Dies ist möglicherweise in einigen Epic Resolute Modulen verfügbar, die den Start und das Ende von Aufgaben verfolgen, wie z.B. Workqueue- oder Aktivitätsmanagement-Protokolle. Oft wird es nicht explizit verfolgt. Beispiele 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| Gesamte Revenue Cycle Zeit TotalRevenueCycleTime | Die gesamte berechnete Dauer vom ersten Service-Event bis zur endgültigen Zahlung oder zum Kontenabschluss. | ||
| Beschreibung Dies ist ein Case-Level-KPI, der die End-to-End-Dauer des Revenue Cycle für ein einzelnes Billing Event misst. Er wird typischerweise als Zeitdifferenz zwischen der Aktivität 'Service Rendered' und der finalen Aktivität 'Payment Received' oder 'Account Closed' berechnet. Diese übergeordnete Metrik bietet eine umfassende Sicht auf die Gesamteffizienz des RCM-Prozesses. Die Verfolgung dieses KPI über die Zeit hilft, die Auswirkungen von Prozessverbesserungsinitiativen zu messen und liefert einen Schlüsselindikator für die Geschwindigkeit der Cash-Konvertierung. Bedeutung Bietet eine übergeordnete End-to-End-Ansicht der Prozesseffizienz, indem direkt gemessen wird, wie lange es dauert, eine Dienstleistung in Barmittel umzuwandeln. Datenquelle Dies ist eine Metrik, die innerhalb des Process Mining Tools berechnet wird, indem nach den ersten und letzten Ereignissen jedes Case gefiltert und die Zeitdifferenz ermittelt wird. Beispiele 259200038880005184000 | |||
| Ist automatisiert IsAutomated | Ein Boolesches Flag, das angibt, ob die Aktivität von einem System oder einem automatisierten Prozess durchgeführt wurde. | ||
| Beschreibung Dieses Flag unterscheidet zwischen Aufgaben, die automatisch vom System ausgeführt werden, wie z.B. die automatisierte Forderungsgenerierung oder Berechtigungsprüfungen, und solchen, die manuell von einem Benutzer durchgeführt werden. Die Analyse dieses Attributs hilft, den Automatisierungsgrad im Prozess zu verstehen. Es kann verwendet werden, um die Effizienz und Fehlerraten von automatisierten versus manuellen Aktivitäten zu vergleichen, Möglichkeiten für weitere Automatisierung zu identifizieren und die Leistung bestehender Bots oder Systemregeln zu überwachen. Bedeutung Unterscheidet zwischen systemgesteuerten und menschlich gesteuerten Aktivitäten, was entscheidend ist, um die Auswirkungen der Automatisierung zu bewerten und neue Automatisierungsmöglichkeiten zu identifizieren. Datenquelle Dies wird oft abgeleitet, indem geprüft wird, ob der 'ResponsibleUser' für eine Aktivität ein System- oder Service-Account ist, oder indem spezifische Aktivitätsnamen, die als automatisiert bekannt sind, gekennzeichnet werden. Beispiele truefalsch | |||
| Letzte Datenaktualisierung LastDataUpdate | Der `Timestamp`, der angibt, wann die `Data` für dieses `Event` zuletzt aktualisiert oder aus dem Quellsystem extrahiert wurde. | ||
| 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 Zeitgerechtigkeit der Analyse zu verstehen und zur Datenvalidierung. Es hilft Benutzern zu erkennen, ob sie die aktuellsten verfügbaren Informationen betrachten, und ist kritisch für die Verwaltung von Datenaktualisierungszyklen. Bedeutung Stellt sicher, dass Benutzer die Aktualität der von ihnen analysierten Daten verstehen, was entscheidend für genaue und aktuelle Geschäftsentscheidungen ist. Datenquelle Dieser Timestamp wird vom ETL-Prozess (Extract, Transform, Load) während der Datenaufnahme hinzugefügt. Beispiele 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| Patienten-ID PatientId | Der eindeutige Identifikator des Patienten, der die Leistung erhält. | ||
| Beschreibung Dieses Attribut ist die Patienten-ID (Medical Record Number, MRN) oder ein anderer eindeutiger Identifikator für den Patienten. Es verbindet das finanzielle Billing Event mit einer bestimmten Person. Obwohl es normalerweise nicht als primäre Analyse-Dimension zum Schutz der Patientendatenschutz verwendet wird, ist es für die Datenvalidierung unerlässlich und kann verwendet werden, um alle Billing Events für einen einzelnen Patienten zu aggregieren, um deren gesamte finanzielle Reise zu verstehen. Es ist auch entscheidend für jede potenzielle Integration mit klinischen Prozessdaten. Bedeutung Links Financial Data to a Specific Patient, Enabling Data Validation und Potential for Broader Analysis of a Patient's Entire Journey, Though It Must be Handled with Care Due to Privacy Concerns. Datenquelle Eine grundlegende Kennung, die in Epic durchgängig zu finden ist und mit der Patientenregistrierung sowie den Kontenunterlagen 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, das in diesem Kontext Epic Resolute ist. In Umgebungen mit mehreren integrierten Systemen hilft dieses Feld, die Datenherkunft zu unterscheiden. Obwohl es in einer Einzelsystemansicht redundant erscheinen mag, ist es eine Best Practice für Data Governance und Skalierbarkeit. Es sorgt für Klarheit, wenn Daten aus anderen Systemen, wie z.B. einer separaten Inkassoplattform, später integriert werden. Bedeutung Liefert entscheidende Datenherkunft und Kontext, um Klarheit über den Ursprung der Daten zu gewährleisten, was für die Data Governance und Fehlerbehebung unerlässlich ist. Datenquelle Dabei handelt es sich typischerweise um einen statischen Wert, der während der Datenextraktion und -transformation hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Epic ResoluteEpicResolute_V2023 | |||
| Schaden-ID ClaimId | Der eindeutige Identifikator, der einer an einen Kostenträger übermittelten Versicherungsforderung zugewiesen wird. | ||
| Beschreibung Dieses Attribut ist die spezifische ID für das an einen Kostenträger gesendete Forderungsformular (z.B. ein CMS-1500 oder UB-04). Ein einzelnes Billing Event kann mehrere Forderungen umfassen, wenn Leistungen erneut abgerechnet oder angefochten werden. Die Verfolgung nach Claim ID ist nützlich für eine detaillierte Analyse der Unterprozesse der Forderungseinreichung und des Ablehnungsmanagements. Es hilft, Aktivitäten im Zusammenhang mit der ursprünglichen Forderung von denen im Zusammenhang mit einer nachfolgenden, erneut eingereichten Forderung für dieselbe Leistung zu unterscheiden. Bedeutung Bietet einen granularen Identifikator zur Verfolgung des Lebenszyklus jeder spezifischen Forderungseinreichung, was für die Analyse von erneuten Einreichungen und Einsprüchen entscheidend ist. Datenquelle Generiert vom Claims Management Module von Epic Resolute, wenn ein Claim Created ist. Es ist Stored in the Claims Data Tables. Beispiele CLM-2023-98765CLAIM-0012345623189A4567 | |||
| Zahlername PayerName | Der Name der Versicherungsgesellschaft, Regierungseinheit oder anderen für die Zahlung verantwortlichen Partei. | ||
| Beschreibung Dieses Attribut identifiziert den primären Kostenträger, der mit dem Billing Event verbunden ist, wie z.B. 'Blue Cross Blue Shield', 'Medicare' oder 'Aetna'. Bei Selbstzahlern kann es den Patienten angeben. Die Segmentierung des Prozesses nach Kostenträger ist eine leistungsstarke Analysetechnik. Sie kann aufzeigen, dass bestimmte Kostenträger höhere Ablehnungsquoten, längere Zahlungszyklen oder komplexere Anforderungen haben. Dieser Einblick ermöglicht die Anpassung von Abrechnungsstrategien an spezifische Kostenträger, um die Effizienz und Zahlungsgeschwindigkeit zu verbessern. Bedeutung Ermöglicht eine Leistungsanalyse nach Zahler, wodurch aufgedeckt wird, welche Zahler hohe Ablehnungsquoten oder langsame Zahlungszyklen aufweisen, was gezielte Nachverfolgungsstrategien ermöglicht. Datenquelle Diese Informationen sind Teil der Patientendeckungsdetails, die mit dem Krankenhausaccount (HAR) in Epic Resolute verknüpft sind. Beispiele Medicare Teil BUnitedHealthcareAetna PPO | |||
| Zahlungsfälligkeitsdatum PaymentDueDate | Das Datum, bis zu dem die Zahlung für die abgerechnete Leistung erwartet wird. | ||
| Beschreibung Dieses Attribut gibt die Zahlungsfrist an, wie auf der Rechnung angegeben oder durch Kostenträgerverträge festgelegt. Es dient als Benchmark zur Messung pünktlicher Zahlungen. Das Fälligkeitsdatum der Zahlung ist unerlässlich für die Erstellung des 'Outstanding Balance Aging Report'. Durch den Vergleich des aktuellen Datums mit dem Fälligkeitsdatum für offene Salden können die Forderungen in Alterskategorien eingeteilt werden (z.B. 0-30 Tage, 31-60 Tage überfällig), was hilft, die Inkassoanstrengungen auf die am längsten überfälligen Konten zu priorisieren. Bedeutung Dient als Grundlage für die Analyse der Debitoren-Altersstruktur, die entscheidend ist für die Priorisierung des Inkassos und das Management des finanziellen Risikos unbezahlter Rechnungen. Datenquelle Dieses Datum wird oft basierend auf dem Rechnungsdatum und den Zahlungsbedingungen berechnet, die im Kostenträgervertrag oder in den Patientenkontoinformationen innerhalb von Epic gespeichert sind. Beispiele 2023-05-302023-06-152023-07-01 | |||
Revenue Cycle Management Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
| `Zahlung erhalten` | Stellt den Zahlungseingang von einem Kostenträger oder Patienten dar. Dieses Ereignis wird typischerweise erfasst, wenn ein elektronisches Zahlungsavis (ERA) geladen oder ein manueller Scheck in das System eingegeben wird. | ||
| Bedeutung Diese Aktivität ist ein wichtiger Meilenstein, der anzeigt, dass Einnahmen eingehen. Die Zeit zwischen Forderungseinreichung und Zahlungseingang ist ein Schlüsselmaß für die Leistung der Forderungsbuchhaltung. Datenquelle Explizit als Payment Transaction in Resolute erfasst. Diese Transactions sind Logged with a Date, Source, und Amount, oft Before They are Fully Posted to Individual Charges. Erfassen Erfassen Sie Zahlungstransaktionen aus dem Finanztransaktionsprotokoll, oft identifizierbar durch spezifische Transaktionstypen. Ereignistyp explicit | |||
| Forderung an Zahler übermittelt | Dies markiert das Ereignis, bei dem die Forderung offiziell zur Bearbeitung an den Versicherer gesendet wird. In Epic ist dies ein verfolgtes Ereignis, das protokolliert wird, wenn die elektronische Forderungsdatei an das Clearinghaus oder den Kostenträger übermittelt wird. | ||
| Bedeutung Dieser Meilenstein ist entscheidend, da er den Beginn der Zahlungsfrist des Kostenträgers markiert. Die Analyse hilft, die Effizienz des Forderungsübermittlungsprozesses zu messen und unterstützt den KPI 'Invoice to Payer Delivery Time'. Datenquelle Dies ist ein explizites Ereignis, das in Resolute erfasst wird. Der Forderungsdatensatz enthält einen Einreichungsstatus und einen Timestamp, der angibt, wann er gesendet wurde. Erfassen Erfassen Sie den Timestamp, der mit der Statusänderung der Claim zu 'Submitted' oder 'Transmitted' verbunden ist. Ereignistyp explicit | |||
| Forderung vom Zahler abgelehnt | Stellt den Erhalt einer Benachrichtigung vom Kostenträger dar, dass die Forderung abgelehnt wurde. Dies wird erfasst, wenn Epic eine elektronische Zahlungsavis (835-Datei) verarbeitet oder wenn ein Benutzer eine Ablehnung manuell verbucht. | ||
| Bedeutung Diese Aktivität initiiert eine kritische Nacharbeits-Schleife. Die Analyse der Ablehnungsgründe und -volumina ist entscheidend, um die Ursachen zu identifizieren, die Erst-Pass-Zahlungsraten zu verbessern und Inkassoverzögerungen zu reduzieren. Datenquelle Explizit als Transaction oder Status Update auf dem Claim erfasst. Denial Information, Including Reason Codes, ist Typically Received Electronically und Posted to the Account. Erfassen Filtern Sie nach spezifischen Transaktionstypen oder Claim Status Updates, die einen Denial anzeigen. Ereignistyp explicit | |||
| Konto abgeschlossen | Dies ist die letzte Aktivität, die signalisiert, dass der ausstehende Saldo des Billing Event null erreicht hat und keine weiteren Aktivitäten ausstehen. Dies kann auf vollständige Zahlung, Anpassungen oder eine Abschreibung zurückzuführen sein. | ||
| Bedeutung Dieses Ereignis markiert den erfolgreichen Abschluss des Revenue Cycle für ein Billing Event. Die End-to-End-Dauer von der Leistung bis zum Abschluss ist ein kritischer KPI für die Gesamtprozesseffizienz. Datenquelle Dies ist typischerweise ein abgeleitetes Ereignis. Es wird durch die Identifizierung des Zeitpunkts bestimmt, zu dem der Kontostand für das Billing Event null wird und null bleibt. Erfassen Abgeleitet durch die Berechnung einer Running Total des Account Balance und die Identifizierung des Timestamp der Last Transaction that Made the Balance Zero. Ereignistyp inferred | |||
| Leistung erbracht | Diese Aktivität markiert den Zeitpunkt, an dem eine klinische Leistung für den Patienten erbracht wird, was das Billing Event initiiert. Dies wird oft aus dem Epic EHR (EpicCare) erfasst, wenn ein Kliniker einen Besuch oder ein Verfahren abschließt. | ||
| Bedeutung Dies ist das primäre Start-Event für den Revenue Cycle. Die Analyse der Zeit von diesem Punkt bis zur Leistungserfassung ist entscheidend, um Verzögerungen bei der Rechnungsstellung und potenzielle Umsatzverluste zu identifizieren. Datenquelle Dieses Ereignis wird typischerweise aus Service- oder Besuchs-Timestamps in den klinischen Modulen abgeleitet, die mit dem Abrechnungskonto verknüpft sind. Das Leistungsdatum auf der Abrechnungstransaktion ist der zentrale Datenpunkt. Erfassen Abgeleitet vom Service Date Associated with the First Charge Transaction for the Billing Event. Ereignistyp inferred | |||
| Leistungen erfasst | Stellt die formale Erfassung abrechenbarer Leistungen für die erbrachten Dienste dar. In Epic ist dies typischerweise eine explizite Transaktion, die auf dem Patienten-Konto gebucht wird, oft automatisch aus klinischen Aktionen generiert oder manuell eingegeben. | ||
| Bedeutung Dies ist ein kritischer erster Meilenstein. Die Messung der Geschwindigkeit und Genauigkeit der Leistungserfassung hilft, den Abrechnungsprozess zu beschleunigen und sicherzustellen, dass alle erbrachten Leistungen abgerechnet werden. Datenquelle Explizit in Resolute's Transaction Logs erfasst. Jede Charge ist ein Discrete Entry with a Post Date, Service Date, und Amount, oft Found in Tables wie ARPB_TRANSACTIONS. Erfassen Erfassen Sie Buchungstransaktionen aus dem Finanztransaktionsprotokoll des Systems. Ereignistyp explicit | |||
| Zahlung dem Konto zugewiesen | Dies ist das Ereignis, bei dem eine erhaltene Zahlung auf spezifische Leistungen auf dem Patientenkonto angewendet oder zugewiesen wird. Diese Aktion reduziert den ausstehenden Saldo des Billing Event. | ||
| Bedeutung Effizientes Payment Posting ist entscheidend für Maintaining Accurate Account Balances und Closing out Billing Events. Es Allows for Correct Identification of Remaining Balances for Secondary Billing oder Collections. Datenquelle Dies ist eine explizite Transaktion in Resolute. Die Zahlungsbuchung verknüpft eine Zahlungstransaktion mit einer oder mehreren Leistungstransaktionen, was in den Transaktionsdetailtabellen erfasst wird. Erfassen Erfassen Sie den Transaktionsdatensatz, der eine Zahlung einer Leistung zuweist, identifizierbar durch spezifische Transaktionstypen. Ereignistyp explicit | |||
| Forderung erneut eingereicht | Dieses Ereignis tritt ein, nachdem eine abgelehnte Forderung korrigiert und erneut an den Kostenträger gesendet wurde. Dies ist ein separates Einreichungsereignis, das mit der ursprünglichen Forderung verknüpft ist. | ||
| Bedeutung Dies ist ein wichtiger Bestandteil der Nacharbeits-Schleife. Die Messung der Zeit bis zur erneuten Einreichung und der Erfolgsquote der erneut eingereichten Forderungen ist entscheidend für das Verständnis der Wirksamkeit des Ablehnungsbeilegungsprozesses. Datenquelle Dies ist ein explizites Ereignis, ähnlich der ursprünglichen Einreichung, aber oft als erneute Einreichung gekennzeichnet. Der Forderungsdatensatz zeigt einen neuen Einreichungs-Timestamp und kann einen Wiedereinreichungscode enthalten. Erfassen Erfassen Sie den Timestamp für eine Claim Submission, die als Correction oder Resubmission gekennzeichnet ist. Ereignistyp explicit | |||
| Forderung generiert | Diese Aktivität kennzeichnet die Erstellung einer formalen Forderung oder Rechnung durch das System auf der Grundlage der erfassten Leistungen. Es ist ein vorbereitender Schritt, bevor die Forderung an den Kostenträger oder Patienten gesendet wird. | ||
| Bedeutung Die Verfolgung der Forderungsgenerierung hilft, Verzögerungen zwischen der Erfassung der Leistungen und deren Vorbereitung zur Einreichung zu isolieren. Es ist ein wichtiger interner Schritt, der die gesamte Pünktlichkeit der Abrechnung beeinflussen kann. Datenquelle Dies wird typischerweise protokolliert, wenn ein Batch-Job zur Abrechnungs- oder Forderungsgenerierung läuft. Das System zeichnet einen Timestamp auf, wenn die Forderungsdatei (wie eine 837-Datei) für ein bestimmtes Konto erstellt wird. Erfassen Identifizieren Sie Log Entries oder Status Changes Indicating the Claim has been Compiled und is Ready for Submission. Ereignistyp explicit | |||
| Kontenanpassung vorgenommen | Diese Aktivität stellt eine Nicht-Zahlungstransaktion dar, die den Kontostand ändert, wie z.B. eine vertragliche Anpassung, eine Abschreibung geringfügiger Restbeträge oder ein Kulanzrabatt. Dies wird als spezifischer Transaktionstyp erfasst. | ||
| Bedeutung Die Analyse von Anpassungen ist entscheidend für die Identifizierung von Umsatzverlusten. Hohe Volumina bestimmter Anpassungstypen können auf Probleme mit Gebührenordnungen, Vertragsgestaltung oder internen Richtlinien hinweisen. Datenquelle Explizit als Adjustment Transactions in Resolute's Financial Logs erfasst. Jeder Adjustment will have a Specific Type oder Reason Code Associated with It. Erfassen Filtern Sie nach Transaktionstypen, die Financial Adjustments oder Write-Offs entsprechen. Ereignistyp explicit | |||
| Nachverfolgung der Ablehnung initiiert | Diese Aktivität markiert den Beginn des internen Prozesses zur Überprüfung und Beilegung einer abgelehnten Forderung. Sie wird oft erfasst, wenn ein Benutzer die abgelehnte Forderung in einer Workqueue übernimmt oder ihren Status ändert. | ||
| Bedeutung Die Verfolgung hilft, die Reaktionsfähigkeit des Denial Management Teams zu messen. Verzögerungen zwischen einer Ablehnung und dem Beginn der Nachverfolgung können den Revenue Cycle unnötig verlängern. Datenquelle Dies wird typischerweise aus Änderungen des Forderungsstatus oder der Zuweisungshistorie innerhalb der Epic Workqueues abgeleitet. Zum Beispiel könnte sich der Status der Forderung von 'Abgelehnt' zu 'In Überprüfung' ändern. Erfassen Abgeleitet von einer Claim Status Change oder einem Audit Log Entry Showing a User has Started Working the Denial. Ereignistyp inferred | |||
| Saldo an Inkasso gesendet | Dies markiert den Zeitpunkt, an dem ein unbezahlter Kontostand an einen internen oder externen Inkassoprozess übertragen wird. Dies ist oft eine explizite Statusänderung im Konto oder Billing Event. | ||
| Bedeutung Diese Aktivität leitet die letzte Phase der Eintreibung unbezahlter Salden ein. Die Verfolgung der Erfolgsquote und der Zykluszeit des Inkassoprozesses ist entscheidend, um uneinbringliche Forderungen zu minimieren. Datenquelle Dies ist typischerweise ein explizites Ereignis. Epic verfügt über Funktionen zur Übertragung von Konten an Inkassobüros, was einen Protokolleintrag oder eine Statusänderung im Konto erzeugt. Erfassen Identifizieren Sie den Status Change oder die Transaction that Indicates an Account has been Placed with a Collection Agency. Ereignistyp explicit | |||
Extraktionsleitfäden
Schritte
- Datenbankverbindung herstellen: Besorgen Sie sich 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.
- Kerntabellen identifizieren: Die primären Tabellen für diese Extraktion umfassen
HSP_ACCOUNTfür Fallinformationen,HSP_TRANSACTIONSfür Finanzereignisse,CLP_CLAIM_INFOfür den Forderungsstatus undF_ARHB_TX_SET_POST_HXfür Details zur Zahlungsbuchung. Sie werden auch Masterdateien wieCLARITY_EMPfür Benutzerdetails verknüpfen. - Umfang definieren: Bevor Sie die Abfrage schreiben, legen Sie den Umfang Ihrer Analyse fest. Definieren Sie einen bestimmten Datumsbereich, typischerweise 3 bis 6 Monate, und identifizieren Sie alle spezifischen Krankenhaus-Servicebereiche (
SERV_AREA_ID) oder Kontenklassen, die Sie einschließen oder ausschließen möchten. - SQL-Abfrage entwickeln: Erstellen Sie eine SQL-Abfrage mithilfe eines Common Table Expression (CTE), um zunächst die Menge der
HSP_ACCOUNT_ID-Werte auszuwählen, die in Ihren definierten Umfang fallen. Dies dient als Basispopulation der Billing Events. - Einzelne Aktivitätsabfragen vereinigen: Für jede der 12 erforderlichen Aktivitäten schreiben Sie eine separate
SELECT-Anweisung, die Daten aus den relevanten Tabellen abruft. Verknüpfen Sie diese mit Ihrer anfänglichen CTE, um sicherzustellen, dass Sie nur die beabsichtigten Konten analysieren. - Abfragen mit UNION ALL kombinieren: Verwenden Sie den
UNION ALL-Operator, um die Ergebnisse aller einzelnen Aktivitätsabfragen zu einem einzigen, kohärenten Event Log zu kombinieren. Dies stapelt die Zeilen jeder Abfrage vertikal. - Auf Standard-Schema abbilden: In jeder
SELECT-Anweisung aliasieren Sie die Spalten, um sie dem erforderlichen ProcessMind-Schema anzupassen:BillingEvent,ActivityName,EventTimestamp,ResponsibleUserusw. Verwenden SieNULLfür Attribute, die für eine bestimmte Aktivität nicht zutreffen. - Abfrage ausführen und verfeinern: Führen Sie die vollständige Abfrage gegen die Clarity-Datenbank aus. Aufgrund der Größe der Tabellen kann dies eine erhebliche Zeit in Anspruch nehmen. Sollte die Leistung ein Problem darstellen, schränken Sie den Datumsbereich weiter ein oder fügen Sie spezifischere Filter in der anfänglichen CTE hinzu.
- Ausgabe überprüfen: Sobald die Abfrage abgeschlossen ist, überprüfen Sie die ersten paar hundert Zeilen der Ausgabe. Vergewissern Sie sich, dass alle Spalten vorhanden sind, Timestamps in einem konsistenten Format vorliegen und verschiedene
ActivityName-Werte wie erwartet erscheinen. - Als CSV exportieren: Exportieren Sie das gesamte Ergebnisset von Ihrem SQL-Client in eine CSV-Datei. Stellen Sie sicher, dass die Datei UTF-8-Codierung verwendet und eine Kopfzeile mit den korrekten Spaltennamen enthält.
- Für den Upload vorbereiten: Bevor Sie die Datei zu ProcessMind hochladen, öffnen Sie die CSV-Datei, um sicherzustellen, dass keine Formatierungsfehler vorliegen. Überprüfen Sie, ob das Timestamp-Format konsistent ist, z. B.
JJJJ-MM-TT HH:MI:SS. Die Datei ist nun bereit für die Erfassung.
Konfiguration
- Datenbankverbindung: Es ist ein schreibgeschützter Benutzerzugang zur Epic Clarity-Datenbank erforderlich.
- Datumsbereichsparameter: Die bereitgestellte Abfrage verwendet die Variablen
@StartDateund@EndDate. Diese müssen festgelegt werden, um den Analysezeitraum zu definieren. Ein Bereich von 3 bis 6 Monaten wird empfohlen, um das Datenvolumen mit der Leistung in Einklang zu bringen. - Tabellen- und Spaltenzuordnung: Die Abfrage geht von Standard-Clarity-Tabellen- und Spaltennamen aus. Die spezifische Epic-Konfiguration oder -Version Ihrer Organisation kann Abweichungen aufweisen. Möglicherweise müssen Sie Tabellennamen, Spaltennamen oder Join-Bedingungen entsprechend anpassen.
- Transaktions- und Statuscodes: Die Abfrage enthält Platzhalter wie
[Your Denial Tx Type]und[Your Collections Status Code]. Sie müssen Ihre Epic-Systemadministratoren konsultieren oder die relevanten Masterdateien, wieZC_TX_TYPEoderZC_ACCOUNT_STATUS, überprüfen, um die korrekten Codes für Ihre Instanz zu finden. - Filterung: Für eine bessere Leistung und eine fokussiertere Analyse fügen Sie Filter zur anfänglichen
BaseAccountsCTE hinzu. Gängige Filter umfassenSERV_AREA_ID, um nach Krankenhaus-Servicebereich zu begrenzen, oderACCOUNT_CLASS_C, um sich auf stationäre oder ambulante Abrechnungen zu konzentrieren.
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
- Datenbankverbindung herstellen: Besorgen Sie sich 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.
- Kerntabellen identifizieren: Die primären Tabellen für diese Extraktion umfassen
HSP_ACCOUNTfür Fallinformationen,HSP_TRANSACTIONSfür Finanzereignisse,CLP_CLAIM_INFOfür den Forderungsstatus undF_ARHB_TX_SET_POST_HXfür Details zur Zahlungsbuchung. Sie werden auch Masterdateien wieCLARITY_EMPfür Benutzerdetails verknüpfen. - Umfang definieren: Bevor Sie die Abfrage schreiben, legen Sie den Umfang Ihrer Analyse fest. Definieren Sie einen bestimmten Datumsbereich, typischerweise 3 bis 6 Monate, und identifizieren Sie alle spezifischen Krankenhaus-Servicebereiche (
SERV_AREA_ID) oder Kontenklassen, die Sie einschließen oder ausschließen möchten. - SQL-Abfrage entwickeln: Erstellen Sie eine SQL-Abfrage mithilfe eines Common Table Expression (CTE), um zunächst die Menge der
HSP_ACCOUNT_ID-Werte auszuwählen, die in Ihren definierten Umfang fallen. Dies dient als Basispopulation der Billing Events. - Einzelne Aktivitätsabfragen vereinigen: Für jede der 12 erforderlichen Aktivitäten schreiben Sie eine separate
SELECT-Anweisung, die Daten aus den relevanten Tabellen abruft. Verknüpfen Sie diese mit Ihrer anfänglichen CTE, um sicherzustellen, dass Sie nur die beabsichtigten Konten analysieren. - Abfragen mit UNION ALL kombinieren: Verwenden Sie den
UNION ALL-Operator, um die Ergebnisse aller einzelnen Aktivitätsabfragen zu einem einzigen, kohärenten Event Log zu kombinieren. Dies stapelt die Zeilen jeder Abfrage vertikal. - Auf Standard-Schema abbilden: In jeder
SELECT-Anweisung aliasieren Sie die Spalten, um sie dem erforderlichen ProcessMind-Schema anzupassen:BillingEvent,ActivityName,EventTimestamp,ResponsibleUserusw. Verwenden SieNULLfür Attribute, die für eine bestimmte Aktivität nicht zutreffen. - Abfrage ausführen und verfeinern: Führen Sie die vollständige Abfrage gegen die Clarity-Datenbank aus. Aufgrund der Größe der Tabellen kann dies eine erhebliche Zeit in Anspruch nehmen. Sollte die Leistung ein Problem darstellen, schränken Sie den Datumsbereich weiter ein oder fügen Sie spezifischere Filter in der anfänglichen CTE hinzu.
- Ausgabe überprüfen: Sobald die Abfrage abgeschlossen ist, überprüfen Sie die ersten paar hundert Zeilen der Ausgabe. Vergewissern Sie sich, dass alle Spalten vorhanden sind, Timestamps in einem konsistenten Format vorliegen und verschiedene
ActivityName-Werte wie erwartet erscheinen. - Als CSV exportieren: Exportieren Sie das gesamte Ergebnisset von Ihrem SQL-Client in eine CSV-Datei. Stellen Sie sicher, dass die Datei UTF-8-Codierung verwendet und eine Kopfzeile mit den korrekten Spaltennamen enthält.
- Für den Upload vorbereiten: Bevor Sie die Datei zu ProcessMind hochladen, öffnen Sie die CSV-Datei, um sicherzustellen, dass keine Formatierungsfehler vorliegen. Überprüfen Sie, ob das Timestamp-Format konsistent ist, z. B.
JJJJ-MM-TT HH:MI:SS. Die Datei ist nun bereit für die Erfassung.
Konfiguration
- Datenbankverbindung: Es ist ein schreibgeschützter Benutzerzugang zur Epic Clarity-Datenbank erforderlich.
- Datumsbereichsparameter: Die bereitgestellte Abfrage verwendet die Variablen
@StartDateund@EndDate. Diese müssen festgelegt werden, um den Analysezeitraum zu definieren. Ein Bereich von 3 bis 6 Monaten wird empfohlen, um das Datenvolumen mit der Leistung in Einklang zu bringen. - Tabellen- und Spaltenzuordnung: Die Abfrage geht von Standard-Clarity-Tabellen- und Spaltennamen aus. Die spezifische Epic-Konfiguration oder -Version Ihrer Organisation kann Abweichungen aufweisen. Möglicherweise müssen Sie Tabellennamen, Spaltennamen oder Join-Bedingungen entsprechend anpassen.
- Transaktions- und Statuscodes: Die Abfrage enthält Platzhalter wie
[Your Denial Tx Type]und[Your Collections Status Code]. Sie müssen Ihre Epic-Systemadministratoren konsultieren oder die relevanten Masterdateien, wieZC_TX_TYPEoderZC_ACCOUNT_STATUS, überprüfen, um die korrekten Codes für Ihre Instanz zu finden. - Filterung: Für eine bessere Leistung und eine fokussiertere Analyse fügen Sie Filter zur anfänglichen
BaseAccountsCTE hinzu. Gängige Filter umfassenSERV_AREA_ID, um nach Krankenhaus-Servicebereich zu begrenzen, oderACCOUNT_CLASS_C, um sich auf stationäre oder ambulante Abrechnungen zu konzentrieren.
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;