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

FHIR vs HL7 v2: praktische Unterschiede

HL7 v2 Nachrichten und FHIR Ressourcen im Vergleich für Entwickler: Format, Transport, das gleiche Laborergebnis in beiden, Übersetzungsfallen und wo Anpheros v2 akzeptiert.

HL7 v2 ist das Nachrichtenformat, das Krankenhäuser seit den späten 1980er Jahren austauschen – Pipe-delimited Events wie „Patient aufgenommen“ oder „Laborergebnis bereit“, die über eine Netzwerkverbindung zwischen Systemen übertragen werden – während HL7 FHIR ein Web-API-Standard ist, bei dem Anwendungen Ressourcen wie Patient und Observation über HTTPS in JSON lesen und schreiben. Sie sind keine Alternativen, die man einmal wählt: Die meisten Krankenhäuser arbeiten intern immer noch mit v2, neue Anwendungen und patientenorientierte APIs verwenden FHIR, und Integrationsarbeiten beinhalten oft die Übersetzung der einen in die andere. Diese Seite vergleicht sie anhand der Punkte, die beim Schreiben von Code wichtig sind, zeigt dieselben Daten in beiden Formaten und erklärt, wo Anpheros v2 akzeptiert.

Nebeneinander

	HL7 v2	HL7 FHIR R4
Stil	Ereignisgesteuerte Nachrichten (Aufnahme, Bestellung, Ergebnis)	Ressourcen, die Sie erstellen, lesen, aktualisieren, suchen
Format	Textsegmente, getrennt durch Zeilenumbrüche, Felder durch `\\|`, Komponenten durch `^`	JSON (oder XML)
Transport	Üblicherweise MLLP über TCP innerhalb des Krankenhausnetzwerks	HTTPS REST
Abfrage	Begrenzt; Systeme schieben hauptsächlich	Suchparameter, `_include`, Verlauf
Sicherheit	Netzwerkebene (VPN, private Links)	OAuth 2.0 / SMART on FHIR, TLS, Scopes
Flexibilität	Viele optionale Felder und lokale Z-Segmente; jede Schnittstelle wird ausgehandelt	Basisressourcen plus Profile (US Core, IPS, European IGs)
Typische Benutzer	KIS, Labor-, Radiologie-, Abrechnungssysteme innerhalb eines Krankenhauses	Apps, Patienten-Zugriffs-APIs, organisationsübergreifender Austausch, KI

Die gängigsten v2-Nachrichten:

Nachricht	Bedeutung	Nächstgelegene FHIR-Ressourcen
ADT^A01, A03, A08	Patient aufnehmen, entlassen, aktualisieren	`Patient`, `Encounter`
ORM / OML	Test bestellen	`ServiceRequest`
ORU^R01	Ergebnis bereit	`Observation`, `DiagnosticReport`
SIU	Terminplanung	`Appointment`
MDM	Dokument	`DocumentReference`

Dasselbe Laborergebnis in beiden Formaten

Eine ORU^R01-Ergebniszeile (OBX-Segment):

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

Dasselbe Ergebnis als HL7 FHIR R4 Observation, wie Anpheros es nach dem Import dieser Nachricht speichert:

{
  "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"}}]
}

Feld für Feld: OBX-3 wird zu code, OBX-5 und OBX-6 werden zu valueQuantity, OBX-7 referenceRange, OBX-8 interpretation, OBX-11 status, OBX-14 effectiveDateTime. HL7 veröffentlicht einen offiziellen HL7 Version 2 to FHIR Implementierungsleitfaden mit Mappings für Segmente, Datentypen und Vokabulare.

Wo Übersetzungen fehlschlagen

