Datatemplate voor Revenue Cycle Management

Optum360
Datatemplate voor Revenue Cycle Management

Datatemplate voor Revenue Cycle Management

Deze template biedt een duidelijk stappenplan voor het verzamelen van de data die nodig is om het Revenue Cycle Management-proces te analyseren. Je ziet welke attributen je verzamelt, welke belangrijke activiteiten je volgt en hoe je deze informatie uit de bron haalt. Met deze template maak je de data klaar voor process mining.
  • Aanbevolen attributen om te verzamelen
  • Belangrijke activiteiten om te volgen
  • Richtlijnen voor data-extractie

Attributen voor Revenue Cycle Management

Dit zijn de aanbevolen datavelden voor het event log, voor een volledige analyse van Revenue Cycle Management.
3 Verplicht 6 Aanbevolen 10 Optioneel
Naam Beschrijving
Activiteit
ActivityName
De naam van een specifieke gebeurtenis of taak binnen het proces voor Revenue Cycle Management.
Beschrijving

De Activiteit beschrijft een stap in de omzetcyclus, zoals ‘Claim ingediend bij betaler’ of ‘Betaling ontvangen’. Dit attribuut vormt de basis van process mining, omdat het de knooppunten in de proceskaart bepaalt.

Door de volgorde en frequentie van activiteiten te analyseren, kunnen organisaties de werkelijke processtroom visualiseren, afwijkingen van de standaardprocedure opsporen en veelvoorkomende herstelprocessen herkennen. Zo wordt duidelijk waar processen inefficiënt zijn en waar complianceproblemen ontstaan.

Waarom dit belangrijk is

Dit attribuut beschrijft de afzonderlijke processtappen. Het vormt de basis van de proceskaart en van alle analyses van processtromen.

Waar vind je dit?

Meestal haal je deze gegevens uit event logs, statuswijzigingen of specifieke transactiecodes in de operationele tabellen van Optum360.

Voorbeelden
Claim aangemaaktClaim ingediend bij betalerBetaling ontvangenAfwijzing ontvangenRekening gesloten
Factureringsactiviteit
BillingEvent
De unieke identificatie van één geleverde dienst of één geleverd product waarvoor kosten in rekening worden gebracht. Dit is het primaire Case-ID.
Beschrijving

De factureringsactiviteit is de primaire identificatie van een case. Ze koppelt alle activiteiten aan één geleverde dienst of één geleverd product waarvoor kosten in rekening worden gebracht. Zo kun je de volledige omzet- en inningscyclus volgen voor elk afzonderlijk factureerbaar product of elke afzonderlijke dienst.

Met process mining op basis van factureringsactiviteiten kunnen organisaties het hele proces bekijken, van de zorgverlening tot de uiteindelijke betaling of het sluiten van de rekening. Zo kun je bottlenecks opsporen, doorlooptijden meten en zien hoe de afhandeling van claims en facturen verschilt.

Waarom dit belangrijk is

Dit is het belangrijkste Case-ID. Het koppelt alle activiteiten in de omzetcyclus en geeft je een volledig beeld van het proces, van begin tot eind.

Waar vind je dit?

Dit is de primaire sleutel die records in de belangrijkste facturerings- en claimtabellen van Optum360 aan elkaar koppelt. Raadpleeg de documentatie van Optum360 voor de exacte tabel- en veldnamen.

Voorbeelden
BE-2023-0012345BE-2023-0012346BE-2023-0012347
Tijdstip van gebeurtenis
EventTime
De timestamp die aangeeft wanneer een specifieke activiteit of gebeurtenis plaatsvond.
Beschrijving

Het tijdstip van de gebeurtenis is de timestamp van elke activiteit. Deze geeft de exacte datum en tijd aan waarop de activiteit plaatsvond. Met deze tijdgegevens kun je de gebeurtenissen per case in chronologische volgorde zetten.

Bij analyses gebruik je het tijdstip van de gebeurtenis om doorlooptijden tussen activiteiten en de totale duur van cases te berekenen. Ook kun je bottlenecks opsporen waar veel tijd verloren gaat met wachten. Deze gegevens vormen de basis voor tijdsgebonden procesanalyses en prestatiemetingen.

Waarom dit belangrijk is

Deze timestamp is nodig om gebeurtenissen in de juiste volgorde te zetten en alle tijdsgebonden metrieken te berekenen, zoals doorlooptijden en bottlenecks.

Waar vind je dit?

Deze informatie staat meestal bij elk transactie- of statuswijzigingsrecord in de databasetabellen van Optum360.

Voorbeelden
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
Betaler-ID
PayerId
De unieke identificatiecode van de verzekeraar of betaler die verantwoordelijk is voor de claim.
Beschrijving

