НП ППП
Немного об HL7 v2.x

12.09.2014

Немного об HL7 v2.x

Немного об HL7 v2.x

HL7 v2.x – это стандарт / протокол обмена сообщениями, исключающий необходимость разработки специфических программных интерфейсов для обмена медицинской информацией между информационными системами в здравоохранении. В отличие от CDA-документов, сообщения HL7 v2, хотя и могут быть прочитаны человеком, прежде всего, используются для унификации взаимодействия автоматизированных систем. CDA-документы (CDA - Архитектура клинического документа) предназначаются для чтения человеком, в том числе после определенных преобразований, например, с помощью XSLT.

Структура HL7-сообщения

Все HL7-сообщения имеют иерархическую структуру; генерирование сообщений происходит на основании возникающих триггер-событий. Стандарт HL7 определяет триггер-события, как "реальные события в здравоохранении, из-за которых возникает потребность в передаче данных между системами". Каждое триггер-событие является порождает одно или несколько соответствующих ему сообщений, передающих определенные виды информации. "Абстрактное" сообщение - есть набор всех возможных сегментов сообщения для передачи информации конкретного триггер-события, учитывающее правила повторения и включения сегментов (разных порядков). В следующей таблице показан пример абстрактного сообщения для триггер-события A04 - "Register Patient" (регистрация пациента).

Тип сообщения / 

сегменты

Абстрактное сообщение

ADT^A04^ADT_A01

Госпитализация, выписка и перевод пациента (ADT)

MSH

Заголовок сообщения

EVN

Тип события

PID

Идентификация пациента (демография: ID, имя, фамилия, пол, раса, код страны, номер телефона, адрес, семейное положение, номер страховки, место рождения, язык, гражданство)

[PD1]

Дополнительная демография (все, что не влезло в PID)

[{ROL}]

Роли

[{NK1}]

Ближайший родственник

PV1

Визит пациента (место, к которому привязан пациент (assigned patient location - палата больницы, например) тип госпитализации, лечащий врач, направляющий врач, номер визита, тип диет-стола и т.д.)

[PV2]

Визит пациента - все что в прошлый сегмент не влезло

[{ROL}]

Роль

[{DB1}]

Информация об инвалидности

[{OBX}]

Наблюдения / результаты: ID обследования, значение, единицы измерения, референтные значения, ID лаборанта / врача, зафиксировавшего наблюдение, метки отклонений от нормы

[{AL1}]

Информация об аллергических реакциях (тип аллергии, код аллергии, тяжесть аллергической реакции)

[{DG1}]

Информация о диагнозе (справочник для кодирования диагноза, код диагноза, описание диагноза, группа сходного диагноза, )

[DRG]

Группа сходного диагноза

[{

PR1

Процедуры (справочник кодирования процедур, код процедуры, описание процедуры, тип/дата процедуры, протокол процедуры, ФИО анестезиолога, код хирурга, наличие согласия на процедуру)

[{ROL}]

Роль

}]

[{GT1}]

Гарантор – физическое или юридическое лицо, ответственное за оплату лечения пациента

[{

IN1

Страховая информация

[IN2]

Доп. инф. о страховании

[{IN3}]

Доп. инф о страховании

[{ROL}]

Роль

}]

[ACC]

Информация о происшествии (аварии и т.д.)

[UB1]

Универсальная платежная информация

[UB2]

Универсальная платежная информация

[PDA]

Смерть и аутопсия пациента

Квадратные скобки "[" "]", говорят, что сегмент или группа сегментов является опциональными, в то время как фигурные скобки "{", "}" указывают на то, сегмент или группа сегментов могут повторяться. Сегмент представляет собой набор полей, причем каждое поле или его компонент (поля) соответствует конкретному типу данных. Поля могут иметь простую или сложную структуру. Они состоят из компонентов, разрешенных определенным типом данных. В целях поддержки более сложных типов данных, некоторые компоненты могут состоять из субкомпонентов (компонентов второго уровня).

Замечание

При кодировании HL7-сообщений используются разделители "|", "^" и "&", однако, при необходимости они могут быть переопределены (в поле MSH.2), хотя, обычно в этом нет необходимости.

Первые спецификации от HL7 не давали определения абстрактным сообщениям. Абстрактное сообщение представляет собой набор всех возможных сегментов, связанных с конкретным триггер-событием. Кроме этого, HL7-сообщения содержат коллекции сегментов или групп сегментов, которые могут повторяться. Первые версии стандарта HL7 также не давали определения группам сегментов. Начиная с версии 2.3.1, и по настоящую версию, используются группы сегментов (из-за поддержки XML).

