ГОСТ Р 57299-2016 Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 10406. Специализация прибора: базовый электрокардиограф (ЭКГ c 1-3 отведениями)

ГОСТ Р 57299-2016/ISO/IEEE 11073-10406:2012

Группа П85

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

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

ИНФОРМАЦИОННОЕ ВЗАИМОДЕЙСТВИЕ С ПЕРСОНАЛЬНЫМИ МЕДИЦИНСКИМИ ПРИБОРАМИ

Часть 10406

Специализация прибора: базовый электрокардиограф (ЭКГ с 1-3 отведениями)

Health informatics. Point-of-care medical device communication. Part 10406. Device specialization. Basic electrocardiograph (ECG) (1- to 3-lead ECG)

ОКС 35.240.80

ОКСТУ 4002

Дата введения 2018-01-01

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному стандарту ISO/IEEE 11073-10406:2012* "Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 10406. Специализация прибора: базовый электрокардиограф (ЭКГ с 1-3 отведениями)" [ISO/IEEE 11073-10406:2012 "Health informatics - Point-of-care medical device communication - Part 10406: Device specialization - Basic electrocardiograph (ECG) (1- to 3-lead ECG)", IDT].

________________

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

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

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

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru*)

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

Настоящий стандарт IEEE (Институт инженеров по электротехнике и радиоэлектронике) может применяться с учетом важных примечаний и правовых оговорок. Эти примечания и оговорки указаны во всех публикациях, содержащих данный документ, и могут быть найдены в разделе "Важные примечания" или "Важные примечания и оговорки, касающиеся стандартов IEEE". Также их можно получить по запросу в IEEE или просмотреть на сайте http://standards.ieee.ors/IPR/disclaimers.html.

1 Обзор

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

В контексте серии стандартов ИСО/ИИЭР 11073, касающихся информационного взаимодействия с устройством, настоящий стандарт устанавливает стандартное определение взаимодействия между персональными приборами базового электрокардиографа (ЭКГ) и менеджерами (например, сотовыми телефонами, персональными компьютерами, персональными медицинскими приборами и дополнительными внешними устройствами) для обеспечения совместимости на основе автоматического конфигурирования. В нем задействуются соответствующие части существующих стандартов, включая терминологию стандарта ИСО/ИИЭР 11073 и информационные модели стандарта ИИЭР 11073-20601. Настоящий стандарт определяет использование определенных кодов терминов, форматов и поведений в среде телездравоохранения, ограничивая опции в основных структурах в пользу интероперабельности. Настоящий стандарт определяет общее ядро функционала коммуникаций для персональных приборов телездравоохранения базового ЭКГ (от 1 до 3 отведений ЭКГ). Приборы контроля (мониторинга) ЭКГ отличаются от диагностического оборудования ЭКГ включением поддержки носимых устройств ЭКГ, ограничением количества отведений, поддерживаемых оборудованием, до трех и отсутствием необходимости в способности аннотирования или анализа обнаруженной электрической активности с целью определения известных кардиальных явлений. Настоящий стандарт согласуется с основной структурой и допускает многофункциональные реализации, следуя множеству специализаций прибора (например, ЭКГ и частота дыхания).

1.2 Цель

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

1.3 Контекст

Общий обзор среды, в рамках которой был разработан настоящий стандарт, см. ИИЭР Std 11073-20601а.

Настоящий стандарт определяет специализацию прибора для базового ЭКГ (от 1 до 3 отведений), который является специальным типом агента, и содержит описание концепций прибора, его возможностей, а также его реализации (внедрения) в соответствии с настоящим стандартом.

Настоящий стандарт основан на стандарте ИИЭР Std 11073-20601а и ИСО/ИИЭР 11073-20601, который, в свою очередь, включает информацию из [А7] и [А8]. Правила кодирования медицинских приборов (MDER), использованные в настоящем стандарте, полностью описаны в ИСО/ИИЭР 11073-20601.

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

Примечания

1 Стандарт ИИЭР Std 11073-20601а является дополнением к стандарту ИСО/ИИЭР 11073-20601. Он содержит новый материал и поправки и не копирует содержание стандарта ИСО/ИИЭР 11073-20601. В настоящем стандарте ссылка на ИИЭР Std 11073-20601а относится к документу, полученному после применения нового материала и поправок к ИСО/ИИЭР 11073-20601.

_______________

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

2 В настоящем стандарте, чтобы привести ссылку на серию стандартов по специализации приборов, применяющих ИИЭР Std 11073-20601а, используется ИСО/ИИЭР 11073-104zz, где zz в ссылке может быть номером от 01 до 99, включительно.

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

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

_______________

* Таблицу соответствия национальных стандартов международным см. по ссылке. - .

