allgosts.ru35.240 Применение информационных технологий35 ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

ГОСТ Р ИСО 13606-1-2011 Информатизация здоровья. Передача электронных медицинских карт. Часть 1. Базовая модель

Обозначение:
ГОСТ Р ИСО 13606-1-2011
Наименование:
Информатизация здоровья. Передача электронных медицинских карт. Часть 1. Базовая модель
Статус:
Действует
Дата введения:
08.01.2012
Дата отмены:
-
Заменен на:
-
Код ОКС:
35.240.80

Текст ГОСТ Р ИСО 13606-1-2011 Информатизация здоровья. Передача электронных медицинских карт. Часть 1. Базовая модель


ГОСТ Р ИСО 13606-1-2011

Группа П85

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

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

ПЕРЕДАЧА ЭЛЕКТРОННЫХ МЕДИЦИНСКИХ КАРТ

Часть 1

Базовая модель

Health informatics. Electronic health record communication. Part 1. Reference model



ОКС 35.240.80
ОКСТУ 4002

Дата введения 2012-08-01


Предисловие


Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 "Стандартизация в Российской Федерации. Основные положения"

Сведения о стандарте

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

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

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

4 Настоящий стандарт идентичен международному стандарту ИСО 13606-1:2008* "Информатизация здоровья. Передача электронных медицинских карт. Часть 1. Базовая модель" (ISO 13606-1:2008 "Health informatics - Electronic health record communication - Part 1: Reference model").
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить перейдя по ссылке на сайт . - .


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

5 ВВЕДЕН ВПЕРВЫЕ


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

Введение

Введение


Комплекс стандартов ИСО 13606 состоит из следующих частей под общим заголовком "Информатизация здоровья. Передача электронных медицинских карт":

- часть 1: "Базовая модель";

- часть 2: "Спецификация передачи архетипов";

- часть 3: "Базовые архетипы и списки терминов";

- часть 4: "Безопасность";

- часть 5: "Спецификация интерфейсов".

0.1 Преамбула

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

Комплекс стандартов ИСО 13606 не предназначен для определения внутренней архитектуры или структуры баз данных систем ведения ЭМК или их компонентов, а также для спецификации типов медицинских приложений, которым могут требоваться данные ЭМК или которые могут формировать эти данные в конкретных условиях оказания медицинской помощи, в сети медицинских организаций или в специализированных медицинских организациях. Поэтому предложенная в данном комплексе информационная модель называется "выписка из ЭМК", и она может использоваться для определения сообщения, документа или схемы XML либо интерфейса объекта. Информационная модель, определенная в настоящем стандарте, описывает информационную точку зрения на выписку из ЭМК в терминах базовой модели ИСО для открытой распределенной обработки (БМ-ОРО).

В комплексе стандартов 13606 предполагается, что ЭМК - это документ, длительно существующий, потенциально охватывающий данные, собираемые в разных учреждениях и странах, отражающий состояние здоровья и лечения отдельного субъекта (пациента), созданный и хранящийся в одной или нескольких физических системах в целях предоставления информации при будущем лечении данного субъекта и медико-юридической регистрации уже оказанной медицинской помощи. Хотя службе или системе ведения ЭМК требуется взаимодействовать со многими другими службами или системами, предоставляющими терминологию, медицинские знания, инструкции, обеспечивающими организацию выполнения работ, безопасность, ведение регистров физических лиц, выставление счетов на оплату лечения и многое другое, комплекс стандартов ИСО 13606 затрагивает только те взаимодействия с внешними службами или системами, информацию о которых необходимо сохранять длительное время в самой ЭМК, и для обеспечения соответствующих обменов данными предусматривает специфические характеристики в базовой модели.

Комплекс стандартов ИСО 13606 может внести практический вклад в архитектуру систем ведения ЭМК, но он будет реализован в основном в виде общего набора внешних интерфейсов или сообщений, встроенного в другие гетерогенные медицинские системы.

Настоящий стандарт является первым из пяти стандартов данного комплекса. Использование в настоящем стандарте положений других стандартов комплекса ИСО 13606 указано в явном виде в соответствующих местах текста.

0.2 Технический подход

Комплекс стандартов ИСО 13606 создан на основе практического опыта, накопленного в результате внедрения его европейского предшественника ENV 13606, других стандартов и спецификаций, относящихся к ЭМК, коммерческих систем и демонстрационных пилотных проектов передачи ЭМК пациентов частями или в целом, а также проводившихся исследований в данной области в течение 15 лет. Комплекс стандартов ИСО 13606 является развитием стандарта ENV 13606, обеспечивая более четкую и полную спецификацию, учет вновь выявленных требований, использование надежных средств применения типовых моделей к отдельным медицинским предметным областям и возможность обмена сообщениями, определенными в стандарте HL7, версия 3. Кроме того, для удобства разработчиков систем, соответствующих стандарту ENV 13606, комплекс стандартов ИСО 13606 содержит отображение элементов данных, описанных в стандарте ENV 13606, на настоящий стандарт. При техническом подходе к созданию комплекса стандартов ИСО 13606 были приняты во внимание несколько групп требований.

а) Наряду с применением традиционного обмена информацией в форме сообщений между изолированными медицинскими системами в некоторых случаях система ведения ЭМК будет реализована как компонент промежуточного уровня (сервер приложений) с использованием технологии распределенных объектов и/или веб-сервисов.

b) "Потребителями" таких серверов приложений будут не только другие системы ведения ЭМК, но и другие службы промежуточного уровня, например компоненты безопасности, системы управления рабочими процессами, службы выдачи предупреждений и поддержки принятия решений, а также другие службы предоставления медицинских знаний.

c) К данной работе проявлен широкий международный интерес, и настоящий стандарт является совместной работой комитета СЕМ и организации ИСО, при этом многие страны-участницы внесли существенный вклад в его формирование.

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

e) Поскольку с 1999 г. научно-исследовательские работы (НИОКР), положенные в основу стандарта ENV 13606, продвинулись далеко вперед, то при разработке настоящего стандарта были приняты во внимание важные новые результаты в данной области. Например платформа "open EHR", интегрирующая результаты НИОКР, проведенных в Европе и Австралии.

Учитывая разнообразие развернутых систем ЭМК, в комплексе стандартов ИСО 13606 большинство характеристик передачи ЭМК определены как факультативные, а не обязательные. Однако для безопасной обработки выписок из ЭМК системой-получателем некоторая степень обязательности все же требуется, что нашло свое отражение в обязательных свойствах объектов, моделируемых в частях 1, 2 и 4 комплекса стандартов ИСО 13606, а также в списках нормативных терминов, определенных в части 3.

На практике комплекс стандартов ИСО 13606 будет согласовываться с другими стандартами в области информатизации здоровья, определяющими конкретные аспекты представления медицинских данных. В приложении В поясняется, как комплекс стандартов ИСО 13606 может использоваться совместно с дополнительными стандартами, включая базовую информационную модель (RIM) стандарта HL7, версия 3, стандарты ЕН 14822-1, ЕН 14822-2, ЕН 14822-3, CEN/TS 14822-4 (GPIC), prEN 12967 (HISA) и prEN 13940 (CONTSYS).

0.3 Подход на основе дуальной модели

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

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

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

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

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

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

0.4 Базис требований настоящего стандарта

В начале 90-х годов специалисты пришли к выводу, что для обмена произвольной медицинской информацией между системами необходимо обобщенное представление данных. В Европе это вылилось в ряд научно-исследовательских проектов, финансируемых ЕС, и в два поколения стандартов CEN по информатизации здоровья, предшествовавших настоящему международному стандарту. Эти проекты и стандарты задумывались для определения общих характеристик информации ЭМК и для их включения в информационные модели и модели сообщений, предусматривающие стандартный интерфейс между медицинскими информационными системами. Подобные работы были призваны предоставить такой стандартизованный способ передачи целой ЭМК или ее части между различными и специализированными медицинскими информационными системами, который мог бы обеспечить точное и общее представление значений данных и контекстуальной организации информации в любой исходной системе ведения ЭМК. При этом преследовалась дополнительная цель - учесть процесс непрерывного развития медицинских знаний и разнообразие, присущее клинической практике.

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

- достоверное представление исходного смысла, который имел в виду автор подраздела ЭМК или совокупности подразделов;

- предоставление базовых средств, соответствующих потребностям специалистов и организаций в анализе и интерпретации ЭМК отдельного пациента или целой популяции;

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

К числу таких исследований относятся проекты GEHR [41, 48, 57], EHCR-SupA [36-38], Synapses [42, 43] и Nora, а также работа, выполненная в Шведском институте развития служб здравоохранения (SPRI). Публикации, посвященные ключевым требованиям, выявленным в этих проектах, перечислены в разделе "Библиография" работы [51]. Эти требования недавно были объединены на международном уровне в документе ИСО/ТС 18308 [9].

В данной базовой модели ключевые контекстно-зависимые требования к достоверному представлению ЭМК связаны с совокупностью базовых логических классов, обладающих необходимыми атрибутами, предложенными для каждого уровня иерархии элементов выписки из ЭМК. В качестве основы для описания свойств данной базовой модели передачи ЭМК были выбраны требования, изложенные в стандарте ИСО/ТС 18308. Отображение формулировок этих требований на конструкции базовой модели представлено в приложении D.

0.5 Обзор иерархии элементов выписки из ЭМК

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

Чтобы обеспечить достоверное представление исходного медицинского контекста и сохранить его смысл при передаче ЭМК между гетерогенными медицинскими системами, базовая модель выписки из ЭМК должна отражать эту иерархическую структуру и организацию информации и удовлетворять поставленным требованиям. Поэтому в предлагаемой модели иерархия элементов ЭМК формально разделяется на компоненты, для которых найдено единообразное отображение на способы организации отдельных ЭМК в гетерогенных системах ведения ЭМК. Эти компоненты представлены в таблице 1.


Таблица 1 - Основные компоненты иерархии базовой модели выписки из ЭМК

Компонент иерархии элементов ЭМК

Описание

Примеры

EHR_EXTRACT (выписка из ЭМК)

Контейнер верхнего уровня для части или всей ЭМК одного субъекта медицинской помощи, предназначенный для передачи данных получателю ЭМК от системы поставщика ЭМК

Нет

FOLDER (том)

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

Лечение диабета, шизофрении, холецистэктомия, педиатрия, в госпитале Св. Мунго, папка врача общей практики, эпизоды лечения в 2000-2001 гг., в Италии

COMPOSITION (композиция)

Совокупность данных, отправленных в ЭМК одним агентом в результате одного приема у врача или сеанса документирования

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

SECTION (раздел)

Данные ЭМК, содержащиеся в композиции COMPOSITION, сгруппированные под одним клиническим заголовком, обычно отражающие поток информации, собранной во время одного обращения к врачу, или структурированные для улучшения будущего восприятия человеком

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

ENTRY (подраздел)

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

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

CLUSTER (кластер)

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

Результаты аудиограммы, расшифровка электроэнцефалограммы, взвешенные дифференциальные диагнозы

ELEMENT (элемент)

Конечный узел иерархии элементов ЭМК, содержащий одно значение данных

Систолическое кровяное давление, частота пульса, название лекарства, симптом, масса тела



Объект EHR_EXTRACT содержит данные ЭМК в форме композиций COMPOSITION, которые могут быть организованы как иерархия томов FOLDER.

Композиции COMPOSITION содержат подразделы ENTRY, которые могут быть сгруппированы в форме иерархии разделов SECTION.

Подразделы ENTRY содержат элементы ELEMENT, которые могут быть сгруппированы в форме иерархии кластеров CLUSTER.

Рисунок 1 - Схема иерархии элементов выписки из ЭМК (часть 1)


Рисунок 1 - Схема иерархии элементов выписки из ЭМК (часть 1)

Рисунок 2 - Схема иерархии выписки из ЭМК (часть 2)


Рисунок 2 - Схема иерархии выписки из ЭМК (часть 2)

0.6 Описание основных классов базовой модели

Класс EHR_EXTRACT

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

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

Класс EHR_EXTRACT содержит данные ЭМК, представленные в трех формах:

1) совокупность композиций COMPOSITION;

2) факультативно каталог томов FOLDER, обеспечивающий верхние уровни группировки и организации композиций COMPOSITION;

3) факультативно совокупность демографических данных каждого лица, сведений об организации, приборе или компоненте программного обеспечения, идентифицированных в формах 1 и 2. Это позволяет включать в ЭМК ссылки на подобные объекты в виде уникального идентификатора, не повторяя каждый раз детали описания этих объектов. При таком подходе любая выписка EHR_EXTRACT может быть интерпретирована изолировано, даже если система получателя не имеет доступа к службам, необходимым для декодирования идентификаторов объектов, использованных поставщиком ЭМК.

Формальный механизм включения информации о политике доступа в выписку EHR_EXTRACT определен в стандарте ИСО 13606-4. Данная информация позволяет ознакомить получателя ЭМК с требованиями субъекта и поставщиков медицинской помощи о том, как должны обрабатываться в будущем запросы на доступ к данным ЭМК.

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

Класс RECORD_COMPONENT

Основными классами строительных блоков, используемых для построения иерархии данных ЭМК в выписке EHR_EXTRACT, являются подтипы абстрактного класса RECORD_COMPONENT, служащего родителем всех конкретных узлов иерархии ЭМК: тома FOLDER, композиции COMPOSITION, раздела SECTION, подраздела ENTRY, кластера CLUSTER, элемента ELEMENT. Он является также родителем двух других абстрактных классов: содержания CONTENT и сущности ITEM.

Абстрактный класс RECORD_COMPONENT определяет характеристики, общие для всех этих строительных блоков, в том числе:

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

- медицинское наименование, использованное в исходной системе ведения ЭМК для обозначения данной части данных ЭМК;

- факультативно, стандартизованное кодированное понятие, на которое это наименование было отображено. Это позволяет обеспечить семантическую интероперабельность эквивалентных экземпляров ЭМК даже в том случае, если им были присвоены разные медицинские наименования в разных системах ведения ЭМК;

- идентификатор узла архетипа, которому соответствует данный класс RECORD_COMPONENT. Этот идентификатор может использоваться либо в системах ведения ЭМК, построенных на основе архетипов, либо для указания того, что архетипы использовались при отображении данных в формат выписки EHR_EXTRACT;

- код чувствительности и ссылки на политики контроля доступа, которые должны использоваться получателем ЭМК для управления последующим доступом к данным;

- средства обеспечения связи между любыми компонентами выписки из ЭМК.

При создании выписки EHR_EXTRACT, соответствующей настоящему стандарту, система поставщика ЭМК может в некоторых случая потребовать, чтобы в иерархию данных выписки был включен класс RECORD_COMPONENT, не имеющий прямого соответствия с какими-либо исходными данными в системе ведения ЭМК. Атрибут synthesised класса RECORD_COMPONENT позволяет экспортирующей системе поставщика ЭМК указать, что класс RECORD_COMPONENT был создан в выписке EHR_EXTRACT для этой цели.

Разделы медицинских карт нередко ссылаются на другие, ранее существовавшие разделы и включают их как "копии". Типичным примером является выписной эпикриз, который может включать в себя копии нескольких частей карты стационарного больного, например обстоятельства госпитализации, основные диагнозы, главные вмешательства и лечебные процедуры. В большинстве случаев требуется включать экземпляры подобных классов RECORD_COMPONENT в выписку EHR_EXTRACT по значению, чтобы каждая композиция COMPOSITION могла быть интерпретирована получателем ЭМК. Однако для медико-правового контроля также важно знать, что эти разделы являются копиями разделов другой части ЭМК данного субъекта. Если эти данные являются копией, то для указания идентификатора rc_id исходного родительского класса RECORD_COMPONENT можно использовать необязательный атрибут original_parent_ref.

Любой класс RECORD_COMPONENT может содержать регистрацию данных о том, кем и когда он был создан в исходной системе ведения ЭМК. В каждой новой версии экземпляра класса RECORD_COMPONENT могут документироваться статус версии, причина пересмотра и идентификатор предыдущей версии. Однако для защиты данных, как правило, рекомендуется, чтобы при обычном обмене медицинскими данными в целях преемственности лечения предыдущие (неправильные) версии ЭМК не пересылались. Их надо передавать только в целях медико-правового контроля.

Важно, чтобы каждый экземпляр класса RECORD_COMPONENT был уникально и единообразно идентифицирован в многократных выписках EHR_EXTRACT. Тогда ссылки на такой экземпляр или между экземплярами останутся действительными. Примерами подобных ссылок являются семантические связи, пересмотр и аттестация. Атрибут rc_id имеет тип данных Instance Identifier (II) (идентификатор экземпляра), в который входит объектный идентификатор (ОИД) ветви идентификаторов ИСО. Тип данных II в настоящее время рассматривается международным сообществом как наиболее подходящий для постоянных идентификаторов, которые должны быть глобально уникальными. Как правило, в современных системах ведения ЭМК глобально уникальные экземпляры типа данных II непосредственно не используются в качестве первичных ключей или внутренних идентификаторов объектов. Однако система поставщика ЭМК, которой был присвоен ОИД организации, может использовать свои внутренние идентификаторы для построения уникальных местных расширений этого ОИД и таким способом создавать глобально уникальные значения атрибута rc_id. В качестве альтернативы она может создать совершенно новые значения атрибутов rc_id и сохранять их отображения на каждый внутренний идентификатор, чтобы любые будущие выписки EHR_EXTRACT, которые будут ею извлечены, использовали согласованные значения атрибутов rc_id. Трудно рассчитывать, что система получателя ЭМК сможет использовать полученные значения атрибута rc_id в качестве своих внутренних первичных ключей данных, поскольку каждая система управления базами данных использует немного отличающийся подход к генерации и использованию таких ключей. Поэтому получателю ЭМК может также потребоваться хранить отображение импортированных значений атрибута rc_id на свои первичные ключи, чтобы будущие ссылки на полученные экземпляры класса RECORD_COMPONENT могли быть надлежащим образом разрешены. Кроме того, он может создавать свои выписки EHR_EXTRACT, в которые эти значения атрибута rc_id будут снова включены для целей экспорта. Альтернативный подход в системах ведения ЭМК заключается в прямом хранении значений атрибутов rc_id вместе с медицинскими данными, рассматривая их как часть "полезной" нагрузки, но не используя в качестве первичных ключей. Необходимо также отметить, что в выписке EHR_EXTRACT атрибут rc_id не является эквивалентом первичного ключа, т.е. повторы значений атрибутов rc_id допустимы, если каждый экземпляр действительно ссылается на ту же самую часть медицинских данных в системе ведения ЭМК поставщика.

Класс FOLDER

Данный класс используется для представления верхних уровней структуры данных ЭМК в выписке EHR_EXTRACT, например для группировки композиций COMPOSITION по эпизодам, бригадам врачей, клинической специальности, условиям оказания медицинской помощи или интервалам времени. В международном масштабе данный вид организующей структуры используется по-разному: в некоторых учреждениях и системах понятие тома (folder) трактуется как неформальное разделение медицинской карты на отдельные части; в других он может представлять юридически значимую часть ЭМК, описывающую услуги, предоставленные учреждением или бригадой.

В выписке EHR_EXTRACT с помощью томов FOLDER создается необязательная иерархия. Тома FOLDER могут содержать другие тома FOLDER, образуя полную систему каталога, и они могут содержать любую необходимую информацию об их создании или изменении в системе поставщика ЭМК. Тома FOLDER содержат композиции COMPOSITION не по значению, а по ссылке, с помощью списка уникальных идентификаторов. Это позволяет любой композиции COMPOSITION присутствовать более чем в одном томе FOLDER, что является требованием, предъявляемым некоторыми поставщиками и органами власти.

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

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

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

Класс COMPOSITION

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

Составителем композиции является посредник (сторона, прибор или программное обеспечение), ответственный за создание, синтезирование или организацию информации, отправляемой в ЭМК. Такой посредник несет ответственность за включение информации в данную ЭМК, даже если он не является ее источником или отправителем. Содержание композиции COMPOSITION первоначально определяется таким составителем. Замена составителя при редактировании композиции не обязательна. Приложения обычно маркируют данные композиции COMPOSITION именем составителя, когда эти данные используются при оказании медицинской помощи. Бывают случаи, когда главного составителя нет (например, при телеконсультации, в которой участвуют врачи разных специальностей, или при проведении конференции), в подобных случаях роль составителя не может быть формально определена, даже если каждый участник и его медицинская роль установлены. Поэтому наличие составителя не является обязательным.

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

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

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

Класс Contribution (вклад)

Класс Contribution является совокупностью композиций COMPOSITION, отправленных одним пользователем в один момент времени в ЭМК одного субъекта медицинской помощи. Некоторые медицинские приложения содержат сложные экранные формы, позволяющие одновременно представлять несколько частей ЭМК (например, с помощью вкладок). Сохраняя содержание экранной формы, пользователь реально может отправить данные в несколько частей ЭМК пациента (например, добавить в какие-то части ЭМК новое заключение консультанта и пересмотренное лекарственное назначение). Объект Contribution охватывает все изменения и модификации, сделанные пользователем в этой ЭМК в течение данного сеанса. Все композиции COMPOSITION, составляющие один объект Contribution, могут быть совместно идентифицированы общим значением атрибута contribution_id.

Класс SECTION

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

Классы SECTION (разделы) могут использоваться для представления дерева медицинских заголовков, используемых в системе поставщика ЭМК для группировки и организации элементов данных в композиции COMPOSITION. Каждый раздел SECTION может содержать дополнительные разделы SECTION и/или подразделы ENTRY.

Класс ENTRY

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

- информация в подразделе ENTRY может относиться и не к пациенту (например, к родственнику): подраздел ENTRY определяет субъекта информации;

- информация в подразделе ENTRY может быть предоставленной или классифицированной конкретным лицом: подраздел ENTRY определяет поставщика информации;

- к конкретному подразделу ENTRY могут иметь отношение другие участники;

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

- в подразделе ENTRY может быть выставлен флаг, сигнализирующий получателю ЭМК, что структура данных содержит признак некоторой неопределенности заключений или обоснований, и что при автоматической обработке этих данных необходимо принимать меры предосторожности.

Подраздел ENTRY содержит структуру данных, образованную из кластеров CLUSTER и элементов ELEMENT. Важно отметить, что подраздел ENTRY не может содержать вложенные подразделы ENTRY. Совокупность атрибутов контекста, определенных на уровне подраздела ENTRY (например, субъект информации), применяется ко всей структуре данных и не может быть переопределена.

Классы ITEM, CLUSTER и ELEMENT

Класс сущности ITEM может представлять собой реальные данные, описывающие наблюдение, предположение или действие, а также необязательные детали таких данных, описывающие метод исследования, физическое состояние пациента либо детали, способствующие процессу клинического обоснования, например ссылку на электронное руководство, систему поддержки принятия решений или иной источник знаний. Необязательный атрибут item_category позволяет различать эти категории сущностей, что может способствовать автоматизированному анализу или фильтрации сущностей ITEM в подразделе ENTRY. Система кодирования значений этого атрибута определена в комплексе стандартов ИСО 13606-3.

Информация, представленная сущностью ITEM (кластер CLUSTER или элемент ELEMENT), может быть привязана к моменту времени, не совпадающему со временем лечебного действия или его регистрации. Атрибут obs_time позволяет представлять значение даты, времени или периода с любой степенью точности. Это позволяет, например, датировать операцию только годом, проявление симптома - месяцем и годом, период занятости - точным диапазоном дат или периодом лет, привязать аритмию сердца к точному моменту времени, организовать ангиограмму в виде временного ряда изображений.

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

С помощью кластера CLUSTER можно представлять сложные структуры данных, требуемые для представления реальных значений данных обследований, медицинских заключений или указаний, состоящих из нескольких частей (вложенных). Может потребоваться представление такой структуры данных в форме таблицы, дерева или временного ряда. Примерами служат ЭКГ в нескольких отведениях, полный клинический анализ крови, исследование ахиллова рефлекса, состав внутривенного вливания.

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

Значения данных

Каждый элемент ELEMENT содержит одно значение данных, представляющее значение реального экземпляра этого класса. Оно должно иметь один из типов данных, определенных комитетом CEN (в стандарте СЕН/ТС 14796):

- текст и кодированные значения;

- количества, включая отношения, интервалы и длительность;

- даты и время;

- графические и другие типы данных MIME (например, изображение, сигнал).

При разработке настоящего стандарта принималось во внимание, что технический комитет ИСО/ТК 215 разрабатывает новый стандарт типов данных, используемых в информатизации здоровья. Предполается, что после его опубликования комитет CEN отменит стандарт СЕН/ТС 14796 в пользу этого нового стандарта. При этом потребуется обеспечить отображение типов данных CEN на новый стандарт типов данных. Это отображение должно быть также использовано для адаптации положений настоящего стандарта к новым типам данных.

Чтобы обеспечить принятие настоящего стандарта в более широком масштабе, чем юрисдикция СЕН/ТС 14967, описание типов данных атрибутов, действительно используемых в данной базовой модели (отличающихся от типов значений элементов ELEMENT), включено в настоящий стандарт в форме пакета SUPPORT. Это описание должно быть исключено после опубликования стандарта типов данных ИСО.

Примечание - Предполагается, что простые типы данных, например, Boolean (булевский), Integer (целый), должны соответствовать стандарту ИСО/МЭК 11404. В настоящем стандарте они не определяются.

0.7 Описание других основных классов базовой модели

Класс AUDIT_INFO

Согласно нормативным актам здравоохранения и защиты персональных данных необходимо документировать и отслеживать, когда и кем данные ЭМК были отправлены в систему ведения ЭМК. Важно также регистрировать изменения данных ЭМК при ее модификации и передавать эти изменения в форме выписки EHR_EXTRACT. Класс AUDIT_INFO используется при представлении этих регистрационных данных:

a) для любого класса RECORD_COMPONENT как постоянная запись о его создании в исходной системе ведения ЭМК;

b) для любой композиции COMPOSITION как запись о ее создании в системе поставщика ЭМК, которая сгенерировала данную выписку EHR_EXTRACT.

Следовательно, композиция COMPOSITION может иметь до двух наборов регистрационных данных - один, относящийся к его исходной системе ведения ЭМК (называемый "feeder_audit"), и второй, относящийся к ее последующей записи в системе поставщика ЭМК (называемый "committal"), если эти две системы разные. Однако настоящий стандарт не требует и не поддерживает передачу неопределенного числа наборов регистрационных данных каждой системе, в которой сохранена композиция COMPOSITION. Это вызвано тем, что накапливаемая совокупность наборов регистрационных данных, лишенная реальной медицинской информации, детально показывающей, какие изменения каждый раз происходили, не считается имеющей медицинское значение. Если требуется передать полную историю изменений, то в выписку EHR_EXTRACT надо включить каждую версию композиции COMPOSITION.

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

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

Для регистрации изменения данных класс AUDIT_INFO содержит статус версии, необязательную причину изменения, идентификатор непосредственно предшествующей версии, к которой были применены эти изменения, и идентификатор совокупности версий, позволяющий связывать друг с другом неупорядоченные версии, созданные в разных системах ведения ЭМК. Необязательный атрибут статуса версии указывает, была ли текущая версия на момент ее отправки черновиком (т.е. предназначалась для замены в ближайшем будущем), обновлением предшествующей черновой версии, исправлением ошибочной старой версии, либо пустой композицией COMPOSITION или разделом ENTRY, означающими логическое удаление предшествующей версии (например при ошибочном сохранении предшествующей версии не в той ЭМК). Если статус не задан, то данная версия подразумевается определяющей (первой).

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

Класс FUNCTIONAL_ROLE

Класс FUNCTIONAL_ROLE (функциональная роль) используется для представления деталей того, кто и где внес свой вклад в медицинскую помощь или в медицинскую карту субъекта медицинской помощи. Данный класс идентифицирует:

- функцию, выполненную в документируемой ситуации;

- личность агента, выполнившего данную функцию;

- способ его участия (например, лично, по телефону);

- медицинское учреждение, в котором находился агент;

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

Часть этой информации может быть опущена, если исполнитель действует не в медицинском учреждении, например, субъект медицинской помощи вводит данные в свою ЭМК из дома.

Класс ATTESTATION_INFO

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

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

В течение многих лет проходила оживленная дискуссия о том, какая информация должна сохраняться в электронных системах, чтобы:

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

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

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

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

Класс ATTESTATION_INFO содержит следующие данные об аттестации:

