# FHIR проти HL7 v2: практичні відмінності

> Повідомлення HL7 v2 та ресурси FHIR порівнюються для розробників: формат, транспортування, той самий лабораторний результат в обох, пастки перекладу та де Anpheros приймає v2.

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

**HL7 v2 — це формат повідомлень, яким лікарняні системи обмінюються з кінця 1980-х років — події, розділені символом вертикальної риски, такі як "пацієнта прийнято" або "готовий лабораторний результат", що надсилаються між системами через мережеве з'єднання — тоді як HL7 FHIR — це стандарт веб-API, де програми читають і записують ресурси, такі як Patient та Observation, через HTTPS у форматі JSON.** Це не альтернативи, які ви обираєте один раз: більшість лікарень досі працюють на v2 внутрішньо, нові програми та API, орієнтовані на пацієнтів, використовують FHIR, а інтеграційна робота часто полягає в перекладі одного в інше. Ця сторінка порівнює їх за пунктами, які мають значення при написанні коду, показує ті самі дані в обох форматах та пояснює, де Anpheros приймає v2.

## Поруч

| | HL7 v2 | HL7 FHIR R4 |
|---|---|---|
| Стиль | Повідомлення, що запускаються подіями (прийом, замовлення, результат) | Ресурси, які ви створюєте, читаєте, оновлюєте, шукаєте |
| Формат | Текстові сегменти, розділені розривами рядків, поля — `\|`, компоненти — `^` | JSON (або XML) |
| Транспорт | Зазвичай MLLP через TCP у межах лікарняної мережі | HTTPS REST |
| Запит | Обмежений; системи переважно надсилають дані | Параметри пошуку, `_include`, історія |
| Безпека | Рівень мережі (VPN, приватні канали) | OAuth 2.0 / SMART on FHIR, TLS, області дії |
| Гнучкість | Багато необов'язкових полів та локальних Z-сегментів; кожен інтерфейс узгоджується | Базові ресурси плюс профілі (US Core, IPS, European IGs) |
| Типові користувачі | EHR, лабораторні, радіологічні, білінгові системи в межах лікарні | Додатки, API для доступу пацієнтів, міжорганізаційний обмін, ШІ |

Найпоширеніші повідомлення v2:

| Повідомлення | Значення | Найближчі ресурси FHIR |
|---|---|---|
| ADT^A01, A03, A08 | Прийом, виписка, оновлення пацієнта | `Patient`, `Encounter` |
| ORM / OML | Замовлення тесту | `ServiceRequest` |
| ORU^R01 | Результат готовий | `Observation`, `DiagnosticReport` |
| SIU | Планування | `Appointment` |
| MDM | Документ | `DocumentReference` |

## Той самий лабораторний результат в обох форматах

Результат ORU^R01 (сегмент OBX):

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

Той самий результат як HL7 FHIR R4 Observation, як Anpheros зберігає його після імпорту цього повідомлення:

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

