Szablon danych do zarządzania cyklem przychodów

Optum360
Szablon danych do zarządzania cyklem przychodów

Szablon danych do zarządzania cyklem przychodów

Ten szablon pomaga zebrać dane potrzebne do analizy procesu zarządzania cyklem przychodów. Zawiera listę najważniejszych atrybutów, działań do monitorowania oraz praktyczne wskazówki dotyczące pozyskiwania informacji. Dzięki niemu można przygotować dane do analizy process mining.
  • Zalecane atrybuty do zebrania
  • Najważniejsze działania do monitorowania
  • Wskazówki dotyczące pozyskiwania danych
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 przeprowadzić pełną analizę zarządzania cyklem przychodów.
3 Wymagane 6 Zalecane 10 Opcjonalne
Nazwa Opis
Czas zdarzenia
EventTime
Znacznik czasu wskazujący, kiedy wystąpiło konkretne działanie lub zdarzenie.
Opis

Czas zdarzenia to znacznik czasu przypisany do każdego działania, który wskazuje dokładną datę i godzinę jego wystąpienia. Te dane czasowe pozwalają ustalić chronologiczną kolejność zdarzeń w każdej sprawie.

W analizie czas zdarzenia służy do obliczania czasu między działaniami, mierzenia czasu trwania sprawy i wykrywania wąskich gardeł, w których dużo czasu upływa na oczekiwaniu. To podstawa analizy procesu i pomiaru wyników w ujęciu czasowym.

Dlaczego to ważne

Ten znacznik czasu pozwala prawidłowo ustalić kolejność zdarzeń i obliczyć wszystkie miary czasu, takie jak czas cyklu i czas oczekiwania w wąskich gardłach.

Skąd pobrać

Informacje te są zwykle przechowywane w tabelach bazy danych Optum360 obok każdego rekordu transakcji lub zmiany statusu.

Przykłady
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:00Z
Nazwa działania
ActivityName
Nazwa konkretnego zdarzenia lub zadania, które wystąpiło w procesie zarządzania cyklem przychodów.
Opis

Nazwa działania opisuje etap procesu cyklu przychodów, na przykład „Wysłano roszczenie do płatnika” lub „Otrzymano płatność”. Ten atrybut jest podstawą process mining, ponieważ określa węzły na mapie procesu.

Analiza kolejności i częstotliwości działań pozwala zobrazować rzeczywisty przebieg procesu, wykryć odstępstwa od standardowej procedury i wskazać powtarzające się pętle poprawek. Ułatwia też zrozumienie nieefektywności procesu i problemów ze zgodnością.

Dlaczego to ważne

Ten atrybut określa poszczególne etapy procesu. Stanowi podstawę mapy procesu i umożliwia analizę jego przebiegu.

Skąd pobrać

Wartość zwykle pochodzi z dzienników zdarzeń, rekordów zmian statusu lub określonych kodów transakcji w tabelach operacyjnych Optum360.

Przykłady
Utworzono roszczenieWysłano roszczenie do płatnikaOtrzymano płatnośćOtrzymano odmowęZamknięto konto
Zdarzenie rozliczeniowe
BillingEvent
Unikalny identyfikator pojedynczej usługi lub dostawy produktu, za którą naliczana jest opłata. Pełni funkcję głównego identyfikatora sprawy.
Opis

Zdarzenie rozliczeniowe pełni funkcję głównego identyfikatora sprawy i łączy wszystkie działania związane z pojedynczą usługą lub dostawą produktu, za którą naliczana jest opłata. Pozwala kompleksowo śledzić cykl generowania i pobierania przychodów dla każdej rozliczanej pozycji lub usługi.

Analiza procesu według zdarzeń rozliczeniowych w process mining pokazuje pełną drogę od wykonania usługi do otrzymania płatności lub zamknięcia konta. Ułatwia wykrywanie wąskich gardeł, pomiar czasu cyklu i analizę różnic w obsłudze poszczególnych roszczeń lub faktur.

Dlaczego to ważne

To podstawowy identyfikator sprawy, który łączy wszystkie powiązane działania w cyklu przychodów i pozwala analizować cały proces od początku do końca.

Skąd pobrać

To klucz główny łączący rekordy w podstawowych tabelach rozliczeń i roszczeń Optum360. Szczegółowe nazwy tabel i pól można znaleźć w dokumentacji Optum360.

Przykłady
BE-2023-0012345BE-2023-0012346BE-2023-0012347
Dział rozliczeń
BillingDepartment
Wewnętrzny dział lub zespół, który obsługiwał albo wykonał czynność związaną z rozliczeniem.
Opis

Atrybut „Dział rozliczeń” wskazuje konkretny zespół lub obszar funkcjonalny w operacjach cyklu przychodów odpowiedzialny za daną czynność. Przykładowo różne zespoły mogą zajmować się kodowaniem, składaniem roszczeń i obsługą odrzuceń.

