1
Доступно поисковых запросов: 1 из 2
Следующий пробный период начнётся: 03 октября 2022 в 00:15
Снять ограничение

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

Информатизация здоровья. Health Level Seven Version 2.5. Прикладной протокол электронного обмена данными в организациях здравоохранения
Действующий стандарт
Проверено:  25.09.2022

Информация

Название Информатизация здоровья. 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
Дата актуализации текста 01.12.2016
Дата актуализации описания 01.01.2021
Дата издания 06.09.2016
Дата введения в действие 01.11.2016
Область и условия применения Стандарт ИСО/HL7 27931:2009 определяет прикладной протокол электронного обмена данными в организациях здравоохранения
Опубликован Официальное издание. М.: Стандартинформ, 2016 год
Утверждён в Росстандарт

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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

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


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

- простое и интегрированное ведение расписаний;

- обеспечение лечебно-диагностического процесса непосредственно на месте оказания медицинской помощи;

- предупреждения и напоминания;

- параллельное наблюдение, измерение и анализ;

- параллельное обеспечение принятия решений;

- отслеживание результатов лечения;

- отслеживание "ожиданий" пациента (то есть потребителя) и степени их удовлетворения;

- ведение списков проблем.

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

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

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

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

1.8.1 Стандарты ANSI


ANSI Х3.30

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

ANSI Х3.4

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

ANSI Х3.43

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

ANSI Х3.50

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

ANSI X3.51

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

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


ИСО 5218

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

ИСО 1000

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

ИСО 2955

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

ИСО 8072

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

ИСО 8601

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

ИСО 8859

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

ИСО 8859/1

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

ИСО 8859/2

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

ИСО 8859/3

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

ИСО 8859/4

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

ИСО 8859/5

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

ИСО 8859/6

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

ИСО 8859/7

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

ИСО 8859/8

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

ИСО 8859/9

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

JAS2020

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

JIS X 0202

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

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


ACR

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

СРТ4

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

CAS

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

EUCLIDES

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

Home Health

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

HIBCC

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

ICCS

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

ICD-9

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

ICD9-CM

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

NANDA

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

NDC

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

NIC

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

NLM

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

Omaha System

Omaha Visiting Nurse Association, Omaha NE

Read

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

SNOMED III

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

WHO

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

UMDNS

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

FDA K10

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

LOINC

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Anita Benson Litchfield, СТ email: an-benson@snet.net

Dan Russler McKessonHBOC Alpharetta, GA email: dan.russler@hboc.com

Karen Van Hentenryck Health Level Seven Ann Arbor, Ml email: Karen-van@hl7.org

Mike Henderson Kaiser Permanente Silver Spring, MD email: mike_henderson_2000@yahoo.com

Frank Oemig Ringholm GmbH #11; Essen, Germany email: Frank.Oemig@ringholm.de

Klaus Veil HL7 Australia Avalon, Australia email: Kveil@compuserve.com

Joann Larson Kaiser Permanente Walnut Creek, CA email: joann.larson@kp.org

Helen Stevens McKessonHBOC Alpharetta, GA email: Helen.stevens@hboc.com

Kathleen Yanik Health Level Seven Ann Arbor, Ml email: Kyanik@HL7.org

Jim Kingsland McKessonHBOC Lake Mary, FL email: jim.kingsland@itb.mckhboc.com

Wayne Tracy Health Patterns Overland Park, KS email: wrtracy@worldnet.att.net

     

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


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

Karen Van Hentenryck Associate Executive Director Health Level Seven 3300 Washtenaw Avenue, Suite 227 Ann Arbor, Ml 48104-4261

Phone: (734) 677-7777

Fax: (734) 677-6622

email: hq@hl7.org

Wes Rishel Chair, HL7 Board of Directors Gartner 970 Post Street Alameda, СA 94501 Phone: (510) 522-8135 Fax: (510) 521-2423 email: Wes.Rishel@Gartner.com

