ГОСТ Р 56843-2015/ISO/IEEE 11073-10201:2004. Национальный стандарт Российской Федерации. Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 10201. Информационная модель предметной области

(утв. и введен в действие Приказом Росстандарта от 28.12.2015 № 2231-ст)

Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии

Предисловие

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

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

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

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

В общем контексте комплекса стандартов ИСО/ИИЭР 11073 задачей настоящего стандарта является определение и структуризация информации, которая непосредственно используется или хотя бы упоминается в процессе коммуникации между сущностями, относящимися к данной предметной области (предметными сущностями, прикладными сущностями).

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

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

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

ЕКС ЕС 1064, Информатика в медицине. Стандартный протокол коммуникаций. Электрокардиография при помощи компьютера (CEN EN 1064, Medical informatics — Standard communication protocol — computer-assisted electrocardiography.)

ЕКС ЕПС 12052, Информатика в медицине. Обмен медицинскими изображениями (CEN ENV 12052, Medical informatics — Medical imaging communication (MEDICOM).)

ИИЭР Std 1073, Стандарт ИИЭР для коммуникаций медицинских приборов. Обзор и основа (IEEE Std 1073, IEEE Standard for Medical Device Communications — Overview and Framework.)

IETF RFC 1155, Структура и идентификация управляющей информации для управляющей информации для сетей интернет, основанных на TCP/IP (IETF RFC 1155, Structure and Identification of Management Information for TCP/IP-Based Internets.)

ИСО 639-1, Коды для представления имен и языков. Часть 1: Код Альфа-2 (ISO 639-1, Code for the representation of names of languages — Part 1: Alpha-2 code.)

ИСО 639-2, Коды для представления имен и языков. Часть 2: Код Альфа-3 (ISO 639-2, Codes for the representation of names of languages — Part 2: Alpha-3 code.)

ИСО 3166-1, Коды для представления названий стран и подчиненных территорий. Часть 1: Коды стран (ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1: Country codes.)

ИСО 3166-2, Коды для представления названий стран и подчиненных территорий. Часть 2: Коды подчиненных территорий (ISO 3166-2, Codes for the representation of names of countries and their subdivisions — Part 2: Country subdivision code.)

ИСО 3166-3, Коды для представления названий стран и подчиненных территорий. Часть 3: Код для старых названий стран (ISO 3166-3, Codes for the representation of names of countries and their subdivisions — Part 3: Code for formerly used names of countries.)

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

ИСО 15225, Номенклатура — Спецификация для системы номенклатуры медицинских приборов, используемых для целей обмена нормативными данными (ISO 15225, Nomenclature — Specification for a nomenclature system for medical devices for the purpose of regulatory data exchange.)

ИСО/МЭК 646, Информационные технологии. ИСО 7-битный набор кодированных символов для обмена данными (ISO/IEC 646, Information technology — ISO 7-bit coded character set for information interchange.)

ИСО/МЭК 2022, Информационные технологии. Структура кода символов и методы расширения (ISO/IEC 2022, Information technology — Character code structure and extension techniques.)

ИСО/МЭК 5218, Информационные технологии. Коды для представления человеческих полов (ISO/IEC 5218, Information technology — Codes for the representation of human sexes.)

ИСО/МЭК 7498-1, Информационные технологии. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель (ISO/IEC 7498-1, Information technology — Open systems interconnection — Basic reference model — Part 1: The basic model.)

ИСО/МЭК 7498-2, Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 2. Архитектура защиты информации (ISO/IEC 7498-2, Information processing systems — Open systems interconnection — Basic reference model — Part 2: Security architecture.)

ИСО/МЭК 7498-3, Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 3. Именование и адресация (ISO/IEC 7498-3, Information processing systems — Open systems interconnection — Basic reference model — Part 3: Naming and addressing.)

ИСО/МЭК 7498-4, Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 4. Основы административного управления (ISO/IEC 7498-4, Information processing systems — Open systems interconnection — Basic reference model — Part 4: Management framework.)

ИСО/МЭК 8649, Системы обработки информации. Взаимосвязь открытых систем. Определение сервиса для сервисного элемента управления ассоциацией (ISO/IEC 8649, Information processing systems — Open systems interconnection — Service definition for the Association Control Service Element.)

ИСО/МЭК 8650-1, Информационные технологии. Взаимосвязь открытых систем. Спецификация протокола для сервисного элемента управления ассоциацией. Часть 1. Протокол (ISO/IEC 8650-1, Information technology — Open systems interconnection — Connection-Oriented Protocol for the Association Control Service Element — Part 1: Protocol.)

ИСО/МЭК 8650-2, Информационные технологии. Взаимосвязь открытых систем. Спецификация протокола для сервисного элемента управления ассоциацией. Часть 2. Проформа свидетельства о конформности протокольной реализации (PICS) (ISO/IEC 8650-2, Information technology — Open systems interconnection — Protocol Specification for Association Control Service Element — Part 2: Protocol Implementation Conformance Statements (PICS) proforma.)

ИСО/МЭК 8824-1, Информационная технология. Абстрактная синтаксическая нотация 1 (ASN.1). Часть 1. Спецификация основной нотации (ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1) — Part 1: Specification of basic notation.)

ИСО/МЭК 8824-2, Информационная технология. Абстрактная синтаксическая нотация 1 (ASN.1). Часть 2. Спецификация информационного объекта (ISO/IEC 8824-2, Information technology — Abstract Syntax Notation One (ASN.1) — Part 2: Information object specification.)

ИСО/МЭК 8859-n, Обработка информации. 8-битные однобайтовые наборы закодированных графических символов. Части 1 — 15. Различные алфавиты (ISO/IEC 8859-n, Information processing — 8-bit single-byte coded graphic character sets — Part 1 to Part 15: Various alphabets.)

ИСО/МЭК 9545, Информационные технологии. Взаимосвязь открытых систем. Структура прикладного уровня (ISO/IEC 9545, Information technology — Open systems interconnection — Application layer structure.)

ИСО/МЭК 9595, Информационные технологии. Взаимосвязь открытых систем. Определение сервиса общей управляющей информации (ISO/IEC 9595, Information technology — Open systems interconnection — Common management information service definition.)

ИСО/МЭК 9596-1, Информационные технологии. Взаимосвязь открытых систем. Протокол общей управляющей информации. Часть 1. Спецификация (ISO/IEC 9596-1, Information technology — Open systems interconnection — Common Management Information Protocol — Part 1: Specification.)

ИСО/МЭК 10040, Информационные технологии. Взаимосвязь открытых систем. Общее описание административного управления систем (ISO/IEC 10040, Information technology — Open systems interconnection — Systems management overview.)

ИСО/МЭК 10164-1, Информационные технологии. Взаимосвязь открытых систем. Административное управление системами. Часть 1. Функция административного управления объектами (ISO/IEC 10164-1, Information technology — Open systems interconnection — Systems management — Part 1: Object management function.)

ИСО/МЭК 10164-2, Информационные технологии. Взаимосвязь открытых систем. Административное управление системами. Часть 2. Функция административного управления состоянием (ISO/IEC 10164-2, Information technology — Open systems interconnection — Systems management — Part 2: State management function.)

ИСО/МЭК 10164-3, Информационные технологии. Взаимосвязь открытых систем. Административное управление системами. Часть 3. Атрибуты для представления связей. (ISO/IEC 10164-3, Information technology — Open systems interconnection — System management — Part 3: Attributes for representing relationships.)

ИСО/МЭК 10164-4, Информационные технологии. Взаимосвязь открытых систем. Административное управление системами. Часть 4. Функция аварийного уведомления (ISO/IEC 10164-4, Information technology — Open systems interconnection — Systems management — Part 4: Alarm reporting function.)

ИСО/МЭК 10164-5, Информационные технологии. Взаимосвязь открытых систем. Административное управление системами. Часть 5. Функция административного управления событиями (ISO/IEC 10164-5, Information technology — Open systems interconnection — Systems management — Part 5: Event management function.)

ИСО/МЭК 10164-6, Информационные технологии. Взаимосвязь открытых систем. Административное управление системами. Часть 6. Функция управления журналом (ISO/IEC 10164-6, Information technology — Open systems interconnection — Systems management — Part 6: Log control function.)

ИСО/МЭК 10164-7, Информационные технологии. Взаимосвязь открытых систем. Административное управление системами. Часть 7. Функция аварийного уведомления о защите (ISO/IEC 10164-7, Information technology — Open systems interconnection — Systems management — Part 7: Security alarm reporting function.)

