ГОСТ Р ИСО/HL7 27931-2015. Национальный стандарт Российской Федерации. Информатизация здоровья. Health Level Seven Version 2.5. Прикладной протокол электронного обмена данными в организациях здравоохранения

(утв. и введен в действие Приказом Росстандарта от 28.12.2015 N 2223-ст)

Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 28 декабря 2015 г. N 2223-ст

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ИНФОРМАТИЗАЦИЯ ЗДОРОВЬЯ

HEALTH LEVEL SEVEN VERSION 2.5. ПРИКЛАДНОЙ ПРОТОКОЛ ЭЛЕКТРОННОГО ОБМЕНА ДАННЫМИ В ОРГАНИЗАЦИЯХ ЗДРАВООХРАНЕНИЯ

Data Exchange Standards. Health Level Seven Version 2.5. An application protocol for electronic data exchange in healthcare environments

(ISO/HL7 27931:2009, Data Exchange Standards - Health Level Seven Version 2.5 - An application protocol for electronic data exchange in healthcare environments, IDT)

ГОСТ Р ИСО/HL7 27931-2015

Группа П85

ОКС 35.240.80

ОКСТУ 4002

Дата введения 1 ноября 2016 года

Предисловие

1 ПОДГОТОВЛЕН Федеральным государственным бюджетным учреждением "Центральный научно-исследовательский институт организации и информатизации здравоохранения" Министерства здравоохранения Российской Федерации (ЦНИИОИЗ Минздрава) и Федеральным бюджетным учреждением "Консультационно-внедренческая фирма в области международной стандартизации и сертификации "Фирма "ИНТЕРСТАНДАРТ" на основе собственного перевода на русский язык англоязычной версии международного стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 468 "Информатизация здоровья" при ЦНИИОИЗ Минздрава - постоянным представителем ISO TC 215

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 28 декабря 2015 г. N 2223-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/HL7 27931:2009 "Информатизация здоровья. Health Level Seven Version 2.5. Прикладной протокол электронного обмена данными в организациях здравоохранения" (ISO/HL7 27931:2009 "Data Exchange Standards - Health Level Seven Version 2.5 - An application protocol for electronic data exchange in healthcare environments").

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (подраздел 6)

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Область применения

Стандарт ИСО/HL7 27931:2009 определяет прикладной протокол электронного обмена данными в организациях здравоохранения.

Сам по себе стандарт HL7 не обеспечивает полного решения задачи интеграции информационных систем на уровне подхода "plug-and-play" ("вставил-заработало"). В организации современных систем оказания медицинской помощи можно выделить несколько барьеров, препятствующих доводке стандарта HL7 до полного решения на уровне "вставил-заработало" (plug-and-play). Два из них таковы: а) отсутствие согласованности процессов при различных условиях оказания медицинской помощи; б) вызванная этим потребность согласования требований между пользователями и поставщиками.

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

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

Полностью интегрированная информационная система учреждения здравоохранения должна опираться на интегрированную базу данных или по крайней мере на виртуально интегрированную базу данных. Однако на практике информационные системы все еще должны устанавливаться и работать в окружении, где либо вовсе нет других систем, либо не все необходимые системы доступны. Поэтому все современные информационные системы конструируются таким образом, что реализованные в них процессы могут полностью опираться на собственные, местные копии необходимых данных.

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

В будущих версиях стандарта HL7 этот исторически сложившийся подход может измениться. Недавние усилия по разработке метамоделей данных, предпринятые Рабочей группой HL7 и другими разработчиками стандартов, аккредитованными Институтом ANSI, обеспечили создание базиса, который может быть использован разработчиками стандартов и приложений для определения и использования данных и их организации. Широкое распространение этих понятий может позволить Рабочей группе HL7 и другим организациям-разработчикам стандартов давать более строгие рекомендации по взаимодействию, реализация которых оставляет меньше свободы выбора.

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

Нормативные ссылки

В настоящем стандарте используются следующие сокращения:

1 Введение

Технический редактор:

John Quinn, CAP Gemini Ernst & Young U.S. LLP.

1.1 Назначение

Настоящий документ содержит описание версии 2.5 стандарта Health Level Seven (HL7), предназначенного для электронного обмена данными в различных учреждениях здравоохранения, в первую очередь в тех, где пациенту оказывают интенсивную медицинскую помощь (например, в больницах). Он обобщает работу комитета организаторов здравоохранения (пользователей), производителей и консультантов, образованного в марте 1987 года по ходу конференции, организованной доктором Сэмом Шультцем (Sam Schultz) в Госпитале Пенсильванского университета (Hospital of the University of Pennsylvania). Ее участников, представлявших как пользователей, так и производителей информационных технологий, объединила общая цель - упростить реализацию взаимодействия компьютерных приложений, созданных различными, нередко конкурирующими производителями. Этот комитет, который впоследствии получил название HL7 Working Group (Рабочая группа HL7), поставил перед собой задачу стандартизовать форматы и протоколы обмена определенными ключевыми наборами данных между прикладными компьютерными системами здравоохранения. Его совещания проходили примерно три раза в год в местах, разбросанных по всем Соединенным Штатам Америки. Санкционированные комитетом HL7 национальные группы существуют также за пределами США во многих других странах, включая Австралию, Канаду, Китай, Финляндию, Германию, Индию, Японию, Южную Корею, Новую Зеландию, Южную Африку, Швейцарию, Тайвань, Нидерланды и Великобританию.

Этот документ предоставляется всем заинтересованным сторонам. Он представляет собой регулярно обновляемый отчет, публикуемый, чтобы привлечь к его использованию как можно более широкий круг участников. От них принимаются комментарии по всем аспектам стандарта.

Усилия Рабочей группы HL7 направлены на создание баллотируемого стандарта, открытого для всех, кто разрабатывает системы обработки данных для здравоохранения. Поскольку стандарт применялся на практике, накопленный опыт отражен в его текущей версии.

С момента публикации версии стандарта 2.2 проводились две параллельные работы. Во-первых, была разработана версия 2.3, опубликованная в декабре 1994 годи и являющаяся эволюцией версии 2.2. Она аккумулирует усилия двух лет и тысяч часов добровольного труда активных членов Рабочей группы HL7 с момента публикации версии 2.2. Ее основная цель - обеспечить совместимость с версией 2.2, устранить ошибки, обнаруженные после публикации версии 2.2, и расширить версию 2.2, сохраняя ее формат и контекст.

Рабочая группа HL7 функционирует в соответствии с формальным регламентом, используя процедуры голосования. Последние были разработаны на основе процедур голосования, принятых в других организациях по стандартизации передачи информации в здравоохранении (например, ASTM). Они рассчитаны на удовлетворение требованиям Американского национального института стандартов (ANSI). Рабочая группа HL7 является участником правления комитета HISB (Health Information Standard Board), работающего под эгидой Института ANSI. В июне 1994 года Рабочая группа HL7 получила аккредитацию в ANSI. Версия 2.2 была официально аккредитована в ANSI в 1996 году, а версия 2.3 стала аккредитованным стандартом ANSI в мае 1997 года. Версия 2.4 была одобрена институтом ANSI в октябре 2000 года.

Как организация, Рабочая группа HL7 значительно выросла за последние годы. В настоящее время в нее входят около 2000 членов различных категорий. Ее совещания проводятся трижды в год и собирают 400 - 500 членов и других лиц.

1.2 Общие сведения

Термин "Уровень 7" (Level 7) ведет свое происхождение от верхнего уровня Модели взаимодействия открытых систем OSI (Open System Interconnection), принятой Международной организацией по стандартизации ISO (International Standardization Organization). Но это вовсе не означает, что стандарт HL7 полностью удовлетворяет элементам седьмого уровня модели OSI. Абстрактные спецификации сообщений стандарта HL7 не включают в себя одобренные организацией ИСО спецификации нижележащих шести уровней модели OSI. Однако при этом стандарт HL7 удовлетворяет концептуальному определению взаимодействия приложений, принятому для седьмого уровня этой модели.

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

Рабочая группа HL7 Working Group состоит из добровольцев, работающих над стандартом за свой счет или при поддержке своих работодателей. Членство в Рабочей группе HL7 было и остается открытым для любого лица, желающего внести свой вклад в разработку и уточнение Стандарта взаимодействия на седьмом уровне, предназначенного для внедрения сетевых технологий в здравоохранении.

В настоящее время стандарт HL7 определяет взаимодействие различных систем, которые посылают или получают данные о регистрации/госпитализации пациента, его выписке и переводе (ADT - admission, discharge, transfer), запросы на предоставление этих данных, требования назначений пациентам и сведения о выделенных ресурсах для этих назначений, заказы и результаты лабораторных анализов и диагностических исследований, счета на оплату лечения, изменения в файлах со справочно-нормативной информацией, сведения, содержащиеся в медицинских картах, сведения о планировании лечебно-диагностических мероприятий, направлениях на консультации, уходе за пациентом. В нем не делается попытки описать архитектуру данных внутри приложения; он равным образом рассчитан на применение централизованной медицинской информационной системы и на более распределенную среду, в которой данные рассредоточены по информационным системам отдельных подразделений. С его помощью можно обеспечить взаимодействие различных отделенных друг от друга приложений, функционирующих в гетерогенной системной среде и использующих различные архитектуры данных.

Если принять во внимание многообразие приложений информационных систем в здравоохранении, а также вариабельность той среды, в которой оказывается медицинская помощь, то становится очевидным, что существует гораздо большее число видов взаимодействия, реализация которых могла бы выиграть от стандартизации. Виды взаимодействия, включенные в стандарт, были наиболее актуальны для членов Рабочей группы HL7, участвовавших в процессе разработки стандарта. В намерении Рабочей группы HL7 входила подготовка полного стандарта для этих видов взаимодействия, используя фундаментальную основу, на базе которой может осуществляться поддержка других видов взаимодействия. Этот стандарт был пущен в дело и в настоящее время используется как база для расширения существующих определений взаимодействия, а также для добавления других определений.

Один из ожидаемых результатов публикации состоит в привлечении к Рабочей группе HL7 новых членов, выражающих свои интересы в новых, еще недостаточно описанных областях. Примерами таких областей могут служить:

a) обеспечение принятия решений;

b) взаимодействие с дополнительными специфичными вспомогательными подразделениями;

c) информационные потребности систем оказания медицинской помощи, находящихся вне рамок интенсивного лечения.

Несмотря на вышеизложенное, члены Рабочей группы HL7 считают, что обсуждаемых в настоящем стандарте видов взаимодействия достаточно для того, чтобы их стандартизация принесла существенные выгоды здравоохранению.

Настоящий документ имеет следующую структуру. Данная глава содержит обоснование разработки стандарта, цели разработки стандарта, а также вопросы, которые Рабочая группа HL7 сочла относящимися к области применения стандарта и подходу к его разработке. Содержание этой главы должно помочь читателям понять основу решений, принятых при разработке стандарта. Последующие главы соответственно содержат:

a) общую структуру всех видов взаимодействия, включая обобщенный интерфейс запросов;

b) описание обмена сообщениями о регистрации, госпитализации, переводе и выписке пациентов;

c) описание обмена данными при вводе направлений на лабораторные анализы и диагностические исследования;

d) описание передачи счетов и другой информации, связанной с оплатой лечения;

e) описание передачи клинических данных, например результатов лабораторных анализов, которые посылаются как совокупность идентифицируемых элементов данных (а не как текст, выдаваемый на экран);

f) обобщенный интерфейс для синхронизации файлов, содержащих справочно-нормативную информацию (master files);

g) управление медицинской информацией;

h) ведение расписаний приема пациентов и выделения ресурсов;

i) направления пациентов из одного учреждения здравоохранения в другое;

j) обмен сообщениями, возникающими при лечении пациентов, при котором ведется проблемно-ориентированная история болезни и обеспечивается "клиническая маршрутизация" (clinical pathways) пациентов;

k) автоматизацию клинических лабораторий;

l) управление прикладными программами;

m) управление персоналом.

1.3 Потребности в стандарте

Организация медицинской помощи и процесс ее оказания связаны с интенсивной обработкой информации. Общепризнано, что автоматизация функций управления информацией существенно влияет на эффективность функционирования системы здравоохранения. Многие полагают, что те учреждения здравоохранения, которые не имеют автоматизированных информационных систем, не смогут успешно конкурировать на рынке медицинских услуг.

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

В настоящее время стало не столь уж большой редкостью встретить в рядовой больнице действующую вычислительную систему, обеспечивающую учет движения коечного фонда и пациентов, автоматизацию клинических лабораторий, отделений лучевой диагностики, бухгалтерский учет и многое другое. Нередко эти приложения разработаны различными производителями или несколькими самостоятельными группами разработчиков так, что каждая подсистема имеет свой чрезвычайно специфичный формат хранения и представления информации. По мере того, как больницы продолжают расширять операции по управлению информацией, возникает настоятельная потребность в параллельном использовании ряда критичных данных. Современные сложные системы, которые способны помочь в выполнении если не всех, то большинства операций по управлению информацией в здравоохранении, разрабатываются небольшим числом производителей. Архитектура таких систем может быть как централизованной, так и распределенной. За исключением случая, когда разработка такой системы уже завершена, ее разработчики непременно будут испытывать потребность в стандарте обмена внешними данными наподобие HL7.

Однако учреждение здравоохранения имеет много стимулов к приобретению или разработке отдельных приложений для своих подразделений на модульной основе. Один из возможных стимулов - специфичные нужды подразделений, которые не могут быть хорошо решены или даже вовсе не могут быть решены производителями сложных систем масштаба учреждения. Для таких подразделений могут требоваться информационные системы, "лучшие в своем роде" (best-of-breed). Другой стимул - потребность в постепенной эволюции всей больничной информационной системы за счет ряда последовательных шагов на уровне подразделений вместо одного революционного скачка. Эти стимулы приводят к решению, когда сложная центральная информационная система дополняется рядом систем отдельных подразделений либо вместо центральной системы создается конгломерат из отдельных достаточно автономных информационных систем.

Сетевая технология стала доступным и экономически эффективным подходом к интеграции различных по функциям и аппаратным средствам прикладных компьютерных систем здравоохранения. Однако эти системы разрабатываются с учетом структуры рынка, а не требований логической целостности информации, вследствие чего они могут оказаться рассчитанными на частные случаи либо получиться достаточно причудливыми. В худшем случае они могут не иметь общей архитектуры данных; хранящиеся ими данные могут образовывать чрезвычайно распределенную и существенно не нормализованную базу данных. Для включения этих приложений в сетевую среду могут потребоваться значительные усилия по их доработке с учетом местной специфики, что может потребовать от потребителя и производителя значительных затрат и при этом не даст производителю возможности заняться решением других задач, например, разработкой новых приложений. Затраты на доработку приложений, учитывающих местную специфику, могут быть значительно снижены, если пользователи и производители информационных систем примут общие стандарты сетевого взаимодействия в здравоохранении.

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

Таким образом, и для пользователей, и для производителей очень важно не оказаться лицом к лицу с проблемами поддержки несовместимых структур коммуникации и выполнения транзакций. Во избежание такой ситуации необходимо создать базу, на основе которой можно минимизировать несовместимость и максимизировать однотипность обмена информацией между системами. Стандарт HL7 как раз и предлагается использовать в качестве "сверхструктуры", обеспечивающей единство спецификаций и методологии при разработке сетевых систем. Действительно, разработка и внедрение стандартных способов взаимодействия компьютерных приложений в учреждениях здравоохранения является как практичной, так и экономически выгодной.

1.4 Цели разработки стандарта

Спецификации настоящего стандарта были разработаны в соответствии с заранее поставленными целями. Дальнейшие расширения стандарта также должны удовлетворять этим целям.

Стандарт HL7 предназначен для облегчения информационного взаимодействия в учреждениях здравоохранения. Его основная цель состоит в такой стандартизации обмена данными между медицинскими компьютерными приложениями, при которой исключается или значительно снижается необходимость в разработке и реализации специфичных программных интерфейсов, требующихся при отсутствии стандарта. Это основная цель может быть подразделена на следующие более частные цели:

a) стандарт должен поддерживать обмен информацией между системами, функционирующими на самом широком спектре технических средств. Его реализация должна оставаться достаточно практичной для широкого круга языков программирования и операционных систем. Он должен также поддерживать информационное взаимодействие в условиях применения разнообразных средств телекоммуникации, начиная от тех, что полностью совместимы с 7-уровневым стеком протоколов модели OSI, до примитивных соединений "точка-точка" по протоколу RS-232C и передачи пакетов данных на внешних носителях, например гибком диске или магнитной ленте;

b) немедленная передача простых транзакций должна поддерживаться наряду с передачей файлов, состоящих из нескольких транзакций;

c) должна быть достигнута наибольшая возможная степень стандартизации, совместимая с местными вариациями формата отдельных элементов данных и их использования. Стандарт должен поддерживать возможность необходимых местных вариаций. К ним должны относиться по меньшей мере местные таблицы значений, определения кодов и местные сегменты сообщений (а именно, Z-сегменты стандарта HL7);

d) стандарт должен обеспечивать постепенное расширение по мере выявления новых требований. Сюда относится поддержка процесса добавления расширений и перехода к новым версиям в существующих операционных средах;

e) стандарт должен быть построен на основе опыта разработки и внедрения существующих производственных протоколов и принятых в промышленности стандартных протоколов. Однако, он не должен предоставлять преимущество частным интересам отдельных фирм в ущерб интересам других пользователей стандарта HL7. В то же время стандарт HL7 должен обеспечить индивидуальному производителю возможность выйти на рынок со своими собственными продуктами;

f) хотя в настоящем виде стандарт ориентирован на больничные информационные системы, в долгосрочном плане целями стандартизации должны быть определение форматов и протоколов для прикладных компьютерных систем всего здравоохранения;

g) сама природа разносторонности видов деятельности в системе здравоохранения исключает возможность разработки универсальной модели как процесса, так и данных, которые могли бы обеспечить описание целевой среды в стандарте HL7. Кроме того, стандарт HL7 не использует априорных предположений об архитектуре информационной системы в здравоохранении и не пытается решить проблему архитектурных различий этих систем. Уже в силу этих причин стандарт HL7 не может быть стандартом взаимодействия типа "поставил-заработало" ("plug and play"). Упомянутые выше различия в местах применения стандарта HL7 могут потребовать выработки дополнительных соглашений между соответствующими сторонами;

h) Рабочая группа HL7 была заинтересована в скорейшей разработке стандарта. Выполнив эту задачу, Рабочая группа HL7 разработала также инфраструктуру, обеспечивающую принятие решений на основании консенсуса, и зарегистрировалась в Американском национальном институте стандартов ANSI как Аккредитованная организация по стандартизации (ASO - Accredited Standards Organization);

i) приоритетным для Рабочей группы HL7 стало взаимодействие с другими организациями, занимающимися стандартизацией в здравоохранении (например, ACR/NEMA DICOM, ASC X12, ASTM, IEEE/MEDIX, NCPDP и др.). Рабочая группа HL7 принимает участие в работе комитета HISPP (Health Information Systems Planning Panel) Института ANSI.

1.5 История разработки стандарта HL7

С марта 1987 года встречи участников Рабочей группы HL7 проводились примерно раз в 3 - 4 месяца для разработки и обсуждения спецификаций стандарта. Группа была разбита на комитеты, часть из которых имела функциональную направленность, а другая часть занималась общей структурой управления и различными административными аспектами деятельности Рабочей группы. Эти комитеты отвечали за авторство глав стандарта HL7 и за их доработку. Кроме того, время от времени внутри Рабочей группы HL7 формировались подгруппы по специальным интересам, которые разрабатывали идеи и поддерживали отдельные перспективы, не охваченные каким-либо из существующих комитетов. Если включение в стандарт новой главы по результатам работы подгруппы специальных интересов признавалось целесообразным, то подгруппа могла войти с предложением к председателю Технического комитета Рабочей группы HL7 и в Исполнительный комитет о ее преобразовании в функциональный Технический комитет.

За первые три встречи была сформирована версия 1.0 предварительного стандарта, охватывающая общую структуру взаимодействия приложений, транзакции госпитализации, выписки и перевода пациентов (ГВП), ввод заказов, а также запросы с дисплейным ответом. Хотя система учета оплаты лечения признавалась чрезвычайно важной, временные рамки не позволили включить ее в первый вариант стандарта. Этот вариант был представлен на пленарном заседании Рабочей группы HL7, проводившемся 8 октября 1987 года в Tyson's Corner (Вайоминг, США).

Версия 2.0 была разработана на I Пленуме в Tyson's Corner и представлена на II Пленуме, проводившемся в сентябре 1988 года в городе Tucson. После II Пленума начались редактирование и пересмотр версий 2.1, 2.2, 2.3, 2.3.1, 2.4 и 2.5. С тех пор Рабочая группа HL7 выросла почти до 400 человек, намного превзойдя начальный состав в 12 человек, и выполнила следующие действия:

a) уточнила и расширила спецификации в различных функциональных областях;

b) установила формальные отношения с рядом других организаций по стандартизации: с комитетом HISPP (Healthcare Information Standards Planning Panel) института ANSI для координации работы над стандартами в здравоохранении (в настоящее время этот комитет преобразован в Правление HISB (Healthcare Information Standards Board), с группой ASC X12N по внешним стандартам обмена электронными документами, с группой ASTM E31.11 по стандартам обмена клиническими данными, с группой ACR/NEMA DICOM по стандартам, связанным с обменом медицинскими изображениями и с другими аспектами информационных систем лучевой диагностики, а также с группой IEEE P1157 по обмену медицинскими данными ("MEDIX");

c) модифицировала общую структуру управления на основе поступивших предложений с тем, чтобы приспособить ее к широкому спектру коммуникационных сред и облегчить взаимодействие с другими группами по стандартизации;

d) добавила главу по взаимодействию с системами учета оплаты лечения;

e) добавила главу по результатам исследования, передаваемым вспомогательными подразделениями, а также по клиническим испытаниям, диетпитанию, лекарственным назначения, обработке сигналов. Эта глава была разработана при активном прямом участии членов комитета ASTM E31.11 таким образом, чтобы ее содержание согласовывалось со стандартом ASTM 1238-91;

f) добавила главу с описанием транзакций, необходимых для синхронизации справочно-нормативных файлов в связанных информационных системах;

g) добавила главу по взаимодействию приложений, обеспечивающих функции ведения медицинской карты, в том числе управление вводом данных, перемещением медицинских карт, анализом неполноты данных, а также управление информированными согласиями и раскрытием информации;

h) добавила главу по взаимодействию приложений, связанному с различными событиями планирования назначений услуг и выделения ресурсов;

i) добавила главу, определяющую комплекс сообщений обмена данными, связанными с направлением пациента из одного специализированного учреждения здравоохранения в другое;

j) создала компьютеризованный словарь всех элементов данных и других компонентов сообщений. В приложении A приводятся ссылки и другая информация, сгенерированная из этого электронного словаря данных;

k) обнаружила противоречия и ошибки в версиях 2.0, 2.1, 2.2 и 2.3 стандарта HL7. Они были исправлены и документированы в версии 2.3.1;

l) выполнила значительные добавления в главы, описывающие ввод заказов/передачу результатов и обеспечивающие включение ориентированных на элементы данных результатов, заказов в аптеку и регистрацию приема лекарств;

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

n) документировала различия между определениями абстрактного сообщения стандарта HL7, которые в чистом виде относятся к седьмому (прикладному) уровню, и правилами преобразования абстрактного сообщения в строку символов, представляющую реальное сообщение (правилами кодирования стандарта HL7). Эти правила кодирования фактически представляют собой потенциальную альтернативу для шестого уровня (уровня представления данных) в тех ситуациях, когда соответствующий стандарт типа Основных правил кодирования BER (Basic Encoding Rules), предложенных в стандарте ASN.1, отсутствует.

1.6 Общие положения

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

1.6.1 Правила кодирования стандарта HL7

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

Все данные представляются в виде изображаемых (печатаемых) символов в заданной кодировке. По умолчанию (если иное не указано в сегменте заголовка сообщения MSH) используется набор печатаемых символов ASCII (шестнадцатеричные коды от 20 до 7E включительно). Все специальные разделители и другие спецсимволы, за исключением разделителя сегментов (символа возврата каретки), представляются также печатаемыми символами набора ASCII.

