Стандарт HL7
HL7 (Health Level 7) — стандарт обмена медицинскими данными в электронном виде. Он легко сопрягается с другими протоколами и стандартами, что позволяет использовать его в качестве стандарта в приборах многими производителями медицинской техники.
В марте 1987 года была разработана первая версия, а в наше время применяется версия HL7 2.2. Данный стандарт используется в США, Канаде, Европе, Австралии, Израиле, Японии и других странах.
Стандарт HL7, не являясь альтернативой DICOM, предоставляет возможность единого представления медицинской документальной информации без разработки специальных программ и интерфейсов, т. е. стандартизирует обмен информацией, а не систем, которые передают эти данные. Следствием этого является разнообразие методов применения стандарта HL7 в различных учреждениях здравоохранения. Единая схема полученных данных является ценным свойством не только для клинических, но и для статистических исследований. Общая структура стандарта включает:
? движение пациентов (поступление, выписка, перевод);
? порядок поступления;
? финансовые вопросы (биллинг);
? данные клинических наблюдений;
? интерфейс для данных общего назначения;
? информацию для руководящего персонала;
? назначения, операции и лечебные процедуры;
? систему эпикризов.
В настоящее время стандарт HL7 определяет взаимодействие различных систем, которые посылают или получают данные о движении пациента (ADT — admission, discharge, transfer), запросы данных, заказы, результаты лабораторных анализов и диагностических исследований, счета на оплату лечения, а также изменения в файлах, содержащих справочно-нормативную информацию. В нем не делается попытки описать архитектуру данных внутри приложения, он рассчитан на ведение центрального банка данных, а также на более распределенную среду, в которой данные рассредоточены по информационным системам отдельных подразделений.
Если принять во внимание многообразие приложений информационных систем в здравоохранении, а также вариации той среды, в которой оказывается медицинская помощь, то становится очевидным, что существует гораздо большее число видов взаимодействия, реализация которых могла бы выиграть от стандартизации.
Организация и оказание медицинской помощи связаны с интенсивной обработкой информации. Автоматизация функций управления информацией существенно влияет на эффективность действий, выполняемых в системе здравоохранения. Многие полагают, что учреждения здравоохранения, не имеющие автоматизированных информационных систем, не смогли в 90-е годы успешно конкурировать на рынке медицинских услуг.
В последние два десятилетия учреждения здравоохранения и, в первую очередь, больницы начали автоматизировать различные аспекты управления своей информацией. Первоначально основные усилия были направлены на уменьшение потока бумажных документов, ускорение обработки счетов и на улучшение принятия управленческих решений. В последние годы внимание фокусировалось также на способах улучшения работы клинических и вспомогательных подразделений, включая системы, обеспечивающие работу "у постели" больного (в больницах и других учреждениях, оказывающих стационарную помощь) и "рядом с больным" в амбулаторных условиях. За последние несколько лет сформировался особый интерес к интеграции всей информации, связанной с оказанием медицинской помощи пациенту в течение всей его жизни (например, ведение электронной истории болезни). Предполагалось также, что по мере необходимости, с помощью средств телекоммуникации к этой электронной истории болезни или соответствующей ее части смогут получать доступ все, кому это необходимо.
В настоящее время можно не так уж редко встретить в рядовой больнице действующую вычислительную систему, обеспечивающую учет движения коечного фонда и пациентов, автоматизацию клинических лабораторий, отделений радиологии и рентгенологии, бухгалтерский учет и многое другое.
Нередко эти приложения разработаны различными производителями или несколькими самостоятельными группами разработчиков так, что каждая подсистема имеет свой чрезвычайно специфичный формат хранения и представления информации. По мере того, как больницы продолжают расширять операции по управлению информацией, возникает настоятельная потребность в параллельном использовании ряда наиболее важных данных. Современные сложные системы, которые способны помочь в выполнении если не всех, то большинства операций по управлению информацией в здравоохранении, находятся в стадии разработки у отдельных производителей. Такие системы могут разрабатываться как централизованные, либо распределенные. За исключением случая, когда разработка такой системы уже завершена, ее разработчики непременно будут испытывать потребность с стандарте обмена внешними данными, например HL7.Однако учреждение здравоохранения имеет много стимулов к приобретению или разработке отдельных приложений для своих подразделений на модульной основе. Один из возможных стимулов — специфичные нужды подразделения, которые не могут быть хорошо решены, или даже вовсе не могут быть решены производителями сложных систем учреждений. Другой стимул — потребность в постепенной эволюции всей больничной информационной системы за счет ряда последовательных шагов на уровне подразделений вместо одного революционного скачка. Эти стимулы приводят к ситуации, когда сложная центральная информационная система дополняется рядом систем отдельных подразделений либо когда вместо центральной системы создается конгломерат из отдельных автономных систем.
Сетевая технология стала доступным и экономически эффективным подходом к интеграции различных по функциям и аппаратным средствам прикладных компьютерных систем в здравоохранении. Однако эти системы разрабатываются, исходя из структуры рынка, а не из требований логической целостности информации, вследствие чего они могут получиться рассчитанными на частные случаи либо оказаться достаточно причудливыми.
Для включения этих приложений в сетевую среду могут потребоваться значительные усилия по их доработке с учетом местной специфики, что может привести разработчика к значительным временным затратам и при этом не даст ему возможности заняться разработкой новых приложений. Затраты на доработку приложений с учетом местной специфики могут быть значительно снижены, если как пользователи информационных систем, так и их производители примут общие стандарты сетевого взаимодействия в здравоохранении.Таким образом, и для пользователей, и для производителей очень важно не оказаться лицом к лицу с проблемами поддержания несовместимых структур коммуникации и выполнения транзакций. Во избежание такой ситуации необходимо создать базу, на основе которой можно минимизировать несовместимость и максимизировать однотипность обмена информацией между системами. Стандарт HL7 как раз и предлагается использовать в качестве сверхструктуры, обеспечивающей единство спецификаций и методологии при разработке сетевых систем. Действительно, разработка и внедрение стандартных способов взаимодействия компьютерных приложений является как практичной, так и экономически выгодной.
Спецификации настоящего стандарта были разработаны в соответствии с заранее поставленными целями, и дальнейшие расширения стандарта также должны удовлетворять им.
Стандарт HL7 предназначен для облегчения взаимодействия компьютерных приложений в учреждениях здравоохранения. Его основная цель состоит в такой стандартизации обмена данными между медицинскими компьютерными приложениями, при которой исключается или значительно снижается необходимость в разработке и реализации специфичных программных интерфейсов, требующихся при отсутствии стандарта.
Основная цель может быть разделена на более частные цели.
? Стандарт должен поддерживать обмен информацией между системами, функционирующими на самом широком спектре технических средств. Его реализация должна оставаться достаточно практичной для широкого круга языков программирования и операционных систем.
Он должен также поддерживать коммуникации в условиях применения разнообразных средств телекоммуникации, начиная от тех, что полностью совместимы с 7-уровневым стеком протоколов модели OSI, до примитивных соединений "point-to-point" по протоколу RS-232C и передачи пакетов данных на внешних носителях, например, гибком диске или магнитной ленте. Сейчас стандарт успешно работает с простыми соединениями типа "direct", и современными TCP/IP, DECNET, SNA, "понимает" управляющие коды Microsoft, Unix, IBM SUN.? Немедленная передача простых транзакций должна поддерживаться наряду с передачей файлов, состоящих из нескольких транзакций.
? Должна быть достигнута возможно наибольшая степень стандартизации, совместимая с местными вариациями формата отдельных элементов данных и их использования. Стандарт должен включать в себя возможность местных вариаций. К ним должны относиться, по меньшей мере, местные таблицы значений, определения кодов и местные сегменты сообщений (например, Z-сегменты стандарта HL7).
? Стандарт должен обеспечивать постепенное расширение по мере выявления новых требований. Сюда относится поддержка процесса добавления расширений и перехода к новым версиям в существующих операционных средах.
? Стандарт должен быть построен на основе опыта разработки и внедрения существующих производственных протоколов и принятых в промышленности стандартных протоколов, но не должен предоставлять преимущество частным интересам отдельных фирм в ущерб интересам других пользователей стандарта HL7. В то же время, стандарт HL7 должен обеспечить индивидуальному производителю возможность выйти на рынок со своими собственными продуктами.
? Хотя в настоящем виде стандарт ориентирован на больничные информационные системы, в долгосрочном плане целями стандартизации должны быть определение форматов и протоколов для прикладных компьютерных систем всего здравоохранения.
? Сама природа разносторонней деловой активности в системе здравоохранения исключает возможность разработки универсальной модели как процесса, так и данных, которые могли бы обеспечить описание целевой среды в стандарте HL7.
Кроме того, стандарт HL7 не включает априорных предположений об архитектуре информационной системы в здравоохранении и не пытается решить проблему архитектурных различий этих систем. Уже в силу этих причин стандарт HL7 не может быть стандартом взаимодействия типа "поставил-заработало" ("Plug-and-Play"). Упомянутые выше различия в местах применения стандарта HL7 могут потребовать выработки дополнительных соглашений между соответствующими учреждениями.? Кооперация с другими разработчиками (ACR/NEMA DICOM, ASC Х12, ASTM, IEEE/MEDIX, NCPDP и т. д.).
Представление данных осуществляется в виде сегментов, состоящих из полей, которым присваиваются уникальные идентификаторы. Так, сообщение о движении пациента будет содержать следующие сегменты: заголовок — Message Header (MSH), тип события — Event Type (EVN), идентификатор пациента — Patient ID (PID) и информацию о визите — Patient Visit (PV1). В структуре данных учитывается положение конкретного сегмента среди других сегментов — их последовательность. Учитывается длина данных (количество символов в поле), тип данных, обязательность (необходимо, опционально и т. д.), повторность и множество других параметров.
Все данные представляются в виде изображаемых (печатаемых) символов таблицы ASCII (шестнадцатеричные коды от 20 до 7Е включительно). Все специальные разделители и другие спецсимволы, за исключением символа возврата каретки, представляются также изображаемыми символами таблицы ASCII.
Правила кодирования обеспечивают различение отсутствующего и пустого значения поля. Отсутствующее значение задается двумя смежными разделителями поля. Пустое значение задается двумя смежными двойными кавычками. Это различие важно в тех ситуациях, когда передаваемое значение используется для модификации уже существующей записи базы данных. Передача пустого значения должна приводить к замене существующего значения поля записи на пустое. Отсутствие переданного значения должно приводить к сохранению текущего значения поля. Если же приложение- получатель не в состоянии обработать отсутствие значения, то, в соответствии с правилами кодирования, оно должно трактовать его как существующее, но пустое значение.
Правила кодирования устанавливают, что приложение-получатель должно игнорировать поля, которые присутствуют в сообщении, но не ожидаются им, и не рассматривать эту ситуацию как ошибочную.
Хотя стандарт HL7 определен в терминах модели "клиент-сервер" (удаленного доступа), тем не менее, он в равной мере приложим к обмену файлами. Одно или более сообщений могут быть обработаны в соответствии с правилами кодирования, сгруппированы в файл и переданы на внешних носителях информации с помощью протоколов FTAM, FTP, Kermit или любого другого протокола.