СП.АРМ

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

Термин “Уровень 7″ в названии стандарта ведет свое происхождение от Модели взаимодействия открытых систем OSI (Open System Interconnection), принятой Международной организацией стандартов ISO (International Standards Organization). Но это вовсе не означает, что стандарт HL7 полностью удовлетворяет элементам седьмого уровня модели OSI. Спецификации передачи сообщений стандарта HL7 также не опираются на одобренные организацией ISO спецификации низлежащих шести уровней модели OSI. Однако при этом стандарт HL7 удовлетворяет концептуальному определению взаимодействия приложений, принятому для седьмого уровня модели OSI.
В концептуальной модели OSI функции как коммуникационного программного обеспечения, так и соответствующих аппаратных средств поделены на семь слоев, или уровней. Стандарт HL7 сосредоточен на вопросах обеспечения взаимодействия, характерных для седьмого, или прикладного уровня. К ним относятся определения данных, которыми надо обмениваться, временные характеристики обмена, а также обмен сообщениями о специфичных для прикладного уровня ошибок передачи. Однако по мере необходимости в тексте стандарта иногда упоминаются протоколы более низких уровней модели OSI с тем, чтобы помочь разработчикам приложений понять контекст настоящего стандарта. Эти ссылки могут оказаться полезными при развертывании систем, созданных на основе стандарта HL7.
Рабочая группа HL7 Working Group (ранее - комитет HL7) состоит из добровольцев, которые работают над стандартом за свой счет или при поддержке своих работодателей. Членство в Рабочей группе HL7 было и остается открытым для любого лица, желающего внести свой вклад в разработку и уточнение Стандарта седьмого уровня, предназначенного для внедрения сетевых технологий в здравоохранении.
В настоящее время стандарт HL7 определяет взаимодействие различных систем, которые посылают или получают данные о прикреплении/госпитализации пациента, его выписке и переводе (ADT - admission, discharge, transfer), запросы этих данных, заказы, результаты лабораторных анализов и диагностических исследований, счета на оплату лечения, а также изменения в файлах, содержащих справочно-нормативную информацию. В нем не делается попытки описать архитектуру данных внутри приложения, он рассчитан на ведение центрального банка данных, а также на более распределенную среду, в которой данные рассредоточены по информационным системам отдельных подразделений.

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

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

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

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

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

Потребность в стандарте

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

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

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

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

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

а) стандарт должен поддерживать обмен информацией между системами, функционирующими на самом широком спектре технических средств. Его реализация должна оставаться достаточно практичной для широкого круга языков программирования и операционных систем. Он должен также поддерживать коммуникации в условиях применения разнообразных средств телекоммуникации, начиная от тех, что полностью совместимы с 7-уровневым стеком протоколов модели OSI, до примитивных соединений “точка-точка” по протоколу RS-232C и передачи пакетов данных на внешних носителях, например гибком диске или магнитной ленте.
б) немедленная передача простых трансакций должна поддерживаться наряду с передачей файлов, состоящих из нескольких трансакций;
в) должна быть достигнута наибольшая возможная степень стандартизации, совместимая с местными вариациями формата отдельных элементов данных и их использования. Стандарт должен включать в себя возможность местных вариаций. К ним должны относиться по меньшей мере местные таблицы значений, определения кодов и местные сегменты сообщений (например Z-сегменты стандарта HL7).
г) стандарт должен обеспечивать постепенное расширение по мере выявления новых требований. Сюда относится поддержка процесса добавления расширений и перехода к новым версиям в существующих операционных средах.
д) стандарт должен быть построен на основе опыта разработки и внедрения существующих производственных протоколов и принятых в промышленности стандартных протоколов. Однако он не должен предоставлять преимущество частным интересам отдельных фирм в ущерб интересам других пользователей стандарта HL7. В то же время стандарт HL7 должен обеспечить индивидуальному производителю возможность выйти на рынок со своими собственными продуктами.
е) хотя в настоящем виде стандарт ориентирован на больничные информационные системы, в долгосрочном плане целями стандартизации должны быть определение форматов и протоколов для прикладных компьютерных систем всего здравоохранения.
ж) сама природа разносторонней деловой активности в системе здравоохранения исключает возможность разработки универсальной модели как процесса, так и данных, которые могли бы обеспечить описание целевой среды в стандарте HL7. Кроме того, стандарт HL7 не включает априорных предположений об архитектуре информационной системы в здравоохранении и не пытается решить проблему архитектурных различий этих систем. Уже в силу этих причин стандарт HL7 не может быть стандартом взаимодействия типа “поставил-заработало” (”plug and play”). Упомянутые выше различия в местах применения стандарта HL7 могут потребовать выработки дополнительных соглашений между соответствующими учреждениями.
з) Рабочая группа HL7 была заинтересована в скорейшей разработке стандарта. Выполнив эту задачу, Рабочая группа HL7 разработала также инфраструктуру, обеспечивающую принятие решений на основании консенсуса, и вошла с предложением к Американскому национальному институту стандартов ANSI зарегистрироваться как Аккредитованная организация по стандартизации (ASO - Accredited Standards Organization).
и) Приоритетом Рабочей группы HL7 стало взаимодействие с другими организациями, занимающимися стандартизацией в здравоохранении (например, ACR/NEMA DICOM, ASC X12, ASTM, IEEE/MEDIX, NCPDP и др.). Рабочая группа HL7 принимает участие в работе комитета HISPP (Health Information Systems Planning Panel) Института ANSI с момента его создания в 1992 году.

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