- дата и время проведения аттестации;

- идентификацию лица, осуществившего аттестацию, в форме ссылки на описанный выше класс FUNCTIONAL_ROLE;

- список аттестованных экземпляров класса RECORD_COMPONENT;

- факультативно, причину или юридическую значимость аттестации;

- факультативно, инкапсулированные данные (по значению или по ссылке), представляющие визуальный образ того, что в действительности видел аттестующий; в настоящее время в некоторых странах ЕС требуется, чтобы эти данные хранились в ЭМК наряду с данными в формате, пригодном для обработки.

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

Класс RELATED_PARTY

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

Данный класс может быть использован для следующих целей:

a) для идентификации лица в терминах его отношения к субъекту медицинской помощи в форме кодированного значения или текста;

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

В целях обеспечения безопасности данных не рекомендуется связывать ЭМК одного субъекта медицинской помощи с ЭМК другого субъекта (если, например, член семьи также является пациентом того же самого медицинского учреждения), но время от времени это требуется в клиниках при проведении генетической или семейной терапии, а иногда и при оказании первичной медицинской помощи. Настоящий стандарт формально не поддерживает связь между ЭМК разных субъектов медицинской помощи, но в принципе класс RELATED_PARTY можно использовать для передачи идентификаторов, являющихся действительными идентификаторами, под которыми другое лицо известно в системе поставщика ЭМК, если такое использование разрешено.

Класс LINK

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

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

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

Для маркировки каждой связи используются два атрибута:

a) грубая категория связи, которая должна иметь одно из нескольких значений, определенных в ИСО 13606-3;

b) необязательная более тонкая маркировка; справочный список кодов маркировки приведен в части 3, но могут использоваться и другие системы кодирования.

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

0.8 Обсуждение конкретных представлений

Представление ролей и ответственности в выписке EHR_EXTRACT

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

Лица, непосредственно участвующие в оказании медицинской помощи

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

Участники процесса документирования медицинской помощи в ЭМК

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

Участники, подтверждающие достоверность документов ЭМК

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

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

В настоящем стандарте (а также в других архитектурах ЭМК, например, ENV 13606 и HL7 CDA) используется следующий подход:

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

- предоставить возможность задания других конкретных участников в медицинских службах и системах, а также в отдельных экземплярах ЭМК на уровне композиций COMPOSITION или подразделов ENTRY;

- обеспечить возможность включения в ЭМК любого числа аттестаций для подписи томов FOLDER или композиций COMPOSITION или разрешить аттестацию только частей композиций COMPOSITION.

Ниже описаны некоторые конкретные роли, определенные в данной базовой модели.

Субъект медицинской помощи

Предполагается, что каждая ЭМК и, следовательно, любая выписка EHR_EXTRACT описывает состояние здоровья одного лица и оказанную ему медицинскую помощь. В терминах защиты данных это лицо является также субъектом данных. Из этого вытекают важные следствия для тех ЭМК, которые могут включать в себя сведения о разных субъектах данных (например, в случае семейного анамнеза); эти следствия рассмотрены ниже при описании субъекта информации.

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

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

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

Ведение отдельной медицинской карты для каждого плода при многоплодной беременности: этот пример часто рассматривают как ситуацию, при которой одна медицинская помощь может действительно оказываться двум или более субъектам лечения. В этих случаях представляется логичным включать копию соответствующей композиции COMPOSITION в выписку EHR_EXTRACT каждого ребенка вместо того, чтобы пытаться установить сложное соединение двух или нескольких медицинских карт, позволяющее сослаться на единственную композицию COMPOSITION, общую для этих карт. (В самих системах ведения ЭМК могут быть организованы более сложные перекрестные связи, позволяющие пользователям однократно вводить данные, которые будут логически включены в обе медицинские карты.)

"Сиамские" близнецы: по этим редким случаям велась дискуссия. В данном случае, если ЭМК ведутся отдельно для каждого близнеца, то представляется логичным и безопасным иметь копии соответствующих композиций COMPOSITION, а не создавать связи между выписками из медицинских карт, которые системы-получатели могут и не суметь безопасно обработать.

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

Идентификатор субъекта медицинской помощи в выписке EHR_EXTRACT будет ссылаться на моментальный снимок демографической информации, хранящейся у поставщика ЭМК, чтобы обеспечить возможность точной идентификации этого субъекта в регистре пациентов получателя ЭМК и/или обеспечить связь выписки EHR_EXTRACT с конкретным субъектом медицинской помощи даже в том случае, если внешние регистры пациентов недоступны. Субъект лечения определен в корне модели, в классе выписки EHR_EXTRACT.

Составитель

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

Следовательно, атрибут composer (составитель) идентифицирует лицо, которое составило данные композиции COMPOSITION, невзирая на то, кто отправил их в базу данных или аттестовал их. Композиция COMPOSITION будет считаться порожденной главным образом этим лицом. Смена составителя при редактировании содержания композиции не обязательна, поскольку принятие решения о смене зависит от степени внесенных изменений, а также от того, хочет и способна ли сторона, вносящая изменения, взять на себя основную ответственность за измененную композицию COMPOSITION в качестве ее составителя. При выводе данных на экран прикладные программы могут помечать данные композиции COMPOSITION фамилией составителя. (Роли других членов бригады, не являющихся составителями, могут быть добавлены с помощью атрибута other_participations ко всей композиции COMPOSITION либо к отдельным подразделам ENTRY.)

Отправитель данных

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

Могут возникать и другие ситуации, когда отправитель не несет ответственность за ввод данных, например, если измерительное устройство непосредственно передает данные в медицинское приложение. В таких случаях для пополнения списка участников можно использовать атрибуты information_provider или other_participations подраздела ENTRY.

Субъект информации

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

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

Атрибут subject_of_information (субъект информации) позволяет включить в подраздел ENTRY ссылку на экземпляр класса RELATED_PARTY, описывающего отношение этого субъекта к пациенту с помощью кодируемого значения и факультативно с помощью идентификатора лица (позволяющего получить информацию об этом лице из регистра лиц, являющегося частью системы ведения ЭМК).

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

Поставщик информации

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

Атрибут info_provider связывает подраздел ENTRY с классом функциональной роли FUNCTIONAL_ROLE, позволяющим описать функции участника и способ участия (по телефону, лично и т.д.). Как и в случае с субъектом информации, поставщик информации может быть или не быть формально идентифицирован в зависимости от его согласия и наличия информации о нем в местном регистре лиц. Составитель может указать формальные идентификаторы субъектов информации в некоторых подразделах ENTRY данной композиции COMPOSITION для описания участия других врачей или приборов (альтернативным способом описания является использование атрибута other_participations).

Демографические данные

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

В настоящей базовой модели принят аналогичный подход: специфичные объекты определяются однократно в пакете DEMOGRAPHIC_EXTRACT, и по мере необходимости остальные части выписки EHR_EXTRACT ссылаются на них с помощью присвоенных им идентификаторов экземпляров. Идентификатор экземпляра, используемый в выписке EHR_EXTRACT, может, но не обязан совпадать с одним из реальных идентификаторов, под которым данный объект известен в системе поставщика ЭМК.

Данная часть модели предложена в целях создания необходимого и достаточного описания каждого объекта, обеспечивающего интерпретацию ЭМК человеком, включая возможность поиска участников по их демографическим данным, чтобы получатель ЭМК мог идентифицировать их в своем регистре лиц. Если нужен обмен более детальными демографическими данными, то для этой цели рекомендуется использовать подходящий альтернативный стандарт, например СЕН/ТС 14796.

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

Изменение данных

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

1) для подавляющего большинства запросов части или полной ЭМК должна быть гарантирована генерация выписки EHR_EXTRACT, содержащей самые последние версии включенных в нее экземпляров класса RECORD_COMPONENT;

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

3) в отдельных случаях оказания медицинской помощи требуется пересылать последовательные версии экземпляров класса RECORD_COMPONENT, например для объяснения ошибки;

4) должна обеспечиваться возможность передачи всего содержания ЭМК, включая все версии измененных элементов, например при юридическом оформлении перевода пациента из одного медицинского учреждения в другое;

5) в композиции COMPOSITION, включенной в выписку EHR_EXTRACT, должна быть обеспечена связь между изменениями данных и отправкой их в ЭМК даже в том случае, если сделанные изменения затрагивают только несколько элементов, содержащихся в композиции;

6) эволюция томов FOLDER во времени также может потребовать похожего управления версиями, хотя обычно это делается в рамках систем ведения ЭМК, а журнал регистрации изменений тома FOLDER, скорее всего, редко будет включен в выписку EHR_EXTRACT;

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

8) в некоторых случаях, например по решению суда, данные могут быть физически удалены из системы ЭМК; в таких случаях иногда может быть правильным сохранение пустого заполнителя экземпляра класса RECORD_COMPONENT на том же месте в иерархии, чтобы показать, когда и почему было произведено удаление.

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

Класс AUDIT_INFO содержит ряд атрибутов, идентифицирующих систему ведения ЭМК, отправителя и время отправки, которые определяют появление любого экземпляра класса RECORD_COMPONENT в системе ведения ЭМК, в которой он впервые был создан. Эта совокупность данных должна быть включена в выписку EHR_EXTRACT при передаче данного экземпляра класса RECORD_COMPONENT. Если данный экземпляр класса RECORD_COMPONENT является изменением предыдущей версии, то должен быть также передан дополнительный набор описаний и ссылок на предыдущие версии. Поэтому всегда можно узнать, изменялся ли экземпляр класса RECORD_COMPONENT, и если да, то когда, почему, кем и в какой системе ведения ЭМК. Когда идентификатор предыдущей версии известен, но получить доступ к этой версии можно лишь в том случае, если получатель ЭМК имеет необходимые права, а поставщик ЭМК готов их обеспечить.

Передача запросов на извлечение данных из ЭМК

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

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

Некоторые представления данных или выборки могут быть получены с помощью "пользовательского" запроса, специально составленного для извлечения данных из ЭМК конкретного субъекта медицинской помощи. В подобных случаях может быть полезно хранить параметры запроса в ЭМК пациента, чтобы его могли повторить другие врачи. В какой мере полезно разделять эту возможность между учреждениями и системами, зависит от того, насколько интероперабельна спецификация этого запроса. Учитывая, что язык спецификации определений и ограничений архетипов (Archetype Definition Language - ADL) стандартизован (ИСО 13606-2) и сообщество, разрабатывающее методические указания по его применению, также движется в сторону обеспечения интероперабельности своих спецификаций, вполне вероятно появление типовой спецификации запроса на извлечение данных из ЭМК.

Хотя до сих пор отсутствует стандартное соглашение по спецификации запросов на извлечение данных из ЭМК, можно предположить, что такие спецификации будут представлять собой массив строковых значений или пар "имя - значение". Спецификация может быть представлена подклассами кластера CLUSTER и элемента ELEMENT класса сущности ITEM со значениями данных типа STRING. Поэтому архетипы подразделов ENTRY могут быть использованы для определения представления любых запросов на извлечение данных из ЭМК, которые должны быть переданы. Преимущество данного подхода в том, что несколько таких спецификаций запросов могут быть определены для использования в медицинских системах, и обновляться со временем без необходимости внесения каких-либо изменений в настоящий стандарт. Ниже приведен пример запроса графика изменения кровяного давления:

ENTRY Blood Pressure Graph Query

CLUSTER: Query Specification

ELEMENT: Query Syntax: <EHR_OQI_vq>

ELEMENT: Query String: "Select...

where Cluster.meaning = <Кровяное давление>

and containing.Entry.subject_of_information = <Пациент>

and containing.Composition.Clinical_Session.session_time.start

> (текущая_дата>-365дней)"

ELEMENT: Datetime first authored: 20 февраля 2003


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


Обмен информацией о форме представления данных

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

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

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

3) система получателя ЭМК может быть не в состоянии точно отобразить экранные формы, используемые системой поставщика ЭМК;

4) медицинские специалисты получателя ЭМК могут иметь свои собственные приложения, с помощью которых они хотят просматривать как импортированные, так и местные данные.

Однако в следующих двух сценариях точная информация о представлении данных может быть важна при передаче данных ЭМК:

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

b) если конкретное представление данных обеспечивает их уникальную интерпретацию, например в виде диаграммы или графика.

В обоих случаях для включения в выписку из ЭМК инкапсулированного визуального представления данных ЭМК любого уровня детализации можно использовать атрибут attested_view класса ATTESTATION_INFO. Например, данный атрибут может быть использован для включения визуального представления документа, составленного в соответствии со стандартом HL7 version 3 CDA Release 1 или Release 2.

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

Передача мультимедийных данных

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

Широкий спектр мультимедийных данных может быть включен в ЭМК в виде специальных значений данных элементов ELEMENT. Следовательно, более сложные структуры мультимедийных данных могут быть представлены как комбинации элементов ELEMENT, возможно, содержащихся в кластерах CLUSTER в виде таблиц, списков или древовидных структур. Конкретные структуры данных или мультимедийные протоколы исследований могут быть представлены как подразделы ENTRY или композиции COMPOSITION, а также в виде архетипов.

Как определено в стандарте СЕН/ТС 14796, тип инкапсулированных данных (сокращенное обозначение ED) позволяет представлять любой тип данных MIME.

0.9 Сравнение настоящего стандарта и EN 13606-1

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

Следующие нормативные положения настоящего стандарта отличаются от приведенных в ЕН 13606-1:

- формулировка раздела 1 "Область применения" была модифицирована (расширена) включением в конец второго абзаца фразы "или для представления данных ЭМК в распределенной (федеративной) системе";

- подраздел 5.2 "Соответствие в странах - участницах ЕС" был переформулирован для большего соответствия требованиям ИСО и переименован в "Соответствие в странах-участницах";

- значение атрибута rm_id выписки EHR_EXTRACT было изменено с "EN 13606-1" на "ISO 13606-1".

Настоящее введение было отредактировано, чтобы пояснить (но не изменить) ответственность получателя в отношении томов FOLDER и связей LINK, а также обстоятельства, при которых личность составителя измененной композиции COMPOSITION может быть изменена в случае необходимости.

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

- фразы "европейский стандарт" заменены фразами "настоящий стандарт";

- фразы "ЕН 13606" заменены фразами "ИСО 13606";

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

- несколько определений терминов, не соответствовавших правилам ИСО, были отредактированы без изменения их сути, т.е. их техническое толкование осталось неизменным;

- были исправлены замеченные опечатки и несоответствия терминов.

Данная часть введения не имеет аналога в ЕН 13606-1, поскольку точное содержание международного стандарта ИСО не было известно на момент публикации стандарта ЕН 13606-1.

Сноски в тексте стандарта, выделенные курсивом, приведены для уточнения оригинала.

1 Область применения


Настоящий стандарт определяет передачу части или всей электронной медицинской карты (ЭМК) одного идентифицированного субъекта медицинской помощи между системами ведения ЭМК или между системами ведения ЭМК и централизованным хранилищем данных ЭМК.

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

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

Настоящий стандарт, являющийся частью комплекса стандартов ИСО 13606, представляет информационную точку зрения на выписку из ЭМК в терминах ИСО/МЭК 10746-1 [13]. Настоящий стандарт не предназначен для определения внутренней архитектуры или структуры баз данных систем ведения ЭМК.

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


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

СЕН/ТС 14796:2004 Информатизация здоровья. Типы данных (CEN/TS 14796:2004, Health Informatics - Data Types)

3 Термины и определения


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

3.1 абстрактный класс (abstract class): Виртуальный общий родитель для двух или нескольких классов, который сам не имеет экземпляров.

3.2

контроль доступа (access control): Совокупность средств, обеспечивающих доступ к ресурсам системы обработки данных только авторизованным субъектам авторизованными способами.

[ИСО/МЭК 2382-8:1998, статья 08.04.01]

3.3

отчетность (accountability): Свойство, обеспечивающее однозначное отслеживание действий субъекта.

[ИСО/МЭК 2382-8:1998, статья 08.01.10]

3.4 экземпляр архетипа (archetype instance): Экземпляр класса метаданных модели архетипов, определяющий медицинское понятие и ограничения значений, применяемые к одному классу экземпляров элементов в выписке из электронной медицинской карты.

3.5 модель архетипов (archetype model): Информационная модель метаданных, представляющая специфические для предметной области характеристики разделов электронной медицинской карты путем определения значений или ограничений на значения для классов и атрибутов в базовой модели электронной медицинской карты.

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

3.7 аттестующий (attester): Сторона (лицо), сертифицирующая и регистрирующая юридическую ответственность за конкретную единицу информации.

3.8 аттестация (attestation): Процесс сертификации и регистрации юридической ответственности за конкретную единицу информации.

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

3.10 аутентификация (authentication): Процесс надежной идентификации субъекта информационной безопасности путем защищенной ассоциации, установленной между идентификатором и субъектом.

3.11 авторизация (authorization): Предоставление прав.

3.12 клиентское приложение (client application): Медицинское приложение, которое в данный момент запрашивает данные медицинской карты из системы ведения ЭМК общего пользования.

3.13 медицинская информация (clinical information): Информация о лице, относящаяся к его здоровью или лечению.

3.14 отправленные данные (committed): Информация, отправленная в систему ведения электронных медицинских карт на постоянное хранение и составляющая часть электронной медицинской карты субъекта медицинской помощи.

3.15 отправитель (committer): Агент (сторона, прибор или программное обеспечение), результатом прямых действий которого является отправка данных в электронную медицинскую карту.

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

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

3.17

конфиденциальность (confidentiality): Состояние информации, при котором она недоступна неавторизованным лицам, субъектам или процессам.

[ИСО 7498-2:1989, статья 3.3.16]

3.18 вклад (contribution): Совокупность элементов данных, отправленная одним пользователем в один момент времени в электронную медицинскую карту одного субъекта медицинской помощи.

3.19

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

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

например получателем.

[ИСО 7498-2:1989, статья 3.3.26]

3.20 распределенная обработка (distributed processing): Обработка информации, при которой дискретные компоненты могут располагаться в разных местах или при которой связь между компонентами может допускать задержки или пропадать.

3.21 выписка из электронной медицинской карты (electronic health record extract): Вся электронная медицинская карта субъекта медицинской помощи или ее часть, передаваемая в соответствии с настоящим стандартом.

3.22 информационная архитектура электронной медицинской карты (electronic health record information architecture): Спецификация информационной точки зрения на электронную медицинскую карту в терминах открытой распределенной обработки (ОРО).

3.23 поставщик электронной медицинской карты (electronic health record provider): Легитимный обладатель электронной медицинской карты, передающий ее другому заинтересованному субъекту.

3.24 получатель электронной медицинской карты (electronic health record recipient): Субъект, которому поставщик электронной медицинской карты передает электронную медицинскую карту.

3.25 инициатор запроса электронной медицинской карты (electronic health record requester): Объект, инициирующий запрос на передачу электронной медицинской карты от поставщика к получателю электронной медицинской карты.

3.26 система ведения электронных медицинских карт (electronic health record system): Система, предназначенная для записи, извлечения и преобразования информации в электронных медицинских картах.

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

3.28 федеративная медицинская карта (federated health record): Виртуальное представление медицинской карты пациента, которое может быть получено с помощью передачи стандартных выписок из всех записей электронных медицинских карт этого пациента, хранящихся в разных системах.

3.29 система-источник (feeder system): Хранилище (данных медицинских карт), к которому может быть обращен запрос в рамках федерации систем ведения электронных медицинских карт для пополнения данных в федеративной медицинской карте.

3.30 типовой (generic): Применимый к требованиям или информационным моделям разных медицинских специалистов, предметных областей и стран.

3.31 медицинский агент (healthcare agent): Лицо, прибор или программное обеспечение, выполняющее определенную роль в оказании медицинской помощи.

3.32 медицинский прибор (healthcare device): Прибор или оборудование, прямо или косвенно участвующее в оказании медицинской помощи отдельному лицу или популяции.

3.33 медицинское учреждение (healthcare organization): Учреждение, прямо или косвенно участвующее в оказании медицинской помощи отдельному лицу или популяции.

3.34 участник сферы здравоохранения (healthcare party): Лицо, прямо или косвенно участвующее в оказании медицинской помощи отдельному лицу или популяции.

3.35 медицинская услуга (healthcare service): Услуга, предоставляемая с целью прямо или косвенно улучшить состояние здоровья отдельного лица или популяции, которым она предоставляется.

3.36 унаследованные данные (legacy data): Данные, которые собирались и обрабатывались в "предыдущей" системе, но теперь хранятся в "текущей" системе.

3.37 метаданные (metadata): Данные, определяющие класс объекта и свойства собранной информации.

3.38

неоспоримость (non-repudiation): Служба, обеспечивающая любую из участвующих сторон подтверждение целостности и происхождения данных (неразрывно друг от друга).**

[ИСО/ТС 17090-1:2002*, статья 3.2.21]

_______________
* Отменен. Действует ИСО 17090-1:2008. Для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.
** Текст документа соответствует оригиналу. - .

3.39 пациент (patient): Синоним термина "субъект медицинской помощи".

3.40 постоянные данные (persistent data): Данные, хранящиеся на постоянной основе.

3.41 персональная медицинская карта (personal health record): Медицинская карта, содержание которой контролирует субъект медицинской помощи или его законный представитель.

3.42

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

[ИСО/МЭК 2382-8:1998, статья 08.01.23]

3.43 элемент записи (record component): Часть выписки из электронной медицинской карты одного субъекта медицинской помощи, представленная как узел в иерархической структуре данных, соответствующей настоящему стандарту.

3.44

роль (role): Совокупность образов действий, связанная с решаемой задачей.

[ИСО/ТС 17090-1:2002*, статья 3.2.24]

_______________
* Отменен. Действует ИСО 17090-1:2008. Для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.

3.45

семантическая интероперабельность (semantic interoperability): Свойство данных, совместно используемых несколькими системами, быть понятными на уровне полностью определенных понятий предметной области.

[ИСО/ТС 18308-2004*, статья 3.38]

_______________
* Отменен. Действует ИСО 18308:2011. Для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.

3.46

совместно используемая электронная медицинская карта (shareable electronic health record): Электронная медицинская карта со стандартизованной информационной моделью,

зависящая от систем ведения электронных медицинских карт и доступная многим

авторизованным пользователям.

[ИСО/ТС 20514:2005, статья 2.33]

3.47

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

[ИСО/МЭК Руководство 2:2004, статья 3.2]

3.48

состояние (процесса) [state (of a process)]: Условие или ситуация, в котором находится объект в период его жизненного цикла и при котором данный объект удовлетворяет некоторому условию, выполняет некоторое действие или ожидает некоторого события.

[ИСО/ТС 18308-2004*, статья 3.39]

_______________
* Отменен. Действует ИСО 18308:2011. Для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.

3.49 субъект медицинской помощи (subject of care): Лицо, которому запланирована медицинская помощь, получающее или получившее медицинскую помощь.

3.50 точка зрения (view): Альтернативное представление данных для другого пользователя или другой цели.

4 Обозначения и сокращения


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

CEN

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

CEN/TC 251

- Технический комитет 251 CEN, разрабатывающий стандарты по информатизации здоровья (CEN Technical Committee 251);

СМЕТ

- общий тип элементов сообщения (формализм, определенный в HL7) (Common Message Element Type);

ЭИБ (EHCR)

- электронная история болезни (Electronic Healthcare Record);

ЭМК (EHR)

- электронная медицинская карта (Electronic Health Record);

EC (EU)

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

GEHR

- Исследовательский проект 1992-1995 гг. (Good European Health Record);

GP

- врач общей практики (general practitioner);

HISA

- архитектура сервисов информатизации здоровья (акроним, использованный в [17]) (Health Informatics Service Architecture);

HL7

- Health Level Seven;

IANA

- Комитет по присвоению адресов в Интернете (Internet Assigned Numbers Authority);

IETF

- Инженерная группа по развитию Интернета (Internet Engineering Task Force);

ИСО (ISO)

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

OPO (ODP)

- открытая распределенная обработка (используется для описания распределенных систем [13]) (Open Distributed Processing);

ОИД (OID)

- объектный идентификатор (Object Identifier);

НИОКР (R&D)

- научно-исследовательские и опытно-конструкторские работы (Research and Development);

RFC

- рабочие предложения (request for comments);

UML

- унифицированный язык моделирования (Unified Modeling Language);

W3C

- Консорциум по всемирной сети (World Wide Web Consortium);

XML

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


5 Соответствие

5.1 Соответствие системы ведения ЭМК

5.1.1 Система передачи данных ЭМК удовлятворяет требованиям настоящего стандарта, если вся подлежащая обмену информация, соответствующая области применения настоящего стандарта, может быть представлена в форме, в которой существует прямое соответствие между структурой обмениваемых данных и информационной моделью EHR_EXTRACT, определенной в разделе 6 с использованием языка UML. Другие модели обмена определены в ИСО 13606-5.

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

5.1.3 Рекомендуется выпустить заявление о соответствии. Краткие указания, что оно может содержать:

a) обозначение продукта/системы;

b) целевое назначение или назначения системы ведения ЭМК (например, является ли она специализированной, используемой при оказании первичной медицинской помощи, предназначенной для стационаров или ограниченной конкретной медицинской специальностью);

c) способность передавать или принимать выписки EHR_EXTRACT, либо выполнять оба действия;

d) объявление реализованного подмножества классов стандарта;

e) объявление используемых типов данных;

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

g) спецификацию синтаксиса или синтаксисов, применяемых для представления выписки EHR_EXTRACT (например, могут быть указаны конкретные XML-схемы).

5.2 Соответствие стран-участниц

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

5.2.3 Данный национальный профиль должен использоваться для проверки на соответствие в данной стране-участнице.

5.2.4 В целях исполнения данного заявления о соответствии национальные органы стандартизации должны уведомить ИСО/ТК 215 о том, что национальный профиль необходим и используется для проверки на соответствие в сфере их юрисдикции.

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

5.2.6 Комитет ИСО/ТК 215 должен опубликовать уведомление о данном национальном профиле.

6 Базовая модель

6.1 Указатель к пакетам


Примечание - Классы в пакетах указаны в алфавитном порядке для удобства поиска. В приведенных далее табличных спецификациях данные приведены в порядке их появления на диаграммах.

Пакет EXTRACT:

Пакет SUPPORT:

ATTESTATION_INFO

CS

AUDIT_INFO

CV

CLUSTER

DATA_VALUE

COMPOSITION

ED

CONTENT

II

EHR_EXTRACT

IVL

ELEMENT

OID

ENTRY

TEXT

EXTRACT_CRITERIA

TS

FOLDER

URI

FUNCTIONAL_ROLE

ITEM

LINK

RECORD_COMPONENT

RELATED_PARTY

SECTION

Пакет DEMOGRAPHICS:

Пакет PRIMITIVES:

ENTITY_NAME

Array<T>

ENTITY_NAME_PART

Boolean

HEALTHCARE_PROFESSIONAL_ROLE

Byte

IDENTIFIED_ENTITY

Character

IDENTIFIED_HEALTHCARE_PROFESSIONAL

Double

ORGANIZATION

Integer

PERSON

List<T>

POSTAL_ADDRESS

Real

POSTAL_ADDRESS_PART

Set<T>

SOFTWARE_OR_DEVICE

String

SUBJECT_OF_CARE_PERSON_IDENTIFICATION

TELECOM


6.2 Пакет EXTRACT

6.2.1 Общая информация

Элементы, входящие в пакет EXTRACT

Имя

Тип

ATTESTATION_INFO

Класс

AUDIT_INFO

Класс

CLUSTER

Класс

COMPOSITION

Класс

CONTENT

Класс

EHR_EXTRACT

Класс

ELEMENT

Класс

ENTRY

Класс

EXTRACT_CRITERIA

Класс

FOLDER

Класс

FUNCTIONAL_ROLE

Класс

ITEM

Класс

LINK

Класс

RECORD_COMPONENT

Класс

RELATED_PARTY

Класс

SECTION

Класс

Рисунок 3 - Диаграмма классов UML пакета EXTRACT


Рисунок 3 - Диаграмма классов UML пакета EXTRACT

6.2.2 Класс EHR_EXTRACT

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

Атрибуты

Сигнатура

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

Кратность

Описание

authorizing_party:ll

0..1

-

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

ehr_id:ll

1

-

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

ehr_system: ll

1

-

Идентификатор системы поставщика ЭМК, из которой сделана данная выписка

rm_id:String

1

-

