# HL7 v2 zu FHIR-Mapping

> Segment-zu-Ressource und OBX-Feld-für-Feld-Mapping von HL7 v2 ORU^R01 zu FHIR R4, die Fallstricke, die Integrationen zum Scheitern bringen, und ein Konverter, den Sie über HTTPS aufrufen können.

Source: https://developers.anpheros.com/de/guides/hl7-v2-to-fhir-mapping

**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](https://hl7.org/fhir/uv/v2mappings/) 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.

<!-- visual:v2map-flow -->

## 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

```bash
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

1.  **Zeitzonen.** `20261002074500` hat keinen Offset; legen Sie die Zone des Senders explizit fest.
2.  **Lokale Codes.** Behalten Sie den eigenen Code des Labors bei, wenn kein LOINC vorhanden ist; lassen Sie ihn niemals weg.
3.  **Erneute Übermittlungen.** Ohne eine stabile Kennung pro Ergebnis werden Wiederholungsversuche zu Duplikaten.
4.  **Korrekturen.** OBX-11 `C` ist eine Korrektur; entscheiden Sie, ob sie ersetzt oder hinzugefügt wird, und kennzeichnen Sie das alte Ergebnis.
5.  **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?
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.

### 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.

### 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).

<!-- visual:cta-v2map -->

## Verwandte Themen

- [API für Laborergebnisse: HL7 v2, FHIR und LOINC](https://developers.anpheros.com/de/guides/lab-results-api)
- [FHIR vs. HL7 v2: Praktische Unterschiede](https://developers.anpheros.com/de/guides/fhir-vs-hl7-v2)
- [Importieren von Laborergebnissen in einen FHIR-Datensatz](https://developers.anpheros.com/de/guides/import-lab-results-fhir)
- [HL7 v2 und FHIR für klinische Dashboards](https://developers.anpheros.com/de/guides/clinical-dashboard-hl7-fhir)
- [Labor-Konnektor](https://developers.anpheros.com/de/guides/lab-connector)