Je Revenue Cycle Management datatemplate
Je Revenue Cycle Management datatemplate
- Aanbevolen attributen om vast te leggen
- Belangrijkste activiteiten om te volgen voor process discovery
- Duidelijke extractiegids voor R1 RCM
Revenue Cycle Management Attributen
| Naam | Beschrijving | ||
|---|---|---|---|
| Activiteitsnaam ActivityName | De naam van de specifieke bedrijfsgebeurtenis of taak die op een bepaald moment binnen het omzetcyclus-proces plaatsvond. | ||
| Beschrijving 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 bekijkking van de feitelijke processtroom mogelijk, de identificatie van knelpunten waar activiteiten te lang duren om te starten, en de detectie van reworkingslussen waarbij activiteiten onnodig worden herhaald, zoals 'Claim geweigerd' gevolgd door 'Herbewerking weigering gestart'. Waarom het belangrijk is Het definieert de stappen in het proces, waardoor de visualisatie van de proceskaart, de berekening van overgangstijden en de identificatie van procesafwijkingen en rework mogelijk zijn. Waar te verkrijgen Deze Informatie is meestal gebaseerd op event logs, statuswijzigings of transactiecodes binnen diverse R1 RCM-modules. Het kan een mapping vereisen van technische codes naar bedrijfsnamen. Voorbeelden Charges VastgelegdClaim ingediendToewijzing Betaler OntvangenBetaling GeboektAccount Afgesloten | |||
| Facturatie `Event` BillingEvent | De unieke ID voor een enkele factureerbare dienst of item, die dient als de primaire case-identificatie voor het volgen van de gehele omzetcyclus. | ||
| Beschrijving De Factuurgebeurtenis-ID vertegenwoordigt een afzonderlijke instantie van een dienst- of productlevering die resulteert in een kostenpost. Het dient als de belangrijkste link 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 vinden, doorlooptijden tussen belangrijke mijlpalen te meten en variaties te begrijpen die leiden tot vertragingen of omzetverlies. Waarom het belangrijk is Deze identificatie is belangrijk voor het groeperen van alle gerelateerde activiteiten in één case, waardoor een complete en nauwkeurige procesanalyse van de omzetcyclus voor elke factureerbare gebeurtenis mogelijk worden. Waar te verkrijgen Dit is de primary key die verschillende tabellen koppelt voor 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 timestamp die aangeeft wanneer een specifieke activiteit of gebeurtenis heeft plaatsgevonden. | ||
| Beschrijving Event Time geeft de precieze datum en tijd waarop een activiteit in het systeem is vastgelegd. Deze temporele Informatie is onmisbaar voor het begrijpen van het proces vanuit een tijdgebonden analyse. In process mining wordt deze timestamp gebruikt om gebeurtenissen chronologisch te ordenen en de duur tussen activiteiten te berekenen, wat belangrijk is voor prestatieanalyse. Het maakt de berekening mogelijk van belangrijke meetwaarden zoals doorlooptijd, verwerkingstijd en wait time, die belangrijk zijn voor het vinden van knelpunten en het meten van efficiëntie. Waarom het belangrijk is Deze timestamp is de basis voor alle tijdgerelateerde analyse, inclusief het berekenen van doorlooptijden, het vinden van knelpunten en het bewaken van procesprestaties tegenover SLA's. Waar te verkrijgen Doorgaans te vinden als een veld 'Aanmaakdatum', 'Timestamp' of 'Laatste update datum' gekoppeld aan elk transactie- of statuswijziging in R1 RCM. Voorbeelden 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z | |||
| Bronsysteem SourceSystem | Het bronsysteem waaruit de gebeurtenis data is opgehaald. | ||
| Beschrijving 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 belangrijk 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 technische omgeving van het proces. Waarom het belangrijk is Identificeert de oorsprong van de data, wat belangrijk is voor data governance, validatie en het begrijpen hoe verschillende systemen interageren binnen het end-to-end proces. Waar te verkrijgen 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 | |||
| Tijdstip van extractie LastDataUpdate | De tijdstempel van de meest recente verversing of extractie van gegevens uit het bronsysteem. | ||
| Beschrijving Dit attribuut geeft aan wanneer de data voor de process mining-analyse voor het laatst is bijgewerkt. Het biedt context over de relevantie 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 door de tijd heenigheid van de data te beheren en zorgt ervoor dat beslissingen worden genomen op basis van een begrepen tijdsbestek. Waarom het belangrijk is Biedt belangrijke context over de relevantie van de data, zodat analysesten en stakeholders op de hoogte zijn van hoe recent de procesinzichten zijn. Waar te verkrijgen 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 | |||
| Afwijzingsredencode DenialReasonCode | Een gestandaardiseerde `code` van de `payer` die uitlegt waarom een `claim` is geweigerd. | ||
| Beschrijving Wanneer een betaler een claim weigert, geeft deze een redencode, 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 vinden en aanpakken, of deze nu gerelateerd zijn aan patiëntgeschiktheid, codeerfouten of gebrek aan medische noodzaak. Dit ondersteunt direct inspanningen om rework te verminderen en cashflow te versnellen. Waarom het belangrijk is Biedt de specifieke reden voor weigeringen van claims, waardoor grondoorzaken kunnen worden geanalyseerd om toekomstige weigeringen te verminderen, rework te minimaliseren en de acceptatiegraad bij eerste indiening te verbeteren. Waar te verkrijgen 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/service mist Informatie die nodig is voor de afhandeling.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. | |||
| Facturatieafdeling BillingDepartment | De afdeling of het functionele team dat verantwoordelijk is voor het uitvoeren van de activiteit. | ||
| Beschrijving Dit attribuut specificeert de onderdeel, 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 belangrijk voor het analyseren van de afdelingsdoorvoer en het vinden van cross-functionele knelpunten. Door het procesmodel te filteren op afdeling, kunnen organisaties zien waar overdrachten soepel verlopen en waar vertragingen optreden, wat de toewijzing van middelen en organisatorische procesoptimalisatie ondersteunt. Waarom het belangrijk is Maakt analyse van procesprestaties per organisatie-eenheid mogelijk, wat helpt bij het vinden van teamspecifieke knelpunten, bron-beperkingen of best practices. Waar te verkrijgen Dit kan worden afgeleid van het gebruikersprofiel in R1 RCM of worden opgeslagen als een 'Afdelingscode' in de transactiedata. Voorbeelden Charge CaptureSchadebeheerAfwijzing & BeroepBoeken van betalingen | |||
| Factuurbedrag InvoiceAmount | De totale financiële waarde van de kosten op de factuur of claim. | ||
| Beschrijving 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 belangrijk voor financiële process mining. Het maakt het mogelijk om claims met hoogwaardige 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 zichtbaar maken dat claims boven een bepaald bedrag een ander, meer handmatig procespad volgen. Waarom het belangrijk is 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-waarde cases voor verbetering. Waar te verkrijgen Te vinden in de hoofdclaim- of factuurheader-tabel in R1 RCM, vaak genaamd 'TotalBilledBedrag' of vergelijkbaar. Voorbeelden 150.002500.7585.5012000.00 | |||
| Factuurstatus InvoiceStatus | De huidige status van de factuur of claim in de levenscyclus. | ||
| Beschrijving 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 belangrijk 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. Waarom het belangrijk is Biedt een actueel beeld van elke case, belangrijk voor het opstellen van verouderingsrapporten en het analyseren van de uiteindelijke resultaten van verschillende procespaden. Waar te verkrijgen 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. | ||
| Beschrijving 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 onmisbaar voor Revenue Cycle Management. Het kan inzichtelijk maken 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. Waarom het belangrijk is Maakt segmentatie van het proces per betaler mogelijk om betalersspecifieke vertragingen, afwijzingspatronen of betalingsgedrag te vinden, wat belangrijk is voor het optimaliseren van de inkomsten. Waar te verkrijgen Te vinden in de verzekerings- of demografische Informatie van de patiënt, gekoppeld aan de claim in R1 RCM. Voorbeelden MedicareUnitedHealthcareBlue Cross Blue ShieldAetnaZelfbetaler | |||
| Toegewezen Gebruiker AssignedUser | De user ID of naam van de medewerker die de activiteit heeft uitgevoerd. | ||
| Beschrijving 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 analysest die een weigering heeft reworkt, 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. Waarom het belangrijk is Maakt analyse van team- en individuele prestaties, werkbelastingdistributie mogelijk en helpt bij het vinden van trainingsmogelijkheden of gebruikersspecifieke procesafwijkingen. Waar te verkrijgen Doorgaans te vinden als een veld 'GebruikerID', 'Verwerker' of 'UpdatedBy' in transactielogs binnen R1 RCM. Voorbeelden jdoeasmithp.jonesBOT_RPA01 | |||
| Correctiebedrag AdjustmentAmount | De financiële waarde van een correctie die is uitgevoerd op het rekeningsaldo. | ||
| Beschrijving 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 belangrijk 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 vinden. Waarom het belangrijk is Kwantificeert omzetverlies en financiële correcties, en helpt de financiële impact van facturatieonvolkomenheden, contractuele verplichtingen of oninbare vorderingen vast te stellen. Waar te verkrijgen 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. | ||
| Beschrijving 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 vinden 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 vinden om de cashflow te verbeteren. Waarom het belangrijk is 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. Waar te verkrijgen 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. | ||
| Beschrijving 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 belangrijk voor het ewaarderen van de effectiviteit van het betalingsproces. 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. Waarom het belangrijk is Meet de effectiviteit van het betalingsproces door de uiteindelijke oplossing van achterstallige rekeningen te volgen, wat helpt bij het optimaliseren van incassostrategieën. Waar te verkrijgen 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. | ||
| Beschrijving 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 belangrijk 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 vinden van nieuwe automatiseringsmogelijkheden en het meten van de ROI van bestaande bots. Waarom het belangrijk is Onderscheidt tussen menselijke en systeemgestuurde activiteiten, wat belangrijk is voor het meten van de impact van automatisering op procesefficiëntie, kosten en kwaliteit. Waar te verkrijgen Dit kan worden afgeleid uit het veld 'AssignedGebruiker', 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 reworkingslus, zoals het opnieuw indienen van een afgewezen claim. | ||
| Beschrijving 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 vinden van rework is een van de krachtigste mogelijkheden van process mining. Het kwantificeert de hoeveelheid verspilde inspanning, tijd en middelen in een proces. Door rework te markeren, kunnen organisaties hun verbeteringsinspanningen richten op het voorkomen van de fouten die het veroorzaken, wat leidt tot aanzienlijke efficiëntiewinst. Waarom het belangrijk is Helpt de frequentie en impact van rework te kwantificeren, zoals claimafwijzingen, waardoor gerichte analyse mogelijk is om inefficiënties en verspilde inspanning te verminderen. Waar te verkrijgen 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 ID voor de patiënt die de dienst heeft ontvangen. | ||
| Beschrijving 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. Waarom het belangrijk is Maakt analyse van billing gebeurtenissen op patiëntniveau mogelijk, wat helpt bij het vinden van terugkerende problemen of patronen voor specifieke patiënten over meerdere contactmomenten. Waar te verkrijgen 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'. | ||
| Beschrijving 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 correcpakketedenen helpt bij het diagnosticeren van de grondoorzaken van omzetverlies. Een hoge frequentie van 'Afschrijving klein saldo' kan bijvoorbeeld duiden op een inefficiënt betalingsproces voor kleine bedragen, terwijl frequente 'Contractuele kortingen' een verwacht onderdeel zijn van onderhandelingen met betalers. Deze analyse ondersteunt het dashboard voor Factuurcorrecties & Compliance Audit. Waarom het belangrijk is Verklaart het 'waarom' achter inkomsten aanpassingen, wat helpt bij het vinden van de diepere oorzaken van inkomstenverlies, zoals contractuele problemen, factureringsfouten of incassofalen. Waar te verkrijgen Dit is doorgaans een code- of tekstveld in hetzelfde transacpakketecord als het Correctiebedrag in R1 RCM. Voorbeelden Contractuele KortingAfschrijving dubieuze debiteurenAfschrijving klein bedragCorrectie Facturatiefout | |||
| Service Code ServiceCode | De facturatiecode voor de specifieke geleverde dienst of procedure, zoals een CPT- of HCPCS-code. | ||
| Beschrijving 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 belangrijk voor het vinden van facturatieproblemen gerelateerd aan specifieke zorgtypes. Het kan inzichtelijk maken welke procedures het vaakst worden geweigerd, de langste betalingscycli hebben, of het meeste rework vereisen, wat gerichte verbeteringen in codeer- en facturatiepraktijken mogelijk maakt. Waarom het belangrijk is Maakt procesanalyse mogelijk op basis van het type geleverde dienst, wat belangrijk is voor het vinden van afwijzingspatronen of betalingsvertragingen in verband met specifieke procedures. Waar te verkrijgen Deze Informatie is te vinden op postniveau voor elke kostenpost of claim binnen R1 RCM. Voorbeelden 992139928573560 | |||
Revenue Cycle Management Activiteiten
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Account Afgesloten | 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. | ||
| Waarom het belangrijk is 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. Waar te verkrijgen 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 | |||
| 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. | ||
| Waarom het belangrijk is 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. Waar te verkrijgen 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 gebeurtenis markeert de ontvangst van gelden, maar de gelden zijn nog niet toegepast op de specifieke rekening of servicecomponenten. | ||
| Waarom het belangrijk is Vertegenwoordigt de instroom van contanten. Het tijdsverschil tussen 'Betaling ontvangen' en 'Betaling geboekt' is een belangrijke meting voor het begrijpen van de backoffice-efficiëntie en vertragingen in kasafstemming. Waar te verkrijgen Geregistreerd uit elektronische betalingsbestanden van betalers of uit de verwerking van patiëntbetalingen. De gebeurtenis 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 | |||
| Charges Vastgelegd | Deze activiteit staat voor de formele registratie van alle factureerbare diensten, procedures en benodigdheden voor een patiëntcontact. Het is een belangrijke stap in gegevensinvoer die klinische activiteiten vertaalt naar financiële transacties. | ||
| Waarom het belangrijk is 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 vinden van achterstanden bij kostenregistratie. Waar te verkrijgen Geregistreerd binnen de charge entry module van R1 RCM of ontvangen via een interface van een EHR. De gebeurtenis wordt doorgaans gemarkeerd door een specifieke transactielog of de aanmaak-timestamp van de kostenpost. Vastleggen Geïdentificeerd door de aanmaak-timestamp van het kosten-transacpakketecord in de facturatietabel. 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. | ||
| Waarom het belangrijk is Een belangrijke 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. Waar te verkrijgen 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. | ||
| Waarom het belangrijk is 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 vinden. Waar te verkrijgen 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 | |||
| Account Geclassificeerd als Oninbare Schuld | Alle incassopogingen zijn uitgeput en het resterende rekeningsaldo wordt als oninbaar beschouwd. Het saldo wordt afgeschreven als dubieuze debiteur, wat een definitief omzetverlies betekent. | ||
| Waarom het belangrijk is 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 inzichtelijk maken. Waar te verkrijgen 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 | |||
| Accountaanpassing Uitgevoerd | 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. | ||
| Waarom het belangrijk is Hoge volumes aan aanpassingen kunnen wijzen op problemen met tariefschema's, contractbeheer of factureringsfouten. Het volgen van aanpassingen is belangrijk voor het analyseren van de omzetintegriteit. Waar te verkrijgen 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 | |||
| 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. | ||
| Waarom het belangrijk is 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. Waar te verkrijgen 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 rework- en beroepsproces wordt geïnitieerd. | ||
| Waarom het belangrijk is Deze activiteit benadrukt omzetverlies en procesinefficiëntie. Het analyseren van weigeringsredenen is belangrijk voor het vinden van grondoorzaken en het verbeteren van de acceptatiegraad van claims bij de eerste indiening. Waar te verkrijgen 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 | |||
| Herstel Afwijzing 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. | ||
| Waarom het belangrijk is Volgt het begin van de kostbare reworkingslus voor geweigerde claims. Het meten van de tijd die in deze fase wordt besteed, is belangrijk om de efficiëntie van het weigeringsbeheerteam te begrijpen. Waar te verkrijgen 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 | |||
| 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. | ||
| Waarom het belangrijk is Markeert het begin van het kostenintensieve betalingsproces. Het analyseren van de effectiviteit en doorlooptijd van deze activiteiten helpt de strategieën voor het innen van dubieuze debiteuren te optimaliseren. Waar te verkrijgen 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ëntenoverzicht Gecreëerd | 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. | ||
| Waarom het belangrijk is 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. Waar te verkrijgen 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 | |||
| Toewijzing Betaler Ontvangen | Het systeem ontvangt een reactie van de betaler voor de ingediende claim, vaak in een Electronic Remittance Advice (ERA)-bestand. Deze reactie specificeert wat betaald, geweigerd of gecorrigeerd werd. | ||
| Waarom het belangrijk is Deze gebeurtenis is een belangrijk 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. Waar te verkrijgen Geregistreerd wanneer een elektronisch betalingsbestand, zoals een ANSI 835-bestand, van de betaler wordt verwerkt door R1 RCM. De gebeurtenis 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 | |||
Extractiegidsen
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 je in staat de specifieke datavelden 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 gebeurtenissen 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 attributen:
BillingEvent,ActiviteitNaam,EventTime,BronsysteemenLastDataUpdate. - Verifieer dat de datum- en tijdformaten in de
EventTimeenLastDataUpdatekolommen consistent zijn voordat u het bestand uploadt naar ProcessMind.
Configuratie
- Verplichten: 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 belangrijk 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 dataverversingen 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;