John Quinn Technical Chair HL7 Working Group CAP Gemini Ernst & Young U.S., L.L.P 1660 W. Second St. Suite 1200 Cleveland, OH 44113-1454 (216) 737-1242 email: john.quinn@cgey.com

     

     2 Управление


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

Mike Henderson, Eastern Informatics.

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

Doug Pratt, Siemens Medical Solutions Health Services Corporation.

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

Larry Reis, Consultant.

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

Mark Shafarman, Oracle.

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

Joann Larson, Kaiser Permanente.

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

Dale Nelson, Zed-Logic.

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

Mark Tucker, Regenstrief.

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

Mary Ann Juurlink, Canada Health Infoway;

Jennifer Puyenbroek, McKesson Information Solutions;

loana Singureanu, Eversolve.

     2.1 Введение


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

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

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

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

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

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

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

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

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


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

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


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

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


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

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

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

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

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


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

2.2.4 Запросы

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

2.4.1 Сообщения


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример 1

Пример 2

Пример 3

{SEG1}

[SEG1]

SEG1

SEG2

{

[SEG2]

[SEG1]

SEG2

SEG3

[SEG1]

{SEG1}

}



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

Пример 1

Пример 2

Пример 3

Пример 4

{SEG1}

{SEG1}

[SEG1]

{SEG1}

[SEG1]

[SEG2]

{

[SEG2

SEG1

[SEG2]

SEG3]

SEG1

SEG1

SEG3

}


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

2.4.3 Поля

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

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

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

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

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

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

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

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

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

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

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

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

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

- максимальная длина поля должна задаваться числом;

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

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

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

2.4.3.3 Тип данных

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

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

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

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

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

О

- обязательное (required - R);

Н

- необязательное (optional - О);

У

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

X

- не используется при данном типе события;

С

- поле оставлено в сегменте только для совместимости с предыдущими версиями стандарта HL7 (backward - В). В определении поля, которое приводится после таблицы с определением сегмента, должна быть указана обязательность этого поля в предыдущих версиях стандарта;

З

- запрещено (withdrawn - W).


Примечания

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

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

2.4.3.5 Повтор

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

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

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

Н или пусто

- без повтора (no repetition - N);

Д

- поле может повторяться неограниченное число раз либо число повторений ограничено местными соглашениями (yes - Y);

(целое число)

- число повторов может доходить до указанного значения.


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

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


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

2.4.3.6 Таблица

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Таблица 1 - Значения разделителей

Разделитель

Рекомендуемое значение

Позиция кодирующего символа

Назначение

Терминатор сегмента

<cr>
0D

Завершает запись сегмента. Это значение не должно изменяться при реализации стандарта

Разделитель полей

I

-

Разделяет два смежных поля данных сегмента. Он также отделяет идентификатор сегмента от первого поля данных сегмента

Разделитель компонентов

^

1

Разделяет смежные компоненты полей данных (если таковые имеются)

Разделитель субкомпонентов

&

4

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

Разделитель повторов

~

2

Разделяет экземпляры поля данных, если таковые имеются

Спецсимвол

\

3

Управляющий символ (Escape), используемый в текстовых полях типа ST, ТХ и FT. Если спецсимвол не используется в сообщении, он может быть опущен. Но если в сообщении есть субкомпоненты, он должен присутствовать

     

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}

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

}

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

}

завершить;

}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}

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

}

завершить;

}

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

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

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

_______________

* Здесь и далее нумерация рисунков соответствует оригиналу. - Примечание изготовителя базы данных.

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

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


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

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

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

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

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

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

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

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

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

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

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

\Н\

- начало выделения (highlighting);

\N\

- нормальный текст (normal), конец выделения;

\F\

- разделитель полей (field separator);

\S\

- разделитель компонентов (component separator);

\Т\

- разделитель субкомпонентов (subcomponent separator);

\R\

- разделитель повторов (repeate separator);

\Е\

- спецсимвол (escape character);

\Xdddd\

- шестнадцатеричные данные;