Идентификатор и версия стандарта базовой модели, в соответствии с которым сделана данная выписка EHR_EXTRACT. Для выписки из ЭМК, соответствующей настоящему стандарту, данный атрибут должен иметь строковое значение "ISO 13606"

subject_of_care: II

1

-

Уникальный идентификатор субъекта медицинской помощи, из ЭМК которого сделана данная выписка, определенный в системе поставщика ЭМК

time_created:TS

1

-

Дата и время момента запроса или экспорта данных из ЭМК субъекта медицинской помощи для создания данной выписки

all_compositions: Set<COMPOSITION>

0..1

0..*

Все композиции COMPOSITION, содержащиеся в данной выписке EHR_EXTRACT, включены по значению с помощью данной ассоциации

criteria: Set<EXTRACT_CRITERIA>

0..1

0..*

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

folders:Set<FOLDER>

0..1

0..*

Иерархия томов FOLDER, содержащаяся в выписке EHR_EXTRACT; каждый том FOLDER может содержать несколько идентификаторов rc_id композиций COMPOSITION и/или других томов FOLDER

demographic extract: Set<IDENTIFIED_ENTITY>

0..1

0..*

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


6.2.3 Класс EXTRACT_CRITERIA

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

Атрибуты

Сигнатура

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

Кратность

Описание

all_versions: Boolean

0..1

-

Данный атрибут показывает, ограничена ли данная выписка EHR_EXTRACT самыми последними версиями композиций COMPOSITION или содержит все предыдущие версии

archetype_ids: SET<II>

0..1

-

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

max_sensitivity: Integer

0..1

-

Данный атрибут определяет максимально разрешенный уровень чувствительности (рамки авторизации), использованный для извлечения данных из системы поставщика ЭМК

multimedia_included: Boolean

0..1

-

Данный атрибут показывает, были ли мультимедийные данные намеренно исключены из данной выписки EHR_EXTRACT

other_constraints: String

0..1

-

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


ГОСТ Р ИСО 13606-1-2011

Группа П85

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

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

ПЕРЕДАЧА ЭЛЕКТРОННЫХ МЕДИЦИНСКИХ КАРТ

Часть 1

Базовая модель

Health informatics. Electronic health record communication. Part 1. Reference model



ОКС 35.240.80
ОКСТУ 4002

Дата введения 2012-08-01


Предисловие


Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 "Стандартизация в Российской Федерации. Основные положения"

Сведения о стандарте

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

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

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

4 Настоящий стандарт идентичен международному стандарту ИСО 13606-1:2008* "Информатизация здоровья. Передача электронных медицинских карт. Часть 1. Базовая модель" (ISO 13606-1:2008 "Health informatics - Electronic health record communication - Part 1: Reference model").
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить перейдя по ссылке на сайт . - .


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

5 ВВЕДЕН ВПЕРВЫЕ


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

Введение

Введение


Комплекс стандартов ИСО 13606 состоит из следующих частей под общим заголовком "Информатизация здоровья. Передача электронных медицинских карт":

- часть 1: "Базовая модель";

- часть 2: "Спецификация передачи архетипов";

- часть 3: "Базовые архетипы и списки терминов";

- часть 4: "Безопасность";

- часть 5: "Спецификация интерфейсов".

0.1 Преамбула

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

Комплекс стандартов ИСО 13606 не предназначен для определения внутренней архитектуры или структуры баз данных систем ведения ЭМК или их компонентов, а также для спецификации типов медицинских приложений, которым могут требоваться данные ЭМК или которые могут формировать эти данные в конкретных условиях оказания медицинской помощи, в сети медицинских организаций или в специализированных медицинских организациях. Поэтому предложенная в данном комплексе информационная модель называется "выписка из ЭМК", и она может использоваться для определения сообщения, документа или схемы XML либо интерфейса объекта. Информационная модель, определенная в настоящем стандарте, описывает информационную точку зрения на выписку из ЭМК в терминах базовой модели ИСО для открытой распределенной обработки (БМ-ОРО).

В комплексе стандартов 13606 предполагается, что ЭМК - это документ, длительно существующий, потенциально охватывающий данные, собираемые в разных учреждениях и странах, отражающий состояние здоровья и лечения отдельного субъекта (пациента), созданный и хранящийся в одной или нескольких физических системах в целях предоставления информации при будущем лечении данного субъекта и медико-юридической регистрации уже оказанной медицинской помощи. Хотя службе или системе ведения ЭМК требуется взаимодействовать со многими другими службами или системами, предоставляющими терминологию, медицинские знания, инструкции, обеспечивающими организацию выполнения работ, безопасность, ведение регистров физических лиц, выставление счетов на оплату лечения и многое другое, комплекс стандартов ИСО 13606 затрагивает только те взаимодействия с внешними службами или системами, информацию о которых необходимо сохранять длительное время в самой ЭМК, и для обеспечения соответствующих обменов данными предусматривает специфические характеристики в базовой модели.

Комплекс стандартов ИСО 13606 может внести практический вклад в архитектуру систем ведения ЭМК, но он будет реализован в основном в виде общего набора внешних интерфейсов или сообщений, встроенного в другие гетерогенные медицинские системы.

Настоящий стандарт является первым из пяти стандартов данного комплекса. Использование в настоящем стандарте положений других стандартов комплекса ИСО 13606 указано в явном виде в соответствующих местах текста.

0.2 Технический подход

Комплекс стандартов ИСО 13606 создан на основе практического опыта, накопленного в результате внедрения его европейского предшественника ENV 13606, других стандартов и спецификаций, относящихся к ЭМК, коммерческих систем и демонстрационных пилотных проектов передачи ЭМК пациентов частями или в целом, а также проводившихся исследований в данной области в течение 15 лет. Комплекс стандартов ИСО 13606 является развитием стандарта ENV 13606, обеспечивая более четкую и полную спецификацию, учет вновь выявленных требований, использование надежных средств применения типовых моделей к отдельным медицинским предметным областям и возможность обмена сообщениями, определенными в стандарте HL7, версия 3. Кроме того, для удобства разработчиков систем, соответствующих стандарту ENV 13606, комплекс стандартов ИСО 13606 содержит отображение элементов данных, описанных в стандарте ENV 13606, на настоящий стандарт. При техническом подходе к созданию комплекса стандартов ИСО 13606 были приняты во внимание несколько групп требований.

а) Наряду с применением традиционного обмена информацией в форме сообщений между изолированными медицинскими системами в некоторых случаях система ведения ЭМК будет реализована как компонент промежуточного уровня (сервер приложений) с использованием технологии распределенных объектов и/или веб-сервисов.

b) "Потребителями" таких серверов приложений будут не только другие системы ведения ЭМК, но и другие службы промежуточного уровня, например компоненты безопасности, системы управления рабочими процессами, службы выдачи предупреждений и поддержки принятия решений, а также другие службы предоставления медицинских знаний.

c) К данной работе проявлен широкий международный интерес, и настоящий стандарт является совместной работой комитета СЕМ и организации ИСО, при этом многие страны-участницы внесли существенный вклад в его формирование.

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

e) Поскольку с 1999 г. научно-исследовательские работы (НИОКР), положенные в основу стандарта ENV 13606, продвинулись далеко вперед, то при разработке настоящего стандарта были приняты во внимание важные новые результаты в данной области. Например платформа "open EHR", интегрирующая результаты НИОКР, проведенных в Европе и Австралии.

Учитывая разнообразие развернутых систем ЭМК, в комплексе стандартов ИСО 13606 большинство характеристик передачи ЭМК определены как факультативные, а не обязательные. Однако для безопасной обработки выписок из ЭМК системой-получателем некоторая степень обязательности все же требуется, что нашло свое отражение в обязательных свойствах объектов, моделируемых в частях 1, 2 и 4 комплекса стандартов ИСО 13606, а также в списках нормативных терминов, определенных в части 3.

На практике комплекс стандартов ИСО 13606 будет согласовываться с другими стандартами в области информатизации здоровья, определяющими конкретные аспекты представления медицинских данных. В приложении В поясняется, как комплекс стандартов ИСО 13606 может использоваться совместно с дополнительными стандартами, включая базовую информационную модель (RIM) стандарта HL7, версия 3, стандарты ЕН 14822-1, ЕН 14822-2, ЕН 14822-3, CEN/TS 14822-4 (GPIC), prEN 12967 (HISA) и prEN 13940 (CONTSYS).

0.3 Подход на основе дуальной модели

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

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

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

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

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

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

0.4 Базис требований настоящего стандарта

В начале 90-х годов специалисты пришли к выводу, что для обмена произвольной медицинской информацией между системами необходимо обобщенное представление данных. В Европе это вылилось в ряд научно-исследовательских проектов, финансируемых ЕС, и в два поколения стандартов CEN по информатизации здоровья, предшествовавших настоящему международному стандарту. Эти проекты и стандарты задумывались для определения общих характеристик информации ЭМК и для их включения в информационные модели и модели сообщений, предусматривающие стандартный интерфейс между медицинскими информационными системами. Подобные работы были призваны предоставить такой стандартизованный способ передачи целой ЭМК или ее части между различными и специализированными медицинскими информационными системами, который мог бы обеспечить точное и общее представление значений данных и контекстуальной организации информации в любой исходной системе ведения ЭМК. При этом преследовалась дополнительная цель - учесть процесс непрерывного развития медицинских знаний и разнообразие, присущее клинической практике.

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

- достоверное представление исходного смысла, который имел в виду автор подраздела ЭМК или совокупности подразделов;

- предоставление базовых средств, соответствующих потребностям специалистов и организаций в анализе и интерпретации ЭМК отдельного пациента или целой популяции;

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

К числу таких исследований относятся проекты GEHR [41, 48, 57], EHCR-SupA [36-38], Synapses [42, 43] и Nora, а также работа, выполненная в Шведском институте развития служб здравоохранения (SPRI). Публикации, посвященные ключевым требованиям, выявленным в этих проектах, перечислены в разделе "Библиография" работы [51]. Эти требования недавно были объединены на международном уровне в документе ИСО/ТС 18308 [9].

В данной базовой модели ключевые контекстно-зависимые требования к достоверному представлению ЭМК связаны с совокупностью базовых логических классов, обладающих необходимыми атрибутами, предложенными для каждого уровня иерархии элементов выписки из ЭМК. В качестве основы для описания свойств данной базовой модели передачи ЭМК были выбраны требования, изложенные в стандарте ИСО/ТС 18308. Отображение формулировок этих требований на конструкции базовой модели представлено в приложении D.

0.5 Обзор иерархии элементов выписки из ЭМК

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

Чтобы обеспечить достоверное представление исходного медицинского контекста и сохранить его смысл при передаче ЭМК между гетерогенными медицинскими системами, базовая модель выписки из ЭМК должна отражать эту иерархическую структуру и организацию информации и удовлетворять поставленным требованиям. Поэтому в предлагаемой модели иерархия элементов ЭМК формально разделяется на компоненты, для которых найдено единообразное отображение на способы организации отдельных ЭМК в гетерогенных системах ведения ЭМК. Эти компоненты представлены в таблице 1.


Таблица 1 - Основные компоненты иерархии базовой модели выписки из ЭМК

Компонент иерархии элементов ЭМК

Описание

Примеры

EHR_EXTRACT (выписка из ЭМК)

Контейнер верхнего уровня для части или всей ЭМК одного субъекта медицинской помощи, предназначенный для передачи данных получателю ЭМК от системы поставщика ЭМК

Нет

FOLDER (том)

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

Лечение диабета, шизофрении, холецистэктомия, педиатрия, в госпитале Св. Мунго, папка врача общей практики, эпизоды лечения в 2000-2001 гг., в Италии

COMPOSITION (композиция)

Совокупность данных, отправленных в ЭМК одним агентом в результате одного приема у врача или сеанса документирования

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

SECTION (раздел)

Данные ЭМК, содержащиеся в композиции COMPOSITION, сгруппированные под одним клиническим заголовком, обычно отражающие поток информации, собранной во время одного обращения к врачу, или структурированные для улучшения будущего восприятия человеком

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

ENTRY (подраздел)

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

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

CLUSTER (кластер)

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

Результаты аудиограммы, расшифровка электроэнцефалограммы, взвешенные дифференциальные диагнозы

ELEMENT (элемент)

Конечный узел иерархии элементов ЭМК, содержащий одно значение данных

Систолическое кровяное давление, частота пульса, название лекарства, симптом, масса тела



Объект EHR_EXTRACT содержит данные ЭМК в форме композиций COMPOSITION, которые могут быть организованы как иерархия томов FOLDER.

Композиции COMPOSITION содержат подразделы ENTRY, которые могут быть сгруппированы в форме иерархии разделов SECTION.

Подразделы ENTRY содержат элементы ELEMENT, которые могут быть сгруппированы в форме иерархии кластеров CLUSTER.

Рисунок 1 - Схема иерархии элементов выписки из ЭМК (часть 1)


Рисунок 1 - Схема иерархии элементов выписки из ЭМК (часть 1)

Рисунок 2 - Схема иерархии выписки из ЭМК (часть 2)


Рисунок 2 - Схема иерархии выписки из ЭМК (часть 2)

0.6 Описание основных классов базовой модели

Класс EHR_EXTRACT

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

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

Класс EHR_EXTRACT содержит данные ЭМК, представленные в трех формах:

1) совокупность композиций COMPOSITION;

2) факультативно каталог томов FOLDER, обеспечивающий верхние уровни группировки и организации композиций COMPOSITION;

3) факультативно совокупность демографических данных каждого лица, сведений об организации, приборе или компоненте программного обеспечения, идентифицированных в формах 1 и 2. Это позволяет включать в ЭМК ссылки на подобные объекты в виде уникального идентификатора, не повторяя каждый раз детали описания этих объектов. При таком подходе любая выписка EHR_EXTRACT может быть интерпретирована изолировано, даже если система получателя не имеет доступа к службам, необходимым для декодирования идентификаторов объектов, использованных поставщиком ЭМК.

Формальный механизм включения информации о политике доступа в выписку EHR_EXTRACT определен в стандарте ИСО 13606-4. Данная информация позволяет ознакомить получателя ЭМК с требованиями субъекта и поставщиков медицинской помощи о том, как должны обрабатываться в будущем запросы на доступ к данным ЭМК.

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

Класс RECORD_COMPONENT

Основными классами строительных блоков, используемых для построения иерархии данных ЭМК в выписке EHR_EXTRACT, являются подтипы абстрактного класса RECORD_COMPONENT, служащего родителем всех конкретных узлов иерархии ЭМК: тома FOLDER, композиции COMPOSITION, раздела SECTION, подраздела ENTRY, кластера CLUSTER, элемента ELEMENT. Он является также родителем двух других абстрактных классов: содержания CONTENT и сущности ITEM.

Абстрактный класс RECORD_COMPONENT определяет характеристики, общие для всех этих строительных блоков, в том числе:

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

- медицинское наименование, использованное в исходной системе ведения ЭМК для обозначения данной части данных ЭМК;

- факультативно, стандартизованное кодированное понятие, на которое это наименование было отображено. Это позволяет обеспечить семантическую интероперабельность эквивалентных экземпляров ЭМК даже в том случае, если им были присвоены разные медицинские наименования в разных системах ведения ЭМК;

- идентификатор узла архетипа, которому соответствует данный класс RECORD_COMPONENT. Этот идентификатор может использоваться либо в системах ведения ЭМК, построенных на основе архетипов, либо для указания того, что архетипы использовались при отображении данных в формат выписки EHR_EXTRACT;

- код чувствительности и ссылки на политики контроля доступа, которые должны использоваться получателем ЭМК для управления последующим доступом к данным;

- средства обеспечения связи между любыми компонентами выписки из ЭМК.

При создании выписки EHR_EXTRACT, соответствующей настоящему стандарту, система поставщика ЭМК может в некоторых случая потребовать, чтобы в иерархию данных выписки был включен класс RECORD_COMPONENT, не имеющий прямого соответствия с какими-либо исходными данными в системе ведения ЭМК. Атрибут synthesised класса RECORD_COMPONENT позволяет экспортирующей системе поставщика ЭМК указать, что класс RECORD_COMPONENT был создан в выписке EHR_EXTRACT для этой цели.

Разделы медицинских карт нередко ссылаются на другие, ранее существовавшие разделы и включают их как "копии". Типичным примером является выписной эпикриз, который может включать в себя копии нескольких частей карты стационарного больного, например обстоятельства госпитализации, основные диагнозы, главные вмешательства и лечебные процедуры. В большинстве случаев требуется включать экземпляры подобных классов RECORD_COMPONENT в выписку EHR_EXTRACT по значению, чтобы каждая композиция COMPOSITION могла быть интерпретирована получателем ЭМК. Однако для медико-правового контроля также важно знать, что эти разделы являются копиями разделов другой части ЭМК данного субъекта. Если эти данные являются копией, то для указания идентификатора rc_id исходного родительского класса RECORD_COMPONENT можно использовать необязательный атрибут original_parent_ref.

Любой класс RECORD_COMPONENT может содержать регистрацию данных о том, кем и когда он был создан в исходной системе ведения ЭМК. В каждой новой версии экземпляра класса RECORD_COMPONENT могут документироваться статус версии, причина пересмотра и идентификатор предыдущей версии. Однако для защиты данных, как правило, рекомендуется, чтобы при обычном обмене медицинскими данными в целях преемственности лечения предыдущие (неправильные) версии ЭМК не пересылались. Их надо передавать только в целях медико-правового контроля.

Важно, чтобы каждый экземпляр класса RECORD_COMPONENT был уникально и единообразно идентифицирован в многократных выписках EHR_EXTRACT. Тогда ссылки на такой экземпляр или между экземплярами останутся действительными. Примерами подобных ссылок являются семантические связи, пересмотр и аттестация. Атрибут rc_id имеет тип данных Instance Identifier (II) (идентификатор экземпляра), в который входит объектный идентификатор (ОИД) ветви идентификаторов ИСО. Тип данных II в настоящее время рассматривается международным сообществом как наиболее подходящий для постоянных идентификаторов, которые должны быть глобально уникальными. Как правило, в современных системах ведения ЭМК глобально уникальные экземпляры типа данных II непосредственно не используются в качестве первичных ключей или внутренних идентификаторов объектов. Однако система поставщика ЭМК, которой был присвоен ОИД организации, может использовать свои внутренние идентификаторы для построения уникальных местных расширений этого ОИД и таким способом создавать глобально уникальные значения атрибута rc_id. В качестве альтернативы она может создать совершенно новые значения атрибутов rc_id и сохранять их отображения на каждый внутренний идентификатор, чтобы любые будущие выписки EHR_EXTRACT, которые будут ею извлечены, использовали согласованные значения атрибутов rc_id. Трудно рассчитывать, что система получателя ЭМК сможет использовать полученные значения атрибута rc_id в качестве своих внутренних первичных ключей данных, поскольку каждая система управления базами данных использует немного отличающийся подход к генерации и использованию таких ключей. Поэтому получателю ЭМК может также потребоваться хранить отображение импортированных значений атрибута rc_id на свои первичные ключи, чтобы будущие ссылки на полученные экземпляры класса RECORD_COMPONENT могли быть надлежащим образом разрешены. Кроме того, он может создавать свои выписки EHR_EXTRACT, в которые эти значения атрибута rc_id будут снова включены для целей экспорта. Альтернативный подход в системах ведения ЭМК заключается в прямом хранении значений атрибутов rc_id вместе с медицинскими данными, рассматривая их как часть "полезной" нагрузки, но не используя в качестве первичных ключей. Необходимо также отметить, что в выписке EHR_EXTRACT атрибут rc_id не является эквивалентом первичного ключа, т.е. повторы значений атрибутов rc_id допустимы, если каждый экземпляр действительно ссылается на ту же самую часть медицинских данных в системе ведения ЭМК поставщика.

Класс FOLDER

Данный класс используется для представления верхних уровней структуры данных ЭМК в выписке EHR_EXTRACT, например для группировки композиций COMPOSITION по эпизодам, бригадам врачей, клинической специальности, условиям оказания медицинской помощи или интервалам времени. В международном масштабе данный вид организующей структуры используется по-разному: в некоторых учреждениях и системах понятие тома (folder) трактуется как неформальное разделение медицинской карты на отдельные части; в других он может представлять юридически значимую часть ЭМК, описывающую услуги, предоставленные учреждением или бригадой.

В выписке EHR_EXTRACT с помощью томов FOLDER создается необязательная иерархия. Тома FOLDER могут содержать другие тома FOLDER, образуя полную систему каталога, и они могут содержать любую необходимую информацию об их создании или изменении в системе поставщика ЭМК. Тома FOLDER содержат композиции COMPOSITION не по значению, а по ссылке, с помощью списка уникальных идентификаторов. Это позволяет любой композиции COMPOSITION присутствовать более чем в одном томе FOLDER, что является требованием, предъявляемым некоторыми поставщиками и органами власти.

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

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

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

Класс COMPOSITION

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

Составителем композиции является посредник (сторона, прибор или программное обеспечение), ответственный за создание, синтезирование или организацию информации, отправляемой в ЭМК. Такой посредник несет ответственность за включение информации в данную ЭМК, даже если он не является ее источником или отправителем. Содержание композиции COMPOSITION первоначально определяется таким составителем. Замена составителя при редактировании композиции не обязательна. Приложения обычно маркируют данные композиции COMPOSITION именем составителя, когда эти данные используются при оказании медицинской помощи. Бывают случаи, когда главного составителя нет (например, при телеконсультации, в которой участвуют врачи разных специальностей, или при проведении конференции), в подобных случаях роль составителя не может быть формально определена, даже если каждый участник и его медицинская роль установлены. Поэтому наличие составителя не является обязательным.

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

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

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

Класс Contribution (вклад)

Класс Contribution является совокупностью композиций COMPOSITION, отправленных одним пользователем в один момент времени в ЭМК одного субъекта медицинской помощи. Некоторые медицинские приложения содержат сложные экранные формы, позволяющие одновременно представлять несколько частей ЭМК (например, с помощью вкладок). Сохраняя содержание экранной формы, пользователь реально может отправить данные в несколько частей ЭМК пациента (например, добавить в какие-то части ЭМК новое заключение консультанта и пересмотренное лекарственное назначение). Объект Contribution охватывает все изменения и модификации, сделанные пользователем в этой ЭМК в течение данного сеанса. Все композиции COMPOSITION, составляющие один объект Contribution, могут быть совместно идентифицированы общим значением атрибута contribution_id.

Класс SECTION

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

Классы SECTION (разделы) могут использоваться для представления дерева медицинских заголовков, используемых в системе поставщика ЭМК для группировки и организации элементов данных в композиции COMPOSITION. Каждый раздел SECTION может содержать дополнительные разделы SECTION и/или подразделы ENTRY.

Класс ENTRY

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

- информация в подразделе ENTRY может относиться и не к пациенту (например, к родственнику): подраздел ENTRY определяет субъекта информации;

- информация в подразделе ENTRY может быть предоставленной или классифицированной конкретным лицом: подраздел ENTRY определяет поставщика информации;

- к конкретному подразделу ENTRY могут иметь отношение другие участники;

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

- в подразделе ENTRY может быть выставлен флаг, сигнализирующий получателю ЭМК, что структура данных содержит признак некоторой неопределенности заключений или обоснований, и что при автоматической обработке этих данных необходимо принимать меры предосторожности.

Подраздел ENTRY содержит структуру данных, образованную из кластеров CLUSTER и элементов ELEMENT. Важно отметить, что подраздел ENTRY не может содержать вложенные подразделы ENTRY. Совокупность атрибутов контекста, определенных на уровне подраздела ENTRY (например, субъект информации), применяется ко всей структуре данных и не может быть переопределена.

Классы ITEM, CLUSTER и ELEMENT

Класс сущности ITEM может представлять собой реальные данные, описывающие наблюдение, предположение или действие, а также необязательные детали таких данных, описывающие метод исследования, физическое состояние пациента либо детали, способствующие процессу клинического обоснования, например ссылку на электронное руководство, систему поддержки принятия решений или иной источник знаний. Необязательный атрибут item_category позволяет различать эти категории сущностей, что может способствовать автоматизированному анализу или фильтрации сущностей ITEM в подразделе ENTRY. Система кодирования значений этого атрибута определена в комплексе стандартов ИСО 13606-3.

Информация, представленная сущностью ITEM (кластер CLUSTER или элемент ELEMENT), может быть привязана к моменту времени, не совпадающему со временем лечебного действия или его регистрации. Атрибут obs_time позволяет представлять значение даты, времени или периода с любой степенью точности. Это позволяет, например, датировать операцию только годом, проявление симптома - месяцем и годом, период занятости - точным диапазоном дат или периодом лет, привязать аритмию сердца к точному моменту времени, организовать ангиограмму в виде временного ряда изображений.

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

С помощью кластера CLUSTER можно представлять сложные структуры данных, требуемые для представления реальных значений данных обследований, медицинских заключений или указаний, состоящих из нескольких частей (вложенных). Может потребоваться представление такой структуры данных в форме таблицы, дерева или временного ряда. Примерами служат ЭКГ в нескольких отведениях, полный клинический анализ крови, исследование ахиллова рефлекса, состав внутривенного вливания.

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

Значения данных

Каждый элемент ELEMENT содержит одно значение данных, представляющее значение реального экземпляра этого класса. Оно должно иметь один из типов данных, определенных комитетом CEN (в стандарте СЕН/ТС 14796):

- текст и кодированные значения;

- количества, включая отношения, интервалы и длительность;

- даты и время;

- графические и другие типы данных MIME (например, изображение, сигнал).

При разработке настоящего стандарта принималось во внимание, что технический комитет ИСО/ТК 215 разрабатывает новый стандарт типов данных, используемых в информатизации здоровья. Предполается, что после его опубликования комитет CEN отменит стандарт СЕН/ТС 14796 в пользу этого нового стандарта. При этом потребуется обеспечить отображение типов данных CEN на новый стандарт типов данных. Это отображение должно быть также использовано для адаптации положений настоящего стандарта к новым типам данных.

Чтобы обеспечить принятие настоящего стандарта в более широком масштабе, чем юрисдикция СЕН/ТС 14967, описание типов данных атрибутов, действительно используемых в данной базовой модели (отличающихся от типов значений элементов ELEMENT), включено в настоящий стандарт в форме пакета SUPPORT. Это описание должно быть исключено после опубликования стандарта типов данных ИСО.

Примечание - Предполагается, что простые типы данных, например, Boolean (булевский), Integer (целый), должны соответствовать стандарту ИСО/МЭК 11404. В настоящем стандарте они не определяются.

0.7 Описание других основных классов базовой модели

Класс AUDIT_INFO

Согласно нормативным актам здравоохранения и защиты персональных данных необходимо документировать и отслеживать, когда и кем данные ЭМК были отправлены в систему ведения ЭМК. Важно также регистрировать изменения данных ЭМК при ее модификации и передавать эти изменения в форме выписки EHR_EXTRACT. Класс AUDIT_INFO используется при представлении этих регистрационных данных:

a) для любого класса RECORD_COMPONENT как постоянная запись о его создании в исходной системе ведения ЭМК;

b) для любой композиции COMPOSITION как запись о ее создании в системе поставщика ЭМК, которая сгенерировала данную выписку EHR_EXTRACT.

Следовательно, композиция COMPOSITION может иметь до двух наборов регистрационных данных - один, относящийся к его исходной системе ведения ЭМК (называемый "feeder_audit"), и второй, относящийся к ее последующей записи в системе поставщика ЭМК (называемый "committal"), если эти две системы разные. Однако настоящий стандарт не требует и не поддерживает передачу неопределенного числа наборов регистрационных данных каждой системе, в которой сохранена композиция COMPOSITION. Это вызвано тем, что накапливаемая совокупность наборов регистрационных данных, лишенная реальной медицинской информации, детально показывающей, какие изменения каждый раз происходили, не считается имеющей медицинское значение. Если требуется передать полную историю изменений, то в выписку EHR_EXTRACT надо включить каждую версию композиции COMPOSITION.

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

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

Для регистрации изменения данных класс AUDIT_INFO содержит статус версии, необязательную причину изменения, идентификатор непосредственно предшествующей версии, к которой были применены эти изменения, и идентификатор совокупности версий, позволяющий связывать друг с другом неупорядоченные версии, созданные в разных системах ведения ЭМК. Необязательный атрибут статуса версии указывает, была ли текущая версия на момент ее отправки черновиком (т.е. предназначалась для замены в ближайшем будущем), обновлением предшествующей черновой версии, исправлением ошибочной старой версии, либо пустой композицией COMPOSITION или разделом ENTRY, означающими логическое удаление предшествующей версии (например при ошибочном сохранении предшествующей версии не в той ЭМК). Если статус не задан, то данная версия подразумевается определяющей (первой).

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