De betaler-ID geeft aan welke verzekeraar, overheidsregeling zoals Medicare of Medicaid, of andere partij verantwoordelijk is voor de betaling van de claim. Elke betaler hanteert vaak eigen regels, indieningsvereisten en betaalgedrag.

Analyse op basis van betaler-ID is essentieel voor RCM. Zo zie je welke betalers de langste betaalcycli en de meeste afwijzingen hebben, of de ingewikkeldste bezwaarprocedures hanteren. Met die informatie kunnen facturatieafdelingen hun aanpak per betaler aanpassen, zodat betalingen sneller binnenkomen en de administratieve last afneemt.

Waarom dit belangrijk is

Door het proces per betaler op te splitsen, zie je welke betalers vertragingen of afwijzingen veroorzaken. Zo kun je het beheer van die betalers gericht verbeteren.

Waar vind je dit?

Deze informatie staat bij elke claim in Optum360. Raadpleeg de documentatie van Optum360 voor de namen van tabellen en velden over betalers.

Voorbeelden
PAYER-AETNAPAYER-BCBS-MAPAYER-MEDICAREPAYER-UHC
Facturatieafdeling
BillingDepartment
De interne afdeling of het team dat de facturatieactiviteit heeft beheerd of uitgevoerd.
Beschrijving

Het attribuut Facturatieafdeling geeft aan welk team of werkgebied binnen de bedrijfsvoering van de inkomstencyclus verantwoordelijk is voor een activiteit. Verschillende teams kunnen bijvoorbeeld de codering, het indienen van claims of het beheer van afwijzingen verzorgen.

Dit attribuut is nodig om prestaties te vergelijken, zoals gevraagd in het dashboard ‘Prestatiebenchmarks van facturatieafdelingen’. Het management kan hiermee de efficiëntie, snelheid en nauwkeurigheid van teams vergelijken, goede werkwijzen herkennen en middelen gericht inzetten om achterstanden aan te pakken.

Waarom dit belangrijk is

Maakt het mogelijk de prestaties van facturatieteams te vergelijken, zodat je goed presterende groepen en verbeterpunten kunt herkennen.

Waar vind je dit?

Dit kan worden afgeleid van de gebruiker die de taak uitvoert, of van een veld op de rekening waarin de verantwoordelijke staat. Raadpleeg de documentatie van Optum360.

Voorbeelden
Centraal facturatiekantoorTeam Beheer van afwijzingenAfdeling CoderingFinanciële patiëntenzorg
Gecorrigeerd bedrag
AdjustedAmount
De geldwaarde van afboekingen, contractuele correcties of aanpassingen van het gefactureerde bedrag.
Beschrijving

Het gecorrigeerde bedrag is het deel van het gefactureerde bedrag dat naar verwachting niet wordt geïnd vanwege contractuele afspraken met betalers, facturatiecorrecties of andere afboekingen. Dit verlaagt de omzet rechtstreeks.

Dit attribuut is belangrijk voor het dashboard ‘Impact van omzetcorrecties’ en de KPI ‘Percentage omzetcorrecties’. Met een analyse van correcties zie je wat contracten met betalers financieel betekenen en waar je omzetverlies kunt beperken, bijvoorbeeld door nauwkeuriger te factureren of contracten opnieuw te onderhandelen.

Waarom dit belangrijk is

Meet rechtstreeks het omzetverlies en is belangrijk voor financiële KPI’s en inzicht in de winstgevendheid.

Waar vind je dit?

Deze informatie staat in de registraties van correctietransacties in het financiële systeem van Optum360.

Voorbeelden
30.00250.2510.00
Gefactureerd bedrag
BilledAmount
De totale geldwaarde van alle kosten die op de claim of factuur zijn ingediend.
Beschrijving

Het gefactureerde bedrag is het brutobedrag voor de geleverde diensten, vóór betalingen, correcties of afboekingen. Dit is de beginwaarde van de openstaande vordering voor de facturatiegebeurtenis.

Dit attribuut is belangrijk voor financiële analyses met process mining. Je gebruikt het bijvoorbeeld om KPI’s zoals het percentage omzetcorrecties te berekenen. Ook kun je cases op bedrag indelen en nagaan of claims met een hoge waarde anders worden verwerkt of meer vertraging oplopen dan claims met een lage waarde.

Waarom dit belangrijk is

Geeft per case de financiële context. Zo kun je analyses op basis van bedragen uitvoeren en belangrijke financiële KPI’s berekenen.

Waar vind je dit?

Dit is een standaardveld bij elke claim of patiëntenrekening in de financiële tabellen van Optum360.

Voorbeelden
150.001250.7585.50
Patiënt-ID
PatientId
De unieke identificatie van de patiënt die de zorg heeft ontvangen.
Beschrijving

Het patiënt-ID is een unieke identificatie die binnen het zorgsysteem aan elke patiënt wordt toegewezen. Hiermee kun je meerdere factureringsactiviteiten aan één patiënt koppelen en analyses vanuit het perspectief van de patiënt uitvoeren.

