Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

Interoperacyjność danych medycznych

Poziomy techniczne, składniowe, semantyczne i organizacyjne interoperacyjności, standardy używane przez Anpheros (FHIR R4, IPS, SMART on FHIR, HL7 v2) i dlaczego pochodzenie danych czyni je godnymi zaufania.

Interoperacyjność danych w opiece zdrowotnej to zdolność różnych systemów — aplikacji, klinik, laboratoriów, szpitali, usług AI — do wymiany danych medycznych i ich wykorzystania bez ręcznej re-interpretacji. Anpheros podchodzi do tego poprzez przechowywanie każdego rekordu w formatach, które inne systemy już rozumieją (HL7 FHIR R4 ze standardowymi systemami kodowania), poprzez wymianę danych za pomocą standardowych protokołów (FHIR REST, SMART on FHIR, International Patient Summary, wiadomości laboratoryjne HL7 v2) oraz poprzez zachowanie kontekstu, który sprawia, że wymieniane dane są godne zaufania: kto je utworzył, kiedy i za czyją zgodą.

Cztery poziomy interoperacyjności

Większość projektów integracyjnych kończy się niepowodzeniem na poziomach semantycznym i organizacyjnym, a nie technicznym. Kodowanie w momencie zapisu i rejestrowanie pochodzenia (provenance) dla każdej wartości sprawia, że dane z jednego źródła są użyteczne w innym.

Standardy używane przez Anpheros

• HL7 FHIR R4. Każdy rekord składa się z zasobów FHIR — 26 typów — z możliwością wyszukiwania i wersjonowania, z CapabilityStatement pod adresem /fhir/R4/metadata. Platforma FHIR
• International Patient Summary (IPS). Patient/{id}/$summary zwraca pakiet dokumentu IPS, zweryfikowany za pomocą oficjalnego walidatora HL7 względem hl7.fhir.uv.ips#1.1.0 bez błędów. IPS to format podsumowania przeznaczony do opieki transgranicznej w Europie.
• Reguły europejskich raportów laboratoryjnych HL7. Wyniki laboratoryjne są sprawdzane podczas zapisu; luki są zgłaszane w nagłówku odpowiedzi Anpheros-Conformance (obecnie jako wskazówka). Observation/$validate?profile=eu-lab wykonuje sprawdzenie na żądanie.
• SMART on FHIR. Aplikacje stron trzecich uzyskują dostęp do rekordu za pomocą OAuth 2.1 z PKCE i zakresów pacjentów SMART v2; odkrywanie pod adresem /fhir/R4/.well-known/smart-configuration. Grupa testowa samodzielnego uruchomienia pakietu Inferno SMART App Launch STU2 przechodzi pomyślnie; uruchamianie w systemie EHR nie jest jeszcze obsługiwane.
• HL7 v2. Wyniki laboratoryjne przychodzą jako wiadomości ORU^R01, a także w formacie CSV lub JSON, i stają się FHIR Observations. Łącznik laboratoryjny
• European Health Data Space. FHIR R4 i IPS to formaty, na których opiera się EHDS w zakresie podsumowań pacjentów i wyników laboratoryjnych; Anpheros ich przestrzega. Jest to zgodność z formatami, a nie certyfikacja.

Wzorce wymiany danych

1. Dostęp aplikacji za zgodą użytkownika — aplikacja prosi pacjenta o zakresy uprawnień, odczytuje i zapisuje dane w rekordzie za pośrednictwem FHIR lub REST, a dostęp jest tracony, gdy pacjent go odwoła.
2. Wymiana dokumentów — rekord lub jego podsumowanie opuszcza system jako pakiet FHIR ($everything, $summary).
3. Wyniki przychodzące — laboratoria i kliniki zapisują dane w rekordzie w imieniu swojej organizacji; pacjent widzi, kto co zapisał.
4. Zdarzenia — subskrybenci są informowani o zmianach (tylko identyfikatory, nigdy treść kliniczna) i odczytują to, do czego mają uprawnienia.

Provenance: interoperacyjność, której możesz zaufać

Dane, które przemieszczają się między systemami, tracą swój kontekst, chyba że kontekst podróżuje razem z nimi. W Anpheros każda wersja każdego zasobu rejestruje:

• typ autora — pacjent, praktykujący lekarz, urządzenie, import lub AI;
• organizację, w imieniu której został napisany, oraz, jeśli podano, praktykującego lekarza;
• system źródłowy i jego identyfikator tam (X-Anpheros-Source-System, X-Anpheros-Origin-Id).

Wartości wygenerowane przez AI są oznaczone jako takie i są oddzielane od faktów klinicznych podczas budowania kontekstu dla modelu.

Tożsamość między aplikacjami

Każda aplikacja widzi swój własny identyfikator dla tej samej osoby (identyfikatory parami), dzięki czemu rekordy nie mogą być korelowane między aplikacjami bez wiedzy pacjenta. Odniesienia do osób spoza zakresu aplikacji są maskowane. Interoperacyjność odbywa się poprzez zgodę, a nie poprzez współdzielone identyfikatory.

Powiązane

• Jak normalizować dane medyczne: kody, jednostki, daty, duplikaty, walidacja
• Wyjaśnienie pochodzenia danych medycznych: kto co napisał i jak to zarejestrować
• Jak zintegrować systemy kliniczne z backendem FHIR: samouczek krok po kroku dla klinicznych systemów EMR
• Jak importować wyniki laboratoryjne do rekordu FHIR: samouczek krok po kroku z CSV i HL7 v2
• Platforma FHIR
• Integracje opieki zdrowotnej
• Systemy kodów FHIR
• API opieki zdrowotnej
• Infrastruktura danych medycznych
• DICOM vs FHIR: dane obrazowe i dane kliniczne oraz ich powiązania
• API wyników laboratoryjnych: HL7 v2 i FHIR dla wyników laboratoryjnych
• FHIR vs HL7 v2: porównanie wiadomości i zasobów
• Europejska Przestrzeń Danych Zdrowotnych (EHDS) dla deweloperów

Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card