\Zdddd\

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


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

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

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

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

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

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

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

\С2842\

- ISO-IR 6 G0 (ИСО 646 : ASCII);

\C2D41\

- ISO-IR 100 (ИСО 8859 : латинский алфавит 1);

\C2D42\

- ISO-IR 101 (ИСО 8859 : латинский алфавит 2);

\C2D43\

- ISO-IR 109 (ИСО 8859 : латинский алфавит 3);

\C2D44\

- ISO-IR 110 (ИСО 8859 : латинский алфавит 4);

\C2D4C\

- ISO-IR 144 (ИСО 8859 : русский алфавит);

\C2D47\

- ISO-IR 127 (ИСО 8859 : арабский алфавит);

\C2D46\

- ISO-IR 126 (ИСО 8859 : греческий алфавит);

\C2D48\

- ISO-IR 138 (ИСО 8859 : древнееврейский алфавит);

\C2D4D\

- ISO-IR 148 (ИСО 8859 : латинский алфавит 5);

\C284A\

- ISO-IR 14 (JIS X 0201-1976: Romaji);

\C2949\

- ISO-IR 13 (JIS X 0201 : Katakana).


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

\М2442\

- ISO-IR 87 (JIS X 0208 : Kanji, hirigana и katakana);

\М242844\

- ISO-IR 159 (JIS X 0212 : дополнительный набор Kanji).

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


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

DSP| ХОЛЕСТЕРИН ОБЩИЙ \H\240*\N\ [90-200]

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

ХОЛЕСТЕРИН ОБЩИЙ 240* [90-200]

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

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


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

DSP | ХОЛЕСТЕРИН ОБЩИЙ 180 \F\90-200\F\

DSP | \S\ - - - - - - - - - - - - - - \S\

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

ХОЛЕСТЕРИН ОБЩИЙ 180 |90-200|

^- - - - - - - - - - - - - -^.

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


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

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

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

.sp <число>

- завершить вывод текущей строки и сделать <число> вертикальных пропусков, где <число> - положительное число. Если <число> отсутствует, то сделать один вертикальный пропуск. Горизонтальная позиция вывода остается неизменной. Имейте в виду, что для совместимости с предыдущими версиями стандарта HL7 последовательность "^\.sp\" должна быть эквивалентна последовательности "\.br\";

.br

- начать вывод новой строки. (Горизонтальная позиция устанавливается на левое поле, а вертикальная увеличивается на 1.);

.fi

- перейти в режим переноса слова целиком на другую строку (word wrap). Этот режим устанавливается по умолчанию. Он может быть отменен с помощью команды .nf;

.nf

- отменить режим переноса слов целиком на другую строку;

.in <число>

- установить отступ на <число> пробелов, где <число> - положительное или отрицательное целое. Эта команда не может быть дана после вывода первого печатаемого символа текущей строки;

.ti <число>

- установить временный отступ на <число> пробелов, где <число> - положительное или отрицательное целое. Эта команда не может быть дана после вывода первого печатаемого символа текущей строки.

.sk <число>

- Отступить на <число> позиций вправо;

.се

- завершить текущую строку и отцентрировать следующую строку.


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

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

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

          

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

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

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

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

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


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

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


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

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

- новые приложения должны быть способны понимать старые сообщения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- сообщение или составная часть сообщения заменены на более лучший метод.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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


Таблица 2 - Общая схема обмена сообщениями

Шаг

Процесс

Примечание

1

Инициирующая система составляет из прикладных данных сообщение стандарта HL7 и посылает его реагирующей системе

2

Реагирующая система получает сообщение и обрабатывает его в соответствии с правилами

Правила зависят от того, применяется ли исходный режим подтверждения или расширенный режим подтверждения

3

Реагирующая система отправляет ответное сообщение

4

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

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

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


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

Поле

Примечание

MSH-3 "Приложение-отправитель"


MSH-4 "Учреждение-отправитель"


MSH-5 "Приложение-получатель"


