ГОСТ ISO/HL7 21731-2013 Информатизация здоровья. HL7, версия 3. Эталонная информационная модель. Выпуск 1.

ГОСТ ISO/HL7 21731-2013

Группа П85

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

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

 HL7, ВЕРСИЯ 3

 Эталонная информационная модель

 Выпуск 1

 Health informatics. HL7 version 3. Reference information model. Release 1

МКС 35.240.80

ОКСТУ 4002      

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

Предисловие

Цели, основные принципы и основной порядок проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0-92 "Межгосударственная система стандартизации. Основные положения" и ГОСТ 1.2-2009 "Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, применения, обновления и отмены"

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

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

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

3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 5 ноября 2013 г. N 61-П)

За принятие проголосовали:

4 Приказом Федерального агентства по техническому регулированию и метрологии от 28 апреля 2014 г. N 422-ст межгосударственный стандарт ГОСТ ISO/HL7 21731-2013 введен в действие в Российской Федерации для применения в качестве национального стандарта с 1 июля 2015 г.

5 Настоящий стандарт идентичен международному стандарту ISO/HL7 21731:2006* Health informatics - HL7 version 3 - Reference information model - Release 1 (Информатизация здоровья. HL7, версия 3. Эталонная информационная модель. Выпуск 1).

Международный стандарт разработан техническим комитетом Международной организации по стандартизации ISO/TC 215 Health informatics (Информатизация здоровья).

Перевод с английского языка (еn).

Официальные экземпляры международного стандарта, на основе которого подготовлен настоящий межгосударственный стандарт, имеются в ФГУП "СТАНДАРТИНФОРМ".

Степень соответствия - идентичная (IDТ)

6 ВВЕДЕН ВПЕРВЫЕ

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

 Предисловие

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

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

Главной задачей технических комитетов является подготовка международных стандартов. Проекты международных стандартов, одобренные техническими комитетами, предлагаются членам комитета для голосования. Публикация документа в качестве международного стандарта требует одобрения по крайней мере 75% членов комитета, принявших участие в голосовании.

Для разработки и сопровождения группы стандартов ISO/HL7 в области медицинских приборов заключено экспериментальное соглашение между ИСО и комитетом Health Level Seven Inc (HL7), одобренное решением Совета 7/2002. В соответствии с этим соглашением на комитет HL7 возлагается ответственность за разработку и сопровождение этих стандартов при участии членов ИСО, представляющих свои предложения.

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

Стандарт ISO/HL7 21731 разработан HL7 и Техническим комитетом ISO/TC 215, Health informatics (Информатизация здоровья).

 Введение

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

Применение ЭИМ в информатизации здоровья

Использование ЭИМ в ИСО ТК 215

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

Использование ЭИМ в комитете HL7

ЭИМ является критичным компонентом процесса развития стандартов HL7 Версии 3. Она положена в основу всех информационных моделей и структур, разрабатываемых в процессе развития Версии 3.

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

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

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

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

Использование ЭИМ вне HL7

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

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

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

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

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

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

Полезная информация

С вопросами или комментариям о содержании стандарта можно обратиться к комитету HL7 (www.hl7.org) или к соответствующему национальному филиалу комитета HL7 либо к Секретариату комитета ИСО ТК 215 "Информатизация здоровья".

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

Эталонная информационная модель (ЭИМ) комитета Health Level Seven (HL7) представляет собой статическую модель информации о здоровье и медицинской помощи в соответствии с областями применения деятельности по развитию стандартов HL7. Она является информационной точкой зрения, согласованной комитетом HL7 и его национальными филиалами. ЭИМ служит основным источником, из которого производится все содержание стандартных спецификаций протокола HL7 Версии 3, связанное с информацией. В контексте деятельности комитета ИСО ТК 215 "Информатизация здоровья" ЭИМ является эталонной моделью, которая может использоваться при разработке других стандартов информатизации здоровья.

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

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

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

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

ISO 17113, Health informatics - Exchange of information between healthcare information systems - Method for development of messages. (ИСО 17113, Информатизация здоровья - Обмен информацией между медицинскими информационными системами - Метод разработки сообщений).

ISO/IEC 19501, Information technology - Open Distributed Processing - Unified Modeling Language (UML) Version 1.4.2 (ИСО/МЭК 19501, Информационные технологии - Открытая распределенная обработка - Унифицированный язык моделирования (UML), Версия 1.4.2.).

ANSI/HL7 V3 DT, R1-2004, HL7 Version 3 Standard: Data Types - Abstract Specification, Release 1 (HL7 Версия 3 - Типы данных - Общая спецификация, выпуск 1).

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

Далее представлены все термины и определения документа.

4.1 ANSI: American National Standards Institute - Американский национальный институт по стандартизации.

4.2 ассоциация (association): Ссылка от одного класса к другому классу или к себе, или связи между двумя объектами (экземплярами классов).

4.3 имя роли ассоциации (association role name): Имя каждого конца ассоциации. Имя - это короткая глагольная фраза, описывающая роль класса, находящегося на противоположном конце ассоциации, по отношению к классу, находящемуся на данном конце ассоциации.

4.4 атрибут: Абстрактное описание составной части класса. При передаче сообщений HL7 атрибуты становятся значениями данных.

4.5 мультимножество (bag): Форма коллекции, элементы которой не упорядочены и не должны быть уникальными.

4.6 кратность (cardinality): Свойство элемента данных (число возможных повторений элемента данных в пределах индивидуального экземпляра представления объекта).

4.7 класс: Абстракция сущности или понятия в специфической прикладной области.

4.8 атрибут классификатора (classifier attribute): Признак, используемый в иерархиях обобщений для указания, какая из специализаций является фокусом класса.

4.9 кодированный атрибут (coded attribute): Атрибут ЭИМ с базовым типом данных CD, СЕ, CS или CV.

4.10 сила кодирования (coding strength): Показатель расширяемости, который определяет, может ли набор кодов быть расширен для учета местных потребностей реализации.

4.11 система кодирования (coding system): Схема представления понятий, использующая (обычно) короткие идентификаторы для обозначения понятий, являющихся элементами системы; определяет совокупность уникальных кодов понятий. Примерами систем кодирования служат МКБ-9, LOINC и SNOMED.

4.12 коллекция (collection): Агрегат подобных объектов. В стандарте HL7 используются следующие формы коллекций: множество (set), мультимножество (bag) и список (list). Объекты, которые могут быть организованы в коллекции, включают типы данных.

4.13 связь (connection): В информационной модели связью является заданное отношение между двумя классами.

4.14 тип данных (data type): Структурный формат данных, передаваемых в атрибуте. Он может ограничивать множество значений, принимаемых атрибутом.

4.15 отдаленный класс (distal class): Применительно к классу в информационной модели, это класс на противоположном конце ассоциации между двумя классами.

4.16 домен (domain): 1. Конкретная предметная область (например, предметной областью стандартов HL7 является здравоохранение). 2. Множество возможных значений типа данных, атрибута, или компонента типа данных. См. также словарный домен.

4.17 событие (event): 1. Воздействие, которое вызывает ощутимое изменение состояния объекта, а также сигнал, воздействующий на поведение объекта. 2. В словарном домене - одно из значений "наклонения" (Mood).

4.18 квалификатор расширяемости (extensibility qualifier): Квалификатор словарного домена, используемый в спецификации домена для указания, может ли существующий словарный домен быть расширен дополнительными значениями. У него два возможных значения: ONE (coded, no extension - кодированный без расширения) и CWE (coded with extension - кодированный с расширением).

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

4.20 иерархия обобщений (generalization hierarchy): Все суперклассы и подклассы с общим корневым суперклассом.

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

4.22 Health Level Seven (HL7): Организация, разрабатывающая стандарты, расположенная в США.

4.23 идентифицирующий атрибут (identifier attribute): Атрибут, используемый для идентификации экземпляра класса.

4.24 информационная модель (information model): Структурированная спецификация требований к информации в предметной области, выраженная графически и/или повествовательно. Информационная модель описывает классы требуемой информации и свойства этих классов, включая атрибуты, отношения и состояния. Примерами в стандартах HL7 служат эталонная информационная модель предметной области (Domain Reference Information Model), ЭИМ, и Уточненная информационная модель сообщений (Refined Message Information Model).

4.25 наследование (inheritance): В отношениях обобщения подкласс наследует все свойства от суперкласса, включая атрибуты, отношения и состояния, если не указано иное.

4.26 экземпляр (instance): Вариант или реализация. Например, объект является экземпляром класса.

4.27 список (list): Форма коллекции, элементы которой упорядочены и не обязаны быть уникальными.

4.28 словесное выражение (literary expression): Текстовое представление модели. Словесное выражение стремится уравновесить потребность в строгом, однозначном описании модели с потребностью в его представлении, которое может быть легко прочитано и интерпретировано людьми, понимающими общие понятия объектно-ориентированных моделей, но, возможно, не обученными формальным языкам определения моделей.

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

4.30 обязательная ассоциация (mandatory association): Ассоциация, минимальная кратность которой на одном конце больше нуля. Полностью обязательная ассоциация имеет ненулевую кратность на каждом конце.

4.31 методология (methodology): Методы или правила, которым надо следовать в конкретной дисциплине.

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

4.33 кратность (multiplicity): В информационной модели кратность - спецификация минимального и максимального числа объектов каждого класса, которые могут участвовать в ассоциации. Кратность определяется для каждого конца ассоциации.

4.34 пространство имен (namespace): Пространство имен - часть модели, в которой определены и используются имена, каждое из которых имеет уникальное значение.

4.35 объект (object): Экземпляр класса. Часть информационной системы, содержащей коллекцию связанных данных (в форме атрибутов) и процедур (методов), предназначенных для обработки этих данных.

4.36 идентичность объекта (object identity): Свойство существования объекта независимо от любых значений, ассоциированных с объектом.

4.37 объектный (object-based): Любой метод, язык или система, поддерживающие идентичность объекта, классификацию и инкапсуляцию. Объектная система не поддерживает специализацию. Ада - пример объектного языка.

4.38 свойство (property): Любой атрибут, ассоциация, метод или модель состояний, определенная для класса или объекта.

4.39 эталонная информационная модель (ЭИМ): Информационная модель HL7, из которой выводятся все другие информационные модели (например, модели R-MIM) и сообщения.

4.40 роль (role): 1. Функция или положение. 2. Класс ЭИМ, который определяет компетенцию класса Entity (сущность). Каждая роль выполняется одним классом Entity (сущность, выполняющая роль) и обычно контролируется другой ролью. 3. В языке UML каждый конец ассоциации обозначается как роль, отражающая функцию класса в ассоциации.

4.41 имя роли (role name): См. имя роли ассоциации.

4.42 множество (set): Форма коллекции, содержащей неупорядоченный список уникальных элементов одного типа.

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

4.44 состояние (state): Именованное состояние экземпляра класса (объекта), которое может быть проверено с помощью анализа атрибутов и ассоциаций этого экземпляра.

4.45 атрибут состояния (state attribute): Атрибут, описывающий текущее состояние объекта.

4.46 диаграмма перехода состояний (state diagram): Графическое представление модели перехода состояний, показывающее состояния как вершины (узлы) и переходы состояния как направленные дуги (стрелки) между узлами.

4.47 машина состояний (state machine): Описание жизненного цикла экземпляров класса, определяемое моделью переходов состояний.

4.48 переход состояния (state transition): Изменение состояния объекта в результате изменения его атрибута или ассоциаций.

4.49 модель переходов состояний (state transition model): Графическое представление жизненного цикла класса. Модель изображает все уместные состояния класса, и действительные переходы в зависимости от состояния.

4.50 подкласс (subclass): Класс, являющийся специализацией другого класса (суперкласса).

4.51 предметная область (subject area): Совокупность классов модели, используемая для деления больших моделей на обозримые подмножества.

4.52 подсостояние (sub-state): Идентифицируемое состояние класса, который имеет более специфичное определение, чем его суперсостояние, и полностью входит в это суперсостояние.

4.53 суперкласс (superclass): Класс, который является обобщением одного или более других классов (подклассов).

4.54 суперсостояние (super-state): Состояние класса, которое охватывает два или более независимых подсостояний.

4.55 унифицированный язык моделирования (UML): Язык для создания моделей предметных областей. Язык UML был создан для объединения нескольких известных объектно-ориентированных методологий моделирования, в том числе Booch, Rumbaugh, Jacobson и другие.

4.56 словарь (vocabulary): Набор допустимых значений кодированного атрибута или поля.

4.57 словарный домен (vocabulary domain): Набор всех понятий, которые могут рассматриваться как допустимые значения кодированного атрибута или поля; ограничение, применяемое к кодированным значениям.

4.58 квалификатор словарного домена (vocabulary domain qualifier): Часть спецификации словарного домена. Двумя существующими квалификаторами являются расширяемость (extensibility) и сфера действия (realm).

4.59 W3C (The World Wide Web Consortium): Консорциум World Wide Web, международный промышленный консорциум.

      5 Интерпретация спецификации

      5.1 Содержание спецификации

ЭИМ состоит из классов, включенных в один или несколько пакетов предметных областей. Атрибуты, отношения и машины состояний связаны с классами.

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

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

- Class.stateAttribute;

- Class.classCode;

- Attribute.mandatorylnclusion;

- Attribute.cardinality;

- Attribute.vocabDomain;

- Attribute.vocabStrength.

      5.2 Понимание ЭИМ

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

5.2.1 ЭИМ как абстрактная модель

ЭИМ содержит 6 "базовых" классов:

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

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

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

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

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

- класс RoleLink (связь ролей), представляющий отношения между отдельными ролями.

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

- classCode (в классах Act, Entity и Role), уточняющий назначение класса или соответствующего ему понятия независимо от того, представлен ли он как класс в иерархии ЭИМ;

- moodCode (в классе Act) и determinerCode (в классе Entity), с помощью которых можно указать, представляет ли класс экземпляр или разновидность класса Act или Entity. Если класс является специализацией класса Act, то атрибут moodCode позволяет указать, описывает ли экземпляр класса Act свершившееся или планируемое действие;