Met het patiënt-ID kunnen analisten patronen bij specifieke patiënten onderzoeken, zoals herhaalde ziekenhuisopnames of een geschiedenis van afgewezen claims. Je kunt het proces ook indelen op basis van patiëntgegevens of voorgeschiedenis. Dat kan waardevolle inzichten opleveren om de financiële ervaring van patiënten te verbeteren.

Waarom dit belangrijk is

Maakt analyses vanuit het perspectief van de patiënt mogelijk. Zo kun je het volledige financiële traject bekijken en patronen bij specifieke patiëntgroepen herkennen.

Waar vind je dit?

Dit is een kernveld in de patiëntstamgegevens en transactietabellen van Optum360. Raadpleeg de documentatie van Optum360 voor meer informatie.

Voorbeelden
PAT-98765PAT-98766PAT-98767
Redencode afwijzing
DenialReasonCode
Een gestandaardiseerde code van de betaler die uitlegt waarom een claim is afgewezen.
Beschrijving

Wanneer een betaler een claim afwijst, geeft die een redencode op, bijvoorbeeld ‘Dienst niet gedekt’ of ‘Dubbele claim’. Deze codes helpen de oorzaken van omzetvertragingen en herstelwerk te begrijpen.

Met een analyse van de codes kan het team dat afwijzingen beheert prioriteiten stellen, trends herkennen en corrigerende maatregelen nemen. Veel afwijzingen wegens ‘Ontbrekende informatie’ kunnen bijvoorbeeld wijzen op een probleem bij het opstellen van claims. Deze analyse helpt het afwijzingspercentage te verlagen en de kasstroom te versnellen.

Waarom dit belangrijk is

Geeft de oorzaak van afgewezen claims aan, zodat je gericht kunt ingrijpen om nieuwe afwijzingen en kostbaar herstelwerk te voorkomen.

Waar vind je dit?

Deze code staat in de Electronic Remittance Advice (ERA)-bestanden van betalers en wordt opgeslagen in de claimbeheermodule van Optum360.

Voorbeelden
CO-16: Claim/dienst bevat onvoldoende informatiePR-97: De vergoeding voor deze dienst is opgenomen in de betaling/vergoeding voor een andere dienst of procedureOA-18: Dubbele claim/dienst
Betaald bedrag
PaidAmount
Het totale bedrag dat de betaler en de patiënt hebben betaald voor de gefactureerde diensten.
Beschrijving

Het betaalde bedrag is de som van alle betalingen die voor een specifieke facturatiegebeurtenis op de rekening zijn geboekt. Dit is het daadwerkelijk ontvangen geld en een belangrijke maatstaf voor het resultaat van de inkomstencyclus.

In procesanalyses is het betaalde bedrag nodig om de kasstroom en de financiële prestaties te begrijpen. Je kunt de snelheid van betalingen analyseren en gefactureerde bedragen vergelijken met ontvangen bedragen. Zo komen onderbetalingen en oninbare vorderingen aan het licht.

Waarom dit belangrijk is

Geeft het daadwerkelijk ontvangen geld weer. Dit is een belangrijke resultaatmaatstaf voor het RCM-proces en helpt bij de analyse van de kasstroom.

Waar vind je dit?

Deze waarde staat meestal in tabellen met betalingstransacties of is samengevat op rekeningniveau in Optum360.

Voorbeelden
120.001000.500.00
Bronsysteem
SourceSystem
Het systeem of de applicatie waarin de gebeurtenisgegevens oorspronkelijk zijn vastgelegd.
Beschrijving

Dit attribuut geeft aan uit welk bronsysteem de gegevens van een gebeurtenis komen. In een complexe IT-omgeving kan RCM-data afkomstig zijn van het Optum360-platform, een gekoppeld elektronisch patiëntendossier (EHR), een clearinghouse of een patiëntenportaal.

Als je het bronsysteem kent, kun je data controleren, problemen met koppelingen oplossen en procesverschillen analyseren die ontstaan door verschillen tussen systemen of manieren van gegevensinvoer.

Waarom dit belangrijk is

Geeft aan waar de data vandaan komen. Dit is belangrijk voor datagovernance, kwaliteitscontroles en het begrijpen van procesverschillen tussen systemen.

Waar vind je dit?

Dit kan een vaste waarde zijn die tijdens het ophalen van de data wordt ingesteld, of een veld in de brontabellen dat de herkomst van de data aangeeft.

Voorbeelden
Optum360EHR-koppelingClearinghouse-APIPatiëntenportaal
Caseduur
CaseDuration
De totale doorlooptijd van een facturatiegebeurtenis, van de eerste tot de laatste activiteit.
Beschrijving