ИСО/МЭК 10164-8, Информационные технологии. Взаимосвязь открытых систем. Административное управление системами. Часть 8. Функция журнала контроля системы защиты (ISO/IEC 10164-8, Information technology — Open systems interconnection — Systems management — Part 8: Security audit trail function.)

ИСО/МЭК 10164-9, Информационные технологии. Взаимосвязь открытых систем. Административное управление системами. Часть 9. Объекты и атрибуты для управления доступом (ISO/IEC 10164-9, Information technology — Open systems interconnection — Systems management — Part 9: Objects and attributes for access control.)

ИСО/МЭК 10164-10, Информационные технологии. Взаимосвязь открытых систем. Административное управление системами. Часть 10. Функция измерения частоты использования ресурса в целях учета (ISO/IEC 10164-10, Information technology — Open systems interconnection — Systems management — Part 10: Usage metering function for accounting purposes.)

ИСО/МЭК 10164-11, Информационные технологии. Взаимосвязь открытых систем. Административное управление системами. Часть 11. Метрические объекты и атрибуты (ISO/IEC 10164-11, Information technology — Open systems interconnection — Systems management — Part 11: Metric objects and attributes.)

ИСО/МЭК 10164-12, Информационные технологии. Взаимосвязь открытых систем. Административное управление системами. Часть 12. Функция управления тестированием (ISO/IEC 10164-12, Information technology — Open systems interconnection — Systems management — Part 12: Test management function.)

ИСО/МЭК 10164-13, Информационные технологии. Взаимосвязь открытых систем. Административное управление системами. Часть 13. Функция управления тестированием. Функция подведения итога (ISO/IEC 10164-13, Information technology — Open systems interconnection — Systems management — Part 13: Summarization function.)

ИСО/МЭК 10164-14, Информационные технологии. Взаимосвязь открытых систем. Административное управление системами. Часть 14. Категории полного и диагностического тестирования (ISO/IEC 10164-14, Information technology — Open systems interconnection — Systems management — Part 14: Confidence and diagnostic test categories.)

ИСО/МЭК 10165-1, Информационные технологии. Взаимосвязь открытых систем. Структура управляющей информации. Часть 1. Модель информации административного управления (ISO/IEC 10165-1, Information technology — Open systems interconnection — Structure of management information — Part 1: Management information model.)

ИСО/МЭК 10165-2, Информационные технологии. Взаимосвязь открытых систем. Структура управляющей информации. Часть 2. Определение информации административного управления (ISO/IEC 10165-2, Information technology — Open systems interconnection — Structure of management information — Part 2: Definition of management information.)

ИСО/МЭК 10646-1, Информационные технологии. Универсальный многооктетный набор кодированных символов (UCS). Часть 1. Архитектура многоязычная матрица (ISO/IEC 10646-1, Information technology — Universal multiple-octet coded character set (UCS) — Part 1: Architecture and basic multilingual plane.)

ИСО/ИИЭР 11073-10101, Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 10101. Номенклатура (ISO/IEEE 11073-10101, Health informatics — Point-of-care medical device communication — Part 10101: Nomenclature.)

ИСО/ИИЭР 11073-20101, Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 20101. Прикладные профили. Базовый стандарт (ISO/IEEE 11073-20101, Health informatics — Point-of-care medical device communication — Part 20101: Application profiles — Base standard.)

NEMA PS 3, Формирование цифровых изображений и обмен ими в медицине [NEMA PS 3, Digital imaging and communications in medicine (DICOM).]

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

В настоящем стандарте применены следующие термины с соответствующими определениями. В случае отсутствия определения каких-либо терминов в данном разделе, обратиться к Официальному словарю терминов стандартов ИИЭР, Седьмая редакция.

3.1 агент (agent): Прибор, который поставляет данные в систему, реализующую взаимодействие по модели менеджер — агент.

3.2 аварийный сигнал (alarm): Сигнал о возникновении ненормальных изменений (аварийной ситуации) в состоянии пациента или прибора.

3.3 сигнал тревоги, тревога (alert): Общий синоним:

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

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

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

3.6 архивный (archival): Термин, относящийся к данным, предназначенным для длительного хранения.

3.7 сервисный элемент управления связью (association control service element, ACSE): Метод, применяемый для установления логической связи между системами медицинских приборов (системами MDS).

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

3.9 класс (class): Типовое абстрактное описание одного или нескольких объектов — представителей класса, в форме единого набора атрибутов этого объекта (объектов) и предоставляемых им (ими) сервисов, включая описание процедуры создания нового объекта — представителя класса.

3.10 коммуникационный контроллер (communication controller): Часть системы медицинских приборов (MDS), отвечающая за обеспечение коммуникации.

3.11 участник (сторона) процесса коммуникации (communication party): Некто (или нечто), играющий определенную роль в предметной области и принимающий участие в процессах коммуникации в рассматриваемой предметной области.

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

3.13 агент данных (data agent): Система сбора данных о пациенте, представляющая собой медицинский прибор и предоставляющая необходимые данные другим приборам (устройствам).

3.14 формат данных (data format): Упорядоченное расположение данных в файле или потоке данных.

3.15 регистратор данных (data logger): Медицинский прибор, функционирующий в качестве оперативного хранилища данных и архива.

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

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

3.18 дискретный параметр (discrete parameter): Результат измерения жизненно важного показателя, который может быть представлен отдельным символьным или цифровым значением.

3.19 информационная модель предметной области (domain information model, DIM): Модель, описывающая общие понятия и связи между ними для данной предметной области.

3.20 событие (event): Изменение состояния прибора, о котором сообщила служба отчетов и уведомлений.

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

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

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

3.24 ведущая система (host system): Условное обозначение медицинской системы, к которой подключены измерительные приборы.

3.25 информационный объект (information object): Абстрактная модель данных, применяемая для передачи значений жизненно важных показателей и прочих данных о пациенте. Атрибуты в определении информационного объекта описывают его свойства. Каждое конкретное определение информационного объекта не несет конкретную информацию о реальном мире, но представляет собой описание класса объектов с одинаковыми свойствами.

3.26 элемент службы обработки данных (information service element): Экземпляры в базе данных медицинской информации (Medical data information base, MDIB).

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

3.28 отделение интенсивной терапии (intensive care unit, ICU): Отделение в структуре медицинского учреждения, в котором пациентов подвергают интенсивной терапии.

3.29 формат обмена данными (interchange format): Формат представления элементов данных и структуры сообщений, содержащих эти элементы данных в процессе обмена данными между системами. Формат обмена данными содержит данные о конструктивных элементах сообщений и синтаксисе. Конкретное представление формата обмена данными зависит от конкретной технологии обмена.

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

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

3.32 нижние уровни (lower layers): Уровни с 1-го по 4-й семиуровневой модели взаимодействия открытых систем (ВОИ) Международной организации по стандартизации (ИСО). Эти уровни охватывают спецификации механического, электрического и базового коммуникационных протоколов.

3.33 менеджер (manager): Прибор, который получает данные в системе, реализующей взаимодействие по модели менеджер — агент.

3.34 модель взаимодействия менеджер — агент (manager — agent model): Модель коммуникации, где устройство-агент предоставляет данные устройству-менеджеру, получающему эти данные.

3.35 база данных медицинской информации (medical data information base, MDIB): Это понятие относится к объектно-ориентированной базе данных, позволяющей, как минимум, хранить информацию о жизненно важных показателях организма.

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

3.37 система медицинского прибора (medical device system, MDS): Абстракция системы, способной выполнять одну или несколько медицинских функций. В контексте настоящего стандарта этот термин используется, в частности, как объектно-ориентированная абстракция прибора, предоставляющего медицинскую информацию в форме информационных объектов, определяемых настоящим стандартом.

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

3.39 объект (object): Понятие, абстракция или предмет, с отчетливыми границами и значимостью для решения рассматриваемой проблемы.

3.40 атрибуты/свойства объекта (object attributes): Данные, которые вместе с методами определяют объект.

3.41 класс объекта (object class): Общее определение группы объектов с одинаковыми атрибутами, общим поведением, общими взаимоотношениями с другими объектами и общей семантикой.

3.42 диаграмма объектов (object diagram): Диаграмма, раскрывающая связи между объектами в системе.

3.43 метод объекта (object method): Процедура или процесс, влияющий на значения атрибутов объекта и состояния класса объекта.

3.44 объектно-ориентированный анализ (object-oriented analysis): Метод анализа предметной области или задачи, основанный на рассмотрении реального мира как совокупности неким образом взаимодействующих объектов и соответствующем моделировании предметной области или задачи.

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

3.46 операция (operation): Функция или преобразование, которая может быть применена объектом или к объекту в классе (иногда называется сервисом).

3.47 проблемная область (problem domain): Область здравоохранения, подвергаемая моделированию.

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

