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

     ГОСТ Р ИСО 13606-2-2012

Группа П85

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

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

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

 Часть 2

 Спецификация передачи архетипов

 Health informatics. Electronic health record communication. Part 2. Archetype interchange specification

ОКС 35.240.80

ОКСТУ 4002

Дата введения 2013-07-01

Предисловие

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

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

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

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

________________

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

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

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

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)

 Введение

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

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

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

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

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

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

Стандарт ИСО 13606-2 подготовлен техническим комитетом ИСО/ТК 215 "Информатизация здоровья".

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

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

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

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

Архетипы

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

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

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

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

Для класса EHR_EXTRACT, определенного в ИСО 13606-1, архетип определяет (и эффективно ограничивает) конкретную иерархию подклассов класса RECORD_COMPONENT, определяя и ограничивая их имена и релевантные значения других атрибутов, обязательность и кратность каждого узла иерархии, типы данных и диапазоны значений, которые могут принимать значения данных класса ELEMENT. Архетип может содержать также другие ограничения зависимостей. Экземпляры архетипа, в свою очередь, соответствуют формальной модели, называемой "моделью архетипов" (которая является моделью ограничений, описывающей информационную точку зрения в терминах модели ОРО). Хотя модель архетипов стабильна, отдельные экземпляры архетипов могут пересматриваться или заменяться другими по мере развития клинической практики. Чтобы новые редакции архетипа не сделали недействительными данные, созданные в предыдущих редакциях, применяется контроль версий.

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

Базовая модель, определенная в ИСО 13606-1, описывает атрибуты, применяемые для указания архетипа, которому соответствует любой объект класса RECORD_COMPONENT, содержащийся в выписке EHR_EXTRACT. Класс RECORD_COMPONENT содержит атрибут archetype_id, предназначенный для идентификации архетипа и узла, которым соответствует этот класс. В случае данных, для представления которых использованы архетипы, атрибут meaning относится к исходному понятию, с которым связан соответствующий узел архетипа. Однако необходимо отметить, что ИСО 13606-1 не требует участия архетипов в управлении иерархией объектов RECORD_COMPONENT в выписке EHR_EXTRACT; в данной модели атрибуты, относящиеся к архетипам, необязательны. Тем самым учтено, что международное принятие подхода на основе архетипов будет постепенным в течение ряда лет.

Фонды архетипов

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

- схемы данных (модели) существующих медицинских информационных систем;

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

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

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

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

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

- заранее согласованные термины в терминологических системах.

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

Привлечение национальных служб здравоохранения, академических организаций и профессиональных органов к разработке архетипов даст возможность использовать данный подход для достижения надежности медицинской практики, основанной на принципах доказательной медицины. Следующей ключевой задачей является стимулирование медицинских сообществ к созданию библиотек архетипов. Определение хода работы находится вне области применения настоящего стандарта, но национальные программы здравоохранения, по крайней мере, в нескольких странах начинают стимулировать коллективы разработчиков медицинских информационных технологий к разработке и вводу в действие совокупностей архетипов, удовлетворяющих потребностям конкретных областей здравоохранения. Будут создаваться региональные или национальные общедоступные библиотеки определений архетипов с доступом через Интернет, которые могут использоваться в системах ведения ЭМК местного уровня. Для этого потребуются процессы верификации и сертификации качества совместно используемых архетипов, что также выходит за рамки настоящего стандарта, но продвигается некоммерческими организациями, например openEHR Foundation и EuroRec Institute.

Передача архетипов

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

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

Обзор модели архетипов

Ниже приведено общее справочное описание модели, определенной в разделе 7.

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

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

В пакет архетипа включен также перечисляемый тип данных VALIDITY_KIND. Он предназначен для использования в качестве типа данных любого атрибута в модели ограничений, имеющего логические значения "обязательный", "необязательный" или "запрещенный". Он используется в данной модели в классах C_Date, C_Time и C_Date_Time.

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

- на новый язык переводится каждый элемент, зависящий от языка;

- к объекту ARCHETYPE.translations добавляется новый экземпляр класса TRANSLATION_DETAILS, содержащий подробные сведения о переводчике, организации, контроле качества и т.д.

