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

HL7 v2 zu FHIR Mapping

Q: Wie bildet man HL7 v2 auf FHIR ab?

Segment für Segment: PID auf Patient, PV1 auf Encounter, ORC/OBR auf ServiceRequest und DiagnosticReport, OBX auf Observation, NTE auf Notizen. Der HL7 V2-to-FHIR Implementierungsleitfaden definiert die Feld-Level-Konzeptzuordnungen.

Q: Gibt es einen HL7 v2 zu FHIR Konverter?

Ja. Interface-Engines und Open-Source-Bibliotheken konvertieren Nachrichten; für Laborergebnisse konvertiert der Anpheros Lab Connector eine ORU^R01-Nachricht in FHIR R4 Observations in einer einzigen HTTPS-Anfrage und speichert sie im Patientenakt.

Q: Welche HL7 v2 Nachrichtentypen akzeptiert Anpheros?

ORU^R01 Laborergebnisse. Eine Nachricht eines anderen Typs erhält eine Warnung, und nur ihre OBX-Segmente werden gelesen; ADT-, Order- und andere Nachrichten werden nicht unterstützt.

Q: Wie werden HL7 v2 Abnormalitätskennzeichnungen in FHIR dargestellt?

OBX-8 wird zu Observation.interpretation unter Verwendung der HL7 ObservationInterpretation Codes (H, L, HH, LL, A, N).

Segment-zu-Ressource und OBX-Feld-für-Feld-Mapping von HL7 v2 ORU^R01 zu FHIR R4, die Fallen, die Integrationen brechen, und ein Konverter, den Sie über HTTPS aufrufen.

Das Mapping von HL7 v2 zu FHIR bedeutet, jedes Segment einer Pipe-delimitierten v2-Nachricht in FHIR R4-Ressourcen umzuwandeln: PID in einen Patient, OBR in einen DiagnosticReport (oder ServiceRequest), jedes OBX in ein Observation, wobei Codes, Einheiten, Bereiche und Zeiten Feld für Feld übernommen werden. HL7 veröffentlicht einen offiziellen V2-to-FHIR Implementation Guide mit Konzept-Maps für die gängigen Segmente. Diese Seite bietet das praktische Mapping für Laborergebnisse (ORU^R01), die Fallstricke, die reale Integrationen zum Scheitern bringen, und einen Konverter, den Sie über HTTPS aufrufen können: den Anpheros Lab Connector.

An ORU^R01 message becoming FHIR

MSHSeparators, message type, message id → MessageHeader or provenance
PIDPatient identity → Patient (or, in Anpheros, the patient in the URL)
OBRThe order and report → DiagnosticReport, report id and date
OBXOne result each → Observation with LOINC, value, range, flag
FHIR recordCoded, versioned resources your apps can read

Segment zu Ressource

HL7 v2 Segment	Was es transportiert	FHIR R4 Ressource	Im Anpheros Lab Connector
MSH	Trennzeichen, sendendes System, Nachrichtentyp, Nachrichten-ID	`MessageHeader` (oder Provenance)	Trennzeichen aus MSH gelesen; Typ für ORU^R01 geprüft; Nachrichten-ID zur Nachverfolgbarkeit beibehalten
PID	Patientenidentifikatoren, Name, Geburtsdatum, Geschlecht	`Patient`	Nicht verwendet: Der Patient ist derjenige in der Request-URL, daher kann eine Nachricht nicht in den falschen Datensatz geschrieben werden
PV1	Besuch	`Encounter`	Nicht verwendet
ORC / OBR	Bestellung und Bericht: Filler/Placer ID, Datum	`ServiceRequest`, `DiagnosticReport`	OBR-3 (oder OBR-2) ist die Berichts-ID, OBR-7 das Standarddatum
OBX	Ein Ergebnis	`Observation`	Eine Laborbeobachtung pro OBX
NTE	Freitextnotiz	`Observation.note`	Nicht verwendet

OBX-Feld für Feld

OBX-Feld	FHIR Observation-Element	Hinweise
OBX-2 Werttyp (NM, SN, ST, CWE)	Wahl von `value[x]`	NM und SN werden zu `valueQuantity`; Text bleibt Text
OBX-3 Identifikator `code^text^system`	`code.coding`	`LN` in OBX-3.3 bedeutet LOINC; andere Systeme sind der lokale Code des Labors
OBX-5 Wert, OBX-6 Einheit	`valueQuantity.value`, `.unit` / `.code` (UCUM)	`<5` und `6,4` müssen bewusst geparst werden
OBX-7 Referenzbereich	`referenceRange.low` / `.high`	`3.5-5.1`, `<200`, `>40`
OBX-8 Abnormalitätsflag	`interpretation`	H, L, HH, LL, A, N
OBX-11 Ergebnisstatus	`status`	F → final, C → amended, P → preliminary, I → registered
OBX-14 Beobachtungszeit	`effectiveDateTime`	v2-Zeiten fehlen oft eine Zeitzone; FHIR benötigt eine

Eine Nachricht mit einer Anfrage konvertieren

curl -X POST "https://platform.anpheros.com/v1/patients/$PID/labs/import" \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: x-application/hl7-v2+er7" \
  -H "Idempotency-Key: $(uuidgen)" \
  --data-binary @oru_r01.hl7

Die Antwort listet auf, wie viele Observations erstellt wurden, wie viele übersprungen wurden, da sie bereits importiert waren, welche Marker nicht zugeordnet werden konnten und die neuen Observations mit ihren Codes. Jede Observation erhält eine stabile Kennung, die sich aus dem Bericht, dem Test, der Zeit und dem Wert ableitet, sodass ein Labor, das dieselbe Nachricht erneut sendet, keine Duplikate erstellt.

Fallstricke, die reale Integrationen zum Scheitern bringen

Zeitzonen. 20261002074500 hat keinen Offset; legen Sie die Zone des Senders explizit fest.
Lokale Codes. Behalten Sie den eigenen Code des Labors bei, wenn kein LOINC vorhanden ist; lassen Sie ihn niemals weg.
Erneute Übermittlungen. Ohne eine stabile Kennung pro Ergebnis werden Wiederholungsversuche zu Duplikaten.
Korrekturen. OBX-11 C ist eine Korrektur; entscheiden Sie, ob sie ersetzt oder hinzugefügt wird, und kennzeichnen Sie das alte Ergebnis.
Nicht-numerische Werte. positive, <5, 6,4 benötigen explizite Regeln, keine Vermutungen.

Was der Connector nicht tut

Er akzeptiert ORU^R01-Laborergebnisse über HTTPS. Er empfängt keine ADT- oder Order-Nachrichten, spricht kein MLLP über TCP (eine vorgeschaltete Interface-Engine kann weiterleiten), erstellt keinen DiagnosticReport und gleicht keine Patienten aus PID ab.

Häufig gestellte Fragen

Wie bildet man HL7 v2 auf FHIR ab?

Segment für Segment: PID auf Patient, PV1 auf Encounter, ORC/OBR auf ServiceRequest und DiagnosticReport, OBX auf Observation, NTE auf Notizen. Der HL7 V2-to-FHIR Implementierungsleitfaden definiert die Feld-Level-Konzeptzuordnungen.

Gibt es einen HL7 v2 zu FHIR Konverter?