Szablon danych do zarządzania cyklem przychodów
Szablon danych do zarządzania cyklem przychodów
- Zalecane atrybuty do zebrania
- Najważniejsze działania do monitorowania
- Wskazówki dotyczące pozyskiwania danych
Atrybuty zarządzania cyklem przychodów
| 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 | |||
Działania w procesie zarządzania cyklem przychodów
| 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 | |||
Instrukcje pozyskiwania danych
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ą.
Nie trzeba podawać danych karty płatniczej. Konfiguracja zajmuje kilka minut.