De caseduur meet de totale tijd tussen de eerste en de laatste gebeurtenis van één facturatiegebeurtenis. Dit is een belangrijke KPI op hoofdlijnen voor de efficiëntie van het hele proces.

Deze metriek ondersteunt rechtstreeks het dashboard ‘Overzicht van de end-to-enddoorlooptijd van RCM’ en de KPI ‘Gemiddelde RCM-doorlooptijd’. Door de caseduur in de tijd te volgen, ziet het management wat verbeterinitiatieven opleveren voor de hele inkomstencyclus.

Waarom dit belangrijk is

Geeft de end-to-enddoorlooptijd van het proces weer. Dit is een belangrijke KPI om de snelheid en efficiëntie van het hele proces te meten.

Waar vind je dit?

Dit wordt berekend door de timestamp van de eerste gebeurtenis af te trekken van de timestamp van de laatste gebeurtenis voor elke unieke case-ID van ‘BillingEvent’.

Voorbeelden
30 dagen95 dagen45 dagen
Eindtijd
EndTime
De timestamp die aangeeft wanneer een activiteit is afgerond.
Beschrijving

De eindtijd geeft aan wanneer een activiteit is afgerond. De starttijd geeft aan wanneer een gebeurtenis plaatsvond. De eindtijd is nodig om de duur te berekenen van activiteiten met een afzonderlijke verwerkingstijd, zoals ‘Herstelwerk na afwijzing gestart’ en de afronding daarvan.

Door de start- en eindtijd van activiteiten te vergelijken, kun je de verwerkingstijd berekenen. Zo maak je onderscheid tussen actieve werktijd en wachttijd tussen activiteiten. Dat geeft een nauwkeuriger beeld van de procesefficiëntie.

Waarom dit belangrijk is

Hiermee kun je de verwerkingstijd van activiteiten nauwkeurig berekenen en actieve werktijd onderscheiden van wachttijd.

Waar vind je dit?

Voor sommige activiteiten is dit een apart timestampveld in het bronsysteem. Voor andere kun je de eindtijd afleiden uit de starttijd van de volgende activiteit.

Voorbeelden
2023-10-26T10:15:00Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
Gebruiker
User
De identificatiecode van de gebruiker of systeemagent die de activiteit heeft uitgevoerd.
Beschrijving

Het attribuut Gebruiker geeft aan welke persoon, welk team of welke geautomatiseerde bot verantwoordelijk was voor een activiteit. Zo kun je prestaties op individueel of groepsniveau analyseren.

Het is nuttig om te weten welke gebruiker of welk team een actie heeft uitgevoerd. Je kunt hiermee productiviteit, kwaliteit en naleving van standaardprocedures beoordelen. Ook zie je waar training nodig is en welke personen of teams goed presteren. Daarnaast kun je onderscheid maken tussen handmatig uitgevoerde taken en taken die door automatisering zijn afgehandeld.

Waarom dit belangrijk is

Maakt duidelijk wie verantwoordelijk is voor processtappen en ondersteunt prestatieanalyses per persoon of team. Dat helpt bij het beheer van middelen en bij het bepalen van trainingsbehoeften.

Waar vind je dit?

Gebruikers-ID’s staan meestal in de auditlogs of transactiegeschiedenis van registraties in Optum360.

Voorbeelden
j.doem.smithAutoBillerBots.jones
Is herstelwerk
IsRework
Een aanduiding die aangeeft of een activiteit deel uitmaakt van een herstelcyclus, zoals het beheer van afwijzingen of bezwaren.
Beschrijving

Is herstelwerk is een booleaanse aanduiding voor activiteiten die gelden als herstelwerk zonder toegevoegde waarde, zoals ‘Herstelwerk na afwijzing gestart’ of ‘Bezwaar ingediend’. Deze activiteiten vinden meestal plaats wanneer het proces afwijkt van de ideale route.

Met dit attribuut kun je de hoeveelheid herstelwerk in het proces meten. Dat is een directe aanwijzing voor inefficiëntie en kosten. Je gebruikt het om de KPI ‘Percentage herstelwerk door facturatiefouten’ te berekenen. Ook ondersteunt het dashboard ‘Bottlenecks en herstelcycli herkennen’, omdat je deze inefficiënte cycli eenvoudig kunt filteren en weergeven.

Waarom dit belangrijk is

Helpt inefficiëntie in het proces te meten door activiteiten met herstelwerk aan te duiden. Zo kun je verspilling makkelijker in kaart brengen en aanpakken.

Waar vind je dit?

Dit wordt meestal afgeleid met bedrijfslogica in de process mining-tool. Zo kan elke activiteit na een gebeurtenis ‘Afwijzing ontvangen’ als herstelwerk worden aangemerkt.

Voorbeelden
truefalse
Laatste data-update
LastDataUpdate
De timestamp van de meest recente data-update of extractie uit het bronsysteem.
Beschrijving