Функция languages_available дает полный список языков архетипа.

Определение архетипа

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

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

- C_complex_object - любой внутренний узел, представляющий ограничение экземпляров непримитивного типа данных, например ENTRY, SECTION;

- C_attribute - узел, представляющий ограничение атрибута объектного типа данных (т.е. в терминах языка UML - "отношение" или "примитивный атрибут");

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

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

- Constraint_ref - узел, который (обычно) ссылается на ограничение текстового объекта или объекта, имеющего кодированные значения. Он появляется в разделе онтологии архетипа и в языке ADL и обозначается с помощью кода "acNNNN"; ограничение выражается в терминах запроса к внешнему объекту обычно к терминологии или онтологии;

- Archetype_slot - узел, формулировки которого задают ограничение, определяющее другие архетипы, возможные в данной точке рассматриваемого архетипа; логически у данного узла та же семантика, что и у узла C_COMPLEX_OBJECT за исключением того, что ограничения выражены для другого архетипа, а не для рассматриваемого.

Описание архетипа

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

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

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

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

Онтология архетипа

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

Специализация архетипа

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

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

Композиция архетипов

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

Типы данных и пакет поддержки

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

Первая группа содержит наиболее общие типы данных:

- Any (любой);

- Boolean (булевский);

- Character (символьный);

- Integer (целый);

- Real (действительный);

- Double (двойной точности);

- String (строковый).

Вторая группа содержит допустимые библиотечные типы данных:

- date (дата);

- time (время);

- date_time (дата и время);

- duration (длительность).

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

Третья группа содержит обобщенные типы данных:

- List<T> (упорядоченный список, дубликаты допустимы);

- Set<T> (неупорядоченный список, дубликаты недопустимы);

- Hash <Т, К> (список односторонних сверток элементов любого типа);

- Interval <Т> (интервал экземпляров любого упорядоченного типа).

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

Остальные необходимые типы данных определены в пакете поддержки (Support Package) модели архетипа:

- ARCHETYPE_ID (идентификатор архетипа);

- HIER_OBJECT_ID (идентификатор иерархии объектов);

- TERMINOLOGY_ID (идентификатор терминологии);

- CODE_PHRASE (кодированное предложение);

- CODED_TEXT (кодированный текст).

Пакет поддержки также содержит два перечисляемых класса, предоставляющие контролируемые наборы данных, необходимые в настоящем стандарте.

Пакет ограничений модели

Любое определение архетипа представляет собой экземпляр класса C_COMPLEX_OBJECT, который описывает ограничения класса в основополагающей базовой модели (см. ИСО 13606-1), записанные в атрибуте rm_type_name. Класс C_COMPLEX_OBJECT содержит атрибуты типа C_ATTRIBUTE, являющиеся ограничениями атрибутов (т.е. любого свойства, включая отношения) данного класса базовой модели. Соответственно, каждый экземпляр класса C_ATTRIBUTE содержит имя ограничиваемого атрибута (в атрибуте rm_attribute_name), существование и кратность, заданные ограничением (в зависимости от того, является ли ограничиваемый атрибут кратным или одиночным отношением), а также ограничение объекта, на который ссылается данный экземпляр класса C_ATTRIBUTE с помощью своего атрибута children (в соответствии с его базовой моделью) в форме новых объектов класса C_OBJECT.

Основными подтипами класса С_OBJECT являются:

- C_COMPLEX_OBJECT (комплексный объект);

- C_PRIMITIVE_OBJECT (примитивный объект);

- ARCHETYPE_SLOT (слот архетипа).

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

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

Все типы узлов

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

Булевское значение атрибута any_allowed "истина" означает, что любое значение, разрешенное базовой моделью для данного атрибута, допускается и архетипом; его использование обеспечивает простое выражение логической идеи полностью "открытого" ограничения, не требующего формирования какой-либо дальнейшей субструктуры.

Узлы атрибутов

