Šablona dat pro řízení výnosového cyklu
Šablona dat pro řízení výnosového cyklu
- Doporučené atributy ke sběru
- Důležité činnosti ke sledování
- Pokyny k extrakci dat
Atributy řízení výnosového cyklu
| Název | Popis | ||
|---|---|---|---|
| Časové razítko události EventTimestamp | Přesné datum a čas, kdy došlo ke konkrétní činnosti nebo události. | ||
| Popis Časové razítko události zaznamenává okamžik, kdy činnost proběhla. Tyto časové údaje jsou důležité pro pochopení načasování a pořadí událostí v cyklu výnosů. Při analýze se časová razítka používají k výpočtu doby mezi činnostmi, například prodlevy při zachycení výkonu nebo doby zaúčtování platby. Pomáhají odhalit úzká místa, měřit délku cyklu a analyzovat výkonnost procesu v různých obdobích. Přesná časová razítka jsou nezbytná pro většinu časových KPI a dashboardů. Proč je to důležité Tento atribut je nezbytný pro výpočet všech časových ukazatelů včetně délky cyklů a trvání. Tyto údaje pomáhají odhalit prodlevy a neefektivitu. Kde data získat Najdete ho v tabulkách transakcí nebo záznamů událostí v Epic Resolute, kde je přiřazen ke každé zaznamenané činnosti. Názvy polí často končí na Dt, DTTM nebo Time. Příklady 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Fakturační událost BillingEvent | Jedinečný identifikátor jednotlivého poskytnutí služby nebo produktu, za které vzniká poplatek. Slouží jako hlavní identifikátor případu. | ||
| Popis Fakturační událost je hlavní identifikátor, který propojuje všechny činnosti v cyklu výnosů pro konkrétní účtovatelnou položku. Začíná poskytnutím služby a končí úplným vypořádáním nebo uzavřením účtu. Při analýze pomocí process miningu je tento atribut nezbytný pro rekonstrukci celého průběhu každého výkonu. Umožňuje sledovat činnosti, jako je zachycení výkonu, odeslání nároku, zaúčtování platby a řešení zamítnutí, a to pro každou fakturační událost zvlášť. Získáte tak přehled o průběhu procesu i jeho odchylkách. Proč je to důležité Jde o základní ID případu, které propojuje všechny související kroky procesu. Díky němu lze analyzovat celý cyklus tvorby a inkasa výnosů za každou službu. Kde data získat Často jde o jedinečný identifikátor nemocničního účtu (HAR) nebo konkrétní relace účtování výkonů v Epic Resolute. Konkrétní tabulky, například záznamy HAR nebo Charge Session, najdete v dokumentaci Epic Resolute. Příklady BE10098765BE20012345BE30054321 | |||
| Název činnosti ActivityName | Název konkrétní události nebo úkolu provedeného v rámci procesu správy cyklu výnosů. | ||
| Popis Tento atribut popisuje jednotlivý krok cyklu výnosů, například „Zachycení účtovatelných výkonů“, „Odeslání nároku plátci“ nebo „Přijetí platby“. Každá činnost představuje samostatný milník při fakturaci a inkasu platby za službu. Analýza činností je základem process miningu. Umožňuje zobrazit mapu procesu, určit obvyklé cesty, odhalit úzká místa mezi kroky a měřit dodržování standardních pracovních postupů. Proč je to důležité Určuje kroky v mapě procesu a umožňuje zobrazit, analyzovat a zlepšovat tok práce v cyklu výnosů. Kde data získat Obvykle se odvozuje ze záznamů událostí, auditních stop nebo záznamů o změnách stavu v modulech fakturace a nároků Epic Resolute. Příklady Zachycení účtovatelných výkonůOdeslání nároku plátciPřijetí platbyUzavření účtu | |||
| Důvod úpravy AdjustmentReason | Důvod ruční nebo automatické úpravy zůstatku na účtu pacienta. | ||
| Popis Tento atribut vysvětluje, proč se zůstatek na účtu změnil jinak než běžnou platbou nebo zaúčtováním výkonu. Důvodem může být smluvní sleva od plátce, odpis nízkého zůstatku nebo oprava chyby při zaúčtování. Tento údaj je nezbytný pro dashboard „Objem úprav účtu podle typu“. Analýza důvodů úprav pomáhá odhalit zdroje úniku výnosů, pochopit dopad smluv s plátci a najít případnou neefektivitu nebo chyby ve fakturaci. Proč je to důležité Vysvětluje, proč se mění zůstatky na účtech, a pomáhá tak odhalit únik výnosů, posoudit přesnost fakturace a omezit zbytečné odpisy. Kde data získat Najdete ho v podrobnostech transakcí u úprav v modulu účtování pacientů Epic Resolute. Příklady Smluvní slevaOdpis nízkého zůstatkuOprava duplicitního výkonu | |||
| Kód důvodu zamítnutí DenialReasonCode | Standardizovaný kód označující důvod, proč plátce zamítl odeslaný nárok. | ||
| Popis Když plátce nárok zamítne, uvede kód důvodu, například „Služba není hrazena“, „Duplicitní nárok“ nebo „Je třeba doplnit informace“. Tyto kódy jsou často standardizovány jako Claim Adjustment Reason Codes (CARCs). Tento atribut je základem dashboardu „Míra a důvody zamítnutí nároků“. Analýza četnosti jednotlivých kódů pomáhá odhalit hlavní příčiny zamítnutí, například problémy s oprávněním poskytovatele, chyby v kódování nebo chybějící předchozí schválení. Organizace pak může cíleně zavádět zlepšení. Proč je to důležité Přímo vysvětluje, proč jsou nároky zamítány. Poskytuje tak informace potřebné ke snížení počtu zamítnutí, omezení ztráty výnosů a urychlení plateb. Kde data získat Tato data se nacházejí v transakcích s odpověďmi na nároky, například v souboru ANSI 835, které přijímáte od plátců a ukládáte v modulu správy nároků Epic Resolute. Příklady CO-16: V nároku nebo u služby chybí informaceOA-18: Duplicitní nárok nebo službaPR-96: Nehrazené poplatky | |||
| Nevyrovnaný zůstatek OutstandingBalance | Zbývající částka, kterou má za fakturační událost zaplatit plátce nebo pacient. | ||
| Popis Tento atribut představuje aktuální zůstatek pohledávky za konkrétní fakturační událost v okamžiku dané činnosti. Zachycuje finanční stav případu v průběhu celého jeho životního cyklu. Nevyrovnaný zůstatek je důležitý pro finanční výkaznictví i pro přehled o stárnutí pohledávek. Analýza jeho vývoje v čase a podle různých dimenzí, například plátce nebo oddělení, pomáhá stanovit priority inkasa, řídit peněžní tok a posoudit finanční riziko. Proč je to důležité Přímo měří finanční dopad prodlev v procesu. Je důležitý pro stanovení priorit inkasa, řízení peněžního toku a přehled o pohledávkách. Kde data získat Jde o základní pole v záznamu účtu pacienta nebo nemocničního účtu (HAR) v Epic Resolute. Obsahuje průběžný zůstatek aktualizovaný podle finančních transakcí. Příklady 1500.00250.750.00 | |||
| Oddělení fakturace BillingDepartment | Oddělení nebo funkční tým odpovědný za fakturační událost či činnost. | ||
| Popis Tento atribut označuje organizační jednotku, například „Fakturace hospitalizovaných pacientů“, „Fakturace ambulantních pacientů“ nebo „Tým pro správu zamítnutých nároků“, která souvisí s fakturační událostí nebo provedla konkrétní činnost. Tato dimenze je důležitá pro dashboard „Ukazatele výkonnosti oddělení fakturace“. Umožňuje porovnávat důležité ukazatele, například míru zamítnutí nebo dobu zachycení výkonů. Vedení díky tomu může určit nejvýkonnější oddělení, sjednotit osvědčené postupy a efektivně rozdělit zdroje. Proč je to důležité Umožňuje porovnávat výkonnost jednotlivých oddělení, odhalit osvědčené postupy i oblasti, které potřebují zlepšení nebo další zdroje. Kde data získat Tyto informace mohou být propojeny se záznamem uživatele, účtem pacienta nebo místem poskytnutí služby v Epic Resolute. Příklady Fakturace kardiologieRCM radiologieCentrální fakturační oddělení | |||
| Odpovědný uživatel ResponsibleUser | Identifikátor uživatele nebo zaměstnance, který činnost provedl. | ||
| Popis Tento atribut zachycuje ID uživatele, jméno nebo zaměstnanecké číslo osoby odpovědné za konkrétní úkol v cyklu výnosů. Může jít o lékaře, který zadal výkony, pracovníka fakturace, který odeslal nárok, nebo pracovníka inkasa, který řešil zamítnutí. Analýza podle uživatele pomáhá odhalit nejvýkonnější pracovníky, určit potřeby školení a porozumět rozložení pracovní zátěže. Je důležitá pro řízení výkonnosti i pro zkoumání odchylek v procesu spojených s konkrétními osobami nebo rolemi. Proč je to důležité Umožňuje analyzovat výkonnost jednotlivců i rolí a odhalit potřeby školení, nerovnoměrné rozložení práce a úzká místa související se zdroji. Kde data získat Obvykle se nachází v auditní stopě nebo transakčních protokolech Epic Resolute a často je propojen s tabulkou kmenových dat uživatelů, například záznamem EMP. Příklady j.doebsmith123User7890 | |||
| Typ služby ServiceType | Kategorie nebo typ poskytnuté zdravotní služby. | ||
| Popis Tento atribut klasifikuje účtovanou službu, například jako „radiologie“, „chirurgický zákrok“, „konzultace“ nebo „návštěva pohotovosti“. Finančním údajům tak dodává klinický kontext. Analýza výnosového cyklu podle typu služby může odhalit rozdíly v procesech jednotlivých klinických oborů. Chirurgické zákroky mohou například vyžadovat složitější vykazování výkonů a schvalování než běžná návštěva ordinace. Procesy se proto mohou lišit a přinášet jiné problémy. Proč je to důležité Doplňuje finanční údaje o klinický kontext a umožňuje analyzovat, jak různé typy zdravotních služeb ovlivňují proces výnosového cyklu a jeho efektivitu. Kde data získat Odvozuje se z číselníku účtovaných výkonů (CDM), servisní linie nebo oddělení přiřazeného k transakci zaúčtovaného výkonu v Epic. Příklady Chirurgický zákrok za hospitalizaceAmbulantní radiologiePohotovostní služby | |||
| Čas ukončení události EventEndTime | Časové razítko označující dokončení činnosti. Slouží k výpočtu její délky. | ||
| Popis Tento atribut zaznamenává čas dokončení činnosti. Mnohé činnosti jsou okamžité události, u nichž se StartTime rovná EndTime. Některé úkoly však mají měřitelnou dobu trvání, například telefonát v rámci následného řešení zamítnutého nároku. Pokud je EndTime k dispozici, lze dobu zpracování činnosti vypočítat přímo jako rozdíl „EndTime“ a „StartTime“. Tento výpočet je přesnější než odhad podle času zahájení následující činnosti, protože zohledňuje prodlevu mezi kroky. Atribut je důležitý pro výpočet hodnoty „ProcessingTime“. Proč je to důležité Umožňuje přesně vypočítat dobu potřebnou k dokončení každé činnosti. To je důležité pro odhalení neefektivních úkolů a měření produktivity zdrojů. Kde data získat Tento údaj může být dostupný v některých modulech Epic Resolute, které sledují začátek a konec úkolu, například v protokolech front práce nebo správy činností. Často se však výslovně nesleduje. Příklady 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| Celková doba výnosového cyklu TotalRevenueCycleTime | Celková vypočtená doba od první události související se službou až po poslední platbu nebo uzavření účtu. | ||
| Popis Tento KPI na úrovni případu měří celkovou dobu výnosového cyklu jedné fakturační události. Obvykle se vypočítává jako časový rozdíl mezi činností „Poskytnutí služby“ a poslední činností „Přijetí platby“ nebo „Uzavření účtu“. Tato souhrnná metrika poskytuje celkový přehled o efektivitě procesu RCM. Sledováním KPI v čase lze měřit dopad iniciativ na zlepšování procesů a získat důležitý ukazatel rychlosti přeměny pohledávek na hotovost. Proč je to důležité Poskytuje celkový přehled o efektivitě procesu od začátku do konce a přímo měří, jak dlouho trvá přeměna poskytnuté služby na peníze. Kde data získat Tuto metriku vypočítává nástroj process mining tak, že pro každý případ vybere první a poslední událost a zjistí časový rozdíl. Příklady 259200038880005184000 | |||
| Datum splatnosti PaymentDueDate | Datum, do kterého se očekává úhrada za vyúčtovanou službu. | ||
| Popis Tento atribut určuje termín úhrady uvedený na faktuře nebo stanovený smlouvou s plátcem. Slouží jako základ pro měření včasnosti plateb. Datum splatnosti je nezbytné pro sestavení „Přehledu stáří neuhrazených zůstatků“. Porovnáním aktuálního data s datem splatnosti otevřených zůstatků lze pohledávky rozdělit do časových pásem, například 0–30 dní nebo 31–60 dní po splatnosti. Tím lze při vymáhání přednostně řešit nejdéle neuhrazené účty. Proč je to důležité Slouží jako základ pro analýzu stáří pohledávek, která pomáhá stanovit priority při vymáhání a řídit finanční riziko spojené s nezaplacenými fakturami. Kde data získat Toto datum se často vypočítává z data faktury a platebních podmínek uložených ve smlouvě s plátcem nebo v údajích o účtu pacienta v Epic. Příklady 2023-05-302023-06-152023-07-01 | |||
| ID nároku ClaimId | Jedinečný identifikátor pojistného nároku odeslaného plátci. | ||
| Popis Tento atribut představuje konkrétní ID formuláře nároku, například CMS-1500 nebo UB-04, odeslaného plátci. Jedna fakturační událost může zahrnovat více nároků, pokud se služby vyúčtují znovu nebo se proti rozhodnutí podá odvolání. Sledování podle ID nároku se hodí pro podrobnou analýzu odesílání nároků a jejich zamítání. Pomáhá odlišit činnosti související s původním nárokem od činností spojených s jeho opětovným odesláním za stejnou službu. Proč je to důležité Poskytuje podrobný identifikátor pro sledování životního cyklu každého odeslaného nároku. Je důležitý při analýze opětovného odesílání a odvolání. Kde data získat Vytváří jej modul správy nároků v Epic Resolute při založení nároku. Ukládá se do datových tabulek nároků. Příklady CLM-2023-98765CLAIM-0012345623189A4567 | |||
| ID pacienta PatientId | Jedinečný identifikátor pacienta, kterému byla služba poskytnuta. | ||
| Popis Tento atribut představuje číslo zdravotnické dokumentace (MRN) nebo jiný jedinečný identifikátor pacienta. Propojuje finanční fakturační událost s konkrétní osobou. Kvůli ochraně soukromí se obvykle nepoužívá jako hlavní analytický rozměr. Je však důležitý pro ověření dat a lze jej použít ke sloučení všech fakturačních událostí jednoho pacienta, aby bylo možné porozumět jeho celkové finanční cestě. Je také důležitý pro případnou integraci s daty o klinických procesech. Proč je to důležité Propojuje finanční údaje s konkrétním pacientem, což umožňuje ověřovat data a případně analyzovat celou jeho cestu. Vzhledem k ochraně soukromí je však nutné s tímto identifikátorem zacházet obezřetně. Kde data získat Základní identifikátor používaný napříč Epic, propojený s registrací pacienta a jeho účty. Příklady MRN-1234567MRN-8765432MRN-5551234 | |||
| Je automatizováno IsAutomated | Logická hodnota označující, zda činnost provedl systém nebo automatizovaný proces. | ||
| Popis Tento příznak rozlišuje úkoly prováděné automaticky systémem, například automatické vytváření nároků nebo kontroly způsobilosti, od úkolů prováděných ručně uživatelem. Analýza tohoto atributu pomáhá určit míru automatizace procesu. Umožňuje porovnat efektivitu a chybovost automatizovaných a ručních činností, hledat příležitosti k další automatizaci a sledovat výkon stávajících botů nebo systémových pravidel. Proč je to důležité Rozlišuje činnosti prováděné systémem od činností prováděných lidmi. Pomáhá tak vyhodnotit dopad automatizace a najít další příležitosti k automatizaci. Kde data získat Obvykle se odvozuje podle toho, zda je „ResponsibleUser“ dané činnosti systémový nebo servisní účet, případně se příznak nastaví u názvů činností, o nichž je známo, že jsou automatizované. Příklady truefalse | |||
| Název plátce PayerName | Název pojišťovny, státní instituce nebo jiné strany odpovědné za úhradu. | ||
| Popis Tento atribut označuje hlavního plátce přiřazeného k fakturační události, například „Blue Cross Blue Shield“, „Medicare“ nebo „Aetna“. Pokud si pacient hradí péči sám, může být uveden pacient. Rozdělení procesu podle plátce je užitečná analytická metoda. Může ukázat, že někteří plátci mají vyšší míru zamítnutí, delší lhůty úhrady nebo složitější požadavky. Tyto poznatky umožňují přizpůsobit fakturační postupy jednotlivým plátcům a zlepšit efektivitu i rychlost úhrad. Proč je to důležité Umožňuje analyzovat výkonnost podle plátce, odhalit plátce s vysokou mírou zamítnutí nebo dlouhými lhůtami úhrady a cíleně nastavit následné kroky. Kde data získat Tyto informace jsou součástí údajů o pojistném krytí pacienta a jsou propojené s nemocničním účtem (HAR) v Epic Resolute. Příklady Medicare Part BUnitedHealthcareAetna PPO | |||
| Poslední aktualizace dat LastDataUpdate | Časové razítko označující, kdy byla data této události naposledy obnovena nebo extrahována ze zdrojového systému. | ||
| Popis Tento atribut ukazuje aktuálnost dat. Označuje, kdy byl záznam naposledy načten z Epic Resolute do datové sady pro process mining. Pomáhá posoudit, jak aktuální je analýza, a ověřit data. Uživatelé díky němu vědí, zda pracují s nejnovějšími dostupnými informacemi. Je také důležitý pro správu obnovy dat. Proč je to důležité Uživatelé díky němu vědí, jak aktuální jsou analyzovaná data. To je důležité pro správná obchodní rozhodnutí založená na nejnovějších informacích. Kde data získat Toto časové razítko přidává proces ETL (extrakce, transformace a načtení) při načítání dat. Příklady 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| Upravená částka AdjustedAmount | Peněžní hodnota transakce úpravy. | ||
| Popis Toto pole zaznamenává konkrétní částku úpravy účtu v dolarech. Může být kladná i záporná a představuje kredit nebo debet zůstatku účtu. Tato částka je hlavní metrikou dashboardu „Objem úprav účtů podle typu“. Součet podle důvodu úpravy ukazuje finanční dopad jednotlivých typů úprav. Lze tak například zjistit, jaká část výnosů se odepisuje kvůli smluvním závazkům a jaká kvůli chybám, které lze napravit. Proč je to důležité Vyčísluje finanční dopad úprav účtů a umožňuje měřit únik výnosů i náklady spojené s nepřesnostmi ve fakturaci. Kde data získat Nachází se v tabulkách s podrobnostmi o finančních transakcích v Epic Resolute a souvisí s transakcemi typu úprava. Příklady -1250.45-50.0025.10 | |||
| Zdrojový systém SourceSystem | Informační systém, ze kterého data pocházejí. | ||
| Popis Tento atribut označuje zdrojový systém záznamu, kterým je v tomto případě Epic Resolute. V prostředí s více propojenými systémy pomáhá rozlišit původ dat. V přehledu jednoho systému se může zdát nadbytečný, jde však o osvědčený postup pro správu dat a rozšiřování řešení. Pokud později přidáte data z dalších systémů, například ze samostatné platformy inkasní agentury, bude jejich původ jasný. Proč je to důležité Poskytuje důležité informace o původu a kontextu dat. Usnadňuje tak správu dat i řešení problémů. Kde data získat Obvykle jde o statickou hodnotu, která se přidává při extrakci a transformaci dat a označuje původ datové sady. Příklady Epic ResoluteEpicResolute_V2023 | |||
Činnosti v řízení výnosového cyklu
| Aktivita | Popis | ||
|---|---|---|---|
| Odeslání nároku plátci | Tato událost označuje oficiální odeslání nároku pojišťovně k posouzení. V Epic se zaznamená při přenosu elektronického souboru nároku do clearingového centra nebo přímo plátci. | ||
| Proč je to důležité Tento milník je důležitý, protože od něj začíná běžet lhůta plátce pro úhradu. Analýza pomáhá měřit efektivitu přenosu nároků a podporuje KPI Doba doručení faktury plátci. Kde data získat V Resolute jde o výslovně zaznamenanou událost. Záznam nároku obsahuje stav odeslání a časové razítko odeslání. Zachycení Zachyťte časové razítko změny stavu nároku na „Odesláno“ nebo „Předáno“. Typ události explicit | |||
| Poskytnutí služby | Tato činnost označuje okamžik, kdy pacient obdrží klinickou službu a vznikne fakturační událost. Obvykle se zaznamená v Epic EHR (EpicCare), když lékař potvrdí návštěvu nebo zákrok. | ||
| Proč je to důležité Jde o hlavní počáteční událost cyklu výnosů. Doba od tohoto okamžiku do zachycení účtovatelných výkonů je důležitá pro odhalení prodlev při zahájení fakturace a možného úniku výnosů. Kde data získat Tato událost se obvykle odvozuje z časových razítek služby nebo návštěvy v klinických modulech propojených s fakturačním účtem. Důležitým údajem je datum služby uvedené u transakce za výkon. Zachycení Odvozeno z data služby přiřazeného k první transakci za výkon v rámci fakturační události. Typ události inferred | |||
| Přijetí platby | Označuje přijetí platby od plátce nebo pacienta. Událost se obvykle zaznamená při načtení elektronického avíza o úhradě (ERA) nebo při ručním zadání šeku do systému. | ||
| Proč je to důležité Tato činnost je důležitým milníkem, který ukazuje, že přicházejí výnosy. Doba mezi odesláním nároku a přijetím platby je důležitým ukazatelem výkonnosti pohledávek. Kde data získat V Resolute je platba výslovně zaznamenána jako transakce. Záznam obsahuje datum, zdroj a částku. Často vznikne ještě před úplným přiřazením platby ke konkrétním výkonům. Zachycení Zachyťte platební transakce z finančního transakčního protokolu. Často je lze rozpoznat podle konkrétních typů transakcí. Typ události explicit | |||
| Uzavření účtu | Jde o závěrečnou činnost. Označuje, že neuhrazený zůstatek fakturační události klesl na nulu a nezbývají žádné další úkony. Může k tomu dojít po úplné úhradě, úpravě nebo odpisu. | ||
| Proč je to důležité Tato událost označuje úspěšné dokončení cyklu výnosů u fakturační události. Celková doba od poskytnutí služby do uzavření účtu je důležitým KPI pro hodnocení efektivity procesu. Kde data získat Tato událost se obvykle odvozuje. Určí se podle okamžiku, kdy zůstatek účtu pro danou fakturační událost klesne na nulu a zůstane nulový. Zachycení Odvoďte událost výpočtem průběžného zůstatku na účtu a určením časového razítka poslední transakce, po které zůstatek klesl na nulu. Typ události inferred | |||
| Zachycení účtovatelných výkonů | Označuje formální zaznamenání účtovatelných výkonů za poskytnuté služby. V Epic jde obvykle o konkrétní transakci zaúčtovanou na účet pacienta. Často vzniká automaticky na základě klinických úkonů nebo se zadává ručně. | ||
| Proč je to důležité Jde o první důležitý milník. Měření rychlosti a přesnosti zachycení účtovatelných výkonů pomáhá urychlit fakturaci a zajistit, aby byly vyúčtovány všechny poskytnuté služby. Kde data získat Záznam je výslovně uveden v transakčních protokolech Resolute. Každý výkon je samostatná položka s datem zaúčtování, datem služby a částkou. Často se nachází v tabulkách, jako je ARPB_TRANSACTIONS. Zachycení Zachyťte transakce zaúčtování výkonů z finančního transakčního protokolu systému. Typ události explicit | |||
| Zamítnutí nároku plátcem | Označuje přijetí oznámení od plátce, že nárok zamítl. Zaznamená se, když Epic zpracuje elektronické avízo o úhradě (soubor 835) nebo když uživatel zamítnutí zadá ručně. | ||
| Proč je to důležité Tato činnost zahajuje důležitý cyklus oprav. Analýza důvodů a počtu zamítnutí je nezbytná pro odhalení hlavních příčin, zvýšení podílu úhrad při prvním podání a omezení prodlev při inkasu. Kde data získat Zamítnutí je výslovně zaznamenáno jako transakce nebo změna stavu nároku. Informace o zamítnutí včetně kódů důvodů se obvykle přijímají elektronicky a zapisují na účet. Zachycení Vyfiltrujte konkrétní typy transakcí nebo změny stavu nároku, které označují zamítnutí. Typ události explicit | |||
| Zaúčtování platby na účet | Tato událost označuje přiřazení přijaté platby ke konkrétním výkonům na účtu pacienta. Tím se sníží neuhrazený zůstatek fakturační události. | ||
| Proč je to důležité Efektivní zaúčtování plateb je důležité pro správné zůstatky na účtech a uzavření fakturačních událostí. Umožňuje správně určit zbývající částky pro sekundární fakturaci nebo inkaso. Kde data získat V Resolute jde o výslovně zaznamenanou transakci. Při zaúčtování se platební transakce propojí s jednou nebo více transakcemi za výkony. Toto propojení se zaznamenává v tabulkách s podrobnostmi transakcí. Zachycení Zachyťte záznam transakce, která přiřazuje platbu k výkonu. Lze ji rozpoznat podle konkrétních typů transakcí. Typ události explicit | |||
| Opětovné odeslání nároku | K této události dochází poté, co byl zamítnutý nárok opraven a znovu odeslán plátci. Jde o samostatnou událost odeslání propojenou s původním nárokem. | ||
| Proč je to důležité Jde o důležitou součást cyklu oprav. Měření doby do opětovného odeslání a úspěšnosti znovu odeslaných nároků pomáhá vyhodnotit, jak účinně se zamítnutí řeší. Kde data získat Jde o výslovně zaznamenanou událost podobnou prvnímu odeslání, často však označenou jako opětovné odeslání. Záznam nároku obsahuje nové časové razítko odeslání a může zahrnovat kód opětovného odeslání. Zachycení Zachyťte časové razítko odeslání nároku označeného jako oprava nebo opětovné odeslání. Typ události explicit | |||
| Předání zůstatku k inkasu | Tento okamžik označuje předání neuhrazeného zůstatku do interního nebo externího procesu inkasa. Obvykle jde o výslovnou změnu stavu účtu nebo fakturační události. | ||
| Proč je to důležité Tato činnost zahajuje závěrečnou fázi vymáhání neuhrazených zůstatků. Sledování úspěšnosti a délky cyklu inkasa je důležité pro omezení nedobytných pohledávek. Kde data získat Obvykle jde o výslovnou událost. Epic umožňuje předávat účty inkasním agenturám, což vytvoří záznam v protokolu nebo změní stav účtu. Zachycení Najděte změnu stavu nebo transakci, která ukazuje, že účet byl předán inkasní agentuře. Typ události explicit | |||
| Úprava účtu | Tato činnost označuje transakci, která není platbou, ale mění zůstatek na účtu. Může jít například o smluvní úpravu, odpis nízkého zůstatku nebo slevu z dobré vůle. Zaznamenává se jako konkrétní typ transakce. | ||
| Proč je to důležité Analýza úprav je důležitá pro odhalení úniku výnosů. Vysoký počet určitých typů úprav může ukazovat na problémy se sazebníky, smlouvami nebo interními pravidly. Kde data získat Úpravy jsou výslovně zaznamenány ve finančních protokolech Resolute. Každá má přiřazen konkrétní typ nebo kód důvodu. Zachycení Vyfiltrujte typy transakcí odpovídající finančním úpravám nebo odpisům. Typ události explicit | |||
| Vytvoření nároku | Tato činnost označuje vytvoření formálního nároku nebo faktury systémem na základě zachycených výkonů. Jde o přípravný krok před odesláním nároku plátci nebo pacientovi. | ||
| Proč je to důležité Sledování vytváření nároků pomáhá odhalit prodlevy mezi zachycením výkonů a jejich přípravou k odeslání. Jde o důležitý interní krok, který může ovlivnit celkovou včasnost fakturace. Kde data získat Událost se obvykle zaznamená při spuštění dávkové úlohy pro fakturaci nebo vytváření nároků. Systém uloží časové razítko vytvoření souboru nároku, například souboru 837, pro daný účet. Zachycení Najděte záznamy v protokolu nebo změny stavu, které ukazují, že nárok byl sestaven a je připraven k odeslání. Typ události explicit | |||
| Zahájení následného řešení zamítnutí | Tato činnost označuje začátek interního procesu kontroly a řešení zamítnutého nároku. Obvykle se zaznamená, když uživatel převezme zamítnutý nárok ve frontě úkolů nebo změní jeho stav. | ||
| Proč je to důležité Sledování této činnosti pomáhá měřit rychlost reakce týmu, který řeší zamítnuté nároky. Prodleva mezi zamítnutím a zahájením následného řešení může zbytečně prodloužit cyklus výnosů. Kde data získat Tato událost se obvykle odvozuje ze změn stavu nároku nebo historie přiřazení ve frontách úkolů Epic. Stav nároku se například může změnit z „Zamítnuto“ na „Probíhá kontrola“. Zachycení Odvoďte událost ze změny stavu nároku nebo ze záznamu auditu, který ukazuje, že uživatel začal zamítnutí řešit. Typ události inferred | |||
Průvodci extrakcí dat
Kroky
- Navázání připojení k databázi: Získejte přihlašovací údaje s přístupem pouze pro čtení k databázi Epic Clarity. K připojení k databázovému serveru použijte běžného SQL klienta, například DBeaver nebo Microsoft SQL Server Management Studio.
- Určení hlavních tabulek: Mezi hlavní tabulky pro tuto extrakci patří
HSP_ACCOUNTs údaji o případech,HSP_TRANSACTIONSs finančními událostmi,CLP_CLAIM_INFOse stavem nároků aF_ARHB_TX_SET_POST_HXs podrobnostmi o zaúčtování plateb. Připojte také hlavní soubory, napříkladCLARITY_EMPs údaji o uživatelích. - Vymezení rozsahu: Než napíšete dotaz, určete rozsah analýzy. Zvolte konkrétní období, obvykle 3 až 6 měsíců, a určete, které oblasti nemocničních služeb (
SERV_AREA_ID) nebo třídy účtů chcete zahrnout či vyloučit. - Vytvoření SQL dotazu: Sestavte SQL dotaz s využitím Common Table Expression (CTE). Nejprve vyberte hodnoty
HSP_ACCOUNT_ID, které spadají do zvoleného rozsahu. Tím vytvoříte základní množinu fakturačních událostí. - Samostatné dotazy pro jednotlivé činnosti: Pro každou z 12 požadovaných činností napište samostatný příkaz
SELECT, který načte data z příslušných tabulek. Připojte jej k původnímu CTE, abyste analyzovali pouze požadované účty. - Spojení dotazů pomocí UNION ALL: Pomocí operátoru
UNION ALLspojte výsledky všech samostatných dotazů do jednoho záznamu událostí. Řádky z jednotlivých dotazů se tím seřadí pod sebe. - Převod na standardní schéma: V každém příkazu
SELECTpřejmenujte sloupce tak, aby odpovídaly požadovanému schématu ProcessMind, napříkladBillingEvent,ActivityName,EventTimestampaResponsibleUser. U atributů, které se na danou činnost nevztahují, použijteNULL. - Spuštění a úprava dotazu: Spusťte celý dotaz nad databází Clarity. Vzhledem k objemu tabulek může jeho zpracování trvat dlouho. Pokud je výkon nedostatečný, zkraťte období nebo přidejte konkrétnější filtry do úvodního CTE.
- Kontrola výsledků: Po dokončení dotazu zkontrolujte prvních několik set řádků. Ověřte, že jsou přítomné všechny sloupce, časová razítka mají jednotný formát a zobrazují se očekávané hodnoty
ActivityName. - Export do CSV: Exportujte celou sadu výsledků z SQL klienta do souboru CSV. Použijte kódování UTF-8 a záhlaví se správnými názvy sloupců.
- Příprava k nahrání: Před nahráním do ProcessMind otevřete soubor CSV a ověřte, že neobsahuje chyby formátování. Zkontrolujte jednotný formát časových razítek, například
YYYY-MM-DD HH:MI:SS. Soubor je nyní připraven k načtení.
Konfigurace
- Připojení k databázi: Potřebujete uživatelský účet s přístupem pouze pro čtení k databázi Epic Clarity.
- Parametry časového období: Dodaný dotaz používá proměnné
@StartDatea@EndDate. Nastavte je tak, aby určovaly období analýzy. Doporučujeme 3 až 6 měsíců, což představuje kompromis mezi objemem dat a výkonem. - Mapování tabulek a sloupců: Dotaz předpokládá standardní názvy tabulek a sloupců v Clarity. Konfigurace Epic nebo její verze se mohou ve vaší organizaci lišit. Podle potřeby upravte názvy tabulek a sloupců nebo podmínky spojení.
- Kódy transakcí a stavů: Dotaz obsahuje zástupné hodnoty, například
[Your Denial Tx Type]a[Your Collections Status Code]. Správné kódy pro vaši instanci zjistíte u správců systému Epic nebo v příslušných hlavních souborech, napříkladZC_TX_TYPEčiZC_ACCOUNT_STATUS. - Filtrování: Pro lepší výkon a cílenější analýzu přidejte filtry do úvodního CTE
BaseAccounts. Mezi běžné filtry patříSERV_AREA_IDpro omezení na oblast nemocničních služeb aACCOUNT_CLASS_Cpro výběr fakturace za hospitalizaci nebo ambulantní péči.
Ukázkový dotaz 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; Kroky
- Ověřte, že máte oprávněný přístup k datům výnosového cyklu Epic Clarity, včetně zdrojových tabulek a pohledů potřebných pro historii účtů, účtovaných výkonů, nároků, zamítnutí, plateb, úprav, vymáhání a uzavření. Dostupné tabulky a názvy sloupců se v jednotlivých organizacích používajících Epic liší. Každý zástupný údaj v dotazu proto namapujte na odpovídající objekt Clarity ve svém prostředí.
- Vymezte období extrakce pomocí parametrů [Start date parameter] a [End date parameter]. Nejprve použijte období tří až šesti měsíců. Prodlužte je až po ověření výkonu dotazu a úplnosti událostí.
- Nastavte mapování BillingEvent. Pokud je k dispozici, dotaz jako výchozí identifikátor případu používá HSP_ACCOUNT.HSP_ACCOUNT_ID. Pokud vaše organizace definuje fakturační událost na úrovni účtovaného výkonu, nároku nebo návštěvy, nahraďte toto mapování schváleným identifikátorem a používejte jej jednotně u všech zdrojů činností.
- Každou zdrojovou činnost namapujte na autoritativní časové razítko a atribut zdroje. Pro činnost Service Rendered použijte zdokumentované časové razítko dokončení služby nebo návštěvy. Pro Charges Captured použijte časové razítko zaúčtování výkonu. U činností Claim Generated a Claim Submitted to Payer použijte odpovídající časová razítka životního cyklu nároku. U zamítnutí, následného řešení, opětovného odeslání, plateb, úprav, vymáhání a uzavření použijte zdokumentovaná časová razítka transakcí nebo změn stavu.
- V dotazu nahraďte všechny zástupné údaje v hranatých závorkách, včetně [Your service source table], [Your charge source table], [Your claim source table], [Your denial source table], [Your follow-up source table], [Your payment source table], [Your adjustment source table], [Your collections source table] a [Your account closure source table]. Nepoužívejte nezdokumentované kódy transakcí. Použijte hodnoty transakcí nebo stavů schválené týmem Epic pro reporting.
- Spusťte dotaz ve schváleném SQL klientovi nebo reportovací platformě organizace. Ověřte, že se všech dvanáct označení činností vrací jako samostatné řádky. ProcessMind neodvozuje chybějící události životního cyklu ze zůstatků, stavů ani pořadí událostí.
- Zkontrolujte schéma výsledků. Výsledek musí obsahovat BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance a ServiceType. U časových razítek zachovejte informace o časovém pásmu nebo místním čase. Pokud to pravidla dovolují, ponechte zdrojové identifikátory v interním výpisu pro audit.
- Ověřte chronologické pořadí událostí v rámci každého BillingEvent, výskyt duplicit, podíl prázdných hodnot, počty činností a soulad s výkazy zdrojového systému. Prověřte události mimo požadované období, pokud jsou potřebné k interpretaci případů, které začaly před tímto obdobím nebo skončily až po něm.
- Exportujte výsledek jako soubor s oddělovači nebo použijte připojení k databázi podporované ProcessMind. Každá událost musí být na samostatném řádku. Použijte stabilní názvy sloupců, jednotný formát časových razítek a kódování UTF-8. Nepoužívejte sloučené buňky ani souhrnné řádky určené k prezentaci. Při nahrávání nastavte BillingEvent jako identifikátor případu, ActivityName jako činnost a EventTimestamp jako časové razítko události.
Konfigurace
- Mapování zdrojů: Implementace Epic Clarity se liší. Každý zástupný údaj zdroje nebo sloupce v hranatých závorkách nahraďte zdokumentovanou tabulkou, pohledem nebo schválenou reportovací vrstvou ve svém prostředí. Nepředpokládejte, že tabulka nebo pole existuje jen proto, že se běžně používá v jiné implementaci Epic.
- Identifikátor případu: Výchozí mapování dotazu používá HSP_ACCOUNT.HSP_ACCOUNT_ID. Ověřte, zda vaše organizace definuje BillingEvent jako účet, návštěvu, nárok, účtovaný výkon nebo jiný schválený obchodní klíč.
- Časové období: Začněte obdobím tří až šesti měsíců. Pokud případy mohou začít před vykazovaným obdobím, zahrňte i předcházející období. Pokud k nárokům, zamítnutím, platbám nebo uzavření může dojít až po datu poskytnutí služby, zahrňte také navazující období.
- Časová razítka činností: Pro každou činnost nastavte jedno autoritativní časové razítko. Nenahrazujte skutečný čas obchodní události časem extrakce, načtení souboru ani časem aktuálního stavu, pokud zdokumentovaný čas události ve zdrojovém systému není právě tento údaj.
- Filtry: Filtry [Company Code filter], [Document Type filter], [Department filter], plátce, oblasti služeb a třídy účtů použijte pouze tehdy, jsou-li jejich definice zdokumentované a analýza je vyžaduje. Filtry musí být stejné ve všech částech spojených pomocí UNION ALL.
- Mapování transakcí a stavů: Nastavte hodnoty schválené organizací pro zaúčtování výkonu, vytvoření nároku, odeslání nároku, zamítnutí, následné řešení, opětovné odeslání, přijetí platby, zaúčtování platby, úpravu, vymáhání a uzavření. Dotaz záměrně obsahuje zástupné údaje, protože hodnoty transakcí a struktury zdrojů se v jednotlivých implementacích Epic liší.
- Práce s prázdnými hodnotami: U atributů, které se na danou činnost nevztahují, ponechte NULL. Chybějící důvody zamítnutí nebo úpravy, uživatele, oddělení ani typy služeb nenahrazujte vymyšlenými hodnotami.
- Výkon: Před spojením s HSP_ACCOUNT omezte zdrojové řádky pomocí indexovaných datových sloupců a schválených organizačních filtrů. Ve filtračních podmínkách nepoužívejte funkce nad indexovanými sloupci s časovými razítky. Pokud je zdrojová historie rozsáhlá, zvažte přípravu samostatného pohledu pro každou zdrojovou činnost ve schválené reportovací vrstvě.
- Odstraňování duplicit: Duplicity neodstraňujte bez zdokumentovaného pravidla. Více plateb, úprav, odeslání nároku nebo změn stavu může představovat platné události jednoho BillingEvent.
- Předpoklady: Potřebná oprávnění mohou zahrnovat přístup k reportingu Epic Clarity, k datům o výnosovém cyklu a historii účtů, schválené prostředí pro spouštění SQL a souhlas organizace se zpracováním chráněných zdravotních údajů. Dostupnost historie nároků, úhrad, front práce, vymáhání a uzavření závisí na licencovaných a nasazených modulech a rozhraních Epic.
Ukázkový dotaz sql
WITH
service_rendered AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Service Rendered' AS ActivityName,
CAST(s.[Service rendered timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(s.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(s.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(s.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(s.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your service source table] s
ON s.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE s.[Service rendered timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND s.[Service rendered timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND [Your company code filter]
),
charges_captured AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Charges Captured' AS ActivityName,
CAST(t.[Charge captured timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(t.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(t.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(t.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(t.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN AR_PB_TRANSACTIONS t
ON t.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE t.[Charge captured timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND t.[Charge captured timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND t.[Charge transaction filter]
AND [Your company code filter]
),
claim_generated AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Generated' AS ActivityName,
CAST(c.[Claim generated timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim generated timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim generated timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim generated status filter]
AND [Your company code filter]
),
claim_submitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
CAST(c.[Claim submitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim submitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim submitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim submitted status filter]
AND [Your company code filter]
),
claim_denied AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
CAST(d.[Denial timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(d.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(d.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(d.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(d.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(d.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your denial source table] d
ON d.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE d.[Denial timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND d.[Denial timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND d.[Denial status filter]
AND [Your company code filter]
),
denial_follow_up AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
CAST(f.[Follow-up timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(f.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(f.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(f.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(f.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(f.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your follow-up source table] f
ON f.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE f.[Follow-up timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND f.[Follow-up timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND f.[Follow-up status filter]
AND [Your company code filter]
),
claim_resubmitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
CAST(c.[Claim resubmitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim resubmitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted status filter]
AND [Your company code filter]
),
payment_received AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Received' AS ActivityName,
CAST(p.[Payment received timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment received timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment received timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment received status filter]
AND [Your company code filter]
),
payment_posted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
CAST(p.[Payment posted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment posted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment posted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment posted status filter]
AND [Your company code filter]
),
account_adjustment AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
CAST(x.[Adjustment timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(x.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(x.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(x.[Adjustment reason column] AS VARCHAR(100)) AS AdjustmentReason,
CAST(x.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(x.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your adjustment source table] x
ON x.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE x.[Adjustment timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND x.[Adjustment timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND x.[Adjustment transaction filter]
AND [Your company code filter]
),
balance_collections AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
CAST(k.[Collections timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(k.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(k.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(k.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(k.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your collections source table] k
ON k.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE k.[Collections timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND k.[Collections timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND k.[Collections status filter]
AND [Your company code filter]
),
account_closed AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Closed' AS ActivityName,
CAST(z.[Account closed timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(z.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(z.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(z.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(z.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your account closure source table] z
ON z.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE z.[Account closed timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND z.[Account closed timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND z.[Account closed status filter]
AND [Your company code filter]
)
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM service_rendered
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM charges_captured
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_generated
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_submitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_denied
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM denial_follow_up
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_resubmitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_received
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_posted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_adjustment
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM balance_collections
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_closed
ORDER BY BillingEvent, EventTimestamp, ActivityName; Chcete začít?
Přesná data vám pomohou naplno využít možnosti procesu řízení výnosového cyklu. Začněte zlepšovat efektivitu a finanční výsledky ještě dnes.
Zvyšte efektivitu: optimalizujte řízení výnosového cyklu
Odhalte neefektivitu RCM v Epic Resolute a zkraťte dobu cyklu o 30 %.
Platební kartu nepotřebujete. Začněte s optimalizací ještě dnes.