1. Ни в стандарте ASTM 1238, ни в версии 2.3 стандарта HL7 нет ничего существенного, что ограничивало бы допустимый набор символов таблицей печатаемых ASCII-символов. В предшествующих версиях такие требования вводились, чтобы учесть ограничения многих существующих коммуникационных систем. Некоторые такие системы интерпретируют некоторые 8-битовые символы как управляющие символы, а не данные; некоторые просто удаляют восьмой бит из кода символа.

2. В странах Европейского союза (ЕС), к числу печатаемых относят символы, не входящие в указанный выше ограниченный набор (например, в него не входят символ немецкого языка oe или акцентированные символы французского языка). На стандартных персональных компьютерах эти печатаемые символы обычно имеют коды в диапазоне 128 - 256, но при этом присваивание символу кода нередко выполняется по-разному. Стандарт ИСО 8859 представляет собой набор из 256 символов, который включает в себя все необходимые буквы европейских алфавитов, и претендует на утверждение в качестве европейского стандарта. Как только в Европе стандартизуют спецификацию 8-битового набора символов, Рабочая группа HL7 включит ее в стандарт без особых затруднений.

3. Многобайтовые наборы символов:

• UNICODE: в случае, если средства коммуникации используют систему кодирования символов UNICODE и все символы представляются одним и тем же числом байтов, все разделители должны быть отдельными символами, кодируемыми заданным числом байтов, и требования стандарта применяются так же, как и в случае однобайтовой системы кодирования, только теперь коды символов могут занимать более одного байта;
• системы кодирования JIS X 0202 - ИСО 2022 предусматривают применение специальных управляющих последовательностей для переключения между различными наборами символов, а также одно- и многобайтовых представлений символов. Стандарт ИСО 2022 и его управляющие последовательности одобрены в Японии под именем JIS X 0202. Этот стандарт позволяет смешивать символы Kanji и ASCII-символы в одном и том же сообщении. Согласно стандарту JIS X 0202, как одно-, так и многобайтовые символы Kanji передаются, используя 7-битовые коды, чтобы исключить возможные проблемы передачи этих данных в существующих коммуникационных системах. Когда сообщения стандарта HL7 посылаются как текст в стандарте JIS X 0202, все разделители должны передаваться как однобайтовые ASCII-символы, а управляющие последовательности для переключения с ASCII на Kanji и обратно должны быть указаны между разделителями. В большинстве случаев коды Kanji будут использоваться для представления текстовых значений. В серии стандартов JIS X есть другие разделы, которые описывают поддержку системы кодирования Katakana (JIS X 0201/ISO IR 13), Romaji (JIS X 0201/ISO IR 14) и Kanji (JIS X 0208/ISO IR 87) и JIS X 0212/ISO IR 159). Они могут быть использованы в сообщениях стандарта HL7 точно так же, как и стандарт JIS X 0202;
• в случае, если в какой-то стране используются конфликтующие правила многобайтового представления символов, то стороны, участвующие в процессе взаимодействия, должны сами заботиться об использование однотипного свода правил передачи сообщений.

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

Правила кодирования устанавливают, что приложение-получатель должно игнорировать поля, которые присутствуют в сообщении, но не ожидаются им, и не рассматривать эту ситуацию как ошибочную. Дополнительную информацию о полях и правилах кодирования см. в разделах 2.5.3 "Поля" и 2.6 "Правила составления сообщений".

1.6.2 Местные вариации

Назначение стандарта HL7 состоит в стандартизации обмена данными, а не прикладных систем, занимающихся этим обменом. Это означает, что методы реализации стандарта в различных учреждениях могут существенно отличаться.

Возможность таких отличий учитывается в стандарте следующим образом:

a) обязательными полями в абстрактном сообщении являются только те, которые необходимы для обеспечения логики взаимодействия сообщений либо отражения их основного назначения. Многие другие поля указаны, но сделаны необязательными;

b) в спецификациях стандарта предусмотрена возможность добавления сообщений либо части сообщений местного характера, используемых лишь в конкретном учреждении. Соответствующие соглашения предназначены для предотвращения конфликта между местными вариациями и будущими версиями стандарта.

1.6.3 Эволюционные изменения стандарта

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

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

Аналогичным образом правила кодирования стандарта HL7 поддерживают изменения в длине полей. Границы полей задаются в сообщении не длиной поля, а с помощью специального разделителя. Изменение длины поля не вызовет изменений в процедуре, используемой для поиска следующих полей.

1.6.4 Применение стандарта к обмену файлами (пакетной обработке)

Хотя стандарт HL7 определен в терминах модели клиент-сервер (удаленного доступа), тем не менее он в равной мере приложим к обмену файлами. Одно или более сообщений могут быть обработаны в соответствии с правилами кодирования, сгруппированы в файл и переданы на внешних носителях информации с помощью протоколов FTAM, FTP, Kermit, или любого другого протокола передачи файлов. В разделе 2 дается описание общих механизмов стандарта HL7 для пакетной обработки сообщений.

1.6.5 Связь с другими протоколами

При разработке стандарта HL7 значительное внимание уделялось его связям с другими протоколами. При этом рассматривались три основных вопроса:

a) каковы связи между протоколом HL7 и протоколами "нижних" (сервисных) уровней? Для соблюдения строгого соответствия модели взаимодействия открытых систем OSI, стандарт HL7 не должен был бы включать в себя какие-либо функции этих протоколов. Это требование можно было бы ужесточить с тем, чтобы избежать репликацию в стандарте HL7 некоторых элементов седьмого уровня модели OSI, имеющих функциональные эквиваленты на сервисном уровне. Однако целью Рабочей группы HL7 была поддержка электронного обмена информацией в здравоохранении при использовании широкого спектра коммуникационных сред, включая многие из тех, которые значительно менее полны по сравнению с моделью OSI, какой она может стать в будущем;

b) каковы связи между протоколом стандарта HL7 и другими протоколами прикладного уровня? Для сопоставления представляют интерес такие протоколы, как ASC X12 для электронного обмена документами, стандарты ASTM 1238-88 для передачи результатов лабораторных анализов, стандарты ACR/NEMA DICOM для передачи медицинских изображений и стандартизации других аспектов информационных систем лучевой диагностики, а также стандарты IEEE P1157 для обмена медицинскими данными ("MEDIX");

c) каковы связи между стандартом HL7 и различными частными протоколами, используемыми в настоящее время в здравоохранении?

1.6.5.1 Протоколы нижних уровней

Правила кодирования <1> сообщений стандарта HL7 существенно отличаются от Основных правил кодирования BER (Basic Encoding Rules) стандарта ASN.1, описанных в документах CCITT X.409, X.209 и ИСО 8825, или тех правил, что приняты в протоколах LU6.2 либо RPC. Это вызвано следующими причинами:

<1> Так называемые "исходные правила кодирования" сообщений HL7, о которых идет речь в этом документе, предполагают использование системы разделителей для структурирования текстовых сообщений. Вместо них сейчас используется XML-кодирование, описанное в документе HL7 Version 2: XML Encoding Syntax, Release 2 (прим. перев.).

a) по определению, правила кодирования стандарта HL7 должны применяться в среде, в которой не предусмотрено программное обеспечение для кодирования данных. В отсутствие такого программного обеспечения прикладным программистам пришлось бы взвалить на себя тяжелую ношу разработки программ, предназначенных для обработки сообщений, закодированных в соответствии с указанными выше правилами;

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

Система обозначений, принятая для описания формата сообщений в стандарте HL7, не совпадает с Основными правилами кодирования BER (Basic Encoding Rules) Нотации абстрактного синтаксиса ASN.1 (Abstract Syntax Notation), определенными в стандартах ИСО.

В отличие от других коммуникационных сред высокого уровня, в данном стандарте нет даже упоминания о сущностях, не связанных с передачей сообщения от клиента к серверу и получения ответа, что вполне соответствует модели клиент-сервер.

В тех случаях, когда стандарт HL7 используется в сетевой среде, адресация сообщений является отдельным вопросом. Это равным образом относится как к сетям, построенным по стандарту ИСО, так и к нестандартным сетям. Хотя в стандарте HL7 не задается способ адресации, в нем предусмотрен ряд полей данных, значениями которых могут быть такие адреса. Такие поля, как MSH-5-приложение-получатель (Receiving Application), MSH-6-учреждение-получатель (Receiving Facility) и MSH-11-идентификатор обработки (Processing ID) присутствуют в заголовке всех сообщений стандарта HL7. Поле MSH-6-учреждение-получатель рассчитано на те операционные и сетевые среды, в которых несколько экземпляров одного и того же приложения могут исполняться в одной и той же компьютерной системе или в одной и той же сети для нужд различных учреждений или других структурных единиц. Поле MSH-11-идентификатор обработки используется в ситуации, когда различные версии одного и того же приложения могут исполняться на данном компьютере в различных целях. Рекомендованные значения этого поля указаны в таблице HL7 0103-идентификатор обработки.

В настоящее время Рабочая группа HL7 не стандартизует значения полей MSH-5-приложение-получатель и MSH-6-учреждение-получатель, поскольку в существующих системах используется слишком много вариаций этих значений, а в различных типах системных и сетевых сред (например, в разных странах) применяются различные системы кодирования символов. Однако по мере включения в стандарт HL7 систем кодирования этих значений настоятельно рекомендуется сразу же переходить к их использованию, поскольку движение к стандартизации этих значений является весьма существенным для обеспечения эффективных коммуникаций.

1.6.5.2 Другие прикладные протоколы

Рабочая группа HL7 уделила значительное внимание взаимосвязям протокола HL7 и других протоколов. В настоящее время предпринимаются значительные усилия по установлению соответствующих контактов, а именно:

a) протокол ACR/NEMA DICOM. Рабочая группа HL7 установила многообещающие связи с рабочей группой ACR/NEMA DICOM. Обе рабочие группы являются членами Правления HISB Института ANSI;

b) стандарты ASC X12 для обмена электронными документами. Имя ASC X12 присвоено семейству стандартов, предлагающих как общие, так и частные описания для обмена данными внутри значительного числа отраслей. Правила кодирования стандарта HL7 ведут свое происхождение от стандартов X12, хотя между ними и имеются некоторые различия. Это связано с необходимостью учитывать в стандарте HL7 он-лайновый обмен индивидуальными транзакциями по локальным сетям компьютеров. Данное обстоятельство и некоторые другие прикладные аспекты и вызывают отличия от стандартов X12. Комитет X12 недавно принял решение следовать правилам кодирования стандарта ЭДИФАКТ-ООН (UN/EDIFACT) для всех стандартов X12, выпущенных в 1995 году и последующих годах. В настоящее время бурно активизировалось использование транзакций стандарта X12N, облегчающих обмен счетами на оплату лечения и информацией о денежных переводах, а также координацию страховых выплат, регистрации клиентов и верификации. Рабочая группа HL7 приняла к сведению, что все новые деловые транзакции между учреждениями, затрагивающие обмен счетами, выплаты и другую финансовую информацию относятся к сфере деятельности страхового подкомитета ASC X12N. В феврале 1994 года Рабочая группа HL7 и Комитет X12 подписали соглашение об усилении координации работ и определении технических вопросов, которые должны быть гармонизированы. Обе группы договорились перейти на соответствующий уровень согласования потенциально пересекающихся работ, привлекая пользователей и участников процесса стандартизации и учитывая требования ожидаемой реформы здравоохранения;

c) стандарт ASTM 1238.94 для передачи результатов лабораторных анализов (Laboratory Data Reporting). Активное взаимодействие между Комитетом ASTM и Рабочей группой HL7 привело к небольшим изменениям в спецификации ASTM, улучшающим совместимость, к изменениям в спецификациях управления в стандарте HL7, также направленным на улучшение совместимости, а также к разработке целой главы стандарта "Передача результатов исследований", которая была совместно разработана несколькими комитетами на основе стандартов ASTM. Это взаимодействие теперь доведено до состояния, при котором каждая из двух указанных выше групп по стандартизации имеет разрешение свободно использовать в своих публикациях не только выдержки, но и "полное" содержание работ по стандартизации, выполняемых другой группой. Некоторые различия между этими стандартами в основном связаны с терминологией, выбранной для описания фактического содержания сообщений. Например, в стандартах ASTM термин "разделитель подполя" (sub-field delimiter) обычно используется для разделения повторов однородных значений. В стандарте HL7 это понятие называется "разделителем повторов" (repetition separator). Как Рабочая группа HL7, так и Комитет ASTM являются членами Правления HISB Института ANSI;

d) стандарт IEEE P1157 ("MEDIX"). Комитет MEDIX определяет рамки протокола прикладного уровня аналогично стандарту HL7, но при этом строго опирается на стек протоколов ИСО, включая элемент сервиса удаленных операций ROSE (Remote Operation Service Element). В отличие от этого стандарт HL7 не зависит от ROSE и не использует нотацию синтаксиса ASN.1 правил кодирования BER. Несмотря на различие подходов, Рабочая группа HL7 регулярно взаимодействует с Комитетом MEDIX. Она приняла для стандарта HL7 формат, который относительно независим от выбранных правил кодирования и легко позволяет выполнить преобразование в нотацию ASN.1. Определенные таким образом транзакции должны быть непосредственно переносимы на язык определений стандарта MEDIX, а сообщения, передаваемые в рамках транзакций и закодированные по правилам стандарта HL7, должны быть транслируемыми в кодировку на основе правил BER. Это должно облегчить создание шлюзов между стандартом HL7 и его будущим окружением.

Кроме того, Рабочая группа HL7 и Комитет MEDIX договорились о направлении конвергенции стандартов, которое должно осуществляться на уровне определения абстрактного сообщения стандарта HL7. Далее, Комитет MEDIX согласился использовать определения абстрактного сообщения версии 2.1 стандарта HL7 как отправную точку для определений сообщений в стандарте MEDIX.

Рабочая группа HL7, организации IEEE и X12 зарегистрированы Институтом ANSI как аккредитованные разработчики стандартов.

1.7 Область применения

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

Многие из этих предметных областей уже рассматриваются Рабочей группой HL7 и соответствующие разделы могут появиться в следующих версиях данного стандарта. Некоторые из них никогда не войдут в стандарт HL7, поскольку ими уже занимаются другие организации-разработчики стандартов. Какие-то предметные области могут быть не охваченными стандартом HL7 из-за отсутствия интереса к ним либо из-за недостатка энергии у членов Рабочей группы HL7.

В любом случае аналитик должен иметь эти границы в виду и либо выбирать иные пути решения соответствующих задач, либо игнорировать их, если они не имеют особого значения. В этом разделе перечислены те задачи, решение которых лучше всего оставить на усмотрение разработчиков приложений. Однако при этом можно представить себе архитектуру, в которой эти решения укладываются в рамки коммуникационного стандарта. Эти области потенциальной стандартизации описаны здесь, чтобы читатель имел как можно более полное представление о данном предмете.

1.7.1 Полное решение

Сам по себе стандарт HL7 не обеспечивает полного решения задачи интеграции информационных систем на уровне подхода "plug-and-play" ("вставил-заработало"). В организации современных систем оказания медицинской помощи можно выделить несколько барьеров, препятствующих доводке стандарта HL7 до полного решения на уровне "вставил-заработало" (plug-and-play). Два из них таковы: а) отсутствие согласованности процессов при различных условиях оказания медицинской помощи; б) вызванная этим потребность согласования требований между пользователями и поставщиками.

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

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

Полностью интегрированная информационная система учреждения здравоохранения должна опираться на интегрированную базу данных или по крайней мере на виртуально интегрированную базу данных. Однако на практике информационные системы все еще должны устанавливаться и работать в окружении, где либо вовсе нет других систем, либо не все необходимые системы доступны. Поэтому все современные информационные системы конструируются таким образом, что реализованные в них процессы могут полностью опираться на собственные, местные копии необходимых данных.

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

В будущих версиях стандарта HL7 этот исторически сложившийся подход может измениться. Недавние усилия по разработке метамоделей данных, предпринятые Рабочей группой HL7 и другими разработчиками стандартов, аккредитованными Институтом ANSI, обеспечили создание базиса, который может быть использован разработчиками стандартов и приложений для определения и использования данных и их организации. Широкое распространение этих понятий может позволить Рабочей группе HL7 и другим организациям-разработчикам стандартов давать более строгие рекомендации по взаимодействию, реализация которых оставляет меньше свободы выбора.

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

1.7.2 Обеспечение безопасности данных в информационных системах учреждений здравоохранения

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

1.7.3 Требования Министерства обороны США (DOD) к безопасности и надежности систем

При разработке стандарта HL7, включая версию 2.5, не учитывались требования Министерства обороны США к безопасности и надежности систем по категориям (A, B, C, D) и классам (1, 2, 3) защиты данных. Если пользователям необходимо выполнять эти требования, то они должны определить собственные структуры, предназначенные для выполнения требований соответствующей категории и класса защиты, и обеспечить их однотипную реализацию во всех системах своего учреждения или ведомства.

1.7.4 Воплощение политики обеспечения безопасности данных на уровне учреждения

Сама по себе версия 2.5 стандарта HL7 не предназначена для воплощения политики обеспечения безопасности данных и управления доступом на уровне организации здравоохранения. До настоящего момента в стандарте не были предусмотрены специальные сообщения, которые бы в соответствии с этой политикой влияли на перемещение данных в зависимости от идентификаторов пользователей сообщения и их прав доступа к информации. Разработчики систем, которым необходимо обеспечить выполнение этих требований, могут обратиться к соответствующим стандартам ASTM и рекомендациям IOM.

1.7.5 Классификации безопасности данных (категорирование), аутентификация и идентификация пользователей

В настоящее время версия 2.5 стандарта HL7 не включает в себя структур, специально рассчитанных на присваивание объектам данных категорий и классов доступа в соответствии с требованиями Министерства обороны США. Для этих целей можно воспользоваться рекомендациями IOM и JCAHO по обеспечению различных уровней конфиденциальности данных и аутентификации как производителей, так и потребителей конфиденциальных данных.

1.7.6 Роли и связи

Сама по себе версия 2.5 стандарта HL7 не пытается определить или даже поддерживать связи, явным или неявным образом возникшие между такими лицами, как пациенты, врачи, организаторы здравоохранения и т.д. В будущем работа по моделированию данных, которая ведется Рабочей группой HL7 и другими разработчиками стандартов, может привести к тому, что эти роли и связи будут отражены в стандарте HL7.

1.7.7 Регистрация транзакций, аудит и ответственность

В версии 2.5 стандарта HL7 не определены такие типичные средства обработки транзакций, как регистрационные журналы. Подобные средства могут быть необходимы для контроля правильности выполнения транзакций как в обычной вычислительной среде, так и в системах с повышенной безопасностью данных. Они могут требоваться для проверки того, что данное действие выполняется уполномоченным на то лицом. Пользователь может сам решить, нужны ли ему эти средства в его интегрированной среде.

1.7.8 Аппаратные и программные средства обеспечения безопасности данных и доверенной постоянной защиты

В версии 2.5 стандарта HL7 не предусматривается возможность использования аппаратных и программных средств обеспечения безопасности данных, в том числе постоянной защиты данных от несанкционированного использования. Такие средства могут быть полезны для ограничения доступа определенным пользователям или с определенных устройств к некоторым типам данных, при котором учитывается тип устройства или местонахождение. Чтобы выполнить определенные требования Министерства обороны США и рекомендаций организации IOM, пользователям могут понадобиться собственные разработки или приобретение сторонних специализированных программно-аппаратных средств.

1.7.9 Однородные определения данных и архитектура данных

В состав версии 2.5 стандарта HL7 не входят ни явно определенная модель данных, ни единый словарь данных. Однако участники Рабочей группы HL7 провели большую работу по созданию моделей данных для версий 2.2 и 2.3. Хотя эти модели не проходили формальные процедуры голосования, с ними можно ознакомиться на веб-сервере HL7. Модель данных и единый словарь данных могут стать официальной частью будущих версий стандарта HL7.

1.7.10 Контролируемое раскрытие защищенной медицинской информации, уведомление о ее закрытом характере, отслеживание исключений

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

1.7.11 Отслеживание коррекции, удаления или отказов в коррекции либо удалении защищенной информации о здоровье пациентов

В версии 2.5 стандарта HL7 не предусмотрены сообщения, обеспечивающие отслеживание коррекции, удаления или отказов в коррекции либо удалении защищенной информации о здоровье пациентов. Такие сообщения могли бы оказаться полезными в процессе верификации этой информации, а также обнаружения и исправления имеющихся в ней ошибок. При необходимости пользователи могут самостоятельно определить и использовать собственные сообщения для этих целей.

1.7.12 Обнаружение неправильно идентифицированной информации

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

1.7.13 Проверка и отслеживание аутентификации источника данных и целостности данных

Хотя версия 2.5 стандарта HL7 и поддерживает электронную подпись в транзакциях завершения записей медицинской карты, в общем случае она не обеспечивают привязку электронной подписи к приложениям, позволяющую аутентифицировать источник произвольных медицинских сведений и нарушение запрета изменения данных, скрепленных электронной подписью.

1.7.14 Отслеживание проверки ввода

В версии 2.5 стандарта HL7 нет специальных сообщений для отслеживания наличия или отсутствия проверки сведений, полученных от источника данных (человека или машины).

1.7.15 Долговременная медицинская карта

Сама по себе версия 2.5 стандарта HL7 ничего не говорит о реальной логической или физической структуре долговременной медицинской карты пациента. В то время как основные компоненты такой медицинской карты вполне могут быть построены с использованием сообщений стандарта HL7, в нем нет каких-либо разделов, определяющих порядок следования и содержание сообщений, с помощью которых можно было бы вести такую карту. Ряд материалов на эту тему опубликован организациями ASTM, CPRI и IOM. В намерения Рабочей группы HL7 до сих пор не входило формальное описание порядка следования и содержания сообщений, предназначенных для непосредственного ведения долговременной медицинской карты, распределенной по нескольким информационным системам внутри (или вне) системы оказания медицинской помощи.

1.7.16 Интеграция распределенной медицинской карты

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

1.7.17 Синхронизация календаря и часов

В то время как в версии 2.5 стандарта HL7 многие данные содержат штамп даты и времени их создания или изменения, в ней отсутствуют транзакции сверки календаря и часов различных компьютерных систем, образующих гетерогенную вычислительную среду учреждения или ведомства здравоохранения.

1.7.18 Межсистемное замыкание записей баз данных и обработка транзакций

В версии 2.5 стандарта HL7 не предусмотрены сообщения для координации изменений баз данных, происходящих в гетерогенной вычислительной среде. Пользователи, которым необходимы распределенные базы данных, могут создавать собственные сообщения или полагаться на встроенные функции систем управления базами данных (к примеру, Oracle, Sybase и др.).

1.7.19 Операции, процессы и другая "местная" поддержка

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

1.7.20 Интерфейсные машины

За последние годы так называемые интерфейсные машины стали популярным средством реализации и использования стандарта HL7 и других интерфейсов, основанных на использовании сообщений. Сами по себе интерфейсные машины не являются априорным условием реализации стандарта HL7 в том или ином месте. В его структуре нет никаких предположений о наличии интерфейсной машины в конкретном месте реализации. Поэтому в нем нет и сообщений, предназначенных для взаимодействия с интерфейсными машинами и управления ими. Таковые могли бы оказаться полезными, если интерфейсная машина берет на себя архитектурные функции динамического фильтра и арбитража сообщений в соответствии с динамическими правилами, задаваемыми системами доставки сообщений.

1.7.21 Машины правил

Как практическое приложение интерфейсных машин в топологии интерфейсов информационных систем здравоохранения, машины правил приобретают все большую популярность. Однако в настоящий момент стандарт HL7 не предусматривает специальных сообщений для определения правил, которые могли бы быть динамически связаны с интерфейсными машинами, и управления их выполнением. К таковым могли бы относиться: создание и модификация терапевтических и/или диагностических протоколов, активизация клинических и/или административных процессов (например, условных заказов, критических путей и т.д.), отмена или приостановка активных клинических процессов, уведомление соответствующих пользователей об изменении состояний или условий.

1.7.22 Приложения инфраструктурного уровня

Значительное число приложений и средств доставки информации функционирует на "инфраструктурном уровне", связывающем отдельные информационные системы. К этим приложениям можно отнести, к примеру:

• простое и интегрированное ведение расписаний;
• обеспечение лечебно-диагностического процесса непосредственно на месте оказания медицинской помощи;
• предупреждения и напоминания;
• параллельное наблюдение, измерение и анализ;
• параллельное обеспечение принятия решений;
• отслеживание результатов лечения;
• отслеживание "ожиданий" пациента (то есть потребителя) и степени их удовлетворения;
• ведение списков проблем.

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