3.49 сканер (scanner): Обозреватель и сумматор значений атрибутов объекта.

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

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

3.52 синтаксис (syntax) (например, формата обмена данными): Правила сочетания конструктивных элементов сообщения, предусмотренных форматом обмена данными.

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

3.54 отметка времени (timestamp): Атрибут или поле в наборе данных, который содержит указание на время создания этого набора данных.

3.55 главный объект (top object): Безусловный базовый класс для всех других объектов в той же модели.

3.56 верхние уровни (upper layers): Уровни с 5 по 7 семиуровневой модели взаимодействия открытых систем (ВОС) Международной организации по стандартизации (ИСО). Обеспечивают функционирование и специфицирование сессий обмена данными, представления данных в процессе обмена и взаимодействия приложений, обменивающихся данными.

3.57 виртуальный медицинский прибор (virtual medical device, VMD): Абстрактное представление подсистемы медицинского назначения в системе медицинских приборов (MDS).

3.58 виртуальный медицинский объект (virtual medical object, VMO): Абстрактное представление объекта в Медицинском пакете, являющемся частью информационной модели предметной области (DIM).

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

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

4 Сокращения

ACSE — сервисный элемент управления связью;

ASN.1 — язык ASN.1 для описания абстрактного синтаксиса;

BCC — прикроватный контроллер связи;

BER — основные правила кодирования;

BMP — основная многоязыковая плоскость;

CMDIP — общий протокол обмена информацией между медицинскими приборами;

CMDISE — служба (сервис) единого протокола доступа к данным медицинских приборов;

CMIP — протокол общей управляющей информации;

CMISE — сервисный элемент общей управляющей информации;

DCC — коммуникационный контроллер медицинского прибора;

DICOM — формирование цифровых изображений и обмен ими в медицине;

DIM — информационная модель предметной области;

ЭКГ — электрокардиограмма;

ЭЭГ — электроэнцефалограмма;

EBWW — глазное яблоко и наручные часы;

FSM — конечный автомат;

GMDN — Всемирная номенклатура медицинских изделий;

GMT — среднее время по Гринвичу;

IANA — Комитет по цифровым адресам в Интернет (уполномоченный орган Общества Internet (ISOC) и Федерального Совета сети (FNC), наблюдающий и координирующий назначение каждого уникального идентификатора протокола, используемого в Интернет);

ICS — заявление о том, что результат реализации чего-либо соответствует требованиям;

ICU — отделение интенсивной терапии;

ID — персональный (индивидуальный) идентификатор или идентификация личности;

LAN — локальная вычислительная сеть;

LSB — младший бит;

MDIB — база данных медицинской информации;

MDS — программно-аппаратная система медицинского прибора;

MEDICOM — система обмена медицинскими данными в форме изображений;

MIB или Mib — база данных управляющей информации;

MOC — класс управляемых объектов;

OID — идентификатор объекта;

OR — операционная комната (операционная);

OSI — модель взаимодействия открытых систем (ВОС)

PC — персональный компьютер;

PDU — часть сообщения, содержащая служебную информацию протокола передачи данных;

PM — постоянная метрика;

SCADA — система оперативного сбора данных и диспетчерского контроля за состоянием какого-либо объекта, основанная на использовании системы датчиков;

SCP ECG — стандартный протокол обмена данными для компьютеризованной электрокардиографии;

SNMP — простой протокол управления сетью, входит в стек протоколов TCP/IP;

SNTP — простой сетевой протокол синхронизации времени;

UML — объединенный (унифицированный) язык моделирования;

UTC — поясное (местное) среднее время по Гринвичу;

VMD — виртуальный медицинский прибор;

VMO — виртуальный медицинский объект;

VMS — виртуальная медицинская система.

5 Общие требования

Семейство стандартов ИСО/ИИЭР 11073 предназначено для того, чтобы обеспечить для медицинских приборов связываться и взаимодействовать друг с другом и с компьютеризированными информационными системами в здравоохранении наиболее подходящим для данной клинической среды образом.

Идеология семейства стандартов ИСО/ИИЭР 11073 основана на объектно-ориентированной парадигме управления системами. Данные (например, результат измерения, состояние) смоделированы в форме информационных объектов, к которым можно получить доступ и которыми можно управлять посредством использования служебного протокола обеспечения доступа к объекту.

Информационная модель предметной области (DIM) определяет полный набор информационных объектов (классов) и их свойств, методов и функций доступа, необходимых для обеспечения коммуникации медицинских приборов друг с другом.

Требования уровня пользователя к организации коммуникации медицинских приборов определены в ИИЭР Стд 1073, который также определяет и пользовательские сценарии организации такой коммуникации, охваченные семейством стандартов ИСО/ИИЭР 11073.

В рамках семейства стандартов ИСО/ИИЭР 11073 к информационной модели предметной области предъявляются следующие основные требования:

• определить объектно-ориентированную модель, содержащую соответствующую информацию (то есть данные) и функции (например, управления прибором), встречающиеся в предметной области коммуникации медицинских приборов, включая информацию об измерениях, контекстные данные, способы управления приборами, и прочие соответствующие аспекты;
• предоставить детальную спецификацию информационных объектов (классов), определенных в объектно-ориентированной модели, включая их свойства и методы;
• определить модель обслуживания коммуникации медицинских приборов, позволяющую предоставить доступ к информационным объектам, их свойствам и их методам;
• использовать номенклатуру, определенную в стандарте ИСО/ИИЭР 11073-10101, для идентификации всех элементов данных в модели;
• быть пригодной для определения протоколов передачи данных, а также и для определения форматов хранения файлов данных;
• определять требования соответствия;
• быть гибкой и расширяемой, чтобы по мере необходимости в будущем позволять вносить изменения и дополнения в существующий набор инструментов моделирования.

6 Информационная модель предметной области (DIM)

6.1 Общие положения

6.1.1 Моделирование

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

Информационная модель и модель обслуживания (сервисная модель) для коммуникационных систем, определенные и используемые в настоящем стандарте, концептуально основаны на модели взаимодействия открытых систем (OSI — open systems interconnection) Международной организации по стандартизации (ИСО). Объекты, определенные в информационной модели, считаются управляемыми (в данном случае — медицинскими) объектами. В основном они непосредственно доступны для функций управления (то есть, к ним есть доступ), что обеспечивается общим протоколом доступа к данным медицинских приборов (CMDISE), как это определено в настоящем стандарте.

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

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

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

На рисунке 6.1 представлена связь между управляемыми медицинскими объектами, MDIB, CMDISE, прикладными процессами и коммуникационной системой в медицинском приборе.

MDIB — база данных медицинской информации;

CMDISE — единый протокол доступа к данным медицинских приборов:

ACSE — протокол управления логическими соединениями (ассоциацией) систем

Рисунок 6.1 — База данных MDIB в коммуницируемых системах

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

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

На рисунке 6.2 показана связь между управляемыми медицинскими объектами, MDIB, CMDISE, прикладными процессами и коммуникационными системами.

Рисунок 6.2 — Управляемые медицинские объекты в архиве значений показателей жизненно-важных функций

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

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

6.1.2.1 Общие положения

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

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

6.1.2.2 Коммуникационные системы

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

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

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

6.1.2.3 Заархивированные показатели жизненно важных функций

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

6.1.3 Подход к моделированию

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

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

6.1.4 Расширение модели

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

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

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

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

6.2 Диаграмма пакетов. Краткий обзор

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

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

Рисунок 6.3 — Пакеты информационной модели предметной области

Числа в пакетах указывают на соответствующие подразделы данного раздела, посвященного моделям, и раздела 7, посвященного определениям объектов.

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

Более детальные модели для этих пакетов содержатся в подразделах 6.3 - 6.10.

6.3 Модель Медицинского пакета

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

На рисунке 6.4 представлена информационная модель (диаграмма классов) Medical Package.

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

Рисунок 6.4 — Модель Медицинского пакета

Модель Медицинского пакета содержит классы, описанные в 6.3.1 - 6.3.13.

Примечание - Экземпляры объекта Channel и объекта PM-Store должны содержаться только в одном экземпляре высшего объекта. См. Пакет тревоги для информации об объектах, связанных с сигналами тревоги.

6.3.1 Класс Virtual Medical Object (VMO — Виртуальный медицинский объект)

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

6.3.2 Класс Virtual Medical Device (VMD — Виртуальный медицинский прибор)

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

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

6.3.3 Класс Channel (Канал)

6.3.4 Класс Metric (Метрический показатель)

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

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

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

6.3.5 Класс Numeric (Числовой показатель)

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

