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

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

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

Текст ГОСТ Р 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

Наименование атрибута

Значение

Квалификатор

Handle

0

M

System-Type

Атрибута не существует. См. ИИЭР Std 11073-20601a

NR

System-Type-Spec-List

Значение специализации:

{MDC_DEV_SPEC_PROFILE_ECG, 1} и значение профиля:

{MDC DEV SUB SPEC PROFILE ECG, 1} или {MDC DEV SUB SPEC PROFILE HR, 1}

M

System-Model

{"Manufacturer","Model"}

M

System-Id

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

M

Dev-Configuration-Id

Стандартная конфигурация: 0x0258 (600). Расширенные конфигурации: 0x4000-0x7FFF

M

Attribute-Value-Map

См. ИИЭР Std 11073-20601a

C

Production-Specification

См. ИИЭР Std 11073-20601a

O

Mds-Time-Info

См. ИИЭР Std 11073-20601a

C

Date-and-Time

См. ИИЭР Std 11073-20601a

C

Base-Offset-Time

См. ИИЭР Std 11073-20601a

C

Relative-Time

См. ИИЭР Std 11073-20601a

C

HiRes-Relative-Time

См. ИИЭР Std 11073-20601a

C

Date-and-Time-Adjustment

См. ИИЭР Std 11073-20601a

C

Power-Status

onBattery или onMains

R

Battery-Level

См. ИИЭР Std 11073-20601a

R

Remaining-Battery-Time

См. ИИЭР Std 11073-20601a

R

Reg-Cert-Data-List

См. ИИЭР Std 11073-20601a

O

Confirm-Timeout

См. ИИЭР Std 11073-20601a

O

Tick-Resolution

См. 6.6.2

C

Примечание - См. ИИЭР 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

Имя атрибута

Идентификатор атрибута

Тип атрибута

Примечание

Квалификаторы

Tick-Resolution

MDC_ATTR_TICK_RES

Тип FLOAT

Данный атрибут определяет разрешение для внутреннего осциллятора агента (т.е. он устанавливает количество импульсов в сек.). Если агент реализует объект интервала R-R (см. 6.6.3) и использует MDC_DIM_TICK для соответствующего атрибута Unit-Code, то атрибут 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

Сервис

Наименование типа подсервиса

Режим

Тип подсервиса (action-type)

Параметры (action-info-args)

Результаты (action-info-args)

ACTION

Set-Time

Подтвержден

MDC ACT SET TIME

SetTimeInvoke

-

ACTION

Set-Base-Offset-Time

Подтвержден

MDC_ACT_SET_BO_TIME

SetBOTimeInvoke

-

- 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 отведений)

Сервис

Наименование типа подсервиса

Режим

Тип подсервиса (action-type)

Параметры (action-info-args)

Результаты (action-info-args)

EVENT REPORT (Отчет о событии)

MDS-Configuration-Event

Подтвержден

MDC_NOTI_CONFIG

ConfgReport

ConfgReportRsp

MDS-Dynamic-Data-Update-Var

Подтвержден или не подтвержден

MDC_NOTI_SCAN_REPORT_VAR

ScanReportInfoVar

-

MDS-Dynamic-Data-Update-Fixed

Подтвержден или не подтвержден

MDC_NOTI_SCAN_REPORT_FIXED

ScanReportInfoFixed

-

MDS-Dynamic-Data-Update-MP-Var

Подтвержден или не подтвержден

MDC_NOTI_SCAN_REPORT_MP_VAR

ScanReportInfoMPVar

-

MDS-Dynamic-Data-Update-MP-Fixed

Подтвержден или не подтвержден

MDC_NOTI_SCAN_REPORT_MP_FIXED

ScanReportInfoMPFixed

-

- 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 отведений)

Сервис

Наименование типа подсервиса

Режим

Тип подсервиса

Параметры

Результаты

GET

<na>

<implied confirmed>

<na>

GetArgumentSimple=(obj-handle=0), attribute-id-list <optional>

GetResultSimple=(obj-handle=0), attribute-list

См. 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 - Атрибуты числовых объектов ЧСС

Наименование атрибута

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

Стандартная конфигурация (Dev-Confguration-Id=0x0258)

Значение

Квалифи-
кация

Значение

Квалифи-
кация

Handle

См. ИИЭР Std 11073-20601a

M

1

M

Type

{MDC PART SCADA ,| MDC_ECG_HEART_RATE} или {MDC PART PHD DIM ,|
MDC ECG HEART RATE INSTANT}

M

{MDC PART SCADA |, MDC_ECG_HEART_RATE}

M

Supplemental-Types

См. ИИЭР Std 11073-20601a

NR

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

NR

Metric-Spec-Small

См. ИИЭР Std 11073-20601a и нижеследующий текст

M

mss-avail-stored-data, mss-acc-agent-initiated

M

Metric-Structure-Small

См. ИИЭР Std 11073-20601a

NR

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

NR

Measurement-Status

См. ИИЭР Std 11073-20601a

O

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

O

Metric-Id

См. ИИЭР Std 11073-20601a

NR

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

NR

Metric-Id-List

См. ИИЭР Std 11073-20601a

NR

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

NR

Metric-Id-Partition

См. ИИЭР Std 11073-20601a

NR

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

NR

Unit-Code

MDC DIM BEAT PER MIN

M

MDC DIM BEAT PER MIN

M

Attribute-Value-Map

См. ИИЭР Std 11073-20601a

C

MDC_ATTR_NU_VAL_OBS_BASIC, then MDC_ATTR_TIME_STAMP_ABS

M

Source-Handle-Reference

См. ИИЭР Std 11073-20601a

NR

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

NR

Label-String

См. ИИЭР Std 11073-20601a

O

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

O

Unit-Label-String

См. ИИЭР Std 11073-20601a

O

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

O

Absolute-Time-Stamp

См. ИИЭР Std 11073-20601a

C

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

NR

Base-Offset-Time-Stamp

См. ИИЭР Std 11073-20601a

C

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

NR

Relative-Time-Stamp

См. ИИЭР Std 11073-20601a

C

Если используется фиксированный формат и стандартная конфигурация не настроена, данный атрибут является обязательным; в ином случае применяются условия, изложенные в ИИЭР Std 11073-20601a-2010

R

HiRes-Time-Stamp

См. ИИЭР Std 11073-20601a

C

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

NR

Measure-Active-Period

См. ИИЭР Std 11073-20601a

NR

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

NR

Simple-Nu-Observed-Value

См. ИИЭР Std 11073-20601a

C

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

NR

Compound-Simple-Nu-Observed-Value

См. ИИЭР Std 11073-20601a

C

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

NR

Basic-Nu-Observed-Value

См. ИИЭР Std 11073-20601a

C

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

R

Compound-Basic-Nu-Observed-Value

См. ИИЭР Std 11073-20601a

C

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

NR

Nu-Observed-Value

См. ИИЭР Std 11073-20601a

C

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

NR

Compound-Nu-Observed-Value

См. ИИЭР Std 11073-20601a

C

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

NR

Accuracy

См. ИИЭР Std 11073-20601a

NR

Атрибут не существует изначально. Если существует, следуйте ИИЭР Std 11073-20601a

NR

Примечания

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

Название атрибута

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

Квалифи-
кация

Handle

См. ИИЭР Std 11073-20601a

M

Type

{MDC PART SCADA , MDC ECG TIME PD RR GL}

M

Supplemental-Types