Класс FUNCTIONAL_ROLE

Класс FUNCTIONAL_ROLE (функциональная роль) используется для представления деталей того, кто и где внес свой вклад в медицинскую помощь или в медицинскую карту субъекта медицинской помощи. Данный класс идентифицирует:

- функцию, выполненную в документируемой ситуации;

- личность агента, выполнившего данную функцию;

- способ его участия (например, лично, по телефону);

- медицинское учреждение, в котором находился агент;

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

Часть этой информации может быть опущена, если исполнитель действует не в медицинском учреждении, например, субъект медицинской помощи вводит данные в свою ЭМК из дома.

Класс ATTESTATION_INFO

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

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

В течение многих лет проходила оживленная дискуссия о том, какая информация должна сохраняться в электронных системах, чтобы:

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

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

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

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

Класс ATTESTATION_INFO содержит следующие данные об аттестации:

- дата и время проведения аттестации;

- идентификацию лица, осуществившего аттестацию, в форме ссылки на описанный выше класс FUNCTIONAL_ROLE;

- список аттестованных экземпляров класса RECORD_COMPONENT;

- факультативно, причину или юридическую значимость аттестации;

- факультативно, инкапсулированные данные (по значению или по ссылке), представляющие визуальный образ того, что в действительности видел аттестующий; в настоящее время в некоторых странах ЕС требуется, чтобы эти данные хранились в ЭМК наряду с данными в формате, пригодном для обработки.

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

Класс RELATED_PARTY

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

Данный класс может быть использован для следующих целей:

a) для идентификации лица в терминах его отношения к субъекту медицинской помощи в форме кодированного значения или текста;

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

В целях обеспечения безопасности данных не рекомендуется связывать ЭМК одного субъекта медицинской помощи с ЭМК другого субъекта (если, например, член семьи также является пациентом того же самого медицинского учреждения), но время от времени это требуется в клиниках при проведении генетической или семейной терапии, а иногда и при оказании первичной медицинской помощи. Настоящий стандарт формально не поддерживает связь между ЭМК разных субъектов медицинской помощи, но в принципе класс RELATED_PARTY можно использовать для передачи идентификаторов, являющихся действительными идентификаторами, под которыми другое лицо известно в системе поставщика ЭМК, если такое использование разрешено.

Класс LINK

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

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

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

Для маркировки каждой связи используются два атрибута:

a) грубая категория связи, которая должна иметь одно из нескольких значений, определенных в ИСО 13606-3;

b) необязательная более тонкая маркировка; справочный список кодов маркировки приведен в части 3, но могут использоваться и другие системы кодирования.

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

0.8 Обсуждение конкретных представлений

Представление ролей и ответственности в выписке EHR_EXTRACT

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

Лица, непосредственно участвующие в оказании медицинской помощи

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

Участники процесса документирования медицинской помощи в ЭМК

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

Участники, подтверждающие достоверность документов ЭМК

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

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

В настоящем стандарте (а также в других архитектурах ЭМК, например, ENV 13606 и HL7 CDA) используется следующий подход:

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

- предоставить возможность задания других конкретных участников в медицинских службах и системах, а также в отдельных экземплярах ЭМК на уровне композиций COMPOSITION или подразделов ENTRY;

- обеспечить возможность включения в ЭМК любого числа аттестаций для подписи томов FOLDER или композиций COMPOSITION или разрешить аттестацию только частей композиций COMPOSITION.

Ниже описаны некоторые конкретные роли, определенные в данной базовой модели.

Субъект медицинской помощи

Предполагается, что каждая ЭМК и, следовательно, любая выписка EHR_EXTRACT описывает состояние здоровья одного лица и оказанную ему медицинскую помощь. В терминах защиты данных это лицо является также субъектом данных. Из этого вытекают важные следствия для тех ЭМК, которые могут включать в себя сведения о разных субъектах данных (например, в случае семейного анамнеза); эти следствия рассмотрены ниже при описании субъекта информации.

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

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

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

Ведение отдельной медицинской карты для каждого плода при многоплодной беременности: этот пример часто рассматривают как ситуацию, при которой одна медицинская помощь может действительно оказываться двум или более субъектам лечения. В этих случаях представляется логичным включать копию соответствующей композиции COMPOSITION в выписку EHR_EXTRACT каждого ребенка вместо того, чтобы пытаться установить сложное соединение двух или нескольких медицинских карт, позволяющее сослаться на единственную композицию COMPOSITION, общую для этих карт. (В самих системах ведения ЭМК могут быть организованы более сложные перекрестные связи, позволяющие пользователям однократно вводить данные, которые будут логически включены в обе медицинские карты.)

"Сиамские" близнецы: по этим редким случаям велась дискуссия. В данном случае, если ЭМК ведутся отдельно для каждого близнеца, то представляется логичным и безопасным иметь копии соответствующих композиций COMPOSITION, а не создавать связи между выписками из медицинских карт, которые системы-получатели могут и не суметь безопасно обработать.

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

Идентификатор субъекта медицинской помощи в выписке EHR_EXTRACT будет ссылаться на моментальный снимок демографической информации, хранящейся у поставщика ЭМК, чтобы обеспечить возможность точной идентификации этого субъекта в регистре пациентов получателя ЭМК и/или обеспечить связь выписки EHR_EXTRACT с конкретным субъектом медицинской помощи даже в том случае, если внешние регистры пациентов недоступны. Субъект лечения определен в корне модели, в классе выписки EHR_EXTRACT.

Составитель

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

Следовательно, атрибут composer (составитель) идентифицирует лицо, которое составило данные композиции COMPOSITION, невзирая на то, кто отправил их в базу данных или аттестовал их. Композиция COMPOSITION будет считаться порожденной главным образом этим лицом. Смена составителя при редактировании содержания композиции не обязательна, поскольку принятие решения о смене зависит от степени внесенных изменений, а также от того, хочет и способна ли сторона, вносящая изменения, взять на себя основную ответственность за измененную композицию COMPOSITION в качестве ее составителя. При выводе данных на экран прикладные программы могут помечать данные композиции COMPOSITION фамилией составителя. (Роли других членов бригады, не являющихся составителями, могут быть добавлены с помощью атрибута other_participations ко всей композиции COMPOSITION либо к отдельным подразделам ENTRY.)

Отправитель данных

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

Могут возникать и другие ситуации, когда отправитель не несет ответственность за ввод данных, например, если измерительное устройство непосредственно передает данные в медицинское приложение. В таких случаях для пополнения списка участников можно использовать атрибуты information_provider или other_participations подраздела ENTRY.

Субъект информации

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

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

Атрибут subject_of_information (субъект информации) позволяет включить в подраздел ENTRY ссылку на экземпляр класса RELATED_PARTY, описывающего отношение этого субъекта к пациенту с помощью кодируемого значения и факультативно с помощью идентификатора лица (позволяющего получить информацию об этом лице из регистра лиц, являющегося частью системы ведения ЭМК).

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

Поставщик информации

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

Атрибут info_provider связывает подраздел ENTRY с классом функциональной роли FUNCTIONAL_ROLE, позволяющим описать функции участника и способ участия (по телефону, лично и т.д.). Как и в случае с субъектом информации, поставщик информации может быть или не быть формально идентифицирован в зависимости от его согласия и наличия информации о нем в местном регистре лиц. Составитель может указать формальные идентификаторы субъектов информации в некоторых подразделах ENTRY данной композиции COMPOSITION для описания участия других врачей или приборов (альтернативным способом описания является использование атрибута other_participations).

Демографические данные

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

В настоящей базовой модели принят аналогичный подход: специфичные объекты определяются однократно в пакете DEMOGRAPHIC_EXTRACT, и по мере необходимости остальные части выписки EHR_EXTRACT ссылаются на них с помощью присвоенных им идентификаторов экземпляров. Идентификатор экземпляра, используемый в выписке EHR_EXTRACT, может, но не обязан совпадать с одним из реальных идентификаторов, под которым данный объект известен в системе поставщика ЭМК.

Данная часть модели предложена в целях создания необходимого и достаточного описания каждого объекта, обеспечивающего интерпретацию ЭМК человеком, включая возможность поиска участников по их демографическим данным, чтобы получатель ЭМК мог идентифицировать их в своем регистре лиц. Если нужен обмен более детальными демографическими данными, то для этой цели рекомендуется использовать подходящий альтернативный стандарт, например СЕН/ТС 14796.

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

Изменение данных

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

1) для подавляющего большинства запросов части или полной ЭМК должна быть гарантирована генерация выписки EHR_EXTRACT, содержащей самые последние версии включенных в нее экземпляров класса RECORD_COMPONENT;

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

3) в отдельных случаях оказания медицинской помощи требуется пересылать последовательные версии экземпляров класса RECORD_COMPONENT, например для объяснения ошибки;

4) должна обеспечиваться возможность передачи всего содержания ЭМК, включая все версии измененных элементов, например при юридическом оформлении перевода пациента из одного медицинского учреждения в другое;

5) в композиции COMPOSITION, включенной в выписку EHR_EXTRACT, должна быть обеспечена связь между изменениями данных и отправкой их в ЭМК даже в том случае, если сделанные изменения затрагивают только несколько элементов, содержащихся в композиции;

6) эволюция томов FOLDER во времени также может потребовать похожего управления версиями, хотя обычно это делается в рамках систем ведения ЭМК, а журнал регистрации изменений тома FOLDER, скорее всего, редко будет включен в выписку EHR_EXTRACT;

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

8) в некоторых случаях, например по решению суда, данные могут быть физически удалены из системы ЭМК; в таких случаях иногда может быть правильным сохранение пустого заполнителя экземпляра класса RECORD_COMPONENT на том же месте в иерархии, чтобы показать, когда и почему было произведено удаление.

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

Класс AUDIT_INFO содержит ряд атрибутов, идентифицирующих систему ведения ЭМК, отправителя и время отправки, которые определяют появление любого экземпляра класса RECORD_COMPONENT в системе ведения ЭМК, в которой он впервые был создан. Эта совокупность данных должна быть включена в выписку EHR_EXTRACT при передаче данного экземпляра класса RECORD_COMPONENT. Если данный экземпляр класса RECORD_COMPONENT является изменением предыдущей версии, то должен быть также передан дополнительный набор описаний и ссылок на предыдущие версии. Поэтому всегда можно узнать, изменялся ли экземпляр класса RECORD_COMPONENT, и если да, то когда, почему, кем и в какой системе ведения ЭМК. Когда идентификатор предыдущей версии известен, но получить доступ к этой версии можно лишь в том случае, если получатель ЭМК имеет необходимые права, а поставщик ЭМК готов их обеспечить.

Передача запросов на извлечение данных из ЭМК

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

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

Некоторые представления данных или выборки могут быть получены с помощью "пользовательского" запроса, специально составленного для извлечения данных из ЭМК конкретного субъекта медицинской помощи. В подобных случаях может быть полезно хранить параметры запроса в ЭМК пациента, чтобы его могли повторить другие врачи. В какой мере полезно разделять эту возможность между учреждениями и системами, зависит от того, насколько интероперабельна спецификация этого запроса. Учитывая, что язык спецификации определений и ограничений архетипов (Archetype Definition Language - ADL) стандартизован (ИСО 13606-2) и сообщество, разрабатывающее методические указания по его применению, также движется в сторону обеспечения интероперабельности своих спецификаций, вполне вероятно появление типовой спецификации запроса на извлечение данных из ЭМК.

Хотя до сих пор отсутствует стандартное соглашение по спецификации запросов на извлечение данных из ЭМК, можно предположить, что такие спецификации будут представлять собой массив строковых значений или пар "имя - значение". Спецификация может быть представлена подклассами кластера CLUSTER и элемента ELEMENT класса сущности ITEM со значениями данных типа STRING. Поэтому архетипы подразделов ENTRY могут быть использованы для определения представления любых запросов на извлечение данных из ЭМК, которые должны быть переданы. Преимущество данного подхода в том, что несколько таких спецификаций запросов могут быть определены для использования в медицинских системах, и обновляться со временем без необходимости внесения каких-либо изменений в настоящий стандарт. Ниже приведен пример запроса графика изменения кровяного давления:

ENTRY Blood Pressure Graph Query

CLUSTER: Query Specification

ELEMENT: Query Syntax: <EHR_OQI_vq>

ELEMENT: Query String: "Select...

where Cluster.meaning = <Кровяное давление>

and containing.Entry.subject_of_information = <Пациент>

and containing.Composition.Clinical_Session.session_time.start

> (текущая_дата>-365дней)"

ELEMENT: Datetime first authored: 20 февраля 2003


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


Обмен информацией о форме представления данных

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

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

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

3) система получателя ЭМК может быть не в состоянии точно отобразить экранные формы, используемые системой поставщика ЭМК;

4) медицинские специалисты получателя ЭМК могут иметь свои собственные приложения, с помощью которых они хотят просматривать как импортированные, так и местные данные.

Однако в следующих двух сценариях точная информация о представлении данных может быть важна при передаче данных ЭМК:

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

b) если конкретное представление данных обеспечивает их уникальную интерпретацию, например в виде диаграммы или графика.

В обоих случаях для включения в выписку из ЭМК инкапсулированного визуального представления данных ЭМК любого уровня детализации можно использовать атрибут attested_view класса ATTESTATION_INFO. Например, данный атрибут может быть использован для включения визуального представления документа, составленного в соответствии со стандартом HL7 version 3 CDA Release 1 или Release 2.

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

Передача мультимедийных данных

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

Широкий спектр мультимедийных данных может быть включен в ЭМК в виде специальных значений данных элементов ELEMENT. Следовательно, более сложные структуры мультимедийных данных могут быть представлены как комбинации элементов ELEMENT, возможно, содержащихся в кластерах CLUSTER в виде таблиц, списков или древовидных структур. Конкретные структуры данных или мультимедийные протоколы исследований могут быть представлены как подразделы ENTRY или композиции COMPOSITION, а также в виде архетипов.

Как определено в стандарте СЕН/ТС 14796, тип инкапсулированных данных (сокращенное обозначение ED) позволяет представлять любой тип данных MIME.

0.9 Сравнение настоящего стандарта и EN 13606-1

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

Следующие нормативные положения настоящего стандарта отличаются от приведенных в ЕН 13606-1:

- формулировка раздела 1 "Область применения" была модифицирована (расширена) включением в конец второго абзаца фразы "или для представления данных ЭМК в распределенной (федеративной) системе";

- подраздел 5.2 "Соответствие в странах - участницах ЕС" был переформулирован для большего соответствия требованиям ИСО и переименован в "Соответствие в странах-участницах";

- значение атрибута rm_id выписки EHR_EXTRACT было изменено с "EN 13606-1" на "ISO 13606-1".

Настоящее введение было отредактировано, чтобы пояснить (но не изменить) ответственность получателя в отношении томов FOLDER и связей LINK, а также обстоятельства, при которых личность составителя измененной композиции COMPOSITION может быть изменена в случае необходимости.

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

- фразы "европейский стандарт" заменены фразами "настоящий стандарт";

- фразы "ЕН 13606" заменены фразами "ИСО 13606";

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

- несколько определений терминов, не соответствовавших правилам ИСО, были отредактированы без изменения их сути, т.е. их техническое толкование осталось неизменным;

- были исправлены замеченные опечатки и несоответствия терминов.

Данная часть введения не имеет аналога в ЕН 13606-1, поскольку точное содержание международного стандарта ИСО не было известно на момент публикации стандарта ЕН 13606-1.

Сноски в тексте стандарта, выделенные курсивом, приведены для уточнения оригинала.

1 Область применения


Настоящий стандарт определяет передачу части или всей электронной медицинской карты (ЭМК) одного идентифицированного субъекта медицинской помощи между системами ведения ЭМК или между системами ведения ЭМК и централизованным хранилищем данных ЭМК.

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

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

Настоящий стандарт, являющийся частью комплекса стандартов ИСО 13606, представляет информационную точку зрения на выписку из ЭМК в терминах ИСО/МЭК 10746-1 [13]. Настоящий стандарт не предназначен для определения внутренней архитектуры или структуры баз данных систем ведения ЭМК.

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


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

СЕН/ТС 14796:2004 Информатизация здоровья. Типы данных (CEN/TS 14796:2004, Health Informatics - Data Types)

3 Термины и определения


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

3.1 абстрактный класс (abstract class): Виртуальный общий родитель для двух или нескольких классов, который сам не имеет экземпляров.

3.2

контроль доступа (access control): Совокупность средств, обеспечивающих доступ к ресурсам системы обработки данных только авторизованным субъектам авторизованными способами.

[ИСО/МЭК 2382-8:1998, статья 08.04.01]

3.3

отчетность (accountability): Свойство, обеспечивающее однозначное отслеживание действий субъекта.

[ИСО/МЭК 2382-8:1998, статья 08.01.10]

3.4 экземпляр архетипа (archetype instance): Экземпляр класса метаданных модели архетипов, определяющий медицинское понятие и ограничения значений, применяемые к одному классу экземпляров элементов в выписке из электронной медицинской карты.

3.5 модель архетипов (archetype model): Информационная модель метаданных, представляющая специфические для предметной области характеристики разделов электронной медицинской карты путем определения значений или ограничений на значения для классов и атрибутов в базовой модели электронной медицинской карты.

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

3.7 аттестующий (attester): Сторона (лицо), сертифицирующая и регистрирующая юридическую ответственность за конкретную единицу информации.

3.8 аттестация (attestation): Процесс сертификации и регистрации юридической ответственности за конкретную единицу информации.

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

3.10 аутентификация (authentication): Процесс надежной идентификации субъекта информационной безопасности путем защищенной ассоциации, установленной между идентификатором и субъектом.

3.11 авторизация (authorization): Предоставление прав.

3.12 клиентское приложение (client application): Медицинское приложение, которое в данный момент запрашивает данные медицинской карты из системы ведения ЭМК общего пользования.

3.13 медицинская информация (clinical information): Информация о лице, относящаяся к его здоровью или лечению.

3.14 отправленные данные (committed): Информация, отправленная в систему ведения электронных медицинских карт на постоянное хранение и составляющая часть электронной медицинской карты субъекта медицинской помощи.

3.15 отправитель (committer): Агент (сторона, прибор или программное обеспечение), результатом прямых действий которого является отправка данных в электронную медицинскую карту.

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

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

3.17

конфиденциальность (confidentiality): Состояние информации, при котором она недоступна неавторизованным лицам, субъектам или процессам.

[ИСО 7498-2:1989, статья 3.3.16]

3.18 вклад (contribution): Совокупность элементов данных, отправленная одним пользователем в один момент времени в электронную медицинскую карту одного субъекта медицинской помощи.

3.19

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

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

например получателем.

[ИСО 7498-2:1989, статья 3.3.26]

3.20 распределенная обработка (distributed processing): Обработка информации, при которой дискретные компоненты могут располагаться в разных местах или при которой связь между компонентами может допускать задержки или пропадать.

3.21 выписка из электронной медицинской карты (electronic health record extract): Вся электронная медицинская карта субъекта медицинской помощи или ее часть, передаваемая в соответствии с настоящим стандартом.

3.22 информационная архитектура электронной медицинской карты (electronic health record information architecture): Спецификация информационной точки зрения на электронную медицинскую карту в терминах открытой распределенной обработки (ОРО).

3.23 поставщик электронной медицинской карты (electronic health record provider): Легитимный обладатель электронной медицинской карты, передающий ее другому заинтересованному субъекту.

3.24 получатель электронной медицинской карты (electronic health record recipient): Субъект, которому поставщик электронной медицинской карты передает электронную медицинскую карту.

3.25 инициатор запроса электронной медицинской карты (electronic health record requester): Объект, инициирующий запрос на передачу электронной медицинской карты от поставщика к получателю электронной медицинской карты.

3.26 система ведения электронных медицинских карт (electronic health record system): Система, предназначенная для записи, извлечения и преобразования информации в электронных медицинских картах.

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

3.28 федеративная медицинская карта (federated health record): Виртуальное представление медицинской карты пациента, которое может быть получено с помощью передачи стандартных выписок из всех записей электронных медицинских карт этого пациента, хранящихся в разных системах.

3.29 система-источник (feeder system): Хранилище (данных медицинских карт), к которому может быть обращен запрос в рамках федерации систем ведения электронных медицинских карт для пополнения данных в федеративной медицинской карте.

3.30 типовой (generic): Применимый к требованиям или информационным моделям разных медицинских специалистов, предметных областей и стран.

3.31 медицинский агент (healthcare agent): Лицо, прибор или программное обеспечение, выполняющее определенную роль в оказании медицинской помощи.

3.32 медицинский прибор (healthcare device): Прибор или оборудование, прямо или косвенно участвующее в оказании медицинской помощи отдельному лицу или популяции.

3.33 медицинское учреждение (healthcare organization): Учреждение, прямо или косвенно участвующее в оказании медицинской помощи отдельному лицу или популяции.

3.34 участник сферы здравоохранения (healthcare party): Лицо, прямо или косвенно участвующее в оказании медицинской помощи отдельному лицу или популяции.

3.35 медицинская услуга (healthcare service): Услуга, предоставляемая с целью прямо или косвенно улучшить состояние здоровья отдельного лица или популяции, которым она предоставляется.

3.36 унаследованные данные (legacy data): Данные, которые собирались и обрабатывались в "предыдущей" системе, но теперь хранятся в "текущей" системе.

3.37 метаданные (metadata): Данные, определяющие класс объекта и свойства собранной информации.

3.38

неоспоримость (non-repudiation): Служба, обеспечивающая любую из участвующих сторон подтверждение целостности и происхождения данных (неразрывно друг от друга).**

[ИСО/ТС 17090-1:2002*, статья 3.2.21]

_______________
* Отменен. Действует ИСО 17090-1:2008. Для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.
** Текст документа соответствует оригиналу. - .

3.39 пациент (patient): Синоним термина "субъект медицинской помощи".

3.40 постоянные данные (persistent data): Данные, хранящиеся на постоянной основе.

3.41 персональная медицинская карта (personal health record): Медицинская карта, содержание которой контролирует субъект медицинской помощи или его законный представитель.

3.42

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

[ИСО/МЭК 2382-8:1998, статья 08.01.23]

3.43 элемент записи (record component): Часть выписки из электронной медицинской карты одного субъекта медицинской помощи, представленная как узел в иерархической структуре данных, соответствующей настоящему стандарту.

3.44

роль (role): Совокупность образов действий, связанная с решаемой задачей.

[ИСО/ТС 17090-1:2002*, статья 3.2.24]

_______________
* Отменен. Действует ИСО 17090-1:2008. Для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.

3.45

семантическая интероперабельность (semantic interoperability): Свойство данных, совместно используемых несколькими системами, быть понятными на уровне полностью определенных понятий предметной области.

[ИСО/ТС 18308-2004*, статья 3.38]

_______________
* Отменен. Действует ИСО 18308:2011. Для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.

3.46

совместно используемая электронная медицинская карта (shareable electronic health record): Электронная медицинская карта со стандартизованной информационной моделью,

зависящая от систем ведения электронных медицинских карт и доступная многим

авторизованным пользователям.

[ИСО/ТС 20514:2005, статья 2.33]

3.47

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

[ИСО/МЭК Руководство 2:2004, статья 3.2]

3.48

состояние (процесса) [state (of a process)]: Условие или ситуация, в котором находится объект в период его жизненного цикла и при котором данный объект удовлетворяет некоторому условию, выполняет некоторое действие или ожидает некоторого события.

[ИСО/ТС 18308-2004*, статья 3.39]

_______________
* Отменен. Действует ИСО 18308:2011. Для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.

3.49 субъект медицинской помощи (subject of care): Лицо, которому запланирована медицинская помощь, получающее или получившее медицинскую помощь.

3.50 точка зрения (view): Альтернативное представление данных для другого пользователя или другой цели.

4 Обозначения и сокращения


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

CEN

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

CEN/TC 251

- Технический комитет 251 CEN, разрабатывающий стандарты по информатизации здоровья (CEN Technical Committee 251);

СМЕТ

- общий тип элементов сообщения (формализм, определенный в HL7) (Common Message Element Type);

ЭИБ (EHCR)

- электронная история болезни (Electronic Healthcare Record);

ЭМК (EHR)

- электронная медицинская карта (Electronic Health Record);

EC (EU)

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

GEHR

- Исследовательский проект 1992-1995 гг. (Good European Health Record);

GP

- врач общей практики (general practitioner);

HISA

- архитектура сервисов информатизации здоровья (акроним, использованный в [17]) (Health Informatics Service Architecture);

HL7

- Health Level Seven;

IANA

- Комитет по присвоению адресов в Интернете (Internet Assigned Numbers Authority);

IETF

- Инженерная группа по развитию Интернета (Internet Engineering Task Force);

ИСО (ISO)

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

OPO (ODP)

- открытая распределенная обработка (используется для описания распределенных систем [13]) (Open Distributed Processing);

ОИД (OID)

- объектный идентификатор (Object Identifier);

НИОКР (R&D)

- научно-исследовательские и опытно-конструкторские работы (Research and Development);

RFC

- рабочие предложения (request for comments);

UML

- унифицированный язык моделирования (Unified Modeling Language);

W3C

- Консорциум по всемирной сети (World Wide Web Consortium);

XML

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


5 Соответствие

5.1 Соответствие системы ведения ЭМК

5.1.1 Система передачи данных ЭМК удовлятворяет требованиям настоящего стандарта, если вся подлежащая обмену информация, соответствующая области применения настоящего стандарта, может быть представлена в форме, в которой существует прямое соответствие между структурой обмениваемых данных и информационной моделью EHR_EXTRACT, определенной в разделе 6 с использованием языка UML. Другие модели обмена определены в ИСО 13606-5.

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

5.1.3 Рекомендуется выпустить заявление о соответствии. Краткие указания, что оно может содержать:

a) обозначение продукта/системы;

b) целевое назначение или назначения системы ведения ЭМК (например, является ли она специализированной, используемой при оказании первичной медицинской помощи, предназначенной для стационаров или ограниченной конкретной медицинской специальностью);

c) способность передавать или принимать выписки EHR_EXTRACT, либо выполнять оба действия;

d) объявление реализованного подмножества классов стандарта;

e) объявление используемых типов данных;

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

g) спецификацию синтаксиса или синтаксисов, применяемых для представления выписки EHR_EXTRACT (например, могут быть указаны конкретные XML-схемы).

5.2 Соответствие стран-участниц

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

5.2.3 Данный национальный профиль должен использоваться для проверки на соответствие в данной стране-участнице.

5.2.4 В целях исполнения данного заявления о соответствии национальные органы стандартизации должны уведомить ИСО/ТК 215 о том, что национальный профиль необходим и используется для проверки на соответствие в сфере их юрисдикции.

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

5.2.6 Комитет ИСО/ТК 215 должен опубликовать уведомление о данном национальном профиле.

6 Базовая модель

6.1 Указатель к пакетам


Примечание - Классы в пакетах указаны в алфавитном порядке для удобства поиска. В приведенных далее табличных спецификациях данные приведены в порядке их появления на диаграммах.

Пакет EXTRACT:

Пакет SUPPORT:

ATTESTATION_INFO

CS

AUDIT_INFO

CV

CLUSTER

DATA_VALUE

COMPOSITION

ED

CONTENT

II

EHR_EXTRACT

IVL

ELEMENT

OID

ENTRY

TEXT

EXTRACT_CRITERIA

TS

FOLDER

URI

FUNCTIONAL_ROLE

ITEM

LINK

RECORD_COMPONENT

RELATED_PARTY

SECTION

Пакет DEMOGRAPHICS:

Пакет PRIMITIVES:

ENTITY_NAME

Array<T>

ENTITY_NAME_PART

Boolean

HEALTHCARE_PROFESSIONAL_ROLE

Byte

IDENTIFIED_ENTITY

Character

IDENTIFIED_HEALTHCARE_PROFESSIONAL

Double

ORGANIZATION

Integer

PERSON

List<T>

POSTAL_ADDRESS

Real

POSTAL_ADDRESS_PART

Set<T>

SOFTWARE_OR_DEVICE

