Коротка відповідь: лабораторний інтерфейс має два напрямки. Замовлення надходять з ЕМС до лабораторної інформаційної системи (ЛІС) у вигляді повідомлень HL7 v2 ORM^O01 або OML^O21 (або як FHIR ServiceRequest), а ЛІС відповідає повідомленнями ORR/ORL і пізніше результатами у вигляді ORU^R01 (або FHIR DiagnosticReport з Observations). Складність полягає не в самих повідомленнях, а в деталях всередині них: номери замовника та виконавця, що пов'язують результати із замовленнями, статус результату (попередній, остаточний, виправлений), прапорці відхилень, одиниці вимірювання та референсні діапазони, інформація про зразок, мікробіологія з її багатокомпонентними результатами та зіставлення кодів з LOINC. При правильному налаштуванні кожен результат потрапляє до правильного пацієнта, до правильного замовлення та на правильне місце в історії хвороби, зі збереженням свого значення.
Крок 1: узгодження потоків
Перший крок в інтеграції лабораторної інформаційної системи з ЕМС – це узгодження з лабораторією, які потоки даних існують: замовлення на виконання, оновлення статусу замовлень, отримання результатів, виправлення, скасування, додаткові та рефлекторні тести, а також передача демографічних даних ADT до ЛІС. Сторони також визначають версію HL7, зазвичай 2.3.1 або 2.5.1, і спосіб передачі, як правило, MLLP з підтвердженнями.
Визначте з лабораторією, які потоки існують: замовлення назовні (чи лабораторія отримує паперові документи та реєструє їх самостійно?), оновлення статусу замовлень, надходження результатів, виправлення, скасування, додаткові тести, рефлексні тести та демографічні дані (потік ADT до ЛІС, щоб вона знала пацієнта до надходження зразка). Намалюйте послідовність для нормального результату, виправленого результату та скасованого замовлення. Виберіть версію HL7 (найпоширеніші 2.3.1 та 2.5.1) та спосіб передачі (MLLP з ACK; іноді файли). Див. HL7 v2 повідомлення про замовлення.
Крок 2: повідомлення про результат, поле за полем
Результат лабораторного дослідження надходить до ЕМС як повідомлення HL7 v2 ORU^R01: MSH ідентифікує відправника та отримувача, PID – пацієнта, PV1 – візит, ORC та OBR містять номери замовлень від замовника та виконавця, замовлений панельний тест та статус звіту, а кожен OBX містить один аналіт з його кодом LOINC, значенням, одиницями вимірювання, референсним діапазоном, прапорцем аномальності та статусом результату.
MSH|^~\&|LIS|CENTRALLAB|EHR|GENHOSP|20260314130500||ORU^R01^ORU_R01|RES0001|P|2.5.1
PID|1||MRN-00012345^^^GENHOSP^MR||DOE^JANE||19800523|F
PV1|1|O|CLINIC-3^^^GENHOSP
ORC|RE|PLC-778812^EHR|FIL-556701^LIS|||||||||42^SMITH^JOHN
OBR|1|PLC-778812^EHR|FIL-556701^LIS|58410-2^CBC panel - Blood by Automated count^LN|||20260314084000|||||||||42^SMITH^JOHN||||||20260314130000|||F
OBX|1|NM|718-7^Hemoglobin [Mass/volume] in Blood^LN||10.9|g/dL|12.0-15.5|L|||F|||20260314125800
OBX|2|NM|6690-2^Leukocytes [#/volume] in Blood by Automated count^LN||6.4|10*3/uL|4.0-10.0|N|||F|||20260314125800
OBX|3|NM|777-3^Platelets [#/volume] in Blood by Automated count^LN||230|10*3/uL|150-400|N|||F|||20260314125800
NTE|1||Mild normocytic anaemia; suggest iron studies if clinically indicated.
- ORC-2 / OBR-2 номер замовника та ORC-3 / OBR-3 номер виконавця: зв'язок із замовленням. OBR-4: панель, закодована (LOINC
LN). OBR-7: час забору зразка. OBR-22: час звіту про результати. OBR-25: статус результату для всього замовлення (Pпопередній,Fостаточний,Cвиправлений,Xскасований). - OBX-2: тип значення (
NMчисловий,STрядок,TXтекст,CE/CWEкодований,SNструктурований числовий, наприклад<^5). OBX-3: аналіт, закодований. OBX-5: значення. OBX-6: одиниці вимірювання, бажано UCUM (10*3/uL, а неK/µL). OBX-7: референсний діапазон у вигляді тексту. OBX-8: прапорці відхилень (L,H,LL,HH,A,N). OBX-11: статус результату для аналіту (P,F,C,X,Dвидалено). OBX-14: час спостереження. OBX-19: час аналізу. - NTE: коментарі, прикріплені до OBR або до конкретного OBX за позицією.
- SPM (2.5+): тип зразка (SNOMED CT), час забору, час отримання, стан.
Крок 3: особливі випадки
Особливі випадки, які повинен обробляти лабораторний інтерфейс, включають: виправлені результати (статус C з оригінальними номерами замовлень, що замінюють і сповіщають, а не видаляють), попередні, а потім остаточні результати, мікробіологію з організмами та чутливістю, пов'язаними за суб-ID, текстові результати та вбудовані PDF-файли, рефлекторні та додаткові тести, скасування, а також одиниці вимірювання та референсні діапазони, які змінюються при зміні аналізаторів у лабораторії.
- Виправлення: новий ORU з
Cв OBR-25 та OBX-11 та тими ж номерами замовника/виконавця; ЕМС повинна замінити, позначити зміну та повідомити лікаря. Ніколи не видаляйте оригінал мовчки. - Попередній, потім остаточний: результати
P(фарбування за Грамом), за якими слідуютьF(культура); історія хвороби повинна відображати статус. - Мікробіологія: один OBX для ідентифікованого організму (кодований, SNOMED CT), потім результати чутливості як OBX для кожного антибіотика з організмом як під-ідентифікатором (OBX-4), часто в кількох повідомленнях. Саме тут ховається більшість помилок інтерфейсу.
- Текстові результати та PDF: коментарі з патології та деякі хімічні коментарі надходять як рядки TX або як вбудований PDF (OBX-2
ED); історія хвороби повинна містити як текст, так і файл. - Рефлексні та додаткові тести: нові OBR під оригінальним замовленням або нове замовлення, створене лабораторією; узгодьте, як вони нумеруються.
- Скасування: статус
X, з оригінальними номерами. - Одиниці вимірювання та діапазони для аналізатора: один і той же тест може змінювати одиниці вимірювання при зміні аналізаторів лабораторією; інтерфейс повинен передавати діапазон з кожним результатом, а не припускати його.
Крок 4: коди
Зіставлення кодів у лабораторному інтерфейсі означає одноразове перетворення локальних кодів тестів лабораторії на LOINC у таблиці, що підтримується, та надсилання як локального, так і коду LOINC у OBX-3, нормалізацію одиниць вимірювання до UCUM та кодування типів зразків та організмів у SNOMED CT. Без цього зіставлення результати не можуть бути відстежені між лабораторіями або прочитані зовнішніми системами.
Зіставте коди тестів лабораторії з LOINC один раз, у таблиці, що підтримується, і надсилайте як локальні коди, так і коди LOINC в OBX-3 (GLU^Glucose^L~2345-7^Glucose [Mass/volume] in Serum or Plasma^LN). Нормалізуйте одиниці вимірювання до UCUM. Типи зразків та організми в SNOMED CT. Метод описано в Як зіставити локальні лабораторні коди з LOINC; без цього результати неможливо відстежувати між лабораторіями або читати будь-якою зовнішньою системою.
Крок 5: альтернатива FHIR
Альтернатива FHIR для лабораторного інтерфейсу HL7 v2 використовує ServiceRequest для замовлення, один Observation для кожного аналіту з кодом LOINC, кількістю UCUM, референсним діапазоном та інтерпретацією, а також DiagnosticReport, який групує їх зі статусом, виконавцем, часом видання, висновком та PDF. Доставка здійснюється через REST-записи, транзакційний Bundle для кожного звіту або FHIR Subscriptions.
З FHIR замовленням є ServiceRequest, результатами – Observations (один на аналіт, код LOINC, кількість UCUM, referenceRange, interpretation), згруповані DiagnosticReport, який містить статус, виконавця, час видачі, висновок та PDF, з посиланням basedOn на ServiceRequest. Виправлення – це версії тих самих ресурсів зі статусом amended або corrected. Доставка здійснюється через REST запити до FHIR-сервера ЕМС, Bundle транзакції на звіт або через Subscriptions. Посібник з перетворення HL7 v2 на FHIR відображає кожне поле вище; багато лабораторій зараз пропонують обидва варіанти. Див. FHIR DiagnosticReport пояснення та FHIR Observation пояснення.
Крок 6: тестування та запуск
Тестування лабораторного інтерфейсу перед запуском означає прогін синтетичних пацієнтів через усі особливі випадки, порівняння денних паралельних результатів між лабораторним звітом та картою ЕМС, перевірку часових зон та переходів на літній/зимовий час, перевірку обробки підтверджень та повторної передачі після збою, а також узгодження процедури чергування для невдалих повідомлень, використовуючи профіль IHE Laboratory Testing Workflow як базовий.
Тестуйте на синтетичних пацієнтах кожен випадок з кроку 3; порівняйте денні паралельні результати з паперового або PDF-звіту та історії хвороби; перевірте часові пояси та перехід на літній/зимовий час; перевірте обробку ACK та повторне надсилання після збою; узгодьте процедуру чергування для збоїв повідомлень. Профіль Laboratory Testing Workflow від IHE та національні набори для перевірки відповідності надають протестовану базову лінію.
Невдачі, проти яких слід проектувати
Збої, проти яких повинен бути спроектований лабораторний інтерфейс, включають: результати, що потрапили до попереднього візиту, об'єднання пацієнтів, які не були застосовані до ЛІС, зміни одиниць вимірювання після оновлення аналізатора, що зміщують тенденції, виправлені результати, що перезаписують без сповіщення, мікробіологічні чутливості, пов'язані з неправильним організмом, та результати тестів, для яких ЕМС не має коду, що зникають у черзі помилок.
Результати, що потрапили до попередньої зустрічі через застарілий PV1; злиття (ADT A40), яке не було застосовано до ЛІС; зміна одиниць вимірювання після модернізації аналізатора, що непомітно змінила тенденції; виправлені результати, що перезаписалися без сповіщення; результати чутливості мікробіології, прикріплені до неправильного організму; лабораторія, що надсилає результати для тесту, для якого ЕМС не має коду, які потім зникають у черзі помилок.
В Anpheros
Лабораторний конектор Anpheros приймає ORU^R01, CSV та JSON і створює Observations у складі DiagnosticReport з LOINC та UCUM, зберігаючи локальні коди та оригінальний файл; посібник для розробників з імпорту лабораторних результатів детально описує це на безкоштовному пісочниці.
Пов'язані сторінки
- HL7 v2 повідомлення про замовлення ORM та OML
- Пояснення повідомлень HL7 v2: ADT та ORU
- Як зіставити локальні лабораторні коди з LOINC
- FHIR DiagnosticReport пояснення
- Лабораторний конектор: HL7 v2, CSV або JSON до FHIR
- Пояснення інтерфейсних рушіїв
- Імпорт лабораторних результатів у FHIR (сайт для розробників)
Джерела
- HL7 v2.5.1 ORU_R01 довідник (Caristix)
- HL7 v2.5.1 сегмент OBX (Caristix)
- Технічний фреймворк IHE Laboratory (LTW)
- Посібник з реалізації HL7 v2 до FHIR
- HL7 FHIR R4: DiagnosticReport
Поширені запитання
Яку версію HL7 слід використовувати для нового лабораторного інтерфейсу?
2.5.1, якщо обидві сторони її підтримують: вона має SPM для зразків та чіткішу обробку статусів. Багато лабораторій все ще використовують 2.3.1, і інтерфейс адаптується до старішої версії.
Як результати зіставляються із замовленнями?
За номером замовлення замовника (призначеним ЕМС) та номером замовлення виконавця (призначеним ЛІС), що передаються в ORC-2/3 та OBR-2/3 як відповіді на замовлення, так і результату. Якщо ЕМС ніколи не записувала номер виконавця, зіставлення відбувається за номером замовника.
Що робити, якщо лабораторія не може надсилати коди LOINC?
Зіставте їхні локальні коди з LOINC на вашому боці, в рушії або конекторі, і зберігайте обидва. Наполягайте на тому, щоб система локальних кодів була стабільною, а про нові тести повідомлялося заздалегідь.
Чи готовий FHIR для лабораторних інтерфейсів?
Так, для нових підключень, особливо поза лікарнею: ServiceRequest, Observation та DiagnosticReport повністю охоплюють замовлення та результати, а національні посібники їх форматують. Усередині лікарні ЛІС та аналізатори ще роками спілкуватимуться мовою HL7 v2.
Спробуйте безкоштовно в пісочниці
Перший запит FHIR за 5 хвилин. API стандарту HL7 FHIR R4 з вбудованою згодою пацієнта: спробуйте в пісочниці, а потім підключіть власну програму чи клінічну систему.
Безкоштовно · 30 синтетичних пацієнтів · без картки
Anpheros створює медичну карту, яку пацієнт контролює та може ділитися з будь-якою клінікою, на платформі HL7 FHIR R4, розташованій в ЄС. Ці посібники допоможуть вам зрозуміти та організувати своє здоров'я; вони не замінюють вашого лікаря.
Про Anpheros →