Atrybut ten jest niezbędny do porównywania wyników zespołów, czego wymaga dashboard „Wskaźniki efektywności działów rozliczeń”. Umożliwia kierownictwu porównanie sprawności, szybkości i dokładności pracy zespołów, wskazanie dobrych praktyk oraz odpowiednie przydzielanie zasobów w celu usunięcia różnic w wynikach.

Dlaczego to ważne

Umożliwia porównanie wyników różnych zespołów rozliczeniowych, wskazanie tych osiągających najlepsze rezultaty oraz obszarów wymagających poprawy.

Skąd pobrać

Informację tę można ustalić na podstawie użytkownika wykonującego zadanie lub pola na koncie wskazującego osobę odpowiedzialną. Szczegóły można znaleźć w dokumentacji Optum360.

Przykłady
Centralny dział rozliczeńZespół ds. odrzuconych roszczeńDział kodowaniaObsługa finansowa pacjentów
Identyfikator pacjenta
PatientId
Unikalny identyfikator pacjenta, który otrzymał usługi.
Opis

Identyfikator pacjenta to unikalna wartość przypisana każdemu pacjentowi w systemie ochrony zdrowia. Łączy wiele zdarzeń rozliczeniowych z jednym pacjentem i umożliwia analizę z jego perspektywy.

Analitycy mogą wykorzystać ten identyfikator do badania wzorców dotyczących konkretnych pacjentów, takich jak częste ponowne przyjęcia do szpitala lub historia odrzuconych roszczeń. Umożliwia on także podział danych według demografii lub historii pacjentów, co może ujawnić sposoby poprawy ich doświadczeń związanych z rozliczeniami.

Dlaczego to ważne

Umożliwia analizę z perspektywy pacjenta, pomaga zrozumieć całą drogę rozliczenia i wykrywać wzorce dotyczące określonych grup pacjentów.

Skąd pobrać

Ten identyfikator jest podstawowym polem w głównych danych pacjentów i tabelach transakcji Optum360. Szczegółowe informacje można znaleźć w dokumentacji Optum360.

Przykłady
PAT-98765PAT-98766PAT-98767
Identyfikator płatnika
PayerId
Unikalny identyfikator firmy ubezpieczeniowej lub płatnika odpowiedzialnego za rozliczenie roszczenia.
Opis

Identyfikator płatnika wskazuje konkretną firmę ubezpieczeniową, program rządowy, taki jak Medicare lub Medicaid, albo inny podmiot odpowiedzialny za opłacenie roszczenia. Każdy płatnik ma zwykle własne zasady, wymagania dotyczące składania roszczeń i sposób realizacji płatności.

Analiza procesu według identyfikatora płatnika ma zasadnicze znaczenie dla RCM. Pozwala ustalić, którzy płatnicy najdłużej realizują płatności, najczęściej odrzucają roszczenia lub wymagają najbardziej złożonych procedur odwoławczych. Dzięki tym informacjom działy rozliczeń mogą dostosować działania do poszczególnych płatników, przyspieszyć odzyskiwanie należności i ograniczyć obciążenia administracyjne.

Dlaczego to ważne

Podział procesu według płatnika pozwala ustalić, którzy płatnicy powodują opóźnienia lub odrzucają roszczenia, a następnie ukierunkować działania usprawniające zarządzanie relacjami z płatnikami.

Skąd pobrać

Informacje te są zapisane w rekordzie każdego roszczenia w Optum360. Nazwy tabel i pól związanych z płatnikami można znaleźć w dokumentacji Optum360.

Przykłady
PŁATNIK-AETNAPŁATNIK-BCBS-MAPŁATNIK-MEDICAREPŁATNIK-UHC
Kod przyczyny odrzucenia
DenialReasonCode
Standardowy kod podany przez płatnika, który wyjaśnia przyczynę odrzucenia roszczenia.
Opis

Gdy płatnik odrzuca roszczenie, podaje kod przyczyny, na przykład „świadczenie nieobjęte ochroną” lub „duplikat roszczenia”. Kody te pomagają ustalić źródła opóźnień w uzyskiwaniu przychodów i konieczności ponownej pracy.

Analiza kodów pozwala zespołowi ds. odrzuconych roszczeń ustalać priorytety, wykrywać powtarzające się problemy i wdrażać działania naprawcze. Na przykład częste odrzucenia z powodu „brakujących informacji” mogą wskazywać na problem z przygotowaniem roszczeń. Taka analiza pomaga ograniczyć liczbę odrzuceń i przyspieszyć przepływ środków.

Dlaczego to ważne

Wskazuje przyczynę odrzucenia roszczenia, co pozwala podjąć ukierunkowane działania zapobiegające kolejnym odrzuceniom i ograniczyć kosztowną ponowną pracę.

