Bevételiciklus-kezelési adatainak sablonja
Bevételiciklus-kezelési adatainak sablonja
- Javasolt attribútumok
- Követendő tevékenységek
- Adatkinyerési útmutató
A bevételiciklus-kezelés attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Esemény időbélyege EventTimestamp | Annak a pontos dátuma és időpontja, amikor egy adott tevékenység vagy esemény történt. | ||
| Leírás Az esemény időbélyege rögzíti, mikor történt egy tevékenység. Ez az időadat elengedhetetlen a bevételi ciklus eseményei időzítésének és sorrendjének megértéséhez. Az elemzés során az időbélyegek alapján számítható ki a tevékenységek közötti idő, például a díjrögzítés késése vagy a befizetés könyvelési ideje. Segítségükkel feltárhatók a szűk keresztmetszetek, mérhetők a ciklusidők, és elemezhető a folyamat teljesítménye különböző időszakokban. A pontos időbélyegek szinte minden időalapú KPI és dashboard kiszámításához szükségesek. Miért fontos? Ez az attribútum minden időalapú mérőszám, köztük a ciklusidők és az időtartamok kiszámításához szükséges. Ezek alapvetőek a késések és a hatékonysági problémák feltárásához. Hol szerezhető be? Az Epic Resolute tranzakciós vagy eseménynapló-tábláiban található, az egyes rögzített tevékenységekhez kapcsolva. A mezőnevek gyakran Dt, DTTM vagy Time végződésűek. Példák 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Számlázási esemény BillingEvent | Egyetlen szolgáltatás vagy termék teljesítésének egyedi azonosítója. Ez hozza létre a díjat, és ez az elsődleges esetazonosító. | ||
| Leírás A számlázási esemény az azonosító, amely összekapcsolja a bevételi ciklus egy adott számlázható tételéhez tartozó összes tevékenységet. A szolgáltatás teljesítésekor kezdődik, és akkor ér véget, amikor a számlát teljesen rendezték vagy lezárták. A process mining elemzésben ez az attribútum elengedhetetlen az egyes díjak teljes folyamatának rekonstruálásához. Segítségével nyomon követhetők az egyes számlázási eseményekhez tartozó tevékenységek, például a díjak rögzítése, az igény benyújtása, a befizetés könyvelése és az elutasítás kezelése. Így jól láthatóvá válik a folyamat menete és annak eltérései. Miért fontos? Ez az alapvető esetazonosító. Segítségével összekapcsolhatók a kapcsolódó folyamatlépések, és elemezhető az egyes szolgáltatások bevételének keletkezése és behajtása a teljes életciklus során. Hol szerezhető be? Ez gyakran egy kórházi számla (HAR) vagy egy adott díjrögzítési munkamenet egyedi azonosítója az Epic Resolute rendszerben. A konkrét táblákról, például a HAR- vagy Charge Session-rekordokról az Epic Resolute dokumentációjában tájékozódhat. Példák BE10098765BE20012345BE30054321 | |||
| Tevékenység neve ActivityName | A bevételi ciklus kezelésének folyamatában végrehajtott konkrét esemény vagy feladat neve. | ||
| Leírás Ez az attribútum a bevételi ciklus egy-egy lépését írja le, például „Díjak rögzítve”, „Igény benyújtva a fizető félnek” vagy „Befizetés beérkezett”. Minden tevékenység a szolgáltatás számlázásának és kifizetésének egy külön mérföldköve. A tevékenységek elemzése a process mining alapja. Segítségével megjeleníthető a folyamattérkép, azonosíthatók a gyakori útvonalak, feltárhatók a lépések közötti szűk keresztmetszetek, és mérhető a belső eljárások betartása. Miért fontos? Meghatározza a folyamattérkép lépéseit, így megjeleníthető, elemezhető és fejleszthető a bevételi ciklus munkafolyamata. Hol szerezhető be? Ez általában az Epic Resolute számlázási és igénykezelő moduljainak eseménynaplóiból, auditnaplóiból vagy állapotváltozási rekordjaiból származik. Példák Díjak rögzítveIgény benyújtva a fizető félnekBefizetés beérkezettSzámla lezárva | |||
| Elutasítási indokkód DenialReasonCode | Szabványos kód, amely megadja, miért utasította el a fizető fél a benyújtott igényt. | ||
| Leírás Amikor a fizető fél elutasít egy igényt, indokkódot ad meg, például „Nem fedezett szolgáltatás”, „Duplikált igény” vagy „További információ szükséges”. Ezek a kódok gyakran szabványosítottak, és Claim Adjustment Reason Code (CARC) néven ismertek. Ez az attribútum a „Igényelutasítások aránya és okai” dashboard alapja. A különböző elutasítási kódok gyakoriságának elemzése segít feltárni az elutasítások kiváltó okait, például a jogosultsági problémákat, a kódolási hibákat vagy az előzetes engedély hiányát. Így célzott fejlesztési intézkedések hozhatók. Miért fontos? Közvetlenül megmutatja, miért utasítják el az igényeket. Az így nyert információk segítenek csökkenteni az elutasítások arányát és a bevételkiesést, valamint gyorsítani a kifizetéseket. Hol szerezhető be? Ezek az adatok a fizető felektől érkező igényválasz-tranzakciókban, például ANSI 835-ös fájlokban találhatók, és az Epic Resolute igénykezelő moduljában tárolódnak. Példák CO-16: Az igényből vagy szolgáltatásból hiányzik egy adatOA-18: Duplikált igény vagy szolgáltatásPR-96: Nem fedezett díj(ak) | |||
| Felelős felhasználó ResponsibleUser | A tevékenységet végrehajtó felhasználó vagy alkalmazott azonosítója. | ||
| Leírás Ez az attribútum rögzíti a bevételi ciklus egy adott feladatáért felelős személy felhasználói azonosítóját, nevét vagy alkalmazotti számát. Ilyen lehet a díjakat rögzítő egészségügyi dolgozó, az igényt benyújtó számlázási munkatárs vagy az elutasítást utánkövető behajtási munkatárs. A felhasználók szerinti elemzés segít azonosítani a kiemelkedő teljesítményt nyújtókat, feltárni a képzési igényeket és megérteni a munkaterhelés eloszlását. Fontos eszköz a teljesítmény kezeléséhez, valamint az egyes személyekhez vagy szerepkörökhöz köthető folyamateltérések vizsgálatához. Miért fontos? Lehetővé teszi az egyéni vagy szerepkör szerinti teljesítményelemzést, és segít feltárni a képzési lehetőségeket, a munkaterhelés egyenlőtlenségeit és az erőforrásokkal kapcsolatos szűk keresztmetszeteket. Hol szerezhető be? Általában az Epic Resolute auditnaplóiban vagy tranzakciós naplóiban található, gyakran egy felhasználói törzsadattáblához, például EMP-rekordhoz kapcsolva. Példák j.doebsmith123User7890 | |||
| Fennálló egyenleg OutstandingBalance | A fizető fél vagy a beteg által a számlázási esemény után még fizetendő összeg. | ||
| Leírás Ez az attribútum az adott számlázási eseményhez tartozó, tevékenység időpontjában fennálló vevőkövetelés egyenlegét mutatja. A számla pénzügyi állapotát tükrözi annak teljes életciklusa során. A fennálló egyenleg fontos a pénzügyi jelentésekhez és a „Fennálló egyenlegek korosítási kimutatása” elkészítéséhez. Az érték időbeli, illetve fizető fél vagy osztály szerinti elemzése segít rangsorolni a behajtási feladatokat, kezelni a pénzforgalmat és felmérni a pénzügyi kockázatot. Miért fontos? Közvetlenül méri a folyamat késéseinek pénzügyi hatását. Elengedhetetlen a behajtási feladatok rangsorolásához, a pénzforgalom kezeléséhez és a vevőkövetelések megértéséhez. Hol szerezhető be? Az Epic Resolute betegszámla- vagy kórházi számlarekordjának (HAR) alapmezője. A pénzügyi tranzakciók folyamatosan frissítik az egyenleget. Példák 1500.00250.750.00 | |||
| Korrekció oka AdjustmentReason | A beteg számlaegyenlegén végrehajtott kézi vagy automatikus korrekció oka. | ||
| Leírás Ez az attribútum megmagyarázza, miért változott meg a számlaegyenleg a szokásos befizetéstől vagy díjtól eltérő okból. Ilyen ok lehet a fizető féllel kötött szerződés szerinti engedmény, kis összegű tartozás leírása vagy könyvelési hiba javítása. Ez az attribútum elengedhetetlen a „Számlakorrekciók száma típusonként” dashboardhoz. A korrekciók okainak elemzésével a szervezetek feltárhatják a bevételkiesés forrásait, megérthetik a fizető felekkel kötött szerződések hatását, és észrevehetik a számlázási folyamat esetleges hatékonysági problémáit vagy hibáit. Miért fontos? Megmutatja a bevételkiesés és a számlázás pontosságának összefüggéseit azáltal, hogy feltárja a számlaegyenlegek módosításának okait. Ez segít csökkenteni a szükségtelen leírásokat. Hol szerezhető be? Az Epic Resolute betegszámla-kezelő moduljának korrekciós tranzakcióihoz tartozó részletek között található. Példák Szerződés szerinti engedményKis összegű tartozás leírásaDuplikált díj korrekciója | |||
| Számlázási osztály BillingDepartment | A számlázási eseményért vagy tevékenységért felelős osztály vagy funkcionális csapat. | ||
| Leírás Ez az attribútum azt a szervezeti egységet jelöli, például a „Fekvőbeteg-számlázás”, a „Járóbeteg-számlázás” vagy az „Elutasításkezelő csapat” egységet, amely a számlázási eseményhez kapcsolódik vagy egy adott tevékenységet végrehajtott. Ez a dimenzió elengedhetetlen a „Számlázási osztályok teljesítménymutatói” dashboardhoz. Lehetővé teszi az olyan fontos mutatók közvetlen összehasonlítását, mint az elutasítási arány vagy a díjrögzítési idő. Segít a vezetőknek azonosítani a jól teljesítő osztályokat, egységesíteni a bevált gyakorlatokat és hatékonyan elosztani az erőforrásokat. Miért fontos? Lehetővé teszi a különböző osztályok teljesítményének összehasonlítását, és segít azonosítani a bevált gyakorlatokat, valamint a fejlesztésre vagy további erőforrásokra szoruló területeket. Hol szerezhető be? Ez az információ az Epic Resolute rendszerben a felhasználói rekordhoz, a beteg számlájához vagy a szolgáltatás helyszínéhez kapcsolódhat. Példák Kardiológiai számlázásRadiológiai RCMKözponti számlázási iroda | |||
| Szolgáltatás típusa ServiceType | Az elvégzett egészségügyi szolgáltatás kategóriája vagy típusa. | ||
| Leírás Ez az attribútum a számlázható szolgáltatást sorolja be, például „Radiológia”, „Műtét”, „Konzultáció” vagy „Sürgősségi ellátás” kategóriába. Klinikai kontextust ad a pénzügyi adatokhoz. A bevételi ciklus szolgáltatástípus szerinti elemzése feltárhatja az egyes klinikai területekre jellemző folyamateltéréseket. A műtéti beavatkozásoknál például összetettebb lehet a díjak rögzítése és az engedélyezés, mint egy szokásos rendelői vizitnél. Ez eltérő folyamatműködéshez és kihívásokhoz vezethet. Miért fontos? Klinikai kontextust ad a pénzügyi adatokhoz, így elemezhető, hogyan befolyásolják a különböző egészségügyi szolgáltatások a bevételi ciklust és annak hatékonyságát. Hol szerezhető be? Az Epic rendszerben a díjtételhez kapcsolódó díjleírás-törzsadatból (CDM), szolgáltatási sorból vagy részlegből származik. Példák Fekvőbeteg-műtétJáróbeteg-radiológiaSürgősségi ellátás | |||
| A bevételi ciklus teljes időtartama TotalRevenueCycleTime | Az első szolgáltatási eseménytől az utolsó fizetésig vagy a számla lezárásáig eltelt, kiszámított idő. | ||
| Leírás Ez az egyedi számlázási esemény bevételi ciklusának teljes időtartamát mérő, esetszintű KPI. Általában a „Service Rendered” tevékenység és a végső „Payment Received” vagy „Account Closed” tevékenység közötti időt számítják ki. Ez a magas szintű mérőszám átfogó képet ad az RCM-folyamat hatékonyságáról. A KPI időbeli követése megmutatja a folyamatfejlesztési kezdeményezések hatását, és jelzi, milyen gyorsan válik a szolgáltatásból készpénzbevétel. Miért fontos? A folyamat hatékonyságáról az elejétől a végéig ad képet, és közvetlenül méri, mennyi idő alatt lesz a szolgáltatásból készpénzbevétel. Hol szerezhető be? Ezt a mérőszámot a process mining eszköz számítja ki: minden esetnél megkeresi az első és az utolsó eseményt, majd kiszámítja a köztük eltelt időt. Példák 259200038880005184000 | |||
| Adatok utolsó frissítése LastDataUpdate | Az az időbélyeg, amely jelzi, mikor frissítették vagy nyerték ki utoljára az esemény adatait a forrásrendszerből. | ||
| Leírás Ez az attribútum az adatok frissességét mutatja. Jelzi, mikor töltötték be utoljára a rekordot az Epic Resolute rendszerből a process mining adathalmazba. Ez fontos az elemzés aktualitásának megítéléséhez és az adatok ellenőrzéséhez. Segít a felhasználóknak megállapítani, hogy a rendelkezésre álló legfrissebb információkat látják-e, és nélkülözhetetlen az adatfrissítések ütemezéséhez. Miért fontos? Segít a felhasználóknak megérteni, mennyire frissek az elemzett adatok. Ez elengedhetetlen a pontos, naprakész üzleti döntésekhez. Hol szerezhető be? Ezt az időbélyeget az ETL (Extract, Transform, Load) folyamat adja hozzá az adatok betöltésekor. Példák 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| Automatizált? IsAutomated | Logikai jelző, amely megmutatja, hogy a tevékenységet rendszer vagy automatizált folyamat végezte-e. | ||
| Leírás Ez a jelző különbözteti meg a rendszer által automatikusan végrehajtott feladatokat, például az igények automatikus létrehozását vagy a jogosultság ellenőrzését a felhasználó által végzett manuális feladatoktól. Az attribútum elemzésével felmérhető a folyamat automatizáltsága. Összehasonlítható az automatizált és a manuális tevékenységek hatékonysága és hibaaránya, azonosíthatók a további automatizálási lehetőségek, és nyomon követhető a meglévő botok vagy rendszerbeállítások teljesítménye. Miért fontos? Megkülönbözteti a rendszer által és az emberek által végzett tevékenységeket. Ez segít az automatizálás hatásának értékelésében és az új automatizálási lehetőségek feltárásában. Hol szerezhető be? Ezt gyakran úgy állapítják meg, hogy ellenőrzik, az adott tevékenység „ResponsibleUser” mezőjében rendszer- vagy szolgáltatásfiók szerepel-e, illetve automatizáltnak ismert tevékenységneveket jelölnek meg. Példák truefalse | |||
| Betegazonosító PatientId | Az ellátásban részesülő beteg egyedi azonosítója. | ||
| Leírás Ez az attribútum a beteg egészségügyi dokumentációs számát (MRN) vagy más egyedi azonosítóját jelöli. A pénzügyi számlázási eseményt egy konkrét személyhez kapcsolja. A beteg adatainak védelme érdekében ezt általában nem használják elsődleges elemzési dimenzióként, de az adatok ellenőrzéséhez elengedhetetlen. Egy beteg valamennyi számlázási eseménye összesíthető vele, így áttekinthető a teljes pénzügyi folyamata. A klinikai folyamatadatokkal való esetleges összekapcsoláshoz is szükség van rá. Miért fontos? A pénzügyi adatokat egy konkrét beteghez kapcsolja, így ellenőrizhetők az adatok, és lehetőség nyílik a beteg teljes folyamatának szélesebb körű elemzésére. Az adatvédelmi kockázatok miatt körültekintően kell kezelni. Hol szerezhető be? Az Epic rendszerben széles körben használt alapvető azonosító, amely a beteg regisztrációs és számlarekordjaihoz kapcsolódik. Példák MRN-1234567MRN-8765432MRN-5551234 | |||
| Esemény befejezési ideje EventEndTime | Az időbélyeg, amely megmutatja, mikor fejeződött be egy tevékenység. A tevékenység időtartamának kiszámítására használható. | ||
| Leírás Ez az attribútum rögzíti a tevékenység befejezésének időpontját. Sok tevékenység azonnali esemény, amelynél a StartTime és az EndTime megegyezik, de egyes feladatoknak mérhető időtartamuk van, például az elutasítás utáni telefonos egyeztetésnek. Ha rendelkezésre áll, az EndTime segítségével közvetlenül kiszámítható a tevékenység feldolgozási ideje: „EndTime” - „StartTime”. Ez pontosabb, mint a következő tevékenység kezdési idejéből következtetni az időtartamra, mert figyelembe veszi a lépések közötti várakozást is. A „ProcessingTime” attribútum kiszámításához is szükséges. Miért fontos? Pontosan kiszámítható vele, mennyi időt vesz igénybe az egyes tevékenységek elvégzése. Ez segít a nem hatékony feladatok azonosításában és az erőforrások termelékenységének mérésében. Hol szerezhető be? Egyes Epic Resolute modulokban érhető el, amelyek rögzítik a feladatok kezdési és befejezési idejét, például a munkasor- vagy tevékenységkezelési naplókban. Gyakran nem rögzítik külön. Példák 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| Fizetési határidő PaymentDueDate | Az a dátum, ameddig a számlázott szolgáltatás ellenértékét várhatóan megfizetik. | ||
| Leírás Ez az attribútum a számlán feltüntetett vagy a fizetővel kötött szerződésben meghatározott fizetési határidőt jelöli. A határidő a pontos fizetés mérésének viszonyítási alapja. A fizetési határidő szükséges a „Outstanding Balance Aging Report” elkészítéséhez. A nyitott egyenlegek határidejét az aktuális dátummal összevetve a követelések késedelmi időszakok szerint csoportosíthatók, például 0–30 vagy 31–60 napos késedelem alapján. Ez segít a legrégebben lejárt számlák behajtásának előtérbe helyezésében. Miért fontos? A követelések korosítási elemzésének alapja. Ez segít a behajtás rangsorolásában és a ki nem fizetett számlákból eredő pénzügyi kockázat kezelésében. Hol szerezhető be? Ezt a dátumot gyakran a számla kelte és az Epicben a fizető szerződésében vagy a beteg számlaadatainál tárolt fizetési feltételek alapján számítják ki. Példák 2023-05-302023-06-152023-07-01 | |||
| Fizető fél neve PayerName | A biztosító, az állami szerv vagy más, a kifizetésért felelős fél neve. | ||
| Leírás Ez az attribútum azonosítja a számlázási eseményhez tartozó elsődleges fizető felet, például a Blue Cross Blue Shieldet, a Medicaret vagy az Aetnát. Saját finanszírozás esetén a beteg is megjelenhet fizető félként. A folyamat fizető fél szerinti elemzése sokat elárulhat. Kiderülhet például, hogy egyes fizető feleknél magasabb az elutasítási arány, hosszabb a kifizetési ciklus vagy összetettebbek a követelmények. Ezek alapján az egyes fizető felekhez igazíthatja a számlázási eljárásokat, és javíthatja a hatékonyságot, valamint a kifizetések sebességét. Miért fontos? Lehetővé teszi a fizető fél szerinti teljesítményelemzést. Megmutatja, mely fizető feleknél magas az elutasítási arány vagy lassú a kifizetési ciklus, így célzott utánkövetési stratégiák alakíthatók ki. Hol szerezhető be? Ez az információ a beteg biztosítási fedezetének részleteihez tartozik, és az Epic Resolute rendszerben a kórházi számlához (HAR) kapcsolódik. Példák Medicare B részUnitedHealthcareAetna PPO | |||
| Forrásrendszer SourceSystem | Az az informatikai rendszer, amelyből az adat származik. | ||
| Leírás Ez az attribútum azonosítja a rekord forrásrendszerét, amely ebben az esetben az Epic Resolute. Több integrált rendszer használatakor ez a mező segít megkülönböztetni az adatok eredetét. Egyetlen rendszer esetén feleslegesnek tűnhet, de az adatirányítás és a bővíthetőség szempontjából bevált gyakorlat. Egyértelművé teszi az adatok eredetét akkor is, ha később más rendszerekből, például egy külön behajtási platformról is érkeznek adatok. Miért fontos? Segít nyomon követni az adatok eredetét és értelmezni a kontextust. Ez fontos az adatirányításhoz és a hibakereséshez. Hol szerezhető be? Ez általában egy statikus érték, amelyet az adatkinyerés és -átalakítás során adnak hozzá az adathalmaz forrásának megjelölésére. Példák Epic ResoluteEpicResolute_V2023 | |||
| Igényazonosító ClaimId | A fizetőnek benyújtott biztosítási igény egyedi azonosítója. | ||
| Leírás Ez az attribútum a fizetőnek elküldött igénylőlap, például a CMS-1500 vagy az UB-04 egyedi azonosítója. Egyetlen számlázási eseményhez több igény is tartozhat, ha a szolgáltatást újraszámlázzák vagy az elutasítás ellen fellebbeznek. Az igény benyújtásának és az elutasítás kezelésének részletes elemzéséhez érdemes az Igényazonosító szerint követni az eseményeket. Így elkülöníthetők az eredeti igényhez kapcsolódó tevékenységek az ugyanarra a szolgáltatásra később újra benyújtott igény tevékenységeitől. Miért fontos? Egyedi azonosítót ad az egyes igénybenyújtások életciklusának követéséhez, ami elengedhetetlen az újrabenyújtások és a fellebbezések elemzéséhez. Hol szerezhető be? Az Epic Resolute igénykezelő modulja hozza létre az igény rögzítésekor. Az igényadatokat tároló táblákban található. Példák CLM-2023-98765CLAIM-0012345623189A4567 | |||
| Módosított összeg AdjustedAmount | A módosítási tranzakció pénzösszege. | ||
| Leírás Ez a mező rögzíti a számlán végrehajtott módosítás pontos összegét. Az érték lehet pozitív vagy negatív, a számlaegyenleg jóváírását vagy terhelését jelölve. Ez az összeg az „Account Adjustment Volume By Type” dashboard elsődleges mérőszáma. Ha a módosítási okok szerint összesíti, jól láthatóvá válik az egyes módosítástípusok pénzügyi hatása. Megmutatja például, hogy mennyi bevételt írnak le szerződéses kötelezettségek miatt, és mennyi vész el javítható hibák következtében. Miért fontos? Számszerűsíti a számlamódosítások pénzügyi hatását, így mérhetővé teszi a bevételkiesést és a számlázási pontatlanságok költségét. Hol szerezhető be? Az Epic Resolute pénzügyi tranzakcióinak részletező tábláiban található, a módosítás típusú tranzakciókhoz kapcsolva. Példák -1250.45-50.0025.10 | |||
A bevételiciklus-kezelés tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Befizetés beérkezett | A fizető féltől vagy a betegtől érkező befizetés beérkezését jelenti. Az esemény általában akkor rögzül, amikor betöltik az elektronikus elszámolási értesítést (ERA), vagy kézzel bevisznek egy csekket a rendszerbe. | ||
| Miért fontos? Ez a tevékenység fontos mérföldkő, mert jelzi, hogy bevétel érkezik. Az igény benyújtása és a befizetés beérkezése közötti idő a vevőkövetelések kezelésének egyik fontos mérőszáma. Hol szerezhető be? A Resolute kifejezetten befizetési tranzakcióként rögzíti. A tranzakciókhoz dátum, forrás és összeg tartozik, és gyakran még azelőtt naplózzák őket, hogy a befizetést az egyes díjakhoz könyvelnék. Rögzítés A befizetési tranzakciókat a pénzügyi tranzakciós naplóból rögzítse. Ezek gyakran meghatározott tranzakciótípusok alapján azonosíthatók. Eseménytípus explicit | |||
| Befizetés könyvelve a számlára | Ez az esemény azt jelzi, hogy a beérkezett befizetést a beteg számláján szereplő konkrét díjakhoz rendelték. Ezzel csökken a számlázási esemény fennálló egyenlege. | ||
| Miért fontos? A befizetések hatékony könyvelése elengedhetetlen a pontos számlaegyenlegek fenntartásához és a számlázási események lezárásához. Így helyesen azonosíthatók a másodlagos számlázáshoz vagy behajtáshoz kapcsolódó fennmaradó összegek. Hol szerezhető be? Ez kifejezetten rögzített tranzakció a Resolute rendszerben. A befizetés könyvelése egy vagy több díjtranzakcióhoz kapcsolja a befizetési tranzakciót, amit a tranzakció részleteit tartalmazó táblák rögzítenek. Rögzítés Rögzítse azt a tranzakciós rekordot, amely a befizetést egy díjhoz rendeli. Ez meghatározott tranzakciótípusok alapján azonosítható. Eseménytípus explicit | |||
| Díjak rögzítve | A teljesített szolgáltatások számlázható díjainak hivatalos rögzítését jelenti. Az Epic rendszerben ez általában a beteg számlájára könyvelt tranzakció. A klinikai tevékenység automatikusan létrehozhatja, de kézzel is rögzíthető. | ||
| Miért fontos? Ez az első fontos mérföldkő. A díjak rögzítésének sebessége és pontossága megmutatja, hogyan gyorsítható a számlázás, és hogy minden teljesített szolgáltatás számlázásra kerül-e. Hol szerezhető be? A Resolute tranzakciós naplói kifejezetten rögzítik. Minden díj külön bejegyzésként szerepel, könyvelési dátummal, szolgáltatási dátummal és összeggel. Az adatok gyakran az ARPB_TRANSACTIONS táblához hasonló táblákban találhatók. Rögzítés A díjak könyvelését a rendszer pénzügyi tranzakciós naplójából rögzítse. Eseménytípus explicit | |||
| Igény benyújtva a fizető félnek | Ez az esemény azt jelzi, hogy az igényt hivatalosan elküldték a biztosítónak elbírálásra. Az Epic nyomon követi ezt az eseményt, és naplózza, amikor az elektronikus igényfájlt továbbítják az elszámolóháznak vagy a fizető félnek. | ||
| Miért fontos? Ez a mérföldkő azért fontos, mert ekkor kezdődik a fizető fél kifizetési határidejének számítása. Az esemény elemzésével mérhető az igények továbbításának hatékonysága, és kiszámítható a „Számla kézbesítési ideje a fizető félnek” KPI. Hol szerezhető be? A Resolute ezt kifejezetten rögzíti. Az igényrekord tartalmazza a benyújtás állapotát és az elküldés időbélyegét. Rögzítés Rögzítse azt az időbélyeget, amikor az igény állapota „Benyújtva” vagy „Továbbítva” értékre változik. Eseménytípus explicit | |||
| Igényt elutasította a fizető fél | Azt jelzi, hogy a fizető fél értesítést küldött az igény elutasításáról. Az esemény akkor rögzül, amikor az Epic feldolgozza az elektronikus elszámolási értesítést (835-ös fájl), vagy amikor egy felhasználó kézzel rögzíti az elutasítást. | ||
| Miért fontos? Ez a tevékenység fontos utómunkafolyamatot indít el. Az elutasítások okainak és számának elemzése segít feltárni a kiváltó okokat, javítani az első benyújtásra történő kifizetések arányát, és csökkenteni a behajtás késedelmét. Hol szerezhető be? Az igényhez kapcsolódó tranzakcióként vagy állapotfrissítésként kifejezetten rögzítik. Az elutasítás adatai, köztük az indokkódok, általában elektronikusan érkeznek, majd bekerülnek a fiókba. Rögzítés Szűrjön azokra a tranzakciótípusokra vagy igényállapot-frissítésekre, amelyek elutasítást jeleznek. Eseménytípus explicit | |||
| Számla lezárva | Ez az utolsó tevékenység. Azt jelzi, hogy a számlázási esemény fennálló egyenlege nullára csökkent, és nincs további függőben lévő tevékenység. Ennek oka lehet a teljes kifizetés, korrekció vagy leírás. | ||
| Miért fontos? Ez az esemény jelzi a számlázási eseményhez tartozó bevételi ciklus sikeres lezárását. A szolgáltatás teljesítése és a lezárás közötti teljes idő fontos KPI a folyamat hatékonyságának méréséhez. Hol szerezhető be? Ez általában kikövetkeztetett esemény. Akkor állapítható meg, amikor a számlázási eseményhez tartozó számlaegyenleg nullára csökken, és nullán is marad. Rögzítés A számlaegyenleg folyamatos összegének kiszámításával következtethető ki. Az időbélyeg azonosításához keresse meg az utolsó tranzakciót, amely nullára csökkentette az egyenleget. Eseménytípus inferred | |||
| Szolgáltatás teljesítve | Ez a tevékenység jelzi, hogy a beteg megkapta az egészségügyi szolgáltatást, ami elindítja a számlázási eseményt. Az adatot gyakran az Epic EHR (EpicCare) rögzíti, amikor az egészségügyi dolgozó jóváhagy egy vizitet vagy beavatkozást. | ||
| Miért fontos? Ez a bevételi ciklus elsődleges kezdő eseménye. A szolgáltatás teljesítése és a díj rögzítése közötti idő elemzése segít feltárni a számlázás megkezdésének késéseit és az esetleges bevételkiesést. Hol szerezhető be? Az esemény általában a számlázási fiókhoz kapcsolt klinikai modulok szolgáltatási vagy vizit-időbélyegeiből következtethető ki. A díjtranzakción szereplő szolgáltatási dátum a legfontosabb adat. Rögzítés A számlázási esemény első díjtranzakciójához tartozó szolgáltatási dátumból következtethető ki. Eseménytípus inferred | |||
| Elutasítás utáni ügyintézés elindítva | Ez a tevékenység jelzi, hogy megkezdődött az elutasított igény belső felülvizsgálata és rendezése. Gyakran akkor rögzül, amikor egy felhasználó átveszi az elutasított igényt egy munkalistában, vagy módosítja annak állapotát. | ||
| Miért fontos? Ennek nyomon követésével mérhető, milyen gyorsan reagál az elutasításokat kezelő csapat. Az elutasítás és az ügyintézés megkezdése közötti késés szükségtelenül meghosszabbíthatja a bevételi ciklust. Hol szerezhető be? Ez általában az igény állapotának vagy az Epic munkalistáiban szereplő hozzárendelési előzményeknek a változásából következtethető ki. Például az igény állapota „Elutasítva” értékről „Felülvizsgálat alatt” értékre változhat. Rögzítés Az igény állapotváltozásából vagy olyan auditnapló-bejegyzésből következtessen rá, amely jelzi, hogy egy felhasználó megkezdte az elutasítás kezelését. Eseménytípus inferred | |||
| Fennálló tartozás átadva behajtásra | Ez az esemény azt jelzi, hogy a ki nem fizetett számlaegyenleget belső vagy külső behajtási folyamatba helyezték át. Ez gyakran a számla vagy a számlázási esemény kifejezett állapotváltozásaként jelenik meg. | ||
| Miért fontos? Ez a tevékenység elindítja a fennálló tartozások behajtásának utolsó szakaszát. A behajtási folyamat sikerességi arányának és átfutási idejének nyomon követése segít mérsékelni a behajthatatlan követeléseket. Hol szerezhető be? Ez általában kifejezetten rögzített esemény. Az Epic lehetővé teszi a számlák behajtó ügynökségnek történő átadását, ami naplóbejegyzést vagy állapotváltozást hoz létre a számlán. Rögzítés Keresse meg azt az állapotváltozást vagy tranzakciót, amely jelzi, hogy a számlát behajtó ügynökséghez helyezték. Eseménytípus explicit | |||
| Igény ismételten benyújtva | Ez az esemény azután történik, hogy kijavították az elutasított igényt, majd ismét elküldték a fizető félnek. Ez külön benyújtási esemény, amely az eredeti igényhez kapcsolódik. | ||
| Miért fontos? Ez az utómunka-folyamat fontos része. Az ismételt benyújtásig eltelt idő és az újra benyújtott igények sikerességi arányának mérése megmutatja, mennyire hatékony az elutasítások rendezése. Hol szerezhető be? Ez az eredeti benyújtáshoz hasonló, kifejezetten rögzített esemény, de gyakran ismételt benyújtásként van megjelölve. Az igényrekord új benyújtási időbélyeget tartalmaz, és ismételt benyújtásra utaló kódot is tartalmazhat. Rögzítés Rögzítse annak az igénybenyújtásnak az időbélyegét, amely javítottként vagy ismételt benyújtásként van megjelölve. Eseménytípus explicit | |||
| Igény létrehozva | Ez a tevékenység azt jelzi, hogy a rendszer a rögzített díjak alapján hivatalos igényt vagy számlát hozott létre. Ez előkészítő lépés, mielőtt az igényt elküldik a fizető félnek vagy a betegnek. | ||
| Miért fontos? Az igény létrehozásának nyomon követése segít elkülöníteni a díjak rögzítése és a benyújtásra való előkészítés közötti késéseket. Ez fontos belső lépés, amely befolyásolhatja a számlázás teljes átfutási idejét. Hol szerezhető be? Ezt általában akkor naplózza a rendszer, amikor lefut egy számlázási vagy igénylétrehozási kötegelt feladat. A rendszer időbélyeget rögzít, amikor létrejön az adott fiókhoz tartozó igényfájl, például egy 837-es fájl. Rögzítés Keresse meg azokat a naplóbejegyzéseket vagy állapotváltozásokat, amelyek jelzik, hogy az igény összeállt és benyújtásra kész. Eseménytípus explicit | |||
| Számlakorrekció rögzítve | Ez a tevékenység olyan, nem befizetésből eredő tranzakciót jelöl, amely módosítja a számlaegyenleget. Ilyen lehet a szerződéses korrekció, a kis összegű tartozás leírása vagy egy méltányossági kedvezmény. A rendszer ezt meghatározott tranzakciótípusként rögzíti. | ||
| Miért fontos? A korrekciók elemzése segít feltárni a bevételkiesést. Bizonyos korrekciótípusok nagy száma díjszabási, szerződéses vagy belső szabályozási problémára utalhat. Hol szerezhető be? A Resolute pénzügyi naplói kifejezetten korrekciós tranzakcióként rögzítik ezeket. Minden korrekcióhoz meghatározott típus vagy indokkód tartozik. Rögzítés Szűrjön a pénzügyi korrekcióknak vagy leírásoknak megfelelő tranzakciótípusokra. Eseménytípus explicit | |||
Adatkinyerési útmutatók
Lépések
- Adatbázis-kapcsolat létrehozása: Kérjen csak olvasási jogosultságot az Epic Clarity adatbázishoz. Csatlakozzon az adatbázis-kiszolgálóhoz egy szabványos SQL-klienssel, például a DBeaverrel vagy a Microsoft SQL Server Management Studióval.
- A fő táblák azonosítása: Az adatkinyeréshez elsősorban a
HSP_ACCOUNTtábla szükséges az esetadatokhoz, aHSP_TRANSACTIONSa pénzügyi eseményekhez, aCLP_CLAIM_INFOaz igények állapotához, azF_ARHB_TX_SET_POST_HXpedig a fizetések könyvelési adataihoz. A felhasználói adatokhoz kapcsolja be a törzsadatokat tartalmazó táblákat is, például aCLARITY_EMPtáblát. - Az elemzés hatókörének meghatározása: A lekérdezés megírása előtt határozza meg az elemzés hatókörét. Adjon meg egy konkrét, jellemzően 3–6 hónapos időszakot, és válassza ki a bevonni vagy kizárni kívánt kórházi szolgáltatási területeket (
SERV_AREA_ID) vagy számlaosztályokat. - Az SQL-lekérdezés összeállítása: Készítsen SQL-lekérdezést Common Table Expression (CTE) használatával. Első lépésként válassza ki a meghatározott hatókörbe eső
HSP_ACCOUNT_IDértékeket. Ezek adják a számlázási események alaphalmazát. - Az egyes tevékenységek lekérdezéseinek összeállítása: A 12 szükséges tevékenység mindegyikéhez írjon külön
SELECTutasítást, amely lekéri az adatokat a megfelelő táblákból. Kapcsolja vissza az adatokat a kezdeti CTE-hez, hogy csak a kívánt számlákat elemezze. - A lekérdezések egyesítése UNION ALL használatával: Az egyes tevékenységek lekérdezéseinek eredményét a
UNION ALLoperátorral egyetlen, egységes eseménynaplóba fűzheti össze. Az operátor egymás alá rendezi a lekérdezések sorait. - Mezők megfeleltetése a szabványos sémának: Minden
SELECTutasításban nevezze át az oszlopokat úgy, hogy megfeleljenek a ProcessMind elvárt sémájának:BillingEvent,ActivityName,EventTimestamp,ResponsibleUserstb. Az adott tevékenységre nem vonatkozó attribútumok értéke legyenNULL. - A lekérdezés futtatása és finomítása: Futtassa a teljes lekérdezést a Clarity adatbázison. A táblák mérete miatt ez sokáig tarthat. Ha a teljesítmény nem megfelelő, szűkítse tovább az időszakot, vagy adjon meg további szűrőket a kezdeti CTE-ben.
- Az eredmény ellenőrzése: A lekérdezés lefutása után vizsgálja meg az első néhány száz sort. Ellenőrizze, hogy minden oszlop megvan-e, az időbélyegek formátuma egységes-e, és a különböző
ActivityNameértékek a várakozásoknak megfelelően jelennek-e meg. - Exportálás CSV-fájlba: Exportálja a teljes eredményhalmazt az SQL-kliensből CSV-fájlba. A fájl kódolása UTF-8 legyen, és tartalmazzon fejlécsort a megfelelő oszlopnevekkel.
- Feltöltés előkészítése: A ProcessMindbe való feltöltés előtt nyissa meg a CSV-fájlt, és ellenőrizze, hogy nincsenek-e benne formázási hibák. Győződjön meg arról, hogy az időbélyegek formátuma egységes, például
YYYY-MM-DD HH:MI:SS. A fájl ezután feltölthető.
Konfiguráció
- Adatbázis-kapcsolat: Csak olvasási jogosultságú felhasználói fiók szükséges az Epic Clarity adatbázishoz.
- Időszak megadása: A lekérdezés az
@StartDateés az@EndDateváltozókat használja. Ezekkel adható meg az elemzés időszaka. Az adatmennyiség és a teljesítmény egyensúlyához 3–6 hónapos időszak javasolt. - Táblák és oszlopok megfeleltetése: A lekérdezés a Clarity tábláinak és oszlopainak szabványos elnevezéséből indul ki. Az Epic helyi konfigurációja vagy verziója miatt az Önök rendszerében eltérhetnek az elnevezések. Szükség esetén módosítsa a táblaneveket, oszlopneveket vagy az összekapcsolási feltételeket.
- Tranzakció- és állapotkódok: A lekérdezés olyan helyőrzőket tartalmaz, mint a
[Your Denial Tx Type]és a[Your Collections Status Code]. A megfelelő kódok megkereséséhez egyeztessen az Epic rendszeradminisztrátoraival, vagy tekintse át a vonatkozó törzsadatokat, például aZC_TX_TYPEvagy aZC_ACCOUNT_STATUStáblát. - Szűrés: A jobb teljesítmény és a célzottabb elemzés érdekében adjon szűrőket a kezdeti
BaseAccountsCTE-hez. Gyakori szűrő aSERV_AREA_ID, amellyel a kórházi szolgáltatási terület korlátozható, illetve azACCOUNT_CLASS_C, amellyel a fekvőbeteg- vagy járóbeteg-számlázás választható ki.
Példa-lekérdezés sql
DECLARE @StartDate DATE = '2023-01-01';
DECLARE @EndDate DATE = '2023-06-30';
WITH BaseAccounts AS (
SELECT DISTINCT
HA.HSP_ACCOUNT_ID
FROM
HSP_ACCOUNT HA
WHERE
HA.ADM_DATE_TIME >= @StartDate
AND HA.ADM_DATE_TIME <= @EndDate
-- Add additional filters here if needed, for example:
-- AND HA.SERV_AREA_ID = [Your Service Area ID]
)
-- 1. Service Rendered
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Service Rendered' AS ActivityName,
tx.SERVICE_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
AND tx.ORIG_REV_TX_ID IS NULL -- Not a reversal
UNION ALL
-- 2. Charges Captured
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Charges Captured' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
UNION ALL
-- 3. Claim Generated
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Generated' AS ActivityName,
claim.GENERATED_TIME AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.GENERATED_TIME IS NOT NULL
UNION ALL
-- 4. Claim Submitted to Payer
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
claim.XMIT_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.XMIT_DATE IS NOT NULL
UNION ALL
-- 5. Claim Denied by Payer
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
remit.REMIT_CODE_ID AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN F_ARHB_TX_SET_POST_HX remit ON tx.TX_ID = remit.TX_ID
WHERE tx.TX_TYPE_C IN ([Your Denial Tx Type]) -- Placeholder for denial transaction type codes
UNION ALL
-- 6. Denial Follow-Up Initiated (assumes status change on account)
SELECT
hist.HSP_ACCOUNT_ID AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
NULL AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCT_STATUS_HX hist
INNER JOIN BaseAccounts ba ON hist.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON hist.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE hist.ACCOUNT_STATUS_C = [Your Denial Followup Status Code] -- Placeholder for a status indicating follow-up
UNION ALL
-- 7. Claim Resubmitted
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
claim.RESUBMIT_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON claim.RESUBMIT_USER_ID = emp.USER_ID
WHERE claim.RESUBMIT_DATE IS NOT NULL
UNION ALL
-- 8. Payment Received & 9. Payment Posted to Account (combined for this query)
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE tx.TX_TYPE_C IN ([Your Payer Payment Tx Type], [Your Patient Payment Tx Type]) -- Placeholder for payment transaction types
UNION ALL
-- 10. Account Adjustment Made
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
zcar.NAME AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN ZC_ADJ_REASON zcar ON tx.ADJ_REASON_C = zcar.ADJ_REASON_C
WHERE tx.TX_TYPE_C IN ([Your Adjustment Tx Type]) -- Placeholder for adjustment transaction types
UNION ALL
-- 11. Balance Sent to Collections
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
INNER JOIN HSP_ACCT_STATUS_HX hist ON acct.HSP_ACCOUNT_ID = hist.HSP_ACCOUNT_ID AND hist.ACCOUNT_STATUS_C = [Your Collections Status Code]
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE acct.ACCOUNT_STATUS_C = [Your Collections Status Code] -- Placeholder for collections status
UNION ALL
-- 12. Account Closed
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Account Closed' AS ActivityName,
acct.CLOSED_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- System or Final transaction user
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE acct.ACCT_FIN_BALANCE = 0
AND acct.CLOSED_DATE IS NOT NULL
AND acct.CLOSED_DATE BETWEEN @StartDate and @EndDate
ORDER BY
BillingEvent,
EventTimestamp; Lépések
- Ellenőrizze, hogy rendelkezésre áll-e a jogosultság az Epic Clarity bevételiciklus-adatainak eléréséhez, beleértve a számla-, díj-, igény-, elutasítás-, fizetés-, módosítás-, behajtás- és lezárási előzményekhez szükséges forrástáblákat és nézeteket. Az Epic rendszerekben eltérhet, hogy mely táblák érhetők el, és hogyan nevezik el az oszlopokat. A lekérdezés minden helyőrzőjét feleltesse meg az Önök környezetében használt Clarity-objektumnak.
- Adja meg az adatkinyerés időszakát a [Start date parameter] és az [End date parameter] használatával. Kezdetben három-hat hónapot válasszon, és csak a lekérdezés teljesítményének és az események teljességének ellenőrzése után hosszabbítsa meg az időszakot.
- Határozza meg a BillingEvent megfeleltetését. A lekérdezés alapértelmezés szerint a
HSP_ACCOUNT.HSP_ACCOUNT_IDmezőt használja esetazonosítóként, ha az rendelkezésre áll. Ha az Önök szervezetében a számlázási eseményt díj-, igény- vagy találkozószinten határozzák meg, cserélje le a megfeleltetést a jóváhagyott azonosítóra, és minden tevékenység forrásában következetesen ugyanazt használja. - Minden forrástevékenységhez rendeljen hiteles időbélyeget és forrásattribútumot. A Service Rendered tevékenységhez a dokumentált szolgáltatási vagy találkozó-befejezési időbélyeget használja. A Charges Captured tevékenységhez a díj könyvelési időbélyegét. A Claim Generated és a Claim Submitted to Payer tevékenységhez a megfelelő igény-életciklus időbélyegeket. Az elutasítás, az utánkövetés, az újrabenyújtás, a fizetés, a módosítás, a behajtás és a lezárás esetén a dokumentált tranzakciós vagy állapot-időbélyeget használja.
- Cserélje le a lekérdezés összes szögletes zárójelben szereplő forráshelyőrzőjét, beleértve a következőket: [Your service source table], [Your charge source table], [Your claim source table], [Your denial source table], [Your follow-up source table], [Your payment source table], [Your adjustment source table], [Your collections source table] és [Your account closure source table]. Ne használjon nem dokumentált tranzakciókódokat. Az Epic jelentéskészítési csapata által jóváhagyott tranzakció- vagy állapotértékeket alkalmazza.
- Futtassa a lekérdezést a szervezet által jóváhagyott SQL-kliensben vagy jelentéskészítő platformon. Ellenőrizze, hogy mind a tizenkét tevékenység címkéje külön sorban szerepel-e. A ProcessMind nem következtet hiányzó életciklus-eseményekre az egyenlegek, az állapotok vagy az események sorrendje alapján.
- Ellenőrizze az eredmény sémáját. Az eredménynek tartalmaznia kell a következő mezőket: BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance és ServiceType. Az időbélyegek mellett őrizze meg az időzónára vagy a helyi időre vonatkozó dokumentációt, és ha ez megengedett, a belső auditkivonatban tartsa meg a forrásazonosítókat.
- Ellenőrizze az események időrendi sorrendjét BillingEvent szerint, a duplikátumok kezelését, a NULL értékek arányát, a tevékenységek számát, valamint az egyezést a forrásrendszer jelentéseivel. Vizsgálja meg azokat az időszakon kívüli eseményeket is, amelyek szükségesek az időszak előtt kezdődő vagy utána lezáruló esetek értelmezéséhez.
- Exportálja az eredményt a ProcessMind által támogatott tagolt fájlba vagy adatbázis-kapcsolaton keresztül. Eseményenként egy sort használjon, stabil oszlopnevekkel, egységes időbélyeg-formátummal és UTF-8 kódolással. Ne legyenek egyesített cellák vagy összesítő sorok. Feltöltéskor a BillingEvent mezőt állítsa be esetazonosítóként, az ActivityName mezőt tevékenységként, az EventTimestamp mezőt pedig esemény-időbélyegként.
Konfiguráció
- Források megfeleltetése: Az Epic Clarity rendszerek megvalósítása eltérő lehet. Minden szögletes zárójelben szereplő forrásobjektum- és oszlophelyőrzőt cseréljen le az Önök környezetében dokumentált táblára, nézetre vagy jóváhagyott jelentéskészítési rétegre. Ne feltételezze, hogy egy tábla vagy mező létezik csak azért, mert más Epic-rendszerekben gyakori.
- Esetazonosító: Az alapértelmezett lekérdezés a
HSP_ACCOUNT.HSP_ACCOUNT_IDmezőt használja. Ellenőrizze, hogy az Önök szervezetében a BillingEvent számlát, találkozót, igényt, díjat vagy más jóváhagyott üzleti kulcsot jelöl-e. - Időszak: Kezdje három-hat hónappal. Ha az esetek a jelentési időszak előtt is elkezdődhetnek, vegyen fel korábbi időszakot is. Ha az igény, az elutasítás, a fizetés vagy a lezárás a szolgáltatás dátuma után történhet, az utánkövetési időszakot is vegye figyelembe.
- Tevékenységek időbélyegei: Minden tevékenységhez egy hiteles időbélyeget állítson be. Ne használja az adatkinyerés, a fájlbetöltés vagy az aktuális állapot időpontját a tényleges üzleti esemény ideje helyett, kivéve, ha a forrásrendszer dokumentációja ezt jelöli meg az esemény időbélyegeként.
- Szűrők: A [Company Code filter], [Document Type filter], [Department filter], a fizető, a szolgáltatási terület és a számlaosztály szűrőit csak akkor alkalmazza, ha a meghatározásuk dokumentált, és az elemzéshez szükségesek. A szűrők legyenek egységesek az összes UNION ALL ágban.
- Tranzakciók és állapotok megfeleltetése: Állítsa be a szervezet által jóváhagyott értékeket a díj könyveléséhez, az igény létrehozásához és benyújtásához, az elutasításhoz, az utánkövetéshez, az újrabenyújtáshoz, a fizetés beérkezéséhez és könyveléséhez, a módosításhoz, a behajtáshoz és a lezáráshoz. A lekérdezés szándékosan használ helyőrzőket, mert az Epic-tranzakciók értékei és forrásstruktúrái rendszerenként eltérnek.
- NULL értékek kezelése: Az adott tevékenységre nem vonatkozó attribútumok értékét hagyja
NULL-ként. Ne pótolja kitalált értékekkel a hiányzó elutasítási okot, módosítási okot, felhasználót, részleget vagy szolgáltatástípust. - Teljesítmény: Az összekapcsolás előtt korlátozza a forrássorokat indexelt dátumoszlopokkal és jóváhagyott szervezeti szűrőkkel. A feltételekben ne alkalmazzon függvényeket indexelt időbélyeg-oszlopokra. Ha a nyers előzményadatok mennyisége nagy, fontolja meg az egyes forrástevékenységek jóváhagyott jelentéskészítési nézetben történő előkészítését.
- Duplikátumok kezelése: Dokumentált szabály nélkül ne távolítsa el a duplikált eseményeket. Egy BillingEventhez több fizetés, módosítás, igénybenyújtás vagy állapotváltozás is tartozhat.
- Előfeltételek: Szükség lehet Epic Clarity jelentéskészítési jogosultságra, a bevételiciklus- és számlaelőzmények elérésére, jóváhagyott SQL-futtatási környezetre, valamint a védett egészségügyi adatok kezelésére vonatkozó szervezeti engedélyre. Az igény-, remittance-, munkasor-, behajtási és lezárási előzmények elérhetősége a licencelt és bevezetett Epic-moduloktól, valamint interfészektől függ.
Példa-lekérdezés sql
WITH
service_rendered AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Service Rendered' AS ActivityName,
CAST(s.[Service rendered timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(s.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(s.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(s.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(s.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your service source table] s
ON s.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE s.[Service rendered timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND s.[Service rendered timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND [Your company code filter]
),
charges_captured AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Charges Captured' AS ActivityName,
CAST(t.[Charge captured timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(t.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(t.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(t.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(t.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN AR_PB_TRANSACTIONS t
ON t.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE t.[Charge captured timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND t.[Charge captured timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND t.[Charge transaction filter]
AND [Your company code filter]
),
claim_generated AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Generated' AS ActivityName,
CAST(c.[Claim generated timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim generated timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim generated timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim generated status filter]
AND [Your company code filter]
),
claim_submitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
CAST(c.[Claim submitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim submitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim submitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim submitted status filter]
AND [Your company code filter]
),
claim_denied AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
CAST(d.[Denial timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(d.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(d.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(d.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(d.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(d.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your denial source table] d
ON d.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE d.[Denial timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND d.[Denial timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND d.[Denial status filter]
AND [Your company code filter]
),
denial_follow_up AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
CAST(f.[Follow-up timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(f.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(f.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(f.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(f.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(f.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your follow-up source table] f
ON f.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE f.[Follow-up timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND f.[Follow-up timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND f.[Follow-up status filter]
AND [Your company code filter]
),
claim_resubmitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
CAST(c.[Claim resubmitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim resubmitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted status filter]
AND [Your company code filter]
),
payment_received AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Received' AS ActivityName,
CAST(p.[Payment received timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment received timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment received timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment received status filter]
AND [Your company code filter]
),
payment_posted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
CAST(p.[Payment posted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment posted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment posted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment posted status filter]
AND [Your company code filter]
),
account_adjustment AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
CAST(x.[Adjustment timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(x.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(x.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(x.[Adjustment reason column] AS VARCHAR(100)) AS AdjustmentReason,
CAST(x.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(x.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your adjustment source table] x
ON x.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE x.[Adjustment timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND x.[Adjustment timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND x.[Adjustment transaction filter]
AND [Your company code filter]
),
balance_collections AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
CAST(k.[Collections timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(k.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(k.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(k.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(k.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your collections source table] k
ON k.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE k.[Collections timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND k.[Collections timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND k.[Collections status filter]
AND [Your company code filter]
),
account_closed AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Closed' AS ActivityName,
CAST(z.[Account closed timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(z.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(z.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(z.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(z.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your account closure source table] z
ON z.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE z.[Account closed timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND z.[Account closed timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND z.[Account closed status filter]
AND [Your company code filter]
)
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM service_rendered
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM charges_captured
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_generated
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_submitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_denied
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM denial_follow_up
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_resubmitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_received
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_posted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_adjustment
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM balance_collections
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_closed
ORDER BY BillingEvent, EventTimestamp, ActivityName; Kezdhetjük?
A pontos adatokkal teljesebben kihasználhatja bevételiciklus-kezelési folyamatában rejlő lehetőségeket. Tegye meg az első lépést a hatékonyabb működés és a jobb pénzügyi teljesítmény felé még ma.
Javítsa a hatékonyságot: optimalizálja bevételiciklus-kezelési folyamatát most
Azonosítsa az Epic Resolute RCM-folyamatának hatékonysági problémáit, és csökkentse a ciklusidőt 30%-kal.
Nincs szükség bankkártyára, kezdje el az optimalizálást még ma.