Ограничения атрибутов описываются экземплярами двух подтипов класса C_ATTRIBUTE, а именно, C_SINGLE_ATTRIBUTE и C_MULTIPLE_ATTRIBUTE. Для обоих подтипов общее ограничение состоит в возможности существования соответствующего экземпляра (заданного атрибутом rm_attribute_name). Оба подтипа имеют список потомков, описывающих ограничения значений объекта (или объектов) атрибута.

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

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

Параметр cardinality (кратность) требуется только для таких контейнеров объектов, как List<T>, Set<T>, BAG<T> и т.д., тогда как параметр existence (существование) требуется всегда. Если используются оба параметра, то это имеет следующий смысл: ограничение существования указывает, будет ли данный объект находиться в контейнере (вообще), тогда как ограничение кратности указывает, сколько элементов должно находиться в контейнере, и организован ли он логически как список (list), множество (set) или пакет (bag).

Примитивные типы данных

Ограничения примитивных типов данных описываются классами, наследуемыми от класса C_PRIMITIVE, а именно, C_STRING, C_INTEGER и т.д.

Ссылки на ограничения

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

- набор допустимых объектов CODED_TERM, например типов гепатита;

- выражение INTERVAL<QUANTITY>, определяющее базовый диапазон;

- множество единиц или свойств, или других числовых элементов.

Утверждения

Класс

C_ATTRIBUTE

и подтипы класса

C_OBJECT

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

C_COMPLEX_OBJECT

может включать в себя один или несколько

инвариантов

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

С_ATTRIBUTE

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

диастолического давления" в архетипе понятия "измерение кровяного давления". Подобные инварианты могут быть выражены с использованием синтаксиса, производного от синтаксиса языка OCL, разработанного в Object Management Group (OMG).

Утверждения также используются в объектах ARCHETYPE_SLOT, чтобы указать для слота "включенные" и "исключенные" архетипы.

Утверждения моделируются в форме дерева обобщенных выражений, состоящих из унарных префиксных (например not р) и бинарных инфиксных (например р and q) операторов.

Атрибут node_id и пути

Атрибут node_id в классе C_OBJECT и всех его подтипах выполняет две функции:

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

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

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

Расширения, специфичные для предметной области

Главная часть модели ограничений архетипа позволяет в соответствии со стандартом архетипировать (т.е. ограничивать) любой тип данных базовой модели с помощью регулярной последовательности объектов: C_COMPLEX_OBJECT/C_ATTRIBUTE/C_PRIMITIVE_OBJECT. Однако для описания типов данных, соответствующих логическим "листьям" более низких уровней, может потребоваться специальная семантика ограничений, которая обычно не используется при стандартном подходе. Чтобы обеспечить интеграцию таких классов в общую модель ограничений, вводится класс C_DOMAIN_TYPE. Это дает возможность создавать особые классы "С_", унаследованные от C_DOMAIN_TYPE, которые описывают пользовательскую семантику специфических типов данных базовой модели. Например, может быть создан класс с именем C_QUANTITY, имеющий семантику ограничений, отличную от используемой по умолчанию семантики последовательности C_COMPLEX_OBJECT/C_ATTRIBUTE, представляющей эти ограничения обычным образом (т.е. на основе базовой модели).

Подразумеваемые значения

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

Понятие подразумеваемых значений отличается от понятия "значений по умолчанию"; значения по умолчанию присутствуют в данных, а подразумеваемые - нет.

Пакет утверждений

Утверждения представляются в архетипах на языке логики предикатов первого порядка с контролем типов (FOL - first-order predicate logic). Они используются в двух случаях: 1) для описания ограничений слотов архетипа; 2) для описания инвариантов в ограничениях сложных объектов. В обоих случаях они ограничивают что-либо внутри архетипа. Ограничения внешних ресурсов, например терминологий, представляются в разделе связывания ограничений онтологии архетипа.

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

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

- именованные константы любого примитивного типа данных плюс типы данных даты и времени;

- арифметические операторы: +, *, -, /,

(показатель степени);

- операторы отношения: >, <, >=, <=, =, != совпадения;

- булевские операторы: not, and, or, xor;

- кванторы, применяемые к переменным контейнера: for_all (для всех), exists (существует).

Пакет примитивов