- code (в классах Act, Entity и Role), обеспечивающий более детальную классификацию значения атрибута classCode, например, конкретный вид исследования в классе Observation (исследование).

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

5.2.2 Представление структуры класса ЭИМ

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

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

5.2.3 Представление контролируемого словаря

Несколько атрибутов в ЭИМ имеют тип данных CS. Это означает, что множество значений такого атрибута должно быть выбрано из множества кодов, определенных в стандарте HL7. Упомянутые ранее атрибуты classCode и typeCode являются примерами атрибутов с типом данных CS.

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

5.2.4 Связанные спецификации

Как отмечено ранее, каждому атрибуту в ЭИМ присвоен тип данных. Формальная спецификация этих типов данных зависит от того, используется ли настоящая модель комитетом HL7 или комитетом ИСО ТК 215. При использовании комитетом HL7 нормативной спецификацией типов данных служит документ "HL7 Data Types Abstract Specification" (Абстрактная спецификация типов данных HL7). При использовании комитетом ИСО ТК 215 документы, специфицирующие релевантные типы данных, имеют обозначение ИСО 22??хх??. Справочная таблица свойств релевантных типов данных включена в Приложение В.

      5.3 Графические диаграммы нормативного содержания ЭИМ

Классы, включенные в нормативное содержание ЭИМ, представлены на рисунках 1-4.

Рисунок 1 - Диаграмма классов всех предметных областей

Рисунок 2 - Диаграмма классов предметной области Acts (действия)

Рисунок 3 - Диаграмма классов предметной области Entities (сущности)

Рисунок 4 - Диаграмма классов предметной области Roles (роли)

Рисунок 5 - Диаграмма перехода состояний класса Act (действие)

Рисунок 6 - Диаграмма перехода состояний класса Entity (сущность)

Рисунок 7 - Диаграмма перехода состояний класса ManagedParticipation (управляемое участие)

Рисунок 8 - Диаграмма перехода состояний класса Role (роль)

      6 Предметные области ЭИМ HL7

      6.1 Предметная область FoundationClasses

Эта совокупность классов и их ассоциаций представляет нормативное содержание HL7 ЭИМ. Содержание данной предметной области утверждается в комитете HL7 как нормативный документ.

Диаграмма классов этой предметной области показана на рисунке 5.3.

Предметная область FoundationClasses содержит следующие предметные области:

- Acts (действия)

- Entities (сущности)

- Roles (роли)

6.1.1 Предметная область Acts (в предметной области FoundationClasses)

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

Диаграмма классов этой предметной области показана на рисунке 2.

Предметная область Acts содержит следующие классы:

- Account (счет);

- Act (действие);

- ActRelationship (связь действий);

- ControlAct (управляющее действие);

- DeviceTask (функция устройства);

- Diagnosticlmage (диагностическое изображение);

-Diet (диета);

- Exposure (воздействие);

- FinancialContract (контракт);

- FinancialTransaction (финансовая операция);

- InvoiceElement (элемент счета-фактуры);

- ManagedParticipation (управляемое участие);

- Observation (исследование);

- Participation (участие);

- Procedure (процедура);

- PublicHealthCase (событие общественного здоровья);

- SubstanceAdministration (лекарственное назначение);

- Supply (предоставление материала);

- WorkingList (рабочий лист).

6.1.2 Предметная область Entities (в предметной области FoundationClasses)

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

Диаграмма классов этой предметной области показана на рисунке 3.

Предметная область Entities содержит следующие классы:

- Container (контейнер);

- Device (устройство);

- Entity (сущность);

- LanguageCommunication (вербальное общение);

- LivingSubject (живой организм);

- ManufacturedMaterial (изготовленный материал);

- Material (материал);

- NonPersonLivingSubject (нечеловеческое живое существо);

- Organization (организация);

- Person (лицо);

- Place (место).

6.1.3 Предметная область Roles (в предметной области FoundationClasses)

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

Диаграмма классов этой предметной области показана на рисунке 4.

Предметная область Roles содержит следующие классы:

- Access (доступ);

- Employee (работник);

- LicensedEntity (лицензированный субъект);

- Patient (пациент);

- Role (роль);

- RoleLink (связь роли).

      7 Классы ЭИМ HL7

Далее перечислены все классы ЭИМ. Порядок сортировки основан на следующих трех критериях:

- нормативное содержание;

- имя основной предметной области (в алфавитном порядке);

- имя класса (в алфавитном порядке).

      7.1 Классы предметной области Acts

7.1.1 Класс Act (в предметной области Acts)

Код класса: ACT.

Атрибуты класса Act:

- classCode:: CS

- moodCode:: CS

- id:: SET<II>

- code:: CD

- negationlnd:: BL

- derivationExpr:: ST

- title:: ED

- text:: ED

- statusCode:: CS

- effectiveTime:: GTS

- activityTime:: GTS

- availabilityTime:: TS

- priorityCode:: SET<CE>

- confidentialityCode:: SET<CE>

- repeatNumber:: IVL<INT>

- interruptiblelnd:: BL

- levelCode:: CE

- independentlnd:: BL

- uncertaintyCode:: CE

- reasonCode:: SET<CE>

- languageCode:: CE

Ассоциации класса Act:

- outboundRelationship::(0..*) ActRelationship::source::(1..1) (ассоциация с классом ActRelationship, роль source - источник);

- inboundRelationship::(0..*) ActRelationship::target::(1..1) (ассоциация с классом ActRelationship, роль target - цель);

- participation::^..*) Participation::act::(1..1) (ассоциация с классом Participation, роль act - действие).

Класс Act является обобщением следующих классов:

- Account (счет);

- ActRelationship (связь действий);

- ControlAct (управляющее действие);

- DeviceTask (функция устройства);

- Diagnosticlmage (диагностическое изображение);

- Diet (диета);

- Exposure (воздействие);

- FinancialContract (контракт);

- FinancialTransaction (финансовая транзакция);

- InvoiceElement (элемент счета);

- ManagedParticipation (управляемое участие);

- Observation (исследование);

- Participation (участие);

- Procedure (процедура);

- PublicHealthCase (событие общественного здоровья);

- SubstanceAdministration (лекарственное назначение);

- Supply (предоставление материала);

- WorkingList (рабочий лист).

Определение класса Act: запись о чем-то, что делается, что было сделано, что может быть сделано, что планируется или что требуется сделать.

Примеры: видами действий, типичными для здравоохранения, являются:

- клиническое исследование;

- оценка состояния здоровья (например, жалобы и диагнозы);

- цели медицинской помощи;

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

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

- санитарное просвещение пациентов и их близких лиц;

- услуги нотариуса (например, упреждающие указания или отказ от искусственного поддержания жизни);

- редактирование и обработка документов, и т.д.

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

Соединение классов действий Act с классами сущностей Entity осуществляется с помощью классов участия Participation и ролей Role. Соединение одного класса действий Act с другим классом Act осуществляется с помощью класса связи действий ActRelationship. Классы участия Participation представляют авторов, исполнителей и другие ответственные стороны, а также субъектов и бенефициариев (в том числе инструменты и материал, используемые при выполнении действия, которые также являются субъектами). Использование атрибута moodCode позволяет различить фактически выполненные действия, запланированные и затребованные действия, а также другие варианты определенности действия.

Каждый класс действия Act имеет (в крайнем случае, косвенно) связь с одним из классов Participation, представляющим основного автора, ответственного за выполнения действия и "владеющего" действием. Ответственность за действие означает ответственность за то, что оно означает, и как это записано. А владелец действия имеет право его изменить в рабочем порядке. Ответственность за действие и владение действием, представленным классом Act, не идентичны ответственности и владению по отношению к тому, что соответствует экземпляру этого класса в реальном мире. Одна и та же деятельность, происходящая в реальном мире, может быть описана с точки зрения двух людей, каждый из которых является автором своего экземпляра класса Act, содержащего такое описание. Но один из этих людей может быть свидетелем деятельности, а другой - ее основным исполнителем. Исполнитель несет ответственность за физические действия; свидетель отвечает только за достоверное описание этих действий в силу своих способностей. Эти два экземпляра класса Act могут даже не быть согласованы между собой, но поскольку у каждого из них есть свой автор, такие разногласия могут сосуществовать и рассматриваться получателем этих экземпляров класса Act.

В этом отношении экземпляр класса Act представляет собой "утверждение" в терминах Rector и Nowlan (1991) [Foundations for an electronic medical record. Methods Inf Med. 30]. Rector и Nowlan подчеркнули важность понимания медицинской карты не как собрания фактов, а как "достоверного отчета о том, что слышали, видели, думали и делали медицинские работники". Rector и Nowlan продолжают эту мысль, заявляя, что "другие требования, предъявляемые к ведению медицинской карты, например, что она должна иметь определенную принадлежность и обладать свойством постоянства, естественно вытекают из этой точки зрения". Действительно, класс Act как раз и представляет собой такое "утверждение", содержащее атрибуты, и правила обновления экземпляров класса Act (обсуждаемые в модели перехода состояний, см. атрибут Act.statusCode), применяемые вместо создания новых экземпляров этого класса, разработаны в соответствии с принципом постоянства и принадлежности.

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

Понятие речевого акта означает, что речевое выражение, кроме изложения факта, имеет определенное прагматическое значение, и что в реальном мире речевые выражения используются для изменения состояния дел, в том числе, чтобы непосредственно инициировать физическую деятельность. Например, заказ исследования представляет собой речевой акт, который (при условии, что оно адекватно) вызывает физическое выполнение заказанного действия. Кульминацией теории речевых актов является плодотворная работа Austin (1962) [How to do things with words. Oxford University Press].

В реальном мире отдельная деятельность может развиваться от ее формулировки до выполнения, проходя этапы планирования и указаний. Отражение этих этапов находит свое представление с помощью атрибута moodCode класса Act. Хотя такую деятельность и можно рассматривать в развитии от плана до выполнения, это развитие должно представляться в форме нескольких экземпляров класса Act, каждый из которых имеет ровно одно значение атрибута moodCode, которое не меняется в течение всего срока жизни этого экземпляра. Это связано с тем, что принадлежность и содержание речевых актов в процессе деятельности могут быть различными, и нередко очень важно вести достоверную и постоянно хранящуюся регистрацию этого процесса. Спецификация указаний, обещаний или планов не должна заменяться на спецификацию того, что было выполнено на самом деле, чтобы иметь возможность сравнить результат с более ранними спецификациями. Экземпляры класса Act, являющиеся отражением развития одной деятельности, должны быть связаны между собой с помощью экземпляров класса ActRelationship, у которых атрибут typeCode имеет значение SEQL (продолжение).

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

В следующих подпунктах описаны атрибуты класса Act.

7.1.1.1 Act.classCode:: CS (1..1) Mandatory

Словарный домен: ActClass (CNE)

Определение: Код, устанавливающий главный тип класса Act, представляющий данный экземпляр этого класса.

Ограничения: домен classCode представляет собой строго контролируемый словарь, который не может быть внешним или пользовательским.

Каждый экземпляр класса Act должен иметь атрибут classCode. Если этот класс не специализирован, то атрибут Act.classCode должен иметь наиболее общее значение (ACT).

Значение атрибута Act.classCode должно быть обобщением определенного понятия (например, заданного значением атрибута Act.code), другими словами, понятия, моделируемые классом Act и передаваемые в его экземпляре, должны быть специализациями класса понятий, заданного значением атрибута Act.classCode. В частности, атрибут classCode не является "модификатором" атрибута кода класса Act.code. (Для сравнения см. описание атрибута Act.code).

7.1.1.2 Act.moodCode:: CS (1..1) Mandatory

Словарный домен: ActMood (CNE)

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

Ограничение: Экземпляр класса Act должен иметь одно и только одно значение атрибута moodCode.

Значение атрибута moodCode конкретного экземпляра класса Act никогда не изменяется. Стадия деятельности, характеризуемая этим атрибутом, не является состоянием объекта.

Чтобы описать развитие конкретной деятельности от ее плана до выполнения, необходимо создать несколько экземпляров классов Act, имеющих разные значения атрибута moodCode, и связать их между собой с помощью экземпляров класса ActRelationship, у которых атрибут typeCode имеет значение SEQL (продолжение).

Обсуждение: Значение атрибута Act.moodCode описывает следующие понятия: (1) событие, т.е. фактическое описание произошедших действий; (2) определение возможных действий и планов действия (на уровне нормативно-справочного файла); (3) намерение, т.е. план действий, который для пациента выражен в форме плана лечения или направления; (4) цель, т.е. желательный результат медицинской помощи пациенту; (4) задача, т.е. желаемый результат, приложенный к проблемам пациента и планам; и (5) критерий, т.е. предикат, используемый для вычисления логического выражения.

Значение атрибута Act.moodCode контролируемым образом изменяет смысл класса Act подобно тому, как в естественном языке грамматическая форма глагола определенным образом изменяет смысл предложения. Например, если значение атрибута Act.moodCode является признаком фактического события, то весь экземпляр класса Act представляет известный факт. Если оно является признаком плана (намерения), то весь экземпляр класса Act представляет описание того, что должно быть сделано. Значение атрибута Act.moodCode не меняет каким-либо особым способом конкретные свойства класса Act.

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

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

Классы Act имеют два типа свойств действий - инертные и описательные. Смысл инертных свойств не зависит от значения атрибута Act.moodCode, а интерпретация описательных свойств зависит. Например, у класса Act есть атрибут Act.id, который обеспечивает уникальную идентификацию экземпляра этого класса. Уникальная идентификация объекта никоим образом не зависит от значения атрибута Act.moodCode. Поэтому "интерпретация" идентификатора Act.id является инертной по отношению к атрибуту Act.moodCode.

Напротив, большинство из других атрибутов класса Act является описательным по отношению к утверждению, передаваемому в форме экземпляра класса Act. Эти атрибуты дают ответы на вопросы, кто выполнил действие, для кого, где, что использовал, как и когда было выполнено это действие. Ответы на вопросы, кто, для кого, где, что использовал, передаются в описательных атрибутах классов Paricipation, а ответы на вопросы, как и когда - в описательных атрибутах и экземплярах классов ActRelationship.