IEEE Std 11073-20601а, Heаlth informatics - Personаl health device communication - Application profile - Optimized Exchange Protocol - Amendment 1 (Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Прикладной профиль. Оптимизированный протокол обмена. Поправка 1

_______________

Стандарты ИИЭР или документы, указанные в данном разделе, обладают товарным знаком Института инженеров по электротехнике и электронике. Публикации ИИЭР доступны в Институте инженеров по электротехнике и радиоэлектронике, Хоус-Лэйн, г.Пискатавэй, штат Нью-Джерси, 08854, США (http://stаndаrds.ieee.org/).

ISO/IEEE 11073-20601:2010, Heаlth informatics - Personаl heаlth device communication - Application profile - Optimized Eхchаnge Protocol (Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Прикладной профиль. Оптимизированный протокол обмена)

_______________

Публикации ИСО/ИИЭР имеются в Центральном секретариате ИСО, 1, ch. de lа Voie-Creuse, Case postаle 56, CH-1211, г.Женева 20, Швейцария (http//www.iso.ch/). Публикации ИСО/ИИЭР также имеются в США в Институте инженеров по электротехнике и электронике, 445 Хоус-Лейн, г.Пискатавэй, штат Нью-Джерси, 08854-4141, США (http://stаndаrds.ieee.org/).

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

3 Термины, определения и сокращения

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

В настоящем стандарте применяются следующие термины и определения. Для получения информации о терминах, не указанных в данном разделе, см. Глоссарий стандартов ИИЭР. Словарь терминов и определений (IEEE Standards Dictionary: Glossary of Terms & Definitions).

_______________

Глоссарий стандартов ИИЭР. Словарь терминов и определений (IEEE Standards Dictionary: Glossary of Terms & Definitions) имеется на сайте http://shop.ieee.org/.

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

3.1.2 класс (class): В объектно ориентированном моделировании он описывает атрибуты, методы и события, которые объекты инстанцируют из используемого класса.

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

3.1.4 электрод (electrode): Электрический датчик, соприкасающийся с определенной частью тела. Два или более электрода используются для определения напряжения сердечной деятельности. См.: отведение (lead).

3.1.5 описатель (handle): Беззначный 16-битный код, который является локально уникальным и определяет один из экземпляров объекта внутри агента.

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

3.1.7 питающий провод (lead wire): Кабель, подключенный между электродом и прибором-агентом.

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

3.1.9 описатель объекта (obj-handle): См. описатель (handle).

3.1.10 объект (object): В объектно ориентированном моделировании является особым экземпляром класса. Инстанцирование реализует атрибуты, методы и события из класса.

3.1.11 персональный медицинский прибор (personal health device): Прибор, используемый в персональной медицинской системе.

3.1.12 персональный прибор для телемедицины (personal telehealth device): См. персональный медицинский прибор (personal health device).

3.2 Сокращения

APDU - пакет данных протокола прикладного уровня;

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

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

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

EUI-64 - расширенный уникальный идентификатор (64 бита);

ICS - заявление о соответствии реализации;

MDC - информационное взаимодействие с медицинским прибором;

MDER - правила кодирования медицинских приборов;

MDS - система медицинских приборов;

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

PDU - блок данных протокола;

PHD - персональный медицинский прибор;

RT-SA - массив выборок в режиме реального времени;

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

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

4 Введение в ИСО/ИИЭР 11073 Персональные медицинские приборы

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

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

Стандарт ИИЭР Std 11073-20601а поддерживает моделирование и внедрение обширного множества персональных медицинских приборов. Настоящий стандарт определяет аспекты базового прибора ЭКГ (1-3 отведений ЭКГ). Он описывает все аспекты, необходимые для внедрения сервисов прикладного уровня и протокола обмена данными между агентом ИСО/ИИЭР 11073 PHD базового ЭКГ (1-3 отведений ЭКГ) и менеджером. Настоящий стандарт определяет подмножество объектов и функциональных возможностей, содержащихся в стандарте ИИЭР Std 11073-20601а, а также расширяет и дополняет это подмножество определениями там, где это необходимо. Все новые определения даны в приложении В на языке OSI для описания абстрактного синтаксиса (ASN.1). Номенклатурные коды, упомянутые в настоящем стандарте и не определенные в ИИЭР Std 11073-20601а, описаны в обязательном приложении С.

4.2 Введение в моделирующие конструкции ИСО/ИИЭР 11073-20601

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

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

4.2.2 Информационная модель предметной области

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

4.2.3 Сервисная модель

Сервисная модель определяет концептуальные механизмы для сервисов по обмену данными. Такие сервисы отображаются в сообщениях, которыми обмениваются агент и менеджер. Протокольные сообщения в рамках серии стандартов ИСО/ИИЭР 11073 определены на языке ASN.1. Сообщения, определенные в ИИЭР Std 11073-20601а, могут сосуществовать с сообщениями, определенными в других стандартных прикладных профилях, указанных в серии стандартов ИСО/ИИЭР 11073.

4.2.4 Коммуникационная модель

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

4.2.5 Внедрение моделей

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

4.3 Соответствие с другими стандартами

Приборам, которые соответствуют настоящему стандарту, возможно, будет необходимо соответствовать другим стандартам, ориентированным на прибор или домен, требования которых заменяют те, что указаны в настоящем стандарте, и затрагивают вопросы, включающие безопасность, надежность и управление рисками. Пользователь настоящего стандарта должен быть ознакомлен со всеми другими подобными применимыми стандартами и тем самым следить за соответствием любых спецификаций более высокого уровня. Как правило, медицинские приборы соответствуют базовым стандартам [А1] в части электромеханической безопасности и любым стандартам, ориентированным на прибор, которые могут быть определены в серии стандартов [А2]. Аспекты программного обеспечения могут быть применены посредством таких стандартов, как [A3]. Приборы, соответствующие настоящему стандарту, реализуют верхние уровни сетевого программного обеспечения и используют нижние уровни в зависимости от требований приложения. Требования к производительности таких приложений и соответствию определены в других стандартах и не входят в область применения настоящего стандарта. Кроме того, использование любого медицинского оборудования должно осуществляться с учетом оценки рисков и управления рисками, надлежащими для выбранного использования. Соответствующими примерами являются [А5] и [А4]. Требования к такой оценке рисков, управлению рисками и соответствию не входят в область распространения настоящего стандарта.

5 Механизм работы и способы воздействия базового ЭКГ (от 1 до 3 отведений)

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

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

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

5.2 Колебания ЭКГ

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

5.3 Интервал R-R

На рисунке 1 изображены сигнал базового ЭКГ и особые колебания, которые могут возникнуть, например, во время деполяризации предсердий (зубец P), деполяризации желудочков (комплекс QRS) и реполяризации желудочков (зубцы ST-T). Интервал R-R (интервал между ударами) - это мгновенное измерение, определяемое как промежуток времени между вершинами двух последовательных зубцов R (в начале деполяризации желудочков), как правило, выражается в миллисекундах или в подсчете частоты внутреннего осциллятора. Последнее используется с целью упрощения внедрения или поддержания высокой точности путем предотвращения ошибок при округлении, это рассматривается как импульсы и определяется в настоящем стандарте как количество импульсов в секунду. По существу, изменение интервала R-R выполняется с помощью датчика, который регистрирует момент времени каждого отдельного зубца R и затем вычисляет интервал между этими моментами.

Рисунок 1 - Основная форма сигнала ЭКГ

5.4 Частота сердечных сокращений

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

6 Информационная модель предметной области базового ЭКГ (от 1 до 3 отведений)

6.1 Краткое описание

Данный раздел описывает информационную модель домена базового ЭКГ (от 1 до 3 отведений).

6.2 Расширения класса

В настоящем стандарте расширения класса в отношении ИИЭР Std 11073-20601а не определены.

6.3 Диаграмма экземпляров объектов

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

Объекты DIM в соответствии с рисунком 2 описаны в подразделах 6.6-6.11. Они включают объекты системы медицинских приборов (MDS) (см. 6.6), числовые объекты (см. 6.7), объекты RT-SA (см. 6.8), объекты перечисления (см. 6.9), объекты PM-хранилища (см. 6.10) и объекты сканера (см. 6.11). См. 6.13 для получения правил расширения информационной модели базового ЭКГ (от 1 до 3 отведений) за пределы элементов в соответствии с описанием в настоящем стандарте. Каждый раздел, описывающий объект базового ЭКГ (от 1 до 3 отведений), содержит следующую информацию:

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

- атрибуты объекта. Каждый объект имеет атрибуты, которые предоставляют и передают информацию на физическом устройстве и его источнике данных. Каждый объект имеет идентификационный атрибут, который определяет экземпляр объекта внутри агента. Значения атрибута находятся в открытом доступе и преобразовываются при помощи таких методов, как GET и SET. Типы атрибутов заданы с помощью ASN.1. Значения ASN.1 для новых типов атрибутов, характерных для настоящего стандарта, указаны в приложении B, а значения ASN.1 для известных типов атрибутов, приведенных в ссылках в настоящем стандарте, описаны в стандарте ИИЭР Std 11073-20601а;

- методы, доступные на объекте;

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

- доступные сервисы, такие как получение или установка атрибутов.

Атрибуты для каждого класса определены в таблицах, которые указывают название атрибута, его значение, и его квалификатор. Существуют следующие значения квалификатора: M - атрибут обязательный, C - атрибут условный и зависит от условия, указанного в графе "Примечания" или "Значения" (если стандарт ИИЭР Std 11073-20601а приведен в ссылке, то он содержит условия), R - рекомендованный атрибут, NR - нерекомендованный атрибут, O - необязательный атрибут. Обязательные атрибуты должны выполняться агентом. Условные атрибуты должны выполняться, если условие применяется и может быть реализовано иным способом. Рекомендованные атрибуты должны выполняться агентом. Нерекомендованные атрибуты не должны выполняться агентом. Необязательные атрибуты могут быть выполнены агентом. Для атрибутов с квалификаторами, определенными как R или NR, должны соблюдаться основные требования, указанные в графах "Примечания" или "Значения" в ИИЭР Std 11073-20601а.

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

Рисунок 2 - Базовый ЭКГ (от 1 до 3 отведений). Информационная модель предменой области

6.4 Типы конфигураций

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

В соответствии с ИИЭР Std 11073-20601а существуют два типа конфигураций. Пункты 6.4.2 и 6.4.3 дают краткое описание стандартных и расширенных конфигураций.

6.4.2 Стандартная конфигурация

Стандартные конфигурации определены в конкретных спецификациях ИИЭР 11073-104zz (например, настоящий стандарт), им присвоен известный идентификатор (Dev-Configuration-Id). Использование стандартной конфигурации согласовывается агентом и менеджером в момент установления связи (ассоциации). Если менеджер опознает и выбирает работу с использованием конфигурации, то агент может отправлять измерения сразу. Если менеджер не опознает конфигурацию, то агент предоставляет конфигурацию до передачи измерительной информации. Модель DIM стандартной конфигурации, определенная в настоящем стандарте, описана в 6.5.3.

6.4.3 Расширенная конфигурация

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

6.5 Профили

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

Профиль содержит объекты, сервисы и коммуникационную модель специализации. Профилируя специализацию устройства, стандарт может предоставить больше указаний касательно специальных обязательных объектов, которые должны быть реализованы, объектов, являющихся необязательными, и объектов, которые не требуются. Настоящий стандарт определяет два профиля: простой профиль ЭКГ (см. 6.5.2) и профиль ЧСС (см. 6.5.3). Базовый прибор ЭКГ (от 1 до 3 отведений) должен реализовывать как минимум один из этих двух профилей.

6.5.2 Простой профиль ЭКГ

Диаграмма экземпляров метрического объекта информационной модели предметной области простого профиля ЭКГ изображена на рисунке 3. Базовый прибор ЭКГ (от 1 до 3 отведений), применяющий простой профиль ЭКГ, должен реализовывать от 1 до 3 объектов RT-SA колебаний ЭКГ. В данный момент для простого профиля ЭКГ не было определено ни одной стандартной конфигурации.

Рисунок 3 - Простой профиль ЭКГ. Метрические объекты

6.5.3 Профиль ЧСС

Диаграмма экземпляров метрического объекта информационной модели предметной области профиля ЧСС изображена на рисунке 4. Числовой объект ЧСС должен поддерживаться базовым прибором ЭКГ (от 1 до 3 отведений), реализующим профиль ЧСС.

Тогда и только тогда, когда агент поддерживает профиль ЧСС, он должен поддерживать стандартную конфигурацию со значением Dev-Configuration-ID 0x258. Информационная модель предметной области для данной стандартной конфигурации содержит отдельный числовой объект ЧСС. Соответствующая диаграмма экземпляров метрического объекта изображена на рисунке 5.

Рисунок 4 - Профиль ЧСС. Метрические объекты

Рисунок 5 - Профиль ЧСС. Стандартная конфигурация (0x258). Метрические объекты

6.6 Объект системы медицинских приборов

6.6.1 Атрибуты объекта MDS

В таблице 1 кратко определены объекты MDS базового ЭКГ (от 1 до 3 отведений). Номенклатурным кодом для идентификации класса MDS является MDC_MOC_VMS_MDS_SIMP.

Таблица 1 - Атрибуты объекта MDS

Примечание - См. ИИЭР Std 11073-20601а для получения информации о том, является ли атрибут статическим или динамическим.

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

См. ИИЭР Std 11073-20601а для получения описания и объяснения отдельных атрибутов, а также для информации об идентификаторе и типе атрибута.

Если агент реализует множественные специализации ИИЭР 11073-104zz, то перечень System-Type-Spec-List является перечислением пар тип/версия, каждая из которых ссылается на определенную специализацию прибора и версию данной специализации. Для агента базового ЭКГ (от 1 до 3 отведений) значение специализации MDC_DEV_SPEC_PROFILE_ECG должно быть включено в атрибут System-Type-Spec-List в соответствии с таблицей 1. Кроме того, значение для поддерживаемого профиля должны быть включены в атрибут System-Type-Spec-List. Значение профиля для агента базового ЭКГ (от 1 до 3 отведений), поддерживающего простой профиль ЭКГ, должно быть установлено в MDC_DEV_SUB_SPEC_PROFILE_ECG. Значение профиля для агента базового ЭКГ (от 1 до 3 отведений), поддерживающего профиль ЧСС, должно быть установлено в MDC_DEV_SUB_SPEC_PROFILE_HR.

Атрибут Dev-Configuration-Id содержит локально уникальный 16-битный идентификатор, который определяет конфигурацию прибора. Для агента базового ЭКГ (от 1 до 3 отведений) с расширенной конфигурацией данный идентификатор выбирается в пределах от extended-config-start до extended-config-end (см. ИИЭР Std 11073-20601а) в соответствии с таблицей 1.

Агент отправляет Dev-Configuration-Id во время ассоциированного состояния (см. 8.3) для идентификации своей конфигурации на весь период проведения ассоциации. Если менеджер уже обладает информацией о конфигурации, относящейся к Dev-Configuration-Id, он опознает Dev-Configuration-Id и пропускает конфигурирующее состояние (см. 8.4), затем агент и менеджер переходят в рабочее состояние. Если менеджер не опознает Dev-Configuration-Id, то агент и менеджер переходят в состояние конфигурации.

6.6.2 Атрибут Tick-Resolution

Атрибут Tick-Resolution устанавливает разрешение для внутреннего осциллятора агента и предоставляет информацию о том, когда соответствующий атрибут Unit-Code эквивалентен MDC_DIM_TICK, что является дополнительной возможностью при измерении интервала R-R (см. 6.7.3).

Таблица 2 дает определение атрибута Tick-Resolution.

Таблица 2 - Базовый ЭКГ (от 1 до 3 отведений). Атрибут Tick-Resolution

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

6.6.3 Методы объектов MDS

В таблице 3 определены методы (действия) объекта MDS. Данные методы применяются с помощью сервиса Action. В таблице 3 графа "Наименование типа подсервиса" определяет название метода; графа "Режим" определяет, применен ли метод в качестве неподтвержденного действия (т.е. roiv-cmip-action из ИИЭР Std 11073-20601a) или подтвержденного действия (т.е. roiv-cmip-confirmed-action); графа "Тип подсервиса" [action-type (тип действия)] определяет номенклатурный код, который должен быть использован в поле action-type или запросе и ответе на действие (см. ИИЭР Std 11073-20601a); графа "Параметры" (action-info-args) определяет связанную структуру данных ASN.1 (см. ИИЭР Std 11073-20601a для получения значений ASN.1), которая должна использоваться в сообщении о действии, в поле запроса action-info-args; графа "Результаты" (action-info-args) определяет структуру, которая должна использоваться в action-info-args ответа.

Таблица 3 - Методы объектов MDS

- Set-Time

Данный метод позволяет менеджеру устанавливать датчик истинного времени в агенте с абсолютным временем. Агент указывает, применима ли команда Set-Time с помощью бита mds-time-capab-set-clock в атрибуте Mds-Time-Info (см. ИИЭР Std 11073-20601a).

Если агент поддерживает атрибут Absolute-Time-Stamp, данный метод должен быть выполнен.

- Set-Base-Offset-Time

Данный метод позволяет менеджеру устанавливать датчик истинного времени в агенте с основным временем и смещением. Агент указывает, применима ли команда Set-Base-Offset-Time с помощью бита mds-time-capab-set-clock в атрибуте Mds-Time-Info (см. ИИЭР Std 11073-20601a).

Если агент поддерживает атрибут Base-Offset-Time-Stamp, должен быть выполнен данный метод.

Агенты, следующие только данной и никакой другой специализации прибора, должны отправлять отчеты о событии, используя передачу данных измерения, инициированную агентом. Агенты, следующие как данной, так и другой специализации прибора, должны отправлять отчеты о событии соответствующим способом. В процессе ассоциации (см. 8.3) data-req-mode-capab должен быть установлен в значение, соответствующее типу отчета о событии. В результате менеджер должен принять, что агент базового ЭКГ (от 1 до 3 отведений) не поддерживает никаких функций MDS-Data-Request (см. ИИЭР Std 11073-20601a для получения дополнительной информации). Таким образом, выполнение метода/дейтвия MDS-Data-Request не требуется в настоящем стандарте и не указано в таблице 3.

6.6.4 События объектов MDS

В таблице 4 определены события, которые могут быть отправлены объектом MDS базового ЭКГ (от 1 до 3 отведений).

Таблица 4 - События объектов MDS базового ЭКГ (от 1 до 3 отведений)

- MDS-Configuration-Event

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

- MDS-Dynamic-Data-Update-Var

Данное событие предоставляет динамические данные измерений от агента базового ЭКГ (от 1 до 3 отведений) для числовых объектов и объектов перечисления. Эти данные передаются в формате переменной списка общих атрибутов. Событие отправляется агентом как незапрашиваемое сообщение (т.е. передача данных измерений, инициированная агентом). См. 8.5.3 для получения более подробной информации о предоставлении отчетов по незапрашиваемым событиям.

- MDS-Dynamic-Data-Update-Fixed

Данное событие предоставляет динамические данные измерений от агента базового ЭКГ (от 1 до 3 отведений) для числовых объектов и объектов перечисления. Такие данные передаются в фиксированном формате, определяемом атрибутом объектов Attribute-Value-Map. Событие отправляется агентом как незапрашиваемое сообщение (т.е. передача данных измерений, инициированная агентом). См. 8.5.3 для получения более подробной информации о предоставлении отчетов по незапрашиваемым событиям.

- MDS-Dynamic-Data-Update-MP-Var

То же, что и MDS-Dynamic-Data-Update-Var, но позволяет включение данных, полученных от разных людей.

- MDS-Dynamic-Data-Update-MP-Fixed

То же, что и MDS-Dynamic-Data-Update-Fixed, но позволяет включение данных, полученных от разных людей.

Примечание - В соответствии с ИИЭР Std 11073-20601a требуется, чтобы менеджеры поддерживали все события объектов MDS, перечисленные выше.

6.6.5 Другие сервисы MDS

6.6.5.1 Сервис GET

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

Менеджер может отправить запрос на атрибут объекта MDS агенту базового ЭКГ (от 1 до 3 отведений); в этом случае, менеджер должен отправить сообщение "Remote Operation Invoke|Get" (см. roiv-cmip-get в ИИЭР Std 11073-20601a) с сохраненным значением идентификатора MDS, равным 0. Агент базового ЭКГ (от 1 до 3 отведений) должен отправить отчет о своих атрибутах объекта MDS менеджеру с помощью сообщения "Remote Operation Response|Get" (см. rors-cmip-get в ИИЭР Std 11073-20601a). См. таблицу 5 для получения краткого описания сервиса GET, включая некоторые поля сообщений.

Таблица 5 - Сервис GET объектов MDS базового ЭКГ (от 1 до 3 отведений)

См. 8.5.2 для получения подробной информации о порядке получения атрибутов объекта MDS.

6.6.5.2 Сервис SET

Специализация базового ЭКГ (от 1 до 3 отведений) не требует реализации для поддержки сервиса SET объекта MDS.

6.7 Числовые объекты

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

Информационная модель предметной области базового ЭКГ (от 1 до 3 отведений) для метрических объектов (см. рисунок 2) содержит два числовых объекта для ЧСС и интервала R-R. Числовой объект ЧСС описан в 6.7.2. Числовой объект интервала R-R описан в разделе 6.7.3.

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

6.7.2 Частота сердечных сокращений

Таблица 6 кратко описывает атрибуты числовых объектов ЧСС. Если значение Dev-Configuration-Id агента установлено на 0x258, числовой объект ЧСС должен быть реализован. Номенклатурным кодом для идентификации числового класса является MDC_MOC_VMO_METRIC_NU.

Таблица 6 - Атрибуты числовых объектов ЧСС

Примечания

1 См. ИИЭР Std 11073-20601а для получения информации о том, является ли атрибут статическим или динамическим.

2 Нет указаний о том, на каком отведении производится измерение ЧСС.

Для агента базового ЭКГ (от 1 до 3 отведений) со стандартной конфигурацией структура AttrValMap (см. ИИЭР Std 11073-20601а) атрибута Attribute-Value-Map должна содержать идентификатор атрибута и информацию о длине атрибута значения Basic-Nu-Observed-Value в соответствии с таблицей 6.

Если измерение ЧСС представляет собой мгновенную частоту сердечных сокращений, то атрибут Type (Тип) должен быть установлен в {MDC_PART_PHD_DIM|MDC_ECG_HEART_RATE_INSTANT}. В ином случае измерение ЧСС представляет собой среднее значение, и атрибут Type должен быть установлен в {MDC_PART_SCADA|MDC_ECG_HEART_RATE_INSTANT} без дальнейшего уточнения усредняющей функции.

Атрибут Metric-Spec-Small используется для определения методов специальных измерений ЧСС. Если частота сердечных сокращений представляет собой измерение от удара к удару, то биты mss-msmt-btb-metric, а также the mss-msmt-aperiodic должны быть установлены для атрибута Metric-Spec-Small.

Числовые объекты ЧСС не поддерживают никаких методов, событий или других сервисов.

См. ИИЭР Std 11073-20601а для получения описания и объяснения отдельных атрибутов, а также для информации об идентификаторе и типе атрибута.

6.7.3 Интервал R-R

В таблице 7 дано краткое описание атрибутов числовых объектов интервала R-R. Номенклатурным кодом для идентификации числового класса является MDC_MOC_VMO_METRIC_NU.

Таблица 7 - Атрибуты числовых объектов интервала R-R

Примечания

1 См. ИИЭР Std 11073-20601а для получения информации о том, является ли атрибут статическим или динамическим.

2 Нет указаний о том, на каком отведении производится измерение ЧСС.

Так как интервал R-R представляет собой измерение мгновенного значения, проводимого по принципу от удара к удару, биты mss-msmt-btb-metric, а также mss-msmt-aperiodic должны быть установлены для атрибута Metric-Spec-Small.

Если используется MDC_DIM_TICK для Unit-Code, разрешение импульса агента для измерения интервала R-R определяется атрибутом Tick-Resolution объекта MDS (см. таблицу 1).

Числовой объект интервала R-R не поддерживают никаких методов, событий или других сервисов.

См. ИИЭР Std 11073-20601а для получения описания и объяснения отдельных атрибутов, а также для информации об идентификаторе и типе атрибута.

6.8 Объекты массива выборок в режиме реального времени (RT-SA)

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

Информационная модель предметной области базового ЭКГ (от 1 до 3 отведений) для метрических объектов (см. рисунок 2) содержит объекты RT-SA для данных по колебаниям ЭКГ.

6.8.2 Колебания ЭКГ

Колебания ЭКГ передаются в виде серии образцов, где каждое колебание представлено как отдельный объект.

В таблице 8 дано краткое описание атрибутов объектов RT-SA колебаний ЭКГ. Номенклатурным кодом для идентификации числового класса является MDC_MOC_VMO_METRIC_SA_RT.

Таблица 8 - Атрибуты объектов RT-SA колебаний ЭКГ

Примечание - См. ИИЭР Std 11073-20601а для получения информации о том, является ли атрибут статическим или динамическим.

Для атрибута Type должен быть использован один из номенклатурных кодов, указанных в таблице 9.

Таблица 9 - Типы измерений отведений ЭКГ

Данные по колебаниям ЭКГ должны быть доступны только через объекты сканера. Соответственно, бит mss-acc-manager и бит mss-acc-agent-initiated в атрибуте Metric-Spec-Small должны быть равны нулю (см. таблицу 8).

6.9 Объекты перечисления

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

Информационная модель предметной области базового ЭКГ (от 1 до 3 отведений) содержит два объекта перечисления.

Числовые объекты состояния прибора описаны в 6.9.2. Объекты перечисления триггера контекстных данных описаны в 6.9.3.

6.9.2 Состояние прибора

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

Таблица 10 - Атрибуты объектов перечисления состояния прибора

Примечание - См. ИИЭР Std 11073-20601а для получения информации о том, является ли атрибут статическим или динамическим.

Так как данные объекты являются флажками событий, атрибут Unit-Code не подходит для них. Аналогично Source-Handle-Reference является неподходящим, так как данный объект контролирует состояние оборудования.

Для явного выражения наличия события, связанного с прибором, соответствующие биты в атрибуте Enum-Observed-Value-Basic-Bit-Str должны быть установлены в соответствии с определением в таблице 11. Если менеджер поддерживает интерпретацию данного объекта, он должен быть способен интерпретировать полный набор представленных состояний, описанных в таблице 11. Агенту не требуется внедрять все функции, определенные в таблице 11. Каждый раз, когда состояние изменяется для любых контролируемых условий, агент должен отправить отчет обо всех контролируемых условиях. Обратите внимание на то, что менеджер должен интерпретировать эти биты только в пределах контекста этих атрибутов и только в рамках специализации этого прибора, так как другие специализации могут содержать соответствующие термины для других целей.

Таблица 11 - Отображение состояния прибора, отведения и сигнала на атрибут объекта Bit-Str

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

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

6.9.3 Запуск контекстных данных

Объекты перечисления запуска контекстных данных сообщают пользователю о том, почему были переданы сегменты данных измерений колебаний ЭКГ, ЧСС или интервала R-R, например, по причине нажатия кнопки пользователем или возникновения автоматического события, вызванного механизмом анализа данных в агенте (например, в случае обнаружения кардиального события). Номенклатурным кодом для идентификации класса объекта перечисления является MDC_MOC_VMO_METRIC_ENUM. Для получения информации по набору атрибутов по данному объекту см. таблицу 12.

Таблица 12 - Атрибуты объектов перечисления запуска контекстных данных

Примечание - См. ИИЭР Std 11073-20601а для получения информации о том, является ли атрибут статическим или динамическим.

Для Enum-Observed-Value-Simple-OID должны использоваться коды, определенные в таблице 13.

Таблица 13 - Номенклатурные коды для запуска контекстных данных

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

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

6.10 Объекты PM-хранилища

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

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

Для того чтобы соответствовать широкому ряду приборов разного уровня сложности и с разными наборами функций, настоящий стандарт поддерживает передачу временно хранимых данных, инициированную агентом, передачу потоковых данных с помощью объектов сканирования, а также передачу данных, записанных в PM-хранилище, инициированную менеджером. Любая конфигурация, в которую не входит PM-хранилище, должна использовать отчеты о событиях, инициированные агентом, или объекты сканирования для передачи результатов измерений или наблюдений. Использование временно хранимых данных в соответствии с определением в ИИЭР Std 11073-20601а наиболее эффективно при небольшом количестве измерений а сами данные подлежат автоматическому удалению сразу после загрузки. Как альтернативное решение любая конфигурация PM-хранилища для более долгого хранения должна блокировать передачу данных, инициированную агентом, а также использование объектов сканирования и поддерживать передачу данных, записанных в PM-хранилище, инициированную менеджером.

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

6.10.2 Модель постоянного хранилища

Модель PM-хранилища, определенная в настоящем стандарте, использует два дополнительных объекта PM-хранилища, а именно периодический объект PM-хранилища для постоянного хранения периодических данных, таких как измерения колебаний ЭКГ или периодические измерения ЧСС, и апериодический объект PM-хранилища для апериодических данных, связанных, например, с перечислениями состояний прибора (рисунок 6). Обратите внимание на то, что объект PM-хранилища не является частью стандартных конфигураций, определенных в настоящем стандарте. Агент, поддерживающий PM-хранилище, которое имеет значение типа, установленное в DEV_SUB_SPEC_PROFILE_ECG, должен использовать периодический объект PM-хранилища.

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

Рисунок 6 - Базовый ЭКГ (от 1 до 3 отведений). Модель постоянного хранилища

Рисунок 7 - Периодическое PM-хранилище с множеством сеансов данных по колебаниям для базового ЭКГ с тремя отведениями. Пример

6.10.3 Периодические объекты

В таблице 14 дано краткое описание атрибутов периодических объектов PM-хранилища. Номенклатурным кодом для идентификации объектов PM-хранилища является MDC_MOC_VMO_PMSTORE.

Таблица 14 - Атрибуты периодических объектов PM-хранилища

Атрибут PM-Store-Capab должен устанавливать следующие биты в соответствии с указанием:

- pmsc-var-no-of-segm

Если агент создает новые сегменты вследствие хранения данных от множества сеансов или изменениями во времени в соответствии с описанием в разделе "Сопоставимое время" в ИИЭР Std 11073-20601a, то бит pmsc-var-no-of-segm должен быть установлен;

- pmsc-epi-seg-entries

Бит pmsc-epi-seg-entries не должен устанавливаться;

- pmsc-peri-seg-entries

Бит pmsc-peri-seg-entries должен устанавливаться.

Оставшиеся биты атрибута PM-Store-Capab являются строго определенными для агента и должны устанавливаться соответствующим образом.

Примечания

1 См. ИИЭР Std 11073-20601a для получения информации о том, является ли атрибут статическим или динамическим.

2 См. 6.3 для получения описания квалификаторов.

6.10.4 Непериодические объекты

В таблице 15 дано краткое описание атрибутов непериодических объектов PM-хранилища. Номенклатурным кодом для идентификации объектов PM-хранилища является MDC_MOC_VMO_ PMSTORE.

Таблица 15 - Атрибуты непериодических объектов PM-хранилища

Атрибут PM-Store-Capab должен устанавливать следующие биты в соответствии с указанием:

- pmsc-var-no-of-segm

Если агент создает новые сегменты вследствие хранения данных от множества сеансов или изменениями во времени в соответствии с описанием в разделе "Сопоставимое время" в ИИЭР Std 11073-20601a, то бит pmsc-var-no-of-segm должен быть установлен;

- pmsc-epi-seg-entries

Бит pmsc-epi-seg-entries должен устанавливаться;

- pmsc-peri-seg-entries

Бит pmsc-peri-seg-entries не должен устанавливаться.

Оставшиеся биты атрибута PM-Store-Capab являются строго определенными для агента и должны устанавливаться соответствующим образом.

Примечания

1 См. ИИЭР Std 11073-20601a для получения информации о том, является ли атрибут статическим или динамическим.

2 См. 6.3 для получения описания квалификаторов.

6.10.5 Методы объекта PM-хранилища

Данный подраздел применяется как к периодическим, так и к апериодическим объектам PM-хранилища. В таблице 16 дано определение методов объекта PM-хранилища.

Таблица 16 - Методы объекта PM-хранилища

- Clear-Segments

Данный метод позволяет менеджеру удалять все записи данных, находящиеся в объекте PM-сегмента. Агент должен поддерживать метод Clear-Segments путем установки бита pmsc-clear-segm-by-all-sup для атрибута PM-Store-Capab. Удаление PM-сегмента не гарантированно данным методом. См. ИИЭР Std 11073-20601a для получения информации о том, как агент должен отвечать в случае, если он решает защитить определенные сегменты от удаления.

- Get-Segment-Info

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

- Trig-Segment-Data-Xfer

Данный метод позволяет менеджеру инициировать передачу записей данных, находящихся в объекте PM-сегмента. Для получения подробной информации см. ИИЭР Std 11073-20601a.

6.10.6 События объекта PM-хранилища

Данный подраздел применяется как к периодическим, так и к апериодическим объектам PM-хранилища. В таблице 17 дано определение событий объектов PM-хранилища.

Таблица 17 - События объекта PM-хранилища

- Segment-Data-Event

Данное событие позволяет агенту отправлять записи данных, находящиеся в объекте PM-сегмента. Данное событие вызывается менеджером с помощью действия Trig-Segment-Data-Xfer action. Для получения подробной информации см. ИИЭР Std 11073-20601a.

6.10.7 Сервисы объекта PM-хранилища

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

Данный подраздел применяется как к периодическим, так и к апериодическим объектам PM- хранилища.

6.10.7.2 Сервис GET

Сервис GET должен предоставляться агентом, реализующим объекты PM-хранилища. Данный сервис должен быть доступен только тогда, когда агент находится в рабочем состоянии. Для получения подробной информации см. ИИЭР Std 11073-20601a.

6.10.7.3 Сервис SET

В настоящий момент в настоящем стандарте не определен ни один сервис SET для объекта PM- хранилища.

6.10.8 Объекты PM-сегмента

6.10.8.1 Периодический сеанс

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

Таблица 18 - Атрибуты объекта PM-сегмента периодического сеанса

Примечания

1 См. ИИЭР Std 11073-20601а для получения информации о том, является ли атрибут статическим или динамическим.

2 См. 6.3 для получения описания квалификаторов.

Если агент не выполняет атрибут Sample-Period периодического объекта PM-сегмента, то он должен выполнить атрибут Sample-Period объекта PM-сегмента периодического сеанса. Если агент выполняет атрибут Sample-Period периодического объекта PM-хранилища, то он не должен выполнять атрибут Sample-Period объектов PM-сегмента периодического сеанса. Для каждого выполненного объекта PM-сегмента периодического сеанса агент должен выполнять либо атрибуты Segment-Start-Abs-Time и Segment-End-Abs-Time, либо атрибуты Segment-Start-BO-Time и Segment-End-BO-Time. Если используются атрибуты Segment-Start-Abs-Time и Segment-End-Abs-Time, тогда в записях PM-сегмента должны использоваться абсолютные значения времени. Если используются атрибуты Segment-Start-BO-Time и Segment-End-BO-Time, то в записях PM-сегмента должны использоваться значения времени со смещением по базе.

Атрибут Fixed-Segment-Data служит в качестве накопителя для хранимых результатов измерений или наблюдений. Когда передается атрибут Fixed-Segment-Data, все записи в отчете о событиях форматируются в соответствии с PM-Segment-Entry-Map. Каждая запись содержит дополнительный заголовок и один или более элементов. Каждый элемент хранит данные одного или нескольких метрических измерений.

6.10.8.2 Непериодический сеанс

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

Таблица 19 - Атрибуты объекта PM-сегмента непериодического сеанса

Примечания

1 См. ИИЭР Std 11073-20601а для получения информации о том, является ли атрибут статическим или динамическим.

2 См. 6.3 для получения описания квалификаторов.

Для каждого выполненного объекта PM-сегмента непериодического сеанса агент должен выполнять либо атрибуты Segment-Start-Abs-Time и Segment-End-Abs-Time, либо атрибуты Segment-Start-BO-Time и Segment-End-BO-Time. Для каждой записи в реализованном непериодическом объекте PM-сегмента агент должен включать один из форматов времени в segm-entry-header.

Атрибут Fixed-Segment-Data служит в качестве накопителя для хранимых результатов измерений или наблюдений. Когда передается атрибут Fixed-Segment-Data, все записи в отчете о событиях форматируются в соответствии со схемой PM-Segment-Entry-Map. Каждая запись содержит дополнительный заголовок и один или более элементов. Каждый элемент хранит данныет одного или нескольких метрических измерений.

6.11 Объекты сканера

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

Класс объектов сканера - это мощная структура, которая обеспечивает надлежащую группировку нескольких изменений значений атрибутов одного или нескольких метрических объектов в один отчет о событиях, делая это более эффективным способом, чем использование события MDS. Использование сканирования может быть как эпизодическим, так и периодическим. Оно также бывает полезным для сообщения продолжительного характера оповещений, выраженного в рамках объектов перечисления, так как объекты сканера могут периодически отправлять отчеты о событии сканирования, посвященные определенной части записи статуса, когда период, сообщенный в атрибуте Reporting-Interval, истекает. Информационная модель структуры сканера показана на рисунке 8 и содержит два дополнительных объекта сканера. Объекты PeriCfgScanner используются для отправки отчетов, содержащих периодические данные. Объекты EpiCfgScanner используются для отправки отчетов, содержащих эпизодические данные, т.е. данные, не имеющие установленного периода времени между каждым значением данных. Следует учесть, что эти периодические объекты и объекты эпизодического конфигурируемого сканера не являются частью стандартной конфигурации, определенной в настоящем стандарте.

Рисунок 8 - Базовый ЭКГ (от 1 до 3 отведений). Модель сканера

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

Рисунок 9 - Структура данных периодического конфигурируемого сканера для базового ЭКГ с тремя отведениями. Пример

Так как ИИЭР Std 11073-20601а содержит требование о том, что менеджеру необходимо поддерживать отчеты о событиях в группированном формате, менеджер должен поддерживать интерпретацию этого класса объекта, если агент передает данные с помощью периодического объекта сканера. В ином случае, если агент представляет основную часть своих данных с помощью объектов сканирования, менеджер не может получить данные, представленные таким агентом.

6.11.2 Атрибуты объекта периодического конфигурируемого сканера

В таблице 20 показаны атрибуты, применимые к объекту периодического конфигурируемого сканера. Номенклатурным кодом для идентификации класса объекта периодического конфигурируемого сканера является MDC_MOC_SCAN_CFG_PERI.

Таблица 20 - Атрибуты объекта периодического конфигурируемого сканера

Примечания

1 См. ИИЭР Std 11073-20601а для получения информации о том, является ли атрибут статическим или динамическим.

2 См. 6.3 для получения описания квалификаторов.

Что касается атрибута Confirm-Mode, агент может поддерживать подтвержденные и/или неподтвержденные отчеты сканирования; менеджер должен поддерживать как подтвержденные, так и неподтвержденные отчеты сканирования.

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

В таблице 21 определены события, отправленные объектом периодического конфигурируемого сканера агента базового ЭКГ (от 1 до 3 отведений).

Таблица 21 - События объекта периодического конфигурируемого сканера

Агенты, которые внедряют периодический конфигурируемый сканер, должны поддерживать сервис SET для атрибута Operational-State, указанного в таблице 20.

6.11.3 Атрибуты объекта эпизодического конфигурируемого сканера

В таблице 22 показаны атрибуты, применимые к объекту эпизодического конфигурируемого сканера. Номенклатурным кодом для идентификации класса объекта эпизодического конфигурируемого сканера является MDC_MOC_SCAN_CFG_EPI.

Таблица 22 - Атрибуты объекта эпизодического конфигурируемого сканера

Примечания

1 См. ИИЭР Std 11073-20601a для получения информации о том, является ли атрибут статическим или динамическим.

2 См. 6.3 для получения описания квалификаторов.

Касательно атрибута Confirm-Mode агент может поддерживать подтвержденные и/или неподтвержденные отчеты сканирования; менеджер должен поддерживать как подтвержденные, так и неподтвержденные отчеты сканирования.

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

В таблице 23 определены события, отправленные объектом эпизодического конфигурируемого сканера агента базового ЭКГ (от 1 до 3 отведений).

Таблица 23 - События объекта эпизодического конфигурируемого сканера

Агенты, которые реализовывают периодический конфигурируемый сканер, должны поддерживать сервис SET для атрибута Operational-State, указанного в таблице 22.

6.12 Объекты расширения класса

В настоящем стандарте не определено никаких объектов расширения класса относительно ИИЭР Std 11073-20601a.

6.13 Правила расширения информационной модели базового ЭКГ (от 1 до 3 отведений)

Информационная модель предметной области базового ЭКГ (от 1 до 3 отведений) настоящего стандарта может быть расширена путем включения элементов, определенных в ИИЭР Std 11073-20601a, а также элементов, специфических для производителя. Любые выполненные расширения объекта или атрибута должны соответствовать указаниям настоящего стандарта как можно точнее.

Агент базового ЭКГ (от 1 до 3 отведений), имеющий конфигурацию с расширениями, выходящими за рамки стандартной конфигурации, в соответствии с указаниями в настоящем стандарте должен использовать идентификатор конфигурации из ряда идентификаторов, предназначенных для расширенных конфигураций (см. ИИЭР Std 11073-20601a).

7 Модель сервиса базового ЭКГ (от 1 до 3 отведений)

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

Модель сервиса определяет концептуальные механизмы для сервисов обмена данными. Такие сервисы отображаются в сообщениях, которыми обмениваются клиент и менеджер. Протокольные сообщения в рамках серии стандартов ИСО/ИИЭР 11073 определены на ASN.1. Для получения подробного описания модели сервиса персонального медицинского прибора см. ИИЭР Std 11073-20601a. Подразделы 7.2 и 7.3 определяют особенности сервисов доступа к объектам и предоставления отчетов о событиях для агента базового ЭКГ (от 1 до 3 отведений) в соответствии с данным стандартом.

7.2 Сервисы доступа к объектам

Сервисы доступа к объектам ИИЭР Std 11073-20601a используются для получения доступа к объектам, определенным в информационной модели предметной области базового ЭКГ (от 1 до 3 отведений).

Следующие универсальные сервисы для доступа к объектам поддерживаются агентом базового ЭКГ (от 1 до 3 отведений) в соответствии с данным стандартом:

- сервис GET: используется менеджером для извлечения значений атрибутов объекта агента MDS или PM-хранилища. Перечень атрибутов базового ЭКГ (от 1 до 3 отведений) приведен в 6.6.1 для объектов MDS и в 6.10.3, а также в 6.10.4 для объектов PM-хранилища;

- сервис SET: используется менеджером для установки значений атрибутов объекта агента. Для агента базового ЭКГ (от 1 до 3 отведений) в соответствии с данным стандартом атрибуты Operational-State, указанные в таблице 20 и таблице 22 атрибутов объектов периодического конфигурируемого сканера и эпизодического конфигурируемого сканера, являются единственными устанавливаемыми атрибутами;

- сервисы отчетов о событии: используются агентом для отправки отчетов о конфигурации и данных измерений менеджеру. Перечень отчетов о событиях для специализации прибора базового ЭКГ (от 1 до 3 отведений) приведен в 6.6.4 для объектов MDS, в 6.10.6 для объектов PM-хранилища и в 6.11.2 и 6.11.3 для объектов сканера;

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

В таблице 24 дано краткое описание сервисов доступа к объектам, описанных в настоящем стандарте.

Таблица 24 - Сервисы доступа к объектам базового ЭКГ (от 1 до 3 отведений)

7.3 Сервисы отчетов о событиях доступа к объектам

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

Следующие условия применяются только к агенту базового ЭКГ (от 1 до 3 отведений) в соответствии с данным стандартом:

- отчеты о событиях MDS должны использоваться в подтвержденном режиме;

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

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

Агент базового ЭКГ (от 1 до 3 отведений), предназначенный для работы в среде, в которой данные могут собираться от множества людей, может использовать один из стилей отчетов о событиях "от множества людей" для передачи всех данных от каждого человеку в единичном событии. Если данная функция не требуется, агент может использовать стиль отчета о событиях "от одного человека", который снижает перегрузку.

Менеджер должен поддерживать отчеты о событиях как "от множества людей", так и "от одного человека". Агент базового ЭКГ (от 1 до 3 отведений) может поддерживать как один из типов отчета о событиях ("от множества людей" и "от одного человека"), так и оба этих типа. Форматы таких отчетов описаны в ИИЭР Std 11073-20601а.

8 Коммуникационная модель базового ЭКГ (от 1 до 3 отведений)

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

Данный раздел описывает общую модель и процедуру взаимодействия агента базового ЭКГ (от 1 до 3 отведений) в соответствии с определением в ИИЭР Std 11073-20601а. Вследствие этого соответствующие части ИИЭР Std 11073-20601а не воспроизведены; вернее, установлены конкретные варианты и ограничения в отношении необязательных элементов (например, объектов, атрибутов и действий) и конкретные расширения (например, номенклатурные термины).

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

8.2 Характеристики взаимодействия

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

Агент базового ЭКГ (от 1 до 3 отведений), реализовывающий только данную специализацию прибора, не должен передавать APDU, большие по размеру, чем , и должен быть способен получать любые APDU размером до . В рамках настоящего стандарта должен быть равен 64512 октет для реализаций, поддерживающих хранение постоянной метрики. Если возможность хранения постоянной метрики отсутствует, должен быть равен 7168 октет для реализаций, поддерживающих простые профили ECG, и 1280 октет для реализаций, поддерживающих профили ЧСС. В рамках настоящего стандарта должен быть равен 256 октет.

Для агента базового ЭКГ (от 1 до 3 отведений), реализовывающего функции других специализаций прибора, оценка верхней границы размеров APDU приводит к следующему: агент не должен передавать никаких APDU, больших по размеру, чем сумма всех реализованных специализаций прибора, и должен быть способен получать любые APDU размером, равным сумме всех реализованных специализаций прибора. Если эти значения выше, чем максимальный размер, определенный в ИИЭР Std 1W73-20601a-2010, следует применять последний способ.

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

8.3 Процедура ассоциации

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

Если не указано иное, процедура ассоциации для агента и менеджера базового ЭКГ (от 1 до 3 отведений) в соответствии с настоящим стандартом должна осуществляться согласно указаниям в ИИЭР Std 11073-20601а.

8.3.2 Процедура запроса на ассоциацию агентом

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

- версия процедуры ассоциации, используемой агентом, должна быть установлена в assoc-version1 (т.е. assoc-version=0x80000000);

- элемент структуры DataProtoList идентификатора протокола данных должен быть установлен в data-proto-id-20601 (т.е. data-proto-id=0x5079);

- поле data-proto-info должно содержать структуру PhdAssociationlnformation, которая должна иметь следующие значения параметра:

1) Агент должен поддерживать версию protocol-version2. Поддержка любой другой версии может быть указана путем установки дополнительных битов. Если используются протоколы с номером версии выше, чем protocol-version2, агент должен продолжать использовать только функции в соответствии с указанием в настоящем стандарте. Если используются протоколы с номером версии ниже, чем protocol-version2, агент должен использовать только функции, указанные в данном протоколе;

2) Должны поддерживаться как минимум правила MDER (т.е. encoding-rules=0x8000);

3) Версия использованной номенклатуры должна быть установлена в nom-version1 (т.е. nomenclature-version=0x80000000);