В конечном счете любое определение архетипа развертывается до конечных узлов ограничений экземпляров примитивных типов данных. Пакет примитивов определяет семантику ограничений таких типов. Для большинства типов данных существуют, по крайней мере, два альтернативных способа описания ограничения; например, ограничение типа данных C_DAТЕ может быть представлено в форме шаблона или интервала дат lnterval<Date>.

Пакет онтологии

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

Онтология архетипа содержит следующие составляющие:

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

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

- набор из одной или нескольких связей определений терминов с кодами терминов из внешних терминологий - факультативно;

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

Глубина специализации

Любой конкретный архетип находится в определенной точке иерархии специализации архетипов. Глубина специализации указывается атрибутом specialisation_depth. Архетип, не являющийся специализацией другого архетипа, имеет глубину специализации 0. Коды терминов и ограничений, включенные в онтологию специализированных архетипов (т.е. тех, которых нет в онтологии родительского архетипа), определяются строго с использованием символа десятичной точки ".". Например, архетип, имеющий глубину специализации 2, будет использовать коды определений терминов следующего вида:

"at0.0.1" - новый термин, который определен в данном архетипе и не является специализацией какого-либо предшествующего термина в каком-либо родительском архетипе;

"аt0001.0.1" - термин, являющийся специализацией термина "аt0001", определенного в родителе верхнего уровня. Промежуточный ".0" необходим, чтобы показать, что новый термин имеет глубину 2, а не 1;

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

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

Определения терминов и ограничений

Локальные определения терминов и ограничений моделируются в виде экземпляров класса ARCHETYPE_TERM, являющихся кодами, связанными со списком пар "имя-значение". Для любого определения термина или ограничения данный список должен содержать, по крайней мере, пары "имя-значение" для имен "text" (текст) и "description" (описание). Кроме того, список должен содержать такой элемент, как "provenance" (происхождение), который мог бы использоваться для указания того, что термин происходит из внешней терминологии. Атрибут term_attribute_names класса ARCHETYPE_ONTOLOGY coдержит список имен атрибутов, используемых в архетипе для определений терминов и ограничений, включая "text" и "description", а также любые другие, используемые в разных местах.

Пакет обобщенных типов данных

Данный пакет включен для подтверждения семантики обобщенных типов данных, используемых в настоящем стандарте. Хотя типы List<T>, Set<T>, Hash<T,K> и lnterval<T> являются обобщенными типами данных, поддерживаемыми многими программными средами, они не поддерживаются в языке UML непосредственно. В данном пакете новые типы данных, например List<String> (список строк), определяются с использованием зависимостей связей между новым базовым типом (в данном случае List<String>) и классом (LIST в данном примере), который определяет минимальную необходимую семантику для всех типов данных List.

Расширение, специфическое для предметной области (справочно)

Классы, специфические для предметной области, могут быть добавлены в модель ограничений архетипа с помощью наследования от класса C_DOMAIN_TYPE. В пункте 7.12.2 (научные/клинические вычислительные типы данных) показан общий подход, используемый для добавления классов ограничений общеупотребительных понятий, используемых в научных и клинических вычислениях, например "порядковое числительное", "кодированный термин" и "количество". В нем показаны типы ограничений C_ORDINAL, C_CODED_TEXT и C_QUANTITY, которые факультативно могут применяться в архетипах вместо используемой по умолчанию семантики ограничений, представленной с помощью экземпляров классов C_OBJECT/C_ATTRIBUTE.

Обзор языка ADL

Язык определения архетипов (ADL) является формальным языком описания архетипов. В языке ADL используются два разных синтаксиса - cADL (форма ограничений ADL) и dADL (форма определения данных ADL) для описания ограничений данных, являющихся экземплярами информационной модели, определенной в разделе 7.

Архетипы, описанные на языке ADL, имеют определенный синтаксис и напоминают файлы в языках программирования. Сам язык ADL имеет очень простой "связующий" синтаксис, в котором используются два других синтаксиса соответственно для представления структурированных ограничений и данных. Синтаксис cADL используется для описания определения архетипа, а синтаксис dADL - для описания данных, появляющихся в разделах "language (язык)", "description (описание)", "ontology (онтология)" и "revision_history (история версий)" ADL-архетипа. Структура верхнего уровня ADL-архетипа показана на рисунке 1 (сокращение FOPL обозначает логику предикатов первого порядка).