Skąd pobrać

Kod znajduje się w plikach Electronic Remittance Advice (ERA) otrzymywanych od płatników i jest przechowywany w module zarządzania roszczeniami Optum360.

Przykłady
CO-16: W roszczeniu lub usłudze brakuje informacjiPR-97: Świadczenie jest uwzględnione w płatności lub dopuszczalnej kwocie za inne świadczenie lub proceduręOA-18: Zduplikowane roszczenie lub usługa
Kwota korekt
AdjustedAmount
Wartość odpisów, korekt umownych lub poprawek wprowadzonych do kwoty zafakturowanej.
Opis

Kwota korekt to część kwoty zafakturowanej, której nie można oczekiwać jako wpływu ze względu na umowy z płatnikami, poprawki w rozliczeniach lub inne odpisy. Bezpośrednio zmniejsza przychody.

Atrybut ten jest niezbędny do analizy na dashboardzie „Wpływ korekt przychodów” i obliczania KPI „Wskaźnik korekt przychodów”. Analiza korekt pozwala określić finansowy wpływ umów z płatnikami oraz znaleźć sposoby ograniczenia utraty przychodów przez poprawę dokładności rozliczeń lub negocjowanie warunków umów.

Dlaczego to ważne

Bezpośrednio mierzy utratę przychodów. Jest niezbędny do obliczania finansowych KPI i oceny rentowności.

Skąd pobrać

Informacje te znajdują się w rekordach transakcji korekt w systemie finansowym Optum360.

Przykłady
30.00250.2510.00
Kwota zafakturowana
BilledAmount
Łączna wartość wszystkich opłat ujętych w roszczeniu lub fakturze.
Opis

Kwota zafakturowana to łączna wartość opłat za udzielone świadczenia przed uwzględnieniem płatności, korekt i odpisów. Jest to początkowa wartość należności powstałej w wyniku rozliczenia.

Atrybut ten stanowi podstawę analizy finansowej w process mining. Służy do obliczania ważnych KPI, takich jak wskaźnik korekt przychodów, a także do podziału spraw według wartości. Dzięki temu można sprawdzić, czy roszczenia o wysokiej wartości są obsługiwane inaczej lub opóźniają się częściej niż roszczenia o niższej wartości.

Dlaczego to ważne

Pokazuje kontekst finansowy każdej sprawy, umożliwiając analizę według wartości i obliczanie istotnych finansowych KPI.

Skąd pobrać

To standardowe pole w rekordzie każdego roszczenia lub konta pacjenta w tabelach finansowych Optum360.

Przykłady
150.001250.7585.50
Czas trwania sprawy
CaseDuration
Łączny czas obsługi rozliczenia, od pierwszej do ostatniej czynności.
Opis

Czas trwania sprawy to czas od pierwszego do ostatniego zdarzenia w ramach pojedynczego rozliczenia. Jest to ogólny KPI służący do oceny sprawności całego procesu.

Miernik ten wspiera analizę na dashboardzie „Przegląd czasu cyklu RCM od początku do końca” oraz KPI „Średni czas cyklu RCM”. Śledzenie jego zmian pozwala kierownictwu ocenić wpływ działań usprawniających na cały cykl przychodów.

Dlaczego to ważne

Pokazuje czas realizacji procesu od początku do końca. To istotny KPI służący do pomiaru szybkości i sprawności całego procesu.

Skąd pobrać

Wartość oblicza się dla każdego unikalnego identyfikatora sprawy „BillingEvent”, odejmując timestamp pierwszego zdarzenia od timestampu ostatniego.

Przykłady
30 dni95 dni45 dni
Czas zakończenia
EndTime
Znacznik czasu wskazujący, kiedy zakończono działanie.
Opis

Czas zakończenia oznacza moment, w którym działanie zostało ukończone. Czas rozpoczęcia wskazuje, kiedy zdarzenie się zaczęło, natomiast czas zakończenia pozwala obliczyć czas trwania działań wymagających określonego czasu przetwarzania, takich jak poprawianie odmowy.

Porównanie czasu rozpoczęcia i zakończenia pozwala obliczyć czas przetwarzania działania. Dzięki temu można odróżnić czas aktywnej pracy od czasu bezczynnego oczekiwania między działaniami i dokładniej ocenić sprawność procesu.

Dlaczego to ważne

Pozwala dokładnie obliczyć czas przetwarzania działań i odróżnić aktywną pracę od oczekiwania w procesie.

Skąd pobrać

W przypadku niektórych działań system źródłowy może przechowywać osobne pole znacznika czasu. W innych przypadkach czas zakończenia można ustalić na podstawie czasu rozpoczęcia kolejnego działania.