4) Поле functional-units может иметь установленные биты тестовой ассоциации, но не должна иметь никаких других установленных битов;

5) Поле system-type должно быть установлено в sys-type-agent (т.е. system-type=0x00800000);

6) Поле system-id должно быть установлено в значение атрибута System-Id объекта MDS агента. Менеджер может использовать только это поле для идентифицирования базового ЭКГ (от 1 до 3 отведений), с которым он устанавливает ассоциацию, и дополнительно для реализации простого метода ограничения доступа;

7) Поле dev-config-id должно быть установлено в значение атрибута Dev-Configuration-Id объекта MDS агента;

8) Если агент поддерживает специализацию только базового ЭКГ (от 1 до 3 отведений), то поле, отображающее режимы запроса данных (data-req-mode-capab), поддерживаемое агентом базового ЭКГ (от 1 до 3 отведений), должно быть установлено в data-req-supp-init-agent;

9) Если агент поддерживает специализацию только базового ЭКГ (от 1 до 3 отведений), то data-req-init-manager-count должно быть установлено в ноль, a data-req-init-agent-count должно быть установлено в 1.

8.3.3 Процедура ответа на ассоциацию менеджером

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

- поле результатов (result) должно быть установлено в соответствующий ответ из тех, что определены в ИИЭР Std 11073-20601a. Например, если все другие условия протокола ассоциации соблюдены, accepted отправляется в ответ, когда менеджер распознает dev-config-id агента, и accepted-unknown-config - если нет;