Dit attribuut registreert de datum en tijd waarop de data voor het laatst uit het bronsysteem zijn opgehaald en in de process mining-tool zijn geladen. Zo weet je hoe actueel de geanalyseerde data zijn.

Analisten en zakelijke gebruikers kunnen hiermee controleren of ze de meest recente informatie bekijken. Het geeft ook inzicht in vertragingen bij het aanleveren van data en is belangrijke metadata voor elk analyseproject.

Waarom dit belangrijk is

Geeft aan hoe actueel de data zijn, zodat gebruikers weten hoe recent de analyse is.

Waar vind je dit?

Deze timestamp wordt meestal aangemaakt en opgeslagen door het ETL-proces (extractie, transformatie en laden van data).

Voorbeelden
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Rekeningstatus
AccountStatus
De huidige status van de facturatierekening binnen de inkomstencyclus.
Beschrijving

De rekeningstatus geeft aan waar een facturatiegebeurtenis zich in het proces bevindt, bijvoorbeeld ‘In afwachting van betaler’, ‘Volledig betaald’ of ‘In incasso’. Dit attribuut geeft context aan de uitgevoerde activiteiten.

Je kunt cases hiermee filteren en indelen om specifieke delen van het proces te onderzoeken. Zo helpt een analyse van alle rekeningen die momenteel ‘In incasso’ zijn om de oorzaken en omvang van dit kostbare procesdeel te begrijpen. Dit ondersteunt het dashboard ‘Omvang en oorzaken van incassoactiviteiten’.

Waarom dit belangrijk is

Geeft op hoofdlijnen de huidige status van een case weer. Zo kun je cases filteren en analyseren, bijvoorbeeld rekeningen die in incasso zijn.

Waar vind je dit?

Dit is meestal een samenvattend veld in de hoofdregistratie van de patiëntenrekening of claim in Optum360.

Voorbeelden
OpenIn afwachting van betalerVolledig betaaldIn incassoGesloten
Zorgcode
ServiceCode
De procedurecode (bijvoorbeeld CPT of HCPCS) die de geleverde dienst aangeeft.
Beschrijving

De zorgcode is een gestandaardiseerde medische code die precies aangeeft welke procedure of dienst aan de patiënt is geleverd. Deze codes zijn nodig voor de facturatie en bepalen voor een groot deel de vergoeding.

Met een analyse per zorgcode zie je of bepaalde procedures vaker worden afgewezen, meer documentatie vereisen of langere betaalcycli hebben. Zo krijg je een gedetailleerder beeld van procesproblemen en kun je het coderings- en facturatiebeleid voor specifieke diensten aanpassen.

Waarom dit belangrijk is

Maakt analyse per type medische dienst mogelijk. Zo zie je of bepaalde procedures vaker worden afgewezen of vertraging oplopen bij de betaling.

Waar vind je dit?

Deze code is een vast onderdeel van de kostenregistratie en claimdetails in Optum360.

Voorbeelden
992137104527447
Zorgverlener
ServiceProvider
De zorgverlener, afdeling of instelling die de factureerbare dienst heeft geleverd.
Beschrijving

Dit attribuut geeft aan welke zorgverlener, zoals een arts, therapeut of ziekenhuisafdeling, de dienst heeft geleverd. Verschillende zorgverleners kunnen andere facturatiepatronen of documentatiegewoonten hebben die van invloed zijn op de inkomstencyclus.

Analyse per zorgverlener kan problemen met het registreren van kosten, de nauwkeurigheid van codering of de documentatiekwaliteit aan het licht brengen. Zo zie je waar bijscholing of procesverbetering nodig is, zodat claims vanaf het begin correct worden opgesteld.

Waarom dit belangrijk is

Helpt facturatieproblemen terug te voeren op de bron. Zo kun je zorgmedewerkers gericht feedback en training geven om kostenregistratie en documentatie te verbeteren.

Waar vind je dit?

Deze informatie is een belangrijk onderdeel van de kosten- of claimregistratie in Optum360 en is vaak gekoppeld aan de stamgegevens van zorgverleners.

Voorbeelden
Dr. Emily CarterAfdeling RadiologieAlgemene chirurgieFysiotherapie
Verplicht Aanbevolen Optioneel

Activiteiten voor Revenue Cycle Management

Dit zijn de belangrijkste processtappen en mijlpalen om in het event log vast te leggen, zodat je het proces nauwkeurig kunt ontdekken.
6 Aanbevolen 9 Optioneel
Activiteit Beschrijving
Afwijzing ontvangen
De verzekeraar heeft een claim afgewezen. Dat blijkt uit de ontvangen betalingsspecificatie. Je kunt deze gebeurtenis afleiden door de gegevens in de specificatie te controleren op afwijzingsredencodes voor de claimregels.
Waarom dit belangrijk is

