Szablon danych do analizy zarządzania cyklem przychodów

R1 RCM
Szablon danych do analizy zarządzania cyklem przychodów

Szablon danych do analizy zarządzania cyklem przychodów

Ten szablon pokazuje, jakie informacje zebrać, aby przeanalizować proces zarządzania cyklem przychodów. Zawiera listę zalecanych atrybutów i działań do śledzenia oraz wskazówki dotyczące pobierania danych z systemu R1 RCM. Ułatwi to przygotowanie danych do analizy process mining.
  • Zalecane atrybuty do zebrania
  • Najważniejsze działania do śledzenia podczas odkrywania procesu
  • Szczegółowe wskazówki dotyczące pobierania danych z R1 RCM
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty zarządzania cyklem przychodów

Poniżej przedstawiono zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie przeanalizować proces zarządzania cyklem przychodów.
5 Wymagane 6 Zalecane 8 Opcjonalne
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
Wymagane Zalecane Opcjonalne

Działania w procesie zarządzania cyklem przychodów

Poniżej przedstawiono najważniejsze kroki i punkty kontrolne, które warto zapisać w dzienniku zdarzeń, aby dokładnie odtworzyć proces zarządzania cyklem przychodów.
6 Zalecane 8 Opcjonalne
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
Zalecane Opcjonalne

Instrukcje pobierania danych

Jak pobrać dane z R1 RCM

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.

Rozpocznij okres próbny

Nie trzeba podawać danych karty płatniczej. Rozpoczęcie zajmuje kilka minut.