Во второй версии стандарта обмена сообщениями HL7 для обеспечения совместимости между версиями стандарта не допускается введение новых структур, конфликтующих с полями и сегментами предыдущих версий (обратная совместимость). Поэтому, депрекация более не используемых триггер-событий и их замена на новые невозможна. Это означает недопустимость замены сегмента сообщения на сегмент с иным смыслом (это делается с использованием Z-сегментов), переназначение обязательного сегмента как опционального, переназначение повторяющегося сегмента как "неповторяющегося".

Типы HL7-сообщений

Выделим выделим некоторые виды спецификаций HL7-сообщений (Предствленные 4 домена можно условно назвать основными для стандарта HL7 v2.3.1. В HL7 v.2.7 таких доменов 14):

- Административный домен (ADT)

- Заказы (ORM)

- Результаты (ORU)

- Оплата / финансы (DFT)

ADT-сообщения (госпитализация, выписка, перевод)

В ADT-сообщениях передается демографическая информация о пациенте, а также информация о триггер-событиях. Некоторые из наиболее важных сегментов в ADT-сообщениях - PID (идентификация пациентов), PV1 (визит пациента), а иногда и IN1 (страхование). ADT-сообщения чрезвычайно распространены и являются одними из самых широко используемых.

Существует 51 тип ADT-сообщений, соответствующих различным ситуациям в здравоохранении (т.е. триггер-событиям). Некоторые из наиболее часто используемых:

ADT-A01 - госпитализация пациента

ADT-A02 - перевод пациента (в другое отделение, в другую больницу)

ADT-A03 - выписка пациента