1.7.23 Поддержка вторичной электронной медицинской карты

В версии 2.5 стандарта HL7 не предусмотрены специальные сообщения, обеспечивающие частичную репликацию (то есть извлечение и последующее объединение) демографических и клинических данных пациента. Этот процесс лежит в области интересов организаций IOM, JCAHO и ряда других, которые рассматривают его как существенное условие для практического использования систем ведения электронной медицинской карты. В будущем, когда такие организации, как ASTM и CPRI, разработают соответствующие спецификации для этого рода деятельности, а производители информационных систем для здравоохранения начнут включать этот тип функциональности в предлагаемые ими системы ведения электронной медицинской карты, стандарт HL7 может предусмотреть более явное обеспечение реализации этой концепции.

1.8 Использованные источники

1.8.1 Стандарты ANSI

ANSI X3.30

1985 Representation for calendar date and ordinal date (представление календарной и порядковой даты)

ANSI X3.4

1986 Coded character sets - American National Standard code for information interchange (7-bit ASCII) (наборы кодированных символов - Американский национальный стандартный код для обмена информацией, 7-битовый код ASCII)

ANSI X3.43

1986 Information systems representation of local time of day for information interchange (представление местного времени дня при информационном взаимодействии автоматизированных систем)

ANSI X3.50

1986 Representations for U.S. customary, SI, and other units to be used in systems with limited character sets (представления традиционных единиц измерения, принятых в США, единиц измерения системы СИ и других систем с использованием ограниченного набора знаков)

ANSI X3.51

1986 Representations of universal time, local time differentials, and United States time zone references for information interchange (представления универсального времени, разностей местного времени и часовых поясов США при обмене информацией)

1.8.2 Стандарты ИСО

ИСО 5218

1977 Information technology - Codes for the representation of human sexes (Информационные технологии. Коды для представления пола человека).

ИСО 1000

1981 SI Units and Recommendations for the use of their multiples and of certain other units (Единицы СИ и рекомендации по применению кратных и дольных от них и некоторых других единиц)

ИСО 2955

1983 Information processing-Representation of SI and other units in systems with limited character sets (Обработка информации. Представление единиц СИ и других единиц в системах с ограниченным набором знаков)

ИСО 8072

1986 Network Standards (Информационные технологии. Взаимосвязь открытых систем. Определение услуг транспортного уровня)

ИСО 8601

1988 Data elements and interchange formats - information interchange (representation of dates and times) (Элементы данных и форматы для обмена информацией. Обмен информацией. Представление дат и времени)

ИСО 8859

1988 Information Processing - 8-bit single-byte coded graphic character sets (Информационные технологии. 8-битовые однобайтовые наборы кодированных графических знаков)

ИСО 8859/1

1988 Information Processing - Latin Alphabet No. 1 (Информационные технологии. 8-битовые однобайтовые наборы кодированных графических знаков. Часть 1. Латинский алфавит N 1)

ИСО 8859/2

1988 Information Processing - Latin Alphabet No. 2 (Информационные технологии. 8-битовые однобайтовые наборы кодированных графических знаков. Часть 2. Латинский алфавит N 2)

ИСО 8859/3

1988 Information Processing - Latin Alphabet No. 3 (Информационные технологии. 8-битовые однобайтовые наборы кодированных графических знаков. Часть 3. Латинский алфавит N 3)

ИСО 8859/4

1988 Information Processing - Latin Alphabet No. 4 (Информационные технологии. 8-битовые однобайтовые наборы кодированных графических знаков. Часть 4. Латинский алфавит N 4)

ИСО 8859/5

1988 Information Processing - Latin/Cyrillic Alphabet (Информационные технологии. 8-битовые однобайтовые наборы кодированных графических знаков. Часть 5. Латинский/кириллический алфавит)

ИСО 8859/6

1988 Information Processing - Latin/Arabic Alphabet Alphabet (Информационные технологии. 8-битовые однобайтовые наборы кодированных графических знаков. Часть 6. Латинский/арабский алфавит)

ИСО 8859/7

1988 Information Processing - Latin/Greek Alphabet Alphabet (Информационные технологии. 8-битовые однобайтовые наборы кодированных графических знаков. Часть 7. Латинский/греческий алфавит)

ИСО 8859/8

1988 Information Processing - Latin/Hebrew Alphabet Alphabet (Информационные технологии. 8-битовые однобайтовые наборы кодированных графических знаков. Часть 8. Латинский/древнееврейский алфавит)

ИСО 8859/9

1988 Information Processing - Latin Alphabet No. 5 (Информационные технологии. 8-битовые однобайтовые наборы кодированных графических знаков. Часть 9. Латинский алфавит N 5)

JAS2020

A subset of ISO 2020 used for most Kanji transmissions (подмножество знаков стандарта ИСО 2020, используемое в большинстве передач текста на кандзи)

JIS X 0202

ISO 2022 with escape sequences for Kanji (стандарт ИСО 2022 с управляющими последовательностями для кандзи)

1.8.3 Источники кодируемых значений и терминологии

ACR

Index for Radiological Diagnosis, Revised 3rd Edition (Перечень диагнозов лучевой диагностики. Издание третье, переработанное)

CPT4

Current Procedural Terminology (Текущая терминология процедур)

CAS

USAN 1990 and the USP dictionary of drug names (словари наименований лекарственных средств LISAN 1990 и Фармакопеи США)

EUCLIDES

European standard for clinical laboratory data exchange (Европейский стандарт по обмену данными клинических лабораторий)

Home Health

Home Healthcare Classification System (Virginia Saba, EdD, RN, Georgetown U. School of Nursing, Washington DC) (Система классификации медицинской помощи на дому)

HIBCC

Standard for electronic business data interchange (Стандарт электронного обмена коммерческими данными)

ICCS

Commission on Professional and Hospital Activities (Комиссия по профессиональной и госпитальной деятельности)

ICD-9

International Classification of Diseases, 9th Revision (Международная классификация заболеваний, 9-й пересмотр)

ICD9-CM

International Classification of Diseases, Clinical Modification Manual of Clinical Microbiology (International Classification of Diseases, 9th Revision (Международная классификация заболеваний, руководство по клинической модификации для клинической микробиологии))

NANDA

North American Nursing Diagnosis Association, Philadelphia PA (Североамериканская ассоциация сестринских диагнозов)

NDC

National drug codes (Национальные коды лекарств)

NIC

Nursing Interventions Classification, Iowa Intervention Project. U. of Iowa (Классификация сестринских вмешательств)

NLM

Unified Medical Language (Унифицированный медицинский язык)

Omaha System

Omaha Visiting Nurse Association, Omaha NE

Read

Clinical Classification of Medicine (Клиническая классификация медицины)

SNOMED III

Systemized Nomenclature of Medicine (Систематизированная номенклатура медицинских терминов)

WHO

Drug Codes (Коды лекарственных средств)

UMDNS

Universal Medical Device Nomenclature System (Универсальная системы номенклатуры медицинских устройств)

FDA K10

Device Codes Device and analyte process codes (Коды устройств и аналитических процессов)

LOINC

Laboratory Object Identifier and Numerical Code (Логические названия и коды идентификаторов лабораторных исследований)

1.8.4 Другие источники

ASTM E31.12 Draft Dec 1990 - A Standard Specification for Representing Clinical Laboratory Test and Analyte Names Draft (Стандартная спецификация представления клинических лабораторных анализов и наименований аналитов, проект)

ASTM E1467-91 Standard Specification for Transferring Digital Neurophysiological Data Between Independent Computer Systems (Стандартная спецификация передачи цифровых нейрофизиологических данных между независимыми вычислительными системами)

ASTM E1394 A Standard Specification for Transferring Information Between Clinical Instruments and Computer Systems (Стандартная спецификация передачи информации между клиническими инструментами и вычислительными системами)

ASTM E1381 Standard Specification for the Low-level Protocol to Transfer Messages between Clinical Instruments and Computer Systems (Стандартная спецификация низкоуровневых протоколов передачи сообщений между клиническими инструментами и вычислительными системами)

McDonald CJ, Hammond WE: Standard formats for electronic transfer of clinical data. Annals of Internal Medicine 1989; 110(5): 333 - 335.

International Union of Pure and Applied Chemistry/International Federation of Clinical Chemistry. The Silver Book: Compendium of terminology and nomenclature of properties in clinical laboratory sciences. Oxford: Blackwell Scientific Publishers, 1995.

LOINC Committee. Logical Observation Identifier Names and Codes. Indianapolis: Regenstrief Institute and LOINC Committee, 1995. c/o Kathy Hutchins, 1001 West 10th Street RG-5, Indianapolis, IN 46202. 317-630-7433. Можно получить по ссылкам FTP/Gopher (dumccss.mc.duke.edu/standards/HL7/termcode/loinclab) и World Wide Web (http://dumccss.mc.duke.edu/standards HL7/termcode/loinclab/)

Forrey AF, McDonald CJ, DeMoor G, Huff SM, Leavelle D, Leleand D et al. Logical Observation Identifier Names and Codes (LOINC) database, A public use set of codes and names for electronic reporting of clinical laboratory test results. Clin Chem 1996; 42: 81 - 90.

UB-92 National Uniform Billing Data Element Specifications as developed by the National Uniform Billing Committee, November 5, 1997. (Национальные спецификации универсальных элементов данных счетов на оплату лечения, утвержденные комитетом Health Claims Review Committee штата Флорида 19 декабря 1993 года, второй пересмотр).

UB-82 Recommended Billing Instructions (Рекомендованные инструкции по счетам на оплату лечения).

1.9 Технические редакторы

В целом техническое редактирование содержания стандарта выполнено следующими лицами:

1.10 Предложения и комментарии

Рабочая группа HL7 Working Group принимает комментарии и предложения по совершенствованию стандарта. Она также открыта для приема новых членов. По вопросам содержания стандарта и членства в Рабочей группе HL7 обращайтесь к следующим лицам:

2 Управление

Основной редактор:

Mike Henderson, Eastern Informatics.

Основной редактор (завершающий работу):

Doug Pratt, Siemens Medical Solutions Health Services Corporation.

Основной редактор (завершающий работу):

Larry Reis, Consultant.

Основной редактор:

Mark Shafarman, Oracle.

Основной редактор (начинающий работу) и технический редактор:

Joann Larson, Kaiser Permanente.

Основной редактор (начинающий работу):

Dale Nelson, Zed-Logic.

Основной редактор (начинающий работу):

Mark Tucker, Regenstrief.

Сопредседатели Рабочей группы по соответствию стандарту:

Mary Ann Juurlink, Canada Health Infoway;

Jennifer Puyenbroek, McKesson Information Solutions;

Ioana Singureanu, Eversolve.

2.1 Введение

В настоящем разделе стандарта даются общие правила, применимые ко всем сообщениям. Последующие разделы определяют функционально специфичные сообщения, обеспечивающие обмен информацией между определенными приложениями. Настоящая глава посвящена описанию следующих специфичных аспектов определения сообщения:

a) формы описания сообщений, используемой в функциональных главах, включая их назначение, содержание и взаимную зависимость. Эта форма называется определением абстрактного сообщения (abstract message definition), поскольку она в чистом виде соответствует определению уровня 7 (прикладного уровня);

b) правил кодирования стандарта HL7, описывающих преобразование абстрактного сообщения в строку символов, являющуюся реальным сообщением;

c) программных процедур, требуемых для обмена сообщениями в соответствии со спецификациями стандарта HL7;

d) предполагаемых связей с протоколами нижних уровней;

e) некоторых сегментов, являющихся компонентами всех сообщений;

f) отдельного сообщения, а именно подтверждения (Acknowledgement message), которое без изменений может быть использовано во многих приложениях.

2.2 Концептуальный подход

2.2.1 События, требующие реакции

Стандарт написан в предположении, что реальное событие, происходящее в сфере здравоохранения, создает потребность в обмене данными между системами. Такое реальное событие называется событием, требующим реакции (trigger event), или просто событием. Например, событие госпитализация пациента может вызвать потребность передачи сведений об этом пациенте ряду других систем. Событие "получен результат исследования пациента" (например, выполнен клинический анализ крови) также может вызвать потребность в передаче этого результата ряду других систем. Когда передача информации инициируется прикладной системой в связи с событием, требующим реакции, то соответствующая транзакция будет называться прямой (unsolicited update).

Примечание - Ни структура, ни архитектура прикладной системы, выполняющей прямую транзакцию, никак не затрагиваются настоящим стандартом. Область его применения ограничена спецификацией сообщений, передаваемых прикладными системами, и событий, которые инициировали эти сообщения.

Стандарт HL7 позволяет использовать события на нескольких уровнях детализации и взаимосвязей данных. Например, большинство событий ГВП (госпитализация, выписка, перевод) являются простыми событиями (скажем, госпитализация инициирует создание сообщения, содержащего данные пациента и идентификацию его лицевого счета). Другие события ГВП включают взаимосвязи между несколькими объектами (например, события объединения приводят к объединению сведений о пациенте или о его лицевых счетах). Некоторые события ГВП включают информацию о совокупности объектов, между которыми нет сколько-нибудь существенных семантических связей (например, запрос сведений в формате записей, содержащих информацию о госпитализированных пациентах, связанных между собой лишь случайно, по географическому признаку).

2.2.2 Подтверждения. Исходный режим

Когда прямая транзакция передается из одной системы в другую, то данный режим подтверждения задает подтверждение на прикладном уровне. Необходимость такого подтверждения вызвана тем, что одной лишь гарантии передачи сообщения нижележащей коммуникационной системой недостаточно. Нужно еще знать, что приложение-получатель успешно обработало данные на прикладном уровне.

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

В стандарте HL7 не делается никаких предположений о владельце данных. В нем также не делается никаких предположений ни о последующих действиях получателя данных, ни о структуре или архитектуре прикладной системы-получателя. Область применения стандарта HL7 ограничена спецификацией сообщений, передаваемых между прикладными системами, и событий, которые их вызвали. В явном виде стандарт HL7 не поддерживает системы, обеспечивающие переадресацию сообщений (store and forward) и их широковещательную передачу (broadcast), хотя и не исключает эти режимы передачи (см. "Руководство по реализации стандарта HL7").

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

2.2.3 Подтверждения. Расширенный режим

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

2.2.4 Запросы

Описание запросов, включая сообщения, сегменты, специальные протоколы, методические указания и примеры перемещены в раздел 5. Описание прямых дисплейных сообщений также перемещено в этот раздел, поскольку синтаксис этих сообщений имеет ту же природу, что и синтаксис запросов.

2.3 Коммуникационная среда

Сообщения и процедуры, используемые для их передачи, определены в стандарте HL7 на уровне взаимодействия прикладных модулей. Тем самым с концептуальной точки зрения он оперирует на седьмом уровне модели взаимодействия открытых систем OSI организации ИСО. При этом он имеет дело в основном с содержанием данных, взаимосвязями сообщений и с передачей некоторых сообщений об ошибках прикладного уровня.

Так как протоколы OSI не реализованы универсальным образом, то Рабочая группа HL7 заинтересована в предложении стандартов, которые заполняли бы этот пробел. Она также отдает себе отчет в том, что в настоящее время существует и будет продолжать существовать определенный интерес к передаче информации между прикладными системами здравоохранения, работающими в коммуникационной среде с высоким уровнем функциональности, но использующей протоколы, отличающиеся от протоколов OSI организации ИСО. Многообразие коммуникационных сред, представляющих интерес для стандарта HL7, включает в себя следующие примеры (но не ограничивается ими):

a) среды ad hoc, которые не предусматривают надежности даже на основном транспортном уровне. Примерами могут служить соединения "точка-точка" на базе стандарта RS-232 и модемов, и даже локальные сети, чьи соединения с центральными компьютерами выполнены также на базе стандарта RS-232. Пока стандарты высоких уровней модели OSI не станут абсолютно преобладающими, многие взаимодействия между прикладными системами здравоохранения будут реализовываться с помощью указанных выше средств связи. В такой среде могут быть полезны протоколы нижних уровней LLP (Lower Level Protocols) стандарта HL7, применение которых может расширить возможности коммуникации приложений в указанных средах. Протоколы нижних уровней стандарта HL7 определены в "Руководстве по реализации стандарта HL7", не являющемся официальной частью стандарта;

b) среды, обеспечивающие приемлемую надежность на транспортном уровне, но не соответствующие требованиям модели OSI на более высоких уровнях, например, TCP/IP, DECNET и SNA;

c) среды, соответствующие стандартам ИСО, и специфические сети производителей, которые реализованы до уровня представления (presentation level) и более высоких уровней. Протоколы SNA LU6.2 фирмы IBM и NFS фирмы SUN Microsystems являют собой примеры полностью специфических сетей;

d) два или более приложения, исполняемые на одной и той же физической и/или логической машине, которые не очень тесно связаны. В таких средах передача сообщений может быть реализована через средства взаимодействия процессов (например, конвейеры Pipes в операционной системе UNIX).

В стандарте HL7 предполагается, что коммуникационная среда обеспечивает следующие возможности:

a) безошибочную передачу данных. Приложения могут рассчитывать на то, что они правильно получают все переданные байты в той последовательности, в которой они были отправлены. Это означает, что контроль ошибок передачи выполняется на более низком уровне. Однако приложения-отправители не могут рассчитывать на то, что сообщение было действительно получено, пока им не придет соответствующее подтверждение.

b) преобразование символов. Если два компьютера, обменивающиеся данными, используют различные системы кодировки символов, то коммуникационная среда должна обеспечивать преобразование кодов символов из одной системы в другую.

c) необходимую длину сообщений. В стандарте HL7 не устанавливается каких-либо ограничений на максимальную длину сообщений. В нем предполагается, что коммуникационная среда может передавать сообщения любой необходимой длины. Однако на практике местным соглашениями может быть введена некоторая верхняя граница длины сообщения. Тогда может потребоваться использование описанного ниже в этом разделе протокола продолжения для тех сообщений, длина которых превышает этот предел.

Примечание - Поскольку в стандарте HL7 не делается никаких предположений о структуре или архитектуре прикладных систем, отправляющих и принимающих определенные в нем сообщения, в нем нет и предположений о коммуникационных средах сверх описанных выше. В частности, структура и архитектура коммуникационных сред, за исключением описанных выше требований, остается за пределами области применения стандарта HL7.

2.4 Сообщения стандарта HL7

В данном разделе даются определения компонентов сообщений, а также обсуждается методология определения абстрактных сообщений, используемая в последующих главах. Правила конструирования сообщений обсуждаются в подразделе 2.6.

2.4.1 Сообщения

Сообщение является минимальной единицей данных, передаваемых между системами. Оно состоит из группы сегментов, расположенных в определенной последовательности. Каждое сообщение относится к определенному типу сообщения, который определяет его назначение. Например, сообщения типа ADT (Admission, Discharge, Transfer) используются для передачи из одной системы в другую отдельных порций сведений о госпитализации, выписке и переводе пациента. Каждое сообщение включает в себя трехсимвольный код, определяющий его тип. Эти коды перечислены в таблице типов сообщений (Приложение A).

Реальное событие, происходящее в системе здравоохранения и инициирующее обмен сообщениями, называется событием, требующим реакции, или просто событием. (Более детальное описание событий см. в 2.2.1, "События, требующие реакции". Перечень всех типов событий, определенных в стандарте, см. в таблице HL7 0003 "Тип события. Коды типов событий представляют значения вида "пациент госпитализирован" или "сделан заказ". Между типами сообщений и кодами типов событий существует отношение один-ко-многим. Один и тот же код типа события не может быть связан более чем с одним типом сообщения, но тип сообщения может связываться более чем с одним кодом типа событием.

Все типы сообщений и коды типов событий, начинающиеся с буквы "Z", зарезервированы для местных сообщений. В стандарте HL7 ни одного такого кода не будет.

2.4.2 Сегменты и группы сегментов

Сегмент представляет собой логическую группировку полей данных. Сегменты сообщения могут быть обязательными или необязательными. Они могут встречаться в сообщении только один раз или же может быть разрешено многократное повторение сегмента. Каждому сегменту присвоено имя. Например, сообщение типа ADT может содержать следующие сегменты: "Заголовок сообщения" (Message Header - MSH), "Тип события" (Event Type - EVN), "Идентификация пациента" (Patient ID - PID), и "Визит пациента" (Patient Visit - PV1).

Каждый сегмент идентифицируется уникальным трехсимвольным кодом, который называется идентификатором сегмента (Segment ID). Хотя реальные сегменты определяются в различных главах, присвоенные им коды перечислены в приложении A.

Все идентификаторы сегментов, начинающиеся с буквы Z, зарезервированы для местных сегментов. Ни одного такого кода сегмента в стандарте HL7 нет.

Два или более сегментов могут быть могут быть организованы как логическая единица, называемая группой сегментов. Группа сегментов может быть обязательной или необязательной, может быть однократной или повторяемой. Начиная с версии 2.5, первый сегмент во вновь определенной группе сегментов должен быть обязательным, чтобы ненароком не определить сообщения, не поддающиеся однозначному разбору.

Группе сегментов присваивается имя, представляющее собой постоянный идентификатор, который не может быть изменен.

Синтаксис абстрактных сообщений допускает, что именованный сегмент X может входить в описание сообщения несколько раз. Это не надо смешивать с повторением сегмента, описанным ранее. Когда сегмент входит в описание сообщения несколько раз, то должны выполняться следующие правила:

Если в описании абстрактного сообщения именованный сегмент X входит в двух отдельных местах или в двух группах, и выполнено одно из следующих условий:

d) каждое вхождение сегмента в конкретное место сообщения является необязательным или повторяющимся;

e) каждое вхождение сегмента в конкретную группу является необязательным или повторяющимся,

то вхождения сегмента X должны быть разделены хотя бы одним обязательным сегментом с другим именем, чтобы не было неоднозначности в определении назначения вхождения сегмента X в конкретный экземпляр сообщения или группы.

Ниже приведены примеры правильной группировки сегментов:

Примеры группировок сегментов, не поддающихся однозначному разбору:

В каждом из этих примеров нельзя однозначно определить, к какой части сообщения принадлежит сегмент SEG1.

2.4.3 Поля

Поле представляет собой строку символов. Поля, предназначенные для использования в сегментах сообщений HL7, определены Рабочей группой HL7. Исчерпывающий словарь данных, описывающий все поля сообщений HL7, приведен В приложении A.

