Инструменти за потребители

Инструменти за сайта


segments

Сегменти

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

MSH сегмент

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

Поле O/R Данни Значение
MSH.1 R Field Separator Разделител на полета, да се ползва |
MSH.2 R Encoding Characters Кодиращи символи, да се ползва ~\&
MSF.3 O Sending Application Изпращащо приложение
  MSH.3.1 О Sending Application Изпращащо приложение
MSF.4 O Sending Application Изпращаща институция
  MSH.4.1 О Sending Facility Изпращаща институция
MSH.5 О Receiving Application Приемащо приложение
  MSH.5.1 О Receiving Application Приемащо приложение
MSH.6 О Receiving Facility Приемаща институция
  MSH.6.1 О Receiving Facility Приемаща институция
MSH.7 R Date/Time Of Message Дата и час на изпращане
  MSH.7.1 R Time Дата и час с точност до секунда (YYYYMMDDhhmmss)
  MSH.7.2 O Degree Of Precision Точност на датата, ползва се S (секунди)
MSH.9 R Message Type Вид съобщение
  MSH.9.1 R Message Code Код на съобщение, според таблица 0076, да се ползва:
OML - при поръчка и промяна на статус
ORU - при резултат
ACK - при отговор
  MSH.9.2 R Trigger Event Събитие на съобщение, според таблица 0003, да се ползва:
О21 - при поръчка и промяна на статус
О01 - при резултат
При отговор се връща събитието на което се отговаря
  MSH.9.3 R Message Structure Структура на съобщение, според таблица 0354, да се ползва:
OML_O21 - при поръчка и промяна на статус
ORU_O01 - при резултат
ACK - при отговор
MSH.10 R Message Control ID Идентификатор на съобщението (например GUID)
MSH.11 R Processing ID Правило за обработка
  MSH.11.1 O Processing ID Правило за обработка, според таблица 0103, да се ползва P (Production)
MSH.11 R Version ID Версия на протокола
  MSH.12.1 O Version ID Версия на протокола, да се ползва 2.5.1

Примери

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

MSH|^~\&|BestHIS|МБАЛ АД|iLab|Клинична лаборатория|20171007135014||OML^O21^OML_O21|6ecd1ec3|P|2.5.1

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

MSH|^~\&|iLab|Клинична лаборатория|BestHIS|МБАЛ АД|20171007134240||ORU^R01^ORU_R01|6ecd1ec4|P|2.5.1

SFT сегмент

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

Поле O/R Данни Забележка
SFT.1 R Software Vendor Organization Компанията-разработчик
  SFT.1.1 О Organization Name Име на компанията-разработчик
SFT.2 R Software Certified Version or Release Number Версия на софтуерния продукт
SFT.3 R Software Product Name Име на софтуерния продукт
SFT.4 R Software Binary ID Да се ползва отново версията, както в SFT.2

Пример

SFT|SKYWARE Group|2.0.0.4848|HL7Orders|2.0.0.4848

NTE сегмент

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

Поле O/R Данни Забележка
NTE.1 O Set ID Номер на набор, пореден номер от 1
NTE.3 O Comment Забележка към поръчката/резултата, до 65536 символа
NTE.4 O Comment Type Вид на забележка, според таблица 0364
   NTE.4.1 O Identifier Идентификатор, ползват се:
RE (Remark)
1R (Primary Reason)
   NTE.4.1 O Name Of Coding System Кодираща система, ползва се HL70364

В OML_O21 (при поръчка)

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

В OML_O21 (при статус на поръчка)

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

В ORU_R01

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

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

Примери

БИС → ЛИС

NTE|1||Това е тестова забележка, която дори включва специални символи кто \F\, \S\, \T\ и \R\.\X000d\\X0A\И дори Windows-style нов ред, както и Linux-style.\X000d\ Демонстрира escape техниките в HL7.|RE^^HL70364

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

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

ЛИС → БИС

NTE|1||Обща забележка към визитата\X000d\\X0A\на два реда.\X000d\\X0A\Хематология: СУЕ е фалшиво.\X000d\\X0A\Биохимия: Албумина не е добре.|RE^^HL70364

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

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

PID сегмент

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