Door afwijzingen te volgen, kun je de oorzaken van omzetverlies en inefficiënte processen opsporen. Deze activiteit is het startpunt voor het beheer van afwijzingen en het herstelwerk bij bezwaarprocedures.

Waar vind je dit?

Leid deze gebeurtenis af uit de gegevens in de Electronic Remittance Advice (EDI 835). Het systeem herkent claim adjustment reason codes (CARCs) die op een afwijzing wijzen.

Vastleggen

Leid deze gebeurtenis af door specifieke afwijzingscodes (CARCs/RARCs) te herkennen in de verwerkte EDI 835-betalingsgegevens.

Gebeurtenistype inferred
Betaling verwerkt
Een ontvangen betaling is succesvol toegewezen aan de rekening van de patiënt en de bijbehorende zorgregels. Een gebruiker of geautomatiseerd proces voert hiervoor een expliciete actie uit en stemt de betaling af op de openstaande kosten.
Waarom dit belangrijk is

Deze activiteit is belangrijk om de efficiëntie van de betalingsverwerking op de backoffice te meten. Vertragingen bij het verwerken kunnen de rapportage van openstaande vorderingen vertekenen en de afsluiting van rekeningen vertragen.

Waar vind je dit?

Je vindt deze gebeurtenis in de transactietabellen voor betalingen. De transactietimestamp van de verwerkingsactie geldt als tijdstip van de gebeurtenis.

Vastleggen

De aanmaaktimestamp van het betalingstransactierecord dat aan een specifieke kostenpost is toegewezen.

Gebeurtenistype explicit
Betalingsspecificatie ontvangen
Het systeem heeft een elektronische betalingsspecificatie (ERA-bestand) van de verzekeraar ontvangen. Daarin staan betalingen, correcties en afwijzingen. De gebeurtenis wordt expliciet vastgelegd wanneer het systeem een EDI 835-bestand inleest.
Waarom dit belangrijk is

Deze activiteit is een belangrijk moment: de verzekeraar heeft de claim verwerkt. De inhoud van het bestand bepaalt wat er daarna gebeurt, zoals het verwerken van de betaling of het beheren van de afwijzing.

Waar vind je dit?

Deze gebeurtenis staat in EDI-transactielogs voor inkomende ANSI 835-bestanden. De timestamp geeft aan wanneer het systeem het bestand heeft ontvangen en verwerkt.

Vastleggen

De timestamp van het inlezen van het EDI 835-bestand (Electronic Remittance Advice).

Gebeurtenistype explicit
Claim ingediend bij betaler
De aangemaakte claim is elektronisch naar de verzekeraar gestuurd voor beoordeling. De module voor claimindiening of de koppeling met het clearinghouse legt deze gebeurtenis expliciet vast zodra de verzending is geslaagd.
Waarom dit belangrijk is

Dit is een belangrijk moment: vanaf hier begint de wachttijd op een reactie van de verzekeraar. Je kunt hiermee de efficiëntie van het claimindieningsproces meten en vertragingen bij het indienen opsporen.

Waar vind je dit?

Je vindt deze gebeurtenis in transactielogs voor claims of in EDI-tabellen (Electronic Data Interchange), met name bij de verzending van 837-claimbestanden. Zoek naar een veld als ‘submission timestamp’ of ‘transmit date’.

Vastleggen

De timestamp uit het EDI 837-transactielog die aangeeft dat de claim succesvol is ingediend.

Gebeurtenistype explicit
Rekening gesloten
De factureringsactiviteit is afgerond: het saldo is nul en er worden geen verdere activiteiten verwacht. Je kunt dit afleiden wanneer het saldo van de rekening nul wordt en de status verandert in ‘Closed’ of een vergelijkbare eindstatus.
Waarom dit belangrijk is

Dit is de belangrijkste eindgebeurtenis van het proces. Door de totale doorlooptijd tot dit moment te meten, krijg je een volledig beeld van de efficiëntie van RCM.

Waar vind je dit?

Leid deze gebeurtenis af uit een combinatie van een nulsaldo en een rekeningstatus als ‘Closed’, ‘Paid in Full’ of een vergelijkbare eindstatus.

Vastleggen

De meest recente timestamp van de laatste betalingsverwerking die het saldo op nul brengt, of van de statuswijziging naar ‘Closed’.

Gebeurtenistype inferred
Zorggegevens ontvangen
Dit markeert het begin van de factureringsactiviteit, wanneer klinische zorggegevens binnenkomen vanuit het elektronisch patiëntendossier (EHR) of een ander bronsysteem. Meestal wordt deze gebeurtenis vastgelegd in een expliciete logregel of transactierecord die een integratiekoppeling aanmaakt zodra de data succesvol zijn ingelezen.
Waarom dit belangrijk is

