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

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


ГОСТ Р ИСО/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 обычно не является необходимым или целесообразным.

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


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

Описание

Значение

Примечания/источник

Категория

Коды исследований, присвоенные Американским институтом радиологии (American College of Radiology)

ACR

Источник: Index for Radiological Diagnosis Revised, 3rd Edition 1986, American College of Radiology, Reston, VA.

Специальные коды, не применяемые для лекарств

Понятия ВОЗ, используемые при описании побочных реакций (WHO Adverse Reaction Terms)

ART

Источник: WHO Collaborating Centre for International Drug Monitoring, Box 26, S-751 03, Uppsala, Sweden.

Коды лекарств

Множество единиц измерения, определенное в стандарте HL7

ANS+

Множество единиц измерения, определенное в стандарте HL7. Основано на стандартах ANSI Х3.50 - 1986, ИСО 2988-83, а также традиционных мерах США (US customary units), см. подраздел 7.4.2.6 раздела 7.

Универсальные коды ASTM Е1238/Е1467

AS4

Источник: American Society for Testing & Materials и CPT4 (см. приложение Х1 спецификации Е1238 и приложение Х2 спецификации Е1467).

Специальные коды, не применяемые для лекарств

Нейрофизио-
логические коды AS4

AS4E

Коды диагнозов и коды/категории результатов исследований, применяемые в клинической нейрофизиологии. См. приложение 2 спецификации ASTM Е1467.

Специальные коды, не применяемые для лекарств

Типы культур организмов (American Type Culture Collection)

АТС

Референтные культуры (микроорганизмы, культуры тканей и т.д.), сопутствующие биологические материалы и ассоциированные данные. Источник: American Type Culture Collection, 12301 Parklawn Dr, Rockville MD, 20852. (301) 881-2600. http://www.atcc.org

Специальные коды, не применяемые для лекарств

Терминология процедур СРТ-4

С4

Источник: American Medical Association, P.O. Box 10946, Chicago IL 60610.

Специальные коды, не применяемые для лекарств

Терминология процедур СРТ-5

С5

В стадии разработки, см. предыдущий источник.

Специальные коды, не применяемые для лекарств

Абстрактные химические коды (Chemical abstract codes)

CAS

Уникальные коды каждого химического вещества, включая все непатентованные лекарства. Дозированные формы в этих кодах не учитываются. Если для конкретного лекарства существует несколько эквивалентных кодов CAS, используется первый из указанных в справочнике USAN. Источники: USAN 1990 и USP dictionary of drug names, William M. Heller, Ph.D., Executive Editor, United States Pharmacopeial Convention, Inc., 12601 Twinbrook Parkway, Rockville, MD 20852.

Коды лекарств

Коды стоматологических терминов CDT-2

CD2

Источник: American Dental Association's Current Dental Terminology (CDT-2) code. American Dental Association, 211 E. Chicago Avenue, Chicago, Illinois 60611.

Специальные коды, не применяемые для лекарств

Коды анализируемых веществ (CDC Analyte Codes)

CDCA

Источник: см. CDCM

Коды методов/приборов (CDC Methods/Instruments Codes)

CDCM

Источник: Public Health Practice Program Office, Centers for Disease Control and Prevention, 4770 Buford Highway, Atlanta, GA, 30421. Эти коды доступны по FTP: ftp.cdc.gov/pub/laboratory_info/CLIA, а также по Gopher: gopher.cdc.gov:70/11/laboratory_info/CLIA

Специальные коды, не применяемые для лекарств

Коды санитарно-
эпидемиологической информации (CDC Surveillance)

CDS

Коды санитарно-эпидемиологической информации (CDC Surveillance). Используются для кодирования данных, специфичных для требований к санитарно-эпидемиологическому надзору. Источник: Epidemiology Program Office, Centers for Disease Control and Prevention, 1600 Clifton Rd, Atlanta, GA, 30333. (404) 639-3661.

Специальные коды, не применяемые для лекарств

Диагностические коды в описаниях ЭКГ (CEN ECG diagnostic codes)

СЕ

Результат работы группы CEN РТ007. Развитая система кодов (сокращений) и их значений, используемых в описаниях ЭКГ. Опубликована комитетом CEN ТС251 в качестве предварительного стандарта. Ее можно запросить в секретариате комитета CEN ТС251, с/о Georges DeMoor, State University Hospital Gent, De Pintelaan 185-5K3, 9000 Gent, Belgium или Jos Willems, University of Gathuisberg, 49 Herestraat, 3000 Leuven, Belgium.