Поле O/R Данни Значенние
PID.3 R Patient Identifier List Списък с идентификатори на пациента
  PID.3.~.1 R Id Number Идентификатор на пациента
  PID.3.~.4 R Assigning Authority Издател на идентификатора
    PID.3.~.4.1 R Namespace Id Издател на идентификатора
  PID.3.~.5 R Identifier Type Code Тип на идентификатора, според таблица 0203, виж по-долу
PID.5 R Patient Name Име на пациента
  PID.5.1 R Family Name Фамилно име на пациента
  PID.5.2 R Given Name Малко име на пациента
  PID.5.3 O Second And Further Given Names Or Initials Thereof Презиме на пациента
PID.7 O Date/Time of Birth Дата на раждане на пациента
  PID.7.1 O Date of birth Дата на раждане на пациента, с точност до ден (YYYYMMDD)
  PID.7.2 O Degree Of Precision Точност на датата, ползва се D (ден)
PID.8 O Administrative Sex Пол на пациента, според таблица 0001, ползват се:
F - Female – Жена
M - Male – Мъж
U - Unknown - неизвестен

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

PID.3.4.1 (CX.4.1)
Assigning Authority
Таблица 0363
PID.3.5 (CX.5)
Identifier Type Code
Таблица 0203
Вид идентификатор Попълва се от
GRAO NI ЕГН БИС и ЛИС
MVR NI ЕНЧ / ЛНЧ БИС и ЛИС
Hospital MR ИЗ (История на заболяването, лежащо болни) БИС и ЛИС
Ambulatory MR Амбулаторен номер (доболничен прием) БИС и ЛИС
Laboratory MR Id на визита в ЛИС ЛИС
HIS XX Id на пациента в БИС БИС
LIS XX Id на пациента в ЛИС ЛИС

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

Пример

БИС → ЛИС

PID|1||4503121207^^^GRAO^NI~5692/2017^^^Hospital^MR~2^^^HIS^XX||Генадиев^Янко^Томов||19450312|M

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

ЛИС → БИС

PID|1||9706166900^^^GRAO^NI~5692/2017^^^Hospital^MR~167859^^^Laboratory^MR~115658^^^LIS^XX||Димитров^Християн^Петров||19970616|M

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

PV1 сегмент

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

Поле O/R Данни Значение Попълва се от
PV.1 O Set ID Id на набора БИС/ЛИС
PV.2 R Patient Class Вид пациент, според таблица 0004
При OML_021 да се ползват:
E - Emergency - Спешен
I - Inpatient - Лежащо болен
O - Outpatient - Амбулаторен
P - Preadmit - При приемане
R - Recurring patient - не се ползва
B - Obstetrics - Акушерство (новородени)
C - Commercial Account - Външни клиенти, по договор
N - Not Applicable - Не е приложимо
U - Unknown - Неизвестен
При ORU_R01 iLab задава винаги
N - Not Applicable - Не е приложимо
БИС и ЛИС
PV1.3 O Assigned Patient Location Местонахождение на пациента БИС и ЛИС
  PV1.3.1 O Point Of Care Име на отделението направило заявката и място на пролежаване на пациентаБИС и ЛИС
  PV1.3.2 O Room Стая в отделение, в която пролежава пациента (за лежащо болни) БИС и ЛИС
  PV1.3.3 O Bed Легло на което пациента пролежава (за лежащо болни) БИС и ЛИС
  PV1.3.4 O Facility Код на отделението (звено) в лечебното заведение.
По този код ЛИС разпознава поръчителя и прилага необходимите цени и/или други данни за поръчката, в т.ч. определя местонахождението на пациента в дадена болница за целите на бъдещи заявки
БИС и ЛИС
PV1.19 O Visit Number Id на визита в ЛИС ЛИС
  PV1.19.1 O Id Number Id на визита в ЛИС ЛИС
  PV1.19.4 O Assigning Authority Издател на Id на визита, ползва се Laboratory ЛИС
  PV1.19.5 O Identifier Type Code Вид на Id на визита, полза се MR ЛИС
PV1.44 O Admit Date/Time Дата и час на регистрация на визитата в ЛИС iLab ЛИС
  PV1.44.1 O Time Дата и час с точност до минута ЛИС
  PV1.44.2 O Degree Of Precision Прецизност на датата и часа, ползва се M (минути) ЛИС
PV1.51 O Visit Indicator Индикатор на визита, според таблица 0326, ползва се V (Visit level) ЛИС

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

Примери

БИС -> ЛИС