Стандарт HL7 никак не затрагивает способы хранения данных в приложениях. Приложения передают поля в виде строк символов. За особо отмеченными исключениями поля данных в стандарте HL7 могут принимать пустое значение (null). Пересылка пустого значения, которое изображается в виде пары смежных кавычек ("), отличается от опущенного значения необязательного поля данных. Эта разница проявляется, когда содержание сообщения используется для модификации уже существующей записи в базе данных. Если никакого значения не передано (т.е. оно опущено), то прежнее значение должно остаться неизмененным. Если передано пустое значение, то прежнее значение должно быть заменено на пустое. (Дополнительные детали см. в разделе 2.5, "Правила составления сообщений".)

Правила контроля версий, затрагивающие поля, см. в разделе "Местные расширения".

Различные главы стандарта содержат таблицы с определениями атрибутов сегментов. В этих таблицах перечисляются и описываются поля данных сегмента и характеризуется их использование. Детальный словарь всех полей стандарта HL7 приведен В приложении A. При определении сегмента для каждого его поля указывается следующая информация.

2.4.3.1 Позиция (положение поля в сегменте)

Порядковый номер поля данных в сегменте. Этот номер используется для последующей ссылки на текстовый комментарий к полю данных, который приводится вслед за таблицей с определением сегмента.

В таблице с определением сегмента номер поля приводится в столбце, озаглавленном N.

2.4.3.2 Максимальная длина

Максимальное число символов, которое может содержать один экземпляр поля.

В таблице с определением сегмента длина поля приводится в столбце, озаглавленном ДЛИНА.

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

Длина поля определяется в зависимости от типа данных, присвоенного полю, и должна находиться между нижним и верхним пределом длины значения этого типа данных. При вычислении длины поля учитываются все входящие в него символы, в том числе разделители компонентов и субкомпонентов. Поскольку максимальная длина задается для одного экземпляра поля, то разделитель повтора полей из подсчета длины поля исключается. (См. 2.4.3.5 "Повтор".)

Применяются следующие соглашения о максимальной длине поля:

• максимальная длина поля должна задаваться числом;
• если максимальная длина поля должна соответствовать "очень большому числу", то для уведомления пользователя должно изображаться число 65536. Это соглашение действовало и в версиях до 2.4, только это число представлялось как 64K;
• если максимальную длину поля нельзя задать точно из-за того, что тип данных этого поля может быть переменным, то должно изображаться символическое число 99999. Это соглашение действовало и в версиях до 2.4, только в качестве длины указывалось слово "перемен." или иное нечисловое описание.

В версии 2.5 максимальные длины присвоены типам данных. См. таблицу HL7 0440 "Типы данных".

2.4.3.3 Тип данных

Основной информационный объект, используемый для конструирования или ограничения значений поля данных. В таблице с определением сегмента тип данных поля приводится в столбце, озаглавленном ТИП. Если поле имеет переменный тип данных, то в этом столбце будет указано "перем.".

В стандарте HL7 определен ряд типов данных. См. 2.16 "Типы данных".

2.4.3.4 Обязательность

Признак того, является ли поле данных обязательным, необязательным или условным в сегменте. В таблице с определением сегмента длина поля приводится в столбце, озаглавленном ОБЯЗ.

Используются следующие обозначения обязательности:

Примечания

1 Начиная с версии 2.3, обязательность поля должна быть явно документирована в определениях полей, которые приведены после таблицы с определением сегмента. Если обязательность полей в сегменте зависит от события, то эта зависимость также должна быть явно документирована.

2 Начиная с версии 2.5, обязательность, ссылка на таблицу значений и длина компонента типа данных приводится в таблицах компонентов, приведенных в определении типа данных. В определениях компонентов, которые следуют за таблицей компонентов, даются пояснения к обязательности и таблице значений. Дополнительные детальные определения полей при необходимости следуют за формальными таблицами с определением сегментов. (См. также разделы 2.4.4, "Разделители сообщения" и 2.5, "Правила составления сообщений").

2.4.3.5 Повтор

Признак того, может ли поле повторяться в сегменте. Значение, указываемое в столбце повтора, определяет максимально допустимое число повторений, например, значение "3" указывает, что допускается до трех экземпляров данного поля. Если в этом столбце ничего не указано, то поле может иметь не более одного экземпляра, т.е. не может повторяться.

В таблице с определением сегмента длина поля приводится в столбце, озаглавленном ПОВТ/#.

Используются следующие обозначения повтора:

Каждый экземпляр поля может содержать число символов, доходящее до максимальной длины поля. См. 2.4.3.2 "Максимальная длина".

Примечание - Для удобства чтения некоторые технические комитеты предпочитают оставлять столбец повтора пустым, чтобы указать, что поле НЕ МОЖЕТ повторяться. Оставлять столбец пустым в качестве признака, что поле может иметь необязательные повторения, нельзя.

Начиная с версии 2.5, пустота столбца повторения означает, что поле НЕ МОЖЕТ повторяться.

2.4.3.6 Таблица

Атрибут таблицы в определении поля указывает идентификатор, присвоенный Рабочей группой HL7 множеству кодированных значений.

В таблице с определением сегмента идентификатор таблицы значений приводится в столбце, озаглавленном ТАБЛ#. Если в этом столбце нет значения или указан пробел, то для этого поля таблица значений не определена.

При описания этого атрибута определения поля данных используется следующий ряд соглашений.

a) если для значения поля используется несколько таблиц, то для их обозначения используется формат xxxx/yyyy. Детальная информация об этих таблицах указана в примечании к описанию поля или типа данных;

b) если поле имеет тип данных ID или IS, то номер таблицы присваивается даже в том случае, когда в описании таблицы, как это бывает с типом данных IS, указано "Рекомендованных значений нет";

c) если поле имеет тип данных CE, CF, CNE или CWE и при этом для его значений используется одна или несколько внешних или местных таблиц, то в столбце номера таблицы будет указано число 9999. Оно служит признаком, что таблица значений используется, но она не считается пользовательской или стандартной таблицей HL7. В описании поля может быть указано, какие внешние таблицы могут использоваться;

d) таблицы значений компонентов или субкомпонентов поля в столбце номера таблицы не указываются:

1. за одним исключением, указанным ниже в пункте 2, таблицы, используемые для значений типов данных, указаны в таблице компонентов типа данных, приведенной в подразделе 2.20 "Типы данных". Однако в комментарии к описанию поля могут быть указаны дополнительные ограничения этих значений. Определение поля данных имеет более высокий приоритет по отношению к определения типа данных;

2. указания таблиц значений, используемых в полях с типами данных CE, CF, CNE и CWE, приводятся только в подразделах с описаниями полей;

3. значения, указанные в таблицах HL7, не могут содержать "разделители по умолчанию", описанные в подразделе 2.4.4 "Разделители сообщений".

В стандарте HL7 определены три типа таблиц значений: таблицы стандарта HL7, пользовательские таблицы и внешние таблицы.

Пользовательские таблицы содержат множества значений, которые определены местными соглашениями. Примером могут служить такие поля, как PV1-3 "Место, закрепленное за пациентом", значения которых зависят от конкретной медицинской организации. Хотя сами табличные значения и не определены в стандарте HL7, тем не менее для облегчения реализации соответствующей таблице присваивается номер пользовательской таблицы. В ряде случае в стандарте указаны рекомендованные значения, которые в данном месте его реализации могут использоваться в качестве отправной точки (например, таблица 0001 "Пол"), Таким пользовательским таблицам нередко присваивается тип данных IS. Обратите внимание, что некоторые пользовательские таблицы значений (например, таблица 0302 "Место лечения") могут представлять собой нормативно-справочные файлы.

Некоторые пользовательские таблицы значений могут быть одинаковыми для целого ряда взаимодействующих организаций здравоохранения, но при этом официально они не стандартизованы. Список значений, рекомендованных для таких таблиц, может быть указан В приложении A. Таблицы таких значений приводятся в тексте окаймленными простой рамкой (например, таблица 0062 "Причина события" в 3.4.1.4 "Коды причин события"). Рекомендуется, чтобы эти значения по возможности использовались в организации, а при необходимости служили базой для расширения. Такие значения тем не менее могут быть переопределены местными соглашениями. Соответствующие функциональные подкомитеты Рабочей группы HL7 принимают предложения по включению дополнительных значений в эти таблицы от тех организаций, которые внедряют данный стандарт.

Таблица HL7 содержит множество значений, которое определено и публикуется Рабочей группой HL7. Такие таблицы являются частью стандарта HL7, поскольку их содержание влияет на интерпретацию сообщений, в которых они передаются. Эти значения не могут быть переопределены местными соглашениями, однако содержание таблицы HL7 может быть расширено за счет местных значений. В частности, это относится к таблице HL7 0003 "Тип события". Таким таблицам чаще всего присваивается тип данных ID. Содержание этих таблиц приведено в приложении A. Они приводятся в тексте также окаймленными простой рамкой (например, таблица HL7 0003 "Тип события").

Внешняя таблица содержит множество кодированных значений, определенное и публикуемое другой стандартизующей организацией. Внешние таблицы используются для присваивания значений таким полям, как FT1-19 "Код диагноза". Другим примером служит кодирование видов клинических исследований с помощью кодов LOINC. Поля, значения которых берутся из внешних таблиц, имеют типы данных CE, CF, CNE и CWE.

Внешние таблицы возникают в приложениях, в которых понятия, а возможно, и коды определяются внешними органами в связи с юридическими требованиями или по соглашению между Рабочей группой HL7 и другими организациями по разработке стандартов. Они могут публиковаться Рабочей группой HL7 с разрешения других организаций. Содержние этих таблиц не баллотируется в Рабочей группе HL7. Они публикуются в стандартах HL7 без изменений. Однако их содержание может изменяться чаще, чем стандарты HL7.

Внешняя таблица может заимствоваться стандартом HL7 в соответствии со специфичным лицензионным соглашением или авторскими правами издателя или автора. Если такая таблица становится таблицей HL7, то пользователи стандарта должны соблюдать требования лицензии или авторского права, предъявляемые источником таблицы, если таковые имеют место.

Поле имеет тип данных CWE, если 1) для этого поля можно использовать другие таблицы, или 2) внешняя таблица допускает местные расширения, или 3) вместо кода можно передавать местный текст.

Поле имеет тип данных CNE, если 1) для этого поля нельзя использовать другие таблицы, и 2) внешняя таблица не допускает местные расширения, и 3) код не может быть заменен текстом. С полем типа CNE должна быть ассоциирована таблица HL7 или внешняя таблица. Она должна быть указана в стандарте.

Местная таблица не имеет идентификатора, присвоенного Рабочей группой HL7. Она содержит множество значений, определенных местными соглашениями. Она может быть присвоена местным полям в Z-сегментах или в полях стандартных сегментов, имеющих тип данных CWE.

2.4.3.7 Идентификатор

Короткое целое число, однозначно идентифицирующее поле данных в тексте стандарта. В таблице с определением сегмента эта информация приводится в столбце, озаглавленном ЭЛЕМ#.

2.4.3.8 Наименование

Описание назначения поля. В таблице с определением сегмента эта информация приводится в столбце, озаглавленном НАИМЕНОВАНИЕ ЭЛЕМЕНТА.

Если поле с тем же самым наименованием используется более чем в одном сегменте, то в каждом таком сегменте оно должно иметь один и тот же тип данных, нести ту же смысловую нагрузку, а также тот же самый идентификатор. Чтобы избежать неоднозначности, вызванной подобным соглашением, при ссылке на подобное поле должны всегда даваться имя сегмента и порядковый номер поля в этом сегменте.

2.4.4 Разделители сообщения

При составлении сообщения используются некоторые специальные символы. К ним относятся терминатор сегмента, разделитель полей, разделитель компонентов, разделитель субкомпонентов, разделитель повтора и спецсимвол (Escape). Терминатором сегмента всегда является символ возврата каретки (в кодировке ASCII он имеет шестнадцатеричный код 0D). Другие разделители определяются в записи заголовка сообщения MSH, при этом разделитель полей занимает 4-ю позицию, а остальные разделители берутся из поля "Символы кодирования" (Encoding Characters), которое следует сразу за идентификатором сегмента. Указанные в заголовке сообщения MSH значения разделителей действительны для всего сообщения. По умолчанию стандарт HL7 рекомендует использовать значения разделителей, показанные в таблице 1.

Подмножество возможных значений разделителей может быть ограничено местными соглашениями. Тогда приложение-получатель может рассчитывать на то, что разделители, взятые из сегмента заголовка сообщения (MSH), будут принадлежать этому подмножеству и их можно будет использовать для разбора сообщения.

Примечание - Двоичные представления разделителей зависят от кодировки символов, используемой для представления сообщения.

Таблица 1

Значения разделителей

2.5 Правила составления сообщений

Примечание - Приведенные ниже правила составления сообщений образуют правила кодирования сообщений стандарта HL7 в форме строк переменной длины с разделителями. Хотя начиная с версии 2.3 стандарта HL7 определен только один свод правил кодирования, тем не менее допускаются и другие своды правил (не будучи включенными в стандарт, они могут использоваться только на основе местных соглашений).

2.5.1 Правила для отправителя

2.5.1.1 Псевдокод составления сообщения

процедура ПередатьСообщение (данные) {

идентифицировать_необходимое_сообщение;

проверить_правильность( данные );

упорядочить_сегменты( данные, список_сегментов );

для_каждого сегмент в (список_сегментов ) {

передать сегмент.имя; /* например., MSH */

/* сформировать все данные для полей */

для_каждого поле в ( поля ( сегмент) ) ) {

передать разделитель_поля; /* например, | */

/* сформировать экземпляры (может исполняться неоднократно только для полей, которые могут повторяться) */

для_каждого экземпляр в ( экземпляры ( поля ) ) {

ПередатьЭкземпляр( экземпляр );

если не последний ( сформированный экземпляр ) передать разделитель повтора; /* например, ~ */

}

прервать если последний ( сформированное поле );

}

передать терминатор_сегмента; /* всегда возврат каретки */

}

завершить;

}

процедура ПередатЭкземпляр( экземпляр) {

/* сформировать заполненные компоненты */

для_каждого компонент в ( компоненты( экземпляр ) ) {

взять_данные_субкомпонента ( компонент );

/* сформировать все данные субкомпонентов */

для_каждого субкомпонент в ( субкомпоненты( компонент ) ) {

/* заменить разделитель поля на управляющую последовательность символов */

заменить( разделитель_поля, \F\ );

/* заменить символы кодирования на управляющие последовательности */

заменить( разделитель_компонентов, \S\ );

заменить(разделитель_повтора, \R\ );

заменить( управляющий_символ, \E\ );

заменить ( разделитель_субкомпонентов, \T\ );

передать субкомпонент;

если не последний ( переданный субкомпонент) передать разделитель_субкомпонентов; /* например, & */

}

если не последний ( переданный компонент ) передать разделитель_компонентов /* например, ^ */

}

завершить;

}

2.5.1.2 Блок-схема составления сообщения

Приведенные ниже блок-схемы представляют другой взгляд на правила составления сообщений. Рисунок 1 показывает правила формирования сообщения; рисунок 2 - правила формирования экземпляра поля.

Рисунок 0 - Блок-схема формирования сообщения

Рисунок 1 - Блок-схема формирования экземпляра поля

2.5.2 Правила для получателя

Следующие правила используются для обработки полученных сообщений стандарта HL7 и преобразования их содержания в данные:

a) игнорировать сегменты, поля, компоненты, субкомпоненты и лишние повторы поля, которые присутствуют в сообщении, но не ожидаются обрабатывающим его приложением;

b) рассматривать сегменты, которые ожидаются приложением, но отсутствуют в сообщении, как состоящие целиком из отсутствующих полей;

c) рассматривать поля и компоненты, которые ожидаются приложением, но не включены в сегмент, как отсутствующие.

2.5.3 Примечания к правилам кодирования

Если сегмент распределен по нескольким сообщениям, то используйте описанные ниже дополнительные правила кодирования. Эти правила описаны в терминах более общего протокола продолжения сообщений (См. 2.9.2 "Продолжение сообщений и сегментов").

2.6 Применение управляющих последовательностей в текстовых полях

2.6.1 Коды формата

В полях данных типов TX, FT и CF можно использовать спецсимвол (escape) для задания некоторых специальных характеристик части текстового поля. Спецсимвол представляет собой изображаемый (печатаемый) ASCII-символ и задается в компоненте спецсимвола поля MSH-2 "Символы кодирования". В настоящем разделе символ "" будет использоваться в качестве спецсимвола, как если бы именно он был описан в указанном поле. Управляющая последовательность состоит из спецсимвола, одного обычного символа - кода управления, 0 или более символов, задающих параметр, и завершается еще одним спецсимволом.

Управляющие последовательности для разделителя полей, разделителя компонентов, разделителя субкомпонентов, разделителя повтора и спецсимвола можно использовать также в полях данных ST.

Определены следующие управляющие последовательности:

Управляющая последовательность не может содержать вложенную управляющую последовательность.

2.6.2 Управляющие последовательности, поддерживающие несколько наборов символов

Приведенные ниже управляющие последовательности обеспечивают возможность одновременного использования нескольких наборов символов в полях, компонентах и субкомпонентов, имеющих типы данных FT, ST и TX. Эти последовательности позволяют процедурам разбора сообщений использовать управляющие последовательности, не нарушая соответствия описанной ниже парадигме управляющих последовательностей стандарта HL7.

1. \Cxxyy\ управляющая последовательность для однобайтового набора символов. Содержит два шестнадцатеричных значения, xx и yy, которые указывают управляющую последовательность, определенную для одного из набора символов, поддерживаемых в текущем сообщении (а именно, ИСО-IR xxx).

2. \Mxxyyzz\ управляющая последовательность для многобайтового набора символов. Содержит три шестнадцатеричных значения, xx, yy и zz. Последнее, zz, является необязательным.

Ниже приведены общие управляющие последовательности смены наборов символов, определенные для упомянутых стандартов кодировки:

Однобайтовые наборы символов:

Многобайтовые наборы символов:

2.6.3 Выделение текста

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

одна система-получатель может выполнить следующий вывод на принтер:

в то время как другая система может вывести "240*" красным цветом.

2.6.4 Управляющие символы

Специальные управляющие последовательности (\F, \S, \R, \T\ и \E) позволяют при выводе текста изображать управляющие символы (например, разделители), не отменяя их назначения. Так, при выводе текста, переданного во фрагменте сообщения:

на экране или принтере будет показана следующая информация (при условии соответствующего назначения разделителей):

2.6.5 Шестнадцатеричные значения

Когда используется управляющая последовательность для шестнадцатеричных значений (\Xdddd...), то за буквой X должны следовать 1 или более пар шестнадцатеричных цифр (0, 1, ..., 9, A, ..., F). Каждая пара шестнадцатеричных цифр задает 8-битовое двоичное значение. Интерпретация этих значений всецело зависит от соглашения между системой-отправителем и системой-получателем и находится вне области применения настоящего стандарта.

2.6.6 Форматированный текст

Если поле данных имеет тип FT (форматированный текст), то команды форматирования также могут быть окаймлены спецсимволом. Каждая команда начинается с точки ".". Допускаются следующие команды форматирования:

Разделитель компонентов, который отделяет строки друг от друга, является пределом действия команды установки временного отступа (.ti) и началом каждой строки в режиме отсутствия переноса слов на следующую строку (.nf). Примерами команд форматирования текста, НЕ включенных в этот тип данных, могут служить: ширина экрана, позиция на странице или на экране, а также тип устройства вывода.

На рисунке 3 приведен пример данных типа FT, взятый из текста протокола лучевого исследования:

Рисунок 2 - Передаваемый форматированный текст

На рисунке 4 показан один из возможных вариантов представления данных, показанных на рисунке 3. Система-получатель может создать много других интерпретаций, варьируя положение правого поля.

Рисунок 3 - Одно из возможных представлений форматированного текста

2.6.7 Местная управляющая последовательность

Когда используется местная управляющая последовательность (\Zdddd), то за буквой Z должны следовать символы, разрешенные для указания в поле данных типа TX. Интерпретация этих данных всецело зависит от местного соглашения между системой-отправителем и системой-получателем и находится вне области применения настоящего стандарта.

2.7 Определение совместимости версий

Правила, описанные в 2.6 "Правила составления сообщения" для обработки полученных сообщений и преобразования их содержания в данные, позволяют дать описанное ниже определение совместимости между версиями 2.x стандарта HL7.

Примечание - Если вариант не покрывается полностью данными правилами, не следует делать вывод, что изменение стандарта допустимо.

Ключом к пониманию совместимости версий служат следующие две аксиомы, а также правила обработки, согласно которым не ожидаемая информация должна игнорироваться:

• старое приложение, получающее новые сообщения, должно быть способно продолжать получение сообщений, не генерируя ошибки;
• новые приложения должны быть способны понимать старые сообщения.

В настоящем разделе обсуждаются те виды измерений, которые могут быть выполнены при условии соблюдения этих двух аксиом. В нем рассматриваются только те изменения, которые могут вноситься Рабочей группой HL7. Местные расширения обсуждаются в 2.11 "Местные расширения".

2.7.1 Добавление сообщений или составных частей сообщений

Новое сообщение или новая составная часть сообщения, определяемые Рабочей группой HL7, могут добавляться в соответствии с описанными ниже правилами. Система-отправитель должна быть способна отправлять новое сообщение или новую составную часть сообщения, а система-получатель, независимо от уровня своей версии, должно игнорировать любое сообщение или новую составную часть сообщения, которые она не ожидает получить, и при этом не генерировать ошибку Это правило не запрещает системе-получателю уведомлять систему-отправителя от том, что дополнительный элемент был игнорирован, но работоспособность системы-получателя не должна нарушаться из-за наличия дополнительного элемента.

a) Могут добавляться новые сообщения.

b) Может быть определена новая группа сегментов.

c) Начиная с версии 2.5, первый сегмент вновь определенной группы сегментов должен быть помечен как обязательный.

d) В существующее сообщение могут добавляться новые сегменты. Обычно они будут добавляться в конец сообщения или группы сегментов, но в принципе могут быть вставлены в любое место сообщения, если для иерархии сегментов это окажется существенным.

e) Если при добавлении нового сегмента возникает ситуация, когда именованный сегмент X появляется в двух разных местах или разных группах, то должны соблюдаться определенные предосторожности. См. 2.6 "Определение сегмента".

f) Новые поля могут добавляться в конце сегмента.

g) Может быть определен новый тип данных.

h) Новые компоненты могут быть добавлены в конце типа данных.

i) Может быть определена новая таблица значений.

2.7.2 Изменение сообщений или составных частей сообщений

Допустимые изменения сообщений или составных частей сообщений могут быть классифицированы как изменение наименования, типа данных, обязательности, повторяемости, длины поля или определения.

a) Описательное текстовое наименования сообщения или составной части сообщения (за исключением наименования группы сегментов) может быть изменено. Такое изменение не должно влиять на способность приложений отправлять или получать и понимать сообщение. Необходимость изменения описательного текстового наименования может быть вызвана следующими причинами: 1) уточнить недостаточно ясное описание, 2) охватить более широкое применение, не нарушая текущее.

b) Может быть изменен тип данных поля или компонента типа данных. Система-отправитель должны быть способна отправить поле с новым или измененным типом данных, а система-получатель, независимо от уровня своей версии, должна быть способна понимать такое сообщение и игнорировать любую составную часть сообщения, которые она не ожидает получить.

1. Тип данных поля может быть изменен при условии, что компоненты нового типа данных имеют ту же структуру и ту же интерпретацию, что и прежний тип данных. Например, тип данных IS может быть заменен на CE, но тип данных PPN не может быть заменен на PN. Тип данных NM не может быть заменен на ST.

2. У существующих полей существующих сегментов тип данных может быть изменен, если крайняя левая часть поля (то есть прежняя версия) имеет тот же смысл, как у прежней версии поля. Это соответствует правилам добавления нового компонента или субкомпонента, описанным в предыдущем разделе. Другими словами, если игнорировать новые части поля (добавленные при изменении типа данных), то оставшиеся части должны представлять собой прежнее поле (имеющее прежний тип данных), имеющее в точности то же значение, которое было у него в предыдущей версии стандарта.

3. Если у компонента типа данных изменен его тип данных, то структура и интерпретация компонента должны остаться теми же, что у прежнего компонента. В конец типа данных можно добавить любой новый компонент.

c) Может быть изменена обязательность составной части сообщения. Система-отправитель должны быть способна отправить измененное поле, а система-получатель, независимо от уровня своей версии, должно быть способно понимать такое сообщение. Допустимы следующие изменения обязательности:

1. существующие необязательные группы сегментов могут быть сделаны обязательными;

2. существующие необязательные сегменты могут быть сделаны обязательными или условно обязательными;

3. существующие необязательные поля могут быть сделаны обязательными или условно обязательными;

4. существующие обязательные поля могут быть сделаны условно обязательными, если сообщение связано с вновь определенным событием. При этом условие должно быть определено таким образом, чтобы для всех ранее определенных событий это поле оставалось обязательным;

5. существующие необязательные компоненты типа данных могут быть сделаны обязательными или условно обязательными.

d) Может быть изменена повторяемость составной части сообщения. Система-отправитель должны быть способна отправить измененную составную часть, а система-получатель, независимо от уровня своей версии, должно быть способно понимать такое сообщение. Учтите, что если неповторяющаяся составная часть сообщения сделана повторяющейся, то информация, переданная в следующих экземплярах составной части, может быть потеряна получателем, которых их не ожидает.

Если стандарт не определяет или не может определить смысловое значение первого экземпляра, а при его реализации использованы правила, согласно которым один из нескольких экземпляров имеющихся данных выбирается в качестве значения неповторяющейся составной части, то эти же самые правила должны применяться и в том случае, когда в новой версии стандарта составная часть определена как повторяющаяся.

Если по мнению владельца или автора соответствующего раздела стандарта изменение составной части сообщения с неповторяющейся на повторяющуюся вызывает проблемы совместимости логического характера, разбора сообщения, деловой практики или иные проблемы, то владелец или автор может предпочесть создание новой структуры, исключающей проблемы совместимости.

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

Допустимы следующие изменения повторяемости:

1. неповторяющаяся группа сегментов может быть сделана повторяющейся при условии соблюдения изложенных выше правил обратной совместимости;

