AnpherosAnpheros PlatformDevelopers

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

FHIR kontra HL7 v2: praktyczne różnice

Wiadomości HL7 v2 i zasoby FHIR porównane dla deweloperów: format, transport, ten sam wynik laboratoryjny w obu, pułapki tłumaczenia i gdzie Anpheros akceptuje v2.

HL7 v2 to format wiadomości, którym systemy szpitalne wymieniają się od późnych lat 80. XX wieku — zdarzenia rozdzielane pionową kreską, takie jak „pacjent przyjęty” lub „wynik laboratoryjny gotowy”, przesyłane między systemami przez połączenie sieciowe — podczas gdy HL7 FHIR to standard API internetowego, w którym aplikacje odczytują i zapisują zasoby, takie jak Patient i Observation, przez HTTPS w formacie JSON. Nie są to alternatywy, które wybiera się raz na zawsze: większość szpitali nadal wewnętrznie korzysta z v2, nowe aplikacje i API skierowane do pacjentów używają FHIR, a praca integracyjna często polega na tłumaczeniu jednego formatu na drugi. Ta strona porównuje je pod kątem punktów istotnych podczas pisania kodu, pokazuje te same dane w obu formatach i wyjaśnia, gdzie Anpheros akceptuje v2.

Obok siebie

HL7 v2 HL7 FHIR R4
Styl Komunikaty wyzwalane przez zdarzenia (przyjęcie, zlecenie, wynik) Zasoby, które tworzysz, odczytujesz, aktualizujesz, wyszukujesz
Format Segmenty tekstowe oddzielone znakami nowej linii, pola przez \|, komponenty przez ^ JSON (lub XML)
Transport Zazwyczaj MLLP przez TCP w sieci szpitalnej HTTPS REST
Zapytania Ograniczone; systemy głównie wysyłają dane Parametry wyszukiwania, _include, historia
Bezpieczeństwo Poziom sieci (VPN, prywatne połączenia) OAuth 2.0 / SMART on FHIR, TLS, zakresy
Elastyczność Wiele opcjonalnych pól i lokalnych segmentów Z; każdy interfejs jest negocjowany Zasoby bazowe plus profile (US Core, IPS, European IGs)
Typowi użytkownicy Systemy EHR, laboratoryjne, radiologiczne, rozliczeniowe w szpitalu Aplikacje, API dostępu dla pacjentów, wymiana międzyorganizacyjna, AI

Najczęstsze komunikaty v2:

Komunikat Znaczenie Najbliższe zasoby FHIR
ADT^A01, A03, A08 Przyjęcie, wypis, aktualizacja pacjenta Patient, Encounter
ORM / OML Zlecenie badania ServiceRequest
ORU^R01 Wynik gotowy Observation, DiagnosticReport
SIU Planowanie Appointment
MDM Dokument DocumentReference

Ten sam wynik laboratoryjny w obu formatach

Wynik ORU^R01 (segment OBX):

OBX|1|NM|2093-3^Cholesterol^LN||212|mg/dL|<200|H|||F|||20261002074500

Ten sam wynik jako HL7 FHIR R4 Observation, tak jak Anpheros przechowuje go po zaimportowaniu wiadomości:

{
  "resourceType": "Observation",
  "status": "final",
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "laboratory"}]}],
  "code": {"coding": [{"system": "http://loinc.org", "code": "2093-3", "display": "Cholesterol [Mass/volume] in Serum or Plasma"}], "text": "Cholesterol"},
  "effectiveDateTime": "2026-10-02T07:45:00Z",
  "valueQuantity": {"value": 212.0, "unit": "mg/dL"},
  "interpretation": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation", "code": "H"}]}],
  "referenceRange": [{"high": {"value": 200.0, "unit": "mg/dL"}}]
}

Pole po polu: OBX-3 staje się code, OBX-5 i OBX-6 stają się valueQuantity, OBX-7 referenceRange, OBX-8 interpretation, OBX-11 status, OBX-14 effectiveDateTime. HL7 publikuje oficjalny HL7 Version 2 to FHIR implementation guide z mapowaniami segmentów, typów danych i słowników.

Gdzie tłumaczenia idą źle

Kiedy czego używać

Gdzie Anpheros pasuje

Anpheros przechowuje rekordy pacjentów jako FHIR R4 i akceptuje jeden typ wiadomości HL7 v2: ORU^R01 wyniki laboratoryjne, wysyłane przez HTTPS do łącznika laboratorium (POST /v1/patients/{id}/labs/import z Content-Type: x-application/hl7-v2+er7). Każdy OBX staje się obserwacją laboratoryjną z kodem LOINC, zakresem referencyjnym i interpretacją; identyfikator raportu jest przechowywany w pochodzeniu, a ponowne wysłane raporty są pomijane. Skorygowany wynik (OBX-11 = C) z nową wartością jest przechowywany jako nowa obserwacja ze statusem amended; oryginał pozostaje niezmieniony, więc jeśli Twoje źródło wysyła poprawki, oznacz wcześniejszą obserwację jako entered-in-error lub zaktualizuj ją za pomocą API FHIR. Działający przykład to API wyników laboratoryjnych.

Nie akceptuje innych wiadomości v2 (ADT, zamówienia, harmonogramy), nie nasłuchuje na MLLP i nie wysyła v2. W tych przypadkach silnik integracyjny przed Anpheros tłumaczy na FHIR i zapisuje przez API.

Często zadawane pytania

Czy FHIR zastępuje HL7 v2?

Nieprędko. v2 pozostaje kręgosłupem większości szpitali, ponieważ działa i jest wbudowany w istniejące systemy. FHIR rozwija się wokół niego — w aplikacjach, dostępie pacjentów i wymianie między organizacjami — a oba standardy współistnieją, często z tłumaczeniem między nimi.

Co to jest MLLP?

Minimal Lower Layer Protocol: prosty sposób ramkowania komunikatów v2 przez połączenie TCP, ze znakami początku i końca wokół każdego komunikatu oraz potwierdzeniem (ACK) zwrotnym. FHIR używa zamiast tego HTTPS.

Czy mogę automatycznie konwertować komunikaty HL7 v2 do FHIR?

W większości przypadków. Przewodnik implementacyjny HL7 v2-to-FHIR zawiera standardowe mapowania, a silniki integracyjne je implementują. Należy spodziewać się ręcznej pracy w przypadku kodów lokalnych, segmentów Z, stref czasowych i sposobu, w jaki każdy nadawca używa pól opcjonalnych.

Czy Anpheros akceptuje HL7 v2?

Tak, w przypadku wyników laboratoryjnych: komunikaty ORU^R01 wysłane przez HTTPS do konektora laboratoryjnego stają się FHIR Observations. Inne typy komunikatów v2 i połączenia MLLP nie są obsługiwane.

Powiązane

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

Product updates by email

New features, guides and the end of the beta. One email a month at most.

Send me occasional Anpheros Platform updates by email (new features, API changes, guides). I'll confirm by email and can unsubscribe in one click from any email. Privacy