PV1|1|I|Отделение хирургия^3^2^3310

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

ЛИС -> БИС

PV1|1|N|Отделение хирургия^3^2^3310||||||||||||||||167859^^^Laboratory^MR

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

QRD сегмент

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

Поле O/R Данни Значение
QRD.1 R Query Date/Time Дата и час на генериране за заявката
QRD.2 R Query Format Code Формат на искания резултат, според таблица 0106, използва се само стойността R (Response is in record-oriented format)
QRD.3 R Query Priority Приоритет на заявката, според таблица 0091, ползва се D (Deferred)
QRD.4 R Query ID Идентификатор на заявката (A-Z,0-9, до 10 символа)
QRD.7 R Quantity Limited Request Ограничение в броя резултати
  QRD.7.1 O Quantity Цяло число - брой визити (ползва се 1)
  QRD.7.1 O Units Единици на ограничението, според таблица 0126 (ползва се RD - Records)
QRD.8 R Who Subject Filter Пациент, чийто данни се заявяват. Полето е от тип XCN (Extended Composite ID Number and Name for Persons)
  QRD.8.1 R Id Number Id на поръчката от БИС
  QRD.8.9.2 O Assigning Authority - Universal Id Издател на идентификатора, да се полза HISORD
QRD.9 R What Subject Filter Вид на исканите данни, според таблица 0048, ползва се RES - Result (лабораторни резултати)
QRD.10 10 What Department Data Code Код на отделение от което се искат данните, ползва се кода на лабораторията, така както е зададен в БИС

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

ORC сегмент

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

Поле O/R Данни Значение Попълва се от
ORC.1 R Order Control - Order Action Според таблица 0119
При поръчка (OML_O21) се ползват:
NW – Нова заявка
XO – Модификация на заявка
CA – Анулиране на заявка
При резултат (ORU_R01) се ползват:
RE - Рапортуване на резултат
При промяна на статус (OML_O21) се ползва:
SC - Смяна на статус
БИС и ЛИС
ORC.2 C Placer Order Number Идентификатор на заявката в БИС БИС
  ORC.2.1 C Entity Identifier Буквено-цифров идентификатор (до 22 символа) на заявката, който я идентифицира уникално в дадена интеграция, реферира се в резултатите, чрез него се прави модификация и анулиране БИС и ЛИС
  ORC.2.2 O Namespace Id Именно пространство на идентификатора на заявката според БИС БИС и ЛИС
ORC.3 C Filler Order Number Идентификатор на заявката в ЛИС ЛИС
  ORC.3.1 C Entity Identifier Идентификатор на заявката в ЛИС (Визита Id), число до 22 разряда ЛИС
  ORC.3.2 O Namespace Id Именно пространство на идентификатора на заявката според ЛИС ЛИС
ORC.5 O Order Status Статус на заявката, според таблица 0038, ползват се:
IP - In process, unspecified (започнала обработка на заявката в ЛИС, заявката е вече заключена)
DC - Order was discontinued - заявката е отхвърлена (също заключена)
ЛИС
ORC.7 O Quantity/Timing Дата и час на пробовземане (backward compatibility), за нови приложения да се ползва TQ1.7 БИС и ЛИС
  ORC.7.4 O Start Date/Time При поръчка (OML_021):
Дата и час на желано пробовземане, без стойност за съпровождащи поръчки и с бъдеща дата за бъдещи поръчки, да се ползва TQ1
При резултат (ORU_R01):
Дата и час на регистрация визитата (да не се бърка с дата и час на пробовземане), може да се пренебрегне, доколкото няма клинично значение
БИС и ЛИС
ORC.12 O Ordering Provider Поръчващ лекар БИС и ЛИС
  ORC.12.1 O Id Number Id - да се ползва УИН, издаден от БЛС БИС и ЛИС
  ORC.12.2 O Family Name Фамилия БИС и ЛИС
  ORC.12.3 O Given Name Лично име БИС и ЛИС
  ORC.12.4 O Second And Further Given Names Or Initials Thereof Презиме БИС и ЛИС
  ORC.12.6 O Prefix (e.g., Dr) Степен/Титла, например Д-р, Проф. Д-р, Доц. Д-р и т.н. БИС и ЛИС
  ORC.12.9.1 O Assigning Authority Издател на идентификатора, да се полза BLS БИС и ЛИС
  ORC.12.13 O Identifier Type Code Вид на идентификатора, да се полза DN БИС и ЛИС

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