MSH-6 "Учреждение-получатель"


MSH-7 "Дата и время сообщения"


MSH-9 "Тип сообщения"


MSH-10 "Идентификатор сообщения"

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

MSH-11 "Тип прикладной обработки"


MSH-12 "Идентификатор версии стандарта"


MSH-13 "Порядковый номер сообщения"


MSH-14 "Указатель продолжения"

Используется в реализации протокола продолжения сообщения. См. 2.10.2 "Продолжение сообщений и сегментов". См. также раздел 5


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

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

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

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

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

_______________

* Текст документа соответствует оригиналу. - Примечание изготовителя базы данных.

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

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

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

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


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

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

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

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

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

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

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

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

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


Таблица 4 - Содержание сегмента MSA

Поле

Содержание

MSA-1 "Код подтверждения"

См. приведенное выше описание

MSA-2 "Идентификатор сообщения"

Значение поля MSH-10 "Идентификатор сообщения" из сегмента заголовка MSH полученного сообщения

MSA-4-ожидаемый порядковый номер

В соответствии с описанием, приведенным в 2.10.1 "Протокол последовательной нумерации" (если используется этот протокол)

Поля сегмента ERR

См. 2.14.5


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Таблица 5 - Содержание сегмента MSA

Поле

Содержание

MSA-1 "Код подтверждения"

См. приведенное выше описание

MSA-2 "Идентификатор сообщения"

Значение поля MSH-10 "Идентификатор сообщения" из сегмента заголовка MSH полученного сообщения

MSA-4-ожидаемый порядковый номер

В соответствии с описанием, приведенным в 2.10.1 "Протокол последовательной нумерации" (если используется этот протокол)

Поля сегмента ERR

См. 2.14.5


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

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

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

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

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


Таблица 6 - Содержание сегмента MSA

Поле

Содержание

MSA-1 "Код подтверждения"

Один из кодов подтверждения прикладной обработки, описанных в подразделе 2.14.8.1

MSA-2 "Идентификатор сообщения"

Значение поля MSH-10 "Идентификатор сообщения" из сегмента заголовка MSH исходного сообщения в соответствии с описанием, приведенным в 2.9.1 "Инициация сообщения"

MSA-3 "Текст сообщения"

Текстовое описание ошибки

ERR-1 "Код и место ошибки"

В соответствии с описанием, приведенным в 2.14.5.1. Заполняется, если выявлена ошибка прикладной обработки


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

А | 1

В | 2

С | 34

ADD | 5 | 678 |

ADD | 90

D | 1

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

А | 1

В | 2

С | 345 | 678 | 90

D | 1

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

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

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

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

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

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

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

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

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

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

Примечания

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

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


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

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

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

MSH | | | | | | | | | 1001 | | 2.4 | 123 | | . .

А | _

B | _

DSC | W4xy

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

MSH | | | | | | | | | 2106 | | 2.4 | 124 | W4xy |

C | _

D | _

DSC | V292

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

MSH | | | | | | | | | 2401 | | 2.4 | 125 | V292

E | _

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

MSH | _. | 2.4 | 123 | | . .

А | _

В | _

С | _

D | _

Е | _

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

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

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

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

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

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

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

MSH | _ | 2.4 |

ANY | 12

ADD

DSC | JR97

- - - - - - - - - (фрагмент 2)

MSH | _ | 2.4 | JR97

ADD | 345

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

MSH | _ | 2.4

ANY | 12345

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

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

MSH

URD

[URS]

{DSP}

(последний сегмент DSP не завершен)

ADD

(не содержит полей)

DSC

(сегмент продолжения)


MSH

(общее подтверждение)

MSA

[ {ERR} ]



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

MSH

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

ADD

(содержит остаток данных продолжаемого сегмента DSP предыдущего сообщения)

{DSP}


MSH

(общее подтверждение)

[ {SFT} ]


MSA


[ {ERR} ]



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

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

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

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

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

[FHS]

(сегмент заголовка файла)