- в элементе структуры DataProtoList идентификатор протокола данных должен быть установлен в data-proto-id-20601 (т.е. data-proto-id=0x5079);

- поле data-proto-info должно быть заполнено структурой PhdAssociationlnformation, которая должна содержать следующие значения параметров:

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

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

3) Версия использованной номенклатуры должна быть установлена в nom-version1 (т.е. nomenclature-version=0x80000000);

4) Поле functional-units должно иметь все биты, за исключением тех, что относятся к тестовой ассоциации;

5) Поле system-type должно быть установлено в sys-type-manager (т.е. system-type=0x80000000);

6) Поле system-id должно содержать уникальный ID системы прибора менеджера, который должен являться идентификатором типа EUI-64;

7) Поле dev-config-id должно быть manager-config-response (0);

8) Поле data-req-mode-capab должно быть 0;

9) Если агент поддерживает специализацию только базового ЭКГ (от 1 до 3 отведений), data-req-initagent-count должен быть 1 и data-req-init-manager-count должен быть 0.

8.4 Процедура настройки конфигурации

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

Агент входит в состояние конфигурации, если получает ответ на ассоциацию в виде accepted-unknown-config. В этом случае процедура настройки конфигурации, указанная в ИИЭР Std 11073-20601a, должна соблюдаться. Пункт 8.4.2 описывает ответные сообщения и уведомления о конфигурации для агента базового ЭКГ (от 1 до 3 отведений) со стандартной конфигурацией ID 600 (0x0258). Как правило, менеджер уже будет знать стандартную конфигурацию. Однако в целях приведения данного примера менеджер не знает стандартной конфигурации.