ORC.12.9.1 (XCN.9.1)
Assigning Authority
Таблица 0363
ORC.12.13 (XCN.13)
Identifier Type Code
Таблица 0203
Вид идентификатор
BLS DN УИН

Примери

БИС -> ЛИС

ORC|NW|158A||||||||||0300999977^Стаменова^Мария^Димитрова^^Д-р^^^BLS^^^^DN

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

ЛИС -> БИС (Резултат)

ORC|RE|447696|16292^iLab||||^^^201710270731|||||1999900015^Йовков^Александър^Иванов^^Д-р^^^BLS^^^^DN

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

ЛИС -> БИС (Промяна на статус)

ORC|SC|JHG6Y8R^R|168321^iLab||IP

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

TQ1 сегмент

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

Поле O/R Данни Значение
TQ1.1 O Set ID
TQ1.7 O Start Date/Time Дата и час на пробовземане
  TQ1.7.1 O Time Желани дата и час на пробовземане с точност до минута (YYYYMMDDhhmm)
TQ1.9 O Priority Приоритет на поръчката
  TQ1.9.1 O Identifier Код на приоритет на поръчката, според таблица 0485, да се ползват:
R - Routine - Рутинна (Нормална)
S - Stat - Спешна
  TQ1.9.2 O Text Приоритет на поръчката като текст (Routine или STAT)

Пример

TQ1|1||||||201710050900||R^Routine

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

OBR сегмент

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

Поле O\R Данни Значение Попълва се от
OBR.1 O Set ID Id а набор БИС и ЛИС
OBR.2 R Placer Order Number Идентификатор на заявката според БИС БИС и ЛИС
  OBR.2.1 R Entity Identifier Идентификатор на заявката според БИС БИС и ЛИС
  OBR.2.2 O Namespace Id Именно пространство на идентификатора на заявката според БИС БИС и ЛИС
OBR.3 C Filler Order Number Идентификатор на заявката според ЛИС ЛИС
  OBR.3.1 C Entity Identifier Идентификатор на заявката според ЛИС ЛИС
  OBR.3.2 C Namespace Id Именно пространство на идентификатора на заявката според ЛИС ЛИС
OBR.4 R Universal Service Identifier Код на изследването БИС и ЛИС
  OBR.4.1 R Identifier Код на изследването (виж Кодиране на обекти - Изследвания) БИС и ЛИС
  OBR.4.2 R Text Наименование на изследването според БИС БИС и ЛИС
  OBR.4.3 R Name Of Coding System Име на кодиращата система, според таблица 0396, да се ползва LN за LOINC (виж Кодиране на обекти - Изследвания) БИС и ЛИС
  OBR.4.4 O Alternate Identifier Алтернативен код на изследването, например Id според БИС или ЛИС (за диагностика на комуникацията) БИС и ЛИС
  OBR.4.6 O Name Of Alternate Coding System Име на алтернативната кодиращата система, според таблица 0396, да се ползва HCPT (Health Care Provider Taxonomy - за идентификация според БИС или ЛИС) БИС и ЛИС
OBR.7 R Observation Date/Time Дата/час на изследването ЛИС
  OBR.7.1 R Time Дата/час на изследването - съвпада с дата/часа на пробовземане - с точност до минута (YYYYMMDDhhmm) ЛИС
  OBR.7.2 R Degree Of Precision Точност на часа, ползва се M (минути) ЛИС
OBR.20 O Filler Field 1 Резервно поле 1 на ЛИС. В това поле се изпраща името на отдела, в който е причислено изследването, например „Хематология“, „Биохимия“ и т.н. ЛИС
OBR.21 O Filler Field 2 Резервно поле 2 на ЛИС. В това поле се изпраща информация дали дадения запис е тест или панел, като с 0 = тест (например Глюкоза), 1 = панел от тестове (напр. Кръвна картина) ЛИС

Примери

БИС -> ЛИС

OBR|1|158A^R||4537-7^СУЕ^LN^22^^HCPT

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

ЛИС -> БИС

OBR|1||272236^iLab|57021-8^Пълна кръвна картина^LN^1-1^^HCPT|||201806270729|||||||||||||Хематология|1

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

DG1 сегмент

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