Przykłady
2023-10-26T10:15:00Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
Czy ponowna praca
IsRework
Flaga wskazująca, czy czynność należy do pętli ponownej pracy, na przykład obsługi odrzucenia lub odwołania.
Opis

Flaga „Czy ponowna praca” przyjmuje wartość logiczną i wskazuje czynności uznawane za ponowną pracę, która nie przynosi wartości, takie jak „Rozpoczęto ponowną obsługę odrzuconego roszczenia” lub „Złożono odwołanie”. Czynności te zwykle pojawiają się, gdy proces odbiega od optymalnego przebiegu.

Atrybut ten pozwala określić skalę ponownej pracy, która bezpośrednio wskazuje na nieefektywność i koszty. Służy do obliczania KPI „Wskaźnik ponownej pracy z powodu błędów rozliczeniowych” i wspiera dashboard „Identyfikacja wąskich gardeł i pętli ponownej pracy”, ułatwiając filtrowanie i wizualizację nieefektywnych pętli.

Dlaczego to ważne

Pomaga określić skalę nieefektywności procesu, oznaczając czynności wymagające ponownej pracy. Ułatwia pomiar strat i wskazanie obszarów do poprawy.

Skąd pobrać

Wartość tę zwykle wyznacza się za pomocą reguł biznesowych w narzędziu process mining. Na przykład każdą czynność po zdarzeniu „Otrzymano odrzucenie” można oznaczyć jako ponowną pracę.

Przykłady
truefalse
Kod świadczenia
ServiceCode
Kod procedury, np. CPT lub HCPCS, który identyfikuje konkretne udzielone świadczenie.
Opis

Kod świadczenia to standardowy kod medyczny, który precyzyjnie określa procedurę lub usługę udzieloną pacjentowi. Kody te są wymagane do rozliczeń i w dużej mierze decydują o wysokości refundacji.

Analiza procesu według kodu świadczenia może ujawnić, że niektóre procedury częściej prowadzą do odrzuceń, wymagają obszerniejszej dokumentacji lub wiążą się z dłuższym oczekiwaniem na płatność. Pozwala to dokładniej zrozumieć problemy w procesie i dostosować zasady kodowania oraz rozliczeń do konkretnych rodzajów świadczeń.

Dlaczego to ważne

Umożliwia analizę według rodzaju świadczenia medycznego i wykrywanie odrzuceń lub opóźnień w płatnościach dotyczących konkretnych procedur.

Skąd pobrać

Kod ten jest podstawowym elementem rekordów wprowadzania opłat i szczegółów roszczenia w Optum360.

Przykłady
992137104527447
Kwota zapłacona
PaidAmount
Łączna kwota otrzymana od płatnika i pacjenta za rozliczone świadczenia.
Opis

Kwota zapłacona to suma wszystkich płatności zaksięgowanych na koncie w ramach danego rozliczenia. Odzwierciedla faktycznie otrzymane środki i jest jednym z głównych mierników skuteczności cyklu przychodów.

Śledzenie kwoty zapłaconej w analizie procesu pozwala lepiej zrozumieć przepływy pieniężne i ogólne wyniki finansowe. Można na tej podstawie analizować tempo płatności i porównywać kwoty zafakturowane z otrzymanymi, aby wykrywać niedopłaty lub nieściągalne należności.

Dlaczego to ważne

Pokazuje faktycznie otrzymane środki. To ważny miernik wyniku procesu RCM i podstawa analizy przepływów pieniężnych.

Skąd pobrać

Wartość ta jest zwykle zapisana w tabelach transakcji płatniczych lub podsumowana na poziomie konta w Optum360.

Przykłady
120.001000.500.00
Ostatnia aktualizacja danych
LastDataUpdate
Znacznik czasu ostatniego odświeżenia lub pobrania danych z systemu źródłowego.
Opis

Ten atrybut zapisuje datę i godzinę ostatniego pobrania danych z systemu źródłowego i wczytania ich do narzędzia process mining. Informuje, jak aktualne są analizowane dane.

Analitycy i użytkownicy biznesowi mogą dzięki niemu sprawdzić, czy pracują na najnowszych informacjach. Ułatwia też uwzględnienie opóźnień w dostępności danych i stanowi ważny element metadanych projektu analitycznego.

Dlaczego to ważne

Informuje o aktualności danych, dzięki czemu użytkownicy wiedzą, jak aktualna jest analiza.

Skąd pobrać

Ten znacznik czasu jest zwykle generowany i zapisywany przez proces ekstrakcji, transformacji i ładowania danych (ETL).

Przykłady
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Status konta
AccountStatus
Bieżący stan konta rozliczeniowego w cyklu przychodów.
Opis

Status konta pokazuje, na jakim etapie procesu znajduje się dane rozliczenie, na przykład „Oczekuje na płatnika”, „Opłacone w całości” lub „W windykacji”. Atrybut ten zapewnia kontekst dla wykonywanych czynności.