См. ИИЭР Std 11073-20601a

NR

Metric-Spec-Small

См. ИИЭР Std 11073-20601a и нижеследующий текст

M

Metric-Structure-Small

См. ИИЭР Std 11073-20601a

NR

Measurement-Status

См. ИИЭР Std 11073-20601a

O

Metric-Id

См. ИИЭР Std 11073-20601a

NR

Metric-Id-List

См. ИИЭР Std 11073-20601a

NR

Metric-Id-Partition

См. ИИЭР Std 11073-20601a

NR

Unit-Code

MDC DIM MILLI SEC или MDC DIM TICK

M

Attribute-Value-Map

См. ИИЭР Std 11073-20601a

C

Source-Handle-Reference

См. ИИЭР Std 11073-20601a

NR

Label-String

См. ИИЭР Std 11073-20601a

O

Unit-Label-String

См. ИИЭР Std 11073-20601a

O

Absolute-Time-Stamp

См. ИИЭР Std 11073-20601a

C

Base-Offset-Time-Stamp

См. ИИЭР Std 11073-20601a

C

Relative-Time-Stamp

См. ИИЭР Std 11073-20601a

C

HiRes-Time-Stamp

См. ИИЭР Std 11073-20601a

C

Measure-Active-Period

См. ИИЭР Std 11073-20601a

NR

Simple-Nu-Observed-Value

См. ИИЭР Std 11073-20601a

C

Compound-Simple-Nu-Observed-Value

См. ИИЭР Std 11073-20601a

C

Basic-Nu-Observed-Value

См. ИИЭР Std 11073-20601a

C

Compound-Basic-Nu-Observed-Value

См. ИИЭР Std 11073-20601a

C

Nu-Observed-Value

См. ИИЭР Std 11073-20601a

C

Compound-Nu-Observed-Value

См. ИИЭР Std 11073-20601a

C

Accuracy

См. ИИЭР Std 11073-20601a

NR

Примечания

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 колебаний ЭКГ

Название атрибута

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

Значение

Квалификация

Handle

См. ИИЭР Std 11073-20601a

M

Type

{MDC_PART_SCADA, см. таблицу 9 для получения информации по поддерживаемым типам измерений отведений}

M

Supplemental-Types

См. ИИЭР Std 11073-20601a

NR

Metric-Spec-Small

0x0000 (не установлено ни одного бита)

M

Measurement-Status

См. ИИЭР Std 11073-20601a

O

Metric-Id

См. ИИЭР Std 11073-20601a

NR

Metric-Id-List

См. ИИЭР Std 11073-20601a

NR

Metric-Id-Partition

См. ИИЭР Std 11073-20601a

NR

Unit-Code

MDC DIM MILLI VOLT

M

Attribute-Value-Map

См. ИИЭР Std 11073-20601a

C

Source-Handle-Reference

См. ИИЭР Std 11073-20601a

NR

Label-String

См. ИИЭР Std 11073-20601a

O

Unit-Label-String

См. ИИЭР Std 11073-20601a

O

Absolute-Time-Stamp

См. ИИЭР Std 11073-20601a

C

Base-Offset-Time-Stamp

См. ИИЭР Std 11073-20601a

C

Relative-Time-Stamp

См. ИИЭР Std 11073-20601a

C

HiRes-Time-Stamp

См. ИИЭР Std 11073-20601a

C

Measure-Active-Period

См. ИИЭР Std 11073-20601a

NR

Sample-Period

См. ИИЭР Std 11073-20601a

M

Simple-Sa-Observed-Value

См. ИИЭР Std 11073-20601a

M

Scale-and-Range-Specification

См. ИИЭР Std 11073-20601a

M

Sa-Specification

См. ИИЭР Std 11073-20601a

M

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

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

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

Тип

Значение

Отведение

MDC ECG ELEC POTL

256

Неуказанное отведение

MDC ECG ELEC POTL I

257

Отведение I

MDC ECG ELEC POTL II

258

Отведение II

MDC ECG ELEC POTL III

317

Отведение III

MDC ECG ELEC POTL AVR

318

Усиленное отведение от правой руки (aVR)

MDC ECG ELEC POTL AVL

319

Усиленное отведение от левой руки (aVL)

MDC ECG ELEC POTL AVF

320

Усиленное отведение от левой ноги (aVF)

MDC ECG ELEC POTL V1

259

Отведение V1

MDC ECG ELEC POTL V2

260

Отведение V2

MDC ECG ELEC POTL V3

261

Отведение V3

MDC ECG ELEC POTL V4

262

Отведение V4

MDC ECG ELEC POTL V5

263

Отведение V5

MDC ECG ELEC POTL V6

264

Отведение V6

Данные по колебаниям ЭКГ должны быть доступны только через объекты сканера. Соответственно, бит 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 - Атрибуты объектов перечисления состояния прибора

Название атрибута

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

Значение

Квалификация

Handle

См. ИИЭР Std 11073-20601a

M

Type

{MDC PART PHD DM, MDC ECG DEV STAT}

M

Supplemental-Types

См. ИИЭР Std 11073-20601a

NR

Metric-Spec-Small

См. ИИЭР Std 11073-20601a

M

Metric-Structure-Small

См. ИИЭР Std 11073-20601a

NR

Measurement-Status

См. ИИЭР Std 11073-20601a

O

Metric-Id

См. ИИЭР Std 11073-20601a

NR

Metric-Id-List

См. ИИЭР Std 11073-20601a

NR

Metric-Id-Partition

См. ИИЭР Std 11073-20601a

NR

Unit-Code

См. ИИЭР Std 11073-20601a

NR

Attribute-Value-Map

См. ИИЭР Std 11073-20601a

C

Source-Handle-Reference

См. ИИЭР Std 11073-20601a

NR

Label-String

См. ИИЭР Std 11073-20601a

O

Unit-Label-String

См. ИИЭР Std 11073-20601a

O

Absolute-Time-Stamp

См. ИИЭР Std 11073-20601a

C

Base-Offset-Time-Stamp

См. ИИЭР Std 11073-20601a

C

Relative-Time-Stamp

См. ИИЭР Std 11073-20601a

C

HiRes-Time-Stamp

См. ИИЭР Std 11073-20601a

C

Measure-Active-Period

См. ИИЭР Std 11073-20601a

NR

Enum-Observed-Value-Simple-OID

См. ИИЭР Std 11073-20601a

NR

Enum-Observed-Value-Simple-Bit-Str

См. ИИЭР Std 11073-20601a

NR

Enum-Observed-Value-Basic-Bit-Str

См. ИИЭР Std 11073-20601a и последующий текст

M

Enum-Observed-Value-Simple-Str

См. ИИЭР Std 11073-20601a

NR

Enum-Observed-Value

См. ИИЭР Std 11073-20601a

NR

Enum-Observed-Value-Partition

См. ИИЭР Std 11073-20601a

NR

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

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

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

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

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

Мнемосхема BasicECGDevStat

Агент сообщает о потере напряжения питающего провода или соединения электрода (отведение не определено)

leadwire-loss

Агент сообщает о потере сигнала отведения (отведение не определено)

leadsignal-loss

Агент сообщает о потере напряжения питающего провода или соединения электрода (первое отведение)

leadwire-loss-first-lead

Агент сообщает о потере сигнала отведения (первое отведение)

leadsignal-loss-first-lead

Агент сообщает о потере напряжения питающего провода или соединения электрода (второе отведение)

leadwire-loss-second-lead