{

- - - Начало пакета

[BHS]

(сегмент заголовка пакета)

{ [

- - - Начало сообщения

MSH

(нуль или более сообщений стандарта HL7)

....


....


....


] }

- - - Конец сообщения

[BTS]

(сегмент конца пакета)

}

- - - конец пакета

[FTS]

(сегмент конца файла)


Примечания

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

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

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


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

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

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

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

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

- BHS "Заголовок пакета" (См. 2.14.2);

- BTS "Конец пакета" (См. 2.14.3);

- FHS "Заголовок файла" (См. 2.14.6);

- FTS "Конец файла" (См. 2.14.7).

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

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

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

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

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

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

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

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

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

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

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

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

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

[FHS]

(сегмент заголовка файла)

{ [BHS]

(сегмент заголовка пакета)

[QRD]

(сегменты QRD и QRF содержат определение запроса,

[QRF]

на который данный пакет служит ответом)

{ MSH

(одно или более сообщений стандарта HL7)

….


….


….


}


[BTS]

(сегмент конца пакета)

}


[FTS]

(сегмент конца файла)

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

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

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

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

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

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

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

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

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

DG1 | " " | " " | " " | " " | " " | " " | " " | " " | " " | " " | " " | " " | " " | " " | " " | " " | " " | " " | " " <cr>

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

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

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


Таблица HL7 0206 - Код действия с сегментом

Код

Значение (в оригинале)

Значение (перевод)

Описание

А

Add

Добавить/вставить

D

Delete

Удалить

U

Update

Изменить


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

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

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


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

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

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


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

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

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

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

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

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

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

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


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

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


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

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

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

Примеры

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


{

АВС

[DEF

[GHI] ]

}

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


{ [АВС] }

[DEF]

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

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


GROUP1 : := ABC, GROUP2?

GROUP2 : := DEF, GHI?

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


{ [

АВС

DEF

[GHI]

] }

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


<GROUP1>

<АВС/>

<GROUP2>

<DEF/>

<GHI/>

</GROUP2>

</GROUP1>

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


<GROUP1>

<АВС/>

<DEF/>

<GHI/>

</GROUP1>

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

NN

Имя элемента рубрики

Значение

1

Идентификатор рабочей группы соответствия (Conformance SIG)

confsig

2

Идентификатор организации

Сокращенная версия названия организации

3

Версия стандарта HL7

Допустимые значения см. в таблице HL7 0104 "Идентификатор версии"

4

Тип рубрики

profile

5

Подтверждение приема

Условие возвращения подтверждения приема (допустимые значения см. в таблице HL7 0155 "Условия подтверждения приема/прикладного подтверждения")

6

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

Условие возвращения подтверждения прикладной обработки (допустимые значения см. в таблице HL7 0155 "Условия подтверждения приема/прикладного подтверждения")

7

Режим подтверждения

Deferred (отложенный) или Immediate (немедленный)


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

confSig-MyOrganization-2.4-profile-AL-NE-Immediate

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


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

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

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

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

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

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

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

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

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

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

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

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

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

     

    

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

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

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

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

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

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

a) всегда,

b) никогда,

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

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

2.11.4 Статическое определение

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

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

В статическом определении явным образом указаны:

a) правила использования сегментов, групп сегментов, полей и компонентов;

b) кратности;

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

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

    
Рисунок 7 - Иллюстрация статического определения

2.11.4.1 Идентификатор статического определения

В целях регистрации каждое статическое определение должно иметь уникальный идентификатор. (См. 2.12.9 "Документ профиля сообщений".) Он может быть присвоен не регистром определений, а другой уполномоченной организацией. Если в момент регистрации статическое определение еще не имеет идентификатора, присвоенного уполномоченной организацией, представляющей определение в регистр, то он будет присвоен уполномоченной организацией, ответственной за ведение регистра. Идентификатор статического определения должен совпадать с тем, который используется, когда система объявляет о строгом соответствии стандарту. (См. описание поля MSH-21 "Идентификатор профиля сообщений" (EI) 01598.)