8.4.2 Базовый ЭКГ (от 1 до 3 отведений). Стандартная конфигурация

8.4.2.1 Процедура агента

Агент выполняет процедуру конфигурации с помощью сообщения "Remote Operation Invoke|Confirmed Event Report" с событием MDC_NOTI_CONFIG для отправки своей конфигурации менеджеру (см. ИИЭР Std 11073-20601a). Структура ConfigReport используется для поля event-info (см. таблицу 4). Для агента базового ЭКГ (от 1 до 3 отведений) со стандартной конфигурацией ID 600 (0x258) формат и содержание сообщения-уведомления о конфигурации должны быть следующими:

8.4.2.2 Процедура менеджера

Менеджер должен отвечать на сообщение-уведомление о конфигурации с помощью сообщения данных "Remote Operation Response|Confirmed Event Report" с событием MDC_NOTI_CONFIG, используя структуру ConfigReportRsp для поля event-info (см. таблицу 4). Так же как и ответ на сообщение-уведомление о стандартной конфигурации, указанные в 8.4.2.1 формат и содержание ответного сообщения-уведомления о конфигурации должны быть следующими:

8.5 Процедура работы

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

Данные измерений и информация о состоянии передаются от агента базового ЭКГ (от 1 до 3 отведений) во время рабочего состояния. Если не указано иное, процедура работы для агента базового ЭКГ (от 1 до 3 отведений) настоящего стандарта должна соответствовать указаниям в ИИЭР Std 11073-20601a.

