Szablon danych ścieżki pacjenta
Szablon danych ścieżki pacjenta
- Zalecane atrybuty kliniczne
- Najważniejsze kamienie milowe procesu
- Wskazówki dotyczące ekstrakcji danych z MEDITECH
Atrybuty ścieżki pacjenta
| Nazwa | Opis | ||
|---|---|---|---|
| Data ostatniej aktualizacji danych LastDataUpdate | Znacznik czasu ostatniej ekstrakcji lub odświeżenia danych. | ||
| Opis Informuje, kiedy rekord został ostatnio przetworzony lub załadowany do narzędzia process mining. Ułatwia kontrolę aktualności danych i sprawdzenie, czy analiza odzwierciedla bieżący stan systemu. Różni się od znacznika czasu zdarzenia, ponieważ dotyczy technicznego przetwarzania danych, a nie czasu zdarzenia klinicznego. Dlaczego to ważne Niezbędny do zarządzania danymi i zapewnienia, że analiza opiera się na aktualnych informacjach. Skąd pobrać Data systemowa w chwili wykonania ETL. Przykłady 2023-11-01T00:00:00Z2023-11-02T12:00:00Z | |||
| Nazwa czynności ActivityName | Konkretne działanie kliniczne lub administracyjne. | ||
| Opis Ten atrybut określa nazwę zdarzenia lub czynności w przebiegu opieki nad pacjentem. Obejmuje poszczególne etapy, takie jak „Rejestracja pacjenta”, „Podanie leku” czy „Wystawienie zlecenia wypisu”. Prawidłowe rozpoznanie czynności jest niezbędne do zmapowania przebiegu procesu. Wartości te pochodzą zwykle z kodów transakcji, statusów zleceń lub udokumentowanych interwencji w elektronicznej dokumentacji medycznej. Dlaczego to ważne Określa etapy procesu i jest niezbędny do wizualizacji mapy procesu. Skąd pobrać Dane pochodzą z różnych dzienników transakcji, takich jak OE Orders, NUR Interventions i ADM Events. Przykłady Rejestracja pacjentaZakończenie triagePodanie lekuWeryfikacja wyniku badania diagnostycznego | |||
| Patient Episode PatientEpisode | Unikalny identyfikator określonego okresu opieki nad pacjentem lub wizyty. | ||
| Opis Patient Episode pełni funkcję głównego identyfikatora sprawy w analizie procesu. Łączy wszystkie zdarzenia kliniczne, administracyjne i finansowe związane z jednym pobytem w szpitalu lub wizytą ambulatoryjną, tworząc spójny przebieg opieki. W systemach MEDITECH zwykle odpowiada numerowi konta lub identyfikatorowi wizyty. Ten atrybut jest niezbędny do odtworzenia przebiegu opieki od rejestracji do wypisu, obliczenia czasu hospitalizacji i analizy ścieżek klinicznych. Dlaczego to ważne To wymagany identyfikator sprawy, który pozwala połączyć różne zdarzenia w jedną instancję procesu. Skąd pobrać Moduł MEDITECH Admissions lub Registration, zwykle pole Account Number. Przykłady V100938475AC29384755E993847211O229384711 | |||
| System źródłowy SourceSystem | Identyfikator systemu, z którego pochodzą dane. | ||
| Opis Wskazuje instancję MEDITECH lub konkretny moduł, z którego wyodrębniono dane o zdarzeniach. W środowiskach obejmujących wiele szpitali pozwala odróżnić dane z poszczególnych placówek lub wersji systemu. Podczas ekstrakcji z jednego systemu atrybut ten ma stałą wartość. Jest jednak niezbędny przy łączeniu danych i tworzeniu wspólnego obrazu sieci szpitali. Dlaczego to ważne Zapewnia pochodzenie i identyfikowalność danych w środowiskach wielosystemowych. Skąd pobrać Wartość ustawiana na stałe podczas ekstrakcji lub konfiguracji identyfikatora systemu. Przykłady MEDITECH_ExpanseMEDITECH_6.1Hospital_A_Main | |||
| Znacznik czasu zdarzenia EventTimestamp | Dokładna data i godzina wykonania czynności. | ||
| Opis Ten atrybut zapisuje dokładny moment wykonania czynności. Służy do uporządkowania zdarzeń chronologicznie i obliczania czasu między kolejnymi etapami procesu. Dokładne znaczniki czasu są niezbędne do rzetelnej analizy oczekiwania, na przykład czasu od triage do oceny pacjenta lub czasu realizacji badań diagnostycznych. Dlaczego to ważne Niezbędny do uporządkowania zdarzeń oraz obliczenia czasu cyklu i przepustowości. Skąd pobrać Kolumny daty i godziny transakcji w tabelach źródłowych. Przykłady 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:45:00Z | |||
| Czy ponowne przyjęcie IsReadmission | Flaga wskazująca, czy epizod rozpoczął się w ciągu 30 dni od poprzedniego wypisu. | ||
| Opis Atrybut logiczny przyjmuje wartość true, jeśli data bieżącej rejestracji pacjenta przypada w ciągu 30 dni od daty wypisu z poprzedniego epizodu. Wspiera dashboard „Ponowne przyjęcia i jakość opieki”. Wykrywanie ponownych przyjęć pozwala prześledzić poprzedni epizod i znaleźć braki w planowaniu wypisu lub dalszej opiece. Dlaczego to ważne Ważny wskaźnik jakości, który wpływa na refundację i wyniki leczenia pacjentów. Skąd pobrać Obliczany przez porównanie bieżącego StartTime z poprzednim Case EndTime dla tego samego MedicalRecordNumber. Przykłady truefalse | |||
| Miejsce przekazania po wypisie DischargeDisposition | Miejsce lub status pacjenta po wypisie. | ||
| Opis Wskazuje, dokąd trafił pacjent po zakończeniu epizodu, na przykład do domu, zakładu opiekuńczo-leczniczego, opieki domowej lub zmarł. To jeden z głównych wskaźników wynikowych na dashboardzie „Optymalizacja planowania wypisu”. Analiza tych danych pomaga ustalić, czy opóźnienia w organizacji opieki po hospitalizacji wydłużają pobyt pacjenta. Dlaczego to ważne Ważny wskaźnik wynikowy przy analizie długości pobytu i ryzyka ponownego przyjęcia. Skąd pobrać Ekrany kodowania wypisu lub rejestracji. Przykłady Wypis do domuPrzekazanie do szpitala ogólnego na krótki pobytZgonWypis na własne żądanie wbrew zaleceniom lekarza | |||
| Numer dokumentacji medycznej MedicalRecordNumber | Unikalny identyfikator pacjenta używany podczas wszystkich wizyt. | ||
| Opis Numer dokumentacji medycznej (MRN) jednoznacznie identyfikuje pacjenta w organizacji ochrony zdrowia. Różni się od identyfikatora konkretnego epizodu i pozwala analitykom łączyć epizody tego samego pacjenta z różnych okresów. Atrybut ten jest niezbędny na dashboardzie „Ponowne przyjęcia i jakość opieki”. Umożliwia wykrywanie pacjentów ponownie przyjętych do szpitala w ciągu 30 dni od wypisu. Dlaczego to ważne Umożliwia analizę wielu epizodów oraz tworzenie widoków skoncentrowanych na pacjencie. Skąd pobrać Główny indeks pacjentów lub tabela rejestracyjna. Przykłady MRN-100293MRN-55928388291002 | |||
| Oddział szpitalny HospitalDepartment | Konkretna jednostka lub oddział, w którym miało miejsce działanie. | ||
| Opis Wskazuje jednostkę organizacyjną odpowiedzialną za działanie, na przykład oddział ratunkowy, radiologię, OIT lub oddział ogólny. Atrybut ten jest niezbędny na dashboardzie „Przepustowość zasobów oddziałów”. Pozwala porównywać wskaźniki efektywności między jednostkami i wskazywać wąskie gardła w przekazywaniu pacjentów oraz wykorzystaniu zasobów. Dlaczego to ważne Przydatny w analizie organizacyjnej i wykrywaniu wąskich gardeł w poszczególnych jednostkach. Skąd pobrać Pola lokalizacji lub oddziału w tabelach transakcyjnych. Przykłady Oddział ratunkowyRadiologiaOddział intensywnej terapiiOddział chirurgiczny 3 | |||
| Personel prowadzący AttendingProvider | Lekarz lub inny pracownik medyczny odpowiedzialny za dane działanie. | ||
| Opis Zapisuje nazwisko lub identyfikator lekarza, pielęgniarki albo technika wykonującego zadanie lub nadzorującego opiekę. Atrybut ten wspiera dashboard „Tempo opracowywania planu leczenia”, przypisując wskaźniki szybkości i efektywności do konkretnych pracowników lub ról. Umożliwia analizę zasobów, równoważenie obciążenia pracą i określanie potrzeb szkoleniowych personelu medycznego. Dlaczego to ważne Umożliwia analizę efektywności zasobów i równoważenie obciążenia pracą. Skąd pobrać Pola Provider lub User w dziennikach działań. Przykłady Dr SmithPielęgniarka JonesTechnik Adams | |||
| Poziom pilności w triage TriageAcuityLevel | Ocena ciężkości stanu pacjenta przypisana podczas triage. | ||
| Opis Określa pilność stanu pacjenta, zwykle w skali, na przykład od 1 do 5, gdzie 1 oznacza stan krytyczny. Atrybut ten jest podstawą analizy przepływu pacjentów na oddziale ratunkowym. Pozwala zestawić czas oczekiwania z ciężkością stanu pacjenta i sprawdzić, czy osoby w najpoważniejszym stanie otrzymują odpowiedni priorytet. Dlaczego to ważne Niezbędny do analizy priorytetyzacji pacjentów na oddziale ratunkowym i zgodności z wymogami bezpieczeństwa. Skąd pobrać Ekrany oceny pielęgniarskiej na oddziale ratunkowym lub podczas triage. Przykłady 1 - Resuscytacja2 - Stan nagły3 - Stan pilny4 - Mniej pilny | |||
| Rodzaj wizyty pacjenta PatientType | Kategoria wizyty pacjenta, na przykład hospitalizacja, wizyta ambulatoryjna lub nagły przypadek. | ||
| Opis Określa charakter wizyty w szpitalu. Typowe wartości to „Hospitalizacja”, „Wizyta ambulatoryjna”, „Nagły przypadek” lub „Obserwacja”. Klasyfikacja ta ma podstawowe znaczenie przy filtrowaniu i porównywaniu procesów, ponieważ standard opieki i oczekiwany czas trwania znacznie różnią się w zależności od rodzaju wizyty. Pole to wspiera dashboard „Optymalizacja planowania wypisu”, umożliwiając segmentację oczekiwanego czasu pobytu. Dlaczego to ważne Podstawowy podział przy porównywaniu procesów, hospitalizacja i wizyta ambulatoryjna. Skąd pobrać Tabele przyjęć lub wizyt, na przykład AdmVisits.Status. Przykłady HospitalizacjaNagły przypadekOperacja ambulatoryjnaObserwacja | |||
| Rozpoznanie główne PrimaryDiagnosis | Główny stan chorobowy rozpoznany w danym epizodzie opieki nad pacjentem. | ||
| Opis Zawiera kod ICD-10 lub opis głównej przyczyny wizyty. To podstawa analizy wariantów ścieżek klinicznych. Grupując przypadki według rozpoznania głównego, kierownicy kliniczni mogą porównywać rzeczywisty przebieg leczenia z zalecaną ścieżką kliniczną dla danego schorzenia. Dlaczego to ważne Niezbędny do grupowania przypadków i analizy ścieżek klinicznych. Skąd pobrać Moduł dokumentacji medycznej lub kodowania danych klinicznych. Przykłady J18.9 - Zapalenie płucI21.9 - Ostry zawał mięśnia sercowegoS72.0 - Złamanie kości udowej | |||
| Czas oczekiwania na triage TriageWaitTime | Czas od rejestracji do zakończenia triage. | ||
| Opis Obliczany czas między zdarzeniami „Rejestracja pacjenta” i „Zakończenie triage”. Bezpośrednio zasila KPI „Średni czas triage”. Monitorowanie tego czasu pomaga kierownikom oddziałów ratunkowych dostosować obsadę w godzinach szczytu i utrzymać wymagany poziom bezpieczeństwa pacjentów. Dlaczego to ważne Ważny wskaźnik operacyjny dla oddziałów ratunkowych. Skąd pobrać Różnica obliczona na podstawie znaczników czasu wybranych działań. Przykłady 15 minut1 godzina 20 minut | |||
| Czy naruszono zgodność ze ścieżką IsAdherenceViolation | Flaga wskazująca, czy przypadek odbiegał od standardowej ścieżki klinicznej. | ||
| Opis Flaga logiczna przyjmuje wartość true, jeśli kolejność działań nie odpowiada modelowi referencyjnemu określonemu dla rozpoznania głównego pacjenta. Wspiera analizę wariantów ścieżek klinicznych. Pozwala szybko odfiltrować przypadki niezgodne ze standardem i sprawdzić, dlaczego nie zastosowano zalecanego standardu opieki. Dlaczego to ważne Szybko wskazuje odchylenia i różnice w przebiegu procesu. Skąd pobrać Obliczany przez algorytmy weryfikacji zgodności. Przykłady truefalse | |||
| Kategoria zlecenia OrderCategory | Klasyfikacja zleceń klinicznych, na przykład laboratoryjne, radiologiczne lub konsultacyjne. | ||
| Opis Grupuje zlecenia w szersze kategorie, takie jak badania laboratoryjne, radiologia, dieta lub konsultacje. Jest niezbędna na dashboardzie „Czas realizacji usług diagnostycznych”. Pozwala analizować osobno przebieg badań obrazowych i badań krwi, których czasy realizacji często ograniczają różne wąskie gardła. Dlaczego to ważne Umożliwia podział procesów diagnostycznych i leczniczych na segmenty. Skąd pobrać Pola kategorii w module Order Entry (OE). Przykłady LaboratoriumRadiologiaPielęgniarstwoFarmacja | |||
| Kwota obciążenia ChargeAmount | Wartość finansowa przypisana do konkretnego działania lub usługi. | ||
| Opis Oznacza koszt lub opłatę zaksięgowaną dla danego zdarzenia, na przykład badania lub pobytu w sali. Choć dotyczy przede wszystkim finansów, wiąże się również z wykorzystaniem zasobów. Zestawienie tych danych pomaga ocenić finansowy wpływ różnic w przebiegu procesu, choć głównym celem analizowanego widoku jest przepływ kliniczny. Dlaczego to ważne Uzupełnia analizę procesu o wymiar finansowy. Skąd pobrać Moduł rozliczeń lub BAR (Billing/Accounts Receivable). Przykłady 150.001200.5045.00 | |||
| Nazwa leku MedicationName | Nazwa podanego leku. | ||
| Opis Zapisuje konkretny lek w zdarzeniach „Podano lek”. Jest wymagany na dashboardzie „Zgodność z zasadami podawania leków”. Umożliwia kierownictwu pielęgniarskiemu sprawdzenie, czy leki wysokiego ryzyka lub wymagające podania o określonej porze, takie jak antybiotyki przy sepsie, są podawane w odpowiednim czasie. Dlaczego to ważne Niezbędny do analizy zgodności z wymogami klinicznymi i bezpieczeństwa. Skąd pobrać Moduły Pharmacy (PHA) lub Bedside Verification (BMV). Przykłady ParacetamolWankomycynaHeparynaInsulina | |||
| Źródło przyjęcia AdmitSource | Miejsce, z którego przybył pacjent, na przykład dom, przekazanie lub skierowanie. | ||
| Opis Opisuje źródło przyjęcia pacjenta, na przykład skierowanie od lekarza, oddział ratunkowy lub przekazanie z innego szpitala. Pokazuje, w jaki sposób pacjenci trafiają do systemu. Pomaga analizować napływ pacjentów oraz jego wpływ na przepływ na oddziale ratunkowym i planowanie zasobów. Dlaczego to ważne Pokazuje źródła napływu pacjentów i kanały zgłoszeń. Skąd pobrać Dane rejestracyjne dotyczące przyjęć. Przykłady Oddział ratunkowySkierowanie z poradniPrzekazanie z placówki opieki długoterminowej | |||
Czynności w ścieżce pacjenta
| Działanie | Opis | ||
|---|---|---|---|
| Podanie leku | Rejestruje faktyczne podanie leku pacjentowi przez personel pielęgniarski. Zwykle zdarzenie jest rejestrowane przez skanowanie kodu kreskowego przy łóżku pacjenta. | ||
| Dlaczego to ważne Wspiera analizę zgodności z procedurami podawania leków. Pomaga wykrywać zagrożenia dla bezpieczeństwa i przerwy w workflow na oddziałach pielęgniarskich. Skąd pobrać MEDITECH PHA (Pharmacy) lub eMAR (Electronic Medication Administration Record). Pole 'AdminDateTime' w historii podawania leków. Rejestrowanie Rejestrowane po wykonaniu transakcji Med Admin Typ zdarzenia explicit | |||
| Rejestracja pacjenta | To zdarzenie oznacza administracyjne utworzenie w systemie rekordu hospitalizacji lub wizyty pacjenta. Rejestruje początek procesu w module MEDITECH ADM (Admissions). | ||
| Dlaczego to ważne Wyznacza początek przebiegu opieki nad pacjentem i punkt startowy do obliczania czasu cyklu. Jest niezbędne do obliczenia całkowitego czasu hospitalizacji. Skąd pobrać Moduł MEDITECH ADM. Dane pochodzą z tabeli 'Admissions', konkretnie z pola 'AdmitDateTime' lub znacznika czasu utworzenia wpisu w dzienniku transakcji. Rejestrowanie Rejestrowane po wykonaniu transakcji New Visit Typ zdarzenia explicit | |||
| Transfer pacjenta | Oznacza fizyczne przeniesienie pacjenta z jednej lokalizacji, oddziału, sali lub łóżka, do innej. Pozwala śledzić przepływ pacjentów w szpitalu. | ||
| Dlaczego to ważne Pomaga wykrywać wąskie gardła przy transferach wewnętrznych. Długi czas transferu może wskazywać na konkurencję o zasoby lub opóźnienia w transporcie pacjentów. Skąd pobrać MEDITECH ADM (Admissions). Dane pochodzą z dzienników transakcji 'Location History' lub 'RoomBed'. Rejestrowanie Rejestrowane po wykonaniu transakcji Transfer Patient Typ zdarzenia explicit | |||
| Udokumentowanie diagnozy | Moment, w którym klinicysta wpisuje do dokumentacji pacjenta diagnozę z kodem ICD-10. Często uruchamia to określoną ścieżkę kliniczną. | ||
| Dlaczego to ważne Umożliwia analizę wariantów ścieżek klinicznych przez kategoryzację przypadku. Jest niezbędne do grupowania pacjentów na potrzeby porównań. Skąd pobrać Moduł MEDITECH ABS (Abstracting) lub Medical Records. Zdarzenie jest rejestrowane po przypisaniu kodów diagnozy do konta. Rejestrowanie Rejestrowane po wykonaniu transakcji Diagnosis Enter Typ zdarzenia explicit | |||
| Weryfikacja wyniku badania diagnostycznego | Oznacza wykonanie badania diagnostycznego, laboratoryjnego lub radiologicznego, i zatwierdzenie wyniku przez technika lub radiologa. Tym samym zamyka proces realizacji zlecenia diagnostycznego. | ||
| Dlaczego to ważne Wyznacza koniec pomiaru 'Diagnostic Services Turnaround'. Jest niezbędne do analizy wąskich gardeł w oddziałach świadczących usługi pomocnicze. Skąd pobrać Moduły MEDITECH LAB lub ITS (Imaging and Therapeutic Services). Zdarzenie można ustalić na podstawie zmiany statusu wyniku na Verified lub Signed. Rejestrowanie Rejestrowane po zmianie pola statusu na Verified Typ zdarzenia explicit | |||
| Wypisanie pacjenta | Administracyjne zamknięcie wizyty. Pacjent opuścił placówkę, a łóżko zostało zwolnione. | ||
| Dlaczego to ważne Formalny koniec procesu. Zdarzenie służy do obliczenia całkowitego czasu hospitalizacji i wyznaczenia 30-dniowego okresu ponownego przyjęcia. Skąd pobrać MEDITECH ADM (Admissions). Pole 'DischargeDateTime' w rekordzie wizyty. Rejestrowanie Rejestrowane po wykonaniu transakcji Discharge Patient Typ zdarzenia explicit | |||
| Wystawienie zlecenia wypisu | Znacznik czasu podpisania przez lekarza zlecenia upoważniającego do wypisu pacjenta. Oznacza początek etapu planowania wypisu. | ||
| Dlaczego to ważne Wyznacza punkt początkowy pomiaru czasu planowania wypisu. Czas od wystawienia zlecenia do faktycznego wyjścia pacjenta wskazuje na nieefektywność operacyjną. Skąd pobrać MEDITECH OE (Order Entry). Zlecenia można filtrować według Category = Discharge. Rejestrowanie Rejestrowane po wykonaniu transakcji Order Enter Typ zdarzenia explicit | |||
| Zakończenie triage | Oznacza zakończenie wstępnej oceny pielęgniarskiej na oddziale ratunkowym. Na jej podstawie określa się pilność przypadku i poziom ciężkości stanu pacjenta. | ||
| Dlaczego to ważne Niezbędne w dashboardzie analizy przepływu pacjentów na oddziale ratunkowym do pomiaru przepustowości i czasu oczekiwania. Skąd pobrać Moduł MEDITECH EDM (Emergency Department Management). Zdarzenie można ustalić na podstawie zmian statusu w rejestrze EDM lub znacznika czasu dokumentu Triage Assessment. Rejestrowanie Rejestrowane po zmianie pola statusu na Triaged Typ zdarzenia explicit | |||
| Złożenie zlecenia | Rejestruje zlecenie usługi, leku lub badania diagnostycznego wystawione przez klinicystę. To zdarzenie rozpoczyna kolejne działania kliniczne. | ||
| Dlaczego to ważne Wyznacza punkt początkowy KPI 'Diagnostic Services Turnaround'. Porównanie z czasem realizacji pozwala wykryć opóźnienia w świadczeniu usług. Skąd pobrać Moduł MEDITECH OE (Order Entry). Dane pochodzą z tabeli 'OeOrders', z pola Order Date/Time. Rejestrowanie Rejestrowane po wykonaniu transakcji Order Enter Typ zdarzenia explicit | |||
| Pobranie próbki | Oznacza fizyczne pobranie materiału biologicznego do analizy laboratoryjnej. Ten etap łączy zlecenie badania z jego realizacją. | ||
| Dlaczego to ważne Szczegółowy etap, który często powoduje opóźnienia w procesie diagnostycznym. Pomaga odróżnić opóźnienia po stronie pielęgniarskiej od opóźnień w laboratorium. Skąd pobrać Moduł MEDITECH LAB. Zdarzenie jest zwykle rejestrowane po zeskanowaniu kodu kreskowego przez osobę pobierającą krew lub zmianie statusu próbki na Collected. Rejestrowanie Rejestrowane po wykonaniu transakcji Collect Specimen Typ zdarzenia explicit | |||
| Rozpoczęcie planu opieki | Oznacza utworzenie lub przypisanie konkretnego planu opieki pielęgniarskiej albo interdyscyplinarnej. Odpowiada pojęciu „opracowanie planu leczenia”. | ||
| Dlaczego to ważne Pozwala mierzyć tempo opracowywania planu leczenia. Opóźnienia na tym etapie mogą wskazywać na problemy z podejmowaniem decyzji klinicznych. Skąd pobrać MEDITECH PCS (Patient Care System) lub Care Manager. Znacznik czasu zastosowania standardowego planu opieki u pacjenta. Rejestrowanie Rejestrowane po wykonaniu transakcji Care Plan Add Typ zdarzenia explicit | |||
| Umówienie wizyty kontrolnej | Zaplanowanie przyszłej wizyty pacjenta. To działanie wspiera ciągłość opieki po wypisie. | ||
| Dlaczego to ważne Wspiera analizę planowania wizyt kontrolnych. Wiąże się z niższym odsetkiem ponownych przyjęć. Skąd pobrać MEDITECH SCH (Scheduling). Zdarzenie można ustalić, łącząc nowy rekord Appointment utworzony w pobliżu daty wypisu z identyfikatorem pacjenta. Rejestrowanie Ustalane przez porównanie pól Appointment Created Date i Discharge Date Typ zdarzenia inferred | |||
| Wysłanie prośby o konsultację | Zlecenie konsultacji specjalistycznej. Rozpoczyna pomiar czasu w dashboardzie 'Specialist Consultation Response'. | ||
| Dlaczego to ważne Pomaga wykrywać wąskie gardła w koordynacji opieki wielodyscyplinarnej. Długi czas oczekiwania wydłuża pobyt w szpitalu. Skąd pobrać MEDITECH OE (Order Entry). Zdarzenie można zidentyfikować, filtrując tabelę 'OeOrders' według Category = Consult. Rejestrowanie Rejestrowane po wykonaniu transakcji Order Enter Typ zdarzenia explicit | |||
| Zakończenie konsultacji | Zakończenie oceny przez specjalistę. Często można je ustalić na podstawie zapisania dokumentu określonego typu, np. 'Cardiology Consult Note'. | ||
| Dlaczego to ważne Wyznacza koniec pomiaru czasu reakcji specjalisty. Jest niezbędne do zapewnienia terminowego przebiegu opieki. Skąd pobrać MEDITECH PCM (Provider Order Management) lub EMR. Zdarzenie można ustalić na podstawie znaczników czasu utworzenia dokumentów o określonych tytułach. Rejestrowanie Porównaj pole statusu przed zmianą i po niej Typ zdarzenia inferred | |||
Instrukcje ekstrakcji danych
Kroki
Znajdź serwer repozytorium danych: Ustal instancję Microsoft SQL Server, na której znajduje się MEDITECH Data Repository (DR). Jest ona odrębna od transakcyjnej bazy M-AT i bazy opartej na plikach. Potrzebne będą dane logowania z uprawnieniami tylko do odczytu, zazwyczaj konto usługi.
Ustal wersję schematu: Struktury MEDITECH DR nieznacznie różnią się między wersjami Magic, Client/Server (6.x) i Expanse. Poniższe zapytanie korzysta ze standardowych nazw, np. AdmVisits i OeOrders. Sprawdź nazwy tabel w Object Explorer w lokalnym SQL Server Management Studio (SSMS).
Określ zakres danych: Znajdź główną tabelę wizyt pacjentów. W zależności od konfiguracji DR może nazywać się AdmVisits, RegAcct lub AbstractData. W zapytaniu tabela AdmVisits pełni rolę punktu odniesienia dla epizodu pacjenta.
Przygotuj środowisko SQL: Otwórz SSMS i połącz się z DR. Otwórz nowe okno zapytania. Upewnij się, że wybrana jest właściwa baza danych, często o nazwie livedb lub podobnej.
Skonfiguruj parametry: W dostarczonym skrypcie SQL zastąp przykładowe zakresy dat, np. „2023-01-01”, oraz identyfikatory placówek, jeśli DR obsługuje kilka lokalizacji.
Uruchom ekstrakcję: Wykonaj cały skrypt T-SQL. Najpierw definiuje on interesującą populację za pomocą Common Table Expressions (CTE), a następnie łączy wiele źródeł danych operatorem UNION ALL, tworząc ujednolicony dziennik zdarzeń.
Obsłuż atrybuty NULL: Zapytanie zawiera logikę obsługi brakujących wartości NULL w znacznikach czasu, w razie potrzeby z użyciem COALESCE. Sprawdza też, czy dostępne są wymagane klucze łączenia, takie jak SourceID i VisitID.
Sprawdź dane z triażu i oddziału ratunkowego: MEDITECH przechowuje dane z oddziału ratunkowego w określonych modułach. Jeśli analizują Państwo workflow oddziału ratunkowego, należy sprawdzić, czy tabele EdVisits lub NurInterventions zawierają dane.
Zweryfikuj kategorie zleceń: Zapytanie rozdziela zlecenia ogólne, konsultacje i zlecenia wypisu na podstawie kategorii, identyfikatorów URN lub skrótów. Może być konieczna zmiana warunków WHERE, aby dopasować je do słownika skrótów używanego w placówce.
Wyeksportuj dane: Po wyświetleniu wyników kliknij prawym przyciskiem myszy siatkę wyników w SSMS i wybierz „Save Results As CSV”. Upewnij się, że eksport zawiera nagłówki.
Sprawdź format: Przed zaimportowaniem otwórz plik CSV i sprawdź, czy daty są zgodne z ISO 8601 (YYYY-MM-DD HH:MM:SS).
Konfiguracja
- Dostęp do bazy danych: Wymagane są uprawnienia db_datareader do bazy MEDITECH DR SQL.
- Zakres dat: Zaleca się ekstrakcję danych wypisanych pacjentów z okresu od 3 do 6 miesięcy, aby uwzględnić zakończone cykle.
- Filtrowanie placówek: Jeśli DR zawiera dane z wielu placówek, filtruj CTE BaseVisits według FacilityID lub SourceSystemID.
- Definicja epizodu: Skrypt używa unikatowego VisitID, często nazywanego Account Number lub Episode Number, jako identyfikatora Case.
- Wydajność: Zapytanie ogranicza zakres skanowania za pomocą CTE. Aby zapewnić wydajne działanie, sprawdź, czy w tabeli AdmVisits istnieją indeksy dla AdmitDate i DischargeDate.
- Opóźnienie danych: Transfer danych z Data Repository może trwać od 15 minut do 24 godzin, zależnie od konfiguracji placówki. Sprawdź znacznik czasu LastDataUpdate.
Przykładowe zapytanie sql
/* MEDITECH Data Repository T-SQL Extraction for ProcessMind */
/* Process: Patient Journey */
/* Dialect: T-SQL */
WITH BaseVisits AS (
/* Define the population: Discharged patients within a date range */
SELECT
V.VisitID,
V.PatientID,
V.AccountNumber AS MedicalRecordNumber,
V.AdmitDateTime,
V.DischargeDateTime,
V.FacilityID,
V.PatientType,
V.AttendingProviderID,
V.DischargeDisposition,
NULLIF(DATEDIFF(MINUTE, V.AdmitDateTime, V.DischargeDateTime), 0) / 1440.0 AS LengthOfStay,
/* Flag readmissions logic would go here, simplified as 0 for base script */
0 AS IsReadmission
FROM
[YourDatabaseName].[dbo].[AdmVisits] V
WHERE
V.DischargeDateTime >= '2023-01-01'
AND V.DischargeDateTime < '2023-04-01'
AND V.Status = 'DIS' /* Discharged Status */
),
PatientDiagnoses AS (
/* Helper CTE for Primary Diagnosis to avoid duplicates in joins */
SELECT
D.VisitID,
MAX(D.ICDCode) AS PrimaryDiagnosis
FROM
[YourDatabaseName].[dbo].[AbsDiagnoses] D
WHERE
D.Rank = 1 /* Primary Diagnosis Rank */
GROUP BY
D.VisitID
),
TriageData AS (
/* Helper CTE for Triage Acuity */
SELECT
T.VisitID,
MAX(T.AcuityLevel) AS TriageAcuityLevel
FROM
[YourDatabaseName].[dbo].[EdTriage] T
GROUP BY
T.VisitID
)
/* 1. Patient Registered */
SELECT
V.VisitID AS PatientEpisode,
'Patient Registered' AS ActivityName,
V.AdmitDateTime AS EventTimestamp,
'MEDITECH_ADM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
V.FacilityID AS HospitalDepartment,
V.AttendingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
BaseVisits V
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
V.AdmitDateTime IS NOT NULL
UNION ALL
/* 2. Triage Completed */
SELECT
V.VisitID AS PatientEpisode,
'Triage Completed' AS ActivityName,
ED.TriageDateTime AS EventTimestamp,
'MEDITECH_ED' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
'Emergency Department' AS HospitalDepartment,
ED.TriageNurseID AS AttendingProvider,
V.PatientType,
ED.AcuityLevel AS TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[EdTriage] ED
INNER JOIN BaseVisits V ON ED.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
WHERE
ED.TriageDateTime IS NOT NULL
UNION ALL
/* 3. Order Placed (General) */
SELECT
V.VisitID AS PatientEpisode,
'Order Placed' AS ActivityName,
O.OrderDateTime AS EventTimestamp,
'MEDITECH_OE' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
O.Department AS HospitalDepartment,
O.OrderingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[OeOrders] O
INNER JOIN BaseVisits V ON O.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
O.Category NOT IN ('CONSULT', 'DISCHARGE') /* Exclude specific types handled elsewhere */
UNION ALL
/* 4. Specimen Collected */
SELECT
V.VisitID AS PatientEpisode,
'Specimen Collected' AS ActivityName,
L.CollectionDateTime AS EventTimestamp,
'MEDITECH_LAB' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
'Laboratory' AS HospitalDepartment,
L.CollectedBy AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[LabSpecimens] L
INNER JOIN BaseVisits V ON L.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
L.CollectionDateTime IS NOT NULL
UNION ALL
/* 5. Diagnostic Result Verified */
SELECT
V.VisitID AS PatientEpisode,
'Diagnostic Result Verified' AS ActivityName,
R.VerifiedDateTime AS EventTimestamp,
'MEDITECH_LAB' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
'Laboratory' AS HospitalDepartment,
R.VerifiedBy AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[LabResults] R
INNER JOIN BaseVisits V ON R.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
R.VerifiedDateTime IS NOT NULL
UNION ALL
/* 6. Diagnosis Documented */
SELECT
V.VisitID AS PatientEpisode,
'Diagnosis Documented' AS ActivityName,
DX.EntryDateTime AS EventTimestamp,
'MEDITECH_ABS' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
V.FacilityID AS HospitalDepartment,
DX.ProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[AbsDiagnoses] DX
INNER JOIN BaseVisits V ON DX.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
DX.EntryDateTime IS NOT NULL
UNION ALL
/* 7. Care Plan Initiated */
SELECT
V.VisitID AS PatientEpisode,
'Care Plan Initiated' AS ActivityName,
N.CreateDateTime AS EventTimestamp,
'MEDITECH_NUR' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
N.NurseUnit AS HospitalDepartment,
N.NurseID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[NurPlan] N
INNER JOIN BaseVisits V ON N.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
N.CreateDateTime IS NOT NULL
UNION ALL
/* 8. Medication Administered */
SELECT
V.VisitID AS PatientEpisode,
'Medication Administered' AS ActivityName,
M.AdminDateTime AS EventTimestamp,
'MEDITECH_PHA' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
M.AdminLocation AS HospitalDepartment,
M.AdministeredBy AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[PhaMedAdmin] M
INNER JOIN BaseVisits V ON M.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
M.Status = 'ADMINISTERED'
UNION ALL
/* 9. Consult Request Sent */
SELECT
V.VisitID AS PatientEpisode,
'Consult Request Sent' AS ActivityName,
O.OrderDateTime AS EventTimestamp,
'MEDITECH_OE' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
O.Department AS HospitalDepartment,
O.OrderingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[OeOrders] O
INNER JOIN BaseVisits V ON O.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
O.Category = 'CONSULT'
UNION ALL
/* 10. Consultation Completed */
SELECT
V.VisitID AS PatientEpisode,
'Consultation Completed' AS ActivityName,
O.CompletedDateTime AS EventTimestamp,
'MEDITECH_OE' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
O.Department AS HospitalDepartment,
O.OrderingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[OeOrders] O
INNER JOIN BaseVisits V ON O.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
O.Category = 'CONSULT'
AND O.Status = 'COMPLETED'
AND O.CompletedDateTime IS NOT NULL
UNION ALL
/* 11. Patient Transferred */
SELECT
V.VisitID AS PatientEpisode,
'Patient Transferred' AS ActivityName,
TX.TransferDateTime AS EventTimestamp,
'MEDITECH_ADM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
TX.ToLocation AS HospitalDepartment,
NULL AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[AdmRoomTx] TX
INNER JOIN BaseVisits V ON TX.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
TX.TransferDateTime IS NOT NULL
UNION ALL
/* 12. Discharge Order Written */
SELECT
V.VisitID AS PatientEpisode,
'Discharge Order Written' AS ActivityName,
O.OrderDateTime AS EventTimestamp,
'MEDITECH_OE' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
O.Department AS HospitalDepartment,
O.OrderingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[OeOrders] O
INNER JOIN BaseVisits V ON O.VisitID = V.VisitID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
O.Category = 'DISCHARGE'
OR O.Mnemonic LIKE '%DISCHARGE%'
UNION ALL
/* 13. Patient Discharged */
SELECT
V.VisitID AS PatientEpisode,
'Patient Discharged' AS ActivityName,
V.DischargeDateTime AS EventTimestamp,
'MEDITECH_ADM' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
V.FacilityID AS HospitalDepartment,
V.AttendingProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
BaseVisits V
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
V.DischargeDateTime IS NOT NULL
UNION ALL
/* 14. Follow-up Booked */
SELECT
V.VisitID AS PatientEpisode,
'Follow-up Booked' AS ActivityName,
S.BookDateTime AS EventTimestamp,
'MEDITECH_SCH' AS SourceSystem,
GETDATE() AS LastDataUpdate,
V.MedicalRecordNumber,
S.ApptDepartment AS HospitalDepartment,
S.ProviderID AS AttendingProvider,
V.PatientType,
T.TriageAcuityLevel,
D.PrimaryDiagnosis,
V.DischargeDisposition,
V.LengthOfStay,
V.IsReadmission
FROM
[YourDatabaseName].[dbo].[SchAppt] S
INNER JOIN BaseVisits V ON S.PatientID = V.PatientID
LEFT JOIN PatientDiagnoses D ON V.VisitID = D.VisitID
LEFT JOIN TriageData T ON V.VisitID = T.VisitID
WHERE
S.BookDateTime > V.AdmitDateTime
AND S.BookDateTime <= DATEADD(day, 30, V.DischargeDateTime) /* Logic to link appt to episode */
AND S.Status NOT IN ('CANCELLED', 'NOSHOW'); Gotowi do rozpoczęcia?
Już dziś zastosuj ten szablon do danych z MEDITECH, aby usprawnić operacje kliniczne. Nasz zespół może pomóc dopracować sposób ekstrakcji danych i zwiększyć sprawność działania szpitala.
Usprawnij ścieżkę pacjenta i już teraz ogranicz opóźnienia
Skróć czas realizacji o 30 procent i zwiększ sprawność szpitala
Nie trzeba podawać danych karty płatniczej. Rozpoczęcie zajmuje kilka minut.