Ułatwia filtrowanie i grupowanie spraw, aby skupić się na wybranych etapach procesu. Przykładowo analiza wszystkich kont oznaczonych jako „W windykacji” pozwala zrozumieć przyczyny i skalę tego kosztownego etapu. Wspiera też analizę na dashboardzie „Liczba i przyczyny działań windykacyjnych”.

Dlaczego to ważne

Pokazuje ogólny bieżący stan sprawy, co pozwala filtrować i analizować wybrane grupy, na przykład sprawy w windykacji.

Skąd pobrać

To zwykle pole podsumowujące w głównym rekordzie konta pacjenta lub roszczenia w Optum360.

Przykłady
OtwarteOczekuje na płatnikaOpłacone w całościW windykacjiZamknięte
Świadczeniodawca
ServiceProvider
Lekarz, dział lub placówka, które udzieliły świadczenia podlegającego rozliczeniu.
Opis

Ten atrybut wskazuje konkretnego świadczeniodawcę, na przykład lekarza, terapeutę lub dział szpitala, który udzielił świadczenia. Różnice w sposobie rozliczania lub dokumentowania pracy przez poszczególnych świadczeniodawców mogą wpływać na cykl przychodów.

Analiza według świadczeniodawcy pomaga wykryć problemy z rejestrowaniem opłat, poprawnością kodowania lub jakością dokumentacji, które pojawiają się w miejscu udzielania świadczenia. Może wskazać potrzebę szkolenia świadczeniodawców lub usprawnienia procesu, aby od początku przygotowywać prawidłowe roszczenia.

Dlaczego to ważne

Pozwala prześledzić problemy z rozliczeniami do ich źródła i przekazać personelowi medycznemu ukierunkowane informacje zwrotne oraz szkolenia, które poprawią rejestrowanie opłat i dokumentację.

Skąd pobrać

Informacja ta jest ważną częścią rekordu opłaty lub roszczenia w Optum360 i często jest powiązana z głównymi danymi świadczeniodawcy.

Przykłady
Dr Emily CarterDział radiologiiChirurgia ogólnaFizjoterapia
System źródłowy
SourceSystem
System lub aplikacja, w której zarejestrowano dane o zdarzeniu.
Opis

Ten atrybut wskazuje system źródłowy, z którego pobrano dane dotyczące danego zdarzenia. W złożonym środowisku IT dane RCM mogą pochodzić z głównej platformy Optum360, zintegrowanego systemu elektronicznej dokumentacji medycznej (EHR), izby rozliczeniowej lub portalu pacjenta.

Znajomość systemu źródłowego pomaga weryfikować dane, rozwiązywać problemy z integracją i analizować różnice w przebiegu procesu wynikające z odmiennego działania systemów lub sposobu wprowadzania danych.

Dlaczego to ważne

Wskazuje źródło danych, co pomaga w zarządzaniu danymi, ocenie ich jakości i analizie różnic w przebiegu procesu między systemami.

Skąd pobrać

Może to być stała wartość ustawiana podczas ekstrakcji danych albo pole w tabelach źródłowych wskazujące ich pochodzenie.

Przykłady
Optum360Interfejs EHRAPI izby rozliczeniowejPortal pacjenta
Użytkownik
User
Identyfikator użytkownika lub agenta systemowego, który wykonał daną czynność.
Opis

Atrybut „Użytkownik” wskazuje konkretną osobę, zespół lub zautomatyzowanego bota odpowiedzialnego za wykonanie danej czynności. Umożliwia analizę wyników pracy poszczególnych osób i grup.

Informacja o tym, kto wykonał daną czynność, pomaga ocenić produktywność, jakość i przestrzeganie standardowych procedur. Może wskazać potrzeby szkoleniowe lub pomóc wyróżnić osoby i zespoły osiągające dobre wyniki. Pozwala też odróżnić zadania wykonywane ręcznie od obsługiwanych automatycznie.

Dlaczego to ważne

Pozwala przypisać odpowiedzialność za poszczególne etapy procesu i analizować wyniki pracy osób lub zespołów. Ułatwia zarządzanie zasobami i planowanie szkoleń.

Skąd pobrać

Identyfikatory użytkowników są zwykle zapisywane w dziennikach audytowych lub historii transakcji w Optum360.

Przykłady
j.doem.smithAutoBillerBots.jones
Wymagane Zalecane Opcjonalne

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

