# FHIR vs HL7 v2: diferențe practice

> Mesaje HL7 v2 și resurse FHIR comparate pentru dezvoltatori: format, transport, același rezultat de laborator în ambele, capcane de traducere și unde Anpheros acceptă v2.

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

**HL7 v2 este formatul de mesaje pe care sistemele spitalicești le-au schimbat încă de la sfârșitul anilor 1980 — evenimente delimitate prin pipe, cum ar fi „pacient admis” sau „rezultat de laborator gata”, transmise între sisteme printr-o conexiune de rețea — în timp ce HL7 FHIR este un standard API web unde aplicațiile citesc și scriu resurse precum Patient și Observation peste HTTPS în JSON.** Acestea nu sunt alternative pe care le alegi o singură dată: majoritatea spitalelor încă funcționează pe v2 intern, noile aplicații și API-urile orientate către pacienți folosesc FHIR, iar munca de integrare implică adesea traducerea unuia în celălalt. Această pagină le compară pe punctele care contează atunci când scrii cod, prezintă aceleași date în ambele formate și explică unde Anpheros acceptă v2.

## Alăturat

| | HL7 v2 | HL7 FHIR R4 |
|---|---|---|
| Stil | Mesaje declanșate de evenimente (admitere, comandă, rezultat) | Resurse pe care le creați, citiți, actualizați, căutați |
| Format | Segmente de text separate prin sfârșituri de linie, câmpuri prin `\|`, componente prin `^` | JSON (sau XML) |
| Transport | De obicei MLLP peste TCP în rețeaua spitalului | HTTPS REST |
| Interogare | Limitată; sistemele împing în principal | Parametri de căutare, `_include`, istoric |
| Securitate | Nivel de rețea (VPN, legături private) | OAuth 2.0 / SMART on FHIR, TLS, scope-uri |
| Flexibilitate | Multe câmpuri opționale și segmente Z locale; fiecare interfață este negociată | Resurse de bază plus profiluri (US Core, IPS, IGs europene) |
| Utilizatori tipici | EHR, laborator, radiologie, sisteme de facturare din cadrul unui spital | Aplicații, API-uri de acces pentru pacienți, schimb inter-organizațional, AI |

Cele mai comune mesaje v2:

| Mesaj | Semnificație | Cele mai apropiate resurse FHIR |
|---|---|---|
| ADT^A01, A03, A08 | Admitere, externare, actualizare pacient | `Patient`, `Encounter` |
| ORM / OML | Comandă un test | `ServiceRequest` |
| ORU^R01 | Rezultat gata | `Observation`, `DiagnosticReport` |
| SIU | Programare | `Appointment` |
| MDM | Document | `DocumentReference` |

## Același rezultat de laborator în ambele formate

O linie de rezultat ORU^R01 (segment OBX):

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

Același rezultat ca o observație HL7 FHIR R4, așa cum este stocat de Anpheros după importarea mesajului:

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

