Šablona dat pro řízení cyklu tržeb
Šablona dat pro řízení cyklu tržeb
- Doporučené atributy ke sběru
- Důležité aktivity pro mapování procesů
- Podrobný návod na získání dat z R1 RCM
Atributy řízení cyklu tržeb
| Název | Popis | ||
|---|---|---|---|
| Čas události EventTime | Časové razítko udávající, kdy došlo ke konkrétní činnosti nebo události. | ||
| Popis Čas události udává přesné datum a čas, kdy byla činnost zaznamenána v systému. Tyto časové údaje jsou základem pro analýzu procesu z časového hlediska. V process mining se podle časových razítek řadí události chronologicky a počítá doba mezi činnostmi, což je důležité pro analýzu výkonnosti. Lze tak vypočítat ukazatele, jako je celková doba průchodu, doba zpracování a čekání. Tyto údaje pomáhají odhalit úzká místa a měřit efektivitu. Proč je to důležité Toto časové razítko je základem veškeré časové analýzy. Umožňuje počítat dobu průchodu, odhalovat úzká místa a sledovat výkonnost procesu vůči SLA. Kde data získat V R1 RCM se obvykle jedná o pole „Creation Date“, „Timestamp“ nebo „Last Update Date“ přiřazené ke každé transakci nebo záznamu o změně stavu. Příklady 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z | |||
| Fakturační událost BillingEvent | Jedinečný identifikátor jednotlivé zpoplatněné služby nebo položky, který slouží jako hlavní identifikátor případu pro sledování celého cyklu výnosů. | ||
| Popis ID fakturační události označuje konkrétní poskytnutí služby nebo dodání produktu, za které se účtuje poplatek. Propojuje všechny související činnosti, od poskytnutí služby a zachycení poplatku přes podání nároku a zaúčtování platby až po uzavření účtu. V process mining umožňuje analýza životního cyklu každé fakturační události získat ucelený přehled o celém cyklu výnosů. Sleduje průběh jednotlivého poplatku, odhaluje obvyklé cesty, měří dobu mezi důležitými milníky a pomáhá pochopit odchylky, které vedou ke zpožděním nebo výpadkům výnosů. Proč je to důležité Tento identifikátor je nezbytný pro seskupení všech souvisejících činností do jednoho případu. Díky tomu lze přesně analyzovat celý proces cyklu výnosů pro každou zpoplatněnou událost. Kde data získat Jde o primární klíč, který propojuje různé tabulky týkající se návštěv pacientů, poplatků, nároků a plateb. Konkrétní pole najdete v dokumentaci R1 RCM. Obvykle souvisí s identifikátorem návštěvy nebo nároku. Příklady BE-2023-0012345BE-2023-0054321BE-2024-0098765 | |||
| Název činnosti ActivityName | Název konkrétní obchodní události nebo úkolu, který v určitém okamžiku nastal v rámci procesu cyklu výnosů. | ||
| Popis Tento atribut popisuje jednotlivý krok nebo milník v procesu správy cyklu výnosů pro danou fakturační událost. Činnosti představují vykonanou práci, například „Zachycení poplatků“, „Podání nároku“ nebo „Zaúčtování platby“. Analýza posloupnosti činností je základem process mining. Umožňuje odhalit skutečný průběh procesu, najít úzká místa, kde zahájení činností trvá příliš dlouho, a odhalit opakované kroky, například když po „Zamítnutí nároku“ následuje „Zahájení přepracování zamítnutí“. Proč je to důležité Určuje jednotlivé kroky procesu. Díky tomu lze zobrazit mapu procesu, vypočítat dobu mezi kroky a odhalit odchylky i opakované práce. Kde data získat Tyto údaje se obvykle získávají ze záznamů událostí, záznamů o změnách stavu nebo transakčních kódů v různých modulech R1 RCM. Technické kódy může být nutné převést na srozumitelné obchodní názvy. Příklady Poplatky zachycenyNárok odeslánOdpověď plátce na nárok přijataPlatba zaúčtovánaÚčet uzavřen | |||
| Poslední aktualizace dat LastDataUpdate | Časové razítko poslední aktualizace nebo extrakce dat ze zdrojového systému. | ||
| Popis Tento atribut udává, kdy byla naposledy aktualizována data pro analýzu process mining. Pomáhá posoudit jejich aktuálnost. Tento údaj je důležitý pro reporty a dashboardy, protože uživatelům ukazuje, jak aktuální jsou získané poznatky o procesu. Umožňuje nastavit správná očekávání ohledně stáří dat a zajistit, aby se rozhodnutí opírala o známé časové období. Proč je to důležité Ukazuje, jak aktuální jsou data, aby analytici i další zainteresovaní věděli, nakolik lze poznatkům o procesu důvěřovat z hlediska jejich stáří. Kde data získat Toto časové razítko se vytváří při procesu extrakce, transformace a načítání dat (ETL) a obvykle se vztahuje k celé datové sadě. Příklady 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Zdrojový systém SourceSystem | Systém, ze kterého byla data o události získána. | ||
| Popis Tento atribut označuje zdrojovou aplikaci nebo modul, který vytvořil data pro danou událost. Ve zdravotnictví mohou data pocházet například z EMR, fakturačního modulu, centra pro zpracování nároků nebo platformy pro vymáhání pohledávek. Znalost zdrojového systému je důležitá pro ověřování dat i analýzu odchylek, které se mohou týkat jen některých systémů. Pomáhá řešit nesrovnalosti v datech a pochopit technologické zázemí procesu. Proč je to důležité Určuje původ dat. To je důležité pro správu a ověřování dat i pro pochopení toho, jak spolu jednotlivé systémy v celém procesu spolupracují. Kde data získat Často jde o statickou hodnotu přidanou při extrakci dat, která označuje systém, například „R1 RCM“, z něhož data pocházejí. Příklady R1 RCMCernerEpic | |||
| Částka faktury InvoiceAmount | Celková peněžní hodnota poplatků na faktuře nebo nároku. | ||
| Popis Tento atribut představuje celkovou vyúčtovanou částku za služby poskytnuté v rámci dané fakturační události. Vyjadřuje očekávaný výnos z nároku. Analýza částky faktury je důležitá pro finanční process mining. Pomáhá upřednostnit nároky s vysokou hodnotou, pochopit finanční dopad zpoždění nebo zamítnutí a rozdělit proces podle hodnoty. Analýza může například ukázat, že nároky nad určitou částku procházejí jiným, více manuálním postupem. Proč je to důležité Doplňuje finanční kontext procesu. Umožňuje analyzovat, jak odchylky v procesu ovlivňují výnosy, a při zlepšování upřednostnit případy s vysokou hodnotou. Kde data získat V R1 RCM se nachází v hlavní tabulce nároků nebo hlaviček faktur, často pod názvem „TotalBilledAmount“ nebo podobným. Příklady 150.002500.7585.5012000.00 | |||
| Fakturační oddělení BillingDepartment | Oddělení nebo funkční tým odpovědný za provedení činnosti. | ||
| Popis Tento atribut označuje organizační jednotku, například „Zadávání poplatků“, „Podávání nároků“ nebo „Řešení zamítnutí“, která provedla konkrétní krok procesu. Pomáhá pochopit předávání práce mezi týmy. Je důležitý pro analýzu průchodnosti jednotlivých oddělení a odhalování úzkých míst mezi týmy. Po filtrování mapy procesu podle oddělení uvidíte, kde se práce předává hladce a kde dochází ke zpožděním. Tyto informace pomáhají při rozdělování zdrojů a zlepšování procesů v organizaci. Proč je to důležité Umožňuje analyzovat výkonnost procesu podle organizačních jednotek a odhalit úzká místa, nedostatek zdrojů nebo osvědčené postupy v jednotlivých týmech. Kde data získat Údaj lze získat z profilu uživatele v R1 RCM nebo z pole „Department Code“ v transakčních datech. Příklady Zachycení poplatkůSpráva nárokůZamítnutí a odvoláníZaúčtování plateb | |||
| Kód důvodu zamítnutí DenialReasonCode | Standardizovaný kód plátce, který vysvětluje, proč byl nárok zamítnut. | ||
| Popis Když plátce zamítne nárok, uvede důvodový kód, například CARC (Claim Adjustment Reason Code), který jeho rozhodnutí vysvětluje. Tyto standardizované kódy označují například „Služba není hrazena“ nebo „Duplicitní nárok“. Tento atribut je pro řešení zamítnutí velmi důležitý. Analýza četnosti jednotlivých důvodových kódů pomáhá organizacím odhalit a řešit příčiny zamítnutí, ať už souvisejí s nárokem pacienta na úhradu, chybami v kódování nebo nedostatečným lékařským odůvodněním. Tím lze omezit opakovanou práci a urychlit peněžní tok. Proč je to důležité Uvádí konkrétní důvod zamítnutí nároku. Umožňuje hledat příčiny, předcházet dalším zamítnutím, omezit opakovanou práci a zvýšit podíl plateb při prvním podání. Kde data získat Tyto údaje přicházejí od plátce v elektronickém vyúčtování (soubor ERA nebo 835) a ukládají se v modulu správy nároků R1 RCM. Příklady CO-16: V nároku nebo žádosti o službu chybí údaje potřebné k posouzení.PR-97: Úhrada této služby je zahrnuta v platbě nebo příspěvku za jinou službu.CO-22: Tuto péči může podle pravidel koordinace dávek hradit jiný plátce.OA-18: Přesně duplicitní nárok nebo služba. | |||
| Název plátce PayerName | Název pojišťovny, státní instituce nebo pacienta odpovědného za platbu. | ||
| Popis Tento atribut označuje hlavního plátce nároku. Může jít o komerční pojišťovnu, například Aetna, státního plátce, například Medicare, nebo o samotného pacienta, který hradí část nákladů přímo. Analýza procesu podle plátce je základem správy cyklu výnosů. Může odhalit, že někteří plátci častěji zamítají nároky, déle zpracovávají platby nebo mají složitější požadavky na podání. Organizace pak může přizpůsobit procesy a zdroje specifickým postupům jednotlivých plátců. Proč je to důležité Umožňuje rozdělit proces podle plátce a odhalit zpoždění, vzorce zamítání nebo způsoby úhrady specifické pro jednotlivé plátce. Tyto poznatky pomáhají zlepšovat výnosy. Kde data získat V R1 RCM se nachází v údajích o pojištění nebo demografických údajích pacienta propojených s nárokem. Příklady MedicareUnitedHealthcareBlue Cross Blue ShieldAetnaPřímá úhrada pacientem | |||
| Přiřazený uživatel AssignedUser | ID nebo jméno zaměstnance, který provedl danou činnost. | ||
| Popis Tento atribut označuje osobu odpovědnou za konkrétní úkol v procesu. Může jít například o pracovníka fakturace, který vytvořil nárok, analytika, který znovu zpracoval zamítnutí, nebo specialistu, který zaúčtoval platbu. Analýza podle uživatele pomáhá pochopit rozložení pracovní zátěže, individuální výkonnost a potřeby školení. Ukáže, kdo pracuje nejefektivněji nebo u koho se častěji objevují chyby. Na základě toho lze cíleně upravit řízení týmu a zlepšovat procesy. Proč je to důležité Umožňuje analyzovat výkonnost týmů i jednotlivců a rozložení pracovní zátěže. Pomáhá také odhalit potřebu školení nebo odchylky v práci konkrétních uživatelů. Kde data získat V transakčních záznamech R1 RCM se obvykle jedná o pole „UserID“, „Processor“ nebo „UpdatedBy“. Příklady jdoeasmithp.jonesBOT_RPA01 | |||
| Stav faktury InvoiceStatus | Aktuální stav faktury nebo nároku v průběhu jeho životního cyklu. | ||
| Popis Tento atribut uvádí poslední známý stav fakturační události, například „Podáno“, „Uhrazeno“, „Zamítnuto“ nebo „Ve vymáhání“. Ukazuje, v jaké fázi procesu se faktura v danou chvíli nachází. Stav faktury je důležitý pro tvorbu přehledů pohledávek podle stáří a sledování jejich stavu. V process mining lze podle něj filtrovat případy, které uvízly v určitém stavu, nebo porovnávat výsledky různých variant procesu, například průběh nároků „Uhrazeno“ a „Zamítnuto“. Proč je to důležité Ukazuje aktuální stav každého případu. Je nezbytný pro tvorbu přehledů pohledávek podle stáří a analýzu konečných výsledků různých průběhů procesu. Kde data získat V R1 RCM jde obvykle o pole se stavem v hlavním záznamu nároku nebo účtu. Příklady Čeká na podáníPodáno plátciZamítnutoPlně uhrazenoVe vymáhání | |||
| Automatizováno IsAutomated | Příznak určující, zda činnost provedl automatizovaný systém, nebo uživatel. | ||
| Popis Tento booleovský atribut rozlišuje úkoly provedené softwarovou automatizací, například RPA botem při podání nároku, od úkolů, které ručně provedl zaměstnanec. Analýza tohoto atributu pomáhá pochopit dopad a účinnost automatizace. Umožňuje porovnat rychlost, náklady a chybovost automatizovaných a manuálních procesů, odhalit další příležitosti k automatizaci a vyhodnotit návratnost stávajících botů. Proč je to důležité Rozlišuje činnosti provedené člověkem a systémem. To je důležité pro měření dopadu automatizace na efektivitu, náklady a kvalitu procesu. Kde data získat Údaj lze odvodit z pole „AssignedUser“, pokud jsou konkrétní ID uživatelů vyhrazená pro boty, například „BOT_RPA01“. Některé systémy mají také samostatné pole označující automatizované transakce. Příklady truefalse | |||
| Částka úpravy AdjustmentAmount | Peněžní hodnota úpravy zůstatku na účtu. | ||
| Popis Tento atribut zachycuje hodnotu finančních úprav provedených na účtu pacienta po prvotním vyúčtování. Úpravy mohou být kladné i záporné a zahrnují smluvní slevy, odpisy nebo opravy. Sledování částek úprav je důležité pro kontrolu správnosti výnosů. Vysoký objem záporných úprav může ukazovat na výpadky výnosů způsobené například nesprávným zachycením poplatků nebo nedobytnými pohledávkami. Analýza těchto údajů pomáhá určit finanční dopad chyb ve fakturaci a neefektivního vymáhání. Proč je to důležité Vyčísluje výpadky výnosů a finanční opravy. Pomáhá určit peněžní dopad nepřesností ve fakturaci, smluvních závazků nebo nedobytných pohledávek. Kde data získat V R1 RCM se nachází v transakčních záznamech týkajících se úprav účtu nebo zaúčtování plateb. Příklady -50.2520.00-1200.00 | |||
| Doba od poskytnutí služby do úhrady ServiceToPaymentCycleTime | Celková vypočítaná doba od poskytnutí služby do zaúčtování konečné platby. | ||
| Popis Tato metrika měří celkovou dobu cyklu výnosů pro jednu fakturační událost. Udává, jak dlouho organizaci trvá převést poskytnutou službu na peněžní prostředky. Jde o důležitý KPI pro finanční zdraví organizace. Analýza této doby pomáhá určit, kde lze proces nejvíce urychlit. Rozdělením celkové doby na jednotlivé části, například „doba do vyúčtování“ a „doba do úhrady“, lze určit největší příležitosti ke zlepšení peněžního toku. Proč je to důležité Tento souhrnný KPI měří celkovou efektivitu přeměny pohledávek na peněžní prostředky a přímo ovlivňuje peněžní tok organizace. Kde data získat Jde o vypočítanou metriku. Představuje časový rozdíl mezi časovým razítkem činnosti „Služba poskytnuta“ a činnosti „Platba zaúčtována“ pro danou fakturační událost. Příklady 35 dní 8 hodin92 dní 4 hodiny15 dní 12 hodin | |||
| Důvod úpravy AdjustmentReason | Důvod finanční úpravy, například „Smluvní sleva“ nebo „Odpis nedobytné pohledávky“. | ||
| Popis Tento atribut vysvětluje, proč byla na účtu provedena finanční úprava. Důvody se obvykle zaznamenávají pomocí standardizovaných kódů nebo popisů, které určují typ úpravy. Analýza důvodů úprav pomáhá odhalit příčiny výpadků výnosů. Časté odpisy malých zůstatků mohou například ukazovat na neefektivní vymáhání drobných částek, zatímco časté smluvní slevy jsou běžnou součástí jednání s plátci. Tato analýza podporuje dashboard Billing Adjustments & Compliance Audit. Proč je to důležité Vysvětluje důvody úprav výnosů a pomáhá odhalit příčiny jejich ztráty, například smluvní problémy, chyby ve fakturaci nebo neúspěšné vymáhání. Kde data získat V R1 RCM jde obvykle o kód nebo textové pole ve stejném transakčním záznamu jako AdjustmentAmount. Příklady Smluvní slevaOdpis nedobytné pohledávkyOdpis malého zůstatkuOprava chyby ve fakturaci | |||
| ID pacienta PatientId | Jedinečný identifikátor pacienta, kterému byla služba poskytnuta. | ||
| Popis Tento atribut je jedinečné ID přidělené pacientovi ve zdravotnickém systému, často označované jako číslo zdravotnické dokumentace (MRN). Analýza se nezaměřuje na péči o jednotlivé pacienty, ale ID pacienta lze využít k odhalení opakujících se problémů s fakturací u stejného pacienta. Pokud se propojí s dalšími údaji o pacientech, může také pomoci rozdělit proces podle demografických údajů nebo historie pacienta a odhalit systémové problémy, které se týkají určitých skupin pacientů. Proč je to důležité Umožňuje analyzovat fakturační události na úrovni pacientů a odhalit opakující se problémy nebo vzorce u konkrétních pacientů napříč návštěvami. Kde data získat Tento identifikátor je základní součástí demografických údajů pacienta propojených s každou návštěvou a nárokem v R1 RCM. Příklady MRN837262MRN937281MRN103847 | |||
| Kód služby ServiceCode | Fakturační kód konkrétní poskytnuté služby nebo zákroku, například kód CPT nebo HCPCS. | ||
| Popis Kódy služeb, například CPT (Current Procedural Terminology), jsou standardizované zdravotnické kódy používané k vykazování zdravotních, chirurgických a diagnostických zákroků a služeb plátcům za účelem úhrady. Analýza procesu podle kódu služby pomáhá odhalit problémy s fakturací u konkrétních typů péče. Ukáže, které zákroky se nejčastěji zamítají, u kterých trvá úhrada nejdéle nebo které vyžadují nejvíce opakované práce. Na základě toho lze cíleně zlepšovat kódování a fakturaci. Proč je to důležité Umožňuje analyzovat proces podle typu poskytnuté služby a odhalit vzorce zamítání nebo zpoždění plateb u konkrétních zákroků. Kde data získat V R1 RCM se tento údaj nachází na úrovni jednotlivých položek každého poplatku nebo nároku. Příklady 992139928573560 | |||
| Opakovaná práce IsRework | Vypočítaný příznak, který označuje činnosti spadající do opakovaného cyklu, například opětovné podání zamítnutého nároku. | ||
| Popis Tento booleovský příznak se obvykle vypočítává při analýze process mining. Nabývá hodnoty „true“, pokud se činnost opakuje po předchozím kroku nebo je součástí posloupnosti, která ukazuje na opravu chyby, například pokud následuje po činnosti „Nárok zamítnut“. Odhalování opakované práce patří mezi důležité možnosti process mining. Umožňuje vyčíslit zbytečně vynaložený čas, úsilí a zdroje. Když organizace opakovanou práci označí, může se zaměřit na prevenci chyb, které ji způsobují, a zvýšit tak efektivitu. Proč je to důležité Pomáhá vyčíslit četnost a dopad opakované práce, například po zamítnutí nároku, a cíleně analyzovat možnosti, jak omezit neefektivitu a zbytečně vynaložené úsilí. Kde data získat Toto pole není ve zdrojovém systému. Vypočítává ho nástroj process mining podle posloupnosti činností, například když zjistí, že se činnost „Nárok podán“ u stejného případu opakuje. Příklady truefalse | |||
| Výsledek vymáhání CollectionOutcome | Konečný výsledek vymáhání dlužné částky. | ||
| Popis Tento atribut popisuje výsledek vymáhání platby po splatnosti. Mezi možné výsledky patří „Paid in Full“, „Settled“, „Placed in Bad Debt“ nebo „Unresolved“. Sledování výsledků vymáhání je důležité pro vyhodnocení jeho efektivity. Analýza činností a jejich výsledků vám pomůže upravit strategii vymáhání, zvýšit míru úspěšného inkasa a rozhodnout, kdy vymáhání ukončit a pohledávku odepsat. Tyto informace využijete v dashboardu Výkonnost činností vymáhání. Proč je to důležité Měří účinnost vymáhání podle konečného vyřešení pohledávek po splatnosti a pomáhá upravit strategii vymáhání. Kde data získat Pravděpodobně jde o pole se stavem na účtu pacienta nebo ve vyhrazeném modulu pro vymáhání v rámci R1 RCM. Příklady Plně uhrazenoDohodnuta nižší částkaPředáno externí agentuřeOdepsáno jako nedobytná pohledávka | |||
Aktivity v řízení cyklu tržeb
| Aktivita | Popis | ||
|---|---|---|---|
| Nárok odeslán | Vytvořený nárok se elektronicky odešle příslušnému plátci, například pojišťovně. Jde o první externí komunikaci ve fakturačním procesu, jejímž cílem je získat úhradu. | ||
| Proč je to důležité Důležitý milník, od kterého se počítá doba do úhrady plátcem. Sledování této události pomáhá kontrolovat nevyřízená podání a dodržovat lhůty pro odeslání nároků plátcům. Kde data získat Tato událost se zaznamená jako konkrétní transakce při odeslání nároku do clearingového centra. Systém uloží časové razítko odeslání a údaje o potvrzení. Zachycení Zaznamená se jako transakce s časovým razítkem odeslání, když je nárok odeslán přes clearingové centrum. Typ události explicit | |||
| Platba přijata | Platba byla přijata od plátce nebo pacienta. Událost označuje přijetí peněz, které však ještě nebyly přiřazeny ke konkrétnímu účtu nebo položkám za služby. | ||
| Proč je to důležité Označuje příliv peněz. Čas mezi událostmi „Platba přijata“ a „Platba zaúčtována“ je důležitým ukazatelem efektivity administrativního zpracování a prodlev při párování plateb. Kde data získat Zaznamenává se z elektronických souborů s úhradami od plátců nebo při zpracování plateb pacientů. Událost odpovídá datu vkladu nebo přijetí souboru. Zachycení Zaznamená se podle data účinnosti platby v souboru ERA nebo data transakce pacientovy platby. Typ události explicit | |||
| Platba zaúčtována | Přijatá platba se oficiálně přiřadí k účtu pacienta a sníží jeho neuhrazený zůstatek. Jde o závěrečný krok při párování platby s vyúčtovanými službami. | ||
| Proč je to důležité Tato aktivita označuje konec doby od poskytnutí služby po platbu a doby zaúčtování platby. Potvrzuje zaúčtování výnosu a aktualizaci účtů. Kde data získat Zaznamenává se jako konkrétní finanční transakce v modulu účtování pacientů R1 RCM. Každé zaúčtování obsahuje datum, částku a zdroj. Zachycení Zaznamená se jako konkrétní transakce s datem zaúčtování, když uživatel nebo automatizovaný proces přiřadí platbu. Typ události explicit | |||
| Poplatky zachyceny | Tato aktivita označuje formální zaznamenání všech zpoplatněných služeb, zákroků a pomůcek při návštěvě pacienta. Jde o důležitý krok zadávání dat, který převádí klinické úkony na finanční transakce. | ||
| Proč je to důležité Označuje předání z klinického provozu do finančního. Je výchozím bodem pro měření doby vystavení faktury a vytvoření nároku a pomáhá odhalit nevyřízené zadávání poplatků. Kde data získat Zaznamenává se v modulu zadávání poplatků R1 RCM nebo se přijímá přes rozhraní z EHR. Událost obvykle označuje konkrétní záznam transakce nebo časové razítko vytvoření záznamu o poplatku. Zachycení Určuje se podle časového razítka vytvoření záznamu o transakci s poplatkem ve fakturační tabulce. Typ události explicit | |||
| Služba poskytnuta | Označuje okamžik, kdy je pacientovi dokončena zpoplatněná služba nebo zákrok. Tato událost se obvykle zaznamenává v klinickém nebo plánovacím systému a spouští výnosový cyklus. | ||
| Proč je to důležité Tato událost označuje začátek KPI doby od poskytnutí služby po platbu. Analýza času od této události pomáhá odhalit prodlevy na začátku výnosového cyklu. Kde data získat Obvykle pochází z elektronické zdravotní dokumentace (EHR) nebo systému pro správu ordinace propojeného s R1 RCM. Často se odvozuje od časového razítka „Datum služby“ nebo „Zákrok dokončen“ v záznamu pacienta. Zachycení Odvozeno od časového razítka „Datum poskytnutí služby“ přiřazeného k návštěvě pacienta. Typ události inferred | |||
| Účet uzavřen | Fakturační událost je plně vyřešena, zůstatek je nulový a účet je formálně uzavřen. Tím je výnosový cyklus pro danou návštěvu úspěšně dokončen. | ||
| Proč je to důležité Jde o hlavní závěrečnou událost standardního průběhu procesu. Měření doby uzavření účtu pomáhá zajistit efektivní dokončení administrativních úkonů a uzavření záznamů. Kde data získat Událost se odvozuje z okamžiku, kdy zůstatek účtu dosáhne nuly a je nastaven konečný stav „Uzavřen“ nebo „Plně uhrazen“. Časové razítko se převezme z poslední finanční transakce, která zůstatek vynulovala. Zachycení Odvozeno z okamžiku, kdy zůstatek účtu klesne na nulu a nastaví se stav „Uzavřen“, spolu s časovým razítkem závěrečné aktivity. Typ události inferred | |||
| Nárok vytvořen | Na základě zachycených poplatků se v systému vytvoří formální fakturační nárok. Zahrnuje shromáždění demografických údajů pacienta, informací o pojištění a kódů služeb do standardizovaného formátu. | ||
| Proč je to důležité Jde o důležitý interní milník před odesláním nároku. Prodlevy v této fázi mohou ukazovat na problémy s kódováním, ověřováním dat nebo konfigurací systému, které zpomalují celý fakturační proces. Kde data získat Jde o interní systémovou událost v R1 RCM. Pravděpodobně se zaznamenává jako změna stavu fakturačního účtu nebo podle časového razítka vytvoření samotného nároku. Zachycení Odvozeno ze změny stavu na „Nárok vytvořen“ nebo z časového razítka vytvoření záznamu o nároku. Typ události inferred | |||
| Nárok zamítnut | Plátce odmítl nárok uhradit, ať už celý, nebo jen některé jeho položky. Zaznamená se důvod zamítnutí a zahájí se oprava a odvolání. | ||
| Proč je to důležité Tato aktivita upozorňuje na ztrátu výnosů a neefektivitu procesu. Analýza důvodů zamítnutí je nezbytná pro odhalení příčin a zvýšení podílu nároků přijatých hned napoprvé. Kde data získat Nejde o samostatnou událost, ale o stav odvozený z údajů ve zpracovaném souboru ERA. Konkrétní kódy zamítnutí v datech o úhradě změní stav nároku. Zachycení Odvozeno z kódů zamítnutí ve zpracovaném souboru ERA, které změní stav nároku na „Zamítnut“. Typ události inferred | |||
| Odpověď plátce na nárok přijata | Systém obdrží od plátce odpověď na odeslaný nárok, často v souboru Electronic Remittance Advice (ERA). Odpověď uvádí, co bylo uhrazeno, zamítnuto nebo upraveno. | ||
| Proč je to důležité Tato událost představuje důležitý bod rozhodnutí v procesu. Určuje, zda bude následovat zaúčtování platby, nebo správa zamítnutého nároku. Analýza pomáhá porozumět chování plátců a rychlosti plateb. Kde data získat Zaznamená se, když R1 RCM zpracuje elektronický soubor s úhradou od plátce, například ANSI 835. Událost označuje časové razítko zpracování souboru. Zachycení Zaznamená se při načtení a zpracování souboru Electronic Remittance Advice (ERA/835). Typ události explicit | |||
| Účet převeden mezi nedobytné pohledávky | Všechny pokusy o vymáhání byly vyčerpány a zbývající zůstatek účtu je považován za nedobytný. Zůstatek se odepíše jako nedobytná pohledávka, což představuje konečnou ztrátu výnosů. | ||
| Proč je to důležité Jde o nepříznivý výsledek procesu a přímou ztrátu výnosů. Analýza případů, které končí jako nedobytné pohledávky, může odhalit vzorce neplacení a možnosti, jak zlepšit vymáhání. Kde data získat V R1 RCM jde obvykle o konkrétní transakci, při které se neuhrazený zůstatek převede do zvláštní kategorie nedobytných pohledávek. Převod často spustí uživatel nebo automatická pravidla pro stáří pohledávky. Zachycení Zaznamená se jako konkrétní finanční transakce, kterou se zůstatek odepíše. Často souvisí s předáním pohledávky externí inkasní agentuře. Typ události explicit | |||
| Účet upraven | Na účet se zaúčtuje transakce, která není platbou a mění jeho zůstatek. Může jít o smluvní úpravy podle dohod s plátci, odpisy malých zůstatků nebo opravy. | ||
| Proč je to důležité Vysoký počet úprav může ukazovat na problémy s ceníky, správou smluv nebo chybami ve fakturaci. Sledování úprav je důležité pro analýzu správnosti vykazovaných výnosů. Kde data získat Zaznamenává se jako konkrétní typ transakce v modulu účtování pacientů R1 RCM. Každá úprava má kód, částku a datum zaúčtování. Zachycení Zaznamená se jako samostatná transakce úpravy, kterou lze určit podle jedinečného kódu transakce. Typ události explicit | |||
| Vyúčtování pro pacienta vytvořeno | Po vyhodnocení nároku pojišťovnou se vytvoří vyúčtování, které pacientovi uvádí zbývající částku k úhradě. Může jít o spoluúčast, odpočitatelnou částku nebo nehrazené služby. | ||
| Proč je to důležité Tato aktivita zahajuje část výnosového cyklu, která se týká plateb pacientů. Její načasování a četnost je důležité sledovat při správě pohledávek za pacienty a cash flow. Kde data získat Obvykle se zaznamená událost při spuštění dávkového procesu, který vytvoří a vytiskne nebo elektronicky odešle vyúčtování pacientům. R1 RCM zaznamená datum vytvoření vyúčtování. Zachycení Zaznamená se jako transakce při spuštění dávkového procesu pro vytvoření vyúčtování pacientům. Typ události explicit | |||
| Zahájena oprava zamítnutého nároku | Uživatel nebo automatizovaný workflow zahájí prověřování a řešení zamítnutého nároku. Může jít o opravu kódování, odeslání dokumentace nebo odvolání proti rozhodnutí plátce. | ||
| Proč je to důležité Označuje začátek nákladného cyklu oprav zamítnutých nároků. Měření času stráveného v této fázi pomáhá vyhodnotit efektivitu týmu, který zamítnuté nároky řeší. Kde data získat Tato událost se často odvozuje ze změny stavu zamítnutého nároku na „Probíhá oprava“ nebo „Prověřuje se“ ve frontě úkolů R1 RCM nebo v modulu pro správu zamítnutých nároků. Zachycení Odvozeno ze změny stavu ve frontě pro správu zamítnutých nároků nebo z první akce uživatele u zamítnutého nároku. Typ události inferred | |||
| Zahájeno vymáhání pohledávky | Účet pacienta je po splatnosti a zahajuje se aktivní vymáhání pohledávky. Může jít o automatické upomínky nebo předání případu specialistovi na vymáhání. | ||
| Proč je to důležité Označuje začátek nákladného procesu vymáhání. Analýza účinnosti a délky těchto aktivit pomáhá zlepšit postupy pro získání nedobytných pohledávek. Kde data získat Tato událost se pravděpodobně zaznamená nebo odvodí ze změny stavu, když je účet v R1 RCM přesunut do fronty pro vymáhání nebo je mu přiřazen stavový kód pro vymáhání. Zachycení Odvozeno ze změny stavu účtu na „Vymáhání“ nebo „Po splatnosti“. Typ události inferred | |||
Návody na získání dat
Kroky
- Přihlaste se do platformy R1 RCM pomocí uživatelského účtu s oprávněním k modulům Business Intelligence nebo přehledů.
- Přejděte do části platformy určené pro přehledy. Může se jmenovat „Business Intelligence“, „Reporting Portal“ nebo „Analytics“.
- Najděte nástroj pro vytvoření vlastního přehledu nebo dotazu. Umožní vám určit datová pole a logiku získávání dat.
- R1 RCM neposkytuje předem připravený jednotný záznam událostí, proto jej musíte sestavit z různých zdrojů. Dodaná konfigurace dotazu pomocí UNION ALL sloučí události z různých obchodních objektů do jednoho chronologického záznamu.
- Zkopírujte celý dotaz z části „Query“ tohoto dokumentu a vložte jej do editoru dotazů nebo konfiguračního rozhraní vlastního přehledu.
- Nastavte parametry přehledu, zejména časové období. V dotazu nahraďte zástupné hodnoty
'{StartDate}'a'{EndDate}'požadovaným obdobím, například posledními 6 měsíci. - Podle potřeby přidejte další filtry, například pro konkrétní zařízení, oddělení nebo skupiny plátců, abyste zúžili rozsah dat.
- Spusťte přehled. Dotaz se provede nad databází R1 RCM a výsledky budou odpovídat zadaným parametrům.
- Po dokončení přehledu vyberte možnost exportu dat. Jako formát zvolte CSV (hodnoty oddělené čárkou), který je přímo kompatibilní s ProcessMind.
- Stáhněte vygenerovaný soubor CSV a rychle jej zkontrolujte. Ověřte, že názvy sloupců odpovídají požadovaným atributům:
BillingEvent,ActivityName,EventTime,SourceSystemaLastDataUpdate. - Před nahráním souboru do ProcessMind ověřte, že formáty data a času ve sloupcích
EventTimeaLastDataUpdatejsou jednotné.
Konfigurace
- Předpoklady: Potřebujete uživatelský účet s dostatečnými oprávněními k přístupu k vlastním přehledům a jejich vytváření v modulu Business Intelligence R1 RCM.
- Typ přehledu: Použijte vlastní dotaz nebo pokročilý nástroj pro tvorbu přehledů, který umožňuje složitější získávání dat a použití příkazů UNION ALL ke spojení různých datových sad.
- Časové období: Kvůli výkonu a objemu dat je důležité omezit analýzu na konkrétní období. Pro první analýzu doporučujeme začít s rozsahem 3 až 6 měsíců. Filtr data použijte na hlavní časové razítko každé aktivity.
- Důležité filtry: Kromě časového období zvažte filtry
Facility ID,Payer TypeneboBilling Department. Zaměříte tak analýzu na konkrétní oblasti provozu a zmenšíte exportovaný soubor. - Formát exportu: Vždy zvolte CSV. Získáte tak přehledný strukturovaný soubor, který nástroje process mining snadno zpracují.
- Plánování: Pokud to modul přehledů R1 RCM umožňuje, nastavte pravidelné spouštění přehledu, například každý týden nebo měsíc. Aktualizace dat tak budou probíhat automaticky a vy je budete moci průběžně sledovat.
Ukázkový dotaz sql
SELECT
c.ClaimID AS BillingEvent,
'Service Rendered' AS ActivityName,
c.ServiceDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ClinicianID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Rendered' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ServiceDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
c.ClaimID AS BillingEvent,
'Charges Captured' AS ActivityName,
c.ChargeEntryTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ChargeEntryUserID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Open' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ChargeEntryTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Created' AS ActivityName,
cl.CreationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.CreatedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Created' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.CreationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Submitted' AS ActivityName,
cl.SubmissionTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.SubmittedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Submitted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.SubmissionTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
era.ClaimID AS BillingEvent,
'Payer Adjudication Received' AS ActivityName,
era.ReceivedTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pa.InvoiceAmount AS InvoiceAmount,
era.PayerName AS PayerName,
'Adjudicated' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [RemittanceAdvice] era
JOIN [PatientAccounts] pa ON era.ClaimID = pa.BillingEvent
WHERE era.ReceivedTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
d.ClaimID AS BillingEvent,
'Claim Denied' AS ActivityName,
d.DenialTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Denied' AS InvoiceStatus,
d.ReasonCode AS DenialReasonCode
FROM [DenialsLog] d
JOIN [ClaimsData] cl ON d.ClaimID = cl.ClaimID
WHERE d.DenialTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
dr.ClaimID AS BillingEvent,
'Denial Rework Started' AS ActivityName,
dr.ReworkStartTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
dr.AssignedUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'In Rework' AS InvoiceStatus,
dr.OriginalDenialCode AS DenialReasonCode
FROM [DenialRework] dr
JOIN [ClaimsData] cl ON dr.ClaimID = cl.ClaimID
WHERE dr.ReworkStartTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ps.PatientAccountID AS BillingEvent,
'Patient Statement Generated' AS ActivityName,
ps.GenerationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ps.GeneratedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
ps.StatementBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Patient Billed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientStatements] ps
JOIN [PatientAccounts] pa ON ps.PatientAccountID = pa.BillingEvent
WHERE ps.GenerationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
p.AssociatedClaimID AS BillingEvent,
'Payment Received' AS ActivityName,
p.ReceiptTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
p.ProcessedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
p.PaymentAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Payment Pending' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentsLog] p
JOIN [PatientAccounts] pa ON p.AssociatedClaimID = pa.BillingEvent
WHERE p.ReceiptTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pt.ClaimID AS BillingEvent,
'Payment Posted' AS ActivityName,
pt.PostingTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pt.PostedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pt.PostedAmount AS InvoiceAmount,
pt.PayerName AS PayerName,
'Partially Paid' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentTransactions] pt
JOIN [PatientAccounts] pa ON pt.ClaimID = pa.BillingEvent
WHERE pt.PostingTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
a.ClaimID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
a.AdjustmentTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
a.AdjusterID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
a.AdjustmentAmount AS InvoiceAmount,
pa.PayerName AS PayerName,
'Adjusted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [Adjustments] a
JOIN [PatientAccounts] pa ON a.ClaimID = pa.BillingEvent
WHERE a.AdjustmentTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ca.PatientAccountID AS BillingEvent,
'Collection Activity Started' AS ActivityName,
ca.ActivityTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ca.AssignedAgentID AS AssignedUser,
'Collections' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'In Collections' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [CollectionsActivity] ca
JOIN [PatientAccounts] pa ON ca.PatientAccountID = pa.BillingEvent
WHERE ca.ActivityTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Placed in Bad Debt' AS ActivityName,
pa.BadDebtPlacementDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pa.BadDebtUserID AS AssignedUser,
'Finance' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Bad Debt' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.BadDebtPlacementDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Closed' AS ActivityName,
pa.ClosureDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
0 AS InvoiceAmount,
pa.PayerName AS PayerName,
'Closed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.ClosureDate BETWEEN '{StartDate}' AND '{EndDate}' AND pa.CurrentBalance = 0; Chcete začít?
Použijte tuto šablonu, zjednodušte sběr dat a pusťte se do optimalizace řízení cyklu tržeb. Provedeme vás jednotlivými kroky.
Optimalizujte R1 RCM a zvyšte efektivitu cyklu tržeb
Odstraňte úzká místa v RCM, zkraťte dobu cyklu o 30 % a zlepšete cash flow.
Kreditní kartu nepotřebujete. Začít můžete během několika minut.