Агент сообщает о потере сигнала отведения (второе отведение)

leadsignal-loss-second-lead

Агент сообщает о потере напряжения питающего провода или соединения электрода (третье отведение)

leadwire-loss-third-lead

Агент сообщает о потере сигнала отведения (третье отведение)

leadsignal-loss-third-lead

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

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

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

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

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

Название атрибута

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

Значение

Квалификация

Handle

См. ИИЭР Std 11073-20601a

M

Type

{MDC PART PHD DM,
MDC ECG EVT CTXT GEN}

M

Supplemental-Types

См. ИИЭР Std 11073-20601a

NR

Metric-Spec-Small

См. ИИЭР Std 11073-20601a

M

Metric-Structure-Small

См. ИИЭР Std 11073-20601a

NR

Measurement-Status

См. ИИЭР Std 11073-20601a

O

Metric-Id

См. ИИЭР Std 11073-20601a

NR

Metric-Id-List

См. ИИЭР Std 11073-20601a

NR

Metric-Id-Partition

См. ИИЭР Std 11073-20601a

NR

Unit-Code

См. ИИЭР Std 11073-20601a

NR

Attribute-Value-Map

См. ИИЭР Std 11073-20601a

C

Source-Handle-Reference

См. ИИЭР Std 11073-20601a

NR

Label-String

См. ИИЭР Std 11073-20601a

O

Unit-Label-String

См. ИИЭР Std 11073-20601a

O

Absolute-Time-Stamp

См. ИИЭР Std 11073-20601a

C

Base-Offset-Time-Stamp

См. ИИЭР Std 11073-20601a

C

Relative-Time-Stamp

См. ИИЭР Std 11073-20601a

C

HiRes-Time-Stamp

См. ИИЭР Std 11073-20601a

C

Measure-Active-Period

См. ИИЭР Std 11073-20601a

NR

Enum-Observed-Value-Simple-OID

См. ИИЭР Std 11073-20601a и последующий текст

M

Enum-Observed-Value-Simple-Bit-Str

См. ИИЭР Std 11073-20601a

NR

Enum-Observed-Value-Basic-Bit-Str

См. ИИЭР Std 11073-20601a

NR

Enum-Observed-Value-Simple-Str

См. ИИЭР Std 11073-20601a

NR

Enum-Observed-Value

См. ИИЭР Std 11073-20601a

NR

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

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

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

Описание/определение

Ссылочный ID

Код

Событие, запущенное пользователем (например, пользователь нажимает кнопку)

MDC_ECG_EVT_CTXT_USER

21978

Периодическое запланированное событие

MDC_ECG_EVT_CTXT_PERIODIC

21979

Обнаруженное неспецифическое кардиальное событие

MDC_ECG_EVT_CTXT_DETECTED

21980

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

MDC_ECG_EVT_CTXT_EXTERNAL

21981

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

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

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-хранилища

Название атрибута

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

Значение

Квалификация

Handle

См. ИИЭР Std 11073-20601a

M

PM-Store-Capab

См. ИИЭР Std 11073-20601a

M

Store-Sample-Algorithm

См. ИИЭР Std 11073-20601a

M

Store-Capacity-Count

См. ИИЭР Std 11073-20601a

M

Store-Usage-Count

См. ИИЭР Std 11073-20601a

M

Operational-State

См. ИИЭР Std 11073-20601a

M

PM-Store-Label

См. ИИЭР Std 11073-20601a

O

Sample-Period

См. ИИЭР Std 11073-20601a

C

Number-Of-Segments

См. ИИЭР Std 11073-20601a

M

Clear-Timeout

См. ИИЭР Std 11073-20601a

M

Атрибут 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-хранилища

Название атрибута

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

Значение

Квалификация

Handle

См. ИИЭР Std 11073-20601a

M

PM-Store-Capab

См. ИИЭР Std 11073-20601a

M

Store-Sample-Algorithm

См. ИИЭР Std 11073-20601a

M

Store-Capacity-Count

См. ИИЭР Std 11073-20601a

M

Store-Usage-Count

См. ИИЭР Std 11073-20601a

M

Operational-State

См. ИИЭР Std 11073-20601a

M

PM-Store-Label

См. ИИЭР Std 11073-20601a

O

Sample-Period

См. ИИЭР Std 11073-20601a

NR

Number-Of-Segments

См. ИИЭР Std 11073-20601a

M

Clear-Timeout

См. ИИЭР Std 11073-20601a

M

Атрибут 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-хранилища

Сервис

Наимено-
вание типа подсервиса

Режим

Тип подсервиса (action-type)

Параметр (action-info-args)

Результаты (action-info-args)

ACTION

Clear-
Segments

Подтвержден

MDC_ACT_SEG_CLR

SegmSelection

Get-
Segment-
Info

Подтвержден

MDC_ACT_SEG_GET_INFO

SegmSelection

SegmentInfoList

Trig-
Segment-
Data-Xfer

Подтвержден

MDC_ACT_SEG_TRIG_XFER

TrigSegmDataXferReq

TrigSegmDataXferRsp

- 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-хранилища

Сервис

Наименование типа подсервиса

Режим

Тип подсервиса (event-type)

Параметр (event-info)

Результаты (event-reply-info)

EVENT
REPORT

Segment-Data-Event

Подтвержден

MDC_NOTI_SEG_MENT_DATA

SegmentDataEvent

SegmentDataResult

- 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-сегмента периодического сеанса

Название атрибута

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

Значение

Квалификация

Instance-Number

См. ИИЭР Std 11073-20601a

M

PM-Segment-Entry-Map

См. ИИЭР Std 11073-20601a

M

PM-Seg-Person-Id

См. ИИЭР Std 11073-20601a

C

Operational-State

См. ИИЭР Std 11073-20601a

M

Sample-Period

См. ИИЭР Std 11073-20601a

C

Segment-Label

См. ИИЭР Std 11073-20601a

O

Segment-Start-Abs-Time

См. ИИЭР Std 11073-20601a

C

Segment-End-Abs-Time

См. ИИЭР Std 11073-20601a

C

Date-and-Time-Adjustment

См. ИИЭР Std 11073-20601a

C

Segment-Start-BO-Time

См. ИИЭР Std 11073-20601a

C

Segment-End-BO-Time

См. ИИЭР Std 11073-20601a

C

Segment-Usage-Count

См. ИИЭР Std 11073-20601a

M

Segment-Statistics

См. ИИЭР Std 11073-20601a

O

Fixed-Segment-Data

См. ИИЭР Std 11073-20601a

M

Confirm-Timeout

См. ИИЭР Std 11073-20601a

O

Transfer-Timeout

См. ИИЭР Std 11073-20601a

M

Примечания

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-сегмента непериодического сеанса

Название атрибута

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

Значение

Квалификация

Instance-Number

См. ИСО/ИИЭР 11073-20601:2010

M

PM-Segment-Entry-Map

См. ИСО/ИИЭР 11073-20601:2010

M

PM-Seg-Person-Id

См. ИСО/ИИЭР 11073-20601:2010

C

Operational-State

См. ИСО/ИИЭР 11073-20601:2010

M

Sample-Period

См. ИСО/ИИЭР 11073-20601:2010

O

Segment-Label

См. ИСО/ИИЭР 11073-20601:2010

O

Segment-Start-Abs-Time

См. ИСО/ИИЭР 11073-20601:2010

M

Segment-End-Abs-Time