Poniżej przedstawiono najważniejsze etapy i kamienie milowe procesu, które należy uwzględnić w dzienniku zdarzeń, aby dokładnie odtworzyć jego przebieg.
6 Zalecane 9 Opcjonalne
Działanie Opis
Otrzymano dane o usłudze
To zdarzenie rozpoczyna obsługę rozliczenia, gdy informacje o usłudze medycznej trafiają z elektronicznej dokumentacji medycznej (EHR) lub innego systemu źródłowego. Zwykle jest rejestrowane jako wpis w dzienniku lub rekord transakcji utworzony przez interfejs integracyjny po pomyślnym wczytaniu danych.
Dlaczego to ważne

To główne zdarzenie rozpoczynające cykl przychodów. Analiza czasu od tego działania do zarejestrowania opłaty pomaga wykryć opóźnienia w danych na początku procesu, które wpływają na jego dalszy przebieg.

Skąd pobrać

Dane można znaleźć w dziennikach interfejsów lub tabelach transakcji obsługujących przychodzące dane o usługach dla pacjentów z systemów zewnętrznych, takich jak EHR. Warto sprawdzić znaczniki czasu komunikatów HL7 lub dzienniki wywołań API.

Rejestrowanie

Dane pochodzą z dzienników integracji lub tabel transakcji, w których zapisuje się znacznik czasu odbioru danych.

Typ zdarzenia explicit
Otrzymano odmowę
Płatnik odrzucił roszczenie, co wynika z otrzymanego zestawienia płatności. Zdarzenie ustala się na podstawie kodów przyczyn odmowy przypisanych do pozycji roszczenia w danych zestawienia.
Dlaczego to ważne

Śledzenie odmów pomaga ustalić przyczyny utraty przychodów i nieefektywności procesu. To działanie rozpoczyna obsługę odmowy i pętle poprawek związane z odwołaniami.

Skąd pobrać

Zdarzenie ustala się na podstawie danych z elektronicznego zestawienia płatności (EDI 835). System wykrywa kody przyczyn korekty roszczenia (CARC), które oznaczają odmowę.

Rejestrowanie

Zdarzenie ustala się przez wykrycie określonych kodów odmowy (CARC/RARC) w przetworzonych danych zestawienia płatności EDI 835.

Typ zdarzenia inferred
Otrzymano zestawienie płatności
System otrzymał od płatnika elektroniczny plik zestawienia płatności (ERA) zawierający informacje o płatnościach, korektach i odmowach. Zdarzenie jest jawnie rejestrowane podczas wczytywania pliku EDI 835 do systemu.
Dlaczego to ważne

To ważny etap, który oznacza, że płatnik rozpatrzył roszczenie. Zawartość pliku określa dalsze działania, takie jak zaksięgowanie płatności lub obsługa odmowy.

Skąd pobrać

Zdarzenie jest rejestrowane w dziennikach transakcji EDI dotyczących przychodzących plików ANSI 835. Znacznik czasu wskazuje, kiedy system otrzymał i przetworzył plik.

Rejestrowanie

Znacznik czasu powiązany z wczytaniem pliku EDI 835 (Electronic Remittance Advice).

Typ zdarzenia explicit
Wysłano roszczenie do płatnika
Wygenerowane roszczenie zostało wysłane elektronicznie do płatnika ubezpieczeniowego w celu rozpatrzenia. Po pomyślnym przesłaniu zdarzenie jest jawnie rejestrowane przez moduł wysyłania roszczeń lub interfejs izby rozliczeniowej.
Dlaczego to ważne

To ważny etap, od którego zaczyna się pomiar czasu oczekiwania na odpowiedź płatnika. Pozwala ocenić sprawność wysyłania roszczeń i wykryć opóźnienia.

Skąd pobrać

Dane znajdują się w dziennikach transakcji dotyczących roszczeń lub tabelach transakcji EDI (Electronic Data Interchange), które rejestrują wysyłanie plików roszczeń 837. Warto szukać pola „znacznik czasu wysłania” lub „data transmisji”.

Rejestrowanie

Znacznik czasu z dziennika transakcji EDI 837 potwierdzający pomyślne wysłanie.

Typ zdarzenia explicit
Zaksięgowano płatność
Otrzymana płatność została przypisana do konkretnego konta pacjenta i pozycji usług. Jest to jawne działanie użytkownika lub automatycznego systemu, które uzgadnia płatność z nieuregulowanymi opłatami.
Dlaczego to ważne

To działanie pozwala ocenić sprawność zaplecza księgowania wpływów. Opóźnienia w księgowaniu mogą zniekształcać raporty należności i opóźniać zamknięcie konta.

Skąd pobrać

Dane znajdują się w tabelach transakcji płatniczych. Czas transakcji związanej z księgowaniem jest czasem zdarzenia.

Rejestrowanie

Czas utworzenia rekordu transakcji płatniczej przypisanej do konkretnej opłaty.

Typ zdarzenia explicit
Zamknięto konto
Zdarzenie rozliczeniowe uznaje się za zakończone, gdy saldo wynosi zero i nie przewiduje się dalszych działań. Zdarzenie ustala się, gdy saldo konta spada do zera, a jego status zmienia się na „Zamknięte” lub inny status końcowy.
Dlaczego to ważne