Поле O/R Данни Значение
DG1.1 R Set ID Id на набора (пореден номер от 1 за списък от диагнози)
DG1.3 O Diagnosis Code Диагноза
  DG1.3.1 O Identifier Код на диагнозата
  DG1.3.2 O Text Текст на диагнозата
  DG1.3.3 O Name Of Coding System Използвана система за кодиране, според таблица 0396, да се използва само I10 (МКБ-10)
DG1.6 R Diagnosis Type Вид на диагнозата, според таблица 0052 както следва:
A - Admitting - При приемане
W - Working - Работна
F - Final - Окончателна

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

Пример

DG1|1||D56.0^Алфа таласемия^I10|||W

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

SPM сегмент

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

Поле O/R Данни Значение Попълва се от
SPM.1 O Set ID Id на набора БИС и ЛИС
SPM.2 O Specimen ID Идентификатор на пробата БИС и ЛИС
  SPM.2.1 O Placer Assigned Identifier Id на пробата (баркод етикета), генериран от БИС БИС
  SPM.2.2 O Filler Assigned Identifier Id на пробата (баркод етикета), генериран от ЛИС ЛИС
SPM.4 R Specimen Type Вид на пробата БИС и ЛИС
  SPM.4.1 O Identifier Идентификатор на вида пробата (например SER - Серум по LOINC, 122590004 - Серум по SNOMED CT)
  SPM.4.2 O Text Наименование (например Серум) БИС и ЛИС
  SPM.4.3 O Name Of Coding System Кодираща система, според таблица 0396, да се ползва:
SNM3 - SNOMED International
HL70487 - Таблица 0487 на HL7
HCPT - Health Care Provider Taxonomy - за локална кодировка
БИС и ЛИС
SPM.17 O Specimen Collection Date/Time Дата и час на пробовземане, с точност до минута (YYYYMMDDhhmm) БИС и ЛИС
  SPM.17.1 O Time Дата и час БИС и ЛИС

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

Примери

БИС -> ЛИС

SPM|1|L682167||BLD^Пълна кръв^HL70487|||||||||||||201709180212

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

ЛИС -> БИС

SPM|1|^AIP3||SER^серум^HL70487|||||||||||||201710270728

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

OBX сегмент

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

Поле O/R/C Данни Значение
OBX.1 O Set ID Id на набора
OBX.2 C Value type Тип на резултата, според таблица 0125, ползват се:
NM - Numeric - числов резултат
TX - Text Data (Display) - текстов резултат
Липсва при изтриване (статус D)
OBX.3 R Observation Identifier Идентификатор на теста
  OBX.3.1 O Identifier Идентификатор на теста, по система LOINC
  OBX.3.2 O Text Име на теста
  OBX.3.3 O Name Of Coding System Кодираща система според таблица 0396, ползва се LN (LOINC)
  OBX.3.4 O Alternate Identifier Алтернативен код, ползва се код на системата-изпращач
  OBX.3.6 O Name Of Alternate Coding System Алтернативна кодираща система според таблица 0396, ползва се HCPT (таксономия на локална система)
OBX.5 O Observation Value Резултат от теста
OBX.6 O Units Мерна единица, в която е изразен резултата (виж Мерни единици)
OBX.7 O References Range Референтна граница, приложена за този тест, за този пациент (зависи от пола и възрастта)
OBX.8 O Abnormal Flags Флаг на резултата, според таблица 0078, ползват се:
< Below absolute low-off instrument scale - под измерима граница
LL - Below lower panic limits, под долна паник граница
L - Below low normal - под долна граница
H - Above high normal - над горна граница
HH - Above upper panic limits - над горна паник граница
> Above absolute high-off instrument scale над горна измерима граница
N - Normal (applies to non-numeric results) - В норма (за нечислови резултати)
A - Abnormal (applies to non-numeric results) - Патологична стойност (за нечислови резултати)
AA - Very abnormal (applies to non-numeric units, analogous to panic limits for numeric units) - Много патологична стойност (за нечислови резултати)
S - Susceptible. Indicates for microbiology susceptibilities only. - Чувствителен (микробиология)
R - Resistant. Indicates for microbiology susceptibilities only. - Резистентен (микробиология)
I - Intermediate. Indicates for microbiology susceptibilities only. - Средно чувствителен (микробиология)
OBX.11 R Observation Result Status Статус на резултата според таблица 0085, ползват се:
I - Specimen in lab; results pending - В процес на работа
F - Final results; Can only be changed with a corrected result. - Финален резултат
C - Record coming over is a correction and thus replaces a final result - Корекция на вече изпратен финален резултат
P - Preliminary results - Предварителен резултат
R - Results entered, not verified - Невалидиран резултат
X - Results cannot be obtained for this observation - Резултата не може да бъде изработен
D - Deletes the OBX record - Изследването е изтрито
OBX.14 O Date/Time of the Observation Дата и час на вземане на пробата, от която е извършено изследването, с точност до минута (YYYYMMDDhhmm)
Ако за изследването няма асоциирана проба - дата и час на визитата
  OBX.14.1 O Time Дата и час
  OBX.14.2 O Degree Of Precision Точност на часа, ползва се M (минути)