Dit is de belangrijkste startgebeurtenis van de omzetcyclus. Door de tijd tussen deze activiteit en het vastleggen van de kosten te analyseren, kun je vertragingen in de gegevensverwerking aan het begin van het proces opsporen. Die vertragingen hebben gevolgen voor het hele proces.

Waar vind je dit?

Deze gebeurtenis staat in interfacelogs of transactietabellen voor inkomende patiëntgegevens uit externe systemen, zoals een EHR. Zoek naar timestamps van HL7-berichten of API-aanroepen.

Vastleggen

Haal deze gegevens uit integratielogs of transactietabellen waarin de timestamp wordt vastgelegd zodra de data binnenkomen.

Gebeurtenistype explicit
Betaling ontvangen
Dit geeft aan dat een betaling van een verzekeraar of patiënt is ontvangen. De betaling staat vaak in de betalingsspecificatie. Je kunt deze gebeurtenis expliciet vastleggen op basis van elektronische betalingsbestanden of handmatige kasontvangstregistraties.
Waarom dit belangrijk is

Deze activiteit is nodig om de kasstroom en de snelheid van betalingen te analyseren. Ze vormt ook het startsein voor de verwerking van de betaling.

Waar vind je dit?

Leid deze gebeurtenis af uit de betalingsgegevens in het EDI 835-bestand of uit lockboxbestanden van een bank. Vaak wordt de controledatum of verwerkingsdatum in het bestand gebruikt.

Vastleggen

Haal deze gegevens op uit het BPR-segment van een EDI 835-bestand of uit het lockboxbestand van een bank.

Gebeurtenistype explicit
Bezwaar ingediend
Er is formeel bezwaar ingediend bij de verzekeraar tegen een afgewezen claim. Een gebruiker legt deze actie expliciet vast in de module voor afwijzingsbeheer of bezwaren.
Waarom dit belangrijk is

Deze activiteit is een belangrijke stap in het terughalen van omzet. Door bezwaren en de bijbehorende doorlooptijden te volgen, krijg je zicht op de effectiviteit van de aanpak voor het oplossen van afwijzingen.

Waar vind je dit?

Deze gebeurtenis staat in een module voor bezwaarregistratie of als een specifiek transactietype bij de claim. Zoek naar een veld als ‘appeal date’ of ‘resubmission date’.

Vastleggen

De expliciete timestamp die wordt vastgelegd wanneer een gebruiker de indiening van een bezwaar registreert.

Gebeurtenistype explicit
Claim aangemaakt
Het systeem heeft een factureerbare claim aangemaakt met alle kosten, codes en demografische gegevens in een standaardindeling. Dit is een expliciete systeemgebeurtenis met een bijbehorende aanmaaktimestamp.
Waarom dit belangrijk is

Deze activiteit markeert de overgang van het vastleggen van kosten naar het formele factureringsproces. De claim moet zijn aangemaakt voordat deze kan worden ingediend. De activiteit is ook nodig om de interne verwerkingstijden te meten.

Waar vind je dit?

Je vindt deze gebeurtenis in de claimtabel of het transactielog. De aanmaaktimestamp van de claimkop geeft het tijdstip aan.

Vastleggen

Haal de timestamp op van het hoofdrecord in de claimdatabasetabel.

Gebeurtenistype explicit
Codering afgerond
Medische codeurs hebben de klinische documentatie beoordeeld en de juiste CPT-, HCPCS- en ICD-codes toegewezen. Meestal wordt dit expliciet vastgelegd wanneer een gebruiker of een geautomatiseerde codeermodule de codeertaak afrondt.
Waarom dit belangrijk is

Codering is vaak een bottleneck die de indiening van claims vertraagt. Door deze activiteit te volgen, kun je de productiviteit van codeurs meten en vertragingen in de codeerwachtrij opsporen.

Waar vind je dit?

Deze gebeurtenis staat in een module voor de codeerworkflow of blijkt uit een statuswijziging van ‘Pending Coding’ naar ‘Coded’ bij de factureringsactiviteit. Gebruik de timestamp van de statuswijziging of van de voltooide taak.

Vastleggen

De timestamp van een statusupdate of logregel die wordt vastgelegd wanneer een gebruiker of systeem de codering van het zorgcontact afrondt.

Gebeurtenistype explicit
Factuuroverzicht naar patiënt verzonden
Er is een factuuroverzicht opgesteld en naar de patiënt gestuurd voor diens deel van de rekening. De module voor patiëntfacturering legt deze gebeurtenis expliciet vast wanneer het overzicht wordt aangemaakt.
Waarom dit belangrijk is

Deze activiteit start het deel van de omzetcyclus waarin de patiënt zelf betaalt. Door dit te volgen, kun je de efficiëntie en effectiviteit van de inning bij patiënten analyseren.

Waar vind je dit?

