Datatemplate voor revenue cycle management
Datatemplate voor revenue cycle management
- Aanbevolen attributen om te verzamelen
- Belangrijke activiteiten om te volgen
- Aanwijzingen voor data-extractie
Attributen voor revenue cycle management
| Naam | Beschrijving | ||
|---|---|---|---|
| Activiteitsnaam ActivityName | De naam van de specifieke gebeurtenis of taak binnen het proces voor omzetcyclusbeheer. | ||
| Beschrijving Dit attribuut beschrijft één stap in de omzetcyclus, zoals ‘Declarabele diensten geregistreerd’, ‘Claim ingediend bij betaler’ of ‘Betaling ontvangen’. Elke activiteit is een afzonderlijke mijlpaal in het factureren van een dienst en het innen van de betaling. Activiteiten analyseren is de basis van process mining. Je kunt er de proceskaart mee visualiseren, veelvoorkomende routes herkennen, bottlenecks tussen stappen opsporen en meten of het proces aan de standaardprocedures voldoet. Waarom dit belangrijk is Dit attribuut beschrijft de stappen op de proceskaart, zodat je het werk in de omzetcyclus kunt visualiseren, analyseren en verbeteren. Waar vind je dit? Dit wordt meestal afgeleid uit event logs, auditsporen of statuswijzigingen in de facturerings- en claimmodules van Epic Resolute. Voorbeelden Declarabele diensten geregistreerdClaim ingediend bij betalerBetaling ontvangenRekening afgesloten | |||
| Factureringsevent BillingEvent | De unieke identificatiecode voor één geleverde dienst of één geleverd product waarvoor kosten in rekening worden gebracht. Dit is de primaire case-ID. | ||
| Beschrijving Het factureringsevent is de belangrijkste identificatiecode die alle activiteiten in de omzetcyclus voor een specifiek factureerbaar item met elkaar verbindt. Het begint wanneer een dienst wordt verleend en eindigt wanneer de rekening volledig is betaald of afgesloten. Bij process mining is dit attribuut essentieel om het volledige verloop van elke kostenpost te reconstrueren. Je kunt activiteiten volgen zoals het registreren van declarabele diensten, het indienen van claims, het boeken van betalingen en het afhandelen van afwijzingen. Zo krijg je een helder beeld van het procesverloop en de varianten. Waarom dit belangrijk is Dit is de primaire Case-ID. Deze is nodig om alle bijbehorende processtappen te koppelen en de volledige levenscyclus van omzet en inning voor elke dienst te analyseren. Waar vind je dit? Dit is vaak een unieke identificatiecode voor een ziekenhuisrekening (HAR) of een specifieke sessie voor kostenregistratie in Epic Resolute. Raadpleeg de documentatie van Epic Resolute voor specifieke tabellen, zoals HAR- of Charge Session-records. Voorbeelden BE10098765BE20012345BE30054321 | |||
| Timestamp van gebeurtenis EventTimestamp | De exacte datum en tijd waarop een specifieke activiteit of gebeurtenis plaatsvond. | ||
| Beschrijving De timestamp van de gebeurtenis legt vast wanneer een activiteit plaatsvond. Deze tijdsgegevens zijn belangrijk om de timing en volgorde van gebeurtenissen in de omzetcyclus te begrijpen. Bij analyses gebruik je timestamps om de tijd tussen activiteiten te berekenen, zoals de vertraging bij het registreren van declarabele diensten of de verwerkingstijd van betalingen. Zo kun je bottlenecks opsporen, doorlooptijden meten en procesprestaties over verschillende perioden analyseren. Nauwkeurige timestamps zijn essentieel voor vrijwel alle tijdgebonden KPI’s en dashboards. Waarom dit belangrijk is Dit attribuut is nodig om alle tijdgebonden metrieken te berekenen, waaronder doorlooptijden en tijdsduur. Daarmee kun je vertragingen en inefficiënties opsporen. Waar vind je dit? Te vinden in transactie- of eventlogtabellen in Epic Resolute, gekoppeld aan elke vastgelegde activiteit. Veldnamen eindigen vaak op Dt, DTTM of Time. Voorbeelden 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Factureringsafdeling BillingDepartment | De afdeling of het functionele team dat verantwoordelijk is voor het factureringsevent of de activiteit. | ||
| Beschrijving Dit attribuut geeft de organisatorische eenheid aan die bij het factureringsevent hoort of een specifieke activiteit heeft uitgevoerd, zoals ‘Facturering klinische opnames’, ‘Facturering poliklinische zorg’ of ‘Team voor claimafwijzingen’. Deze dimensie is belangrijk voor het dashboard met prestatiemetrieken per factureringsafdeling. Je kunt belangrijke metrieken, zoals afwijzingspercentages of registratietijden van declarabele diensten, naast elkaar vergelijken. Zo kan het management goed presterende afdelingen herkennen, goede werkwijzen overnemen en middelen gericht toewijzen. Waarom dit belangrijk is Hiermee kun je prestaties tussen afdelingen vergelijken en goede werkwijzen herkennen. Ook zie je waar verbetering of extra middelen nodig zijn. Waar vind je dit? Deze informatie kan gekoppeld zijn aan de gebruikersregistratie, de patiëntenrekening of de zorglocatie in Epic Resolute. Voorbeelden Facturering cardiologieRCM radiologieCentrale factureringsafdeling | |||
| Openstaand saldo OutstandingBalance | Het resterende bedrag dat de betaler of patiënt voor het factureringsevent moet betalen. | ||
| Beschrijving Dit attribuut geeft het actuele debiteurensaldo voor een specifiek factureringsevent weer op het moment van de activiteit. Het laat de financiële status van de case gedurende de levenscyclus zien. Het openstaande saldo is belangrijk voor financiële rapportages en het ouderdomsoverzicht van openstaande saldi. Door dit bedrag in de tijd en per dimensie, zoals betaler of afdeling, te analyseren, kun je incassoacties prioriteren, de cashflow beheren en financiële risico’s inschatten. Waarom dit belangrijk is Dit attribuut meet rechtstreeks de financiële gevolgen van procesvertragingen. Het is belangrijk om incassoacties te prioriteren, de cashflow te beheren en inzicht te krijgen in debiteuren. Waar vind je dit? Dit is een standaardveld in de patiëntenrekening of ziekenhuisrekening (HAR) in Epic Resolute. Het bevat een lopend saldo dat door financiële transacties wordt bijgewerkt. Voorbeelden 1500.00250.750.00 | |||
| Reden van aanpassing AdjustmentReason | De reden voor een handmatige of automatische aanpassing van het saldo op de rekening van een patiënt. | ||
| Beschrijving Dit attribuut verklaart waarom een rekeningsaldo buiten een standaardbetaling of kostenpost om is gewijzigd. Redenen kunnen contractuele vergoedingen van betalers zijn, het afboeken van een klein saldo of correcties voor boekingsfouten. Dit attribuut is belangrijk voor het dashboard met het aantal rekeningaanpassingen per type. Door de redenen voor aanpassingen te analyseren, kunnen organisaties bronnen van omzetverlies opsporen, de invloed van contracten met betalers begrijpen en mogelijke inefficiënties of fouten in het factureringsproces herkennen. Waarom dit belangrijk is Dit attribuut geeft inzicht in omzetverlies en de nauwkeurigheid van de facturering. Het verklaart waarom rekeningsaldi worden aangepast en helpt onnodige afboekingen te beperken. Waar vind je dit? Te vinden in de transactiedetails van aanpassingen in de patiëntenadministratiemodule van Epic Resolute. Voorbeelden Contractuele vergoedingKlein saldo afgeboektCorrectie dubbele kostenpost | |||
| Redencode afwijzing DenialReasonCode | Een gestandaardiseerde code die aangeeft waarom een betaler een ingediende claim heeft afgewezen. | ||
| Beschrijving Wanneer een betaler een claim afwijst, geeft die een redencode op die de reden verklaart, zoals ‘Dienst niet gedekt’, ‘Dubbele claim’ of ‘Aanvullende informatie vereist’. Deze codes zijn vaak gestandaardiseerd als Claim Adjustment Reason Codes (CARCs). Dit attribuut vormt de basis voor het dashboard met afwijzingspercentages en redenen van claims. Door te analyseren hoe vaak verschillende afwijzingscodes voorkomen, kun je de oorzaken achterhalen, zoals problemen met bevoegdheden, coderingsfouten of ontbrekende voorafgaande goedkeuringen. Zo kun je gericht verbeteringen doorvoeren. Waarom dit belangrijk is Dit attribuut verklaart waarom claims worden afgewezen. Zo krijg je concrete aanknopingspunten om afwijzingspercentages en omzetverlies te beperken en betalingen te versnellen. Waar vind je dit? Deze data staat in de transacties met claimreacties, zoals een ANSI 835-bestand dat je van betalers ontvangt. De data wordt opgeslagen in de claimbeheerfunctie van Epic Resolute. Voorbeelden CO-16: Claim/dienst bevat onvoldoende informatieOA-18: Dubbele claim/dienstPR-96: Niet-gedekte kostenpost(en) | |||
| Type dienst ServiceType | De categorie of het type medische dienst dat is verleend. | ||
| Beschrijving Dit attribuut deelt de factureerbare dienst in, bijvoorbeeld als 'Radiologie', 'Chirurgie', 'Consult' of 'Bezoek aan de spoedeisende hulp'. Het geeft financiële data een klinische context. Door de revenue cycle per type dienst te analyseren, kun je procesverschillen ontdekken die specifiek zijn voor bepaalde klinische afdelingen. Chirurgische ingrepen kunnen bijvoorbeeld complexere eisen stellen aan de registratie van kosten en autorisaties dan een standaard poliklinisch bezoek. Dat leidt tot ander procesgedrag en andere uitdagingen. Waarom dit belangrijk is Geeft financiële data een klinische context, zodat je kunt analyseren hoe verschillende soorten medische diensten de revenue cycle en de efficiëntie ervan beïnvloeden. Waar vind je dit? Afgeleid van de charge description master (CDM), de servicelijn of de afdeling die in Epic aan de kostenboeking is gekoppeld. Voorbeelden Klinische chirurgiePoliklinische radiologieSpoedeisende hulp | |||
| Verantwoordelijke gebruiker ResponsibleUser | De identificatiecode van de gebruiker of medewerker die de activiteit heeft uitgevoerd. | ||
| Beschrijving Dit attribuut bevat de gebruikers-ID, naam of het personeelsnummer van de persoon die verantwoordelijk was voor een specifieke taak in de omzetcyclus. Dat kan de zorgverlener zijn die kosten invoerde, de facturatiemedewerker die een claim indiende of de incassomedewerker die een afwijzing opvolgde. Door activiteiten per gebruiker te analyseren, kun je goed presterende medewerkers herkennen, trainingsbehoeften vaststellen en de werkverdeling begrijpen. Dit is nuttig voor prestatiebeheer en voor onderzoek naar procesafwijkingen die samenhangen met specifieke personen of rollen. Waarom dit belangrijk is Hiermee kun je prestaties per persoon of rol analyseren en kansen voor training, een onevenwichtige werkverdeling en bottlenecks door een tekort aan middelen opsporen. Waar vind je dit? Meestal te vinden in auditsporen of transactielogs in Epic Resolute, vaak gekoppeld aan een tabel met stamgegevens van gebruikers, zoals een EMP-record. Voorbeelden j.doebsmith123User7890 | |||
| Aangepast bedrag AdjustedAmount | De geldwaarde van een correctietransactie. | ||
| Beschrijving Dit veld bevat het specifieke bedrag in dollars van een rekeningcorrectie. De waarde kan positief of negatief zijn en staat voor een bij- of afschrijving op het rekeningsaldo. Dit bedrag is de belangrijkste metriek voor het dashboard 'Volume rekeningcorrecties per type'. Door deze waarde op te tellen per correctiereden, krijg je een helder beeld van de financiële gevolgen van verschillende soorten correcties. Zo zie je hoeveel omzet wordt afgeboekt vanwege contractuele verplichtingen en hoeveel verloren gaat door fouten die te herstellen zijn. Waarom dit belangrijk is Maakt de financiële gevolgen van rekeningcorrecties meetbaar, zodat je omzetverlies en de kosten van onjuiste facturering kunt bepalen. Waar vind je dit? Te vinden in de detailtabellen voor financiële transacties in Epic Resolute, bij transacties van het type correctie. Voorbeelden -1250.45-50.0025.10 | |||
| Bronsysteem SourceSystem | Het informatiesysteem waaruit de data afkomstig is. | ||
| Beschrijving Dit attribuut geeft aan uit welk systeem de registratie komt. In deze context is dat Epic Resolute. Als meerdere systemen zijn gekoppeld, helpt dit veld om de herkomst van data te onderscheiden. In een omgeving met één systeem lijkt dit veld misschien overbodig, maar het is een goede gewoonte voor datagovernance en schaalbaarheid. Zo blijft de herkomst duidelijk als later data uit andere systemen wordt toegevoegd, bijvoorbeeld van een apart incassoplatform. Waarom dit belangrijk is Dit attribuut geeft inzicht in de herkomst en context van de data. Zo is duidelijk waar de data vandaan komt, wat belangrijk is voor datagovernance en het oplossen van problemen. Waar vind je dit? Dit is meestal een vaste waarde die tijdens de data-extractie en -transformatie wordt toegevoegd om de herkomst van de dataset aan te geven. Voorbeelden Epic ResoluteEpicResolute_V2023 | |||
| Claim-ID ClaimId | De unieke identificatiecode van een verzekeringsclaim die bij een betaler is ingediend. | ||
| Beschrijving Dit attribuut is de specifieke ID van het claimformulier, bijvoorbeeld een CMS-1500 of UB-04, dat naar een betaler is gestuurd. Voor één factureringsgebeurtenis kunnen meerdere claims nodig zijn als diensten opnieuw worden gefactureerd of als er bezwaar wordt gemaakt. Met de Claim-ID kun je de indiening van claims en het beheer van afwijzingen in detail analyseren. Zo kun je activiteiten voor de eerste claim onderscheiden van activiteiten voor een later opnieuw ingediende claim voor dezelfde dienst. Waarom dit belangrijk is Biedt een gedetailleerde identificatiecode om het verloop van elke afzonderlijke claim te volgen. Dat is belangrijk voor de analyse van opnieuw ingediende claims en bezwaren. Waar vind je dit? Wordt aangemaakt door de module voor claimbeheer van Epic Resolute wanneer een claim wordt gemaakt. De ID wordt opgeslagen in de claimdatatabellen. Voorbeelden CLM-2023-98765CLAIM-0012345623189A4567 | |||
| Eindtijd gebeurtenis EventEndTime | De timestamp die aangeeft wanneer een activiteit is afgerond. Hiermee kun je de duur van een activiteit berekenen. | ||
| Beschrijving Dit attribuut registreert het tijdstip waarop een activiteit is afgerond. Veel activiteiten zijn gebeurtenissen zonder duur, waarbij StartTime gelijk is aan EndTime. Sommige taken hebben wel een meetbare duur, zoals een telefoontje om een afgewezen claim op te volgen. Als EndTime beschikbaar is, kun je de verwerkingstijd van een activiteit rechtstreeks berekenen ('EndTime' - 'StartTime'). Dat is nauwkeuriger dan de duur afleiden uit de starttijd van de volgende activiteit, omdat ook de wachttijd tussen stappen wordt meegenomen. EndTime is een belangrijk onderdeel van de berekening van het attribuut 'ProcessingTime'. Waarom dit belangrijk is Maakt het mogelijk om nauwkeurig te berekenen hoelang elke activiteit duurt. Zo kun je inefficiënte taken opsporen en de productiviteit van medewerkers meten. Waar vind je dit? Deze informatie is mogelijk beschikbaar in sommige Epic Resolute-modules die de start en het einde van taken registreren, zoals logs voor werklijsten of activiteitenbeheer. Vaak wordt dit niet expliciet bijgehouden. Voorbeelden 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| Is geautomatiseerd IsAutomated | Een booleaanse vlag die aangeeft of de activiteit door een systeem of geautomatiseerd proces is uitgevoerd. | ||
| Beschrijving Deze vlag maakt onderscheid tussen taken die automatisch door het systeem worden uitgevoerd, zoals het automatisch aanmaken van claims of controleren van de verzekeringsdekking, en taken die een gebruiker handmatig uitvoert. Met dit attribuut kun je het automatiseringsniveau van het proces bepalen. Je kunt de efficiëntie en foutpercentages van geautomatiseerde en handmatige activiteiten vergelijken, mogelijkheden voor verdere automatisering opsporen en de prestaties van bestaande bots of systeemregels volgen. Waarom dit belangrijk is Maakt onderscheid tussen activiteiten die door het systeem en door medewerkers worden uitgevoerd. Dat is belangrijk om het effect van automatisering te beoordelen en nieuwe mogelijkheden voor automatisering te vinden. Waar vind je dit? Dit wordt vaak afgeleid door te controleren of de 'ResponsibleUser' van een activiteit een systeem- of serviceaccount is, of door specifieke activiteiten waarvan bekend is dat ze geautomatiseerd zijn als zodanig te markeren. Voorbeelden truefalse | |||
| Laatste data-update LastDataUpdate | De timestamp die aangeeft wanneer de data voor deze gebeurtenis voor het laatst is vernieuwd of uit het bronsysteem is opgehaald. | ||
| Beschrijving Dit attribuut geeft aan hoe actueel de data is. Het laat zien wanneer de registratie voor het laatst uit Epic Resolute is opgehaald en aan de process mining-dataset is toegevoegd. Dit is belangrijk om te weten hoe actueel de analyse is en om de data te controleren. Zo zie je of je naar de meest recente beschikbare informatie kijkt. Het attribuut is ook belangrijk voor het beheren van vernieuwingscycli van data. Waarom dit belangrijk is Zo weten gebruikers hoe actueel de data is die ze analyseren. Dat is belangrijk om zakelijke beslissingen te nemen op basis van juiste, actuele informatie. Waar vind je dit? Deze timestamp wordt tijdens het laden van de data toegevoegd door het ETL-proces (Extract, Transform, Load). Voorbeelden 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| Naam betaler PayerName | De naam van de verzekeraar, overheidsinstantie of andere partij die verantwoordelijk is voor de betaling. | ||
| Beschrijving Dit attribuut geeft aan wie de primaire betaler voor het factureringsevent is, zoals ‘Blue Cross Blue Shield’, ‘Medicare’ of ‘Aetna’. Bij zelfbetaling kan dit de patiënt zijn. Door het proces per betaler op te splitsen, kun je zien of bepaalde betalers vaker claims afwijzen, langer over betalingen doen of ingewikkeldere eisen stellen. Met die informatie kun je de factureringsaanpak per betaler aanpassen en betalingen sneller en efficiënter verwerken. Waarom dit belangrijk is Hiermee kun je prestaties per betaler analyseren en zien bij welke betalers afwijzingen vaak voorkomen of betalingen lang op zich laten wachten. Zo kun je de opvolging gericht aanpakken. Waar vind je dit? Deze informatie maakt deel uit van de dekkingsgegevens van de patiënt en is gekoppeld aan de ziekenhuisrekening (HAR) in Epic Resolute. Voorbeelden Medicare Part BUnitedHealthcareAetna PPO | |||
| Patiënt-ID PatientId | De unieke identificatiecode van de patiënt die de dienst ontvangt. | ||
| Beschrijving Dit attribuut is het medisch dossiernummer (MRN) of een andere unieke identificatiecode van de patiënt. Het koppelt de financiële factureringsgebeurtenis aan een specifieke persoon. Om de privacy van patiënten te beschermen, wordt dit attribuut meestal niet gebruikt als primaire analysedimensie. Het is wel nodig om data te valideren en kan worden gebruikt om alle factureringsgebeurtenissen van één patiënt samen te voegen. Zo krijg je inzicht in het volledige financiële traject van die patiënt. Het attribuut is ook belangrijk voor een eventuele koppeling met klinische procesdata. Waarom dit belangrijk is Koppelt financiële data aan een specifieke patiënt. Zo kun je data valideren en eventueel het volledige traject van een patiënt analyseren. Vanwege privacyrisico’s moet je zorgvuldig met deze gegevens omgaan. Waar vind je dit? Een basisidentificatiecode die in heel Epic voorkomt en is gekoppeld aan de registratie- en rekeninggegevens van de patiënt. Voorbeelden MRN-1234567MRN-8765432MRN-5551234 | |||
| Totale doorlooptijd van de revenue cycle TotalRevenueCycleTime | De totale berekende tijd vanaf de eerste dienstgebeurtenis tot de laatste betaling of het sluiten van de rekening. | ||
| Beschrijving Dit is een KPI op caseniveau die de totale doorlooptijd van de revenue cycle voor één factureringsgebeurtenis meet. Meestal wordt deze berekend als het tijdsverschil tussen de activiteit 'Dienst verleend' en de laatste activiteit 'Betaling ontvangen' of 'Rekening gesloten'. Deze overkoepelende metriek geeft een volledig beeld van de efficiëntie van het RCM-proces. Door de KPI in de tijd te volgen, kun je het effect van procesverbeteringen meten. De KPI geeft ook aan hoe snel diensten in geld worden omgezet. Waarom dit belangrijk is Geeft een totaalbeeld van de procesefficiëntie en meet rechtstreeks hoelang het duurt om een dienst in geld om te zetten. Waar vind je dit? Deze metriek wordt berekend in de process mining-tool. Per case worden de eerste en laatste gebeurtenissen geselecteerd en wordt het tijdsverschil bepaald. Voorbeelden 259200038880005184000 | |||
| Uiterste betaaldatum PaymentDueDate | De datum waarop de betaling voor de gefactureerde dienst uiterlijk wordt verwacht. | ||
| Beschrijving Dit attribuut geeft de uiterste betaaldatum aan, zoals vermeld op de factuur of bepaald in contracten met betalers. De datum dient als referentie om tijdige betalingen te meten. De uiterste betaaldatum is nodig voor het rapport 'Ouderdomsanalyse openstaand saldo'. Door de huidige datum te vergelijken met de uiterste betaaldatum van openstaande bedragen, kun je debiteuren indelen in ouderdomscategorieën, bijvoorbeeld 0-30 dagen en 31-60 dagen achterstallig. Zo kun je de incasso van de meest achterstallige rekeningen voorrang geven. Waarom dit belangrijk is Vormt de basis voor de ouderdomsanalyse van debiteuren. Die analyse is belangrijk om incasso’s te prioriteren en het financiële risico van onbetaalde facturen te beheersen. Waar vind je dit? Deze datum wordt vaak berekend op basis van de factuurdatum en de betalingsvoorwaarden in het contract met de betaler of de patiëntgegevens in Epic. Voorbeelden 2023-05-302023-06-152023-07-01 | |||
Activiteiten voor revenue cycle management
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Betaling ontvangen | Dit is het moment waarop een betaling van een betaler of patiënt binnenkomt. Dit wordt meestal vastgelegd wanneer een elektronisch betalingsbericht (ERA) wordt geladen of een handmatige cheque in het systeem wordt ingevoerd. | ||
| Waarom dit belangrijk is Deze activiteit is een belangrijke mijlpaal: er komt omzet binnen. De tijd tussen het indienen van de claim en het ontvangen van de betaling is een belangrijke maatstaf voor de prestaties van debiteurenbeheer. Waar vind je dit? Dit wordt expliciet als betalingstransactie vastgelegd in Resolute. De transacties bevatten een datum, bron en bedrag en worden vaak geregistreerd voordat ze volledig aan afzonderlijke kostenposten zijn toegewezen. Vastleggen Haal betalingstransacties op uit het financiële transactielogboek. Je herkent ze vaak aan specifieke transactietypen. Gebeurtenistype explicit | |||
| Betaling op rekening geboekt | Dit is het moment waarop een ontvangen betaling wordt toegewezen aan specifieke kostenposten op de rekening van de patiënt. Hierdoor daalt het openstaande saldo van het factureringsevent. | ||
| Waarom dit belangrijk is Een efficiënte betalingsverwerking is belangrijk voor correcte rekeningsaldi en een goede afronding van factureringsevents. Zo kun je resterende bedragen correct vaststellen voor aanvullende facturering of incasso. Waar vind je dit? Dit is een expliciete transactie in Resolute. Bij het boeken van een betaling wordt een betalingstransactie gekoppeld aan een of meer transacties van kostenposten. Dit wordt vastgelegd in de transactiedetailtabellen. Vastleggen Leg de transactieregel vast waarmee een betaling aan een kostenpost wordt toegewezen. Je kunt deze herkennen aan specifieke transactietypen. Gebeurtenistype explicit | |||
| Claim afgewezen door betaler | Dit is het moment waarop de betaler laat weten dat de claim is afgewezen. Dit wordt vastgelegd wanneer Epic een elektronisch betalingsbericht (835-bestand) verwerkt of wanneer een gebruiker een afwijzing handmatig boekt. | ||
| Waarom dit belangrijk is Deze activiteit start een belangrijke herstelronde. Door de redenen en aantallen afwijzingen te analyseren, kun je de oorzaken achterhalen, het percentage betalingen bij de eerste indiening verbeteren en vertragingen bij het innen beperken. Waar vind je dit? Dit wordt expliciet vastgelegd als transactie of statusupdate van de claim. Informatie over de afwijzing, waaronder redenencodes, wordt meestal elektronisch ontvangen en op de rekening geboekt. Vastleggen Filter op specifieke transactietypen of claimstatusupdates die op een afwijzing wijzen. Gebeurtenistype explicit | |||
| Claim ingediend bij betaler | Dit is het moment waarop de claim officieel naar de verzekeraar wordt gestuurd voor beoordeling. In Epic wordt dit bijgehouden en vastgelegd wanneer het elektronische claimbestand naar het clearinghouse of de betaler wordt verzonden. | ||
| Waarom dit belangrijk is Deze mijlpaal is belangrijk omdat vanaf dit moment de betalingstermijn van de betaler begint. Door dit te analyseren, meet je hoe efficiënt claims worden verzonden en kun je de KPI voor de levertijd van factuur aan betaler volgen. Waar vind je dit? Dit is een expliciet vastgelegde gebeurtenis in Resolute. De claim bevat een indieningsstatus en een timestamp die aangeeft wanneer de claim is verzonden. Vastleggen Leg de timestamp vast waarop de claimstatus verandert in ‘Submitted’ of ‘Transmitted’. Gebeurtenistype explicit | |||
| Declarabele diensten geregistreerd | Dit is de formele registratie van de kosten voor verleende diensten. In Epic is dit meestal een expliciete transactie op de rekening van de patiënt. De transactie wordt vaak automatisch aangemaakt op basis van klinische handelingen of handmatig ingevoerd. | ||
| Waarom dit belangrijk is Dit is een belangrijke eerste mijlpaal. Door de snelheid en nauwkeurigheid van de registratie te meten, kun je de facturering versnellen en controleren of alle verleende diensten in rekening worden gebracht. Waar vind je dit? Dit wordt expliciet vastgelegd in de transactielogs van Resolute. Elke kostenpost is een afzonderlijke regel met een boekingsdatum, servicedatum en bedrag. Deze gegevens staan vaak in tabellen zoals ARPB_TRANSACTIONS. Vastleggen Haal de boekingstransacties van kostenposten op uit het financiële transactielogboek van het systeem. Gebeurtenistype explicit | |||
| Dienst verleend | Deze activiteit markeert het moment waarop een klinische dienst aan de patiënt wordt verleend en het factureringsevent begint. Dit wordt vaak vastgelegd in het Epic EHR (EpicCare) wanneer een zorgverlener een bezoek of ingreep afrondt. | ||
| Waarom dit belangrijk is Dit is de belangrijkste startgebeurtenis van de omzetcyclus. De tijd tussen dit moment en de registratie van declarabele diensten is belangrijk om vertragingen bij de start van de facturering en mogelijk omzetverlies op te sporen. Waar vind je dit? Deze gebeurtenis wordt meestal afgeleid van service- of bezoektimestamps in de klinische modules die aan de factureringsrekening zijn gekoppeld. De servicedatum bij de factureringstransactie is het belangrijkste datapunt. Vastleggen Afgeleid van de servicedatum bij de eerste factureringstransactie voor het factureringsevent. Gebeurtenistype inferred | |||
| Rekening afgesloten | Dit is de laatste activiteit. Het openstaande saldo van het factureringsevent is dan nul en er staan geen activiteiten meer open. Dit kan komen door volledige betaling, aanpassingen of een afboeking. | ||
| Waarom dit belangrijk is Deze gebeurtenis markeert de succesvolle afronding van de omzetcyclus voor een factureringsevent. De totale tijd van dienstverlening tot afsluiting is een belangrijke KPI voor de efficiëntie van het proces. Waar vind je dit? Dit is meestal een afgeleide gebeurtenis. Je bepaalt het moment waarop het rekeningsaldo voor het factureringsevent nul wordt en nul blijft. Vastleggen Leid dit af door het lopende rekeningsaldo te berekenen en de timestamp te bepalen van de laatste transactie waardoor het saldo nul werd. Gebeurtenistype inferred | |||
| Claim aangemaakt | Deze activiteit geeft aan dat het systeem op basis van de geregistreerde kosten een formele claim of factuur heeft aangemaakt. Dit is een voorbereidende stap voordat de claim naar de betaler of patiënt wordt verstuurd. | ||
| Waarom dit belangrijk is Door het aanmaken van claims te volgen, zie je waar vertraging ontstaat tussen het registreren van kosten en het klaarmaken van claims voor indiening. Dit is een belangrijke interne stap die invloed heeft op de totale snelheid van de facturering. Waar vind je dit? Dit wordt meestal vastgelegd wanneer een batchtaak voor het aanmaken van facturen of claims wordt uitgevoerd. Het systeem registreert een timestamp wanneer het claimbestand, bijvoorbeeld een 837-bestand, voor een rekening wordt aangemaakt. Vastleggen Zoek naar logboekregels of statuswijzigingen die aangeven dat de claim is samengesteld en klaar is om te worden ingediend. Gebeurtenistype explicit | |||
| Claim opnieuw ingediend | Deze gebeurtenis vindt plaats nadat een afgewezen claim is gecorrigeerd en opnieuw naar de betaler wordt gestuurd. Het is een afzonderlijke indiening die aan de oorspronkelijke claim is gekoppeld. | ||
| Waarom dit belangrijk is Dit is een belangrijk onderdeel van de herstelronde. Door de tijd tot herindiening en het slagingspercentage van opnieuw ingediende claims te meten, krijg je inzicht in de effectiviteit van de afhandeling van afwijzingen. Waar vind je dit? Dit is een expliciete gebeurtenis, vergelijkbaar met de eerste indiening, maar vaak gemarkeerd als herindiening. De claim bevat een nieuwe indieningstimestamp en mogelijk een code voor herindiening. Vastleggen Leg de timestamp vast van een claimindiening die als correctie of herindiening is gemarkeerd. Gebeurtenistype explicit | |||
| Opvolging van afwijzing gestart | Deze activiteit markeert het begin van het interne proces om een afgewezen claim te beoordelen en op te lossen. Dit wordt vaak vastgelegd wanneer een gebruiker de claim in een werkvoorraad oppakt of de status ervan wijzigt. | ||
| Waarom dit belangrijk is Door dit te volgen, meet je hoe snel het team voor claimafwijzingen reageert. Vertraging tussen een afwijzing en de start van de opvolging kan de omzetcyclus onnodig verlengen. Waar vind je dit? Dit wordt meestal afgeleid van wijzigingen in de claimstatus of toewijzingsgeschiedenis in de werkvoorraden van Epic. De status van de claim kan bijvoorbeeld veranderen van ‘Denied’ in ‘In Review’. Vastleggen Leid dit af uit een wijziging van de claimstatus of een auditspoor waaruit blijkt dat een gebruiker de afwijzing in behandeling heeft genomen. Gebeurtenistype inferred | |||
| Rekening aangepast | Deze activiteit is een transactie die geen betaling is, maar wel het rekeningsaldo wijzigt. Denk aan een contractuele correctie, het afboeken van een klein saldo of een korting uit coulance. Dit wordt vastgelegd als een specifiek transactietype. | ||
| Waarom dit belangrijk is Door aanpassingen te analyseren, kun je omzetverlies opsporen. Veel aanpassingen van een bepaald type kunnen wijzen op problemen met tarieflijsten, contracten of intern beleid. Waar vind je dit? Dit wordt expliciet vastgelegd als aanpassingstransactie in de financiële logs van Resolute. Elke aanpassing heeft een specifiek type of een redenencode. Vastleggen Filter op transactietypen die horen bij financiële aanpassingen of afboekingen. Gebeurtenistype explicit | |||
| Saldo overgedragen aan incasso | Dit markeert het moment waarop een onbetaald rekeningsaldo wordt overgedragen aan een intern of extern incassoproces. Dit is vaak een expliciete statuswijziging van de rekening of het factureringsevent. | ||
| Waarom dit belangrijk is Met deze activiteit begint de laatste fase van het innen van openstaande bedragen. Door het slagingspercentage en de doorlooptijd van het incassoproces te volgen, kun je oninbare schulden beperken. Waar vind je dit? Dit is meestal een expliciete gebeurtenis. Epic heeft functies om rekeningen over te dragen aan incassobureaus. Daarbij wordt een logboekregel of statuswijziging op de rekening vastgelegd. Vastleggen Zoek naar de statuswijziging of transactie die aangeeft dat een rekening bij een incassobureau is ondergebracht. Gebeurtenistype explicit | |||
Extractiegidsen
Stappen
- Databaseverbinding instellen: Vraag inloggegevens met alleen-lezenrechten aan voor de Epic Clarity-database. Maak met een standaard SQL-client, zoals DBeaver of Microsoft SQL Server Management Studio, verbinding met de databaseserver.
- Belangrijkste tabellen bepalen: Voor deze extractie zijn de belangrijkste tabellen
HSP_ACCOUNTvoor casegegevens,HSP_TRANSACTIONSvoor financiële gebeurtenissen,CLP_CLAIM_INFOvoor de claimstatus enF_ARHB_TX_SET_POST_HXvoor betalingsboekingen. Koppel ook masterbestanden, zoalsCLARITY_EMPvoor gebruikersgegevens. - De scope bepalen: Bepaal de scope van de analyse voordat je de query schrijft. Stel een specifieke periode vast, meestal 3 tot 6 maanden, en bepaal welke ziekenhuisservicegebieden (
SERV_AREA_ID) of rekeningklassen je wilt opnemen of uitsluiten. - De SQL-query opstellen: Stel een SQL-query op met een Common Table Expression (CTE). Selecteer daarin eerst de waarden voor
HSP_ACCOUNT_IDdie binnen de gekozen scope vallen. Dit vormt de basispopulatie van factureringsgebeurtenissen. - Query’s voor afzonderlijke activiteiten samenvoegen: Schrijf voor elk van de 12 vereiste activiteiten een aparte
SELECT-instructie die data uit de relevante tabellen ophaalt. Koppel deze aan de oorspronkelijke CTE, zodat je alleen de bedoelde rekeningen analyseert. - Query’s combineren met UNION ALL: Gebruik de operator
UNION ALLom de resultaten van alle afzonderlijke query’s samen te voegen tot één event log. De rijen uit elke query worden zo onder elkaar geplaatst. - De standaardstructuur toepassen: Geef de kolommen in elke
SELECT-instructie aliassen die overeenkomen met het vereiste ProcessMind-schema, zoalsBillingEvent,ActivityNameenEventTimestamp. GebruikNULLvoor attributen die niet van toepassing zijn op een specifieke activiteit. - De query uitvoeren en verfijnen: Voer de volledige query uit op de Clarity-database. Door de omvang van de tabellen kan dit veel tijd kosten. Beperk bij prestatieproblemen de periode verder of voeg specifiekere filters toe aan de eerste CTE.
- De uitvoer controleren: Bekijk na afloop de eerste paar honderd rijen. Controleer of alle kolommen aanwezig zijn, timestamps hetzelfde formaat hebben en de verschillende waarden voor
ActivityNamenaar verwachting voorkomen. - Exporteren naar CSV: Exporteer de volledige resultatenset vanuit je SQL-client naar een CSV-bestand. Gebruik UTF-8-codering en voeg een kopregel met de juiste kolomnamen toe.
- Klaarmaken voor upload: Open het CSV-bestand voordat je het naar ProcessMind uploadt en controleer op opmaakfouten. Controleer of de timestamps hetzelfde formaat hebben, bijvoorbeeld
YYYY-MM-DD HH:MI:SS. Het bestand is nu klaar om te worden ingelezen.
Configuratie
- Databaseverbinding: Je hebt een gebruikersaccount met alleen-lezenrechten voor de Epic Clarity-database nodig.
- Parameters voor de periode: De query gebruikt de variabelen
@StartDateen@EndDate. Stel deze in om de analyseperiode te bepalen. Een periode van 3 tot 6 maanden is aan te raden als balans tussen de hoeveelheid data en de prestaties. - Tabellen en kolommen toewijzen: De query gaat uit van de standaardnamen voor Clarity-tabellen en -kolommen. De Epic-configuratie of -versie van je organisatie kan hiervan afwijken. Mogelijk moet je tabelnamen, kolomnamen of koppelvoorwaarden aanpassen.
- Transactie- en statuscodes: De query bevat tijdelijke aanduidingen zoals
[Your Denial Tx Type]en[Your Collections Status Code]. Raadpleeg de Epic-systeembeheerders of bekijk de relevante masterbestanden, zoalsZC_TX_TYPEofZC_ACCOUNT_STATUS, om de juiste codes voor jouw omgeving te vinden. - Filteren: Voeg filters toe aan de eerste CTE
BaseAccountsvoor betere prestaties en een gerichtere analyse. Veelgebruikte filters zijnSERV_AREA_IDom het ziekenhuisservicegebied te beperken enACCOUNT_CLASS_Com de facturering voor klinische of poliklinische zorg te selecteren.
a Voorbeeldquery sql
DECLARE @StartDate DATE = '2023-01-01';
DECLARE @EndDate DATE = '2023-06-30';
WITH BaseAccounts AS (
SELECT DISTINCT
HA.HSP_ACCOUNT_ID
FROM
HSP_ACCOUNT HA
WHERE
HA.ADM_DATE_TIME >= @StartDate
AND HA.ADM_DATE_TIME <= @EndDate
-- Add additional filters here if needed, for example:
-- AND HA.SERV_AREA_ID = [Your Service Area ID]
)
-- 1. Service Rendered
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Service Rendered' AS ActivityName,
tx.SERVICE_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
AND tx.ORIG_REV_TX_ID IS NULL -- Not a reversal
UNION ALL
-- 2. Charges Captured
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Charges Captured' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
UNION ALL
-- 3. Claim Generated
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Generated' AS ActivityName,
claim.GENERATED_TIME AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.GENERATED_TIME IS NOT NULL
UNION ALL
-- 4. Claim Submitted to Payer
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
claim.XMIT_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.XMIT_DATE IS NOT NULL
UNION ALL
-- 5. Claim Denied by Payer
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
remit.REMIT_CODE_ID AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN F_ARHB_TX_SET_POST_HX remit ON tx.TX_ID = remit.TX_ID
WHERE tx.TX_TYPE_C IN ([Your Denial Tx Type]) -- Placeholder for denial transaction type codes
UNION ALL
-- 6. Denial Follow-Up Initiated (assumes status change on account)
SELECT
hist.HSP_ACCOUNT_ID AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
NULL AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCT_STATUS_HX hist
INNER JOIN BaseAccounts ba ON hist.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON hist.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE hist.ACCOUNT_STATUS_C = [Your Denial Followup Status Code] -- Placeholder for a status indicating follow-up
UNION ALL
-- 7. Claim Resubmitted
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
claim.RESUBMIT_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON claim.RESUBMIT_USER_ID = emp.USER_ID
WHERE claim.RESUBMIT_DATE IS NOT NULL
UNION ALL
-- 8. Payment Received & 9. Payment Posted to Account (combined for this query)
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE tx.TX_TYPE_C IN ([Your Payer Payment Tx Type], [Your Patient Payment Tx Type]) -- Placeholder for payment transaction types
UNION ALL
-- 10. Account Adjustment Made
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
zcar.NAME AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN ZC_ADJ_REASON zcar ON tx.ADJ_REASON_C = zcar.ADJ_REASON_C
WHERE tx.TX_TYPE_C IN ([Your Adjustment Tx Type]) -- Placeholder for adjustment transaction types
UNION ALL
-- 11. Balance Sent to Collections
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
INNER JOIN HSP_ACCT_STATUS_HX hist ON acct.HSP_ACCOUNT_ID = hist.HSP_ACCOUNT_ID AND hist.ACCOUNT_STATUS_C = [Your Collections Status Code]
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE acct.ACCOUNT_STATUS_C = [Your Collections Status Code] -- Placeholder for collections status
UNION ALL
-- 12. Account Closed
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Account Closed' AS ActivityName,
acct.CLOSED_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- System or Final transaction user
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE acct.ACCT_FIN_BALANCE = 0
AND acct.CLOSED_DATE IS NOT NULL
AND acct.CLOSED_DATE BETWEEN @StartDate and @EndDate
ORDER BY
BillingEvent,
EventTimestamp; Stappen
- Controleer of je geautoriseerde toegang hebt tot de Clarity-data voor de revenue cycle, inclusief de brontabellen en -weergaven die nodig zijn voor de geschiedenis van rekeningen, kosten, claims, afwijzingen, betalingen, correcties, incasso’s en afsluitingen. Welke tabellen beschikbaar zijn en hoe kolommen heten, verschilt per Epic-organisatie. Koppel daarom elke tijdelijke aanduiding in de query aan het bijbehorende Clarity-object in jouw omgeving.
- Bepaal de extractieperiode met [Start date parameter] en [End date parameter]. Begin met een periode van drie tot zes maanden en verleng deze pas nadat je de queryprestaties en volledigheid van de gebeurtenissen hebt gecontroleerd.
- Stel de koppeling voor BillingEvent vast. De query gebruikt waar mogelijk standaard HSP_ACCOUNT.HSP_ACCOUNT_ID als case-ID. Als jouw organisatie een factureringsgebeurtenis definieert op het niveau van een kostenboeking, claim of contactmoment, vervang deze koppeling dan door de goedgekeurde identificatiecode. Gebruik die code consequent voor elke activiteitenbron.
- Koppel elke bronactiviteit aan een gezaghebbende timestamp en bronattribuut. Gebruik voor Service Rendered de gedocumenteerde timestamp waarop de dienst of het contactmoment is afgerond. Gebruik voor Charges Captured de timestamp van de kostenboeking. Gebruik voor Claim Generated en Claim Submitted to Payer de bijbehorende timestamps uit de levenscyclus van de claim. Gebruik voor afwijzingen, opvolging, opnieuw indienen, betalingen, correcties, incasso’s en afsluiting de gedocumenteerde transactie- of statustimestamps.
- Vervang alle tijdelijke aanduidingen tussen vierkante haken in de query, waaronder [Your service source table], [Your charge source table], [Your claim source table], [Your denial source table], [Your follow-up source table], [Your payment source table], [Your adjustment source table], [Your collections source table] en [Your account closure source table]. Gebruik geen transactiec codes die niet zijn gedocumenteerd. Gebruik de transactie- of statuswaarden die door het Epic-rapportageteam zijn goedgekeurd.
- Voer de query uit in de door je organisatie goedgekeurde SQL-client of het rapportageplatform. Controleer of alle twaalf activiteitslabels als afzonderlijke rijen worden weergegeven. ProcessMind leidt ontbrekende gebeurtenissen in de levenscyclus niet af uit saldi, statussen of de volgorde van gebeurtenissen.
- Controleer het uitvoerschema. Het resultaat moet de volgende velden bevatten: BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance en ServiceType. Leg vast of timestamps een tijdzone of lokale tijd gebruiken. Bewaar bronidentificatiecodes in een intern auditbestand als dat is toegestaan.
- Controleer de chronologische volgorde binnen elke BillingEvent, dubbele waarden, het aandeel lege waarden, activiteitenaantallen en de aansluiting op rapporten uit het bronsysteem. Onderzoek gebeurtenissen buiten de gekozen periode als die nodig zijn om cases te begrijpen die vóór de periode beginnen of erna eindigen.
- Exporteer het resultaat als een bestand met scheidingstekens of gebruik een databaseverbinding die ProcessMind ondersteunt. Gebruik één rij per gebeurtenis, vaste kolomnamen, een consistent timestampformaat en UTF-8-codering. Voeg geen samengevoegde cellen of totalen voor presentatiedoeleinden toe. Stel tijdens het uploaden BillingEvent in als case-ID, ActivityName als activiteit en EventTimestamp als timestamp van de gebeurtenis.
Configuratie
- Brontoewijzing: Epic Clarity-implementaties verschillen. Vervang elke tijdelijke aanduiding tussen vierkante haken voor een bronobject of kolom door een gedocumenteerde tabel, weergave of goedgekeurde rapportagelaag in je omgeving. Ga er niet van uit dat een tabel of veld bestaat omdat het in een andere Epic-implementatie gebruikelijk is.
- Case-ID: De standaardtoewijzing in de query gebruikt HSP_ACCOUNT.HSP_ACCOUNT_ID. Controleer of de organisatie BillingEvent definieert als een account, contactmoment, claim, kostenpost of een andere goedgekeurde bedrijfssleutel.
- Datumbereik: Begin met drie tot zes maanden. Neem een terugkijkperiode op als cases kunnen beginnen vóór de rapportageperiode. Neem ook een vervolgperiode op als claims, afwijzingen, betalingen of afsluitingen na de servicedatum kunnen plaatsvinden.
- Activiteitstimestamps: Stel voor elke activiteit één gezaghebbende timestamp in. Gebruik de extractietijd, bestandlaadtijd of tijd van de huidige status niet als vervanging voor het werkelijke tijdstip van de bedrijfsgebeurtenis, tenzij dit de gedocumenteerde timestamp van de gebeurtenis in het bronsysteem is.
- Filters: Pas filters voor [Company Code], [Document Type], [Department], betaler, servicegebied en accountklasse alleen toe als de definities zijn gedocumenteerd en de analyse ze vereist. Gebruik dezelfde filters in alle UNION ALL-vertakkingen.
- Transactie- en statusmapping: Stel waarden in die door de organisatie zijn goedgekeurd voor het boeken van kosten, het aanmaken van claims, het indienen van claims, afwijzingen, opvolging, opnieuw indienen, ontvangst en boeking van betalingen, correcties, incasso en afsluiting. De query gebruikt bewust tijdelijke aanduidingen, omdat Epic-transactiewaarden en bronstructuren per implementatie verschillen.
- Omgaan met NULL-waarden: Behoud NULL voor attributen die niet van toepassing zijn op een activiteit. Vul ontbrekende afwijsredenen, correctieredenen, gebruikers, afdelingen of servicetypen niet in met verzonnen waarden.
- Prestaties: Beperk bronrijen eerst met geïndexeerde datumkolommen en goedgekeurde organisatiebrede filters, en koppel ze daarna aan HSP_ACCOUNT. Gebruik geen functies op geïndexeerde timestampkolommen in voorwaarden. Overweeg elke bronactiviteit beschikbaar te maken via een goedgekeurde rapportageweergave als de ruwe historie groot is.
- Deduplicatie: Verwijder geen dubbele gebeurtenissen zonder een gedocumenteerde regel. Meerdere betalingen, correcties, indieningen of statuswijzigingen kunnen geldige gebeurtenissen zijn voor één BillingEvent.
- Vereisten: Mogelijk is toegang nodig tot Epic Clarity-rapportages, gegevens over de omzetcyclus en accountgeschiedenis, een goedgekeurde SQL-omgeving en toestemming van de organisatie voor beschermde gezondheidsinformatie. Of historie over claims, betalingsspecificaties, werklijsten, incasso en afsluiting beschikbaar is, hangt af van de gelicentieerde en geïmplementeerde Epic-modules en interfaces.
a Voorbeeldquery sql
WITH
service_rendered AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Service Rendered' AS ActivityName,
CAST(s.[Service rendered timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(s.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(s.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(s.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(s.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your service source table] s
ON s.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE s.[Service rendered timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND s.[Service rendered timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND [Your company code filter]
),
charges_captured AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Charges Captured' AS ActivityName,
CAST(t.[Charge captured timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(t.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(t.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(t.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(t.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN AR_PB_TRANSACTIONS t
ON t.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE t.[Charge captured timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND t.[Charge captured timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND t.[Charge transaction filter]
AND [Your company code filter]
),
claim_generated AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Generated' AS ActivityName,
CAST(c.[Claim generated timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim generated timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim generated timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim generated status filter]
AND [Your company code filter]
),
claim_submitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
CAST(c.[Claim submitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim submitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim submitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim submitted status filter]
AND [Your company code filter]
),
claim_denied AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
CAST(d.[Denial timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(d.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(d.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(d.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(d.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(d.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your denial source table] d
ON d.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE d.[Denial timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND d.[Denial timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND d.[Denial status filter]
AND [Your company code filter]
),
denial_follow_up AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
CAST(f.[Follow-up timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(f.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(f.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(f.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(f.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(f.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your follow-up source table] f
ON f.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE f.[Follow-up timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND f.[Follow-up timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND f.[Follow-up status filter]
AND [Your company code filter]
),
claim_resubmitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
CAST(c.[Claim resubmitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim resubmitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted status filter]
AND [Your company code filter]
),
payment_received AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Received' AS ActivityName,
CAST(p.[Payment received timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment received timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment received timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment received status filter]
AND [Your company code filter]
),
payment_posted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
CAST(p.[Payment posted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment posted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment posted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment posted status filter]
AND [Your company code filter]
),
account_adjustment AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
CAST(x.[Adjustment timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(x.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(x.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(x.[Adjustment reason column] AS VARCHAR(100)) AS AdjustmentReason,
CAST(x.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(x.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your adjustment source table] x
ON x.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE x.[Adjustment timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND x.[Adjustment timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND x.[Adjustment transaction filter]
AND [Your company code filter]
),
balance_collections AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
CAST(k.[Collections timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(k.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(k.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(k.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(k.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your collections source table] k
ON k.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE k.[Collections timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND k.[Collections timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND k.[Collections status filter]
AND [Your company code filter]
),
account_closed AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Closed' AS ActivityName,
CAST(z.[Account closed timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(z.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(z.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(z.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(z.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your account closure source table] z
ON z.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE z.[Account closed timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND z.[Account closed timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND z.[Account closed status filter]
AND [Your company code filter]
)
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM service_rendered
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM charges_captured
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_generated
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_submitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_denied
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM denial_follow_up
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_resubmitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_received
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_posted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_adjustment
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM balance_collections
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_closed
ORDER BY BillingEvent, EventTimestamp, ActivityName; Klaar om te beginnen?
Met nauwkeurige data kun je het proces voor revenue cycle management verbeteren. Zet vandaag de eerste stap naar meer efficiëntie en betere financiële resultaten.
Verbeter de efficiëntie: optimaliseer nu revenue cycle management
Spoor inefficiënties in RCM in Epic Resolute op en verkort de doorlooptijd met 30%.
Geen creditcard nodig. Begin vandaag met optimaliseren.