To główne zdarzenie kończące proces. Pomiar całkowitego czasu cyklu do tego momentu daje pełny obraz sprawności RCM.

Skąd pobrać

Zdarzenie ustala się na podstawie połączenia dwóch warunków: saldo konta wynosi zero, a pole statusu ma wartość „Zamknięte”, „W pełni opłacone” lub równoważny status końcowy.

Rejestrowanie

Późniejszy z dwóch znaczników czasu: końcowego zaksięgowania płatności, które zeruje saldo, lub zmiany statusu na „Zamknięte”.

Typ zdarzenia inferred
Otrzymano płatność
Oznacza otrzymanie płatności od płatnika lub pacjenta, często odnotowanej w zestawieniu płatności. Zdarzenie można zarejestrować na podstawie elektronicznych plików zestawień lub ręcznych dzienników wpływów gotówkowych.
Dlaczego to ważne

To podstawowe działanie przy analizie przepływów pieniężnych i tempa otrzymywania płatności. Rozpoczyna proces księgowania płatności.

Skąd pobrać

Dane pochodzą z informacji o płatności w pliku zestawienia EDI 835 lub z plików bankowych lockbox. Często wykorzystuje się datę czeku lub datę przetworzenia podaną w pliku.

Rejestrowanie

Dane pochodzą z segmentu BPR pliku EDI 835 lub pliku danych lockbox banku.

Typ zdarzenia explicit
Rozpoczęto poprawianie odmowy
Użytkownik lub automatyczny workflow rozpoczął analizę i rozpatrywanie odrzuconego roszczenia. Zdarzenie może być zapisane bezpośrednio po działaniu użytkownika lub ustalone na podstawie zmiany statusu roszczenia.
Dlaczego to ważne

To działanie rozpoczyna pętlę poprawek po odmowie. Pomiar czasu od otrzymania odmowy do rozpoczęcia poprawek pomaga wykryć zaległości w kolejce obsługi odmów.

Skąd pobrać

Dane znajdują się w modułach obsługi odmów lub kolejek zadań. Może to być jawny znacznik czasu, gdy użytkownik otwiera zadanie dotyczące odmowy lub przypisuje je do siebie, albo zdarzenie ustalone na podstawie zmiany statusu, na przykład z „Odrzucono” na „W trakcie poprawiania”.

Rejestrowanie

Zdarzenie ustala się na podstawie zmiany statusu roszczenia na „Do poprawy” lub „W trakcie weryfikacji” albo na podstawie jawnego wpisu o działaniu użytkownika.

Typ zdarzenia inferred
Rozpoczęto windykację
Z powodu braku płatności konto pacjenta skierowano do aktywnej windykacji. Zdarzenie zwykle ustala się na podstawie zmiany klasy finansowej lub statusu konta.
Dlaczego to ważne

Pozwala wskazać konta wymagające intensywniejszych działań następczych. Analiza częstotliwości i przyczyn tego działania pomaga usprawnić strategie odzyskiwania należności na wcześniejszych etapach.

Skąd pobrać

Zdarzenie ustala się na podstawie zmiany statusu konta na „Windykacja”, „Należność nieściągalna” lub „Przekazano do agencji”. Znacznik czasu zdarzenia odpowiada dacie zmiany statusu.

Rejestrowanie

Znacznik czasu zmiany pola statusu konta na wartość związaną z windykacją.

Typ zdarzenia inferred
Skorygowano konto
Do konta zaksięgowano korektę umowną, odpis lub inną korektę finansową. Jest to jawna transakcja finansowa zapisana w księdze systemu.
Dlaczego to ważne

Korekty bezpośrednio wpływają na uzyskane przychody. Analiza ich przyczyn i terminów pomaga wykryć problemy z cennikami, umowami lub dokładnością rozliczeń.

Skąd pobrać

Dane znajdują się w tabeli transakcji finansowych. Można je rozpoznać po kodach transakcji dotyczących odpisów lub korekt. Datą zdarzenia jest data transakcji.

Rejestrowanie

Data transakcji wpisu w księdze finansowej oznaczonego określonym kodem korekty.

Typ zdarzenia explicit
Utworzono roszczenie
System wygenerował roszczenie do rozliczenia, łącząc wszystkie opłaty, kody i dane demograficzne w ustandaryzowanym formacie. Jest to jawne zdarzenie systemowe z przypisanym czasem utworzenia.
Dlaczego to ważne

To działanie oznacza przejście od rejestrowania opłat do formalnego procesu rozliczeniowego. Jest warunkiem wysłania roszczenia i pozwala śledzić czas wewnętrznej obsługi.

Skąd pobrać

