Объяснение сообщений HL7 v2 ORM и OML для заказов

Краткий ответ: в HL7 v2 заказ (лабораторный анализ, радиологическое исследование, назначение лекарства) отправляется как сообщение ORM^O01 в версиях до 2.5.1, или как сообщение о лабораторном заказе OML^O21 начиная с версии 2.4. Оба сообщения содержат информацию о пациенте (PID), визите (PV1), сегмент ORC, который управляет заказом (новый, отмена, приостановка, изменение статуса, с номерами отправителя и исполнителя), и сегмент OBR, который указывает, что было заказано, кем и на когда. Система-исполнитель отвечает сообщением ORR (или ORL для OML) и позднее возвращает результаты в виде ORU. Эквивалентом ORC+OBR в FHIR является ServiceRequest.

Лабораторный заказ, сегмент за сегментом

Сообщение HL7 v2 для лабораторного заказа (ORM^O01) состоит из сегментов: MSH указывает тип и версию сообщения, PID идентифицирует пациента, PV1 описывает визит, ORC содержит код управления заказом, номера заказа отправителя и исполнителя, приоритет и врача, назначившего исследование, OBR указывает запрошенный тест с кодом LOINC и время взятия образца, а DG1 — обосновывающий диагноз.

MSH|^~\&|EHR|GENHOSP|LIS|CENTRALLAB|20260314091200||ORM^O01^ORM_O01|MSG0001|P|2.5.1
PID|1||MRN-00012345^^^GENHOSP^MR||DOE^JANE||19800523|F|||12 High Street^^Leeds^^LS1 4AB^GB
PV1|1|O|CLINIC-3^^^GENHOSP||||42^SMITH^JOHN^^^Dr
ORC|NW|PLC-778812^EHR|||||^^^20260314093000^^R||20260314091200|42^SMITH^JOHN
OBR|1|PLC-778812^EHR||4548-4^Hemoglobin A1c/Hemoglobin.total in Blood^LN|||20260314093000||||||||42^SMITH^JOHN
DG1|1||E11.9^Type 2 diabetes mellitus without complications^I10

MSH-9 ORM^O01^ORM_O01 указывает тип сообщения, триггерное событие и структуру. MSH-12 указывает версию.
PID идентифицирует пациента; PID-3 содержит идентификатор с органом, который его выдал, и тип (MR, номер медицинской карты).
PV1 содержит информацию о визите: амбулаторный (O), местоположение, лечащий врач.
ORC-1 — это код управления заказом: NW новый заказ, CA запрос на отмену, OC заказ отменен, HD приостановлен, RL возобновлен, SC статус изменен, OK заказ принят, UA не удалось принять, XO изменение заказа, DC прекратить. ORC-2 — это номер заказа отправителя (присвоенный системой, которая сделала заказ), ORC-3 — номер заказа исполнителя (присвоенный лабораторией, пустой до получения ответа). ORC-7 содержит информацию о времени и приоритете (R обычный, S срочный, A как можно скорее). ORC-12 — это врач, назначивший исследование.
OBR-4 — это универсальный идентификатор услуги: что было заказано, с кодом (здесь LOINC, LN). OBR-7 — дата и время проведения исследования или сбора образца. OBR-16 повторяет информацию о враче, назначившем исследование. В лабораторных заказах детали образца находятся в OBR-15 в старых версиях и в отдельном сегменте SPM начиная с версии 2.5.
DG1 содержит диагноз, который является основанием для заказа.

Один и тот же заказ с несколькими тестами повторяет пару ORC/OBR один раз для каждого теста, каждый со своим уникальным идентификатором OBR-1.

ORM против OML

ORM^O01 — это общее сообщение HL7 v2 для заказа, имеющее свободную структуру для лаборатории, радиологии, аптеки и расходных материалов. OML, представленный в версии 2.4, является сообщением для заказа, специфичным для лаборатории, с триггерами O21, O33 и O35, а также явными сегментами SPM и SAC для образцов и контейнеров. Большинство интерфейсов больница-лаборатория по-прежнему используют ORM^O01; OML встречается в более новых лабораторных системах и профилях IHE.

ORM^O01 — это общее сообщение о заказе: одна структура для лаборатории, радиологии, аптеки, диетологии и расходных материалов, что делало ее гибкой. Начиная с версии 2.4, HL7 представила OML (лабораторный заказ) с несколькими триггерами: O21 (заказ по тесту), O33 (заказ по образцу) и O35 (заказ по образцу и контейнеру), а также более строгую структуру с сегментами SPM и SAC для образцов и контейнеров. OMG (общий клинический заказ), OMI (радиология), OMP (аптека) следовали тому же шаблону. На практике большинство интерфейсов между больницами и лабораториями по-прежнему работают на ORM^O01 в версиях 2.3.1 или 2.5.1, а OML появляется в более новых лабораторных системах и в профиле IHE Laboratory Testing Workflow.

Ответы

На заказ HL7 v2 поступают два ответа. Немедленный ACK (MSA-1 AA, AE или AR) подтверждает получение и разбор сообщения. Затем следует ответ приложения: ORR^O02 для ORM или ORL^O22 для OML, который повторяет ORC с кодом OK или UA и заполняет ORC-3, номер заказа исполнителя. Результаты позже возвращаются в виде ORU^R01, содержащего оба номера заказа.