Специальные коды, не применяемые для лекарств

Коды, используемые в протоколах лучевых исследований (CLIP)

CLP

Источник: Simon Leeming, Beth Israel Hospital, Boston MA. Codes for radiology reports.

Специальные коды, не применяемые для лекарств

Коды модификаторов процедур (СРТ Modifier Code)

СРТМ

Можно запросить у организации АМА по адресу, указанному выше для классификации СРТ. Эти коды включены в приложение А издания СРТ 2000 Standard Edition. (СРТ 2000 Standard Edition, American Medical Association, Chicago, IL).

Специальные коды, не применяемые для лекарств

COSTART

CST

Международная система кодирования побочных реакций лекарственных средств. В США эта система ведется агентством FDA, Rockville, MD.

Коды лекарств

Коды вакцин (CDC Vaccine Codes)

CVX

Источник: National Immunization Program, Centers for Disease Control and Prevention, 1660 Clifton Road, Atlanta, GA, 30333

Коды лекарств

Контролируемая терминология, используемая в стандарте DICOM

DCM

Коды, определенные в источнике DICOM Content Mapping Resource. Digital Imaging and Communications in Medicine (DICOM). NEMA Publication PS-3.16 National Electrical Manufacturers Association (NEMA). Rosslyn, VA, 22209. Можно получить по адресу http://medical.nema.org.

Специальные коды, не применяемые для лекарств

EUCLIDES

Е

Можно получить у организации Euclides Foundation International nv, Excelsiorlaan 4A, B-1930 Zaventem, Belgium; телефон 32 2 720 90 60.

Специальные коды, не применяемые для лекарств

Коды количеств величин (Euclides quantity codes)

Е5

Можно получить у организации Euclides Foundation International nv (см. выше).

Специальные коды, не применяемые для лекарств

Коды лабораторных методик (Euclides Lab method codes)

Е6

Можно получить у организации Euclides Foundation International nv, Excelsiorlaan 4A, B-1930 Zaventem, Belgium; телефон 32 2 720 90 60.

Специальные коды, не применяемые для лекарств

Коды лабораторных приборов (Euclides Lab equipment codes)

Е7

Можно получить у организации Euclides Foundation International nv (см. выше).

Специальные коды, не применяемые для лекарств

Коды ферментов

ENZC

Коды ведутся комитетом Enzyme Committee Международного союза по биохимии и молекулярной биологии (International Union of Biochemistry and Molecular Biology). Источник: Enzyme Nomenclature: Recommendations on the Nomenclature and Classification of Enzyme-Catalysed Reactions. London: Academic Press, 1992.

Специальные коды, не применяемые для лекарств

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

FDDC

Источник: National Drug Data File. Частная собственность организации First DataBank, Inc. (800) 633-3453 или http://www.firstdatabank.com.

Коды лекарств

Коды совместимости лекарств с диагнозами (First DataBank Diagnostic Codes)

FDDX

Эти коды используются для проверки совместимости лекарств с диагнозами. Частная собственность организации First DataBank, Inc. Контактную информацию см. в описании кодов FDDC.

Коды лекарств

Коды устройств и аналитических процессов (FDA K10)

FDK

Источник: Dept. of Health & Human Services, Food & Drug Administration, Rockville, MD 20857 (коды устройств и аналитических процессов).

Специальные коды, не применяемые для лекарств

Штрих-коды для здравоохранения (HIBCC)

HB

Источник: Health Industry Business Communications Council, 5110 N. 40th St., Ste 120, Phoenix, AZ 85018.

Специальные коды, не применяемые для лекарств

Общая система кодирования процедур CMS (Common Procedure Coding System, ранее НСFA)

HCPCS

Система HCPCS содержит коды медицинских приборов, лекарств, применяемых для инъекций, служб транспортировки и других служб, отсутствующие в классификации процедур СРТ4.

Специальные коды, не применяемые для лекарств

Таксономия поставщиков медицинской помощи (Health Care Provider Taxonomy)

HCPT