Dane znajdują się w tabeli roszczeń lub dzienniku transakcji. Zdarzenie oznacza czas utworzenia rekordu nagłówka roszczenia.

Rejestrowanie

Czas utworzenia głównego rekordu w tabeli roszczeń w bazie danych.

Typ zdarzenia explicit
Wysłano odwołanie
Formalnie wysłano do płatnika odwołanie od odrzuconego roszczenia. Działanie jest jawnie rejestrowane przez użytkownika w module obsługi odmów lub odwołań.
Dlaczego to ważne

To ważny etap odzyskiwania przychodów. Śledzenie wysłanych odwołań i czasu ich rozpatrywania pozwala ocenić skuteczność strategii obsługi odmów.

Skąd pobrać

Dane znajdują się w module śledzenia odwołań lub jako określony typ transakcji przypisany do roszczenia. Warto szukać pola „data odwołania” lub „data ponownego wysłania”.

Rejestrowanie

Jawny znacznik czasu zapisany w chwili, gdy użytkownik rejestruje wysłanie odwołania.

Typ zdarzenia explicit
Wysłano zestawienie dla pacjenta
Wygenerowano i wysłano pacjentowi zestawienie jego części rachunku. Moduł rozliczeń pacjentów jawnie rejestruje to zdarzenie podczas tworzenia zestawienia.
Dlaczego to ważne

To działanie rozpoczyna część cyklu przychodów, w której pacjent opłaca rachunek samodzielnie. Śledzenie go pomaga ocenić skuteczność i sprawność pobierania należności od pacjentów.

Skąd pobrać

Dane są zapisywane w tabeli korespondencji z pacjentem lub historii generowania zestawień. Znacznik czasu wskazuje, kiedy zestawienie utworzono lub wysłano.

Rejestrowanie

Znacznik czasu z dziennika lub tabeli historii generowania zestawień dla pacjentów.

Typ zdarzenia explicit
Zakończono kodowanie
Oznacza, że koderzy medyczni przejrzeli dokumentację kliniczną i przypisali odpowiednie kody CPT, HCPCS i ICD. Zwykle jest to jawne zdarzenie zarejestrowane przez użytkownika lub automatyczny silnik kodujący po zakończeniu zadania.
Dlaczego to ważne

Kodowanie często stanowi wąskie gardło i może opóźniać wysyłanie roszczeń. Śledzenie tego działania pomaga mierzyć wydajność koderów i wykrywać opóźnienia w kolejce kodowania.

Skąd pobrać

Zdarzenie jest rejestrowane w module workflow do kodowania lub jako zmiana statusu zdarzenia rozliczeniowego z „Oczekuje na kodowanie” na „Zakodowano”. Wykorzystuje się znacznik czasu zmiany statusu lub zakończenia zadania.

Rejestrowanie

Znacznik czasu aktualizacji statusu lub wpisu w dzienniku, gdy użytkownik albo system kończy kodowanie wizyty.

Typ zdarzenia explicit
Zarejestrowano opłaty
Oznacza moment formalnego wprowadzenia do systemu rozliczeniowego konkretnych usług i materiałów podlegających rozliczeniu. Jest to jawne działanie użytkownika lub systemu, które tworzy rekordy transakcji dotyczących opłat.
Dlaczego to ważne

To działanie pozwala mierzyć opóźnienie w rejestrowaniu opłat, czyli czas między wykonaniem usługi a rozpoczęciem rozliczenia. Skrócenie tego czasu przyspiesza cały cykl przychodów.

Skąd pobrać

Informacje znajdują się w tabelach transakcji dotyczących opłat, często nazwanych tabelami wprowadzania opłat lub pozycji usług. Czas utworzenia rekordu opłaty jest czasem zdarzenia.

Rejestrowanie

Zdarzenie oznacza czas utworzenia rekordu w tabeli głównej opłat lub tabeli transakcji dotyczących opłat.

Typ zdarzenia explicit
Zalecane Opcjonalne

Instrukcje pozyskiwania danych

Jak pobrać dane z Optum360

Metody ekstrakcji danych dla tego procesu są obecnie weryfikowane. Prosimy wrócić później lub skontaktować się z nami w celu uzyskania pomocy.

Gotowi do rozpoczęcia?

Skorzystajcie z tego szablonu, aby usprawnić zbieranie danych i rozpocząć ulepszanie procesów zarządzania cyklem przychodów. Odkryjcie zależności w danych i zwiększcie efektywność działania.

Usprawnijcie zarządzanie cyklem przychodów i ograniczcie opóźnienia

Dołączcie do organizacji, które skróciły czas cyklu o 30% i poprawiły kondycję finansową.

Rozpocznijcie okres próbny

Nie trzeba podawać danych karty płatniczej. Konfiguracja zajmuje kilka minut.