Revenue Cycle Management-adatsablon
Revenue Cycle Management-adatsablon
- Javasolt attribútumok
- Követendő fő tevékenységek
- Adatkinyerési útmutató az Oracle Health Revenue Cycle rendszerhez
A Revenue Cycle Management attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Esemény időbélyege EventTimestamp | Az a pontos dátum és időpont, amikor a tevékenységet rögzítették a rendszerben. | ||
| Leírás Ez az attribútum minden tevékenységhez időbélyeget rendel, amely megmutatja a bekövetkezés pontos időpontját. Segítségével megérthető az események időzítése és sorrendje egy adott számlázási esemény bevételi ciklusában. Az elemzés során az esemény időbélyege alapján időrendbe állíthatók a tevékenységek, kiszámítható az egyes lépések közötti időtartam és átfutási idő, valamint elemezhetők a szűk keresztmetszetek. Ez az alapja minden időalapú process mining mérőszámnak, például az „Igény benyújtva” és az „Elszámolási értesítés beérkezett” közötti késedelem azonosításának. Miért fontos? Ez az időbélyeg elengedhetetlen az események sorrendbe állításához, a teljesítménymutatók, például az átfutási idők és időtartamok kiszámításához, valamint a folyamat szűk keresztmetszeteinek azonosításához. Hol szerezhető be? Az Oracle Health Revenue Cycle minden tranzakciós vagy eseménynapló-táblájában kell lennie egy időbélyegoszlopnak, amely jelzi a rekord létrehozásának vagy az esemény bekövetkezésének időpontját. Példák 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| Számlázási esemény BillingEvent | Egyetlen szolgáltatás vagy termék teljesítésének egyedi azonosítója, amely díjtételt hoz létre. Ez azonosítja az esetet a bevételi ciklus folyamatában. | ||
| Leírás A számlázási esemény az elsődleges esetazonosító. Egyedi számlázható tétel esetén összekapcsolja az összes tevékenységet a díjtételek rögzítésétől a számla lezárásáig. Minden számlázási esemény a bevételi ciklus folyamatának egyedi példánya, így nyomon követhető az útja a különböző szakaszokon, például az igény benyújtásán, a befizetés könyvelésén, valamint az esetleges elutasításokon vagy korrekciókon keresztül. A process mining elemzésben ez az attribútum alapvető a folyamat teljes menetének rekonstruálásához. Segítségével megjeleníthetők a folyamatváltozatok, kiszámíthatók a tevékenységek közötti ciklusidők, és azonosíthatók az egyes számlázható eseményekhez kapcsolódó szűk keresztmetszetek és eltérések. Miért fontos? Ez az alapvető azonosító a számlázható szolgáltatás teljes életútjának követéséhez, valamint a folyamatútvonalak elemzéséhez és a teljesítmény méréséhez. Hol szerezhető be? Ennek az azonosítónak egyedi kulcsnak kell lennie az Oracle Health Revenue Cycle központi számlázási vagy díjtétel-tranzakciós tábláiban. A díjtétel-események elsődleges kulcsának meghatározásához tekintse meg a rendszer dokumentációját. Példák BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| Tevékenység neve ActivityName | A bevételi ciklus folyamatában végrehajtott konkrét lépés vagy bekövetkezett esemény neve. | ||
| Leírás Ez az attribútum rögzíti a számlázási esemény életciklusa során végrehajtott egyes tevékenységek nevét. Ilyen például a „Díjtételek rögzítve”, az „Igény benyújtva a fizető félnek” és a „Kifizetés rögzítve”. Ezek a tevékenységek alkotják a feltárt folyamattérkép csomópontjait. A tevékenységek sorrendjének és gyakoriságának elemzése a process mining alapja. Ez az attribútum segít azonosítani a leggyakoribb folyamatútvonalakat, feltárni a standard eljárástól való eltéréseket, és megérteni a bevételi ciklus működését. Miért fontos? Meghatározza a folyamat lépéseit, így megjeleníthető a folyamattérkép és elemezhetők a munkafolyamat mintázatai. Hol szerezhető be? Jellemzően az eseménynaplókból, az állapotváltozások rekordjaiból vagy az Oracle Health bevételi ciklusának egyes szakaszaihoz kapcsolódó tranzakciós táblákból származik. Példák Igény létrehozvaElszámolási értesítés beérkezettElutasítás megfellebbezveSzámla lezárva | |||
| Betegosztály PatientClass | A betegtalálkozó besorolása, például fekvőbeteg- vagy járóbeteg-ellátás. | ||
| Leírás Ez az attribútum a díjtételt eredményező betegvizit vagy betegtalálkozó típusát sorolja kategóriába. Gyakori besorolás a fekvőbeteg-ellátás, a járóbeteg-ellátás, a sürgősségi ellátás és a visszatérő beteg. A betegosztály gyakran meghatározza a teljes számlázási és igénybenyújtási folyamatot. Az egyes betegosztályok eltérő folyamatútvonalakat követnek, és más-más megfelelési követelmények vonatkoznak rájuk. Az attribútum szerinti elemzés segít megérteni ezeket az eltéréseket, célzott fejlesztéseket tervezni, és biztosítani, hogy minden osztály esetében a megfelelő eljárásokat kövessék. Miért fontos? Elkülöníti az eltérő folyamatútvonalakat, például a fekvőbeteg- és járóbeteg-ellátást, amelyek összetettsége, időigénye és számlázási követelményei különböznek. Hol szerezhető be? Ez az Oracle Health betegtalálkozóhoz vagy felvételi rekordhoz kapcsolódó standard mezője. Példák FekvőbetegJáróbetegSürgősségiIsmétlődő | |||
| Elutasítási ok kódja DenialReasonCode | A biztosító által elutasított igény okát jelölő szabványos kód. | ||
| Leírás Ha a biztosító elutasít egy igényt, megadja az elutasítás okát jelölő kódot, például „Nem fedezett szolgáltatás” vagy „Duplikált igény”. Ez az attribútum rögzíti a kódot és a hozzá tartozó leírást. Az elutasítási okok elemzése alapvető a bevételi ciklus fejlesztéséhez. Segítségével a szervezet felismerheti a gyakori problémákat, például a kódolási hibákat vagy a beteg jogosultságával kapcsolatos gondokat, és intézkedhet a további elutasítások megelőzésére. Ez közvetlenül javítja a hibátlan igények arányát, és csökkenti az ismételt munkavégzés költségét. Miért fontos? Feltárja az igények elutasításának kiváltó okait, így célzott fejlesztésekkel növelhető a hibátlan igények aránya és gyorsítható a bevételek beszedése. Hol szerezhető be? Ezt az információt a biztosító elektronikus elszámolási értesítője (ANSI 835 fájl) tartalmazza. Az Oracle Health igény- vagy elszámolási tábláiban kell tárolni. Példák CO-16: Az igényből vagy szolgáltatásból hiányzik az elbíráláshoz szükséges információ.PR-96: Nem fedezett díj(ak).CO-18: Duplikált igény vagy szolgáltatás. | |||
| Felhasználó UserPerformingAction | A tevékenységet végrehajtó személy felhasználói azonosítója vagy neve. | ||
| Leírás Ez az attribútum azonosítja azt a munkatársat vagy automatizált rendszerfelhasználót, aki egy adott tevékenységért felelős. Segít megérteni a munkaterhelés eloszlását és az erőforrások teljesítményét, valamint feltárni a képzési igényeket. Az elemzés során felhasználó vagy csapat szerint szűrhető vele a folyamattérkép, összehasonlítható a különböző erőforrások teljesítménye, és elemezhető a „Billing Department Workload” dashboard munkaterhelése. Segíthet azonosítani a kiemelkedően teljesítő munkatársakat, illetve azokat, akiknek további támogatásra vagy képzésre lehet szükségük. Miért fontos? A folyamati tevékenységeket konkrét felhasználókhoz vagy csapatokhoz kapcsolja, így elemezhető a munkaterhelés, összehasonlítható a teljesítmény, és feltárhatók a képzési lehetőségek. Hol szerezhető be? A tranzakciós táblákban az Oracle Health moduljain keresztül jellemzően megtalálhatók a felhasználói azonosító mezők, például a „CREATED_BY” és a „USER_ID”. Példák j.doeasmithBillingBot_AUTOk.williams | |||
| Fennálló egyenleg OutstandingBalance | A számlázási esemény adott időpontban még ki nem fizetett egyenlege. | ||
| Leírás Ez az attribútum azt mutatja, hogy a befizetések és korrekciók elszámolása után mennyi a számlázási esemény fennálló tartozása. Az adott díjhoz kapcsolódó aktuális követelést jelzi. Ez az attribútum alapvető az „Outstanding Balance Aging” dashboardhoz. Az érték időbeli elemzése segít nyomon követni a pénzáramlás sebességét, felmérni a behajtási tevékenység eredményességét, valamint kiszámítani olyan fontos pénzügyi KPI-kat, mint a kintlévőségek átlagos behajtási ideje (DSO). Miért fontos? Esetenként nyomon követi az aktuális követelést, ami elengedhetetlen a pénzáramlás kezeléséhez és a behajtás eredményességének elemzéséhez. Hol szerezhető be? Ezt az értéket általában az adott számlázási eseményhez tartozó összes pénzügyi tranzakció, vagyis a díjak, befizetések és korrekciók összege alapján számítják ki. Előfordulhat, hogy egy számlaösszesítő táblában külön mezőként is szerepel. Példák 75.000.00550.80 | |||
| Fizető fél neve PayerName | A fizetésért felelős biztosító vagy harmadik fél neve. | ||
| Leírás Ez az attribútum azonosítja azt a szervezetet, például biztosítót vagy állami programot, mint a Medicare, amelynek a szolgáltatást kiszámlázzák. A fizető fél adatai alapvetőek a bevételi ciklus elemzéséhez. A folyamat fizető fél szerinti elemzésével jelentős eltérések tárhatók fel a kifizetési időkben, az elutasítási arányokban és a fellebbezések sikerességében. Segít azonosítani a késedelmet vagy bevételkiesést okozó problémás fizető feleket, és elengedhetetlen a velük kötött szerződések és kapcsolatok hatékony kezeléséhez. Miért fontos? Lehetővé teszi a folyamat fizető fél szerinti bontását, és megmutatja az eltérő működést, elutasítási arányokat és kifizetési sebességet, amelyek fontosak a pénzügyi teljesítmény szempontjából. Hol szerezhető be? Ez az információ az Oracle Health Revenue Cycle betegszámlázási vagy biztosítási nyilvántartásaiban található. Példák AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| Korrekció összege AdjustmentAmount | A számlaegyenlegen végrehajtott korrekciók pénzértéke. | ||
| Leírás Ez az attribútum rögzíti a számlázási eseményhez kapcsolódó pénzügyi korrekciók összegét, például a szerződéses engedményeket, leírásokat vagy helyesbítéseket. A korrekciók közvetlenül csökkentik a díjból várható bevételt. Az „Account Adjustment Impact” dashboard nagymértékben támaszkodik erre az attribútumra. A korrekciók összegének és indokainak elemzése segít feltárni a bevételkiesés forrásait, a szerződéskezelési hiányosságokat és az eredeti díjrögzítés problémáit. A pénzügyi helyzet egyik fontos mérőszáma. Miért fontos? Számszerűsíti a leírásokból vagy helyesbítésekből eredő bevételkiesést, így segít feltárni és kezelni a pénzügyi veszteség kiváltó okait. Hol szerezhető be? A beteg számláján végrehajtott korrekciókat vagy leírásokat rögzítő pénzügyi tranzakciós táblákban található. Példák -50.25-120.0025.00 | |||
| Számlázási részleg BillingDepartment | A tevékenységért felelős részleg vagy funkcionális csapat. | ||
| Leírás Ez az attribútum megadja, melyik részleg, például a „Díjtétel-rögzítés”, a „Kódolás” vagy a „Behajtás” végezte a tevékenységet. Szervezeti szempontból helyezi kontextusba a folyamatot. A folyamat részlegek szerinti elemzése segít megérteni a csapatok közötti átadásokat, és feltárni a részlegeken átívelő hatékonysági problémákat. A „Billing Department Workload” dashboardon részlegenként összesíthetők vele a tevékenységek és a teljesítménymutatók. Miért fontos? A tevékenységeket szervezeti egységekhez rendeli, így elemezhető a részlegek közötti átadás, a munkaterhelés és a csapatok teljesítménye. Hol szerezhető be? Ez az információ közvetlenül az Oracle Health felhasználói profiladataiban tárolható, vagy a felhasználó, illetve a tevékenység típusa alapján is meghatározható. Példák BetegfelvételKódolásSzámlázásBehajtás | |||
| Automatizált IsAutomated | Jelzi, hogy a tevékenységet automatizált rendszer vagy emberi felhasználó végezte-e. | ||
| Leírás Ez a logikai attribútum megkülönbözteti a szoftveres automatizálással, például botokkal vagy rendszeres kötegelt feladatokkal végrehajtott tevékenységeket a felhasználók által kézzel végzettektől. Például az „Igény létrehozása” automatizált lépés lehet, míg az „Elutasítás megfellebbezése” valószínűleg manuális. Az attribútum elemzésével felmérhető a folyamat automatizáltsága, valamint annak hatása a hatékonyságra és a hibaarányra. Összehasonlítható az automatizált és a manuális folyamatút teljesítménye, és azonosíthatók a további automatizálási lehetőségek. Miért fontos? Megkülönbözteti az emberi és a rendszer által végzett tevékenységeket. Ez elengedhetetlen az automatizálás eredményességének elemzéséhez és az új automatizálási lehetőségek feltárásához. Hol szerezhető be? Ezt általában a UserPerformingAction attribútum alapján határozzák meg. Például a „SYSTEM” vagy „RPA_BOT” felhasználói azonosítóval végzett tevékenységeket automatizáltnak jelölik. Példák truefalse | |||
| Betegazonosító PatientId | A számlázási eseményhez kapcsolódó beteg egyedi azonosítója. | ||
| Leírás Ez az attribútum a szolgáltatást igénybe vevő beteg egyedi azonosítója, amelyet gyakran egészségügyi dokumentációs számnak (MRN) neveznek. A pénzügyi tranzakciót egy konkrét személyhez kapcsolja. Bár nem ez a folyamat esetazonosítója, a betegazonosítóval egy beteg összes számlázási eseménye összevonható, így áttekinthető a teljes pénzügyi előzménye. A beteg törzsadataival összekapcsolva demográfiai adatok vagy kórelőzmény alapján is lehetővé teszi a szegmentálást. Miért fontos? A pénzügyi eseményeket egy adott beteghez kapcsolja, így betegközpontú elemzés és az összes számlázási tevékenység összevonása válik lehetővé. Hol szerezhető be? Ez az azonosító a beteg törzsrekordjának alapvető eleme, és minden kapcsolódó tranzakciós táblában, például a díjak, igények és befizetések tábláiban is szerepel. Példák MRN-1002345MRN-1002346MRN-1002347 | |||
| Díj összege ChargeAmount | A számlázott szolgáltatás vagy termék bruttó pénzértéke. | ||
| Leírás Ez az attribútum a szolgáltatás eredeti, kedvezmények levonása előtti díját mutatja, még az elszámolások, szerződéses engedmények vagy befizetések alkalmazása előtt. Ez a számlázási esemény kiinduló pénzügyi értéke. A díj összegének nyomon követése fontos a pénzügyi elemzéshez. Segítségével kiszámítható például a nyújtott szolgáltatások teljes értéke, és felmérhető a későbbi korrekciók vagy leírások pénzügyi hatása. Alapul szolgál a bevétel realizálásának méréséhez. Miért fontos? Meghatározza az eset kiinduló pénzügyi értékét, amely minden további pénzügyi elemzés és hatásvizsgálat alapja. Hol szerezhető be? Az Oracle Health díjrészleteket vagy díjtranzakciókat tartalmazó tábláiban található. Példák 150.001250.7585.50 | |||
| Esemény befejezési ideje EventEndTime | A tevékenység befejezésének időbélyege, ha rendelkezésre áll. | ||
| Leírás A StartTime a tevékenység kezdetét, az EventEndTime pedig a befejezését jelöli. Nem minden tevékenységnek van külön befejezési időpontja, mivel sok esemény azonnal lezajlik. Az időtartammal rendelkező tevékenységeknél, például egy időigényes „Elutasítás megfellebbezve” eseménynél azonban ez a mező nagyon hasznos. Ez az attribútum pontosabbá teszi az egyes tevékenységek feldolgozási idejének kiszámítását. Segít megkülönböztetni a várakozási időt, vagyis a tevékenységek közötti időt, a feldolgozási időtől, vagyis a tevékenységgel töltött időtől. Miért fontos? Közvetlenül kiszámítható vele, mennyi ideig tart egy tevékenység befejezése, és elkülöníthető a feldolgozási idő a várakozási időtől. Hol szerezhető be? Az Oracle Health Revenue Cycle egyes tranzakciós táblái tartalmazhatnak kezdési és befejezési időbélyeget is bizonyos, hosszabb ideig futó feladatokhoz. Példák 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| Forrásrendszer SourceSystem | Az a rendszer, amelyből az eseményadatokat kinyerték. | ||
| Leírás Ez az attribútum azonosítja a forrásalkalmazást vagy -modult, ahonnan az adatok származnak. Ennél a folyamatnál ez jellemzően az „Oracle Health Revenue Cycle”, de több forrásból származó adatok esetén a rendszer különböző moduljait is megjelölheti. Ez az információ hasznos az adatirányítás és a hibaelhárítás szempontjából. Segít ellenőrizni az adatok eredetét, és fontos olyan környezetben, ahol több rendszer adatai alkotnak egyetlen, végpontok közötti folyamatot. Miért fontos? Megmutatja az adatok eredetét, ami fontos az adatok ellenőrzéséhez és irányításához, valamint a rendszertől függő folyamatváltozatok megértéséhez. Hol szerezhető be? Ez gyakran az adatkinyerés, -átalakítás és -betöltés (ETL) során hozzáadott statikus érték, amely az adatkészlet forrását jelöli. Példák OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| Igényazonosító ClaimId | A biztosítónak benyújtott biztosítási igény egyedi azonosítója. | ||
| Leírás Ez az attribútum az igény egyedi azonosítója, amelyet a visszatérítés érdekében hoznak létre és küldenek el a biztosítónak. Egy számlázási esemény során annak teljes életciklusa alatt egy vagy több igény is keletkezhet, például ha helyesbítésre van szükség. Az igényazonosítóval nyomon követhető a biztosítónak küldött konkrét beadvány, és közvetlenül összekapcsolható a válasszal, például a kifizetéssel vagy az elutasítással. A teljes bevételi ciklusnál részletesebb nyomon követést tesz lehetővé. Miért fontos? Egyedi azonosítót ad az igény biztosítónál megtett útjának követéséhez, így a teljes számlázási eseménynél részletesebb elemzést tesz lehetővé. Hol szerezhető be? Ezt az azonosítót az Oracle Health hozza létre az igény rögzítésekor, és az elsődleges igénytáblában tárolja. Példák CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| Ismételt munka IsRework | Jelzi, hogy egy tevékenység ismételt munkát vagy erőfeszítést jelent-e. | ||
| Leírás Ez a számított attribútum megjelöli azokat a tevékenységeket, amelyek eltérnek az ideális folyamattól, és ismételt munkát jelentenek. Ilyen például a „Helyesbített igény benyújtása” vagy az „Elutasítás megfellebbezése”, amelyekre nem lenne szükség, ha a folyamat elsőre hibátlanul zajlana le. Az ismételt munka azonosítása és számszerűsítése a process mining egyik fő célja. Ezzel a jelölővel egyszerűen szűrhetők és elemezhetők az ismétlődő folyamatkörök, így mérhető a gyakoriságuk, költségük és a kiváltó okuk. Segít megérteni a minőségi problémák tényleges költségét a bevételi ciklusban. Miért fontos? Segít számszerűsíteni az ismétlődő folyamatkörök gyakoriságát és hatását, rávilágítva a folyamat hiányosságaira és a gyenge minőség költségére. Hol szerezhető be? Ez egy származtatott attribútum. Az adatátalakítás során, üzleti szabályok alapján számítják ki, amelyek meghatározott tevékenységneveket ismételt munkaként jelölnek meg. Példák truefalse | |||
| Utolsó adatfrissítés LastDataUpdate | Az az időbélyeg, amely megmutatja, mikor frissítették vagy nyerték ki utoljára az esemény adatait. | ||
| Leírás Ez az attribútum megmutatja, mikor frissítették utoljára az adatkészletet. Jelzi az elemzett adatok aktualitását, ami segít megítélni, mennyire időszerűek a process mining elemzésből származó megállapítások. Ezzel az attribútummal ellenőrizhető, hogy a legfrissebb folyamatadatokat látja-e. Segít tisztázni, mennyire naprakészek az adatok, és az adatirányítás, valamint a minőségbiztosítás fontos része. Miért fontos? Jelzi, mennyire frissek az adatok, így az elemzés és a döntések naprakész információkra támaszkodhatnak. Hol szerezhető be? Ez egy metaadatmező, amelyet jellemzően a process mining platformra adatokat betöltő ETL-folyamat hoz létre és tölt ki. Példák 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Vitatás oka DisputeReason | Az ügyfél vagy a beteg által a számla vagy a díj vitatására megadott indok. | ||
| Leírás Ez az attribútum rögzíti, hogy a beteg vagy más felelős fél miért vitatja a számlát. Az ok lehet például hibás díj, el nem végzett szolgáltatás vagy a biztosítói ügyintézés problémája. Ez az információ elengedhetetlen az „Invoice Dispute Resolution Metrics” dashboardhoz. A leggyakoribb vitatási okok megismerése segít feltárni a díjrögzítés, a kódolás vagy a számlázás rendszerszintű problémáit. Ezek kezelése jelentősen csökkentheti a vitatások arányát és a rendezésükhöz szükséges adminisztrációs terheket. Miért fontos? Megmutatja, miért vitatják a számlákat, és rávilágít a számlázás pontosságával vagy érthetőségével kapcsolatos javítandó problémákra. Hol szerezhető be? Valószínűleg az Oracle Health ügykezelési vagy ügyfélszolgálati moduljában tárolják, a beteg számlájához kapcsolva. Példák Hibásan számlázott szolgáltatásDuplikált díjHibásan számlázott biztosításEl nem végzett szolgáltatás | |||
A Revenue Cycle Management tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Betegtalálkozó létrehozva | A betegszámla létrehozását jelzi egy adott vizithez vagy szolgáltatáshoz. Ez jellemzően a regisztrációs rendszer vagy az Admit/Discharge/Transfer (ADT) adatfolyam által kiváltott, kifejezetten rögzített esemény. | ||
| Miért fontos? Ez az adott számlázási eseményhez tartozó teljes bevételi ciklus kiindulópontja. Segítségével elemezhető a folyamat teljes időtartama és a regisztráció pontossága. Hol szerezhető be? A Patient Registration vagy az ADT modul naplóiból származik. Keresse a betegtalálkozó létrehozására vonatkozó eseményeket, illetve a betegtalálkozóhoz vagy pénzügyi azonosítóhoz tartozó legkorábbi időbélyeget. Rögzítés A beteg regisztrációjakor vagy felvételekor rögzített esemény. Eseménytípus explicit | |||
| Igény benyújtva a fizető félnek | A létrehozott igény elektronikus vagy papíralapú benyújtását jelzi a biztosítónak vagy más fizető félnek. A rendszernek rögzítenie kell a továbbítás dátumát és időpontját. | ||
| Miért fontos? Ezzel indul a kifizetési ciklus mérése. A benyújtás és a kifizetés közötti idő elemzése segít megérteni a fizető felek teljesítményét és a vevőkövetelés-állományi napok számát (DSO). Hol szerezhető be? Az igénykezelő modulból származik, amely rögzíti a továbbítási eseményeket. Keresse a benyújtás időbélyegét vagy az igényelőzmények „Submitted” állapotváltozását. Rögzítés A fizető félnek történő, elszámolóházon keresztüli sikeres továbbításkor rögzített esemény. Eseménytípus explicit | |||
| Igény létrehozva | Azt jelzi, amikor az egyes díjtételekből hivatalos számlázási igény, például UB-04 vagy CMS-1500 készül. Ez a rendszer által létrehozott esemény hozza létre az első számlát. | ||
| Miért fontos? Ez fontos mérföldkő, amely azt jelzi, hogy az igény benyújtható a fizető félnek. Ezzel zárul a belső, díjtétel-rögzítéstől a számlázásig tartó idő mérése. Hol szerezhető be? Az igénylétrehozási naplókban vagy táblákban rögzített, kifejezett esemény. Keresse a betegtalálkozóhoz tartozó elsődleges igényrekord létrehozásának időbélyegét. Rögzítés Az igényrekord létrehozásakor rögzített esemény. Eseménytípus explicit | |||
| Kifizetés rögzítve | A fizető féltől beérkezett összegnek a betegszámla megfelelő díjtételeihez rendelését jelzi. Ez olyan pénzügyi tranzakció, amelyet egy felhasználó vagy egy automatizált folyamat rögzít. | ||
| Miért fontos? A kifizetések rögzítésének hatékonysága befolyásolja a vevőkövetelések pontosságát. Az itt jelentkező késedelmek torzíthatják a pénzügyi képet, és késleltethetik a másodlagos számlázást. Hol szerezhető be? A kifizetési tranzakciós táblákban található. Minden rögzített kifizetés egyedi tranzakcióazonosítóval és időbélyeggel rendelkezik. Rögzítés A kifizetés számlához rendelésekor pénzügyi tranzakció kerül rögzítésre. Eseménytípus explicit | |||
| Számla lezárva | Az utolsó tevékenység, amely azt jelzi, hogy a számlaegyenleg nulla, és további tevékenység nem várható. Ezt gyakran abból lehet megállapítani, hogy a számlaegyenleg nullára csökken. | ||
| Miért fontos? A bevételi ciklus sikeres lezárását jelzi. A folyamat általános hatékonyságának fontos mérőszáma, hogy mennyi idő alatt jut el idáig. Hol szerezhető be? Ezt jellemzően úgy állapítják meg, hogy megkeresik azt az első időpontot, amikor a számla fennálló egyenlege nullára csökken, és az összes kifizetés és korrekció után is nulla marad. Rögzítés Akkor számítják ki, amikor az összes díjtétel és kifizetés rögzítése után a számlaegyenleg először lesz nulla. Eseménytípus calculated | |||
| Behajtás megkezdve | Azt jelzi, hogy a nemfizetés miatt a beteg számlája behajtási folyamatba került. Ezt jellemzően a számla pénzügyi besorolásának vagy állapotának változása mutatja. | ||
| Miért fontos? Ez fontos lépés a behajthatatlan követelések kezelésében. A pénzügyi helyzet megőrzéséhez elengedhetetlen annak elemzése, hogy mi vezet ehhez a szakaszhoz, és milyen eredményes a behajtás. Hol szerezhető be? A számla állapotmezőjének „Collections” vagy „Bad Debt” értékre változásából következtethető ki. Az állapotváltozáshoz időbélyegnek kell tartoznia. Rögzítés A számla „Collections” vagy hasonló állapotra váltásából következtethető ki. Eseménytípus inferred | |||
| Betegszámla kiküldve | Azt jelzi, amikor a beteg fennmaradó fizetési kötelezettségéről számla készül, és azt elküldik a betegnek. Ezt a betegszámlázási modul kifejezett műveletként rögzíti. | ||
| Miért fontos? Ezzel indul a bevételi ciklus beteg általi fizetési szakasza. Követése segít elemezni a betegektől történő követelésbehajtás hatékonyságát. Hol szerezhető be? A betegszámlázási vagy levelezési naplókból származik. A rendszernek rögzítenie kell az egyes számlák létrehozásának vagy elküldésének dátumát. Rögzítés A betegszámla létrehozásakor, nyomtatásakor vagy elektronikus elküldésekor rögzített esemény. Eseménytípus explicit | |||
| Díjtételek kódolva | Azt a folyamatot jelzi, amelyben az egészségügyi kódolók szabványos kódokat, például CPT- vagy ICD-10-kódokat rendelnek a rögzített díjtételekhez. Ezt gyakran a díjtétel vagy a betegtalálkozó állapotváltozása jelzi. | ||
| Miért fontos? A kódolás késedelme gyakori szűk keresztmetszet. Ennek a tevékenységnek a követése segít feltárni a kódolási munkafolyamat hatékonysági problémáit és azok számlázási határidekre gyakorolt hatását. Hol szerezhető be? Gyakran a betegtalálkozó vagy a díjtétel-köteg állapotváltozásából következtethető ki, például az „Uncoded” állapot „Coded” állapotra váltásából. Ehhez szükség van az állapotváltozás időbélyegére. Rögzítés A betegtalálkozó vagy a díjtétel állapotának „Coded” vagy „Ready for Billing” értékre változásából következtethető ki. Eseménytípus inferred | |||
| Díjtételek rögzítve | A számlázható szolgáltatások vagy tételek betegszámlára történő felvitelét jelzi. Ez történhet automatikusan a klinikai rendszerekből, vagy a munkatársak kézi adatbevitelével. | ||
| Miért fontos? Ez a tevékenység alapvető a „charge lag”, vagyis a szolgáltatásnyújtás és a számlázás megkezdése közötti idő méréséhez. Ez közvetlenül befolyásolja a pénzforgalmat és a bevételek pontosságát. Hol szerezhető be? A díjtétel-tranzakciós táblákból nyerhető ki, az egyes díjtételsorok létrehozásának időbélyege alapján. Az Oracle Health rendszerben ez gyakran a díjtételekhez kapcsolódó táblákban található. Rögzítés Minden új díjtételhez tranzakciónapló-bejegyzés készül. Eseménytípus explicit | |||
| Elszámolási értesítés beérkezett | A fizető féltől érkező elektronikus elszámolási értesítés (ERA) vagy papíralapú ellátási magyarázat (EOB) beérkezését jelzi. A dokumentum részletezi, hogy mely díjtételeket fizették ki, utasították el vagy módosították. | ||
| Miért fontos? Ez a fizető fél első válasza, ezért fontos a kifizetések gyorsaságának megértéséhez és az elutasítási trendek korai felismeréséhez. Hol szerezhető be? Az elszámolási értesítéseket feldolgozó modulban található. Keresse az igényhez kapcsolódó ERA-fájl, például egy 835-ös tranzakciós fájl importálásának vagy létrehozásának időbélyegét. Rögzítés A fizető fél elszámolási fájljának, például az ANSI 835-nek az importálásakor és feldolgozásakor rögzített esemény. Eseménytípus explicit | |||
| Elutasítás megfellebbezve | Azt jelzi, hogy egy felhasználó vagy rendszer megfellebbezi az elutasított igényt. Ezt jellemzően állapotfrissítésként vagy a munkasorban létrehozott konkrét feladatként rögzítik. | ||
| Miért fontos? Ez a tevékenység újrafeldolgozási ciklust indít. A fellebbezések gyakoriságának és sikerességi arányának elemzése fontos a bevételek visszaszerzésére irányuló munka javításához. Hol szerezhető be? Ez lehet kifejezetten a felhasználó által kezdeményezett esemény, vagy az igény állapotváltozásából következtethető ki, például az „Appealed” vagy „In Review” állapotból. Rögzítés Állapotváltozás vagy naplózott esemény, amikor a felhasználó fellebbezést indít egy elutasított igény ügyében. Eseménytípus explicit | |||
| Igény elutasítva | Azt az eseményt jelzi, amikor a fizető fél elutasít egy igényt vagy annak egyes tételeit, amint azt az elszámolási értesítés mutatja. Az esemény gyakran az elszámolási adatokban szereplő elutasítási kódokból következtethető ki. | ||
| Miért fontos? Az elutasítások követése segít feltárni a kiváltó okokat, például a kódolási hibákat vagy a jogosultsági problémákat, és javítani a hibamentes igények arányát. Hol szerezhető be? Az elszámolási értesítés (ERA/835) adataiból következtethető ki. Az esemény akkor jön létre, ha egy igényhez vagy tételhez nem nulla elutasított összeg és a hozzá tartozó elutasítási indok kódja tartozik. Rögzítés Az elutasítás indokát tartalmazó elszámolási adatokból következtethető ki (CARC/RARC-kódok). Eseménytípus inferred | |||
| Javított igény benyújtva | A módosított vagy javított igény fizető félnek történő benyújtását jelzi, gyakran egy elutasítást vagy további információkérését követően. Ezt egy új igénybenyújtás jelzi, amely javítási jelölőt tartalmaz. | ||
| Miért fontos? Ez a tevékenység az elutasításkezelés újrafeldolgozási ciklusának fontos része. A gyakori előfordulás az eredeti igény pontosságával kapcsolatos problémákra utal. Hol szerezhető be? Az igénybenyújtási naplókból nyerhető ki. Keresse a meglévő betegtalálkozóhoz tartozó új benyújtást, amelyet gyakran újraküldési kód vagy magasabb sorszám jelöl. Rögzítés Az igény újbóli benyújtásakor rögzített esemény, amely gyakran egyedi igénygyakorisági kóddal azonosítható. Eseménytípus explicit | |||
| Számlaegyenleg módosítva | A számlaegyenlegen végrehajtott pénzügyi korrekciót jelzi, például szerződéses engedményt, leírást vagy kedvezményt. Minden korrekció külön pénzügyi tranzakció. | ||
| Miért fontos? A korrekciók közvetlenül befolyásolják a bevételt. Gyakoriságuk, típusuk és összegük elemzésével feltárhatók a bevételkiesések és a számlázási pontatlanságok. Hol szerezhető be? A pénzügyi tranzakciós táblákban található. Minden korrekció külön tételsorként, egyedi tranzakciókóddal és időbélyeggel szerepel. Rögzítés A pénzügyi tranzakciót egyedi korrekciós kóddal rögzítik. Eseménytípus explicit | |||
Adatkinyerési útmutatók
Lépések
- Adatbázis-hozzáférés igénylése: Kérjen csak olvasási jogosultságú hitelesítő adatokat az Oracle Health Revenue Cycle adatbázishoz. Hozzá kell férnie a beteg-, betegtalálkozó-, számlázási és pénzügyi tranzakciós adatokat tartalmazó sémákhoz. Ehhez általában az informatikai biztonsági és adatbázis-adminisztrációs csapat jóváhagyása szükséges.
- Sémák és táblák nevének azonosítása: Adatbázis-adminisztrátorral vagy rendszerelemzővel egyeztesse az Oracle Health-példány pontos séma- és táblaneveit. A lekérdezésben szereplő nevek általános helyőrzők, amelyeket az Ön környezetének megfelelő nevekre kell cserélni.
- SQL-kliens telepítése: Telepítsen a munkaállomására egy kompatibilis SQL-klienst, például az Oracle SQL Developert vagy a DBeavert. Ezzel csatlakozik az adatbázishoz, és futtatja az adatkinyerő szkriptet.
- Adatbázis-kapcsolat beállítása: Hozzon létre új adatbázis-kapcsolatot az SQL-kliensben a megadott gazdagép, port, szolgáltatásnév és hitelesítő adatok használatával. Tesztelje a kapcsolatot.
- SQL-lekérdezés testreszabása: Másolja a megadott SQL-szkriptet egy új lekérdezésszerkesztő-ablakba. Keresse meg a helyőrzőket, például a
[START_DATE]és[END_DATE]értékeket, és cserélje le őket az elemzéshez kívánt dátumtartományra, például'2023-01-01'értékre. Igény szerint módosítsa a szűrési feltételeket, például szűrjön egy adott Patient Class értékre. - Adatkinyerő szkript futtatása: Futtassa a testreszabott SQL-szkriptet. A lekérdezés részletes adatokat kér le, ezért a dátumtartománytól és az adatbázis méretétől függően néhány perctől akár több óráig is tarthat.
- Első eredmények ellenőrzése: A lekérdezés lefutása után tekintse át az SQL-kliens eredménytáblájának első néhány száz sorát. Keresse a nyilvánvaló hibákat, például a csak null értékeket tartalmazó oszlopokat vagy a hibás adatformátumokat.
- Adatok exportálása CSV-fájlba: Exportálja a teljes eredményhalmazt CSV-fájlba. A karakterhibák elkerüléséhez használjon UTF-8 kódolást. Ellenőrizze, hogy az exportált fájl fejlécsora a lekérdezés aliasaiban megadott oszlopneveket tartalmazza, például a „BillingEvent” és az „ActivityName” értéket.
- Feltöltés előkészítése: Mielőtt feltölti a fájlt egy process mining eszközbe, nyissa meg, és ellenőrizze az épségét. Győződjön meg arról, hogy az időbélyegek formátuma egységes, az oszlopfejlécek pedig pontosan megfelelnek az elvárt attribútumoknak. Ezután a fájl feltölthető.
Konfiguráció
- Dátumtartomány: A lekérdezés a
[START_DATE]és[END_DATE]helyőrzőket használja. Az adatmennyiség szabályozásához adjon meg pontos, ésszerű dátumtartományt. Első elemzéshez 3–6 hónapnyi adatot javaslunk. - Szűrés: A kezdeti adathalmazt a betegtalálkozó regisztrációs dátuma (
reg_dt_tm) alapján szűri aRelevantEncountersszakasz. TovábbiWHEREfeltételekkel szűkítheti az adatkört, például aze.patient_class_code IN ('INPATIENT', 'OUTPATIENT')feltétellel, ha bizonyos betegtalálkozó-típusokra szeretne összpontosítani. - Teljesítmény: Az éles adatbázisból végzett közvetlen lekérdezés hatással lehet a rendszer teljesítményére. Az adatkinyerést lehetőleg csúcsidőn kívül vagy, ha rendelkezésre áll, az éles adatbázis csak olvasási replikáján futtassa.
- Előfeltételek: Ehhez a módszerhez olyan adatbázis-felhasználói fiók szükséges, amely
SELECTjogosultsággal rendelkezik a lekérdezésben hivatkozott összes táblához. Ide tartoznak a betegtalálkozó-, számlázási, díj-, igénylés-, elszámolási és pénzügyi tranzakciós táblák. - Táblák és oszlopok megfeleltetése: A megadott szkript gyakori, példaként használt tábla- és oszlopneveket tartalmaz. Ellenőrizze, és rendelje hozzá ezeket a szervezet Oracle Health adatbázissémájában ténylegesen használt nevekhez. A
FINANCIAL_TRANSACTIONtábla például az Ön rendszerébenAR_TRANSACTIONSnéven szerepelhet.
Példa-lekérdezés 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; Készen áll a kezdésre?
Használja ezt a sablont az adatok megfelelő előkészítéséhez. Kezdje el még ma a Revenue Cycle Management folyamat fejlesztését.
Fejlessze a bevételi ciklust, hogy gyorsabban érkezzenek be a kifizetések
Szüntesse meg a szűk keresztmetszeteket, csökkentse 30%-kal az átfutási időt, és javítsa a pénz beáramlását.
Nincs szükség bankkártyára. Néhány perc alatt beállíthatja.