В разделе 8 определены синтаксисы dADL и cADL, синтаксис путей ADL, а также комбинированный синтаксис ADL, архетипы и библиотеки типов данных, специфичных для предметной области.

Рисунок 1 - Структура ADL-архетипа

Пример

Ниже приведен пример простого архетипа. Понятие guitar (гитара) определено в терминах ограничений общей модели понятия INSTRUMENT (инструмент). Имена, указанные в разделе "definition (определение)" (INSTRUMENT, size и т.д.), являются попеременно именами классов и атрибутов из модели объектов. Каждый блок квадратных скобок содержит спецификацию некоторого конкретного набора экземпляров, соответствующих конкретному понятию, например гитара или гриф. Эта спецификация определяется в терминах ограничений типов данных из обобщенной модели классов. Конечные пары квадратных скобок содержат ограничения примитивных типов данных, например, Integer, String и Boolean.

Медицинские примеры архетипов

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

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

http://svn.openehr.org/knowledge/archetypes/dev/index.html

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

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

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

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

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

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

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

      2 Соответствие

Передача архетипа, используемого для ограничения части выписки EHR_EXTRACT, должна соответствовать информационной модели, определенной в разделе 7, а также факультативно может соответствовать спецификации языка определения архетипа ADL, определенной в разделе 8.

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

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

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

ИСО 639 (все части) Коды для представления наименования языков [ISO 639 (all parts), Codes for the representation of names of languages]

ИСО 8601 Элементы данных и форматы обмена. Обмен информацией. Представление дат и времени (ISO 8601, Data elements and interchange formats - Information interchange - Representation of dates and times)

ИСО/МЭК 10646 Информационная технология. Универсальный многооктетный набор кодированных символов (UCS) [ISO/IEC 10646, Information technology - Universal Multiple-Octet Coded Character Set (UCS)]

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

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

4.1 абстрактный класс (abstract class): (в языке UML) "Виртуальный" общий родитель двух или более классов.

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

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

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

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

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

4.6 понятие (concept): Единица знаний, созданная с помощью уникальной комбинации характеристик (определение 3.2.1 из [6]).

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

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

Примечание - Адаптировано из [10], определение 2.11.

4.8 запись электронной медицинской карты (electronic health record entry): Любые данные из медицинской карты.

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

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

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

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

4.12 метаданные (metadata): Данные, определяющие и описывающие другие данные (определение 3.2.18 из [7]).

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

4.14 семантический (semantic): Относящийся к смыслу языковой конструкции.

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

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

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

      5 Сокращения

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

ADL - язык определения архетипов (Archetype Definition Language);

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

OPO - открытая распределенная обработка (Open Distributed Processing, ODP);

OWL - веб-язык онтологии (Ontology Web Language);

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

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

      6 Требования к представлению архетипов

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

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

      6.2 Определение, описание архетипа и информация о его публикации

6.2.1 Определение архетипа должно содержать перечисленную ниже информацию.

6.2.1.1 Глобально уникальный идентификатор определения данного архетипа.

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

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

6.2.1.4 Область информатизации здоровья, в которой применяется данный архетип (например ЭМК). Данная область отображается на множество базовых моделей, с которыми может использоваться данный архетип.

6.2.1.5 Основная базовая модель, для которой данный архетип был идеально приспособлен.

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

6.2.1.6 Естественный язык, на котором данный архетип был первоначально определен, заданный его кодом по ИСО 639. В случае неточного перевода для интерпретации архетипа должно использоваться определение на этом языке.

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

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

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

6.2.2.3 Причина создания новой версии ранее существовавшего архетипа.

6.2.2.4 Идентификатор того архетипа, на который данный архетип был заменен (если таковая замена имела место).

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

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

6.2.3 Набор описаний архетипа должен содержать перечисленную ниже информацию.

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

