Datatemplate voor Revenue Cycle Management
Datatemplate voor Revenue Cycle Management
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten om te volgen
- Richtlijnen voor data-extractie
Attributen voor Revenue Cycle Management
| 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 | |||
Activiteiten voor Revenue Cycle Management
| 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 | |||
Extractiegidsen
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.
Geen creditcard nodig. Binnen enkele minuten ingesteld.