Пример - Результат измерения пульса отражается в объекте класса Numeric.

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

6.3.6 Класс Sample Array (Массив выборок)

6.3.7 Класс Real Time Sample Array (Массив выборок в режиме реального времени)

6.3.8 Класс Time Sample Array (Временной массив выборок)

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

Пример - Программное обеспечение для анализа сегмента ST может использовать объект класса Time Sample Array, чтобы представить фрагменты графика кардиограммы, фиксируемой в режиме реального времени, которые содержат только единственный комплекс QRS. В пределах этого фрагмента графика программное обеспечение может само расположить точки измерения ST. Например, можно получать новый фрагмент графика каждые 15 секунд.

6.3.9 Класс Distribution Sample Array (Распределенный массив выборок)

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

Пример - Приложение для снятия электроэнцефалограммы (ЭЭГ) может использовать преобразование Фурье, чтобы получить распределение частоты (то есть, спектр) сигнала ЭЭГ. В этом случае для представления спектра в базе данных MDIB используется как раз объект класса Distribution Sample Array.

6.3.10 Класс Enumeration (Перечисление)

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

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

6.3.11 Класс Complex Metric (Комплексный метрический показатель)

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

Пример - Вентилятор может обеспечить широкие возможности анализа дыхания пациента. Для каждого вздоха он может вычислять различные числовые значения (например, объем вздоха, соотношение I:E, длительность вздоха) так же хорошо, как и перечисляемые значения (например, классификация типа дыхания или хронологические данные). Для повышения эффективности обработки вся эта информация группируется в одном экземпляре объекта Complex Metric, который обновляется после каждого вздоха.

6.3.12 Класс Persistent Metric Store, PM-Store (Хранилище постоянной метрики)

Объект класса PM-Store предоставляет возможность долговременного хранения метрических данных. Он может содержать различное количество объектов класса PM-Segment, к которым можно получить доступ только через данный объект класса PM-Store. По умолчанию объект класса PM-Store предназначен, чтобы хранить данные единственного объекта подклассов класса Metric.

Пример - Прибор сохраняет числовое значение инвазивного кровяного давления на диске. В этом случае для представления неизменяемой информации используется объект класса PM-Store. Атрибуты объекта класса PM-Store описывают период осуществления выборки, алгоритм осуществления выборки, и формат хранящихся данных. Когда этикетка текущего измерения давления меняется (например, во время wedge procedure), в процессе хранения создается новый объект класса PM-Segment для хранения уже обновленных контекстных данных (в данном случае — этикетки).

6.3.13 Класс Persistent Metric Segment, PM-Segment (Сегмент постоянной метрики)

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

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

6.4 Модель Пакета тревоги

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

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

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

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

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

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

На рисунке 6.5 показана модель классов Пакета тревоги.

Рисунок 6.5 — Модель Пакета тревоги

Примечание - Экземпляры объекта Пакета тревоги должны содержаться только в одном объекте-контейнере (объекте одного из верхних (белых) классов в модели).

Модель Пакета тревоги включает в себя классы, описанные в 6.4.1 - 6.4.3.

6.4.1 Класс Alert (Тревога)

Класс Alert предназначен для отражения результата выявления простого сигнала тревоги. Поэтому, он отражает только одну единственную аварийную ситуацию физиологического или технического характера, связанную с состоянием соответствующего объекта (медицинский прибор (MDS), виртуальный медицинский прибор (VMD) или метрический показатель (Metric)). Если прибор порождает объект класса Alert, то он уже не может породить объект класса Alert Status или класса Alert Monitor. Для каждой тревоги, которую может выявить прибор, необходим отдельный объект класса Alert.

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

Примечание - Экземпляр объекта Alert не создается и не уничтожается динамически в случаях, когда соответствующая тревога начинается или прекращается. Скорее, в этих случаях изменяются значения атрибутов некоторого существующего экземпляра объекта Alert.

6.4.2 Класс Alert Status (Уровень тревоги)

6.4.3 Класс Alert Monitor (Монитор тревожных ситуаций)

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

Если прибор порождает объект класса Alert Monitor, то он уже не может порождать объекты классов Alert или Alert Status. MDS должен содержать не более одного экземпляра объекта Alert Monitor.

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

6.5 Модель Пакета системы

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

На рисунке 6.6 показана модель классов Пакета системы.

Рисунок 6.6 — Модель Пакета системы

Модель Пакета системы содержит классы, описанные в 6.5.1 - 6.5.10.

6.5.1 Класс Virtual Medical System (Виртуальная медицинская система, VMS)

Класс VMS — абстрактный базовый класс для всех классов Пакета системы в данной модели. Это обстоятельство позволяет установить непротиворечивую систему наименования и обозначения классов в пакете System.

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

6.5.2 Класс Medical Device System (MDS)

Класс MDS — абстракция медицинского прибора, который предоставляет медицинские данные в форме классов, определенных в Медицинском пакете рассматриваемой информационной модели предметной области.

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

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

6.5.3 Класс Simple MDS (Простая MDS)

6.5.4 Класс Hydra MDS (Модульная MDS)

6.5.5 Класс Composite Single Bed MDS (Составная простая прикроватная MDS)

Класс Composite Single Bed MDS описывает медицинский прибор, который включает в себя (или связывается посредством некоторого интерфейса c) один или несколько объектов классов Simple MDS или Hydra MDS, сосредоточенных в одном месте (то есть, на одной или у одной кровати).

6.5.6 Класс Composite Multiple Bed MDS (Составная модульная прикроватная MDS)

Класс Composite Multiple Bed MDS описывает медицинский прибор, который содержит (или связывается посредством некоторого интерфейса c) несколько объектов классов Simple MDS или Hydra MDS, распределенных по нескольким местоположениям (то есть, на или у нескольких кроватей).

6.5.7 Класс Log (Журнал (лог))

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

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

6.5.8 Класс Event Log (Журнал событий)

Класс Event Log — основная разновидность (класс-потомок) класса Log, предназначен для хранения системных событий в свободном текстовом формате (неформатированный текст).

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

6.5.9 Класс Battery (Батарея)

Для приборов с батарейным питанием, некоторая часть информации о батарее включается в состав объекта класса MDS в форме соответствующих атрибутов. Для случаев, когда батарейная подсистема способна предоставлять дополнительную информацию (смарт-батарея) или некоторым способом управляться, определен специальный класс Battery.

6.5.10 Класс Clock (Часы)

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

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

6.6 Модель Пакета управления

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

Модель для дистанционного управления, определенная в настоящем стандарте, обеспечивает следующие преимущества:

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

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

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

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

Различные специализации потомков класса Operation определяют, как именно изменяется значение виртуального атрибута. Класс Select Item Operation, например, позволяет выбрать конкретное значение из данного списка возможных значений для атрибута. Класс Set Value Operation позволяет установить для атрибута значение из определенного диапазона с определенной шириной шага (то есть с определенным разрешением).

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

К объектам класса Operation не могут непосредственно получить доступ сервисы, определенные в модели обслуживания в разделе 8 настоящего стандарта. Вместо этого все попытки управления должны направляться через объект класса SCO (Service-and-Control). Этот объект поддерживает простой механизм блокировки транзакций, чтобы предотвратить побочные эффекты, вызванные одновременными запросами.

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

На рисунке 6.7 показана модель Пакета управления.

Рисунок 6.7 — Модель Пакета управления

Модель Пакета управления содержит классы, описанные в 6.6.1 - 6.6.9.

6.6.1 Класс Service-and-Control Object (Объект, предоставляющий сервис и управление, SCO)

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

Дистанционное управление в коммуницировании медицинских приборов чувствительно к проблемам обеспечения сохранности и безопасности. Класс SCO предоставляет средства для следующего:

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

b) индикация состояний, которая позволяет осуществлять локальную и удаленную индикацию текущих процессов управления.

6.6.2 Класс Operation (Операция)

Класс Operation — абстрактный базовый класс для классов, которые описывают удаленно-управляемые элементы. Каждый объект класса Operation (или класса-потомка) позволяет системе изменять некий конкретный элемент (то есть, виртуальный атрибут) конкретным способом, определенным объектом класса Operation (или класса-потомка). К объектам класса Operation не могут непосредственно получить доступ сервисы, определенные в модели обслуживания в разделе 8 настоящего стандарта. Вместо этого все попытки управления должны направляться через объект класса SCO (Service-and-Control Object) для упрощения обработки транзакций.

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

6.6.3 Класс Select Item Operation (Операция выбора элемента из списка)

Класс Select Item Operation позволяет осуществить выбор одного элемента из данного списка.