Для иллюстрации влияния атрибута moodCode ниже рассмотрены экземпляры класса Act, относящиеся к процессу определения сахара крови.

Экземпляр специализации класса Act, у которого атрибут moodCode имеет значение DEF (definition - описание), содержит справочное описание процесса "определение сахара крови". Связанные с ним экземпляры классов Participation содержат характеристики субъектов, которые должны участвовать в этом процессе, и требуемых для него объектов, например, биоматериал, подразделение, лабораторное оборудование и т.д. Значение атрибута Observation.value указывает абсолютный диапазон значений (домен) результата анализа (например, "15-500 мг/дл").

Если атрибут moodCode имеет значение INT (intent - намерение), это означает, что автор, указанный в экземпляре класса, намерен назначить анализ концентрации сахара в крови ("надо определить сахар крови"). Связанные с ним экземпляры классов Participation содержат информацию о тех субъектах и объектах, которые фактически или предположительно участвуют в этом назначении, в первую очередь об авторе намерения или о любом отдельном лице при групповом намерении, а также о передаваемом биоматериале, о требованиях к лабораторному оборудованию и т.д. Атрибут Observation.value в этом случае обычно отсутствует, поскольку речь идет о намерении провести анализ концентрации сахара, а не измерить концентрацию сахара в указанном диапазоне значений. (Иная ситуация будет, если атрибут moodCode имеет значение GOL.)

Экземпляр специализации класса Act, у которого атрибут moodCode имеет значение RQO (request - требование, что можно рассматривать как разновидность намерения), содержит направление на анализ концентрации сахара в крови ("определите сахар крови"). Связанные с ним экземпляры классов Participation содержат информацию о субъектах и объектах, которые фактически или предположительно должны участвовать в процессе выполнения анализа, в первую очередь о заказчике анализа и о выбранном исполнителе, а также о передаваемом биоматериале, о требованиях к лабораторному оборудованию и т.д. Атрибут Observation.value в этом случае обычно отсутствует, поскольку речь идет о намерении провести анализ концентрации сахара, а не измерить концентрацию сахара в указанном диапазоне значений.

Экземпляр специализации класса Act, у которого атрибут moodCode имеет значение EVN (event - событие), содержит результат определения сахара крови ("сахар крови определен"). Связанные с ним экземпляры классов Participation содержат информацию о субъектах и объектах, фактически участвовавших в процессе определения (включая биоматериал, подразделение, лабораторное оборудование). Атрибут Observation.value содержит измеренное значение (например, "80 мг/дл" или "<15 мг/дл").

Если атрибут moodCode имеет значение EVN.CRT (event-criterion - критерий события), это означает, что автор, указанный в экземпляре класса, рассматривает некоторый класс процессов "определения сахара крови", возможно, с определенным критерием оценки (диапазоном). Связанные с ним экземпляры классов Participation содержат критерий, применяемый, например, к пациенту. Атрибут Observation.value содержит диапазон значений критерия (например, ">180 мг/дл" или "200-300 мг/дл").

Экземпляр специализации класса Act, у которого атрибут moodCode имеет значение GOL (goal - цель, что можно рассматривать как разновидность критерия), содержит информацию о цели, которую требуется достичь ("целью является определенный уровень (диапазон) концентрации сахара в крови"). Связанные с ним экземпляры классов Participation содержат информацию, близкую к той, что была указана в намерении определения сахара крови, в первую очередь сведения об авторе цели и о пациенте, по отношению к которому эта цель поставлена. Атрибут Observation.value содержит целевой диапазон значений (например, "80-120 мг/дл").

Объяснение: смысл атрибута moodCode заимствован от наклонения глагола в грамматике естественного языка (лат. modus verbi).

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

7.1.1.3 Act.id:: SET<II> (0..*)

Определение: уникальный идентификатор экземпляра класса Act.

7.1.1.4 Act.code:: CD (0..1)

Словарный домен: ActCode (СWE)

Определение: код, указывающий конкретный вид действия, представленного экземпляром класса Act.

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

Концептуально значение атрибута Act.code должно быть специализацией значения атрибута Act.classCode. Поэтому структура словарного домена ActClass должна найти свое отражение на верхнем уровне структуры словарного домена ActCode и отдельные коды или внешние словари должны быть подчинены структуре словарного домена ActClass.

Атрибуты Act.classCode и Act.code не являются модификаторами друг для друга, однако понятие, передаваемое в атрибуте Act.code, должно логически вытекать из понятия, передаваемого в атрибуте Act.classCode. Негативным примером служит использование атрибута Act.code для передачи понятия "калий" одновременно в экземпляре класса Observation, у которого атрибут Act.classCode имеет значение SPCOBS (specimen observation - лабораторное исследование биоматериала), чтобы он означал "лабораторное исследование содержания калия", и в экземпляре класса Medication, у которого атрибут Act.classCode имеет значение SBADM (substance administration - лекарственное назначение), чтобы он означал "замещение калия". Такое взаимное изменяющее использование сочетаний атрибутов Act.classCode и Act.code не допускается.

Обсуждение: атрибут Act.code не является обязательным в классе Act. Вместо конкретизации вида действия с помощью атрибута Act.code можно воспользоваться атрибутом Act.classCode и другими свойствами класса Act. Более общий и чаще встречающийся прием состоит в задании вида действия с помощью экземпляра класса Act, в котором атрибут Act.moodCode имеет значение DEF, связанного с другим экземпляром класса Act с помощью экземпляра класса ActRelationship. Вид действия без труда можно указать и без такой привязки к его определению, используя другие атрибуты, а также классы ActRelationship и Participation. Например, вид лекарственного назначения, передаваемого в экземпляре класса SubstanceAdministarion, можно указать с помощью ассоциации ActRelationship с экземпляром класса Entity, содержащим информацию о конкретном лекарстве.

7.1.1.5 Act.negationlnd:: BL (0..1)

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

Примеры: использование этого индикатора в экземпляре класса Observation, у которого атрибут Act.moodCode имеет значение EVN (событие), позволяет передать утверждение "у пациента НЕТ боли в груди". А в экземпляре класса Observation, у которого атрибут Act.moodCode имеет значение EVN.CRT (критерий), использование идентификатора отрицания позволяет передавать критерии выполнения действия вида "если у пациента НЕТ боли в груди в течение 3 дней...", или "если систолическое давление НЕ находится в пределах 90-100 мм рт. т...".

Обсуждение: атрибут negationlnd используется как отрицание квантора существования. Его смысл лучше всего объяснять для экземпляров класса Act, у которых атрибут Act.moodCode имеет значение EVN.CRT (критерий). Если критерий используется без индикатора отрицания, то обычно в экземпляре класса Act надо передать только несколько тех критичных атрибутов и связей (параметров), которые нужны для проверки критерия. Чем больше параметров указано, тем более специфичным (ограниченным) будет критерий. Например, для задания критерия "систолическое давление находится в пределах 90-100 мм рт.ст." в экземпляре класса Observation достаточно указать описательные атрибуты Act.code, указывающий "измерение кровяного давления", и Observation.value, указывающий диапазон значений "90-100 мм рт.ст.". Если будет указан еще и атрибут effectiveTime, скажем, со значением "вчера", то критерий станет более узким. Если при таком критерия атрибут negationlnd будет иметь значение TRUE (истина), то критерий приобретет следующий смысл: "не существует вчерашнего значения систолического кровяного давления в диапазоне 90-100 мм рт.ст." (вне зависимости от того, измерялось вчера кровяное давление или нет).

Значение атрибута negationlnd воздействует указанным ранее образом на описательные атрибуты класса Act (включая Act.code, Act.effectiveTime, Observation.value, Act.doseQty, и т.д.), и на любые его компоненты. Инертные свойства, например, Act.id, Act.moodCode, Act.confidentialityCode, и особенно ассоциация с классом Participation, имеющая роль автора, остаются неизменными. Эти инертные свойства всегда имеют одно и тоже значение: т.е., автор остается и автором отрицательного исследования. Кроме того, атрибут negationlnd не воздействует и на большинство связей ActRelationship (за исключением компонентов).

Например, крайне конфиденциальное указание, записанное д-ром Джонсом в форме "не применять сукцинилхолин" в связи (класс ActRelationship) с имевшейся злокачественной гипертермией (класс Observation), является отрицанием положительного указания "применить сукцинилхолин" (атрибут Act.code), но тем не менее остается указанием, написанным д-ром Джонсом для пациента Джона Смита, и причина этого указания - имевшаяся у пациента злокачественная гипертермия.

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

Экземпляр класса Act, у которого атрибут negationlnd имеет значение TRUE, тем не менее, остается утверждением об определенном факте, описанном в этом экземпляре. Например, отрицание утверждения "1 июля выявлена одышка" означает, что его автор определенно отрицает, что 1 июля была одышка, и что он несет ту же самую ответственность за это утверждение и те же самые требования к его доказательству, как если бы он не использовал отрицание. И наоборот, признак отрицания, переданный в атрибуте negationlnd, никоим образом не отрицает того, что факт был подтвержден или что утверждение имело место. Это равным образом относится ко всем наклонениям утверждения, задаваемым атрибутом moodCode, например, применение отрицания к направлению является указанием не делать того, что в нем написано, а вовсе не лапидарное утверждение, что такого направления нет.

7.1.1.6 Act.derivationExpr:: ST (0..1)

Определение: строка символов, содержащая выражение на формальном языке, которое указывает, каким образом значения атрибутов экземпляра класса Act выводятся из входных параметров, связанных с этим экземпляром отношениями "произведен из".

Обсуждение: производный результат исследования, передаваемый в экземпляре класса Observation, может быть определен с помощью ассоциаций ActRelationship, у которых атрибут typeCode имеет значение DRIV (is derived from - произведен из) и которые связывают данный экземпляр с другими экземплярами класса Observation. Например, для определения производного исследования "среднее содержание гемоглобина в эритроците" (МСН) надо связать исследование МСН с исследованием концентрации гемоглобина (Нb) и абсолютным содержанием эритроцитов (RBC). В этом случае производное выражение должно задаваться формулой МСН = Hb / RBC.

Производное выражение представляется в виде строки символов.

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

7.1.1.7 Act.text:: ED (0..1)

Определение: текстовое или мультимедийное описание действия.

Примеры: в экземпляре класса Act, у которого атрибут moodCode имеет значение DEF (определение), атрибут Act.text может содержать справочную информацию о действии. В экземпляре класса Act, у которого атрибут moodCode имеет значение RQO (направление), атрибут Act.text будет содержать специфические инструкции, применяемые только к этому направлению.

Ограничения: никаких ограничений ни на содержание описания, ни на его длину не накладывается.

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

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

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

7.1.1.8 Act.statusCode:: CS (0..1)

Словарный домен: ActStatus (CNE)

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

7.1.1.9 Act.effectiveTime:: GTS (0..1)

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

Примеры: для клинических исследований атрибут effectiveTime содержит время проведения исследования (эффективное время) пациента.

Для контрактов атрибут effectiveTime указывает срок действия контракта.

Для информированных согласий атрибут effectiveTime указывает срок действия согласия.

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

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

Для действий транспортировки атрибут effectiveTime указывает время в пути.

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

Обсуждение: понятие "эффективного времени" называется также "основным" временем (в стандарте Arden Syntax) или "биологически значимым временем" (в стандарте HL7 v2.x). Этот атрибут надо отличать от атрибута activityTime, описывающего время деятельности.

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

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

Например, время, необходимое для приезда на место погрузки А и последующего возвращения на свою автобазу из пункта разгрузки Б, включается в физическую деятельность, но не включается во время транспортировки полезного груза. Другой пример: рабочие часы, считающиеся эффективным временем, могут быть с 8 часов утра до 5 часов вечера независимо от того, тратит ли человек на дорогу 10 минут или 2 часа. Приход на работу необходим, но на рабочие часы не влияет.

7.1.1.10 Act.activityTime:: GTS (0..1)

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

Обсуждение: см. также описание атрибута effectiveTime. Атрибут activityTime содержит полное время деятельности, в том числе время, затрачиваемое на ее подготовку и на необходимые действия после ее завершения, если таковые считаются релевантными для основной деятельности. Следовательно, промежуток времени, передаваемый в атрибуте activityTime, может быть более долгим по сравнению со значением атрибута effectiveTime того же самого экземпляра класса Act либо совсем отличаться от него. Например, при ретроспективных исследованиях время деятельности намного позже эффективного времени.

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

7.1.1.11 Act.availabilityTime:: TS (0..1)

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

Примеры: в экземпляре класса Act может передаваться информация о том, что 3 часа назад у пациента произошел инфаркт миокарда правого желудочка (см. описание атрибута Act.effectiveTime), но информация об этом необычном случае поступила только несколько минут назад (значение атрибута Act.availabilityTime). Соответственно, с момента Act.effectiveTime до момента Act.availabilityTime любые вмешательства, скорее всего, предпринимались, исходя из предположения о более распространенном инфаркте миокарда левого желудочка. Новое знание может объяснить, почему эти вмешательства (например, назначение нитрата) могли оказаться не подходящими.

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

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

7.1.1.12 Act.priorityCode:: SET<CE> (0..*)

Словарный домен: ActPriority (CWE)

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

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

7.1.1.13 Act.confidentialityCode:: SET<CE> (0..*)

Словарный домен: Confidentiality (CWE)

Определение: Код, контролирующий раскрытие информации о данном действии независимо от значения атрибута moodCode.

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

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

7.1.1.14 Act.repeatNumber:: IVL<INT> (0..1)

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

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

Обсуждение: этот атрибут принадлежит к совокупности атрибутов управления рабочим процессом.

Число повторений дополнительно ограничивается временем. Действие будет повторяться, по меньшей мере, минимальное число раз и, самое большее, максимальное число раз. Повторения также закончатся, если время превысит максимальное значение атрибута Act.effectiveTime, если это случится раньше.

