Integracja

Integracja systemów szpitalnych: HIS i EHR, silniki interfejsów, laboratorium, radiologia, urządzenia noszone i telemedycyna

Jak systemy w szpitalu komunikują się ze sobą i ze światem zewnętrznym: HIS lub EHR w centrum, silnik interfejsów kierujący ruchem HL7 v2 i FHIR, laboratorium i radiologia, apteka, urządzenia, telemedycyna i aplikacje pacjenta. Przepływające komunikaty, działające schematy, tryby awarii i miejsce FHIR w tym wszystkim.

autor Opublikowano 8 min czytania

Krótka odpowiedź: szpital posiada dziesiątki systemów, a integracja to praca polegająca na tym, aby wszystkie te systemy "dogadały się" w kwestii jednego pacjenta. W centrum znajduje się HIS (system informatyczny szpitala) lub EHR, który zarządza tożsamością pacjenta, przyjęciami i dokumentacją medyczną. Wokół niego znajdują się: system laboratorium (LIS), radiologii (RIS i PACS), apteki, bloku operacyjnego, SOR-u, rozliczeń, urządzeń (monitory, pompy infuzyjne), a coraz częściej także aplikacje pacjenta, urządzenia noszone i telemedycyna. Silnik integracyjny (interface engine) pośrodku odbiera, przetwarza i kieruje wiadomości, dzięki czemu każdy system jest podłączony raz, a nie do każdego innego systemu. Ruch odbywa się głównie za pomocą wiadomości HL7 v2 przez MLLP dla zdarzeń (przyjęcia, zlecenia, wyniki), DICOM dla obrazów, CDA lub PDF dla dokumentów, oraz FHIR przez REST dla wszystkiego, co nowe, skierowane do pacjenta lub zewnętrzne.

Systemy i co wymieniają

Krajobraz integracji szpitala tworzą system HIS lub EHR, który zarządza tożsamością pacjenta, wizytami i dokumentacją medyczną, a także system laboratoryjny, radiologia (RIS i PACS), apteka, urządzenia, aplikacje pacjenta, telemedycyna i systemy regionalne. Wymieniają one komunikaty HL7 v2, takie jak ADT, zlecenia i wyniki ORU, obrazy DICOM, dokumenty CDA oraz zasoby FHIR.

System Zarządza Wysyła Odbiera
HIS / EHR Tożsamość pacjenta, wizyty, zlecenia, dokumentacja medyczna ADT (przyjęcia, transfery), zlecenia ORM/OML, harmonogram SIU Wyniki ORU, dokumenty MDM, opłaty DFT
LIS (laboratorium) Próbki, analizy, wyniki, zakresy referencyjne Wyniki ORU^R01, odpowiedzi na zlecenia ORR Zlecenia ORM/OML, ADT dla danych demograficznych
RIS / PACS Zlecenia badań obrazowych, listy pracy, raporty, obrazy Raporty ORU, DICOM do przeglądarek, SIU Zlecenia ORM/OMI, ADT; listy pracy DICOM MWL do aparatury
Apteka Farmakopea, wydawanie leków, zapasy Wydawanie RDS, podawanie RAS Zlecenia leków OMP/RDE, ADT
Urządzenia i monitory Parametry życiowe, przebiegi, alarmy Obserwacje ORU^R01 (IHE PCD), własne formaty ADT dla kontekstu pacjenta
Portal pacjenta / aplikacje Dane wprowadzane przez pacjenta, dostęp Obserwacje FHIR, kwestionariusze, wiadomości Odczyt wyników FHIR, wizyty, dokumenty
Telemedycyna Wizyty wideo, zdalne monitorowanie Wizyta FHIR, Obserwacja, Dokumentacja Wizyta, Kontekst pacjenta, Uruchomienie SMART
Systemy regionalne i krajowe Wspólne rekordy, rejestry, e-recepty Dokumenty CDA (XDS), FHIR, wiadomości krajowe Zapytania, powiadomienia

Silnik integracyjny

Silnik integracyjny to centrum wymiany komunikatów szpitala: odbiera ruch HL7 v2, FHIR, pliki i dane z baz danych z każdego systemu, przekształca je i kieruje do każdego innego systemu, który ich potrzebuje, a także zarządza kolejkami, ponownymi próbami, monitorowaniem i audytem. Bez niego N systemów wymaga do N×(N−1)/2 ręcznie tworzonych interfejsów; z silnikiem każdy system łączy się raz.

Silnik (Mirth Connect / NextGen Connect, Rhapsody, InterSystems HealthShare i IRIS for Health, Infor Cloverleaf, Qvera QIE i inne) zapewnia nasłuchy (MLLP, HTTP, pliki, bazy danych), transformacje (mapowanie pól, poprawianie kodów, konwersja v2 na FHIR), routing (wysyłanie ADT do ośmiu systemów z ośmioma filtrami), kolejkowanie i ponowne próby, monitorowanie i audyt. Jest to również miejsce, gdzie tożsamość pacjenta jest uzgadniana, gdy systemy się nie zgadzają, i gdzie często budowana jest fasada FHIR nad starszą bazą danych. Zobacz Wyjaśnienie silników integracyjnych.

