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-х годов — события, разделенные символом "pipe" (например, "пациент принят" или "готов лабораторный результат"), передаваемые между системами по сетевому соединению — в то время как 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) |
| Типичные пользователи | Системы ЭМК, лаборатории, радиологии, биллинга внутри больницы | Приложения, 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 показывает, чего не хватает в переведенном ресурсе.
- Исправления. Статус результата v2
C(исправлено) должен обновлять существующее наблюдение и сохранять его историю, а не создавать второе.
Когда что использовать
- Внутри больницы, между существующими системами: 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) с новым значением сохраняется как новое наблюдение (Observation) со статусом amended; исходный результат остается без изменений. Поэтому, если ваш источник отправляет исправления, пометьте предыдущее наблюдение entered-in-error или обновите его через FHIR API. Пример работы можно найти в Lab results API.
Anpheros не принимает другие сообщения 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