8.5.2 Атрибуты MDS базового ЭКГ (от 1 до 3 отведений) сервиса GET

См. таблицу 5 для получения краткого описания сервиса GET.

Если поле attribute-id-list в сервисном сообщении roiv-cmip-get пустое, то агент базового ЭКГ (от 1 до 3 отведений) должен отвечать сервисным сообщением rors-cmip-get, в котором attribute-list содержит перечень всех реализованных атрибутов объекта MDS.

Если менеджер запрашивает конкретный атрибут объекта MDS, указанный элементами в attribute-id-list, и агент поддерживает данную возможность, то агент базового ЭКГ (от 1 до 3 отведений) должен отвечать сервисным сообщением rors-cmip-get, в котором attribute-list содержит перечень запрашиваемых атрибутов объекта MDS, которые реализовываются. Агент базового ЭКГ (от 1 до 3 отведений) может и не поддерживать данную возможность. Если эта возможность не реализовывается, агент базового ЭКГ (от 1 до 3 отведений) должен отвечать в соответствии с указанием в разделе атрибуты объекта MDS в ИИЭР Std 11073-20601a.

8.5.3 Передача данных измерений

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

Для ограничения количества данных, передаваемых в пределах APDU, агент базового ЭКГ (от 1 до 3 отведений) не должен включать более 25 временно хранимых измерений в один отчет о событиях. Если для передачи доступно более 25 незавершенных измерений, они должны быть отправлены путем использования множественных отчетов о событиях или механизма PM-хранилища. Если имеется множество измерений базового ЭКГ (от 1 до 3 отведений), то в одном отчете о событии должно быть передано до 25 измерений. В другом случае они могут передаваться с помощью отдельного отчета о событии для каждого измерения базового ЭКГ (от 1 до 3 отведений). Однако первый из вышеуказанных способов рекомендован для сокращения общего размера сообщений и потребления мощности.