String

SUBJECT_OF_CARE_PERSON_IDENTIFICATION

TELECOM


6.2 Пакет EXTRACT

6.2.1 Общая информация

Элементы, входящие в пакет EXTRACT

Имя

Тип

ATTESTATION_INFO

Класс

AUDIT_INFO

Класс

CLUSTER

Класс

COMPOSITION

Класс

CONTENT

Класс

EHR_EXTRACT

Класс

ELEMENT

Класс

ENTRY

Класс

EXTRACT_CRITERIA

Класс

FOLDER

Класс

FUNCTIONAL_ROLE

Класс

ITEM

Класс

LINK

Класс

RECORD_COMPONENT

Класс

RELATED_PARTY

Класс

SECTION

Класс

Рисунок 3 - Диаграмма классов UML пакета EXTRACT


Рисунок 3 - Диаграмма классов UML пакета EXTRACT

6.2.2 Класс EHR_EXTRACT

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

Атрибуты

Сигнатура

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

Кратность

Описание

authorizing_party:ll

0..1

-

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

ehr_id:ll

1

-

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

ehr_system: ll

1

-

Идентификатор системы поставщика ЭМК, из которой сделана данная выписка

rm_id:String

1

-

Идентификатор и версия стандарта базовой модели, в соответствии с которым сделана данная выписка EHR_EXTRACT. Для выписки из ЭМК, соответствующей настоящему стандарту, данный атрибут должен иметь строковое значение "ISO 13606"

subject_of_care: II

1

-

Уникальный идентификатор субъекта медицинской помощи, из ЭМК которого сделана данная выписка, определенный в системе поставщика ЭМК

time_created:TS

1

-

Дата и время момента запроса или экспорта данных из ЭМК субъекта медицинской помощи для создания данной выписки

all_compositions: Set<COMPOSITION>

0..1

0..*

Все композиции COMPOSITION, содержащиеся в данной выписке EHR_EXTRACT, включены по значению с помощью данной ассоциации

criteria: Set<EXTRACT_CRITERIA>

0..1

0..*

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

folders:Set<FOLDER>

0..1

0..*

Иерархия томов FOLDER, содержащаяся в выписке EHR_EXTRACT; каждый том FOLDER может содержать несколько идентификаторов rc_id композиций COMPOSITION и/или других томов FOLDER

demographic extract: Set<IDENTIFIED_ENTITY>

0..1

0..*

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


6.2.3 Класс EXTRACT_CRITERIA

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

Атрибуты

Сигнатура

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

Кратность

Описание

all_versions: Boolean

0..1

-

Данный атрибут показывает, ограничена ли данная выписка EHR_EXTRACT самыми последними версиями композиций COMPOSITION или содержит все предыдущие версии

archetype_ids: SET<II>

0..1

-

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

max_sensitivity: Integer

0..1

-

Данный атрибут определяет максимально разрешенный уровень чувствительности (рамки авторизации), использованный для извлечения данных из системы поставщика ЭМК

multimedia_included: Boolean

0..1

-

Данный атрибут показывает, были ли мультимедийные данные намеренно исключены из данной выписки EHR_EXTRACT

other_constraints: String

0..1

-

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

time_period: IVL<TS>

0..1

-

Данный атрибут содержит дату или интервал времени, ограничивающий данную выписку EHR_EXTRACT


6.2.4 Класс RECORD_COMPONENT{Abstract}

Непосредственные подклассы: CONTENT, COMPOSITION, ITEM и FOLDER.

Данный абстрактный класс является суперклассом для всех конкретных узлов иерархии ЭМК: тома FOLDER, композиции COMPOSITION, раздела SECTION, подраздела ENTRY, кластера CLUSTER, элемента ELEMENT, а также для двух абстрактных классов: содержания CONTENT и сущности ITEM.

Атрибуты

Сигнатура

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

Кратность

Описание

archetype_id: String

0..1

-

Уникальный идентификатор узла архетипа, которому соответствует данный элемент RECORD_COMPONENT, присвоенный либо системой поставщика ЭМК, либо при выполнении отображения, примененного для создания данной выписки EHR_EXTRACT. Синтаксис значения данного атрибута определен в ИСО 13606-2

meaning:CV

0..1

-

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

name:TEXT

1

-

Имя, представленное кодированным значением или обычным текстом. Указывает медицинское или административное понятие, которому соответствует данный элемент ЭМК. Берется из системы ведения ЭМК, в которой данный элемент появился впервые

orig_parent_ref:ll

0..1

-

Идентификатор элемента RECORD_COMPONENT, являющегося исходным родителем (контекстом) данного элемента RECORD_COMPONENT. Он должен присутствовать, если данная информация была скопирована из другой части ЭМК данного субъекта медицинской помощи

policy_ids:SET<ll>

0..1

-

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

rc_id:ll

1

-

Глобально уникальный идентификатор, с помощью которого осуществляются ссылки на данный узел иерархии ЭМК в системе ведения ЭМК, в которой данные этого узла появились впервые. Этот идентификатор должен быть сохранен получателем ЭМК и повторно использован, если впоследствии данный элемент RECORD_COMPONENT будет включен в другую выписку EHR_EXTRACT

sensitivity: Integer

0..1

-

Чувствительность данного элемента RECORD_COMPONENT, представленная с помощью системы кодирования значений данного атрибута, определенной в ИСО 13606-4

synthesised: Boolean

1

-

Этот атрибут должен иметь значение TRUE (ИСТИНА), если данный элемент RECORD_COMPONENT был создан для того, чтобы соответствовать настоящему стандарту, но сам этот элемент отсутствует в ЭМК, из которой извлечена данная выписка

links:Set<LINK>

0..1

0..*

Любой элемент RECORD_COMPONENT может не иметь ни одной или иметь несколько семантических связей с другими элементами RECORD_COMPONENT

feeder_audit: AUDIT_INFO

0..1

-

Эта ассоциация представляет информацию об отправке и изменениях, относящуюся к данному RECORD_COMPONENT в системе ведения ЭМК, в которую он был первоначально отправлен. Данная ассоциация может быть опущена, если информация об отправке и изменениях элемента RECORD_COMPONENT та же самая, что и у его родительского элемента RECORD_COMPONENT. Для композиции COMPOSITION данная ассоциация также может быть опущена, если система поставщика ЭМК является системой, в которой данные композиции появились впервые (поскольку информация об отправке и изменениях будет идентична той, что представлена с помощью ассоциации committal)


6.2.5 Класс FOLDER

RECORD COMPONENT

|
+- - FOLDER

Класс тома FOLDER может использоваться для организации и группировки классов COMPOSITION в выписке EHR_EXTRACT. Иерархия томов может соответствовать или иметь сходство с верхними уровнями организации данных ЭМК в системе ЭМК поставщика, либо быть созданной специально для данной выписки EHR_EXTRACT.

Атрибуты, унаследованные от ассоциаций

Сигнатура

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

Кратность

Описание

sub-folders: Set<FOLDER>

0..1

0..*

Данная ассоциация обеспечивает представление иерархии томов FOLDER

attestations: Set<ATTESTATION_lNFO>

0..1

0..*

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

compositions: Set<COMPOSITION>

0..1

0..*

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


6.2.6 Класс COMPOSITION

RECORD COMPONENT

|
+ - - COMPOSITION

Класс композиции COMPOSITION представляет собой совокупность элементов RECORD_COMPONENT, составленную (созданную) в течение одного врачебного приема или сеанса документирования и отправленную в одну ЭМК.

Атрибуты

Сигнатура

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

Кратность

Описание

contribution_id:ll

0..1

-

Данный необязательный идентификатор может использоваться для логической группировки совокупности композиций COMPOSITION, отправленных одним пользователем в один момент времени в ЭМК одного субъекта лечения, если система ведения ЭМК допускает одновременную отправку данных нескольких композиций COMPOSITION

session_time: IVL<TS>

0..1

-

Дата и время или интервал, в течение которого имел место врачебный прием или сеанс документирования

territory:CS

0..1

-

Код территории, на которой была создана данная композиция COMPOSITION, соответствующий стандарту ИСО 3166 [3-5]. Этот код указывает страну, в соответствии с законами которой была создана данная композиция COMPOSITION


Атрибуты, унаследованные от ассоциаций

Сигнатура

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

Кратность

Описание

attestations: Set<ATTESTATION_INFO>

0..1

0..*

Данная ассоциация позволяет композиции COMPOSITION содержать любое число аттестаций, относящихся к ней или к ее содержанию

other_participations:Set <FUNCTIONAL_ROLE>

0..1

0..*

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

committal: AUDIT_INFO

1

-

Данная обязательная ассоциация содержит информацию об отправке (и факультативно об изменениях) содержания данной композиции COMPOSITION в систему поставщика ЭМК

content: Set<CONTENT>

0..1

0..*

Данная ассоциация содержит совокупность разделов SECTION и подразделов ENTRY, являющихся частью данной композиции COMPOSITION. Композиция COMPOSITION может не иметь содержания, если она заменяет ошибочно записанную композицию COMPOSITION

composer: FUNCTIONAL_ROLE

0..1

-

Агент (лицо, прибор или программное обеспечение), ответственное за создание, синтезирование или организацию информации, отправленной в ЭМК. Данный агент несет ответственность за информацию, включенную в данную ЭМК, даже если он не является ее источником информации или тем, кто ее отправил. Замена составителя при изменении содержания композиции не является обязательной; обычно она зависит от объема изменений


Ограничение

Имя

Выражение

Описание

TERRITORY

inv: territory.coding_scheme_name = "ISO 3166"

-


6.2.7 Класс CONTENT{Abstract}

RECORD COMPONENT

|
+ - - CONTENT

Непосредственные подклассы: ENTRY и SECTION.

Данный класс является абстрактным родителем для классов SECTION и ENTRY, представляющих содержание данных ЭМК в композиции COMPOSITION.

6.2.8 Класс SECTION

CONTENT

|
+ - - SECTION

Класс раздела SECTION содержит совокупность подразделов ENTRY и факультативно, другие разделы SECTION, сгруппированные под одним медицинским заголовком.

Атрибут, унаследованный от ассоциаций

Сигнатура

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

Кратность

Описание

members: Set<CONTENT>

0..1

0..*

Данная ассоциация позволяет разделу SECTION содержать другие разделы SECTION и/или подразделы ENTRY


6.2.9 Класс ENTRY

CONTENT

|
+ - - ENTRY

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

Атрибуты

Сигнатура

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

Кратность

Описание

act_id:String

0..1

-

Если данный раздел ENTRY описывает действие, то идентификатор, содержащийся в этом атрибуте, связывает этот раздел с системой управления действиями или рабочими процессами

act_status:CS

0..1

-

Если данный раздел ENTRY описывает действие, управляемое системой управления действиями или рабочими процессами, то данный атрибут содержит состояние действия. Система кодирования этих состояний определена в ИСО 13606-3

subject_of_informatio n_category:CS

0..1

-

Категория отношения лица или объекта, информация о котором содержится в данном подразделе ENTRY, к субъекту медицинской помощи. Система кодирования значений данного атрибута определена в ИСО 13606-3. Для передачи данных о нескольких субъектах информации в выписке EHR_EXTRACT должен использоваться отдельный подраздел ENTRY для каждого субъекта

uncertainty_expresse d:Boolean

1

-

Если данный атрибут имеет значение TRUE (ИСТИНА), то это указывает получателю ЭМК, что данные этого подраздела ENTRY имеют некоторую степень неопределенности и что при использовании этих данных в автоматизированных процессах и системах необходимо принимать меры предосторожности


Атрибуты, унаследованные от ассоциаций

Сигнатура

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

Кратность

Описание

items: Set<ITEM>

0..1

0..*

Данная ассоциация содержит структуру содержания подраздела ENTRY

info_provider: FUNCTIONAL_ROLE

0..1

-

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

other_participations: Set<FUNCTIONAL_ROLE>

0..1

0..*

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

subject_of_information: RELATED_PARTY

0..1

-

Отношение к субъекту лечения и необязательный идентификатор лица или объекта, информация о котором содержится в данном подразделе ENTRY


Ограничения

Имя

Выражение

Описание

ACT_STATUS

inv: act_status.coding_scheme_name =
'CEN/TC251/EN13606-3:ACT_STATUS'

-

SUBJECT_CATEGORY

inv: subject_of_information_category.coding_scheme name = 'CEN/TC251/EN13606-3:SUBJECT_CATEGORY'

-


6.2.10 Класс ITEM{Abstract}

RECORD COMPONENT

|
+ - - ITEM

Непосредственные подклассы: ELEMENT и CLUSTER.

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

Атрибуты

Сигнатура

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

Кратность

Описание

emphasis:CV

0..1

-

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

item_category:CS

0..1

-

Значение данного атрибута может использоваться для классификации или логической группировки элементов структуры данных сущности ITEM, для различения основных значений в методе исследования, состоянии пациента и т.д. Система кодирования значений данного атрибута определена в ИСО 13606-3

obs_time:IVL<TS>

0..1

-

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


Ограничение

Имя

Выражение

Описание

ITEM_CATEGORY

inv:item_category.coding_scheme_name =
'CEN/TC251/EN13606-3:ITEM_CATEGORY'

-


6.2.11 Класс CLUSTER

ITEM

|
+- - CLUSTER

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

Атрибут

Сигнатура

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

Кратность

Описание

structure_type:CS

1

-

Этот атрибут указывает время и/или пространственную организацию данных в данном кластере CLUSTER. Система кодирования значений данного атрибута определена в части ИСО 13606-3


Атрибут, унаследованный от ассоциаций

Сигнатура

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

Кратность

Описание

parts:Set<ITEM>

0..1

0..*

С помощью этой ассоциации кластер CLUSTER может включать в себя содержать другие кластеры CLUSTER и/или элементы ELEMENT*


Ограничение

Имя

Выражение

Описание

STRUCTURE_TYPE

inv: structure_type.coding_scheme_name = 'CEN/TC251/EN13606-3:STRUCTURE_TYPE'

-


6.2.12 Класс ELEMENT

ITEM

|
+ - - ELEMENT

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

Атрибут, унаследованный от ассоциаций

Сигнатура

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

Кратность

Описание

value:DATA_VALUE

0..1

-

Элемент ELEMENT имеет единственный атрибут с типом данных DATA_VALUE, содержащий значение, если только он не определен как отсутствующий с помощью атрибута null_flavour


6.2.13 Класс AUDIT_INFO

Данный класс содержит элемента RECORD_COMPONENT*. С помощью ассоциации committal, идущей от композиции COMPOSITION, этот класс позволяет указать данные об отправке и изменении содержания композиции COMPOSITION в системе поставщика ЭМК. С помощью ассоциации feeder_audit, идущей от элемента RECORD_COMPONENT, данный класс позволяет указать сведения об отправке и изменениях этого элемента RECORD_COMPONENT в той системе ведения ЭМК, в которую он был впервые отправлен.
_______________

* Текст документа соответствует оригиналу. - .


Атрибуты

Сигнатура

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

Кратность

Описание

committer:ll

1

-

Сторона, ответственная за отправку данного элемента RECORD_COMPONENT в ЭМК данного субъекта медицинской помощи

ehr_system:ll

1

-

Данный атрибут идентифицирует систему ведения ЭМК, в которую был отправлен данный элемент RECORD_COMPONENT

previous_version:ll

0..1

-

Этот атрибут содержит значение идентификатора rc_id элемента RECORD_COMPONENT, пересмотром которого является данный элемент RECORD_COMPONENT. Если данный атрибут пуст, то предыдущей версии не существует (т.е. данная версия является самой первой)

reason_for_revision:CV

0..1

-

Код причины присвоения статуса текущей версии

time_committed:TS

1

-

Дата и время, когда данный элемент RECORD_COMPONENT был отправлен в указанную систему ведения ЭМК и поэтому стал частью данной ЭМК субъекта медицинской помощи

version_set_id:ll

0..1

-

Этот атрибут содержит значение идентификатора rc_id самой первой версии данного элемента RECORD_COMPONENT. Данный атрибут может отсутствовать, если данный элемент RECORD_COMPONENT является самой первой версией

version_status:CS

0..1

-

Медико-правовой статус данной версии элемента RECORD_COMPONENT. Система кодирования значений данного атрибута определена в ИСО 13606-3


Ограничение

Имя

Выражение

Описание

VERSION_STATUS

inv:attribute version_status.coding_scheme_name = 'CEN/TC251/EN13606-3:VERSION_STATUS'

-


6.2.14 Класс ATTESTATION_INFO

Этот класс содержит детальные сведения об аттестациях элементов RECORD_COMPONENT, содеращихся в томе FOLDER или композиции COMPOSITION.

Атрибуты

Сигнатура

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

Кратность

Описание

attested_view:ED

0..1

-

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

proof: ED

0..1

-

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

reason_for_attestation:CV

1

-

Кодированное значение причины проведения данной аттестации, определяющее ее конкретную причину или юридическое требование для ее проведения

time:TS

1

-

Дата и время проведения аттестации


Атрибуты, унаследованные от ассоциаций

Сигнатура

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

Кратность

Описание

target:Set<RECORD_COMPONENT>

1

1..*

Идентификатор(ы) rc_id аттестованного элемента (аттестованных элементов) RECORD_COMPONENT

attester: FUNCTIONAL_ROLE

1

-

Идентификация и роль лица, проводившего аттестацию


6.2.15 Класс FUNCTIONAL_ROLE

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

Атрибуты

Сигнатура

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

Кратность

Описание

function:CV

0..1

-

Кодированное значение исполненной функции или роли

healthcare_facility:ll

0..1

-

Учреждение, в котором исполнялась данная роль

mode:CS

0..1

-

Механизм участия в функции или роли. Система кодирования значений данного атрибута определена в ИСО 13606-3

performer:II

1

-

Идентификация агента, исполнившего данную функцию или роль

service_setting :CV

0..1

-

Тип условий медицинской помощи, в которых исполнялась данная роль


Ограничение

Имя

Выражение

Описание

FUNCTIONAL_ROLE_MODE

inv:mode.coding_scheme_name = 'CEN/TC251/EN13606-3:FUNCTIONAL_ROLE'

-


6.2.16 Класс RELATED_PARTY

Класс RELATED_PARTY является базовым классом атрибута subject_of_information подраздела ENTRY. Этот атрибут позволяет идентифицировать лицо в терминах его связи с субъектом медицинской помощи.

Атрибуты

Сигнатура

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

Кратность

Описание

party:ll

0..1

-

Необязательная персональная идентификация связанной стороны

relationship:TEXT

1

-

Связь стороны с субъектом медицинской помощи


6.2.17 Класс LINK

Класс LINK определяет семантику нелокализованной связи между двумя компонентами RECORD_COMPONENT. Исходный компонент RECORD_COMPONENT может иметь связи с произвольным числом конечных компонентов RECORD_COMPONENT.

Атрибуты

Сигнатура

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

Кратность

Описание

follow_link: Boolean

1

-

Этот атрибут имеет значение TRUE (ИСТИНА), если композиция COMPOSITION, содержащая целевой элемент RECORD_COMPONENT, должна быть включена в данную выписку EHR_EXTRACT

nature:CS

1

-

Обобщенная семантическая категория связи, объявленной между двумя элементами RECORD_COMPONENT. Система кодирования значений данного атрибута определена в ИСО 13606-3

role:CV

0..1

-

Детальное описание семантической связи целевого элемента RECORD_COMPONENT с исходным элементом RECORD_COMPONENT. Необязательная система кодирования значений данного атрибута определена в ИСО 13606-3


Атрибут, унаследованный от ассоциаций

Сигнатура

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

Кратность

Описание

target: Set<RECORD_COMPONENT>

1

1..*

Идентификатор rc_id элемента RECORD_COMPONENT, являющегося целью ассоциации

6.3 Пакет DEMOGRAPHICS

6.3.1 Общая информация

Элементы пакета DEMOGRAPHICS

Имя

Тип

_self - S.276.1107.04.24ENTITY_NAME

Класс

_self - S.276.1107.04.27ENTITY_NAME_PART

Класс

_self - S.276.1107.04.56HEALTHCARE_PROFESSIONAL_ROLE

Класс

_self - S.276.1107.04.7IDENTIFIED_ENTITY

Класс

_self - S.276.1107.04.38IDENTIFIED_HEALTHCARE_PROFESSIONAL

Класс

_self - S.276.1107.04.62ORGANIZATION

Класс

_self - S.276.1107.04.69PERSON

Класс

_self - S.276.1107.04.31POSTAL_ADDRESS

Класс

_self - S.276.1107.04.35POSTAL_ADDRESS_PART

Класс

_self - S.276.1107.04.52SOFTWARE_OR_DEVICE

Класс

_self - S.276.1107.04.12SUBJECT_OF_CARE_PERSON_IDENTIFICATION

Класс

_self - S.276.1107.04.65TELECOM

Класс

Рисунок 4 - Диаграмма классов UML пакета DEMOGRAPHICS


Рисунок 4 - Диаграмма классов UML пакета DEMOGRAPHICS

6.3.2 Класс IDENTIFIED_ENTITY{Abstract}

Непосредственные подклассы: SOFTWARE_OR_DEVICE, ORGANIZATION, PERSON.

Этот класс может содержать информацию о любой идентифицируемой стороне, например об учреждении, лице, приборе или программном обеспечении.

Атрибуты

Сигнатура

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

Кратность

Описание

extract_id:ll

1

-

Уникальный идентификатор, одинаково используемый в пакете EXTRACT, определяющем выписку EHR_EXTRACT, для идентификации объекта IDENTIFIED_ENTITY, определенного в данном пакете DEMOGRAPHICS

id:

0..1

-

Необязательная совокупность идентификаторов, присваиваемых службами здравоохранения, профессиональными органами и т.д. данному объекту IDENTIFIED_ENTITY в системах ведения ЭМК. Идентификаторы используются получателем ЭМК при поиске этого объекта по демографическим данным


Атрибут, унаследованный от ассоциаций

Сигнатура

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

Кратность

Описание

telecom: Set<TELECOM>

0..1

0..*

Совокупность телекоммуникационных адресов, предназначенных для контакта или связи с данным объектом IDENTIFIED_ENTITY


6.3.3 Класс SOFTWARE_OR_DEVICE

IDENTIFIED ENTITY

|
+ - - SOFTWARE_OR_DEVICE

Данный класс представляет описание оборудования или прибора (соответствует компоненту GPIC 2.055).

Атрибуты

Сигнатура

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

Кратность

Описание

code: CV

1

-

Код, используемый для описания типа прибора или оборудования

desc: String

1

-

Строка, используемая для описания деталей типа прибора или информации, дополняющей код типа прибора

manufacturerModelName: String

1

-

Наименование модели и, возможно, ее версии, как они обозначены производителем

version: String

0..1

-

-


Атрибут, унаследованный от ассоциаций

Сигнатура

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

Кратность

Описание

owningOrganization: ORGANIZATION

0..1

-

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


6.3.4 Класс ORGANIZATION

IDENTIFIED ENTITY

|
+ - - ORGANIZATION

Данный класс представляет информацию об организации (соответствует компоненту GPIC 2.008).

Атрибуты

Сигнатура

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

Кратность

Описание

code: CV

1

-

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

desc: String

1

-

Описание организации свободным текстом

name: String

1

-

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


Атрибут, унаследованный от ассоциаций

Сигнатура

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

Кратность

Описание

addr:Set<POSTAL_ADDRESS>

0..1

0..*

С помощью этой ассоциации можно указать любое число адресов данной организации


6.3.5 Класс PERSON

IDENTIFIED ENTITY

|
+ - - PERSON

Непосредственные подклассы: IDENTIFIED_HEALTHCARE_PROFESSIONAL, SUBJECT_OF_CARE_PERSON_IDENTIFICATION.

Данный класс представляет общие демографические данные лица (соответствует компоненту GPIC 2.006).

Атрибуты, унаследованные от ассоциаций

Сигнатура

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

Кратность

Описание

name:Set<ENTITY_NAME>

0..1

0..*

Данная ассоциация представляет имя (имена), под которым известно данное лицо

addr:Set<POSTAL_ADDRESS>

0..1

0..*

С помощью этой ассоциации можно указать любое число адресов данного лица


6.3.6 Класс IDENTIFIED_HEALTHCARE_PROFESSIONAL

PERSON

|
+ - - IDENTIFIED_HEALTHCARE_PROFESSIONAL

Данный класс обеспечивает средства для ссылок на идентифицированного медицинского работника (основан на GPIC 2.034, но с более подробной ролевой связью).

Атрибут, унаследованный от ассоциаций

Сигнатура

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

Кратность

Описание

role:Set<HEALTHCARE_
PROFESSIONAL_ROLE>

0..1

0..*

Данная ассоциация позволяет указать для объекта IDENTIFIED_HEALTHCARE_PROFESSIONAL любое число ролей, которые контролируются (авторизуются) одной или несколькими организациями


6.3.7 Класс HEALTHCARE_PROFESSIONAL_ROLE

Данный класс описывает роль, исполняемую лицом, являющимся медицинским работником (основан на одноименном классе GPIC, но с добавлением ассоциации с идентифицированным классом ORGANIZATION).

Атрибуты

Сигнатура

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

Кратность

Описание

id:Set<ll>

0..1

-

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

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

position_or_grade:CV

0..1

-

Название должности медицинского работника. Примеры: старшая медсестра, интерн

profession:CV

0..1

-

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

specialty:CV

0..1

-

Код специальности медицинского работника. Примеры: дерматология, терапия


Атрибут, унаследованный от ассоциаций

Сигнатура

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

Кратность

Описание

scopingOrganization: ORGANIZATION

0..1

-

Организация, в которой может выполняться, а также авторизоваться данная роль


6.3.8 Класс SUBJECT_OF_CARE_PERSON_IDENTIFICATION

PERSON
|
+ - - SUBJECT_OF_CARE_PERSON_IDENTIFICATION

Данный класс представляет информацию о лице, которую можно использовать в целях идентификации (соответствует компоненту GPIC 2.015).

Атрибуты

Сигнатура

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

Кратность

Описание

administrativeGenderCode:CS

1

-

Пол пациента, используемый для административных целей (может не использоваться в клинических целях). Значения: 0 = мужской, 1 = женский, 2 = гермафродит, 9 = неизвестен

birthOrderNumber: Integer

0..1

-

Для новорожденных пациентов при многоплодных родах - порядок рождения.

birthTime:TS

1

-

Дата и время рождения

Примечание - Время рождения может быть указано как дата и время, дата или просто год

deceasedTime:TS

0..1

-

Дата и время смерти


6.3.9 Класс TELECOM

(Соответствует группе Common Access Group компонентов GPIC.)

Указатель местонахождения некоторого ресурса (информации или сервисов), доступного с помощью телекоммуникационного оборудования. Ответчиком по указанному телекоммуникационному адресу может быть автоматическая служба, возвращающая информацию (например, служба FTP или HTTP). В таких случаях телекоммуникационный адрес служит ссылкой на информацию, доступную с помощью этого адреса. Использование телекоммуникационного адреса может быть ограничено во времени, иметь ограниченный период действия и может иметь определенное предназначение (код, указывающий обстоятельства, при которых данный телекоммуникационный адрес является предпочтительным среди других адресов). Телекоммуникационный адрес является расширением универсального указателя ресурса (URL), определенного в стандарте Интернета [23].

Атрибуты

Сигнатура

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

Кратность

Описание

telecomAddress:URI

1

-

Адрес задается строкой символов, формат которой полностью определяется схемой URI

use:SET<CS>

0..1

-

Значения: НТ = домашний телефон, WT = рабочий телефон, AS = служба телефонисток, ЕС = экстренная связь, МС = мобильная связь, PG = пейджер, FX = факс

validTime:IVL<TS>

0..*

-

Один или несколько интервалов времени, когда можно пользоваться данным типом телекоммуникационного адреса (например, после 18:00)


6.3.10 Класс POSTAL_ADDRESS

Данный класс используется для представления почтового, домашнего или служебного адреса (соответствует группе Common Access Group компонентов GPIC).

Атрибуты

Сигнатура

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

Кратность

Описание

addressUse: SET<CS>

0..1

-

Один или несколько кодов, позволяющих системе или пользователю выбрать нужный из ряда похожих адресов для заданной цели. Значения: BIR (место рождения), Н (домашний), HP (основной домашний), HV (адрес в отпуске), WP (рабочее место)

postalCode:String

0..1

-

Почтовый код или индекс