2. неповторяющийся сегмент может быть сделан повторяющимся при условии соблюдения изложенных выше правил обратной совместимости;

3. повторяющийся сегмент не может быть сделан неповторяющимся;

4. неповторяющееся поле может быть сделано повторяющимся при условии соблюдения изложенных выше правил обратной совместимости. Повторяющееся поле не может быть сделано неповторяющимся.

e) Длина поля, типа данных или компонента типа данных может быть увеличена.

f) Могут быть изменены определения таблиц:

1. пользовательская таблица может быть сделана стандартной таблицей HL7 или внешней таблицей;

2. стандартная таблица HL7 может быть сделана внешней таблицей. При этом тип данных поля должен быть заменен на CNE или CWE.

2.7.3 Запрещение сообщения или составной части сообщения

Любая обязательная, необязательная или условно обязательная составная часть сообщения, включая само сообщение, может быть запрещена. Это означает, что будет иметь место одна из следующих ситуаций:

• сообщение или составная часть сообщения больше не несут смысловой нагрузки;
• сообщение или составная часть сообщения заменены на более лучший метод.

При этом в стандарт должна быть добавлена формулировка с указанием факта запрещения, версии, в которой произошло запрещение, а также с указанием заменяющего сообщения или составной части сообщения, если таковые имели место. Стандартная формулировка должна иметь вид "Оставлено для обратной совместимости только в версии 2.x".

Факт запрещения не должен влиять ни на отправителя, ни на получателя сообщения, поскольку сообщение или составная часть сообщения оставлены для обратной совместимости. Организации, внедряющие стандарт, могут договориться не поддерживать передачу запрещенных составных частей сообщений.

Допустимы следующие варианты:

a) сообщение может быть запрещено;

b) событие, инициирующее передачу сообщения, может быть запрещено;

c) структура сообщения может быть запрещена;

d) может быть запрещен сегмент существующего сообщения. Если у запрещаемого сегмента есть зависимые сегменты, то должна быть запрещена вся группа сегментов. Например, в группе [{ABC[DEF][{GHI}]] сегменты DEF или GHI могут быть запрещены, но сегмент АВС не может быть запрещен, если не запрещена вся группа сегментов;

e) поле может быть запрещено Рабочей группой HL7. Организациями, внедряющими стандарт, могут договориться не использовать запрещенные поля;

f) может быть запрещен компонент типа данных;

g) может быть запрещена таблица, включая стандартную таблицу HL7, пользовательскую таблицу, импортированную внешнюю таблицу и ссылку на внешнюю таблицу;

h) может быть запрещено табличное значение. Если таблица содержит значительное число запрещенных значений, то она должна быть пересмотрена в целом;

i) значение, включенное в импортированную внешнюю таблицу, не может быть запрещено.

2.7.4 Удаление сообщения или составной части сообщения

При условии выполнения критериев, приведенных в данном разделе, сообщение или его составная часть могут быть удалены из стандарта. Рабочая группа HL7 контролирует старые имена, чтобы они повторно не использовались.

Примечание - Чтобы получить детальную информацию об отмененном сообщении или отмененной составной части сообщения, читатель должен ознакомиться с соответствующей более ранней версии стандарта. По местному соглашению отправители и получатели могут продолжить использование удаленного сообщения или удаленной составной части сообщения.

a) Составная часть сообщения может быть немедленно удалена из стандарта, если выполняются следующие критерии ("немедленно" означает, что удаление выполняется в той же версии стандарта, в которой эти критерии выполнены).

1. Структура сообщения может быть немедленно удалена, если в стандарте нет ссылок на это сообщение. При этом должны соблюдаться меры предосторожности, чтобы не удалить сообщение преждевременно при удалении события, с которым связано это сообщение. Например, пусть структура сообщения ABC_D01 связан с событиями D01, D02 и D03. Если событие D01 изменилось и с ним стало связано другое существующее сообщение DEF_E01, то структура сообщения ABC_D01 продолжает оставаться активной и связанной с событиями D02 и D03.

2. Сегмент может быть немедленно удален, если он не включен ни в одно сообщение, определенное в стандарте.

3. Тип данных может быть немедленно удален, если он не присвоен ни одному полю. Такое может произойти, если тип данных поля заменен на другой, включающий в себя компоненты старого типа данных.

4. Таблица может быть удалена, если удалены все поля и компоненты, использующие эту таблицу. Это правило относится к таблицам HL7, пользовательским и внешним таблицам. Следует отдавать себе отчет, что такое удаление может вызвать отдаленные последствия.

b) За исключением ситуаций, описанных ниже в пунктах в), г) и д), составная часть сообщения может быть отменена и удалена из стандарта только после того, как она будет находиться в запрещенном состоянии в двух версиях стандарта. Например, если сообщение было изначально запрещено в версии 2.2, то его определение может быть удалено при публикации версии 2.5.

1. Тип сообщения и его определение могут быть удалены.

2. Событие и его определение могут быть удалены.

3. Группа сегментов может быть удалена из существующего сообщения.

4. Сегмент может быть удален из существующего сообщения.

c) Запрещенное поле существующего сегмента не может быть удалено из стандарта. Однако это поле может быть помечено как отмененное и все его описание будет удалено из стандарта, но не раньше, чем оно будет пребывать в запрещенном состоянии в двух версиях стандарта.

d) Запрещенный компонент существующего типа данных не может быть удален из стандарта. Однако этот компонент может быть помечен как отмененный и все его описание будет удалено из стандарта, но не раньше, чем он будет пребывать в запрещенном состоянии в двух версиях стандарта.

e) Запрещенное табличное значение не может быть удалено из стандарта. Однако это значение может быть помечено как отмененное и все его описание будет удалено из стандарта, но не раньше, чем оно будет пребывать в запрещенном состоянии в двух версиях стандарта.

2.7.5 Раннее применение изменений стандарта

Ранее применение изменений стандарта, которые были одобрены техническим комитетом и представлены для следующего голосования в Рабочей группе HL7, является распространенной практикой и не запрещается, однако несет определенные риски. Такие изменения могут быть отменены или изменены в процессе голосования. Например, изменение может пройти голосование, но при этом будет иным способом позиционировано в сегменте или в типе данных.

2.7.6 Правила внесения технических изменений

Технические изменения могут быть выполнены в промежутке между публикациями версий стандарта по мере их необходимости. Эти изменения публикуются на сайте Рабочей группы HL7. К числу технических относятся следующие изменения:

a) исправление орфографических ошибок;

b) ошибочные ссылки на разделы;

c) ошибки, допущенные при импорте внешней таблицы;

d) исправление несовместимости между таблицей с описанием сегмента и описанием поля сегмента;

e) ошибочные примеры;

f) ошибочные или вводящие в заблуждение описания.

2.8 Правила обработки сообщений

Описанные здесь правила обработки применимы ко всем обменам сообщениями независимо от того, применяются ли правила кодирования стандарта HL7 либо протоколы нижних уровней. Они соответствуют основному режиму обработки сообщений. Пользователь может на свое усмотрение применять исходные правила обработки, описанные в 2.9.2, или расширенные правила обработки, описанные в 2.9.3.

Примечание - Сообщение MCF "Отложенное подтверждение" удалено из стандарта. Оно было запрещено в версии 2.2. Соответственно, текстовые описания отложенной обработки удалены из данного раздела.

Существуют некоторые варианты, описанные в разных разделах. К ним относятся:

a) необязательный протокол последовательной нумерации. См. 2.10.1;

b) необязательный протокол продолжения очень длинных сообщений. См. 2.10.2.

Поскольку протокол описывает обмен сообщениями, то описание дается в терминах двух субъектов - инициирующей системы и реагирующей системы. Каждая из них является как отправителем, так и получателем сообщений. Инициирующая система вначале отправляет, а затем получает сообщение, в то время как реагирующая система вначале получает, а затем отправляет сообщение.

Общая схема такого обмена описана в таблице 2.

Таблица 2

Общая схема обмена сообщениями

2.8.1 Инициация сообщения

Инициирующее приложение составляет из своих данных сообщение согласно определению, приведенному в соответствующем разделе настоящего стандарта. Показанные ниже значения данных должны содержаться в сегменте заголовка сообщения MSH (в соответствии с определением сегмента MSH, приведенным в настоящем разделе). Сообщение кодируется в соответствии с прикладными правилами и передается протоколам нижнего уровня, которые попытаются отправить его реагирующему приложению. (Определение полей сегмента MSH см. в 2.14.9 "Сегмент MSH "Заголовок сообщения".)

Таблица 3

Содержание заголовка сообщения

Код события, являющийся вторым компонентом поля MSH-9 "Тип сообщения", может оказаться избыточным в некоторых сообщениях. Например, эта же информация содержится в сегменте EVN сообщения ADT. Она включена туда для совместимости с предыдущими версиями протокола HL7. Для вновь определенных сообщений код события должен включаться только в поле MSH-9 "Тип сообщения".

2.8.2 Реагирование на сообщение с использованием исходных правил обработки

2.8.2.1 Прием и проверка сообщения реагирующей системой

Если используются исходные правила подтверждения, то протокольное программное обеспечение реагирующей системы должно выполнить проверить соответствие полученного сообщения как минимум следующим критериям:

a) значение поля MSH-9 "Тип сообщения" принадлежит к числу тех, что приемлемы для получателя сообщения;

b) значение поля MSH-12 "Идентификатор версии стандарта" приемлемо для получателя сообщения;

c) значение поля MSH-11 "Тип прикладной обработки" приемлемо для прикладного процесса, обрабатывающего сообщение.

Примечание - В сообщении отсутствуют либо пусты поля MSH-15 "Тип подтверждения приема" и MSH-16 "Тип подтверждения прикладной обработки".

Если хотя бы одна из этих проверок дает отрицательный результат, то протокольное программное обеспечение отвергает сообщение, то есть создает сообщение подтверждения ACK со значением AR в поле MSA-1 "Код подтверждения".

Если сообщение успешно проходит все эти проверки, то процесс его обработки переходит к следующему шагу.

2.8.2.2 Прием и проверка/обработка сообщения приложением-получателем

После успешной проверки сообщения реагирующей системой, оно передается приложению-получателю, которое выполняет одно из следующих действий:

a) успешно обрабатывает сообщение и генерирует функциональное ответное сообщение, у которого поле MSA-1 "Код подтверждения" имеет значение AA;

b) посылает сообщение об ошибке, помещая информацию об ошибке в функциональные сегменты этого сообщения и присваивая значение AE полю MSA-1 "Код подтверждения";

c) оказывается не в состоянии обработать сообщение (отвергает его) по причинам, не связанным с его содержанием либо форматом (аварийный останов системы, внутренняя ошибка и т.д.). В большинстве таких ситуаций реагирующая система с большой вероятностью способна удовлетворительно обработать сообщение в другое время. Разработчики, реализующие стандарт, должны принять решение с учетом особенностей прикладной обработки, надо ли автоматически повторить передачу исходного сообщения. Ответное сообщение содержит значение AR в поле MSA-1 "Код подтверждения".

Сегмент заголовка MSH в ответном сообщении конструируется заново в соответствии с описанными выше правилами создания исходного сообщения. В частности, поля MSH-7 "Дата и время сообщения" и MSH-10 "Идентификатор сообщения" характеризуют ответное сообщение, а не переносятся из исходного сообщения. Поля MSH-5 "Приложение-получатель", MSH-6 "Учреждение-получатель" и MSH-11 "Тип прикладной обработки" содержат коды, скопированные из полей исходного сообщения MSH-3 "Приложение-отправитель", MSH-4 "Учреждение-отправитель" и MSH-11 "Тип прикладной обработки".

Во всех описанных выше ситуациях в сегмент MSA помещаются значения, указанные в таблице 4. Определения полей сегмента MSA см. в 2.14.8.

Таблица 4

Содержание сегмента MSA

2.8.2.3 Передача ответного сообщения

По получению ответного сообщения от приложения-получателя реагирующая система отправляет его инициирующей системе.

Инициирующая система обрабатывает ответное сообщение.

2.8.3 Реагирование на сообщение с использованием расширенных правил подтверждения

Реагирование на сообщение с использованием расширенных правил подтверждения осуществляется следующим образом:

a) реагирующая система получает сообщение и отправляет его в надежное хранилище. Это означает, что реагирующая система принимает на себя ответственность за полученное сообщение, освобождая систему-отправителя от каких-либо обязательств повторной передачи этого сообщения. Затем реагирующая система проверяет сегмент заголовка сообщения, чтобы определить, требует ли инициирующая система отправки подтверждения успешного получения и надежного сохранения сообщения. Если таковое требуется, то составляется сообщение подтверждения приема и отправляется инициирующей системе;

b) в этот момент определяется, требуется ли отправка дополнительной информации приложениями, вовлеченными в процесс взаимодействия. Отправляемое сообщение называется подтверждением прикладной обработки и содержит информацию, которая может варьироваться от простой проверки полученного сообщения до сложного ответа, зависящего от приложения. Если реагирующая система ожидает возвращение такой информации, то она инициирует передачу обратного сообщения, как только эта информация станет доступной. На этот раз роли инициирующей системы и реагирующей системы меняются на обратные.

2.8.3.1 Прием и проверка сообщения реагирующей системой

Если используются расширенные правила подтверждения, то протокольное программное обеспечение реагирующей системы должно сначала проверить, может ли сообщение быть принято, анализируя следующие факторы:

a) состояние интерфейса;

b) доступность надежного хранилища, в которое можно поместить сообщение;

c) синтаксическая правильность сообщения, если архитектура системы-получателя предусматривает такую проверку на этом шаге;

d) значения полей MSH-9 "Тип сообщения", MSH-12 "Идентификатор версии стандарта" и MSH-11 "Тип прикладной обработки", если архитектура системы-получателя предусматривает их анализ на этом шаге.

Затем протокольное программное обеспечение реагирующей системы анализирует содержание сегмента заголовка MSH, чтобы определить, требует ли инициирующая система возвращения подтверждения приема.

Примечание - В сообщении присутствует хотя бы одно из полей MSH-15 "Тип подтверждения приема" или MSH-16 "Тип подтверждения прикладной обработки".

2.8.3.2 Передача сообщения общего подтверждения

Инициирующая система не всегда требует, чтобы ей возвращалось сообщение общего подтверждения, но если это имеет место, то реагирующая система возвращает в этом подтверждении один из следующих результата анализа полученного сообщения:

a) подтверждение приема (CA) в поле MSA-1 "Код подтверждения", если сообщение может быть принято для обработки;

b) отказ в приеме (CR) в поле MSA-1 "Код подтверждения", если хотя бы одно из значений полей MSH-9 "Тип сообщения", MSH-12 "Идентификатор версии стандарта" и MSH-11 "Тип прикладной обработки" не приемлемо для приложения-получателя;

c) ошибку приема (CE) в поле MSA-1 "Код подтверждения", если сообщение не может быть принято по какой-либо иной причине (например, при ошибке в протоколе порядковой нумерации).

Сегмент заголовка MSH ответного сообщения конструируется заново в соответствии с описанными выше правилами составления исходного сообщения. В частности, поля, MSH-7 "Дата и время сообщения" и MSH-10 "Идентификатор сообщения" относятся уже к ответному сообщению, а не переносятся из исходного сообщения. Поля MSH-5 "Приложение-получатель", MSH-6 "Учреждение-получатель" и MSH-11 "Тип прикладной обработки" содержат коды, копируемые из полей исходного сообщения MSH-3 "Приложение-отправитель", MSH-4 "Учреждение-отправитель" и MSH-11 "Тип прикладной обработки".

Во всех описанных выше ситуациях в сегмент MSA помещаются значения, указанные в таблице 5. Определения полей сегмента MSA "Подтверждение сообщения" см. в 2.14.8.

Таблица 5

Содержание сегмента MSA

2.8.3.3 Передача подтверждения прикладной обработки

Если сегмент заголовка исходного сообщения указывает, что инициирующей системе требуется также подтверждение прикладной обработки, то таковое должно возвращаться в качестве исходного сообщения в другом обмене.

По отношению к подтверждению прикладной обработки реагирующая система выступает как инициатор. Поскольку посылаемое ею сообщение подтверждения зависит от выполняемого приложения, то структуру такого сообщения надо брать из тех разделов, которые описывают сообщения, характерные для конкретных приложений. При необходимости сообщение с подтверждением о прикладной обработке может само затребовать (в поле MSH-15 "Тип подтверждения приема") сообщение с подтверждением приема (MSA). Однако в этом случае поле MSH-16 "Тип подтверждения прикладной обработки" обязательно должно быть пустым, поскольку протокол не разрешает сообщению с подтверждением прикладной обработки иметь подтверждение прикладной обработки.

Для этого ответного сообщения в сегмент MSA помещаются значения, указанные в таблице 6. Определения полей сегмента MSA "Подтверждение сообщения" см. в 2.14.8.

Таблица 6

Содержание сегмента MSA

Если обработка данных реагирующей системой проходит через несколько стадий, то для передачи другим системам (включая инициирующую систему) информации о промежуточных состояниях обработки можно использовать сообщения, описанные в функциональных разделах. Такие сообщения не являются частью схемы подтверждения исходного сообщения, а должны рассматриваться как независимые сообщения, порожденные событиями в (первоначальной) реагирующей системе.

Примечание - Исходный протокол подтверждения эквивалентен расширенному протоколу, при котором в поле MSH-15 "Тип подтверждения приема" указано значение NE, а в поле MSH-16 "Тип подтверждения прикладной обработки" - значение AL, и при этом сообщение с подтверждением прикладной обработки не требует подтверждения приема (его поле MSH-15 "Тип подтверждения приема" имеет значение NE).

2.9 Специальные протоколы HL7

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

2.9.1 Протокол последовательной нумерации

Для некоторых типов информационного взаимодействия систем вопрос синхронизации содержания баз данных является достаточно критичным. Примером может служить система параклинического отделения, например, лаборатории, которой необходимо знать местонахождение всех госпитализированных пациентов, чтобы правильно адресовать результаты выполненных анализов. Если лаборатория получит транзакцию (сообщение) госпитализации-выписки-перевода ADT, выпадающую из общей последовательности, то информация о текущем составе пациентов и их местонахождении может оказаться некорректной. Хотя применение простой схемы подтверждений один-к-одному и может предотвратить появление выпадающих из последовательности транзакций, но только использование последовательной нумерации может предотвратить их дублирование.

Примечание - Хотя данный протокол последовательной нумерации ограничен рамками простого потока транзакций между двумя приложениями, тем не менее его вполне можно использовать для разработки совместимых со стандартом HL7 приложений, обеспечивающих переадресацию сообщений.

a) Начальные условия:

1. предполагается, что система, получающая поток данных, обеспечивает надежное хранение порядкового номера последней принятой транзакции перед тем, как ее подтвердить. Хранение этого порядкового номера позволяет сравнить его с порядковым номером следующей транзакции и реализовать устойчивую к сбоям схему повторной передачи сообщений;

2. инициирующая система хранит очередь последовательно нумеруемых исходящих транзакций. Длина этой очереди должна подбираться в процессе разработки данной связи. Минимальная длина очереди равна 1;

3. порядковый номер представляет собой положительное (ненулевое) целое число и увеличивается (инициирующей системой) на 1 для каждой следующей транзакции.

b) Начало процесса связи:

1. нулевое значение (0) порядкового номера резервируется: оно допускается только в том случае, когда инициирующая система впервые или заново открывает процесс связи;

2. если система-получатель принимает транзакцию с нулем (0) в поле порядкового номера, то она должна возвратить общее сообщение подтверждения, в котором поле ожидаемого порядкового номера сегмента MSA содержит значение, на единицу большее, нежели номер последней транзакции, которую система-получатель уже приняла. Если это значение не существует (в случае начала установления процесса связи), то сегмент MSA в качестве порядкового номера должен содержать значение -1, означающее, что система-получатель будет использовать положительный ненулевой порядковый номер следующей транзакции, которую она примет, в качестве начального значения запоминаемого порядкового номера (см. ниже в п. д) восстановление синхронизации процесса связи);

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

c) Нормальное функционирование связи:

Принимая очередную транзакцию, система-получатель обеспечивает надежное запоминание ее порядкового номера (согласующегося с ожидаемым ею порядковым номером), а затем подтверждает сообщение, указывая этот же самый номер в поле MSA-4 "Ожидаемый порядковый номер".

d) Ошибочные ситуации (с точки зрения инициирующей системы). Они идентифицируются системой-получателем при сравнении только что полученного ею (текущего) порядкового номера (в поле MSH-13 "Порядковый номер" сегмента заголовка MSH) с ожидаемым порядковым номером, который система-получатель должна вернуть инициирующей системе в поле MSA-4 "Ожидаемый порядковый номер" сегмента MSA:

1. ожидаемый порядковый номер на единицу больше текущего значения. Это означает, что инициирующая система потеряла предыдущее подтверждение и повторно послала ту же транзакцию. Ситуация корректируется инициирующей системой путем посылки следующей по порядку транзакции;

2. ожидаемый порядковый номер меньше текущего значения. Инициирующая система может либо попытаться скорректировать ситуацию, снова передав транзакцию с нулевым порядковым номером, либо заморозить процесс связи до вмешательства оператора;

3. другие ошибки: процесс связи замораживается до вмешательства оператора.

e) Принудительное восстановление синхронизация процесса связи. Значение -1 порядкового номера резервируется; оно допускается только при повторной синхронизации процесса связи инициирующей системой. Как только система-получатель принимает транзакцию с порядковым номером -1, она должна вернуть общее сообщение подтверждения со значением -1 в поле ожидаемого порядкового номера, а затем переустановить свой запомненный порядковый номер на полученный в следующей принятой транзакции ненулевой положительный порядковый номер.

Примечание - Когда инициирующая система посылает сообщение с порядковым номером 0 или -1 (см. выше п. б) или д)), то в этом сообщении кроме сегмента заголовка MSH других сегментов не должно быть, а уж если они присутствуют, то все их поля должны быть пустыми. Со стороны реагирующей системы в этих двух случаях требуется только передача общего сообщения подтверждения.

2.9.2 Продолжение сообщений и сегментов

Иногда ограничения, возникающие при реализации стандарта, приводят к необходимости разбивать длинные сообщения или сегменты на более управляемые порции. Для описания разбиения логического сообщения на одно или несколько отдельных сообщений, соответствующих стандарту, будет использоваться термин "фрагментация". В стандарте идентифицированы две ситуации, когда это может происходить.

Во-первых, отдельный сегмент может оказаться слишком длинным. Для его разбиения на несколько меньших сегментов в стандарте предусмотрен сегмент ADD.

Во-вторых, слишком длинным может оказаться отдельное сообщение. Для управления фрагментацией сообщений в стандарте предусмотрены сегмент DSC и протокол продолжения сообщений.

Обсуждение сегмента указателя продолжения и поля указателя продолжения, и их применения для продолжения ответов на запросы и прямых сообщений изменения данных приведено в 5.

2.9.2.1 Фрагментация и продолжение сегментов с помощью сегмента ADD

Начиная с версии стандарта 2.4, сегмент ADD может использовать для разбиения длинного сегмента на более короткие сегменты в пределах одного сообщения.

Примечание - Приложение-получатель не должно менять интерпретацию смысла сообщения из-за наличия в нем сегмента ADD, если только между системами не действует специальное соглашение.

Для разбиения длинного сегмента используется следующая процедура:

a) сегмент, требующий продолжения (назовем его ANY в данном примере) обрывается на символе с произвольной позицией и завершается стандартным символом завершения сегмента (возврат каретки);

b) следующим в сообщении должен быть сегмент ADD. Все символы после сегмента ADD и разделителя полей ("|") являются логическим продолжением предшествующего сегмента. Все следующие последовательные сегменты ADD содержат символы сегмента ANY, пока не встретится первый сегмент, отличающийся от ADD;

c) сегмент ADD без разделителя полей имеет специальное назначение. См. 2.14.2.3 "Фрагментация сегмента между сообщениями".

Например, сегмент "C" может быть следующим образом фрагментирован в сообщении:

Логически эта последовательность символов эквивалентна следующему фрагменту:

Обратите внимание, что символ "|" в конце первого сегмента ADD является частью значения, а символы "|" после имени сегмента ADD - нет.

2.9.2.2 Фрагментация и продолжение сегментов с помощью сегмента DSC

Если сообщение должно быть фрагментировано и послано как несколько сообщений, то используется сегмент DSC.