Ассоциация Blue Cross and Blue Shield примет роль администратора таксономии поставщиков медицинской помощи, поэтому структура этих кодов классифицируется как внешняя по отношению к стандарту передачи медицинских данных Х12. Ответственность за ведение таксономии возлагается на рабочую группу Workgroup 15 (Provider Information) комитета ANSI ASC X12N или ее последователей. Такосономию можно запросить у организации Blue Cross and Blue Shield Association, 225 North Michigan Avenue, Chicago, IL 60601, Attention: ITS Department, ECNS Unit. http://www.wpc-edi.com/taxonomy. В настоящее время за ее публикацию на этом веб-сайте отвечает организация Washington Publishing Company.

Специальные коды, не применяемые для лекарств

Классификация Home Health Care

HHC

Источник: Home Health Care Classification System; Virginia Saba, EdD, RN; Georgetown University School of Nursing; Washington, DC.

Специальные коды, не применяемые для лекарств

Классификация результатов лечения (Health Outcomes)

HI

Коды результатов лечения организации Health Outcomes Institute можно получить (по запросу) от организации Stratis Health (ранее Foundation for Health Care Evaluation and Health Outcomes Institute), 2901 Metro Drive, Suite 400, Bloomington, MN, 55425-1525; (612) 854-3306 (voice); (612) 853-8503 (fax); dziegen@winternet.com. Примеры кодов см. в руководстве по внедрению.

Специальные коды, не применяемые для лекарств

Коды, определенные в стандарте HL7, где nnnn - номер таблицы HL7

HL7nnnn

Источник кодов - Рабочая группа Health Level Seven. Строка "nnnn" представляет собой номер таблицы HL7

Коды общего назначения

Японские национальные коды лекарств (Japanese Nationwide Medicine Code)

НОТ

Коды процедур CMS, ранее - коды процедур организации HCFA (HCPCS)

НРС

Общая система кодирования процедур HCPCS организации Health Саге Financing Administration (HCFA), включая модификаторы.

Специальные коды, не применяемые для лекарств

MКB-10 (ICD-10)

I10

Публикация ВОЗ (World Health Publications, Albany, NY).

Специальные коды, не применяемые для лекарств

Коды процедур ICD-10

I10Р

Система кодирования процедур (ICD-10-PCS). Дополнительную информацию см. на сайте http://www.hcfa.gov/stats/icd10.icd 10.htm.

Специальные коды, не применяемые для лекарств

МКБ-9 (ICD9)

I9

Публикация ВОЗ (World Health Publications, Albany, NY).

Специальные коды, не применяемые для лекарств

Клиническое расширение МКБ-9 (ICD-9CM)

I9C

Источник: Commission on Professional and Hospital Activities, 1968 Green Road, Ann Arbor, Ml 48105 (включает в себя коды всех процедур и диагностических исследований).

Специальные коды, не применяемые для лекарств

Коды ISBT

IBT

Начиная с версии 2.5, оставлена только в целях обратной совместимости. Этот идентификатор заменен на IBTnnnn. Источник: International Society of Blood Transfusion. Blood Group Terminology 1990. VOX Sanquines 1990 58(2):152-169.

Специальные коды, не применяемые для лекарств

Коды системы ISBT 128, где nnnn означает конкретную таблицу в этой
системе.

IBTnnnn

Источник: International Society of Blood Transfusion (конкретная контактная информация будет предоставлена редактору.) Переменный суффикс "nnnn" идентифицирует конкретную таблицу в системе ISBT 128.

Специальные коды, не применяемые для лекарств

Классификация проблем со здоровьем ICHPPC-2

IC2

Источник: International Classification of Health Problems in Primary Care, Classification Committee of World Organization of National Colleges, Academies and Academic Associations of General Practitioners (WONCA), 3rd edition. An adaptation of ICD9 intended for use in General Medicine, Oxford University Press.

Специальные коды, не применяемые для лекарств

Австралийская модификация МКБ-10 (ICD-10 Australian modification)

ICD10AM

Канадская модификация МКБ-10 (ICD-10 Canada)

ICD10CA

Международная классификация онкологических заболеваний (International Classification of Diseases for Oncology)

ICDO

Источник: International Classification of Diseases for Oncology, 2nd Edition. World Health Organization: Geneva, Switzerland, 1990. Можно заказать у организации College of American Pathologists, 325 Waukegan Road, Northfield, IL, 60093-2750. (847) 446-8800.

Специальные коды, не применяемые для лекарств

