Uw Revenue Cycle Management Data Template
Uw Revenue Cycle Management Data Template
- Aanbevolen attributen om vast te leggen
- Belangrijkste activities om te volgen voor proces discovery
- Gedetailleerde extractiehandleiding voor R1 RCM
Attributen binnen Revenue Cycle Management
| Naam | Omschrijving | ||
|---|---|---|---|
| Activiteitsnaam ActivityName | De naam van de specifieke bedrijfsgebeurtenis of taak die op een bepaald moment binnen het omzetcyclusproces plaatsvond. | ||
| Omschrijving Dit attribuut beschrijft een enkele stap of mijlpaal binnen het Revenue Cycle Management proces voor een gegeven factuurgebeurtenis. Activiteiten vertegenwoordigen het uitgevoerde werk, zoals 'Kosten vastgelegd', 'Claim ingediend' of 'Betaling geboekt'. Het analyseren van de reeks activiteiten vormt de kern van process mining. Het maakt de ontdekking van de feitelijke processtroom mogelijk, de identificatie van knelpunten waar activiteiten te lang duren om te starten, en de detectie van herwerkingslussen waarbij activiteiten onnodig worden herhaald, zoals 'Claim geweigerd' gevolgd door 'Herbewerking weigering gestart'. Het belang Het definieert de stappen in het proces, waardoor de visualisatie van de proceskaart, de berekening van overgangstijden en de identificatie van procesafwijkingen en herwerk mogelijk zijn. Vindplaats Deze informatie is doorgaans afgeleid van event logs, statuswijzigingsrecords of transactiecodes binnen diverse R1 RCM-modules. Het kan een mapping vereisen van technische codes naar bedrijfsnamen. Voorbeelden Kosten GeregistreerdClaim ingediendBetaler Beoordeling OntvangenBetaling GeboektRekening Gesloten | |||
| Billing Event BillingEvent | De unieke identificatie voor een enkele factureerbare dienst of item, die dient als de primaire case-identificatie voor het volgen van de gehele omzetcyclus. | ||
| Omschrijving De Factuurgebeurtenis ID vertegenwoordigt een afzonderlijke instantie van een dienst- of productlevering die resulteert in een kostenpost. Het dient als de centrale draad die alle gerelateerde activiteiten verbindt, van de initiële dienstverlening en vastlegging van kosten tot claimindiening, boeken van betalingen en uiteindelijke afsluiting van de rekening. Bij process mining maakt het analyseren van de levenscyclus van elke Factuurgebeurtenis een uitgebreid beeld van de end-to-end omzetcyclus mogelijk. Het wordt gebruikt om de volledige reis van één kostenpost te traceren, veelvoorkomende paden te identificeren, doorlooptijden tussen belangrijke mijlpalen te meten en variaties te begrijpen die leiden tot vertragingen of omzetverlies. Het belang Deze identificatie is essentieel voor het groeperen van alle gerelateerde activiteiten in één case, waardoor een complete en nauwkeurige procesanalyse van de omzetcyclus voor elke factureerbare gebeurtenis mogelijk wordt. Vindplaats Dit is de primaire sleutel die verschillende tabellen koppelt met betrekking tot patiëntcontacten, kosten, claims en betalingen. Raadpleeg de R1 RCM-documentatie voor het specifieke veld, vaak gerelateerd aan een contact- of claimidentificatie. Voorbeelden BE-2023-0012345BE-2023-0054321BE-2024-0098765 | |||
| Tijdstip Gebeurtenis EventTime | De tijdstempel die aangeeft wanneer een specifieke activiteit of gebeurtenis heeft plaatsgevonden. | ||
| Omschrijving Event Time geeft de precieze datum en tijd waarop een activiteit in het systeem is vastgelegd. Deze temporele informatie is fundamenteel voor het begrijpen van het proces vanuit een tijdgebaseerde analyse. In process mining wordt deze timestamp gebruikt om events chronologisch te ordenen en de duur tussen activiteiten te berekenen, wat cruciaal is voor prestatieanalyse. Het maakt de berekening mogelijk van belangrijke metrics zoals cycle time, processing time en wait time, die essentieel zijn voor het identificeren van knelpunten en het meten van efficiëntie. Het belang Deze timestamp is de basis voor alle tijdgerelateerde analyse, inclusief het berekenen van doorlooptijden, het identificeren van knelpunten en het bewaken van procesprestaties tegenover SLA's. Vindplaats Doorgaans te vinden als een veld 'Aanmaakdatum', 'Timestamp' of 'Laatste update datum' gekoppeld aan elk transactie- of statuswijzigingsrecord in R1 RCM. Voorbeelden 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z | |||
| Bronsysteem SourceSystem | Het bronsysteem waaruit de event data is geëxtraheerd. | ||
| Omschrijving Dit attribuut identificeert de brontoepassing of module die de data voor een specifieke gebeurtenis heeft gegenereerd. In een complexe omgeving zoals de gezondheidszorg kan data afkomstig zijn van een EPD, een facturatiemodule, een claims clearinghouse of een incassoplatform. Het begrijpen van het bronsysteem is cruciaal voor datavalidatie en voor het analyseren van procesvariaties die specifiek kunnen zijn voor bepaalde systemen. Het helpt bij het oplossen van data-inconsistenties en het begrijpen van het technologische landschap van het proces. Het belang Identificeert de oorsprong van de data, wat cruciaal is voor data governance, validatie en het begrijpen hoe verschillende systemen interageren binnen het end-to-end proces. Vindplaats Dit is vaak een statische waarde die tijdens het data-extractieproces wordt toegevoegd, en identificeert het systeem (bijv. 'R1 RCM') waaruit de data afkomstig is. Voorbeelden R1 RCMCernerEpic | |||
| Laatste data-update LastDataUpdate | De tijdstempel van de meest recente verversing of extractie van gegevens uit het bronsysteem. | ||
| Omschrijving Dit attribuut geeft aan wanneer de data voor de process mining-analyse voor het laatst is bijgewerkt. Het biedt context over de actualiteit van de geanalyseerde data. Deze informatie is belangrijk voor rapporteren en dashboarding, omdat het de gebruiker vertelt hoe actueel de procesinzichten zijn. Het helpt de verwachtingen over de tijdigheid van de data te beheren en zorgt ervoor dat beslissingen worden genomen op basis van een begrepen tijdsbestek. Het belang Biedt cruciale context over de actualiteit van de data, zodat analisten en stakeholders op de hoogte zijn van hoe recent de procesinzichten zijn. Vindplaats Deze timestamp wordt gegenereerd tijdens het data-extractie-, transformatie- en laadproces (ETL) en wordt doorgaans toegepast op de gehele dataset. Voorbeelden 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Facturatieafdeling BillingDepartment | De afdeling of het functionele team dat verantwoordelijk is voor het uitvoeren van de activiteit. | ||
| Omschrijving Dit attribuut specificeert de organisatorische eenheid, zoals 'Kosteninvoer', 'Claimindiening' of 'Weigeringsbeheer', die een specifieke processtap heeft uitgevoerd. Het helpt bij het begrijpen van hoe werk wordt overgedragen tussen verschillende teams. Dit is cruciaal voor het analyseren van de afdelingsdoorvoer en het identificeren van cross-functionele knelpunten. Door het procesmodel te filteren op afdeling, kunnen organisaties zien waar overdrachten soepel verlopen en waar vertragingen optreden, wat de resource-allocatie en organisatorische procesoptimalisatie ondersteunt. Het belang Maakt analyse van procesprestaties per organisatie-eenheid mogelijk, wat helpt bij het identificeren van teamspecifieke knelpunten, resourcebeperkingen of best practices. Vindplaats Dit kan worden afgeleid van het gebruikersprofiel in R1 RCM of worden opgeslagen als een 'Afdelingscode' in de transactiedata. Voorbeelden KostenregistratieSchadebeheerAfwijzing & BeroepBoeken van betalingen | |||
| Factuurbedrag InvoiceAmount | De totale monetaire waarde van de kosten op de factuur of claim. | ||
| Omschrijving Dit attribuut vertegenwoordigt het totale gefactureerde bedrag voor de geleverde diensten in een gegeven factuurgebeurtenis. Het weerspiegelt de verwachte omzet van de claim. Het analyseren van het factuurbedrag is cruciaal voor financiële process mining. Het maakt het mogelijk om claims met hoge waarde te prioriteren, de financiële impact van procesvertragingen of weigeringen te begrijpen, en het proces te segmenteren op basis van waarde. Een analyse kan bijvoorbeeld onthullen dat claims boven een bepaald bedrag een ander, meer handmatig procespad volgen. Het belang Biedt financiële context aan het proces, waardoor analyse mogelijk is van hoe procesvariaties de omzet beïnvloeden, en helpt bij het prioriteren van high-value cases voor verbetering. Vindplaats Te vinden in de hoofdclaim- of factuurheader-tabel in R1 RCM, vaak genaamd 'TotalBilledAmount' of vergelijkbaar. Voorbeelden 150.002500.7585.5012000.00 | |||
| Factuurstatus InvoiceStatus | De huidige status van de factuur of claim in de levenscyclus. | ||
| Omschrijving Dit attribuut geeft de laatst bekende status van een factuurgebeurtenis aan, zoals 'Ingediend', 'Betaald', 'Geweigerd' of 'Ter incasso'. Het biedt een momentopname van waar een factuur zich op een gegeven moment in het proces bevindt. De factuurstatus is essentieel voor het maken van verouderingsrapporten en het bewaken van de gezondheid van debiteuren. In process mining kan het worden gebruikt om te filteren op cases die vastzitten in een bepaalde status of om de resultaten van verschillende procesvarianten te analyseren, bijvoorbeeld het vergelijken van de paden van 'Betaalde' versus 'Geweigerde' claims. Het belang Biedt een actueel beeld van elke case, essentieel voor het opstellen van verouderingsrapporten en het analyseren van de uiteindelijke resultaten van verschillende procespaden. Vindplaats Dit is doorgaans een statusveld op de hoofdclaim- of rekeningrecord in R1 RCM. Voorbeelden Wachtend op indieningIngediend bij betalerGeweigerdVolledig betaaldIn Incasso | |||
| Naam Betaler PayerName | De naam van de verzekeringsmaatschappij, overheidsinstantie of patiënt die verantwoordelijk is voor de betaling. | ||
| Omschrijving Dit attribuut identificeert de primaire betaler voor de claim. Dit kan een commerciële verzekeraar zijn zoals Aetna, een overheidsbetaler zoals Medicare, of de patiënt zelf voor eigen bijdragen. Het analyseren van het proces per betaler is fundamenteel voor Revenue Cycle Management. Het kan aan het licht brengen dat bepaalde betalers hogere weigeringspercentages, langere betalingscycli of complexere indieningsvereisten hebben. Deze inzichten stellen de organisatie in staat om haar processen en middelen af te stemmen op betalerspecifiek gedrag. Het belang Maakt segmentatie van het proces per betaler mogelijk om betalersspecifieke vertragingen, afwijzingspatronen of betalingsgedrag te identificeren, wat cruciaal is voor het optimaliseren van de inkomsten. Vindplaats Te vinden in de verzekerings- of demografische informatie van de patiënt, gekoppeld aan de claim in R1 RCM. Voorbeelden MedicareUnitedHealthcareBlue Cross Blue ShieldAetnaZelfbetaler | |||
| Redencode Afwijzing DenialReasonCode | Een gestandaardiseerde code van de betaler die verklaart waarom een claim werd afgewezen. | ||
| Omschrijving Wanneer een betaler een claim weigert, geeft deze een reden code, zoals een CARC (Claim Adjustment Reason Code), om de beslissing toe te lichten. Deze codes zijn gestandaardiseerd en wijzen op problemen zoals 'Dienst niet gedekt' of 'Dubbele claim'. Dit attribuut is uiterst belangrijk voor weigeringsbeheer. Door de frequentie van verschillende weigeringsredencodes te analyseren, kunnen organisaties de grondoorzaken van weigeringen identificeren en aanpakken, of deze nu gerelateerd zijn aan patiëntgeschiktheid, codeerfouten of gebrek aan medische noodzaak. Dit ondersteunt direct inspanningen om herwerk te verminderen en cashflow te versnellen. Het belang Biedt de specifieke reden voor weigeringen van claims, waardoor grondoorzaken kunnen worden geanalyseerd om toekomstige weigeringen te verminderen, herwerk te minimaliseren en de acceptatiegraad bij eerste indiening te verbeteren. Vindplaats Deze informatie wordt ontvangen in het elektronische betalingsafschrift (ERA- of 835-bestand) van de betaler en wordt opgeslagen in de claimsbeheermodule van R1 RCM. Voorbeelden CO-16: Claim/dienst mist informatie nodig voor beoordeling.PR-97: Het voordeel voor deze dienst is inbegrepen in de betaling/toelage voor een andere dienst.CO-22: Deze zorg kan door een andere betaler worden gedekt conform de coördinatie van voordelen.OA-18: Exacte dubbele claim/dienst. | |||
| Toegewezen Gebruiker AssignedUser | De user ID of naam van de medewerker die de activiteit heeft uitgevoerd. | ||
| Omschrijving Dit attribuut identificeert de persoon die verantwoordelijk is voor het uitvoeren van een specifieke taak in het proces. Dit kan de facturatieverantwoordelijke zijn die de claim heeft aangemaakt, de analist die een weigering heeft herwerkt, of de specialist die een betaling heeft geboekt. Analyseren per gebruiker helpt om de werkdrukverdeling, individuele prestaties en trainingsbehoeften te begrijpen. Het kan benadrukken welke gebruikers het meest efficiënt zijn of welke mogelijk geassocieerd zijn met hogere foutenpercentages, waardoor gerichte management- en procesverbeteringsinspanningen mogelijk worden. Het belang Maakt analyse van team- en individuele prestaties, werkbelastingdistributie mogelijk en helpt bij het identificeren van trainingsmogelijkheden of gebruikersspecifieke procesafwijkingen. Vindplaats Doorgaans te vinden als een veld 'UserID', 'Verwerker' of 'UpdatedBy' in transactielogs binnen R1 RCM. Voorbeelden jdoeasmithp.jonesBOT_RPA01 | |||
| Aanpassingsbedrag AdjustmentAmount | De monetaire waarde van een correctie die is uitgevoerd op het rekeningsaldo. | ||
| Omschrijving Dit attribuut legt de waarde vast van financiële correcties die aan een patiëntenrekening zijn gedaan na de initiële facturatie. Correcties kunnen positief of negatief zijn en omvatten contractuele kortingen, afschrijvingen of correcties. Het volgen van correctiebedragen is cruciaal voor het begrijpen van omzetintegriteit. Grote negatieve correcties kunnen wijzen op omzetverlies door problemen zoals onjuiste vastlegging van kosten of oninbare schuld. Het analyseren van deze data helpt de financiële impact van facturatiefouten en incasso-inefficiënties te identificeren. Het belang Kwantificeert omzetverlies en financiële correcties, en helpt de monetaire impact van facturatieonvolkomenheden, contractuele verplichtingen of oninbare vorderingen vast te stellen. Vindplaats Te vinden in de transactielogs gerelateerd aan rekeningaanpassingen of betalingsboeking in R1 RCM. Voorbeelden -50.2520.00-1200.00 | |||
| Doorlooptijd van dienst tot betaling ServiceToPaymentCycleTime | De totale berekende duur vanaf het moment dat een dienst werd geleverd tot het moment dat de uiteindelijke betaling werd geboekt. | ||
| Omschrijving Deze meting meet de end-to-end duur van de omzetcyclus voor een enkele factuurgebeurtenis. Het vertegenwoordigt de totale tijd die een organisatie nodig heeft om een geleverde dienst om te zetten in contanten. Dit is een kritieke Key Performance Indicator (KPI) voor financiële gezondheid. Het analyseren van deze duur helpt bij het identificeren van belangrijke gebieden voor procesversnelling. Door de doorlooptijd op te splitsen in de samenstellende delen, zoals 'tijd om te factureren' en 'tijd om te betalen', kunnen organisaties de grootste kansen aanwijzen om de cashflow te verbeteren. Het belang Dit is een kritieke, high-level KPI die de algehele efficiëntie van de cash conversion cycle meet en direct van invloed is op de cashflow van de organisatie. Vindplaats Dit is een berekende meting. Het is het tijdsverschil tussen de timestamp van de activiteit 'Dienst geleverd' en de activiteit 'Betaling geboekt' voor een gegeven Factuurgebeurtenis. Voorbeelden 35 dagen 8 uur92 dagen 4 uur15 dagen 12 uur | |||
| Incasso Resultaat CollectionOutcome | Het eindresultaat van incassoactiviteiten voor een openstaand saldo. | ||
| Omschrijving Dit attribuut beschrijft het resultaat van inspanningen om betaling te innen voor een achterstallige rekening. Mogelijke uitkomsten zijn 'Volledig betaald', 'Afgehandeld', 'Als oninbaar geboekt' of 'Onopgelost'. Het volgen van incassoresultaten is essentieel voor het evalueren van de effectiviteit van het incassoproces. Door te analyseren welke activiteiten leiden tot welke resultaten, kunnen organisaties hun incassostrategieën optimaliseren, herstelpercentages verbeteren en weloverwogen beslissingen nemen over wanneer incassopogingen te staken en saldi af te schrijven. Dit ondersteunt het dashboard voor Incassoactiviteitsprestaties. Het belang Meet de effectiviteit van het incassoproces door de uiteindelijke oplossing van achterstallige rekeningen te volgen, wat helpt bij het optimaliseren van incassostrategieën. Vindplaats Dit is waarschijnlijk een statusveld op de patiëntenrekening of in een speciale incassomodule binnen R1 RCM. Voorbeelden Volledig betaaldAfgehandeld voor een lager bedragNaar extern bureau gestuurdAfgeschreven als oninbare vordering | |||
| Is Geautomatiseerd IsAutomated | Een indicator die aangeeft of de activiteit werd uitgevoerd door een geautomatiseerd systeem of een menselijke gebruiker. | ||
| Omschrijving Dit Booleaanse attribuut onderscheidt taken die zijn uitgevoerd door softwareautomatisering, zoals een RPA-bot voor claimindiening, en taken die handmatig zijn uitgevoerd door een medewerker. Het analyseren van dit attribuut is essentieel om de impact en effectiviteit van automatiseringsinitiatieven te begrijpen. Het maakt het vergelijken van de snelheid, kosten en foutenpercentages van geautomatiseerde versus handmatige processen mogelijk, wat helpt bij het identificeren van nieuwe automatiseringsmogelijkheden en het meten van de ROI van bestaande bots. Het belang Onderscheidt tussen menselijke en systeemgestuurde activiteiten, wat cruciaal is voor het meten van de impact van automatisering op procesefficiëntie, kosten en kwaliteit. Vindplaats Dit kan worden afgeleid uit het veld 'AssignedUser', waar specifieke gebruikers-ID's zijn gereserveerd voor bots (bijv. 'BOT_RPA01'). Als alternatief hebben sommige systemen een speciaal veld om geautomatiseerde transacties te markeren. Voorbeelden truefalse | |||
| Is herstelwerk IsRework | Een berekende indicator die activiteiten identificeert die deel uitmaken van een herwerkingslus, zoals het opnieuw indienen van een afgewezen claim. | ||
| Omschrijving Dit attribuut is een Booleaanse vlag die doorgaans wordt berekend tijdens process mining-analyse. Het wordt 'waar' als een activiteit een herhaling is van een eerdere stap of deel uitmaakt van een reeks die de correctie van een fout aangeeft, bijvoorbeeld elke activiteit volgend op 'Claim geweigerd'. Het identificeren van herwerk is een van de krachtigste mogelijkheden van process mining. Het kwantificeert de hoeveelheid verspilde inspanning, tijd en middelen in een proces. Door herwerk te markeren, kunnen organisaties hun verbeteringsinspanningen richten op het voorkomen van de fouten die het veroorzaken, wat leidt tot aanzienlijke efficiëntiewinst. Het belang Helpt de frequentie en impact van herwerk te kwantificeren, zoals claimafwijzingen, waardoor gerichte analyse mogelijk is om inefficiënties en verspilde inspanning te verminderen. Vindplaats Dit is geen veld in het bronsysteem. Het wordt berekend door de process mining tool op basis van de reeks activiteiten, zoals het detecteren wanneer een 'Claim ingediend'-activiteit meer dan eens voorkomt voor dezelfde case. Voorbeelden truefalse | |||
| Patiënt ID PatientId | De unieke identificatie voor de patiënt die de dienst heeft ontvangen. | ||
| Omschrijving Dit attribuut is de unieke ID die aan een patiënt binnen het zorgsysteem wordt toegewezen, vaak aangeduid als het Medisch Dossier Nummer (MRN). Hoewel individuele patiëntenzorg niet de focus is, kan de Patiënt ID worden gebruikt om terugkerende facturatieproblemen voor dezelfde patiënt over tijd te analyseren. Het kan ook helpen om het proces te segmenteren op patiëntdemografie of -geschiedenis indien gekoppeld aan andere patiëntdata, waardoor mogelijk systemische problemen die specifieke patiëntgroepen beïnvloeden, aan het licht komen. Het belang Maakt analyse van billing events op patiëntniveau mogelijk, wat helpt bij het identificeren van terugkerende problemen of patronen voor specifieke patiënten over meerdere contactmomenten. Vindplaats Deze identificatie is een kernonderdeel van de demografische patiëntdata die gekoppeld is aan elk patiëntcontact en elke claim in R1 RCM. Voorbeelden MRN837262MRN937281MRN103847 | |||
| Reden van aanpassing AdjustmentReason | De reden voor een financiële correctie, zoals 'Contractuele korting' of 'Afschrijving oninbare vorderingen'. | ||
| Omschrijving Dit attribuut biedt context voor waarom een financiële correctie aan een rekening werd uitgevoerd. Redenen zijn vaak gestandaardiseerde codes of beschrijvingen die het type correctie categoriseren. Het analyseren van correctieredenen helpt bij het diagnosticeren van de grondoorzaken van omzetverlies. Een hoge frequentie van 'Afschrijving klein saldo' kan bijvoorbeeld duiden op een inefficiënt incassoproces voor kleine bedragen, terwijl frequente 'Contractuele kortingen' een verwacht onderdeel zijn van onderhandelingen met betalers. Deze analyse ondersteunt het dashboard voor Factuurcorrecties & Compliance Audit. Het belang Verklaart het 'waarom' achter inkomsten aanpassingen, wat helpt bij het identificeren van de diepere oorzaken van inkomstenverlies, zoals contractuele problemen, factureringsfouten of incassofalen. Vindplaats Dit is doorgaans een code- of tekstveld in hetzelfde transactierecord als het Correctiebedrag in R1 RCM. Voorbeelden Contractuele TegemoetkomingAfschrijving dubieuze debiteurenAfschrijving klein bedragFactureringsfout Correctie | |||
| Servicecode ServiceCode | De facturatiecode voor de specifieke geleverde dienst of procedure, zoals een CPT- of HCPCS-code. | ||
| Omschrijving Servicecodes, zoals CPT-codes (Current Procedural Terminology), zijn gestandaardiseerde medische codes die worden gebruikt om medische, chirurgische en diagnostische procedures en diensten te rapporteren aan betalers voor vergoeding. Het analyseren van het proces per servicecode is essentieel voor het identificeren van facturatieproblemen gerelateerd aan specifieke zorgtypes. Het kan aan het licht brengen welke procedures het vaakst worden geweigerd, de langste betalingscycli hebben, of het meeste herwerk vereisen, wat gerichte verbeteringen in codeer- en facturatiepraktijken mogelijk maakt. Het belang Maakt procesanalyse mogelijk op basis van het type geleverde dienst, wat cruciaal is voor het identificeren van afwijzingspatronen of betalingsvertragingen in verband met specifieke procedures. Vindplaats Deze informatie is te vinden op postniveau voor elke kostenpost of claim binnen R1 RCM. Voorbeelden 992139928573560 | |||
Activiteiten binnen Revenue Cycle Management
| Activiteit | Omschrijving | ||
|---|---|---|---|
| Betaling Geboekt | De ontvangen betaling wordt officieel toegepast op de rekening van de patiënt, waardoor het openstaande saldo wordt verminderd. Dit is de laatste stap in het afstemmen van een betaling met de gefactureerde diensten. | ||
| Het belang Deze activiteit vormt het eindpunt voor het berekenen van de doorlooptijden van Dienst-tot-Betaling en Betalingen Boeken. Het bevestigt dat omzet wordt verantwoord en rekeningen nauwkeurig worden bijgewerkt. Vindplaats Dit wordt vastgelegd als een expliciete financiële transactie in de financiële administratie module van R1 RCM. Elke boeking omvat een datum, bedrag en bron. Vastleggen Vastgelegd als een specifieke transactie met een boekingsdatum wanneer een gebruiker of geautomatiseerd proces de betaling verwerkt. Gebeurtenistype explicit | |||
| Betaling Ontvangen | Een betaling wordt ontvangen van een betaler of een patiënt. Deze event markeert de ontvangst van gelden, maar de gelden zijn nog niet toegepast op de specifieke rekening of servicecomponenten. | ||
| Het belang Vertegenwoordigt de instroom van contanten. Het tijdsverschil tussen 'Betaling ontvangen' en 'Betaling geboekt' is een cruciale meting voor het begrijpen van de backoffice-efficiëntie en vertragingen in kasafstemming. Vindplaats Geregistreerd uit elektronische betalingsbestanden van betalers of uit de verwerking van patiëntbetalingen. De event komt overeen met de stortingsdatum of de ontvangstdatum van het bestand. Vastleggen Geregistreerd vanuit de effectieve betalingsdatum van het ERA-bestand of de transactiedatum van een patiëntbetaling. Gebeurtenistype explicit | |||
| Claim ingediend | De gegenereerde claim wordt elektronisch ingediend bij de verantwoordelijke betaler, zoals een verzekeringsmaatschappij. Dit markeert de eerste externe communicatie in het facturatieproces om vergoeding veilig te stellen. | ||
| Het belang Een cruciale mijlpaal die de klok start voor de vergoeding door de betaler. Het volgen hiervan helpt bij het monitoren van achterstanden in indieningen en zorgt voor tijdige indiening in overeenstemming met de regels van de betalers. Vindplaats Deze gebeurtenis wordt vastgelegd als een expliciete transactie wanneer de claim naar een clearinghouse wordt verzonden. Het systeem registreert de indiening timestamp en bevestigingsdetails. Vastleggen Expliciet geregistreerd als een transactie met een indienings-timestamp wanneer de claim via het clearinghouse wordt verzonden. Gebeurtenistype explicit | |||
| Dienst Geleverd | Vertegenwoordigt het moment waarop een factureerbare dienst of procedure voor een patiënt is voltooid. Deze gebeurtenis wordt vaak vastgelegd vanuit een klinisch of planningssysteem en dient als de trigger voor de omzetcyclus. | ||
| Het belang Dit is het startpunt voor de Service-to-Payment doorlooptijd KPI. Het analyseren van de tijd vanaf deze gebeurtenis helpt front-end vertragingen in de omzetcyclus te identificeren. Vindplaats Doorgaans afkomstig van een Elektronisch Patiëntendossier (EPD) of een praktijkmanagementsysteem geïntegreerd met R1 RCM. Het wordt vaak afgeleid van een 'Datum dienst' of 'Procedure voltooid' timestamp in het patiëntendossier. Vastleggen Afgeleid van de 'Date of Service' timestamp geassocieerd met de patiëntafspraak. Gebeurtenistype inferred | |||
| Kosten Geregistreerd | Deze activiteit staat voor de formele registratie van alle factureerbare diensten, procedures en benodigdheden voor een patiëntcontact. Het is een cruciale stap in gegevensinvoer die klinische activiteiten vertaalt naar financiële transacties. | ||
| Het belang Markeert de overdracht van klinische naar financiële operaties. Het is het startpunt voor het meten van de doorlooptijden van factuur- en claimgeneratie en helpt bij het identificeren van achterstanden bij kostenregistratie. Vindplaats Geregistreerd binnen de charge entry module van R1 RCM of ontvangen via een interface van een EHR. De event wordt doorgaans gemarkeerd door een specifieke transactielog of de aanmaak-timestamp van de kostenpost. Vastleggen Geïdentificeerd door de aanmaak-timestamp van het kosten-transactierecord in de facturatietabel. Gebeurtenistype explicit | |||
| Rekening Gesloten | De factuurgebeurtenis is volledig opgelost met een nulbalans en de rekening is formeel afgesloten. Dit markeert de succesvolle voltooiing van de omzetcyclus voor dit specifieke contact. | ||
| Het belang Dit is de primaire 'happy path' eindgebeurtenis voor het proces. Het meten van de doorlooptijd van rekeningafsluiting helpt ervoor te zorgen dat administratieve taken efficiënt worden voltooid en records worden gefinaliseerd. Vindplaats Deze gebeurtenis wordt afgeleid wanneer het rekeningsaldo nul bereikt en een uiteindelijke status van 'Afgesloten' of 'Volledig betaald' wordt toegepast. De timestamp wordt genomen van de laatste financiële transactie die het saldo op nul bracht. Vastleggen Afgeleid wanneer het rekeningsaldo nul wordt en een 'Gesloten' status wordt toegepast, samen met een finale activiteit timestamp. Gebeurtenistype inferred | |||
| Afwijzing Herwerk Gestart | Een gebruiker of geautomatiseerde workflow begint met het onderzoeken en oplossen van een afgewezen claim. Dit kan het corrigeren van codering, het indienen van documentatie of het aanvechten van de beslissing van de betaler inhouden. | ||
| Het belang Volgt het begin van de kostbare herwerkingslus voor geweigerde claims. Het meten van de tijd die in deze fase wordt besteed, is essentieel om de efficiëntie van het weigeringsbeheerteam te begrijpen. Vindplaats Deze gebeurtenis wordt vaak afgeleid uit een wijziging in de status van de geweigerde claim naar 'Herwerk in uitvoering' of 'In beoordeling' binnen een R1 RCM-wachtrij of weigeringsbeheer module. Vastleggen Afgeleid van een statuswijziging in een denial management werklijst of door de eerste gebruikersactie op een afgewezen claim. Gebeurtenistype inferred | |||
| Betaler Beoordeling Ontvangen | Het systeem ontvangt een reactie van de betaler met betrekking tot de ingediende claim, vaak in een Electronic Remittance Advice (ERA)-bestand. Deze reactie specificeert wat betaald, geweigerd of gecorrigeerd werd. | ||
| Het belang Deze gebeurtenis is een cruciaal knooppunt in het proces, dat bepaalt of de volgende stap het boeken van betalingen of het beheer van weigeringen is. Analyse hiervan helpt het betalergedrag en de betalingssnelheid te begrijpen. Vindplaats Geregistreerd wanneer een elektronisch betalingsbestand, zoals een ANSI 835-bestand, van de betaler wordt verwerkt door R1 RCM. De event wordt gemarkeerd door de verwerking timestamp van dit bestand. Vastleggen Geregistreerd bij de ingestie en verwerking van het Electronic Remittance Advice (ERA/835) bestand. Gebeurtenistype explicit | |||
| Claim aangemaakt | Een formele factuurclaim wordt in het systeem gegenereerd op basis van de geregistreerde kosten. Dit omvat het samenstellen van patiëntdemografie, verzekeringsinformatie en servicecodes in een gestandaardiseerd formaat. | ||
| Het belang Dit is een belangrijke interne mijlpaal vóór externe indiening. Vertragingen hier kunnen wijzen op problemen met codering, datavalidatie of systeemconfiguratie die het gehele facturatieproces vertragen. Vindplaats Dit is een interne systeemgebeurtenis binnen R1 RCM. Het wordt waarschijnlijk vastgelegd als een statuswijziging op de factureringsrekening of door de aanmaak timestamp van de claimentiteit zelf. Vastleggen Afgeleid van de statuswijziging naar 'Claim Generated' of de aanmaak-timestamp van de claimrecord. Gebeurtenistype inferred | |||
| Claim geweigerd | De betaler heeft geweigerd de claim te betalen, hetzij volledig, hetzij voor specifieke posten. De weigeringsreden wordt vastgelegd, waardoor een herwerk- en beroepsproces wordt geïnitieerd. | ||
| Het belang Deze activiteit benadrukt omzetverlies en procesinefficiëntie. Het analyseren van weigeringsredenen is essentieel voor het identificeren van grondoorzaken en het verbeteren van de acceptatiegraad van claims bij de eerste indiening. Vindplaats Dit is geen discrete gebeurtenis, maar eerder een status afgeleid uit de details binnen een verwerkt ERA-bestand. Specifieke weigeringscodes binnen de betalingsdata triggeren een statuswijziging op de claim. Vastleggen Afgeleid van afwijzingscodes aanwezig in het verwerkte ERA-bestand, die de status van de claim wijzigen naar 'Denied'. Gebeurtenistype inferred | |||
| Incasso Activiteit Gestart | De rekening van de patiënt is achterstallig geworden en proactieve incassopogingen worden geïnitieerd. Dit kan variëren van geautomatiseerde herinneringsbrieven tot plaatsing bij een incassospecialist. | ||
| Het belang Markeert het begin van het kostenintensieve incassoproces. Het analyseren van de effectiviteit en cycle time van deze activiteiten helpt de strategieën voor het innen van dubieuze debiteuren te optimaliseren. Vindplaats Deze gebeurtenis wordt waarschijnlijk gelogd of afgeleid uit een statuswijziging wanneer een rekening wordt verplaatst naar een incassowachtrij of een incassostatuscode krijgt toegewezen binnen R1 RCM. Vastleggen Afgeleid van een statuswijziging op de rekening naar een 'Collections' of 'Delinquent' status. Gebeurtenistype inferred | |||
| Patiëntoverzicht Geregistreerd | Na de verzekeringsbeoordeling wordt een overzicht voor de patiënt gemaakt met het resterende bedrag waarvoor zij verantwoordelijk zijn. Dit kan betrekking hebben op eigen bijdragen, eigen risico of niet-gedekte diensten. | ||
| Het belang Deze activiteit initieert het patiëntbetalingsgedeelte van de omzetcyclus. Het analyseren van de timing en frequentie ervan is belangrijk voor het beheren van patiëntincasso en cashflow. Vindplaats Doorgaans vastgelegd als een gelogde gebeurtenis wanneer een batchproces wordt uitgevoerd om patiëntafschriften aan te maken en af te drukken of elektronisch te verzenden. R1 RCM zou de datum vastleggen waarop het afschrift werd gegenereerd. Vastleggen Geregistreerd als een transactie wanneer het batchproces voor het genereren van patiëntoverzichten wordt uitgevoerd. Gebeurtenistype explicit | |||
| Rekening Afgeschreven als Dubieuze Debiteur | Alle incassopogingen zijn uitgeput en het resterende rekeningsaldo wordt als oninbaar beschouwd. Het saldo wordt afgeschreven als dubieuze debiteur, wat een definitief omzetverlies betekent. | ||
| Het belang Dit vertegenwoordigt een negatieve procesuitkomst en direct omzetverlies. Het analyseren van welke cases resulteren in oninbare vorderingen kan patronen in wanbetaling en kansen om incasso te verbeteren aan het licht brengen. Vindplaats Dit is doorgaans een expliciete transactie in R1 RCM waarbij het openstaande saldo naar een specifieke categorie oninbare vorderingen wordt verplaatst, vaak getriggerd door een gebruiker of geautomatiseerde verouderingsregels. Vastleggen Geregistreerd als een specifieke financiële transactie om het saldo af te schrijven, vaak geassocieerd met een overdracht aan een extern incassobureau. Gebeurtenistype explicit | |||
| Rekeningaanpassing Gemaakt | Een niet-betalingstransactie wordt op de rekening geboekt om het saldo te wijzigen. Dit kan contractuele aanpassingen omvatten op basis van betalersovereenkomsten, afschrijvingen van kleine saldi of correcties. | ||
| Het belang Hoge volumes aan aanpassingen kunnen wijzen op problemen met tariefschema's, contractbeheer of factureringsfouten. Het volgen van aanpassingen is cruciaal voor het analyseren van de omzetintegriteit. Vindplaats Vastgelegd als een specifiek transactietype in de financiële administratie module van R1 RCM. Elke correctie heeft een code, een bedrag en een boekingsdatum. Vastleggen Geregistreerd als een afzonderlijke aanpassingstransactie, identificeerbaar door een unieke transactiecode. Gebeurtenistype explicit | |||
Extractie Guides
Stappen
- Log in op het R1 RCM platform met een gebruikersaccount dat rechten heeft om toegang te krijgen tot de business intelligence of rapportagemodules.
- Navigeer naar de rapportagesectie van het platform. Dit kan gelabeld zijn als "Business Intelligence", "Reporting Portal" of "Analytics".
- Zoek de tool voor het aanmaken van een nieuw aangepast rapport of query. Dit stelt u in staat de specifieke data-velden en logica voor de extractie te definiëren.
- Aangezien R1 RCM geen vooraf gebouwd, uniform event log biedt, moet u er zelf een samenstellen door data uit verschillende bronnen te combineren. De geleverde query-configuratie gebruikt een UNION ALL benadering om events van diverse business objecten samen te voegen tot één chronologisch logboek.
- Kopieer de complete query uit de "Query"-sectie van dit document en plak deze in de query-editor of configuratie-interface van het aangepaste rapport.
- Configureer de rapportparameters, vooral het datumbereik. Stel de
'{StartDate}'en'{EndDate}'placeholders in de query in om de tijdsperiode voor de extractie te definiëren, zoals de laatste 6 maanden. - Voeg eventuele andere noodzakelijke filters toe aan de rapportconfiguratie, zoals filteren op specifieke faciliteiten, afdelingen of betalersgroepen om de reikwijdte van de data te verkleinen.
- Voer het rapport uit. Dit zal de query uitvoeren op de R1 RCM database en de resultaten genereren op basis van uw gespecificeerde parameters.
- Zodra het rapport is voltooid, zoek de optie om de data te exporteren. Selecteer CSV (Comma Separated Values) als exportformaat, aangezien dit direct compatibel is met ProcessMind.
- Download het gegenereerde CSV-bestand en open het voor een snelle controle. Zorg ervoor dat de kolomheaders overeenkomen met de vereiste attributes:
BillingEvent,ActivityName,EventTime,SourceSystemenLastDataUpdate. - Verifieer dat de datum- en tijdformaten in de
EventTimeenLastDataUpdatekolommen consistent zijn voordat u het bestand uploadt naar ProcessMind.
Configuratie
- Vereisten: Een gebruikersaccount met voldoende rechten om aangepaste rapporten te openen en aan te maken binnen de R1 RCM Business Intelligence module is vereist.
- Rapporttype: Gebruik een aangepaste query of geavanceerde rapportbouwer die complexe data-ophaling en het gebruik van UNION ALL statements mogelijk maakt om verschillende datasets te combineren.
- Datumbereik: Om de prestaties en het datavolume te beheren, is het cruciaal om te filteren op een specifieke periode. We raden aan om voor de initiële analyse te beginnen met een periode van 3 tot 6 maanden. Pas het datumfilter toe op het primaire timestamp-veld voor elke activiteit.
- Belangrijke filters: Naast het datumbereik kunt u overwegen filters toe te passen voor
Facility ID,Payer TypeofBilling Departmentom de analyse te richten op specifieke operationele gebieden en de grootte van de export te verminderen. - Exportformaat: Kies altijd CSV als uitvoerformaat. Dit zorgt voor een schoon, gestructureerd bestand dat gemakkelijk kan worden geparseerd door process mining tools.
- Planning: Indien de R1 RCM rapportagemodule dit ondersteunt, overweeg dan dit rapport periodiek (bijv. wekelijks of maandelijks) te plannen om data-verversingen te automatiseren voor continue monitoring.
a Voorbeeldquery config
SELECT
c.ClaimID AS BillingEvent,
'Service Rendered' AS ActivityName,
c.ServiceDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ClinicianID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Rendered' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ServiceDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
c.ClaimID AS BillingEvent,
'Charges Captured' AS ActivityName,
c.ChargeEntryTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ChargeEntryUserID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Open' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ChargeEntryTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Created' AS ActivityName,
cl.CreationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.CreatedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Created' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.CreationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Submitted' AS ActivityName,
cl.SubmissionTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.SubmittedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Submitted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.SubmissionTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
era.ClaimID AS BillingEvent,
'Payer Adjudication Received' AS ActivityName,
era.ReceivedTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pa.InvoiceAmount AS InvoiceAmount,
era.PayerName AS PayerName,
'Adjudicated' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [RemittanceAdvice] era
JOIN [PatientAccounts] pa ON era.ClaimID = pa.BillingEvent
WHERE era.ReceivedTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
d.ClaimID AS BillingEvent,
'Claim Denied' AS ActivityName,
d.DenialTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Denied' AS InvoiceStatus,
d.ReasonCode AS DenialReasonCode
FROM [DenialsLog] d
JOIN [ClaimsData] cl ON d.ClaimID = cl.ClaimID
WHERE d.DenialTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
dr.ClaimID AS BillingEvent,
'Denial Rework Started' AS ActivityName,
dr.ReworkStartTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
dr.AssignedUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'In Rework' AS InvoiceStatus,
dr.OriginalDenialCode AS DenialReasonCode
FROM [DenialRework] dr
JOIN [ClaimsData] cl ON dr.ClaimID = cl.ClaimID
WHERE dr.ReworkStartTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ps.PatientAccountID AS BillingEvent,
'Patient Statement Generated' AS ActivityName,
ps.GenerationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ps.GeneratedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
ps.StatementBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Patient Billed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientStatements] ps
JOIN [PatientAccounts] pa ON ps.PatientAccountID = pa.BillingEvent
WHERE ps.GenerationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
p.AssociatedClaimID AS BillingEvent,
'Payment Received' AS ActivityName,
p.ReceiptTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
p.ProcessedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
p.PaymentAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Payment Pending' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentsLog] p
JOIN [PatientAccounts] pa ON p.AssociatedClaimID = pa.BillingEvent
WHERE p.ReceiptTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pt.ClaimID AS BillingEvent,
'Payment Posted' AS ActivityName,
pt.PostingTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pt.PostedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pt.PostedAmount AS InvoiceAmount,
pt.PayerName AS PayerName,
'Partially Paid' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentTransactions] pt
JOIN [PatientAccounts] pa ON pt.ClaimID = pa.BillingEvent
WHERE pt.PostingTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
a.ClaimID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
a.AdjustmentTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
a.AdjusterID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
a.AdjustmentAmount AS InvoiceAmount,
pa.PayerName AS PayerName,
'Adjusted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [Adjustments] a
JOIN [PatientAccounts] pa ON a.ClaimID = pa.BillingEvent
WHERE a.AdjustmentTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ca.PatientAccountID AS BillingEvent,
'Collection Activity Started' AS ActivityName,
ca.ActivityTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ca.AssignedAgentID AS AssignedUser,
'Collections' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'In Collections' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [CollectionsActivity] ca
JOIN [PatientAccounts] pa ON ca.PatientAccountID = pa.BillingEvent
WHERE ca.ActivityTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Placed in Bad Debt' AS ActivityName,
pa.BadDebtPlacementDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pa.BadDebtUserID AS AssignedUser,
'Finance' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Bad Debt' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.BadDebtPlacementDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Closed' AS ActivityName,
pa.ClosureDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
0 AS InvoiceAmount,
pa.PayerName AS PayerName,
'Closed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.ClosureDate BETWEEN '{StartDate}' AND '{EndDate}' AND pa.CurrentBalance = 0;