a) Сначала логического сообщения прерывается на произвольном сегменте.

b) Затем передается сегмент DSC. Полю DSC-1 "Указатель продолжения" присваивается уникальное значение, которое используется для связи со следующим сообщением.

c) Сегмент DSC завершает первый фрагмент логического сообщения.

d) В поле MSH-14 "Указатель продолжения" следующего сообщения должно быть указано значение, совпадающее со значением поля DSC-1. (Наличие значения у поля MSH-14 служит признаком того, что сообщение является очередным фрагментом ранее посланного сообщения.) У каждого следующего сообщения поле MSH-10 "Идентификатор сообщения" должно иметь собственное уникальное значение. Для связывания фрагментов сообщения в должном порядке используется координация значений полей DSC-1 "Указатель продолжения" и MSH-14 "Указатель продолжения".

e) Логическое сообщение является конкатенацией содержания первого сообщения (у которого поле MSH-14 не имеет значения, а в конце передан сегмент DSC, что служит признаком первого фрагмента) и всех следующих фрагментов (идентифицируемых по значению полей MSH-14).

f) Если используется расширенный режим подтверждения и в сообщении указано, что должно быть возвращено подтверждение приема ACK, то получатель сообщений должен подтвердить получение каждого фрагмента сообщения с помощью сообщения ACK. Так как каждый фрагмент имеет собственный идентификатор сообщения, то при его подтверждении в подтверждении приема ACK должен быть указан идентификатор сообщения того фрагмента, получение которого оно подтверждает.

g) Если используется расширенный режим подтверждения и в сообщении указано, что должно быть возвращено подтверждение прикладной обработки, то получатель должен отправить его однократно после получения последнего фрагмента.

Примечания

1 В подтверждении прикладной обработки должен быть указан идентификатор сообщения, в котором был передан первый фрагмент.

2 Получатель должен определить, является ли данное входящее сообщение фрагментом, по наличию в его конце сегмента DSC. Следующие сообщения идентифицируются как фрагменты по наличию значения у поля MSH-14. Наличие сегмента DSC в конце фрагмента указывает, что следует ожидать дополнительные фрагменты.

Если сообщение завершается сегментом DSC, но за ним не передано ни одного фрагмента, это должно рассматриваться как ошибка протокола продолжения.

Например, одно логическое сообщение может быть следующим образом фрагментировано на три сообщения:

---- Первое сообщение (незавершенный фрагмент) ----

---- Второе сообщение (фрагмент 2) ----

---- Третье сообщение (фрагмент 3, заключительный) ----

Такая последовательность сообщений логически эквивалентна следующему сообщению:

Более содержательный пример приведен в 2.18.4.

2.9.2.3 Фрагментация сегмента между сообщениями

Если требуется разбить последний сегмент фрагмента, то должно быть применено следующее идиоматическое использование сегмента ADD:

a) сегмент, требующий продолжения (назовем его ANY в данном примере) обрывается на символе с произвольной позицией и завершается стандартным символом завершения сегмента (возврат каретки);

b) следующим в сообщении должен быть сегмент ADD. Он не содержит никаких символов, кроме своего имени (ADD). Отсутствие символов является признаком, что сегмент ANY будет продолжен;

c) следующим сегментом должен быть DSC, используемый в соответствии с описанием, приведенным в 2.9.2.2 "Фрагментация и продолжение сегментов с помощью сегмента DSC";

d) первым сегментом следующего фрагмента должен быть ADD. Символы, из которых он составлен, логически являются частью сегмента ADD, переданного в предыдущем фрагменте. Например, фрагменты

логически эквиваленты фрагменту

e) ниже показан пример потока транзакций при передаче прямого сообщения с продолжающимся сегментом.

Первое прямое сообщение и его подтверждение:

Второе прямое сообщение и его подтверждение:

Примечание - Второе сообщение также может быть продолжено с помощью второго сегмента DSC. При необходимости перед ним может быть указан второй сегмент ADD.

2.9.3 Протокол пакетной обработки сообщений стандарта HL7

В ряде ситуаций удобно передавать пакеты сообщений стандарта HL7. Типичным примером может служить пакет финансовых транзакций DFT, пересылаемых системой вспомогательного подразделения финансовой системе. Такой пакет может быть передан он-лайн с помощью обычного протокола обмена файлами либо офф-лайн на магнитной ленте или на дискете.

2.9.3.1 Структура пакетного файла стандарта HL7

Ниже показана структура пакетного файла стандарта HL7 (в терминах синтаксиса абстрактных сообщений):

Примечания

1 Протокол последовательной нумерации естественным образом применяется в передаче пакетов сообщений. См. ниже обсуждение подтверждения пакета.

2 Хотя обычно пакет состоит из однотипных сообщений, его определение никоим образом этого не требует.

3 Сегменты заголовков и концов файла и пакета в стандарте HL7 определяются таким же образом, что и прочие сегменты сообщений этого стандарта. Следовательно, правила составления сообщений, изложенные в 2.5 "Правила составления сообщений", могут быть использованы для кодирования и декодирования пакетных файлов сообщений стандарта HL7.

Пакетный файл стандарта HL7 может содержать нулевое число сообщений только в двух случаях:

a) пакет с нулевым числом сообщений стандарта HL7 может передаваться, чтобы выполнить требование периодической посылки пакетов, несмотря на то, что для передачи нет сообщений;

b) пакет, содержащий нулевое число сообщений с негативными подтверждениями, может передаваться как свидетельство того, что все сообщения стандарта HL7, содержащиеся в требующем подтверждения пакете, неявным образом подтверждаются. См. ниже раздел 2.9.3.3 "Подтверждающие пакеты".

2.9.3.2 Использование сегментов и данных, связанных с передачей пакетов

С протоколом пакетной передачи стандарта HL7 связаны следующие сегменты:

• BHS "Заголовок пакета" (См. 2.14.2);
• BTS "Конец пакета" (См. 2.14.3);
• FHS "Заголовок файла" (См. 2.14.6);
• FTS "Конец файла" (См. 2.14.7).

Сегмент конца пакета BTS содержит поле BTS-3 "Итоговые суммы пакета", которое может содержать одну или несколько сумм, вычисляемых по полям сообщений, составляющих пакет. Метод вычисления таких итоговых сумм определяется спецификой учреждения или приложения, если только он не задан явным образом в функциональных разделах данного стандарта.

2.9.3.3 Подтверждающие пакеты

Вообще говоря, основной смысл посылки пакетов данных состоит в том, что все данные принимаются как целое и обработка ошибок осуществляется по принципу исключения. Однако в стандарте HL7 допускается подтверждение всех сообщений за один прием. Стандарт предоставляет целый ряд возможностей подтверждения пакетов сообщений, которые должны выбираться с учетом прикладной специфики. В этих случаях приложениям, обрабатывающим пакеты сообщений, может быть полезен протокол последовательной нумерации.

Эти возможности таковы:

a) все сообщения подтверждаются в ответном пакете;

b) система-получатель печатает некоторую форму отчета об исполнении пакета, которая вручную обрабатывается персоналом системы-отправителя. При этом протокольное программное обеспечение не выполняет никаких подтверждений;

c) создается автоматический пакет подтверждений, содержащий сообщения подтверждения только для тех сообщений переданного пакета, в которых обнаружены ошибки. В этом режиме может создаваться пустой пакет подтверждений (то есть пакетный файл без сообщений подтверждения).

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

Когда пакет повторно передается для коррекции ошибок предыдущей передачи, то поле BHS-12 "Ссылка на идентификатор пакета" должно содержать идентификатор исходного пакета.

2.9.3.4 Пакетное сообщение как ответ на запрос

Запрос стандарта HL7 может быть использован для получения пакета сообщений следующим образом:

a) укажите значение BB или BL в поле QRD-5 "Тип отложенного ответа", чтобы задать режим пакетного ответа. Запрос будет подтверждаться с помощью общего сообщения подтверждения так, как показано выше в примере отложенного доступа (см. 5);

b) в дополнение к этому следующим образом вставьте в пакетный файл сегменты QRD и QRF:

c) подтверждение пакета описано в 2.9.3.3 "Подтверждающие пакеты".

2.9.4 Режимы модификации с использованием повторяющихся сегментов

Когда в сообщении появляются группы повторяющихся сегментов, то основной синтаксис абстрактных сообщений стандарта HL7 не накладывает никаких ограничений на то, каким образом эти группы будут использоваться системой-получателем сообщения. Поэтому стандарт в дополнение к синтаксису рекомендует два метода их использования: режим "моментального снимка" и режим "кода действия/уникального идентификатора".

Предпосылки: если требуется изменять только часть ранее переданной информации, то интерпретация повторяющихся сегментов (AL1, DG1, PR1, GT1, IN1, IN2, IN3, NK1, NTE) в сообщениях госпитализации, выписки, перевода (ADT) и в финансовых сообщениях может вызывать определенные затруднения. Вплоть до версии 2.3 стандарта HL7 для изменения информации, ранее переданной в этих сегментах, приходилось посылать все сегменты заново, поскольку не существовало никакого способа указать, какой именно из ранее переданных сегментов изменился, а какой - нет. К примеру, пусть изначально были переданы два сегмента диагноза DG1 (один из которых содержал основной диагноз, а другой - сопутствующий диагноз). Если после этого появился еще один сопутствующий диагноз, то система-отправитель должна была передавать все текущие диагнозы заново, то есть три сегмента DG1 (основной диагноз, первый сопутствующий диагноз, второй сопутствующий диагноз). Этот способ дополнения и изменения информации будет именоваться режимом "моментального снимка". В этом режиме вся текущая информация (все повторяющиеся сегменты) должна передаваться заново в каждом последующем сообщении этого типа.

Как описано в разделах, посвященных вводу заказов, передаче результатов исследований и уведомлений об изменении нормативно-справочных файлов, поля кодов действий (то есть кодов управления и статуса), а также уникальных идентификаторов (например, номера заказа у заказчика и у исполнителя) включены в сегменты ORC, OBR, OBX и MFE. Поэтому, если не считать сегментов NTE, данная проблема имеет место в основном для тех сегментов, которые определены в главах, посвященных движению пациентов и финансовым транзакциям

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

2.9.4.1 Определение режима моментального снимка

В режиме "моментального снимка" система-получатель заменяет всю предыдущую группу повторяющихся сегментов на группу повторяющихся сегментов вновь поступившего сообщения. Эта операция эквивалентна удалению сведений, переданных в предыдущей группе, и добавлению сведений, содержащихся во вновь переданной группе. Режим моментального снимка был типичен в реализациях версий 2.1 и 2.2 стандарта HL7, но он остается вполне возможным в версии 2.3 и в более поздних версиях. Чтобы в режиме моментального снимка задать "удаление всех сегментов данной повторяющейся группы", пошлите один сегмент, в котором для всех полей указано "удаление данных".

Пусть, к примеру, в сообщении ADT, содержащем сведения об изменении информации о госпитализированном пациенте, передан следующий сегмент DG1:

Если используется режим моментального снимка, то этот сегмент должен восприниматься как указание удаления всех ранее переданных диагнозов, связанных с данной госпитализацией.

2.9.4.2 Определение режима кода действия/уникального идентификатора

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

Таблица HL7 0206

Код действия с сегментом

Можно дать следующее общее определение уникальному идентификатору: он однозначно задает один из нескольких экземпляров объекта, информация о которых передана в группе повторяющихся сегментов, и при этом данная идентификация не изменяется с течением времени. Он не зависит от любого поля идентификатора уровня сообщения (MSH); его область действия выходит за рамки отдельного сообщения. Способы выбора уникальных идентификаторов зависят от особенностей конкретных типов объектов, информация о которых передается в повторяющихся сегментах. В ряде случаев, например, при передаче диагнозов, такой идентификатор может иметь тип данных CE. При передаче таких данных, как идентификатор лица, используется тип данных CX. В других случаях он может иметь тип данных EI (идентификатор объекта).

Примечание - Этот режим можно использовать только при передаче новых сегментов, введенных, начиная с версии 2.3 стандарта HL7.

2.10 Местные расширения

В следующих подразделах указано, в каких случаях местные расширения сообщения и его составных частей разрешены, в каких нет и в каких они хотя и возможны, но не рекомендованы. Для местных расширений должны соблюдаться правила совместимости версий, а также некоторые ограничения и запреты, описанные в следующих подразделах. В общем случае базовые структуры не должны подвергаться изменению.

Рекомендуется ознакомиться с механизмом объявления соответствия стандарту, описанному в 2.11 "Объявление соответствия стандарту с помощью профилей сообщений".

2.10.1 Местные расширения сообщений

Местные расширения сообщений могут быть выполнены следующим образом:

a) пользователи могут разработать местные сообщения, используемые в предметной области, еще не покрытой данным стандартом. По возможности они должны состоять из стандартных сегментов HL7;

b) местные сообщения могут целиком состоять из Z-сегментов, только должны начинаться с сегмента заголовка MSH;

c) местное Z-сообщение подтверждения должно начинаться с сегмента MSH, за которым следует сегмент MSA, необязательный сегмент SFT, и условно обязательный сегмент ERR;

d) пользователи могут разрабатывать Z-сегменты и добавлять их к Z-сообщениям;

e) пользователи могут разрабатывать Z-сегменты и добавлять их к стандартным сообщениям HL7. Событие, инициирующее передачу сообщения, может оставаться тем же самым, если назначение сообщения остается не измененным;

f) практика добавления к существующему сообщению HL7 стандартных сегментов HL7, например, NTE, не рекомендуется. В следующих версиях стандарта сегмент может быть перемещен или изменен, и местное расширение может оказаться несовместимым.

2.10.2 Местные события

Пользователи могут разрабатывать местные Z-события, инициирующие передачу сообщений.

2.10.3 Группы сегментов

Местные расширения группы сегментов должны удовлетворять следующим ограничениям:

a) практика местного преобразования сегмента или последовательности сегментов в группу сегментов не разрешена для события, определенного в стандарте. Она может негативно повлиять на кодирование сообщений с использованием языка XML и другие способы кодирования, основанные на использовании компонентов. С другой стороны, Рабочая группа HL7 такие преобразования может выполнять;

b) группа сегментов не может быть разгруппирована для местных целей.

Примеры

1 Пусть в стандарте определена группа вида

Местное преобразование этой группы в последовательность сегментов

недопустима.

2 Пусть исходное определение имеет вид

и в местных целях сегменты группы GROUP2 предполагается сделать обязательными, например, использовать синтаксис вида

Тогда фрагмент экземпляра сообщения, содержащий эти группы, мог бы выглядеть следующим образом:

Было бы ошибкой вместо этого передать фрагмент

c) неповторяющаяся группа сегментов может быть в местных целях сделана повторяющейся. Первый экземпляр группы должен трактоваться так, как это определено стандартом;

d) практика местного включения Z-сегмента в группу сегментов разрешена.

2.10.4 Местные расширения сегментов

2.10.4.1 Правила местного расширения сегментов

Пользователям запрещено модифицировать существующий сегмент, за исключением ситуаций, описанных в 2.7.2.

В местных сегментах могут использоваться местные поля, хотя по возможности лучше использовать поля, определенные в стандарте. Практика расширения стандартного сегмента HL7 местными полями не запрещена, но не рекомендована.

Рабочая группа HL7 также учитывает, что при внедрении стандарта местные поля могут возникать в тех случаях, когда пользователи полагают, что такое расширение может представлять интерес для всего сообщества HL7 и намерены подать соответствующее предложение в Рабочую группу HL7.

2.10.4.2 Предостережения к местным расширениям сегментов

Добавление местных полей к стандартному сегменту чревато проблемами совместимости при появлении следующей редакции стандарта HL7. Однако при некоторых обстоятельствах Рабочая группа HL7 предлагает сообществу добавить Z-поля как промежуточное решение между версиями, позволяющее выполнить требования регулирующих уполномоченных органов. Эти поля Рабочая группа HL7 резервирует для официального включения в следующую редакцию стандарта.

Если какая-то организация намерена добавить поле, предложенное Рабочей группе HL7, до того, как оно будет официально принято, то существует риск, что оно может войти в конфликт с другим полем, когда Рабочая группа HL7 официально примет или отклонит предложенные расширения. Некоторые организации практикуют присвоение местному полю большого номера, оставляя значительный зазор между порядковым номером последнего официально определенного поля и номером местного поля. Во избежание конфликтов между полями такие пользовательские поля должны быть удалены или запрещены, как только Рабочая группа HL7 официально примет или отклонит предложенные расширения. Следует учесть, что при возникновении таких конфликтов местное внедрение должно быть изменено, чтобы обеспечить соответствие стандарту.

2.10.5 Местные расширения типов данных

Местные расширения типов данных должны удовлетворять следующим правилам:

e) местные типы данных могут быть определены для использования в местных полях сегментов, хотя по возможности для местных полей лучше использовать стандартные типы данных;

f) местное переопределение компонентов существующих типов данных, например, изменение типа данных компонента с NM на ST запрещено;

g) при местном расширении типа данных новые компоненты могут быть добавлены в его конце. Такое расширение создает Z-тип данных.

Примечание - Практика расширения стандартных типов данных местными компонентами крайне не рекомендована и может вызывать проблемы соответствия при появлении новой редакции стандарта.

2.10.6 Местные расширения таблиц

Правила местных расширений таблиц те же, что описаны в 2.4.3.6 "Таблица":

a) пользователи могут переопределять рекомендованные значения в пользовательских таблицах;

b) для Z-полей могут использоваться местные таблицы;

c) местные таблицы могут быть указаны для стандартных полей, имеющих тип данных CWE.

2.11 Объявление соответствия стандарту с помощью профилей сообщений

В предыдущих разделах были определены правила и соглашения по составлению и передаче сообщения, используя части его структуры. Сообщения, удовлетворяющие тем правилам, которые описаны в конкретной версии стандарта, являются соответствующими этой версии стандарта.

Исторически было невозможно содержательным образом определить и измерить соответствие стандарту HL7. Для компенсации этого недостатка разработчики и пользователи использовали различные методы описания граничных условий, например, обязательность и кратность. Нередко такие описания мало что давали сверх не всегда строго определенных ограничений, указанных в стандарте HL7.

В настоящем разделе представлена методология составления точной и однозначно трактуемой спецификации, называемой профилем сообщения. Сообщения, удовлетворяющие ограничениям, описанным в профиле сообщения, называют соответствующими этому профилю. Чтобы соответствие можно было измерить, профиль сообщения должен содержать следующие типы информации:

Какие данные будут передаваться в сообщении.

Формат передачи этих данных.

Обязанности отправителя и получателя по подтверждению обработки сообщения.

Заявление о соответствии представляет собой документ, в котором указано, что поведение прикладной программы или ее модуля удовлетворяет ограничениям, описанным в одном или нескольким профилях сообщений. Определение профиля сообщения дано в настоящем разделе. Однако заявление о соответствии в настоящем документе обсуждаться далее не будет.

Определение. Профиль сообщений HL7 представляет собой однозначно трактуемую спецификацию одного или нескольких сообщений, определенных в стандарте HL7, которая проанализирована для конкретного сценария обмена данными. В ней предписан набор точных ограничений, накладываемых на одно или несколько сообщений.

Профиль сообщений HL7 во всех отношениях соответствует определениям, которые даны стандартом для всех сообщений, включенных в этот профиль. Он может давать им более строгие ограничения.

Профиль сообщений полностью описывает обмен сообщениями между двумя или большим числом систем, используя сочетание следующих сущностей:

a) анализ одного сценария обмена сообщениями,

b) одно или несколько динамических определений,

c) одно или несколько статических определений.

Анализ сценария может быть документирован как диаграмма прецедентов (дополненная текстом) или только в виде текста. (См. 2.12.2 "Модель прецедентов".)

Динамическое определение представляет собой спецификацию последовательности обменов данными между двумя или более системами. (См. 2.12.3 "Динамическое определение".)

Статическое определение представляет собой исчерпывающую спецификацию структуры одного сообщения (См. 2.12.4 "Статическое определение"). Если оно представлено нормативным образом как XML-документ, который можно проверить на соответствие нормативной XML-схеме профиля сообщений, то его можно зарегистрировать на веб-сайте HL7. (См. 2.12.9 "Документ профиля сообщений").

Читателю, заинтересованному в получении детальной информации о принципах составления профилей сообщений, положенных в основу настоящего раздела, рекомендуется обратиться к документу "Message Profiling Specification, Version 2.2", который прошел голосование в рабочей группе Conformance и был опубликован 30 ноября 2000 г. Он доступен на веб-сайте ресурсов рабочей группе HL7 Conformance (http://www.hl7.org).

Для иллюстрации частей профиля сообщений и их совместного использования на рисунке 5 показан пример профиля сообщений.

Рисунок 4 - Пример профиля сообщений

2.11.1 Профиль сообщений

Определение. Профиль сообщений HL7 представляет собой однозначно трактуемую спецификацию одного или нескольких сообщений, определенных в стандарте HL7, которая проанализирована для конкретного сценария обмена данными. Каждый профиль сообщений должен иметь уникальный идентификатор и идентификацию рубрик публикации/подписки.

2.11.1.1 Идентификатор профиля сообщений

Для упрощения ссылок каждый профиль сообщений должен иметь уникальный идентификатор.

2.11.1.2 Рубрики публикации/подписки профиля сообщений

Рубрики публикации/подписки профиля сообщений не обязаны быть уникальными. Они могут использоваться системами публикации/подписки для указания некоторых аспектов профиля сообщений (см. описание поля MSH-21 "Идентификатор профиля сообщений" (EI) 01598).

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

Элементы рубрик публикации/подписки профиля сообщений перечислены в таблице 7.

Таблица 7

Элементы рубрик публикации/подписки профиля сообщений

Пример рубрик публикации/подписки профиля сообщений:

2.11.2 Диаграмма прецедентов

Диаграмма прецедентов документирует область применения профиля сообщений или совокупности профилей, а также предъявляемые к ним требования.

Диаграмма прецедентов должна:

a) иметь название, ясно и точно определяющее обмен данными;

b) документировать цель каждого обмена сообщениями;

c) определять действующие лица, включая приложение-отправитель и приложение-получатель;

d) определять события обмена сообщениями между действующими лицами, включая, если это возможно, производные события;

e) документировать ситуации, в которых требуется обмен сообщениями стандарта HL7, описанными в конкретном профиле сообщений.

Дальнейшую информацию о диаграммах прецедентов и их использовании в стандартах HL7 см. в документе HL7 V3.0 Message Development Framework (MDF 99).

2.11.3 Динамическое определение

Динамическое определение представляет собой спецификацию обмена сообщениями между двумя или более системами. Оно может содержать ссылки на одно или несколько статических определений. В дополнение к описанию условий возвращения подтверждений динамическое определение может включать в себя диаграмму взаимодействия.

2.11.3.1 Модель взаимодействия

Модель взаимодействия иллюстрирует последовательность событий обмена данными и соответствующий поток сообщений между двумя и более системами. Она может быть представлена в графической или текстовой форме. В качестве графической формы должны использоваться диаграммы деятельности на языке UML. На рисунках 6 и 7 показаны примеры диаграмм деятельности для исходного и расширенного режима подтверждений.

Рисунок 5 - Пример диаграммы деятельности - ADT^01/ACK^01 (исходный режим подтверждения)

Рисунок 6 - Пример диаграммы деятельности - ADT^A01/ACK^A01 (расширенный режим подтверждения)

2.11.3.2 Подтверждения

В дополнение к статическому определению профиля сообщений HL7 должны быть описаны требуемые или разрешенные специфичные подтверждения сообщений. А именно, в динамическом определении должно быть указано, являются ли подтверждения приема и/или прикладной обработки разрешенными или требуемыми.

Каждое статическое определение может быть дополнено одним или несколькими динамическими определениями.

Динамическое определение должно описывать условия, при которых должно ожидаться подтверждение приема или подтверждение прикладной обработки.

Допускаются следующие условия:

a) всегда,

b) никогда,

c) только при успешной обработке,

d) только при ошибке обработки.

2.11.4 Статическое определение

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

Статическое определение идентифицирует только те специфичные элементы стандартного сообщения HL7, которые используются при обмене данными.

В статическом определении явным образом указаны:

a) правила использования сегментов, групп сегментов, полей и компонентов;

b) кратности;

c) наборы значений и системы кодирования.