Пример - VMD для измерения инвазивного давления может позволить модификацию своей этикетки. Для этого используется объект класса Select Item Operation. Список допустимых значений этикетки, предоставляемых операцией, может выглядеть, например, как {ABP, PAP, CVP, LAP}. Вызывая операцию, пользователь получает возможность выбрать одно значение из этого списка.

6.6.4 Класс Set Value Operation (Операция установления значения)

Класс Set Value Operation позволяет осуществлять подстройку значения атрибута в пределах заданного диапазона с заданным разрешением.

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

6.6.5 Класс Set String Operation (Операция задания строки)

Класс Set String Operation позволяет системе устанавливать содержание закрытой строковой переменной заданной максимальной длины и формата.

Пример — Устройство для инъекций может позволить удаленной системе определять имя влитого лекарственного средства в свободно-текстовой форме, для удобства показа на собственном (локальном) дисплее. Для этого используется экземпляр объекта Set String Operation. Операция определяет максимальную длину последовательности и формат символов так, чтобы устройство было в состоянии показать название лекарственного средства на своем дисплее.

6.6.6 Класс Toggle Flag Operation (Операция переключения)

Класс Toggle Flag Operation позволяет осуществлять операцию переключения между двумя альтернативными состояниями (например, вкл/выкл).

Пример - VMD для снятия кардиограммы может обеспечить линейную частотную фильтрацию. Для включения и выключения фильтра используется объект класса Toggle Flag Operation.

6.6.7 Класс Activate Operation (Операция активации)

Класс Activate Operation позволяет начать определенную деятельность (например, обнуление показателя давления).

Пример - Процедура обнуления показателя инвазивного давления для соответствующего VMD может начаться при наличии соответствующего объекта класса Activate Operation.

6.6.8 Класс Limit Alert (Operation Операция настройки границы тревожного состояния)

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

6.6.9 Класс Set Range Operation (Операция установления границ диапазона значений)

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

Пример - Объект VMD для измерения показателя может обеспечить прием аналогового сигнала, для которого диапазон значений может быть настроен при наличии объекта класса Set Range Operation.

6.7 Модель Пакета дополнительных сервисов

6.7.1 Класс Scanner (Сканер)

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

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

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

6.7.2 Класс CfgScanner (Конфигурируемый сканер)

Класс CfgScanner — абстрактный базовый класс, у которого есть специальный атрибут ScanList, который позволяет системе устанавливать, какие атрибуты объектов следует сканировать. Значение атрибута ScanList может быть изменено или системой-агентом (автоконфигурация или преконфигурация) или системой-менеджером (полная динамически изменяемая конфигурация посредством использования сервиса SET).

Класс CfgScanner может выполнять сканирование с разной степенью детализации:

a) группа атрибутов (то есть, предопределенный набор атрибутов). Атрибут ScanList содержит идентификаторы (ID) групп атрибутов, и все атрибуты в такой группе сканируются;

b) отдельный атрибут. Атрибут ScanList содержит идентификаторы (ID) всех атрибутов, которые сканируются.

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

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

6.7.3 Класс EpiCfgScanner (Эпизодически конфигурируемый сканер)

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

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

Пример - Медицинский прибор формирует отчет о сердцебиении пациента в форме объекта класса Enumeration. Управляющая программа дисплея создает экземпляр объекта EpiCfgScanner и добавляет в его атрибут ScanList отслеживаемое значение объекта класса Enumeration. Экземпляр объекта Scanner впоследствии посылает уведомление каждый раз, когда соответствующий объект класса Enumeration сообщает о сердцебиении.

6.7.4 Класс PeriCfgScanner (Периодически конфигурируемый сканер)

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

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

Пример - Приложение, ведущее журнал изменения данных, порождает экземпляр объекта PeriCfgScanner и конфигурирует сканер так, чтобы он посылал обновление информации о значениях сканируемых атрибутов всех объектов класса Numeric в базу данных MDIB каждые 15 с.

6.7.5 Класс FastPeriCfgScanner (Быстрый периодически конфигурируемый сканер)

Класс FastPeriCfgScanner — специализированный класс объектов, предназначенный для того, чтобы отслеживать значения подлежащих просмотру значения атрибутов объекта класса Real Time Sample Array. Этот специальный сканер глубоко оптимизирован для оперативной отправки отчетов с минимальными задержками и эффективного использования пропускной способности канала коммуникации, что необходимо для нормального доступа к значениям данных в форме осциллограмм, получаемым в реальном масштабе времени.

Пример - Программе управления дисплеем в режиме реального времени (например, система-менеджер) нужно отразить графики кардиограммы. Она создает объект класса FastPeriCfgScanner в системе-агенте (например, на сервере) и запрашивает периодические обновления значений со всех датчиков ЭКГ.

6.7.6 Класс UcfgScanner (Неконфигурируемый сканер)

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

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

6.7.7 Класс Context Scanner (Контекстный сканер)

Класс Context Scanner предназначен для отслеживания изменений конфигурации устройства. Порожденный объект класса Context Scanner отвечает за оповещение о появлении новых экземпляров объектов в базе данных MDIB прибора. Сканер предоставляет данные об иерархии вложенности экземпляров объекта и значениях статических атрибутов объекта.

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

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

6.7.8 Класс Alert Scanner (Сканер тревожных состояний)

Класс Alert Scanner предназначен для отслеживания групп атрибутов, связанных с сигналами тревоги, у объектов в Пакете тревога. По соображениям обеспечения безопасности данный сканер — не конфигурируем (отслеживаются или все или никакие объекты класса Alert).

Объект класса Alert Scanner периодически посылает отчеты о событиях для проверки условий времени ожидания (тайм-аута).

6.7.9 Класс Operating Scanner (Сканер функционирования)

6.8 Модель Пакета коммуникаций

Рисунок 6.9 — Модель Пакета коммуникаций

Модель Пакета коммуникаций содержит объекты, описанные в 6.8.1 - 6.8.6.

6.8.1 Класс Communication Controller (Коммуникационный контроллер)

Класс Communication Controller представляет высоко- и низкоуровневый коммуникационный профиль медицинского прибора.

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

Будучи абстрактным базовым классом, класс Communication Controller не может иметь конкретных представителей-экземпляров. Для него определены, однако, два специализированных производных класса: Bedside Communication Controller (BCC) и Device Communication Controller (DCC), которые могут иметь объекты-представителей. База данных MDIB медицинского прибора или не содержит ни одного объекта классов, производных от Communication Controller, или один объект класса BCC, или один объект класса DCC (в зависимости от назначения прибора).

6.8.2 Класс Device Communication Controller (Коммуникационный контроллер прибора, DCC)

Класс DCC — производный от класса Communication Controller. Его объекты используются в процессе работы медицинских приборов в качестве систем-агентов (отвечающих при ассоциировании приборов).

Объект класса DCC должен содержать один или несколько объектов класса Device Interface.

6.8.3 Класс Bedside Communication Controller (Прикроватный коммуникационный контроллер, BCC)

Класс Bedside Communication Controller — производный от класса Communication Controller. Его объекты используются в процессе работы медицинских приборов в качестве систем-менеджеров (запрашивающих ассоциирование приборов).

Объект класса BCC должен содержать один или несколько объектов класса Device Interface.

6.8.4 Класс Device Interface (Интерфейс прибора)

Объект класса Device Interface отражает частный интерфейс прибора, то, что называется порт. Порт представляет собой логический или физический конечный пункт ассоциации, для которого (например, статистически) могут быть независимо собраны данные, извлеченные из объектов классов, производных от класса MibElement.

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

Объект класса Device Interface не доступен для функций сервиса CMDISE. Этот объект содержит, по крайней мере, один объект класса, производного от класса MibElement (то есть, объект подкласса Device Interface MibElement класса MibElement, который отражает свойства интерфейса прибора, включается в объект класса Device Interface, соответствующий этому интерфейсу), который может быть доступен посредством специального метода, определенного соответствующим объектом класса, производного от класса Communication Controller.

6.8.5 Класс MibElement (Объект базы данных управляющей информации)

Объект класса MibElement содержит статистику функционирования и данные о производительности для одного объекта класса Device Interface. Класс MibElement — всего лишь абстрактный базовый класс для производных специализированных классов, и поэтому не может иметь конкретных экземпляров-представителей.

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

Объект класса, производного от класса MibElement, непосредственно недоступен. К его атрибутам можно получить доступ только через объект класса, производного от класса Communication Controller. Объект класса, производного от класса MibElement, не является частью базы данных MDIB прибора.

6.8.6 Класс Specialized MibElement (Специализированный производный класс (подкласс) от класса MibElement)

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

Настоящий стандарт, однако, определяет только два обобщенных подкласса класса MibElement:

• класс обязательно существующих объектов Device Interface MibElement, который описывает свойства некоторого интерфейса прибора и включается в объект класса Device Interface, соответствующий этому интерфейсу;
• класс необязательных объектов MibElement общей статистики коммуникации, который моделирует набор типовых статистических данных коммуникации, который применим в общем случае.

Специализированные подклассы класса MibElement определены в стандарте ИИЭР Р 1073.2.1.2.

6.9 Модель Архивного пакета

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

На рисунке 6.10 показана модель классов Архивного пакета.

Рисунок 6.10 — Модель Архивного пакета

Модель Архивного пакета содержит классы, описанные в 6.9.1 - 6.9.7.

6.9.1 Класс Multipatient Archive (Общий архив данных о пациентах)

Объект класса Multipatient Archive группирует вместе несколько объектов класса Patient Archive, относящихся к разным пациентам.

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

6.9.2 Класс Patient Archive (Архив данных о пациенте)

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

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

6.9.3 Класс Session Archive (Архив данных сессии лечения)

Объект класса Session Archive отражает данные о разовом визите пациента или периоде непрерывного пребывания в больнице или конкретном отделении больницы. Диагностические процедуры, проведенные за этот период, отражаются объектами класса Session Test, содержащимися в объекте класса Session Archive. Этот объект ссылается на динамически изменяющиеся (то есть вариативные) данные о конкретном пациенте, содержащиеся в объекте класса Patient Demographics.

6.9.4 Класс Physician (Врач)

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

6.9.5 Класс Session Test (Проверка состояния здоровья в период сессии лечения)

Объект класса Session Test содержит информацию о показателях жизненно важных функций единичного пациента, зафиксированную во время единичного освидетельствования или диагностического мероприятия. Этот объект содержит метрические значения показателей жизненно важных функций в форме объектов класса PM-Store. Он также может содержать информацию об оборудовании, которое использовалось для того, чтобы сделать запись (в форме связей с объектами подклассов класса MDS и объектами класса Ancillary).

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

6.9.6 Класс Session Notes (Примечания к сессии лечения)

Объект класса Session Notes играет роль контейнера для диагностических данных, деталей лечения и технологической информации в форме текстовых данных.

6.9.7 Класс Ancillary (Вспомогательный)

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

Пример - Поступающие графические данные, соответствующие требованиям стандартов MEDICOM (CEN ENV12052) или DICOM (NEMA PS 3), разрешается включать в объект класса Session Test в качестве вспомогательных данных.

6.10 Модель Пакета пациента

Рисунок 6.11 — Модель Пакета пациента

Модель Пакета пациента содержит только один класс (см. 6.10.1).

6.10.1 Класс Patient Demographics (Персональные данные пациента)

Объект класса Patient Demographics предназначен для хранения типового набора персональных данных пациента.

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

6.11 Информационная модель предметной области (DIM). Динамическая модель

6.11.1 Общие положения

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

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

6.11.2 Конечный автомат коммуникаций MDS (Finite state machine, FSM)

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

Рисунок 6.12 — Модель конечного автомата MDS

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

Обнаружив попытку соединения, прибор пытается установить логическое соединение (ассоциацию) с другим прибором. Система-менеджер (клиент) запрашивает ассоциацию (association requester), а система-агент (сервер) система — отвечает на запрос, т.е. выступает в качестве респондента (association responder). В процессе установления ассоциации выполняются базовые проверки на совместимость ассоциирующихся приборов.

После успешной ассоциации происходит обмен данными о конфигурации MDS (то есть актуальной структурой баз данных MDIB приборов) посредством использования базовых и дополнительных сервисов (в частности, объекта класса Context Scanner), как это описывается в настоящем стандарте. Предоставление дополнительной информации (например, значений атрибутов MDS) позволяет осуществить более глубокие проверки состояний и совместимости ассоциированных приборов.

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

При наступлении события разъединения, прибор переходит в состояние разъединения.

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

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

Конечный автомат считается частью объекта класса MDS. Атрибут Status класса MDS отражает состояние автомата. Таким образом, MDS может объявлять об изменениях в состоянии автомата в форме отчетов о событии изменения значения этого атрибута.

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

6.11.3 Коммуникационные системы. Диаграмма взаимодействия объектов при запуске

На рисунке 6.13 представлена диаграмма взаимодействия объектов, которая визуализирует фазу запуска процесса коммуникации после соединения двух приборов.

Рисунок 6.13 — Запуск процесса обмена данными после установления соединения между системами

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

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

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

6.11.4 Пакет коммуникаций. Организация доступа к данным представителей подклассов класса MibElement

На рисунке 6.14 представлена диаграмма взаимодействия объектов, которая показывает, как система-менеджер получает доступ к данным объектов подклассов MibElement, используя классы, определенные в Пакете коммуникаций (см. 6.8).

• фаза конфигурации уже закончена, и у менеджера есть полное представление о содержимом базы данных MDIB агента;
• объект класса DCC (Device Communication Controller) содержится в базе данных MDIB агента.

Сначала менеджер использует сервис GET, чтобы получить доступ к атрибутам всех объектов класса DCC и их значениям. Атрибуты определяют, сколько в данное время существует объектов класса Device Interface.

Затем Менеджер использует сервис ACTION с соответствующим методом класса Communication Controller, чтобы получить доступ к атрибутам обязательно присутствующего объекта класса Device Interface MibElement. Количество атрибутов будет варьироваться, в случае, если у данного интерфейса присутствуют дополнительные объекты подклассов MibElement.

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

6.11.5 Динамически изменяющиеся связи между объектами

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

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

Пример - Модульный монитор состояния пациента моделируется объектом класса MDS. Модули измерений моделируются объектами класса VMD. Если к монитору подключается новый модуль, тут же образуется новая связь между объектом класса MDS и новым экземпляром объекта VMD.

Системы — коммуникационные агенты — использует определенные в настоящем стандарте сервисы, чтобы объявить о событиях изменения конфигурации прочим связанным системам. У этих систем-менеджеров изменяется представление о содержании базы данных MDIB системы-агента.

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

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

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

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

Пример на рисунке 6.15 показывает связь между классом Session Archive и классом MDS. Связь представлена классом. У этого класса есть атрибуты, которые отражают информацию, например, о времени установления соединения и разъединения.

Рисунок 6.15 — Пример представления связи классом

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

То, как динамически изменяющиеся связи объектов обрабатываются системами, которые соответствуют определениям в настоящем стандарте, определено в 6.11.5.1 и 6.11.5.2.

6.11.5.1 Динамически изменяющиеся связи между объектами в системах связи

Связи между экземплярами объектов, которые определены в моделях пакетов, содержат информацию об их (связей) конфигурации. Объект Context Scanner предоставляет информацию о конфигурации в форме уведомлений о создании объекта и удалении объекта в связи. Для систем связи не определены никакие средства для постоянного хранения полной информации о старой конфигурации.

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

6.11.5.2 Динамически изменяющиеся связи между объектами в архивных системах

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

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

7 Определения объектов DIM

7.1 Общие положения

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

7.1.1 Условное обозначение

Каждый объект описывается в отдельном подразделе (см. 7.2 - 7.10). Остальные подразделы описывают атрибуты, поведение и уведомления для объектов.

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

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

M — атрибут обязателен;

В подразделе Поведение описаны конкретные методы или функции, обеспечиваемые классом объекта. Данные методы можно активировать с помощью сервиса CMDISE ACTION.

События, создаваемые классом объекта (отличного от уведомления об изменении базового атрибута), описываются в подразделе Уведомления. Объект сообщает о данных событиях с помощью сервиса CMDISE EVENT REPORT (Отчет о событии элемента CMDISE).

7.1.2 Общие типы данных

Настоящий пункт описывает набор типов данных языка ASN.1, которые используются в определениях объектов.

7.1.2.1 Данные целого типа и данные типа строки бит

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

--

-- 8-битное беззнаковое целое число

--

INT-U8 ::= INTEGER (0..255)

--

-- 8-битное целое число со знаком

--

INT-I8 ::= INTEGER (-128..127)

--

-- 16-битное беззнаковое целое число

--

INT-U16 ::= INTEGER (0..65535)

--

-- 16-битное целое число со знаком

--

INT-I16 ::= INTEGER (-32768..32767)

--

-- 32-битное беззнаковое целое число

--

INT-U32 ::= INTEGER (0..4294967295)

--

-- 32-битное целое число со знаком

--

INT-I32 ::= INTEGER (-2147483648..2147483647)

--

-- 16-битная битовая строка

--

BITS-16 ::= BIT STRING (SIZE(16))

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