2.11.4.2 Рубрики публикации/подписки статического определения

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

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

Элементы рубрик публикации/подписки статического определения перечислены в таблице 8.


Таблица 8 - Элементы рубрик публикации/подписки статического определения

NN

Имя элемента рубрики

Значение

1

Идентификатор рабочей группы соответствия (Conformance SIG)

confsig

2

Идентификатор организации

Сокращенная версия названия организации

3

Версия стандарта HL7

Допустимые значения см. в таблице HL7 0104 "Идентификатор версии"

4

Тип рубрики

static

5

Код типа сообщения

Допустимые значения см. в таблице HL7 0076 "Тип сообщения"

6

Тип события

Допустимые значения см. в таблице HL7 0003 "Тип события" (эта таблица может быть дополнена местными кодами Z-событий)

7

Код управления заказом

Допустимые значения см. в таблице HL7 0119 "Коды управления заказом"

8

Тип структуры сообщения

Допустимые значения см. в таблице HL7 0354 "Структура сообщения" (эта таблица может быть дополнена местными кодами Z-событий)

9

Версия спецификации

Номер версии прикладной программы, интерфейса или спецификации

10

Статус спецификации

Статус прикладной программы, интерфейса или спецификации

11

Роль

Sender (отправитель) или Receiver (получатель)


Пример рубрик публикации/подписки статического определения:

confsig-MyOrganization-2.4-static-ADT-A04 - - ADT_A01-v2-draft-Sender

2.11.5 Тип профиля

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

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

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

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

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

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

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

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

2.11.5.1 Профили, ограничиваемые разработчиком

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

2.11.5.2 Профили, ограничиваемые местом применения

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

a) AS4700.1-2001 Implementation of HL7 v2.3.1 Part 1:Patient Administration (ограничиваемый профиль, сконструированный для применения в Австралии. В него входят сообщения, определенные в главе 3 стандарта HL7 версии 2.3.1);

b) AS/NZS 4700.3-1999 Implementation of HL7 v2.3 Part 3: Electronic messages for exchange of information on Drug Prescription (ограничиваемый профиль, сконструированный для применения в Австралии. В него входят сообщения, определенные в различные главах стандарта HL7 версии 2.3).

2.11.5.3 Реализуемые профили

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

a) Adverse Drug Reaction Implementers Specification, 2001, TGA (реализуемый профиль, ограничивающий австралийские стандарты и ограничиваемые профили стандарта HL7 v2.3.1 в проекте Therapeutic Goods Administration ADRAC Messaging Implementation);

b) Diabetes Reporting Implementers Specification, 2001, UNSW (реализуемый профиль, ограничивающий австралийские стандарты и ограничиваемые профили стандарта HL7 v2.3.1 в проекте Diabetes Messaging Implementation университета NSW);

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

2.11.6 Понятия статического определения

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

2.11.6.1 Кратность

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

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


Таблица 9 - Примеры спецификаций кратности

Значение

Описание

Примечание

[0..0]

Элемент всегда отсутствует

[0..1]

Элемент может отсутствовать или иметь не более одного экземпляра

[1..1]

Элемент должен присутствовать ровно в одном экземпляре

[0..n]

Элемент может отсутствовать или иметь до n экземпляров

[1..n]

Элемент должен присутствовать как минимум один раз, и может иметь до n экземпляров

[0..*]

Элемент может отсутствовать или иметь неограниченное число экземпляров

[1..*]

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

[m..n]

Элемент должен иметь не менее "m" и не более "n" экземпляров

2.11.6.2 Использование

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

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


Таблица 10 - Коды использования

Значение

Описание

Примечание

О

Обязательный

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

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

ОП

Обязательный, но может быть пустым

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

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

Н

Необязательный

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

У

Условный

С этим кодом использования связан предикат условия (См. 2.12.6.6 "Предикат условия").

Если предикат истинен, то приложение