validTime:IVL<TS>

0..1

-

Интервал времени действия данного адреса

Примечание - Интервал времени действия может быть задан:

- датой/временем начала действия,

- датой/временем конца действия,

- двумя этими значениями


Атрибут, унаследованный от ассоциаций

Сигнатура

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

Кратность

Описание

addrPart:Set<POSTAL_
ADDRESS_PART>

0..1

0..*

Данная ассоциация указывает части структурированного адреса


6.3.11 Класс POSTAL_ADDRESS_PART

Данный класс представляет строку адреса (соответствует группе Common Access Group компонентов GPIC).

Атрибуты

Сигнатура

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

Кратность

Описание

addressLine:String

1

-

Часть адреса, представленная в виде строки

addressLineType:CS

0..1

-

Значения: BNM = название судна, CNT = страна, СРА = округ или район, HNM = номер квартиры, РОВ = почтовый ящик, SAL = адресная строка улицы, STA = республика или область, STR = название улицы


6.3.12 Класс ENTITY NAME

Данный класс определяет имя объекта - фамилию, имя и отчество лица или название организации, места либо предмета.

Пример - "Леонардо да Винчи", "Организация Объединенных Наций", "Эйфелева башня" и т.п.

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

Атрибуты

Сигнатура

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

Кратность

Описание

use:CV

1

-

Код назначения или основного использования имени

validTime:IVL<TS>

1

-

Интервал времени действия данного имени.

Примечание - Интервал времени действия может быть задан:

- датой/временем начала действия,

- датой/временем конца действия,

- двумя этими значениями


Атрибут, унаследованный от ассоциаций

Сигнатура

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

Кратность

Описание

namePart:Set<ENTITY_
NAME_PART>

1

1...*

Имя объекта может состоять из любого числа частей


6.3.13 Класс ENTITY_NAME_PART

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

Атрибуты

Сигнатура

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

Кратность

Описание

entityPartName:String

1

-

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

namePartQualifier:CS

1

-

Значения: АС = академическое звание, NB = дворянский титул, PR = профессиональный признак, W = префикс, BR = фамилия, имя, отчество в свидетельстве о рождении, CL = предпочтительные фамилия, имя, отчество, IN = инициал

namePartType:CS

1

-

Значения: FAM = фамилия, GIV = имя, PFX = префикс, SFX = суффикс


6.4 Пакет SUPPORT

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

Данный пакет содержит подмножество типов данных, определенных в СЕН/ТС 14796 и используемых в качестве типов данных атрибутов в пакетах EHR_EXTRACT и DEMOGRAPHICS. Более подробные сведения об этих типах данных, включая допустимые специализации классов, определенных в данном пакете, представлены в стандарте СЕН/ТС 14796.

Элементы пакета SUPPORT

Имя

Тип

_self - S.276.1107.04.234CS

Класс

_self - S.276.1107.04.244CV

Класс

_self - S.276.1107.04.2DATA_VALUE

Класс

_self - S.276.1107.04.191ED

Класс

_self - S.276.1107.04.187II

Класс

_self - S.276.1107.04.209IVL

Класс

_self - S.276.1107.04.209OID

Класс

_self - S.276.1107.04.226TEXT

Класс

_self - S.276.1107.04.269TS

Класс

_self - S.276.1107.04.211URI

Класс

Рисунок 5 - Диаграмма классов UML пакета SUPPORT


Примечание - Показанные на рисунке подтипы типа данных DATA_VALUE использованы в базовой модели в качестве типов данных атрибутов. Более полный набор подтипов типа данных DATA_VALUE, подходящих для типов значений элемента ELEMENT, приведен в СЕН/ТС 14796.

Рисунок 5 - Диаграмма классов UML пакета SUPPORT

6.4.2 Класс DATA_VALUE{Abstract}

Непосредственные подклассы: II, ED, CV, TEXT, CS, TS, URI, IVL.

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

Атрибут

Сигнатура

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

Кратность

Описание

null_flavour:CS

0...1

-

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

_______________

* Текст документа соответствует оригиналу. - .


Ограничение

Имя

Выражение

Описание

NULL_FLAVOUR

inv: null_flavour.coding_scheme_name =
'BS ISO 21090/A.2/Null flavour values'

-


6.4.3 Класс CS

DATA VALUE

|
+ - - CS

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

Атрибуты

Сигнатура

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

Кратность

Описание

codeValue:String

1

-

Строка, содержащая значение кода

codingScheme:OID

1

-

Объектный идентификатор (ОИД), соответствующий стандарту ИСО/МЭК 8824-1, обеспечивающий уникальную идентификацию системы кодирования, к которой относятся данное понятие и значение его кода, например, ОИД "106.75.314.67.89.24" может идентифицировать классификацию МКБ

codingSchemeName: String

1

-

Строка, содержащая наименование системы кодирования, например "SNOMED СТ"

codingSchemeVersion: String

1

-

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


6.4.4 Класс CV

DATA VALUE

|
+ - - CV

Класс CV представляет кодированные значения. Он похож на класс CS, но конкретные значения кодов с типом данных CV не задаются настоящим стандартом.

Атрибуты

Сигнатура

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

Кратность

Описание

codeValue:String

1

-

Строка, содержащая значение кода

codingScheme:OID

1

-

Объектный идентификатор (ОИД), соответствующий стандарту ИСО/МЭК 8824-1, обеспечивающий уникальную идентификацию системы кодирования, к которой относятся данное понятие и значение его кода, например, ОИД "106.75.314.67.89.24" может идентифицировать классификацию МКБ

codingSchemeName: String

1

-

Строка, содержащая наименование системы кодирования, например "SNOMED CT"

codingSchemeVersion: String

1

-

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

displayName:String

1

-

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


6.4.5 Класс TEXT

DATA VALUE

|
+ - - TEXT

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

Атрибуты

Сигнатура

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

Кратность

Описание

charsetCS

1

-

Определяет используемый набор символов и их кодировку

language:CS

1

-

Определяет язык текстовых данных. Система кодирования языков определена в [2]

originalText:String

1

-

Строка произвольной длины


6.4.6 Класс ED

DATA VALUE

|
+ - - ED

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

Атрибуты

Сигнатура

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

Кратность

Описание

alternateString:TEXT

1

-

Текст, предназначенный для вывода вместо отображения или воспроизведения мультимедийной информации

charset:CS

1

-

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

compression:CV

1

-

Указывает, являются ли исходные данные сжатыми и какой алгоритм сжатия использован

data:Array<Byte>

1

-

Двоичные данные, подлежащие передаче

integrityCheck: Array<Byte>

1

-

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

integrityCheckAlgorithm:CV

1

-

Указывает алгоритм расчета значения атрибута integrityCheck

language:CS

1

-

При передаче текстовой информации атрибут language определяет естественный язык текста в соответствии с [2]

mediaType:CS

1

-

Идентифицирует тип двоичных данных и метод их интерпретации или представления

reference:URI

1

-

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

size:lnteger

1

-

Размер данных в байтах

thumbnail:ED

1

-

Эскиз полного изображения


Ограничение

Имя

Выражение

Описание

MEDIA_TYPE

inv: media_type.coding_scheme_name = 'in BS ISO 21090:2005, Annex D' [16]

Домен типов носителей данных определен организацией IANA и описан в стандартах Интернет RFC 2045 [24] и 2046 [25]. В документе RFC 2046 тип носителя идентифицируется двумя компонентами: 1) тип носителя верхнего уровня и 2) подтип носителя. Однако настоящий стандарт трактует тип носителя как одну неделимую строку символов в виде, определенном организацией IANA, т.е. обозначение типа верхнего уровня, за которым следуют косая черта "/" и обозначение подтипа носителя. Текущие типы носителей зарегистрированы в базе данных организации IANA, доступной по адресу http.//www.iana.org/assignments/ mediatypes/index.html

CHARSET

inv: charset.coding_scheme_name = 'in BS ISO 21090 Annex С'

Используемый набор символов должен принадлежать к числу тех, что зарегистрированы Службой регистрации наборов символов Комитета по цифровым адресам в Интернете (IANA) (http:// www.iana.org/ assignments/character-sets) в соответствии с документом RFC 2978 [28]

LANGUAGE

inv: language.coding_scheme_name = "ISO 639"

-


6.4.7 Класс TS

DATA VALUE

|
+ - - TS

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

Примечания

1 Этот тип данных описан более полно в [7].

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

Атрибут

Сигнатура

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

Кратность

Описание

time:String

1

-

Полное представление календарной даты и времени в соответствии со стандартом ИСО 8601 [7]


6.4.8 Класс URI

DATA VALUE

|
+ - - URI

Данный класс предназначен для представления ссылки на объект, которая соответствует стандарту универсальных идентификаторов ресурсов (URI), описанному в документе RFC 2936 [27]. Описание универсальных идентификаторов ресурсов, подготовленное Тимом Бернерс-Ли (Tim Berners-Lee), представлено в Интернете по адресу http://www.ietf.org/rfc/rfc2396.txt. Начальные сведения об идентификаторах URI представлены по адресу http://www.w3.org/Addressing. Новые типы идентификаторов URI, например номеров телефонов, факсов и модемов, представлены по адресу http://www.ietf.org/rfc/rfc2806.txt.

Атрибуты

Сигнатура

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

Кратность

Описание

fragment_id:String

1

-

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

literal:String

1

-

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

path:String

1

-

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

Пример - Если scheme = "ftp", то путь может быть значение/pub/images/image_01. Строки "." и ".." зарезервированы для специального использования в пути. Пути могут включать идентификаторы положения в сети Интернет/Интранет в виде: поддомен... домен, например "info.cern.ch"

query:String

1

-

Строка запроса, передаваемая приложению, подразумеваемому схемой и путем, дает возможность включать в идентификатор URI любые содержательные запросы к приложениям и базам данных, в том числе на языке SQL

scheme:String

1

-

Распределенное информационное "пространство", в котором существуют информационные объекты. Схема scheme определяет одновременно как информационное пространство, так и механизм доступа к объектам этого пространства.

Пример - Значение scheme = "ftp" определяет информационное пространство, в котором существуют все объекты, которые могут быть доступны по протоколу ftp, а также приложение (ftp), которое может быть использовано для доступа к этим объектам

value:String

1

-

Телекоммуникационный адрес, соответствующий стандарту Интернет RFC 1738 [23]


6.4.9 Класс II

DATA VALUE

|
+ - - II

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

Атрибуты

Сигнатура

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

Кратность

Описание

assigningAuthorityName: String

1

-

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

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

extension:String

1

-

Значение идентификатора, уникальное в пространстве имен, присваиваемых этой организацией

validTime:IVL<TS>

-

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

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


Атрибут, унаследованный от ассоциаций

Сигнатура

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

Кратность

Описание

root:OID

1

-

Уникальный идентификатор, гарантирующий глобальную уникальность идентификатора данного объекта. Значение атрибута root может служить идентификатором само по себе; расширение extension требуется не всегда


6.4.10 Класс OID

Данный класс представляет уникальный идентификатор, способ присвоения которого гарантирует глобальную уникальность идентификатора объектов. Он может использоваться как самостоятельный идентификатор без расширения extension.

Атрибут

Сигнатура

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

Кратность

Описание

oid:String

1

-

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


6.4.11 Класс IVL<T>

DATA VALUE

|
+ - - IVL

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

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

Атрибуты

Сигнатура

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

Кратность

Описание

low:T

0..1

-

Нижняя граница интервала

high:T

0..1

-

Верхняя граница интервала

lowClosed: Boolean

0..1

-

Булевское значение, указывающее, является ли нижняя граница интервала закрытой. Не заданные или бесконечные границы всегда открыты

highClosed: Boolean

0..1

-

Булевское значение, указывающее, является ли верхняя граница интервала закрытой

literal:String

0..1

-

Строковая форма типа данных интервала


Параметр шаблона

Имя

Тип

Значение по умолчанию

Т

-

-


6.5 Примитивные типы данных


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

- Boolean (булевский);

- Byte (байт);

- Character (символ);

- Double (вещественный двойной точности);

- Integer (целый);

- Real (вещественный);

- String (строковый);

- Аггау<Т> (массив значений типа <Т>);

- Set<T> (множество значений типа <Т>);

- List<T> (список значений типа <Т>).

Рисунок 6 - Диаграмма классов UML пакета примитивных типов данных


Рисунок 6 - Диаграмма классов UML пакета примитивных типов данных

Приложение А (справочное). Профиль UML


Приложение А
(справочное)

А.1 Введение

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

А.2 Общая часть

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

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

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

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

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

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

Цветовые выделения сами по себе не имеют значения и используются только для улучшения восприятия информации. Линии наследования показаны черным цветом, а линии ассоциаций - красно-коричневым. Цветовое выделение прямоугольников классов иногда используется для обозначения конкретных групп классов. Серый цвет прямоугольника класса означает, что данный класс подробно раскрыт на другой диаграмме.

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

Кратность начала ассоциации подразумевается равной 1, если не указано иное.

Закрашенные ромбы обозначают включение по значению, а незакрашенные - включение по ссылке.

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

А.3 Подробное описание модели

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

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

Описание модели упорядочено по пакетам, а внутри пакета - по классам.

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

Имя на дальнем конце связи

становится

Именем атрибута

Класс на дальнем конце связи

становится

Типом данных атрибута

Кратность ассоциации

генерирует

Тип контейнера

и

Обязательность атрибута

Исходная кратность

0..*

Set<Клacc на дальнем конце>

0..1

0..*

0..* {упорядоченная}

List<Клacc на дальнем конце>

0..1

0..* {упорядоченная}

1..*

Set<Клacc на дальнем конце>

1

1..*

1..* {упорядоченная}

List<Клacc на дальнем конце>

1

1..* {упорядоченная}

*

Set<Клacc на дальнем конце>

0..1

*

0..1

Без контейнера

0..1

-

1

Без контейнера

1

-

Приложение В (справочное). Связь с другими стандартами


Приложение В
(справочное)

В.1 Связь со стандартом HL7, версия 3

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

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

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

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

1) признать значимость работы, предпринятой для разработки настоящего стандарта, и добиться одобрения совместимой с ним статической модели HL7, описывающей передачу данных ЭМК по стандарту HL7, версия 3;

2) принять нормативную модель из раздела 6 в качестве модели анализа предметной области в терминах "Основы разработки стандарта HL7" (HDF); это будет способствовать разработке модели предметной области, достоверно отражающей требования, предъявляемые как комитетом HL7, так и ИСО, а в дальнейшем обеспечит отображение этой модели либо на базовую информационную модель (RIM), либо на соответствующую уточненную информационную модель сообщений HL7 (RMIM);

3) объявить "Шаблон медицинских утверждений HL7" (информационную модель сообщений предметной области) наиболее подходящей целью отображения для всех типовых медицинских представлений, включая модель передачи данных ЭМК.

Для реализации этого подхода на основе шаблона медицинского утверждения HL7 была разработана статическая модель (HL7 ISO 13606-1 RMIM), логически согласованная с моделью, определенной в разделе 6 настоящего стандарта. Следовательно, эта модель соответствует настоящему стандарту. Кроме того, разрабатывается "Руководство по реализации модели HL7 13606".

В.2 Связь со стандартом ЕН 13940 (стандарт CONTSYS)

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

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

Настоящий стандарт определяет выписку EHR_EXTRACT в очень общих терминах, а ИСО 13606-2 определяет средства обмена структурами знаний (архетипами), пригодных для отражения содержания современных лечебных руководств, подготовленных в соответствии с положениями доказательной медицины. Большинство конструкций стандарта CONTSYS, относящихся к клинической информации, будут представлены в базовой модели настоящего стандарта скорее как особые архетипы, а не классы и атрибуты. Однако некоторые фундаментальные понятия стандарта CONTSYS имеют аналогию с настоящей базовой моделью. Эти понятия приведены ниже, чтобы показать, каким образом разработчик системы ЭМК должен отобразить понятия стандарта CONTSYS в выписке EHR_EXTRACT.


Таблица В.1 - Отображение понятий стандарта CONTSYS на модель настоящего стандарта

Понятие в стандарте CONTSYS

Соответствие в настоящем стандарте

Контакт (Contact)

- прием у врача (clinical encounter)

- управление записями в медицинской карте (record management)

Класс COMPOSITION

Между этими двумя подтипами элемента контакта нет специфичных различий: для каждого из этих подтипов будут использоваться свои архетипы

Заболевание (Health issue)

Описание или обозначение заболевания пациента может быть представлено как специфичный (возможно с использованием архетипа) подраздел ENTRY в композиции COMPOSITION

Элемент контакта (Contact element)

Совокупность разделов SECTION и/или подразделов ENTRY в одной композиции COMPOSITION, содержащей связи LINK только с медицинской проблемой пациента

Течение заболевания (Health issue thread)

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

Атрибут link_nature должен иметь значение "LINK-C0" в соответствии с определением в ИСО 13606-3, что означает "относится к той же самой проблеме или заболеванию". Эта связь LINK может быть помечена значением атрибута роли

Эпизод лечения (Episode of care)

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

Совокупный эпизод лечения (Cumulative episode of care)

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

Цель лечения (Healthcare goal)

Определение или формулировка цели лечения может быть представлена как особый (возможно, с использованием архетипа) подраздел ENTRY композиции COMPOSITION

Метод лечения (Health approach)

Описанию метода лечения соответствует совокупность композиций COMPOSITION и/или подразделов ENTRY, имеющих связь LINK с указанной целью лечения

Клинические указания (Guideline)

Клинические указания редко включаются в ЭМК одного субъекта медицинской помощи в явном виде: обычно на них дается ссылка как на внешний источник знаний. В качестве такой ссылки могут быть использованы специфичные (возможно, использующие архетипы) подразделы ENTRY. Другой способ представления ссылки на внешние методические указания - использовать элемент ELEMENT со специальным значением атрибута item_category

Протокол (Protocol)

(То же отображение, что для описанного выше понятия "клинические указания")

Программа лечения (Programme of care)

Программа лечения может документироваться в отдельной ЭМК целиком или из нее могут быть взяты только необходимые части, возможно, со ссылками на конкретный протокол. Для этой цели должна быть использована специфичная композиция COMPOSITION (возможно, с применением архетипов)

Задача лечения (Healthcare objective)

Определение или формулировка каждой задачи лечения может быть представлена подразделом ENTRY в программе лечения, описанной в композиции COMPOSITION

Цель лечения (Healthcare goal)

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

План лечения (Care plan)

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

Совокупность действий (Activities bundle)

Совокупность композиций COMPOSITION и/или подразделов ENTRY в ЭМК, имеющих связь LINK с конкретным планом лечения

Требование обязательного оказания медицинской помощи (Mandate for care)

Для описания требования обязательного оказания медицинской помощи должна использоваться специфичная совокупность композиций COMPOSITION (возможно с использованием архетипов)

Период предоставления услуги (Period of service)

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


В.3 Связь со стандартом prEN 12967 HISA

Стандарт prEN 12967 определяет типовую архитектуру сервисов информатизации здоровья (HISA) в качестве логической структуры информационных систем, обслуживающих потребности больших и малых учреждений здравоохранения. Спецификация информационной точки зрения в ИСО 13606-2 определяет основные классы информации, которой надо управлять в медицинском учреждении и, возможно, использовать совместно с другими вычислительными ресурсами. Один из пакетов, описанных в данном международном стандарте, определяет типовое представление медицинской информации. Кроме того, в нем определено множество типовых классов, общих для всей информационной точки зрения стандарта HISA.

Чтобы можно было обеспечить передачу данных ЭМК в соответствии с настоящим стандартом, большая часть медицинской информации, содержащейся в системе, соответствующей стандарту HISA и относящейся к указанному субъекту медицинской помощи (в отличие от терминологии или других источников знаний), должна быть отображена на выписку EHR_EXTRACT. Однако в стандарте HISA некоторые общие классы содержат атрибуты, которые необходимы для управления целостностью хранилища физических данных, но которые не надо передавать в другое хранилище ЭМК. В таблице В.2 представлены основные классы, определенные в стандарте HISA и относящиеся к обмену данными ЭМК, и показано, какие значения данных соответствуют классам и атрибутам базовой модели, описанной в настоящем стандарте. Поскольку некоторые классы HISA являются даже более общими, чем классы данной базовой модели, в некоторых случаях показан список вариантов; выбор точного отображения будет зависеть от медицинских понятий, представленных этими данными. Классы и атрибуты HISA, которые не требуется включать в передаваемые данные ЭМК, в таблице В.2 не представлены.


Таблица В.2 - Отображение элементов данных HISA на элементы данных настоящего стандарта

Классы и атрибуты, определенные в стандарте
ЕН 12967

Классы и атрибуты, определенные в настоящем стандарте

GenericHISACIass

RECORD_COMPONENT

SystemAttributes

RECORD_COMPONENT и AUDIT_INFO

displayName и userCode

name

updateTime

time_committed

updateAgent

committer

updateUnit

ehr_system

authorization

policy_ids

isDeleted

version_status

Примечание - Дополнительная информация о политике доступа может быть представлена как бизнес-правила, связанные с экземпляром данного класса

ExtendedAttributes

Представлен с использованием типа данных ED из СЕН/ТС 14796

VersionAttributes

Данная информация должна быть отображена как ссылка на значение атрибута ID предыдущей версии классов Clinicallnformation или ClinicallnformationComplex

Clinicallnformation and ClinicallnformationComplex

Данные классы будут отображаться на иерархию классов RECORD_COMPONENT в зависимости от уровня детальности каждого узла

id

rc_id

values

Атрибут data_value элемента ELEMENT

unitMeasure

Тип данных PQ, определенный в стандарте СЕН/ТС 14796

status

AUDIT_INFO.version_status

SubjectOfCare

EHR_EXTRACT.subject_of_care

Agent

FUNCTIONAL_ROLE

Activity

Через связь LINK с другими классами RECORD_COMPONENT

Примечание - Класс HISA StateChanges может предоставить дополнительную информацию о статусе, которая отображается на класс AUDIT_INFO настоящего стандарта

Подклассы Clinicallnformation: Healthlssue, ClinicalObservationAndResult, EvaluationAndOthers, ClinicalObjective, Demand for care

Эти подклассы могут быть представлены (возможно, с использованием архетипов) как специфичные композиции COMPOSITION и/или подразделы ENTRY

TypeOfClinicallnformation

RECORD_COMPONENT.meaning и RECORD_COMPONENT.archetype_id

ActivityClinicallnformationAssociation и ReasonForAssociationOfTypesOfClinicallnformation

LINK.nature и LINK.role

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

RoleOfAgentlnClinicallnformationLifeCycle

FUNCTIONAL_ROLE


В.4 Связь со стандартами ЕН 14822-1, ЕН 14822-2, ЕН 14822-3 и СЕН/ТС 14822-4

В стандартах ЕН 14822-1 - ЕН 14822-3 и СЕН/ТС 14822-4 определено множество информационных компонентов общего назначения (GPIC), являющихся фрагментами моделей UML, представляющими разные бизнес-объекты информатизации здоровья, часто встречающиеся в медицинских сообщениях. Каждая из этих моделей ограничена подмножествами классов и атрибутов базовой информационной модели (RIM) стандарта HL7, версия 3, в целях будущего развития сообщений, разрабатываемых комитетом CEN в соответствии с этим стандартом. Стандарты ЕН 14822 определяют множество компонентов GPIC как медицинского, так и немедицинского назначения.

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

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

В.5 Связь со спецификацией IHE XDS

Спецификация перекрестного использования документов (XDS), разработанная организацией Integrating the Healthcare Enterprise (IHE), определяет архитектуру информации и интерфейсы сервисов для совместно используемого хранилища медицинских документов. Разработка данной спецификации считается важным шагом на пути создания интероперабельных систем ведения ЭМК, хотя она и ограничивается возможностью обмена только целыми документами, анализировать содержание которых не обязательно. Спецификация XDS была гармонизирована с комплексом стандартов ИСО 13606, поэтому выписки EHR_EXTRACT можно передавать в хранилище, удовлетворяющее спецификации XDS, со следующими ограничениями:

a) в настоящее время спецификация XDS поддерживает только один уровень иерархии класса томов FOLDER;

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

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


Таблица В.3 - Отображение записи о документе, соответствующей спецификации XDS, на класс и атрибуты, определенные в настоящем стандарте

Атрибут записи о документе XDS

Отображение на классы и атрибуты, определенные в настоящем стандарте

AvailabilityStatus

Класс: AUDIT_INFO

Атрибут: revision_status

Примечание - Если документ заменен, то ebXML-спецификация XDS требует ссылки на предыдущую версию, которая может быть получена из атрибута previous_version AUDIT_INFO

Patientld

Класс: EHR_EXTRACT

Атрибут: subject_of_care

Uniqueld

Класс: RECORD_COMPONENT

Атрибут: rc_id

ClassCode

Класс: COMPOSITION

Атрибут: name

EventCode

Класс: RECORD_COMPONENT

Атрибут: meaning

TypeCode

(Отображается на коды регистра документов XDS, содержащиеся в элементе COMPOSITION.meaning)

CreationTime

Класс: AUDIT_INFO

Атрибут: time_committed

ServiceStartTime и ServiceStopTime

Класс: COMPOSITION

Атрибут: session_time

Authorlnstitution

Класс: COMPOSITION

Связь: composer.FUNCTIONAL_ROLE.healthcare_facility

AuthorDepartment

Класс: COMPOSITION

Ассоциация: composer.FUNCTIONAL_ROLE.servcie_setting

AuthorPerson

Класс: COMPOSITION

Ассоциация: composer. FUNCTIONAL_ROLE. performer

HealthcareFacilityTypeCode

(Отображается из элемента composer.FUNCTIONAL_ROLE.healthcare_facility)

LegalAuthenticator

Класс: FUNCTIONAL_ROLE

(ассоциация от класса ATTESTATION)

Атрибут: performer

FormatCode

Класс: EHR_EXTRACT

Атрибут: rm_id



Таблица В.4 - Отображение набора документов, определенного в спецификации XDS, на классы и атрибуты, определенные в настоящем стандарте

Атрибут набора документов XDS

Отображение на классы и атрибуты, определенные в настоящем стандарте

Uniqueld

Данный атрибут может быть добавлен в оболочку сообщения, содержащего выписку EHR_EXTRACT, системой поставщика ЭМК

Authorlnstitution

Класс: EHR_EXTRACT

Атрибут: ehr_system

SubmissionTime

Класс: EHR_EXTRACT

Атрибут: time_created

AuthorPerson

Класс: EHR_EXTRACT

Атрибут: authorizing_party



Таблица В.5 - Отображение элемента тома, определенного в спецификации XDS, на классы и атрибуты, определенные в настоящем стандарте

Атрибут тома XDS

Отображение на классы и атрибуты, определенные в настоящем стандарте

Uniqueld

Класс: FOLDER

Атрибут: rc_id

LastUpdateTime

Управляется сервисом XDS

CodeList

Класс: FOLDER

Атрибут: meaning


В.6 Связь с предшествующим стандартом ENV 13606

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


Таблица В.6 - Отображение атрибутов и ассоциаций, определенных в стандарте ENV 13606-1, на атрибуты и ассоциации, определенные в настоящем стандарте

Класс ENV 13606

Атрибут ENV 13606

Комментарий к спецификации ENV 13606

Класс ИСО 13606

Атрибут ИСО 13606

Комментарии к отображению

Root architectural component

-

-

EHR_EXTRACT

-

-

-

Attestation information

-

-

-

Аттестация применяется к конкретным компонентам ЭМК, а не к выписке EHR_EXTRACT в целом. Корневая папка каталога ЭМК может быть аттестована, поскольку она является разновидностью объекта RECORD_COMPONENT

-

Presentation information

-

-

-

Представление рассматривается применительно к конкретным компонентам ЭМК, а не ко всей выписке EHR_EXTRACT

-

Component unique identifier

-

-

her_system AND ehr_id

-

-

Originating healthcare agent

-

-

authorizing_party

-

-

Originating date and time

-

-

time_created

-

-

Related healthcare agent

-

-

-

Другие стороны могут быть указаны для конкретных компонентов иерархии элементов ЭМК, а не для всей выписки EHR_EXTRACT. Однако их можно определить в корневом томе каталога ЭМК, поскольку он является разновидностью объекта RECORD_COMPONENT

-

Related date and time

-

-

-