7.1.2.2 Идентификационный тип данных

Всем элементам (например, классам, объектам, типам измерений), которые требуют использования уникальной идентификации, присваивают идентификаторы OID. Набор действующих идентификаторов OID для данного стандарта описан в ИСО/ИИЭЭ 11073-10101. Номенклатура разделена на ряд сегментов, и каждый сегмент имеет свой диапазон 16-ти битных кодов. Другими словами, 16-ти битный код — это код, зависящий от контекста.

Тип 16-ти битных идентификационных данных представлен в следующем виде:

--

-- тип OID согласно указанному в номенклатуре

-- (не путать с OID языка ASN.1)

--

OID-Type ::= INT-U16 -- 16-битный целый тип

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

--

-- Личный OID

--

PrivateOid ::= INT-U16

7.1.2.3 Тип данных Описатель (Handle)

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

--

-- описатель

--

HANDLE ::= INT-U16

7.1.2.4 Тип данных Номер экземпляра (Instance number)

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

--

-- Номер экземпляра

--

InstNumber ::= INT-U16

7.1.2.5 Идентификация глобального объекта

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

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

Пример - Медицинский прибор может быть связан с другими медицинскими приборами (т.е. суб-приборами). В информационной базе MDIB данный прибор может моделировать эти суб-приборы в качестве отдельных объектов системы MDS с их собственным контекстом именования. Таким образом, конфликтов пространств имен (например, дублированные значения описателя, дублированные коды номенклатуры) можно избежать без переназначения значений описателя. Системе менеджера необходимо интерпретировать идентификаторы контекста системы MDS вместе со значениями описателя, чтобы уникально идентифицировать экземпляры объектов в рамках данной составной информационной базы MDIB. Идентификаторы контекста присваиваются, когда уведомления о создании объекта Context Scanner (Сканер контекста) формируют базу MDIB.

Предположения и возможные ограничения касательно различных контекстов именования в рамках базы MDIB не зависят от профиля. Тем не менее, они описаны в серии стандартов ИСО/ИИЭЭ Р11073-202хх.

7.1.2.6 Тип данных Идентификатор типа (Type ID)

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

7.1.2.7 Тип данных Утверждение значения атрибута (Attribute value assertion)

7.1.2.8 Тип данных Список атрибутов (Attribute list)

Зачастую необходим список пар значения идентификатор-атрибут. Тип данных Список атрибутов — это особый тип данных, который служит для данной ситуации и представлен следующим образом:

--

AttributeList ::= SEQUENCE OF AVA-Type

7.1.2.9 Тип данных Список идентификаторов атрибута (Attribute ID list)

Зачастую используется список идентификаторов атрибута. Тип данных Список идентификаторов атрибута — это особый тип данных, который обеспечивается для удобства и представлен следующим образом:

--

AttributeIdList ::= SEQUENCE OF OID-Type

7.1.2.10 Тип данных Тип с плавающей точкой (Floating point)

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

--

-- 32-битный тип с плавающей точкой; целый тип числа является лишь

-- символом-заполнителем

--

FLOAT-Type ::= INT-U32

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

7.1.2.11 Тип данных Относительное время (Relative time)

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

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

7.1.2.12 Тип данных Относительное время высокого разрешения (High-resolution relative time)

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

--

-- 64-битное (8 байтов) время высокого разрешения, LSB представляет собой 1 мкс

--

HighResRelativeTime ::= OCTET STRING (SIZE(8))

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

7.1.2.13 Тип данных Абсолютное время (Absolute time)

Тип данных Абсолютное время указывает на время дня с разрешением минимум 1 сек. В целях эффективности, значения в структуре закодированы в двоично-десятичный код (BCD) (т.е. 4-битные полубайты). Например, 1996 год представлен шестнадцатеричным значением 0x19 в поле век и шестнадцатеричным значением 0x96 в поле год. Данный формат можно легко перевести в представления, основанные на символах или целых числах. Тип данных абсолютного времени представлен следующим образом:

7.1.2.14 Тип данных дата (Date)

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

7.1.2.15 Тип данных Рабочее состояние (Operational state)

Тип данных Рабочее состояние определяет, активирован или деактивирован ли определенный объект или свойство. Определения берутся из ИСО/МЭК 10164-2 и представлены следующим образом:

--

OperationalState ::= INT-U16 {

disabled (0),

enabled (1),

notAvailable (2)

}

7.1.2.16 Тип данных Административное состояние (Administrative state)

Тип данных Административное состояние определяет, разблокирован или заблокирован ли определенный объект. Определения берутся из ИСО/МЭК 10164-2 и представлены следующим образом:

--

AdministrativeState ::= INT-U16 {

locked(0),

unlocked(1),

shuttingDown(2)

}

7.1.2.17 Тип данных Цвет (Colour)

Тип данных Цвет представляет собой основные RGB-цвета и представлен следующим образом:

7.1.2.18 Тип данных Локаль (Locale)

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

Поле Locale::language должно отображать представление по ИСО/МЭК 646 в нижнем регистре для двухсимвольного идентификационного кода языка из ISO 639-1 или ISO 639-2. Для удобства обработки идентификатор языка хранится в целочисленном 32-битном поле. Первый октет кода хранится в наиболее значимом байте данного поля. Неиспользуемые октеты в данном поле заполняются НУЛЕВЫМИ (NULL) байтами.

Пример -

Поле Locale::country должно отображать представление по ИСО/МЭК 646 в верхнем регистре двухсимвольного идентификационного кода языка из ISO 3166-1, ISO 3166-2 или ISO 3166-3. Для удобства обработки идентификатор языка хранится в целочисленном 32-битном поле. Первый октет кода хранится в наиболее значимом байте данного поля. Неиспользуемые октеты в данном поле заполняются НУЛЕВЫМИ (NULL) байтами.

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

Если страна не определена, в данном поле указывают 0.

Пример -

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

Для взаимодействия рекомендуется использовать схему кодирования символов iso-10646-ucs-2. Данная схема кодирования соответствует ИСО/МЭК 10646 с 2-октетным (т.е. 16 битов на символ) кодированием с обратным порядком байтов, которое представляет собой основную многоязыковую плоскость (BMP). Коды символов в рамках ИСО/МЭК 10646 прямо не соответствуют глифам, т.е. графическому представлению символа. ИСО/МЭК 10646 также не зависит от языка. Другие значения Locale::charset могут в значительной степени зависеть от языка, так как они также обозначают определенный набор символов.

7.1.2.19 Тип данных Ссылка на внешнюю номенклатуру (External nomenclature reference)

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

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

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

7.1.2.20 Тип данных Список связей с внешними объектами (External object relation list data type)

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

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

Примеры

1 В определенных ситуациях необходимо указать определенную производственную информацию (например, серийный номер) передатчика, который используется для проведения измерений. Передатчик не определен в настоящем стандарте как управляемый медицинский объект. Поэтому экземпляры объекта VMD используют запись о связи (отношении) для предоставления информации, например, {relation-type = is-connected; related-object = Transducer; relation-attributes = {model, «A-Model,» serial-number = «12345»}}.

2 Определенное числовое значение измерения подтверждается на соответствие медсестрой вручную. Таким образом, система построения графиков хранит в себе информацию о ручном подтверждении информации. Медсестра не смоделирована в настоящем стандарте как объект. Поэтому система построения графиков использует запись об отношении в качестве дополнительного атрибута объекта Numeric, например, {relation-type = validated-by; related-object = Nurse; relation-attributes = {name, «C. Smith,» date, «041295»}}.

Тип данных Список связей с внешними объектами очень сильная концепция для расширения информационной модели без определения дополнительных объектов.

7.2 Главный объект (базовый класс)

7.2.1 Атрибуты

Класс Главного объекта определяет атрибуты, указанные в таблице 7.1.

Таблица 7.1

Атрибуты класса главного объекта

Класс главного объекта не определяет никакие группы атрибутов.

7.2.2 Поведение

Класс главного объекта не определяет никакие специальные методы.

7.2.3 Уведомления

Класс главного объекта определяет события, указанные в таблице 7.2.

Таблица 7.2

События класс главного объекта

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

7.3 Объекты в Медицинском пакете

Определения объектов в Медицинском пакете указаны в пунктах 7.3.1 - 7.3.13.

7.3.1 VMO (Виртуальный медицинский объект)

7.3.1.1 Атрибуты

Класс объекта VMO определяет атрибуты, представленные в таблице 7.3.

Таблица 7.3

Атрибуты класса объекта VMO

В таблице 7.4 класс VMO определяет группы атрибутов или расширения для унаследованных групп атрибутов.

Таблица 7.4

Группы атрибутов класса VMO

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

