Пояснення повідомлень 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 повертається з номером виконавця, який EHR ніколи не бачив, зазвичай тому, що 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 зі статусом, наміром замовлення, пріоритетом, кодом LOINC, суб'єктом, візитом, запитувачем, occurrenceDateTime, причиною (reasonCode) для діагнозу та ідентифікаторами для номерів розміщувача та виконавця. Отримані Observation та DiagnosticReport посилаються на нього через basedOn, як це відображено в посібнику з реалізації HL7 v2-to-FHIR.

У FHIR ORC та OBR об'єднуються в один ServiceRequest: status (active, on-hold, revoked, completed), intent (order), priority (routine, urgent, asap, stat), code (тест LOINC), subject, encounter, requester, occurrenceDateTime, reasonCode (діагноз ICD-10) та identifier для номерів замовника та виконавця. Результат Observation та DiagnosticReport посилаються назад за допомогою basedOn. HL7 публікує відображення полів у посібнику з реалізації v2-to-FHIR.

Anpheros Platform підтримує ServiceRequest, Observation та DiagnosticReport, а її лабораторний конектор приймає результати у форматах HL7 v2 ORU, CSV або JSON. Він не надсилає та не отримує замовлення; замовлення залишаються в системах лікарні чи лабораторії, а готовий результат додається до запису пацієнта.

Пов'язані сторінки

Джерела

Поширені запитання

Яка різниця між ORC та OBR?

ORC стосується замовлення як адміністративного об'єкта: хто його розмістив, його номери, його статус, його пріоритет. OBR стосується запитуваної послуги: який тест, на якому зразку, коли. Кожному OBR передує його ORC.

Хто такий замовник (placer) та виконавець (filler)?

Замовник — це система, яка запитує послугу (EHR або система лікаря, що замовляє); виконавець — це система, яка її виконує (лабораторія або система радіології). Кожна призначає власний номер замовлення, і повідомлення містять обидва, щоб будь-яка сторона могла знайти замовлення.

Чи варто впроваджувати ORM чи OML для нового лабораторного інтерфейсу?

Якщо партнер підтримує OML^O21 у версії 2.5.1 або новішій, надавайте перевагу йому: обробка зразків є явною, і профілі IHE побудовані на ньому. Якщо партнер — це старіша LIS, то ORM^O01 — це те, що вона підтримує, і ви адаптуєтеся.

Як замовлення HL7 v2 відображається на FHIR?

ORC та OBR разом стають ServiceRequest; номери замовника та виконавця стають ідентифікаторами; 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 →