Uw Revenue Cycle Management Data Template
Uw Revenue Cycle Management Data Template
- Aanbevolen attributen om vast te leggen
- Belangrijkste activiteiten om te volgen
- Richtlijnen voor data-extractie
Attributen voor Omzetcyclusbeheer
| Naam | Omschrijving | ||
|---|---|---|---|
| Activiteitsnaam ActivityName | De naam van de specifieke gebeurtenis of taak die is uitgevoerd binnen het omzetcyclusbeheerproces. | ||
| Omschrijving Dit attribuut beschrijft een enkele stap in de omzetcyclus, zoals 'Charges Captured', 'Claim Submitted to Payer', of 'Payment Received'. Elke activiteit vertegenwoordigt een duidelijke mijlpaal in het proces van facturering en het innen van betaling voor een dienst. Het analyseren van activiteiten is de basis van process mining. Het maakt de visualisatie van de proceskaart, identificatie van gemeenschappelijke paden, ontdekking van knelpunten tussen stappen, en de meting van conformiteit met standaard operationele procedures mogelijk. Het belang Definieert de stappen in de proceskaart, waardoor het mogelijk wordt de workflow in de omzetcyclus te visualiseren, analyseren en optimaliseren. Vindplaats Dit wordt doorgaans afgeleid uit event logs, audit trails of statuswijzigingsrecords binnen de facturatie- en claimsmodules van Epic Resolute. Voorbeelden Charges VastgelegdClaim Ingediend bij BetalerBetaling OntvangenAccount Gesloten | |||
| Billing Event BillingEvent | De unieke identificatie voor een enkele dienst of productlevering die een kostenpost genereert, dienend als de primaire case-identificatie. | ||
| Omschrijving De Billing Event is de kernidentificatie die alle activiteiten binnen de omzetcyclus voor een specifiek declareerbaar item verbindt. Het begint wanneer een dienst wordt geleverd en eindigt wanneer de rekening volledig is voldaan of afgesloten. In Process Mining analyse is dit attribuut essentieel voor het reconstrueren van het end-to-end traject van elke kostenpost. Het maakt het volgen van activiteiten zoals kostenregistratie, claimindiening, betalingsverwerking en afwijzingsbeheer voor individuele billing events mogelijk, wat een duidelijk beeld geeft van de processtroom en de variaties ervan. Het belang Dit is de fundamentele Case ID, cruciaal voor het koppelen van alle gerelateerde processtappen om de complete levenscyclus van omzetgeneratie en -incasso voor elke service te analyseren. Vindplaats Dit is vaak een unieke identificatie voor een ziekenhuisrekening (HAR) of een specifieke kostenregistratiesessie in Epic Resolute. Raadpleeg de Epic Resolute documentatie voor specifieke tabellen zoals HAR of Charge Session records. Voorbeelden BE10098765BE20012345BE30054321 | |||
| Gebeurtenistijdstempel EventTimestamp | De exacte datum en tijd waarop een specifieke activiteit of gebeurtenis plaatsvond. | ||
| Omschrijving De Event Timestamp legt het moment vast waarop een activiteit plaatsvond. Deze temporele data is cruciaal voor het begrijpen van de timing en volgorde van evenementen in de omzetcyclus. In analyse worden timestamps gebruikt om de duur tussen activiteiten te berekenen, zoals vertragingen bij kostenregistratie of de verwerkingstijd van betalingen. Ze maken de ontdekking van knelpunten, het meten van cyclustijden en de analyse van procesprestaties over verschillende tijdsperioden mogelijk. Nauwkeurige timestamps zijn essentieel voor vrijwel alle tijdgebonden KPI's en dashboards. Het belang Dit attribuut is essentieel voor het berekenen van alle tijdgebonden meetwaarden, inclusief cyclustijden en -duren, die fundamenteel zijn voor het identificeren van vertragingen en inefficiënties. Vindplaats Te vinden in transactie- of event log tabellen binnen Epic Resolute, geassocieerd met elke vastgelegde activiteit. Velden zijn vaak genoemd met achtervoegsels zoals Dt, DTTM of Time. Voorbeelden 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Facturatieafdeling BillingDepartment | De afdeling of het functionele team dat verantwoordelijk is voor de billing event of activiteit. | ||
| Omschrijving Dit attribuut geeft de organisatorische eenheid aan, zoals 'Inpatient Billing', 'Outpatient Billing', of 'Denial Management Team', die geassocieerd is met de billing event of een specifieke activiteit heeft uitgevoerd. Deze dimensie is cruciaal voor het 'Billing Department Performance Metrics' dashboard, wat vergelijkingen mogelijk maakt van belangrijke meetwaarden zoals afwijzingspercentages of kostenregistratietijden. Het helpt het management om goed presterende afdelingen te identificeren, best practices te standaardiseren en resources effectief toe te wijzen. Het belang Maakt prestatiebenchmarking tussen verschillende afdelingen mogelijk, wat helpt bij het identificeren van best practices en gebieden die verbetering of aanvullende middelen nodig hebben. Vindplaats Deze informatie kan gekoppeld zijn aan de gebruikersrecord, de patiëntenrekening of de servicelocatie binnen Epic Resolute. Voorbeelden Cardiologie FacturatieRadiologie RCMCentraal Facturatiekantoor | |||
| Openstaand Saldo OutstandingBalance | Het resterende bedrag dat de betaler of patiënt verschuldigd is voor de billing event. | ||
| Omschrijving Dit attribuut representeert het huidige debiteurensaldo voor een specifieke billing event op het moment van de activiteit. Het weerspiegelt de financiële status van de case gedurende de gehele levenscyclus. Het openstaande saldo is cruciaal voor financiële rapportage en voor de 'Outstanding Balance Aging Report'. Het analyseren van deze waarde over tijd en door verschillende dimensies zoals betaler of afdeling helpt bij het prioriteren van incassoinspanningen, het beheren van de cashflow en het beoordelen van financieel risico. Het belang Meet direct de financiële impact van procesvertragingen en is essentieel voor het prioriteren van incasso's, het beheren van de cashflow en het begrijpen van de debiteurenportefeuille. Vindplaats Dit is een kernveld op de patiëntenrekening of ziekenhuisrekening (HAR) record in Epic Resolute. Het is een doorlopend saldo dat wordt bijgewerkt door financiële transacties. Voorbeelden 1500.00250.750.00 | |||
| Reden Code Afwijzing DenialReasonCode | Een gestandaardiseerde code die de reden aangeeft waarom een betaler een ingediende claim heeft afgewezen. | ||
| Omschrijving Wanneer een betaler een claim afwijst, geven zij een reden code op die de afwijzing verklaart, zoals 'Non-Covered Service', 'Duplicate Claim', of 'Requires Additional Information'. Deze codes zijn vaak gestandaardiseerd als Claim Adjustment Reason Codes (CARCs). Dit attribuut is de hoeksteen van het 'Claim Denial Rates And Reasons' dashboard. Het analyseren van de frequentie van verschillende afwijzingscodes helpt bij het identificeren van de grondoorzaken van afwijzingen, zoals credentialing-problemen, coderingsfouten of ontbrekende pre-autorisaties, waardoor gerichte verbeteringsinitiatieven mogelijk worden. Het belang Verklaart direct waarom claims worden afgewezen, en biedt bruikbare inzichten die nodig zijn om afwijzingspercentages te verminderen, omzetverlies te voorkomen en betalingen te versnellen. Vindplaats Deze data is te vinden in de claimreactietransacties (zoals een ANSI 835-bestand) die van betalers worden ontvangen en is opgeslagen binnen Epic Resolute's claims management module. Voorbeelden CO-16: Claim/dienst mist informatieOA-18: Dubbele claim/dienstPR-96: Niet-gedekte charge(s) | |||
| Reden van aanpassing AdjustmentReason | De reden voor een handmatige of geautomatiseerde aanpassing van het saldo van een patiëntenrekening. | ||
| Omschrijving Dit attribuut verklaart waarom een rekeningsaldo werd gewijzigd buiten een standaardbetaling of -kostenpost. Redenen kunnen contractuele toeslagen met betalers, afschrijvingen van kleine saldi, of correcties voor boekingsfouten omvatten. Dit is essentieel voor het 'Account Adjustment Volume By Type' dashboard. Door aanpassingsredenen te analyseren, kunnen organisaties bronnen van omzetlekkage identificeren, de impact van betalerscontracten begrijpen en potentiële inefficiënties of fouten in het facturatieproces opsporen. Het belang Biedt inzicht in omzetlekkage en facturatienauwkeurigheid door te verklaren waarom rekeningsaldi worden gewijzigd, wat helpt onnodige afschrijvingen te verminderen. Vindplaats Te vinden in de transactiedetails voor aanpassingsboekingen binnen Epic Resolutes patiëntenboekhoudingsmodule. Voorbeelden Contractuele KortingAfschrijving Klein SaldoCorrectie Dubbele Charge | |||
| Servicetype ServiceType | De categorie of het type medische dienst dat werd geleverd. | ||
| Omschrijving Dit attribuut classificeert de declareerbare dienst, bijvoorbeeld als 'Radiology', 'Surgery', 'Consultation', of 'Emergency Room Visit'. Het biedt klinische context aan de financiële data. Het analyseren van de omzetcyclus per servicetype kan procesvariaties onthullen die specifiek zijn voor bepaalde klinische gebieden. Chirurgische procedures kunnen bijvoorbeeld complexere kostenregistratie- en autorisatievereisten hebben dan een standaard kantoorbezoek, wat leidt tot verschillende procesgedragingen en uitdagingen. Het belang Biedt klinische context aan financiële data, waardoor analyse mogelijk wordt van hoe verschillende soorten medische diensten de omzetcyclus en de efficiëntie ervan beïnvloeden. Vindplaats Afgeleid van de charge description master (CDM), servicelijn of afdeling gekoppeld aan de charge-transactie in Epic. Voorbeelden Klinische ChirurgieAmbulante RadiologieSpoedeisende Hulp | |||
| Verantwoordelijke Gebruiker ResponsibleUser | De identificatie van de gebruiker of medewerker die de activiteit heeft uitgevoerd. | ||
| Omschrijving Dit attribuut legt de gebruikers-ID, naam of het personeelsnummer vast van de persoon die verantwoordelijk is voor het voltooien van een specifieke taak in de omzetcyclus. Dit kan de clinicus zijn die kosten heeft ingevoerd, de facturatiemedewerker die een claim heeft ingediend, of de incassomedewerker die een afwijzing heeft opgevolgd. Analyseren per gebruiker helpt bij het identificeren van topmedewerkers, het vaststellen van trainingsbehoeften en het begrijpen van de werkdrukverdeling. Het is cruciaal voor prestatiemanagement en voor het onderzoeken van procesafwijkingen geassocieerd met specifieke individuen of rollen. Het belang Maakt prestatieanalyse per individu of rol mogelijk, wat helpt bij het identificeren van trainingsmogelijkheden, werkdrukverschillen en resourcegerelateerde knelpunten. Vindplaats Doorgaans te vinden in audit trail of transactielogs binnen Epic Resolute, vaak gekoppeld aan een gebruikersmasterdatatable (bijv. EMP-record). Voorbeelden j.doebsmith123User7890 | |||
| Aangepast Bedrag AdjustedAmount | De monetaire waarde van een aanpassingstransactie. | ||
| Omschrijving Dit veld registreert het specifieke dollarbedrag van een rekeningaanpassing. Het kan een positieve of negatieve waarde zijn, die een creditering of debitering van het rekeningsaldo vertegenwoordigt. Dit bedrag is de primaire meetwaarde voor het 'Account Adjustment Volume By Type' dashboard. Door deze waarde per aanpassingsreden te sommeren, krijgt men een duidelijk beeld van de financiële impact van verschillende soorten aanpassingen, zoals hoeveel omzet wordt afgeschreven vanwege contractuele verplichtingen versus hoeveel verloren gaat door corrigeerbare fouten. Het belang Kwantificeert de financiële impact van rekeningaanpassingen, waardoor het mogelijk wordt om omzetlekkage en de kosten van factureringsonvolkomenheden te meten. Vindplaats Te vinden in de financiële transactiedetailtabellen in Epic Resolute, geassocieerd met transacties van het aanpassingstype. Voorbeelden -1250.45-50.0025.10 | |||
| Bewerkingstijd ProcessingTime | De berekende duur van de tijd die actief aan een activiteit is besteed. | ||
| Omschrijving Verwerkingstijd, ook wel afhandelingstijd genoemd, meet de duur van een activiteit van begin tot eind. Het vertegenwoordigt de tijd dat een resource actief bezig was met de taak. Deze meetwaarde wordt berekend als het verschil tussen 'EventEndTime' en 'EventTimestamp'. Het analyseren van de verwerkingstijd helpt bepalen welke specifieke taken het meest tijdrovend zijn, waardoor gerichte inspanningen kunnen worden geleverd om te stroomlijnen en de efficiëntie te verbeteren. Het is een fundamentele maatstaf voor resourceproductiviteit. Het belang Meet de werkelijke duur van activiteiten, wat helpt bij het identificeren van tijdrovende taken en het evalueren van de efficiëntie van middelen. Vindplaats Dit is geen veld in het bronsysteem. Het wordt berekend tijdens datatransformatie met behulp van de formule: EventEndTime - EventTimestamp. Voorbeelden 900605120 | |||
| Bronsysteem SourceSystem | Het informatiesysteem waaruit de data afkomstig is. | ||
| Omschrijving Dit attribuut identificeert het bronsysteem van de record, wat in deze context Epic Resolute is. In omgevingen met meerdere geïntegreerde systemen helpt dit veld bij het differentiëren van data-oorsprongen. Hoewel het overbodig kan lijken in een enkel-systeemweergave, is het een best practice voor datagovernance en schaalbaarheid. Het zorgt voor duidelijkheid als data van andere systemen, zoals een apart incassobureauplatform, later wordt geïntegreerd. Het belang Biedt cruciale data lineage en context, wat zorgt voor duidelijkheid over de herkomst van de data, essentieel voor datagovernance en probleemoplossing. Vindplaats Dit is meestal een statische waarde die tijdens data-extractie en transformatie wordt toegevoegd om de herkomst van de dataset te labelen. Voorbeelden Epic ResoluteEpicResolute_V2023 | |||
| Claim-ID ClaimId | De unieke identificatie die is toegewezen aan een verzekeringsclaim ingediend bij een betaler. | ||
| Omschrijving Dit attribuut is de specifieke ID voor het claimformulier (bijv. een CMS-1500 of UB-04) verstuurd naar een betaler. Eén billing event kan meerdere claims omvatten als diensten opnieuw worden gefactureerd of aangevochten. Volgen via Claim ID is nuttig voor gedetailleerde analyse van de sub-processen van claimindiening en afwijzingsbeheer. Het helpt activiteiten met betrekking tot de initiële claim te onderscheiden van die met betrekking tot een volgende, opnieuw ingediende claim voor dezelfde service. Het belang Biedt een gedetailleerde identificatie voor het volgen van de levenscyclus van elke specifieke claimindiening, wat cruciaal is voor het analyseren van herindieningen en beroepen. Vindplaats Gegenereerd door de claims management module van Epic Resolute wanneer een claim wordt aangemaakt. Het wordt opgeslagen in de claims data tabellen. Voorbeelden CLM-2023-98765CLAIM-0012345623189A4567 | |||
| Eindtijd van het event EventEndTime | De timestamp die aangeeft wanneer een activiteit is voltooid, nuttig voor het berekenen van de duur van de activiteit. | ||
| Omschrijving Dit attribuut registreert de voltooiingstijd van een activiteit. Hoewel veel activiteiten onmiddellijke evenementen zijn waarbij StartTime gelijk is aan EndTime, hebben sommige taken een meetbare duur, zoals een opvolgingsgesprek voor een afwijzing. Wanneer beschikbaar, maakt EndTime de directe berekening van de verwerkingstijd van de activiteit ('EndTime' - 'StartTime') mogelijk. Dit is nauwkeuriger dan de duur af te leiden uit de starttijd van de volgende activiteit, aangezien het rekening houdt met inactieve tijd tussen stappen. Het is een essentieel onderdeel voor het berekenen van het 'ProcessingTime' attribuut. Het belang Maakt de precieze berekening mogelijk van hoe lang elke activiteit duurt om te voltooien, wat cruciaal is voor het identificeren van inefficiënte taken en het meten van de productiviteit van middelen. Vindplaats Dit is mogelijk beschikbaar in sommige Epic Resolute modules die de start en het einde van taken bijhouden, zoals work queue of activity management logs. Vaak wordt dit niet expliciet bijgehouden. Voorbeelden 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| Is Geautomatiseerd IsAutomated | Een boolean vlag die aangeeft of de activiteit door een systeem of een geautomatiseerd proces is uitgevoerd. | ||
| Omschrijving Deze vlag onderscheidt taken die automatisch door het systeem worden uitgevoerd, zoals geautomatiseerde claimgeneratie of geschiktheidscontroles, en die handmatig door een gebruiker worden uitgevoerd. Het analyseren van dit attribuut helpt bij het begrijpen van de mate van automatisering in het proces. Het kan worden gebruikt om de efficiëntie en foutenpercentages van geautomatiseerde versus handmatige activiteiten te vergelijken, kansen voor verdere automatisering te identificeren en de prestaties van bestaande bots of systeemregels te monitoren. Het belang Onderscheidt systeemgestuurde en menselijke activiteiten, wat cruciaal is voor het evalueren van de impact van automatisering en het identificeren van nieuwe automatiseringsmogelijkheden. Vindplaats Dit wordt vaak afgeleid door te controleren of de 'ResponsibleUser' voor een activiteit een systeem- of serviceaccount is, of door specifieke activiteitsnamen te markeren die bekend zijn als geautomatiseerd. Voorbeelden truefalse | |||
| Laatste data-update LastDataUpdate | De timestamp die aangeeft wanneer de data voor dit event voor het laatst is vernieuwd of geëxtraheerd uit het bronsysteem. | ||
| Omschrijving Dit attribuut toont de actualiteit van de data. Het geeft aan wanneer de record voor het laatst is opgehaald uit Epic Resolute in de process mining dataset. Dit is belangrijk voor het begrijpen van de tijdigheid van de analyse en voor datavalidatiedoeleinden. Het helpt gebruikers te weten of zij naar de meest actuele beschikbare informatie kijken en is cruciaal voor het beheren van datarefreshcycli. Het belang Zorgt ervoor dat gebruikers de actualiteit van de data die ze analyseren begrijpen, wat cruciaal is voor het nemen van accurate, up-to-date zakelijke beslissingen. Vindplaats Deze timestamp wordt toegevoegd door het ETL (Extract, Transform, Load) proces tijdens data-ingestie. Voorbeelden 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| Naam Betaler PayerName | De naam van de verzekeringsmaatschappij, overheidsinstantie of andere partij die verantwoordelijk is voor de betaling. | ||
| Omschrijving Dit attribuut identificeert de primaire betaler die is gekoppeld aan de billing event, zoals 'Blue Cross Blue Shield', 'Medicare', of 'Aetna'. In gevallen van zelfbetaling kan het de patiënt aangeven. Het segmenteren van het proces per betaler is een krachtige analysetechniek. Het kan aan het licht brengen dat bepaalde betalers hogere afwijzingspercentages, langere betalingscycli of complexere vereisten hebben. Dit inzicht maakt het aanpassen van facturatiestrategieën aan specifieke betalers mogelijk om de efficiëntie en betalingssnelheid te verbeteren. Het belang Maakt prestatieanalyse per betaler mogelijk, wat onthult welke betalers hoge afwijzingspercentages of trage betalingscycli hebben, en gerichte opvolgingsstrategieën mogelijk maakt. Vindplaats Deze informatie is onderdeel van de dekkingsgegevens van de patiënt, gekoppeld aan de ziekenhuisrekening (HAR) in Epic Resolute. Voorbeelden Medicare Deel BUnitedHealthcareAetna PPO | |||
| Patiënt ID PatientId | De unieke identificatie voor de patiënt die de dienst ontvangt. | ||
| Omschrijving Dit attribuut is het Medical Record Number (MRN) of een andere unieke identificatie voor de patiënt. Het koppelt de financiële billing event aan een specifiek individu. Hoewel het meestal niet als primaire analyse-dimensie wordt gebruikt om de privacy van patiënten te beschermen, is het essentieel voor datavalidatie en kan het worden gebruikt om alle billing events voor één patiënt te aggregeren om hun algehele financiële traject te begrijpen. Het is ook cruciaal voor elke potentiële integratie met klinische procesdata. Het belang Koppelt financiële data aan een specifieke patiënt, wat data validatie en potentieel voor bredere analyse van het gehele traject van een patiënt mogelijk maakt, hoewel dit zorgvuldig moet worden behandeld vanwege privacyoverwegingen. Vindplaats Een fundamentele identificator die overal in Epic te vinden is, gekoppeld aan de registratie- en rekeninggegevens van de patiënt. Voorbeelden MRN-1234567MRN-8765432MRN-5551234 | |||
| Totale Omzetcyclustijd TotalRevenueCycleTime | De totaal berekende duur vanaf de eerste service-evenement tot de uiteindelijke betaling of rekeningafsluiting. | ||
| Omschrijving Dit is een case-level KPI die de end-to-end duur van de omzetcyclus voor één billing event meet. Het wordt doorgaans berekend als het tijdsverschil tussen de activiteit 'Service Rendered' en de uiteindelijke activiteit 'Payment Received' of 'Account Closed'. Deze high-level meetwaarde biedt een holistisch beeld van de algehele efficiëntie van het RCM-proces. Het volgen van deze KPI in de loop van de tijd helpt de impact van procesverbeteringsinitiatieven te meten en biedt een belangrijke indicator voor de snelheid van kasconversie. Het belang Biedt een hoogwaardig, end-to-end overzicht van procesefficiëntie, door direct te meten hoe lang het duurt om een dienst om te zetten in geld. Vindplaats Dit is een meetwaarde berekend binnen de process mining tool door te filteren op de eerste en laatste evenementen van elke case en het tijdsverschil te bepalen. Voorbeelden 259200038880005184000 | |||
| Uiterste betaaldatum PaymentDueDate | De datum waarop betaling voor de gefactureerde dienst wordt verwacht. | ||
| Omschrijving Dit attribuut specificeert de uiterste betaaldatum, zoals vermeld op de factuur of bepaald door betalerscontracten. Het dient als een benchmark voor het meten van tijdige betalingen. De betalingstermijn is essentieel voor het opstellen van het 'Outstanding Balance Aging Report'. Door de huidige datum te vergelijken met de vervaldatum voor openstaande saldi, kunnen debiteuren worden gecategoriseerd in ouderdomscategorieën (bijv. 0-30 dagen, 31-60 dagen over tijd), wat helpt incassoinspanningen te prioriteren op de meest achterstallige rekeningen. Het belang Dient als basis voor analyse van de ouderdom van debiteuren, wat cruciaal is voor het prioriteren van incasso's en het beheren van financiële risico's door onbetaalde facturen. Vindplaats Deze datum wordt vaak berekend op basis van de factuurdatum en betalingsvoorwaarden die zijn opgeslagen in het betalerscontract of de patiëntenrekeninginformatie binnen Epic. Voorbeelden 2023-05-302023-06-152023-07-01 | |||
Activiteiten voor Omzetcyclusbeheer
| Activiteit | Omschrijving | ||
|---|---|---|---|
| Account Gesloten | Dit is de laatste activiteit, wat betekent dat het openstaande saldo van de billing event nul heeft bereikt en er geen verdere activiteiten meer in behandeling zijn. Dit kan te wijten zijn aan volledige betaling, aanpassingen of een afschrijving. | ||
| Het belang Deze gebeurtenis markeert de succesvolle voltooiing van de omzetcyclus voor een billing event. De end-to-end duur van service tot afsluiting is een kritieke KPI voor de algehele procesefficiëntie. Vindplaats Dit is doorgaans een afgeleide gebeurtenis. Het wordt bepaald door het moment te identificeren waarop het rekeningsaldo voor de billing event nul wordt en nul blijft. Vastleggen Afgeleid door een doorlopend totaal van het rekeningsaldo te berekenen en de timestamp te identificeren van de laatste transactie die het saldo nul maakte. Gebeurtenistype inferred | |||
| Betaling Geboekt op Rekening | Dit is de gebeurtenis waarbij een ontvangen betaling wordt toegepast of toegewezen aan specifieke kosten op de patiëntenrekening. Deze actie vermindert het openstaande saldo van de billing event. | ||
| Het belang Efficiënte payment posting is cruciaal voor het handhaven van accurate rekeningstanden en het afsluiten van Vindplaats Dit is een expliciete transactie in Resolute. Betalingsverwerking koppelt een betalingstransactie aan één of meer kostenposttransacties, die is vastgelegd in de transactiedetailtabellen. Vastleggen Leg de transactierecord vast die een betaling toewijst aan een charge, identificeerbaar aan de hand van specifieke transactietypen. Gebeurtenistype explicit | |||
| Betaling Ontvangen | Vertegenwoordigt de ontvangst van een betaling van een betaler of patiënt. Deze gebeurtenis wordt doorgaans vastgelegd wanneer een elektronisch betalingsadvies (ERA) wordt geladen of een handmatige controle in het systeem wordt ingevoerd. | ||
| Het belang Deze activiteit is een belangrijke mijlpaal die aangeeft dat er inkomsten binnenkomen. De tijd tussen claimindiening en ontvangst van betaling is een belangrijke maatstaf voor de prestaties van debiteuren. Vindplaats Expliciet vastgelegd als een betalingstransactie in Resolute. Deze transacties worden gelogd met een datum, bron en bedrag, vaak voordat ze volledig op individuele charges zijn geboekt. Vastleggen Leg betalingstransacties vast vanuit het financiële transactielogboek, vaak geïdentificeerd aan de hand van specifieke transactietypen. Gebeurtenistype explicit | |||
| Charges Vastgelegd | Vertegenwoordigt de formele registratie van declareerbare kosten voor de geleverde diensten. In Epic is dit doorgaans een expliciete transactie die op de patiëntenrekening wordt geboekt, vaak automatisch gegenereerd vanuit klinische acties of handmatig ingevoerd. | ||
| Het belang Dit is een kritieke eerste mijlpaal. Het meten van de snelheid en nauwkeurigheid van kostenregistratie helpt bij het versnellen van het facturatieproces en het waarborgen dat alle geleverde diensten worden gefactureerd. Vindplaats Expliciet vastgelegd in de transactielogs van Resolute. Elke charge is een discrete invoer met een boekingsdatum, servicedatum en bedrag, vaak te vinden in tabellen zoals ARPB_TRANSACTIONS. Vastleggen Leg charge posting transacties vast vanuit het financiële transactielogboek van het systeem. Gebeurtenistype explicit | |||
| Claim Afgewezen door Betaler | Vertegenwoordigt de ontvangst van een melding van de betaler dat de claim is afgewezen. Dit wordt vastgelegd wanneer Epic een elektronisch betalingsadvies (835-bestand) verwerkt of wanneer een gebruiker handmatig een afwijzing boekt. | ||
| Het belang Deze activiteit initieert een kritieke herstelcyclus. Het analyseren van afwijzingsredenen en -volumes is essentieel voor het identificeren van grondoorzaken, het verbeteren van 'first-pass' betalingspercentages en het verminderen van incassovertragingen. Vindplaats Expliciet vastgelegd als een transactie of statusupdate op de claim. Informatie over afwijzingen, inclusief reden codes, wordt doorgaans elektronisch ontvangen en op de rekening geboekt. Vastleggen Filter op specifieke transactietypen of claimstatusupdates die een afwijzing aangeven. Gebeurtenistype explicit | |||
| Claim Ingediend bij Betaler | Dit markeert de gebeurtenis waarbij de claim officieel naar de verzekeringsbetaler wordt gestuurd voor beoordeling. In Epic is dit een bijgehouden gebeurtenis, gelogd wanneer het elektronische claimbestand wordt verzonden naar het clearinghouse of de betaler. | ||
| Het belang Deze mijlpaal is cruciaal, aangezien het de klok start voor de betalingstermijn van de betaler. Het analyseren hiervan helpt de efficiëntie van het claimtransmissieproces te meten en ondersteunt de KPI 'Invoice to Payer Delivery Time'. Vindplaats Dit is een expliciete gebeurtenis vastgelegd in Resolute. De claimrecord zal een indieningsstatus en een timestamp hebben die aangeeft wanneer deze is verzonden. Vastleggen Leg de timestamp vast die hoort bij de claimstatus die verandert naar 'Submitted' of 'Transmitted'. Gebeurtenistype explicit | |||
| Dienst Geleverd | Deze activiteit markeert het punt waarop een klinische dienst aan de patiënt wordt geleverd, wat de billing event initieert. Dit wordt vaak vastgelegd vanuit de Epic EHR (EpicCare) wanneer een clinicus een bezoek of procedure aftekent. | ||
| Het belang Dit is de primaire startevenement voor de omzetcyclus. Het analyseren van de tijd vanaf dit punt tot kostenregistratie is cruciaal voor het identificeren van vertragingen in de facturatie-initiatie en potentiële omzetlekkage. Vindplaats Deze gebeurtenis wordt doorgaans afgeleid uit service- of bezoektimestamps in de klinische modules die zijn gekoppeld aan de billing account. De servicedatum op de kostenposttransactie is het belangrijkste datapunt. Vastleggen Afgeleid van de servicedatum die gekoppeld is aan de eerste charge-transactie voor de billing event. Gebeurtenistype inferred | |||
| Accountaanpassing Uitgevoerd | Deze activiteit vertegenwoordigt een niet-betalingstransactie die het rekeningsaldo wijzigt, zoals een contractuele aanpassing, een afschrijving van een klein saldo, of een coulancekorting. Dit wordt vastgelegd als een specifiek transactietype. | ||
| Het belang Het analyseren van aanpassingen is cruciaal voor het identificeren van omzetlekkage. Grote volumes van bepaalde aanpassingstypes kunnen duiden op problemen met tariefschema's, contractering of intern beleid. Vindplaats Expliciet vastgelegd als aanpassingstransacties in de financiële logs van Resolute. Elke aanpassing heeft een specifiek type of reden code gekoppeld. Vastleggen Filter op transactietypen die overeenkomen met financiële aanpassingen of afschrijvingen. Gebeurtenistype explicit | |||
| Claim Gecreëerd | Deze activiteit betekent de creatie door het systeem van een formele claim of factuur op basis van de vastgelegde kosten. Het is een voorbereidende stap voordat de claim naar de betaler of patiënt wordt gestuurd. | ||
| Het belang Het volgen van claimgeneratie helpt vertragingen te isoleren tussen het vastleggen van kosten en het voorbereiden ervan voor indiening. Het is een belangrijke interne stap die de algehele tijdigheid van facturatie kan beïnvloeden. Vindplaats Dit wordt doorgaans gelogd wanneer een batchtaak voor facturatie of claimgeneratie wordt uitgevoerd. Het systeem zal een timestamp vastleggen wanneer het claimbestand (zoals een 837-bestand) voor een gegeven rekening wordt aangemaakt. Vastleggen Identificeer log-entries of statuswijzigingen die aangeven dat de claim is samengesteld en klaar is voor indiening. Gebeurtenistype explicit | |||
| Claim Opnieuw Ingediend | Deze gebeurtenis vindt plaats nadat een afgewezen claim is gecorrigeerd en teruggestuurd naar de betaler. Dit is een afzonderlijke indieningsgebeurtenis die is gekoppeld aan de oorspronkelijke claim. | ||
| Het belang Dit is een belangrijk onderdeel van de herstelcyclus. Het meten van de tijd tot herindiening en het succespercentage van opnieuw ingediende claims is essentieel voor het begrijpen van de effectiviteit van het afwijzingsoplossingsproces. Vindplaats Dit is een expliciete gebeurtenis vergelijkbaar met de initiële indiening, maar vaak gemarkeerd als een herindiening. De claimrecord zal een nieuwe indienings timestamp tonen en kan een herindieningscode bevatten. Vastleggen Leg de timestamp vast voor een claimindiening die is gemarkeerd als een correctie of herindiening. Gebeurtenistype explicit | |||
| Opvolging Afwijzing Gestart | Deze activiteit markeert de start van het interne proces om een afgewezen claim te beoordelen en op te lossen. Het wordt vaak vastgelegd wanneer een gebruiker de verantwoordelijkheid voor de afgewezen claim neemt in een workqueue of de status ervan wijzigt. | ||
| Het belang Het volgen hiervan helpt de responsiviteit van het denials management team te meten. Vertragingen tussen een afwijzing en de start van de opvolging kunnen de omzetcyclus onnodig verlengen. Vindplaats Dit wordt doorgaans afgeleid uit wijzigingen in de status of toewijzingsgeschiedenis van de claim binnen de workqueues van Epic. De status van de claim kan bijvoorbeeld veranderen van 'Denied' naar 'In Review'. Vastleggen Afleiden uit een claimstatuswijziging of een audit log entry die aangeeft dat een gebruiker is begonnen met het verwerken van de afwijzing. Gebeurtenistype inferred | |||
| Saldo Doorgestuurd naar Incasso | Dit markeert het punt waarop een onbetaald rekeningsaldo wordt overgedragen aan een intern of extern incassoproces. Dit is vaak een expliciete statuswijziging op de rekening of billing event. | ||
| Het belang Deze activiteit initieert de laatste fase van het terugvorderen van openstaande saldi. Het volgen van het succespercentage en de cyclustijd van het incassoproces is essentieel voor het minimaliseren van oninbare vorderingen. Vindplaats Dit is doorgaans een expliciete gebeurtenis. Epic heeft functionaliteiten om rekeningen over te dragen aan incassobureaus, wat een logboekvermelding of een statuswijziging op de rekening creëert. Vastleggen Identificeer de statuswijziging of transactie die aangeeft dat een account bij een incassobureau is geplaatst. Gebeurtenistype explicit | |||
Extractie Guides
Stappen
- Databaseverbinding tot stand brengen: Verkrijg alleen-lezen inloggegevens voor de Epic Clarity database. Gebruik een standaard SQL client, zoals DBeaver of Microsoft SQL Server Management Studio, om verbinding te maken met de databaseserver.
- Kerntabellen identificeren: De primaire tabellen voor deze extractie omvatten
HSP_ACCOUNTvoorcaseinformatie,HSP_TRANSACTIONSvoor financiëleevents,CLP_CLAIM_INFOvoor claimstatus, enF_ARHB_TX_SET_POST_HXvoorpayment postingdetails. U zult ook master files zoalsCLARITY_EMPjoinen voor gebruikersdetails. - Bereik definiëren: Bepaal, voordat u de query schrijft, het bereik van uw analyse. Definieer een specifiek datumbereik, typisch 3 tot 6 maanden, en identificeer eventuele specifieke ziekenhuis servicegebieden (
SERV_AREA_ID) of accountklassen die u wilt opnemen of uitsluiten. - De SQL-query ontwikkelen: Construeer een SQL-query met behulp van een Common Table Expression (CTE) om eerst de set van
HSP_ACCOUNT_ID-waarden te selecteren die binnen uw gedefinieerde bereik vallen. Dit dient als de basispopulatie vanbilling events. - Individuele Activiteitenqueries samenvoegen: Voor elk van de 12 vereiste activiteiten schrijft u een aparte
SELECTstatement die data ophaalt uit de relevante tabellen. Join terug naar uw initiële CTE om te garanderen dat u alleen de beoogde accounts analyseert. - Queries combineren met UNION ALL: Gebruik de
UNION ALLoperator om de resultaten van alle individuele activiteitenqueries te combineren tot één samenhangendeevent log. Dit stapelt de rijen van elke query verticaal. - Toewijzen aan Standaard Schema: In elke
SELECTstatement, alias de kolommen om te matchen met het vereiste ProcessMind schema:BillingEvent,ActivityName,EventTimestamp,ResponsibleUser, etc. GebruikNULLvoorattributesdie niet van toepassing zijn op een specifieke activiteit. - De Query uitvoeren en verfijnen: Voer de complete query uit tegen de Clarity database. Vanwege de grootte van de tabellen kan dit aanzienlijk veel tijd in beslag nemen. Als
performanceeen probleem is, beperk dan het datumbereik verder of voeg meer specifieke filters toe in de initiële CTE. - De Output controleren: Zodra de query is voltooid, inspecteert u de eerste paar honderd rijen van de output. Verifieer dat alle kolommen aanwezig zijn,
timestampsin een consistent formaat zijn en verschillendeActivityNamewaarden verschijnen zoals verwacht. - Exporteren naar CSV: Exporteer de gehele resultaatset vanuit uw SQL client naar een CSV-bestand. Zorg ervoor dat het bestand UTF-8-codering gebruikt en een
header rowbevat met de juiste kolomnamen. - Voorbereiden voor Upload: Voordat u uploadt naar ProcessMind, opent u het CSV-bestand om te bevestigen dat er geen formatteringsfouten zijn. Controleer of het
timestampformaat consistent is, for example,YYYY-MM-DD HH:MI:SS. Het bestand is nu klaar vooringestion.
Configuratie
- Databaseverbinding: Een alleen-lezen gebruikersaccount met toegang tot de Epic Clarity database is vereist.
- Datumbereikparameters: De meegeleverde query gebruikt de variabelen
@StartDateen@EndDate. Deze moeten worden ingesteld om de analyseperiode te definiëren. Een bereik van 3 tot 6 maanden wordt aanbevolen om het gegevensvolume en de prestaties in evenwicht te houden. - Tabel- en Kolomtoewijzing: De query gaat uit van standaard Clarity tabel- en kolomnamen. De specifieke Epic-configuratie of -versie van uw organisatie kan afwijkingen vertonen. Mogelijk moet u tabelnamen, kolomnamen of join-condities dienovereenkomstig aanpassen.
- Transactie- en Statuscodes: De query bevat placeholders zoals
[Your Denial Tx Type]en[Your Collections Status Code]. U dient uw Epic systeembeheerders te raadplegen of de relevante stamgegevensbestanden, zoalsZC_TX_TYPEofZC_ACCOUNT_STATUS, te bekijken om de juiste codes voor uw instance te vinden. - Filteren: Voor betere prestaties en een gerichtere analyse voegt u filters toe aan de initiële
BaseAccountsCTE. Veelvoorkomende filters zijn onder meerSERV_AREA_IDom te beperken per ziekenhuis servicegebied ofACCOUNT_CLASS_Com te focussen op Inpatient of Outpatient facturatie.
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
- Databaseverbinding tot stand brengen: Verkrijg alleen-lezen inloggegevens voor de Epic Clarity database. Gebruik een standaard SQL client, zoals DBeaver of Microsoft SQL Server Management Studio, om verbinding te maken met de databaseserver.
- Kerntabellen identificeren: De primaire tabellen voor deze extractie omvatten
HSP_ACCOUNTvoorcaseinformatie,HSP_TRANSACTIONSvoor financiëleevents,CLP_CLAIM_INFOvoor claimstatus, enF_ARHB_TX_SET_POST_HXvoorpayment postingdetails. U zult ook master files zoalsCLARITY_EMPjoinen voor gebruikersdetails. - Bereik definiëren: Bepaal, voordat u de query schrijft, het bereik van uw analyse. Definieer een specifiek datumbereik, typisch 3 tot 6 maanden, en identificeer eventuele specifieke ziekenhuis servicegebieden (
SERV_AREA_ID) of accountklassen die u wilt opnemen of uitsluiten. - De SQL-query ontwikkelen: Construeer een SQL-query met behulp van een Common Table Expression (CTE) om eerst de set van
HSP_ACCOUNT_ID-waarden te selecteren die binnen uw gedefinieerde bereik vallen. Dit dient als de basispopulatie vanbilling events. - Individuele Activiteitenqueries samenvoegen: Voor elk van de 12 vereiste activiteiten schrijft u een aparte
SELECTstatement die data ophaalt uit de relevante tabellen. Join terug naar uw initiële CTE om te garanderen dat u alleen de beoogde accounts analyseert. - Queries combineren met UNION ALL: Gebruik de
UNION ALLoperator om de resultaten van alle individuele activiteitenqueries te combineren tot één samenhangendeevent log. Dit stapelt de rijen van elke query verticaal. - Toewijzen aan Standaard Schema: In elke
SELECTstatement, alias de kolommen om te matchen met het vereiste ProcessMind schema:BillingEvent,ActivityName,EventTimestamp,ResponsibleUser, etc. GebruikNULLvoorattributesdie niet van toepassing zijn op een specifieke activiteit. - De Query uitvoeren en verfijnen: Voer de complete query uit tegen de Clarity database. Vanwege de grootte van de tabellen kan dit aanzienlijk veel tijd in beslag nemen. Als
performanceeen probleem is, beperk dan het datumbereik verder of voeg meer specifieke filters toe in de initiële CTE. - De Output controleren: Zodra de query is voltooid, inspecteert u de eerste paar honderd rijen van de output. Verifieer dat alle kolommen aanwezig zijn,
timestampsin een consistent formaat zijn en verschillendeActivityNamewaarden verschijnen zoals verwacht. - Exporteren naar CSV: Exporteer de gehele resultaatset vanuit uw SQL client naar een CSV-bestand. Zorg ervoor dat het bestand UTF-8-codering gebruikt en een
header rowbevat met de juiste kolomnamen. - Voorbereiden voor Upload: Voordat u uploadt naar ProcessMind, opent u het CSV-bestand om te bevestigen dat er geen formatteringsfouten zijn. Controleer of het
timestampformaat consistent is, for example,YYYY-MM-DD HH:MI:SS. Het bestand is nu klaar vooringestion.
Configuratie
- Databaseverbinding: Een alleen-lezen gebruikersaccount met toegang tot de Epic Clarity database is vereist.
- Datumbereikparameters: De meegeleverde query gebruikt de variabelen
@StartDateen@EndDate. Deze moeten worden ingesteld om de analyseperiode te definiëren. Een bereik van 3 tot 6 maanden wordt aanbevolen om het gegevensvolume en de prestaties in evenwicht te houden. - Tabel- en Kolomtoewijzing: De query gaat uit van standaard Clarity tabel- en kolomnamen. De specifieke Epic-configuratie of -versie van uw organisatie kan afwijkingen vertonen. Mogelijk moet u tabelnamen, kolomnamen of join-condities dienovereenkomstig aanpassen.
- Transactie- en Statuscodes: De query bevat placeholders zoals
[Your Denial Tx Type]en[Your Collections Status Code]. U dient uw Epic systeembeheerders te raadplegen of de relevante stamgegevensbestanden, zoalsZC_TX_TYPEofZC_ACCOUNT_STATUS, te bekijken om de juiste codes voor uw instance te vinden. - Filteren: Voor betere prestaties en een gerichtere analyse voegt u filters toe aan de initiële
BaseAccountsCTE. Veelvoorkomende filters zijn onder meerSERV_AREA_IDom te beperken per ziekenhuis servicegebied ofACCOUNT_CLASS_Com te focussen op Inpatient of Outpatient facturatie.
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;