Deze gebeurtenis staat in een tabel met patiëntcorrespondentie of de aanmaakgeschiedenis van factuuroverzichten. De timestamp geeft aan wanneer het overzicht is aangemaakt of verzonden.

Vastleggen

De timestamp uit een log of geschiedenistabel voor het aanmaken van patiëntfactuuroverzichten.

Gebeurtenistype explicit
Herstelwerk na afwijzing gestart
Een gebruiker of geautomatiseerde workflow is begonnen met het beoordelen en oplossen van een afgewezen claim. Dit kan expliciet worden vastgelegd via een gebruikersactie of worden afgeleid uit een statuswijziging van de claim.
Waarom dit belangrijk is

Deze activiteit start het herstelproces na een afwijzing. Door de tijd tussen het ontvangen van de afwijzing en de start van het herstelwerk te meten, kun je achterstanden in de wachtrij voor afwijzingsbeheer opsporen.

Waar vind je dit?

Je vindt deze gebeurtenis in modules voor afwijzingsbeheer of werkvoorraad. Er kan een expliciete timestamp zijn wanneer een gebruiker een afwijzingstaak opent of claimt. Je kunt de gebeurtenis ook afleiden uit een statuswijziging, bijvoorbeeld van ‘Denied’ naar ‘In Rework’.

Vastleggen

Leid deze gebeurtenis af uit een statuswijziging van de claim naar ‘Rework’ of ‘Under Review’, of uit een expliciete logregel van een gebruikersactie.

Gebeurtenistype inferred
Inningsactiviteit gestart
De rekening van de patiënt is wegens uitblijvende betaling overgedragen aan een actief inningstraject. Dit kun je meestal afleiden uit een wijziging van de financiële categorie of status van de rekening.
Waarom dit belangrijk is

Zo herken je rekeningen waarvoor intensievere opvolging nodig is. Door te analyseren hoe vaak deze activiteit voorkomt en waardoor ze wordt veroorzaakt, kun je de inningsaanpak aan het begin van het proces verbeteren.

Waar vind je dit?

Leid deze gebeurtenis af uit een statuswijziging van de rekening naar ‘Collections’, ‘Bad Debt’ of ‘Sent to Agency’. De datum van de statuswijziging is de timestamp van de gebeurtenis.

Vastleggen

De timestamp van een wijziging in het statusveld van de rekening naar een waarde die met inning te maken heeft.

Gebeurtenistype inferred
Kosten vastgelegd
Dit is het moment waarop factureerbare zorg en benodigdheden formeel in het factureringssysteem worden ingevoerd. Een gebruiker of het systeem voert hiervoor een expliciete actie uit, die transactierecords voor de kosten aanmaakt.
Waarom dit belangrijk is

Deze activiteit is nodig om de vertraging tussen de geleverde zorg en de start van de facturering te meten. Als je die vertraging verkleint, verloopt de omzetcyclus sneller.

Waar vind je dit?

Je vindt deze gegevens in transactietabellen voor kosten, vaak met namen als charge entry of service line. De aanmaaktimestamp van het kostenrecord geldt als tijdstip van de gebeurtenis.

Vastleggen

De gebeurtenis is de aanmaaktimestamp van een record in de charge master- of transactietabel voor kosten.

Gebeurtenistype explicit
Rekening gecorrigeerd
Er is een contractuele correctie, afboeking of andere financiële correctie op de rekening verwerkt. Dit is een expliciete financiële transactie in het grootboek van het systeem.
Waarom dit belangrijk is

Correcties hebben rechtstreeks invloed op de gerealiseerde omzet. Door de redenen en timing van correcties te analyseren, kun je problemen met tarieflijsten, contracten of de nauwkeurigheid van facturen opsporen.

Waar vind je dit?

Je vindt deze gebeurtenis in de tabel met financiële transacties. Specifieke transactiecodes voor afboekingen of correcties maken de gebeurtenis herkenbaar. De transactiedatum is het tijdstip van de gebeurtenis.

Vastleggen

De transactiedatum van een boeking in het financiële grootboek met een specifieke correctiecode.

Gebeurtenistype explicit
Aanbevolen Optioneel

Extractiegidsen

Zo haal je data op uit Optum360

De extractiemethoden voor dit proces worden nog gevalideerd. Kom later terug of neem contact met ons op voor hulp.

Klaar om aan de slag te gaan?

Gebruik deze template om data sneller te verzamelen en te beginnen met het verbeteren van processen voor Revenue Cycle Management. Krijg inzicht in het proces en werk gericht aan een efficiëntere bedrijfsvoering.

Verbeter Revenue Cycle Management en beperk vertragingen

Sluit je aan bij organisaties die de doorlooptijd met 30% verkortten en hun financiële positie verbeterden.

Start je gratis proefperiode

Geen creditcard nodig. Binnen enkele minuten ingesteld.