На рисунке 8 графическим образом представлена концепция, согласно которой статическое определение накладывается на структуру сообщения HL7 в форме более строгих ограничений. К примеру, если в структуре сообщения HL7 показано неограниченное число сегментов NK1, то статическое определение может разрешать только три экземпляра этого сегмента. Кроме того, поля, которые в структуре сообщения HL7 являются необязательными, могут стать обязательными в статическом определении.

Рисунок 7 - Иллюстрация статического определения

2.11.4.1 Идентификатор статического определения

В целях регистрации каждое статическое определение должно иметь уникальный идентификатор. (См. 2.12.9 "Документ профиля сообщений".) Он может быть присвоен не регистром определений, а другой уполномоченной организацией. Если в момент регистрации статическое определение еще не имеет идентификатора, присвоенного уполномоченной организацией, представляющей определение в регистр, то он будет присвоен уполномоченной организацией, ответственной за ведение регистра. Идентификатор статического определения должен совпадать с тем, который используется, когда система объявляет о строгом соответствии стандарту. (См. описание поля MSH-21 "Идентификатор профиля сообщений" (EI) 01598.)

2.11.4.2 Рубрики публикации/подписки статического определения

Рубрики публикации/подписки статического определения должны отражать аспекты статического определения профиля сообщений. Они могут использоваться системами публикации/подписки. (См. описание поля MSH-21 "Идентификатор профиля сообщений" (EI) 01598.)

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

Элементы рубрик публикации/подписки статического определения перечислены в таблице 8.

Таблица 8

Элементы рубрик публикации/подписки статического определения

Пример рубрик публикации/подписки статического определения:

2.11.5 Тип профиля

При документирования соответствия стандарту используются три основных типа профилей:

a) стандартный профиль HL7 (описывает конкретный опубликованный стандарт HL7, создание и публикация профиля ограничены использованием Рабочей группой HL7);

b) ограничиваемый профиль (включающий в себя необязательные элементы, которые могут быть затем ограничены при конструировании реализуемого профиля);

c) реализуемый профиль (не содержащий необязательных частей, полностью реализуемый).

Эта модель позволяет разработчикам или поставщикам систем публиковать общие профили, из которых могут конструироваться полностью ограниченные реализуемые профили.

В отличие от стандартных профилей HL7, для ролей отправителя и получателя могут конструироваться отдельные ограничиваемые и реализуемые профили.

Как в ограничиваемых, так и реализуемых профилях основное внимание уделяется ожиданиям приложения-отправителя, а на поведение приложения-получателя накладываются минимальные ограничения.

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

2.11.5.1 Профили, ограничиваемые разработчиком

Разработчик может сконструировать профиль сообщения, которому должны соответствовать все разработанные им прикладные программы, но который сам по себе не является реализуемым профилем. Различные прикладные программы могут быть предназначены для разных областей применения и могут сочетаться с программами других разработчиков. Такой профиль может накладывать дополнительные ограничения на требования, сформулированные в стандарте HL7, определяя согласованные табличные значения, правила обязательности компонентов сообщений, допустимые элементы, а также местные расширения. Эти ограничения должны восприниматься всеми взаимодействующими прикладными программами. Однако эти ограничения не обязаны быть полными. Например, в профиле, сконструированном разработчиком, какой-то элемент может быть объявлен необязательным, поскольку в одних сценариях использования он необходим, в других может быть необязательным или условно обязательным, а в третьих вовсе отсутствует. Для отдельных прикладных программ разработчик может использовать профили, которые будут представлять собой дальнейшие ограничения ранее сконструированного, более общего профиля. Такие профили будут описывать специфичную информационную модель и ее элементы. Профиль, предназначенный для конкретной прикладной программы, может все еще оставаться ограничиваемым профилем, поскольку точное содержание соответствующих ему сообщений может зависеть от конфигурационных параметров и настроек. Только в том случае, когда будут учтены все конфигурационные параметры и настройки, можно получить полностью ограниченный "реализуемый" профиль.

2.11.5.2 Профили, ограничиваемые местом применения

Ограничиваемые профили, применяемые в национальном или региональном масштабе, отражают локализацию и ограничения, наложенные местными условиями на соответствующий стандарт. При этом они допускают достаточно большую свободу, и могут использоваться для конструирования более специфичных реализуемых профилей. Можно привести следующие примеры профилей, ограничиваемых местом применения:

a) AS4700.1-2001 Implementation of HL7 v2.3.1 Part 1:Patient Administration (ограничиваемый профиль, сконструированный для применения в Австралии. В него входят сообщения, определенные в главе 3 стандарта HL7 версии 2.3.1);

b) AS/NZS 4700.3-1999 Implementation of HL7 v2.3 Part 3: Electronic messages for exchange of information on Drug Prescription (ограничиваемый профиль, сконструированный для применения в Австралии. В него входят сообщения, определенные в различные главах стандарта HL7 версии 2.3).

2.11.5.3 Реализуемые профили

Реализуемые профили представляют собой нижний уровень спецификации, требуемой для однозначной реализации. Примерами реализуемых профилей могут служить:

a) Adverse Drug Reaction Implementers Specification, 2001, TGA (реализуемый профиль, ограничивающий австралийские стандарты и ограничиваемые профили стандарта HL7 V2.3.1 в проекте Therapeutic Goods Administration ADRAC Messaging Implementation);

b) Diabetes Reporting Implementers Specification, 2001, UNSW (реализуемый профиль, ограничивающий австралийские стандарты и ограничиваемые профили стандарта HL7 V2.3.1 в проекте Diabetes Messaging Implementation университета NSW);

c) специфичная версия прикладной программы, реализующей обработку сообщения в конкретной медицинской информационной системе.

2.11.6 Понятия статического определения

В этом разделе обсуждаются понятия, общие для каждого уровня статического определения (уровни сообщения, сегмента и поля). Для обозначения группы сегментов, сегменты, поля, компонентов и субкомпонентов в нем используется общий термин "элемент".

2.11.6.1 Кратность

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

Существуют два специальных значения кратности. Если минимальное число экземпляров элемента равно 0, то элемент может не включаться в сообщение. В некоторых случаях максимальное значение числа экземпляров не имеет определенного предела. Тогда оно обозначается символом "*". Примеры распространенных спецификаций кратности приведены в таблице 9.

Таблица 9

Примеры спецификаций кратности

2.11.6.2 Использование

Правила использования описывают обстоятельства появления элемента в сообщении. Некоторые элементы всегда должны присутствовать, некоторые элементы - всегда отсутствовать, а другие могут присутствовать только при определенных обстоятельствах.. Для точного указания правил, управляющих присутствием конкретного элемента, используется коды, перечисленные в таблице 10.

Правила использования управляют ожидаемым поведением приложения-отправителя по отношению к определенному элементу и задают некоторые ограничения на обработку этого элемента приложением-получателем. Коды использования расширяют или уточняют коды кратности, определенные в стандарте HL7.

2.11.6.3 Зависимости между обязательностью, определенной в стандарте HL7, и кодами использования, применяемые при объявлении соответствия

Коды использования, указываемые при объявлении соответствия, более специфичны, нежели коды обязательности, определенные в стандарте HL7. В силу требования, что заявления о соответствии должны удовлетворять описанию сообщения HL7, о котором идет речь, существуют ограничения на присвоение кодов использования элементам в зависимости от того, какие коды обязательности присвоены этим элементам в стандарте HL7 (таблица 11).

Таблица 11

Коды обязательности HL7 и коды использования, применяемые при объявлении соответствия

<1> Этот код обязательности впервые появился в версии 2.7. Его значение несколько отличается от значения кода использования ОП, который может быть указан в профиле сообщений.

2.11.6.4 Зависимость между использованием и кратностью

Как кратность, так и использование управляют наличием поля. Следовательно, между этими понятиями существует определенная зависимость. При использовании в профилях сообщений код использование задает дополнительное ограничение кратности, а именно:

a) если код использования равен О (обязательный), то минимальная кратность элемента должна быть большей или равной 1;

b) если код использования не равен О (то есть любой код, отличающийся от "О"), то минимальное значение кратности должно быть равно 0, за исключением следующего условия: если автору профиля требуется указать обстоятельства, при которых элемент не всегда присутствует, но если уж включен в сообщение, то минимальное число экземпляров должно быть больше 1, то это может быть сделано с помощью указания кода использования "Н" и минимальной кратности, равной минимальному числу экземпляров в случае, когда элемент присутствует в сообщении. Это может быть выражено, как в языке UML, в форме (0, m..n), указывая, что допустимое число экземпляров или равно 0, или должно быть в диапазоне от n до m.

Примеры сочетаний кодов использования и кратности приведены в таблице 12.

Таблица 12

Примеры сочетаний кодов использования и кратности

2.11.6.5 Применения понятия использования к иерархическим элементам

Одним из компонентов определения соответствия является дополнительное правило, определяющее, должен ли конкретный "элемент" присутствовать в сообщении. Это правило таково: чтобы элемент мог рассматриваться как присутствующий, он должен иметь содержание. Это означает, что значения простых элементов (полей, компонентов или субкомпонентов, имеющих простые типы данных, например, NM, ST, ID) должны содержать не менее одного символа. Сложные элементы (те, что состоят из других элементов, например, сообщения, группы сегментов, а также поля, имеющие комплексные типы данных, например, CNE, XPN и т.д.) должны содержать по меньшей мере один присутствующий компонент. Элементы, не удовлетворяющие этим условиям, не рассматриваются как присутствующие.

Например, если сегмент состоит из 10 необязательных полей, то сегмент будет считаться присутствующим, если хотя бы одно из этих полей присутствует. Таким образом, если этот сегмент обозначен как обязательный, то экземпляр сообщения будет соответствовать стандарту только в том случае, если этот сегмент содержит хотя бы одно поле. Это правило введено для того, чтобы гарантировать соответствие назначению профиля. Оно обязательно потому, что традиционные правила кодирования сообщений HL7 с использованием разделителей позволяют указать идентификатор сегмента, после которого нет ни одного поля (например, строка "NTE|" будет рассматриваться правильной при традиционных правилах кодирования, но этот сегмент должен считаться отсутствующим при проверке соответствия стандарту). Правила кодирования XML также позволяют аналогичные указания как сегментов, так и полей без компонентов, и компонентов без субкомпонентов, например, <PID.3/>.

2.11.6.6 Предикат условия

Если код использования элемента имеет значение "У" или "УП", то с этим элементом должен быть связан предикат условия, при котором этот элемент должен или может присутствовать. Этот предикат должен быть проверяемым и вычисляться по другим значениям, передаваемым в данном сообщении. Такой предикат может быть представлен в форме математического выражения или в форме текста и может использовать такие операторы, как эквивалентность, логические "И", "ИЛИ" и "НЕ". Как приложение-отправитель, так и приложение-получатель, соответствующие стандарту, должны уметь вычислять этот предикат. Если код использования не равен "У" или "УП", то предикат условия не задается.

2.11.7 Статическое определение - уровень сообщения

Статическое определение уровня сообщения должно документироваться с помощью синтаксиса абстрактного сообщения HL7, в который добавлены указания кратности и использования каждого сегмента, содержащегося в структуре сообщения.

В столбце "Использование" должно быть отражено использование сегмента или группы сегментов в данном конкретном статическом определении.

В столбце "Кратность" должно быть точно указано минимальное и максимальное разрешенное число экземпляров сегмента или группы сегментов в данном конкретном статическом определении.

Пример статического определения на уровне сообщения приведен в таблице 13.

Таблица 13

Пример статического определения на уровне сообщения

2.11.7.1 Определение сегментов

Должен быть определен список сегментов и групп сегментов, включенных в сообщение. Он должен содержать все сегменты или группы сегментов, которые стандарт HL7 объявил в этом сообщении обязательными.

2.11.7.2 Использование сегмента

Использование сегмента или группы сегментов в сообщении должно быть определено с помощью одного из кодов, описанных выше в таблице 10.

2.11.7.3 Кратность сегмента

В сообщении HL7 некоторые сегменты и группы сегментов могут присутствовать в нескольких экземплярах. Должна быть указана кратность всех сегментов и групп сегментов в сообщении.

2.11.8 Статическое определение - уровень сегмента

Статическое определение уровня сегмента должно документироваться, используя формат таблицы атрибутов сегментов HL7, в который добавлены указания длины, кратности и использования каждого поля, содержащегося в структуре сегмента.

В столбце "Длина" должна быть точно указана максимальная разрешенная длина поля в данном определении сегмента.

В столбце "Использование" должно быть отражено использование поля в данном определении сегмента.

В столбце "Кратность" должны быть точно указаны минимальное и максимальное разрешенное число экземпляров поля в данном определении сегмента.

Пример статического определения на уровне сегмента приведен в таблице 14.

Таблица 14

Пример статического определения на уровне сегмента (сегмент идентификации пациента PID)

Должен быть указан список полей каждого сегмента, содержащегося в определении на уровне сообщения.

Если сегмент входит в профиль сообщения несколько раз, то для каждого вхождения может сконструирован собственный профиль сегмента. Это должно быть явно указано в определении на уровне сообщения.

2.11.8.2 Кратность поля

Некоторые поля могут входить в сегмент в нескольких экземплярах. Должна быть определена кратность каждого поля сегмента.

2.11.8.3 Использование поля

Использование поля в сегменте должно быть определено в соответствии с типом профиля, задавая один из кодов, указанных в таблице 10.

2.11.8.4 Тип данных

Столбец типа данных должен точно отражать тип данных, присвоенный этому полю в определении сегмента.

2.11.8.5 Длина

Столбец длины должен точно отражать правильную длину поля в этом определении сегмента.

2.11.8.6 Ссылка на таблицу

В столбце номера таблицы должен быть точно указан номер таблицы, из которой должны быть взяты значения этого поля в данном определении сегмента.

2.11.9 Статическое определение. Уровень поля

2.11.9.1 Определения полей

Каждому отдельному полю сегмента должно быть дано полное определение, исключающее любую возможную неоднозначность.

В случаях, когда определение поля в стандарте HL7 2.x не является достаточным, должно быть указано точное семантическое определение.

2.11.9.2 Пользовательские и рекомендуемые значения поля

Разрешенные (табличные) значения многих полей в стандарте HL7 указаны как пользовательские (тип данных IS) или стандартные (тип данных ID). Описание правил, управляющих различными таблицами значений, см. в 2.4.3.6 "Таблица".

Для такого поля должен быть указан точный набор допустимых значений. Эти значения должны быть определены в соответствии с областью применения профиля сообщений, заданной разработчиком или поставщиком, либо местом применения профиля.

Значения полей с кодированными значениями (CE, CF, CWE и CNE) должны браться из систем кодирования. В профиле для каждого такого поля должны быть указаны конкретные системы кодирования. Совместимые прикладные программы должны использовать заданную систему кодирования, но могут также использовать альтернативную систему кодирования, если таковая допустима для этого типа данных (см. пример в определении каждого типа данных).

2.11.9.3 Константы

Если значением элемента всегда является константа, это должно быть указано. Константы можно задавать только для элементов, имеющих примитивные типы данных, то есть тех, у которых нет компонентов или субкомпонентов.

2.11.9.4 Значения данных

Может быть указан список примеров значений данных элемента. Значения данных можно приводить только для элементов, имеющих примитивные типы данных, то есть тех, у которых нет компонентов или субкомпонентов.

2.11.9.5 Компоненты и субкомпоненты

До версии HL7 2.5 многие поля и компоненты имели тип данных CM (составное поле). Начиная с версии 2.5, всем экземплярам поля назначаются действующие типы данных, отличающиеся от CM. К версиям 2.3.1 и 2.4 были выпущены дополнения, в которых для полей типа CM даны альтернативные определения типов данных. Это позволяет указывать более точные имена всех таких полей при XML-кодировании экземпляров сообщений. Хотя конструирование профилей сообщений не ограничено конкретной версий стандарта HL7, настоятельно рекомендуется использовать эти новые типы данных, чтобы улучшить интероперабельность версий.

Для каждого компонента составного поля должен быть составлен профиль. Это требует указания кода использования, ограничений длины, типа данных и значений данных каждого компонента. Если у компонента есть субкомпоненты, то для каждого субкомпонента должен быть составлен аналогичный профиль. За исключением кратности, правила составления совпадают с теми, что предложены для полей (См. 2.11.8 "Статическое определение - уровень сегмента").

2.11.10 Документ профиля сообщения

Головной офис Рабочей группы HL7 представит служебную программу, далее называемую регистром, в разделе своего сайта, предназначенном только для членов комитета (Members' Only) (http://www.hl7.org), где можно будет зарегистрировать профиль сообщения.

Все зарегистрированные профили сообщений каталогизированы с помощью набора метаданных. Организации, передающие профили в регистр, должны заполнить форму, которая собирает требуемые метаданные. Регистр и метаданные документированы в справочном документе и ниже более не обсуждаются.

2.11.10.1 Формат документа профиля сообщения

Рабочая группа Conformance нашла наилучший подход к стандартизации формата профиля сообщения, обеспечивающему возможность сравнения и оценки степени соответствия. Таким форматом были признаны документы на языке XML (eXtensible Markup Language XML W3C XML 1.0 2nd Ed).

Использование языка XML для этих целей никак не связано со спецификацией кодирования экземпляров сообщений стандарта HL7 версии 2.x на языке XML. Формат документа профиля сообщения предусматривает только структуру документирования профиля сообщения и никак не ограничивает способ кодирования конкретных экземпляров сообщений.

2.11.10.2 Определение документа профиля сообщения

Документ профиля сообщений считается действительным профилем сообщений HL7, если он удовлетворяет ограничениям, указанным в определении документа профиля сообщения (см. 2.19 "Определение документа профиля сообщения"), а также дополнительным правилам, описанным в настоящем документе.

2.11.11 Инструментальные средства

Инструментальные средства, используемые для создания, общего использования, повторного использования, подготовки отчетов, анализа и сравнения профилей сообщений, не входят в область применения стандарта HL7. На веб-сайте рабочей группы Conformance можно найти ссылки, полезные для расширения интереса к профилям сообщений и рабочей группе Conformance, а также к поддержке этого направления.

2.12 Структура функциональных разделов, определяющих сообщения стандарта HL7

В следующих разделах первого уровня описаны сообщения, которыми приложения обмениваются в функционально специфических ситуациях. Каждый такой функциональный раздел организован следующим образом:

a) назначение. Приводятся описание назначения раздела, общая информация и понятия;

b) события и сообщения. Приводится перечень событий, требующих реакции;

c) сегменты сообщений. Определенные в разделе сегменты перечисляются в функциональном порядке, обеспечивающем максимальную концептуальную ясность;

d) примеры. Включены примеры полных сообщений;

e) обсуждение реализации. В этой части функциональных разделов дается дополнительная специальная информация. Она включает моменты, которые необходимо учесть при планировании реализации этой части стандарта;

f) актуальные вопросы. Здесь приводятся вопросы, находящиеся в стадии изучения или требующие изучения.

2.12.1 Представление сообщения

Для каждого события, требующего реакции, приводятся определения сообщений, которыми системы обмениваются при наступлении события. В этих определениях используется описанный ниже синтаксис абстрактных сообщений HL7.

Каждое сообщение определяется в специальной нотации, согласно которой идентификаторы сегментов перечисляются в том порядке, в котором они могут появиться в сообщении. Фигурные скобки {...} означают одно или несколько повторений группы сегментов, которая заключена в эти скобки. (Конечно, группа может состоять из единственного сегмента.) Квадратные скобки [...] указывают, что заключенная в них группа сегментов является необязательной. Если группа сегментов может повторяться и является необязательной, то она должна быть заключена как в квадратные скобки, так и в фигурные, [{...}].

Примечание - Записи [{...}] и {[...]} эквивалентны.

Если фигурные или квадратные скобки содержат более одного идентификатора сегмента, то используется специальное стилистическое соглашение, облегчающее читателю понимание иерархии повторов. Например, первый идентификатор сегмента появляется в той же строке, что и фигурные скобки, со сдвигом на две позиции вправо. Следующие идентификаторы сегментов появляются строго под первым. Закрывающая фигурная скобка появляется в отдельной строке строго под открывающей скобкой. Это соглашение не является обязательным и используется исключительно для удобства читателя. Если возникает конфликт между этим соглашением и фигурными скобками, которые появляются в схеме сообщения, то фигурные скобки задают фактическую допустимую группировку сегментов.

Выбор одного сегмента из группы сегментов обозначается, используя угловые скобки, в которые заключается группа, и разделители (вертикальная черта) между отдельными сегментами.

Например, в сообщении ORMA^O01, описанном в подразделе 4.4.1 функционального раздела 4, допускается выбор одного из нескольких сегментов деталей заказа. Этот выбор может быть представлен следующим образом:

Рассмотрим гипотетическое событие "запрос отчета по воздушным замкам". Оно может обслуживаться двумя сообщениями - сообщением запроса отчета по воздушным замкам с именем WRQ (Widget Request) и ответным сообщением с именем WRP (Widget Report), содержащем отчет о результатах запроса. Эти сообщения должны быть определены в функциональном разделе, посвященной воздушным замкам (например, в разделе XX). Сообщение WRQ может состоять из следующих сегментов: заголовка сообщения MSH (Message Header), сегмента программного обеспечения SFT (Software) и сегмента идентификации замка WID (Widget ID). Сообщение WRP может состоять из следующих сегментов: заголовка сообщения MSH, сегмента программного обеспечения SFT, сегмента подтверждения сообщения MSA (Message Acknowledgement), сегмента ошибок ERR (Error) и одного или нескольких сегментов WDN (Widget Description) с общим описанием воздушного замка, каждый из которых дополняется одним сегментом WPN (Widget Portion) с описанием интерьера замка, за которым следует несколько (возможно, ни одного) сегментов WPD (Widget Portion Detail) с описанием деталей интерьера.

2.12.2 Пример синтаксиса абстрактного сообщения стандарта HL7

Схематическая форма описанного выше обмена сообщениями показана на рисунке 9.

Рисунок 8 - Гипотетическое схематичное сообщение

Как показывает номер XX в правом столбце, сегменты WID, WDN, WPN и WPD должны были быть определены комитетом по воздушным замкам в функциональной разделе XX. Сегменты MSH и MSA включены в сообщения о воздушных замках, но определены в другом разделе. Они будут упоминаться по ссылке в функциональном разделе XX по воздушным замкам.

Комитет по воздушным замкам мог принять иное решение по структуре сообщения, например, постановить, что сегменты WPN и WPD должны всегда появляться вместе, но эти пары сегментов являются необязательными и могут повторяться. Новая схема сообщения показана на рисунке 10.

Рисунок 9 - Сегменты WPN и WPD в парах

Если же комитет по воздушным замкам решил, что за сегментом WDN должна следовать хотя бы одна пара сегментов WPN и WPD, то схема сообщения примет вид, показанный на рисунке 11.

Рисунок 10 - По крайней мере одна пара сегментов WPN и WPD

2.13 Сообщения подтверждения

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

2.13.1 Сообщение ACK. Общее подтверждение

Простое общее подтверждение (АСК) может быть использовано в тех случаях, когда при прикладной обработке нет необходимости в специальном подтверждении прикладной обработки либо когда возникает ошибка, препятствующая началу прикладной обработки. Оно может также использоваться для подтверждения приема сообщения. Дополнительные сведения приведены в 2.8 "Правила обработки сообщений".

Примечание - В сегменте заголовка сообщения общего подтверждения АСК значение компонента MSH-9-2 "Тип события" должно совпадать со значением компонента MSH-9-2 "Тип события", указанного в сегменте заголовка подтверждаемого сообщения. Компонент MSH-9-2 "Структура сообщения" всегда должен иметь значение "АСК".

2.13.2 Сообщение MCF. Отложенное подтверждение

Примечание - Сообщение MCF было запрещено в версии 2.2 и его определение удалено из всех версий стандарта, начиная с 2.5.

2.14 Управляющие сегменты сообщений

Для обеспечения выполнения функций, описанных в этом разделе, требуются описанные ниже управляющие сегменты.

Примечание - Правила составления сообщений HL7 определяют представление сообщений стандарта в форме строк переменной длины с разделителями. Хотя в версии 2.3 стандарта HL7 определен только один свод правил кодирования, тем не менее допускаются и другие правила кодирования (не будучи включенными в стандарт, они могут использоваться только на основе местных соглашений).

В настоящем разделе сегменты перечислены в алфавитном порядке. В таблице 15 список сегментов упорядочен по категориям.