7.1.1.15 Act.interruptiblelnd:: BL (0..1)

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

Обсуждение: этот атрибут принадлежит к совокупности атрибутов управления рабочим процессом. Активные действия могут быть прерваны разными способами. Различаются следующие события прерывания: (1) когда получено прямое требование прекращения действия; (2) когда истекло время, выделенное для выполнения этого действия (тайм-аут); (3) когда "условие" выполнения действия перестает быть истинным (см. описание атрибута ActRelationship.checkpointCode); (4) когда экземпляр класса Act является компонентом, у которого атрибут joinCode имеет значение К (kill - прекращение) и все другие компоненты этой же группы завершены (см. описание атрибута Act.joinCode), и (5) когда прерывается объемлющий экземпляр класса Act.

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

7.1.1.16 Act.levelCode:: СЕ (0..1)

Словарный домен: ActContextLevel (CWE)

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

Обсуждение: Читатели должны иметь в виду, что этот признак может быть объявлен "устаревающим" в следующем нормативном выпуске HL7 ЭИМ. Вместо него рассматривается альтернативное понятие уровня, использующее иерархию значений атрибута classCode. Если это изменение будет принято, то согласно процедурам сопровождения модели HL7 ЭИМ атрибут levelCode будет объявлен "устаревающим" в следующем выпуске ЭИМ, а затем "устаревшим" в выпуске после этого. Прежде чем использовать этот атрибут, пользователям рекомендуется проверить самые последние внутренние определения ЭИМ.

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

Примеры: экземпляры класса Act, находящиеся на "уровне выписки из медицинской карты" (значение атрибута Act.levelCode равно "EXTRACT") и "уровне папки" (значение атрибута Act.levelCode равно "FOLDER") должны содержать данные о единственном лице, в то время как на "уровне нескольких субъектов" эти экземпляры могут содержать данные более чем об одном лице. В то время как "выписка из медицинской карты" может быть сделана из нескольких источников, "папка" должна содержать данные из одного источника. Уровень "композиции" (значение атрибута Act.levelCode равно "COMPOSITION") обычно имеет единственного автора.

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

7.1.1.17 Act.independentlnd:: BL (0..1)

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

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

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

7.1.1.18 Act.uncertaintyCode:: СЕ (0..1)

Словарный домен: ActUncertainty (CNE)

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

Примеры: пациенту могли в прошлом сделать операцию по холецистэктомии (однако он в этом не уверен).

Ограничения: отсутствие точности, объявленное с помощью этого атрибута, относится к объединенному смыслу утверждения, передаваемого в экземпляре класса Act с помощью всех описательных атрибутов (например, Act.code, Act.effectiveTime, Observation.value, SubstanceAdministration.doseQuantity и т.д.), и к смыслу всех компонентов.

Обсуждение: этот атрибут не предназначен для замены или конкуренции с отсутствием точности значения атрибута Observation.value или других отдельных атрибутов класса. Такие точечные указания отсутствия точности должны быть определены с помощью расширения типов данных PPD, UVP или UVN, применяемых к конкретному атрибуту. В частности, если отсутствие точности относится к значению количественного измерения, то его надо указать с помощью присваивания этому значению типа данных PPD<PQ>, а не с помощью атрибута uncertaintyCode. Если, к примеру, дифференциальные диагнозы перенумерованы или им присвоены вероятностные веса, то надо использовать типы данных UVP<CD> или UVN<CD>, а не атрибут uncertaintyCode. Использование атрибута uncertaintyCode возможно только в том случае, если точность всего действия и зависящих от него действий подвергаются сомнению.

Можно было бы подумать, что если точность совсем уж мала, то вместо атрибута uncertaintyCode надо воспользоваться атрибутом отрицания negationlnd, однако эти два понятия совершенно независимы. Можно быть очень неуверенным в том, что событие имело место, но это не означает уверенности в его отрицании.

7.1.1.19 Act.reasonCode:: SET<CE> (0..*)

Словарный домен: ActReason (CWE)

Определение: код, указывающий мотивацию, причину, или логическое обоснование действия, если такое обоснование не было представлено с помощью ассоциации ActRelationship, у которой атрибут typeCode имеет значение RSON (has reason - имеет причину) и которая связывает данное действие с другим.

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

Обсуждение: большинство причин действий могут быть четко описаны с помощью связывания нового действие с предшествующим, использующего ассоциацию ActRelationship, у которой атрибут typeCode имеет значение RSON. Такая связь означает, что предшествующее действие служит причиной для нового (см. описание класса ActRelationship). Это предшествующее действие может быть специфичным существующим действием или текстовым разъяснением. Такой подход пригоден для большинства случаев, и чем более специфична причина, тем более надо использовать ассоциацию ActRelationship, а не атрибут reasonCode.

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

7.1.1.20 Act.languageCode:: СЕ (0..1)

Словарный домен: HumanLanguage (CWE)

Определение: основной язык, на котором описано данное действие, в особенности язык значения атрибута Act.text.

Переходы состояний экземпляра класса Act

Диаграмма перехода состояний класса Act показана на рисунке 5. Действие может иметь следующие состояния:

- aborted (прервано) - подсостояние состояния normal: активный объект услуги был неожиданно завершен;

- active (активно) - подсостояние состояния normal: объект услуги активен;

- cancelled (отменено) - подсостояние состояния normal: объект услуги был отменен до того, как стал активным;

- completed (завершено) - подсостояние состояния normal: объект услуги завершен;

- held (отложено) - подсостояние состояния normal: объект услуги, все еще находящийся на подготовительной стадии. Он не может стать активным, пока не будет выведен из этого состояния;

- new (новое) - подсостояние состояния normal: объект услуги, который готовится стать активным;

- normal (нормальное): охватывает все ожидаемые состояния объекта услуги, за исключением nullified и obsolete, которые представляют необычные терминальные состояния жизненного цикла;

- nullified (аннулировано): объект услуги не должен был создаваться, поэтому он аннулирован;

- obsolete (устарело): объект услуги заменен новым объектом;

- suspended (приостановлено) - подсостояние состояния normal: объект активной услуги временно приостановлен.

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

- abort (прервать) - из состояния active в состояние aborted;

- revise (пересмотреть) - из состояния active в состояние active;

- complete (завершить) - из состояния active в состояние completed;

- suspend (приостановить) - из состояния active в состояние suspended;

- reactivate (активировать заново) - из состояния completed в состояние active;

- revise (пересмотреть) - из состояния completed в состояние completed;

- cancel (отменить) - из состояния held в состояние cancelled;

- revise (пересмотреть) - из состояния held в состояние held;

- release (освободить) - из состояния held в состояние new;

- activate (активировать) - из состояния new в состояние active;

- cancel (отменить) - из состояния new в состояние cancelled;

- complete (завершить) - из состояния new в состояние completed;

- hold (задержать) - из состояния new в состояние held;

- revise (пересмотреть) - из состояния new в состояние new;

- nullify (аннулировать) - из состояния normal в состояние nullified;

- obsolete (сделать устаревшим) - из состояния normal в состояние obsolete;

- activate (активировать) - из начального (пустого) состояния в состояние active;

- complete (завершить) - из начального (пустого) состояния в состояние completed;

- create (создать) - из начального (пустого) состояния в состояние new;

- jump (перейти) - из начального (пустого) состояния в состояние normal;

- abort (прервать) - из состояния suspended в состояние aborted;

- resume (возобновить) - из состояния suspended в состояние active;

- complete (завершить) - из состояния suspended в состояние completed;

- revise (пересмотреть) - из состояния suspended в состояние suspended.

7.1.2 Класс: ActRelationship (в предметной области Acts)

Атрибуты класса ActRelationship:

- typeCode:: CS

- inversionlnd:: BL

- contextControlCode:: CS

- contextConductionlnd:: BL

- sequenceNumber:: INT

- priorityNumber:: REAL

- pauseQuantity:: PQ

- checkpointCode:: CS

- splitCode:: CS

- joinCode:: CS

- negationlnd:: BL

- conjunctionCode:: CS

- localVariableName:: ST

- seperatablelnd:: BL

Ассоциации класса ActRelationship:

- target:: (1..1) Act:: inboundRelationship :: (0..*) (ассоциация с классом Act, роль inboundRelationship - входящая связь)

- source :: (1..1) Act:: outboundRelationship :: (0..*) (ассоциация с классом Act, роль outboundRelationship - исходящая связь)

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

Примеры:

1) Компонентами панели электролитов являются натрий, калий, pH и бикарбонат. Тогда экземпляр класса Act, описывающий панель электролитов, имела бы 4 "исходящие" ассоциации с экземплярами классов ActRelationship, у которых атрибут ActRelationship.typeCode имеет значение COMP (has component - имеет компонент).

2) Панель электролитов исследуется по направлению на лабораторный анализ. Тогда экземпляр класса Act, содержащий результат исследования, имел бы "исходящую" ассоциацию с экземпляром класса ActRelationship, у которого атрибут ActRelationship.typeCode имеет значение FLFS (fulfills - выполняет) и который имеет "входящую" ассоциацию с экземпляром класса Act, содержащим направление на анализ.

3) Операция "холецисэктомия" выполнена в связи с результатом исследования "желчекаменная болезнь". Тогда экземпляр класса Act, содержащий сведения об этой операции, имел бы "исходящую" ассоциацию с экземпляром класса ActRelationship, у которого атрибут ActRelationship.typeCode имеет значение RSON (has reason - имеет причину) и который имеет "входящую" ассоциацию с экземпляром класса Observation, в котором указан диагноз "желчекаменная болезнь".

Обсуждение: каждый экземпляр класса ActRelationship можно рассматривать как стрелу с наконечником (упирающимся в целевой объект) и хвостовиком (упирающимся в объект-источник). Функции (иногда называемые "ролями"), которые выполняют экземпляры класса Act при таком связывании, определяются для каждого типа класса экземпляр класса ActRelationship по-разному. Когда экземпляр класса ActRelationship обеспечивать связь "композиция", то источник является составным объектом, а цель - его компонентом. Когда экземпляр класса ActRelationship обеспечивать причинно-следственную связь, то источником может быть любой экземпляр класса Act, а целью - экземпляр класса Act, описывающий причину появления источника.

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

Более подробные сведения о различных типах экземпляров класса ActRelationship см. в описании атрибута ActRelationship.typeCode.

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

Одним из наиболее распространенных применений класса ActRelationship является описание композиций и декомпозиций действий, в которых экземпляры этого класса используются с атрибутом typeCode, имеющим значение COMP (has component - имеет компонент). Этот тип связи позволяет описывать действия с разной степенью детализации.

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

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

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

С помощью атрибутов Act.activityTime и ActRelationship.pauseQty можно явным образом задавать время выполнения планируемых действий;

С помощью экземпляров класса ActRelationship, у которых атрибут ActRelationship.typeCode имеет значение PRCN (has precondition - имеет предусловие), можно задавать условия выполнения шагов плана в зависимости от состояния или результата предшествующих действий. С помощью атрибута ActRelationhsip.checkpointCode можно указать, когда проверяется предусловие действия в процессе передачи управления.

С помощью композиций экземпляров класса ActRelationship можно организовывать многие уровни вложения, позволяющие полностью представить управление рабочими процессами. Такое вложение и такое использование атрибутов рабочих процессов сконструировано по аналогии с конструкциями языков структурного программирования, поддерживающих параллелизм (ветвление, соединение, прерывания) и не требующих применения операторов перехода GOTO. Важно отметить, что ВСЕ планы описываются с помощью упорядоченных компонентов (шагов) составного действия (блока), которые могут быть отображены с помощью диаграмм Насси-Шнейдерман (известных также как "щелевые схемы" (Chap Charts) или структограммы), а не в форме цепочек связанных действий, как в блок-схемах.

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

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

В следующих подпунктах описаны атрибуты класса ActRelationship.

7.1.2.1 ActRelationship.typeCode:: CS (1..1) Mandatory

Словарный домен: ActRelationshipType (CNE)

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

Обсуждение: типы экземпляров класса ActRelationship попадают в одну из 5 категорий:

1) Композиция или декомпозиция, с составным объектом (источником) и компонентом (цель).

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

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

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

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

7.1.2.2 ActRelationship.inversionlnd:: BL (0..1)

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

7.1.2.3 ActRelationship.contextControlCode:: CS (0..1)

Словарный домен: ContextControl (CNE)

Определение: код, указывающий, какой вклад вносит данный экземпляр класса ActRelationship в контекст текущего экземпляра класса Act, и будет ли этот контекст распространяться на действия-потомки, чьи связи разрешают такое распространение (см. описание атрибута ActRelationship.contextConductionlnd).

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

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

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

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

Примеры: пусть экземпляр класса Observation имеет исходящую ассоциацию к экземпляру класса ActRelationship, содержащему информацию об участии пациента в исследовании, и при этом атрибут ActRelationship.contextControlCode имеет значение АР (additive, propagating - аддитивная, распространяемая). Пусть этот же экземпляр класса Observation имеет связи с компонентами исследования, описанные с помощью экземпляров класса ActRelationship, которые маркированы как распространяющие контекст. Это означает, что участие пациента, описанное для родительского экземпляра класса Observation, распространяется и на эти компоненты исследования.

Пусть создано составное назначение, содержащее заказ в аптеку, а также заказ нескольких лабораторных анализов. Это составное назначение имеет связи участия с пациентом и автором назначения, а также связь с диагнозом, и каждая из этих связей маркирована как "аддитивная, распространяемая". Пусть связь между составным назначением и заказом в аптеку маркирована как распространяющая связь (ее атрибут contextConductionlnd имеет значение TRUE). При этом заказ в аптеку имеет связь участия с автором, маркированную как AN (additive, non-propagating - аддитивная, не распространяемая), и причинно-следственную связь с диагнозом, маркированную как ОР (overriding, propagating - замещающая, распространяемая). Кроме того, заказ в аптеку имеет связь с информацией об отпуске лекарства, а также связь с формуляром лекарства, которая маркирована как не распространяемая (ее атрибут contextConductionlnd имеет значение FALSE). Такая совокупность объектов и связей трактуется следующим образом.

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