С марта 1987 года встречи участников Рабочей группы HL7 проводились примерно раз в 3-4 месяца для разработки и обсуждения спецификаций стандарта. Группа была разбита на комитеты, часть из которых имела функциональную направленность, а другая часть занималась общей структурой управления и различными административными аспектами деятельности Рабочей группы. Эти комитеты отвечали за авторство глав стандарта HL7 и за их доработку. Кроме того, время от времени внутри Рабочей группы HL7 формировались подгруппы по специальным интересам, которые разрабатывали идеи и поддерживали отдельные перспективы, не охваченные каким-либо из существующих комитетов. Если включение в стандарт новой главы по результатам работы подгруппы специальных интересов признавалось целесообразным, то подгруппа могла войти с предложением к председателю Технического комитета Рабочей группы HL7 и в Исполнительный комитет о ее преобразовании в функциональный Технический комитет.
За первые три встречи была сформирована версия 1.0 предварительного стандарта, охватывающая общую структуру взаимодействия приложений, ГВП, ввод заказов и запросы, вывод которых был ориентирован на дисплеи. Хотя система учета оплаты лечения признавалась чрезвычайно важной, временные рамки не позволили включить ее в первый вариант предварительного стандарта. Этот вариант был представлен на I Пленуме Рабочей группы HL7, проводившейся 8 октября 1987 года в Tyson’s Corner (Вайоминг, США). Версия 2.0 была разработана на I Пленуме и представлена на II Пленуме, проводившемся в сентябре 1988 года в Tucson. После II Пленума начались редактирование и пересмотр версий 2.1, а теперь версии 2.2. С тех пор Рабочая группа HL7 выросла до 300 человек, намного превзойдя начальный состав в 12 человек, и выполнила следующие действия:

а) уточнила и расширила спецификации в различных функциональных областях.
б) установила формальные отношения с несколькими другими организациями по стандартизации: с комитетом HISPP (Healthcare Information Standards Planning Panel) института ANSI для координации работы над стандартами в здравоохранении, с группой ASC X12N по внешним стандартам обмена электронными документами, с группой ASTM E31.11 по стандартам обмена клиническими данными, с группой ACR/NEMA DICOM по стандартам, связанным с обменом изображений, и по другим аспектам рентгенологических и радиологических информационных систем, а также с группой IEEE P1157 по обмену медицинскими данными (”MEDIX”).
в) модифицировала общую структуру управления на основе комментариев с тем, чтобы приспособить ее к широкому спектру коммуникационных сред и облегчить взаимодействие с другими группами по стандартизации;
г) добавила главу по взаимодействию с системами учета оплаты лечения;
д) добавила главу по передаче результатов параклинических отделений, основанную на стандарте ASTM 1238-88 и разработанную при активном прямом участии членов комитета ASTM E31.11
е) создала компьютеризованный словарь всех элементов данных и других компонентов сообщений. Части документа, содержащие детальные распечатки этих данных, компоновались непосредственно из этого словаря. В Приложении А приводятся ссылки и другая информация из этого электронного словаря данных.
ж) обнаружила противоречия и ошибки в версиях 2.0 и 2.1 стандарта. Они были исправлены и документированы в версии 2.2.
з) в главы с описанием ввода заказов и передачи результатов были сделаны значительные добавления, обеспечивающие включение результатов, ориентированных на элементы данных, заказов в аптеку и административных документов.
и) расширила объем подтверждения сообщений, чтобы включить отдельный режим “подтверждения получения.” Хотя этот режим подтверждения всегда был допустим, его явное выделение позволяет получить ясное представление о том, каким образом стандарт HL7 поддерживает любую среду, в которой существуют промежуточные узлы с определенными задержками передачи данных (например, службы переадресовки сообщений, “интерфейсные машины”, обеспечивающие распространение сообщений, и
пр.). Возможность передачи немедленного подтверждения получения сообщения позволяет освободить систему-отправителя от обязанности заботиться о возможной повторной пересылке сообщения.
к) документировала различия между определением абстрактного сообщения стандарта HL7, которое в чистом виде относится к седьмому (прикладному) уровню, и правилами преобразования абстрактного сообщения в строку символов, представляющую реальное сообщение. Эти правила кодирования фактически представляют собой потенциальную альтернативу для шестого уровня (уровня представления данных) в тех ситуациях, когда отсутствует соответствующий стандарт типа Основных правил кодирования BER (Basic Encoding Rules ), предложенных в стандарте ASN.1.
Этот раздел содержит описание концептуальной основы стандарта HL7, методов включения в него местных вариаций и выполнения эволюционных изменений, а также способа его структурирования, обеспечивающего возможность применения стандарта в различных существующих и будущих коммуникационных средах.

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