Классификация организации ICCS

ICS

Источник: Commission on Professional and Hospital Activities, 1968 Green Road, Ann Arbor, Ml 48105.

Специальные коды, не применяемые для лекарств

Международная классификация нарушений сна (International Classification of Sleep Disorders)

ICSD

Источник: International Classification of Sleep Disorders Diagnostic and Coding Manual, 1990. Можно получить у организации American Sleep Disorders Association, 604 Second Street SW, Rochester, MN 55902

Специальные коды, не применяемые для лекарств

Коды, определенные ИСО, где "nnnn" - номер таблицы ИСО

ISOnnnn

Источник: International Standards Organization, где "nnnn" - номер таблицы ИСО

Коды общего назначения

Единицы измерений, определенные в стандарте ИСО 2955.83, с расширениями, предложенными Рабочей группой HL7

ISO+

См. подраздел 7.4.2.6 раздела 7

Коды свойств (IUPAC/IFCC Property Codes)

IUPP

Источник: International Union of Pure and Applied Chemistry/International Federation of Clinical Chemistry. The Silver Book: Compendium of terminology and nomenclature of properties in clinical laboratory sciences. Oxford: Blackwell Scientific Publishers, 1995. Henrik Olesen, M.D., D.M.Sc, Chairperson, Department of Clinical Chemistry, KK76.4.2, Rigshospitalet, University Hospital of Copenhagen, DK-2200, Copenhagen. http://inet.uni-c.dk/~qukb7642

Коды компонентов (IUPAC/IFCC Component Codes)

IUPC

Коды, используемые организацией IUPAC/IFF для идентификации содержания компонентов (аналитов). Обратитесь к Henrik Olesen, контактная информация указана выше для системы IUPP

Система Japanese Chemistry

JC8