Таблица 15

Сегменты сообщений HL7

2.14.1 Сегмент ADD "Дополнение"

Сегмент ADD используется для идентификации продолжения предшествующего ему сегмента в продолжающемся сообщении. Детали его использования описаны в 2.9.2.1.

Таблица 16

Атрибуты сегмента ADD "Дополнение"

Определение полей сегмента ADD

2.14.1.1 ADD-1 "Указатель продолжения сегмента" (ST) 00066

Это используется для идентификации продолжения предшествующего сегмента в продолжающемся сообщении. Детальные сведения см. в 2.9.2 "Продолжение сообщений и сегментов". Когда сегмент ADD передается после сегмента, который будет иметь продолжение, то он не содержит полей. Он является только признаком того, что предшествующий ему сегмент будет продолжен в следующем сообщении. Таким образом, в этом сегменте отсутствует от 1 до N полей. Значение указателя (1-N) указывает на остаток полей продолжающегося сегмента. Этот остаток присутствует только в том случае, когда сегмент ADD передается в продолжении сообщения.

2.14.2 Сегмент BHS "Заголовок пакета"

Сегмент BHS используется как заголовок пакета сообщений.

Таблица 17

Атрибуты сегмента BHS "Заголовок пакета"

Определение полей сегмента BHS

2.14.2.1 BHS-1 "Разделитель полей пакета" (ST) 00081

Это поле содержит разделитель между идентификатором сегмента и первым настоящим полем, BHS-2 "Символы кодирования". Оно служит разделителем и задает символ, который будет использован в качестве разделителя полей в остальной части сообщения. Рекомендованный разделитель - символ "|" (ASCII-код 124).

2.14.2.2 BHS-2 "Символы кодирования" (ST) 00082

Это поле содержит четыре символа в следующее порядке: разделитель компонентов, разделитель повтора, спецсимвол (escape) и разделитель субкомпонентов. Рекомендованное значение: "^~&" (карат, тильда, косая черта и знак Ампера; соответственно ASCII-коды 94, 126, 92 и 38). См. 2.4.4 "Разделители сообщения".

2.14.2.3 BHS-3 "Приложение-отправитель пакета" (HD) 00083

Компоненты: идентификатор из пространства имен (IS)> ^ <универсальный идентификатор (ST)> ^ <тип универсального идентификатора (ID)>

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

2.14.2.4 BHS-4 "Учреждение-отправитель пакета" (HD) 00084

Компоненты: идентификатор из пространства имен (IS)> ^ <универсальный идентификатор (ST)> ^ <тип универсального идентификатора (ID)>

Это поле однозначно идентифицирует данное приложение-отправитель среди нескольких одноименных экземпляров, исполняемых в различных учреждениях или ведомствах. Наряду с другими вариантами во второй компонент поля можно помещать идентификатор организации здравоохранения, присваиваемый (в США) системой Medicare (Medicare Provider ID). Полностью зависит от местной реализации.

2.14.2.5 BHS-5 "Приложение-получатель пакета" (HD) 0085

Компоненты: <идентификатор из пространства имен (IS)> ^ <универсальный идентификатор (ST)> ^ <тип универсального идентификатора (ID)>

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

2.14.2.6 BHS-6 "Учреждение-получатель пакета" (HD) 00086

Компоненты: <идентификатор из пространства имен (IS)> ^ <универсальный идентификатор (ST)> ^ <тип универсального идентификатора (ID)>

Это поле однозначно идентифицирует данное приложение-отправитель среди нескольких одноименных экземпляров, исполняемых в различных учреждениях или ведомствах. См. комментарий к полю BHS-4 "Учреждение-отправитель пакета". Полностью зависит от местной реализации.

2.14.2.7 BHS-7 "Дата и время создания пакета" (TS) 00087

Компоненты: <время (DTM)> ^ <ЗАПРЕЩЕНА: степень точности (ID)>

Задает дату и время создания сообщения системой-отправителем. Если в этом поле указан часовой пояс, то он может быть использован как часовой пояс по умолчанию для остальной части сообщения.

2.14.2.8 BHS-8 "Защита пакета" (ST) 00088

В некоторых приложениях стандарта HL7 это поле используется для обеспечения защиты данных. В настоящее время его использование более детально не определено.

2.14.2.9 BHS-9 "Имя/тип пакета" (ST) 00089

Это поле может быть использовано приложением, обрабатывающим этот пакет. При необходимости оно может иметь дополнительные компоненты.

Примечание - Упоминание "дополнительных компонентов" оставлено только для обратной совместимости, в текущей версии тип данных ST не может иметь такие компоненты.

2.14.2.10 BHS-10 "Комментарий к заголовку пакета" (ST) 00090

Свободный текст, использование которого в стандарте не определяется.

2.14.2.11 BHS-11 "Идентификатор пакета" (ST) 00091

Это поле используется для однозначной идентификации данного пакета. Если требуется передать ответный пакет, то значение этого поля может возвращаться обратно в поле BHS-12 "Ссылка на идентификатор пакета".

2.14.2.12 BHS-12 "Ссылка на идентификатор пакета" (ST) 00092

Это поле содержит значение поля BHS-11 "Идентификатор пакета", взятое из первой передачи этого пакета. Если данная передача пакета - первая, то поле ссылки на идентификатор должно отсутствовать. См. определение поля BHS-11 "Идентификатор пакета".

2.14.3 Сегмент BTS "Конец пакета"

Сегмент BTS задает конец пакета.

Таблица 18

Атрибуты сегмента BTS "Конец пакета"

Определение полей сегмента BTS

2.14.3.1 BTS-1 "Счетчик числа сообщений в пакете" (ST) 00093

Число сообщений, содержащихся в данном пакете.

2.14.3.2 BTS-2 "Комментарий к концу пакета" (ST) 00090

Поле комментария, детали которого в протоколе HL7 не определяются.

2.14.3.3 BTS-3 "Итоговые суммы пакета" (NM) 00095

Новые пользователи этого поля могут использовать тип данных NM и возможность повторения этого поля, впервые введенные в стандарте HL7 версии 2.3. Это поле содержит итоговую сумму. Если для пакета подсчитывается несколько итоговых сумм, это поле может повторяться.

До версии 2.5 это поле могло иметь тип данных CM для обратной совместимости с версиями 2.1 и 2.2, в которых каждая итоговая сумма представляет собой отдельный компонент. В этом случае каждый компонент должен иметь тип данных NM.

2.14.4 Сегмент DSC "Указатель продолжения"

Сегмент DSC используется в протоколе продолжения.

Таблица 19

Атрибуты сегмента DSC "Указатель продолжения"

Определение полей сегмента DSC

2.14.4.1 DSC-1 "Указатель продолжения сообщения" (ST) 00014

Это поле содержит указатель продолжения сообщения. В первом запросе это поле отсутствует. Если реагирующая система возвращает в нем пустое значение или это поле отсутствует, то это означает, что для последующих продолжений запроса данных больше нет. Использование указателя продолжения при передаче прямых сообщений см. в разделах 5 и 2.9.2 "Продолжение сообщений и сегментов". Обратите внимание, что протоколы продолжения работают как с дисплейными сообщениями, так и с сообщениями в формате записи.

2.14.4.2 DSC-2 "Способ продолжения сообщения" (ID) 01354

Это поле указывает, используется ли сегмент при фрагментации сообщения или как часть продолжающегося диалогового сообщения. (См. 5.6.3 "Диалоговое продолжение ответных сообщений".)

Допустимые значения см. в таблице HL7 0398 "Код типа продолжения".

Таблица HL7 0398

Код типа продолжения

2.14.5 Сегмент ERR "Ошибка"

Сегмент ошибки ERR используется для добавления к подтверждению сообщения комментария по поводу возникшей ошибки.

Варианты использования:

a) категорирование ошибок - приложение-получатель создает два сообщения, одно об ошибке, другое с предупреждением, и передает их. Приложение выдает оба сообщения на экран с пометкой о категории ошибки;

b) кодирование ошибок прикладной обработки - приложение-получатель обнаруживает ошибку прикладной обработки, идентифицируемую определенным кодом, и возвращает эту информацию в ответном сообщении. Этот код используется службой технической поддержки для выявления точной причины ошибки, либо приложением, которое запрашивает необходимую реакцию у пользователя (например, дата смерти должна быть более поздней или равной дате рождения);

c) параметризация ошибок прикладной обработки: приложение-получатель обнаруживает ошибку при выполнении транзакции. Оно может дополнить код ошибки параметром, который дает более точную информацию о природе ошибки. Затем оно выбирает сообщение, соответствующее коду ошибки, подставляет в него параметр и выдает полученное сообщение пользователю;

d) диагностическая информация - приложение-получатель генерирует исключение при выполнении транзакции. При этом создается значительный объем информации о месте и причине обнаруженной ошибки. Приложение-получатель перехватывает исключение и посылает сопутствующую ему информацию в своем ответе. Пользователь сообщает об ошибке службе технической поддержки и по ее запросу посылает факс с копией диагностической информации, облегчающей анализ возникшей проблемы;

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

f) кодирование персональной информации - после отправки транзакции отпуска лекарства пользователю возвращается сообщение, указывающее, что пациент может оказаться наркоманом. Учитывая чувствительность этой информации, возвращается код ошибки вместе с признаком, что пациент не должен быть информирован об ошибке и что надо либо оказаться от требования отпуска лекарства, либо подтвердить его;

g) тип исключения - если правила отпуска лекарств гласят, что по отложенному рецепту нельзя сделать отпуск, то для отпуска лекарства в порядке исключения тип исключения может иметь значение "Отпустить лекарство по отложенному рецепту";

h) коды причины исключения - пациенту отпущено лекарство, но часть таблеток испортилась до завершения курса лечения. Пациент возвращается в аптеку и объясняет ситуацию провизору. Провизор принимает решение о замене испорченных таблеток, однако при попытке провести транзакцию получает сообщение о превышении максимально допустимой общей дозы прописанного лекарства. Провизор проводит транзакцию в порядке исключения и указывает код причины исключения, указывающий, что происходит замена утраченного лекарства;

i) контакт со службой технической поддержки - контактная информация службы технической поддержки хранится в базе данных. При обнаружении ошибки приложение выполняет запрос к этой базе данных и возвращает в сообщении об ошибке актуальную контактную информацию службы технической поддержки. Это сообщение выводится на экран для информирования пользователя;

j) улучшенная локализация ошибки - система-получатель обнаружила ошибку в третьем экземпляре элемента ROL.4(Действующее лицо - XCN).16(Контекст ФИО - CE).4(Альтернативный идентификатор - IS). Чтобы облегчить диагностику проблемы, приложение возвращает в сообщении об ошибке идентификацию конкретного повторение поля и компонента, при обработке которых возникла ошибка;

k) локализация множественных ошибок - два поля сообщения определены как условно обязательные. Условие состоит в том, что одно из них должно быть указано. Приложение-отправитель не заполнило оба этих поля. Приложение-получатель выявляет ошибку и возвращает сообщение об ошибке, в котором указано, что одно из полей должно быть заполнено. При этом в сегменте ERR указаны ссылки на оба поля сообщения, с которыми связана эта ошибка.

Атрибуты сегмента ERR описаны в таблице 20.

Таблица 20

Атрибуты сегмента ERR "Ошибка"

Определение поля сегмента ERR

2.14.5.1 ERR-1 "Код и место ошибки" (ELD) 00024

Компоненты: <идентификатор сегмента (ST)> ^ <порядковый номер сегмента (NM)> ^ <позиция поля (NM)> ^ <код, идентифицирующий ошибку (CE)>

Субкомпоненты кода, идентифицирующего ошибку (CE): <идентификатор (ST)> & <текст (ST)> & <наименование системы кодирования (ID)> & <альтернативный идентификатор (ST)> & <альтернативный текст (ST)> & <наименование альтернативной системы кодирования (ID)>

Это поле идентифицирует ошибочный сегмент другого сообщения. Начиная с версии 2.5, оно оставлено только для обратной совместимости. Используйте вместо него поля ERR-2 и ERR-3.

Допустимые значения кодов ошибки см. в таблице HL7 0357 "Код ошибки обработки сообщения".

2.14.5.2 ERR-2 "Место ошибки" (ERL) 01812

Компоненты: <идентификатор сегмента (ST)> ^ <порядковый номер сегмента (NM)> ^ <номер поля (NM)> ^ <экземпляр поля (NM)> ^ <номер компонента (NM)> ^ <номер субкомпонента (NM)>

Это поле идентифицирует место сообщения, связанное с обнаруженной ошибкой, предупреждением или комментарием. Если это поле присутствует в нескольких экземплярах, то ошибка возникла в связи с сочетанием элементов данных, расположенных в разных местах сообщения.

2.14.5.3 ERR-3 "Код ошибки HL7" (CWE) 01813

Компоненты: <идентификатор (ST)> ^ <текст (ST)> ^ <наименование системы кодирования (ID)> ^ <альтернативный идентификатор (ST)> ^ <альтернативный текст (ST)> ^ <наименование альтернативной системы кодирования (ID)> ^ <версия системы кодирования (ST)> ^ <версия альтернативной системы кодирования (ST)> ^ <исходный текст (ST)>

Это поле идентифицирует код (коммуникационной) ошибки HL7. Допустимые значения кодов ошибки см. в таблице HL7 0357 "Код ошибки обработки сообщения".

Таблица HL7 0357

Код ошибки обработки сообщения

2.14.5.4 ERR-4 "Уровень серьезности ошибки" (ID) 01814

Это поле идентифицирует уровень серьезности ошибки приложения. Знание того, является информация сообщением об ошибке, предупреждением или комментарием, важно для понимания того, как приложение обработало содержание сообщения. Допустимые значения уровней серьезности ошибки см. в таблице HL7 0516 "Уровень серьезности ошибки". Если в поле ERR-3 передано значение "0", то в поле ERR-4 должно быть передано значение "I".

Пример предупреждения - может быть возвращено предупреждение о том, что сообщение содержало сегменты комментариев, которые были игнорированы, поскольку не могли быть обработаны автоматически. Таким образом, часть переданных данных оказалась невостребованной.

Пример комментариев - при обработке счета на оплату лечения плательщик может указать, что оставшееся страховое покрытие ниже лимита.

Таблица HL7 0516

Уровень серьезности ошибки

2.14.5.5 ERR-5 "Код ошибки приложения" (CWE) 01815

Компоненты: <идентификатор (ST)> ^ <текст (ST)> ^ <наименование системы кодирования (ID)> ^ <альтернативный идентификатор (ST)> ^ <альтернативный текст (ST)> ^ <наименование альтернативной системы кодирования (ID)>)> ^ <версия системы кодирования (ST)> ^ <версия альтернативной системы кодирования (ST)> ^ <исходный текст (ST)>

Это поле идентифицирует код специфичной ошибки приложения. Допустимые значения кодов ошибки см. в пользовательской таблице 0533 "Код ошибки приложения".

Если текст сообщения об ошибке имеет параметры, то рекомендуется записывать его в формате java.text.MessageFormat. Этот формат предусматривает информацию о типе параметра, что позволяет представлять числа, даты и время в соответствии с местными требованиями.

Пользовательская таблица 0533

Код ошибки приложения

2.14.5.6 ERR-6 "Параметр ошибки приложения" (ST) 01816

Это поле содержит дополнительную информацию, которая может быть использована вместе с кодом ошибки приложения в целях уточнения конкретной причины ошибки, предупреждения или комментариев. Это поле может повторяться до 10 раз.

Например, если код ошибки приложения, указанный в поле ERR-5, соответствует тексту "В периоде до {0, date, medium} у пациента остались вычеты на сумму {1, number, currency}", и первые два экземпляра поля ERR-6 содержат значения "20121231" и "2500" соответственно, то в России приложение-получатель должно вывести сообщение "В период до 31 декабря 2002 г. у пациента остались вычеты на сумму 2500 р.".

2.14.5.7 ERR-7 "Диагностическая информация" (TX) 01817

Это поле содержит информацию, которая может быть использована службой технической поддержки или иным персоналом для диагностики возникшей проблемы.

2.14.5.8 ERR-8 "Пользовательское сообщение" (TX) 01818

Это поле содержит текст, который должен быть изображен пользователю приложения, например

Этот текст отличается от фактического значения кода ошибки и может содержать дополнительную диагностическую информацию.

2.14.5.9 ERR-9 "Признак информирования лица" (IS) 01819

Это поле указывает, кого информировать об ошибке (если это необходимо). В этом поле также можно указать, что кого-то не надо информировать об ошибке (например, "Не информировать пациента"). Допустимые значения см. в пользовательской таблице 0517 "Код информирования лица".

Пользовательская таблица 0517

Код информирования лица

2.14.5.10 ERR-10 "Тип исключения из правил" (CWE) 01820

Компоненты: <идентификатор (ST)> ^ <текст (ST)> ^ <наименование системы кодирования (ID)> ^ <альтернативный идентификатор (ST)> ^ <альтернативный текст (ST)> ^ <наименование альтернативной системы кодирования (ID)> ^ <версия системы кодирования (ST)> ^ <версия альтернативной системы кодирования (ST)> ^ <исходный текст (ST)>

Это поле указывает тип исключения из правил, которое может быть применено для преодоления возникшей ошибки.

Допустимые значения см. в пользовательской таблице 0518 "Тип исключения из правил".

Пользовательская таблица 0518

Тип исключения из правил

2.14.5.11 ERR-11 "Код причины исключения из правил" (CWE) 01821

Компоненты: <идентификатор (ST)> ^ <текст (ST)> ^ <наименование системы кодирования (ID)> ^ <альтернативный идентификатор (ST)> ^ <альтернативный текст (ST)> ^ <наименование альтернативной системы кодирования (ID)> ^ <версия системы кодирования (ST)> ^ <версия альтернативной системы кодирования (ST)> ^ <исходный текст (ST)>

Это поле указывает код возможной причины, побуждающей преодолеть правило, из-за нарушения которого была выдана ошибка.

Допустимые значения см. в пользовательской таблице 0519 "Код причины исключения из правил".

Пользовательская таблица 0519

Код причины исключения из правил

2.14.5.12 ERR-12 "Контактная информация службы технической поддержки" (XTN) 01822

Компоненты: <ЗАПРЕЩЕН-номер телефона (ST)> ^ <код использования телекоммуникаций (ID)> ^ <тип телекоммуникационного оборудования (ID)> ^ <адрес электронной почты (ST)> ^ <код страны (NM)> ^ <код района/города (NM)> ^ <номер телефона (NM)> ^ <дополнительный номер (NM)> ^ <неформатированный номер телефона (ST)>

Это поле указывает номер телефона, факса, адрес электронной почты или иной телекоммуникационный адрес службы технической поддержки.

2.14.6 Сегмент FHS "Заголовок файла"

Сегмент FHS используется как заголовок файла (группы пакетов сообщений) в соответствии с описанием, приведенным в 2.9.3 "Протокол пакетной обработки сообщений стандарта HL7".

Таблица 21

Атрибуты сегмента FHS "Заголовок файла"

Определение полей сегмента FHS

2.14.6.1 FHS-1 "Разделитель полей файла" (ST) 00067

Имеет то же определение, что и соответствующее поле в сегменте заголовка сообщения MSH.

2.14.6.2 FHS-2 "Символы кодирования" (ST) 00068

Имеет то же определение, что и соответствующее поле в сегменте заголовка сообщения MSH.

2.14.6.3 FHS-3 "Приложение-отправитель файла" (HD) 00069

Компоненты: <идентификатор из пространства имен (IS)> ^ <универсальный идентификатор (ST)> ^ <тип универсального идентификатора (ID)>

Имеет то же определение, что и соответствующее поле в сегменте заголовка сообщения MSH.

2.14.6.4 FHS-4 "Учреждение-отправитель файла" (HD) 00070

Компоненты: <идентификатор из пространства имен (IS)> ^ <универсальный идентификатор (ST)> ^ <тип универсального идентификатора (ID)>

Имеет то же определение, что и соответствующее поле в сегменте заголовка сообщения MSH.

2.14.6.5 FHS-5 "Приложение-получатель файла" (HD) 00071

Компоненты: <идентификатор из пространства имен (IS)> ^ <универсальный идентификатор (ST)> ^ <тип универсального идентификатора (ID)>

Имеет то же определение, что и соответствующее поле в сегменте заголовка сообщения MSH.

2.14.6.6 FHS-6 "Учреждение-получатель файла" (HD) 00072

Компоненты: <идентификатор из пространства имен (IS)> ^ <универсальный идентификатор (ST)> ^ <тип универсального идентификатора (ID)>

Имеет то же определение, что и соответствующее поле в сегменте заголовка сообщения MSH.

2.14.6.7 FHS-7 "Дата и время создания файла" (TS) 00073

Компоненты: <время (DTM)> ^ <ЗАПРЕЩЕНА: степень точности (ID)>

Имеет то же определение, что и соответствующее поле в сегменте заголовка сообщения MSH.

2.14.6.8 FHS-8 "Защита файла" (ST) 00074

Имеет то же определение, что и соответствующее поле в сегменте заголовка сообщения MSH.

2.14.6.9 FHS-9 "Имя файла" (ST) 00075

Может быть использовано приложением, обрабатывающим этот файл. Никакие детали этого использования в стандарте не определяются.

2.14.6.10 FHS-10 "Комментарий к заголовку файла" (ST) 00076

Свободный текст, использование которого в стандарте не определяется.

2.14.6.11 FHS-11 "Идентификатор файла" (ST) 00077

Используется для однозначной идентификации данного файла. Может возвращаться обратно в поле FHS-12 "Ссылка на идентификатор файла".

2.14.6.12 FHS-12 "Ссылка на идентификатор файла" ID (ST) 00078

Значение поля FHS-11-идентификатор файла, взятое из первой передачи этого файла. Если данная передача файла - первая, то поле ссылки на идентификатор должно отсутствовать.

2.14.7 Сегмент FTS "Конец файла"

Сегмент FTS задает конец файла.

Таблица 22

Атрибуты сегмента FTS "Конец файла"

Определения полей сегмента FTS

2.14.7.1 FTS-1 "Счетчик числа пакетов в файле" (NM) 00079

Указывает число пакетов, содержащихся в данном файле.

2.14.7.2 FTS-2 "Комментарий к концу файла" (ST) 00080

Свободный текст, использование которого в стандарте не определяется.

2.14.8 Сегмент MSA "Подтверждение сообщения"

Сегмент подтверждения сообщения MSA содержит информацию, передаваемую при подтверждении другого сообщения.

Таблица 23

Атрибуты сегмента MSA "Подтверждение сообщения"

Определения полей сегмента MSA

2.14.8.1 MSA-1 "Код подтверждения" (ID) 00018

Это поле содержит код подтверждения, обрабатываемый в соответствии правилами, изложенными в 2.8 "Правила обработки сообщений". Допустимые значения см. в таблице HL7 0008 "Код подтверждения".

Таблица HL7 0008

Код подтверждения

2.14.8.2 MSA-2 "Идентификатор сообщения" (ST) 00010

Идентификатор сообщения, переданного системой-отправителем. Он позволяет последней связать ее ответ с тем сообщением, на которое он дается.

2.14.8.3 MSA-3 "Текст сообщения об ошибке" (ST) 00020

Необязательное текстовое поле, содержащее дальнейшее описание причины ошибки. Оно может быть распечатано в журнале ошибок либо представлено конечному пользователю.

Поле MSA-3 запрещено, начиная с версии 2.4. Для этой информации должен использоваться сегмент ERR, в котором предусмотрены более богатые возможности описания ошибки.

2.14.8.4 MSA-4 "Ожидаемый порядковый номер" (NM) 00021

Необязательное числовое поле, используемое в протоколе последовательной нумерации сообщений.

2.14.8.5 MSA-5 "Тип отложенного подтверждения" (ID) 00022

Предупреждение. Это поле было запрещено в версии 2.2 и детали его определения удалены, начиная с версии стандарта 2.5.

2.14.8.6 MSA-6 "Причина ошибки" (CE) 00023

Компоненты: <идентификатор (ID)> ^ <текст (ST)> ^ <имя системы кодирования (ST)> ^ <альтернативный идентификатор (ID)> ^ <альтернативный текст (ST)> ^ <имя альтернативной системы кодирования (ST)>

Это поле позволяет подтверждающей системе использовать определенный пользователем код ошибки для дальнейшего уточнения причины возвращения подтверждений типа AR и AE.