7.1.2.4 ActRelationship.contextConductionlnd:: BL (0..1)

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

Обсуждение: распространяются только те связи, которые были добавлены к контексту родительского действия и были маркированы как "распространяемые" (см. описания атрибута contextControlCode в классах ActRelationship и Participation).

Идентификация экземпляра класса Act как родительского или дочернего (и, следовательно, идентификация направления распространения контекста) определяется пересечением связи при ее сериализации. Первое обнаруженное действие рассматривается как родительское. Контекст распространяется через экземпляр класса ActRelationship на второе (дочернее) действие.

Обоснование и примеры указаны в описании атрибута ActRelationship.contextControlCode.

7.1.2.5 ActRelationship.sequenceNumber:: INT (0..1)

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

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

7.1.2.6 ActRelationship.priorityNumber:: REAL (0..1)

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

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

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

7.1.2.7 ActRelationship.pauseQuantity:: PQ (0..1)

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

Обсуждение: этот атрибут принадлежит к группе атрибутов управления рабочим процессом. План действия представляет собой составное действие, связанное с действиями-компонентами. В упорядоченном плане каждый экземпляр класса ActRelationship, связывающий составное действие с компонентом, имеет атрибут sequenceNumber, значение которого определяет порядок шагов плана. Если у шага есть предусловия, то его выполнение инициируется в том случае, когда они удовлетворяются. В этот момент запускает таймер со значением pauseQuantity, и действие начинает выполняться, когда пройдет время, указанное в атрибуте pauseQuantity.

7.1.2.8 ActRelationship.checkpointCode:: CS (0..1)

Словарный домен: ActRelationshipCheckpoint (CNE)

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

Обсуждение: этот атрибут принадлежит к группе атрибутов управления рабочим процессом. План действия представляет собой составное действие, связанное с действиями-компонентами. В упорядоченном плане каждый экземпляр класса ActRelationship, связывающий составное действие с компонентом, имеет атрибут sequenceNumber, значение которого определяет порядок шагов плана. Если у шага есть предусловия, то его выполнение инициируется в том случае, когда они удовлетворяются. С помощью атрибута repeatNumber можно указать, что выполнение действия может повторяться. А с помощью атрибута checkpointCode можно указать, когда проверяется предусловие, что аналогично различным условным операторам и циклам в языках программирования: while-do по сравнению с do-while или repeat-until по сравнению с loop-exit.

Для всех значений атрибута checkpointCode, кроме Е (end - конец), предусловия проверяются в момент завершения предшествующего шага плана при условии, что данный шаг является следующим согласно значению атрибута sequenceNumber.

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

Если атрибут checkpointCode имеет значение S (entry - вход), то критерий проверяется в начале каждого повторения (если таковые имеются), при этом "начало" означает, что критерий проверяется однократно при старте "циклического" повторения.

Если атрибут checkpointCode имеет значение Т (through - в течение), то оно задает особый случай, когда критерий проверяется в процессе повторения. Как только критерий перестал выполняться, должно быть инициировано событие прерывания действия (см. описание атрибута Act.interruptiblelnd) и в принципе действие должно быть завершено.

Атрибут checkpointCode со значением X (exit - выход) используется в специальном шаге плана, представляющем выход из цикла. С его помощью можно обеспечить завершение плана действий в связи с выполнением определенного условия, проверяемого при выполнении этого плана. Такие критерии выхода упорядочены относительно других компонентов плана с помощью атрибута ActRelationship.sequenceNumber.

7.1.2.9 ActRelationship.splitCode:: CS (0..1)

Словарный домен: ActRelationshipSplit (CNE)

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

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

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

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

7.1.2.10 ActRelationship.joinCode:: CS (0..1)

Словарный домен: ActRelationshipJoin (CNE)

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

Обсуждение: этот атрибут принадлежит к группе атрибутов управления рабочим процессом. План действия представляет собой составное действие, связанное с действиями-компонентами. В упорядоченном плане каждый экземпляр класса ActRelationship, связывающий составное действие с компонентом, имеет атрибут sequenceNumber, значение которого определяет порядок шагов плана. Если для нескольких компонентов значение атрибута sequenceNumber одинаково, то эти компоненты являются ветвями. Ветви могут выполняться параллельно, если атрибут splitCode указывает, что в одно и то же время может исполняться более одной ветви. В этом случае с помощью атрибута joinCode можно указать, будет ли восстанавливаться синхронизация ветвей, и если да, то каким образом.

Основные способы восстановления синхронизации следующие:

- поток управления ждет, пока выполнение каждой ветви не завершится (ожидание ветвей);

- как только выполнится одна ветвь, выполнение остальных ветвей прекращается (прекращение ветвей);

- синхронизация ветвей не восстанавливается, и они продолжают выполняться (отложенные ветви).

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

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

7.1.2.11 ActRelationship.negationlnd:: BL (0..1)

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

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

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

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

7.1.2.12 ActRelationship.conjunctionCode:: CS (0..1)

Словарный домен: RelationshipConjunction (CNE)

Определение: код, указывающий логическое соединение критериев, описанных условными связями между действиями (например, AND ("и"), OR ("или"), XOR ("исключающее или")).

Ограничения: Все критерии, соединенные с помощью AND, должны выполняться. Если в одну группу входят критерии, соединяемые с помощью OR и AND, то должны выполняться хотя бы один из критериев OR и все критерии AND. Если в одну группу входят критерии, соединяемые с помощью XOR, OR и AND, то должен выполняться ровно один критерий XOR, по крайней мере один из критериев OR и все критерии AND. Другими словами, множества критериев AND, OR и XOR, в свою очередь, объединены логическим оператором AND (все критерии AND, по крайней мере один из критериев OR и ровно один критерий XOR). Если требуется иное, то можно воспользоваться вложенными критериями.

7.1.2.13 ActRelationship.localVariableName:: ST (0..1)

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

7.1.2.14 ActRelationship.seperatablelnd:: BL (0..1)

Определение: этот индикатор указывает, должно ли действие-источник связи интерпретироваться независимо от целевого действия связи. Его значение не может препятствовать человеку или приложению обрабатывать действия независимо друг от друга, оно лишь обозначает желание и готовность автора аттестовать содержание действия-источника, если оно будет отделено от содержания целевого действия. Имейте в виду, что типичным значением этого атрибута по умолчанию будет TRUE. Также учтите, что этот атрибут ортогонален механизму наследования контекста и никак с ним не связан. Если контекст действия распространен на вложенные действия, то тем самым предполагается, что эти вложенные действия не могут интерпретироваться без распространенного контекста.

7.1.3 Класс Participation (в предметной области Acts)

Атрибуты класса Participation:

- typeCode:: CS

- functionCode:: CD

- contextControlCode:: CS

- sequenceNumber:: INT

- negationlnd:: BL

- noteText:: ED

- time:: IVL<TS>

- modeCode:: CE

- awarenessCode:: CE

- signatureCode:: CE

- signatureText:: ED

- performlnd:: BL

- substitutionConditionCode:: CE

Ассоциации класса Participation:

- act::(1..1 )Act::participation::(0..*) (ассоциация с классом Act, роль participation - участие)

- role::(1..1 )Role:participation::(0..*) (ассоциация с классом Role, роль participation - участие)

Класс Participation является обобщением следующих классов:

- ManagedParticipation (управляемое участие)

Определение класса Participation: класс Participation моделирует ассоциацию между классом действия Act и классом сущности Entity, принимающим участие в действии, описанном классом Act, и выполняющим в этом участии роль, описанную классом Role. Каждая пара сущность-роль связана с экземпляром класса Act с помощью одного экземпляра класса Participation. Тип вовлечения этой пары в действие, описываемое экземпляром класса Act, задается с помощью атрибута Participation.typeCode.

Примеры:

1) Исполнители действий (хирурги, исследователи, врачи общей практики);

2) Субъекты действий, пациент, устройства;

3) Местоположения;

4) Автор, поручитель, свидетель, информатор;

5) Адресат, получатель информации.

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

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

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

Например, в протокол хирургической операции могли быть внесены три лица:

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

б) ведущий хирург;

в) анестезиолог.

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

а) получение согласия,

б) собственно операция,

в) анестезия, выполняемая параллельно с операцией.

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

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

В следующих подпунктах описаны атрибуты класса Participation.

7.1.3.1 Participation.typeCode:: CS (1..1) Mandatory

Словарный домен: ParticipationType (CNE)

Определение: код, указывающий вид участия (вовлечения) сущности, выполняющей определенную роль, связанную с этим участием, в действии, описанном в ассоциированном экземпляре класса Act.

Ограничения: допустимые значения атрибута Participant.typeCode имеют строгие семантические определения, соответствующие области применения стандарта HL7. Это атрибут с кодируемыми значениями без исключений. Альтернативные системы кодирования этого атрибута не допускаются.

7.1.3.2 Participation.functionCode:: CD (0..1)

Словарный домен: ParticipationFunction (CWE)

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

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

Ограничения: если этот код указан, его значение не должно конфликтовать со значением атрибута Participation. typeCode.

Не будет написано ни одной спецификации стандарта HL7, технически зависящей от атрибута functionCode. Если возникнет потребность в дополнительных понятиях, то они должны быть определены для значений атрибута Participation.typeCode.

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

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

7.1.3.3 Participation.contextControlCode:: CS (0..1)

Словарный домен: ContextControl (CNE)

Определение: код, указывающий, какой вклад вносит данный экземпляр класса Participation в контекст текущего экземпляра класса Act, и будет ли этот контекст распространяться на действия-потомки, чьи связи разрешают такое распространение (см. описание атрибута ActRelationship.contextConductionlnd).

Обсуждение: обоснование, обсуждение и примеры см. в описании атрибута ActRelationship.context-ControlCode.

7.1.3.4 Participation.sequenceNumber:: INT (0..1)

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

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

7.1.3.5 Participation.negationlnd:: BL (0..1)

Определение: значение TRUE этого атрибута указывает, что участие, описанное в экземпляре класса Participation, не имело, не имеет или не должно иметь место (в зависимости от значения атрибута moodCode).

Обоснование: этот атрибут имеет два основных приложения:

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

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

Обсуждение: экземпляр класса Participation, у которого атрибут negationlnd имеет значение TRUE, обладает преимуществом по отношению к экземпляру класса Participation, у которого атрибут negationlnd имеет значение FALSE. Другими словами, если возник конфликт, то отрицание участия имеет больший приоритет.

Примеры: Др. Смит не участвовал; пациент Джонс не подписывал информированное согласие.

7.1.3.6 Participation.noteText:: ED (0..1)

Определение: текстовое или мультимедийное представление комментария к данному участию. Относится только к этому участнику.

7.1.3.7 Participation.time:: IVL<TS> (0..1)

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

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

Примеры:

1. Время ввода данных в систему-источник передается в атрибуте Participation.time экземпляра класса Participation, связывающем действие с ролью "ввод данных".

2. Концом времени участия автора считается время подписи данных, передаваемых в экземпляре класса Act.

3. Временем участия поручителя, передаваемым в атрибуте Participation.time, считается момент его подписи.

7.1.3.8 Participation.modeCode:: СЕ (0..1)

Словарный домен: ParticipationMode (CWE)

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

Примеры: физическое присутствие, по телефону, письменная коммуникация.

Обоснование: этот атрибут особенно часть используется для участников "автор" ("создатель"), чтобы определить, обеспечивалась ли информация, представленная действием, первоначально устно, письменно (рукописно) или в электронном виде.

7.1.3.9 Participation.awarenessCode:: СЕ (0..1)

Словарный домен: TargetAwareness (CWE)

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

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

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

7.1.3.10 Participation.signatureCode:: СЕ (0..1)

Словарный домен: ParticipationSignature (CNE)

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

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

7.1.3.11 Participation.signatureText:: ED (0..1)

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

Примеры:

1) Участник "автор" берет на себя ответственность за достоверность содержания экземпляра класса Act в меру его осведомленности.

2) Получатель информации подтверждает лишь факт ее получения.

Обсуждение: подпись может быть представлена многими разными способами либо по значению, либо по ссылке в соответствии с типом данных ED. Типичные случаи таковы:

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

2) Электронная подпись: с помощью типа данных ED можно представить фактически любую схему электронной подписи.

3) Стандартная электронная подпись: в частности, с помощью типа данных ED можно представить стандартные электронные подписи, например, с помощью ссылки на блок данных подписи, сконструированный в соответствии со стандартом электронной подписи, например, XML-DSIG, PKCS#7, PGP и т.д.

7.1.3.12 Participation.performlnd:: BL (0..1)

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

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

7.1.3.13 Participation.substitutionConditionCode:: СЕ (0..1)

Словарный домен: SubstitutionCondition (CWE)

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

7.1.4 Класс Account (в предметной области Acts)

Код класса: АССТ.

Атрибуты класса Account:

- balanceAmt:: МО

- currencyCode:: СЕ

- interestRateQuantity:: RTO<MO,PQ>

- allowedBalanceQuantity:: IVL<MO>

Класс Account является специализацией класса Act.

Определение класса Account: специализация класса Act, представляющая категорию финансовых операций, которые проводятся на отдельном балансе.

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

Примеры: лицевые счета пациентов, счета за случаи обращения; центры затрат; счета дебиторов.

В следующих подпунктах описаны атрибуты класса Account.

7.1.4.1 Account.name::ST (0..1)

Определение: описательное имя счета, взятое из книги, в которой ведется этот счет.

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

Примеры: "затраты июня 2002 года", "дебиторская задолженность Джона Смита".

7.1.4.2 Account.balanceAmt:: МО (0..1)

Определение: сумма операций по дебету и кредиту счета (остаток) с момента его открытия.

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

7.1.4.3 Account.currencyCode:: СЕ (0..1)

Словарный домен: Currency (CWE)

Определение: указывает валюту счета.

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

7.1.4.4 Account.interestRateQuantity:: RTO<MO,PQ> (0..1)

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