Принимающая система отвечает дважды. Сразу же — сообщением ACK (MSA-1 AA принято, AE ошибка, AR отклонено), которое подтверждает получение и разбор сообщения. Затем, как ответ приложения, — сообщением ORR^O02 (для ORM) или ORL^O22 (для OML), повторяющим ORC с кодом OK или UA и заполняющим ORC-3, номер заказа исполнителя, который обе стороны используют с этого момента. Результаты возвращаются в виде ORU^R01, с теми же номерами отправителя и исполнителя в OBR-2 и OBR-3, что позволяет результату найти свой заказ. См. Сообщения HL7 v2: ADT и ORU.

Где заказы могут быть некорректны

Заказы HL7 v2 чаще всего нарушаются из-за несоответствия номеров отправителя и исполнителя, когда ORR не был обработан, использования локальных кодов тестов в OBR-4 без кода LOINC, отмен, отправленных без исходного номера отправителя, несоответствия версий, например, отправки сегмента SPM получателю версии 2.3.1, а также указания приоритета в свободной форме в NTE вместо ORC-7 или OBR-5.

Несовпадающие номера: ORU возвращается с номером исполнителя, который система электронных медицинских карт никогда не видела, обычно потому, что ORR не был обработан.
Локальные коды в OBR-4: внутренний код теста лаборатории вместо (или без) кода LOINC, поэтому принимающая система не может сопоставить тест. Решение — код, содержащий оба: GLU^Glucose^L~2345-7^Glucose [Mass/volume] in Serum or Plasma^LN.
Отмены без исходных номеров: CA должен содержать номер отправителя отменяемого заказа.
Несоответствие версий: сегмент SPM, отправленный приемнику версии 2.3.1, будет отброшен или отклонен.
Приоритет в неправильном поле: STAT в текстовом поле NTE вместо ORC-7 или OBR-5.

Тот же заказ в FHIR

В FHIR сегменты ORC и OBR заказа HL7 v2 объединяются в один ServiceRequest со статусом, намерением (order), приоритетом, кодом LOINC, субъектом, визитом, запрашивающим лицом, временем выполнения (occurrenceDateTime), кодом причины (reasonCode) для диагноза и идентификаторами номеров отправителя и исполнителя. Полученные Observation и DiagnosticReport ссылаются на него через basedOn, как это предусмотрено руководством по реализации HL7 v2-to-FHIR.

В FHIR сегменты ORC и OBR объединяются в один ServiceRequest: status (активный, на удержании, отозван, завершен), intent (order), priority (обычный, срочный, как можно скорее, экстренный), code (тест LOINC), subject, encounter, requester, occurrenceDateTime, reasonCode (диагноз ICD-10) и identifier для номеров отправителя и исполнителя. Результат Observation и DiagnosticReport ссылаются обратно через basedOn. HL7 публикует сопоставление полей в руководстве по реализации v2-to-FHIR.

Платформа Anpheros поддерживает ServiceRequest, Observation и DiagnosticReport, а ее лабораторный коннектор принимает результаты в форматах HL7 v2 ORU, CSV или JSON. Он не отправляет и не получает заказы; заказы остаются в системах больницы или лаборатории, а готовый результат добавляется в карту пациента.

Связанные страницы

Источники

Частые вопросы

В чем разница между ORC и OBR?

ORC касается заказа как административного объекта: кто его сделал, его номера, его статус, его приоритет. OBR касается запрашиваемой услуги: какой тест, на каком образце, когда. Каждому OBR предшествует его ORC.

Кто такой placer и filler?

Placer — это система, которая запрашивает услугу (EHR или система врача, делающего заказ); filler — это система, которая выполняет услугу (лаборатория или радиологическая система). Каждая присваивает свой собственный номер заказа, и сообщения содержат оба номера, чтобы любая сторона могла найти заказ.

Стоит ли мне внедрять ORM или OML для нового лабораторного интерфейса?

Если партнер поддерживает OML^O21 в версии 2.5.1 или новее, предпочтите его: обработка образцов явная, и профили IHE построены на нем. Если партнер — это старая LIS, она работает с ORM^O01, и вам придется адаптироваться.

Как заказ HL7 v2 сопоставляется с FHIR?

ORC и OBR вместе становятся ServiceRequest; номера placer и filler становятся идентификаторами; ORC-1 и ORC-5 сопоставляются со статусом; OBR-4 — с кодом; DG1 — с reasonCode; врач, назначивший исследование, — с requester. Руководство HL7 v2-to-FHIR публикует подробные таблицы.

Anpheros Platform

Попробуйте бесплатно в песочнице

Первый запрос FHIR за 5 минут. API HL7 FHIR R4 с встроенным согласием пациента: попробуйте в песочнице, затем подключите свое приложение или систему клиники.

Создать бесплатную песочницу Читать руководства для разработчиков →

Бесплатно · 30 синтетических пациентов · без карты

Это руководство носит информационный характер и не заменяет консультацию врача. Решения о своём здоровье принимайте вместе с врачом. В экстренной ситуации звоните по местному номеру экстренной помощи (112 в Европе).

Автор

Команда Anpheros

Anpheros создает медицинскую карту, которую пациент контролирует и может делиться с любой клиникой, на платформе HL7 FHIR R4, базирующейся в ЕС. Эти руководства помогут вам понять и организовать свое здоровье; они не заменяют вашего врача.

О Anpheros →