Ihr Daten-Template für Revenue Cycle Management
Ihr Daten-Template für Revenue Cycle Management
- Empfohlene Datenattribute für eine umfassende Analyse
- Wichtige Prozessaktivitäten für eine wirksame Nachverfolgung
- Praktische Hinweise zur Datenextraktion aus Waystar
Attribute des Umsatzzyklusmanagements
| Name | Beschreibung | ||
|---|---|---|---|
| Abrechnungsereignis BillingEvent | Die eindeutige Kennung für die Erbringung einer einzelnen Leistung oder Lieferung eines Produkts, die eine Belastung erzeugt und als Case für den Umsatzzyklus dient. | ||
| Beschreibung Das Billing Event dient als primäre Case-Kennung und verknüpft alle Aktivitäten von der Erfassung der Belastung bis zum Abschluss des Kontos für eine bestimmte abrechenbare Leistung. Es bildet den gesamten Lebenszyklus eines einzelnen Claims oder einer Patientenrechnung ab. Im Process Mining ermöglicht die Analyse des Verlaufs jedes Billing Events einen umfassenden Blick auf den Umsatzzyklus. Sie hilft, typische Prozesspfade, Abweichungen und Bottlenecks zu erkennen, die einzelne Claims beeinflussen. Diese Detailtiefe ist entscheidend, um die Prozessleistung zu verstehen und konkrete Verbesserungsbereiche zu bestimmen, etwa Verzögerungen bei der Einreichung von Claims oder der Verbuchung von Zahlungen. Warum das wichtig ist Dies ist die zentrale Case ID, die alle zugehörigen Aktivitäten des Umsatzzyklus verbindet und die durchgängige Nachverfolgung des Prozesses für jede abrechenbare Position ermöglicht. Bezugsquelle Dies ist üblicherweise der Primärschlüssel aus der zentralen Tabelle für Abrechnungs- oder Claim-Transaktionen in Waystar. Den konkreten Tabellen- und Feldnamen entnehmen Sie bitte der Waystar-Dokumentation. Beispiele BE-2024-0012345BE-2024-0012346BE-2024-0012347 | |||
| Aktivitätsname ActivityName | Der Name des konkreten Geschäftsereignisses oder Prozessschritts, der im Umsatzzyklus stattgefunden hat, etwa „Claim Submitted“ oder „Payment Posted“. | ||
| Beschreibung Dieses Attribut beschreibt die einzelnen Aktivitäten, aus denen der durchgängige Umsatzzyklus besteht. Jeder Wert steht für einen bestimmten Schritt, Meilenstein oder Task eines Abrechnungsereignisses, etwa das Erstellen eines Claims, den Eingang einer Ablehnung oder das Verbuchen einer Zahlung. Die Analyse der Reihenfolge und Häufigkeit dieser Aktivitäten bildet die Grundlage des Process Mining. Sie ermöglicht die Visualisierung der Prozesslandkarte, die Erkennung von Nachbearbeitungsschleifen, etwa „Claim Denied“ gefolgt von „Claim Corrected“, sowie die Messung der Übergangszeiten zwischen den Schritten. Das ist entscheidend, um Prozesseffizienz und Compliance zu verstehen. Warum das wichtig ist Dieses Attribut definiert die Schritte in der Prozesslandkarte und ist damit grundlegend für die Visualisierung und Analyse des Workflows im Umsatzzyklus. Bezugsquelle Erzeugt aus Event Logs, Statusänderungsdatensätzen oder Transaktionstypen in den Claim- und Abrechnungsmodulen von Waystar. Beispiele Anspruch beim Kostenträger eingereichtClaim abgelehntZahlung verbuchtKonto geschlossen | |||
| Zeitstempel des Ereignisses EventTimestamp | Das genaue Datum und die genaue Uhrzeit, zu denen die Aktivität stattgefunden hat. | ||
| Beschreibung Der Event Timestamp erfasst den exakten Zeitpunkt, zu dem eine Aktivität stattgefunden hat. Dieser Timestamp ist entscheidend, um Ereignisse chronologisch zu ordnen und Zeitspannen zwischen verschiedenen Prozessschritten zu berechnen. In der Prozessanalyse dienen Timestamps zur Berechnung wichtiger Leistungskennzahlen wie Durchlauf-, Warte- und Bearbeitungszeiten. Beispielsweise bestimmt die Differenz zwischen dem Timestamp von „Claim Submitted“ und dem von „Payment Posted“ die gesamte Zahlungszykluszeit. Genaue Timestamps sind für die Bottleneck-Analyse und die Leistungsüberwachung unerlässlich. Warum das wichtig ist Timestamps sind erforderlich, um Ereignisse zu ordnen, Durchlaufzeiten zu berechnen und die Prozessleistung zu analysieren. Sie bilden das zeitliche Fundament der Analyse. Bezugsquelle Dies ist ein Standardfeld, das mit nahezu jedem Transaktions- oder Statusänderungsdatensatz in Waystar verknüpft ist und häufig „Creation Date“, „Transaction Date“ oder ähnlich heißt. Beispiele 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, der angibt, wann die Daten für dieses Ereignis zuletzt aktualisiert oder extrahiert wurden. | ||
| Beschreibung Dieses Attribut enthält einen Timestamp für den Zeitpunkt, zu dem die Daten zuletzt aus dem Quellsystem extrahiert wurden. Es handelt sich nicht um den Zeitpunkt des Geschäftsereignisses, sondern um den Zeitpunkt, zu dem der Datensatz für die Analyse abgerufen wurde. Diese Information ist für Data Governance und das Verständnis der Aktualität der Daten in der Process-Mining-Analyse entscheidend. Sie zeigt, ob aktuelle Informationen vorliegen, und ist für die Verwaltung inkrementeller Datenladungen unerlässlich. Warum das wichtig ist Sorgt für Transparenz über die Aktualität des Datensatzes. Das ist für eine genaue und zeitnahe Berichterstattung und Analyse von großer Bedeutung. Bezugsquelle Dieser Timestamp wird üblicherweise während der Datenaufnahme vom ETL-Prozess (Extract, Transform, Load) erzeugt und jeder Zeile hinzugefügt. Beispiele 2024-01-15T02:00:00Z2024-01-16T02:00:00Z | |||
| Quellsystem SourceSystem | Das System oder die Anwendung, aus der die Ereignisdaten stammen. | ||
| Beschreibung Dieses Attribut identifiziert das Quellsystem, das die Ereignisdaten erzeugt hat. In einer komplexen IT-Landschaft können Ereignisse des Umsatzzyklus aus verschiedenen Waystar-Modulen oder sogar aus integrierten externen Systemen wie einem Electronic Health Record (EHR) stammen. Das Verständnis des Quellsystems ist wichtig für die Datenvalidierung, die Fehlerbehebung und die Analyse von Prozessvarianten, die durch unterschiedliche Systemverhalten entstehen können. Es hilft, Prozessprobleme der richtigen Anwendung oder Schnittstelle zuzuordnen. Warum das wichtig ist Identifiziert die Herkunft der Daten. Das ist entscheidend für Data Governance, Qualitätssicherung und das Verständnis von Prozessvarianten in unterschiedlichen Systemen. Bezugsquelle Dies ist häufig ein statischer Wert („Waystar“), der während der Datenextraktion ergänzt wird, oder lässt sich aus bestimmten Modulen oder Tabellen des Systems ableiten. Beispiele Waystar RCMWaystar-AbrechnungsmodulEHR-Schnittstelle | |||
| Abgerechneter Betrag BilledAmount | Der Gesamtbetrag, der für die auf dem Claim erbrachten Leistungen berechnet wird. | ||
| Beschreibung Der Billed Amount entspricht dem Bruttobetrag der für den Patienten erbrachten Leistungen, bevor Anpassungen, vertragliche Nachlässe oder Zahlungen berücksichtigt werden. Er ist der ursprüngliche Wert des beim Kostenträger eingereichten Claims. Dieses Attribut ist für die Finanzanalyse und das Verständnis des durch den Prozess fließenden Geldwerts entscheidend. Es kann verwendet werden, um Analysen nach Claim-Wert zu segmentieren, Trends bei den Beträgen verschiedener Leistungen zu erkennen und die finanziellen Auswirkungen von Prozessineffizienzen wie Ablehnungen oder Zahlungsverzögerungen zu berechnen. Für die meisten Finanz-Dashboards ist es eine grundlegende Kennzahl. Warum das wichtig ist Stellt den Gesamtwert eines Claims dar und ermöglicht die Analyse der finanziellen Auswirkungen von Prozessverzögerungen, Ablehnungen und Anpassungen. Bezugsquelle Ein Standardfeld für Finanzdaten auf dem Claim- oder Erfassungsbildschirm für Belastungen in Waystar. Beispiele 150.001250.75540.50 | |||
| Claim-Status ClaimStatus | Der aktuelle Status des Claims in seinem Lebenszyklus, etwa „Submitted“, „Pending“, „Paid“ oder „Denied“. | ||
| Beschreibung Der Claim Status zeigt zu jedem Zeitpunkt, an welcher Stelle sich ein bestimmtes Abrechnungsereignis im Umsatzzyklus befindet. Er gibt den zuletzt erreichten Meilenstein an, etwa ob ein Claim gesendet wurde, vom Kostenträger geprüft wird, bezahlt oder zurückgewiesen wurde. Dieses Attribut ist für Finanzberichte und das operative Management entscheidend. Im Process Mining hilft es, den aktuellen Zustand aller offenen Cases zu verstehen und zu analysieren, wie lange Cases in bestimmten Status verbleiben, etwa in „Pending Payer Adjudication“. Es unterstützt direkt das Dashboard „Offene Salden und Altersstruktur“. Warum das wichtig ist Bietet eine aktuelle Sicht auf alle laufenden Claims und ermöglicht die Analyse von Bottlenecks sowie die Priorisierung der Arbeit. Bezugsquelle Ein Standardfeld im Claim- oder Abrechnungsdatensatz in Waystar, das aktualisiert wird, während der Claim den Zyklus durchläuft. Beispiele ÜbermitteltVom Kostenträger bestätigtAbgelehntVollständig bezahlt | |||
| Code für den Ablehnungsgrund DenialReasonCode | Ein standardisierter Code, der angibt, warum ein Claim vom Kostenträger abgelehnt wurde. | ||
| Beschreibung Wenn ein Kostenträger einen Claim ablehnt, übermittelt er einen Begründungscode für die Zurückweisung. Diese Codes können auf fehlende Informationen, nicht abgedeckte Leistungen oder Codierungsfehler hinweisen. Dieses Attribut erfasst den jeweiligen Code. Die Analyse der Codes für Ablehnungsgründe ist grundlegend für die Verbesserung des Umsatzzyklus. Sie ermöglicht es der Organisation, die Ursachen von Ablehnungen zu erkennen, etwa häufige Fehler einer bestimmten Abteilung oder Probleme mit den Anforderungen eines bestimmten Kostenträgers. Diese Daten bilden die Grundlage für das Dashboard „Claim-Ablehnungsquote und -gründe“ und sind entscheidend, um Strategien zur Vermeidung künftiger Ablehnungen und zur Verbesserung der Erstzahlungsquote zu entwickeln. Warum das wichtig ist Dieses Attribut ist für die Ursachenanalyse von Claim-Ablehnungen unerlässlich. Es ermöglicht gezielte Maßnahmen, um Umsatzverluste und Nachbearbeitung zu reduzieren. Bezugsquelle Wird im Claim-Datensatz erfasst, wenn ein Ablehnungsereignis eintritt. Diese Information wird vom Kostenträger in der Zahlungsmitteilung übermittelt. Beispiele CO-16: Der Anspruch beziehungsweise die Leistung enthält nicht die erforderlichen Informationen.PR-96: Nicht erstattungsfähige Position(en)CO-22: Diese Versorgung kann von einem anderen Kostenträger übernommen werden. | |||
| Leistungsart ServiceType | Die Kategorie oder Art der erbrachten medizinischen Leistung, etwa „Radiology“, „Consultation“ oder „Surgical Procedure“. | ||
| Beschreibung Service Type klassifiziert die Art der für den Patienten erbrachten abrechenbaren Leistung. Verschiedene Leistungsarten haben häufig unterschiedliche Abrechnungscodes, Erstattungssätze und Prozesskomplexitäten. Dieses Attribut ermöglicht eine detaillierte Analyse des Umsatzzyklus nach klinischer Abteilung oder Leistungsbereich. Es hilft bei Fragen wie: „Bei welchen Leistungsbereichen kommt es zu den meisten Verzögerungen in der Abrechnung?“ oder „Sind die Ablehnungsquoten bei chirurgischen Eingriffen höher als bei Beratungen?“ Das ist entscheidend für die Leistungsanalyse von Abteilungen und gezielte Prozessverbesserungen. Warum das wichtig ist Ermöglicht die Analyse der Prozessleistung nach klinischer Abteilung oder Leistungsbereich und macht Unterschiede bei Effizienz und Rentabilität sichtbar. Bezugsquelle Üblicherweise aus Verfahrenscodes (CPT/HCPCS) abgeleitet oder mit der Abteilung verknüpft, die die Leistung in Waystar erbracht hat. Beispiele RadiologieKardiologische BeratungNotaufnahmebesuchAmbulante Operation | |||
| Name des Kostenträgers PayerName | Der Name des Versicherungsunternehmens oder externen Kostenträgers, der für den Claim verantwortlich ist. | ||
| Beschreibung Dieses Attribut identifiziert den konkreten Kostenträger, etwa ein Versicherungsunternehmen, ein staatliches Programm wie Medicare oder eine andere Stelle, die für die Prüfung und Bezahlung des Claims verantwortlich ist. Jeder Kostenträger kann eigene Anforderungen an die Einreichung, Zahlungsfristen und Ablehnungsmuster haben. Die Analyse nach dem Namen des Kostenträgers ist entscheidend, um Kostenträger mit den längsten Zahlungszyklen, den höchsten Ablehnungsquoten oder den komplexesten Prozessen zu erkennen. So können Organisationen ihre Strategien anpassen, Nachfassaktionen bei problematischen Kostenträgern priorisieren und bessere Verträge aushandeln. Warum das wichtig ist Die Segmentierung des Prozesses nach Kostenträger ist entscheidend, um kostenträgerspezifische Bottlenecks, Ablehnungsgründe und Zahlungsverzögerungen zu erkennen. Bezugsquelle Zu finden in den Claim- oder Abrechnungsdaten, verknüpft mit den Versicherungsinformationen des Patienten in Waystar. Beispiele AetnaBlue Cross Blue ShieldCignaMedicare Teil B | |||
| Offener Saldo OutstandingBalance | Der verbleibende Betrag, der für das Abrechnungsereignis noch eingezogen werden muss. | ||
| Beschreibung Der Outstanding Balance entspricht dem aktuellen Forderungsbetrag für ein bestimmtes Abrechnungsereignis. Er wird als abgerechneter Betrag abzüglich der bis dahin verbuchten Zahlungen und Anpassungen berechnet. Dies ist eine zentrale Finanzkennzahl für die Steuerung des Cashflows und der Forderungen. Sie ist das wichtigste Attribut für das Dashboard „Offene Salden und Altersstruktur“. Damit kann die Organisation Gesamtforderungen verfolgen, Konten mit hohen Salden erkennen und Einziehungsmaßnahmen priorisieren. Die Entwicklung dieses Werts über die Zeit zeigt die Wirksamkeit des Einziehungsprozesses. Warum das wichtig ist Misst direkt die offenen Forderungen und ist damit entscheidend für Cashflow-Steuerung, die Priorisierung von Einziehungen und die Bewertung der finanziellen Lage. Bezugsquelle Dies ist üblicherweise ein berechnetes Feld in den Reporting-Modulen von Waystar (Billed Amount - Paid Amount - Adjustments). Wenn kein direktes Feld verfügbar ist, muss der Wert möglicherweise während der Datenextraktion berechnet werden. Beispiele 30.00270.25540.50 | |||
| Angepasster Betrag AdjustedAmount | Der gesamte finanzielle Betrag, der für das Abrechnungsereignis angepasst oder abgeschrieben wurde. | ||
| Beschreibung Der Adjusted Amount entspricht der Summe aller finanziellen Anpassungen des Saldos eines Abrechnungsereignisses. Dazu gehören vertragliche Nachlässe aufgrund von Vereinbarungen mit Kostenträgern sowie andere Abschreibungen oder Korrekturen. Dies ist eine wichtige Kennzahl für das Dashboard „Anpassungsquote und Auswirkungen auf Konten“. Die Summierung dieses Betrags nach Begründungscodes oder Kostenträgern zeigt die finanziellen Auswirkungen von Umsatzverlusten. Sie hilft, Verluste zu quantifizieren und eine wirtschaftliche Grundlage für die Beseitigung der Ursachen von Anpassungen zu schaffen. Warum das wichtig ist Quantifiziert den Umsatzbetrag, der durch Abschreibungen und Anpassungen verloren geht, und macht die finanziellen Auswirkungen von Abrechnungsproblemen und Vertragsbedingungen sichtbar. Bezugsquelle Stammt aus finanziellen Anpassungstransaktionen in Waystar. Für ein einzelnes Abrechnungsereignis kann die Summierung mehrerer Anpassungseinträge erforderlich sein. Beispiele 250.2550.0015.80 | |||
| Bezahlter Betrag PaidAmount | Der Gesamtbetrag, der von Kostenträgern oder dem Patienten für den Claim empfangen und verbucht wurde. | ||
| Beschreibung Dieses Attribut erfasst den kumulierten Betrag, der für ein Abrechnungsereignis erfolgreich eingezogen wurde. Dazu gehören Zahlungen primärer und sekundärer Kostenträger sowie Zahlungen des Patienten. Paid Amount ist eine zentrale Ergebniskennzahl des Umsatzzyklus. Sie dient dazu, den endgültigen Ertrag aus den abgerechneten Beträgen zu berechnen und die Wirksamkeit des gesamten Prozesses zu messen. Der Vergleich von Billed Amount und Paid Amount zeigt die finanzielle Leistung und macht Bereiche mit Umsatzverlusten sichtbar. Das Attribut ist für Dashboards zur Wirksamkeit der Einziehung und zur allgemeinen finanziellen Lage unerlässlich. Warum das wichtig ist Misst die tatsächlich eingezogenen Zahlungseingänge und ist damit eine zentrale Ergebniskennzahl für die Bewertung des Erfolgs des gesamten Umsatzzyklus. Bezugsquelle Abgeleitet aus Zahlungstransaktionen, die in Waystar mit dem Claim verknüpft sind. Dafür kann die Summierung mehrerer Zahlungsdatensätze erforderlich sein. Beispiele 120.00980.500.00 | |||
| Code für den Anpassungsgrund AdjustmentReasonCode | Ein Code, der den Grund für eine finanzielle Anpassung des Kontosaldos erklärt. | ||
| Beschreibung Wenn sich der Kontosaldo aus einem anderen Grund als einer Zahlung ändert, etwa aufgrund eines vertraglichen Nachlasses oder einer Abschreibung, dokumentiert ein Adjustment Reason Code den Grund. Dieses Attribut erfasst diesen Code. Die Analyse dieser Codes ist für das Dashboard „Anpassungsquote und Auswirkungen auf Konten“ entscheidend. Sie hilft, die Ursachen von Umsatzverlusten zu erkennen, etwa häufige vertragliche Anpassungen bei bestimmten Kostenträgern oder Abschreibungen aufgrund von Abrechnungsfehlern. Das Verständnis dieser Gründe ist der erste Schritt, um vermeidbare Umsatzverluste zu reduzieren. Warum das wichtig ist Erklärt, warum Umsätze angepasst oder abgeschrieben wurden, und liefert wichtige Erkenntnisse zu Umsatzverlusten und zur Leistung von Verträgen mit Kostenträgern. Bezugsquelle Mit Anpassungstransaktionen im Modul für Zahlungsverarbeitung oder Forderungen von Waystar verknüpft. Beispiele Vertragliche VerpflichtungAbschreibung eines KleinbetragsKorrektur von Abrechnungsfehlern | |||
| Kostenträgertyp PayerType | Die Kategorie des Kostenträgers, etwa „Commercial“, „Medicare“ oder „Self-Pay“. | ||
| Beschreibung Payer Type fasst einzelne Kostenträger anhand ihrer Art in übergeordneten Kategorien zusammen. Dadurch entsteht eine höher aggregierte Sicht als beim konkreten Payer Name. Dieses Attribut eignet sich für strategische Analysen und Berichte. Es ermöglicht der Führungsebene, Leistungstrends über wichtige Kostenträgerkategorien hinweg zu verstehen, etwa durch den Vergleich staatlicher Kostenträger mit privaten Versicherern. Die Ergebnisse können strategische Entscheidungen zu Verträgen mit Kostenträgern und zur Ressourcenverteilung unterstützen. Warum das wichtig ist Ermöglicht eine übergeordnete Analyse, indem Kostenträger in Kategorien wie Commercial oder Government gruppiert werden, die häufig ein unterschiedliches Zahlungsverhalten und eigene Regeln haben. Bezugsquelle Üblicherweise durch Zuordnung des Payer Name zu einer vordefinierten Kategorienliste abgeleitet. Diese Logik kann in Waystar vorhanden sein oder muss während der Datentransformation erstellt werden. Beispiele GewerblichMedicareMedicaidSelbstzahler | |||
| Patienten-ID PatientId | Die eindeutige Kennung des Patienten, der die Leistung erhalten hat. | ||
| Beschreibung Dieses Attribut ist die eindeutige Kennung des Patienten, der mit dem Abrechnungsereignis verbunden ist. Es verknüpft die Finanztransaktion mit der Person, die die Behandlung erhalten hat. Während das Billing Event den Case bildet, ermöglicht die Patient ID eine patientenzentrierte Analyse. Damit lassen sich wiederkehrende Patienten erkennen, der durchgängige finanzielle Verlauf eines Patienten über mehrere Besuche hinweg verstehen und Zusammenhänge zwischen bestimmten Patientendemografien, Zahlungsproblemen oder höheren Ablehnungsquoten analysieren. So können alle Abrechnungsaktivitäten einer Person zusammengeführt werden. Warum das wichtig ist Ermöglicht eine patientenzentrierte Analyse und zeigt den gesamten finanziellen Verlauf einer Person über mehrere Abrechnungsereignisse hinweg. Bezugsquelle Ein Standardfeld im Claim- oder Patientenregistrierungsdatensatz in Waystar oder ein aus einem EHR verknüpftes Feld. Beispiele MRN-887654MRN-902101MRN-123456 | |||
| Patientenklasse PatientClass | Gibt den Status des Patienten für den Behandlungskontakt an, etwa „Inpatient“ oder „Outpatient“. | ||
| Beschreibung Patient Class kategorisiert die Art des Patientenkontakts, die häufig Abrechnungsregeln und Erstattungssätze bestimmt. Übliche Klassen sind Inpatient, Outpatient und Emergency. Die Analyse des Umsatzzyklus nach Patient Class kann deutliche Prozessunterschiede sichtbar machen. Claims für stationäre Behandlungen sind beispielsweise häufig komplexer und haben längere Zahlungszyklen als Claims für ambulante Behandlungen. Diese Segmentierung ist wichtig, um realistische Leistungsziele festzulegen und Prozessverbesserungen auf die Anforderungen der jeweiligen Klasse auszurichten. Warum das wichtig ist Hilft, den Prozess nach der Komplexität des Behandlungskontakts zu segmentieren, etwa stationär gegenüber ambulant. Diese Komplexität steht häufig mit unterschiedlichen Abrechnungsregeln und Durchlaufzeiten in Zusammenhang. Bezugsquelle Ein Standardfeld in den Patientenregistrierungs- oder Behandlungsdaten in Waystar oder im Quell-EHR. Beispiele StationärAmbulantNotfall | |||
| Verantwortlicher Benutzer ResponsibleUser | Der Benutzer oder Sachbearbeiter, der die Aktivität ausgeführt hat, etwa ein Mitarbeiter der Abrechnung, ein Codierer oder ein Spezialist für Einziehungen. | ||
| Beschreibung Dieses Attribut identifiziert den konkreten Mitarbeiter oder Systembenutzer, der eine bestimmte Aktivität im Prozess ausgeführt hat. Es kann beispielsweise zeigen, welcher Mitarbeiter der Abrechnung einen Claim eingereicht oder welcher Sachbearbeiter einen Folgeanruf eingeleitet hat. Die Analyse nach Benutzer hilft, die Arbeitsverteilung, die individuelle Leistung und den Schulungsbedarf zu verstehen. Sie kann zeigen, ob bestimmte Benutzer höhere Fehlerquoten aufweisen oder Ablehnungen effizienter bearbeiten. Das ist für Teammanagement und Qualitätskontrolle in der Abteilung für den Umsatzzyklus wertvoll. Warum das wichtig ist Ordnet Prozessschritten Verantwortlichkeiten zu, ermöglicht die Leistungsanalyse auf Einzel- oder Teamebene und zeigt Schulungsmöglichkeiten auf. Bezugsquelle Zu finden im Audit Trail oder in den Transaktionsprotokollen für Ereignisse in Waystar, häufig unter „UserID“, „ProcessedBy“ oder einer ähnlichen Bezeichnung. Beispiele jsmithadavisbilling_bot_01 | |||
| Zahlung im ersten Durchlauf IsFirstPassPayment | Ein Kennzeichen, das angibt, ob der Claim bei der ersten Einreichung ohne Ablehnungen oder Anpassungen korrekt bezahlt wurde. | ||
| Beschreibung Dieses berechnete boolesche Attribut gibt an, ob ein Claim ohne zwischenzeitliche negative Ereignisse wie eine Ablehnung, Zurückweisung oder Anforderung zusätzlicher Informationen bezahlt wurde. Der Wert „true“ steht für einen reibungslosen und effizienten Prozess für diesen Claim. Dieses Attribut unterstützt direkt die KPI „Erstzahlungsquote“, eine zentrale Kennzahl für die Effizienz des gesamten Umsatzzyklus. Die Analyse der Merkmale von Claims, die nicht im ersten Durchlauf bezahlt werden, etwa nach Kostenträger oder Leistungsart, hilft, die wichtigsten Ursachen für Nachbearbeitung und Zahlungsverzögerungen zu erkennen. Eine Verbesserung dieser Quote führt zu schnellerem Cashflow und geringeren Betriebskosten. Warum das wichtig ist Misst direkt die Qualität der Abrechnung und Claim-Verarbeitung. Eine hohe Erstzahlungsquote weist auf einen effizienten Prozess mit wenig Nachbearbeitung hin. Bezugsquelle Dies ist ein abgeleitetes Attribut, das während der Datentransformation berechnet wird. Die Logik prüft, ob ein Ereignis „Payment Posted“ auftritt, ohne dass ihm Ereignisse wie „Claim Denied“ oder „Account Adjusted“ vorausgehen. Beispiele truefalse | |||
| Zahlungsfälligkeitsdatum PaymentDueDate | Das Datum, bis zu dem die Zahlung für die Rechnung oder den Claim erwartet wird. | ||
| Beschreibung Das Payment Due Date ist das vom Leistungserbringer festgelegte oder durch Verträge mit Kostenträgern vorgegebene Datum, bis zu dem die Zahlung eingegangen sein sollte. Es dient als Referenz für die Messung der Zahlungspünktlichkeit. Dieses Attribut ist für das Dashboard „Offene Salden und Altersstruktur“ unerlässlich. Es wird verwendet, um das Alter von Forderungen zu berechnen und sie in Zeiträume wie „0–30 Tage“, „31–60 Tage“ und weitere Kategorien einzuordnen. Diese Altersstrukturanalyse ist eine gängige Finanzpraxis zur Verwaltung von Forderungen und zur Priorisierung von Einziehungen bei überfälligen Konten. Warum das wichtig ist Liefert die Grundlage für die Berechnung der Altersstruktur von Forderungen. Das ist entscheidend für das Forderungsmanagement und das Verständnis der Pünktlichkeit von Zahlungseingängen. Bezugsquelle Zu finden im Rechnungs- oder Claim-Datensatz. Der Wert kann anhand des Rechnungsdatums und der Zahlungsbedingungen berechnet werden. Beispiele 2023-11-252023-12-152024-01-30 | |||
| Zeit von Service bis Rechnung ServiceToInvoiceCycleTime | Die verstrichene Zeit zwischen dem Abschluss eines Service und der Erfassung der Gebühren sowie der Erstellung eines Claims. | ||
| Beschreibung Diese Kennzahl, auch als „Charge Lag“ bezeichnet, misst die Effizienz des vorgelagerten Abrechnungsprozesses. Sie wird als Zeitdifferenz zwischen dem Ereignis „Service Provided/Completed“ und dem Ereignis „Charges Captured“ oder „Claim Created“ berechnet. Dieses Attribut unterstützt direkt das Dashboard „Service To Invoice Cycle Time“. Verzögerungen in diesem Prozessabschnitt, dem sogenannten Charge Lag, verschieben den Beginn des Zahlungszyklus und verzögern dadurch den Cashflow. Die Überwachung hilft sicherzustellen, dass alle Services zeitnah und korrekt abgerechnet werden. So vermeiden Sie Umsatzverluste und beschleunigen den gesamten Revenue Cycle. Warum das wichtig ist Misst die Effizienz der vorgelagerten Abrechnung. Die Reduzierung dieses „Charge Lag“ ist entscheidend, um den gesamten Revenue Cycle zu beschleunigen und nicht erfasste Gebühren zu vermeiden. Bezugsquelle Wird während der Datentransformation berechnet, indem der Timestamp des Service-Ereignisses vom Timestamp des Ereignisses zur Gebührenerfassung oder Claim-Erstellung abgezogen wird. Beispiele 2 Tage 8 Stunden1 Tag 0 Stunden5 Tage 1 Stunde | |||
Aktivitäten des Umsatzzyklusmanagements
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Anspruch beim Kostenträger eingereicht | Die elektronische Übermittlung des Abrechnungsanspruchs an den Versicherungskostenträger zur Prüfung. Dies ist eine wichtige Übergabe vom System des Leistungserbringers an das System des Kostenträgers über das Clearinghouse. | ||
| Warum das wichtig ist Ein wichtiger Meilenstein, ab dem die Reaktionszeit des Kostenträgers gemessen wird. Er ist entscheidend für die Ermittlung von KPIs zum Zahlungszyklus und für das Erkennen von Rückständen bei der Einreichung. Bezugsquelle Die Clearinghouse-Funktion von Waystar protokolliert Datum und Uhrzeit der Übermittlung der Anspruchsdatei ausdrücklich. Suchen Sie nach Übermittlungsprotokollen oder der Statushistorie des Anspruchs. Erfassen Wird nach erfolgreicher Übermittlung in der Historie der Anspruchseinreichung oder im Transaktionsprotokoll gespeichert. Ereignistyp explicit | |||
| Anspruch geprüft | Der Kostenträger hat den Claim verarbeitet und eine Zahlungsentscheidung getroffen. Dieses Ereignis wird erfasst, wenn ein Electronic Remittance Advice (ERA) oder eine 835-Datei vom Kostenträger eingeht. | ||
| Warum das wichtig ist Dies ist der zentrale Entscheidungspunkt im Prozess. Er bestimmt, ob der Claim bezahlt oder abgelehnt wird, und wirkt sich direkt auf den Umsatzfluss sowie die Workflows für das Ablehnungsmanagement aus. Bezugsquelle Abgeleitet aus dem Eingangsdatum des ERA (835-Datei), das in Waystar mit dem Claim verknüpft ist. Die ERA-Datei enthält die detaillierte Entscheidung des Kostenträgers. Erfassen Abgeleitet aus dem Verarbeitungsdatum der vom Kostenträger empfangenen ERA- bzw. 835-Datei. Ereignistyp inferred | |||
| Claim abgelehnt | Der Kostenträger hat den Claim abgelehnt und wird keine Zahlung leisten, wie im Electronic Remittance Advice (ERA) angegeben. Dieses Ereignis löst die Schleife für das Ablehnungsmanagement oder die Nachbearbeitung aus. | ||
| Warum das wichtig ist Unterstützt direkt die KPI „Claim-Ablehnungsquote“. Die Häufigkeit und Gründe von Ablehnungen zu erkennen, ist entscheidend für Prozessverbesserungen und die Rückgewinnung von Umsätzen. Bezugsquelle Dies wird aus spezifischen Ablehnungscodes innerhalb des empfangenen ERA (835-Datei) abgeleitet. Diese Codes werden als Claim Adjustment Reason Codes (CARCs) bezeichnet. Erfassen Abgeleitet aus Claim Adjustment Reason Codes (CARCs) in der ERA-Datei, die eine Ablehnung anzeigen. Ereignistyp inferred | |||
| Erfasste Gebühren | Kennzeichnet die Erfassung abrechenbarer Leistungen im Revenue-Cycle-System. Dieses Ereignis wird in der Regel ausdrücklich protokolliert, wenn ein Benutzer eine Gebühr abschließt, oder wenn Daten aus einem klinischen System eingehen. | ||
| Warum das wichtig ist Dies ist der Ausgangspunkt des Abrechnungsprozesses. Die Analyse der Zeit von der abgeschlossenen Leistung bis zur Erfassung der Gebühr ist entscheidend, um Umsatzverluste und Verzögerungen am Prozessanfang zu erkennen. Bezugsquelle Dieses Ereignis wird in Waystar in einer Tabelle für Gebührenerfassungen oder Transaktionen gespeichert. In der Regel enthält der Datensatz einen Erstellungs-Timestamp, der beim Speichern oder Abschließen der Gebühr angelegt wird. Erfassen Ereignis, das beim Speichern oder Abschließen einer Gebühr protokolliert wird. Ereignistyp explicit | |||
| Konto geschlossen | Der Lebenszyklus des Abrechnungsereignisses ist abgeschlossen. Der Kontosaldo hat durch Zahlungen und Anpassungen null erreicht. Dies kennzeichnet das erfolgreiche Ende des Umsatzzyklus für diesen Case. | ||
| Warum das wichtig ist Dies ist der zentrale Endpunkt des Prozesses. Die Zeit bis zum Abschluss und der Anteil erfolgreich geschlossener Konten sind wichtige übergreifende Leistungskennzahlen. Bezugsquelle Dies ist ein berechnetes Ereignis, das üblicherweise abgeleitet wird, wenn das Feld für den offenen Saldo des Abrechnungsereignisses im Patientenbuchhaltungssystem null erreicht. Erfassen Berechnet, wenn die Summe aus Zahlungen und Anpassungen dem Gesamtbetrag der Belastung entspricht. Ereignistyp calculated | |||
| Zahlung verbucht | Eine eingegangene Zahlung wird dem jeweiligen Patientenkonto und Claim zugeordnet oder mit diesen abgeglichen. Dadurch wird der Saldo von den Forderungen in den Zahlungseingang überführt. | ||
| Warum das wichtig ist Dies ist ein entscheidender letzter Schritt im Zyklus mit dem Kostenträger. Er unterstützt KPIs zum Durchsatz und zur Verzögerungszeit bei der Zahlungsverarbeitung und stellt sicher, dass Konten zeitnah und korrekt aktualisiert werden. Bezugsquelle Dies ist eine explizite Aktion, die in Waystar protokolliert wird, wenn ein Benutzer die Zahlung aus dem ERA verbucht. Viele Systeme verfügen außerdem über Funktionen zur automatischen Verbuchung, die dieses Ereignis ebenfalls protokollieren. Erfassen Ereignis, das protokolliert wird, wenn eine Zahlung aus einem ERA einem Claim zugeordnet wird, manuell oder über die automatische Verbuchung. Ereignistyp explicit | |||
| Ablehnung angefochten | Ein Benutzer hat Maßnahmen ergriffen, um eine Claim-Ablehnung anzufechten. Dazu kann gehören, den Claim korrigiert erneut einzureichen oder einen formellen Einspruch einzulegen. Diese Aktivität ist ein wichtiger Schritt im Nachbearbeitungsprozess. | ||
| Warum das wichtig ist Misst die Effizienz des Teams für das Ablehnungsmanagement. Die Zeit von der Ablehnung bis zum Einspruch sowie die Erfolgsquote von Einsprüchen zu verfolgen, ist wichtig, um Maßnahmen zur Rückgewinnung von Umsätzen zu optimieren. Bezugsquelle Dies kann als explizite Benutzeraktion oder Notiz im Modul für das Ablehnungsmanagement protokolliert werden. Alternativ lässt es sich aus einer Statusänderung des abgelehnten Claims ableiten. Erfassen Ereignis, das protokolliert wird, wenn ein Benutzer einen Einspruch dokumentiert oder den Claim-Status auf „Appealed“ aktualisiert. Ereignistyp explicit | |||
| Anspruch erstellt | Bezeichnet die Erstellung eines formellen Abrechnungsanspruchs aus den erfassten Gebühren. Dies ist ein interner Schritt, bei dem das System die Informationen vor der Einreichung zusammenstellt. | ||
| Warum das wichtig ist Misst die interne Effizienz bei der Erstellung von Ansprüchen. Verzögerungen in dieser Phase können den gesamten Zahlungszyklus aufschieben, noch bevor der Anspruch das System des Leistungserbringers verlässt. Bezugsquelle Dieses Ereignis kann ausdrücklich protokolliert werden, wird jedoch häufig aus dem ersten Timestamp abgeleitet, der einem Anspruchsdatensatz im Waystar-Modul für das Anspruchsmanagement zugeordnet ist. Erfassen Abgeleitet aus dem Erstellungsdatum des Anspruchsdatensatzes in der primären Anspruchstabelle. Ereignistyp inferred | |||
| Bestätigung des Kostenträgers eingegangen | Das System des Kostenträgers bestätigt den Eingang der übermittelten Anspruchsdatei. In der Regel handelt es sich um eine automatische Antwort, etwa einen 277CA- oder 999-Bericht, die anzeigt, dass der Anspruch zur Verarbeitung angenommen wurde. | ||
| Warum das wichtig ist Bestätigt die erfolgreiche Übermittlung und hilft, Ablehnungen am Prozessanfang aufgrund von Formatierungs- oder Datenfehlern vor Beginn der Prüfung zu isolieren. Dadurch lassen sich Korrekturen schneller umsetzen. Bezugsquelle Wird nach der Verarbeitung einer eingehenden Bestätigungsdatei des Kostenträgers in den Tabellen zum Anspruchsstatus oder zu Antwortdateien im Clearinghouse-Modul von Waystar gespeichert. Erfassen Ereignis, das bei der Verarbeitung einer elektronischen Bestätigungsdatei des Kostenträgers protokolliert wird. Ereignistyp explicit | |||
| Claim korrigiert und erneut eingereicht | Nach einer Ablehnung oder Zurückweisung wurde der Claim korrigiert und erneut an den Kostenträger gesendet. Dies kennzeichnet den Neustart des Prüfzyklus für einen bestimmten Claim. | ||
| Warum das wichtig ist Dies ist eine wichtige Nachbearbeitungsschleife. Die Analyse der Häufigkeit und Gründe für erneute Einreichungen hilft, die Ursachen ursprünglicher Fehler zu erkennen, etwa Fehler bei der Codierung oder bei Patientendaten. Bezugsquelle Abgeleitet aus einem neuen Ereignis „Claim Submitted To Payer“ für einen Claim, der zuvor abgelehnt wurde. Das System kann außerdem einen eigenen Status für erneut eingereichte Claims führen. Erfassen Abgeleitet aus einem neuen Einreichungsereignis, das mit der Kennung eines zuvor abgelehnten Claims verknüpft ist. Ereignistyp inferred | |||
| Einziehung gestartet | Das Patientenkonto ist überfällig geworden, und aktive Maßnahmen zur Einziehung haben begonnen. Dazu können automatische Zahlungserinnerungen oder die Übergabe an ein externes Inkassounternehmen gehören. | ||
| Warum das wichtig ist Unterstützt das Dashboard „Wirksamkeit der Einziehungsmaßnahmen“. Es hilft, Kosten und Erfolgsquote der Einziehungsmaßnahmen für überfällige Forderungen zu analysieren. Bezugsquelle Dies wird üblicherweise aus einer Änderung des Kontostatus in Waystar auf „Collections“ oder „Bad Debt“ abgeleitet. Dadurch wird ein anderer Workflow ausgelöst. Erfassen Abgeleitet aus einer Änderung des Kontostatus auf „Collections“ oder „Bad Debt“. Ereignistyp inferred | |||
| Konto angepasst | Der Kontosaldo wird manuell oder aufgrund vertraglicher Vorgaben angepasst. Dazu können Abschreibungen, vertragliche Nachlässe, Patientenrabatte oder andere Korrekturen gehören. | ||
| Warum das wichtig ist Entscheidend für das Verständnis von Umsatzverlusten. Die Analyse von Anpassungen hilft, Probleme bei Gebührenordnungen, im Vertragsmanagement oder bei uneinbringlichen Forderungen zu erkennen. Bezugsquelle Jede finanzielle Anpassung muss zu Prüfzwecken als Transaktion protokolliert werden. Sie erscheint als explizites Ereignis in der Transaktionstabelle des Kontos. Erfassen Als spezifischer Transaktionstyp im Kontenbuch protokolliert. Ereignistyp explicit | |||
| Patientenabrechnung versendet | Nach der Prüfung durch den Versicherer wird eine Abrechnung für einen verbleibenden Saldo erstellt und an den Patienten gesendet. Damit verlagert sich der Schwerpunkt der Einziehung vom Kostenträger auf den Patienten. | ||
| Warum das wichtig ist Dieses Ereignis startet den Zahlungszyklus des Patienten. Die Wirksamkeit und der Zeitpunkt des Versands von Abrechnungen zu analysieren, ist entscheidend für die Verwaltung offener Patientenforderungen und die Verbesserung der Customer Experience. Bezugsquelle Dies ist ein explizites Ereignis, das vom Modul für die Patientenabrechnung protokolliert wird, wenn ein Abrechnungslauf erstellt oder elektronisch beziehungsweise an einen Druckdienstleister gesendet wird. Erfassen Ereignis, das in der Korrespondenzhistorie des Patienten protokolliert wird, wenn eine Abrechnung erstellt wird. Ereignistyp explicit | |||
Anleitungen zur Datenextraktion
Die Extraktionsmethoden für diesen Prozess werden derzeit geprüft. Bitte schauen Sie später wieder vorbei oder kontaktieren Sie uns für Unterstützung.
Bereit für den nächsten Schritt?
Gehen Sie den nächsten Schritt zur Optimierung Ihres Revenue Cycle Management. Nutzen Sie diese Datenerkenntnisse ab heute, um die Effizienz zu steigern und den Cashflow zu verbessern.
Optimieren Sie Ihr Revenue Cycle Management und steigern Sie jetzt den Cashflow
Ermitteln Sie Ineffizienzen, verkürzen Sie die Durchlaufzeiten um 30 % und steigern Sie den Cashflow.
Keine Kreditkarte erforderlich. Beginnen Sie noch heute mit der Optimierung.