Ihr Daten-Template für Revenue Cycle Management
Ihr Daten-Template für Revenue Cycle Management
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten zur Nachverfolgung
- Hinweise zum Datenexport
Attribute für Revenue Cycle Management
| Name | Beschreibung | ||
|---|---|---|---|
| Abrechnungsereignis BillingEvent | Die eindeutige Kennung für die Erbringung einer einzelnen Leistung oder Lieferung eines Produkts, für die eine Gebühr anfällt. Sie dient als primäre Case-ID. | ||
| Beschreibung Das Abrechnungsereignis dient als primäre Case-ID und verknüpft alle Aktivitäten zu einer einzelnen erbrachten Leistung oder gelieferten Produkteinheit, für die eine Gebühr anfällt. So lässt sich der gesamte Prozess der Erlöserfassung und des Forderungseinzugs für jede einzelne abrechenbare Position oder Leistung nachverfolgen. Wenn Organisationen den Prozess anhand des Abrechnungsereignisses analysieren, sehen sie in Process Mining den vollständigen Ablauf von der Leistungserbringung bis zum Zahlungseingang oder Kontenabschluss. Diese Sicht ist entscheidend, um Engpässe zu erkennen, Durchlaufzeiten zu messen und Unterschiede bei der Bearbeitung von Ansprüchen oder Rechnungen zu verstehen. Warum das wichtig ist Dies ist die zentrale Case-ID, die alle zugehörigen Aktivitäten im Abrechnungszyklus verknüpft und eine vollständige Prozessanalyse von Anfang bis Ende ermöglicht. Woher beziehen Dieser Primärschlüssel verknüpft Datensätze in den zentralen Abrechnungs- und Anspruchstabellen von Optum360. Die genauen Tabellen- und Feldnamen finden Sie in der Optum360-Dokumentation. Beispiele BE-2023-0012345BE-2023-0012346BE-2023-0012347 | |||
| Aktivitätsname ActivityName | Der Name eines bestimmten Ereignisses oder einer Aufgabe im Revenue-Cycle-Management-Prozess. | ||
| Beschreibung Der Aktivitätsname bezeichnet einen Schritt im Abrechnungszyklus, zum Beispiel „Anspruch beim Kostenträger eingereicht“ oder „Zahlung eingegangen“. Dieses Attribut ist eine Grundlage für Process Mining, denn es definiert die Knoten in der Prozessübersicht. Durch die Analyse der Reihenfolge und Häufigkeit von Aktivitäten können Organisationen den tatsächlichen Prozessablauf visualisieren, Abweichungen von der Standardvorgehensweise erkennen und häufige Nachbearbeitungsschleifen aufdecken. So lassen sich Ineffizienzen und Compliance-Probleme im Prozess besser verstehen. Warum das wichtig ist Dieses Attribut definiert die einzelnen Prozessschritte. Es bildet die Grundlage der Prozessübersicht und ermöglicht alle Analysen des Prozessflusses. Woher beziehen Dieses Attribut wird üblicherweise aus Event Logs, Datensätzen zu Statusänderungen oder bestimmten Transaktionscodes in den operativen Tabellen von Optum360 abgeleitet. Beispiele Anspruch erstelltAnspruch beim Kostenträger eingereichtZahlung eingegangenAblehnung eingegangenKonto geschlossen | |||
| Ereigniszeit EventTime | Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat. | ||
| Beschreibung Die Ereigniszeit ist der Timestamp jeder Aktivität und gibt Datum und Uhrzeit ihres Auftretens genau an. Diese Zeitangabe ist erforderlich, um die Ereignisse für jeden Case chronologisch anzuordnen. In der Analyse dient die Ereigniszeit dazu, Durchlaufzeiten zwischen Aktivitäten und die Dauer eines Cases zu berechnen. Außerdem lassen sich damit Engpässe erkennen, an denen viel Zeit durch Warten verloren geht. Sie bildet die Grundlage für zeitbasierte Prozessanalysen und Leistungsmessungen. Warum das wichtig ist Dieser Timestamp ist entscheidend, um Ereignisse korrekt anzuordnen und alle zeitbasierten Kennzahlen wie Durchlaufzeiten und Engpässe zu berechnen. Woher beziehen Diese Information wird üblicherweise zusammen mit jedem Transaktionsdatensatz oder Datensatz zu einer Statusänderung in den Datenbanktabellen von Optum360 gespeichert. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z | |||
| Abgerechneter Betrag BilledAmount | Der Gesamtbetrag aller Gebühren, die mit dem Anspruch oder der Rechnung eingereicht wurden. | ||
| Beschreibung Der abgerechnete Betrag entspricht den Bruttokosten der erbrachten Leistungen vor Zahlungen, Anpassungen oder Abschreibungen. Er ist der ursprüngliche Wert der Forderung aus dem Abrechnungsvorgang. Dieses Attribut ist eine wichtige Grundlage für die Finanzanalyse mit Process Mining. Es dient zur Berechnung zentraler Kennzahlen wie der Umsatzanpassungsquote. Außerdem können Sie Fälle nach ihrem Wert segmentieren und prüfen, ob Ansprüche mit hohen Beträgen anders bearbeitet werden oder häufiger Verzögerungen aufweisen als Ansprüche mit niedrigen Beträgen. Warum das wichtig ist Liefert den finanziellen Kontext für jeden Case und ermöglicht wertbasierte Auswertungen sowie die Berechnung wichtiger Finanzkennzahlen. Woher beziehen Dieses Standardfeld ist in Optum360 in jedem Anspruchs- oder Patientenkonto in den Finanztabellen enthalten. Beispiele 150.001250.7585.50 | |||
| Ablehnungsgrundcode DenialReasonCode | Ein standardisierter Code des Kostenträgers, der den Grund für die Ablehnung eines Anspruchs angibt. | ||
| Beschreibung Lehnt ein Kostenträger einen Anspruch ab, gibt er einen Ablehnungsgrundcode an, der das Problem beschreibt, etwa „Leistung nicht abgedeckt“ oder „Doppelter Anspruch“. Diese Codes sind wichtig, um die Ursachen für Umsatzverzögerungen und Nacharbeit zu verstehen. Die Analyse der Codes hilft dem Team für das Management abgelehnter Ansprüche, Aufgaben zu priorisieren, Trends zu erkennen und Korrekturmaßnahmen einzuleiten. Häufen sich beispielsweise Ablehnungen wegen „Fehlender Angaben“, kann das auf ein Problem bei der Erstellung der Ansprüche hinweisen. Diese Analyse ist entscheidend, um die Ablehnungsquote zu senken und den Cashflow zu beschleunigen. Warum das wichtig ist Zeigt die Ursache für abgelehnte Ansprüche. So können Sie gezielte Maßnahmen ergreifen, um weitere Ablehnungen zu verhindern und kostspielige Nacharbeit zu verringern. Woher beziehen Dieser Code ist in den von Kostenträgern erhaltenen Dateien mit elektronischen Zahlungsmitteilungen (ERA) enthalten und wird im Anspruchsmanagement-Modul von Optum360 gespeichert. Beispiele CO-16: Angaben zum Anspruch/zur Leistung fehlenPR-97: Die Leistung ist in der Zahlung/Vergütung für eine andere Leistung/einen anderen Eingriff enthaltenOA-18: Doppelter Anspruch/doppelte Leistung | |||
| Abrechnungsabteilung BillingDepartment | Die interne Abteilung oder das Team, das die Abrechnung bearbeitet oder durchgeführt hat. | ||
| Beschreibung Das Attribut Abrechnungsabteilung bezeichnet das Team oder den Funktionsbereich im Revenue Cycle Management, der für eine Aktivität zuständig ist. So können verschiedene Teams beispielsweise die Kodierung, die Einreichung von Ansprüchen oder das Management abgelehnter Ansprüche übernehmen. Dieses Attribut ist für Leistungsvergleiche wichtig, wie sie im Dashboard „Leistungsvergleich der Abrechnungsabteilungen“ vorgesehen sind. Die Leitung kann damit Effizienz, Geschwindigkeit und Genauigkeit der Teams vergleichen, bewährte Vorgehensweisen ermitteln und Ressourcen gezielt einsetzen, um Leistungsunterschiede auszugleichen. Warum das wichtig ist Ermöglicht den Leistungsvergleich zwischen Abrechnungsteams. So lassen sich besonders leistungsstarke Teams und Bereiche mit Verbesserungsbedarf erkennen. Woher beziehen Diese Information kann sich aus dem Benutzer ergeben, der die Aufgabe ausgeführt hat, oder aus einem Feld des Kontos, das die Zuständigkeit angibt. Weitere Informationen finden Sie in der Optum360-Dokumentation. Beispiele Zentrale AbrechnungsstelleTeam für das Management abgelehnter AnsprücheKodierungsabteilungFinanzdienstleistungen für Patienten | |||
| Angepasster Betrag AdjustedAmount | Der Geldwert von Abschreibungen, vertraglichen Anpassungen oder Korrekturen des abgerechneten Betrags. | ||
| Beschreibung Der angepasste Betrag bezeichnet den Teil des abgerechneten Betrags, der aufgrund von Vereinbarungen mit Kostenträgern, Abrechnungskorrekturen oder anderen Abschreibungen voraussichtlich nicht eingezogen wird. Dadurch sinkt der Umsatz unmittelbar. Dieses Attribut ist entscheidend für das Dashboard „Auswirkungen von Umsatzanpassungen“ und die Kennzahl „Umsatzanpassungsquote“. Die Analyse der Anpassungen zeigt, welche finanziellen Auswirkungen Verträge mit Kostenträgern haben. Außerdem lassen sich Möglichkeiten finden, Umsatzverluste durch genauere Abrechnungen oder Vertragsverhandlungen zu verringern. Warum das wichtig ist Misst unmittelbar Umsatzverluste und ist wichtig für die Berechnung von Finanzkennzahlen sowie für die Beurteilung der Rentabilität. Woher beziehen Diese Information finden Sie in den Anpassungstransaktionen des Finanzsystems von Optum360. Beispiele 30.00250.2510.00 | |||
| Kostenträger-ID PayerId | Die eindeutige Kennung der Versicherung oder des Kostenträgers, der für den Anspruch zuständig ist. | ||
| Beschreibung Die Kostenträger-ID bezeichnet die jeweilige Versicherung, ein staatliches Programm wie Medicare oder Medicaid oder eine andere Stelle, die für die Zahlung des Anspruchs zuständig ist. Jeder Kostenträger hat häufig eigene Regeln, Einreichungsanforderungen und Zahlungsabläufe. Für das Revenue Cycle Management (RCM) ist es entscheidend, den Prozess nach Kostenträger-ID auszuwerten. So lässt sich feststellen, bei welchen Kostenträgern die Zahlungszyklen am längsten sind, die meisten Ansprüche abgelehnt werden oder Einsprüche besonders aufwendig sind. Diese Erkenntnisse helfen den Abrechnungsteams, ihre Vorgehensweise auf die jeweiligen Kostenträger abzustimmen, Zahlungen schneller einzuziehen und den Verwaltungsaufwand zu senken. Warum das wichtig ist Eine Segmentierung nach Kostenträgern ist wichtig, um festzustellen, welche Kostenträger Verzögerungen oder Ablehnungen verursachen. So können Sie die Verwaltung der Kostenträger gezielt verbessern. Woher beziehen Diese Information ist in Optum360 in jedem Anspruchsdatensatz gespeichert. Angaben zu Tabellen- und Feldnamen für Kostenträger finden Sie in der Optum360-Dokumentation. Beispiele PAYER-AETNAPAYER-BCBS-MAPAYER-MEDICAREPAYER-UHC | |||
| Patienten-ID PatientId | Die eindeutige Kennung des Patienten, der die Leistungen erhalten hat. | ||
| Beschreibung Die Patienten-ID ist eine eindeutige Kennung, die jedem Patienten im Gesundheitssystem zugewiesen wird. Sie verknüpft mehrere Abrechnungsereignisse mit einem Patienten und ermöglicht so patientenbezogene Analysen. Mithilfe der Patienten-ID können Analysefachkräfte Muster bei einzelnen Patienten untersuchen, etwa häufige Wiederaufnahmen oder wiederholte Ablehnungen von Ansprüchen. Außerdem lassen sich Prozesse nach Patientendemografie oder Vorgeschichte segmentieren. So können wichtige Erkenntnisse zur Verbesserung der finanziellen Customer Experience von Patienten gewonnen werden. Warum das wichtig ist Ermöglicht patientenbezogene Analysen, mit denen sich der gesamte finanzielle Ablauf nachvollziehen und Muster bei bestimmten Patientengruppen erkennen lassen. Woher beziehen Diese Kennung ist ein zentrales Feld in den Stammdaten der Patienten und den Transaktionstabellen von Optum360. Einzelheiten finden Sie in der Optum360-Dokumentation. Beispiele PAT-98765PAT-98766PAT-98767 | |||
| Benutzer User | Die Kennung des Benutzers oder Systemagenten, der die Aktivität ausgeführt hat. | ||
| Beschreibung Das Attribut Benutzer bezeichnet die Person, das Team oder den automatisierten Bot, der eine Aktivität ausgeführt hat. So können Sie die Leistung einzelner Personen oder Gruppen analysieren. Zu wissen, welcher Benutzer oder welches Team eine Aktion ausgeführt hat, hilft bei der Beurteilung von Produktivität, Qualität und Einhaltung standardisierter Vorgehensweisen. Dadurch lassen sich Schulungsbedarf erkennen und besonders leistungsstarke Personen oder Teams würdigen. Außerdem können Sie unterscheiden, ob Aufgaben manuell oder automatisiert ausgeführt wurden. Warum das wichtig ist Ordnet Prozessschritte den zuständigen Personen zu und ermöglicht die Leistungsanalyse nach Person oder Team. Das ist wichtig für die Ressourcenplanung und Schulung. Woher beziehen Benutzer-IDs werden in Optum360 üblicherweise in den Audit-Protokollen oder im Transaktionsverlauf der Datensätze erfasst. Beispiele j.doem.smithAutoBillerBots.jones | |||
| Case-Dauer CaseDuration | Die gesamte Zykluszeit eines Abrechnungsvorgangs, von der ersten bis zur letzten Aktivität. | ||
| Beschreibung Die Case-Dauer misst die gesamte Zeit vom ersten bis zum letzten Ereignis eines einzelnen Abrechnungsvorgangs. Sie ist eine wichtige übergeordnete Kennzahl für die Effizienz des Gesamtprozesses. Diese Kennzahl unterstützt direkt das Dashboard „Überblick über die durchgängige RCM-Zykluszeit“ und die Kennzahl „Durchschnittliche RCM-Zykluszeit“. Wenn die Leitung die Entwicklung im Zeitverlauf verfolgt, kann sie erkennen, wie sich Verbesserungsmaßnahmen auf den gesamten Abrechnungszyklus auswirken. Warum das wichtig ist Gibt die durchgängige Zykluszeit des Prozesses an. Diese wichtige Kennzahl misst die Geschwindigkeit und Effizienz des Gesamtprozesses. Woher beziehen Wird berechnet, indem für jede eindeutige Case-ID „BillingEvent“ der Timestamp des ersten Ereignisses vom Timestamp des letzten Ereignisses abgezogen wird. Beispiele 30 Tage95 Tage45 Tage | |||
| Endzeit EndTime | Der Timestamp, der angibt, wann eine Aktivität abgeschlossen wurde. | ||
| Beschreibung Die Endzeit markiert den Abschluss einer Aktivität. Während die Startzeit angibt, wann ein Ereignis begonnen hat, wird die Endzeit benötigt, um die Dauer von Aktivitäten mit einer klar abgegrenzten Bearbeitungszeit zu berechnen, etwa von „Nachbearbeitung einer Ablehnung begonnen“ bis zu deren Abschluss. Beim Prozessvergleich anhand von Start- und Endzeit lässt sich die Bearbeitungszeit berechnen. So können Sie aktive Arbeitszeit von Leerlauf- und Wartezeit zwischen Aktivitäten unterscheiden und die Prozesseffizienz genauer beurteilen. Warum das wichtig ist Ermöglicht die genaue Berechnung der Bearbeitungszeit einzelner Aktivitäten. So lässt sich aktive Arbeitszeit von Leerlauf- und Wartezeit im Prozess unterscheiden. Woher beziehen Für manche Aktivitäten gibt es im Quellsystem ein eigenes Timestamp-Feld. Bei anderen muss die Endzeit möglicherweise aus der Startzeit der nachfolgenden Aktivität abgeleitet werden. Beispiele 2023-10-26T10:15:00Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z | |||
| Gezahlter Betrag PaidAmount | Der Gesamtbetrag, den der Kostenträger und der Patient für die abgerechneten Leistungen gezahlt haben. | ||
| Beschreibung Der gezahlte Betrag ist die Summe aller Zahlungen, die für einen bestimmten Abrechnungsvorgang auf dem Konto verbucht wurden. Er entspricht den tatsächlich eingegangenen Zahlungen und ist eine zentrale Kennzahl für den Erfolg des Revenue Cycle Managements. Bei der Prozessanalyse ist es wichtig, den gezahlten Betrag zu verfolgen, um den Cashflow und die finanzielle Gesamtleistung zu verstehen. Damit können Sie die Zahlungsgeschwindigkeit analysieren und abgerechnete mit eingegangenen Beträgen vergleichen. So werden Unterzahlungen und uneinbringliche Forderungen sichtbar. Warum das wichtig ist Gibt die tatsächlich eingegangenen Zahlungen an. Diese zentrale Ergebniskennzahl des RCM-Prozesses ist wichtig für die Cashflow-Analyse. Woher beziehen Dieser Wert ist in Optum360 üblicherweise in Zahlungstransaktionstabellen oder als Zusammenfassung auf Kontoebene gespeichert. Beispiele 120.001000.500.00 | |||
| Ist Nacharbeit IsRework | Kennzeichnet, ob eine Aktivität Teil einer Nacharbeitsschleife ist, etwa beim Management abgelehnter Ansprüche oder bei Einsprüchen. | ||
| Beschreibung „Ist Nacharbeit“ ist ein boolesches Kennzeichen für Aktivitäten, die als nicht wertschöpfende Nacharbeit gelten, etwa „Nachbearbeitung einer Ablehnung gestartet“ oder „Einspruch eingereicht“. Solche Aktivitäten treten häufig auf, wenn der Prozess vom idealen „Happy Path“ abweicht. Mit diesem Attribut lässt sich der Umfang der Nacharbeit im Prozess beziffern. Das ist ein direkter Hinweis auf Ineffizienz und Kosten. Es dient zur Berechnung der Kennzahl „Nacharbeitsquote bei Abrechnungsfehlern“ und unterstützt das Dashboard „Engpässe und Nacharbeitsschleifen erkennen“, indem sich ineffiziente Schleifen einfach filtern und visualisieren lassen. Warum das wichtig ist Hilft, Ineffizienzen im Prozess zu beziffern, indem Aktivitäten mit Nacharbeit gekennzeichnet werden. So lässt sich Verschwendung leichter messen und gezielt verringern. Woher beziehen Dieses Kennzeichen wird üblicherweise mithilfe von Geschäftslogik im Process-Mining-Tool abgeleitet. Beispielsweise kann jede Aktivität nach dem Ereignis „Ablehnung erhalten“ als Nacharbeit gekennzeichnet werden. Beispiele truefalse | |||
| Kontostatus AccountStatus | Der aktuelle Status des Abrechnungskontos im Revenue Cycle Management. | ||
| Beschreibung Der Kontostatus zeigt, an welcher Stelle im Gesamtprozess sich ein Abrechnungsvorgang befindet, zum Beispiel „Ausstehend beim Kostenträger“, „Vollständig bezahlt“ oder „Im Inkasso“. Dieses Attribut liefert den Kontext zu den ausgeführten Aktivitäten. Es eignet sich dazu, Cases zu filtern und zu segmentieren, um bestimmte Prozessbereiche gezielt zu untersuchen. Eine Analyse aller Konten, die sich derzeit „Im Inkasso“ befinden, kann beispielsweise die Ursachen und das Volumen dieses kostenintensiven Prozessbereichs aufzeigen. Das unterstützt das Dashboard „Volumen und Ursachen der Inkassoaktivitäten“. Warum das wichtig ist Liefert einen Überblick über den aktuellen Status eines Case und ermöglicht es, bestimmte Case-Gruppen, etwa Konten im Inkasso, zu filtern und zu analysieren. Woher beziehen In Optum360 ist dies üblicherweise ein zusammenfassendes Feld im Hauptdatensatz des Patientenkontos oder Anspruchs. Beispiele OffenAusstehend beim KostenträgerVollständig bezahltIm InkassoGeschlossen | |||
| Leistungscode ServiceCode | Der Verfahrenscode (z. B. CPT, HCPCS), der die erbrachte Leistung eindeutig bezeichnet. | ||
| Beschreibung Der Leistungscode ist ein standardisierter medizinischer Code, der den beim Patienten durchgeführten Eingriff oder die erbrachte Leistung genau bezeichnet. Diese Codes sind für die Abrechnung erforderlich und bestimmen maßgeblich die Erstattung. Eine Auswertung nach Leistungscode kann zeigen, dass bestimmte Eingriffe häufiger abgelehnt werden, mehr Dokumentation erfordern oder längere Zahlungszyklen haben. Dadurch lassen sich Herausforderungen im Prozess genauer verstehen und Kodierungs- sowie Abrechnungsrichtlinien für bestimmte Leistungsarten gezielt anpassen. Warum das wichtig ist Ermöglicht die Analyse nach Art der medizinischen Leistung. So können Sie Muster bei Ablehnungen oder Zahlungsverzögerungen für bestimmte Eingriffe erkennen. Woher beziehen Dieser Code ist ein grundlegender Bestandteil der Leistungserfassungs- und Anspruchsdetails in Optum360. Beispiele 992137104527447 | |||
| Leistungserbringer ServiceProvider | Der Arzt, die Abteilung oder die Einrichtung, die die abrechenbare Leistung erbracht hat. | ||
| Beschreibung Dieses Attribut bezeichnet den jeweiligen Leistungserbringer, etwa einen Arzt, Therapeuten oder eine Krankenhausabteilung, der die Leistung erbracht hat. Unterschiedliche Leistungserbringer können verschiedene Abrechnungsmuster oder Dokumentationsgewohnheiten haben, die sich auf den Abrechnungszyklus auswirken. Eine Auswertung nach Leistungserbringer kann Probleme bei der Leistungserfassung, der Kodiergenauigkeit oder der Dokumentationsqualität aufzeigen, die am Ort der Behandlung entstehen. Sie kann auch auf Möglichkeiten für Schulungen der Leistungserbringer oder Prozessverbesserungen hinweisen, damit Ansprüche von Anfang an korrekt erstellt werden. Warum das wichtig ist Hilft dabei, Abrechnungsprobleme bis zu ihrer Ursache zurückzuverfolgen. So können Sie klinischen Mitarbeitenden gezielt Rückmeldungen und Schulungen geben und die Leistungserfassung sowie Dokumentation verbessern. Woher beziehen Diese Information ist ein wichtiger Bestandteil des Leistungs- oder Anspruchsdatensatzes in Optum360 und häufig mit den Stammdaten der Leistungserbringer verknüpft. Beispiele Dr. Emily CarterRadiologieabteilungAllgemeinchirurgiePhysiotherapie | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp der letzten Aktualisierung oder Extraktion von Daten aus dem Quellsystem. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit, zu denen die Daten zuletzt aus dem Quellsystem extrahiert und in das Process-Mining-Tool geladen wurden. Es gibt Aufschluss darüber, wie aktuell die analysierten Daten sind. So können Analysefachkräfte und Fachanwender beurteilen, ob sie die neuesten Informationen sehen. Das Attribut hilft, Erwartungen an die Datenverzögerung zu steuern, und ist ein wichtiger Metadatensatz für jedes Analyseprojekt. Warum das wichtig ist Gibt Aufschluss über die Aktualität der Daten, damit Benutzer den zeitlichen Stand der Analyse einschätzen können. Woher beziehen Dieser Timestamp wird üblicherweise vom ETL-Prozess (Extraktion, Transformation und Laden) erzeugt und gespeichert. Beispiele 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Quellsystem SourceSystem | Das System oder die Anwendung, in dem beziehungsweise der die Ereignisdaten ursprünglich erfasst wurden. | ||
| Beschreibung Dieses Attribut gibt an, aus welchem Quellsystem die Daten für ein bestimmtes Ereignis stammen. In einer komplexen IT-Landschaft können RCM-Daten aus der zentralen Optum360-Plattform, einem angebundenen elektronischen Patientenaktensystem (EHR), einer Clearingstelle oder einem Patientenportal kommen. Die Kenntnis des Quellsystems hilft bei der Datenvalidierung und der Fehlersuche bei Integrationen. Außerdem lassen sich Prozessabweichungen untersuchen, die durch unterschiedliches Systemverhalten oder verschiedene Dateneingabepraktiken entstehen können. Warum das wichtig ist Gibt die Herkunft der Daten an. Das ist wichtig für die Data Governance, die Qualitätsbewertung und das Verständnis von Prozessabweichungen zwischen verschiedenen Systemen. Woher beziehen Dabei kann es sich um einen statischen Wert handeln, der bei der Datenextraktion festgelegt wird, oder um ein Feld in den Quelltabellen, das die Herkunft der Daten angibt. Beispiele Optum360EHR-SchnittstelleClearingstellen-APIPatientenportal | |||
Aktivitäten im Revenue Cycle Management
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Ablehnung eingegangen | Der Kostenträger hat einen Anspruch abgelehnt, wie aus einer eingegangenen Zahlungsmitteilung hervorgeht. Dieses Ereignis wird abgeleitet, indem die Daten der Zahlungsmitteilung nach bestimmten Ablehnungsgrundcodes für die Anspruchspositionen durchsucht werden. | ||
| Warum das wichtig ist Die Nachverfolgung von Ablehnungen ist entscheidend, um Ursachen für Erlösausfälle und ineffiziente Prozesse zu erkennen. Diese Aktivität markiert den Beginn aller Bearbeitungs- und Einspruchsschleifen bei Ablehnungen. Woher beziehen Das Ereignis wird aus den Daten der elektronischen Zahlungsmitteilung (EDI 835) abgeleitet. Das System erkennt Claim Adjustment Reason Codes (CARCs), die eine Ablehnung kennzeichnen. Erfassung Das Ereignis wird abgeleitet, indem bestimmte Ablehnungscodes (CARCs/RARCs) in den ausgewerteten EDI-835-Daten der Zahlungsmitteilung erkannt werden. Ereignistyp inferred | |||
| Anspruch beim Kostenträger eingereicht | Der erstellte Anspruch wurde zur Prüfung elektronisch an den Versicherungskostenträger übermittelt. Dieses Ereignis wird nach erfolgreicher Übertragung explizit vom Modul für die Anspruchseinreichung oder von der Clearingstelle protokolliert. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein markiert den Beginn der Wartezeit auf eine Antwort des Kostenträgers. Er hilft dabei, die Effizienz des Einreichungsprozesses zu messen und Verzögerungen bei der Übermittlung zu erkennen. Woher beziehen Der Eintrag findet sich in Transaktionsprotokollen für Ansprüche oder in EDI-Tabellen (Electronic Data Interchange), in denen insbesondere die Übermittlung von 837-Anspruchsdateien erfasst wird. Suchen Sie nach einem Feld wie „Einreichungs-Timestamp“ oder „Übermittlungsdatum“. Erfassung Timestamp aus dem EDI-837-Transaktionsprotokoll, der die erfolgreiche Einreichung angibt. Ereignistyp explicit | |||
| Konto geschlossen | Das Abrechnungsereignis gilt als abgeschlossen, wenn der Saldo null beträgt und keine weiteren Aktivitäten zu erwarten sind. Das Ereignis wird abgeleitet, sobald der Kontostand null erreicht und der Kontostatus auf „Geschlossen“ oder einen vergleichbaren Endstatus gesetzt wird. | ||
| Warum das wichtig ist Dies ist das zentrale End-Event des Prozesses. Die Gesamtdauer bis zu diesem Zeitpunkt zeigt die Effizienz des gesamten RCM-Prozesses. Woher beziehen Abgeleitet aus dem Zusammenspiel eines Kontostands von null und einem Kontostatus wie „Geschlossen“, „Vollständig bezahlt“ oder einem gleichbedeutenden Endstatus. Erfassung Der späteste Timestamp der abschließenden Zahlungsverbuchung, durch die der Saldo null erreicht, oder der Statusänderung zu „Geschlossen“. Ereignistyp inferred | |||
| Leistungsdaten eingegangen | Kennzeichnet den Beginn des Abrechnungsereignisses, sobald klinische Leistungsinformationen aus dem elektronischen Patientenaktensystem (EHR) oder einem anderen Quellsystem eingehen. Dieses Ereignis wird üblicherweise durch einen expliziten Protokolleintrag oder einen Transaktionsdatensatz erfasst, den eine Integrationsschnittstelle nach erfolgreicher Datenübernahme erstellt. | ||
| Warum das wichtig ist Dies ist das zentrale Start-Event des Abrechnungszyklus. Die Zeitspanne von dieser Aktivität bis zur Leistungserfassung ist entscheidend, um Verzögerungen bei der vorgelagerten Datenverarbeitung zu erkennen, die sich auf den gesamten Prozess auswirken. Woher beziehen Der Eintrag findet sich in Schnittstellenprotokollen oder Transaktionstabellen, die eingehende Patientendaten aus externen Systemen wie einem EHR verarbeiten. Suchen Sie nach Timestamps von HL7-Nachrichten oder Protokollen von API-Aufrufen. Erfassung Der Timestamp wird aus Integrationsprotokollen oder Transaktionstabellen übernommen, in denen der Dateneingang erfasst wird. Ereignistyp explicit | |||
| Zahlung verbucht | Eine eingegangene Zahlung wurde erfolgreich dem jeweiligen Patientenkonto und den zugehörigen Leistungspositionen zugeordnet. Dabei handelt es sich um eine explizite Aktion eines Benutzers oder eines automatisierten Systems, durch die die Zahlung mit den offenen Forderungen abgeglichen wird. | ||
| Warum das wichtig ist Diese Aktivität ist entscheidend, um die Effizienz der nachgelagerten Zahlungszuordnung zu messen. Verzögerungen bei der Verbuchung können die Berichterstattung zu Forderungen verfälschen und den Abschluss eines Kontos verzögern. Woher beziehen Der Eintrag findet sich in den Zahlungstransaktionstabellen. Als Ereigniszeit dient der Transaktions-Timestamp der Verbuchung. Erfassung Erstellungs-Timestamp des Zahlungstransaktionsdatensatzes, der einer bestimmten Leistung zugeordnet wurde. Ereignistyp explicit | |||
| Zahlungsmitteilung eingegangen | Das System hat vom Kostenträger eine elektronische Zahlungsmitteilung (ERA-Datei) mit Angaben zu Zahlungen, Korrekturen und Ablehnungen erhalten. Dieses Ereignis wird explizit erfasst, wenn das System eine EDI-835-Datei einliest. | ||
| Warum das wichtig ist Diese Aktivität ist ein wichtiger Meilenstein: Sie zeigt an, dass der Kostenträger den Anspruch bearbeitet hat. Die Angaben in der Datei bestimmen die nächsten Schritte, etwa die Verbuchung der Zahlung oder die Bearbeitung einer Ablehnung. Woher beziehen Der Eintrag findet sich in EDI-Transaktionsprotokollen für eingehende ANSI-835-Dateien. Der Timestamp gibt an, wann das System die Datei empfangen und verarbeitet hat. Erfassung Timestamp der Übernahme der EDI-835-Datei (Electronic Remittance Advice). Ereignistyp explicit | |||
| Anspruch erstellt | Das System hat einen abrechenbaren Anspruch erstellt und alle Leistungen, Codes und demografischen Angaben in einem standardisierten Format zusammengeführt. Dieses explizite Systemereignis hat einen entsprechenden Erstellungs-Timestamp. | ||
| Warum das wichtig ist Diese Aktivität markiert den Übergang von der Leistungserfassung zum formellen Abrechnungsprozess. Sie ist Voraussetzung für die Einreichung und wichtig, um interne Bearbeitungszeiten nachzuverfolgen. Woher beziehen Der Eintrag findet sich in der Anspruchstabelle oder im Transaktionsprotokoll. Der Erstellungs-Timestamp des Anspruchskopfs kennzeichnet das Ereignis. Erfassung Der Timestamp wird anhand des Erstellungs-Timestamps des Hauptdatensatzes in der Anspruchsdatenbank erfasst. Ereignistyp explicit | |||
| Einspruch eingereicht | Ein Einspruch gegen einen abgelehnten Anspruch wurde formell beim Kostenträger eingereicht. Diese Aktion wird von einem Benutzer explizit im Modul für das Ablehnungsmanagement oder Einsprüche protokolliert. | ||
| Warum das wichtig ist Diese Aktivität ist ein wichtiger Schritt zur Rückgewinnung von Erlösen. Die Nachverfolgung von Einsprüchen und ihrer Bearbeitungsdauer ist entscheidend, um die Wirksamkeit der Strategie zur Klärung von Ablehnungen zu beurteilen. Woher beziehen Der Eintrag findet sich in einem Modul zur Nachverfolgung von Einsprüchen oder als eigener Transaktionstyp zum Anspruch. Suchen Sie nach einem Feld wie „Einspruchsdatum“ oder „Datum der erneuten Einreichung“. Erfassung Expliziter Timestamp, der erfasst wird, wenn ein Benutzer die Einreichung eines Einspruchs protokolliert. Ereignistyp explicit | |||
| Forderungseinzug begonnen | Wegen ausbleibender Zahlung wurde das Patientenkonto in den aktiven Forderungseinzug überführt. Dies wird üblicherweise aus einer Änderung der Finanzklasse oder des Kontostatus abgeleitet. | ||
| Warum das wichtig ist So lassen sich Konten erkennen, die eine intensivere Nachverfolgung erfordern. Die Analyse der Häufigkeit und Ursachen dieser Aktivität hilft, die Strategien für den Forderungseinzug im Vorfeld zu verbessern. Woher beziehen Abgeleitet aus einer Statusänderung des Kontos zu „Forderungseinzug“, „Uneinbringliche Forderung“ oder „An Inkassobüro übergeben“. Das Datum der Statusänderung ist der Ereignis-Timestamp. Erfassung Timestamp der Änderung eines Kontostatusfelds zu einem Wert im Zusammenhang mit dem Forderungseinzug. Ereignistyp inferred | |||
| Kodierung abgeschlossen | Medizinische Kodierfachkräfte haben die klinische Dokumentation geprüft und die passenden CPT-, HCPCS- und ICD-Codes zugewiesen. Dieses Ereignis wird üblicherweise explizit erfasst, wenn ein Benutzer oder eine automatisierte Kodierungssoftware die Kodierungsaufgabe abschließt. | ||
| Warum das wichtig ist Die Kodierung ist häufig ein Engpass, der die Einreichung von Ansprüchen verzögert. Wenn Sie diese Aktivität nachverfolgen, können Sie die Produktivität der Kodierfachkräfte messen und Verzögerungen in der Kodierungswarteschlange erkennen. Woher beziehen Der Eintrag findet sich in einem Modul für Kodierungs-Workflows oder wird durch eine Statusänderung des Abrechnungsereignisses von „Kodierung ausstehend“ zu „Kodiert“ erfasst. Verwendet wird der Timestamp der Statusänderung oder des Aufgabenabschlusses. Erfassung Timestamp einer Statusaktualisierung oder eines Protokolleintrags, wenn ein Benutzer oder das System die Kodierung des Behandlungsfalls abschließt. Ereignistyp explicit | |||
| Konto korrigiert | Eine vertragliche Korrektur, Abschreibung oder sonstige finanzielle Berichtigung wurde auf dem Konto verbucht. Dabei handelt es sich um eine explizite Finanztransaktion im Hauptbuch des Systems. | ||
| Warum das wichtig ist Korrekturen wirken sich direkt auf die realisierten Erlöse aus. Die Analyse ihrer Gründe und Zeitpunkte ist entscheidend, um Probleme mit Gebührenordnungen, Verträgen oder der Abrechnungsgenauigkeit zu erkennen. Woher beziehen Der Eintrag findet sich in der Tabelle für Finanztransaktionen und lässt sich anhand bestimmter Transaktionscodes für Abschreibungen oder Korrekturen identifizieren. Als Ereigniszeit gilt das Transaktionsdatum. Erfassung Transaktionsdatum eines Eintrags im Hauptbuch mit einem bestimmten Korrekturcode. Ereignistyp explicit | |||
| Leistungen erfasst | Hier werden abrechenbare Leistungen und Materialien offiziell in das Abrechnungssystem eingetragen. Dabei handelt es sich um eine explizite Aktion eines Benutzers oder des Systems, durch die Transaktionsdatensätze für die Abrechnung entstehen. | ||
| Warum das wichtig ist Diese Aktivität ist wichtig, um die Verzögerung zwischen Leistungserbringung und Abrechnungsbeginn zu messen. Eine kürzere Verzögerung beschleunigt den Abrechnungszyklus direkt. Woher beziehen Die Daten finden sich in Transaktionstabellen für Leistungen, häufig in Tabellen zur Leistungserfassung oder zu Leistungspositionen. Als Ereigniszeit dient der Erstellungs-Timestamp des Abrechnungsdatensatzes. Erfassung Als Ereigniszeit gilt der Erstellungs-Timestamp eines Datensatzes in der Leistungstabelle oder der Tabelle für Abrechnungstransaktionen. Ereignistyp explicit | |||
| Nachbearbeitung einer Ablehnung begonnen | Ein Benutzer oder ein automatisierter Workflow hat mit der Prüfung und Klärung eines abgelehnten Anspruchs begonnen. Das Ereignis kann durch eine Benutzeraktion explizit erfasst oder aus einer Statusänderung des Anspruchs abgeleitet werden. | ||
| Warum das wichtig ist Diese Aktivität startet die Nachbearbeitungsschleife für Ablehnungen. Anhand der Zeit zwischen Eingang der Ablehnung und Beginn der Nachbearbeitung lassen sich Rückstände in der Warteschlange für die Ablehnungsbearbeitung erkennen. Woher beziehen Der Eintrag findet sich in Modulen für das Ablehnungsmanagement oder die Arbeitswarteschlange. Er kann als expliziter Timestamp erfasst werden, wenn ein Benutzer eine Aufgabe zur Ablehnung öffnet oder übernimmt, oder aus einer Statusänderung wie „Abgelehnt“ zu „In Nachbearbeitung“ abgeleitet werden. Erfassung Abgeleitet aus einer Statusänderung des Anspruchs zu „Nachbearbeitung“ oder „In Prüfung“ oder aus einem expliziten Protokoll einer Benutzeraktion. Ereignistyp inferred | |||
| Patientenabrechnung versendet | Eine Abrechnung für den vom Patienten zu tragenden Anteil wurde erstellt und an ihn versendet. Dieses Ereignis wird bei der Erstellung der Abrechnung explizit vom Abrechnungsmodul für Patienten protokolliert. | ||
| Warum das wichtig ist Diese Aktivität startet den Selbstzahleranteil des Abrechnungszyklus. Ihre Nachverfolgung hilft dabei, die Effizienz und Wirksamkeit des Forderungseinzugs bei Patienten zu analysieren. Woher beziehen Der Eintrag findet sich in einer Tabelle zum Patienten-Schriftverkehr oder im Verlauf der Abrechnungserstellung. Der Timestamp gibt an, wann die Abrechnung erstellt oder versendet wurde. Erfassung Timestamp aus dem Protokoll oder Verlauf der Erstellung von Patientenabrechnungen. Ereignistyp explicit | |||
| Zahlung eingegangen | Zeigt an, dass eine Zahlung von einem Kostenträger oder Patienten eingegangen ist. Sie wird häufig als Teil der Zahlungsmitteilung erfasst. Das Ereignis kann explizit aus elektronischen Zahlungsdateien oder manuellen Protokollen für Zahlungseingänge übernommen werden. | ||
| Warum das wichtig ist Diese grundlegende Aktivität ist wichtig für die Analyse des Zahlungsflusses und die Messung der Zahlungsgeschwindigkeit. Sie löst die Verbuchung der Zahlung aus. Woher beziehen Abgeleitet aus den Zahlungsinformationen in der EDI-835-Zahlungsdatei oder aus den Lockbox-Dateien einer Bank. Häufig werden das Scheckdatum oder das Verarbeitungsdatum in der Datei verwendet. Erfassung Übernommen aus dem BPR-Segment einer EDI-835-Datei oder aus der Lockbox-Datendatei einer Bank. Ereignistyp explicit | |||
Anleitungen zum Datenexport
Die Extraktionsmethoden für diesen Prozess werden derzeit geprüft. Schauen Sie später wieder vorbei oder kontaktieren Sie uns wenn Sie Unterstützung benötigen.
Möchten Sie loslegen?
Verwenden Sie dieses Template, um die Datenerfassung zu vereinfachen und mit der Optimierung Ihrer Revenue-Cycle-Management-Prozesse zu beginnen. Gewinnen Sie Erkenntnisse und steigern Sie die Effizienz Ihrer Abläufe.
Optimieren Sie Ihr Revenue Cycle Management und verkürzen Sie Verzögerungen
Schließen Sie sich Unternehmen an, die ihre Zykluszeit um 30 % verkürzt und ihre finanzielle Lage verbessert haben.
Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.