7.3.1.2 Поведение

Объект VMO не определяет никакие конкретные методы.

7.3.1.3 Уведомления

Объект VMO не формирует никакие специальные уведомления.

7.3.2 Объект VMD (Виртуальный медицинский прибор)

7.3.2.1 Атрибуты

Класс объекта VMD определяет атрибуты, представленные в таблице 7.5.

Таблица 7.5

Атрибуты класса объекта VMD

Примечание - Идентификация и изменение атрибутов не требуются, если VMD не представляет компонент аппаратного обеспечения.

В таблице 7.6 класс объекта VMD описывает группы атрибутов и расширения к унаследованным группам атрибутов.

Таблица 7.6

Группы атрибутов класса объекта VMD

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

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

7.3.2.2 Поведение

Объект VMD не определяет никакие конкретные методы.

7.3.2.3 Уведомления

Объект VMD не формирует никакие конкретные уведомления.

7.3.3 Объект Channel (Канал)

7.3.3.1 Атрибуты

Объект Channel определяет атрибуты, представленные в таблице 7.7.

Таблица 7.7

Атрибуты класса объекта Channel

7.3.3.2 Поведение

7.3.3.3 Уведомления

Объект Канал не формирует никакие специальные уведомления.

7.3.4 Объект Metric (Метрика)

7.3.4.1 Атрибуты

В таблице 7.9 класс объекта Metric описывает атрибуты.

Таблица 7.9

Атрибуты класса объекта Metric

В таблице 7.10 класс объекта Metric описывает группу атрибутов или расширения унаследованных групп атрибутов.

7.3.4.2 Поведение

7.3.4.3 Уведомления

Объект Metric не формирует никакие конкретные уведомления.

7.3.5 Объект Numeric (Числовой показатель)

7.3.5.1 Атрибуты

Объект Numeric определяет атрибуты, представленные в таблице 7.11.

Таблица 7.11

Атрибуты класса объекта Numeric

В таблице 7.12 класс объекта Numeric описывает группу атрибутов или расширения унаследованных групп атрибутов.

Таблица 7.12

Группы атрибутов класса объекта Numeric

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

7.3.5.2 Поведение

Объект Numeric не описывает никакой конкретный метод.

7.3.5.3 Уведомления

Объект Numeric не формирует никакие конкретные уведомления.

7.3.6 Объект Sample Array (Массив выборок)

7.3.6.1 Атрибуты

Класс Объекта Sample Array определяет атрибуты, представленные в таблице 7.13.

Таблица 7.13

Атрибуты класса Объекта Sample Array

В таблице 7.14 класс объекта Sample Array описывает группу атрибутов или расширения унаследованных групп атрибутов.

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

7.3.6.2 Поведение

Объект Sample Array не описывает никакие конкретные методы.

7.3.6.3 Уведомления

Объект Sample Array не формирует никакие конкретные уведомления.

7.3.7 Объект Real Time Sample Array (Массив выборок в режиме реального времени)

7.3.7.1 Атрибуты

Класс объект Real Time Sample Array определяет атрибуты, представленные в таблице 7.15.

Таблица 7.15

Атрибуты класса объекта Real Time Sample Array

Примечание - Вместе с атрибутом Average-Reporting-Delay (Средняя задержка создания отчетов) можно использовать Атрибут Sample-Time-Sync (Синхронизация времени выборки) или HiRes-Sample-Time-Sync (Синхронизация времени выборки высокого разрешения), чтобы точно указать определенное время выборки. Отчеты об атрибутах Sample-Time-Sync и HiRes-Sample-Time-Sync должны поступать от сканера эпизодически:

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

См. также 6.7.5 для получения информации по определению класса объекта FastPeriCfgScanner.

В таблице 7.16 класс объекта Real Time Sample Array описывает группы атрибутов и расширения к унаследованным группам атрибутов.

Таблица 7.16

Группы атрибутов класса объекта Real Time Sample Array

Не применимы никакие дополнительные определения типа.

7.3.7.2 Поведение

Объект Массив выборок реального времени не описывает никакие конкретные методы.

7.3.7.3 Уведомления

Объект Массив выборок реального времени не формирует никакие конкретные уведомления.

7.3.8 Объект Time Sample Array (Временный массив выборок)

7.3.8.1 Атрибуты

Класс объекта Time Sample Array определяет атрибуты, представленные в таблице 7.17.

Таблица 7.17

Атрибуты класса объекта Time Sample Array

В таблице 7.18 класс объекта Time Sample Array описывает группы атрибутов и расширения к унаследованным группам атрибутов.

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

7.3.8.2 Поведение

Объект Массив выборок времени не описывает никакие конкретные методы.

7.3.8.3 Уведомления

Объект Массив выборок времени не формирует никакие конкретные уведомления.

7.3.9 Объект Distribution Sample Array (Распределенный массив выборок)

7.3.9.1 Атрибуты

Класс объекта Distribution Sample Array определяет атрибуты, представленные в таблице 7.19.

Класс объекта Distribution Sample Array описывает в таблице 7.20 группы атрибутов и расширения к унаследованным группам атрибутов.

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

7.3.9.2 Поведение

Объект Distribution Sample Array не описывает никакие конкретные методы.

7.3.9.3 Уведомления

Объект Distribution Sample Array не формирует никакие конкретные уведомления.

7.3.10 Объект Enumeration (Перечисление)

7.3.10.1 Атрибуты

В таблице 7.22 класс объекта Enumeration описывает группы атрибутов и расширения к унаследованным группам атрибутов.

Таблица 7.22

Группы атрибутов класса объекта Enumeration

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

7.3.10.2 Поведение

Объект Перечисление не описывает никакие конкретные методы.

7.3.10.3 Уведомления

Объект Перечисление не формирует никакие конкретные уведомления.

7.3.11 Объект Complex Metric (Комплексный метрический показатель)

7.3.11.1 Атрибуты

Класс Объекта Complex Metric определяет атрибуты, представленные в таблице 7.23.

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

7.3.11.2 Поведение

7.3.11.3 Уведомления

7.3.12 Объект PM-Store (Хранилище постоянной метрики)

7.3.12.1 Атрибуты

Класс объекта PM-Store определяет атрибуты, представленные в таблице 7.25.

Таблица 7.25

Атрибуты класса объекта PM-Store

Класс объекта PM-Store описывает в таблице 7.26 Группы атрибутов и расширения к унаследованным группам атрибутов.

Таблица 7.26

Группы атрибутов класса объекта PM-Store

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

7.3.12.2 Поведение

Объект PM-Store задает методы, представленные в таблице 7.27.

Таблица 7.27

7.3.12.3 Уведомления

7.3.13 Объект PM-Segment (Сегмент постоянной метрики)

7.3.13.1 Атрибуты

Класс объекта PM-Segment не обозначает никакую группу атрибутов.

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

--

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

-- Примечание — Данный формат может занимать много места в хранилище

--

SegDataGen ::= SEQUENCE OF AttributeList

--

-- Оптимизированный формат объекта Numeric для периодически приобретаемых

-- численных данных (numerics); хранится только действительное значение

--

SegDataNuOpt ::=SEQUENCE OF FLOAT-Type

--

-- Оптимизированный формат объекта Real Time Sample Array; последовательный

-- массив выборок

--

SegDataRtsaOpt ::= OCTET STRING

7.3.13.2 Поведение

Объект PM-Segment не описывает никакие конкретные методы.

7.3.13.3 Уведомления

Объект PM-Segment не формирует никакие конкретные уведомления.

7.4 Объекты в Пакете тревоги

Определения объектов в Пакете тревоги указаны в пунктах 7.4.1 - 7.4.3.

7.4.1 Объект Alert (Тревога)

7.4.1.1 Атрибуты

Класс объекта Alert определяет атрибуты, представленные в таблице 7.29.

Таблица 7.29

Атрибуты класса объекта Тревога

Примечание - Поле производного типа объекта VMO определяет является ли Тревога сигналом технического или физиологического характера.

В таблице 7.30 класс объекта Alert описывает группы атрибутов и расширения к унаследованным группам атрибутов.

Таблица 7.30

Группы атрибутов класса объекта Тревога

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

Примечание — Код alert-code берется из раздела номенклатуры событий. Записи (т.е. коды) в данном разделе — это четные числа. Последний бит кода используется для определения раздела номенклатуры, откуда берется al-source (в объекте Alert Monitor, см. 7.4.3.1). Если последний бит — 0, al-source берется из раздела номенклатуры метрики. Если последний бит — 1 (1 добавляется к основному коду в номенклатуре события), источник al-source — из раздела объектно-ориентированной номенклатуры.