1. Правила кодирования в стандарте HL7
Форматы сообщений, предписанные правилами кодирования стандарта HL7, состоят из полей данных переменной длины, отделенных символом разделителя полей. Правила описывают, каким образом различные типы данных кодируются в поле, и когда данное поле может повторяться. Поля данных объединяются в логические группы, называемые сегментами. Сегменты отделяются друг от друга символом разделителя сегментов. Каждый сегмент начинается с трехбуквенного идентификатора, определяющего его назначение в сообщении. Сегменты могут определяться как обязательные или необязательные. Может быть разрешено повторение сегментов. Поля данных идентифицируются в сообщении по их положению внутри соответствующих сегментов.
Все данные представляются в виде изображаемых (печатаемых) символов таблицы ASCII (шестнадцатеричные коды от 20 до7E включительно). Все специальные разделители и другие спецсимволы, за исключением символа возврата каретки, представляются также изображаемыми символами таблицы ASCII.
Правила кодирования обеспечивают различение отсутствующего и пустого значения поля. Отсутствующее значение задается двумя смежными разделителями поля. Пустое значение задается двумя смежными двойными кавычками. Это различие важно в тех ситуациях, когда передаваемое значение используется для модификации уже существующей записи базы данных. Передача пустого значения должна приводить к замене существующего значения поля записи на пустое. Отсутствие переданного значения должно приводить к сохранению текущего значения поля. Но если приложение-получатель не в состоянии обработать отсутствие значения, то в соответствии с правилами кодирования оно должно трактовать его как существующее, но пустое значение.
Правила кодирования устанавливают, что приложение-получатель должно игнорировать поля, которые присутствуют в сообщении, но не ожидаются им, и не рассматривать эту ситуацию как ошибочную.

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

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

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

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

5. Связь с другими протоколами
При разработке стандарта YL7 значительное внимание уделялось его связям с другими протоколами. При этом рассматривались три основных вопроса:
а) каковы связи между протоколом HL7 и протоколами предыдущего (сервисного) уровня? Для соблюдения строгого соответствия модели взаимодействия открытых систем OSI, стандарт HL7 не должен включать в себя какие-либо функции этих протоколов. Это требование можно было бы ужесточить, чтобы избежать включения в стандарт HL7 некоторых элементов седьмого уровня модели OSI, имеющих функциональные эквиваленты на шестом, сервисном уровне.
Однако целью Рабочей группы HL7 была поддержка электронного обмена информацией в здравоохранении при использовании широкого спектра коммуникационных сред, включая и значительно менее полные по сравнению с моделью OSI.
б) каковы связи между протоколом стандарта HL7 и другими протоколами прикладного уровня? Для сопоставления представляют интерес такие протоколы, как ASC X12 для электронного обмена документами, стандарты ASTM 1238-88 для передачи результатов лабораторных тестов, стандарты ACR/NEMA DICOM для передачи изображений и стандартизации других аспектов информационных систем рентгенологических и радиологических отделений, а также стандарты IEEE P1157 для обмена медицинскими данными (”MEDIX”).
в) каковы связи между стандартом HL7 и различными частными протоколами, используемыми в настоящее время в здравоохранении?