См. ИСО/ИИЭР 11073-20601:2010

M

Date-and-Time-Adjustment

См. ИСО/ИИЭР 11073-20601:2010

C

Segment-Start-BO-Time

См. ИСО/ИИЭР 11073-20601:2010

C

Segment-End-BO-Time

См. ИСО/ИИЭР 11073-20601:2010

C

Segment-Usage-Count

См. ИСО/ИИЭР 11073-20601:2010

M

Segment-Statistics

См. ИСО/ИИЭР 11073-20601:2010

O

Fixed-Segment-Data

См. ИСО/ИИЭР 11073-20601:2010

M

Confirm-Timeout

См. ИСО/ИИЭР 11073-20601:2010

O

Transfer-Timeout

См. ИСО/ИИЭР 11073-20601:2010

M

Примечания

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 - Атрибуты объекта периодического конфигурируемого сканера

Название атрибута

Значение

Квалификация

Handle

См. ИИЭР Std 11073-20601a

M

Operational-State

См. ИИЭР Std 11073-20601a

M

Scan-Handle-List

См. ИИЭР Std 11073-20601a

C

Scan-Handle-Attr-Val-Map

См. ИИЭР Std 11073-20601a

C

Confirm-Mode

См. ИИЭР Std 11073-20601a

M

Confirm-Timeout

См. ИИЭР Std 11073-20601a

O

Transmit-Window

См. ИИЭР Std 11073-20601a

O

Reporting-Interval

См. ИИЭР Std 11073-20601a

M

Примечания

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

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

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

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

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

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

Событие

Режим

Тип события

Параметр информации события

Event-
reply-
info

Buf-Scan-
Report-Var

Подтвержденный или неподтвержденный

MDC_NOTI_BUF_SCAN_
REPORT_VAR

ScanReportInfoVar

-

Buf-Scan-
Report-
Fixed

Подтвержденный или неподтвержденный

MDC_NOTI_BUF_SCAN_
REPORT_FIXED

ScanReportInfoFixed

-

Buf-Scan-
Report-
Grouped

Подтвержденный или неподтвержденный

MDC_NOTI_BUF_SCAN_
REPORT_GROUPED

ScanReportInfoGrouped

-

Buf-Scan-
Report-MP-
Var

Подтвержденный или неподтвержденный

MDC_NOTI_BUF_SCAN_
REPORT_MP_VAR

ScanReportInfoMPVar

-

Buf-Scan-
Report-MP-
Fixed

Подтвержденный или неподтвержденный

MDC_NOTI_BUF_SCAN_
REPORT_MP_FIXED

ScanReportInfoMPFixed

-

Buf-Scan-
Report-MP-
Grouped

Подтвержденный или неподтвержденный

MDC_NOTI_BUF_SCAN_
REPORT_MP_GROUPED

ScanReportInfoMPGrouped

-

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

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

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

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

Название атрибута

Значение

Квалификация

Handle

См. ИИЭР Std 11073-20601a

M

Operational-State

См. ИИЭР Std 11073-20601a

M

Scan-Handle-List

См. ИИЭР Std 11073-20601a

C

Scan-Handle-Attr-Val-Map

См. ИИЭР Std 11073-20601a

C

Confrm-Mode

См. ИИЭР Std 11073-20601a

M

Confirm-Timeout

См. ИИЭР Std 11073-20601a

O

Transmit-Window

См. ИИЭР Std 11073-20601a

O

Min-Reporting-Interval

См. ИИЭР Std 11073-20601a

M

Примечания

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

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

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

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

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

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

Событие

Режим

Тип события

Параметр информации события

Event-
reply-
info

Unbuf-Scan-
Report-Var

Подтвержденный или неподтвержденный

MDC_NOT_UNBUF_SCAN_
REPORT_VAR

ScanReportInfoVar

-

Unbuf-Scan-
Report-
Fixed

Подтвержденный или неподтвержденный

MDC_NOT_UNBUF_SCAN_
REPORT_FIXED

ScanReportInfoFixed

-

Unbuf-Scan-
Report-
Grouped

Подтвержденный или неподтвержденный

MDC_NOT_UNBUF_SCAN_
REPORT_GROUPED

ScanReportInfoGrouped

-

Unbuf-Scan-
Report-MP-
Var

Подтвержденный или неподтвержденный

MDC_NOT_UNBUF_SCAN_
REPORT_MP_VAR

ScanReportInfoMPVar

-

Unbuf-Scan-
Report-MP-
Fixed

Подтвержденный или неподтвержденный

MDC_NOT_UNBUF_SCAN_
REPORT_MP_FIXED

ScanReportInfoMPFixed

-

Unbuf-Scan-
Report-MP-
Grouped

Подтвержденный или неподтвержденный

MDC_NOT_UNBUF_SCAN_
REPORT_MP_GROUPED

ScanReportInfoMPGrouped

-

Агенты, которые реализовывают периодический конфигурируемый сканер, должны поддерживать сервис 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 отведений)

Сервис

Наименование типа подсервиса

Режим

Тип подсервиса

Параметр

Результат

Примечание

GET

<nа>

<implied Confirmed>

<nа>

GetArgumentSimple=(obj-handle=0), attribute-id-list <optional>

GetResultSimple=(obj-handle=0), attribute-list

Позволяет менеджеру извлекать значения атрибутов объекта MDS в агенте

<nа>

<implied Confirmed>

<nа>

GetArgumentSimple=(obj-handle=идентификатор объекта PM-хранилища), attribute-id-list <optional>

GetResultSimple=(obj-handle=идентификатор объекта PM-хранилища), attribute-list

Позволяет менеджеру извлекать значения атрибутов объекта РМ-хранилища в агенте

SET

<nа>

Подтвержденный или неподтвержденный

<nа>

SetArgumentSimple=(obj-handle=идентификатор объекта сканера)

SetResultSimple=(obj-handle=идентификатор объекта сканера)

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

EVENT REPORT

MDS-
Configuration-
Event

Подтвержденный или неподтвержденный

MDC_
NOTI_
CONFIG

ConfigReport

ConfigReport
Rsp

Отчет о конфигурации для сообщения менеджеру о конфигурации агента

MDS-Dynamic-
Data-
Update-Var

Подтвержденный или неподтвержденный

MDC_
NOTI_
SCAN_
REPORT_
VAR

ScanReportlnfoVar

-

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

MDS-
Dynamic-
Data-
Update-
Fixed

Подтвержденный или неподтвержденный

MDC_
NOTI_
SCAN_
REPORT_
FIXE_D

ScanReportlnfo
Fixed

-

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

MDS-
Dynamic-
Data-
Update-MP-
Var

Подтвержденный или неподтвержденный

MDC_NOTI_
SCAN_
REPORT_
MP_VAR

ScanReportlnfo
MPVar

-

То же, что и MDS-Dynamic-Data-Update-Var, но позволяет включать данные от множества людей

MDS-
Dynamic-
Data-
Update-MP-
Fixed

Подтвержденный или неподтвержденный

MDC_NOTI_
SCAN_
REPORT_
MP_FIXED

ScanReportlnfo
MPFixed

-

То же, что и MDS-Dynamic-Data-Update-Fixed, но позволяет включать данные от множества людей

EVENT REPORT

Segment-
Data-Event

Подтвержден

MDC_NOTI_
SEGMENT_
DATA

SegmentData
Event

Segment
DataResult

Событие объекта РМ-хранилища для передачи данных, хранящихся в Fixed-Segment-Data РМ-сегмента, от агента к менеджеру

