Je Revenue Cycle Management datatemplate
Je Revenue Cycle Management datatemplate
- Aanbevolen attributen om vast te leggen
- Belangrijkste activiteiten om te volgen
- Extractiehandleiding voor Oracle Health-omzetcyclusbeheer
Revenue Cycle Management Attributen
| Naam | Beschrijving | ||
|---|---|---|---|
| Activiteitsnaam ActivityName | De naam van de specifieke stap of gebeurtenis die plaatsvond binnen het revenue cycle proces. | ||
| Beschrijving Dit attribuut registreert de naam van elke activiteit die wordt uitgevoerd binnen de levenscyclus van een facturatie-gebeurtenis. Voorbeelden zijn 'Charges Captured', 'Claim Submitted To Payer' en 'Payment Posted'. Deze activiteiten vormen de stappen van de bekijkte proceskaart. Het analyseren van de volgorde en frequentie van activiteiten vormt de kern van process mining. Dit attribuut helpt bij het vinden van de meest voorkomende procespaden, het bekijken van afwijkingen van de standaardprocedure en het begrijpen van de operationele flow van de omzetcyclus. Waarom het belangrijk is Het definieert de stappen in het proces, wat de visualisatie van de proceskaart en analyse van Waar te verkrijgen Doorgaans afgeleid uit event logs, statuswijzigings of specifieke transactietabellen die gekoppeld zijn aan verschillende stadia van de omzetcyclus in Oracle Health. Voorbeelden Claim GegenereerdRemittance OntvangenAfwijzing AangevochtenAccount Afgesloten | |||
| Facturatie `Event` BillingEvent | De unieke kenmerk voor een enkele service- of productlevering die een kostenpost genereert, dienend als de case kenmerk voor het revenue cycle proces. | ||
| Beschrijving Het Billing Event fungeert als de primaire case kenmerk, die alle activiteiten van kostenregistratie tot accountafsluiting koppelt voor een afzonderlijk factureerbaar item. Elk Billing Event vertegenwoordigt een unieke instantie van het omzetcyclus-proces, waardoor de reis door verschillende stadia, zoals claimindiening, betalingsboeking en mogelijke afwijzingen of aanpassingen, volledig kan worden gevolgd. In process mining-analyse is dit attribuut onmisbaar bij het reconstrueren van de end-to-end processtroom. Het maakt de visualisatie van procesvarianten, de berekening van cyclustijden tussen activiteiten en de identificatie van knelpunten of afwijkingen die verband houden met specifieke factureerbare gebeurtenissen mogelijk. Waarom het belangrijk is Dit is de onmisbaar voor het volgen van de gehele levenscyclus van een factureerbare service, waardoor alle processtroomanalyse en prestatiemeting mogelijk worden. Waar te verkrijgen Deze kenmerk moet een unieke sleutel zijn die aanwezig is in de kernfacturatie- of kosten-transactietabellen binnen Oracle Health-omzetcyclusbeheer. Raadpleeg de systeemdocumentatie om de primary key voor kosten-gebeurtenissen te vinden. Voorbeelden BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| Tijdstempel EventTimestamp | De exacte datum en tijd waarop een activiteit in het systeem werd geregistreerd. | ||
| Beschrijving Dit attribuut levert de timestamp voor elke activiteit, die het exacte moment markeert waarop deze plaatsvond. Het is belangrijk voor het begrijpen van de timing en volgorde van gebeurtenissen binnen de omzetcyclus voor een specifieke facturatie-gebeurtenis. In analyse wordt de Event Timestamp gebruikt om activiteiten chronologisch te ordenen, looptijden en cyclustijden tussen verschillende stappen te berekenen en knelpuntanalyse uit te voeren. Het vormt de basis voor alle tijdgebonden process mining meetwaarden, zoals het vinden van vertragingen tussen 'Claim Submitted' en 'Remittance Received'. Waarom het belangrijk is Deze timestamp is belangrijk voor het ordenen van gebeurtenissen, het berekenen van alle prestatie meetwaarden zoals cyclustijden en looptijden, en het vinden van procesknelpunten. Waar te verkrijgen Elke transactie- of Voorbeelden 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| Afwijzingsredencode DenialReasonCode | Een gestandaardiseerde code die de reden aangeeft waarom een claim door de betaler werd afgewezen. | ||
| Beschrijving Wanneer een betaler een claim afwijst, geeft deze een redencode op die de afwijzing verklaart, zoals 'Niet-gedekte service' of 'Duplicatie claim'. Dit attribuut legt die code en de bijbehorende beschrijving vast. Het analyseren van afwijzingsredenen is onmisbaar voor het verbeteren van de omzetcyclus. Het stelt de organisatie in staat om veelvoorkomende patronen te vinden, zoals problemen met codering of patiëntgeschiktheid, en corrigerende maatregelen te implementeren om toekomstige afwijzingen te voorkomen. Dit heeft directe impact op de clean claim rate en vermindert de kosten van herstelwerk. Waarom het belangrijk is Biedt de grondoorzaak voor claimafwijzingen, waardoor gerichte verbeteringen mogelijk zijn om het percentage 'schone' claims te verhogen en de omzetinning te versnellen. Waar te verkrijgen Deze Informatie wordt ontvangen in het elektronische betalingsadvies (ANSI 835 bestand) van de betaler en moet worden opgeslagen in de claim- of betalingstabellen in Oracle Health. Voorbeelden CO-16: Claim/service mist Informatie die nodig is voor de afhandeling.PR-96: Niet-gedekte `charge`(s).CO-18: Dubbele claim/service. | |||
| Correctiebedrag AdjustmentAmount | De financiële waarde van eventuele aanpassingen aan het accountsaldo. | ||
| Beschrijving Dit attribuut legt het bedrag vast van elke financiële aanpassing, zoals contractuele kortingen, afschrijvingen of correcties, die op de facturatie-gebeurtenis wordt toegepast. Aanpassingen verminderen direct de verwachte omzet uit een kostenpost. Het 'Account Adjustment Impact' dashboard is sterk afhankelijk van dit attribuut. Het analyseren van aanpassingsbedragen en de bijbehorende redenen helpt bij het vinden van bronnen van omzetverlies, problemen met contractbeheer of knelpunten in het initiële proces van kostenregistratie. Het is een belangrijke metriek voor financiële gezondheid. Waarom het belangrijk is Kwantificeert omzetverlies als gevolg van afschrijvingen of correcties, en helpt bij het vinden en aanpakken van grondoorzaken van financiële erosie. Waar te verkrijgen Gevonden in Voorbeelden -50.25-120.0025.00 | |||
| Facturatieafdeling BillingDepartment | De afdeling of het functionele team dat verantwoordelijk is voor de activiteit. | ||
| Beschrijving Dit attribuut specificeert de afdeling, zoals 'Charge Capture', 'Coding' of 'Collections', die de activiteit heeft uitgevoerd. Het biedt een organisatorische context aan de processtroom. Het analyseren van het proces vanuit een afdelingsperspectief is belangrijk voor het begrijpen van overdrachten tussen teams en het vinden van cross-functionele inefficiënties. Het ondersteunt het 'Billing Department Workload' dashboard door het aggregeren van activiteiten en prestatie meetwaarden op afdelingsniveau mogelijk te maken. Waarom het belangrijk is Wijs activiteiten toe aan organisatie-eenheden, wat belangrijk is voor het analyseren van interdepartementale overdrachten, Waar te verkrijgen Deze Informatie kan direct worden opgeslagen bij de gebruikersprofiel data in Oracle Health of worden afgeleid op basis van de gebruiker of het activiteitstype. Voorbeelden PatiënttoegangCoderingFacturatieIncasso | |||
| Gebruiker UserPerformingAction | De gebruikers-id of naam van de persoon die de activiteit uitvoerde. | ||
| Beschrijving Dit attribuut identificeert de medewerker of geautomatiseerde systeemgebruiker die verantwoordelijk is voor het uitvoeren van een specifieke activiteit in het proces. Het is belangrijk voor het begrijpen van de werkverdeling, bron prestaties en het vinden van trainingsbehoeften. In analyse maakt dit attribuut het mogelijk om de proceskaart te filteren op gebruiker of team, prestaties te vergelijken tussen verschillende bronnen en de werkdruk te analyseren voor het 'Billing Department Workload' dashboard. Het kan helpen bij het vinden van best presterende medewerkers of individuen die extra ondersteuning of training nodig hebben. Waarom het belangrijk is Koppelt procesactiviteiten aan specifieke gebruikers of teams, enabling Waar te verkrijgen Gebruikers-ID velden (bijv. 'CREATED_BY', 'USER_ID') zijn doorgaans aanwezig in transactietabellen binnen de Oracle Health modules. Voorbeelden j.doeasmithBillingBot_AUTOk.williams | |||
| Naam Betaler PayerName | De naam van de verzekeringsmaatschappij of derde betaler die verantwoordelijk is voor de betaling. | ||
| Beschrijving Dit attribuut identificeert de entiteit, zoals een verzekeringsmaatschappij of overheidsprogramma zoals Medicare, die wordt gefactureerd voor de service. Payer-Informatie is onmisbaar voor revenue cycle analyse. Het analyseren van het proces per betaler kan aanzienlijke variaties in betalingstijden, afwijzingspercentages en succespercentages van beroepen zichtbaar maken. Het helpt bij het vinden van problematische betalers die vertragingen of omzetverlies veroorzaken en is belangrijk voor het effectief beheren van betalerscontracten en -relaties. Waarom het belangrijk is Maakt segmentatie van het proces per betaler mogelijk, wat verschillende gedragingen, afwijzingspercentages en betalingssnelheden onthult – belangrijk voor de financiële prestaties. Waar te verkrijgen Deze Informatie is opgeslagen in de facturatie- of verzekeringsgegevens van de patiënt binnen Oracle Health-omzetcyclusbeheer. Voorbeelden AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| Openstaand Saldo OutstandingBalance | Het resterende onbetaalde saldo voor de facturatie-gebeurtenis op een bepaald moment. | ||
| Beschrijving Dit attribuut toont het actuele openstaande bedrag dat verschuldigd is voor een facturatie-gebeurtenis nadat alle betalingen en aanpassingen zijn toegepast. Het vertegenwoordigt de actieve debiteuren voor die specifieke kostenpost. Dit is een onmisbaar attribuut voor het 'Outstanding Balance Aging' dashboard. Het analyseren van deze waarde over tijd helpt bij het monitoren van de snelheid van de cashflow, het beoordelen van de effectiviteit van incasso-inspanningen en het berekenen van belangrijke financiële KPI's zoals Days Sales Outstanding (DSO). Waarom het belangrijk is Volgt de huidige debiteuren voor elke case, wat belangrijk is voor het beheren van de cashflow en het analyseren van de effectiviteit van incasso's. Waar te verkrijgen Deze waarde wordt doorgaans berekend uit de som van alle financiële transacties (kosten, betalingen, aanpassingen) voor een gegeven facturatie-gebeurtenis. Het kan bestaan als een veld in een accountsamenvattingstabel. Voorbeelden 75.000.00550.80 | |||
| Patiënt Klasse PatientClass | De classificatie van de patiëntenontmoeting, zoals Klinisch of Poliklinisch. | ||
| Beschrijving Dit attribuut categoriseert het type patiëntbezoek of -ontmoeting dat de kostenpost heeft gegenereerd. Gangbare classificaties zijn Klinisch (Inpatient), Poliklinisch (Outpatient), Spoedeisend (Emergency) en Herhalende Patiënt (Recurring Patient). De patiëntklasse dicteert vaak het gehele facturatie- en claimindieningsproces. Verschillende patiëntklassen volgen afzonderlijke procespaden en hebben verschillende compliance vereisten. Het analyseren van het proces op basis van dit attribuut helpt om deze variaties te begrijpen, verbeterinitiatieven aan te passen en ervoor te zorgen dat de juiste procedures voor elke klasse worden gevolgd. Waarom het belangrijk is Scheidt verschillende processtromen (bijv. klinisch versus poliklinisch) die uiteenlopende complexiteiten, doorlooptijden en facturatievereisten hebben. Waar te verkrijgen Dit is een standaardveld dat geassocieerd is met een patiëntenontmoeting of opnamerecord in Oracle Health. Voorbeelden OpnamePoliklinischNoodgevalTerugkerend | |||
| Bronsysteem SourceSystem | Het systeem waaruit de gebeurtenisdata is opgehaald. | ||
| Beschrijving Dit attribuut identificeert de bronapplicatie of -module waar de data vandaan komt. Voor dit proces zal dit typisch 'Oracle Health-omzetcyclusbeheer' zijn, maar het kan ook verschillende modules binnen het systeem specificeren als data vanuit meerdere plaatsen wordt geïntegreerd. Deze Informatie is waardevol voor data governance en probleemoplossing. Het helpt de data lineage te bevestigen en is belangrijk in omgevingen waar meerdere systemen bijdragen aan één end-to-end proces. Waarom het belangrijk is Biedt context over de Waar te verkrijgen Dit is vaak een statische waarde die wordt toegevoegd tijdens het data-extractie, transformatie en laad (ETL) proces om de herkomst van de dataset te labelen. Voorbeelden OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| Claim-ID ClaimId | De unieke kenmerk voor de verzekeringsclaim die bij een betaler is ingediend. | ||
| Beschrijving Dit attribuut is de unieke ID die wordt toegewezen aan een claim die wordt gegenereerd en naar een betaler wordt gestuurd voor vergoeding. Eén facturatie-gebeurtenis kan gedurende de levenscyclus leiden tot één of meerdere claims, bijvoorbeeld als een correctie nodig is. Het gebruik van de Claim ID maakt het mogelijk om een specifieke indiening bij een betaler te traceren en deze direct te koppelen aan de respons, zoals een betaling of afwijzing. Het biedt een gedetailleerder niveau van tracking binnen het bredere revenue cycle proces. Waarom het belangrijk is Biedt een specifieke ID om het traject van een claim bij een betaler te volgen, wat gedetailleerder is dan het algemene facturatie Waar te verkrijgen Deze ID wordt gegenereerd door Oracle Health wanneer een claim wordt aangemaakt en wordt opgeslagen in de primaire claims-tabel. Voorbeelden CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| Eindtijd van het gebeurtenis EventEndTime | De timestamp die de voltooiing van een activiteit markeert, indien beschikbaar. | ||
| Beschrijving Terwijl StartTime het begin van een activiteit markeert, markeert EventEndTime de voltooiing ervan. Niet alle activiteiten hebben een duidelijke eindtijd, aangezien veel gebeurtenissen instantane zijn. Echter, voor activiteiten die een duur hebben, zoals 'Denial Appealed' (beroep op afwijzing ingediend) dat tijd kan kosten om te processen, is dit veld zeer nuttig. Dit attribuut maakt een nauwkeurigere berekening van de verwerkingstijd voor individuele activiteiten mogelijk. Het helpt onderscheid te maken tussen wachttijd (tijd tussen activiteiten) en verwerkingstijd (tijd besteed aan een activiteit). Waarom het belangrijk is Maakt de directe berekening mogelijk van hoe lang een activiteit duurt, waarbij verwerkingstijd wordt gescheiden van wachttijd. Waar te verkrijgen Sommige transactietabellen in Oracle Health-omzetcyclusbeheer kunnen zowel een start- als een eind-timestamp bevatten voor specifieke, langlopende taken. Voorbeelden 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| Factuurbedrag ChargeAmount | De bruto financiële waarde van de gefactureerde service of product. | ||
| Beschrijving Dit attribuut vertegenwoordigt het initiële, onverdisconteerde bedrag dat in rekening wordt gebracht voor een service voordat enige aanpassingen, contractuele kortingen of betalingen worden toegepast. Het is de startwaarde voor de financiële facturatie-gebeurtenis. Het volgen van het kostenbedrag is belangrijk voor financiële analyse, zoals het berekenen van de totale waarde van geleverde services en het begrijpen van de financiële impact van daaropvolgende aanpassingen of afschrijvingen. Het dient als basis voor het meten van omzetrealisatie. Waarom het belangrijk is Stelt de initiële financiële waarde van de Waar te verkrijgen Gevonden in de Voorbeelden 150.001250.7585.50 | |||
| Is Geautomatiseerd IsAutomated | Een indicator die aangeeft of de activiteit werd uitgevoerd door een geautomatiseerd systeem of een menselijke gebruiker. | ||
| Beschrijving Dit boolean attribuut maakt onderscheid tussen activiteiten die worden uitgevoerd door software-automatisering, zoals bots of systeem batch jobs, en activiteiten die handmatig door een gebruiker worden uitgevoerd. Bijvoorbeeld, 'Claim Generated' kan een geautomatiseerde stap zijn, terwijl 'Denial Appealed' waarschijnlijk handmatig is. Het analyseren van dit attribuut helpt bij het begrijpen van het automatiseringsniveau in het proces en de impact ervan op efficiëntie en foutpercentages. Het kan worden gebruikt om de prestaties van geautomatiseerde versus handmatige paden te vergelijken en mogelijkheden voor verdere automatisering te vinden. Waarom het belangrijk is Maakt onderscheid tussen menselijke en systeemgestuurde activiteiten, wat belangrijk is voor het analyseren van de effectiviteit van automatisering en het vinden van nieuwe automatiseringskansen. Waar te verkrijgen Dit wordt doorgaans afgeleid op basis van het GebruikerPerformingAction attribuut. Activiteiten die worden uitgevoerd door gebruikers-id's zoals 'SYSTEM' of 'RPA_BOT' worden bijvoorbeeld als geautomatiseerd gemarkeerd. Voorbeelden truefalse | |||
| Is herstelwerk IsRework | Een vlag die activiteiten identificeert die `herstelwerk` of herhaalde inspanningen vertegenwoordigen. | ||
| Beschrijving Dit berekende attribuut markeert activiteiten die een afwijking van het ideale 'happy path' aangeven en neerkomen op herstelwerk. Voorbeelden zijn 'Corrected Claim Submitted' of 'Denial Appealed', die niet zouden voorkomen als het proces de eerste keer perfect verliep. Het vinden en kwantificeren van herstelwerk is een belangrijk doel van process mining. Deze vlag maakt eenvoudig filteren en analyseren van alle herstelwerk-loops mogelijk, wat helpt bij het meten van de frequentie, kosten en oorzaken van procesinefficiënties. Het is belangrijk voor het begrijpen van de werkelijke kosten van kwaliteit in de revenue cycle. Waarom het belangrijk is Helpt de frequentie en impact van Waar te verkrijgen Dit is een afgeleid attribuut. Het wordt berekend tijdens datatransformatie door bedrijfslogica toe te passen die specifieke activiteitsnamen markeert als herstelwerk. Voorbeelden truefalse | |||
| Patiënt ID PatientId | De unieke kenmerk voor de patiënt die gekoppeld is aan de facturatie-gebeurtenis. | ||
| Beschrijving Dit attribuut is de unieke kenmerk voor de patiënt die de service heeft ontvangen, vaak bekend als het Medisch Dossier Nummer (MDN). Het koppelt de financiële transactie aan een specifiek individu. Hoewel het niet de case ID voor het proces is, is de Patient ID nuttig voor het aggregeren van alle facturatie-gebeurtenissen voor één patiënt om hun gehele financiële traject te begrijpen. Het maakt ook segmentatie mogelijk op basis van patiëntdemografie of geschiedenis indien gekoppeld met patiëntstamdata. Waarom het belangrijk is Koppelt financiële Waar te verkrijgen Deze kenmerk is een kernelement van de patiëntenstamkaart en zal aanwezig zijn in alle gerelateerde transactietabellen zoals kosten, claims en betalingen. Voorbeelden MRN-1002345MRN-1002346MRN-1002347 | |||
| Reden Geschil DisputeReason | De reden die door de klant of patiënt wordt opgegeven voor het betwisten van een factuur of kostenpost. | ||
| Beschrijving Dit attribuut legt de reden vast waarom een patiënt of andere verantwoordelijke partij een factuur heeft betwist. Redenen kunnen incorrecte kosten, niet-geleverde services of problemen met de verzekeringsafhandeling omvatten. Deze Informatie is belangrijk voor het 'Invoice Dispute Resolution Kengetallen' dashboard. Inzicht in de meest voorkomende redenen voor geschillen helpt bij het vinden van systemische problemen in de processen van kostenregistratie, codering of facturatie. Het aanpakken van deze hoofdoorzaken kan de geschillenratio en de administratieve overhead die nodig is om ze op te lossen aanzienlijk verminderen. Waarom het belangrijk is Verklaart waarom facturen worden betwist, en biedt direct inzicht in problemen met de factuurnauwkeurigheid of -duidelijkheid die moeten worden opgelost. Waar te verkrijgen Dit wordt waarschijnlijk opgeslagen in een case management of customer service module binnen Oracle Health, gekoppeld aan het account van de patiënt. Voorbeelden Onjuist Gefactureerde ServiceDubbele ChargeVerzekering Onjuist GefactureerdDienst Niet Geleverd | |||
| Tijdstip van extractie LastDataUpdate | De timestamp die aangeeft wanneer de data voor dit gebeurtenis voor het voor het laatst is bijgewerkt of opgehaald. | ||
| Beschrijving Dit attribuut toont wanneer de dataset voor het laatst is bijgewerkt. Het geeft context over de relevantie van de geanalyseerde data, wat belangrijk is voor het begrijpen van de tijdigheid van de inzichten die voortvloeien uit de process mining-analyse. Gebruikers kunnen dit attribuut controleren om te bevestigen dat ze de meest recente procesInformatie bekijken. Het helpt verwachtingen te beheren over de relevantie van de data en is een belangrijk onderdeel van data governance en kwaliteitsborging. Waarom het belangrijk is Geeft de relevantie van de Waar te verkrijgen Dit is een metadataveld dat doorgaans wordt gegenereerd en gevuld tijdens het ETL-proces dat data in het process mining platform laadt. Voorbeelden 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
Revenue Cycle Management Activiteiten
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Account Afgesloten | De laatste activiteit, die aangeeft dat het accountsaldo nul is en er geen verdere activiteit wordt verwacht. Dit wordt vaak afgeleid wanneer het accountsaldo nul bereikt. | ||
| Waarom het belangrijk is Markeert de succesvolle voltooiing van de Waar te verkrijgen Dit wordt doorgaans afgeleid door de eerste keer te vinden dat het openstaande saldo van het account nul wordt en nul blijft na alle betalingen en aanpassingen. Vastleggen Berekend wanneer het accountsaldo voor het eerst nul is nadat alle Gebeurtenistype calculated | |||
| Betaling Geboekt | Vertegenwoordigt de toepassing van de ontvangen betaling van de betaler op de corresponderende `charges` op de patiëntenrekening. Dit is een financiële transactie vastgelegd door een gebruiker of een geautomatiseerd proces. | ||
| Waarom het belangrijk is De efficiëntie van het boeken van betalingen beïnvloedt de nauwkeurigheid van de debiteuren. Vertragingen hier kunnen het financiële beeld verstoren en secundaire facturatie vertragen. Waar te verkrijgen Gevonden in de Vastleggen Een financiële transactie wordt vastgelegd wanneer de betaling op de rekening wordt toegepast. Gebeurtenistype explicit | |||
| Claim Gegenereerd | Markeert het punt waarop individuele `charges` worden samengesteld tot een formele `billing claim`, zoals een UB-04 of CMS-1500. Dit is een systeemgegenereerd `gebeurtenis` dat de initiële factuur creëert. | ||
| Waarom het belangrijk is Dit is een belangrijke mijlpaal die de gereedheid aangeeft om een betaler te factureren. Het is het eindpunt voor het meten van de interne kosten-tot-factuur vertraging. Waar te verkrijgen Een expliciet Vastleggen
Gebeurtenistype explicit | |||
| Claim Ingediend bij Betaler | Vertegenwoordigt de elektronische of papieren indiening van de gegenereerde claim bij de verzekeringsmaatschappij of betaler. Het systeem moet de datum en tijd van deze transmissie vastleggen. | ||
| Waarom het belangrijk is Deze activiteit start de betalingscyclus. Het analyseren van de tijd van indiening tot betaling is belangrijk om de prestaties van de betaler en de Days Sales Outstanding (DSO) te begrijpen. Waar te verkrijgen Afkomstig uit de claims management module, die transmissie-gebeurtenissen logt. Zoek naar een indienings-timestamp of een statuswijziging naar 'Ingediend' in de declaratiegeschiedenis. Vastleggen
Gebeurtenistype explicit | |||
| Patiënt `Encounter` Aangemaakt | Markeert de creatie van een patiëntenrekening voor een specifiek bezoek of service. Dit is doorgaans een expliciet `gebeurtenis` dat wordt geactiveerd door het registratiesysteem of een `Admit/Discharge/Transfer (ADT) feed`. | ||
| Waarom het belangrijk is Het dient als startpunt voor de gehele Waar te verkrijgen Afkomstig uit de Patient Registration of ADT module logs. Zoek naar 'encounter creation gebeurtenissen' of de vroegste timestamp die gekoppeld is aan de encounter of het financiële nummer. Vastleggen
Gebeurtenistype explicit | |||
| Account Aangepast | Vertegenwoordigt een financiële aanpassing aan het accountsaldo, zoals een contractuele korting, een afschrijving of een korting. Elke aanpassing is een afzonderlijke financiële transactie. | ||
| Waarom het belangrijk is Aanpassingen hebben directe invloed op de omzet. Het analyseren van hun frequentie, type en bedrag helpt om omzetverlies en facturatieonjuistheden te vinden. Waar te verkrijgen Gevonden in Vastleggen Een financiële transactie wordt vastgelegd met een specifieke correctiecode. Gebeurtenistype explicit | |||
| Afwijzing Aangevochten | Een gebruikers- of systeemactie die aangeeft dat een afgewezen claim wordt aangevochten. Dit wordt doorgaans vastgelegd als een statusupdate of een specifieke taak die in een `work queue` is aangemaakt. | ||
| Waarom het belangrijk is Deze activiteit initieert een herstelwerk loop. Het analyseren van de frequentie en het succespercentage van beroepen is belangrijk voor het optimaliseren van de inspanningen voor omzetherstel. Waar te verkrijgen Dit kan een expliciet door de gebruiker geïnitieerd gebeurtenis zijn of worden afgeleid uit een statuswijziging van de claim, zoals 'Appealed' (in beroep gegaan) of 'In Review' (in behandeling). Vastleggen Een statuswijziging of vastgelegd Gebeurtenistype explicit | |||
| Afwijzing Ontvangen | Markeert het `gebeurtenis` waarbij de betaler een claim of specifieke regelitems heeft afgewezen, zoals aangegeven in het `remittance` advies. Dit `gebeurtenis` wordt vaak afgeleid van `denial codes` die aanwezig zijn in de `remittance data`. | ||
| Waarom het belangrijk is Het volgen van afwijzingen is belangrijk voor het vinden van hoofdoorzaken, zoals coderingsfouten of geschiktheidsproblemen, en het verbeteren van de clean claim rate. Waar te verkrijgen Afgeleid van de Vastleggen Afgeleid van Gebeurtenistype inferred | |||
| Charges Gecodeerd | Vertegenwoordigt het proces waarbij medische codeurs gestandaardiseerde codes, zoals CPT of ICD-10, toewijzen aan de vastgelegde `charges`. Dit wordt vaak gevolgd door een statuswijziging op de `charge` of `encounter`. | ||
| Waarom het belangrijk is Vertragingen in de codering zijn een veelvoorkomende Waar te verkrijgen Vaak afgeleid van een statuswijziging op de patiënt Vastleggen Afgeleid van een wijziging in de Gebeurtenistype inferred | |||
| Charges Vastgelegd | Vertegenwoordigt de invoer van factureerbare diensten of items in de patiëntenrekening. Dit kan automatisch gebeuren vanuit klinische systemen of via handmatige invoer door personeel. | ||
| Waarom het belangrijk is Deze activiteit is belangrijk voor het meten van de 'charge lag', de tijd tussen servicelevering en de start van de facturatie, wat direct van invloed is op de cashflow en de integriteit van de omzet. Waar te verkrijgen Vastgelegd vanuit Vastleggen Transactielog-item aangemaakt voor elke nieuwe kostenpost. Gebeurtenistype explicit | |||
| Gecorrigeerde Claim Ingediend | Vertegenwoordigt de indiening van een herziene of gecorrigeerde declaratie bij de betaler, vaak na een afwijzing of verzoek om meer Informatie. Dit wordt geïdentificeerd door een nieuwe declaratie-indiening met een correctie-indicator. | ||
| Waarom het belangrijk is Deze activiteit is een belangrijk onderdeel van de denial management herstelwerk loop. Een hoge frequentie duidt op problemen met de initiële claimnauwkeurigheid. Waar te verkrijgen Vastgelegd vanuit de Vastleggen Vastgelegd Gebeurtenistype explicit | |||
| Incasso Activiteit Gestart | Geeft aan dat de patiëntenrekening is overgeheveld naar een `collections` proces vanwege wanbetaling. Dit wordt doorgaans vastgelegd door een wijziging in de financiële- of statusklasse van het account. | ||
| Waarom het belangrijk is Dit is een kritieke stap voor het beheer van dubieuze debiteuren. Het analyseren van wat tot dit stadium leidt en het succespercentage ervan is belangrijk voor financiële gezondheid. Waar te verkrijgen Afgeleid van een wijziging in het accountstatusveld naar 'Collections' of 'Bad Debt'. Deze statuswijziging moet een bijbehorende Vastleggen Afgeleid van een accountstatuswijziging naar een 'Collections' of vergelijkbare status. Gebeurtenistype inferred | |||
| Patiëntoverzicht Verzonden | Markeert het `gebeurtenis` waarbij een factuur voor de resterende patiëntverantwoordelijkheid wordt gegenereerd en naar de patiënt wordt verzonden. Dit is een expliciete actie vastgelegd door de patiëntfacturatiemodule. | ||
| Waarom het belangrijk is Dit initieert het patiëntenbetalingsgedeelte van de omzetcyclus. Het volgen hiervan helpt bij het analyseren van de effectiviteit van patiëntenincasso's. Waar te verkrijgen Afkomstig uit patiëntfacturatie- of correspondentielogs. Het systeem moet de datum registreren waarop elk overzicht is gegenereerd of verzonden. Vastleggen
Gebeurtenistype explicit | |||
| Remittance Ontvangen | Geeft de ontvangst aan van een Electronic Remittance Advice (ERA) of een papieren Explanation of Benefits (EOB) van de betaler. Dit document detailleert welke `charges` zijn betaald, afgewezen of aangepast. | ||
| Waarom het belangrijk is Dit is de eerste reactie van de betaler en is belangrijk voor het begrijpen van de betalingssnelheid en het vroegtijdig vinden van afwijzingstrends. Waar te verkrijgen Vastgelegd in de Vastleggen
Gebeurtenistype explicit | |||
Extractiegidsen
Stappen
- Database Toegang Aanvragen: Verkrijg read-only inloggegevens voor de Oracle Health-omzetcyclusbeheer database. U heeft toegang nodig tot de schema's die patiënt-,
encounter-, facturatie- en financiële transactiedatabevatten. Dit vereist doorgaans goedkeuring van de IT-beveiligings- en databasebeheerteams. - Schema- en Tabelnamen Identificeren: Werk samen met een databasebeheerder of een systeemanalysest om de exacte schema- en tabelnamen voor uw Oracle Health-instantie te bevestigen. De namen die in de query worden verstrekt, zijn veelvoorkomende
placeholders en moeten worden gemapt naar uw specifieke omgeving. - Installeer een SQL Client: Installeer een compatibele SQL
client, zoals Oracle SQL Developer of DBeaver, op uw werkstation. Deze tool zal worden gebruikt om verbinding te maken met de database en het extractiescript uit te voeren. - Databaseverbinding Tot Stand Brengen: Configureer een nieuwe databaseverbinding in uw SQL
clientmet behulp van de opgegeven host, poort, servicenaam en inloggegevens. Test de verbinding om er zeker van te zijn dat deze succesvol is. - Pas de SQL Query aan: Kopieer het meegeleverde SQL-script naar een nieuw query-editorvenster. Zoek de
placeholderwaarden, zoals[START_DATE]en[END_DATE], en vervang deze door het gewenste datumbereik voor uw analyse (bijv. '2023-01-01'). Pas eventuele filtercondities aan op basis van uw specifieke analytische behoeften, zoals filteren op een bepaaldePatient Class. - Voer het Extractiescript uit: Voer het aangepaste SQL-script uit. De query is ontworpen om uitgebreid te zijn en kan, afhankelijk van het datumbereik en de grootte van je database, enkele minuten tot uren duren om te voltooien.
- Bekijk Initiële Resultaten: Zodra de query is voltooid, controleert u de eerste paar honderd rijen in het resultatenraster van uw SQL
client. Controleer op duidelijke fouten, zoals volledig lege kolommen of onjuistedataformaten, om er zeker van te zijn dat het script correct is uitgevoerd. - Exporteer Data naar CSV: Exporteer de gehele resultaatset naar een CSV-bestand. Gebruik UTF-8 codering om karakterproblemen te voorkomen. Zorg ervoor dat het geëxporteerde bestand een headerrij bevat met de kolomnamen die zijn gespecificeerd in de query
aliases(bijv. "BillingEvent", "ActiviteitNaam"). - Voorbereiden op Upload: Voordat u uploadt naar een
process miningtool, opent u het CSV-bestand om de integriteit ervan te bevestigen. Controleer of hettimestampformaat consistent is en of de kolomheaders exact overeenkomen met de vereisteattributen. Het bestand is nu klaar voor upload.
Configuratie
- Datumbereik: De query gebruikt de
[START_DATE]en[END_DATE]placeholders. Het is belangrijk om een specifiek en redelijk datumbereik te definiëren om hetdatavolume te beheersen. Een bereik van 3 tot 6 maanden wordt aanbevolen voor een initiële analyse. - Filtering: De initiële
data setwordt gefilterd op deencounterregistratiedatum (reg_dt_tm) in de sectieRelevantEncounters. U kunt andereWHERE-clausules aan deze sectie toevoegen om de reikwijdte te verfijnen, bijvoorbeelde.patient_class_code IN ('INPATIENT', 'OUTPATIENT')om u te richten op specifiekeencountertypen. - Prestaties: Directe databasequery's op een productiesysteem kunnen de prestaties beïnvloeden. Het wordt sterk aanbevolen om deze extractie uit te voeren buiten piekuren of, indien beschikbaar, op een read-only replica van de productiedatabase.
- Verplichten: Voor deze methode is een databasegebruikersaccount nodig met
SELECT-rechten op alle tabellen waarnaar in de query wordt verwezen. Deze tabellen omvattenencounter,billing,charge,claim,remittanceenfinancial transactiontabellen. - Tabel- en Kolom
Mapping: Het meegeleverde script gebruikt gangbare, representatieve namen voor tabellen en kolommen. U moet deze bevestigen en mappen naar de daadwerkelijke namen in het Oracle Health databaseschema van uw organisatie. Zo kanFINANCIAL_TRANSACTIONin je systeemAR_TRANSACTIONSheten.
a Voorbeeldquery sql
WITH RelevantEncounters AS (
SELECT
e.billing_event_id
FROM ENCOUNTER e
WHERE e.reg_dt_tm BETWEEN TO_DATE('[START_DATE]', 'YYYY-MM-DD') AND TO_DATE('[END_DATE]', 'YYYY-MM-DD')
)
SELECT
e.billing_event_id AS "BillingEvent",
'Patient Encounter Created' AS "ActivityName",
e.reg_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.reg_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cd.billing_event_id AS "BillingEvent",
'Charges Captured' AS "ActivityName",
cd.charge_entry_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cd.charge_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CHARGE_DETAIL cd
JOIN ENCOUNTER e ON cd.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cd.entry_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cd.performing_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
ch.billing_event_id AS "BillingEvent",
'Charges Coded' AS "ActivityName",
ch.coded_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CODING_HISTORY ch
JOIN ENCOUNTER e ON ch.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ch.coder_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cl.billing_event_id AS "BillingEvent",
'Claim Generated' AS "ActivityName",
cl.create_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM cl
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cl.create_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Claim Submitted To Payer' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'INITIAL'
UNION ALL
SELECT
ra.billing_event_id AS "BillingEvent",
'Remittance Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM REMITTANCE_ADVICE ra
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Payment Posted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'PAYMENT'
UNION ALL
SELECT
rd.billing_event_id AS "BillingEvent",
'Denial Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
rd.denial_reason_code AS "DenialReasonCode"
FROM REMITTANCE_DETAIL rd
JOIN REMITTANCE_ADVICE ra ON rd.remit_id = ra.remit_id
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
WHERE rd.denial_reason_code IS NOT NULL
UNION ALL
SELECT
at.billing_event_id AS "BillingEvent",
'Denial Appealed' AS "ActivityName",
at.appeal_filed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
at.related_denial_code AS "DenialReasonCode"
FROM APPEAL_TRACKING at
JOIN ENCOUNTER e ON at.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON at.appeal_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON at.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Corrected Claim Submitted' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'CORRECTED'
UNION ALL
SELECT
psl.billing_event_id AS "BillingEvent",
'Patient Statement Sent' AS "ActivityName",
psl.statement_sent_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
psl.statement_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM PATIENT_STATEMENT_LOG psl
JOIN ENCOUNTER e ON psl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON psl.sent_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
UNION ALL
SELECT
ash.billing_event_id AS "BillingEvent",
'Collection Activity Started' AS "ActivityName",
ash.status_change_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ash.account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ACCOUNT_STATUS_HISTORY ash
JOIN ENCOUNTER e ON ash.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ash.change_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ash.responsible_org_id = org.organization_id
WHERE ash.new_status_code = 'COLLECTIONS'
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Account Adjusted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
ft.transaction_amount AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
ft.adjustment_reason_code AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'ADJUSTMENT'
UNION ALL
SELECT
e.billing_event_id AS "BillingEvent",
'Account Closed' AS "ActivityName",
e.account_closed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
0 AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.closed_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
WHERE e.total_account_balance = 0 AND e.account_closed_dt_tm IS NOT NULL;