ADT-A04 - регистрация пациента (Комментарий от автора http://hl7blog.livejournal.com: "Вот это интересный пример, потому как нет ADT_A04 сообщения. Есть ADT_A01 вызванное триггер-событием A04. Этот пример как раз представлен в таблице выше.")

ADT-A05 - подготовка к госпитализации / проведению консультации пациента (сбор информации для процедуры / лечения в стационаре / консультации)

ADT-A08 - обновление текущей информации о пациенте

ADT-A11 - отмена госпитализации пациента

ADT-A12 - отмена перевода пациента

ADT-A13 - отмена выписки пациента

HL7 ORU - Сообщение о результате наблюдения (Observation Result)

Прежде всего, давайте определимся с тем, что же такое «наблюдение» (observation) в контексте стандартов HL7. Обратимся к словарю медицинских терминов:

Наблюдение (observation) - (1) "Оценка состояния пациента или анализ полученной информации об одном или нескольких пациентах ответственным за осмотр лицом или лицами, в соответствии с процедурой установленной протоколом" и (An assessment of a patient’s condition, or analysis of data collected on one or more patients by the investigator/staff as required by protocol.) "Некоторая совокупность данных, полученных в ходе осмотра, обследования или анализа" (A discrete datum (piece of information) collected during a study). Определения взяты из Segen's Medical Dictionary. © 2012 Farlex, Inc., Определение слова «study» взято из The American Heritage® Medical Dictionary Copyright © 2007, 2004

HL7-сообщение ORU-R01 используется для передачи информации о наблюдениях из информационных систем / диагностического оборудования (например, ЛИС, ЭКГ-система) в систему разместившую заказ (МИС, АРМ врача). Оно также может использоваться для передачи данных о результате наблюдения в архив медицинских записей или в другую систему, первоначально не участвующую в процессе формирования заказа и получения результата наблюдения. ORU-сообщение также иногда используется для регистрации или привязки клинических исследований (речь идет об испытании лек.средств) или для работы с отчетами о лекарствах и мед.изделиях.

Виды наблюдений, передаваемых в ORU-R01 сообщении:

· Результаты лабораторных клинических анализов;

· Отчеты о результатах визуальной диагностики;

· ЭКГ, результаты исследования функции легких;

· Состояние пациента или другие данные (показатели жизненно-важных функций, симптомы, аллергические реакции, замечания и т.д.)

ORU-сообщение - это структурированный отчет, в котором каждое наблюдение представлено отдельным сегментом, состоящей из полей. С помощью ORU-сообщений возможно передавать изображения в поле с типом данных ED (encapsulated data); с помощью различных типов данных ORU-сообщение может передавать числовые, текстовые или кодированные данные. (Комментарий от http://hl7blog.livejournal.com: "В ORU-сообщениях, в сегменте OBX есть поле OBX.5 (ObservationValue) с неопределённым типом данных. Если используется ED, то можно передавать base64-encoded изображения и другие бинарные данные.") В ORU-сообщении, сегменты OBR (запрос на наблюдение) и OBX (непосредственно наблюдение) наиболее значимы в силу выполняемых ими функций: 

Сегмент OBR используется во всех ORU-сообщениях в качестве заголовка отчета (report header) и содержит важную информацию о выполняемом заказе (т.е. номере заказа, дате / времени запроса, дате / времени выполнения наблюдения, исполнителю заказа и т.д.). Этот сегмент входит в группу повторно используемых сегментов, один OBR-сегмент используется для записи информации о результате одного конкретного наблюдения.

Сегмент OBX передает фактические результаты клинического наблюдения в форме одного фактического наблюдения или фрагмента наблюдения. OBX-сегменты также могут многократно встречаться в сообщении; за ними могут следовать сегменты NTE с дополнительными записями и комментариями о наблюдениях. 

Структура ORU_R01-сообщения

Сегмент / группа

Имя

MSH

Заголовок сообщения

ResultsGroupПовторяющаяся группа сегментов «Results Group», включает следующие групп сегментов:

PatientGroupГруппа сегментов о пациента

PID

(PID) Идентификационные данные о пациенте

PID1

(Patient demographics) Демографическая информация о пациенте

NTE

Замечания и комментарии

PatientVisitGroupГруппа сегментов, содержащая информацию о визите пациента

PV1

Визит пациента

PV2

Дополнительная информация о визите пациента

OrderGroupПовторяющаяся группа о заказах

ORC

Общая информация о заказе (pharmacy, diet) + инф. о заказчике

OBR

Непосредственный запрос наблюдения

NTE-1

Замечания и комментарии

ObservationGroup Повторяющаяся группа о наблюдениях, часть OrderGroup

OBX

Наблюдение

NTE-2

Замечания и комментарии

OrderGroup continued Продолжение Order Group

CTI

Идентификатор проводимого обследования

Дополнительные сегменты:

DSC

Continuation pointer segment -  Продолжение взаимодействия систем …

Пример сообщения ORU^R01:

MSH|^~\&|LCS|LCA|LIS|TEST9999|199807311532||ORU^R01|3629|P|2.2

PID|2|2161348462|20809880170|1614614|20809880170^TESTPAT||19760924|M|||^^^^ 00000-0000|||||||86427531^^^03|SSN# HERE

ORC|NW|8642753100012^LIS|20809880170^LCS||||||19980727000000|||HAVILAND

OBR|1|8642753100012^LIS|20809880170^LCS|008342^UPPER RESPIRATORY CULTURE^L|||19980727175800||||||SS#634748641 CH14885 SRC:THROA SRC:PENI|19980727000000||||||20809880170||19980730041800||BN|F

OBX|1|ST|008342^UPPER RESPIRATORY CULTURE^L||FINALREPORT|||||N|F||| 19980729160500|BN

ORC|NW|8642753100012^LIS|20809880170^LCS||||||19980727000000|||HAVILAND

OBR|2|8642753100012^LIS|20809880170^LCS|997602^.^L|||19980727175800||||G||| 19980727000000||||||20809880170||19980730041800|||F|997602|||008342

OBX|2|CE|997231^RESULT 1^L||M415|||||N|F|||19980729160500|BN

NTE|1|L|MORAXELLA (BRANHAMELLA) CATARRHALIS

NTE|2|L| HEAVY GROWTH

NTE|3|L| BETA LACTAMASE POSITIVE

OBX|3|CE|997232^RESULT 2^L||MR105|||||N|F|||19980729160500|BN

NTE|1|L|ROUTINE RESPIRATORY FLORA

Заключение

Стандарт HL7 v2.x получил широкое распространение в существующих медицинских информационных системах / ЭМК-системах по всему мира из-за простоты структуры сообщений и гибкости правил валидации. Можно предположить, что это один из наиболее распространенных стандартов электронного взаимодействия в здравоохранении. HL7 v2.x может использоваться в качестве механизма интеграции данных разрозненных вычислительных систем одного медицинского учреждения или даже региональной системы здравоохранения, обеспечивая одинаковые условия работы при централизованном или распределенном хранении медицинских данных. 




Вернуться в список событий

Работает на 1С-Битрикс: Управление сайтом ASP.NET  |   Администрирование