Посочените по-долу сегменти са с опростена, но валидна спрямо стандарта структура, заедно с пояснения. Ако изпращащото приложение попълва и други валидни полета и компоненти, извън посочените тук, то те няма да навредят на интеграцията.

MSH (Message Header) сегмента е задължителен за всички видове съобщения и съдържа данни за изпращача, получателя, версията, Id на съобщение и т.н.

БИС → ЛИС (При поръчка)

ЛИС → БИС (При резултат)

SFT (Software Segment) - този сегмент предоставя допълнителна информация за софтуерния продукт, използван като приложение за изпращане. Основната цел на този сегмент е за диагностика. Сегментът не е задължителен, но препоръчваме да се включи в съобщенията.

NTE (Notes and Comments) сегмента служи за описание на забележки. Полето е опционално и може да се повтаря.

Когато NTE е част от OML_021 (в основното тяло, непосредствено след MSH и евентуално SFT), то това се смята за забележка към поръчката. Очаква се NTE.4.1 да е със стойност RE.

Когато ЛИС iLab рапортува статус на поръчка (чрез OML_021 съобщение), по-специално в случай на отхвърляне на поръчка, в NTE в съобщението се подава причината за отхвърляне. В този случай NTE.4.1 е със стойност 1R (основна причина).

Забележките в ЛИС iLab могат да са на различни нива - на ниво визита и на ниво тест. Забележките от различните нива се попълват в NTE сегменти в различни групи на ORU_R01, както следва:

• Обща забележка към визитата - в NTE в група PATIENT, непосредствено след сегмента PID;
• Забележка към конкретен тест - в NTE в групата OBSERVATION, веднага след OBX;

Тъй като забележкитя нямат статус, следва при всяко следващо приемане, примащата страна да презаписва цялата забележка.

БИС → ЛИС

Декодирана забележката от примера по-горе следва да се визуализира като:

Това е тестова забележка, която дори включва специални символи кто |, ^, & и ~.
И дори Windows-style нов ред, както и Linux-style.
Демонстрира escape техниките в HL7.

ЛИС → БИС

Декодирана забележката от примера по-горе следва да се визуализира като:

Обща забележка към визитата
на два реда.
Хематология: СУЕ е фалшиво.
Биохимия: Албумина не е добре.

PID (Patient Identification) сегмента е задължителен за групата PATIENT, която по стандарт е опционална за OML_021, но задължителна за настоящата интеграция. Появява се веднъж и само веднъж. Описва идентификационни и демографски данни за пациента (виж Идентификация на пациента).

Поле PID.3 е от тип CX - Extended Composite ID with Check Digit - и служи за описание на идентификатори. Освен това е повтаряемо в репетиции. В компонент CX.1 (PID.3.1) се поставя самия идентификатор, като издателя и вида се описват според таблицата по-долу.

ВНИМАНИЕ: Посочването на пол и възраст, макар и опционално, е ключово за определяне на референтните граници, поради което следва да се попълват винаги, когато са налични. При непосочен пол, ЛИС iLab ще приложи референтни граници, приложими за двата пола, а при непосочена възраст - тези за 33г. Ако е посочен ЕГН, ЛИС iLab ще извлече пола и възрастта оттам, което не отменя попълването им.

БИС → ЛИС

В посочения по-горе пример PID.3 има три повторения (репетиции), които описват ЕГН (4503121207), ИЗ (5692/2017) и Id на пациента в БИС (2). Пациента е мъж, роден на 03 декември 1945 и се казва Янко Томов Генадиев.

ЛИС → БИС

В посочения по-горе пример PID.3 има четири повторения (репетиции), които описват ЕГН (9706166900), ИЗ в БИС (5692/2017), визита в ЛИС (167859) и Id на пациента в ЛИС (115658). Пациента е мъж, роден на 16 юли 1997 и се казва Християн Петров Димитров.

PV1 сегмента (Patient Visit) е задължителен за групата PATIENT VISIT, която пък е опционална за групата PATIENT w съобщенията OМL_O21 и ORU_R01. Описва данни за визитата. Доколкото е ключова за реализираната интеграция, групата и сегмента трябва да присъстват.

ЗАБЕЛЕЖКА: ЛИС попълва Assigned Patient Location (PV1.3) само когато изпраща резултати, които са следствие на HL7 поръчка от БИС. В този случай, ЛИС връща същите данни, които е получила от БИС при поръчката. Ако пациента е междувременно преместен, например в друга стая, ЛИС няма как да отрази този факт. Когато поръчката е направена на хартия или по телефон, ЛИС няма да попълни PV1.3.

В посочения пример, пациента е лежащо болен и се намира в Отделение хирургия (код на отделението 3310), стая 3, легло 2.

В примера резултатите са по визита 167859 по идентификацията на ЛИС, пациента се намира в Отделение хирургия (код на отделението 3310), стая 3, легло 2.

