Szablon danych do zarządzania cyklem przychodów
Szablon danych do zarządzania cyklem przychodów
- Zalecane atrybuty do zebrania
- Działania, które warto śledzić
- Wskazówki dotyczące ekstrakcji danych
Atrybuty zarządzania cyklem przychodów
| Nazwa | Opis | ||
|---|---|---|---|
| Nazwa czynności ActivityName | Nazwa konkretnego zdarzenia lub zadania wykonanego w procesie zarządzania cyklem przychodów. | ||
| Opis Ten atrybut opisuje pojedynczy etap cyklu przychodów, na przykład „Należności zarejestrowane”, „Roszczenie wysłane do płatnika” lub „Płatność otrzymana”. Każda czynność oznacza odrębny etap rozliczania usługi i pobierania za nią płatności. Analiza czynności stanowi podstawę process mining. Umożliwia wizualizację mapy procesu, identyfikację typowych ścieżek, wykrywanie wąskich gardeł między etapami i pomiar zgodności ze standardowymi procedurami. Dlaczego to ważne Określa etapy na mapie procesu, dzięki czemu można wizualizować, analizować i usprawniać przepływ pracy w cyklu przychodów. Skąd pobrać Zazwyczaj dane pochodzą z dzienników zdarzeń, ścieżek audytowych lub rejestrów zmian statusu w modułach rozliczeń i roszczeń Epic Resolute. Przykłady Należności zarejestrowaneRoszczenie wysłane do płatnikaPłatność otrzymanaKonto zamknięte | |||
| Zdarzenie rozliczeniowe BillingEvent | Unikalny identyfikator pojedynczej usługi lub dostawy produktu, za którą naliczana jest opłata. Pełni funkcję głównego identyfikatora case. | ||
| Opis Zdarzenie rozliczeniowe to główny identyfikator łączący wszystkie czynności w cyklu przychodów dotyczące konkretnej pozycji podlegającej rozliczeniu. Rozpoczyna się w chwili wykonania usługi, a kończy po pełnym uregulowaniu należności lub zamknięciu konta. W analizie process mining ten atrybut jest niezbędny do odtworzenia pełnego przebiegu każdej należności. Umożliwia śledzenie czynności, takich jak rejestrowanie należności, wysyłanie roszczeń, księgowanie płatności i obsługa odrzuceń, dla poszczególnych zdarzeń rozliczeniowych. Dzięki temu można przejrzyście analizować przebieg procesu i jego różne warianty. Dlaczego to ważne To podstawowy identyfikator case, niezbędny do powiązania wszystkich powiązanych etapów procesu i analizy pełnego cyklu generowania oraz odzyskiwania przychodów z każdej usługi. Skąd pobrać Często jest to unikalny identyfikator konta szpitalnego (HAR) lub konkretnej sesji rozliczeniowej w Epic Resolute. Szczegółowych informacji o tabelach, takich jak HAR lub rekordy Charge Session, należy szukać w dokumentacji Epic Resolute. Przykłady BE10098765BE20012345BE30054321 | |||
| Znacznik czasu zdarzenia EventTimestamp | Dokładna data i godzina wystąpienia określonej czynności lub zdarzenia. | ||
| Opis Znacznik czasu zdarzenia wskazuje moment wykonania czynności. Te dane czasowe są niezbędne do zrozumienia kolejności i czasu trwania zdarzeń w cyklu przychodów. W analizie znaczniki czasu służą do obliczania odstępów między czynnościami, na przykład opóźnienia w rejestrowaniu należności lub czasu księgowania płatności. Pomagają wykrywać wąskie gardła, mierzyć czas trwania cyklu i analizować wyniki procesu w różnych okresach. Dokładne znaczniki czasu są niezbędne do obliczania niemal wszystkich KPI i dashboardów opartych na czasie. Dlaczego to ważne Ten atrybut jest niezbędny do obliczania wszystkich miar opartych na czasie, w tym czasu trwania cyklu i poszczególnych etapów. Pomaga wykrywać opóźnienia i nieefektywności. Skąd pobrać Dane znajdują się w tabelach transakcji lub dzienników zdarzeń Epic Resolute i są powiązane z każdą zarejestrowaną czynnością. Nazwy pól często kończą się na Dt, DTTM lub Time. Przykłady 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| Dział rozliczeń BillingDepartment | Dział lub zespół funkcyjny odpowiedzialny za zdarzenie rozliczeniowe albo daną czynność. | ||
| Opis Ten atrybut wskazuje jednostkę organizacyjną, na przykład „Rozliczenia hospitalizacji”, „Rozliczenia ambulatoryjne” lub „Zespół ds. odrzuceń”, powiązaną ze zdarzeniem rozliczeniowym lub odpowiedzialną za wykonanie określonej czynności. Ten wymiar jest niezbędny w dashboardzie „Wskaźniki wyników działów rozliczeń”. Umożliwia porównywanie najważniejszych miar, takich jak odsetek odrzuceń czy czas rejestrowania należności. Pomaga kierownictwu wskazywać działy osiągające najlepsze wyniki, upowszechniać dobre praktyki i efektywnie przydzielać zasoby. Dlaczego to ważne Umożliwia porównywanie wyników różnych działów, pomaga wskazywać dobre praktyki oraz obszary wymagające usprawnień lub dodatkowych zasobów. Skąd pobrać Informacje te mogą być powiązane z rekordem użytkownika, kontem pacjenta lub lokalizacją świadczenia w Epic Resolute. Przykłady Rozliczenia kardiologiczneRCM w radiologiiCentralny dział rozliczeń | |||
| Kod przyczyny odrzucenia DenialReasonCode | Ustandaryzowany kod określający przyczynę odrzucenia wysłanego roszczenia przez płatnika. | ||
| Opis Po odrzuceniu roszczenia płatnik podaje kod przyczyny, na przykład „Usługa nieobjęta ubezpieczeniem”, „Duplikat roszczenia” lub „Wymagane dodatkowe informacje”. Kody te są często ustandaryzowane jako kody przyczyn korekty roszczenia (CARC). Ten atrybut stanowi podstawę dashboardu „Odsetek i przyczyny odrzuceń roszczeń”. Analiza częstotliwości poszczególnych kodów pomaga ustalić źródła odrzuceń, takie jak problemy z uprawnieniami, błędy w kodowaniu lub brak wymaganej wcześniejszej zgody. Dzięki temu można podejmować ukierunkowane działania naprawcze. Dlaczego to ważne Bezpośrednio wyjaśnia przyczyny odrzucania roszczeń i dostarcza informacji potrzebnych do ograniczenia liczby odrzuceń, zapobiegania stratom przychodów i przyspieszenia płatności. Skąd pobrać Dane znajdują się w transakcjach odpowiedzi na roszczenia, na przykład w pliku ANSI 835 otrzymanym od płatnika, i są przechowywane w module zarządzania roszczeniami Epic Resolute. Przykłady CO-16: Roszczenie lub usługa nie zawiera wymaganych informacjiOA-18: Duplikat roszczenia lub usługiPR-96: Opłata za usługę nieobjętą ubezpieczeniem | |||
| Przyczyna korekty AdjustmentReason | Powód ręcznej lub automatycznej korekty salda konta pacjenta. | ||
| Opis Ten atrybut wyjaśnia, dlaczego saldo konta zmieniło się z przyczyn innych niż standardowa płatność lub obciążenie. Powodem może być uzgodniona z płatnikiem korekta umowna, odpisanie niewielkiego salda lub poprawienie błędu księgowania. Atrybut jest niezbędny w dashboardzie „Liczba korekt konta według typu”. Analiza przyczyn korekt pomaga organizacjom wykrywać źródła strat przychodów, oceniać wpływ umów z płatnikami oraz identyfikować nieefektywności i błędy w procesie rozliczeń. Dlaczego to ważne Wyjaśnia przyczyny zmian sald kont, pomagając wykrywać straty przychodów i oceniać dokładność rozliczeń. Ułatwia też ograniczanie niepotrzebnych odpisów. Skąd pobrać Dane znajdują się w szczegółach transakcji korekt w module rozliczeń kont pacjentów Epic Resolute. Przykłady Korekta umownaOdpisanie niewielkiego saldaKorekta zduplikowanej należności | |||
| Rodzaj usługi ServiceType | Kategoria lub rodzaj wykonanej usługi medycznej. | ||
| Opis Ten atrybut klasyfikuje usługę podlegającą rozliczeniu, na przykład jako „Radiologia”, „Chirurgia”, „Konsultacja” lub „Wizyta na oddziale ratunkowym”. Nadaje danym finansowym kontekst kliniczny. Analiza cyklu przychodów według rodzaju usługi może ujawnić różnice w przebiegu procesu charakterystyczne dla poszczególnych obszarów klinicznych. Na przykład procedury chirurgiczne mogą wymagać bardziej złożonego rejestrowania opłat i uzyskiwania zgód niż standardowa wizyta w gabinecie, co wiąże się z innym przebiegiem procesu i odmiennymi wyzwaniami. Dlaczego to ważne Nadaje danym finansowym kontekst kliniczny i pozwala analizować, jak różne rodzaje usług medycznych wpływają na przebieg i efektywność procesu cyklu przychodów. Skąd pobrać Pochodzi z głównego pliku opisów opłat (CDM), linii usługowej lub działu powiązanego z transakcją opłaty w Epic. Przykłady Chirurgia stacjonarnaRadiologia ambulatoryjnaUsługi ratunkowe | |||
| Saldo należności OutstandingBalance | Pozostała kwota należna od płatnika lub pacjenta w ramach zdarzenia rozliczeniowego. | ||
| Opis Ten atrybut przedstawia bieżące saldo należności dla konkretnego zdarzenia rozliczeniowego w chwili wykonania danej czynności. Odzwierciedla sytuację finansową sprawy na kolejnych etapach jej obsługi. Saldo należności jest ważne przy raportowaniu finansowym i w raporcie „Wiekowanie sald należności”. Analiza wartości w czasie i według różnych wymiarów, takich jak płatnik lub dział, pomaga ustalać priorytety windykacji, zarządzać przepływami pieniężnymi i oceniać ryzyko finansowe. Dlaczego to ważne Bezpośrednio pokazuje finansowe skutki opóźnień w procesie. Pomaga ustalać priorytety windykacji, zarządzać przepływami pieniężnymi i analizować należności. Skąd pobrać To podstawowe pole rekordu konta pacjenta lub konta szpitalnego (HAR) w Epic Resolute. Przedstawia bieżące saldo aktualizowane na podstawie transakcji finansowych. Przykłady 1500.00250.750.00 | |||
| Użytkownik odpowiedzialny ResponsibleUser | Identyfikator użytkownika lub pracownika, który wykonał daną czynność. | ||
| Opis Ten atrybut zawiera identyfikator, nazwę lub numer pracownika odpowiedzialnego za wykonanie określonego zadania w cyklu przychodów. Może to być lekarz, który wprowadził należności, osoba rozliczająca, która wysłała roszczenie, lub pracownik windykacji, który podjął działania w sprawie odrzucenia. Analiza według użytkownika pomaga wskazać osoby osiągające najlepsze wyniki, określić potrzeby szkoleniowe i zrozumieć rozkład obciążenia pracą. Jest przydatna w zarządzaniu wynikami oraz badaniu odstępstw od procesu związanych z konkretnymi osobami lub rolami. Dlaczego to ważne Umożliwia analizę wyników poszczególnych osób lub ról, pomagając wykrywać potrzeby szkoleniowe, nierównomierne obciążenie pracą i wąskie gardła związane z zasobami. Skąd pobrać Dane znajdują się zwykle w ścieżkach audytowych lub dziennikach transakcji Epic Resolute i często są powiązane z tabelą danych podstawowych użytkowników, na przykład rekordem EMP. Przykłady j.doebsmith123User7890 | |||
| Całkowity czas cyklu przychodów TotalRevenueCycleTime | Łączny obliczony czas od pierwszego zdarzenia związanego z usługą do otrzymania płatności lub zamknięcia konta. | ||
| Opis To KPI na poziomie sprawy, które mierzy całkowity czas cyklu przychodów dla pojedynczego zdarzenia rozliczeniowego. Zwykle oblicza się go jako różnicę między działaniem „Usługa wykonana” a końcowym działaniem „Płatność otrzymana” lub „Konto zamknięte”. Ta miara pokazuje ogólną efektywność procesu RCM. Śledzenie KPI w czasie pozwala ocenić wpływ działań usprawniających proces i mierzyć tempo zamiany usług na gotówkę. Dlaczego to ważne Pokazuje efektywność procesu od początku do końca i mierzy czas, jaki upływa od wykonania usługi do otrzymania za nią płatności. Skąd pobrać Miara obliczana w narzędziu process mining przez wybranie pierwszego i ostatniego zdarzenia w każdej sprawie oraz obliczenie różnicy czasu. Przykłady 259200038880005184000 | |||
| Czas zakończenia zdarzenia EventEndTime | Znacznik czasu wskazujący zakończenie działania, przydatny do obliczania czasu jego trwania. | ||
| Opis Ten atrybut zapisuje czas zakończenia działania. Wiele działań to zdarzenia chwilowe, w których StartTime jest równe EndTime, ale niektóre zadania trwają określony czas, na przykład telefon w sprawie odmowy. Jeśli EndTime jest dostępne, czas przetwarzania działania można obliczyć bezpośrednio jako różnicę między „EndTime” a „StartTime”. Jest to dokładniejsze niż szacowanie czasu na podstawie rozpoczęcia kolejnego działania, ponieważ uwzględnia przerwy między krokami. Atrybut ten jest jednym z elementów potrzebnych do obliczenia „ProcessingTime”. Dlaczego to ważne Pozwala dokładnie obliczyć czas realizacji każdego działania, co pomaga wykrywać nieefektywne zadania i mierzyć produktywność zasobów. Skąd pobrać Dane te mogą być dostępne w niektórych modułach Epic Resolute, które rejestrują rozpoczęcie i zakończenie zadań, na przykład w dziennikach kolejek roboczych lub zarządzania działaniami. Często nie są jednak jawnie rejestrowane. Przykłady 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| Czy zautomatyzowane IsAutomated | Wartość logiczna wskazująca, czy działanie wykonał system lub zautomatyzowany proces. | ||
| Opis Ta flaga odróżnia zadania wykonywane automatycznie przez system, takie jak automatyczne generowanie roszczeń lub sprawdzanie uprawnień, od zadań wykonywanych ręcznie przez użytkownika. Analiza tego atrybutu pomaga określić poziom automatyzacji procesu. Można porównać efektywność i liczbę błędów w działaniach automatycznych i ręcznych, wskazać możliwości dalszej automatyzacji oraz monitorować działanie istniejących botów i reguł systemowych. Dlaczego to ważne Odróżnia działania wykonywane przez system od działań wykonywanych przez ludzi. Pomaga ocenić wpływ automatyzacji i wskazać kolejne możliwości jej zastosowania. Skąd pobrać Wartość tę często ustala się, sprawdzając, czy pole „ResponsibleUser” dla danego działania wskazuje konto systemowe lub usługowe, albo oznaczając nazwy działań, o których wiadomo, że są 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 pobrane z systemu źródłowego. | ||
| Opis Ten atrybut informuje o aktualności danych. Wskazuje, kiedy rekord został ostatnio pobrany z Epic Resolute do zbioru danych process mining. Pozwala ocenić aktualność analizy i zweryfikować dane. Użytkownicy mogą sprawdzić, czy analizują najnowsze dostępne informacje. Atrybut jest też ważny przy zarządzaniu cyklami odświeżania danych. Dlaczego to ważne Pozwala ocenić aktualność analizowanych danych, co jest niezbędne do podejmowania trafnych decyzji biznesowych na podstawie bieżących informacji. Skąd pobrać Ten znacznik czasu jest dodawany podczas pobierania danych przez proces ETL (Extract, Transform, Load). Przykłady 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| Identyfikator pacjenta PatientId | Unikalny identyfikator pacjenta, który otrzymuje usługę. | ||
| Opis Ten atrybut to numer dokumentacji medycznej (MRN) lub inny unikalny identyfikator pacjenta. Łączy zdarzenie rozliczeniowe z konkretną osobą. Ze względu na ochronę prywatności zwykle nie służy jako główny wymiar analizy, ale jest niezbędny do walidacji danych. Można go też użyć do zebrania wszystkich zdarzeń rozliczeniowych dotyczących jednego pacjenta i prześledzenia jego sytuacji finansowej. Jest również istotny przy ewentualnej integracji z danymi o procesach klinicznych. Dlaczego to ważne Łączy dane finansowe z konkretnym pacjentem, umożliwiając walidację danych i szerszą analizę całej ścieżki pacjenta. Ze względu na ochronę prywatności należy obchodzić się z tym identyfikatorem ostrożnie. Skąd pobrać Podstawowy identyfikator używany w całym systemie Epic, powiązany z rejestracją pacjenta i jego kontami. Przykłady MRN-1234567MRN-8765432MRN-5551234 | |||
| Identyfikator roszczenia ClaimId | Unikalny identyfikator przypisany do roszczenia ubezpieczeniowego przesłanego płatnikowi. | ||
| Opis Ten atrybut to identyfikator konkretnego formularza roszczenia, na przykład CMS-1500 lub UB-04, przesłanego płatnikowi. Jedno zdarzenie rozliczeniowe może obejmować kilka roszczeń, jeśli usługi są rozliczane ponownie lub składane jest odwołanie. Śledzenie według identyfikatora roszczenia przydaje się do szczegółowej analizy zgłaszania roszczeń i podprocesów zarządzania odmowami. Pozwala odróżnić działania związane z pierwotnym roszczeniem od tych dotyczących kolejnego roszczenia złożonego ponownie za tę samą usługę. Dlaczego to ważne Umożliwia szczegółowe śledzenie cyklu życia każdego zgłoszonego roszczenia, co ma znaczenie przy analizie ponownych zgłoszeń i odwołań. Skąd pobrać Identyfikator jest generowany przez moduł zarządzania roszczeniami Epic Resolute podczas tworzenia roszczenia i zapisywany w tabelach danych dotyczących roszczeń. Przykłady CLM-2023-98765CLAIM-0012345623189A4567 | |||
| Kwota korekty AdjustedAmount | Wartość pieniężna transakcji korekty. | ||
| Opis To pole zawiera dokładną kwotę korekty konta. Może być dodatnia lub ujemna i oznaczać uznanie albo obciążenie salda konta. Kwota ta jest główną miarą na dashboardzie „Wolumen korekt konta według rodzaju”. Zsumowanie jej według przyczyny korekty pokazuje wpływ finansowy poszczególnych rodzajów korekt, na przykład przychody odpisane z powodu zobowiązań umownych w porównaniu ze stratami wynikającymi z błędów, które można skorygować. Dlaczego to ważne Określa finansowy wpływ korekt konta, umożliwiając pomiar utraconych przychodów i kosztów nieprawidłowości w rozliczeniach. Skąd pobrać Znajduje się w tabelach szczegółowych transakcji finansowych w Epic Resolute i jest powiązana z transakcjami typu korekta. Przykłady -1250.45-50.0025.10 | |||
| Nazwa płatnika PayerName | Nazwa ubezpieczyciela, instytucji publicznej lub innej strony odpowiedzialnej za płatność. | ||
| Opis Ten atrybut wskazuje głównego płatnika powiązanego ze zdarzeniem rozliczeniowym, na przykład „Blue Cross Blue Shield”, „Medicare” lub „Aetna”. W przypadku płatności bezpośredniej może wskazywać pacjenta. Podział procesu według płatnika to przydatna metoda analizy. Może ujawnić, że niektórzy płatnicy częściej odrzucają roszczenia, dłużej realizują płatności lub stawiają bardziej złożone wymagania. Dzięki tym informacjom można dostosować sposób rozliczania do poszczególnych płatników, aby zwiększyć efektywność i przyspieszyć płatności. Dlaczego to ważne Umożliwia analizę wyników według płatnika, wskazując tych, którzy częściej odrzucają roszczenia lub wolniej realizują płatności. Ułatwia to planowanie ukierunkowanych działań następczych. Skąd pobrać Te informacje są częścią danych o zakresie ubezpieczenia pacjenta i są powiązane z kontem szpitalnym (HAR) w Epic Resolute. Przykłady Medicare Part BUnitedHealthcareAetna PPO | |||
| System źródłowy SourceSystem | System informatyczny, z którego pochodzą dane. | ||
| Opis Ten atrybut wskazuje system źródłowy rekordu, którym w tym przypadku jest Epic Resolute. W środowiskach z wieloma zintegrowanymi systemami pozwala rozróżniać źródła danych. W przypadku analizy danych z jednego systemu może wydawać się zbędny, ale jego stosowanie jest dobrą praktyką w zakresie zarządzania danymi i skalowalności. Pozwala zachować jasność co do pochodzenia danych, jeśli później zostaną zintegrowane informacje z innych systemów, na przykład odrębnej platformy agencji windykacyjnej. Dlaczego to ważne Zapewnia informacje o pochodzeniu danych i ich kontekst, co ułatwia ustalenie źródła. Jest to ważne dla zarządzania danymi i rozwiązywania problemów. Skąd pobrać Zazwyczaj jest to stała wartość dodawana podczas wyodrębniania i przekształcania danych, aby oznaczyć źródło zbioru danych. Przykłady Epic ResoluteEpicResolute_V2023 | |||
| Termin płatności PaymentDueDate | Data, do której oczekuje się płatności za rozliczoną usługę. | ||
| Opis Ten atrybut określa termin płatności podany na fakturze lub wynikający z umowy z płatnikiem. Służy jako punkt odniesienia przy pomiarze terminowości płatności. Termin płatności jest niezbędny do przygotowania „Raportu o zaległych saldach według wieku należności”. Porównanie bieżącej daty z terminem płatności dla otwartych sald pozwala przypisać należności do przedziałów zaległości, na przykład 0–30 dni lub 31–60 dni po terminie. Ułatwia to ustalanie priorytetów w działaniach windykacyjnych i skupienie się na najbardziej przeterminowanych kontach. Dlaczego to ważne Stanowi podstawę analizy wieku należności, która pomaga ustalać priorytety windykacji i zarządzać ryzykiem finansowym związanym z niezapłaconymi rachunkami. Skąd pobrać Ta data jest często obliczana na podstawie daty faktury i warunków płatności zapisanych w umowie z płatnikiem lub informacjach o koncie pacjenta w Epic. Przykłady 2023-05-302023-06-152023-07-01 | |||
Działania w procesie zarządzania cyklem przychodów
| Działanie | Opis | ||
|---|---|---|---|
| Konto zamknięte | To ostatnia czynność, która oznacza, że saldo zdarzenia rozliczeniowego wynosi zero i nie ma już żadnych oczekujących działań. Może to wynikać z pełnej płatności, korekt lub odpisania należności. | ||
| Dlaczego to ważne To zdarzenie oznacza pomyślne zakończenie cyklu przychodów dla danego zdarzenia rozliczeniowego. Czas od wykonania usługi do zamknięcia sprawy to istotny KPI efektywności całego procesu. Skąd pobrać Zdarzenie to zwykle ustala się pośrednio. Określa się moment, w którym saldo konta dla danego zdarzenia rozliczeniowego spada do zera i pozostaje zerowe. Rejestrowanie Ustalane przez obliczenie bieżącej sumy salda konta i znalezienie znacznika czasu ostatniej transakcji, która wyzerowała saldo. Typ zdarzenia inferred | |||
| Należności zarejestrowane | Oznacza formalne zarejestrowanie należności za wykonane usługi. W Epic jest to zwykle jawna transakcja zaksięgowana na koncie pacjenta, często generowana automatycznie na podstawie czynności klinicznych lub wprowadzana ręcznie. | ||
| Dlaczego to ważne To ważny pierwszy etap. Pomiar szybkości i dokładności rejestrowania należności pomaga przyspieszyć rozliczenia i upewnić się, że wszystkie wykonane usługi zostały ujęte w rachunku. Skąd pobrać Zdarzenie jest jawnie rejestrowane w dziennikach transakcji Resolute. Każda należność stanowi osobny wpis zawierający datę księgowania, datę usługi i kwotę. Dane te często znajdują się w tabelach takich jak ARPB_TRANSACTIONS. Rejestrowanie Pobierz transakcje księgowania należności z dziennika transakcji finansowych systemu. Typ zdarzenia explicit | |||
| Płatność otrzymana | Oznacza otrzymanie płatności od płatnika lub pacjenta. Zdarzenie jest zwykle rejestrowane po załadowaniu elektronicznego zestawienia rozliczeniowego (ERA) lub ręcznym wprowadzeniu czeku do systemu. | ||
| Dlaczego to ważne Ta czynność oznacza ważny etap, w którym zaczynają napływać przychody. Czas od wysłania roszczenia do otrzymania płatności jest istotnym miernikiem wyników w obszarze należności. Skąd pobrać Zdarzenie jest jawnie rejestrowane jako transakcja płatnicza w Resolute. Transakcje te zawierają datę, źródło i kwotę, a często są zapisywane przed przypisaniem płatności do poszczególnych należności. Rejestrowanie Pobierz transakcje płatnicze z dziennika transakcji finansowych. Często można je rozpoznać po określonych typach transakcji. Typ zdarzenia explicit | |||
| Płatność zaksięgowana na koncie | To moment przypisania otrzymanej płatności do konkretnych należności na koncie pacjenta. Ta czynność zmniejsza saldo zdarzenia rozliczeniowego. | ||
| Dlaczego to ważne Sprawne księgowanie płatności pomaga utrzymywać prawidłowe salda kont i zamykać zdarzenia rozliczeniowe. Ułatwia też ustalenie pozostałych kwot do rozliczenia wtórnego lub windykacji. Skąd pobrać To jawna transakcja w Resolute. Księgowanie płatności łączy transakcję płatniczą z jedną lub kilkoma transakcjami obciążeniowymi. Informacja ta jest zapisywana w tabelach szczegółów transakcji. Rejestrowanie Pobierz rekord transakcji przypisującej płatność do należności. Można go rozpoznać po określonych typach transakcji. Typ zdarzenia explicit | |||
| Roszczenie odrzucone przez płatnika | Oznacza otrzymanie od płatnika powiadomienia o odrzuceniu roszczenia. Zdarzenie jest rejestrowane, gdy Epic przetwarza elektroniczne zestawienie rozliczeniowe (plik 835) lub gdy użytkownik ręcznie wprowadza informację o odrzuceniu. | ||
| Dlaczego to ważne Ta czynność rozpoczyna istotną pętlę poprawek. Analiza przyczyn i liczby odrzuceń pomaga ustalić ich źródła, zwiększyć odsetek płatności przy pierwszym rozpatrzeniu i ograniczyć opóźnienia w odzyskiwaniu należności. Skąd pobrać Zdarzenie jest jawnie rejestrowane jako transakcja lub zmiana statusu roszczenia. Informacje o odrzuceniu, w tym kody przyczyn, są zwykle otrzymywane elektronicznie i zapisywane na koncie. Rejestrowanie Filtruj określone typy transakcji lub zmiany statusu roszczenia wskazujące na jego odrzucenie. Typ zdarzenia explicit | |||
| Roszczenie wysłane do płatnika | To moment oficjalnego wysłania roszczenia do ubezpieczyciela w celu rozpatrzenia. W Epic zdarzenie jest śledzone i rejestrowane podczas przesyłania elektronicznego pliku roszczenia do izby rozliczeniowej lub płatnika. | ||
| Dlaczego to ważne Ten etap jest ważny, ponieważ rozpoczyna bieg terminu płatności po stronie płatnika. Analiza pozwala ocenić sprawność przesyłania roszczeń i wspiera pomiar KPI „Czas dostarczenia faktury do płatnika”. Skąd pobrać To jawne zdarzenie rejestrowane w Resolute. Rekord roszczenia zawiera status wysłania i znacznik czasu wskazujący, kiedy zostało wysłane. Rejestrowanie Zapisz znacznik czasu zmiany statusu roszczenia na „Wysłane” lub „Przesłane”. Typ zdarzenia explicit | |||
| Usługa wykonana | Ta czynność oznacza moment, w którym pacjent otrzymuje świadczenie medyczne, co rozpoczyna zdarzenie rozliczeniowe. Informacja jest często rejestrowana w systemie Epic EHR (EpicCare), gdy lekarz zatwierdza wizytę lub zabieg. | ||
| Dlaczego to ważne To główne zdarzenie rozpoczynające cykl przychodów. Analiza czasu od tego momentu do zarejestrowania należności za usługę pomaga wykrywać opóźnienia w rozpoczęciu rozliczeń i potencjalne straty przychodów. Skąd pobrać Zdarzenie to zwykle ustala się na podstawie znaczników czasu usługi lub wizyty w modułach klinicznych powiązanych z kontem rozliczeniowym. Kluczową daną jest data usługi w transakcji obciążeniowej. Rejestrowanie Ustalane na podstawie daty usługi przypisanej do pierwszej transakcji obciążeniowej w ramach zdarzenia rozliczeniowego. Typ zdarzenia inferred | |||
| Korekta salda konta | Ta czynność oznacza transakcję inną niż płatność, która zmienia saldo konta, na przykład korektę umowną, odpisanie niewielkiego salda lub rabat uznaniowy. Jest rejestrowana jako określony typ transakcji. | ||
| Dlaczego to ważne Analiza korekt pomaga wykrywać straty przychodów. Duża liczba korekt określonego typu może wskazywać na problemy z cennikami, umowami lub wewnętrznymi zasadami. Skąd pobrać Korekty są jawnie rejestrowane w dziennikach finansowych Resolute. Każda z nich ma przypisany określony typ lub kod przyczyny. Rejestrowanie Filtruj typy transakcji odpowiadające korektom finansowym lub odpisom. Typ zdarzenia explicit | |||
| Roszczenie wygenerowane | Ta czynność oznacza utworzenie przez system formalnego roszczenia lub faktury na podstawie zarejestrowanych należności. To etap przygotowawczy przed wysłaniem roszczenia do płatnika lub pacjenta. | ||
| Dlaczego to ważne Śledzenie generowania roszczeń pomaga wykrywać opóźnienia między rejestrowaniem należności a przygotowaniem ich do wysłania. To ważny etap wewnętrzny, który może wpływać na terminowość rozliczeń. Skąd pobrać Zdarzenie jest zwykle rejestrowane podczas uruchomienia zadania wsadowego do generowania rozliczeń lub roszczeń. System zapisuje znacznik czasu utworzenia pliku roszczenia, na przykład pliku 837, dla danego konta. Rejestrowanie Znajdź wpisy w dzienniku lub zmiany statusu wskazujące, że roszczenie zostało przygotowane i jest gotowe do wysłania. Typ zdarzenia explicit | |||
| Roszczenie wysłane ponownie | To zdarzenie następuje po skorygowaniu odrzuconego roszczenia i ponownym wysłaniu go do płatnika. Jest to osobne zdarzenie wysłania powiązane z pierwotnym roszczeniem. | ||
| Dlaczego to ważne To ważny etap pętli poprawek. Pomiar czasu do ponownego wysłania i odsetka skutecznie rozpatrzonych roszczeń pozwala ocenić skuteczność procesu obsługi odrzuceń. Skąd pobrać To jawne zdarzenie podobne do pierwszego wysłania, ale często oznaczone jako ponowne wysłanie. Rekord roszczenia zawiera nowy znacznik czasu wysłania i może również zawierać kod ponownego wysłania. Rejestrowanie Zapisz znacznik czasu wysłania roszczenia oznaczonego jako korekta lub ponowne wysłanie. Typ zdarzenia explicit | |||
| Rozpoczęto działania następcze w sprawie odrzucenia | Ta czynność oznacza rozpoczęcie wewnętrznego procesu weryfikacji i rozwiązania sprawy odrzuconego roszczenia. Zdarzenie jest często rejestrowane, gdy użytkownik przejmuje odrzucone roszczenie w kolejce zadań lub zmienia jego status. | ||
| Dlaczego to ważne Śledzenie tego etapu pomaga ocenić szybkość reakcji zespołu zarządzającego odrzuceniami. Opóźnienie między odrzuceniem a rozpoczęciem działań następczych niepotrzebnie wydłuża cykl przychodów. Skąd pobrać Zdarzenie to zwykle ustala się na podstawie zmian statusu roszczenia lub historii przypisań w kolejkach zadań Epic. Na przykład status roszczenia może zmienić się z „Odrzucone” na „W trakcie weryfikacji”. Rejestrowanie Ustal zdarzenie na podstawie zmiany statusu roszczenia lub wpisu w dzienniku audytowym wskazującego, że użytkownik rozpoczął pracę nad odrzuceniem. Typ zdarzenia inferred | |||
| Saldo przekazane do windykacji | To moment przekazania nieopłaconego salda do wewnętrznego lub zewnętrznego procesu windykacji. Zdarzenie jest często rejestrowane jako jawna zmiana statusu konta lub zdarzenia rozliczeniowego. | ||
| Dlaczego to ważne Ta czynność rozpoczyna ostatni etap odzyskiwania nieopłaconych należności. Śledzenie skuteczności i czasu trwania windykacji pomaga ograniczyć nieściągalne należności. Skąd pobrać Zwykle jest to jawne zdarzenie. Epic umożliwia przekazywanie kont do agencji windykacyjnych, co powoduje zapisanie wpisu w dzienniku lub zmianę statusu konta. Rejestrowanie Znajdź zmianę statusu lub transakcję wskazującą, że konto przekazano agencji windykacyjnej. Typ zdarzenia explicit | |||
Przewodniki dotyczące ekstrakcji danych
Kroki
- Nawiąż połączenie z bazą danych: Uzyskaj dane logowania z uprawnieniami tylko do odczytu do bazy Epic Clarity. Połącz się z serwerem bazy danych za pomocą standardowego klienta SQL, takiego jak DBeaver lub Microsoft SQL Server Management Studio.
- Wskaż główne tabele: Do ekstrakcji potrzebne są przede wszystkim tabele
HSP_ACCOUNTz informacjami o sprawach,HSP_TRANSACTIONSze zdarzeniami finansowymi,CLP_CLAIM_INFOze statusem roszczeń orazF_ARHB_TX_SET_POST_HXze szczegółami księgowania płatności. Połącz je również z plikami głównymi, takimi jakCLARITY_EMP, zawierającym dane użytkowników. - Określ zakres: Przed napisaniem zapytania ustal zakres analizy. Wybierz konkretny przedział dat, zwykle od 3 do 6 miesięcy, i określ, które obszary usług szpitalnych (
SERV_AREA_ID) lub klasy kont uwzględnić albo wykluczyć. - Przygotuj zapytanie SQL: Utwórz zapytanie SQL z użyciem Common Table Expression (CTE), aby najpierw wybrać wartości
HSP_ACCOUNT_IDmieszczące się w ustalonym zakresie. Będą one stanowić zbiór bazowy zdarzeń rozliczeniowych. - Przygotuj osobne zapytania dla działań: Dla każdego z 12 wymaganych działań napisz osobną instrukcję
SELECT, która pobiera dane z odpowiednich tabel. Połącz ją z początkowym CTE, aby analizować tylko wybrane konta. - Połącz zapytania operatorem UNION ALL: Użyj operatora
UNION ALL, aby połączyć wyniki wszystkich zapytań dotyczących poszczególnych działań w jeden dziennik zdarzeń. W ten sposób wiersze z kolejnych zapytań zostaną dodane jeden pod drugim. - Dopasuj dane do standardowego schematu: W każdej instrukcji
SELECTnadaj kolumnom aliasy zgodne z wymaganym schematem ProcessMind, na przykładBillingEvent,ActivityName,EventTimestamp,ResponsibleUser. Dla atrybutów, które nie dotyczą danego działania, użyjNULL. - Uruchom zapytanie i wprowadź poprawki: Wykonaj całe zapytanie na bazie Clarity. Ze względu na rozmiar tabel może to zająć dużo czasu. Jeśli wydajność jest niewystarczająca, zawęź zakres dat lub dodaj dokładniejsze filtry w początkowym CTE.
- Sprawdź wyniki: Po zakończeniu zapytania przejrzyj pierwszych kilkaset wierszy. Sprawdź, czy są wszystkie kolumny, znaczniki czasu mają spójny format, a wartości
ActivityNamesą zgodne z oczekiwaniami. - Wyeksportuj dane do CSV: Wyeksportuj cały zestaw wyników z klienta SQL do pliku CSV. Upewnij się, że plik jest zapisany w kodowaniu UTF-8 i zawiera wiersz nagłówkowy z prawidłowymi nazwami kolumn.
- Przygotuj plik do przesłania: Przed przesłaniem do ProcessMind otwórz plik CSV i sprawdź, czy nie ma błędów formatowania. Upewnij się, że znaczniki czasu mają spójny format, na przykład
YYYY-MM-DD HH:MI:SS. Plik jest gotowy do zaimportowania.
Konfiguracja
- Połączenie z bazą danych: Wymagane jest konto użytkownika z uprawnieniami tylko do odczytu i dostępem do bazy Epic Clarity.
- Parametry zakresu dat: W zapytaniu użyto zmiennych
@StartDatei@EndDate. Należy ustawić je tak, aby określić okres analizy. Zalecany zakres to od 3 do 6 miesięcy, co pozwala zachować równowagę między ilością danych a wydajnością. - Mapowanie tabel i kolumn: Zapytanie zakłada standardowe nazwy tabel i kolumn Clarity. Konfiguracja Epic lub wersja używana w Państwa organizacji może się różnić. Może być konieczna zmiana nazw tabel i kolumn lub warunków łączenia.
- Kody transakcji i statusów: W zapytaniu znajdują się symbole zastępcze, takie jak
[Your Denial Tx Type]i[Your Collections Status Code]. Należy skonsultować się z administratorami systemu Epic lub sprawdzić odpowiednie pliki główne, takie jakZC_TX_TYPElubZC_ACCOUNT_STATUS, aby ustalić prawidłowe kody dla używanej instancji. - Filtrowanie: Aby poprawić wydajność i zawęzić analizę, dodaj filtry do początkowego CTE
BaseAccounts. Często stosuje sięSERV_AREA_ID, aby ograniczyć dane do obszaru usług szpitalnych, lubACCOUNT_CLASS_C, aby uwzględnić rozliczenia stacjonarne albo ambulatoryjne.
Przykładowe zapytanie 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; Kroki
- Sprawdź, czy dostęp do danych cyklu przychodów Epic Clarity jest autoryzowany i obejmuje tabele źródłowe oraz widoki potrzebne do analizy historii kont, opłat, roszczeń, odmów, płatności, korekt, windykacji i zamknięć. Dostępność tabel i nazewnictwo kolumn różnią się między organizacjami korzystającymi z Epic, dlatego każdy symbol zastępczy w zapytaniu należy przypisać do odpowiedniego obiektu Clarity w danym środowisku.
- Określ okres ekstrakcji za pomocą parametrów [Start date parameter] i [End date parameter]. Na początek wybierz okres od trzech do sześciu miesięcy. Wydłuż go dopiero po sprawdzeniu wydajności zapytania i kompletności zdarzeń.
- Ustal mapowanie BillingEvent. Domyślnie zapytanie używa HSP_ACCOUNT.HSP_ACCOUNT_ID jako identyfikatora sprawy, jeśli jest dostępny. Jeśli w Państwa organizacji zdarzenie rozliczeniowe jest definiowane na poziomie opłaty, roszczenia lub wizyty, zastąp to mapowanie zatwierdzonym identyfikatorem i stosuj go konsekwentnie dla wszystkich źródeł działań.
- Przypisz każdemu działaniu źródłowemu wiarygodny znacznik czasu i atrybut źródłowy. Dla działania Service Rendered użyj udokumentowanego znacznika czasu zakończenia usługi lub wizyty. Dla Charges Captured użyj znacznika czasu zaksięgowania opłaty. Dla Claim Generated i Claim Submitted to Payer użyj odpowiednich znaczników czasu z cyklu życia roszczenia. W przypadku odmów, działań następczych, ponownych zgłoszeń, płatności, korekt, windykacji i zamknięcia użyj udokumentowanych znaczników czasu transakcji lub zmiany statusu.
- Zastąp wszystkie symbole zastępcze w nawiasach kwadratowych, w tym [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] i [Your account closure source table]. Nie używaj nieudokumentowanych kodów transakcji. Wykorzystaj wartości transakcji lub statusów zatwierdzone przez zespół raportowania Epic.
- Wykonaj zapytanie w zatwierdzonym przez organizację kliencie SQL lub na platformie raportowej. Sprawdź, czy wyniki zawierają jawne wiersze dla wszystkich dwunastu etykiet działań. ProcessMind nie odtwarza brakujących zdarzeń cyklu życia na podstawie sald, statusów ani kolejności zdarzeń.
- Sprawdź schemat wyników. Zestaw danych musi zawierać BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance i ServiceType. Zachowaj informację o strefie czasowej lub czasie lokalnym przy znacznikach czasu. Jeśli jest to dozwolone, zachowaj identyfikatory źródłowe w wewnętrznym zestawieniu audytowym.
- Sprawdź kolejność chronologiczną zdarzeń w ramach każdego BillingEvent, sposób obsługi duplikatów, odsetek wartości NULL, liczbę działań oraz zgodność z raportami systemu źródłowego. Zbadaj zdarzenia spoza wybranego okresu, jeśli są potrzebne do interpretacji spraw rozpoczętych przed jego początkiem lub zakończonych po jego końcu.
- Wyeksportuj wyniki do pliku rozdzielanego separatorami lub użyj połączenia z bazą danych obsługiwanego przez ProcessMind. Zapisz jeden wiersz na zdarzenie, stosuj stałe nazwy kolumn, spójny format znaczników czasu i kodowanie UTF-8. Nie łącz komórek ani nie dodawaj sum przeznaczonych do prezentacji. Podczas przesyłania ustaw BillingEvent jako identyfikator sprawy, ActivityName jako działanie, a EventTimestamp jako znacznik czasu zdarzenia.
Konfiguracja
- Mapowanie źródeł: Implementacje Epic Clarity różnią się między organizacjami. Zastąp każdy symbol zastępczy źródła lub kolumny w nawiasach kwadratowych udokumentowaną tabelą, widokiem albo zatwierdzoną warstwą raportową w danym środowisku. Nie zakładaj, że tabela lub pole istnieje tylko dlatego, że jest często używane w innej implementacji Epic.
- Identyfikator sprawy: Domyślne mapowanie w zapytaniu wykorzystuje HSP_ACCOUNT.HSP_ACCOUNT_ID. Sprawdź, czy w Państwa organizacji BillingEvent oznacza konto, wizytę, roszczenie, opłatę czy inny zatwierdzony klucz biznesowy.
- Zakres dat: Zacznij od okresu od trzech do sześciu miesięcy. Jeśli sprawy mogą rozpocząć się przed okresem raportowania, uwzględnij wcześniejszy okres. Jeśli roszczenia, odmowy, płatności lub zamknięcia mogą nastąpić po dacie usługi, uwzględnij również późniejszy okres.
- Znaczniki czasu działań: Dla każdego działania ustaw jeden wiarygodny znacznik czasu. Nie zastępuj czasu rzeczywistego zdarzenia biznesowego czasem ekstrakcji, wczytania pliku ani bieżącego statusu, chyba że jest to udokumentowany znacznik czasu zdarzenia w systemie źródłowym.
- Filtry: Stosuj filtry [Company Code filter], [Document Type filter], [Department filter], płatnika, obszaru usług i klasy kont tylko wtedy, gdy ich definicje są udokumentowane i są potrzebne w analizie. Zachowaj te same filtry we wszystkich częściach zapytania połączonych operatorem UNION ALL.
- Mapowanie transakcji i statusów: Skonfiguruj zatwierdzone przez organizację wartości dla księgowania opłat, tworzenia i przesyłania roszczeń, odmów, działań następczych, ponownych zgłoszeń, otrzymywania i księgowania płatności, korekt, windykacji oraz zamknięć. Zapytanie celowo zawiera symbole zastępcze, ponieważ wartości transakcji i struktury źródłowe Epic różnią się między implementacjami.
- Obsługa wartości NULL: Pozostaw wartość NULL dla atrybutów, które nie dotyczą danego działania. Nie zastępuj brakujących przyczyn odmów ani korekt, użytkowników, działów czy rodzajów usług wymyślonymi wartościami.
- Wydajność: Ogranicz liczbę wierszy źródłowych za pomocą indeksowanych kolumn dat i zatwierdzonych filtrów organizacyjnych przed połączeniem z HSP_ACCOUNT. Unikaj stosowania funkcji do indeksowanych kolumn znaczników czasu w warunkach zapytania. Jeśli historia źródłowa jest duża, rozważ przygotowanie osobnego widoku raportowego dla każdego działania w zatwierdzonym środowisku.
- Usuwanie duplikatów: Nie usuwaj powielonych zdarzeń bez udokumentowanej reguły. Wiele płatności, korekt, zgłoszeń lub zmian statusu może być prawidłowymi zdarzeniami w ramach jednego BillingEvent.
- Wymagania wstępne: Dostęp może wymagać uprawnień do raportowania Epic Clarity, dostępu do danych o cyklu przychodów i historii kont, zatwierdzonego środowiska do wykonywania zapytań SQL oraz zgody organizacji na przetwarzanie chronionych informacji o stanie zdrowia. Dostępność historii roszczeń, rozliczeń płatników, kolejek roboczych, windykacji i zamknięć zależy od licencji oraz wdrożonych modułów i interfejsów Epic.
Przykładowe zapytanie 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; Gotowi do rozpoczęcia?
Dokładne dane pozwalają lepiej zarządzać procesem cyklu przychodów. Już dziś rozpocznij działania na rzecz większej efektywności i lepszych wyników finansowych.
Zwiększ efektywność: usprawnij zarządzanie cyklem przychodów
Wykryj nieefektywności RCM w Epic Resolute i skróć czas cyklu o 30%.
Nie trzeba podawać danych karty płatniczej. Już dziś rozpocznij optymalizację.