5.1 Протоколы предшествующего уровня
Правила кодирования стандарта HL7 существенно отличаются от Основных правил кодирования BER (Basic Encoding Rules) стандарта ASN.1, описанных в документах CCITT X.409 , X.209 и ISO 8825, или тех правил, что приняты в протоколах LU6.2 либо RPC. Это вызвано следующими причинами:
а) по определению, правила кодирования стандарта HL7 должны применяться в среде, в которой не предусмотрено программное обеспечение для декодирования. В связи с этим прикладные программисты должны самостоятельно разрабатывать программное обеспечение, предназначенное для обработки сообщений, закодированных в соответствии с указанными правилами.
б) правила кодирования в упомянутых выше протоколах предполагают, что протоколы нижнего уровня являются прозрачными (то есть все коды символов могут быть переданы без какого-либо изменения на нижних уровнях). Это предположение нередко не выполняется в коммуникационных средах, которые тем не менее должны обслуживать стандарт HL7. При этом методы реализации прозрачности протоколов нижнего уровня достаточно сложно реализуются в некоторых существующих прикладных средах.
Система обозначений, принятая для описания формата сообщений в стандарте HL7, не совпадает с Основными правилами кодирования BER (Basic Encoding Rules) Нотации абстрактного синтаксиса ASN.1 (Abstract Syntax Notation), используемых в стандартах ISO и MEDIX. Это вызвано тем, что язык синтаксиса ASN.1 весьма богат, а форматы сообщений стандарта HL7 очень просты, и в результате, если определить сообщения стандарта HL7, используя ASN.1, то эти определения окажутся перегруженными и тяжелыми для восприятия. Такие определения трудно объяснить прикладным программистам, которые не учились ни рекурсивным языкам вообще, ни языку ASN.1 в частности.
В отличие от других коммуникационных сред высокого уровня, в нашем случае нет даже упоминания об ассоциациях, не связанных с передачей сообщения от клиента к серверу и получения ответа, что вполне соответствует модели клиент-сервер.
В тех случаях, когда стандарт HL7 используется в сетевой среде, адресация сообщений является отдельным вопросом. Это равным образом относится как к сетям, построенным по стандарту ISO, так и к нестандартным сетям. Хотя в стандарте HL7 не задается способ адресации, в нем предусмотрен ряд полей данных, значениями которых могут быть такие адреса. Такие поля, как Приложение-получатель (Receiving Application), Организация-получатель (Receiving Facility) и Идентификатор обработки (Processing ID) присутствуют в заголовке всех сообщений стандарта HL7. Поле Организация-получатель рассчитано на среды, в которых несколько экземпляров одного и того же приложения могут исполняться на одной и той же компьютерной системе или в одной и той же сети для нужд различных учреждений или других структурных единиц. Поле Идентификатор обработки используется в ситуации, когда одно и то же приложение может исполняться на данном компьютере в различных целях. Рекомендованными значениями этого поля являются Производство, Обучение и Отладка.
Рабочая группа HL7 не стандартизует значения полей Приложение-получатель и Организация-получатель (Receiving Facility), поскольку системы кодирования их значений слишком тесно связаны с общей архитектурой приложений, используемых данной организацией. Для их представления в качестве элементов ассоциаций управляющих услуг (Association Control Service Element) стандарта ISO, эти значения должны быть зарегистрированы как Точки служебного доступа (Service Access Points) стандарта ISO.