Сегментът е задължителен за съобщението Заявка за резултат (QRY_R02). Използва се за дефиниция на заявка.

ЛИС iLab обработва постъпилите заявки за резултати в опашка, поради което неглижира стойността от QRD.3. Всички заявки ще се обработят по реда на пристигането им, възможно най-бързо. Количественото ограничение от QRD.7 също ще бъде игнорирано, доколкото iLab ще изпрати резултат от една поръчка.

Сегментът ORC (Common Order) е задължителен за групата ORDER, която от своя страна е задължителна за Поръчка (OML_O21) и Статус на поръчка (OML_O21). В Резултат (ORU_R01) групата ORDER също е задължителна, но вече в нея сегмента ORC е опционален. Въпреки това, ЛИС iLab го попълва. ORC съдържа данни и информация, общи за всички тестове, съдържащи се в съобщението за поръчка.

В компоненти 9 и 11 на ORC.12 се уточнява вида да идентификатора от компонент 1, както следва:

Примера по-горе е от нова заявка с Id 158A, направена от Д-р Мария Димитрова Стаменова, с УИН 0300999977.

Примера е от резултат, който реферира HL7 заявка с Id 447696, направена от Д-р Александър Иванов Йовков с УИН 1999900015, която е приета за работа в ЛИС под визита с номер 16292 на 27.10.2017 в 07:31.

В примера ЛИС информира за промяна на статус на поръчка JHG6Y8R (в именно пространство R). Новия статус показва че изпълнението на поръчката е започнало (и вече е заключена). Номера на визита в iLab e 168321.

В настоящата интеграция сегмента TQ1 (Timing/Quantity) се използва за указване на приоритета на поръчката. iLab обработва само първото срещане на сегмента, доколкото приоритета е на ниво поръчка, а не на изследване. По тази причина е редно всички изследвания да се задават с един и същи приоритет.

В посочения пример, заявката е със нормален приоритет и е за бъдещо изпълнение, като заявения дата и час на превземане е 09:00 на 05.10.2017г.

OBR (Observation Request) сегмента служи за заявяване на конкретно изследване при заявка и за рефериране на изследването при резултат. Появява се веднъж и само веднъж в групата OBSERVATION REQUEST на OML_21. Също така присъства веднъж и в групата ORDER OBSERVATION на ORU_R01.

Важно е да се обърне внимание на изследвания със статус X (No results available; Order canceled), чрез който ЛИС указва на приемащата страна да изтрие евентуално вече получен резултат(и) по това изследване, защото то е анулирано или сторнирано.

В посочения пример е заявено изследване СУЕ с LOINC код 4537-7, като същото това изследване има Id в БИС 22.

В посочения пример се рапортуват резултати за изследване Пълна кръвна картина с LOINC код 57021-8, като същото това изследване има Id в ЛИС 1-1.

DG1 (Diagnosis) сегмента служи за описание на диагноза към поръчката. Съпровождане на поръчката с релевантна диагноза значително подобраява възможността за плаузибилитетния контрол в лабораторията. Сегмента се появява нула, веднъж или повече пъти в групата OBSERVATION REQUEST на OML_O21 съобщението. За интеграцията от значение са следните полета:

Предвид вида на интеграцията, следва във вид на диагнозата да се задават само работни диагнози, т.е. предполага се че в полето DG1.6 винаги ще има стойност W. Повече информация за МКБ-10 виж Диагнози. Макар и опционално по стандарт, поле 3 (Diagnosis Code) следва да се попълва, доколкото без него сегмента е безсмислен в настоящата интеграция.

В посочения пример е указана работна диагноза D56.0 - Алфа таласемия, като кодирането е по МКБ-10.

SPM (Specimen) сегмента служи за описание на пробата, от която да бъде или е извършено дадено изследване. Сегмента следва да се поддържа за OML_021 в интеграции, които позволяват пробовземане на място в отделението. ЛИС iLab предава SPM сегменти за всички проби, от които са извършени изследванията. Ключов момент при получаване на резултати е датата и часа на пробовземане.

БЕЛЕЖКИ: Когато ЛИС iLab предава резултати, при правилна настройка на системата, за всеки OBR сегмент (т.е. за всяко изследване) ще бъде изпратен един SPM сегмент. В някои случаи обаче, за един OBR ще се изпратят повече от един SPM сегменти. Това се получава при комплексни изследвания, които се извършват от повече от една проба, като например креатининов клирънс, при който се изследва серум и урина за да се получи резултата. При визуализация на резултата, приемащата страна следва да показва точка във времето ако всички проби са с едни и същи дата и час на пробовземане, и диапазон при разлика. При съобщение за промяна на статуса (OML_O21) и в случай на отхвърляне на едно или повече изследвания по причина негодност на пробата, ЛИС ще посочи това обстоятелство в SPM.21.