OBX.16 O Responsible Observer Отговорен лекар
  OBX.16.1 O Id Number УИН
    OBX.16.2.1 O Family Name Фамилия на лекаря
  OBX.16.3 O Given Name Име на лекаря
  OBX.16.3 O Second And Further Given Names Or Initials Thereof Презиме на лекаря
  OBX.16.6 O Prefix (e.g., Dr) Титла на лекаря (Д-р, Проф. и т.н.)
  OBX.16.6 O Assigning Authority Издател на идентификатора, ползва се BLS
  OBX.16.13 O Identifier Type Code Вид на идентификатора според таблица 0203, ползва се DN (Doctor number)

Записки по OBX.11

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

Пример

OBX|1|NM|47281-1^WBC (левкоцити)^LN^0-215^^HCPT||4.55|x10\S\9/L|4.00 - 11.00||||F|||||2299999901^Домусчиев^Ненчо^Велинов^^Д-р^^^BLS^^^^DN

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

BLG сегмент

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

Поле Данни Значение
BLG.3 Account ID Идентификатор на сметка
  BLG.3.1 Id Number Идентификатор на сметката, до 16 символа
  BLG.3.4 Assigning Authority Институция издател, да се ползва:
Hospital
  BLG.3.5 Identifier type Вид идентификатор, според таблица 0203, да се ползва:
XX - Organization identifier - Идентификатор в организация

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

Пример

BLG|||201601^^^Hospital^XX

MSA сегмент

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

Поле O/R Данни Забележка
MSA.1 R Acknowledgment Code Код на отговор, според таблица 0008, ползват се:
AA - Application Accept - Съобщението е прието без грешки
AE - Application Error - Грешка при приемане
AR - Application Reject - съобщението е отхвърлено
MSA.2 R Message Control ID Id на съобщението на което се отговаря (предадено в MSH.10)
MSA.3 B Text Message Текст на съобщението - визуализира се в журналите за сесия, следва да е максимално разбираем за потребители текст
MSA.6 B Error Condition Код на грешка при отхвърляне, виж по-долу

Статус на отговора

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

Код Значение Описание
0 Message accepted Съобщението е прието
100 Segment sequence error Грешка в последователността на сегментите
101 Required field missing Липсва изискуемо поле
102 Data type error Грешка във вида на данните
103 Table value not found Посочена стойност липсва в дефинирана таблица
200 Unsupported message type Вида на съобщението не се поддържа
201 Unsupported event code Вида на събитието не се поддържа
202 Unsupported processing id Неизвестно Id на съобщение
203 Unsupported version id Версията на протокола не се поддържа
204 Unknown key identifier Неизвестен ключов идентификатор
205 Duplicate key identifier Повторение в ключов идентификатор
206 Application record locked Записът е заключен
207 Application internal error Вътрешна грешка в приложението

Кодове от ЛИС iLab

Кодовете са максимално описателни, като много важни са стойностите 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, поръчващата страна трябва да направи нова поръчка, с вече различен номер и да реферира баркодовете на направената вече основна поръчка. Това е ключов момент в логиката на комуникация за да сработят допълнителните поръчки когато основната поръчка е вече заключена. Така или иначе, поръчващата страна винаги трябва да прави първо опит за актуализация на основната поръчка и ако записа е заключен – да прави нова допълнителна с референция към вече изпратените проби. Технически допустимо е изпращането на допълнителна поръчка и при все още незаключена основна, макар това да е логически необосновано и да затруднява вътрелабораторния процес.

segments.txt · Последна промяна: 2018/10/22 00:40 от admin