6.2.3.2 Естественный язык, на котором представлен данный набор описаний, указанный его кодом в стандарте ИСО 639.

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

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

Пример - Клиническая область применения и назначение могут описывать:

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

- список клинических, медицинских или процедурных терминов (ключевых слов): диагнозы, действия, лекарства, исследования и т.д.;

- тип пациента, для которого предназначен архетип (возраст, пол и т.д.).

6.2.4 Набор описаний архетипа может при необходимости содержать представленную ниже информацию.

6.2.4.1 Формальное заявление о цели применения архетипа.

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

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

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

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

6.2.5 Определение архетипа должно содержать формулировку состояния его публикации.

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

6.2.6 Сведения о состоянии публикации архетипа должны включать в себя перечисленную ниже информацию.

6.2.6.1 Состояние публикации архетипа, выбранное из следующего списка:

- тестовый/демонстрационный;

- предварительный;

- черновой;

- для внутренних целей;

- общедоступный;

- предпочтительный;

- отмененный.

6.2.6.2 Дата присвоения данного состояния публикации.

Примечание - Датой первого состояния публикации архетипа будет дата первичного составления документа.

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

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

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

      6.3 Ограничения узлов архетипа

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

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

6.3.2 Ссылки на узлы архетипа

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

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

6.3.2.3 Ссылка на фрагмент архетипа может быть внутренней (т.е. указывать на часть текущего архетипа).

6.3.2.4 Узел архетипа может быть задан как один из совокупности возможных архетипов посредством указания явного списка кандидатов и/или задания набора ограничений конкретных атрибутов определения архетипа.

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

________________

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

6.3.3 Спецификация узла архетипа

6.3.3.1 Спецификация узла архетипа (если он определен не по ссылке) должна содержать перечисленную ниже информацию.

6.3.3.2 Внутренне уникальный идентификатор данного узла архетипа. В сочетании с глобально уникальным идентификатором определения данного архетипа он должен быть глобально уникальной ссылкой на этот узел.

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

- FOLDER (том);

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

- SECTION (раздел);

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

- CLUSTER (кластер);

- ELEMENT (элемент).

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

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

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

6.3.3.6 Правила ограничений могут быть выражены в форме критериев включения или исключения.

6.3.3.7 Любое определение правила ограничения должно идентифицировать формализм (включая версию), в котором оно выражено (например ADL, OWL).

6.3.4 Связь узлов архетипа с терминами

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

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

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

- основное понятие;

- связывание терминов;

- синоним;

- перевод на другой язык.

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

6.3.5 Ограничения атрибутов и ассоциаций

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

Такие ограничения могут заранее задавать или ограничивать некоторую часть или всю контекстную информацию, содержащуюся в данном экземпляре, в соответствии с представлением в базовой модели. Контекстная информация, например лицо, с которым связано конкретное исследование или заключение, формально представлена в большинстве ЭМК-подобных моделей в целях обеспечения реализации безопасных запросов и выборок информации, даже если эта информация может быть определена по имени архетипа или фасету терминологической системы, из которой берутся значения данных. Некоторые архетипы или их фрагменты заранее определяют элементы контекстной информации, которые могут быть включены в определение архетипа (например, чтобы указать в архетипе семейного анамнеза, что субъектом информации является родственник, а не пациент). Применимость любого аспекта контекста к данному узлу архетипа определяется атрибутами контекста соответствующего узла базовой модели целевой ЭМК. Например, в базовой модели, определенной в EN 13606, субъект информации представлен на уровне элемента Entry. Между совокупостями элементов контекстной информации, определенных в разных базовых моделях, существует значительная общность (например между моделями, определенными в EN 13606 и HL7 CDA Release 2). В идеале должен быть принят общий набор меток этих элементов, что позволит применять соответствующие контекстные ограничения к нескольким базовым моделям.

6.3.6 Дополнительная информация

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

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

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

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

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

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

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

6.3.6.8 Ограничения могут быть указаны для значений данных конечных узлов или конечных атрибутов.

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

      6.4 Ограничения значений данных

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

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

6.4.2.1 Разрешено ли данным принимать пустое значение, и дополнительно указать, почему оно пустое (например указать код причины пустого значения).

