# Maparea HL7 v2 la FHIR

> Maparea segment-la-resursă și câmp-cu-câmp OBX de la HL7 v2 ORU^R01 la FHIR R4, capcanele care strică integrările și un convertor pe care îl puteți apela prin HTTPS.

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

**Maparea HL7 v2 la FHIR înseamnă transformarea fiecărui segment dintr-un mesaj v2 delimitat prin pipe în resurse FHIR R4: PID într-un Patient, OBR într-un DiagnosticReport (sau ServiceRequest), fiecare OBX într-un Observation, cu coduri, unități, intervale și timpi transferați câmp cu câmp.** HL7 publică un [ghid de implementare V2-to-FHIR](https://hl7.org/fhir/uv/v2mappings/) oficial cu hărți de concepte pentru segmentele comune. Această pagină oferă maparea practică pentru rezultatele de laborator (ORU^R01), capcanele care strică integrările reale și un convertor pe care îl puteți apela prin HTTPS: conectorul de laborator Anpheros.

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

## Segment către resursă

| Segment HL7 v2 | Ce transportă | Resursă FHIR R4 | În conectorul de laborator Anpheros |
|---|---|---|---|
| MSH | Separatori, sistem de trimitere, tip mesaj, ID mesaj | `MessageHeader` (sau provenance) | Separatori citiți din MSH; tip verificat pentru ORU^R01; ID mesaj păstrat pentru trasabilitate |
| PID | Identificatori pacient, nume, data nașterii, sex | `Patient` | Nu este utilizat: pacientul este cel din URL-ul cererii, deci un mesaj nu poate scrie în registrul greșit |
| PV1 | Vizită | `Encounter` | Nu este utilizat |
| ORC / OBR | Comandă și raport: ID filler/placer, dată | `ServiceRequest`, `DiagnosticReport` | OBR-3 (sau OBR-2) este ID-ul raportului, OBR-7 data implicită |
| OBX | Un rezultat | `Observation` | O observație de laborator per OBX |
| NTE | Notă text liber | `Observation.note` | Nu este utilizat |

## Câmp cu câmp OBX

| Câmp OBX | Element FHIR Observation | Note |
|---|---|---|
| OBX-2 tip valoare (NM, SN, ST, CWE) | choice of `value[x]` | NM și SN devin `valueQuantity`; textul rămâne text |
| OBX-3 identificator `code^text^system` | `code.coding` | `LN` în OBX-3.3 înseamnă LOINC; alte sisteme sunt codul local al laboratorului |
| OBX-5 valoare, OBX-6 unitate | `valueQuantity.value`, `.unit` / `.code` (UCUM) | `<5` și `6,4` trebuie analizate deliberat |
| OBX-7 interval de referință | `referenceRange.low` / `.high` | `3.5-5.1`, `<200`, `>40` |
| OBX-8 flag anormal | `interpretation` | H, L, HH, LL, A, N |
| OBX-11 status rezultat | `status` | F → final, C → amendat, P → preliminar, I → înregistrat |
| OBX-14 timp observație | `effectiveDateTime` | timpii v2 adesea nu au fus orar; FHIR necesită unul |

## Convertiți un mesaj cu o singură cerere

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

Răspunsul listează câte Observații au fost create, câte au fost omise deoarece au fost deja importate, ce markeri nu au putut fi mapați și noile Observații cu codurile lor. Fiecare primește un identificator stabil derivat din raport, test, oră și valoare, astfel încât un laborator care retrimite același mesaj nu creează duplicate.

## Capcane care strică integrările reale

1. **Fusuri orare.** `20261002074500` nu are offset; decideți explicit zona expeditorului.
2. **Coduri locale.** Păstrați codul propriu al laboratorului atunci când nu există LOINC; nu-l omiteți niciodată.
3. **Re-trimitere.** Fără un identificator stabil per rezultat, reîncercările devin duplicate.
4. **Corecții.** OBX-11 `C` este o corecție; decideți dacă înlocuiește sau adaugă și marcați rezultatul vechi.
5. **Valori non-numerice.** `positive`, `<5`, `6,4` necesită reguli explicite, nu o presupunere.

## Ce nu face conectorul

Acceptă rezultate de laborator ORU^R01 prin HTTPS. Nu primește mesaje ADT sau de comandă, nu comunică MLLP peste TCP (un motor de interfață în față poate redirecționa), nu creează un DiagnosticReport și nu potrivește pacienți din PID.

## Întrebări frecvente

### Cum se mapează HL7 v2 la FHIR?
Segment cu segment: PID la Patient, PV1 la Encounter, ORC/OBR la ServiceRequest și DiagnosticReport, OBX la Observation, NTE la notes. Ghidul de implementare V2-to-FHIR al HL7 definește mapările conceptelor la nivel de câmp.

### Există un convertor HL7 v2 la FHIR?
Da. Motoarele de interfață și bibliotecile open-source convertesc mesajele; pentru rezultatele de laborator, conectorul de laborator Anpheros convertește un mesaj ORU^R01 în FHIR R4 Observations într-o singură cerere HTTPS și le stochează în dosarul pacientului.

### Ce tipuri de mesaje HL7 v2 acceptă Anpheros?
ORU^R01 rezultate de laborator. Un mesaj de alt tip primește un avertisment, iar doar segmentele sale OBX sunt citite; ADT, mesaje de comandă și alte mesaje nu sunt acceptate.

### Cum sunt reprezentate semnele anormale HL7 v2 în FHIR?
OBX-8 devine `Observation.interpretation` folosind codurile HL7 ObservationInterpretation (H, L, HH, LL, A, N).

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

## Conexe

- [API pentru rezultate de laborator: HL7 v2, FHIR și LOINC](https://developers.anpheros.com/ro/guides/lab-results-api)
- [FHIR vs HL7 v2: diferențe practice](https://developers.anpheros.com/ro/guides/fhir-vs-hl7-v2)
- [Cum se importă rezultatele de laborator într-un fișier FHIR](https://developers.anpheros.com/ro/guides/import-lab-results-fhir)
- [HL7 v2 și FHIR pentru tablouri de bord clinice](https://developers.anpheros.com/ro/guides/clinical-dashboard-hl7-fhir)
- [Conector de laborator](https://developers.anpheros.com/ro/guides/lab-connector)