Unbuf-
Scan-
Report-Var

Подтвержденный или неподтвержденный

MDC_NOTI_
UNBUF_
SCAN_
REPORT_
VAR

ScanReportlnfo
Var

-

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

Unbuf-
Scan-
Report-
Fixed

Подтвержденный или неподтвержденный

MDC_NOTI_
UNBUF_
SCAN_
REPORT_
FIXED

ScanReportlnfo
Fixed

-

То же, что и Unbuf-Scan-Report-Fixed, но с фиксированным форматом сообщения для каждого объекта

Unbuf-
Scan-
Report-
Grouped

Подтвержденный или неподтвержденный

MDC_NOTI_
UNBUF_
SCAN_
REPORT_
GROUPED

ScanReportlnfo
Grouped

-

То же, что и Unbuf-Scan-Report-Fixed, но с группированным форматом сообщений

Unbuf-
Scan-
Report-MP-
Var

Подтвержденный или неподтвержденный

MDC_NOTI_
UNBUF_
SCAN_
REPORT_
MP_
VAR

ScanReportlnfo
MPVar

-

То же, что и Unbuf-Scan-Report-Var, но позволяет включать данные от множества людей

Unbuf-
Scan-
Report-MP-
Fixed

Подтвержденный или неподтвержденный

MDC_NOTI_
UNBUF_
SCAN_
REPORT_
MP_
FIXED

ScanReportlnfo
MPFixed

-

То же, что и Unbuf-Scan-Report-Fixed, но позволяет включать данные от множества людей

Unbuf-
Scan-
Report-MP-
Grouped

Подтвержденный или неподтвержденный

MDC_NOTI_
UNBUF_
SCAN_
REPORT_
MP_
GROUPED

ScanReportlnfo
MPGrouped

-

То же, что и Unbuf-Scan-Report-Grouped, но позволяет включать данные от множества людей

EVENT REPORT

Buf-Scan-
Report-Var

Подтвержденный или неподтвержденный

MDC_NOTI_
BUF_SCAN_
REPORT_
VAR

ScanReportlnfo
Var

-

Событие периодического конфигурируемого сканера, аналогичное Unbuf-Scan-Report-Var, но содержащее данные, буферизированные через отчетный интервал

Buf-Scan-
Report-
Fixed

Подтвержденный или неподтвержденный

MDC_NOTI_
BUF_SCAN_
REPORT_
FIXED

ScanReportlnfo
Fixed

-

Событие периодического конфигурируемого сканера, аналогичное Unbuf-Scan-Report-Fixed, но содержащее данные, буферизированные через отчетный интервал

Buf-Scan-
Report-
Grouped

Подтвержденный или неподтвержденный

MDC_NOTI_
BUF_SCAN_
REPORT_
GROUPED

ScanReportlnfo
Grouped

-

Событие периодического конфигурируемого сканера, аналогичное Unbuf-Scan-Report-Grouped, но содержащее данные, буферизированные через отчетный интервал

Buf-Scan-
Report-MP-
Var

Подтвержденный или неподтвержденный

MDC_NOTI_
BUF_SCAN_
REPORT_
MP_VAR

ScanReportlnfo
MPVar

-

Событие периодического конфигурируемого сканера, аналогичное Unbuf-Scan-Report-MP-Var, но содержащее данные, буферизированные через отчетный интервал

Buf-Scan-
Report-MP-
Fixed

Подтвержденный или неподтвержденный

MDC_NOTI_
BUF_SCAN_
REPORT_
MP_FIXED

ScanReportlnfo
MPFixed

-

Событие периодического конфигурируемого сканера, аналогичное Unbuf-Scan-Report-MP-Fixed, но содержащее данные, буферизированные через отчетный интервал

Buf-Scan-
Report-MP-
Grouped

Подтвержденный или неподтвержденный

MDC_NOTI_
BUF_SCAN_
REPORT_
MP_
GROUPED

ScanReportlnfo
MPGrouped

-

Событие периодического конфигурируемого сканера, аналогичное Unbuf-Scan-Report-MP-Grouped, но содержащее данные, буферизированные через отчетный интервал

ACTION

Set-Time

Подтвержден

MDC_ACT_
SET_TIME

SetTimelnvoke

-

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

Set-Base-
Offset-Time

Подтвержден

MDC_ACT_
SET_ВО_
TIME

SetBOTimelnvoke

-

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

Clear-
Segments

Подтвержден

MDC_ACT_
SEG_CLR

SegmSelection

-

Позволяет менеджеру удалять данные, хранящиеся в выбранном РМ-сегменте в агенте

Get-
Segment-
Info

Подтвержден

MDC_ACT_
SEG_GET_
INFO

SegmSelection

SegmentlnfoList

Позволяет менеджеру извлекать значения атрибутов РМ-сегмента одного или более РМ-сегментов в агенте

Trig-
Segment-
Data-Xfer

Подтвержден

MDC_ACT_SEG_TRIG_
XFER

TrigSegmData
XferReq

TrigSegm
DataXferRsp

Позволяет менеджеру запускать передачу атрибута Fixed-Segment-Data РМ-сегмента в агенте

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) формат и содержание сообщения-уведомления о конфигурации должны быть следующими:

0xE7

0x00

Тип APDU CHOICE (PrstApdu)

0x00

0x40

CHOICE.Iength=64

0x00

0x3e

OCTET STRING.Iength=66

0x00

0x02

invoke-id=2 (запуск DataApdu. MDER закодировано)

0x01

0x01

CHOICE(Remote Operation Invoke|Confirmed Event Report)

0x00

0x38

CHOICE.Iength=56

0x00

0x00

obj-handle=0 (объект MDS)

0x00

0x00

0x00

0x00

event-time=0

0x0D

0x1C

event-type=MDC'NOTI'CONFIG

0x00

0x2e

event-info.length=46 (запуск ConfigReport)

0x02

0x58

config-report-id (значение Dev-Configuration-Id)

0x00

0x01

config-obj-list.count=1 Объект измерения будет "назван"

0x00

0x28

config-obj-list.length=40

0x00

0x06

obj-class=MDC_MOC_VMO_METRIC_NU

0x00

0x01

obj-handle=1 ( 1e измерение - это ЧСС)

0x00

0x04

attributes.count=4

0x00

0x20

attributes.length=32

0x09

0x2F

attribute-id=MDC_ATTR_ID_TYPE

0x00

0x04

attribute-value.length=4

0x00

0x02

0x4B

0x5C MDC_PART_SCADA|MDC_ECG_HEART_RATE

0x0A

0x46

attribute-id=MDC_ATTR_METRIC_SPEC_SMALL

0x00

0x02

attribute-value.length=2

0x40

0x40

Metric-Spec-Small (mss-avail-stored-data, mss-acc-agent)

0x09

0x96

attribute-id=MDC_ATTR_UNIT_CODE

0x00

0x02

attribute-value.length=2

0x0A

0xA0

MDC_DIM_BEAT_PER_MIN

0x0A

0x55

attribute-id=MDC_ATTR_ATTRIBUTE_VAL_MAP

0x00

0x0C

attribute-value.length=12

0x00

0x02

AttrValMap.count=2

0x00

0x08

AttrValMap.length=8

0x0A

0x4C

0x00

0x02

MDC_ATTR_NU_VAL_OBS_BASIC, 2

0x09

0x8F

0x00

0x04