Поле за полем: OBX-3 стає `code`, OBX-5 та OBX-6 стають `valueQuantity`, OBX-7 `referenceRange`, OBX-8 `interpretation`, OBX-11 `status`, OBX-14 `effectiveDateTime`. HL7 публікує офіційний [HL7 Version 2 to FHIR](https://build.fhir.org/ig/HL7/v2-to-fhir/) посібник з реалізації з відображеннями сегментів, типів даних та словників.

## Де переклади йдуть неправильно

- **Часові пояси.** v2 мітки часу, такі як `20261002074500`, часто не містять зміщення; ви повинні знати часовий пояс відправника. FHIR вимагає часовий пояс, коли присутній час. (Anpheros читає v2 час без часового поясу як UTC; надсилайте зміщення, якщо воно у вас є.)
- **Локальні коди.** Багато лабораторій використовують власні коди в OBX-3 замість LOINC. Хороший переклад зберігає локальний код і зіставляє його з LOINC, коли це можливо, а не відкидає його.
- **Повторні надсилання.** Відправники v2 повторно передають дані при тайм-аутах. Без стабільного ідентифікатора на результат, FHIR сховище заповнюється дублікатами.
- **Все опціонально.** Одне й те саме поле може бути порожнім, повторюваним або використовуватися по-різному двома відправниками. Валідуйте сторону FHIR; [FHIR R4 validator](https://developers.anpheros.com/tools/fhir-validator) показує, чого не вистачає в перекладеному ресурсі.
- **Виправлення.** v2 статус результату `C` (виправлений) повинен оновлювати існуюче спостереження (Observation) і зберігати його історію, а не створювати друге.

## Коли що використовувати

- **Всередині лікарні, між існуючими системами:** v2 зазвичай є мовою, якою спілкуються системи. Інтеграційний рушій маршрутизує та трансформує повідомлення.
- **Створення програми, API для доступу пацієнтів або будь-чого, що виходить за межі організацій:** FHIR, з OAuth та згодою.
- **Живлення ШІ або аналітики:** FHIR, оскільки він запитуваний, кодований та версіонований.
- **Обидва:** поширений реальний шаблон — отримувати v2 з лабораторії або EHR, зберігати FHIR, надавати FHIR додаткам.

## Де Anpheros вписується

Anpheros зберігає записи пацієнтів у форматі FHIR R4 та приймає один тип повідомлень HL7 v2: **ORU^R01 лабораторні результати**, що надсилаються через HTTPS до [лабораторного конектора](https://developers.anpheros.com/uk/guides/lab-connector) (`POST /v1/patients/{id}/labs/import` з `Content-Type: x-application/hl7-v2+er7`). Кожен OBX стає лабораторним спостереженням (Observation) з кодом LOINC, референсним діапазоном та інтерпретацією; ідентифікатор звіту зберігається у походженні (provenance), а повторно надіслані звіти пропускаються. Виправлений результат (OBX-11 = `C`) з новим значенням зберігається як нове спостереження зі статусом `amended`; оригінал залишається незмінним, тому якщо ваше джерело надсилає виправлення, позначте попереднє спостереження `entered-in-error` або оновіть його через FHIR API. Практичний приклад: [Lab results API](https://developers.anpheros.com/uk/guides/lab-results-api).

Він не приймає інші повідомлення v2 (ADT, замовлення, планування), не слухає на MLLP і не надсилає v2. Для цього інтеграційний рушій перед Anpheros перекладає дані у FHIR та записує через API.

## Часті запитання

### Чи FHIR замінює HL7 v2?
Не скоро. v2 залишається основою в більшості лікарень, оскільки він працює і вбудований у наявні системи. FHIR розвивається навколо нього — у додатках, доступі пацієнтів та обміні між організаціями — і ці два стандарти співіснують, часто з перекладом між ними.

### Що таке MLLP?
Minimal Lower Layer Protocol: простий спосіб форматування повідомлень v2 через TCP-з'єднання, зі стартовими та кінцевими символами навколо кожного повідомлення та підтвердженням (ACK) у відповідь. FHIR натомість використовує HTTPS.

### Чи можу я автоматично конвертувати повідомлення HL7 v2 у FHIR?
Здебільшого. Посібник з реалізації HL7 v2-to-FHIR надає стандартні відображення, а інтеграційні рушії їх реалізують. Очікуйте ручної роботи для локальних кодів, Z-сегментів, часових поясів та того, як кожен відправник використовує необов'язкові поля.

### Чи Anpheros приймає HL7 v2?
Так, для лабораторних результатів: повідомлення ORU^R01, надіслані через HTTPS до лабораторного конектора, стають FHIR Observations. Інші типи повідомлень v2 та MLLP-з'єднання не підтримуються.

## Пов'язане

- [HL7 v2 до FHIR мапінг](https://developers.anpheros.com/uk/guides/hl7-v2-to-fhir-mapping): мапінг сегментів та полів, а також конвертер
- [API лабораторних результатів: HL7 v2, FHIR та LOINC](https://developers.anpheros.com/uk/guides/lab-results-api)
- [Як імпортувати лабораторні результати до запису FHIR](https://developers.anpheros.com/uk/guides/import-lab-results-fhir)
- [Інтероперабельність медичних даних](https://developers.anpheros.com/uk/guides/interoperability)
- [DICOM проти FHIR: дані візуалізації та клінічні дані](https://developers.anpheros.com/uk/guides/dicom-vs-fhir)
- [Платформа FHIR](https://developers.anpheros.com/uk/guides/fhir)