Обсуждение: в этом атрибуте может быть указана процентная ставка для платежей (например, по ссудам, просроченным счетам) или для поступлений (по вложениям капитала и т.д.) в зависимости от типа счета.

Примеры: 0.10/1 а (10% в год); 0.0005895/1d (0,05895% в день).

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

7.1.4.5 Account.allowedBalanceQuantity:: IVL<MO> (0..1)

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

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

Примеры: пределы для "прекращения потерь"; пределы для кредита.

7.1.5 Класс DeviceTask (в предметной области Acts)

Код класса: CONTREG.

Атрибуты класса DeviceTask:

- parameterValue:: LIST<ANY>

Класс DeviceTask является специализацией класса Act.

Определение класса DeviceTask: специализация класса Act, представляющая деятельность автоматизированной системы.

Обсуждение: этот класс может использоваться для представления действий, вызванных внешней командой или запланированных и самостоятельно инициированных устройством (например, периодическая калибровка или очистка). Если экземпляр класса DeviceTask содержит описание команды, то его атрибут moodCode должен иметь значение ORD; если он содержит описание задачи (в том числе находящейся в стадии выполнения), то атрибут moodCode должен иметь значение EVN; для задачи, автоматически выполняемой по расписанию, атрибут moodCode должен иметь значение APT.

В следующих подпунктах описаны атрибуты класса DeviceTask.

7.1.5.1 DeviceTask.parameterValue:: LIST<ANY> (0..*)

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

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

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

Ограничения: параметры задаются таким способом только в том случае, если они не включены в отдельную структуру, определенную в стандарте HL7. Параметры представляют собой список значений любых типов данных, интерпретируемых устройством. Параметрам должны быть присвоены типы данных из числа определенных в стандарте HL7 (например, коды для номинальных значений, к примеру, для флажков, типы данных REAL и INT для чисел, тип данных TS для моментов времени, тип данных PQ для физических количеств и т.д.). Однако, помимо типов данных, использование параметров не входит в область применения стандарта HL7.

7.1.6 Класс Diagnosticlmage (в предметной области Acts)

Код класса: DGIMG.

Атрибуты класса Diagnosticlmage:

- subjectOrientationCode:: СЕ

Класс Diagnosticlmage является специализацией класса Observation.

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

В следующих подпунктах описаны атрибуты класса Diagnosticlmage.

7.1.6.1 DiagnosticImage.subjectOrientationCode:: СЕ (0..1)

Словарный домен: ImagingSubjectOrientation (CWE)

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

7.1.7 Класс Diet (в предметной области Acts)

Код класса: DIET.

Атрибуты класса Diet:

- energyQuantity:: PQ

- carbohydrateQuantity:: PQ

Класс Diet является специализацией класса Supply.

Определение класса Diet: действие кормления субъекта или предоставления ему питания.

Обсуждение: детали диеты передаются в экземпляре класса Material, ассоциированного с помощью экземпляра класса Participation, у которого атрибут typeCode имеет значение PRD (product - товар). Номер диеты, имеющий медицинское значение, можно передать в атрибуте Diet.code, однако детали пищи, входящей в диету, и различные сочетания блюд должны передаваться в форме экземпляров класса Material.

Примеры: безглютеновая диета, бессолевая диета.

В следующих подпунктах описаны атрибуты класса Diet.

7.1.7.1 Diet.energyQuantity:: PQ (0..1)

Определение: предоставляемая биологическая энергия (калории) в день.

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

7.1.7.2 Diet.carbohydrateQuantity:: PQ (0..1)

Определение: предоставляемое количество углеводов (грамм) в день.

Обсуждение: для диабетической диеты типично ограничение количества усваиваемых углеводов в день (например, 240 г/д). Это ограничение может быть передано как значение атрибута carbohydrateQuantity.

7.1.8 Класс FinancialContract (в предметной области Acts)

Код класса: FCNTRCT.

Атрибуты класса FinancialContract:

- paymentTermsCode:: СЕ

Класс FinancialContract является специализацией класса Act.

Определение класса FinancialContract: контракт, имеющий денежное выражение.

Примеры: договор страхования, соглашение о закупках.

В следующих подпунктах описаны атрибуты класса FinancialContract.

7.1.8.1 FinancialContract.paymentTermsCode:: СЕ (0..1)

Словарный домен: PaymentTerms (CWE)

Определение: сроки платежа по контракту или обязательствам.

Примеры: "в течение 30 дней с даты выставления счета", "по получению счета", "по завершению услуги".

7.1.9 Класс FinancialTransaction (в предметной области Acts)

Код класса: ХАСТ.

Атрибуты класса FinancialTransaction:

- amt:: МО

- creditExchangeRateQuantity:: REAL

- debitExchangeRateQuantity:: REAL

Класс FinancialTransaction является специализацией класса Act.

Определение класса FinancialTransaction: действие, представляющее движение денежных сумм между двумя счетами.

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

Если у экземпляра класса FinancialTransaction атрибут moodCode имеет значение ORD, то этот экземпляр трактуется как требование выполнения операции.

Если атрибут moodCode имеет значение EVN, то этот экземпляр класса FinancialTransaction содержит информацию об уже выполненной операции.

Примеры: затраты на услугу; оплата услуги; оплата счета.

В следующих подпунктах описаны атрибуты класса FinancialTransaction.

7.1.9.1 FinancialTransaction.amt:: МО (0..1)

Определение: указывает денежную сумму, перемещаемую с дебета на кредит счета.

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

7.1.9.2 FinancialTransaction.creditExchangeRateQuantity:: REAL (0..1)

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

Примеры: при регистрации оплаты услуг, оцененных в мексиканских песо (МХР) и оплаченных в долларах США (USD) со счета, который ведется в канадских долларах (CAD), в качестве обменного курса валюты кредита должно быть передано десятичное число г, для которого "у (USD) * r = х (CAD)".

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

7.1.9.3 FinancialTransaction.debitExchangeRateQuantity:: REAL (0..1)

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

Примеры: при регистрации оплаты услуг, оцененных в мексиканских песо (МХР) и оплаченных в долларах США (USD) со счета, который ведется в канадских долларах (CAD), в качестве обменного курса валюты дебита должно быть передано десятичное число r, для которого "у (USD) * r = х (МХР)".

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

7.1.10 Класс InvoiceElement (в предметной области Acts)

Код класса: INVE.

Атрибуты класса InvoiceElement:

- modifierCode:: SET<CE>

- unitQuantity:: RTO<PQ,PQ>

- unitPriceAmt:: RTO<MO,PQ>

- netAmt:: MO

- factorNumber:: REAL

- pointsNumber:: REAL

Класс InvoiceElement является специализацией класса Act.

Определение класса InvoiceElement: действие, представляющее объявление и обоснование суммы, подлежащей оплате.

Обсуждение: эта информация является частью "расшифровки" счета. Она часто объединяется с информацией о финансовой операции, представляющей сумму, подлежащую оплате, сумму, согласованную к оплате, или фактически оплаченную сумму.

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

Если у экземпляра класса InvoiceElement атрибут moodCode имеет значение DEF, то этот экземпляр описывает "возможное" согласование строки счета-фактуры при его будущем рассмотрении. Если атрибут moodCode имеет значение EVN, то этот экземпляр класса InvoiceElement содержит информацию о сумме, которую должен оплатить получатель.

В следующих подпунктах описаны атрибуты класса InvoiceElement.

7.1.10.1 InvoiceElement.modifierCode:: SET<CE> (0..*)

Словарный домен: InvoiceElementModifier (CWE)

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

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

Обоснование: этот модификатор не рассматривается как часть пре-координированной классификации с кодом, передаваемым в атрибуте code, поскольку система кодирования значений атрибута modifierCode не обязательно специально является детализацией системы кодирования атрибута code. Это не соответствует смыслу имени modifier (модификатор), поскольку обычно словарный домен модификатора должен быть определен как часть базового системы кодирования или должен быть разработан специально для нее.

7.1.10.2 InvoiceElement.unitQuantity:: RTO<PQ,PQ> (0..1)

Определение: описание количества товара или услуги, которое должно быть оплачено или уже оплачено.

Примеры: 4 часа, 4 мг, 4 коробки, 15 штук из контейнера, содержащего 1000 штук, и т.д.

Обсуждение: каждый экземпляр класса InvoiceElement, описывающий элемент счета-фактуры, подлежащий оплате или оплаченный, идентифицируется кодом товара или услуги, передаваемым в атрибуте InvoiceElement.code. В некоторых случаях этот код берется из пре-координированной классификации и идентифицирует контейнер (например, универсальный код продукта (УКП), присвоенный контейнеру, содержащему 1000 таблеток, и другой УКП-код для контейнера, содержащего 100 таких же таблеток). УКП-код используется при выставлении счетов, но при его применении возникает необходимость указать в форме дроби, что только часть контейнера (например, флакона) подлежит оплате или оплачена. Если товар, информация о котором передается в экземпляре класса InvoiceElement, не является контейнером, то знаменатель дроби не указывается.

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

Ограничения: единицы товара или услуги должны быть ограничены такими измеряемыми единицами как литры, миллиграммы и часы. Не измеряемые, но исчисляемые единицы, например, короба, пакеты, посещения, таблетки и контейнеры, не должны указываться в компоненте единиц измерения типа данных PQ иначе как в аннотации, указанной в фигурных скобках ({ххх}). См. спецификацию типов данных в документе Data Types Part II Unabridged Specification, Appendix A: Unified Code for Units of Measure.

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

- определить исчисляемую единицу в атрибуте InvoiceElement.code. В этом случае конкретное значение атрибута InvoiceElement.code будет содержать указание, что предмет, описанный в данном экземпляре класса InvoiceElement, является упаковкой, содержащей 20 элементов. Для упаковки, содержащей 40 элементов, должен использоваться другой код, и т.д.

Например, если значение InvoiceElement.code соответствует упаковке, содержащей 20 элементов, а значение атрибута количества InvoiceElement.unitQuantity = 2 (без единиц измерения), то данный экземпляр класса InvoiceElement описывает 2 упаковки по 20 элементов в каждой, т.е. всего 40 элементов.

Если требуется указать больше деталей (например, описать состав, упаковку, производителя товара), то эта информация должна быть описана как экземпляр класса Entity, связанный с данным экземпляром класса InvoiceElement с помощью экземпляров классов Role и Participation, при этом атрибут Participation.typeCode должен иметь значение PRD.

7.1.10.3 InvoiceElement.unitPriceAmt:: RTO<MO,PQ> (0..1)

Определение: стоимость единицы товара или услуги.

Ограничения: при указании дроби числитель должен иметь тип данных МО, а знаменатель - тип данных PQ. Детали указания дроби см. в описании атрибута unitQuantity.

Примеры: $0.20/мг; $250/день; $50.

7.1.10.4 InvoiceElement.netAmt:: МО (0..1)

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

Определение: для листовых элементов счета-фактуры эта сумма вычисляется по формуле unitQuantity*unitPriceAmt[*factorNumber][*pointsNumber]. Для группировок элементов счета-фактуры эта сумма вычисляется как сумма значений атрибутов netAmt всех элементов группы.

7.1.10.5 InvoiceElement.factorNumber:: REAL (0..1)

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

Примеры: 10 (число услуг в качестве единиц) * $3.00 (стоимость единицы) * 1.5 (коэффициент) = $45.00 (сумма).

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

Простейшая формула для вычисления полной суммы такова: unitQuantity * unitPriceAmount = netAmt.

С помощью коэффициента можно учесть скидки или доплаты, применяемые к полной сумме. Например, с учетом коэффициента формула для вычисления полной суммы примет следующий вид: unitQuantity * unitPrice (Cost/Point) * factorNumber = netAmt. См. аналогичное примечание к описанию атрибута InvoiceElement.pointsNumber, когда стоимость вычисляется с помощью баллов. При применении коэффициента и баллов формула для вычисления полной суммы примет следующий вид: unitQuantity * unitPriceAmt * pointsNumber * factorNumber = netAmt

7.1.10.6 InvoiceElement.pointsNumber:: REAL (0..1)

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

Примеры: 5 (число услуг в качестве единиц) * 3 (число баллов, присвоенных одной услуге) * $20.00 (стоимость балла) = $300.00 (сумма).

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

Простейшая формула для вычисления полной суммы такова: unitQuantity * unitPriceAmount = netAmt.

Понятие баллов может использоваться для расценки услуг и/или товаров, при которой количество услуг или товара измеряется в баллах, а одному баллу назначается определенная стоимость в долларах. В этом случае для расчета полной стоимости используется следующая формула: unitQuantity * pointsNumber * unitPriceAmt = netAmt.

См. соответствующее примечание к описанию атрибута factorNumber. При использовании коэффициентов и баллов для вычисления полной суммы применяется следующая формула: unitQuantity * unitPriceAmt * pointsNumber * factorNumber = netAmt.

7.1.11 Класс ManagedParticipation (в предметной области Acts)

Атрибуты класса ManagedParticipation:

- id:: SET<II>

- statusCode:: CS>

Класс ManagedParticipation является специализацией класса Participation.

Определение класса ManagedParticipation: участие, которое может меняться с течением времени, в связи с чем его состоянием и идентичностью надо управлять.

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

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

Однако в некоторых случаях представление о том, в чем именно состоят эти подзадачи и что именно выполняют участники, является не очень определенным и поэтому их моделирование в форме компонентов оказывается неоднозначным или затруднительным. Для таких случаев предназначен класс ManagedParticipation, который расширяет базовый класс Participation двумя атрибутами: идентификатором id и кодом состояния statusCode. Классы ManagedParticipation должны применяться с чрезвычайными предосторожностями, чтобы избежать путаницы с действиями, моделируемыми в виде классов Act, и не создавать для участий инфраструктуру управления, подобную той, что уже существует для действий.

В следующих подпунктах описаны атрибуты класса ManagedParticipation.

7.1.11.1 ManagedParticipation.id:: SET<II> (0..*)

