Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
FHIR проти HL7 v2: практичні відмінності
Повідомлення HL7 v2 та ресурси FHIR порівняно для розробників: формат, транспорт, той самий лабораторний результат в обох, пастки перекладу та де Anpheros приймає 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 зберігає його після імпорту цього повідомлення:
{
"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 посібник з реалізації з відображеннями сегментів, типів даних та словників.
Де переклади йдуть неправильно
- Часові пояси. v2 мітки часу, такі як
20261002074500, часто не містять зміщення; ви повинні знати часовий пояс відправника. FHIR вимагає часовий пояс, коли присутній час. (Anpheros читає v2 час без часового поясу як UTC; надсилайте зміщення, якщо воно у вас є.) - Локальні коди. Багато лабораторій використовують власні коди в OBX-3 замість LOINC. Хороший переклад зберігає локальний код і зіставляє його з LOINC, коли це можливо, а не відкидає його.
- Повторні надсилання. Відправники v2 повторно передають дані при тайм-аутах. Без стабільного ідентифікатора на результат, FHIR сховище заповнюється дублікатами.
- Все опціонально. Одне й те саме поле може бути порожнім, повторюваним або використовуватися по-різному двома відправниками. Валідуйте сторону FHIR; FHIR R4 validator показує, чого не вистачає в перекладеному ресурсі.
- Виправлення. v2 статус результату
C(виправлений) повинен оновлювати існуюче спостереження (Observation) і зберігати його історію, а не створювати друге.
Коли що використовувати
- Всередині лікарні, між існуючими системами: v2 зазвичай є мовою, якою спілкуються системи. Інтеграційний рушій маршрутизує та трансформує повідомлення.
- Створення програми, API для доступу пацієнтів або будь-чого, що виходить за межі організацій: FHIR, з OAuth та згодою.
- Живлення ШІ або аналітики: FHIR, оскільки він запитуваний, кодований та версіонований.
- Обидва: поширений реальний шаблон — отримувати v2 з лабораторії або EHR, зберігати FHIR, надавати FHIR додаткам.
Де Anpheros вписується
Anpheros зберігає записи пацієнтів у форматі FHIR R4 та приймає один тип повідомлень HL7 v2: ORU^R01 лабораторні результати, що надсилаються через HTTPS до лабораторного конектора (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.
Він не приймає інші повідомлення 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 мапінг: мапінг сегментів та полів, а також конвертер
- API лабораторних результатів: HL7 v2, FHIR та LOINC
- Як імпортувати лабораторні результати до запису FHIR
- Інтероперабельність медичних даних
- DICOM проти FHIR: дані візуалізації та клінічні дані
- Платформа FHIR
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card