MDC_ATTR_TIME_REL, 4

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

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

0xE7

0x00

APDU CHOICE Type (PrstApdu)

0x00

0x16

CHOICE.Iength=22

0x00

0x14

OCTET STRING.Iength=20

0x00

0x02

invoke-id=0x0002 (дублируется из вызова)

0x02

0x01

CHOICE (Remote Operation Response|Confirmed Event Report)

0x00

0x0E

CHOICE.Iength=14

0x00

0x00

obj-handle=0 (объект MDS)

0x00

0x00

0x00

0x00

currentTime=0

0x0D

0x1C

event-type=MDC_NOTI_CONFIG

0x00

0x04

event-reply-info.length=4

0x02

0x58

ConfigReportRsp.config-report-id=600

0x00

0x00

ConfigReportRsp.config-resuIt=accepted-config

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

Индекс

Свойство

Ссылка

Требование/Состояние

Поддержка

Комментарий

GEN
11073-
10406-1

Описание реализации

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

GEN
11073-
10406-2

Соблюдаемые стандарты и изменения к ним

(Стандартные документы)

(Набор имеющихся поправок)

(Набор поддерживаемых поправок)

GEN
11073-
10406-3

Используемый номенклатурный документ и поправки к нему

(Стандартные документы)

(Набор имеющихся поправок)

(Набор поддерживаемых поправок)

GEN 11073-
10406-4

Соблюдение соответствия "Уровень 1"

См. 10.3.2

Заявление об основном соответствии, о том, что прибор удовлетворяет требованиям соответствия ИИЭР Std 11073-10406:

a) все обязательные требования должны быть реализованы;

b) если реализованные, условные, рекомендованные и необязательные требования должны соответствовать настоящему стандарту

Да/Нет (нет не подразумевается как нет, которое означает, что реализация несовместима)

GEN
11073-
10406-5

Соблюдение соответствия "Уровень 2"

См. 10.3.3

В дополнение к GEN 11073-10406-4, если прибор реализует расширения и/или добавления, он должен соответствовать номенклатурным кодам ASN.1 и/или структуры 10101.

Данные расширения также должны быть определены в таблице ICS с указанием на ссылки к ним

Да/Нет

GEN
11073-
10406-6

См. 6.3

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

GEN
11073-
10406-7

(Стандартные документы)

(Набор имеющихся поправок)

(Набор поддерживаемых поправок)

GEN
11073-
10406-8

Описание метода(ов) кодирования для структур данных ASN.1

GEN
11073-
10406-9

Использует ли реализация объекты, которые не определены в DIM?

Да/Нет

(если да, то дайте объяснение в таблице 26)

GEN
11073-
10406-10

Использует ли реализация частные расширения номенклатуры (т.е. коды 0xF000-0xFFFF из ИСО/ИИЭР 11073-10101:2004 [B6])? Частные номенклатурные расширения допускаются только в том случае, если стандартные номенклатурные коды не включают специальных терминов, требуемых приложением

Да/Нет

(если да, то дайте объяснение в таблице 29)

GEN
11073-
10406-11

Предоставьте отчет о соответствии, требуемый стандартом ИИЭР Std 11073-20601а-2010

Префикс GEN 11073-10406 используется для указания в общей таблице ICS.

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

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

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

Индекс

Свойство

Ссылка

Требование/Состояние

Поддержка

Комментарий

MOC-n

Описание объекта

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

Реализован

Укажите ограничения, например, максимальное количество поддерживаемых экземпляров

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

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

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

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

10.4.4 ICS атрибута MOC

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

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

Индекс

Свойство

Ссылка

Требование/Состояние

Поддержка

Комментарий

ATTR-n-x

Наименование атрибута. Расширенные атрибуты также должны включать идентификатор атрибута

Заполните ссылкой на структуру ASN.1, если атрибут не определен в настоящем стандарте

M=Обязательный/
C=Условный/
R=Рекомендованный/
O=Необязательный (согласно определениям в таблице определений атрибута)

Реализован?

(Да/Нет)

Статический/
Динамический.

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

Опишите любые специальные ограничения

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

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

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

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

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

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

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

Индекс

Свойство

Ссылка

Требование/
Состояние

Поддержка

Коммен-
тарий

NOTI-n-x

Название сообщения и ID сообщения

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

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

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

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

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

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

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

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

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

Индекс

Свойство

Ссылка

Требование/
Состояние

Поддержка

Комментарий

NOME-n

Наименование номенклатуры и значение номенклатуры

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

Опишите, как используется номенклатура. Опишите любые специальные ограничения

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

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


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

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

[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)

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

*/

#define MDC_ATTR_TICK_RES

2693

/*

*/

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

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

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

#define MDC_ECG_TIME_PD_RR_GL

16168

/*

*/

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

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

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

#define MDC_DIM_TICK

6848

/*

*/

#define MDC_DIM_MILLI_VOLT

4274

/*

mV

/*

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

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

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

#define MDC_DEV_SPEC_PROFILE_ECG

4102

/*

/*

/* 4236 through 4243 used for IEEE Std 11073-10406 (Basic ECG)

*/

#define MDC_DEV_SUB_SPEC_PROFILE_ECG

4236

/*

*/

#define MDC_DEV_SUB_SPEC_PROFILE_HR

4237

/*

*/

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

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

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

#define MDC_ECG_DEV_STAT

21976

/*

*/

#define MDC_ECG_EVT_CTXT_GEN

21977

/*

*/

#define MDC_ECG_EVT_CTXT_USER

21978

/*

*/

#define MDC_ECG_EVT_CTXT_PERIODIC

21979

/*

*/

#define MDC_ECG_EVT_CTXT_DETECTED

21980

/*

*/

#define MDC_ECG_EVT_CTXT_EXTERNAL

21981

/*

*/

#define MDC_ECG_HEART_RATE_INSTANT

21982

/*

*/

Приложение 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 отведений) отправляет нижеописанное сообщение менеджеру. Агент намерен установить ассоциацию, используя расширенную конфигурацию.

0xE2

0x00

Тип APDU CHOICE (AarqApdu)

0x00

0x32

CHOICE.Iength=50

0x80

0x00

0x00

0x00

assoc-version

0x00

0x01

0x00

0х2А

data-proto-Iist.count=1|length=42

0x50

0x79

data-proto-id=20601

0x00

0x26

data-proto-info length=38

0x40

0x00

0x00

0x00

protocolVersion

0x80

0x00

правила кодирования=MDER

0x80

0x00

0x00

0x00

nomencIatureVersion

0x00

0x00

0x00

0x00

functionalUnits - нет возможности установки тестовой ассоциации

0x00

0x80

0x00

0x00

systemType=sys-type-agent

0x00

0x08

длина system-id=8 и значение (особое для производителя и прибора)

0x31

0x32

0x33

0x34

0x35

0x36

0x37

0x38

0x40

0x00

dev-config-id - расширенная конфигурация

0x00

0x00

data-req-mode-flags

0x01

0x00

data-req-init-agent-count=1|data-req-init-manager-count=00x00

0x00

0x00

0x00

optionList.count=0|optionList.Iength=0

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

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

0xE3

0x00

Тип APDU CHOICE (AareApdu)

0x00

0x2C

длина CHOICE.Iength=44

0x00

0x03

результат=accepted-unknown-config

0x50

0x79

data-proto-id=20601

0x00

0x26

длина data-proto-info=38

0x40

0x00

0x00

0x00

protocolVersion

0x80