Определение: уникальный идентификатор, с помощью которого можно идентифицировать конкретный экземпляр класса ManagedParticipation среди всех экземпляров этого класса, имеющих ассоциации с тем же самым экземпляром класса Act и с тем же самым экземпляром класса Role. (См. описание класса ManagedParticipation.)

7.1.11.2 ManagedParticipation.statusCode:: CS (0..1)

Словарный домен: ManagedParticipationStatus (CNE)

Определение: код, указывающий, описывает ли экземпляр класса ManagedParticipation готовящееся, активное, завершенное или отмененное участие. (См. описание класса ManagedParticipation.)

7.1.11.3 Переходы состояний класса ManagedParticipation

Диаграмма перехода состояний класса ManagedParticipation показана на рисунке 7. Управляемое участие может иметь следующие состояния:

- active (активно) - подсостояние состояния normal: это состояние отражает тот факт, что участие продолжается;

- cancelled (отменено) - подсостояние состояния normal: участие было отменено до того, как стало активным;

- completed (завершено) - подсостояние состояния normal: участие успешно завершено;

- normal (нормальное): "типичное" состояние. Исключает состояние nullified, которое указывает, что экземпляр участия был создан по ошибке;

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

- pending (готовящееся) - подсостояние состояния normal: это состояние отражает тот факт, что участие еще не стало активным.

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

- revise (пересмотреть) - из состояния active в состояние active;

- complete (завершить) - из состояния active в состояние completed;

- reactivate (активизировать заново) - из состояния completed в состояние active;

- revise (пересмотреть) - из состояния completed в состояние completed;

- nullify (аннулировать) - из состояния normal в состояние nullified;

- create (создать) - из начального (пустого) состояния в состояние active;

- create (создать) - из начального (пустого) состояния в состояние completed;

- create (создать) - из начального (пустого) состояния в состояние pending;

- activate (активизировать) - из состояния pending в состояние active;

- cancel (отменить) - из состояния pending в состояние cancelled;

- revise (пересмотреть) - из состояния pending в состояние pending.

7.1.12 Класс Observation (в предметной области Acts)

Код класса: OBS.

Атрибуты класса Observation:

- modifierCode:: SET<CE>

- unitQuantity:: RTO<PQ,PQ>

- unitPriceAmt:: RTO<MO,PQ>

- netAmt:: MO

- factorNumber:: REAL

- pointsNumber:: REAL

Класс Observation является генерализацией следующих классов:

- Diagnosticlmage

- PublicHealthCase

Класс Observation является специализацией класса Act.

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

Обсуждение: структура многих результатов исследований может быть представлена в форме пар имя-значение, при этом атрибут Observation.code (унаследованный от класса Act) - это имя свойства, а атрибут Observation.value - значение свойства. Такая конструкция часто называется "переменной" (т.е. именованное свойство, которому может быть присвоено значение). Таким образом, класс Observation всегда используется для передачи общих пар имя-значение, т.е. переменных, даже если вычисление переменной и не является результатом сложного метода исследования. Оно может быть просто ответом на вопрос, или утверждением, или присваиванием значения параметру.

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

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

В следующих подпунктах описаны атрибуты класса Observation.

7.1.12.1 Observation.value:: ANY (0..*)

Определение: Информация, которая создана или определена действием исследования.

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

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

Далее приведены общие рекомендации по выбору типа данных:

В количественных результатах, в основном, используется тип данных Physical Quantity (PQ). Этот тип данных, по существу, представляет собой вещественное число с единицей измерения. Это общие предпочтения для всех числовых значений. Некоторые исключения описаны далее.

Числовые значения не должны быть передаваться в форме простой строки символов (тип данных ST).

Для титра (например, 1:64) и очень немногих других отношений используется тип данных RTO. У титров числителем и знаменателем отношения являются целые числа (например, 1:128). В других отношениях могут использоваться разные количественные типы данных, например, "цена" с типом данных МО.

Иногда по местным соглашениям для титров передаются только знаменатели (например, 32 вместо 1/32). Такие соглашения могут вносить путаницу и в сообщениях стандарта HL7 вместо них должны использоваться правильные отношения.

Для передачи значений индекса (числа без единицы измерения) используется вещественный тип данных (REAL). Если количество не имеет подходящей единицы измерения, то его можно передать как вещественное число. В качестве альтернативы можно использовать тип данных PQ с безразмерной единицей (например, 1 или %). Целое число можно передавать только в том случае, если согласно определению исследования результатами могут являться только целые числа, что является редким случаем, например, если результат исследования имеет перечислимые значения (см. ниже).

Диапазоны (например, <3; 12-20) должны быть представлены в форме диапазонов физических количеств (тип данных IVL<PQ>) или в форме интервалов значений других количественных типов данных. Иногда такие интервалы используются, чтобы указать неопределенность измеренного значения. Однако на этот случай имеются специальные расширения типов данных.

Для передачи перечислимых значений (например, +, ++, +++; или I, IIа, IIb, IIl, IV) используется тип данных СО (coded ordinal - кодированное перечислимое значение).

Номинальные результаты ("таксоны", например, тип организма) передаются с помощью любого из кодируемых типов данных (CD, СЕ), которые указывают, по меньшей мере, код, систему кодирования и необязательный исходный текст, преобразование в другую систему кодирования, а иногда - еще и квалификаторы.

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

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

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

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

Множества значений любого типа данных, перечисляемые данные, а также интервалы часто используются в экземплярах класса Observation, описывающих критерии (т.е. в экземплярах, у которых атрибут moodCode имеет значение EVN.CRT), чтобы указать "референтные пределы" или "пороговые значения" (для тревожных сигналов) и т.д.

Для последовательностей результатов (повторяемые измерения тех же свойств в течение относительно короткого времени) используется тип данных LIST (list - список). Дополнительные детали см. в спецификации коррелируемых последовательностей результатов (Correlated Observation Sequences).

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

7.1.12.2 Observation.interpretationCode:: SET<CE> (0..*)

Словарный домен: Observationlnterpretation (CWE)

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

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

7.1.12.3 Observation.methodCode:: SET<CE> (0..*)

Словарный домен: ObservationMethod (CWE)

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

Примеры: способы измерения кровяного давления (артериальная пункция, сфигмоманометр (Riva-Rocci), сидя, лежа на спине и т.д.).

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

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

Обсуждение: при всех исследованиях метод их выполнения частично определяется по типу исследования (определению исследования, атрибут Act.code) и эту косвенную информацию о методе не надо явным образом указывать в атрибуте Observation.methodCode. Например, в классификации LOINC многим видам исследований присвоены разные коды, если методики исследования различаются и это может практически повлиять на интерпретацию результатов исследования. Например, в этой классификации проводится различие между исследованием чувствительности к антибиотикам методом "минимальной ингибирующей концентрации" (МИК) и "методом диффузии в агаре" (Кирби-Бауэр), так что этим видам исследований специально присвоены разные коды. Следовательно, значение атрибута methodCode может лишь служить дополнительным квалификатором, указывающим то, что не выводится непосредственно из значения атрибута Act.code.

Кроме того, некоторые вариации методов могут быть связаны с конкретным используемым устройством. Но значение атрибута methodCode не должно использоваться для указания конкретного устройства или использованного диагностикума. Такую информацию надо связывать сданным экземпляром класса Observation, используя экземпляр класса Participation, у которого атрибут typeCode имеет значение DEV (device - устройство).

7.1.12.4 Observation.targetSiteCode:: SET<CD> (0..*)

Словарный домен: ActSite (CWE)

Определение: код, указывающий анатомическую локализацию или систему организма, являющуюся предметом наблюдения, если такая информация не вытекает из определения исследования или из значения атрибута Act.code.

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

Обсуждение: в большинстве случаев исследуемая анатомическая локализация вытекает из определения исследования, значения атрибута Act.code или значения атрибута Observation.value. Например, "шумы сердца" заведомо относятся к сердцу. Этот атрибут используется только в тех случаях, когда анатомическая локализация должна быть детализирована, например, чтобы различать правую и левую сторону, и т.д.

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

7.1.13 Класс PatientEncounter (в предметной области Acts)

Код класса: ENC

Атрибуты класса PatientEncounter:

- admissionReferralSourceCode:: СЕ

- lengthOfStayQuantity:: PQ

- dischargeDispositionCode:: СЕ

- acuityLevelCode:: СЕ

- preAdmitTestlnd:: BL

- specialCourtesiesCode:: SET<CE>

- specialArrangementCode:: SET<CE>

Класс PatientEncounter является специализацией класса Act.

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

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

В следующих подпунктах описаны атрибуты класса PatientEncounter.

7.1.13.1 PatientEncounter.admissionReferralSourceCode:: СЕ (0..1)

Словарный домен: EncounterReferralSource (CWE)

Определение: источник направления, инициировавшего данное обращение.

7.1.13.2 PatientEncounter.lengthOfStayQuantity:: PQ (0..1)

Определение: общее время, которое субъект проведет или провел в медицинской организации как часть обращения.

Обсуждение: фактическое число дней пребывания не может быть получено вычитанием даты выписки издаты поступления из-за возможных отпусков (на выходные).

7.1.13.3 PatientEncounter.dischargeDispositionCode:: СЕ (0..1)

Словарный домен: EncounterDischargeDisposition (CWE)

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

7.1.13.4 PatientEncounter.acuityLevelCode:: СЕ (0..1)

Словарный домен: EncounterAcuity (CWE)

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

7.1.13.5 PatientEncounter.preAdmitTestlnd:: BL (0..1)

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

7.1.13.6 PatientEncounter.specialCourtesiesCode:: SET<CE> (0..*)

Словарный домен: EncounterSpecialCourtesy (CWE)

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

7.1.13.7 PatientEncounter.specialArrangementCode:: SET<CE> (0..*)

Словарный домен: SpecialArrangement (CWE)

Определение: код, указывающий тип специальных мер, которые должны быть предприняты до обращения пациента (например, инвалидное кресло, носилки, переводчик, дежурный врач, собака-поводырь). Если атрибут moodCode экземпляра класса PatientEncounter указывает будущее действие, то этот экземпляр может использоваться для указания специальных мер, которые надо предпринять перед ожидаемым поступлением пациента.

7.1.14 Класс Procedure (в предметной области Acts)

Код класса: PROC

Атрибуты класса Procedure:

- methodCode:: SET<CE>

- approachSiteCode:: SET<CD>

- targetSiteCode:: SET<CD>

Класс Procedure является специализацией класса Act.

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

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

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

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

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

В следующих подпунктах описаны атрибуты класса Procedure.

7.1.14.1 Procedure.methodCode:: SET<CE> (0..*)

Словарный домен: ProcedureMethod (CWE)

Определение: указывает средства или методику выполнения процедуры.

Обсуждение: у любой процедуры может быть несколько разных методов. Хотя они обеспечивают, в основном, те же самые результаты, для более тщательной интерпретации протокола процедуры может требоваться указание, какой именно метод был применен (например, открытая или лапароскопическая холецистэктомия). Понятия метода могут быть "пре-координированы" в определении действия. Поскольку существует много возможных методов, существенно зависящих от конкретных видов процедур, конструирование словарного домена, который бы охватывал все эти методы, представляется затруднительным. Однако для конкретного типа процедуры такую систему кодирования сконструировать можно. Таким образом, пользователь, направляющий пациента на процедуру, может указать конкретный метод ее выполнения, выбрав требуемый вариант из такой системы кодирования. Возможные варианты методов выполнения могут быть описаны в справочнике процедур. В записях такого справочника, передаваемых с помощью экземпляров класса Procedure, у которых атрибут moodCode имеет значение DEF, атрибут methodCode может содержать список методов выполнения процедуры, используемый для выбора нужного метода при оформлении направления на процедуру или для проверки полученного протокола процедуры.

7.1.14.2 Procedure.approachSiteCode:: SET<CD> (0..*)

Словарный домен: ActSite (CWE)

Определение: анатомическая локализация или система организма, через которую процедура достигает места своего применения (см. описание атрибута targetSiteCode).

Примеры:

1) При нефрэктомии доступ к почке может быть трансабдоминальным или, главным образом, ретроперитонеальным.

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

3) Для неинвазивных процедур, например, иглоукалывания, место доступа - прокалываемое место кожи.

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

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

7.1.14.3 Procedure.targetSiteCode:: SET<CD> (0..*)

Словарный домен: ActSite (CWE)

Определение: Анатомическая локализация или система организма, являющаяся местом применения процедуры.

Примеры:

1) Местом применения нефрэктомии является правая или левая почка.

2) Местом применения катетеризации легочной артерии является легочная артерия.

3) Для неинвазивных процедур, например, иглоукалывания, местом применения является орган/система, на которые рассчитано воздействие (например, "печень").

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

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

7.1.15 Класс PublicHealthCase (в предметной области Acts)

Код класса: CASE

Атрибуты класса PublicHealthCase:

- detectionMethodCode:: СЕ

- transmissionModeCode:: СЕ

- diseaselmportedCode:: СЕ

Класс PublicHealthCase является специализацией класса Observation.

Определение класса PublicHealthCase: описание события, имеющего определенное значение для общественного здоровья, представляется как специализация класса Observation. Обычно это информация об одном или нескольких случаях инфекционного заболевания или другого события, подлежащего регистрации. Описание события общественного здоровья может включать в себя сведения о состоянии здоровья одного лица или сведения о нескольких случаях того же самого заболевания или условия, которые рассматриваются как угроза общественному здоровью. Типичным примером может служить вспышка заболевания. Определение события общественного здоровья (передаваемое в экземпляре класса PublicHealthCase, у которого атрибут moodCode имеет значение DEF) включает в себя описание клинических, лабораторных и эпидемиологических показателей, связанных с заболеванием или условием, влияющим на общественное здоровье. Есть определения событий для условий, которые подлежат регистрации, а также для тех, которые не подлежат. Есть также определения событий вспышек. Определение события общественного здоровья используется здравоохранением для статистики событий и не должно использоваться в качестве клинических рекомендаций, предназначенных для лечения. Примерами служат СПИД, синдром токсического шока, сальмонеллез и связанные с ними симптомы, используемые при определении угрозы.