5.2 Другие прикладные протоколы
Рабочая группа HL7 уделила значительное внимание взаимосвязям протокола HL7 и других протоколов. В настоящее время предпринимаются значительные усилия по установлению соответствующих контактов, а именно:
а) Протокол ACR/NEMA DICOM. Рабочая группа HL7 установила многообещающие связи с рабочей группой ACR/NEMA DICOM. Обе рабочие группы являются членами подкомитета HISPP MSDS института ANSI.
б) Стандарты ASC X12 для обмена электронными документами. Имя X12 присвоено семейству стандартов, предлагающих как общие, так и частные описания для обмена данными внутри значительного числа отраслей. Правила кодирования стандарта HL7 ведут свое происхождение от стандартов X12, хотя между ними и имеются некоторые различия. Это связано с необходимостью учитывать в стандарте HL7 онлайновый обмен индивидуальными трансакциями по локальным сетям компьютеров. Данное отличие и некоторые другие прикладные аспекты и вызывают отличия от стандартов X12. Комитет X12 недавно принял решение следовать правилам кодирования стандарта ЭДИФАКТ-ООН (UN/EDIFACT) для всех стандартов X12, выпущенных в 1995 году и последующих годах. Однако в настоящее время это решение не требует ретроспективного пересмотра всех существующих стандартов X12 по наборам трансакций.
В настоящее время бурно активизировалось использование трансакций стандарта X12N, облегчающих обмен счетами на оплату лечения и информацией о денежных переводах, а также координацию страховых выплат, регистрации клиентов и верификации. Рабочая группа HL7 приняла к сведению, что все деловые трансакции между учреждениями, затрагивающие обмен счетами, выплаты и другую финансовую информацию относятся к сфере деятельности страхового подкомитета ASC X12N. Как Рабочая группа HL7, так и подкомитет ASC X12N являются членами Подкомитета разработчиков стандартных сообщений HISPP Messaging Standards Developers Subcommittee института ANSI.
В феврале 1994 года Рабочая группа HL7 и Комитет X12 подписали соглашение об “усилении координации работ и определении технических вопросов, которые должны быть гармонизированы. Обе группы договорились перейти на соответствующий уровень согласования пересекающихся работ, привлекая пользователей и участников процесса стандартизации и учитывая требования ожидаемой реформы здравоохранения.”
С тех пор Рабочая группа HL7 и Комитет X12 создали две структуры для решения задачи гармонизации: (1) Координационно-управляющий комитет HL7 - X12N (функции контроля) и (2) Совместный координирующий комитет HL7 - X12N для разработки и реализации планов по достижению гармонизации. Оба комитета уже провели встречи в 1994 году и продолжат свою работу в 1995 году.
в) Стандарт ASTM 1238.88 для передачи результатов лабораторных анализов (Laboratory Data Reporting). Активное взаимодействие между Комитетом ASTM и Рабочей группой HL7 привело к небольшим изменениям в спецификации ASTM, улучшающим совместимость, к изменениям в спецификациях управления в стандарте HL7, также направленным на улучшение совместимости, а также к разработке целой главы стандарта, Передача результатов параклинических отделений, которая была разработана совместно на основе стандартов ASTM. Это взаимодействие теперь доведено до состояния, при котором каждая из двух указанных выше групп по стандартизации имеет разрешение свободно использовать в своих публикациях не только выдержки, но и “полное” содержание работ по стандартизации, выполняемых другой группой.
Некоторые различия между этими стандартами в основном связаны с терминологией, выбранной для описания фактического содержания сообщений. Например, в стандартах ASTM термин “разделитель подполя” (sub-field delimiter) обычно используется для разделения повторов однородных значений. В стандарте HL7 это понятие называется “разделителем повторов” (repetition separator). Как Рабочая группа HL7, так и Комитет ASTM являются членами Подкомитета разработчиков стандартных сообщений HISPP Messaging Standards Developers Subcommittee института ANSI (HISPP MSDS).
г) Стандарт IEEE P1157 (”MEDIX”). Комитет MEDIX определяет рамки протокола прикладного уровня аналогично стандарту HL7, но при этом строго опирается на стек протоколов ISO, включая элемент сервиса удаленных операций ROSE (Remote Operation Service Element). В отличие от этого стандарт HL7 не зависит от ROSE и не использует нотацию синтаксиса BER стандарта ASN.1. Несмотря на различие подходов, Рабочая группа HL7 регулярно взаимодействует с Комитетом MEDIX. Она приняла для стандарта HL7 формат, который относительно независим от выбранных правил кодирования и легко позволяет выполнить преобразование в нотацию ASN.1. Определенные таким образом трансакции должны быть непосредственно переносимы на язык определений стандарта MEDIX, а сообщения, передаваемые в рамках трансакций и закодированные по правилам стандарта HL7, должны быть транслируемыми в кодировку на основе правил BER. Это должно облегчить создание шлюзов между стандартом HL7 и его будущим окружением.

Кроме того, Рабочая группа HL7 и Комитет MEDIX договорились о направлении конвергенции стандартов, которое должно осуществляться на уровне определения абстрактного сообщения стандарта HL7. Далее, Комитет MEDIX согласился использовать определения абстрактного сообщения версии 2.1 стандарта HL7 как отправную точку для определений сообщений в стандарте MEDIX. Как Рабочая группа HL7, так и Комитет MEDIX являются членами Подкомитета разработчиков стандартных сообщений HISPP Messaging Standards Developers Subcommittee института ANSI.