0x00

правила кодирования=MDER

0x80

0x00

0x00

0x00

nomenclatureVersion

0x00

0x00

0x00

0x00

functionalUnits - обычная ассоциация

0x80

0x00

0x00

0х00

systemType=sys-type-manager

0x00

0x08

длина system-id=8 и значение (особое для производителя и прибора)

0x38

0x37

0x36

0x35

0x34

0x33

0x32

0x31

0x00

0x00

ответ менеджера на config-id всегда 0

0x00

0x00

data-req-mode-flags

0x00

0x00

data-req-init-agent-count=0|data-req-init-manager-count=0

0x00

0x00

0x00

0х00

optionList.count=0|optionList.length=0

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

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

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

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

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

0xE2

0x00

Тип APDU CHOICE (AarqApdu)

0x00

0x32

CHOICE.length=50

0x80

0x00

0x00

0x00

assoc-version

0x00

0x01

0x00

0х2А

data-proto-list.count=1|длина=42

0x50

0x79

data-proto-id=20601

0x00

0x26

длина data-proto-info=38

0x40

0x00

0x00

0x00

protocolVersion

0x80

0x00

правила кодирования=MDER

0x80

0x00

0x00

0x00

nomenclatureVersion

0x00

0x00

0x00

0x00

functionalUnits - нет возможности установки тестовой ассоциации

0x00

0x80

0x00

0х00

systemType=sys-type-agent

0x00

0x08

длина system-id=8 и значение (особое для производителя и прибора)

0x31

0x32

0x33

0x34

0x35

0x36

0x37

0x38

0x40

0x00

dev-config-id - расширенная конфигурация

0x00

0x00

data-req-mode-flags

0x01

0x00

data-req-init-agent-count=1|data-req-init-manager-count=0

0x00

0x00

0x00

0х00

optionList.count=0|optionList.length=0

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

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

0xE3

0x00

Тип APDU CHOICE (AareApdu)

0x00

0x2C

CHOICE.length=44

0x00

0x00

результат=accepted

0x50

0x79

data-proto-id=20601

0x00

0x26

длина data-proto-info=38

0x40

0x00

0x00

0x00

protocolVersion

0x80

0x00

правила кодирования=MDER

0x80

0x00

0x00

0x00

nomenclatureVersion

0x00

0x00

0x00

0x00

functionalUnits - нормальная ассоциация

0x80

0x00

0x00

0х00

systemType=sys-type-manager

0x00

0x08

длина system-id=8 и значение (особое для производителя и прибора)

0x38

0x37

0x36

0x35

0x34

0x33

0x32

0x31

0x00

0x00

ответ менеджера на config-id всегда 0

0x00

0x00

data-req-mode-flags

0x00

0x00

data-req-init-agent-count=0|data-req-init-manager-count=0

0x00

0x00

0x00

0x00

optionList.count=0|optionList.length=0

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

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

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

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

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

0xE2

0x00

Тип APDU CHOICE (AarqApdu)

0x00

0x32

CHOICE.length=50

0x80

0x00

0x00

0x00

assoc-version

0x00

0x01

0x00

0х2А

data-proto-list.count=1|length=42

0x50

0x79

data-proto-id=20601

0x00

0x26

длина data-proto-info=38

0x40

0x00

0x00

0x00

protocolVersion

0x80

0x00

правила кодирования

0x80

0x00

0x00

0x00

версия номенклатуры

0x00

0x00

0x00

0х00

функциональные узлы

0x00

0x80

0x00

0х00

systemType=sys-type-agent

0x00

0x08

длина system-id=8 и значение (особое для производителя и прибора)

0x31

0x32

0x33

0x34

0x35

0x36

0x37

0x38

0x02

0x58

dev-config-id:600

0x00

0x00

data-req-mode-flags

0x01

0x00

data-req-init-agent-count=1|data-req-init-manager-count=0

0x00

0x00

0x00

0х00

optionList.count=0|optionList.length=0

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

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

0xE3

0x00

Тип APDU CHOICE (AareApdu)

0x00

0x2C

CHOICE.length=44

0x00

0x03

Результат - принять неизвестную конфигурацию

0x50

0x79

data-proto-id=20601

0x00

0x26

data-proto-info length=38

0x40

0x00

0x00

0x00

protocolVersion

0x80

0x00

правила кодирования=MDER

0x80

0x00

0x00

0x00

nomenclatureVersion

0x00

0x00

0x00

0x00

functionalUnits

0x80

0x00

0x00

0х00

systemType=sys-type-manager

0x00

0x08

длина system-id=8 и значение (особое для производителя и прибора)

0x38

0x37

0x36

0x35

0x34

0x33

0x32

0x31

0x00

0x00

ответ менеджера на config-id всегда 0

0x00

0x00

data-req-mode-flags

0x00

0x00

data-req-init-agent-count=0|data-req-init-manager-count=0

0x00

0x00

0x00

0х00

optionList.count=0|optionList.length=0

Е.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.

0xE7

0x00

Тип APDU CHOICE (PrstApdu)

0x00

0x70

CHOICE.length=112

0x00

0x6E

OCTET STRING.length=110

0x00

0x02

invoke-id=2 (начало DataApdu. кодирован MDER.)

0x01

0x01

CHOICE(Remote Operation Invoke|Confirmed Event Report)

0x00

0x68

CHOICE.length=104

0x00

0x00

obj-handle=0 (объект MDS)

0x00

0x00

0x00

0x00

event-time=0

0x0D

0x1C

event-type=MDC_NOTI_CONFIG

0x00

0x5E

event-info.length=94 (начало ConfigReport)

0x40

0x00

config-report-id=16384

0x00

0x01

config-obj-list.count=2 объекта измерения будут "названы"

0x00

0x58

config-obj-list. length=88

0x00

0x06

obj-class=MDC_MOC_VMO_METRIC_NU

0x00

0x01

obj-handle=1 (->1-e измерение - это ЧСС)

0x00

0x04

attributes.count=4

0x00

0x24

attributes.length=36

0x09

0x2F

attribute-id=MDC_ATTR_ID_TYPE

0x00

0x04

attribute-value.length=4

0x00

0x02

0x4B

0x5C

MDC PART SCADA|MDC_ECG_HEART_RATE

0x0A

0x46

attribute-id=MDC_ATTR_METRIC_SPEC_SMALL

0x00

0x02

attribute-value.length=2

0x80

0x80

хранимые данные, инициирование агента

0x09

0x96

attribute-id=MDC_ATTR_UNIT_CODE

0x00

0x02

attribute-value.length=2

0x0A

0xA0

MDC_DIM_BEAT_PER_MIN

0x0A

0x55

attribute-id=MDC_ATTR_ATTRIBUTE_VAL_MAP

0x00

0x08

attribute-value.length=12

0x00

0x02

AttrValMap.count=2

0x00

0x08

AttrValMap.length=8

0x0A

0x4C

0x00

0x02

MDC_ATTR_NU_VAL_OBS_BASIC, 2

0x09

0x91

0x00

0x04

MDC_ATTR_TIME_STAMP_REL, 4

0x00

0x06

obj-class=MDC_MOC_VMO_METRIC_NU

0x00

0x02

obj-handle=2 (-> 2-е измерение - это интервал R-R)

0x00

0x05

attributes.count=5

0x00

0x24

attributes.length=36

0x09

0x2F

attribute-id=MDC_ATTR_ID_TYPE

0x00

0x04

attribute-value.length=4

