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

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

Группа П85

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

Информатизация здоровья

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

ОКС 35.240.80
ОКСТУ 4002

Дата введения 2016-11-01

Предисловие

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному стандарту ИCO/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) автоматизацию клинических лабораторий;

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

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 Х12, 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 Е31.11 по стандартам обмена клиническими данными, с группой ACR/NEMA DICOM по стандартам, связанным с обменом медицинскими изображениями и с другими аспектами информационных систем лучевой диагностики, а также с группой IEEE Р1157 по обмену медицинскими данными ("MEDIX");

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2) В странах Европейского союза (ЕС), к числу печатаемых относят символы, не входящие в указанный выше ограниченный набор (например, в него не входят символ немецкого языка или акцентированные символы французского языка). На стандартных персональных компьютерах эти печатаемые символы обычно имеют коды в диапазоне 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 Х12 для электронного обмена документами, стандарты ASTM 1238-88 для передачи результатов лабораторных анализов, стандарты ACR/NEMA DICOM для передачи медицинских изображений и стандартизации других аспектов информационных систем лучевой диагностики, а также стандарты IEEE Р1157 для обмена медицинскими данными ("MEDIX");

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

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

Правила кодирования сообщений стандарта HL7 существенно отличаются от Основных правил кодирования BER (Basic Encoding Rules) стандарта ASN.1, описанных в документах CCITT Х.409, Х.209 и ИСО 8825, или тех правил, что приняты в протоколах LU6.2 либо RPC. Это вызвано следующими причинами:
_______________
Так называемые "исходные правила кодирования" сообщений 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 Х12 для обмена электронными документами. Имя ASC Х12 присвоено семейству стандартов, предлагающих как общие, так и частные описания для обмена данными внутри значительного числа отраслей. Правила кодирования стандарта HL7 ведут свое происхождение от стандартов Х12, хотя между ними и имеются некоторые различия. Это связано с необходимостью учитывать в стандарте HL7 он-лайновый обмен индивидуальными транзакциями по локальным сетям компьютеров. Данное обстоятельство и некоторые другие прикладные аспекты и вызывают отличия от стандартов Х12. Комитет Х12 недавно принял решение следовать правилам кодирования стандарта ЭДИФАКТ-ООН (UN/EDIFACT) для всех стандартов Х12, выпущенных в 1995 году и последующих годах. В настоящее время бурно активизировалось использование транзакций стандарта X12N, облегчающих обмен счетами на оплату лечения и информацией о денежных переводах, а также координацию страховых выплат, регистрации клиентов и верификации. Рабочая группа HL7 приняла к сведению, что все новые деловые транзакции между учреждениями, затрагивающие обмен счетами, выплаты и другую финансовую информацию относятся к сфере деятельности страхового подкомитета ASC X12N. В феврале 1994 года Рабочая группа HL7 и Комитет Х12 подписали соглашение об усилении координации работ и определении технических вопросов, которые должны быть гармонизированы. Обе группы договорились перейти на соответствующий уровень согласования потенциально пересекающихся работ, привлекая пользователей и участников процесса стандартизации и учитывая требования ожидаемой реформы здравоохранения;

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 Р1157 ("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 и Х12 зарегистрированы Институтом 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, не учитывались требования Министерства обороны США к безопасности и надежности систем по категориям (А, В, С, 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, это приводило бы к передаче сообщений, у которых отсутствует обязательная правильная идентификация пациента.