Câmp cu câmp: OBX-3 devine `code`, OBX-5 și OBX-6 devin `valueQuantity`, OBX-7 `referenceRange`, OBX-8 `interpretation`, OBX-11 `status`, OBX-14 `effectiveDateTime`. HL7 publică un ghid oficial de implementare [HL7 Version 2 to FHIR](https://build.fhir.org/ig/HL7/v2-to-fhir/) cu mapări pentru segmente, tipuri de date și vocabular.

## Unde traducerile eșuează

- **Fusuri orare.** Marcajele temporale v2 precum `20261002074500` adesea nu conțin un decalaj; trebuie să cunoașteți zona expeditorului. FHIR necesită o zonă ori de câte ori este prezent un timp. (Anpheros citește un timp v2 fără zonă ca UTC; trimiteți decalajul dacă îl aveți.)
- **Coduri locale.** Multe laboratoare introduc propriile coduri în OBX-3 în loc de LOINC. O traducere bună păstrează codul local și îl mapează la LOINC atunci când poate, în loc să-l elimine.
- **Trimiteri repetate.** Expeditorii v2 retransmit la timeout-uri. Fără un identificator stabil per rezultat, un depozit FHIR se umple cu duplicate.
- **Opționalitate generală.** Același câmp poate fi gol, repetat sau utilizat diferit de doi expeditori. Validați partea FHIR; [validatorul FHIR R4](https://developers.anpheros.com/tools/fhir-validator) arată ce lipsește unui resursă tradusă.
- **Corecții.** Starea rezultatului v2 `C` (corectat) ar trebui să actualizeze Observația existentă și să-i păstreze istoricul, nu să creeze o a doua.

## Când să folosiți ce

- **În interiorul unui spital, între sisteme existente:** v2 este de obicei ceea ce vorbesc sistemele. Un motor de integrare direcționează și transformă mesajele.
- **Construirea unei aplicații, a unui API de acces pentru pacienți sau a oricărui lucru care traversează organizații:** FHIR, cu OAuth și consimțământ.
- **Alimentarea AI sau a analizei:** FHIR, deoarece este interogabil, codificat și versionat.
- **Ambele:** modelul comun din lumea reală — primiți v2 de la laborator sau EHR, stocați FHIR, serviți FHIR aplicațiilor.

## Unde se încadrează Anpheros

Anpheros stochează dosarele pacienților ca FHIR R4 și acceptă un singur tip de mesaj HL7 v2: **ORU^R01 rezultate de laborator**, trimis prin HTTPS către [conectorul de laborator](https://developers.anpheros.com/ro/guides/lab-connector) (`POST /v1/patients/{id}/labs/import` cu `Content-Type: x-application/hl7-v2+er7`). Fiecare OBX devine o observație de laborator cu cod LOINC, interval de referință și interpretare; ID-ul raportului este păstrat în proveniență, iar rapoartele retrimise sunt omise. Un rezultat corectat (OBX-11 = `C`) cu o nouă valoare este stocat ca o nouă observație cu starea `amended`; originalul rămâne așa cum a fost, deci dacă sursa dvs. trimite corecții, marcați observația anterioară `entered-in-error` sau actualizați-o prin API-ul FHIR. Un exemplu funcțional este [API-ul pentru rezultate de laborator](https://developers.anpheros.com/ro/guides/lab-results-api).

Nu acceptă alte mesaje v2 (ADT, comenzi, programări), nu ascultă pe MLLP și nu trimite v2. Pentru acestea, un motor de integrare din fața Anpheros traduce în FHIR și scrie prin API.

## Întrebări frecvente

### Înlocuiește FHIR HL7 v2?
Nu curând. v2 rămâne coloana vertebrală în majoritatea spitalelor deoarece funcționează și este integrat în sistemele existente. FHIR crește în jurul său — în aplicații, accesul pacienților și schimbul între organizații — iar cele două coexistă, adesea cu traducere între ele.

### Ce este MLLP?
Minimal Lower Layer Protocol: o modalitate simplă de a încadra mesajele v2 peste o conexiune TCP, cu caractere de început și de sfârșit în jurul fiecărui mesaj și un ACKnowledgement (ACK) înapoi. FHIR folosește HTTPS în schimb.

### Pot converti automat mesajele HL7 v2 în FHIR?
În mare parte. Ghidul de implementare v2-to-FHIR al HL7 oferă mapări standard, iar motoarele de integrare le implementează. Așteptați-vă la muncă manuală pentru coduri locale, segmente Z, fusuri orare și modul în care fiecare expeditor utilizează câmpurile opționale.

### Acceptă Anpheros HL7 v2?
Da, pentru rezultatele de laborator: mesajele ORU^R01 postate prin HTTPS către conectorul de laborator devin FHIR Observations. Alte tipuri de mesaje v2 și conexiunile MLLP nu sunt acceptate.

## Conexe

- [Mapare HL7 v2 la FHIR](https://developers.anpheros.com/ro/guides/hl7-v2-to-fhir-mapping): mapare segment și câmp, și un convertor
- [API pentru rezultate de laborator: HL7 v2, FHIR și LOINC](https://developers.anpheros.com/ro/guides/lab-results-api)
- [Cum se importă rezultatele de laborator într-un fișier FHIR](https://developers.anpheros.com/ro/guides/import-lab-results-fhir)
- [Interoperabilitatea datelor din domeniul sănătății](https://developers.anpheros.com/ro/guides/interoperability)
- [DICOM vs FHIR: date imagistice și date clinice](https://developers.anpheros.com/ro/guides/dicom-vs-fhir)
- [Platformă FHIR](https://developers.anpheros.com/ro/guides/fhir)