Szablon danych do analizy zarządzania cyklem przychodów
Szablon danych do analizy zarządzania cyklem przychodów
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia podczas odkrywania procesu
- Szczegółowe wskazówki dotyczące pobierania danych z R1 RCM
Atrybuty zarządzania cyklem przychodów
| Nazwa | Opis | ||
|---|---|---|---|
| Czas zdarzenia EventTime | Znacznik czasu wskazujący, kiedy miało miejsce konkretne działanie lub zdarzenie. | ||
| Opis Czas zdarzenia określa dokładną datę i godzinę zarejestrowania działania w systemie. Te informacje są niezbędne do analizy procesu pod kątem czasu. W process mining znacznik czasu służy do chronologicznego uporządkowania zdarzeń i obliczania czasu między działaniami, co ma zasadnicze znaczenie dla analizy wyników. Pozwala obliczać takie wskaźniki jak czas cyklu, czas przetwarzania i czas oczekiwania. Ułatwia to wykrywanie wąskich gardeł i pomiar efektywności. Dlaczego to ważne Ten znacznik czasu stanowi podstawę wszystkich analiz czasowych, w tym obliczania czasu cyklu, wykrywania wąskich gardeł i monitorowania wyników procesu względem SLA. Skąd pobrać W R1 RCM pole to występuje zwykle pod nazwą „Creation Date”, „Timestamp” lub „Last Update Date” i jest powiązane z każdą transakcją albo zapisem zmiany statusu. Przykłady 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z | |||
| Nazwa działania ActivityName | Nazwa konkretnego zdarzenia biznesowego lub zadania, które miało miejsce w określonym momencie cyklu przychodów. | ||
| Opis Ten atrybut opisuje pojedynczy krok lub etap procesu zarządzania cyklem przychodów dla danego zdarzenia rozliczeniowego. Działania pokazują, jakie prace wykonano, na przykład „Zarejestrowano opłaty”, „Wysłano roszczenie” lub „Zaksięgowano płatność”. Analiza kolejności działań stanowi podstawę process mining. Pozwala odkryć rzeczywisty przebieg procesu, wskazać wąskie gardła, w których rozpoczęcie działań trwa zbyt długo, oraz wykryć pętle poprawek, czyli niepotrzebnie powtarzane czynności, na przykład gdy po odmowie roszczenia rozpoczyna się jego ponowna obsługa. Dlaczego to ważne Atrybut określa kroki procesu, dzięki czemu można zwizualizować mapę procesu, obliczyć czas przejścia między etapami oraz wykryć odstępstwa i poprawki. Skąd pobrać Informacje te pochodzą zwykle z dzienników zdarzeń, zapisów zmian statusu lub kodów transakcji w różnych modułach R1 RCM. Kody techniczne mogą wymagać przypisania do nazw zrozumiałych dla użytkowników biznesowych. Przykłady Opłaty zarejestrowaneRoszczenie wysłaneOdpowiedź płatnika na roszczenie otrzymanaPłatność zaksięgowanaKonto zamknięte | |||
| Zdarzenie rozliczeniowe BillingEvent | Unikalny identyfikator pojedynczej usługi lub pozycji podlegającej rozliczeniu. Służy jako główny identyfikator sprawy, który pozwala śledzić cały cykl przychodów. | ||
| Opis Identyfikator zdarzenia rozliczeniowego (Billing Event ID) oznacza konkretne świadczenie usługi lub dostarczenie produktu, za które naliczono opłatę. Łączy wszystkie powiązane działania: od wykonania usługi i zarejestrowania opłaty, przez wysłanie roszczenia i zaksięgowanie płatności, aż po zamknięcie konta. W process mining analiza cyklu życia każdego zdarzenia rozliczeniowego pozwala zobaczyć cały cykl przychodów. Umożliwia prześledzenie pojedynczej opłaty, wykrycie typowych ścieżek, pomiar czasu między ważnymi etapami oraz zrozumienie przyczyn opóźnień i utraty przychodów. Dlaczego to ważne Ten identyfikator pozwala połączyć wszystkie powiązane działania w jedną sprawę i przeprowadzić pełną, rzetelną analizę procesu rozliczania każdego zdarzenia podlegającego rozliczeniu. Skąd pobrać To klucz główny łączący różne tabele dotyczące wizyt pacjentów, opłat, roszczeń i płatności. Informacje o konkretnym polu można znaleźć w dokumentacji R1 RCM. Często jest ono powiązane z identyfikatorem wizyty lub roszczenia. Przykłady BE-2023-0012345BE-2023-0054321BE-2024-0098765 | |||
| Data ostatniej aktualizacji danych LastDataUpdate | Znacznik czasu ostatniego odświeżenia danych lub ich pobrania z systemu źródłowego. | ||
| Opis Ten atrybut wskazuje, kiedy ostatnio zaktualizowano dane wykorzystywane w analizie process mining. Informuje o ich aktualności. Jest to ważne w raportach i dashboardach, ponieważ pokazuje, jak aktualne są analizowane dane o procesie. Pozwala właściwie ocenić ich aktualność i podejmować decyzje ze świadomością, jakiego okresu dotyczą. Dlaczego to ważne Informuje o aktualności danych, dzięki czemu analitycy i interesariusze wiedzą, jak świeże są wnioski dotyczące procesu. Skąd pobrać Ten znacznik czasu jest generowany podczas procesu ekstrakcji, transformacji i ładowania danych (ETL) i zwykle dotyczy całego zbioru danych. Przykłady 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| System źródłowy SourceSystem | System, z którego pobrano dane o zdarzeniach. | ||
| Opis Ten atrybut wskazuje aplikację lub moduł źródłowy, w którym wygenerowano dane dotyczące danego zdarzenia. W złożonym środowisku ochrony zdrowia dane mogą pochodzić z systemu EMR, modułu rozliczeniowego, izby rozliczeniowej roszczeń lub platformy windykacyjnej. Znajomość systemu źródłowego jest ważna przy weryfikacji danych i analizie różnic w przebiegu procesu, które mogą wynikać z użycia konkretnych systemów. Pomaga też wyjaśniać niespójności danych i zrozumieć środowisko technologiczne procesu. Dlaczego to ważne Wskazuje źródło danych, co ma znaczenie dla zarządzania danymi, ich weryfikacji oraz zrozumienia, jak poszczególne systemy współdziałają w całym procesie. Skąd pobrać Często jest to stała wartość dodawana podczas pobierania danych, która wskazuje system źródłowy, na przykład „R1 RCM”. Przykłady R1 RCMCernerEpic | |||
| Dział rozliczeń BillingDepartment | Dział lub zespół funkcyjny odpowiedzialny za wykonanie działania. | ||
| Opis Ten atrybut wskazuje jednostkę organizacyjną, na przykład „Rejestrowanie opłat”, „Wysyłanie roszczeń” lub „Obsługa odmów”, która wykonała dany krok procesu. Pomaga zrozumieć, jak praca jest przekazywana między zespołami. Ma to znaczenie przy analizie przepustowości działów i wykrywaniu wąskich gardeł na styku różnych funkcji. Filtrowanie mapy procesu według działu pozwala sprawdzić, gdzie przekazywanie pracy przebiega sprawnie, a gdzie pojawiają się opóźnienia. Ułatwia też planowanie zasobów i usprawnianie procesów w organizacji. Dlaczego to ważne Umożliwia analizę wyników procesu według jednostek organizacyjnych i pomaga wykrywać wąskie gardła, ograniczenia zasobów oraz dobre praktyki w poszczególnych zespołach. Skąd pobrać Informacje te można pobrać z profilu użytkownika w R1 RCM lub z pola „Department Code” w danych transakcyjnych. Przykłady Rejestrowanie opłatZarządzanie roszczeniamiOdmowy i odwołaniaKsięgowanie płatności | |||
| Kod przyczyny odmowy roszczenia DenialReasonCode | Ustandaryzowany kod płatnika wyjaśniający przyczynę odmowy roszczenia. | ||
| Opis Gdy płatnik odrzuca roszczenie, podaje kod przyczyny, na przykład CARC (Claim Adjustment Reason Code), który wyjaśnia decyzję. Kody są ustandaryzowane i wskazują między innymi, że usługa nie jest objęta ubezpieczeniem lub że roszczenie zostało złożone ponownie. Ten atrybut ma duże znaczenie dla obsługi odmów. Analiza częstotliwości poszczególnych kodów pozwala wykrywać i usuwać źródła odmów, takie jak brak uprawnień pacjenta, błędy kodowania lub brak uzasadnienia medycznego. Wspiera to ograniczanie poprawek i przyspiesza przepływ środków. Dlaczego to ważne Wskazuje konkretną przyczynę odmowy roszczenia. Umożliwia analizę źródeł problemu, ograniczenie kolejnych odmów i poprawek oraz zwiększenie odsetka płatności przy pierwszym rozpatrzeniu. Skąd pobrać Informacje te są przekazywane przez płatnika w elektronicznym zestawieniu płatności (ERA lub pliku 835) i przechowywane w module zarządzania roszczeniami R1 RCM. Przykłady CO-16: W roszczeniu lub opisie usługi brakuje informacji potrzebnych do rozpatrzenia.PR-97: Świadczenie za tę usługę jest uwzględnione w płatności lub dopuszczalnej kwocie za inną usługę.CO-22: Zgodnie z zasadami koordynacji świadczeń za tę opiekę może odpowiadać inny płatnik.OA-18: Dokładnie takie samo roszczenie lub usługa zostały zgłoszone wcześniej. | |||
| Kwota faktury InvoiceAmount | Łączna wartość opłat ujętych na fakturze lub w roszczeniu. | ||
| Opis Ten atrybut określa łączną kwotę naliczoną za usługi w ramach danego zdarzenia rozliczeniowego. Pokazuje przychód oczekiwany z tytułu roszczenia. Analiza kwoty faktury ma duże znaczenie w finansowym process mining. Pozwala ustalać priorytety dla roszczeń o wysokiej wartości, oceniać finansowe skutki opóźnień i odmów oraz dzielić proces według wartości. Analiza może na przykład wykazać, że roszczenia przekraczające określoną kwotę przebiegają inną, bardziej manualną ścieżką. Dlaczego to ważne Pokazuje finansowy kontekst procesu, pozwala ocenić wpływ różnic w jego przebiegu na przychody i ustalać priorytety dla spraw o wysokiej wartości. Skąd pobrać W R1 RCM pole to znajduje się w głównej tabeli roszczeń lub nagłówków faktur. Często nosi nazwę „TotalBilledAmount” lub podobną. Przykłady 150.002500.7585.5012000.00 | |||
| Nazwa płatnika PayerName | Nazwa firmy ubezpieczeniowej, instytucji publicznej lub pacjenta odpowiedzialnego za płatność. | ||
| Opis Ten atrybut wskazuje głównego płatnika roszczenia. Może to być komercyjny ubezpieczyciel, taki jak Aetna, publiczny płatnik, taki jak Medicare, albo sam pacjent w przypadku płatności z własnej kieszeni. Analiza procesu według płatnika ma podstawowe znaczenie dla zarządzania cyklem przychodów. Może wykazać, że niektórzy płatnicy częściej odrzucają roszczenia, dłużej realizują płatności lub wymagają bardziej złożonej dokumentacji. Dzięki tym informacjom organizacja może dostosować procesy i zasoby do wymagań poszczególnych płatników. Dlaczego to ważne Pozwala podzielić proces według płatnika i wykryć charakterystyczne dla niego opóźnienia, przyczyny odmów oraz sposób realizacji płatności. Ułatwia to usprawnianie procesu i ochronę przychodów. Skąd pobrać W R1 RCM informacje te znajdują się w danych ubezpieczeniowych lub demograficznych pacjenta powiązanych z roszczeniem. Przykłady MedicareUnitedHealthcareBlue Cross Blue ShieldAetnaPłatność z własnej kieszeni | |||
| Przypisany użytkownik AssignedUser | Identyfikator lub imię i nazwisko pracownika, który wykonał dane działanie. | ||
| Opis Ten atrybut wskazuje osobę odpowiedzialną za wykonanie konkretnego zadania w procesie. Może to być pracownik działu rozliczeń, który utworzył roszczenie, analityk ponownie obsługujący odmowę lub specjalista księgujący płatność. Analiza według użytkownika pomaga ocenić rozkład obciążenia pracą, indywidualne wyniki i potrzeby szkoleniowe. Może wskazać osoby pracujące najsprawniej lub te, których działania częściej wiążą się z błędami. Ułatwia to lepsze zarządzanie i ukierunkowane ulepszanie procesów. Dlaczego to ważne Umożliwia analizę wyników zespołów i poszczególnych osób oraz rozkładu obciążenia pracą. Pomaga też wskazać potrzeby szkoleniowe i odstępstwa od procesu związane z konkretnymi użytkownikami. Skąd pobrać W dziennikach transakcji R1 RCM pole to występuje zwykle pod nazwą „UserID”, „Processor” lub „UpdatedBy”. Przykłady jdoeasmithp.jonesBOT_RPA01 | |||
| Status faktury InvoiceStatus | Bieżący status faktury lub roszczenia w cyklu życia. | ||
| Opis Ten atrybut wskazuje ostatni znany stan zdarzenia rozliczeniowego, na przykład „Wysłano”, „Opłacono”, „Odrzucono” lub „W windykacji”. Pokazuje, na jakim etapie procesu znajduje się faktura w danym momencie. Status faktury jest ważny przy tworzeniu raportów wiekowania należności i monitorowaniu stanu należności. W process mining można go użyć do filtrowania spraw, które utknęły na danym etapie, lub porównywania wyników różnych wariantów procesu, na przykład ścieżek roszczeń opłaconych i odrzuconych. Dlaczego to ważne Pokazuje bieżący stan każdej sprawy. Jest niezbędny do tworzenia raportów wiekowania należności i analizy wyników poszczególnych ścieżek procesu. Skąd pobrać W R1 RCM jest to zwykle pole statusu w głównym rekordzie roszczenia lub konta. Przykłady Oczekuje na wysłanieWysłano do płatnikaOdrzuconoOpłacono w całościW windykacji | |||
| Czas od wykonania usługi do płatności ServiceToPaymentCycleTime | Łączny obliczony czas od wykonania usługi do zaksięgowania końcowej płatności. | ||
| Opis Ten wskaźnik mierzy całkowity czas cyklu przychodów dla pojedynczego zdarzenia rozliczeniowego. Pokazuje, ile czasu zajmuje organizacji zamiana wykonanej usługi na środki pieniężne. To ważny KPI obrazujący kondycję finansową. Analiza czasu trwania cyklu pomaga wskazać obszary, w których można przyspieszyć proces. Podział czasu na etapy, takie jak „czas do wystawienia rachunku” i „czas do otrzymania płatności”, pozwala określić, gdzie usprawnienia mogą najbardziej poprawić przepływ środków. Dlaczego to ważne Ten KPI mierzy ogólną sprawność cyklu konwersji gotówki, który bezpośrednio wpływa na przepływy pieniężne organizacji. Skąd pobrać Jest to wskaźnik obliczany jako różnica czasu między znacznikiem czasu działania „Wykonano usługę” a działaniem „Zaksięgowano płatność” dla danego zdarzenia rozliczeniowego. Przykłady 35 dni 8 godzin92 dni 4 godziny15 dni 12 godzin | |||
| Czy poprawka IsRework | Obliczana flaga wskazująca działania należące do pętli poprawek, na przykład ponowne wysłanie odrzuconego roszczenia. | ||
| Opis Ten atrybut logiczny jest zwykle obliczany podczas analizy process mining. Przyjmuje wartość „true”, jeśli działanie powtarza wcześniejszy krok lub należy do sekwencji wskazującej na poprawianie błędu, na przykład gdy następuje po odmowie roszczenia. Wykrywanie poprawek to jedna z ważnych możliwości process mining. Pozwala określić, ile czasu, pracy i zasobów pochłaniają zbędne czynności. Oznaczenie poprawek pomaga skupić działania usprawniające na zapobieganiu błędom, które je powodują, i zwiększać efektywność procesu. Dlaczego to ważne Pomaga określić częstotliwość i skutki poprawek, na przykład po odmowie roszczenia. Umożliwia ukierunkowaną analizę, która pozwala ograniczyć nieefektywność i zbędną pracę. Skąd pobrać To pole nie występuje w systemie źródłowym. Oblicza je narzędzie process mining na podstawie kolejności działań, na przykład wykrywając, że działanie „Wysłano roszczenie” wystąpiło więcej niż raz w tej samej sprawie. Przykłady truefalse | |||
| Czy zautomatyzowane IsAutomated | Flaga wskazująca, czy działanie wykonał system automatyczny, czy użytkownik. | ||
| Opis Ten atrybut logiczny odróżnia zadania wykonywane przez oprogramowanie, na przykład bota RPA wysyłającego roszczenia, od zadań wykonywanych ręcznie przez pracownika. Analiza tego atrybutu pozwala ocenić wpływ i skuteczność automatyzacji. Umożliwia porównanie szybkości, kosztów i liczby błędów w procesach zautomatyzowanych i ręcznych. Pomaga też wskazywać kolejne możliwości automatyzacji i mierzyć zwrot z inwestycji w istniejące boty. Dlaczego to ważne Odróżnia działania wykonywane przez ludzi od działań systemowych. Jest to niezbędne do oceny wpływu automatyzacji na efektywność, koszty i jakość procesu. Skąd pobrać Informacje można uzyskać z pola „AssignedUser”, jeśli określone identyfikatory użytkowników są zarezerwowane dla botów, na przykład „BOT_RPA01”. Niektóre systemy mają też osobne pole oznaczające transakcje zautomatyzowane. Przykłady truefalse | |||
| Identyfikator pacjenta PatientId | Unikalny identyfikator pacjenta, któremu udzielono świadczenia. | ||
| Opis Ten atrybut to unikalny identyfikator pacjenta w systemie ochrony zdrowia, często nazywany numerem dokumentacji medycznej (MRN). Analiza nie dotyczy opieki nad poszczególnymi pacjentami, ale identyfikator pacjenta pozwala wykrywać powtarzające się problemy z rozliczeniami w kolejnych okresach. W połączeniu z innymi danymi o pacjencie może też służyć do analizy procesu według danych demograficznych lub historii pacjenta i ujawniać problemy systemowe dotyczące określonych grup. Dlaczego to ważne Umożliwia analizę zdarzeń rozliczeniowych na poziomie pacjenta i pomaga wykrywać powtarzające się problemy lub wzorce w wielu wizytach. Skąd pobrać Ten identyfikator jest podstawowym elementem danych demograficznych pacjenta i jest powiązany z każdą wizytą oraz roszczeniem w R1 RCM. Przykłady MRN837262MRN937281MRN103847 | |||
| Kod usługi ServiceCode | Kod rozliczeniowy konkretnej usługi lub procedury, na przykład kod CPT lub HCPCS. | ||
| Opis Kody usług, takie jak CPT (Current Procedural Terminology), to ustandaryzowane kody medyczne używane do zgłaszania płatnikom procedur i usług medycznych, chirurgicznych oraz diagnostycznych w celu uzyskania refundacji. Analiza procesu według kodu usługi pomaga wykrywać problemy rozliczeniowe związane z konkretnymi rodzajami świadczeń. Może wskazać procedury najczęściej kończące się odmową, mające najdłuższy czas oczekiwania na płatność lub wymagające najwięcej poprawek. Ułatwia to ukierunkowane usprawnianie kodowania i rozliczeń. Dlaczego to ważne Umożliwia analizę procesu według rodzaju udzielonego świadczenia. Pomaga wykrywać przyczyny odmów i opóźnień płatności związane z konkretnymi procedurami. Skąd pobrać W R1 RCM informacje te znajdują się na poziomie pojedynczej pozycji opłaty lub roszczenia. Przykłady 992139928573560 | |||
| Kwota korekty AdjustmentAmount | Wartość pieniężna korekty salda konta. | ||
| Opis Ten atrybut określa wartość korekt finansowych wprowadzonych na koncie pacjenta po wystawieniu pierwotnego rachunku. Korekty mogą być dodatnie lub ujemne i obejmują między innymi uzgodnione obniżki, odpisy oraz korekty błędów. Śledzenie kwot korekt ma duże znaczenie dla kontroli prawidłowości rozliczeń przychodów. Wysokie ujemne korekty mogą wskazywać na utratę przychodów spowodowaną na przykład błędnym rejestrowaniem opłat lub nieściągalnym długiem. Analiza tych danych pomaga ocenić finansowe skutki błędów rozliczeniowych i nieskutecznej windykacji. Dlaczego to ważne Pozwala określić skalę utraty przychodów i korekt finansowych oraz wskazać skutki błędów rozliczeniowych, zobowiązań umownych i nieściągalnych należności. Skąd pobrać W R1 RCM informacje te znajdują się w dziennikach transakcji dotyczących korekt kont lub księgowania płatności. Przykłady -50.2520.00-1200.00 | |||
| Przyczyna korekty AdjustmentReason | Powód korekty finansowej, na przykład „Uzgodniona obniżka” lub „Odpis nieściągalnego długu”. | ||
| Opis Ten atrybut wyjaśnia, dlaczego wprowadzono korektę finansową na koncie. Przyczyny są zwykle opisywane za pomocą ustandaryzowanych kodów lub kategorii. Analiza przyczyn korekt pomaga ustalić źródła utraty przychodów. Częste odpisy niewielkich sald mogą na przykład wskazywać, że windykacja małych kwot jest nieefektywna, natomiast częste uzgodnione obniżki są zwykle przewidywalnym skutkiem negocjacji z płatnikami. Analiza ta wspiera dashboard „Audyt korekt rozliczeniowych i zgodności”. Dlaczego to ważne Wyjaśnia przyczyny korekt przychodów i pomaga wykrywać źródła strat, takie jak problemy umowne, błędy rozliczeniowe lub nieskuteczna windykacja. Skąd pobrać W R1 RCM jest to zwykle pole tekstowe lub kod w tym samym rekordzie transakcji co AdjustmentAmount. Przykłady Uzgodniona obniżkaOdpisano nieściągalny długOdpis niewielkiego saldaKorekta błędu rozliczeniowego | |||
| Wynik windykacji CollectionOutcome | Końcowy wynik działań windykacyjnych dotyczących zaległego salda. | ||
| Opis Ten atrybut opisuje wynik działań podjętych w celu odzyskania należności z zaległego konta. Możliwe wyniki to między innymi „Opłacono w całości”, „Uzgodniono niższą kwotę”, „Przekazano do obsługi nieściągalnego długu” lub „Nie rozwiązano sprawy”. Śledzenie wyników windykacji pozwala ocenić skuteczność tego procesu. Analiza działań prowadzących do poszczególnych wyników pomaga usprawniać strategie windykacyjne, zwiększać odzyskiwane kwoty i podejmować świadome decyzje o zakończeniu windykacji oraz odpisaniu salda. Wspiera to dashboard „Skuteczność działań windykacyjnych”. Dlaczego to ważne Mierzy skuteczność windykacji, pokazując końcowy wynik obsługi zaległych kont. Pomaga usprawniać strategie odzyskiwania należności. Skąd pobrać Jest to prawdopodobnie pole statusu na koncie pacjenta lub w dedykowanym module windykacyjnym R1 RCM. Przykłady Opłacono w całościUzgodniono niższą kwotęPrzekazano do zewnętrznej agencjiOdpisano jako nieściągalny dług | |||
Działania w procesie zarządzania cyklem przychodów
| Działanie | Opis | ||
|---|---|---|---|
| Konto zamknięte | Zdarzenie rozliczeniowe zostało w pełni rozliczone, saldo wynosi zero, a konto formalnie zamknięto. Oznacza to pomyślne zakończenie cyklu przychodów dla danej wizyty. | ||
| Dlaczego to ważne To podstawowe zdarzenie kończące prawidłowy przebieg procesu. Pomiar czasu zamknięcia konta pomaga sprawdzić, czy zadania administracyjne są wykonywane sprawnie, a dokumentacja finalizowana. Skąd pobrać Zdarzenie ustala się, gdy saldo konta osiąga zero i zostaje nadany końcowy status „Zamknięte” lub „Opłacone w całości”. Znacznik czasu pochodzi z ostatniej transakcji finansowej, która wyzerowała saldo. Rejestrowanie Ustalane, gdy saldo konta wynosi zero, nadano status „Zamknięte” i zarejestrowano znacznik czasu ostatniej czynności. Typ zdarzenia inferred | |||
| Opłaty zarejestrowane | Ta czynność oznacza formalne zarejestrowanie wszystkich usług, procedur i materiałów podlegających rozliczeniu w ramach wizyty pacjenta. To ważny etap wprowadzania danych, który przekształca czynności kliniczne w transakcje finansowe. | ||
| Dlaczego to ważne Oznacza przekazanie sprawy z obszaru klinicznego do finansowego. Rozpoczyna pomiar czasu tworzenia faktur i roszczeń oraz pomaga wykryć zaległości w rejestrowaniu opłat. Skąd pobrać Zdarzenie jest rejestrowane w module wprowadzania opłat w R1 RCM lub przekazywane przez interfejs z systemu EHR. Zwykle oznacza je wpis w dzienniku transakcji albo znacznik czasu utworzenia rekordu opłaty. Rejestrowanie Ustalane na podstawie znacznika czasu utworzenia rekordu transakcji opłaty w tabeli rozliczeń. Typ zdarzenia explicit | |||
| Płatność otrzymana | Płatność otrzymana od płatnika lub pacjenta. Zdarzenie oznacza wpływ środków, które nie zostały jeszcze przypisane do konkretnego konta lub pozycji usługi. | ||
| Dlaczego to ważne Oznacza wpływ środków pieniężnych. Odstęp między otrzymaniem a zaksięgowaniem płatności jest ważnym miernikiem efektywności zaplecza administracyjnego i opóźnień w uzgadnianiu środków. Skąd pobrać Zdarzenie jest rejestrowane na podstawie elektronicznych zestawień płatności od płatników lub podczas przetwarzania płatności pacjentów. Odpowiada dacie wpłaty lub otrzymania pliku. Rejestrowanie Rejestrowane na podstawie daty wejścia w życie płatności w pliku ERA lub daty transakcji płatności pacjenta. Typ zdarzenia explicit | |||
| Płatność zaksięgowana | Otrzymana płatność zostaje formalnie przypisana do konta pacjenta, zmniejszając saldo należności. To końcowy etap uzgadniania płatności z rozliczonymi usługami. | ||
| Dlaczego to ważne Ta czynność wyznacza koniec okresu mierzonego dla czasu od wykonania usługi do płatności oraz czasu księgowania płatności. Potwierdza rozpoznanie przychodu i aktualizację kont. Skąd pobrać Zdarzenie jest rejestrowane jako osobna transakcja finansowa w module rozliczeń pacjentów R1 RCM. Każde księgowanie zawiera datę, kwotę i źródło płatności. Rejestrowanie Rejestrowane jako osobna transakcja z datą księgowania, gdy użytkownik lub zautomatyzowany proces przypisuje płatność. Typ zdarzenia explicit | |||
| Roszczenie wysłane | Wygenerowane roszczenie jest przesyłane elektronicznie do odpowiedniego płatnika, na przykład firmy ubezpieczeniowej. To pierwsza zewnętrzna komunikacja w procesie rozliczeniowym, której celem jest uzyskanie zwrotu kosztów. | ||
| Dlaczego to ważne To ważny etap, od którego liczy się czas oczekiwania na zwrot kosztów od płatnika. Monitorowanie tego zdarzenia pomaga kontrolować zaległości w wysyłce i dotrzymywać terminów składania roszczeń. Skąd pobrać Zdarzenie jest rejestrowane jako osobna transakcja w chwili przesłania roszczenia do izby rozliczeniowej. System zapisuje znacznik czasu wysyłki i dane potwierdzenia. Rejestrowanie Rejestrowane jako osobna transakcja ze znacznikiem czasu wysyłki, gdy roszczenie jest przesyłane przez izbę rozliczeniową. Typ zdarzenia explicit | |||
| Usługa wykonana | Oznacza moment zakończenia usługi lub procedury podlegającej rozliczeniu na rzecz pacjenta. Zdarzenie jest często rejestrowane w systemie klinicznym lub systemie planowania wizyt i rozpoczyna cykl przychodów. | ||
| Dlaczego to ważne To początek pomiaru KPI czasu od wykonania usługi do płatności. Analiza czasu od tego zdarzenia pomaga wykryć opóźnienia na początkowych etapach cyklu przychodów. Skąd pobrać Dane pochodzą zwykle z elektronicznej dokumentacji medycznej (EHR) lub systemu zarządzania placówką zintegrowanego z R1 RCM. Zdarzenie często ustala się na podstawie znacznika czasu pola „Data usługi” lub „Zakończenie procedury” w dokumentacji pacjenta. Rejestrowanie Ustalane na podstawie znacznika czasu „Data usługi” powiązanego z wizytą pacjenta. Typ zdarzenia inferred | |||
| Konto przekazane do kategorii nieściągalnych należności | Wyczerpano wszystkie działania windykacyjne, a pozostałe saldo uznano za nieściągalne. Kwota zostaje odpisana jako nieściągalna należność, co oznacza ostateczną utratę przychodu. | ||
| Dlaczego to ważne To niekorzystny wynik procesu i bezpośrednia utrata przychodu. Analiza spraw zakończonych uznaniem należności za nieściągalną może ujawnić wzorce braku płatności i możliwości usprawnienia windykacji. Skąd pobrać Zwykle jest to osobna transakcja w R1 RCM, w ramach której nieuregulowane saldo zostaje przeniesione do określonej kategorii nieściągalnych należności. Może ją zainicjować użytkownik lub automatyczne reguły dotyczące wieku należności. Rejestrowanie Rejestrowane jako osobna transakcja finansowa odpisująca saldo, często powiązana z przekazaniem sprawy zewnętrznej firmie windykacyjnej. Typ zdarzenia explicit | |||
| Korekta konta wprowadzona | Na koncie księgowana jest transakcja niebędąca płatnością, która zmienia saldo. Może to być korekta wynikająca z umowy z płatnikiem, odpis niewielkiej należności lub poprawka. | ||
| Dlaczego to ważne Duża liczba korekt może wskazywać na problemy z cennikami, zarządzaniem umowami lub błędy w fakturowaniu. Monitorowanie korekt jest niezbędne do analizy rzetelności rozliczeń. Skąd pobrać Rejestrowane jako określony typ transakcji w module rozliczeń pacjentów R1 RCM. Każda korekta ma kod, kwotę i datę księgowania. Rejestrowanie Rejestrowane jako osobna transakcja korekty, którą można rozpoznać po unikatowym kodzie transakcji. Typ zdarzenia explicit | |||
| Odpowiedź płatnika na roszczenie otrzymana | System otrzymuje od płatnika odpowiedź dotyczącą przesłanego roszczenia, często w pliku elektronicznego zestawienia płatności (ERA). Odpowiedź zawiera informacje o kwotach wypłaconych, odrzuconych lub skorygowanych. | ||
| Dlaczego to ważne To ważny punkt rozgałęzienia procesu, który decyduje, czy kolejnym etapem będzie księgowanie płatności, czy obsługa odrzuconego roszczenia. Analiza tego zdarzenia pomaga zrozumieć zachowania płatników i szybkość płatności. Skąd pobrać Zdarzenie jest rejestrowane, gdy R1 RCM przetwarza elektroniczny plik z zestawieniem płatności od płatnika, na przykład plik ANSI 835. Jego znacznik czasu odpowiada chwili przetworzenia pliku. Rejestrowanie Rejestrowane po wczytaniu i przetworzeniu pliku Electronic Remittance Advice (ERA/835). Typ zdarzenia explicit | |||
| Roszczenie odrzucone | Płatnik odmówił pokrycia całości roszczenia lub wybranych pozycji. Zapisanie przyczyny odrzucenia rozpoczyna proces poprawek i odwołania. | ||
| Dlaczego to ważne Ta czynność wskazuje na utratę przychodów i nieefektywność procesu. Analiza przyczyn odrzuceń jest niezbędna do wykrycia ich źródeł i zwiększenia odsetka roszczeń akceptowanych za pierwszym razem. Skąd pobrać Nie jest to osobne zdarzenie, lecz status ustalany na podstawie danych z przetworzonego pliku ERA. Konkretne kody odrzucenia w danych dotyczących płatności powodują zmianę statusu roszczenia. Rejestrowanie Ustalane na podstawie kodów odrzucenia w przetworzonym pliku ERA, które zmieniają status roszczenia na „Odrzucone”. Typ zdarzenia inferred | |||
| Roszczenie utworzone | Na podstawie zarejestrowanych opłat system generuje formalne roszczenie. W tym celu łączy dane demograficzne pacjenta, informacje o ubezpieczeniu i kody usług w ustandaryzowanym formacie. | ||
| Dlaczego to ważne To ważny etap wewnętrzny przed wysłaniem roszczenia na zewnątrz. Opóźnienia mogą wskazywać na problemy z kodowaniem, weryfikacją danych lub konfiguracją systemu, które spowalniają cały proces rozliczeniowy. Skąd pobrać To wewnętrzne zdarzenie systemowe w R1 RCM. Prawdopodobnie jest rejestrowane jako zmiana statusu konta rozliczeniowego lub na podstawie znacznika czasu utworzenia samego rekordu roszczenia. Rejestrowanie Ustalane na podstawie zmiany statusu na „Roszczenie wygenerowane” lub znacznika czasu utworzenia rekordu roszczenia. Typ zdarzenia inferred | |||
| Rozpoczęto poprawianie odrzuconego roszczenia | Użytkownik lub zautomatyzowany workflow rozpoczyna analizę i poprawianie odrzuconego roszczenia. Może to obejmować korektę kodowania, przesłanie dokumentacji lub odwołanie od decyzji płatnika. | ||
| Dlaczego to ważne Oznacza początek kosztownego procesu poprawiania odrzuconych roszczeń. Pomiar czasu trwania tego etapu pomaga ocenić efektywność zespołu zajmującego się odrzuconymi roszczeniami. Skąd pobrać Zdarzenie często ustala się na podstawie zmiany statusu odrzuconego roszczenia na „Poprawianie w toku” lub „W trakcie weryfikacji” w kolejce zadań albo module obsługi odrzuconych roszczeń w R1 RCM. Rejestrowanie Ustalane na podstawie zmiany statusu w kolejce zadań związanych z obsługą odrzuconych roszczeń lub pierwszej czynności użytkownika dotyczącej odrzuconego roszczenia. Typ zdarzenia inferred | |||
| Rozpoczęto windykację | Konto pacjenta ma zaległe saldo i rozpoczynają się aktywne działania windykacyjne. Mogą one obejmować automatyczne wysyłanie przypomnień lub przekazanie sprawy specjaliście ds. windykacji. | ||
| Dlaczego to ważne Oznacza początek kosztownego procesu windykacji. Analiza skuteczności i czasu trwania tych działań pomaga usprawnić strategie odzyskiwania trudnych należności. Skąd pobrać Zdarzenie jest prawdopodobnie rejestrowane lub ustalane na podstawie zmiany statusu, gdy konto trafia do kolejki zadań windykacyjnych lub otrzymuje w R1 RCM kod statusu windykacyjnego. Rejestrowanie Ustalane na podstawie zmiany statusu konta na „Windykacja” lub „Zaległość”. Typ zdarzenia inferred | |||
| Zestawienie dla pacjenta wygenerowane | Po rozpatrzeniu roszczenia przez ubezpieczyciela tworzone jest zestawienie dla pacjenta, które określa pozostałą do zapłaty kwotę. Może ona obejmować współpłatność, udział własny lub usługi nieobjęte ubezpieczeniem. | ||
| Dlaczego to ważne Ta czynność rozpoczyna etap cyklu przychodów związany z płatnością pacjenta. Analiza czasu i częstotliwości jej występowania pomaga zarządzać należnościami od pacjentów i przepływami pieniężnymi. Skąd pobrać Zdarzenie jest zwykle rejestrowane podczas uruchomienia procesu wsadowego, który tworzy zestawienia dla pacjentów i drukuje je lub wysyła elektronicznie. R1 RCM zapisuje datę wygenerowania zestawienia. Rejestrowanie Rejestrowane jako transakcja podczas uruchomienia procesu wsadowego generującego zestawienia dla pacjentów. Typ zdarzenia explicit | |||
Instrukcje pobierania danych
Kroki
- Zaloguj się do platformy R1 RCM na konto użytkownika z uprawnieniami do modułów Business Intelligence lub raportowania.
- Przejdź do sekcji raportowania. Może ona nosić nazwę „Business Intelligence”, „Reporting Portal” lub „Analytics”.
- Znajdź narzędzie do tworzenia raportu niestandardowego lub zapytania. Pozwala ono określić pola danych i logikę pobierania.
- R1 RCM nie udostępnia gotowego, wspólnego dziennika zdarzeń, dlatego trzeba go zbudować, łącząc dane z różnych źródeł. W podanej konfiguracji zapytania zastosowano UNION ALL, aby połączyć zdarzenia z różnych obiektów biznesowych w jeden chronologiczny dziennik.
- Skopiuj całe zapytanie z sekcji „Query” tego dokumentu i wklej je do edytora zapytań lub konfiguracji raportu niestandardowego.
- Ustaw parametry raportu, zwłaszcza zakres dat. W zapytaniu zastąp symbole zastępcze
'{StartDate}'i'{EndDate}'datami określającymi okres pobierania, na przykład ostatnie 6 miesięcy. - W razie potrzeby dodaj filtry, na przykład dla placówek, działów lub grup płatników, aby zawęzić zakres danych.
- Uruchom raport. Zapytanie zostanie wykonane na bazie R1 RCM, a wyniki będą zgodne z podanymi parametrami.
- Po zakończeniu raportowania wybierz opcję eksportu danych. Jako format wybierz CSV (Comma Separated Values), który jest bezpośrednio zgodny z ProcessMind.
- Pobierz plik CSV i sprawdź jego zawartość. Upewnij się, że nagłówki kolumn odpowiadają wymaganym atrybutom:
BillingEvent,ActivityName,EventTime,SourceSystemiLastDataUpdate. - Przed przesłaniem pliku do ProcessMind sprawdź, czy format daty i godziny w kolumnach
EventTimeiLastDataUpdatejest spójny.
Konfiguracja
- Wymagania wstępne: Potrzebne jest konto użytkownika z uprawnieniami do dostępu do modułu Business Intelligence w R1 RCM i tworzenia w nim raportów niestandardowych.
- Typ raportu: Użyj zapytania niestandardowego lub zaawansowanego kreatora raportów, który umożliwia pobieranie złożonych zestawów danych i stosowanie instrukcji UNION ALL do łączenia różnych zbiorów.
- Zakres dat: Aby ograniczyć obciążenie systemu i ilość danych, należy ustawić konkretny okres. Do wstępnej analizy zalecamy zakres od 3 do 6 miesięcy. Filtr daty zastosuj do głównego pola znacznika czasu dla każdego działania.
- Najważniejsze filtry: Oprócz zakresu dat warto filtrować dane według
Facility ID,Payer TypelubBilling Department, aby skupić analizę na wybranych obszarach operacyjnych i zmniejszyć rozmiar eksportu. - Format eksportu: Zawsze wybieraj CSV. Otrzymany plik będzie uporządkowany i łatwy do przetworzenia przez narzędzia process mining.
- Harmonogram: Jeśli moduł raportowania R1 RCM na to pozwala, zaplanuj cykliczne uruchamianie raportu, na przykład co tydzień lub co miesiąc, aby regularnie odświeżać dane i monitorować proces.
Przykładowe zapytanie sql
SELECT
c.ClaimID AS BillingEvent,
'Service Rendered' AS ActivityName,
c.ServiceDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ClinicianID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Rendered' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ServiceDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
c.ClaimID AS BillingEvent,
'Charges Captured' AS ActivityName,
c.ChargeEntryTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
c.ChargeEntryUserID AS AssignedUser,
d.DepartmentName AS BillingDepartment,
c.TotalChargeAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Open' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ServiceAndChargeData] c
JOIN [Departments] d ON c.DepartmentID = d.DepartmentID
JOIN [Payers] p ON c.PayerID = p.PayerID
WHERE c.ChargeEntryTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Created' AS ActivityName,
cl.CreationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.CreatedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Created' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.CreationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
cl.ClaimID AS BillingEvent,
'Claim Submitted' AS ActivityName,
cl.SubmissionTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
cl.SubmittedByUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Submitted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [ClaimsData] cl
WHERE cl.SubmissionTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
era.ClaimID AS BillingEvent,
'Payer Adjudication Received' AS ActivityName,
era.ReceivedTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pa.InvoiceAmount AS InvoiceAmount,
era.PayerName AS PayerName,
'Adjudicated' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [RemittanceAdvice] era
JOIN [PatientAccounts] pa ON era.ClaimID = pa.BillingEvent
WHERE era.ReceivedTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
d.ClaimID AS BillingEvent,
'Claim Denied' AS ActivityName,
d.DenialTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'Denied' AS InvoiceStatus,
d.ReasonCode AS DenialReasonCode
FROM [DenialsLog] d
JOIN [ClaimsData] cl ON d.ClaimID = cl.ClaimID
WHERE d.DenialTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
dr.ClaimID AS BillingEvent,
'Denial Rework Started' AS ActivityName,
dr.ReworkStartTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
dr.AssignedUserID AS AssignedUser,
cl.BillingDepartment AS BillingDepartment,
cl.TotalAmount AS InvoiceAmount,
cl.PayerName AS PayerName,
'In Rework' AS InvoiceStatus,
dr.OriginalDenialCode AS DenialReasonCode
FROM [DenialRework] dr
JOIN [ClaimsData] cl ON dr.ClaimID = cl.ClaimID
WHERE dr.ReworkStartTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ps.PatientAccountID AS BillingEvent,
'Patient Statement Generated' AS ActivityName,
ps.GenerationTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ps.GeneratedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
ps.StatementBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Patient Billed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientStatements] ps
JOIN [PatientAccounts] pa ON ps.PatientAccountID = pa.BillingEvent
WHERE ps.GenerationTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
p.AssociatedClaimID AS BillingEvent,
'Payment Received' AS ActivityName,
p.ReceiptTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
p.ProcessedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
p.PaymentAmount AS InvoiceAmount,
p.PayerName AS PayerName,
'Payment Pending' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentsLog] p
JOIN [PatientAccounts] pa ON p.AssociatedClaimID = pa.BillingEvent
WHERE p.ReceiptTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pt.ClaimID AS BillingEvent,
'Payment Posted' AS ActivityName,
pt.PostingTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pt.PostedByUserID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
pt.PostedAmount AS InvoiceAmount,
pt.PayerName AS PayerName,
'Partially Paid' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PaymentTransactions] pt
JOIN [PatientAccounts] pa ON pt.ClaimID = pa.BillingEvent
WHERE pt.PostingTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
a.ClaimID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
a.AdjustmentTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
a.AdjusterID AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
a.AdjustmentAmount AS InvoiceAmount,
pa.PayerName AS PayerName,
'Adjusted' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [Adjustments] a
JOIN [PatientAccounts] pa ON a.ClaimID = pa.BillingEvent
WHERE a.AdjustmentTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
ca.PatientAccountID AS BillingEvent,
'Collection Activity Started' AS ActivityName,
ca.ActivityTimestamp AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
ca.AssignedAgentID AS AssignedUser,
'Collections' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'In Collections' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [CollectionsActivity] ca
JOIN [PatientAccounts] pa ON ca.PatientAccountID = pa.BillingEvent
WHERE ca.ActivityTimestamp BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Placed in Bad Debt' AS ActivityName,
pa.BadDebtPlacementDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
pa.BadDebtUserID AS AssignedUser,
'Finance' AS BillingDepartment,
pa.CurrentBalance AS InvoiceAmount,
'Patient' AS PayerName,
'Bad Debt' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.BadDebtPlacementDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
SELECT
pa.BillingEvent AS BillingEvent,
'Account Closed' AS ActivityName,
pa.ClosureDate AS EventTime,
'R1 RCM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
'System' AS AssignedUser,
pa.BillingDepartment AS BillingDepartment,
0 AS InvoiceAmount,
pa.PayerName AS PayerName,
'Closed' AS InvoiceStatus,
NULL AS DenialReasonCode
FROM [PatientAccounts] pa
WHERE pa.ClosureDate BETWEEN '{StartDate}' AND '{EndDate}' AND pa.CurrentBalance = 0; Gotowi do rozpoczęcia?
Skorzystajcie z tego szablonu, aby usprawnić zbieranie danych i rozpocząć optymalizację zarządzania cyklem przychodów. Na każdym etapie można liczyć na nasze wsparcie.
Zoptymalizujcie R1 RCM i usprawnijcie cykl przychodów
Usuńcie wąskie gardła w RCM, skróćcie czas cyklu o 30% i poprawcie przepływy pieniężne.
Nie trzeba podawać danych karty płatniczej. Rozpoczęcie zajmuje kilka minut.