Другие дата и время могут быть указаны для конкретных компонентов иерархии элементов ЭМК, а не для всей выписки EHR_EXTRACT. Однако их можно определить в корневом томе каталога ЭМК, поскольку он является разновидностью объекта RECORD_COMPONENT

-

Component name structure

-

-

-

Класс EHR_EXTRACT не имеет атрибут name, но корневой том FOLDER каталога ЭМК может его содержать, поскольку является разновидностью объекта RECORD_COMPONENT

-

Subject of care identifier

-

-

subject_of_care

-

-

Component status information

При создании устанавливается значение "current" (текущий)

-

-

В целях передачи любая выписка EHR_EXTRACT считается текущей в момент создания, который указан в атрибуте time_created

-

Distribution rule reference

-

-

Не применимо

Метод контроля доступа определен в ИСО 13606-4

-

Language

-

-

-

Язык считается относящимся к отдельным терминам или текстовым данным ЭМК, но не к выписке EHR_EXTRACT в целом

Record component

-

-

RECORD_
COMPONENT

-

-

-

Attestation information

-

-

ATTESTATION_INFO

-

-

Presentation information

Стандарт
ENV 13606 предусматривает только ссылку на характеристики визуального представления, но не формализует их

-

-

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

-

Revision information

-

-

AUDIT_INFO

-

-

Component unique identifier

-

-

rc_id

-

-

Originating healthcare agent

-

-

AUDIT_INFO.committer

-

-

Originating date and time

-

-

AUDIT_INFO.time_ committed

-

-

Related healthcare agent

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

-

-

Другие агенты здравоохранения могут быть указаны в форме ассоциации между композицией COMPOSITION и подразделом ENTRY

-

Related date and time

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

-

-

Другие даты и время могут быть указаны с помощью специфичных ассоциаций между композицией COMPOSITION (session_time) и сущностью ITEM (obs_time)

-

Component name structure

-

-

name

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

-

Subject of care identifier

-

-

-

Значение данного атрибута определено в выписке EHR_EXTRACT и не повторяется в каждом узле иерархии элементов ЭМК

-

Component status information

-

-

AUDIT_INFO.revision_ status

-

-

Distribution rule reference

-

-

sensitivity policy_ids

Метод контроля доступа определен в ИСО 13606-4; эта ссылка требует уточнения

-

Language

-

-

-

Язык считается относящимся к отдельным терминам или текстовым данным ЭМК, но не к выписке EHR_EXTRACT в целом

Folder OCC

-

-

FOLDER

-

-

-

OCC type

Значение по умолчанию =
"Folder OCC"

-

(Имя класса)

Данное значение задается именем класса и не требует повторения в качестве значения атрибута

Composition OCC

-

-

COMPOSITION

-

-

-

Originating healthcare agent

-

-

AUDIT_INFO.committer

Так как композиция COMPOSITION является основным контейнером данных ЭМК, то предусмотрена возможность указания отправителя исходных данных в его системе ведения ЭМК и отправителя данных выписки COMPOSITION в системе поставщика ЭМК

-

Originating date and time

-

-

AUDIT_INFO.time_ committed

Так как композиция COMPOSITION является основным контейнером данных ЭМК, то предусмотрена возможность указания времени отправки данных в системе ведения ЭМК, где они были впервые созданы, и время отправки данных композиции COMPOSITION в системе поставщика ЭМК

-

Related healthcare agent

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

-

composer other_participants

-

-

Related date and time

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

-

session_time

-

-

Component name category

-

-

archetype_id AND meaning

-

-

OCC type

Значение по умолчанию = "Composition OCC"

-

-

Данное значение задается именем класса и не требует повторения в качестве значения атрибута

Headed section OCC

-

-

SECTION

-

-

-

Component name category

-

-

archetype_id AND meaning

-

-

OCC type

Значение по умолчанию = "headed section OCC"

-

-

Данное значение задается именем класса и не требует повторения в качестве значения атрибута

Cluster OCC

-

-

ENTRY, CLUSTER

-

См. описание данных классов в разделе 5

-

Presentation information

Стандарт
ENV 13606 предусматривает только ссылку на характеристики визуального представления, но не формализует их

CLUSTER, ELEMENT

emphasis

-

-

Related healthcare agent

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

ENTRY

info_provider AND other_participants

-

-

Related date and time

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

CLUSTER

obs_time

-

-

Annotation identifier

-

ENTRY

uncertainty_expressed

Аннотации, определенные в стандарте ENV 13606-2, не сохранены в настоящем стандарте, т.к. было сочтено, что они существенно перекрываются семантикой имен и терминов, используемых для значений данных в классе RECORD_COMPONENT

-

OCC type

Значение по умолчанию = "Cluster OCC"

-

-

-

Data Item

-

-

CLUSTER, ELEMENT

-

См. описание данных классов в приложении В

-

Attestation information

-

-

ATTESTATION_INFO

-

-

Presentation information

Стандарт
ENV 13606 предусматривает только ссылку на характеристики визуального представления, но не формализует их

CLUSTER, ELEMENT

emphasis

-

-

Related date and time

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

CLUSTER, ELEMENT

obs_time

-

Data item type reference

В стандарте ЕН/ТС 13606-4 определены несколько типов элементов данных, включая определенный сообществом разработчиков. Это означает, что элемент данных может представлять либо конечный узел, либо разновидность кластера

archetype_id AND meaning

В комплексе стандартов ИСО 13606 класс ELEMENT всегда является конечным узлом. Поэтому составные элементы данных, определенные в стандарте ENV 13606, отображаются на кластер CLUSTER, а элементы данных, имеющие одно значение, отображаются на элемент ELEMENT

-

Data item content

-

-

DATA_VALUE

Типы данных теперь определены в стандарте комитета CEN, поэтому они не определены в настоящем стандарте

SCC

-

-

RECORD_ COMPONENT

orig_parent_ref

См. в разделе 5 описание способов, с помощью которых представления и параметры запросов обеспечены в настоящем стандарте

-

-

-

LINK

target

-

Link Item

-

-

LINK

-

-

Attestation information

-

-

ATTESTATION_
INFO

-

-

-

Attesting agent

-

-

FUNCTIONAL_ ROLE.performer

-

-

Date and time of attestation

-

-

time

-

-

Reason for attestation

-

-

FUNCTIONAL_ ROLE.function

-

-

Digital signature

-

-

proof

-

Revision information

-

-

AUDIT_INFO

-

-

-

Revised version reference

-

-

previous_version

-

-

Reason for revision

-

-

reason_for_revision

-

-

Reason for revision comments

-

-

-

Комментарии к причине изменения могут быть отображены на атрибут displayName в типе данных CV

Data types

-

-

-

-

Теперь используются типы данных, определенные в стандарте комитета CEN. Любую необходимую информацию об отображении см. в стандарте ЕН 13606

Healthcare agent subsystem

-

-

Пакет DEMOGRAPHICS

-

-

Приложение С (справочное). Клинический пример


Приложение С
(справочное)


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

28-недельное обследование проведено 12.07.96 г. в 13:42 доктором Д.Калра.

Беременность 27 недель

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

Живот:

Головное предлежание плода

Пульс плода 140/мин, ритмичный (по данным ультразвукового исследования)

Кровяное давление: 100/60

Для усложнения данного примера предполагается, что показанное выше кровяное давление отправлено в ЭМК на следующий день после обследования, а в день обследования оно было ошибочно введено как 100/160. Для передачи обоих версий в приведенном ниже примере выписки EHR_EXTRACT данные передаются в виде двух полных композиций COMPOSITION со ссылками между ними.

EHR_EXTRACT

ehr_system.extension = Whittington

ehr_system.assigningAuthorityName = NHS

ehr_system.valid_time = 1/1/1990 - 1/1/3000

ehr_system.root.oid = 9876543211

ehr_id.extension = WH.1234

ehr_id.assigningAuthorityName = NHS

ehr_id.valid_time = 1/1/1990 - 1/1/3000

ehr_id.root.oid = 9876543211

subject_of_care.extension = 9876543

subject_of_care.assigningAuthorityName = NHS

subject_of_care.valid_time = 1/1/1990 - 1/1/3000

subject_of_care.root.oid = 9876543211

time_created.time= 16/07/2004 17:32

rm_id = EN 13606-1.0

FOLDER

rc_id.extension = 0001

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Дородовая помощь

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-asdyz

meaning.displayName = Дородовая помощь

synthesised = FALSE

COMPOSITION

rc_d.extension = 0113

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = 28-недельное обследование

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyz

meaning.displayName = Дородовое обследование 28-недельной беременности

synthesised = FALSE

sensitivity = 3

composer.performer.extension = KALRA194

composer.performer.assigningAuthorityName = NHS

committal.ehr_system.extension = Whittington

committal.ehr_system.assigningAuthorityName = NHS

committal.ehr_system.valid_time = 1/1/1990 - 1/1/3000

committal.ehr_system.root.oid = 9876543211

committal.time_committed = 12.07.199613:42

committal.committer.extension = KALRA194

committal.committer.assigningAuthorityName = NHS

committal.committer.valid_time = 1/1/1990 - 1/1/3000

committal.committer.root.oid = 9876543211

ENTRY

rc_id.extension = 0114

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Беременность

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzA

meaning.displayName = Срок беременности

synthesised = FALSE

subject_of_information_category.codingScheme = 987654333

subject_of_infoimation_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_ category.codingSchemeVersion = 1.0

subject_of_information_category.codeValue = DS0

uncertainty_expressed = FALSE

ELEMENT

rc_id.extension =0115

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Оценка срока беременности

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzAA

meaning.displayName = Оценка срока беременности в неделях

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.PQ.value = 27

value.PQ.units = Неделя

value.PQ.property = Время

ENTRY

rc_id.extension = 0116

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Текущие симптомы

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzB

meaning.displayName = Симптомы при беременности

synthesised = FALSE

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_category. codingSchemeVersion = 1.0

subject_of_information_category.codeValue = DS0

0

uncertainty_ expressed = FALSE

ELEMENT

rc_id.extension = 0117

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Симптом

meaning. codingScheme = 1234567890

meaning. codingSchemeName = CEN

meaning. codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwabcA

meaning.displayName = Описание симптома

item_category = IC01

synthesised = FALSE

value.TEXT.displayName = Постоянное плохое самочувствие

ELEMENT

rc_id.extension = 0118

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Симптом

meaning.codingScheme = 1234567890

meaning RC_UID=0012

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwabcA

meaning.displayName = Описание симптома

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.CODED_TEXT.codingScheme = ICD-12

value.CODED_TEXT.codingSchemeName = Класс внутренних заболеваний

value. CODED_TEXT.codingSchemeVersion = 12

value.CODED_TEXT.codeValue = D1234

value.CODED_TEXT.displayName = Рефлюкс-эзофагит, сильный

value.CODED_TEXT.originalText = Сильная изжога

links.nature = LINK-C0

links.role = LINK-C9

links.follow_link = FALSE

links.target.rc_id.extension = 0008

links.target.rc_id.assigningAuthorityName = NLONDON-NHS

links.target.rc_id.valid_time = 1/1/1990 - 1/1/3000

links.target.rc_id.root.oid = 9876543213

SECTION

rc_id.extension = 0120

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Абдоминальное обследование

synthesised = FALSE

ENTRY

rc_id.extension = 0121

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id .valid time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Предлежание

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzF

meaning.displayName = Предлежание плода

synthesised = FALSE

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_category.codingSchemeVersion = 1.0

subject_of_information_category.codeValue = DS00

uncertainty_expressed = FALSE

ELEMENT

rc_id.extension = 0122

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Lie

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzF1

meaning.displayName = Ориентация плода

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.CV.codingScheme = CTV3

value.CV.codingSchemeName = NHS Clin. Terms

value.CV.codingSchemeVersion = 1.0

value.CV.codeValue = 635284

value.CV.displayName = Длительный

ELEMENT

rc_id.extension = 0123

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Предлежание

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzF2

meaning.displayName = Предлежание плода

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.CV.codingScheme = CTV3

value.CV.codingSchemeName = NHS Clin. Terms

value. CV.codingSchemeVersion = 1.0

value.CV.codeValue = 635288

value.CV.displayName = Головное

ENTRY

rc_id.extension =0131

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Пульс

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzH

meaning.displayName = Измерение пульса плода

synthesised = FALSE

subject_of_information_category = DS02

uncertainty_expressed = FALSE

subject_of_information_category.codingScheme = 987654333

subject_of_Information_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_category.codingSchemeVersion = 1.0

subject_of_information_category.codeValue = DS002

subject_of_information.relationship.codeValue = "Плод"

ELEMENT

rc_id.extension = 0133

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = FH

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzHA

meaning.displayName = Частота сокращения сердца плода в минуту

item_category.codingScheme =987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.PQ.value=140

value.PQ.units = Удар в минуту

value. PQ.property = Частота

ELEMENT

rc_id.extension = 0135

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 -1/1/3000

rc_id.root.oid = 9876543213

name = Диагностический прибор

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzHD

meaning.displayName = Прибор для измерения пульса плода

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC04

synthesised = FALSE

value.CV.codingScheme = CEN DEV REG

value.CV.codingSchemeName = CEN device registry

value.CV.codingSchemeVersion = 6.8

value.CV.codeValue = 5621

value.CV.displayName = УЗ аппарат Sonicaid doppler deluxe

ELEMENT

rc_id .extension = 0136

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990-1/1/3000

rc_id.root.oid = 9876543213

name = Ритм пульса плода

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzHR

meaning.displayName = Описание ритма пульса плода

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.CV.codingScheme = CTV3

value.CV.codingSchemeName = NHS Clin. Terms

value.CV.codingSchemeVersion = 1.0

value.CV.codeValue = 635700

value.CV.displayName = Ритмичный

ENTRY

rc_id .extension = 0151

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Кровяное давление

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvbnh

meaning.displayName = Кровяное давление

synthesised = FALSE

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_category.codingSchemeVersion = 1.0

subject_of_information_category.codeValue = DS00

uncertainty_expressed = FALSE

ELEMENT

rc_id.extension = 0155

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Систолическое

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvbnhS

meaning.displayName = Измерение систолического давления крови

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.PQ.value = 100

value.PQ.units = мм рт.ст.

value.PQ.property = Давление

ELEMENT

rc_id.extension = 0158

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Диастолическое

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvbnhD

meaning.displayName = Измерение диастолического давления крови

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN 13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.PQ.value = 160

value.PQ.units = мм рт.ст.

value.PQ.property = Давление

COMPOSITION

rc_id.extension = 0213

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = 28-недельное обследование

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyz

meaning.displayName = Дородовое обследование 28-недельной беременности

synthesised = FALSE

sensitivity = 3

composer.performer.extension = KALRA194

composer.performer.assigningAuthorityName = NHS

committal.ehr_system.extension = Whittington

committal.ehr_system.assigningAuthorityName = NHS

committal.ehr_system.valid_time= 1/1/1990 - 1/1/3000

committal.ehr_system.root.oid = 9876543211

committal.time_committed = 13.07.1996 09:11

committal.committer.extension = LLOYD345

committal.committer.assigningAuthorityName = NHS

committal.committer.valid_time = 1/1/1990 - 1/1/3000

committal.committer.root.oid = 9876543211

committal.version_status.codingScheme = 987654338

committal.version_status.codingSchemeName = EN13606-3 VERSION_STATUS

committal.version_status.codingSchemeVersion = 1.0

committal.version_status.codeValue = VER03

committal.previous_version.re id.extension = 0113

committal.previous_version.rc_id.assigningAuthorityName = NLONDON-NHS

committal.previous_version.rc_id.valid_time = 1/1/1990 - 1/1/3000

committal.previous_version.rc_id.root.oid = 9876543213

committal.version_set_id.rc_id.extension = 0113

committal.version_set_id.rc_id.assigningAuthorityName = NLONDON-NHS

committal.version_set_id.rc_id.valid_time = 1/1/1990 - 1/1/3000

committal.version_set_id.rc_id.root.oid = 9876543213

ENTRY

rc_id.extension = 0114

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 -1/1/3000

rc_id.root.oid = 9876543213

name = Беременность

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzA

meaning.displayName = Срок беременности

synthesised = FALSE

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_category.codingSchemeVersion= = 1.0

subject_of_information_category.codeValue = DS00

uncertainty_expressed = FALSE

original_parent_ref.rc_id.extension = 0113

original_parent_ref.rc_id.assigningAuthorityName = NLONDON-NHS

original_parent_ref.rc_id.valid_time = 1/1/1990 - 1/1/3000

original_parent_ref.rc_id.root.oid = 9876543213

ELEMENT

rc_id.extension =0115

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Оценка срока беременности

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzAA

meaning.displayName = Оценка срока беременности в неделях

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.PQ.value = 27

value.PQ.units = Неделя

value.PQ.property = Время

ENTRY

rc_id.extension = 0116

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time= 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Текущие симптомы

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzB

meaning.displayName = Симптомы при беременности

synthesised = FALSE

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codingSchemeName = EN 13606-3 SUBJECT_CATEGORY

subject_of_information_category.codingSchemeVersion = 1.0

subject_of_information_category.codeValue = DS00

uncertainty_expressed = FALSE

original_parent_ref.rc_id.extension = 0113

original_parent_ref.rc_id.assigningAuthorityName = NLONDON-NHS

original_parent_ref.rc_id.valid_time = 1/1/1990 - 1/1/3000

original_parent_ref.rc_id.root.oid = 9876543213

ELEMENT

rc_id.extension = 0117

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Симптом

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwabcA

meaning.displayName = Описание симптома

item_category = IC01

synthesised = FALSE

value.TEXT.displayName = Постоянное плохое самочувствие

ELEMENT

rc_id.extension = 0118

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Симптом

meaning.codingScheme = 1234567890

meaning RC_UID = 0012

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwabcA

meaning.displayName = Описание симптома

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.CODED_TEXT.codingScheme = ICD-12

value.CODED_TEXT.codingSchemeName = Класс внутренних заболеваний

value.CODED_TEXT.codingSchemeVersion = 12

value.CODED_TEXT.codeValue = D1234

value.CODED_TEXT.displayName = Рефлюкс-эзофагит, сильный

value.CODED_TEXT.originalText= Сильная изжога

links.nature = LINK-C0

links.role = LINK-C9

links.follow_link = FALSE

links.target.rc_id.extension = 0008

links.target.rc_id.assigningAuthorityName = NLONDON-NHS

links.target.rc_id.valid_time = 1/1/1990 - 1/1/3000

links.target.rc_id.root.oid = 9876543213

SECTION

rc_id.extension = 0120

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Абдоминальное обследование

synthesised = FALSE

original_parent_ref.rc_id.extension = 0113

original_parent_ref.rc_id.assigningAuthorityName = NLONDON-NHS

original_parent_ref.rc_id.valid_time = 1/1/1990 - 1/1/3000

original_parent_ref.rc_id.root.oid = 9876543213

ENTRY

rc_id.extension = 0121

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1 /1/3000

rc_id.root.oid = 9876543213

name = Предлежание

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzF

meaning.displayName = Предлежание плода

synthesised = FALSE

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_category.codingSchemeVersion = 1.0

subject_of_information_category.codeValue = DS00

uncertainty_expressed = FALSE

ELEMENT

rc_id.extension = 0122

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Lie

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzF1

meaning.displayName = Ориентация плода

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.CV.codingScheme = CTV3

value.CV.codingSchemeName = NHS Clin. Terms

value. CV.codingSchemeVersion = 1.0

value.CV.codeValue = 635284

value. CV.displayName = Длительный

ELEMENT

rc_id.extension = 0123

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Предлежание

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzF2

meaning.displayName = Предлежание плода

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.CV.codingScheme = CTV3

value.CV.codingSchemeName = NHS Clin. Terms

value.CV.codingSchemeVersion = 1.0

value.CV.codeValue = 635288

value.CV.displayName = Головное

ENTRY

rc_id.extension =0131

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Пульс

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzH

meaning.displayName = Измерение пульса плода

synthesised = FALSE

subject_of_information_category = DS02

uncertainty_expressed = FALSE

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_category.codingSchemeVersion = 1.0

subject_of_information_category.codeValue = DS002

subject_of_information.relationship.codeValue = "Плод"

ELEMENT

rc_id.extension =0133

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = FH

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzHA

meaning.displayName = Частота сокращения сердца плода в минуту

item_category.codingScheme =
= 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.PQ.value = 140

value.PQ.units = Удар в минуту

value.PQ.property = Частота

ELEMENT

rc_id.extension = 0135

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Диагностический прибор

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzHD

meaning.displayName = Прибор для измерения пульса плода

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC04

synthesised = FALSE

value.CV.codingScheme = CEN DEV REG

value.CV.codingSchemeName = CEN device registry

value.CV.codingSchemeVersion = 6.8

value.CV.codeValue = 5621

value.CV.displayName = УЗ аппарат Sonicaid doppler deluxe

ELEMENT

rc_id.extension = 0136

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Ритм пульса плода

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvwyzHR

meaning.displayName = Описание ритма пульса плода

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.CV.codingScheme = CTV3

value.CV.codingSchemeName = NHS Clin. Terms

value.CV.codingSchemeVersion = 1.0

value.CV.codeValue = 635700

value.CV.displayName =
= Ритмичный

ENTRY

rc_id .extension = 0251

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rс_id.root.oid = 9876543213

name = BP

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvbnh

meaning.displayName = Кровяное давление

synthesised = FALSE

subject_of_information_category.codingScheme = 987654333

subject_of_information_category.codingSchemeName = EN13606-3 SUBJECT_CATEGORY

subject_of_information_category.codingSchemeVersion = 1.0

subject_of_information_category.codeValue = DS00

uncertainty_expressed = FALSE

committal.ehr_system.extension = Whittington

committal.ehr_system.assigningAuthorityName = NHS

committal.ehr_system.valid_time= 1/1/1990-1/1/3000

committal.ehr_system.root.oid = 9876543211

committal.time_committed = 13.07.1996 09:11

committal.committer.extension = LLOYD345

committal.committer.assigningAuthorityName = NHS

committal.committer.valid_time = 1/1/1990 - 1/1/3000

committal.committer.root.oid = 9876543211

committal .version_status.codingScheme = 987654338

committal.version_status.codingSchemeName = EN13606-3 VERSION_STATUS

committal.version_status.codingSchemeVersion = 1.0

committal.version_status.codeValue = VER03

committal.previous_version.rc_id.extension = 0151

committal.previous_version.rc_id.assigningAuthorityName = NLONDON-NHS

committal.previous_version.rc_id.valid_time = 1/1/1990 - 1/1/3000

committal.previous_version.rc_id.root.oid = 9876543213

committal.version_set_id.rc_id.extension = 0151

committal.version_set_id.rc_id.assigningAuthorityName = NLONDON-NHS

committal.version_set_id.rc_id.valid_time = 1/1/1990 - 1/1/3000

committal.version_set_id.rc_id.root.oid = 9876543213

ELEMENT

rc_id.extension = 0155

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Систолическое

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvbnhS

meaning.displayName = Измерение систолического давления крови

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN 13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

original_parent_ref.rc_id.extension = 0151

original_parent_ref.rc_id.assigningAuthorityName = NLONDON-NHS

original_parent_ref.rc_id.valid_time = 1/1/1990 - 1/1/3000

original_parent_ref.rc_id.root.oid = 9876543213

value.PQ.value = 100

value.PQ.units = мм рт.ст.

value.PQ.property = Давление

ELEMENT

rc_id.extension = 0258

rc_id.assigningAuthorityName = NLONDON-NHS

rc_id.valid_time = 1/1/1990 - 1/1/3000

rc_id.root.oid = 9876543213

name = Диастолическое

meaning.codingScheme = 1234567890

meaning.codingSchemeName = CEN

meaning.codingSchemeVersion = 1.1

meaning.codeValue = CENarch-xvbnhD

meaning.displayName = Измерение диастолического давления крови

item_category.codingScheme = 987654334

item_category.codingSchemeName = EN 13606-3 ITEM_CATEGORY

item_category.codingSchemeVersion = 1.0

item_category.codeValue = IC01

synthesised = FALSE

value.PQ.value = 60

value.PQ.units = мм рт.ст.

value.PQ.property = Давление


Приложение D (справочное). Отображение на формулировки требований

Приложение D
(справочное)


Как указано во введении, в качестве основы для формулировки требований настоящего стандарта был принят стандарт ИСО/ТС 18308 [9]. В данном приложении представлено отображение формулировок последнего на основные конструкции базовой модели. Это отображение неизбежно не является взаимно-однозначным. Приведенная ниже таблица D.1 предназначена для углубления понимания подхода, принятого при разработке базовой модели.


Таблица D.1 - Отображение требований стандарта ИСО/ТС 18308 на требования настоящего стандарта

Код

Формулировка требования ИСО/ТС 18308

Соответствие в настоящем стандарте

СОС1.1

Архитектура ЭМК должна поддерживать генерацию выходных данных в формате, ориентированном на потребителя (9.1)

Обеспечивается с помощью мер контроля доступа, определенных в ИСО 13606-4

СОС1.2

Архитектура ЭМК должна поддерживать право потребителей на доступ ко всей информации ЭМК с соблюдением юрисдикционных ограничений (9.1)

Обеспечивается с помощью мер контроля доступа, определенных в ИСО 13606-4

СОС1.3

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

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

СОМ2.1

Архитектура ЭМК должна давать возможность обмена данными ЭМК целиком или частично (выписками) между системами с совместимыми архитектурами ЭМК (4.4)

EHR_EXTRACT

СОМ2.3

Архитектура ЭМК должна определять семантику данных, объединяемых в выписке из ЭМК, в соответствии с резидентной ЭМК в принимающей системе (4.7)

EHR_EXTRACT

СОМ2.4

Архитектура ЭМК должна обеспечивать ведение контрольного журнала процессов обмена данными, включая аутентификацию, для идентификации точек передачи и приема выписки из ЭМК, которые необходимо учитывать при объединении данных (4.3)

Передача журнала регистрации доступа, определенная в ИСО 13606-4

СОМ2.6

Архитектура ЭМК должна давать возможность семантической интероперабельности медицинских понятий между системами ведения ЭМК для поддержки автоматической обработки данных в принимающей системе (3.3.4)

Семантика в основном представлена атрибутом RECORD_COMPONENT.meaning с использованием архетипов и типов данных кодированных значений

MEL1.1

Архитектура ЭМК должна поддерживать меры по обеспечению точного отражения хронологии клинических событий и доступности информации в ЭМК (6.3)

Доступность информации:

- RECORD_COMPONENT.committal.time_ committed;

- RECORD_COMPONENT.feeder_audit.time_ committed.

Хронология медицинских событий:

- COMPOSITION.session_time;

- ITEM.obs_time

МЕL1 .2

Архитектура ЭМК должна предоставлять возможность точно воспроизводить содержимое ЭМК по состоянию на любые заданные дату и время с момента ее создания (6.4)

Аналогично MEL1.1

MEL2.1

Архитектура ЭМК должна учитывать, что субъектом лечения в ЭМК может быть как один, так и несколько человек (6.1.1)

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

MEL2.2

Архитектура ЭМК должна обеспечивать регистрацию адекватных атрибутов идентификации пациентов и таких клинически значимых атрибутов пациентов, как дата рождения, пол, этническая принадлежность и т.д. (6.1.2)

Данное требование представлено с помощью пакета DEMOGRAPHICS, но в нем предусмотрены лишь те атрибуты, которые являются минимально достаточными для поиска информации о пациенте в системах ведения ЭМК

MEL2.3

Архитектура ЭМК должна обеспечивать однозначную и надежную идентификацию пользователей, удостоверяющих и помещающих любую конкретную информацию в ЭМК (6.1.3)

AUDIT_INFO.committer

ATTESTATION_INFO.attester.performer

MEL2.4

Архитектура ЭМК должна поддерживать постоянную способность идентифицировать пользователей, даже после изменения имени, профессии, пола или адреса (6.1.3)

Данное требование обеспечивается с помощью единого идентификатора во всех данных ЭМК и его привязкой к демографическим данным в пакете DEMOGRAPHICS

MEL2.5

Архитектура ЭМК должна поддерживать меры по обеспечению однозначной идентификации всех врачей, на которых имеются ссылки в ЭМК (6.1.4)

Аналогично MEL2.4

MEL2.7

Архитектура ЭМК должна поддерживать меры по обеспечению того, чтобы каждая запись в ЭМК имела дату, а ее автор был идентифицирован (6.1.6)

AUDIT_INFO.time_committed