Zeitzonen. v2-Zeitstempel wie 20261002074500 enthalten oft keinen Offset; Sie müssen die Zone des Absenders kennen. FHIR erfordert eine Zone, wenn eine Zeit vorhanden ist. (Anpheros liest eine v2-Zeit ohne Zone als UTC; senden Sie den Offset, falls Sie ihn haben.)
Lokale Codes. Viele Labore verwenden ihre eigenen Codes in OBX-3 anstelle von LOINC. Eine gute Übersetzung behält den lokalen Code bei und ordnet ihn, wenn möglich, LOINC zu, anstatt ihn zu verwerfen.
Wiederholte Sendungen. v2-Absender senden bei Timeouts erneut. Ohne eine stabile Kennung pro Ergebnis füllt sich ein FHIR-Store mit Duplikaten.
Optional alles. Dasselbe Feld kann leer sein, wiederholt werden oder von zwei Absendern unterschiedlich verwendet werden. Validieren Sie die FHIR-Seite; der FHIR R4 Validator zeigt, was einer übersetzten Ressource fehlt.
Korrekturen. Der v2-Ergebnisstatus C (korrigiert) sollte die bestehende Observation aktualisieren und ihre Historie beibehalten, anstatt eine zweite zu erstellen.

Wann was verwenden

Innerhalb eines Krankenhauses, zwischen bestehenden Systemen: v2 ist normalerweise das, was die Systeme sprechen. Eine Integrations-Engine leitet und transformiert Nachrichten.
Beim Erstellen einer App, einer Patienten-API oder allem, das Organisationen überschreitet: FHIR, mit OAuth und Zustimmung.
Für KI oder Analysen: FHIR, da es abfragbar, kodiert und versioniert ist.
Beides: das übliche Muster in der Praxis – v2 vom Labor oder EHR empfangen, FHIR speichern, FHIR für Anwendungen bereitstellen.

Wo Anpheros passt

Anpheros speichert Patientenakten als FHIR R4 und akzeptiert einen HL7 v2 Nachrichtentyp: ORU^R01 Laborergebnisse, gesendet über HTTPS an den Lab Connector (POST /v1/patients/{id}/labs/import mit Content-Type: x-application/hl7-v2+er7). Jedes OBX wird zu einer Labor Observation mit LOINC-Code, Referenzbereich und Interpretation; die Berichts-ID wird in der Provenienz gespeichert und erneut gesendete Berichte werden übersprungen. Ein korrigiertes Ergebnis (OBX-11 = C) mit einem neuen Wert wird als neue Observation mit Status amended gespeichert; das Original bleibt unverändert, also wenn Ihre Quelle Korrekturen sendet, markieren Sie die frühere Observation entered-in-error oder aktualisieren Sie sie über die FHIR API. Ein funktionierendes Beispiel ist Lab Results API.

Es akzeptiert keine anderen v2-Nachrichten (ADT, Bestellungen, Terminplanung), hört nicht auf MLLP und sendet keine v2. Dafür übersetzt eine Integrations-Engine vor Anpheros in FHIR und schreibt über die API.

Häufig gestellte Fragen

Ersetzt FHIR HL7 v2?

Nicht bald. v2 bleibt das Rückgrat in den meisten Krankenhäusern, weil es funktioniert und in bestehende Systeme integriert ist. FHIR wächst darum herum – in Apps, Patientenzugang und Austausch zwischen Organisationen – und die beiden existieren nebeneinander, oft mit Übersetzung dazwischen.

Was ist MLLP?

Das Minimal Lower Layer Protocol: eine einfache Methode, v2-Nachrichten über eine TCP-Verbindung zu rahmen, mit Start- und Endzeichen um jede Nachricht und einer Bestätigung (ACK) zurück. FHIR verwendet stattdessen HTTPS.

Kann ich HL7 v2-Nachrichten automatisch in FHIR konvertieren?

Größtenteils. Der Implementierungsleitfaden von HL7 für v2-zu-FHIR bietet Standardzuordnungen, und Integrations-Engines implementieren diese. Rechnen Sie mit manueller Arbeit für lokale Codes, Z-Segmente, Zeitzonen und die Art und Weise, wie jeder Sender optionale Felder verwendet.

Akzeptiert Anpheros HL7 v2?

Ja, für Laborergebnisse: ORU^R01-Nachrichten, die über HTTPS an den Labor-Connector gesendet werden, werden zu FHIR Observations. Andere v2-Nachrichtentypen und MLLP-Verbindungen werden nicht unterstützt.