0x00

0x02

0x3F

0x28

MDC_PART_SCADA|MDC_ECG_TIME_PD_RR_GL

0x0A

0x46

attribute-id=MDC_ATTR_METRIC_SPEC_SMALL

0x00

0x02

attribute-value.length=2

0x88

0x80

хранимые данные, метрика от удара к удару, инициирование агента

0x09

0x96

attribute-id=MDC_ATTR_UNIT_CODE

0x00

0x02

attribute-value.length=2

0x1A

0xC0

MDC_DIM_TICK

0x0A

0x55

attribute-id=MDC_ATTR_ATTRIBUTE_VAL_MAP

0x00

0x0C

attribute-value.length=12

0x00

0x02

AttrValMap.count=2

0x00

0x08

AttrValMap.length=8

0x0A

0x4C

0x00

0x02

MDC_ATTR_NU_VAL_OBS_BASIC, 2

0x09

0x8F

0x00

0x04

MDC_ATTR_TIME_REL, 4

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

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

0xE7

0x00

Тип APDU CHOICE (PrstApdu)

0x00

0x16

CHOICE.length=22

0x00

0x14

OCTET STRING.length=20

0x00

0x02

invoke-id=2 (дублируется из вызова)

0x02

0x01

CHOICE (Remote Operation Response|Confirmed Event Report)

0x00

0x0E

CHOICE.length=14

0x00

0x00

obj-handle=0 (MDS object)

0x00

0x00

0x00

0x00

currentTime=0

0x0D

0x1C

event-type=MDC_NOTI_CONFIG

0x00

0x04

event-reply-info.length=4

0x40

0x00

ConfigReportRsp.config-report-id=16384

0x00

0x00

ConfigReportRsp.config-result=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.

0xE7

0x00

Тип APDU CHOICE (PrstApdu)

0x00

0x0E

CHOICE.length=14

0x00

0x0C

OCTET STRING.length=12

0x00

0x03

invoke-id=3 (выбирает это сообщение среди любых других, выбор зависит от реализации)

0x01

0x03

CHOICE (Remote Operation Invoke|Get)

0x00

0x06

CHOICE.length=6

0x00

0x00

идентификатор=0 (объект MDS)

0x00

0x00

attribute-id-list.count=0 (все атрибуты)

0x00

0x00

attribute-id-list.length=0

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

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

0xE7

0x00

Тип APDU CHOICE (PrstApdu)

0x00

0x64

CHOICE.length=100

0x00

0x62

OCTET STRING.length=98

0x00

0x03

invoke-id=3 (дублируется из запроса)

0x02

0x03

CHOICE (Remote Operation Response|Get)

0x00

0x5C

CHOICE.length=92

0x00

0x00

идентификатор=0 (объект MDS)

0x00

0x06

attribute-list.count=6

0x00

0x56

attribute-list.length=86

0x0A

0x5A

идентификатор атрибута=MDC_ATTR_SYS_TYPE_SPEC_LIST

0x00

0x08

attribute-value.length=8

0x00

0x01

TypeVerList count=1

0x00

0x04

TypeVerList.length=4

0x10

0x8D

тип=MDC_DEV_SUB_SPEC_PROFILE_HR

0x00

0x01

версия=версия специализации 1

0x09

0x28

идентификатор атрибута=MDC_ATTR_ID_MODEL

0x00

0x22

attribute-value.length=34

0x00

0x0A

0x54

0x68

длина строки=10|"TheCompany"

0x65

0x43

0x6F

0x6D

0x70

0x61

0x6E

0x79

0x00

0x14

0x54

0x68

длина строки=20|"TheHeartRateMonitorX"

0x65

0x48

0x65

0x61

0x72

0x74

0x52

0x61

0x74

0x65

0x4D

0x6F

0x6E

0x69

0x74

0x6F

0x72

0x58

0x09

0x84

attribute-id=MDC_ATTR_S Y S_ID

0x00

0x0A

attribute-value.length=10

0x00

0x08

0x31

0x32

длина строки октетов=8|EUI-64

0x33

0x34

0x35

0x36

0x37

0x38

0x0a

0x44

attribute-id=MDC_ATTR_DEV_CONFIG_ID

0x00

0x02

attribute-value.length=2

0x40

0x00

dev-config-id=16384 (extended-config-start)

0x09

0x8F

attribute-id=MDC_ATTR_TIME_REL

0x00

0x02

attribute-value.length =4

0x00

0x00

0x64

0x00

Relative-Time=3.2c

0x0A

0x85

attribute-id=MDC ATTR TICK RES

0x00

0x04

attribute-value.length=4

0x00

0x00

0x04

0x00

Tick-Resolution=1024 s-1

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

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

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

0xE7

0x00

Тип APDU CHOICE (PrstApdu)

0x00

0x38

CHOICE.length=56

0x00

0x36

OCTET STRING.length=54

0x00

0x04

invoke-id=4

0x01

0x00

CHOICE(Remote Operation Invoke|Event Report)

0x00

0x30

CHOICE.length=48

0x00

0x00

obj-handle=0 (MDS object)

0x00

0x00

0x00

0x00

event-time=0

0x0D

0x1D

event-type=MDC_NOTI_SCAN_REPORT_FIXED

0x00

0x26

event-info.length=38

0xF0

0x00

ScanReportInfoFixed.data-req-id=0xF000

0x00

0x01

ScanReportInfoFixed.scan-report-no=1

0x00

0x01

ScanReportInfoFixed.obs-scan-fixed.count=3

0x00

0x1E

ScanReportInfoFixed.obs-scan-fixed.length=30

0x00

0x01

ScanReportInfoFixed.obs-scan-fxed.value [0].obj-handle=1

0x00

0x06

ScanReportInfoFixed.obs-scan-fixed.value[0].obs-val-data.length=6

0x00

0x79

Basic-Nu-Observed-Value=121 bpm

0x00

0x00

0xE2

0x90

Relative-Time-Stamp=7.25 s

0x00

0x02

ScanReportInfoFixed.obs-scan-fixed.value [0]. obj-handle =2

0x00

0x06

ScanReportInfoFixed.obs-scan-fixed.value[0]. obs-val-data.length =6

0x00

0x09

Basic-Nu-Observed-Value=512 импульсов

0x00

0x00

0xE2

0x90

Relative-Time-Stamp=7.25 c

0x00

0x02

ScanReportInfoFixed.obs-scan-fixed.value[0].obj-handle=2

0x00

0x06

ScanReportInfoFixed.obs-scan-fixed.value[0]. obs-val-data.length =6

0x00

0x08

Basic-Nu-Observed-Value=509 импульсов

0x00

0x00

0xF2

0x19

Relative-Time-Stamp=7.747125 c

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

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

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

0xE4

0x00

Тип APDU CHOICE (RlrqApdu)

0x00

0x02

CHOICE.length=2

0x00

0x00

причина=normal

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

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

0xE5

0x00

Тип APDU CHOICE (RlreApdu)

0x00

0x02

CHOICE.length=2

0x00

0x00

причина=normal

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


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

Таблица ДА.1

Обозначение ссылочного международного стандарта, документа

Степень соответствия

Обозначение и наименование соответствующего национального стандарта

IEEE Std 11073-20601а-2010

-

*

ISO/IEEE 11073-20601:2010

-

*

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

УДК 004:61:006.354

ОКС 35.240.80

П85

ОКСТУ 4002

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

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

и сверен по:

, 2017