8.6 Синхронизация времени

Синхронизация времени между агентом базового ЭКГ (от 1 до 3 отведений) и менеджером может использоваться для приведения в соответствие часов, используемых при создании отчета о физиологических событиях. Обратите внимание на то, что механизм для синхронизации агента и менеджера не входит в область применения настоящего стандарта. Если используется синхронизация времени, то это должно сообщаться в атрибуте Mds-Time-Info объекта MDS.

9 Тестовая ассоциация

Тестовая ассоциация предоставляет производителю механизм для проверки или показа функций продукта в полном объеме. Данный раздел определяет поведение стандартного агента базового ЭКГ (от 1 до 3 отведений) в процессе тестовой ассоциации. Поддержка тестовой ассоциации является необязательной.

9.1 Поведение при стандартной конфигурации

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

Агент базового ЭКГ (от 1 до 3 отведений) должен отправить одно имитированное значение ЧСС, равное 7 уд./мин (значение не встречавшееся в обычном использовании и выходящее за нормальный диапазон значений) в течение 30 с после вхождения в рабочее состояние. Если реализовывается атрибут measurement-status числового объекта, то должен быть установлен бит test-data.

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

9.2 Поведение с расширенной конфигурацией

Данная спецификация не дает определение тестовой ассоциации, которая использует расширенную конфигурацию.

10 Соответствие

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

Настоящий стандарт должен применяться совместно с ИИЭР Std 11073-20601a.

Реализация или система могут соответствовать следующим элементам настоящего стандарта:

- иерархии классов информационной модели предметной области и определения объектов (атрибуты объектов, уведомления, методы, определения типов данных);

- значению номенклатурных кодов;

- моделям сервисов и протоколов;

- модели сервиса коммуникаций (ассоциация и конфигурирование).

10.2 Спецификация соответствия

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

- информационной модели конкретного прибора;

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

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

Спецификации должны быть предоставлены в форме набора заявлений о соответствии реализаций (ICS) в соответствии с описанием в разделе 10.4.

Настоящий стандарт используется совместно с ИИЭР Std 11073-20601a. Рекомендуется, чтобы ICS для настоящего стандарта было создано первым так, чтобы ICS для ИИЭР Std 11073-20601a мог содержать ссылки на ICS для настоящего стандарта там где, они применимы.

10.3 Уровни соответствия

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

Настоящий стандарт определяет следующие уровни соответствия.

10.3.2 Уровень соответствия 1. Основное соответствие

Приложение использует элементы информационной, сервисной и коммуникационной моделей (иерархия объекта, действия, отчеты о событии, определения типов данных) и номенклатурную схему, определенные в ИИЭР Std 11073-20601а-2010 и документах ИИЭР 11073-104zz. Все обязательные функции, указанные в таблице определений объекта и в таблице ICS, реализованы. Кроме того, любые реализованные условные, рекомендованные или необязательные функции должны соответствовать требованиям ИИЭР Std 11073-20601а и документов ИСО/ИИЭР 11073-104zz.

10.3.3 Уровень соответствия 2. Расширенная номенклатура (ASN.1 и/или ИСО/ИИЭР 11073-10101:2004 [B6])

Уровень соответствия 2 соответствует уровню соответствия 1, но также использует или добавляет расширения как минимум в одну из информационных, номенклатурных моделей или моделей сервиса. Расширения для номенклатурных кодов должны соответствовать концептуальной модели [А6] и находиться в пределах закрытого диапазона номенклатурных расширений (0xF000-0xFFFF).

Расширения для информационных или сервисных моделей должны быть полностью определены, используя ASN.1 там, где это необходимо, и иметь полное описание поведения в соответствии с концептуальной моделью ИИЭР Std 11073-20601а-2010 и/или [А8]. Все расширения должны быть определены и включать ссылки на определение, а в тех случаях, когда нет ни одной общедоступной ссылки, определение расширения должно быть приложено к свидетельству о соответствии.

10.4 Заявление о соответствии реализации

10.4.1 Общий формат

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

Заголовки граф таблицы имеют следующие значения:

- Индекс: идентификатор (т.е. номер) конкретной особенности.

- Свойство: кратко описывает характеристики, для которых создается заявление о соответствии.

- Ссылка: на раздел/пункт в данном документе или другом источнике для определения свойства (может оставаться пустым).

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

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

- Комментарий: содержит любую дополнительную информацию о свойстве. Эта графа должна заполняться исполнителем.

Подразделы с 10.4.2 по 10.4.6 определяют формат конкретных таблиц ICS.

10.4.2 Общее заявление о соответствии реализации

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

Таблица 25 - Общее ICS

10.4.3 Заявление о соответствии реализации DIM MOC

Заявление о соответствии реализации DIM MOC определяет, какой объект реализовывается. Информация по каждому объекту должна быть предоставлена отдельной строкой в образце таблицы 26.

Таблица 26 - Образец таблицы DIM MOC ICS

Индекс n в графе "Индекс" должен указывать на описатель объекта для реализаций, которые имеют предопределенные объекты. В ином случае в графе "Индекс" должен быть просто указан уникальный номер (1..m).

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

Графа "Поддержка" должна содержать любые ограничения для реализации объекта.

Диаграмма состава объекта (диаграмма экземпляра класса) должна быть предоставлена в составе DIM MOC ICS.

10.4.4 ICS атрибута MOC

ICS атрибута MOC определяет, какой атрибут, включая любые наследуемые атрибуты, используется/поддерживается в каждом объекте реализации. Информация по каждому объекту должна быть предоставлена отдельной строкой в образце таблицы 27. Для каждого объекта должно быть предусмотрено отдельное ICS атрибута MOC.

Таблица 27 - Образец таблицы ICS атрибута MOC

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

Индекс n в графе "Индекс" относится к идентификатору управляемого объекта, для которого предоставлена таблица (т.е. индекс объекта менеджера в соответствии с указанием в MOC ICS). Для каждого поддерживаемого управляемого объекта создается отдельная таблица.

Индекс х в графе "Индекс" является уникальным серийным номером (1..m).

10.4.5 Заявление о соответствии реализации сообщения MOC

ICS сообщения MOC определяет все реализованные сообщения (как правило, в форме сервиса отчета о событии), которые были отправлены агентом.

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

Таблица 28 - Образец таблицы ICS сообщения MOC

Индекс n в графе "Индекс" относится к идентификатору управляемого объекта, для которого предоставлена таблица (т.е. индекс объекта менеджера в соответствии с указанием в MOC ICS). Для каждого управляемого объекта, который поддерживает специальные сообщения объекта (т.е. события), создается отдельная таблица.

Индекс х в графе "Индекс" является уникальным серийным номером (1..m).

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

10.4.6 Заявление о соответствии реализации номенклатуры MOC

ICS номенклатуры MOC определяет все нестандартные номенклатурные коды, которые используются агентом.

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

Таблица 29 - Образец таблицы ICS номенклатуры MOC

Приложение А
(справочное)

Библиография

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

[A1] МЭК 60601-1:2005 Изд.3 Изделия медицинские электрические. Часть 1. Общие требования к общей безопасности и существенные рабочие характеристики

_______________