Najważniejsze przepływy

Najważniejsze przepływy integracyjne w szpitalu to ADT (przyjęcia, wypisy, transfery i aktualizacje danych demograficznych rozpowszechniane z systemu HIS), zlecenia i wyniki między EHR a laboratorium lub radiologią, zlecenia leków i ich wydawanie, dokumenty takie jak listy wypisowe, dane z urządzeń monitorujących oraz wymiana wyników, wizyt i pomiarów domowych z pacjentem za pomocą FHIR.

  • ADT: każde przyjęcie, wypis, transfer, rejestracja i aktualizacja danych demograficznych (A01, A03, A02, A04, A08, A40 merge) rozsyłane są z HIS do wszystkich innych. Jeśli ADT jest opóźnione lub błędne, każdy system poniżej przechowuje dane pod niewłaściwym pacjentem lub wizytą. Zobacz Wyjaśnienie wiadomości HL7 v2: ADT i ORU.
  • Zlecenia i wyniki: ORM/OML wychodzące, ORU wracające, z numerami zleceniodawcy i wykonawcy łączącymi je; LOINC i UCUM w wynikach. Zobacz Wiadomości zleceń HL7 v2 i Integracja systemu laboratoryjnego z EHR.
  • Obrazowanie: zlecenia do RIS, listy pracy DICOM do skanerów, obrazy do PACS, raporty z powrotem jako ORU, przeglądarki przez DICOMweb. Zobacz PACS vs RIS vs VNA.
  • Leki: zlecenia do apteki, informacje o wydaniu i podaniu z powrotem, z celem bezpieczeństwa w postaci zamkniętej pętli (kod kreskowy przy łóżku).
  • Dokumenty: listy wypisowe, notatki operacyjne i zeskanowane dokumenty jako wiadomości MDM, CDA lub PDF do repozytorium dokumentów, publikowane w rejestrach regionalnych.
  • Urządzenia: monitory przesyłające parametry życiowe do dokumentacji za pomocą profili IHE PCD lub bramek producenta, z zarządzaniem alarmami jako osobną dziedziną.
  • Dla pacjenta: wyniki, wizyty i dokumenty do portalu i aplikacji przez FHIR; kwestionariusze, pomiary domowe i dane z urządzeń noszonych z powrotem, z oznaczeniem pochodzenia jako dane zgłoszone przez pacjenta. Zobacz Zdalne monitorowanie pacjenta z FHIR.

Działające wzorce

Działające wzorce integracji szpitalnej to: jeden główny system dla tożsamości pacjenta, z subskrypcjami ADT dla wszystkich pozostałych; mapowanie kodów do LOINC, SNOMED CT i ATC raz w silniku; potwierdzenia, kolejki i ponowne próby dla każdego komunikatu; idempotentne wyniki i dokumenty; warstwa FHIR dla aplikacji pacjenta i partnerów zewnętrznych; oraz środowiska testowe z syntetycznymi pacjentami przed uruchomieniem.

  • Jeden główny system dla tożsamości. HIS (lub główny indeks pacjenta) posiada identyfikatory; wszyscy inni subskrybują ADT i nigdy nie tworzą własnych pacjentów.
  • Kody na granicy. Mapuj lokalne kody na LOINC, SNOMED CT, ATC w silniku, raz, i zachowaj lokalny kod obok.
  • Potwierdzenie, kolejkowanie, ponawianie. Każda wiadomość v2 otrzymuje ACK; silnik zapisuje i odtwarza; nikt nie traci wyniku z powodu restartu systemu.
  • Idempotentność. Wyniki i dokumenty zawierają identyfikatory; ponowne przetworzenie aktualizuje, a nie duplikuje.
  • Warstwa FHIR dla wszystkiego, co nowe. Aplikacje pacjenta, telemedycyna, wyciągi badawcze i partnerzy zewnętrzni komunikują się przez FHIR z fasadą lub dedykowanym serwerem FHIR zasilanym z wewnętrznych przepływów, zamiast bezpośrednio z HIS.
  • Środowiska testowe z syntetycznymi pacjentami oraz etap zgodności (profile IHE Connectathon, krajowe zestawy testowe) przed wprowadzeniem czegokolwiek do produkcji.

Tryby awarii spotykane wszędzie

Tryby awarii spotykane w niemal każdej integracji szpitalnej to duplikaty pacjentów z powodu błędów w rejestracji, wyniki przypisane do niewłaściwej wizyty po połączeniu, niezmapowane kody lokalne, błędy stref czasowych i czasu letniego w znacznikach czasu, jednostki w tekście swobodnym, interfejsy, które milkną bez monitorowania, niestandardowe segmenty dostawców łamiące parsery oraz tymczasowe kanały CSV, które nigdy nie są wycofywane.