В следующих подпунктах описаны атрибуты класса PublicHealthCase.

7.1.15.1 PublicHealthCase.detectionMethodCode:: СЕ (0..1)

Словарный домен: CaseDetectionMethod (CWE)

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

7.1.15.2 PublicHealthCase.transmissionModeCode:: СЕ (0..1)

Словарный домен: CaseTransmissionMode (CWE)

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

7.1.15.3 PublicHealthCase.diseaselmportedCode:: СЕ (0..1)

Словарный домен: CaseDiseaselmported (CWE)

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

7.1.16 Класс SubstanceAdministration (в предметной области Acts)

Код класса: SBADM

Атрибуты класса SubstanceAdministration:

- routeCode:: СЕ

- approachSiteCode:: SET<CD>

- doseOuantity:: IVL<PG>:: CE

- rateOuantity:: IVL<PЙ>

- doseCheckOuantity:: SET<RTO>

- maxDoseOuantity:: SET<RTO>

Класс SubstanceAdministration является специализацией класса Act.

Определение класса SubstanceAdministration: лекарственное назначение, т.е. действие введения или иного применения субстанции к субъекту.

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

Примеры: протокол химиотерапии, рецепт, запись о вакцинации.

В следующих подпунктах описаны атрибуты класса SubstanceAdministration.

7.1.16.1 SubstanceAdministration.routeCode:: СЕ (0..1)

Словарный домен: RouteOfAdministration (CWE)

Определение: метод введения терапевтического материала внутрь или на поверхность субъекта.

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

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

Примеры: перорально - per os (РО), сублингвально - sublingual (SL), суппозиторий - rectal (PR), ингаляция - per inhalationem (IH), глазные капли - ophtalmic (OP), назальное применение - nasal (NS), ушное применение - otic (ОТ), пессарий - vaginal (VG), внутрикожно - intra-dermal (ID), подкожно - subcutaneous (SC), внутривенно - intra-venous (IV), внутрисердечно - intra-cardial (IC)

7.1.16.2 SubstanceAdministration.approachSiteCode:: SET<CD> (0..*)

Словарный домен: ActSite (CWE)

Определение: детальное указание анатомической локализации, куда лекарство вводится или где оно применяется к субъекту.

Обсуждение: этот атрибут необходим только в том случае, если значение атрибута routeCode требует дальнейшего уточнения. Например, если атрибут routeCode имеет значение РО (перорально), то никакая дальнейшая спецификация места введения не требуется. Если, однако, атрибут routeCode имеет значение IV (внутривенно) или IM (внутримышечно), то в атрибуте approachSiteCode можно указать точное место введения (например, правое предплечье или левая дельтовидная мышца соответственно).

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

7.1.16.3 SubstanceAdministration.doseQuantity:: IVL<PQ> (0..1)

Определение: количество терапевтического агента или другой субстанции, полученное за один прием.

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

Единицы измерения должны быть ограничены такими измеряемыми единицами как литры, миллиграммы. Не измеряемые, но исчисляемые единицы, например, таблетки и капсулы, не должны указываться в компоненте единиц измерения типа данных PQ иначе как в аннотации, указанной в фигурных скобках ({ххх}). См. спецификацию типов данных в документе Data Types Part II Unabridged Specification, Appendix A: Unified Code for Units of Measure.

7.1.16.4 SubstanceAdministration.rateQuantity:: IVL<PQ> (0..1)

Определение: указывает скорость введения субстанции в субъект. Выражается как физическое (экстенсивное) количество, введенное за единицу времени (например, 100 мл/ч, 1 г/сут, 40 ммоль/ч, и т.д.).

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

7.1.16.5 SubstanceAdministration.doseCheckQuantity:: SET<RTO> (0..*)

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

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

Примеры:

1) При назначении эритромицина в дозировке 250 мг (1 таблетка 3 раза в день) общую суточную дозу можно рассчитать по формуле doseCheckQuantity = doseQuantity (1) * Ingredient.quantity (250 мг) * effectiveTime (3/сут) = 750 мг/сут.

2) При внутривенном введении ожидаемое количество субстанции в час можно рассчитать по формуле doseCheckQuantity = doseQuantity (100 мл) * Ingredient.quantity (5 мг/л) / rateQuantity (1 час) = 0.5 мг/ч, что можно преобразовать в суточную дозу по формуле doseCheckQuantity = 0.5 мг/ч * 24 ч/сут = 12 мг/сут.

Обоснование: вместо определения атрибута "общая суточная доза", как это было сделано в стандарте HL7 v2.3, здесь введено более общее понятие doseCheckQuantity, имеющее тип данных "отношение" (RTO).

Ограничения: invariant(SubstanceAdministration med, RTO max) where med.doseCheckQuantity.contains(max) {max.numerator.compares(med.doseQuantity); max.denominator.compares(1 s);}. Числитель должен быть в единицах, сопоставимых с единицами измерения значения doseQuantity, а знаменатель должен быть мерой времени.

7.1.16.6 SubstanceAdministration.maxDoseQuantity:: SET<RTO> (0..*)

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

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

Примеры: 500 мг/сут; 1200 мг/неделя.

Ограничения: invariant(SubstanceAdministration med, RTO max) where med.maxDoseQuantity.contains(max) {max.numerator.compares(med.doseQuantity); max.denominator.compares(1 s);}. Числитель должен выражаться в единицах, сопоставимых с единицами измерения значения doseQuantity, а знаменатель должен быть мерой времени.

7.1.17 Класс Supply (в предметной области Acts)

Код класса: SPLY

Атрибуты класса Supply:

- quantity:: PQ

- expectedllseTime:: IVL<TS>

Класс Supply является генерализацией класса Diet.

Класс Supply является специализацией класса Act.

Определение класса Supply: действие, включающее в себя передачу материала (товара) от одной сущности к другой.

Обсуждение: информация о передаваемом материале связывается с экземпляром класса Supply с помощью экземпляра класса Participation, у которого атрибут typeCode имеет значение PRD (product - товар). При этом важна точная идентификация материала (производитель, серийный номер и т.д.). Большая часть детальной информации о материале должна передаваться в экземпляре класса Material. Если требуется отдельно описать планирование доставки, доставку и оплату материала, то с экземпляром класса Supply можно связать экземпляр класса Transportation. Для описания услуги отпуска лекарственного средства используется экземпляр класса Supply, связанный с экземпляром класса SubstanceAdministration. В этом случае экземпляр класса SubstanceAdministration описывает применение лекарства, а экземпляр класса Supply - отпуск.

Примеры: заказ простыней, отпуск лекарства, отпуск медицинских расходных материалов со склада.

В следующих подпунктах описаны атрибуты класса Supply.

7.1.17.1 Supply.quantity:: PQ (0..1)

Определение: количество материала, которое было предоставлено или должно быть предоставлено (в зависимости от значения атрибута moodCode).

Обсуждение: этот атрибут может использоваться как альтернатива атрибуту expectedUlseTime или вместе с этим атрибутом. Если оба эти атрибута указаны, то значение, указанное в атрибуте quantity, представляет собой количество, которое предполагается израсходовать в течение времени, указанного в атрибуте expectedUseTime.

Единицы измерения должны быть ограничены такими измеряемыми единицами как литры, миллиграммы. Не измеряемые, но исчисляемые единицы, например, таблетки и капсулы, не должны указываться в компоненте единиц измерения типа данных PQ иначе как в аннотации, указанной в фигурных скобках ({ххх}). См. спецификацию типов данных в документе Data Types Part II Unabridged Specification, Appendix A: Unified Code for Units of Measure. Тип "исчисляемой" информации определен информацией сущности "продукта".

7.1.17.2 Supply.expectedUseTime:: IVL<TS> (0..1)

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

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

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

7.1.18 Класс WorkingList (в предметной области Acts)

Код класса: LIST

Атрибуты класса WorkingList:

- ownershipLevelCode:: СЕ

Класс WorkingList является специализацией класса Act.

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

Обсуждение: группируемые действия связываются с экземпляром класса WorkingList с помощью экземпляров класса ActRelationship, у которых атрибут typeCode имеет значение COMP (component - компонент).

Примеры: список жалоб, список целей лечения, список аллергий, листы назначений и т.д.

В следующих подпунктах описаны атрибуты класса WorkingList.

7.1.18.1 WorkingList.ownershipLevelCode:: СЕ (0..1)

Словарный домен: ListOwnershipLevel (CWE)

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

      7.2 Классы предметной области Entities

7.2.1 Класс Entity (в предметной области Entities)

Код класса: ENT.

Атрибуты класса Entity:

- classCode:: CS

- determinerCode:: CS

- id:: SET<II>

- code:: CD

- quantity:: SET<PQ>

- name:: BAG<EN>

- desc:: ED

- statusCode:: CS

- existenceTime:: IVL<TS>

- telecom:: BAG<TEL>

- riskCode:: SET<CE>

- handlingCode:: CE

Ассоциации класса Entity:

- languageCommunication::(0..*) LanguageCommunication::entity::(1..1) (ассоциация с классом LanguageCommunication, роль entity - сущность)

- playedRole::(0..*) Role::player:: (0..1) (ассоциация с классом LanguageCommunication, роль player - исполнитель)

- scopedRole::(0..*) Role::scoper:: (0..1) (ассоциация с классом LanguageCommunication, роль sсорег - контролер)

Класс Entity является генерализацией следующих классов:

- LivingSubject

- Material

- Organization

Класс Entity является специализацией класса InfrastructureRoot.

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

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

Ограничения: понятие сущности не включает в себя события/дела/действия или выполняемые роли (например, пациент, поставщик).

В следующих подпунктах описаны атрибуты класса Entity.

7.2.1.1 Entity.classCode:: CS (1..1) Mandatory

Словарный домен: EntityClass (CNE)

Определение: код, определяемый стандартом HL7 и указывающий вид или категорию экземпляра класса Entity.

Примеры: человек, животное, химическая субстанция, группа, организация.

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

7.2.1.2 Entity.determinerCode:: CS (1..1) Mandatory

Словарный домен: EntityDeterminer (CNE)

Определение код, определяемый стандартом HL7 и указывающий, представляет ли экземпляр класса Entity вид сущностей (kind-of) или конкретный экземпляр сущности.

Примеры: 1 человек (экземпляр), 3 шприца (вид сущностей, количество которых определено) или население Индианаполиса (вид группы)

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

7.2.1.3 Entity.id:: SET<II> (0..*)

Определение: уникальный идентификатор экземпляра класса Entity.

Обоснование: для успешной передачи данных требуется лишь наличие у сущности уникального идентификатора. Но поскольку различные системы ведут различные базы данных, то одной и той же сущности в них могут быть присвоены разные идентификаторы. Учтите, что идентификатор экземпляра сущности представляет собой чистый идентификатор, а не классификатор. Для представления серийных номеров, присваиваемых производителями, или артикулов в каталогах поставщиков, или инвентарных номеров материалов и товаров, информация о которых передается в экземплярах класса Material, могут использоваться атрибуты Role.id, что позволяет более ясно отразить тот факт, что такие номера или артикулы присвоены определенной стороной, связанной с этим материалом или товаром.

7.2.1.4 Entity.code:: CD (0..1)

Словарный домен: EntityCode (CWE)

Определение: значение, указывающее определенный вид сущности, представляемой в форме экземпляра класса Entity.

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

Обоснование: система кодирования значений этого атрибута зависит от значения атрибута Entity.classCode, например, своя система кодирования живых субъектов (таксономии животного и растительного мира), своя для химических субстанций (например, код IUPAC), системы кодирования организаций, страховых компаний, органов государственного управления, больниц, парков, озер, шприцев и т.д. В принципе система кодирования значений Entity.code может быть до такой степени детализирована, что будет содержать единственное значение. Примером может служить код CDC производителя вакцины, моделируемый как словарь понятий, в котором каждое понятие фактически относится к единственному экземпляру.

7.2.1.5 Entity.quantity:: SET<PQ> (0..*)

Определение: число сущностей или количество сущности, с соответствующими единицами измерения, что определяется значением атрибута Entity.determinerCode.

Примеры: для неопределенных видов значение этого атрибута представляет собой справочное значение для спецификации пропорций ингредиентов или компонентов (например, используя ассоциации RoleLink с экземплярами класса Role, у которых атрибут RoleLink.typeCode имеет значение PART, означающий "имеет часть", "имеет компонент", или "имеет содержание"). К примеру, популяция, в составе которой 60% женщин, может быть описана в виде связи "имеет часть" экземпляра класса Person, у которого атрибут quantity имеет значение 100, с экземпляром класса Person, у которого атрибут quantity имеет значение 60, а атрибут sex - значение F, т.е. женский пол. Амоксициллин в таблетках с дозировкой 500 мг может быть описан в виде связи "имеет ингредиент" экземпляра класса Material, у которого атрибут formCode имеет значение TAB (tablet - таблетка), а атрибут quantity имеет значение 1, с экземпляром класса Material, у которого атрибут code имеет значение кода амоксициллина, а атрибут quantity имеет значение 500 мг. Раствор глюкозы 5% (D5W) можно описать в виде связи "имеет ингредиент" экземпляра класса Material, у которого атрибут code имеет значение D5W, а атрибут quantity - значение 1 кг, с экземпляром класса Material, у которого атрибут code имеет значение кода глюкозы, а атрибут quantity имеет значение 50 г.

Количественные отношения, специфичные для материалов, выражаются, используя тот факт, что тип данных этого атрибута - множество физических количеств (SET<PQ>). Если это множество имеет более одного значения, то каждый его элемент рассматривается как определяющий одно и то же количество материала. Например, для одного литра воды можно было указать множество физических количеств 1 л, 1 кг, 55,56 моль, задающих, соответственно, объем, массу и количество вещества для одного и того же самого количества воды, что эквивалентно плотности массы (объемной массе) 1 кг/л и молярной массе (18 г/моль). Для глюкозы можно указать множество значений 180 г, 1 моль в соответствии с ее молярной массой (180 г/моль).