Šablona dat pro řízení výnosového cyklu
Šablona dat pro řízení výnosového cyklu
- Doporučené atributy ke sběru
- Aktivity, které je vhodné sledovat
- Pokyny k extrakci dat z Oracle Health Revenue Cycle
Atributy řízení výnosového cyklu
| Název | Popis | ||
|---|---|---|---|
| Časové razítko události EventTimestamp | Přesné datum a čas, kdy byla činnost zaznamenána v systému. | ||
| Popis Tento atribut uvádí časové razítko každé činnosti, tedy přesný okamžik, kdy k ní došlo. Je nezbytný pro pochopení načasování a pořadí událostí ve výnosovém cyklu konkrétní fakturační události. Při analýze se časové razítko události používá k chronologickému seřazení činností, výpočtu dob a časů cyklu mezi jednotlivými kroky a k analýze úzkých míst. Je základem všech časových metrik process mining, například pro odhalení prodlevy mezi „Odesláním nároku na úhradu“ a „Přijetím vyúčtování“. Proč je to důležité Toto časové razítko je nezbytné pro řazení událostí, výpočet ukazatelů výkonnosti, jako jsou doby cyklu a trvání, i odhalování úzkých míst v procesu. Kde data získat Každá transakční tabulka nebo tabulka záznamů událostí v Oracle Health Revenue Cycle by měla obsahovat sloupec s časovým razítkem vytvoření záznamu nebo výskytu události. Příklady 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| Fakturační událost BillingEvent | Jedinečný identifikátor konkrétního poskytnutí služby nebo produktu, za které se účtuje poplatek. Slouží jako identifikátor případu ve výnosovém cyklu. | ||
| Popis Fakturační událost slouží jako hlavní identifikátor případu a propojuje všechny činnosti od zachycení poplatku po uzavření účtu pro konkrétní zpoplatněnou položku. Každá fakturační událost představuje jeden konkrétní průběh výnosového cyklu. Umožňuje sledovat jeho jednotlivé fáze, například podání nároku na úhradu, zaúčtování platby nebo případné zamítnutí či úpravy. Tento atribut je základem rekonstrukce celého průběhu procesu při analýze process mining. Umožňuje zobrazit varianty procesu, vypočítat dobu mezi jednotlivými činnostmi a odhalit úzká místa nebo odchylky spojené s konkrétními fakturačními událostmi. Proč je to důležité Tento nezbytný identifikátor umožňuje sledovat celý životní cyklus zpoplatněné služby. Je základem analýzy průběhu procesu i měření jeho výkonnosti. Kde data získat Tento identifikátor by měl být jedinečným klíčem v hlavních tabulkách fakturace nebo transakcí poplatků v Oracle Health Revenue Cycle. Primární klíč pro události poplatků najdete v dokumentaci systému. Příklady BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| Název činnosti ActivityName | Název konkrétního kroku nebo události, ke které došlo v rámci výnosového cyklu. | ||
| Popis Tento atribut zaznamenává název každé činnosti v životním cyklu fakturační události. Patří sem například „Zachycení poplatků“, „Odeslání nároku na úhradu plátci“ nebo „Zaúčtování platby“. Tyto činnosti tvoří uzly zjištěné mapy procesu. Analýza pořadí a četnosti činností je základem process mining. Díky tomuto atributu zjistíte nejčastější cesty procesem, odhalíte odchylky od standardního postupu a lépe porozumíte provozu výnosového cyklu. Proč je to důležité Určuje jednotlivé kroky procesu. Umožňuje zobrazit mapu procesu a analyzovat vzorce ve workflow. Kde data získat Obvykle se odvozuje ze záznamů událostí, záznamů změn stavu nebo konkrétních transakčních tabulek pro různé fáze výnosového cyklu v Oracle Health. Příklady Vytvoření nároku na úhraduPřijetí vyúčtování od plátceOdvolání proti zamítnutíUzavření účtu | |||
| Částka úpravy AdjustmentAmount | Peněžní hodnota úprav zůstatku na účtu. | ||
| Popis Tento atribut zachycuje částku finanční úpravy, například smluvní slevy, odpisu nebo opravy, která byla uplatněna u účtované události. Úpravy přímo snižují očekávané výnosy z poplatku. Dashboard „Dopad úprav na účet“ tento atribut ve velké míře využívá. Analýza částek úprav a souvisejících důvodů pomáhá odhalit úniky výnosů, problémy se správou smluv nebo nedostatky při původním zachycení poplatků. Jde o důležitý ukazatel finančního zdraví. Proč je to důležité Vyčísluje úniky výnosů způsobené odpisy nebo opravami a pomáhá odhalit a řešit příčiny jejich poklesu. Kde data získat Nachází se ve finančních transakčních tabulkách, které zaznamenávají úpravy nebo odpisy na pacientském účtu. Příklady -50.25-120.0025.00 | |||
| Kód důvodu zamítnutí DenialReasonCode | Standardizovaný kód označující důvod, proč plátce zamítl nárok. | ||
| Popis Když plátce zamítne nárok, uvede kód důvodu, například „Služba není hrazena“ nebo „Duplicitní nárok“. Tento atribut zachycuje kód i jeho popis. Analýza důvodů zamítnutí je základem pro zlepšování výnosového cyklu. Organizace díky ní může odhalit časté problémy, například chyby v kódování nebo nároku pacienta na úhradu, a přijmout opatření, která zabrání dalším zamítnutím. To přímo ovlivňuje podíl správně podaných nároků a snižuje náklady na opakované zpracování. Proč je to důležité Odhaluje příčiny zamítnutí nároků a umožňuje cíleně zvyšovat podíl správně podaných nároků a urychlovat inkaso výnosů. Kde data získat Tyto informace přicházejí od plátce v elektronickém avízu o úhradě (soubor ANSI 835) a měly by se ukládat do tabulek nároků nebo avíz o úhradě v Oracle Health. Příklady CO-16: V nároku nebo službě chybí informace potřebné k posouzení.PR-96: Poplatek za službu, která není hrazena.CO-18: Duplicitní nárok nebo služba. | |||
| Název plátce PayerName | Název pojišťovny nebo jiného plátce odpovědného za úhradu. | ||
| Popis Tento atribut označuje subjekt, například pojišťovnu nebo státní program, jako je Medicare, kterému se služba fakturuje. Informace o plátci jsou pro analýzu výnosového cyklu zásadní. Analýza procesu podle plátce může odhalit výrazné rozdíly v době úhrady, míře zamítnutí i úspěšnosti odvolání. Pomáhá určit plátce, kteří způsobují zpoždění nebo ztrátu výnosů, a účinněji spravovat smlouvy a vztahy s plátci. Proč je to důležité Umožňuje rozdělit proces podle plátce a odhalit rozdíly v jeho postupech, míře zamítnutí a rychlosti plateb, které mají zásadní vliv na finanční výsledky. Kde data získat Tyto informace jsou uloženy v záznamech o fakturaci pacienta nebo jeho pojištění v Oracle Health Revenue Cycle. Příklady AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| Nevyrovnaný zůstatek OutstandingBalance | Zbývající nezaplacená částka účtované události k určitému okamžiku. | ||
| Popis Tento atribut udává aktuální dlužnou částku za účtovanou událost po započtení všech plateb a úprav. Představuje pohledávku za konkrétní poplatek. Jde o důležitý atribut pro dashboard „Stárnutí nevyrovnaných zůstatků“. Sledování této hodnoty v čase pomáhá monitorovat rychlost peněžních toků, vyhodnocovat účinnost vymáhání pohledávek a počítat finanční KPI, například dobu inkasa pohledávek (DSO). Proč je to důležité Sleduje aktuální pohledávky za jednotlivé případy, což je důležité pro řízení peněžních toků a vyhodnocení účinnosti vymáhání. Kde data získat Tato hodnota se obvykle vypočítá jako součet všech finančních transakcí (poplatků, plateb a úprav) pro danou účtovanou událost. Může být také uvedena jako pole v souhrnné tabulce účtů. Příklady 75.000.00550.80 | |||
| Oddělení fakturace BillingDepartment | Oddělení nebo funkční tým odpovědný za danou činnost. | ||
| Popis Tento atribut uvádí oddělení, například „Zachycení poplatků“, „Kódování“ nebo „Vymáhání pohledávek“, které činnost provedlo. Zasazuje průběh procesu do organizačního kontextu. Pohled na proces podle oddělení je důležitý pro pochopení předávání práce mezi týmy a odhalení neefektivit napříč odděleními. Podporuje dashboard „Pracovní zátěž oddělení fakturace“, protože umožňuje seskupovat činnosti a ukazatele výkonnosti podle oddělení. Proč je to důležité Přiřazuje činnosti organizačním jednotkám. To je důležité pro analýzu předávání práce mezi odděleními, pracovní zátěže a výkonnosti týmů. Kde data získat Tyto informace mohou být uloženy přímo v údajích o uživatelském profilu v Oracle Health nebo odvozeny podle uživatele či typu činnosti. Příklady Přístup k pacientůmKódováníFakturaceVymáhání pohledávek | |||
| Třída pacienta PatientClass | Klasifikace návštěvy pacienta, například hospitalizace nebo ambulantní péče. | ||
| Popis Tento atribut kategorizuje typ návštěvy nebo případu pacienta, za který vznikl poplatek. Mezi běžné kategorie patří hospitalizace, ambulantní péče, pohotovost a opakovaná návštěva. Třída pacienta často určuje celý postup fakturace a podání nároku na úhradu. Jednotlivé třídy pacientů mají odlišné průběhy procesu a požadavky na shodu. Analýza podle tohoto atributu pomáhá pochopit rozdíly, přizpůsobit zlepšování procesů a ověřit, že se pro každou třídu používají správné postupy. Proč je to důležité Odděluje různé průběhy procesu, například hospitalizaci a ambulantní péči, které mají odlišnou složitost, časové rámce a požadavky na fakturaci. Kde data získat Jde o standardní pole spojené se záznamem návštěvy nebo přijetí pacienta v Oracle Health. Příklady HospitalizaceAmbulantní péčeAkutníOpakovaný | |||
| Uživatel UserPerformingAction | ID nebo jméno uživatele, který činnost provedl. | ||
| Popis Tento atribut určuje zaměstnance nebo automatizovaného systémového uživatele odpovědného za konkrétní činnost v procesu. Pomáhá pochopit rozložení pracovní zátěže, výkonnost zdrojů i potřeby školení. Při analýze můžete podle tohoto atributu filtrovat mapu procesu podle uživatele nebo týmu, porovnávat výkonnost jednotlivých zdrojů a analyzovat pracovní zátěž na dashboardu „Pracovní zátěž oddělení fakturace“. Pomůže vám také najít nejvýkonnější pracovníky nebo ty, kteří potřebují další podporu či školení. Proč je to důležité Propojuje činnosti procesu s konkrétními uživateli nebo týmy. Umožňuje analyzovat pracovní zátěž, porovnávat výkonnost a určovat potřeby školení. Kde data získat Pole s ID uživatele, například „CREATED_BY“ nebo „USER_ID“, se obvykle nacházejí v transakčních tabulkách napříč moduly Oracle Health. Příklady j.doeasmithBillingBot_AUTOk.williams | |||
| Čas ukončení události EventEndTime | Časové razítko označující dokončení činnosti, pokud je k dispozici. | ||
| Popis Zatímco StartTime označuje začátek činnosti, EventEndTime označuje její konec. Ne všechny činnosti mají samostatný čas ukončení, protože mnohé proběhnou okamžitě. U činností, které určitou dobu trvají, například u vyřízení odvolání proti zamítnutí, je však toto pole velmi užitečné. Atribut umožňuje přesněji vypočítat dobu zpracování jednotlivých činností. Pomáhá odlišit čekání, tedy dobu mezi činnostmi, od zpracování, tedy času stráveného konkrétní činností. Proč je to důležité Umožňuje přímo vypočítat dobu potřebnou k dokončení činnosti a oddělit dobu zpracování od čekání. Kde data získat Některé transakční tabulky v Oracle Health Revenue Cycle mohou u konkrétních dlouhotrvajících úkolů obsahovat časové razítko začátku i konce. Příklady 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| Částka zaúčtovaného poplatku ChargeAmount | Hrubá peněžní hodnota účtované služby nebo produktu. | ||
| Popis Tento atribut udává původní částku za službu před uplatněním slev, smluvních úprav nebo plateb. Jde o výchozí finanční hodnotu účtované události. Sledování částky zaúčtovaného poplatku je důležité pro finanční analýzu. Pomáhá například vypočítat celkovou hodnotu poskytnutých služeb a zjistit finanční dopad následných úprav nebo odpisů. Slouží jako základ pro měření skutečně realizovaných výnosů. Proč je to důležité Určuje výchozí finanční hodnotu případu, která je základem pro další finanční analýzu a posouzení dopadů. Kde data získat V Oracle Health se nachází v tabulkách podrobností o poplatcích nebo transakcí s poplatky. Příklady 150.001250.7585.50 | |||
| Důvod reklamace DisputeReason | Důvod, který zákazník nebo pacient uvedl při reklamaci faktury či poplatku. | ||
| Popis Tento atribut zachycuje důvod, proč pacient nebo jiná odpovědná osoba reklamovala účet. Může jít například o nesprávné poplatky, neposkytnutou službu nebo problém se zpracováním pojištění. Tyto informace jsou důležité pro dashboard „Ukazatele řešení reklamací faktur“. Přehled nejčastějších důvodů reklamací pomáhá odhalit systémové problémy při zachycení poplatků, kódování nebo fakturaci. Řešení jejich příčin může výrazně snížit počet reklamací i administrativní náklady na jejich vyřízení. Proč je to důležité Vysvětluje, proč zákazníci reklamují faktury, a ukazuje na problémy s přesností nebo srozumitelností účtování, které je třeba napravit. Kde data získat Tyto informace se pravděpodobně ukládají v modulu správy případů nebo zákaznického servisu v Oracle Health a jsou propojené s pacientským účtem. Příklady Nesprávně účtovaná službaDuplicitní poplatekNesprávně účtované pojištěníSlužba nebyla poskytnuta | |||
| ID nároku ClaimId | Jedinečný identifikátor pojistného nároku odeslaného plátci. | ||
| Popis Tento atribut je jedinečné ID nároku vytvořeného a odeslaného plátci k úhradě. Z jedné účtované události může v průběhu jejího zpracování vzniknout jeden nebo více nároků, například pokud je nutná oprava. ID nároku umožňuje dohledat konkrétní podání plátci a propojit ho s odpovědí, například s platbou nebo zamítnutím. V rámci celého výnosového cyklu tak lze sledovat podrobnější úroveň než jen účtovanou událost. Proč je to důležité Umožňuje sledovat konkrétní nárok u plátce a poskytuje podrobnější identifikaci než celá účtovaná událost. Kde data získat Toto ID vytváří Oracle Health při založení nároku a ukládá ho do hlavní tabulky nároků. Příklady CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| ID pacienta PatientId | Jedinečný identifikátor pacienta spojeného s účtovanou událostí. | ||
| Popis Tento atribut je jedinečný identifikátor pacienta, kterému byla služba poskytnuta. Často se označuje jako číslo zdravotnické dokumentace (MRN). Propojuje finanční transakci s konkrétní osobou. ID pacienta není ID případu v procesu, ale umožňuje seskupit všechny účtované události jednoho pacienta a získat přehled o jeho finanční historii. Po propojení s hlavními údaji o pacientech lze data také rozdělit podle demografických údajů nebo historie pacienta. Proč je to důležité Propojuje finanční události s konkrétním pacientem a umožňuje analýzu z pohledu pacienta i souhrn všech jeho účtovaných služeb. Kde data získat Tento identifikátor je základní součástí hlavního záznamu pacienta a nachází se ve všech souvisejících transakčních tabulkách, například v tabulkách poplatků, nároků a plateb. Příklady MRN-1002345MRN-1002346MRN-1002347 | |||
| Jde o opakované zpracování IsRework | Příznak označující činnosti, které představují opakovanou práci nebo úsilí. | ||
| Popis Tento vypočítaný atribut označuje činnosti, které se odchylují od ideálního průběhu a vedou k opakované práci. Příkladem je „Odeslání opraveného nároku“ nebo „Odvolání proti zamítnutí“. K těmto činnostem by nedošlo, kdyby proces proběhl správně hned napoprvé. Jedním z cílů process mining je identifikovat a vyčíslit opakovanou práci. Tento příznak umožňuje snadno filtrovat a analyzovat všechny opakované průchody procesem a měřit jejich četnost, náklady i příčiny neefektivity. Pomáhá zjistit skutečné náklady na kvalitu ve výnosovém cyklu. Proč je to důležité Pomáhá vyčíslit četnost a dopad opakované práce, odhalit neefektivitu procesu a náklady na nedostatečnou kvalitu. Kde data získat Tento atribut se odvozuje při transformaci dat pomocí obchodních pravidel, která označují konkrétní názvy činností jako opakovanou práci. Příklady truefalse | |||
| Je automatizovaná IsAutomated | Příznak určující, zda činnost provedl automatizovaný systém, nebo uživatel. | ||
| Popis Tento logický atribut rozlišuje činnosti provedené automatizací, například botem nebo dávkovou úlohou systému, od činností provedených uživatelem. Například „Vygenerování nároku“ může být automatizovaný krok, zatímco „Odvolání proti zamítnutí“ pravděpodobně provádí člověk. Analýza tohoto atributu pomáhá zjistit míru automatizace procesu a její vliv na efektivitu a chybovost. Umožňuje porovnat automatizované a ruční postupy a najít další příležitosti k automatizaci. Proč je to důležité Rozlišuje činnosti prováděné lidmi a systémy. To je důležité pro vyhodnocení účinnosti automatizace a hledání dalších možností automatizace. Kde data získat Obvykle se odvozuje z atributu UserPerformingAction. Činnosti provedené pod ID uživatele, jako je „SYSTEM“ nebo „RPA_BOT“, se například označí jako automatizované. Příklady truefalse | |||
| Poslední aktualizace dat LastDataUpdate | Časové razítko poslední aktualizace nebo extrakce dat pro tuto událost. | ||
| Popis Tento atribut uvádí, kdy byla datová sada naposledy aktualizována. Informuje o aktuálnosti analyzovaných dat, což je důležité při posuzování, nakolik jsou poznatky z analýzy process mining aktuální. Uživatelé si mohou ověřit, zda pracují s nejnovějšími informacemi o procesu. Atribut pomáhá nastavit očekávání ohledně stáří dat a je důležitou součástí správy a kontroly kvality dat. Proč je to důležité Udává aktuálnost dat, abyste mohli analýzu a rozhodnutí opřít o nejnovější informace. Kde data získat Jde o pole metadat, které se obvykle vytváří a vyplňuje během procesu ETL při načítání dat do platformy process mining. Příklady 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Zdrojový systém SourceSystem | Systém, ze kterého byla data událostí získána. | ||
| Popis Tento atribut označuje zdrojovou aplikaci nebo modul, ze kterého data pocházejí. V tomto procesu půjde obvykle o Oracle Health Revenue Cycle, ale pokud se data spojují z více míst, může označovat i konkrétní moduly systému. Tyto informace jsou užitečné pro správu dat a řešení problémů. Pomáhají ověřit původ dat a jsou důležité v prostředích, kde se na jednom procesu od začátku do konce podílí více systémů. Proč je to důležité Udává původ dat, což je důležité pro jejich ověření a správu i pro pochopení odchylek v procesu, které mohou záviset na použitém systému. Kde data získat Často jde o statickou hodnotu, která se přidává během procesu extrakce, transformace a načítání dat (ETL) a označuje původ datové sady. Příklady OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
Aktivity v řízení výnosového cyklu
| Aktivita | Popis | ||
|---|---|---|---|
| Odeslání nároku na úhradu plátci | Označuje elektronické nebo papírové odeslání vytvořeného nároku na úhradu pojišťovně nebo jinému plátci. Systém by měl zaznamenat datum a čas odeslání. | ||
| Proč je to důležité Tato činnost spouští měření platebního cyklu. Doba od odeslání do platby je důležitá pro hodnocení výkonnosti plátců a počtu dnů pohledávek po splatnosti (DSO). Kde data získat Údaje pocházejí z modulu správy nároků, který zaznamenává události odeslání. V historii nároku hledejte časové razítko odeslání nebo změnu stavu na „Submitted“. Zachycení Událost se zaznamená po úspěšném odeslání nároku přes clearinghouse. Typ události explicit | |||
| Uzavření účtu | Poslední činnost, která označuje nulový zůstatek účtu a předpoklad, že už neproběhnou žádné další činnosti. Často se odvozuje z dosažení nulového zůstatku. | ||
| Proč je to důležité Označuje úspěšné dokončení výnosového cyklu. Doba do dosažení tohoto stavu je důležitým ukazatelem celkové efektivity procesu. Kde data získat Obvykle se odvozuje podle prvního okamžiku, kdy se nesplacený zůstatek účtu po zaúčtování všech plateb a úprav dostane na nulu a zůstane nulový. Zachycení Vypočítá se při prvním dosažení nulového zůstatku účtu po zaúčtování všech poplatků a plateb. Typ události calculated | |||
| Vytvoření nároku na úhradu | Označuje okamžik, kdy se jednotlivé poplatky spojí do formálního nároku na úhradu, například formuláře UB-04 nebo CMS-1500. Jde o událost vytvořenou systémem, při které vzniká první faktura. | ||
| Proč je to důležité Jde o důležitý milník, který znamená, že je vše připraveno k fakturaci plátci. Zároveň označuje konec období, které se měří jako prodleva od poplatku po fakturaci. Kde data získat Výslovná událost zaznamenaná v protokolech nebo tabulkách generování nároků na úhradu. Hledejte časové razítko vytvoření hlavního záznamu nároku spojeného s návštěvou. Zachycení Událost se zaznamená při vytvoření záznamu nároku na úhradu. Typ události explicit | |||
| Vytvoření návštěvy pacienta | Označuje vytvoření účtu pacienta pro konkrétní návštěvu nebo službu. Obvykle jde o výslovnou událost, kterou zaznamená registrační systém nebo datový tok Admit/Discharge/Transfer (ADT). | ||
| Proč je to důležité Jde o začátek celého výnosového cyklu pro danou fakturační událost. Umožňuje analyzovat celkovou dobu procesu i přesnost registrace. Kde data získat Údaje pocházejí z protokolů modulu Patient Registration nebo ADT. Hledejte události vytvoření návštěvy nebo nejstarší časové razítko spojené s návštěvou či finančním číslem. Zachycení Událost se zaznamená při registraci nebo přijetí pacienta. Typ události explicit | |||
| Zaúčtování platby | Označuje přiřazení platby od plátce k odpovídajícím poplatkům na účtu pacienta. Jde o finanční transakci zaznamenanou uživatelem nebo automatizovaným procesem. | ||
| Proč je to důležité Efektivita zaúčtování plateb ovlivňuje správnost pohledávek. Zpoždění mohou zkreslit finanční přehled a oddálit fakturaci dalšímu plátci. Kde data získat Údaje najdete v tabulkách platebních transakcí. Každé zaúčtování platby má jedinečné ID transakce a přiřazené časové razítko. Zachycení Finanční transakce se zaznamená při přiřazení platby k účtu. Typ události explicit | |||
| Kódování poplatků | Označuje proces, při kterém zdravotničtí kodéři přiřazují zachyceným poplatkům standardizované kódy, například CPT nebo ICD-10. Tato činnost se často sleduje podle změny stavu poplatku nebo návštěvy. | ||
| Proč je to důležité Zpoždění při kódování bývají častým úzkým místem. Sledováním této činnosti odhalíte neefektivitu v workflow kódování a její dopad na termíny fakturace. Kde data získat Často se odvozuje ze změny stavu návštěvy pacienta nebo dávky poplatků, například z „Uncoded“ na „Coded“. Je potřeba časové razítko této změny. Zachycení Odvozeno ze změny stavu návštěvy nebo poplatku na „Coded“ či „Ready for Billing“. Typ události inferred | |||
| Odeslání opraveného nároku na úhradu | Označuje odeslání upraveného nebo opraveného nároku plátci, obvykle po zamítnutí nebo žádosti o další informace. Rozpozná se podle nového odeslání nároku s příznakem opravy. | ||
| Proč je to důležité Tato činnost je důležitou součástí cyklu přepracování při správě zamítnutých nároků. Její častý výskyt ukazuje na problémy se správností původních nároků. Kde data získat Údaje se získávají z protokolů odesílání nároků. Hledejte nové odeslání pro již existující návštěvu, často označené kódem opětovného podání nebo vyšším číslem iterace. Zachycení Zaznamenaná událost opětovného podání nároku, kterou lze často identifikovat podle konkrétního kódu typu četnosti nároku. Typ události explicit | |||
| Odeslání vyúčtování pacientovi | Označuje vytvoření a odeslání faktury pacientovi za zbývající částku, kterou má uhradit. Jde o výslovnou akci zaznamenanou modulem fakturace pacientů. | ||
| Proč je to důležité Touto událostí začíná část výnosového cyklu, ve které platí pacient. Její sledování pomáhá vyhodnotit účinnost vymáhání plateb od pacientů. Kde data získat Údaje pocházejí z protokolů fakturace pacientů nebo korespondence. Systém by měl zaznamenat datum vytvoření nebo odeslání každého vyúčtování. Zachycení Událost se zaznamená při vytvoření a vytištění vyúčtování pacienta nebo jeho elektronickém odeslání. Typ události explicit | |||
| Odvolání proti zamítnutí | Akce uživatele nebo systému, která označuje, že se proti zamítnutému nároku podává odvolání. Obvykle se zaznamená jako změna stavu nebo konkrétní úkol vytvořený ve frontě práce. | ||
| Proč je to důležité Touto činností začíná cyklus přepracování. Analýza četnosti odvolání a jejich úspěšnosti je důležitá pro zlepšení vymáhání výnosů. Kde data získat Může jít o výslovnou akci uživatele nebo o odvození ze změny stavu nároku, například na „Appealed“ či „In Review“. Zachycení Změna stavu nebo zaznamenaná událost, když uživatel zahájí odvolání proti zamítnutému nároku. Typ události explicit | |||
| Přijetí vyúčtování od plátce | Označuje přijetí elektronického avíza o platbě (ERA) nebo papírového vysvětlení plnění (EOB) od plátce. Dokument uvádí, které poplatky byly uhrazeny, zamítnuty nebo upraveny. | ||
| Proč je to důležité Jde o první odpověď plátce. Je důležitá pro pochopení rychlosti plateb a včasné odhalení trendů v zamítání nároků. Kde data získat Zaznamenává se v modulu zpracování vyúčtování. Hledejte časové razítko importu nebo vytvoření souboru ERA, například transakčního souboru 835, propojeného s nárokem. Zachycení Událost se zaznamená při importu a zpracování souboru s vyúčtováním od plátce, například ANSI 835. Typ události explicit | |||
| Přijetí zamítnutí nároku | Označuje situaci, kdy plátce zamítne nárok na úhradu nebo konkrétní položky, jak je uvedeno ve vyúčtování. Událost se často odvozuje z kódů zamítnutí v datech vyúčtování. | ||
| Proč je to důležité Sledování zamítnutí je zásadní pro odhalení jejich příčin, například chyb v kódování nebo problémů s nárokem na úhradu, a pro zvýšení podílu správně podaných nároků. Kde data získat Odvozeno z dat vyúčtování (ERA/835). Událost se spustí, pokud má nárok nebo jeho položka nenulovou částku zamítnutí a odpovídající kód důvodu zamítnutí. Zachycení Odvozeno z dat vyúčtování obsahujících kódy důvodů zamítnutí (CARC/RARC). Typ události inferred | |||
| Úprava účtu | Označuje finanční úpravu zůstatku účtu, například smluvní slevu, odpis nebo jinou slevu. Každá úprava je samostatná finanční transakce. | ||
| Proč je to důležité Úpravy přímo ovlivňují výnosy. Analýza jejich četnosti, typu a částky pomáhá odhalit úniky výnosů a nepřesnosti ve fakturaci. Kde data získat Údaje najdete v tabulkách finančních transakcí. Každá úprava se zaznamená jako samostatná položka s konkrétním kódem transakce a časovým razítkem. Zachycení Finanční transakce se zaznamená s konkrétním kódem úpravy. Typ události explicit | |||
| Zachycení poplatků | Označuje zadání zpoplatněných služeb nebo položek na účet pacienta. Může proběhnout automaticky z klinických systémů nebo ručním zadáním pracovníkem. | ||
| Proč je to důležité Tato činnost je důležitá pro měření prodlevy při zachycení poplatku, tedy doby mezi poskytnutím služby a zahájením fakturace. Tato prodleva přímo ovlivňuje cash flow i správnost výnosů. Kde data získat Údaje se získávají z tabulek transakcí poplatků. Jednotlivé položky se identifikují podle časového razítka jejich vytvoření. V Oracle Health bývají tyto údaje v tabulkách souvisejících s poplatky. Zachycení Pro každý nový poplatek se vytvoří záznam v transakčním protokolu. Typ události explicit | |||
| Zahájení vymáhání pohledávky | Označuje převedení účtu pacienta do procesu vymáhání kvůli nezaplacení. Obvykle se zaznamená změnou finanční třídy účtu nebo jeho stavu. | ||
| Proč je to důležité Jde o důležitý krok při správě nedobytných pohledávek. Pro finanční zdraví je zásadní analyzovat, co k této fázi vede a jaká je její úspěšnost. Kde data získat Odvozeno ze změny pole stavu účtu na „Collections“ nebo „Bad Debt“. Tato změna stavu by měla mít přiřazené časové razítko. Zachycení Odvozeno ze změny stavu účtu na „Collections“ nebo podobný stav. Typ události inferred | |||
Návody k extrakci dat
Kroky
- Požádejte o přístup k databázi: Získejte přihlašovací údaje s oprávněním pouze ke čtení pro databázi Oracle Health Revenue Cycle. Budete potřebovat přístup ke schématům s údaji o pacientech, návštěvách, fakturaci a finančních transakcích. Obvykle je nutné získat souhlas týmů IT bezpečnosti a správy databází.
- Zjistěte názvy schémat a tabulek: S administrátorem databáze nebo systémovým analytikem ověřte přesné názvy schémat a tabulek ve vaší instanci Oracle Health. Názvy uvedené v dotazu jsou běžné zástupné hodnoty, které je nutné namapovat na vaše prostředí.
- Nainstalujte klienta SQL: Na pracovní stanici nainstalujte kompatibilního klienta SQL, například Oracle SQL Developer nebo DBeaver. Pomocí tohoto nástroje se připojíte k databázi a spustíte extrakční skript.
- Připojte se k databázi: V klientovi SQL nastavte nové připojení pomocí zadaného hostitele, portu, názvu služby a přihlašovacích údajů. Otestujte, zda připojení funguje.
- Upravte dotaz SQL: Zkopírujte dodaný skript SQL do nového okna editoru dotazů. Najděte zástupné hodnoty, například
[START_DATE]a[END_DATE], a nahraďte je požadovaným časovým obdobím analýzy, například „2023-01-01“. Podle potřeby upravte filtry, například filtr pro konkrétní Patient Class. - Spusťte extrakční skript: Spusťte upravený skript SQL. Dotaz je navržen pro rozsáhlou extrakci a jeho dokončení může trvat několik minut až několik hodin, podle zvoleného období a velikosti databáze.
- Zkontrolujte první výsledky: Po dokončení dotazu si v mřížce výsledků klienta SQL prohlédněte prvních několik set řádků. Ověřte, že se neobjevují zjevné chyby, například sloupce obsahující pouze hodnoty null nebo nesprávné formáty dat.
- Exportujte data do CSV: Exportujte celou sadu výsledků do souboru CSV. Použijte kódování UTF-8, aby nedocházelo k problémům se znaky. Ověřte, že export obsahuje řádek záhlaví s názvy sloupců uvedenými v aliasu dotazu, například „BillingEvent“ a „ActivityName“.
- Připravte soubor k nahrání: Před nahráním do nástroje process mining otevřete soubor CSV a ověřte jeho správnost. Zkontrolujte, zda mají časová razítka jednotný formát a záhlaví sloupců přesně odpovídají požadovaným atributům. Soubor je nyní připraven k nahrání.
Konfigurace
- Časové období: Dotaz používá zástupné hodnoty
[START_DATE]a[END_DATE]. Určete konkrétní a přiměřené období, abyste měli objem dat pod kontrolou. Pro první analýzu doporučujeme 3 až 6 měsíců. - Filtrování: Počáteční datová sada se v části
RelevantEncountersfiltruje podle data registrace návštěvy (reg_dt_tm). Další podmínkyWHEREmůžete přidat do této části a zúžit tak rozsah, napříklade.patient_class_code IN ('INPATIENT', 'OUTPATIENT')pro výběr konkrétních typů návštěv. - Výkon: Přímé dotazování do produkční databáze může ovlivnit její výkon. Extrakci proto doporučujeme spouštět mimo špičku, případně použít repliku produkční databáze určenou pouze ke čtení, pokud je k dispozici.
- Předpoklady: Tato metoda vyžaduje databázový účet s oprávněním
SELECTke všem tabulkám uvedeným v dotazu. Patří mezi ně tabulky návštěv, fakturace, poplatků, nároků, vyúčtování, plateb a finančních transakcí. - Mapování tabulek a sloupců: Dodaný skript používá běžné, reprezentativní názvy tabulek a sloupců. Ověřte je a namapujte na skutečné názvy ve schématu Oracle Health vaší organizace. Například
FINANCIAL_TRANSACTIONse ve vašem systému může jmenovatAR_TRANSACTIONS.
Ukázkový dotaz 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; Chcete začít?
Pomocí této šablony připravíte data pro úspěšnou analýzu. Začněte zlepšovat proces řízení výnosového cyklu ještě dnes.
Zlepšete výnosový cyklus a urychlete platby
Odstraňte úzká místa, zkraťte dobu cyklu o 30 % a zlepšete tok peněz.
Kreditní kartu nepotřebujete. Nastavení zabere jen několik minut.