Классификация клинических исследований. Источник: Japan Association of Clinical Pathology. Version 8, 1990. Многомерный код, включая ось субъекта (например, Rubella = 5f395, идентифицирующий код (например, вирус ab IGG), код биоматериала (например, сыворотка крови = 023) и код методики (например, ELISA = 022)

Запрещена

Национальные коды лабораторных анализов (JLAC/JSLM, nationwide laboratory code)

JC10

Источник: Classification & Coding for Clinical Laboratory. Japanese Society of Laboratory Medicine (JSLM, Old:Japan Society of Clinical Pathology). Version 10, 1997. Многомерный код, включая код аналита (например, Rubella = 5f395, идентифицирующий код (например, вирус ab IGG), код биоматериала (например, сыворотка крови = 023) и код методики (например, ELISA = 022)

Japanese Image Examination Cache

JJ1017

Местные коды, используемые в счетах на оплату лечения (Local billing code)

LB

Местные коды, используемые в счетах на оплату лечения (с необходимыми расширениями).

Коды общего назначения

Логические идентификаторы имен и кодов исследований (Logical Observation Identifier Names and Codes, LOINC®)

LN

Источник: Regenstrief Institute, с/о LOINC, 1050 Wishard Blvd., 5th floor, Indianapolis, IN 46202. 317/630-7433. Можно загрузить с сервера института Regenstrief Institute по адресу http://www.Regenstrief.org/loinc/loinc.htm. Доступны также на файловом сервере FTP/Gopher Рабочей группы HL7: www.mcis.duke.edu/standards/termcode/ loinclab и www.mcis.duke.edu/standards/termcode/ loinclin), а также на веб-сервере http://www.mcis.duke.edu/standards/ termcode/loincl.htm. Версия от января 2000 года содержит идентификаторы, синонимы и перекрестные ссылки для более чем 26000 лабораторных анализов и сопутствующих исследований и 1,500 клинических характеристик.

Специальные коды, не применяемые для лекарств

Коды организации Medicaid

MCD

Коды и их значения, используемые организацией Medicaid в счетах на оплату лечения.

Специальные коды, не применяемые для лекарств

Коды организации Medicare

MCR

Коды и их значения, используемые организацией Medicare в счетах на оплату лечения.

Специальные коды, не применяемые для лекарств

Диагностические коды (Medispan Diagnostic Codes)

MDDX

Эти коды используются для проверки совместимости лекарств с диагнозами. Частная собственность. Источник: Hierarchical drug codes for identifying drugs down to manufacturer and pill size. MediSpan, Inc., 8425 Woodfield Crossing Boulevard, Indianapolis, IN 46240. Tel: (800) 428-4495, http://www.espan.com/medispan/pages/medhome.html. См. описание системы MGPI.

Коды лекарств

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

MEDC

Частные коды для идентификации лекарств. Частная собственность организации Medical Economics Data, Inc. (800) 223-0581.

Коды лекарств

Медицинский словарь peгуляторной деятельности (MEDDRA)

MEDR

Источник: Dr. Louise Wood, Medicines Control Agency, Market Towers, 1 Nine Elms Lane, London SW85NQ, UK Tel: (44)0 171-273-0000, http://www.open.gov.uk/mca/mcahome.htm

Коды лекарств

Диагностические коды (Medical Economics Diagnostic Codes)

MEDX

Эти коды используются для проверки совместимости лекарств с диагнозами. Частная собственность организации Medical Economics Data, Inc. (800) 223-0581.

Коды лекарств

Коды лекарств (Medispan GPI)

MGPI

Иерархические коды, предназначенные для идентификации лекарств до уровня производителя и размера таблеток. Частная собственность организации MediSpan, Inc., 8425 Woodfield Crossing Boulevard, Indianapolis, IN 46240. Tel: (800) 428-4495.

Коды лекарств

Коды производителей вакцин (CDC Vaccine Manufacturer Codes)

MVX

См. выше описание системы CVX

Коды лекарств

Коды сестринских диагнозов (NANDA)

NDA

Источник: North American Nursing Diagnosis Association, Philadelphia, PA.

Специальные коды, не применяемые для лекарств

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

NDC

Коды, уникальные для каждого сочетания лекарства, дозированной формы, производителя и упаковки. (Предоставляются организацией National Drug Code Directory, FDA, Rockville, MD, и другими источниками.)

Коды лекарств

Классификация сестринских вмешательств (Nursing Interventions Classification)

NIC

Источник: Iowa Intervention Project, College of Nursing, University of Iowa, Iowa City, Iowa

Специальные коды, не применяемые для лекарств

Национальные идентификаторы поставщиков медицинской помощи (National Provider Identifier)

NPI

Источник: Health Care Finance Administration, US Dept. of Health and Human Services, 7500 Security Blvd., Baltimore, MD 21244.

Специальные коды, не применяемые для лекарств

Коды, используемые в счетах на оплату лечения (National Uniform Billing Committee Code)

NUBC

Классификация Omaha System

ОНА

Источник: Omaha Visiting Nurse Association, Omaha, NB.

Специальные коды, не применяемые для лекарств

Коды Omaha

ОНА

Источник: Omaha Visiting Nurse Association, Omaha, NB.

Специальные коды, не применяемые для лекарств

Коды мест оказания медицинской помощи POS Codes

POS

Источник: HCFA Place of Service Codes for Professional Claims (cm.
http://www.hcfa.gov/medicare/poscode.htm).

Специальные коды, не применяемые для лекарств

Коды Рида (Read Classification)

RC

Источник: The Read Clinical Classification of Medicine, Park View Surgery, 26 Leicester Rd., Loughborough LE11 2AG (включает коды лекарственных назначений, коды диагнозов и другие коды).

Специальные коды, не применяемые для лекарств

Словарь терминов SNOMED-DICOM Microglossary

SDM

Источник: College of American Pathologists, Skokie, IL, 60077-1034 (ранее этот словарь имел обозначение 99SDM).

Специальные коды, не применяемые для лекарств

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

SNM

Источник: Systemized Nomenclature of Medicine, 2nd Edition 1984 Vols 1, 2, College of American Pathologists, Skokie, IL.

Специальные коды, не применяемые для лекарств

Номенклатура медицинских терминов SNOMED International

SNM3

Источник: SNOMED International, 1993 Vols 1-4, College of American Pathologists, Skokie, IL, 60077-1034.

Специальные коды, не применяемые для лекарств

Коды анатомической локализации (SNOMED topology codes)

SNT

Источник: College of American Pathologists, 5202 Old Orchard Road, Skokie, IL 60077-1034.

Специальные коды, не применяемые для лекарств

Классификация UCDS

UC

Источник: Uniform Clinical Data Systems. Ms. Michael McMullan, Office of Peer Review Health Care Finance Administration, The Meadows East Bldg., 6325 Security Blvd., Baltimore, MD 21207; (301) 966 6851.

Специальные коды, не применяемые для лекарств

Номенклатура медицинских приборов (MDNS)

UMD

Источник: Universal Medical Device Nomenclature System. ECRI, 5200 Butler Pike, Plymouth Meeting, PA 19462 USA. Phone: 215-825-6000, Fax: 215-834-1275.

Коды приборов

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

UML

Источник: National Library of Medicine, 8600 Rockville Pike, Bethesda, MD 20894.

Специальные коды, не применяемые для лекарств

Универсальные коды продукции (Universal Product Code)

UPC

Источник: The Uniform Code Council. 8163 Old Yankee Road, Suite J, Dayton, OH 45458; (513) 435 3070

Специальные коды, не применяемые для лекарств

Идентификаторы врачей (UPIN)

UPIN

Универсальные идентификаторы врачей, присваиваемые организациями Medicare/CMS (ранее HCFA). Распространяются организацией Health Care Financing Administration, U.S. Dept. of Health and Human Services, Bureau of Program Operations, 6325 Security Blvd., Meadows East Bldg., Room 300, Baltimore, MD 21207

Специальные коды, не применяемые для лекарств

Почтовые индексы, присваиваемые Почтой США (United States Postal Service)

USPS

Двухбуквенные коды штатов и владений (Two Letter State and Possession Abbreviations) перечислены в публикации Publication 28, Postal Addressing Standards, которая может быть получена от организации Address Information Products, National Address Information Center, 6060 Primacy Parkway, Suite 101, Memphis, Tennessee 38188-0001. Вопросы или комментарии по содержанию публикации должны быть адресованы организации Office of Address and Customer Information Systems, Customer and Automation Service Department, US Postal Service, 475 Lenfant Plaza SW Rm 7801, Washington, DC 20260-5902

Специальные коды, не применяемые для лекарств

Шестизначные номера записей лекарств в словаре ВОЗ (WHO record # drug codes (6 digit))

W1

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

Коды лекарств

Восьмизначные номера записей лекарств в словаре ВОЗ (WHO record # drug codes (8 digit))

W2

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

Коды лекарств

Номера записей лекарств в словаре ВОЗ с дополнениями ASTM (WHO record # code with ASTM extension)

W4

Дополнения номеров записей лекарств в словаре ВОЗ, предложенные организацией ASTM (см. Руководство по внедрению), позволяют кодировать биохимические показатели сыворотки крови, соблюдение пациентом инструкций по применения лекарств, среднюю суточную дозу и т.д. (см. приложение Appendix Х1 Руководства по внедрению).

Коды лекарств

Анатомо-
терапевтическо-
химическая классификация лекарств (WHO АТС)

WC

Анатомо-терапевтическо-химическая классификация лекарств ВОЗ представляет собой иерархическую классификацию лекарств по терапевтическому действию. Коды ATX имеют связи с указанными выше номерами записей лекарств в словаре ВОЗ.

Коды лекарств

Сокращения


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

ISO

International Organization for Standardization (Международная организация по стандартизации)

CEN

de Normalisation (Европейский комитет по стандартизации, федерация из 28 национальных органов стандартизации, которые также входят в ИСО)

EU

European Union (Европейский Союз)

HL7

Health Level 7

ICH

The International Conference on Harmonisation of Technical Requirements for Registration of Pharmaceuticals for Human Use (Международная конференция по гармонизации технических требований к регистрации лекарственных препаратов для человека)

SDO

Standards Development Organization (организация по разработке стандартов)

SGML

Standardized generalized markup language (стандартный обобщенный язык разметки). Стандарт ИСО по платформенно-независимому описанию структурированной информации

SNOMED

The Systematized Nomenclature of Human and Veterinary Medicine (Систематизированная номенклатура терминов медицины и ветеринарии)

SNOMED-СТ

Systematized Nomenclature of Medicine-Clinical Terms Medicine (Систематизированная номенклатура терминов клинической медицины)

V2.5

HL7 Version 2.5 Messaging Standard (стандарт передачи сообщений HL7, версия 2.5)

W3C

World Wide Web Consortium (Консорциум Всемирной паутины)

XML

eXtensible Markup Language (расширяемый язык разметки)

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, это приводило бы к передаче сообщений, у которых отсутствует обязательная правильная идентификация пациента.