Duplikaty pacjentów z powodu błędów rejestracji; wyniki przypisane do niewłaściwej wizyty po scaleniu; lokalne kody testowe, których nikt nie zmapował; strefy czasowe i czas letni w znacznikach czasu wiadomości; jednostki w tekście swobodnym; interfejs, który cicho się zatrzymał i nikt go nie monitorował; specyficzne dla producenta segmenty Z, które łamią parsery; oraz "tymczasowy" kanał CSV, który działa nadal po dziesięciu latach.

Gdzie FHIR zmienia obraz

FHIR zmienia integrację szpitalną na obrzeżach, a nie w rdzeniu. Wewnątrz budynku HL7 v2 i DICOM pozostają, ponieważ analizatory, skanery i starsze moduły z nimi współpracują; FHIR przejmuje dostęp pacjenta, aplikacje SMART on FHIR, wsparcie decyzji CDS Hooks, subskrypcje, wymianę regionalną i krajową w ramach EHDS i TEFCA oraz wyciągi badawcze.

Wewnętrznie, HL7 v2 i DICOM pozostaną przez lata, ponieważ każdy analizator, skaner i starszy moduł z nimi współpracuje. FHIR wygrywa na krawędziach: dostęp pacjenta, aplikacje uruchamiane wewnątrz EHR (SMART on FHIR), wsparcie decyzji (CDS Hooks), subskrypcje dla integracji sterowanej zdarzeniami, wymiana regionalna i krajowa w ramach EHDS i TEFCA, oraz wyciągi badawcze. Wiele szpitali uruchamia obecnie serwer FHIR zasilany przez silnik jako warstwę integracyjną dla wszystkiego poza budynkiem; zobacz Standardy interoperacyjności w opiece zdrowotnej: mapa.

W Anpheros

Platforma Anpheros znajduje się na obrzeżu FHIR integracji szpitalnej: jest to rekord FHIR R4, do którego szpital lub przychodnia może zapisywać i z którego może odczytywać dane za zgodą pacjenta, zasilany przez własną integrację szpitala za pośrednictwem konektora laboratoryjnego (HL7 v2 ORU, CSV lub JSON), z webhookami i informacją o pochodzeniu dla każdego źródła. Nie zastępuje systemu HIS ani silnika.

Platforma Anpheros znajduje się na tej krawędzi: rekord FHIR R4, do którego szpital lub przychodnia może zapisywać i z którego może odczytywać dane za zgodą pacjenta, zasilany przez własną integrację szpitala ( łącznik laboratoryjny pobiera HL7 v2 ORU, CSV lub JSON), z webhookami do powiadamiania o zmianach i informacją o pochodzeniu dla każdego źródła. Nie zastępuje on HIS ani silnika; daje pacjentowi rekord, który podąża za nim poza budynek.

Powiązane strony

Źródła

Najczęstsze pytania

Czy nowy szpital powinien integrować wszystko z FHIR?

Nie wszystko. Analizatory, skanery i większość systemów działowych komunikuje się w HL7 v2 i DICOM, i to się szybko nie zmieni. Używaj FHIR do integracji skierowanych do pacjenta, zewnętrznych i nowych, a silnika do połączenia.

Jaka jest różnica między HIS a EHR?

Użycie różni się w zależności od kraju. HIS często oznacza system administracyjny i kliniczny szpitala razem; EHR kładzie nacisk na dokumentację medyczną. W terminach integracji oba są systemami, które posiadają tożsamość, wizyty i dokumentację.

Ile interfejsów ma szpital średniej wielkości?

Zazwyczaj od pięćdziesięciu do kilkuset przepływów wiadomości przez silnik, licząc każdy kierunek i każdy odbierający system. Ekran monitorowania silnika to miejsce, gdzie żyją zespoły integracyjne.

Kto jest odpowiedzialny za integrację w szpitalu?

Zespół IT ds. integracji szpitala, zazwyczaj ze wsparciem dostawcy silnika, oraz każdy dostawca działowy po swojej stronie. Programy krajowe i profile IHE zmniejszają, ale nie eliminują pracy projektowej.

Anpheros Platform

Wypróbuj za darmo w sandboksie

Pierwsze wywołanie FHIR w 5 minut. API HL7 FHIR R4 z wbudowaną zgodą pacjenta: wypróbuj w piaskownicy, a następnie połącz własną aplikację lub system kliniczny.

Za darmo · 30 syntetycznych pacjentów · bez karty

Ten poradnik ma charakter informacyjny i nie zastępuje konsultacji lekarskiej. Decyzje dotyczące zdrowia podejmuj z lekarzem. W nagłym wypadku zadzwoń pod lokalny numer alarmowy (112 w Europie).
Napisane przez
Zespół Anpheros

Anpheros tworzy dokumentację medyczną, nad którą pacjent ma kontrolę i którą może udostępniać dowolnej klinice, na platformie HL7 FHIR R4, z siedzibą w UE. Te przewodniki pomogą Ci zrozumieć i uporządkować informacje o Twoim zdrowiu; nie zastępują one wizyty u lekarza.

O Anpheros →