6.4.2.2 Основано ли ограничение или правило на критерии включения или исключения.

6.4.2.3 Формализм (включая версию), в котором представлено данное ограничение.

6.4.2.4 Предлагаемое фиксированное (предписанное) значение экземпляров, соответствующих определению архетипа.

6.4.2.5 Предлагаемое значение по умолчанию для экземпляров, соответствующих определению архетипа.

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

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

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

- диапазон, в котором значения считаются выходящими за пределы нормы или критичными с клинической точки зрения;

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

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

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

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

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

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

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

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

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

- идентификатор архетипа;

- идентификатор узла архетипа;

- имя атрибута или ассоциации;

- вхождение в иерархию архетипов, например: первое, самое последнее, любое,

-ое упорядоченное по параметру

(

-й элемент множества экземпляров, упорядоченных по параметру

), наибольшее значение, наименьшее значение, один или несколько экземпляров в (определяемом) недавнем интервале времени;

- предлагаемую связь между данным значением указанного экземпляра и ограничиваемым значением, например: то же самое значение; подмножество или подстрока; больше чем, больше или равно, меньше чем, меньше или равно; раньше чем, позже чем и т.д.; если ..., то ...; не должно быть тем же самым.

6.4.8 Для формирования составных правил эти сравнительные ограничения могут быть вложенными и включать логические операторы или операторы над множествами.

      6.5 Профиль по отношению к базовой модели EN 13606-1

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

Таблица 1 - Список разделов и элементов контекста

Таблица 2 - Базовая модель ЕН 13606 - Профиль контекста

      7 Модель архетипов

      7.1 Введение

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

Данная модель представлена с использованием ограниченной формы диаграмм UML, описанной ниже в профиле UML.

7.1.2 Профиль UML

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

Прямоугольники классов обычно содержат три части.

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

Вторая часть, если она присутствует, содержит атрибуты с указанием имени, типа и кратности атрибута. Кратность может также быть уточнена маркером "ordered (упорядоченный)". Имена атрибутов написаны строчными буквами. Имена типов данных атрибутов записаны с первой прописной буквы, остальные строчные, если данный тип является одним из базовых типов, или все прописные, если данный тип представляет собой другой класс.

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

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

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

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

7.1.3 Подробное документирование модели

Порядок документирования - по пакетам, а внутри пакета - по классам.

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

а) атрибуты;

b) атрибуты, унаследованные от ассоциаций;

с) операции;

d) ограничения.

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

7.1.4 Структура пакетов

Рисунок 2 - Структура пакетов

Общая модель архетипа, показанная на рисунках 3 и 4, определяет обобщенное представление архетипов для целей интероперабельности и обмена данными.

      7.2 Обзор

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

Рисунок 3 - Общий вид модели архетипа. Часть 1

Рисунок 4 - Общий вид модели архетипа. Часть 2

Документация, сгенерированная из модели UML

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

7.2.2 Пакет :: am

Внутренние элементы

      7.3 Пакет archetype

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

Рисунок 5 - Пакет archetype

7.3.2 Пакет :: archetype

Внутренние элементы

Пакет: archetype

Класс ARCHETYPE

Основной класс пакета archetype.

Атрибуты

Атрибуты, унаследованные от ассоциаций

Ограничения

      7.4 Пакет archetype_description

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

Рисунок 6 - Пакет archetype_description

7.4.2 Пакет:: archetype_description

"Метаданные" архетипа.

Внутренние элементы

Пакет: archetype_description

Класс AUDIT_DETAILS

Атрибуты

Ограничения

Пакет: archetype_description

Класс ARCHETYPE_DESCRIPTION

Данный класс определяет описательные метаданные архетипа.

Атрибуты

Атрибут, унаследованный от ассоциации

Ограничения

Пакет: archetype_description

Класс ARCHETYPE_DESCRIPTION_ITEM

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

Атрибуты

Ограничения

Пакет: archetype_description

Класс TRANSLATION_DETAILS

Класс, описывающий детали перевода на естественный язык.

Атрибуты

      7.5 Пакет constraint_model

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