В посочения пример е реферирана епруветка с Пълна кръв, с баркод генериран от БИС L682167 и взета на 18 септември 2017г., в 02:12 часа.

В посочения пример е реферирана епруветка със Серум, с баркод генериран от ЛИС AIP3 и взета на 27 октомври 2017г., в 07:28 часа.

OBX (Observation/Result) сегмента служи за описание на резултат от тест.

• Има редица случаи, в които резултат не може да бъде докладван, поради невъзможност на лабораторията да добие такъв. Причините са много и варират от недостатъчно количество проба, негоден материал, липса на реактив и др. подобни. В този случай, в OBX-2 ще бъде изпратен знака * (звезда), а в OBX-11 - статус X;
• Неготовите тестове се рапортуват с I (pending). В ЛИС iLab има настройка (SkipPending) при която неготовите въобще не се рапортуват;
• След изработване на резултата (неготов → готов): при всяко изпращане се рапортува със статус F;
• При корекция на резултата (готов → готов): първо изпращане със статус C (corrected), всяко следващо - F.
• Ако резултата бъде изтрит (готов → неготов): при първо изпращане се рапортува с C (corrected), всяко следващо - отново със статус I (pending);
• Ако изследването бъде премахнато от визитата: при първо изпращане се указва статус D (deleted). При следващо изпращане позицията въобще липсва. Има настройка, според която изтрите въобще не се изпращат (SkipDeleted), която е удобна в случай че приемащата страна винаги регенерира цялата визита.

Има настройка в ЛИС iLab (SkipReported), при включване на която, след изпращане на финален резултат (F), и липса на промяна, при следващо изпращане теста не се рапортува.

ЛИС iLab поддръжа различни варианти (диалекти), като поведението ѝ се променя в някои детайли. Към момента реализацията на HL7 2.5.1 е в два варината - 10 и 11. Базовия вариант е 10, като в 11 има някои промени.

• При случай, в който резултат не може да бъде изработен, резултата идва със статус X или C, в зависимост дали до момента е имало докладван резултат, т.е. прехода неготов → не може да се изработи, става с I и следващ X, докато прехода готов → не може да се изработи става с F и следващ C. След евентуално възникнал случай на преход готов → невалиден (F → C), всяко следващо изпращане ще е отново със статус X.

В посочения пример е докладван резултат за изследване „WBC (левкоцити)“ с резултат 4.55, при мерни единици x10^9/L и референтна стойност 4.00 - 11.00. Изследването е извършено от Д-р Ненчо Домусчиев.

Сегментът BLG (Billing) се използва за предоставяне на информация за плащането за поръчаните услуги по поръчката. Сметката в случая е абстрактно понятие и стойностите ѝ се уточняват за всяка отделна интеграция. Виж Кодиране на обекти - Финансови данни за повече информация.

В ЛИС iLab една поръчка се презентира като една визита, като цялата е по един вид плащане. Ето защо всички изследвания в една поръчка (или допълнителна поръчка към нея) следва да са по една и съща сметка. На практика iLab ще обработи първото срещане на сегмента.

Сегментът MSA (Message Acknowledgment) се използва за указване на резултата от операция при отговор (виж Отговор (ACK)) на друго съобщение.

При отговор, в случай на отхвърляне на съобщение, може да има попълнено поле MSA.6 - Error Condition със стойности от таблица 0357:

Кодовете са максимално описателни, като много важни са стойностите 0, 101, 204, 205, 206 и 207:

• 0 (Message accepted): всичко е ОК, няма нужда от по-нататъшна обработка;
• 101 (Required field missing): липсва задължителен код, най-вече липсващи (или невалидни) едновременно ЕГН/ЕНЧ и ИЗ.
• 204 (Unknown key identifier): опит за актуализация или изтриване на поръчка, която не е правилно приета и не съществува в БД на ЛИС;
• 205 (Duplicate key identifier): опит за нова поръчка с номер (на поръчващата страна), който вече е използван (вече има заявка с такъв номер);
• 206 (Application record locked): опит за промяна или изтриване (анулиране) на поръчка, чието изпълнение е започнало (заключена е).
• 207 (Application internal error): вътрешна грешка, преимуществено проблем при връзката с базата данни.

При варианта допълнителна поръчка или просто актуализация, трябва да се следи за този код. Ако Той е 206, поръчващата страна трябва да направи нова поръчка, с вече различен номер и да реферира баркодовете на направената вече основна поръчка. Това е ключов момент в логиката на комуникация за да сработят допълнителните поръчки когато основната поръчка е вече заключена. Така или иначе, поръчващата страна винаги трябва да прави първо опит за актуализация на основната поръчка и ако записа е заключен – да прави нова допълнителна с референция към вече изпратените проби. Технически допустимо е изпращането на допълнителна поръчка и при все още незаключена основна, макар това да е логически необосновано и да затруднява вътрелабораторния процес.