COMPOSITION.composer.performer (не обязателен)

MEL2.8

Архитектура ЭМК должна поддерживать меры по обеспечению реализации безусловного требования того, чтобы каждая вносимая в ЭМК запись приписывалась конкретному ответственному участнику здравоохранения (независимо от того, является ли он ее автором или нет) (6.1.5)

Может быть обеспечено с помощью
COMPOSITION.committal.committer или COMPOSITION.feeder_audit.committer и/или COMPOSITION.composer.performer

MEL2.9

Архитектура ЭМК должна поддерживать меры по обеспечению того, чтобы каждая запись в ЭМК была удостоверена ответственным лицом (6.1.6)

Том FOLDER и композиция COMPOSITION могут содержать экземпляры сведений об аттестации ATTESTATION_INFO, которые, в свою очередь, могут ссылаться на любое число элементов RECORD_ COMPONENTS. Однако в настоящем стандарте включение сведений об аттестации является не обязательным, т.к. многие экземпляры ЭМК никогда не аттестуются

MEL3.1

Архитектура ЭМК должна поддерживать демонстрацию клинической компетентности и ответственности врачей (6.2)

Данное требование является общим, и ему соответствуют многие части базовой модели

MEL5.1

В случае если открытый текст или закодированные термины в ЭМК были переведены на другой язык или преобразованы, то исходный текст или заголовок на языке оригинала должен быть сохранен (6.5.2)

Этому требованию соответствуют свойства типов данных TEXT и CV

MEL7.1

Архитектура ЭМК должна поддерживать управление версиями с дискретностью, на которой информация удостоверяется (6.8)

Вся совокупность записей, отправленных в ЭМК, должна быть заново аттестована при изменении каких-либо частей их содержания. Аттестации заверяют данные, содержащиеся в одной версии композиции COMPOSITION, и не переносятся автоматически на пересмотренную версию

PRO1.1

Архитектура ЭМК должна поддерживать регистрацию всех типов клинических событий, приемов или эпизодов, связанных с лечением пациента (3.1)

Данное требование может быть представлено с помощью архетипов

PRO1.13

Архитектура ЭМК должна поддерживать формирование плана лечения, включая управление состояниями процесса лечения (например запланированное, заказанное, намеченное, текущее, отложенное, ожидающее, завершенное, измененное, проверенное, отмененное) в рамках процесса планирования лечения (3.2.4)

Для определения состояния рабочего процесса (жизненного цикла) и для ссылки на систему управления рабочими процессами могут использоваться атрибуты ENTRY.act_id и ENTRY.act_status. Для ссылок на медицинские показания и последствия действий может использоваться класс связи LINK

PRO1.14

Архитектура ЭМК должна поддерживать регистрацию и отслеживание клинических заявок и запросов, включая выписанные рецепты и другие заявки на лечение, направления на исследования и направления к врачу (3.3.6)

Для определения состояния рабочего процесса (жизненного цикла) и для ссылки на систему управления рабочими процессами могут использоваться атрибуты ENTRY.act_id и ENTRY.act_status

PRO1.15

Архитектура ЭМК должна поддерживать связь между выписанными назначениями и данными наблюдений на основе результатов их выполнения (например, между назначениями на проведение исследований или приема лекарственных средств и последствиями их выполнения)

Аналогично PRO1.13

PRO1.16

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

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

PRO1.2

Архитектура ЭМК должна поддерживать создание, реализацию и обслуживание клинических процессов, поддерживающих действия ее пользователей (3.3.5)

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

PRO1.3

Архитектура ЭМК должна поддерживать непрерывность клинического процесса, возможность запрашивать состояние клинического процесса, вносить изменения в существующий клинический процесс и проверять факт его завершения (3.3.5)

Для определения состояния рабочего процесса (жизненного цикла) и для ссылки на систему управления рабочими процессами могут использоваться атрибуты ENTRY.act_id и ENTRY.act_status. Для ссылок на медицинские показания и последствия действий может использоваться класс связи LINK

PRO1.4

Архитектура ЭМК должна обеспечивать возможность фиксировать неполное завершение клинического процесса (3.3.5)

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

PRO1.5

Архитектура ЭМК должна поддерживать регистрацию и представление целостного состояния здоровья, функционального состояния, проблем, обстоятельств, экологических условий и их последствий (3.2.1)

Эти виды данных могут быть представлены с помощью атрибута RECORD_COMPONENT.meaning, a также с помощью архетипов

PRO1.8

Архитектура ЭМК должна поддерживать регистрацию всех клинических данных в различных режимах (включая автоматизированный) в целях обоснования диагнозов, заключений и предпринимаемых действий, направленных на сохранение здоровья и проведение лечения пациента (3.2.2)

Специфичные сущности ITEM могут быть помечены с помощью атрибута item_category как относящиеся к медицинским заключениям или клиническим обоснованиям

PRO1.9

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

Эти виды данных могут быть представлены с помощью атрибута RECORD_COMPONENT.meaning, с помощью архетипов и типов данных кодированных значений. Специфичные сущности ITEM могут быть помечены с помощью атрибута emphasis как имеющие особое значение

PRO2.1

Архитектура ЭМК должна поддерживать ясные и последовательные правила для ввода, модификации, проверки, передачи, получения, перемещения и замены устаревших данных. Это требование не подразумевает, что для какой-либо конкретной реализации необходимо разрешить удаление содержимого ЭМК. В конкретных случаях следует применять локальные правила сохранения данных (3.3.1)

Данная информация представляется с помощью класса AUDIT_INFO

PRS1.2

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

Обеспечивается с помощью мер контроля доступа, определенных в ИСО 13606-4

PRS1.3

Архитектура ЭМК должна поддерживать ограничения, связанные с секретностью и конфиденциальностью, на уровне как наборов данных, так и отдельных атрибутов данных

Обеспечивается с помощью мер контроля доступа, определенных в ИСО 13606-4

PRS2.2

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

Обеспечивается с помощью мер контроля доступа, определенных в ИСО 13606-4

PRS2.4

Архитектура ЭМК должна поддерживать регистрацию временных интервалов, в рамках которых действует каждое согласие (5.3)

Обеспечивается с помощью мер контроля доступа, определенных в ИСО 13606-4

PRS3.1

Архитектура ЭМК должна поддерживать меры, связанные с определением, применением, изменением и удалением прав доступа ко всем и/или отдельным разделам ЭМК (5.1.1)

Обеспечивается с помощью мер контроля доступа, определенных в ИСО 13606-4

PRS3.3

Архитектура ЭМК должна поддерживать меры, связанные с разрешением и ограничением доступа ко всем и/или отдельным разделам ЭМК в соответствии с действующими правилами согласия и доступа (5.1.1)

Обеспечивается с помощью мер контроля доступа, определенных в ИСО 13606-4

PRS3.4

Архитектура ЭМК должна поддерживать меры, связанные с разделением возможности добавления и/или модификации данных в ЭМК уполномоченными лицами от возможности получения ими доступа к ЭМК (5.1.1)

Обеспечивается с помощью мер контроля доступа, определенных в ИСО 13606-4

PRS5.1

Архитектура ЭМК должна поддерживать ведение контрольного журнала доступа и модификации данных в рамках всей или отдельных разделов ЭМК (5.5)

Передача журнала регистрации доступа, определенная в ИСО 13606-4

PRS5.2

Архитектура ЭМК должна поддерживать регистрацию характера каждого доступа и/или модификации (5.5)

Передача журнала регистрации доступа, определенная в ИСО 13606-4

STR1.1

Архитектура ЭМК должна обеспечивать структурирование информации, содержащейся в ЭМК, по разным разделам для обеспечения пользователям возможности поиска данных и просмотра разделов в соответствии с их запросами (1.1)

Класс раздела SECTION

STR1.3

Архитектура ЭМК должна поддерживать ЭМК, которая может передаваться между ее пользователями и объединяться с информацией из других ЭМК независимо от аппаратных средств, программного обеспечения (прикладных программ, операционных систем, языков программирования), баз данных, сетей, систем кодирования и естественных языков (2.6)

Соответствует главным целям данной базовой модели

STR2.1

Архитектура ЭМК должна обеспечивать возможность хранения данных в виде списков с тем, чтобы сохранялся порядок данных при их выводе на экран (1.2.1)

CLUSTER.structure_type

STR2.10

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

- истории болезни;

- врачебного осмотра;

- психологической, социальной, экологической, семейной информации и проведенного самолечения;

- аллергических реакций и других лечебных мер предосторожности;

- профилактических и оздоровительных мер, например прививок и воздействия на образ жизни;

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

- клинических обследований, трактовок, решений и клинических обоснований;

- запросов/распоряжений о дальнейшем исследовании, лечении или выписке;

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

- планов здравоохранения, здоровья, функционального состояния и сводок о здоровье;

- выявления болезней и получения согласий;

- поставщиков, моделей и изготовителей технических средств (например, имплантатов или протезов)

Эти виды данных могут быть представлены с помощью атрибута RECORD_COMPONENT.meaning, а также с помощью архетипов

STR2.11

Архитектура ЭМК должна поддерживать регистрацию (и классификацию в целях идентификации) данных о пациенте, включающих в себя идентификацию пациента, его местожительство (регистрацию по месту проживания и пребывания), демографические признаки, контактную информацию, род деятельности и другие административные данные (1.3.3)

Демографические данные пациента представлены с помощью пакета DEMOGRAPHICS, но в нем предусмотрены лишь те атрибуты, которые являются минимально достаточными для поиска информации о пациенте в системах ведения ЭМК

STR2.12

Архитектура ЭМК должна поддерживать стандарты информации, позволяющие однозначно идентифицировать субъект лечения, врачей, привлеченных к лечению (включая их роли и контекст лечения), место, дату, время и продолжительность лечения, а также третьи стороны, например ближайших родственников или неклинические контакты (1.3.3)

Для указания сторон, отвечающих за исполнение данных ролей, предусмотрена ассоциация класса FUNCTIONAL_ROLE с конкретными элементами RECORD_COMPONENT

STR2.13

Архитектура ЭМК должна поддерживать управление процессами здравоохранения и эпизодами лечения, а также организацию данных о посещениях и приемах у врача (1.3.3)

(Главные цели базовой модели)

STR2.13

Архитектура ЭМК должна поддерживать управление процессами здравоохранения и эпизодами лечения, а также организацию данных о посещениях и приемах у врача (1.3.3)

Если эти виды данных включены в ЭМК, то их можно представить с помощью архетипов

STR2.14

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

Если эти виды данных включены в ЭМК, то их можно представить с помощью архетипов

STR2.15

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

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

Согласия на раскрытие информации определены в ИСО 13606-4

STR2.2

Архитектура ЭМК должна обеспечивать возможность хранения данных в виде таблиц для сохранения связи данных с наименованиями соответствующих строк и столбцов (1.2.1)

CLUSTER.structure_type

STR2.3

Архитектура ЭМК должна обеспечивать возможность хранения данных в виде иерархических структур с тем, чтобы сохранялась связь между родительскими и дочерними узлами (1.2.1)

Полная иерархия элементов RECORD_COMPONENT

STR2.4

Архитектура ЭМК должна обеспечивать возможность такого хранения данных, чтобы сохранялись простые пары "имя - значение" (1.2.1)

Атрибуты элемента RECORD_COMPONENT: name, meaning и archetype_id

STR2.5

Архитектура ЭМК должна обеспечивать возможность хранения множества значений какого-либо параметра, полученных как через короткие промежутки времени при неизменном положении измерительного инструмента, так и при проведении многократных отдельных измерений в одном или в разных местах. Контекст этих измерений (например, кто производил измерение, какой метод использовался и т.д.) должен быть сохранен. Должна быть обеспечена возможность выдачи этих значений по запросам и их упорядочения разными способами (1.1)

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

STR2.6

Архитектура ЭМК должна поддерживать включение повествовательного свободного текста (1.2.2.1)

Данное требование обеспечивается типом данных TEXT

STR2.8

Архитектура ЭМК должна поддерживать включение комментариев в хранящиеся данные, предоставляя врачу возможность соответствующим образом квалифицировать структурированную информацию. Должна иметься возможность устанавливать связи комментариев с конкретными атрибутами данных (1.2.2.2)

Идентификация информации о клиническом обосновании обеспечивается с помощью атрибута ITEM.item_category

STR2.9

Архитектура ЭМК должна обеспечивать средства для связи выделенных элементов на разных уровнях с комментариями и другими элементами, которые могут изменять форму их вывода на экран или выдачи по запросу (1.2.2.2)

ITEM.emphasis и любые дополнительные атрибуты визуального представления данных, включенные в специфичные архетипы

STR3.14

Архитектура ЭМК должна поддерживать регистрацию контекстно-зависимых данных, связанных с датой и/или временем, когда событие произошло

COMPOSITION.session_time

STR3.15

Архитектура ЭМК должна поддерживать регистрацию контекстно-зависимых данных, связанных с датой и/или временем, когда событие было зарегистрировано

AUDIT_INFO.time_committed

STR3.16

Архитектура ЭМК должна поддерживать регистрацию контекстно-зависимых данных, связанных с субъектом

EHR_EXTRACT.subject_of_care и факультативно ENTRY.subject_of_information

STR3.19

Архитектура ЭМК должна поддерживать регистрацию контекстно-зависимых данных, связанных с местом, где событие было зарегистрировано

FUNCTIONAL_ROLE.healthcare_facility и FUNCTIONAL_ROLE.service_setting

STR3.2

Архитектура ЭМК должна поддерживать определение логической структуры числовых и количественных данных, включая оперирование единицами измерения (1.3.4.2)

С помощью иерархии сущностей ITEM можно представить структуру данных любой степени сложности; для представления отдельных числовых или количественных данных можно использовать тип данных PQ, определенный в стандарте CEN

STR3.20

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

Информацию о клинических обоснованиях можно идентифицировать с помощью атрибута ITEM.item_category

STR3.21

Архитектура ЭМК должна поддерживать регистрацию контекстно-зависимых данных, связанных с протоколом, относящимся к зарегистрированной информации

Протокол, ссылку на руководство или описание можно идентифицировать с помощью атрибута ITEM.item_category

STR3.22

Архитектура ЭМК должна определять семантическое представление связей между различной информацией в ЭМК (1.3.7)

Класс LINK и совокупность терминов, относящихся к характеру и роли, определенных в ИСО 13606-3

STR3.23

Архитектура ЭМК должна поддерживать связи с "внешними справочными данными", которые не могут храниться в ЭМК, не подвергая при этом риску безопасность пациента (1.3.7)

Эти данные могут быть представлены с помощью типа данных ED, определенного в стандарте CEN

STR3.5

Диапазоны величин

Эти данные могут быть представлены с помощью типа данных PQ, определенного в стандарте CEN

STR3.6

Отношения величин

Эти данные могут быть представлены с помощью типа данных PQ, определенного в стандарте CEN

STR4.2

На уровне атрибутов данных архитектура ЭМК должна поддерживать владение кодом, схемой кодирования (например, системой кодирования/классификации), версией, исходным языком и исходными правилами

Эти данные могут быть представлены с помощью типа данных CV

STR4.3

Архитектура ЭМК должна обеспечивать хранение терминологических данных и сохранять информацию о терминологическом комплекте, из которого они были выбраны (1.2.1)

Эти данные могут быть представлены с помощью типа данных CV

STR4.4

В случае если информация не является однозначной, связанной только с одним местом или одним способом, архитектура ЭМК должна поддерживать подробные правила, позволяющие избежать двусмысленности (например, не должно быть несколько толкований значения того, что означает запись: "[не] [отсутствует пульс на нижних конечностях]")

После многочисленных консультаций было принято решение, что такие данные должны контролироваться терминологическими системами, а не архитектурой ЭМК

STR4.6

Исходное представление текста, введенное врачом, должно сохраняться в ЭМК при переводе информации с одного естественного языка на другой или при преобразовании терминов из одной системы кодирования/классификации в другую

Эти данные могут быть представлены с помощью типов данных TEXT и CV

Приложение ДА (справочное). Сведения о соответствии ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации

Приложение ДА
(справочное)



Таблица ДА. 1

Обозначение ссылочного международного стандарта

Степень соответствия

Обозначение и наименование соответствующего национального стандарта

СЕН/ТС 14796:2004

-

*

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

Библиография

[1]

ISO/IEC Guide 2:2004, Standardization and related activities - General vocabulary

[2]

ISO 639 (all parts), Codes for the representation of names of languages

[3]

ISO 3166-1:2006, Codes for the representation of names of countries and their subdivisions - Part 1: Country codes

[4]

ISO 3166-2:1998*, Codes for the representation of names of countries and their subdivisions - Part 2: Country subdivision code

_______________
* Отменен. Действует ИСО 3166-2:2007. Для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.

[5]

ISO 3166-3:1999, Codes for the representation of names of countries and their subdivisions - Part 3: Code for formerly used names of countries

[6]

ISO 7498-2:1989, Information processing systems - Open Systems Interconnection - Basic Reference Model - Part 2: Security Architecture

[7]

ISO 8601:2004 Data elements and interchange formats - Information interchange - Representation of dates and times

[8]

ISO/TS 17090-1:2002*, Health informatics - Public key infrastructure - Part 1: Framework and overview

_______________
* Отменен. Действует ИСО 17090-1:2008. Для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.

[9]

ISO/TS 18308:2004*, Health informatics - Requirements for an electronic health record architecture

_______________
* Отменен. Действует ИСО 18308:2011. Для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.

[10]

ISO/TR 20514:2005, Health informatics - Electronic health record - Definition, scope and context

[11]

ISO/IEC 2382-8:1998, Information technology - Vocabulary - Part 8: Security

[12]

ISO/IEC 8824-1, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation - Part 1

[13]

ISO/IEC 10746-1:1998, Information technology - Open Distributed Processing - Reference model: Overview - Part 1

[14]

ISO/IEC 11179-3:2003, Information technology - Metadata registries (MDR) - Part 3: Registry metamodel and basic attributes

[15]

ISO/IEC 11404:1996* Information technology - Programming languages, their environments and system software interfaces - Language-independent datatypes

_______________
* Отменен. Действует ИСО 11404:2007. Для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.

[16]

BS ISO 21090, Harmonized data types for information interchange

[17]

EN 12967 (all parts), Health Informatics - Service architecture

[18]

EN 13940-1:2007, Health informatics - System of concepts to support continuity of care - Part 1: Basic concepts

[19]

EN 14822-1:2005, Health informatics - General purpose information components - Part 1: Overview

[20]

EN 14822-2:2005, Health informatics - General purpose information components - Part 2: Nonclinical

[21]

EN 14822-3:2005, Health informatics - General purpose information components - Part 3: Clinical

[22]

CEN/TS 14822-4:2005, Health informatics - General purpose information components - Part 4: Message headers

[23]

RFC 1738:1994, Uniform Resource Locators (URL)

[24]

RFC 2045:1996, Multipurpose Internet Mail Extensions - (MIME) Part One: Format of Internet Message Bodies

[25]

RFC 2046:1996, Multipurpose Internet Mail Extensions - (MIME) Part Two: Media Types

[26]

RFC 2806:2000, URLs for Telephone Calls

[27]

RFC 2936:2000, HTTP MIME Type Handler Detection

[28]

RFC 2978:2000, IANA Charset Registration Procedures

[29]

ATM Draft Standard Specification for Continuity of Care Record (CCR). Technical Committee E.31.28. 2004

http://www.astm.org

[30]

ASTM E 1769-95, Standard Guide for Properties of Electronic Health Records and Record Systems

[31]

BARNETT, G.O. and SHORTLIFFE, E.H., Medical Informatics: Computer Applications in Health Care, Addison Wesley, 1990

[32]

BEALE T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. In: Procs. 17th Annual ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications, Washington 2002

http://www.deepthought.com.au/it/archetypes/archetypes_new.pdf

[33]

BEALE, Т., The GEHR software architecture for a reliable EHR, Toward an Electronic Health Record Europe '99, pp.328-339, Nov. 1999

[34]

BERG, M., Medical work and the computer-based patient record: a sociological perspective, Methods of Information in Medicine, 37(3), pp.294-301, Sep. 1998

[35]

DICK, R.S. and STEEN, E.B., The Computer-Based Patient Record: An Essential Technology for Health Care, US National Academy of Sciences, Institute of Medicine, 1991

[36]

DIXON, R., GRUBB, P.A. and LLOYD, D., Interim report to CEN. EHCR Support Action Deliverables 3.1 and 3.2, European Commission DGXIII, Brussels; Sep. 1998

http://www.chime.ucl.ac.uk/Healthl/EHCR-SupA

[37]

DIXON, R., GRUBB, P.A. and LLOYD, D., Guidelines on the interpretation of CEN EHCRA. EHCR Support Action Deliverable 2.4, European Commission DGXIII, Brussels; May 2000

http://www.chime.ucl.ac.uk/Healthl/EHCR-SupA

[38]

DIXON, R., GRUBB, P.A., LLOYD, D. and KALRA, D., Consolidated List of Requirements, EHCR Support Action Deliverable 1.4, European Commission DGXIII, Brussels, 59 pp., May 2001
http://www.chime.ucl.ac.uk/Healthl/EHCR-SupA/del1-4v1_3.PDF

[39]

DOLIN, R.H., ALSCHULER, L, BEHLEN, R, BIRON, P.V., BOYER, S., ESSIN, D., HARDING, L, LINCOLN, T, MATTISON, J.E., RISHEL, W., SOKOLOWSKI, R., SPINOSA, J. and WILLIAMS, J.P., HL7 document patient record architecture: an XML document architecture based on a shared information model. Proceedings/AMIA Annual Symposium, pp.52-56, 1999

[40]

DOLIN, R.H., ALSCHULER, L, BOYER, S., and BEEBE, C, An update on HL7's XML-based document representation standards, Proceedings/AMIA Annual Symposium, pp.190-194, 2000

[41]

GRIFFITH, S., KALRA, D., LLOYD, D. and INGRAM, D., A portable and communicable architecture for electronic healthcare records: the Good European Healthcare Record Project (AIM project 2014), Greenes, R. A. et al, eds. Medinfo 8, 1995; pp.223-226, 1995

[42]

GRIMSON, J., GRIMSON, W., BERRY, D., STEPHENS, G., FELTON, E., KALRA, D., TOUSSAINT, P. and WEIER, O.W., A CORBA-based integration of distributed electronic healthcare records using the synapses approach, IEEE Trans Inf Technol Biomed., 2(3), pp.124-138, Sep. 1998

[43]

GRIMSON, W. and GROTH, T, (eds) The Synapses User Requirements and Functional Specification (Part B), EU Telematics Application Programme, Brussels, The Synapses Project, Deliverable USER 1.1.1b, 1996

[44]

Health Level Seven (HL7): Clinical Document Architecture (CDA) Release 2. Committee Ballot, December 2003

http://hl7.org/library/Committees/structure/CDA.ReleaseTwo.CommitteeBallot02.Dec.2003.zip

[45]

Health Level Seven (HL7): Reference Information Model (RIM) version 2.02

http://hl7.org/library/data-model/RIM/C30202/rim.htm

[46]

HEARD, S., GRIVEL, A., SCHLOEFFEL, P. and DOUST, J., The benefits and difficulties of introducing a national approach to electronic health records in Australia in: National Electronic Health Records Taskforce, A Health Information Network for Australia, Department of Health and Aged Care, Commonwealth of Australia, Jul. 2000

[47]

IAKOVIDIS, I., Towards personal health record: current situation, obstacles and trends in implementation of electronic healthcare record in Europe, International Journal of Medical Informatics, 52(1-3), 105-115, 1998b

[48]

INGRAM, D., The Good European Health Record Project in: Laires, Laderia, Christensen, (eds) Health in the New Communications Age, IOS Press, Amsterdam, pp.66-74, 1995

[49]

INGRAM, D., SOUTHGATE, L, KALRA, D., GRIFFITH, S., HEARD, S. et al, The GEHR Requirements for Clinical Comprehensiveness, European Commission, Brussels, The Good European Health Record Project: Deliverable 4, 19 chapters, 144 pages, 1992

[50]

Integrating the Healthcare Enterprise (IHE), Cross-Enterprise Clinical Documents Sharing (XDS), IHE IT Infrastructure Technical Framework Supplement version 2.12004, 2004-2005

http://www.himss.org/content/files/IHE_ITI_Cross-enterprise_Doc_Sharing_PC_2004-06-15.pdf

[51]

KALRA, D., Clinical foundations and information architecture for the implementation of a federated health record service, PhD Thesis, University of London, 2003

http://www.ehr.chime.ucl.ac.uk/docs/Kalra,%20Dipak%20(PhD%202002).pdf

[52]

KALRA, D., (ed) Synapses ODP Information Viewpoint, EU Telematics Application Programme, Brussels, The Synapses Project: Final Deliverable, 10 chapters, 64 pages, 1998

[53]

KALRA D., LLOYD D., AUSTIN T, O'CONNOR A., PATTERSON D. and INGRAM D., Information Architecture for a Federated Health Record Server, in Mennerat F. (ed), Electronic Health Records and Communication for Better Health Care Proceedings of EuroRec '01. Studies in Health Technology and Informatics, 87, 47-71, IOS Press, ISSN: 0926-9630, 2002

[54]

KALRA, D., AUSTIN, A., O'CONNOR, A., PATTERSON, D., LLOYD, D. and INGRAM, D., Design and Implementation of a Federated Health Record Server, Toward an Electronic Health Record Europe, Paper 001: 1-13, Medical Records Institute for the Centre for Advancement of Electronic Records Ltd., 2001

[55]

KALRA, D., FRERIKS, G., LLOYD, D., KLEIN, G., BEALE, T, HEARD, S., SCHLOEFFEL, P., MASKENS, A., MENNERAT, F. and INGRAM, D., Towards a revised CEN standard for Electronic Health Record Communication, in Brown P (ed) procs Mobile-Health Europe, Medical Records Institute, April 2002

[56]

LLOYD, D. and KALRA, D., EHR Requirements, in BLOBEL, B. and PHAROW, P., (eds) Advanced Health Telematics and Telemedicine - The Magdeburg Expert Summit Textbook, Studies in Health Technology and Informatics, 96, pp.231-237, IOS Press, ISSN:0926-9630, 2003

[57]

LLOYD, D., KALRA, D., BEALE, T, MASKENS, A., DIXON, R., ELLIS, J., CAMPLIN, D., GRUBB, P. and INGRAM, D., (eds), The GEHR Final Architecture Description. European Commission, Brussels, The Good European Health Record Project, Deliverable 19, 11 chapters, 250 pages, 1995

http://www.chime.ucl.ac.uk/Healthl/GEHR/EUCEN/del19.pdf

[58]

RECTOR, A.L., NOWLAN, W.A., KAY, S., GOBLE, C.A. and HOWKINS, T.J., A framework for modelling the electronic medical record. Methods of Information in Medicine, 32(2), pp.109-119, Apr. 1993

[59]

SCHLOEFFEL, P., LLOYD, D., BEALE, T, INGRAM, D., HEARD, S. and KALRA, D., The open HER Foundation [Web Page], Accessed July 2004

http://www.openehr.org

[60]

SCHLOEFFEL, P., HEARD, S., BEALE, T. and ROWED, D., The Good Electronic Health Record (GEHR) in Australian General Practice, Toward an Electronic Health Record Europe '99, pp.340-346, Nov. 1999

[61]

SHORTLIFFE, E.H., The evolution of health-care records in the era of the Internet. Medinfo, 9,1, Suppl: 8-14, 1998

[62]

SOTTILE, P.A., FERRARA, F.M., GRIMSON, W., KALRA, D. and SCHERRER, J.R., The holistic healthcare information system, Toward an Electronic Health Record Europe '99, pp.259-266, Nov. 1999

[63]

TANGE, H.J., Consultation of medical narratives in the electronic medical record, Methods of Information in Medicine, 38(4-5), pp.289-93*, Dec. 1999

_______________
* Текст документа соответствует оригиналу. - .

[64]

WAEGEMANN, C.P., Medical Record Institute's survey of electronic health record trends and usage, Toward an Electronic Health Record Europe '99, pp.147-158, Nov. 1999

[65]

A Health Information Network for Australia, Commonwealth of Australia, National Electronic Health Record Taskforce, ISBN 0 642 44668 7, July 2000

http: //www.health.gov.au.




Электронный текст документа
и сверен по:
официальное издание
М.: Стандартинформ, 2013