Szablon danych do zarządzania cyklem przychodów
Szablon danych do zarządzania cyklem przychodów
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Wskazówki dotyczące ekstrakcji danych z Oracle Health Revenue Cycle
Atrybuty zarządzania cyklem przychodów
| Nazwa | Opis | ||
|---|---|---|---|
| Nazwa działania ActivityName | Nazwa konkretnego kroku lub zdarzenia, które wystąpiło w procesie cyklu przychodów. | ||
| Opis Ten atrybut zapisuje nazwę każdego działania w cyklu życia zdarzenia rozliczeniowego. Przykłady to „Ujęto opłaty”, „Wysłano roszczenie do płatnika” i „Zaksięgowano płatność”. Działania te tworzą węzły na mapie procesu. Analiza kolejności i częstotliwości działań stanowi podstawę process mining. Ten atrybut pomaga wskazać najczęstsze ścieżki procesu, wykryć odstępstwa od standardowej procedury i zrozumieć przebieg operacji w cyklu przychodów. Dlaczego to ważne Określa kroki procesu, dzięki czemu można przedstawić mapę procesu i analizować wzorce workflow. Skąd pobrać Zwykle dane pochodzą z dzienników zdarzeń, zapisów zmian statusu lub tabel transakcji powiązanych z poszczególnymi etapami cyklu przychodów w Oracle Health. Przykłady Utworzono roszczenieOtrzymano rozliczenie od płatnikaZłożono odwołanie od odmowyZamknięto konto | |||
| Zdarzenie rozliczeniowe BillingEvent | Unikalny identyfikator pojedynczej usługi lub dostawy produktu, za którą naliczana jest opłata. Pełni funkcję identyfikatora sprawy w procesie cyklu przychodów. | ||
| Opis Billing Event jest głównym identyfikatorem sprawy. Łączy wszystkie działania, od ujęcia opłaty po zamknięcie konta, dla konkretnej pozycji podlegającej rozliczeniu. Każdy Billing Event oznacza odrębny przebieg procesu cyklu przychodów, który można śledzić na kolejnych etapach, takich jak wysłanie roszczenia, zaksięgowanie płatności oraz ewentualne odmowy lub korekty. W analizie process mining ten atrybut jest podstawą odtworzenia procesu od początku do końca. Umożliwia wizualizację wariantów procesu, obliczanie czasu między działaniami oraz wykrywanie wąskich gardeł i odstępstw dotyczących konkretnych pozycji rozliczeniowych. Dlaczego to ważne To niezbędny identyfikator do śledzenia całego cyklu życia usługi podlegającej rozliczeniu. Umożliwia analizę przebiegu procesu i pomiar jego wyników. Skąd pobrać Ten identyfikator powinien być unikalnym kluczem w głównych tabelach rozliczeń lub transakcji opłat w Oracle Health Revenue Cycle. W dokumentacji systemu należy sprawdzić, który klucz główny identyfikuje zdarzenia dotyczące opłat. Przykłady BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| Znacznik czasu zdarzenia EventTimestamp | Dokładna data i godzina zarejestrowania działania w systemie. | ||
| Opis Ten atrybut zawiera znacznik czasu każdego działania i wskazuje dokładny moment jego wystąpienia. Jest niezbędny do ustalenia czasu i kolejności zdarzeń w cyklu przychodów dla konkretnego zdarzenia rozliczeniowego. W analizie znacznik czasu zdarzenia służy do chronologicznego porządkowania działań, obliczania czasu trwania i czasu cyklu między krokami oraz wykrywania wąskich gardeł. Stanowi podstawę wszystkich czasowych miar process mining, na przykład analizy opóźnień między „Wysłano roszczenie” a „Otrzymano rozliczenie od płatnika”. Dlaczego to ważne Ten znacznik czasu jest niezbędny do porządkowania zdarzeń, obliczania miar efektywności, takich jak czas cyklu i czas trwania, oraz wykrywania wąskich gardeł procesu. Skąd pobrać Każda tabela transakcji lub dziennika zdarzeń w Oracle Health Revenue Cycle powinna zawierać kolumnę ze znacznikiem czasu utworzenia rekordu lub wystąpienia zdarzenia. Przykłady 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| Dział rozliczeń BillingDepartment | Dział lub zespół funkcyjny odpowiedzialny za dane działanie. | ||
| Opis Ten atrybut wskazuje dział, na przykład „Ujmowanie opłat”, „Kodowanie” lub „Windykacja”, który wykonał dane działanie. Określa kontekst organizacyjny przebiegu procesu. Analiza procesu z perspektywy działów pomaga zrozumieć przekazywanie zadań między zespołami i wykryć nieefektywności na styku różnych funkcji. Umożliwia też agregowanie działań i miar efektywności według działu na dashboardzie „Obciążenie działu rozliczeń”. Dlaczego to ważne Przypisuje działania do jednostek organizacyjnych, co ułatwia analizę przekazywania zadań między działami, obciążenia pracą i wyników zespołów. Skąd pobrać Informacje te mogą być zapisane bezpośrednio w danych profilu użytkownika w Oracle Health albo wywnioskowane na podstawie użytkownika lub rodzaju działania. Przykłady Obsługa pacjentaKodowanieRozliczeniaWindykacja | |||
| Klasa pacjenta PatientClass | Klasyfikacja wizyty pacjenta, na przykład jako hospitalizacji lub wizyty ambulatoryjnej. | ||
| Opis Ten atrybut określa rodzaj wizyty pacjenta, w ramach której naliczono opłatę. Typowe klasyfikacje to hospitalizacja, wizyta ambulatoryjna, wizyta na oddziale ratunkowym i wizyty powtarzające się. Klasa pacjenta często wyznacza cały przebieg rozliczenia i wysyłania roszczeń. Dla różnych klas pacjentów obowiązują odrębne ścieżki procesu i wymagania dotyczące zgodności. Analiza procesu według tego atrybutu pomaga zrozumieć te różnice, dopasować działania usprawniające i upewnić się, że dla każdej klasy stosowane są właściwe procedury. Dlaczego to ważne Rozdziela różne przebiegi procesu, na przykład hospitalizację i wizytę ambulatoryjną, które różnią się złożonością, czasem trwania i wymaganiami rozliczeniowymi. Skąd pobrać To standardowe pole powiązane z wizytą pacjenta lub rekordem przyjęcia w Oracle Health. Przykłady HospitalizacjaWizyta ambulatoryjnaNagłyCykliczny | |||
| Kod przyczyny odmowy DenialReasonCode | Ustandaryzowany kod określający przyczynę odrzucenia roszczenia przez płatnika. | ||
| Opis Gdy płatnik odrzuca roszczenie, podaje kod przyczyny, na przykład „Usługa nieobjęta ubezpieczeniem” lub „Duplikat roszczenia”. Ten atrybut przechowuje kod wraz z opisem. Analiza przyczyn odmów jest niezbędna do usprawniania cyklu przychodów. Pozwala wykrywać powtarzające się problemy, takie jak błędy w kodowaniu lub nieprawidłowe dane o uprawnieniach pacjenta, i podejmować działania naprawcze, aby zapobiegać kolejnym odmowom. Wpływa to bezpośrednio na odsetek roszczeń poprawnych przy pierwszym zgłoszeniu i ogranicza koszty ponownej pracy. Dlaczego to ważne Wskazuje przyczyny odrzucenia roszczeń, co pozwala wprowadzać ukierunkowane usprawnienia, zwiększać odsetek poprawnych zgłoszeń i przyspieszać odzyskiwanie należności. Skąd pobrać Informacje te są przekazywane przez płatnika w elektronicznym zestawieniu płatności (plik ANSI 835) i powinny być przechowywane w tabelach roszczeń lub zestawień płatności w Oracle Health. Przykłady CO-16: Roszczenie lub usługa nie zawiera informacji niezbędnych do rozpatrzenia.PR-96: Opłata za usługę nieobjętą ubezpieczeniem.CO-18: Duplikat roszczenia lub usługi. | |||
| Kwota korekty AdjustmentAmount | Wartość pieniężna korekt salda konta. | ||
| Opis Ten atrybut rejestruje kwotę korekty finansowej, na przykład uzgodnionej ulgi, odpisu lub sprostowania, zastosowanej do zdarzenia rozliczeniowego. Korekty bezpośrednio zmniejszają oczekiwany przychód z obciążenia. Dashboard „Wpływ korekt na konto” w dużej mierze opiera się na tym atrybucie. Analiza kwot korekt i powiązanych z nimi przyczyn pomaga wykrywać źródła utraconych przychodów, problemy z zarządzaniem umowami oraz błędy przy pierwotnym rejestrowaniu obciążeń. To ważny miernik kondycji finansowej. Dlaczego to ważne Pozwala określić skalę utraconych przychodów z powodu odpisów lub sprostowań, a tym samym wykrywać i usuwać przyczyny pogorszenia wyników finansowych. Skąd pobrać Dane znajdują się w tabelach transakcji finansowych, w których rejestrowane są korekty i odpisy na koncie pacjenta. Przykłady -50.25-120.0025.00 | |||
| Nazwa płatnika PayerName | Nazwa ubezpieczyciela lub innego płatnika odpowiedzialnego za płatność. | ||
| Opis Ten atrybut wskazuje podmiot, na przykład ubezpieczyciela lub program rządowy taki jak Medicare, któremu przedstawiono usługę do rozliczenia. Informacje o płatniku są podstawą analizy cyklu przychodów. Analiza procesu według płatnika może ujawnić istotne różnice w czasie płatności, odsetku odmów i skuteczności odwołań. Pomaga wskazać płatników powodujących opóźnienia lub utratę przychodów. Jest też niezbędna do skutecznego zarządzania umowami i relacjami z płatnikami. Dlaczego to ważne Umożliwia podział procesu według płatnika i ujawnia różnice w sposobie działania, odsetku odmów i szybkości płatności, które wpływają na wyniki finansowe. Skąd pobrać Informacje te są zapisane w dokumentacji rozliczeniowej lub ubezpieczeniowej pacjenta w Oracle Health Revenue Cycle. Przykłady AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| Saldo do zapłaty OutstandingBalance | Pozostała nieopłacona kwota zdarzenia rozliczeniowego w danym momencie. | ||
| Opis Ten atrybut pokazuje aktualną kwotę należną z tytułu zdarzenia rozliczeniowego po uwzględnieniu wszystkich płatności i korekt. Określa bieżącą należność z tytułu danego obciążenia. To ważny atrybut dla dashboardu „Wiekowanie salda do zapłaty”. Analiza tej wartości w czasie pomaga monitorować przepływy pieniężne, oceniać skuteczność windykacji oraz obliczać istotne KPI finansowe, takie jak Days Sales Outstanding (DSO). Dlaczego to ważne Śledzi bieżące należności dla każdej sprawy, co pomaga zarządzać przepływami pieniężnymi i oceniać skuteczność windykacji. Skąd pobrać Wartość tę zwykle oblicza się jako sumę wszystkich transakcji finansowych (obciążeń, płatności i korekt) dotyczących danego zdarzenia rozliczeniowego. Może być też zapisana w tabeli podsumowującej konto. Przykłady 75.000.00550.80 | |||
| Użytkownik UserPerformingAction | Identyfikator lub nazwa użytkownika, który wykonał działanie. | ||
| Opis Ten atrybut wskazuje pracownika lub użytkownika systemowego odpowiedzialnego za wykonanie konkretnego działania w procesie. Ma znaczenie przy analizie rozkładu pracy i efektywności zasobów oraz przy określaniu potrzeb szkoleniowych. W analizie pozwala filtrować mapę procesu według użytkownika lub zespołu, porównywać wyniki różnych osób i zespołów oraz analizować obciążenie na dashboardzie „Obciążenie działu rozliczeń”. Pomaga wskazać osoby osiągające najlepsze wyniki oraz te, które mogą potrzebować dodatkowego wsparcia lub szkolenia. Dlaczego to ważne Łączy działania w procesie z konkretnymi użytkownikami lub zespołami. Umożliwia analizę obciążenia pracą i porównanie wyników, a także wskazanie potrzeb szkoleniowych. Skąd pobrać Pola identyfikatora użytkownika, na przykład „CREATED_BY” i „USER_ID”, zwykle występują w tabelach transakcji w różnych modułach Oracle Health. Przykłady j.doeasmithBillingBot_AUTOk.williams | |||
| Czas zakończenia zdarzenia EventEndTime | Znacznik czasu zakończenia działania, jeśli jest dostępny. | ||
| Opis StartTime oznacza początek działania, a EventEndTime jego zakończenie. Nie każde działanie ma określony czas zakończenia, ponieważ wiele zdarzeń jest chwilowych. To pole jest jednak przydatne w przypadku działań trwających dłużej, takich jak „Złożono odwołanie od odmowy”, którego obsługa może zająć trochę czasu. Atrybut ten pozwala dokładniej obliczyć czas realizacji poszczególnych działań. Ułatwia odróżnienie czasu oczekiwania, czyli przerwy między działaniami, od czasu przetwarzania, czyli czasu poświęconego na dane działanie. Dlaczego to ważne Umożliwia bezpośrednie obliczenie czasu potrzebnego na wykonanie działania i oddzielenie czasu przetwarzania od czasu oczekiwania. Skąd pobrać Niektóre tabele transakcji w Oracle Health Revenue Cycle mogą zawierać znaczniki czasu rozpoczęcia i zakończenia określonych, długotrwałych zadań. Przykłady 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| Czy ponowna praca IsRework | Flaga wskazująca czynności wymagające ponownej pracy lub powtórzenia. | ||
| Opis Ten obliczany atrybut oznacza czynności, które odbiegają od idealnego przebiegu procesu i wymagają ponownej pracy. Przykłady to „Wysłano skorygowane roszczenie” lub „Złożono odwołanie od odmowy”. Nie wystąpiłyby, gdyby proces przebiegł prawidłowo za pierwszym razem. Wykrywanie i mierzenie ponownej pracy to jeden z celów process mining. Ta flaga ułatwia filtrowanie i analizowanie wszystkich pętli poprawek, a także pomiar ich częstotliwości, kosztów i przyczyn nieefektywności procesu. Pomaga określić rzeczywisty koszt jakości w cyklu przychodów. Dlaczego to ważne Pomaga mierzyć częstotliwość i wpływ pętli poprawek, wskazując nieefektywność procesu i koszty niskiej jakości. Skąd pobrać To atrybut pochodny. Jest obliczany podczas transformacji danych na podstawie reguł biznesowych, które oznaczają wybrane nazwy czynności jako wymagające ponownej pracy. Przykłady truefalse | |||
| Czy zautomatyzowane IsAutomated | Flaga wskazująca, czy czynność wykonał system automatyczny, czy użytkownik. | ||
| Opis Ten atrybut logiczny rozróżnia czynności wykonywane przez automatyzację programową, na przykład boty lub zadania wsadowe systemu, od czynności wykonywanych ręcznie przez użytkownika. Przykładowo „Utworzenie roszczenia” może być krokiem automatycznym, a „Odwołanie od odmowy” prawdopodobnie wymaga pracy ręcznej. Analiza tego atrybutu pomaga określić poziom automatyzacji procesu oraz jej wpływ na wydajność i liczbę błędów. Można porównać wyniki ścieżek automatycznych i ręcznych oraz wskazać kolejne możliwości automatyzacji. Dlaczego to ważne Rozróżnia czynności wykonywane przez ludzi i systemy, co pozwala oceniać skuteczność automatyzacji i wskazywać kolejne możliwości jej zastosowania. Skąd pobrać Wartość tę zwykle wyznacza się na podstawie atrybutu UserPerformingAction. Czynności wykonane przez identyfikatory użytkowników takie jak „SYSTEM” lub „RPA_BOT” są oznaczane jako zautomatyzowane. Przykłady truefalse | |||
| Data ostatniej aktualizacji danych LastDataUpdate | Znacznik czasu wskazujący, kiedy dane dotyczące tego zdarzenia zostały ostatnio odświeżone lub wyodrębnione. | ||
| Opis Ten atrybut wskazuje, kiedy zbiór danych został ostatnio zaktualizowany. Informuje, jak aktualne są analizowane dane, co pomaga ocenić aktualność wniosków z analizy process mining. Można sprawdzić ten atrybut, aby potwierdzić, że wyświetlane informacje o procesie są aktualne. Ułatwia ocenę wieku danych i stanowi ważny element zarządzania danymi oraz zapewniania ich jakości. Dlaczego to ważne Informuje o aktualności danych, dzięki czemu analizę i decyzje można opierać na bieżących informacjach. Skąd pobrać To pole metadanych jest zwykle generowane i uzupełniane podczas procesu ETL, który ładuje dane do platformy process mining. Przykłady 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Identyfikator pacjenta PatientId | Unikalny identyfikator pacjenta powiązanego ze zdarzeniem rozliczeniowym. | ||
| Opis Ten atrybut zawiera unikalny identyfikator pacjenta, który otrzymał usługę, często określany jako numer dokumentacji medycznej (MRN). Łączy transakcję finansową z konkretną osobą. Identyfikator pacjenta nie jest identyfikatorem sprawy w procesie, ale pozwala zestawić wszystkie zdarzenia rozliczeniowe dotyczące jednej osoby i przeanalizować całą historię jej rozliczeń. Po połączeniu z głównymi danymi pacjentów umożliwia też segmentację według danych demograficznych lub historii pacjenta. Dlaczego to ważne Łączy zdarzenia finansowe z konkretnym pacjentem, umożliwiając analizę z perspektywy pacjenta i zestawienie wszystkich jego rozliczeń. Skąd pobrać Ten identyfikator jest podstawowym elementem głównego rekordu pacjenta i występuje we wszystkich powiązanych tabelach transakcji, takich jak obciążenia, roszczenia i płatności. Przykłady MRN-1002345MRN-1002346MRN-1002347 | |||
| Identyfikator roszczenia ClaimId | Unikalny identyfikator roszczenia ubezpieczeniowego przekazanego płatnikowi. | ||
| Opis Ten atrybut zawiera unikalny identyfikator roszczenia utworzonego i wysłanego do płatnika w celu uzyskania zwrotu kosztów. Jedno zdarzenie rozliczeniowe może w trakcie obsługi wygenerować jedno lub więcej roszczeń, na przykład gdy konieczne jest wprowadzenie korekty. Identyfikator roszczenia pozwala śledzić konkretne zgłoszenie przekazane płatnikowi i powiązać je bezpośrednio z odpowiedzią, taką jak płatność lub odmowa. Umożliwia dokładniejsze śledzenie poszczególnych etapów w ramach całego procesu cyklu przychodów. Dlaczego to ważne Umożliwia śledzenie konkretnego roszczenia u płatnika, z większą dokładnością niż w przypadku całego zdarzenia rozliczeniowego. Skąd pobrać Identyfikator jest generowany przez Oracle Health podczas tworzenia roszczenia i zapisywany w głównej tabeli roszczeń. Przykłady CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| Kwota obciążenia ChargeAmount | Wartość brutto usługi lub produktu objętego rozliczeniem. | ||
| Opis Ten atrybut określa początkową kwotę naliczoną za usługę, przed uwzględnieniem rabatów, uzgodnionych korekt i płatności. To początkowa wartość finansowa zdarzenia rozliczeniowego. Śledzenie kwoty obciążenia jest niezbędne do analiz finansowych, takich jak obliczanie łącznej wartości wykonanych usług i ocena wpływu późniejszych korekt lub odpisów. Kwota ta stanowi punkt odniesienia przy pomiarze uzyskanych przychodów. Dlaczego to ważne Określa początkową wartość finansową sprawy, niezbędną do dalszych analiz finansowych i oceny wpływu. Skąd pobrać W Oracle Health znajduje się w tabelach szczegółów obciążeń lub transakcji obciążeniowych. Przykłady 150.001250.7585.50 | |||
| Przyczyna zakwestionowania DisputeReason | Powód podany przez klienta lub pacjenta, który kwestionuje fakturę lub naliczoną opłatę. | ||
| Opis Ten atrybut określa, dlaczego pacjent lub inna osoba odpowiedzialna za płatność zakwestionowała rachunek. Przyczyną mogą być nieprawidłowe opłaty, niewykonana usługa lub problemy z rozliczeniem ubezpieczenia. Informacje te są niezbędne dla dashboardu „Wskaźniki rozpatrywania sporów dotyczących faktur”. Wiedza o najczęstszych przyczynach sporów pomaga wykrywać problemy systemowe w rejestrowaniu obciążeń, kodowaniu lub rozliczeniach. Usunięcie ich źródeł może znacznie ograniczyć liczbę sporów i nakład pracy administracyjnej potrzebny do ich rozpatrzenia. Dlaczego to ważne Wyjaśnia, dlaczego faktury są kwestionowane, i wskazuje problemy z poprawnością lub przejrzystością rozliczeń, które wymagają rozwiązania. Skąd pobrać Informacje te są prawdopodobnie przechowywane w module zarządzania sprawami lub obsługi klienta w Oracle Health i powiązane z kontem pacjenta. Przykłady Nieprawidłowo rozliczona usługaPodwójnie naliczona opłataNieprawidłowe rozliczenie ubezpieczeniaUsługa niewykonana | |||
| System źródłowy SourceSystem | System, z którego wyodrębniono dane o zdarzeniach. | ||
| Opis Ten atrybut wskazuje aplikację źródłową lub moduł, z którego pochodzą dane. W tym procesie będzie to zwykle „Oracle Health Revenue Cycle”, ale może też wskazywać różne moduły systemu, jeśli dane pochodzą z kilku źródeł. Informacja ta przydaje się w zarządzaniu danymi i rozwiązywaniu problemów. Pomaga potwierdzić pochodzenie danych i ma znaczenie w środowiskach, w których kilka systemów obsługuje jeden proces od początku do końca. Dlaczego to ważne Wskazuje pochodzenie danych, co ma znaczenie przy ich weryfikacji i zarządzaniu nimi oraz przy analizie różnic w procesie zależnych od systemu. Skąd pobrać Często jest to stała wartość dodawana podczas ekstrakcji, transformacji i ładowania danych (ETL), aby oznaczyć źródło zbioru danych. Przykłady OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
Działania w procesie zarządzania cyklem przychodów
| Działanie | Opis | ||
|---|---|---|---|
| Utworzono roszczenie | Oznacza połączenie poszczególnych opłat w formalne roszczenie rozliczeniowe, takie jak UB-04 lub CMS-1500. To zdarzenie generowane przez system, które tworzy pierwszą fakturę. | ||
| Dlaczego to ważne To ważny etap, który oznacza gotowość do rozliczenia z płatnikiem. Jest punktem końcowym pomiaru wewnętrznego opóźnienia między ujęciem opłaty a rozliczeniem. Skąd pobrać Jawne zdarzenie zapisane w dziennikach lub tabelach generowania roszczeń. Należy szukać znacznika czasu utworzenia głównego rekordu roszczenia powiązanego z wizytą. Rejestrowanie Zdarzenie rejestrowane podczas tworzenia rekordu roszczenia. Typ zdarzenia explicit | |||
| Utworzono wizytę pacjenta | Oznacza utworzenie konta pacjenta dla konkretnej wizyty lub usługi. Zwykle jest to jawne zdarzenie wywoływane przez system rejestracji lub komunikat Admit/Discharge/Transfer (ADT). | ||
| Dlaczego to ważne To początek całego cyklu przychodów dla danego zdarzenia rozliczeniowego. Umożliwia analizę łącznego czasu procesu i poprawności rejestracji. Skąd pobrać Dane pochodzą z dzienników modułu Patient Registration lub ADT. Należy szukać zdarzeń utworzenia wizyty albo najwcześniejszego znacznika czasu powiązanego z wizytą lub numerem finansowym. Rejestrowanie Zdarzenie rejestrowane podczas rejestracji lub przyjęcia pacjenta. Typ zdarzenia explicit | |||
| Wysłano roszczenie do płatnika | Oznacza elektroniczne lub papierowe przekazanie wygenerowanego roszczenia do ubezpieczyciela lub innego płatnika. System powinien zapisywać datę i godzinę wysłania. | ||
| Dlaczego to ważne To działanie rozpoczyna cykl płatności. Analiza czasu od wysłania roszczenia do otrzymania płatności pomaga ocenić sprawność płatnika i wskaźnik DSO. Skąd pobrać Dane pochodzą z modułu zarządzania roszczeniami, który rejestruje zdarzenia transmisji. W historii roszczenia należy szukać znacznika czasu wysłania lub zmiany statusu na „Submitted”. Rejestrowanie Zdarzenie rejestrowane po pomyślnym przesłaniu roszczenia przez izbę rozliczeniową. Typ zdarzenia explicit | |||
| Zaksięgowano płatność | Oznacza przypisanie płatności otrzymanej od płatnika do odpowiednich opłat na koncie pacjenta. Jest to transakcja finansowa rejestrowana przez użytkownika lub proces automatyczny. | ||
| Dlaczego to ważne Sprawność księgowania płatności wpływa na poprawność należności. Opóźnienia na tym etapie mogą zniekształcić obraz finansowy i opóźnić rozliczenia wtórne. Skąd pobrać Informacje znajdują się w tabelach transakcji płatniczych. Każde zaksięgowanie płatności ma unikalny identyfikator transakcji i powiązany znacznik czasu. Rejestrowanie Transakcja finansowa jest rejestrowana w chwili przypisania płatności do konta. Typ zdarzenia explicit | |||
| Zamknięto konto | Ostatnie działanie, oznaczające zerowe saldo konta i brak oczekiwanych dalszych operacji. Często można je wywnioskować z osiągnięcia zerowego salda. | ||
| Dlaczego to ważne Oznacza pomyślne zakończenie cyklu przychodów. Czas potrzebny na osiągnięcie tego stanu jest ważną miarą ogólnej sprawności procesu. Skąd pobrać Zdarzenie zwykle można wywnioskować, ustalając, kiedy saldo należności po raz pierwszy spadło do zera i pozostało zerowe po zaksięgowaniu wszystkich płatności i korekt. Rejestrowanie Obliczane, gdy saldo konta po raz pierwszy osiąga zero po zaksięgowaniu wszystkich opłat i płatności. Typ zdarzenia calculated | |||
| Otrzymano odmowę płatności | Oznacza odrzucenie przez płatnika roszczenia lub konkretnych pozycji, wskazane w informacji o rozliczeniu. Zdarzenie często można wywnioskować z kodów odmowy zawartych w danych rozliczeniowych. | ||
| Dlaczego to ważne Śledzenie odmów jest niezbędne do ustalenia ich przyczyn, takich jak błędy kodowania lub problemy z uprawnieniami, oraz do poprawy odsetka roszczeń przyjmowanych bez zastrzeżeń. Skąd pobrać Zdarzenie można wywnioskować z danych rozliczeniowych ERA/835. Jest wyzwalane, gdy kwota odmowy dla roszczenia lub pozycji jest większa od zera i podano odpowiadający jej kod przyczyny odmowy. Rejestrowanie Zdarzenie można wywnioskować z danych rozliczeniowych zawierających kody przyczyn odmowy (CARCs/RARCs). Typ zdarzenia inferred | |||
| Otrzymano rozliczenie od płatnika | Oznacza otrzymanie elektronicznego Electronic Remittance Advice (ERA) lub papierowego Explanation of Benefits (EOB) od płatnika. Dokument zawiera informacje o opłatach opłaconych, odrzuconych lub skorygowanych. | ||
| Dlaczego to ważne To pierwsza odpowiedź płatnika. Ma zasadnicze znaczenie dla oceny szybkości płatności i wczesnego wykrywania trendów w odmowach. Skąd pobrać Zdarzenie jest rejestrowane w module przetwarzania rozliczeń. Należy szukać znacznika czasu importu lub utworzenia pliku ERA, na przykład pliku transakcji 835 powiązanego z roszczeniem. Rejestrowanie Zdarzenie rejestrowane po zaimportowaniu i przetworzeniu pliku rozliczeniowego płatnika, na przykład ANSI 835. Typ zdarzenia explicit | |||
| Rozpoczęto windykację | Oznacza przekazanie konta pacjenta do windykacji z powodu braku płatności. Zwykle jest to rejestrowane jako zmiana klasy finansowej lub statusu konta. | ||
| Dlaczego to ważne To ważny etap zarządzania należnościami nieściągalnymi. Ustalenie, co prowadzi do tego etapu i jak często windykacja kończy się powodzeniem, ma duże znaczenie dla kondycji finansowej. Skąd pobrać Zdarzenie można wywnioskować ze zmiany pola statusu konta na „Collections” lub „Bad Debt”. Zmiana statusu powinna mieć przypisany znacznik czasu. Rejestrowanie Zdarzenie można wywnioskować ze zmiany statusu konta na „Collections” lub podobny. Typ zdarzenia inferred | |||
| Skorygowano konto | Oznacza korektę salda konta, na przykład uzgodnioną obniżkę, odpis lub rabat. Każda korekta jest odrębną transakcją finansową. | ||
| Dlaczego to ważne Korekty bezpośrednio wpływają na przychody. Analiza ich częstotliwości, rodzaju i kwoty pomaga wykryć utratę przychodów i nieprawidłowości w rozliczeniach. Skąd pobrać Informacje znajdują się w tabelach transakcji finansowych. Każda korekta jest rejestrowana jako osobna pozycja z określonym kodem transakcji i znacznikiem czasu. Rejestrowanie Transakcja finansowa jest rejestrowana z określonym kodem korekty. Typ zdarzenia explicit | |||
| Ujęto opłaty | Oznacza wprowadzenie do konta pacjenta usług lub pozycji podlegających rozliczeniu. Może się to odbywać automatycznie w systemach klinicznych albo ręcznie, przez personel. | ||
| Dlaczego to ważne To działanie ma zasadnicze znaczenie przy pomiarze opóźnienia w ujęciu opłat, czyli czasu między wykonaniem usługi a rozpoczęciem rozliczenia. Wpływa ono bezpośrednio na przepływy pieniężne i rzetelność rozliczeń przychodów. Skąd pobrać Dane pochodzą z tabel transakcji opłat. Zdarzenie można rozpoznać po znaczniku czasu utworzenia każdej pozycji opłaty. W Oracle Health informacje te często znajdują się w tabelach związanych z opłatami. Rejestrowanie Dla każdej nowej opłaty tworzony jest wpis w dzienniku transakcji. Typ zdarzenia explicit | |||
| Wysłano skorygowane roszczenie | Oznacza wysłanie do płatnika zmienionego lub skorygowanego roszczenia, często po odmowie lub prośbie o dodatkowe informacje. Można je rozpoznać po nowym zgłoszeniu roszczenia z oznaczeniem korekty. | ||
| Dlaczego to ważne To ważny etap ponownej obsługi sprawy po odmowie. Częste występowanie tego działania wskazuje na problemy z poprawnością pierwotnych roszczeń. Skąd pobrać Dane pochodzą z dzienników wysyłania roszczeń. Należy szukać nowego zgłoszenia dla istniejącej wizyty, często oznaczonego kodem ponownego zgłoszenia lub wyższym numerem iteracji. Rejestrowanie Zarejestrowane zdarzenie ponownego wysłania roszczenia, często rozpoznawalne po określonym kodzie częstotliwości zgłoszenia. Typ zdarzenia explicit | |||
| Wysłano zestawienie pacjentowi | Oznacza wygenerowanie i wysłanie pacjentowi rachunku za pozostałą do zapłaty kwotę. Jest to jawne działanie rejestrowane przez moduł rozliczeń pacjentów. | ||
| Dlaczego to ważne To początek części cyklu przychodów związanej z płatnością pacjenta. Śledzenie tego etapu pomaga ocenić skuteczność odzyskiwania należności od pacjentów. Skąd pobrać Dane pochodzą z dzienników rozliczeń pacjentów lub korespondencji. System powinien zapisywać datę wygenerowania lub wysłania każdego zestawienia. Rejestrowanie Zdarzenie rejestrowane po wygenerowaniu zestawienia pacjenta i jego wydrukowaniu lub wysłaniu elektronicznym. Typ zdarzenia explicit | |||
| Zakodowano opłaty | Oznacza przypisanie przez koderów medycznych standardowych kodów, takich jak CPT lub ICD-10, do ujętych opłat. Zdarzenie jest często rejestrowane jako zmiana statusu opłaty lub wizyty. | ||
| Dlaczego to ważne Opóźnienia w kodowaniu często tworzą wąskie gardło. Śledzenie tego działania pomaga wykryć nieefektywności w workflow kodowania i ocenić ich wpływ na terminy rozliczeń. Skąd pobrać Zdarzenie często można wywnioskować ze zmiany statusu wizyty pacjenta lub partii opłat, na przykład z „Uncoded” na „Coded”. Potrzebny jest znacznik czasu tej zmiany. Rejestrowanie Zdarzenie można wywnioskować ze zmiany statusu wizyty lub opłaty na „Coded” albo „Ready for Billing”. Typ zdarzenia inferred | |||
| Złożono odwołanie od odmowy | Działanie użytkownika lub systemu wskazujące, że od odmowy roszczenia składane jest odwołanie. Zwykle jest rejestrowane jako zmiana statusu lub zadanie utworzone w kolejce zadań. | ||
| Dlaczego to ważne To działanie rozpoczyna ponowną obsługę sprawy. Analiza częstotliwości odwołań i ich skuteczności ma duże znaczenie dla usprawnienia odzyskiwania przychodów. Skąd pobrać Może to być jawne zdarzenie zainicjowane przez użytkownika albo zdarzenie wywnioskowane ze zmiany statusu roszczenia, na przykład na „Appealed” lub „In Review”. Rejestrowanie Zmiana statusu lub zarejestrowane zdarzenie wskazujące, że użytkownik rozpoczął procedurę odwoławczą od odmowy roszczenia. Typ zdarzenia explicit | |||
Instrukcje ekstrakcji danych
Kroki
- Uzyskajcie dostęp do bazy danych: Zdobądźcie dane logowania z uprawnieniami tylko do odczytu do bazy Oracle Health Revenue Cycle. Potrzebny będzie dostęp do schematów zawierających dane pacjentów, wizyt, rozliczeń i transakcji finansowych. Zwykle wymaga to zgody zespołów ds. bezpieczeństwa IT i administracji baz danych.
- Ustalcie nazwy schematów i tabel: Wspólnie z administratorem bazy danych lub analitykiem systemowym potwierdźcie dokładne nazwy schematów i tabel w używanej instancji Oracle Health. Nazwy podane w zapytaniu są przykładowymi symbolami zastępczymi i trzeba je dopasować do konkretnego środowiska.
- Zainstalujcie klienta SQL: Zainstalujcie na komputerze zgodnego klienta SQL, na przykład Oracle SQL Developer lub DBeaver. Będzie on służył do łączenia się z bazą danych i uruchamiania skryptu ekstrakcji.
- Nawiążcie połączenie z bazą danych: Skonfigurujcie nowe połączenie w kliencie SQL, podając host, port, nazwę usługi i dane logowania. Przetestujcie połączenie, aby upewnić się, że działa.
- Dostosujcie zapytanie SQL: Skopiujcie dostarczony skrypt SQL do nowego okna edytora zapytań. Znajdźcie symbole zastępcze, takie jak
[START_DATE]i[END_DATE], i zastąpcie je wybranym zakresem dat (np. '2023-01-01'). Dostosujcie warunki filtrowania do potrzeb analizy, na przykład ograniczając dane do określonej klasy pacjentów. - Uruchomcie skrypt ekstrakcji: Wykonajcie dostosowany skrypt SQL. Zapytanie obejmuje szeroki zakres danych, dlatego jego wykonanie może potrwać od kilku minut do kilku godzin, zależnie od zakresu dat i wielkości bazy.
- Sprawdźcie wstępne wyniki: Po zakończeniu zapytania przejrzyjcie kilkaset pierwszych wierszy w tabeli wyników klienta SQL. Sprawdźcie, czy nie ma oczywistych błędów, takich jak kolumny zawierające wyłącznie wartości null lub nieprawidłowe formaty danych.
- Wyeksportujcie dane do CSV: Wyeksportujcie cały zestaw wyników do pliku CSV. Użyjcie kodowania UTF-8, aby uniknąć problemów z zapisem znaków. Upewnijcie się, że plik zawiera wiersz nagłówkowy z nazwami kolumn określonymi w aliasach zapytania, na przykład „BillingEvent” i „ActivityName”.
- Przygotujcie plik do przesłania: Przed przesłaniem pliku do narzędzia process mining otwórzcie go i sprawdźcie, czy jest poprawny. Upewnijcie się, że znaczniki czasu mają spójny format, a nagłówki kolumn dokładnie odpowiadają wymaganym atrybutom. Plik jest gotowy do przesłania.
Konfiguracja
- Zakres dat: W zapytaniu użyto symboli zastępczych
[START_DATE]i[END_DATE]. Należy określić konkretny, rozsądny zakres dat, aby kontrolować ilość danych. Do wstępnej analizy zaleca się zakres 3–6 miesięcy. - Filtrowanie: Wstępny zestaw danych jest filtrowany według daty rejestracji wizyty (
reg_dt_tm) w sekcjiRelevantEncounters. Można dodać inne klauzuleWHERE, aby zawęzić zakres, na przykłade.patient_class_code IN ('INPATIENT', 'OUTPATIENT'), jeśli analiza ma obejmować określone typy wizyt. - Wydajność: Bezpośrednie odpytywanie produkcyjnej bazy danych może obniżyć wydajność systemu. Zaleca się uruchamianie ekstrakcji poza godzinami szczytu lub korzystanie z repliki produkcyjnej bazy danych przeznaczonej tylko do odczytu, jeśli jest dostępna.
- Wymagania wstępne: Ta metoda wymaga konta użytkownika bazy danych z uprawnieniami
SELECTdo wszystkich tabel użytych w zapytaniu. Są to tabele dotyczące wizyt, rozliczeń, opłat, roszczeń, rozliczeń płatności i transakcji finansowych. - Mapowanie tabel i kolumn: Skrypt zawiera przykładowe, często spotykane nazwy tabel i kolumn. Należy sprawdzić, jakie nazwy obowiązują w schemacie bazy Oracle Health w Państwa organizacji, i odpowiednio je przypisać. Na przykład tabela
FINANCIAL_TRANSACTIONmoże w używanym systemie nazywać sięAR_TRANSACTIONS.
Przykładowe zapytanie 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; Gotowi do rozpoczęcia?
Skorzystajcie z tego szablonu, aby odpowiednio przygotować dane. Zacznijcie usprawniać proces zarządzania cyklem przychodów już dziś.
Usprawnijcie cykl przychodów, aby szybciej otrzymywać płatności
Usuńcie wąskie gardła, skróćcie czas cyklu o 30% i poprawcie przepływ środków.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.