Публикации IEC имеются в отделе продаж Международной электротехнической комиссии по адресу: Case Postale 131, 3 Rue De , CH-1211, Женева 20, Швейцария (http://www.iec.ch/). Публикации IEC также имеются в США в отделе продаж Американского национального института стандартов, по адресу: 11 West 42nd Street, 13-й этаж, Нью-Йорк, 10036, США.

[A2] МЭК 60601-2 Изделия медицинские электрические. Часть 2. Частные требования к безопасности и основным характеристикам конкретных приборов. (См. полную серию стандартов, с части 2-1 по часть 2-51)

[A3] МЭК 62304:2006/EN 62304:2006 Программные средства медицинского оборудования. Жизненный цикл программного продукта

_______________

Публикации EN имеются в Европейском комитете по стандартизации (CEN), 36, rue de Stassart, B-1050 Брюссель, Бельгия (http://www.cenorm.be) (http://www.iso.ch/).

[A4] МЭК 80001-1:2010 Применение менеджмента рисков для IT-сетей, связанных с медицинскими приборами. Часть 1. Роли, ответственность и деятельность

[A5] ИСО 14971:2007 Изделия медицинские. Применение менеджмента риска к медицинским изделиям

_______________

Публикации ИСО имеются в Центральном секретариате ISO, Case Postale 56, 1 rue de Varembe, CH-1211, г.Женева 20, Швейцария (http://www.iso.ch/). Публикации ИСО/ИИЭР также имеются в США в отделе продаж Американского национального института стандартов, по адресу: 11 West 42nd Street, 13-й этаж, Нью-Йорк, 10036, США.

[A6] ИСО/ИИЭР 11073-10101:2004 Информатика в здравоохранении. Взаимодействие с медицинскими приборами, находящимися в местах оказания медицинской помощи. Часть 10101. Номенклатура

_______________

Публикации ИСО/ИИЭР имеются в Центральном секретариате ИСО, 1, ch. de la Voie-Creuse, Case postale 56, CH-1211, г.Женева 20, Швейцария (http://www.iso.ch/). Публикации ИСО/ИИЭР также имеются в США в Институте инженеров по электротехнике и электронике, 445 Хоус-Лейн, г.Пискатавэй, штат Нью-Джерси, 08854-4141, США (http://standards.ieee.org/).

[A7] ИСО/ИИЭР 11073-10201:2004 Информатика в здравоохранении. Взаимодействие с медицинскими приборами, находящимися в местах оказания медицинской помощи. Часть 10201. Информационная модель предметной области

[A8] ИСО/ИИЭР 11073-20101:2004 Информатика в здравоохранении. Взаимодействие с медицинскими приборами, находящимися в местах оказания медицинской помощи. Часть 20101. Профили применения. Базовый стандарт

[A9] ITU-T Рек. Х.680-2002 Информационные технологии. Язык OSI для описания абстрактного синтаксиса (ASN.1). Спецификация базовой нотации

_______________

Публикации ITU имеются в Международном союзе по телекоммуникациям, Place des Nations, 1211 Женева 20, Швейцария (http://www.itu.in/)

Приложение В
(обязательное)

Несколько дополнительных определений ASN.1

Побитовое отображение состояния приборов, отведений или сигналов

Объект перечисления состояния прибора требует следующего определения структуры ASN.1

BasicECGDevStat ::=BITS-16 {

leadwire-loss(0)

leadsignal-loss(1)

leadwire-loss-first-lead(2)

leadsignal-loss-first-lead(3)

leadwire-loss-second-lead(4)

leadsignal-loss-second-lead(5)

leadwire-loss-third-lead(6)

leadsignal-loss-third-lead(7)

}

Приложение С
(обязательное)

Распределение идентификаторов

Данное приложение содержит номенклатурные коды, используемые в данном документе, не найденные в ИИЭР Std 11073-20601а. Обязательные определения кодов, которые не содержатся в данном приложении, могут содержаться в ИИЭР Std 11073-20601а.

Формат, использованный в данном приложении, взят из [А6].

/****************************************************************************************************************************************

* От объекта инфраструктуры (MDC_PART_OBJ)

*****************************************************************************************************************************************

*/

*/

/ ****************************************************************************************************************************************

* От медицинского дистанционного управления и сбора данных (MDC_PART_SCADA)

**************************************************************************************************************************************** /

*/

/****************************************************************************************************************************************

* От размеров (MDC_PART_DIM)

**************************************************************************************************************************************** /

*/

/****************************************************************************************************************************************

* От информационно-коммуникационной инфраструктуры (MDC_PART_INFRA)

****************************************************************************************************************************************/

/****************************************************************************************************************************************/

* От управления течением заболевания персонального медицинского прибора (MDC_PART_PHD_DM)

*****************************************************************************************************************************************/

Приложение D
(справочное)

Примеры последовательности сообщений

На рисунке D.1 изображена диаграмма последовательности процедуры обмена сообщениями, соответствующая следующему сценарию использования. Пользователь прибора агента базового ЭКГ (от 1 до 3 отведений) намерен подключить его к прибору менеджера в первый раз. Базовый ЭКГ (от 1 до 3 отведений) способен выполнять измерения ЧСС и интервала R-R.

a) Когда пользователь подключает базовый ЭКГ (от 1 до 3 отведений), менеджер не распознает конфигурацию агента и отправляет ответ на запрос агента на ассоциацию с результатом accepted-unknown-config. См. E.2.2.2 и E.2.2.1 для получения соответствующих примеров PDU (протокольного блока данных).

b) Вследствие этого агент сообщает информацию о своей конфигурации менеджеру. После получения подтверждения от менеджера, принявшего конфигурацию агента, прибор агента готов к отправке результатов измерений. Оба прибора входят в рабочее состояние. См. E.3.2.2 и E.3.2.3 для получения соответствующих примеров PDU.

c) Затем менеджер может запросить атрибуты объекта MDS агента путем отправки сообщения данных с помощью команды "Remote Operation Invoke|Get". Обратите внимание на то, что менеджер может запросить атрибуты объекта MDS сразу после того, как агент войдет в ассоциированное состояние, включая конфигурирующее и рабочее подсостояния. В ответ агент сообщает менеджеру свои атрибуты объекта MDS путем отправки сообщения данных с помощью команды "Remote Operation Response|Get". См. E.4.1.2 и E.4.1.3 для получения соответствующих примеров PDU.

d) На следующем этапе пользователь прибора агента проводит несколько измерений за определенный период времени. Данные измерений передаются менеджеру с помощью неподверженного* ответа о событии. См. E.5.1 для получения соответствующего примера PDU.

________________

* Текст документа соответствует оригиналу. - .

e) Пользователь завершает сеанс измерений (например, путем нажатия соответствующей кнопки на приборе или прекращения пользования прибором на время, превышающее определенный период). В результате агент разрывает ассоциацию с менеджером путем отправки запроса на разрыв ассоциации. Менеджер отправляет ответ на разрыв ассоциации. См. E.6.1 и E.6.2 для получения соответствующих примеров PDU.

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

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

Рисунок D.1 - Диаграмма последовательности для примера использования базового ЭКГ (от 1 до 3 отведений)

Приложение Е
(справочное)

Примеры протокольных блоков данных

Е.1 Общие положения

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

Е.2 Обмен информацией об ассоциации

Е.2.1 Общие положения

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

Е.2.2 Расширенная конфигурация

Е.2.2.1 Общие положения

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

E.2.2.2 Запрос на ассоциацию

Агент базового ЭКГ (от 1 до 3 отведений) отправляет нижеописанное сообщение менеджеру. Агент намерен установить ассоциацию, используя расширенную конфигурацию.

Е.2.2.3 Ответ на ассоциацию

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

Е.2.3 Расширенные конфигурации, известные ранее

Е.2.3.1 Общие положения

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

Е.2.3.2 Запрос на ассоциацию

Агент базового ЭКГ (от 1 до 3 отведений) отправляет нижеописанное сообщение менеджеру. Агент намерен установить ассоциацию, используя расширенную конфигурацию.

Е.2.3.3 Ответ на ассоциацию

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

Е.2.4 Стандартная конфигурация

Е.2.4.1 Общие положения

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

Е.2.4.2 Запрос на ассоциацию

Агент базового ЭКГ (от 1 до 3 отведений) отправляет нижеописанное сообщение менеджеру. Агент намерен установить ассоциацию, используя стандартную конфигурацию. Агент готов начать тестовую ассоциацию в соответствии с описанием в разделе 9.

Е.2.4.3 Ответ на ассоциацию

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

Е.3 Обмен информацией о конфигурации

Е.3.1 Общие положения

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

Е.3.2 Расширенная конфигурация

Е.3.2.1 Общие сведения

Данный обмен происходит, когда менеджер возвращает код AssociateResult с результатом accepted-unknown-config. Агент предоставляет описание своей конфигурации, соответствующей dev-config-id, который он предоставил в запросе на ассоциацию.

Е.3.2.2 Конфигурация отчета о событии вызова дистанционной работы

Агент базового ЭКГ (от 1 до 3 отведений) отправляет описание своих расширенных конфигураций. Он выполняет данное действие путем отправки подтвержденного отчета о событии типа MDC_NOTI_CONFIG.

Е.3.2.3 Конфигурация отчета о событии ответа на вызов дистанционной работы

Менеджер отвечает, что может использовать конфигурацию агента. Менеджер отправляет ответ на подтвержденный отчет о событии с помощью config-result of accepted-config.

Е.3.3 Известная конфигурация

Е.3.3.1 Общие положения

Данный обмен происходит, когда менеджер возвращает код AssociateResult с результатом accepted (принят), так как менеджер ранее получил и обработал конфигурацию, соответствующую конфигурации dev-config-id, отправленную агентом. В этом случае не происходит никакого обмена информацией о конфигурации, а агент и менеджер переходят в рабочее состояние.

Е.3.3.2 Конфигурация отчета о событии вызова дистанционной работы

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

Е.3.3.3 Конфигурация отчета о событии ответа на вызов дистанционной работы

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

Е.3.4 Стандартная конфигурация

Е.3.4.1 Общие положения

Данный обмен происходит, когда менеджер возвращает код AssociateResult с результатом accepted (принят), так как менеджер был ранее запрограммирован со стандартной конфигурацией, соответствующей dev-config-id, отправленной агентом. В этом случае не происходит никакого обмена информацией о конфигурации, а агент и менеджер переходят в рабочее состояние.

Е.3.4.2 Конфигурация отчета о событии вызова дистанционной работы

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

Е.3.4.3 Конфигурация отчета о событии ответа на вызов дистанционной работы

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

Е.4 Сервис GET атрибута MDS

Е.4.1.1 Общие сведения

Атрибуты GET MDS вызываются в любое время, когда агент находится в ассоциированном состоянии.

Е.4.1.2 Запрос на получение всех атрибутов системы медицинских приборов

Менеджер запрашивает у агента его атрибуты объекта MDS.

E.4.1.3 Ответ на получение со всеми атрибутами MDS

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

Е.5 Предоставление данных

Е.5.1 Неподтвержденная передача данных измерений

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

E.6 Разрыв ассоциации

E.6.1 Запрос на разрыв ассоциации

Агент базового ЭКГ (от 1 до 3 отведений) отправляет менеджеру нижеописанное сообщение.

Е.6.2 Ответ на разрыв ассоциации

Менеджер отвечает агенту, что может разорвать ассоциацию.

Приложение ДА
(справочное)

Сведения о соответствии ссылочных международных стандартов и документов национальным стандартам Российской Федерации

Таблица ДА.1

Электронный текст документа

и сверен по:

, 2017