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

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

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

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


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



ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

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

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

Часть 10406

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

(ISO/IEEE 11073-10406:2012, ЮТ)

НАЦИОНАЛЬНЫМ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ГОСТР

57299—

2016/

ISO/IEEE

11073-10406

2012

Издание официальное

Москва

Стандарти нформ 2017

ГОСТ Р 57299—2016

Предисловие

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

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

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

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

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

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

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

€> Стандартинформ. 2017

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

и

ГОСТ Р 57299—2016

Содержание

1    Обэор..............................................................................1

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

1.2    Цель............................................................................2

1.3    Контекст.........................................................................2

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

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

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

3.2    Сокращения.....................................................................3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.5    Профили........................................................................8

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

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

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

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

6.10    Объекты РМ-хранилища.........................................................21

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

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

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

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

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

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

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

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

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

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

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

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

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

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

III

ГОСТ Р 57299—2016

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

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

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

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

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

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

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

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

Приложение А (справочное) Библиография................................................45

Приложение В (обязательное) Несколько дополнительных определений ASN.1..................46

Приложение С (обязательное) Распределение идентификаторов..............................47

Приложение D (справочное) Примеры последовательности сообщений........................49

Приложение Е (справочное) Примеры протокольных блоков данных...........................51

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

и документов национальным стандартам Российской Федерации...............58

«V

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

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

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

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

Часть 10406

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

Health informatics. Point-of-care medical device communication.

Part 10406. Device specialization. Basic electrocardiograph (ECG) {1- to 34ead ECG)

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

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

Настоящий стандарт IEEE (Институт инженеров по электротехнике и радиоэлектронике) может применяться с учетом важных примечаний и правовых оговорок. Эти примечания и оговорки указаны во всех публикациях, содержащих данный документ, и могут быть найдены в разделе «важные примечания» или «Важные примечания и оговорки, касающиеся стандартов 1ЕЕЕ». Также их можно получить по запросу в IEEE или просмотреть на сайте .

1 Обзор

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

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

Издание официальное

1

ГОСТ Р 57299—2016

1.2    Цель

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

1.3    Контекст

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

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

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

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

Примечания

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

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

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

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

IEEE Std 11073-20601а. Health informatics — Personal health device communication — Application profile — Optimized Exchange Protocol — Amendment 1 (Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Прикладной профиль. Оптимизированный протокол обмена. Поправка 1* 2 3>)

ISO/IEEE11073-20601:2010. Health informatics» Personal health device communication—Application profile — Optimized Exchange Protocol (Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Прикладной профиль. Оптимизированный протокол обмена31)

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

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

2) Стандарты ИИЭР или документы, указанные в данном разделе, обладают товарным знаком Института инженеров по электротехнике и электронике. Публикации ИИЭР доступны в Институте инженеров по электротехнике и радиоэлектронике. Хоус-Лэйн. г. Пискагааэй. штат Нью-Джерси. 08654. США ().

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

2

ГОСТ Р 57299—2016

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

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

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

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 — система медицинских приборов:

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

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

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

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

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

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

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

3

ГОСТ Р 57299—2016

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

ГОСТ Р 57299—2016

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

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

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

(от 1 до 3 отведений)

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

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

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

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

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

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

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

5

ГОСТ Р 57299—2016

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), объекты РМ-хранилища (см. 6.10) и объекты сканера (см. 6.11). См. 6.13 для получения правил расширения информационной модели базового ЭКГ (от 1 до 3 отведений) за пределы элементов в соответствии с описанием в настоящем стандарте. Каждый раздел, описывающий объект базового ЭКГ (от 1 до 3 отведений), содержит следующую информацию:

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

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

6

ГОСТ Р 57299—2016

с помощью ASN.1. Значения ASN.1 для новых типов атрибутов, характерных для настоящего стандарта, указаны в приложении В. а значения ASN.1 для известных типов атрибутов, приведенных в ссылках в настоящем стандарте, описаны в стандарте ИИЭР Std 11073~20601а;

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

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

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

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

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

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

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

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

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

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

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

7

ГОСТ Р 57299—2016

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 колебаний ЭКГ. 8 данный момент для простого профиля ЭКГ не было определено ни одной стандартной конфигурации.

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

6.5.3 Профиль ЧСС

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

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

8

ГОСТ Р 57299—2016

Эоемплиры метрического объекта профиля PHD частота сердцебиений

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

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

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

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

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

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

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

Значение

Кделифи-

кагор

Handle

0

м

System-Type

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

NR

9

ГОСТ Р 57299—2016

Окончание таблицы 1

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

Значение

Квзпнфи-

катер

System-Type-Spec-List

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

(MDC DEV SPEC PROFILE ECG. 1} и значение профиля:

(MDC OEV SUB SPEC PROFILE ECG. 1) или (MDC DEV SUB SPEC PROFILE HR. 1)

м

System-Model

{'Manufacturer* "Model')

м

System-Id

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

м

Dev-Configuration-ld

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

м

Attribute-Value-Map

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

с

Production-Specification

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

О

Mds-Time-Infb

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

с

Date-and-Time

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

с

Base-Offset-Time

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

с

Relative-Time

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

с

HiRes-Relative-Time

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

с

Date-end-Time-Adjustment

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

с

Power-Status

onBattery или onMains

R

Battery-Level

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

R

Remaining-Battery-Time

См. ИИЭР Std 11073-206018

R

Reg-Cert-Data-Usl

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

О

Confirm-Timeout

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

О

Tick-Resolution

См. 6.6.2

С

Примечание — См. ИИЭР 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-ld содержит локально уникальный 16-битный идентификатор, который определяет конфигурацию прибора. Для агента базового ЭКГ (от 1 до 3 отведений) с расширенной конфигурацией данный идентификатор выбирается в пределах от extended-config-start до extended-config-end (см. ИИЭР Std 11073-20601а) в соответствии с таблицей 1.

Агент отправляет Dev-Configuration-ld во время ассоциированного состояния (см. 8.3) для идентификации своей конфигурации на весь период проведения ассоциации. Если менеджер уже обладает инфор

10

ГОСТ Р 57299—2016

мацией о конфигурации, относящейся к Dev-Con figuration-id. он опознает Dev-Configuration-ld и пропускает конфигурирующее состояние {см. 8.4). затем агент и менеджер переходят е рабочее состояние. Если менеджер не опознает Dev-Configuration-ld. то агент и менеджер переходят в состояние конфигурации.

6.6.2 Атрибут Tick-Resolution

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

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

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

Имя

атрибута

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

атрибута

Тип атрибута

Примечание

Кмлифиха*

торы

Tick-

Resolution

MDC ATTR TICK RES

Тип FLOAT

Данный атрибут определяет разрешение для внутреннего осциллятора агента (т. в. он устанавливает количество импульсов в сек.). Ест агент реализует объект жтервала R-R (см. 6.6.3) и использует MDC_OIM_TICK для соответствующего атрибута Unit-Code, то атрибут Tick-Resolution должен быть реализован

Условный

статичесхий

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

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

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

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

Сервис

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

Режим

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

Параметры

(action-infa-args)

Результаты

{action-in-

fo-args)

ACTION

Set-Tme

Подтвержден

MDC ACT SET TIME

SetTimelnvoke

ACTION

Set-Base-

Offset-Time

Подтвержден

MDC_ACT_SET_BO_TIME

SetBOTimelnvoke

•    Set-Time

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

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

•    Set-Base-Offset-Time

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

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

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

11

ГОСТ Р 57299—2016

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

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

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

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

Сервис

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

Режим

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

Параметры

{action-info-args)

Ре>улыаты

(action-info-args)

MDS-Configuration-

Event

Подтвержден

MDC_NOTI_CONFIG

ConfigReport

ConfigReport

Rsp

MDS-Dynamic-

Data-Update-Var

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

MDC NOTI SCAN REPORTJ/AR

ScanReportlnfoVar

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

MDS-Dynamic-

Data-Update-

Fixed

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

MDC NOT! SCAN REPORT.FIXED

ScanReportlnfoFixed

MDS-Dynamic-

Data-Update-

MP-Var

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

MDC NOTI SCAN REPORT.MPVAR

ScanReportlnfoMP

Var

MDS-Dynamic-

Data-Update-

MP-Fixed

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

MDC NOTI SCAN REPORT.MPFIXED

ScanReportlnfoMP

Fixed

•    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-20601а требуется, чтобы менеджеры поддерживали все события объектов MDS. перечисленные выше.

ГОСТ Р 57299—2016

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

<па>

< implied confirmed>

<па>

GelArgumenlSimple = (obf-handte = 0). atlribute-id-lrsl <optiona!>

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.

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

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

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

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

Неименованно

атрибута

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

Стандартная конфигурация (Oev-Conlt^u ration-id » 0x02S4)

Значение

Квалифи

кация

Значение

Квалифи

кация

Handle

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

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

13

ГОСТ Р 57299—2016

Продолжение таблицы 6

Наименование

атрибута

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

Стандартная конфигурация iDeV'ConfiQurabon-td ■ 0x0256)

Значение

Квалифи

кация

Значение

Квалифи

кация

Supplemental-

Types

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

NR

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

NR

Metric-Spec-

Small

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

М

mss-avai-stored-data. mss-acc-agent- initiated

М

Metric-Struc-lure-Small

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

NR

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

NR

Measurement-

Status

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

О

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

О

Metric-Id

См. ИИЭР Std 1107Э-206013

NR

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

NR

Metric-Id-List

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

NR

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

NR

Metric-Id-

Partition

См. ИИЭР Std 1107Э-20601а

NR

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

NR

Unit-Code

MDC DIM BEAT PER MIN

М

MDC DIM BEAT PER MIN

М

Attribute-

Value-Map

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

С

MDC ATTR NU VAL OBS BASIC, then MDC ATTR TIME STAMP,ABS

М

Source-

Handte-

Reference

См. ИИЭР Std 11073-20в01а

NR

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

NR

Label-String

См. ИИЭР Std 1107Э-20601а

О

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

О

Unil-

Label-String

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

О

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

О

Absofute-

Ttme-Stamp

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

С

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

NR

Base-Offset-

Time-Stamp

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

С

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

NR

Relative-

Time-Stamp

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

С

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

R

14

ГОСТ Р 57299—2016

Окончание таблицы 6

Наименование

атрибута

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

Стандартная конфигурация (Oev-CanK^uiation-ld * 0x02 SB)

Значение

КоапифН’

кация

Значение

Квалифи

кация

HiRes-Time-

Stamp

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

С

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

NR

Measure-

Active-Period

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

NR

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

NR

Simple-Nu-

Observed-

Value

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

С

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

NR

Compound-

Simple-Nu-

Observed-

Value

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

С

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

NR

Bastc-Nu-

Observed-

Value

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

С

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

R

Compound-

Basic-Nu-

Observed-

Value

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

С

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

NR

Nu-Observed-

Value

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

С

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

NR

Compound-

Nu-Observed-

Value

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

С

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

NR

Accuracy

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

NR

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

NR

Примечания

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

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

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

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

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

15

ГОСТ Р 57299—2016

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

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

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

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

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

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

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

Квалифи

кация

Handle

См. ИИЭР Std 11073-206013

м

Туре

{MDC PART SCADA. MDC ECG TIME PD RR GL)

м

Supplemental-Types

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

NR

Metric-Spec-Smalt

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

М

Metric-Structure-Small

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

NR

Measurement-Status

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

О

Metric-Id

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

NR

Metric-Id-List

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

NR

Metric-Id-Partition

См. ИИЭР Std 11073-206013

NR

Unit-Code

MDC DIM MILLI SEC или MDC DIM TICK

M

Attribute-Value-Map

См. ИИЭР Std 11073-206013

C

Source-Handle-Reference

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

NR

Label-String

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

0

Unit-Label-String

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

О

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

Simpie-Nu-Observed-Value

См. ИИЭР Std 1t073-20601a

C

Compound-Simple-Nu-Observed-Value

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

C

Basic-Nu-Observed-Value

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

C

Compound-Basic-Nu-Observed-Valoe

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

C

No-Observed-Value

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

C

Compound-Nu-Observed-Value

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

C

Accuracy

См. ИИЭР Std 1t073-20601a

NR

Примечания

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

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

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

16

ГОСТ Р 57299—2016

Если используется 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    Колебания ЭКГ

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

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

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

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

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

Значение

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

Handle

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

М

Туре

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

М

Supplemental-Types

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

NR

Metric-Spec-Small

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

М

Measurement-Status

См. ИИЭР Sid 11073-20601а

О

Metric-Id

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

NR

Metric-Id-List

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

NR

Metnc-ld-Partition

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

NR

Unit-Code

MDC OIM MILLI VOLT

М

Attribute-Value-Map

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

С

Source-Handle-Reference

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

NR

Label-String

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

О

Unit-Label-String

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

О

Absolute-Time-Stamp

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

С

Base-Offset-Time-Stamp

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

С

Relatrve-Time-Stamp

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

с

HiRes-Tme-Stamp

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

с

Measure-Active-Period

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

NR

Sample-Period

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

М

Simple-Sa-Observed-Value

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

м

Scale-and-Range-Specification

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

м

Sa-Specification

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

м

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

17

ГОСТ Р 57299—2016

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

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

Тип

Значение

Отведение

MDC ECG ELEC POTL

256

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

МОС ECG ELEC POTLI

257

Отведете I

MDC ECG ELEC POTL И

258

Отведение II

MOC ECG ELEC POTL III

317

Отведение III

MOC ECG ELEC POTLAVR

318

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

MOC ECG ELEC POTLAVL

319

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

MOC ECG ELEC POTLAVF

320

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

MOC ECG ELEC POTL V1

259

Отведение VI

MOC ECG ELEC POTL V2

260

Отведение V2

MOC ECG ELEC POTL V3

261

Отведение V3

MOC ECG ELEC POTL V4

262

Отведение V4

MDC ECG ELEC POTL V5

263

Отведение V5

MOC 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 — Атрибуты объектов перечисления состояния прибора

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

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

Значение

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

Напеве

См. ИИЭР Std 1107Э-20601а

M

Туре

(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-2060la

NR

Measurement-Status

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

0

Metric-Id

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

NR

18

ГОСТ Р 57299—2016

Окончание таблицы 10

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

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

Значение

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

Metric-Id-List

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

NR

Metric-Id-Partition

См. ИИЭР Std 11073-206018

NR

Unit-Code

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

NR

Attribute-Value-Map

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

С

Source-Handle-Reference

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

NR

Label-String

См. ИИЭР Std 11073-206018

О

Unil-Labet-String

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

О

Absolute-Time-Stamp

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

С

Base-Offset-Time-Stamp

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

С

Relative-Time-Stamp

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

С

HiRes-Time-Stamp

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

С

Measure-Active-Period

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

NR

Enum-Observed-Value-Simpte-OID

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

NR

Enum-Observed-Value-Simpie-Bit-Str

См. ИИЭР Std 11073-206013

NR

Enum-Observed-Value-Basic-Bit-Str

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

М

Enum-Observed-Value-Simpie-Str

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

NR

Enum-Observed-Value

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

NR

Enum-Observed-Value-Partition

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

NR

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

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

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

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

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

Мнемосхема BastcECGOevSlal

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

lead wire-loss

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

keadsignal-loss

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

lead wire-loss-first-lead

19

ГОСТ Р 57299—2016

Окончание таблицы f1

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

Мнемосхема BasicECGDevStal

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

leadsignal-toss-first-lead

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

leadwire-toss-second-lead

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

leadsignal-toss-second-lead

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

leadwire-toss-third-tead

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

leadsignal-toss-third-lead

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

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

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

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

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

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

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

Значение

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

Handle

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

M

Type

{MDC PART PHD DM.

MDC ECG EVT CTXT GEN}

M

Supplemental-Types

См. ИИЭР Std 11073-2060la

NR

Metric-Spec-Small

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

M

Metric-Structure-Smail

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

NR

Measurement-Status

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

О

Metric-id

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

NR

Metric-Id-List

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

NR

Metric-id-Partitton

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

NR

Unit-Code

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

NR

Attribute-Value-Map

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

C

Source-Handle-Reference

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

NR

Label-String

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

О

20

ГОСТ Р 57299—2016

Окончание таблицы 12

На>*ание атрибута

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

Значение

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

Unit-Labet-String

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

О

Absolute-Time-Stamp

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

С

Base-Offset-Time-Stamp

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

С

Relative-Time-Stamp

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

С

HiRes-Time-Stamp

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

С

Measura-Active-Period

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

NR

Enum-Observed-Value-Sfmpte-OID

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

М

Enum-Observed-VBlua-Simpte-Bit-Str

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

NR

Enum-Observed-Value-Basic-Bit-Str

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

NR

Enum-Observed-Value-Simpie-Str

См. ИИЭР Std 11073-206013

NR

Enum-Observed-Value

См. ИИЭР Std 11073-206013

NR

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

Для EnunvObserved-Value-Simple-OID должны использоваться коды, определенные в таблице 13. Таблица 13 — Номенклатурные коды для запуска контекстных данных

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

Ссылочный ID

Код

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

MDC_ECG_EVT_CTXT_USER

21978

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

MOC_ECG_EVT_CTXT_PERIOD1C

21979

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

MDC_ECG_EVT_CTXT_DETECTED

21980

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

MDC_ECG_EVT_CTXT_EXTERNAL

21981

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

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

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

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

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

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

21

ГОСТ Р 57299—2016

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

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

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

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

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

Эюмпляры мтричасмхообмкта гфофиля PHD стандартной. _юифигудада» (OX2S3)_

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

22

ГОСТ Р 57299—2016

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

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

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

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

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

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

Значение

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

Handle

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

М

PM-Store-Capab

См. ИИЭР Std 11073-206018

М

Slore-Sampie-AJgorithm

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

М

Store-Capacity-Count

См. ИИЭР Std 11073-206018

м

Store-Usage-Count

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

м

Operational-State

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

м

PM-Store-Label

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

о

Sample-Period

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

с

Number-Of-Segments

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

м

Clear-Timeoul

См. ИИЭР Std 11073-206018

м

23

ГОСТ Р 57299—2016

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

-    pmsc-var-no-of-segm

Если агент создает новые сегменты вследствие хранения данных от множества сеансов или изменениями во времени в соответствии с описанием в разделе «Сопоставимое время» в ИИЭР Std 11073-20601а. то бит 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-20601а для получения информации о том. является ли атрибут статическим или динамическим.

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

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

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

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

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

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

Значение

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

Handle

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

М

PM-Store-Capab

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

М

Store-Sample-Algorithm

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

М

Store-Capacity-Count

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

М

Store-Usage-Count

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

М

Operational-State

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

М

PM-Store-Labet

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

О

Sample-Period

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

NR

Number-Of-Segments

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

М

Clear-Timeout

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

М

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

-    pmsc-var-no-of-segm

Если агент создает новые сегменты вследствие хранения данных от множества сеансов или изменениями во времени в соответствии с описанием в разделе «Сопоставимое время» в ИИЭР Std 11073* 20601а. то бит 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-20601а для получения информации о том. является ли атрибут статическим или динамическим.

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

24

ГОСТ Р 57299—2016

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

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

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

Сервис

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

Режим

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

Параметр

(action-inlo-args)

Результаты

(action-inlo-args}

ACTION

Clear-

Segments

Подтверж

ден

MDC_ACT_SEG_CLR

SegmSelecbon

Get-

Segment-

Info

Подтверж

ден

MDC ACT SEG GET INFO

Segm Selection

SegmentlnfoUst

Trig-

Segment-

Data-Xfer

Подтверж

ден

MDC ACT SEG TRIG XFER

TrigSegmDataXferReq

TrigSegmDataXferRsp

•    Clear-Segments

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

•    Get-Segment-Info

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

•    Trig-Segment-Data-Xfer

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

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

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

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

Сервис

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

Режим

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

Параметр

{evenl-info)

Результаты

(event-repty-info)

EVENT

REPORT

Segment-

Data-Event

Подтвер

жден

MDC NOT! SEG MENT.DATA

SegmentDataEvent

SegmentDataResult

• Segment-Data-Event

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

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

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

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

6.10.7.2    Сервис GET

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

6.10.7.3    Сервис SET

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

25

ГОСТ Р 57299—2016

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

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

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

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

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

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

Значение

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

Instance-Number

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

М

PM-Segment-Entry-Map

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

М

PM-Seg-Per son-id

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

С

Operational-State

См. ИИЭР Std 11073-206013

М

Sample-Period

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

С

Segment-Label

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

О

Segment-Start-Abs-Time

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

С

Segment-End-Abs-Time

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

С

Date-and-Time-Adjustment

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

С

Segment-Start-BO-Time

См. ИИЭР Std 11073-206018

С

Segment-End-BO-Time

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

С

Segment-Usage-Count

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

М

Segment-Statistics

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

О

Fixed-Segment-Data

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

М

Confirm-Timeout

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

О

Transfer-Timeout

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

М

Примечания

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

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

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

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

26

ГОСТ Р 57299—2016

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

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

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

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

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

Значение

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

Instance-Number

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

М

PM-Segment-Entry-Map

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

м

PM-Seg-Person-ld

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

с

Operational-State

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

м

Sample-Period

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

о

Segment-Label

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

О

Segment-Start-Abs-Tcme

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

м

Segment-End-Abs-Time

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

м

Date-and-Time-Adjustment

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

с

Segment-Start-BO-Time

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

с

Segment-End-BO-Time

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

с

Segment-Usage-Count

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

м

Segment-Statistics

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

О

Fixed-Segment-Data

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

м

Confirm-Timeout

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

О

Transfer-Timeout

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

м

Примечания

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

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

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

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

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

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

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

27

ГОСТ Р 57299—2016

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

Экземпляры объекта сканера PHD базового ЭКГ

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

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

Отчет

Абсолютное

ЧСС

Образцы данных

Образцы данных

Образцы данных

о событии 1

время

отведения I

отведения II

отведения III

Отчет

Абсолютное

ЧСС

Образцы данных

Образцы данных

Образцы данных

о событии 2

время

отведения I

отведения II

отведения ill

Отчет

Абсолютное

ЧСС

Образцы данных

Образцы данных

Образцы данных

о событии 3

время

отведения I

отведения II

отведения III

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

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

28

ГОСТ Р 57299—2016

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

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

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

Значение

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

Handle

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

M

Operational-State

См. ИИЭР Std 11073-206013

M

Scan-Handle-List

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

c

Scan-Handle-A ttr-Val-Map

См. ИИЭР Std 11073-206013

c

Confirm-Mode

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

M

Confirm-Timeout

См. ИИЭР Std 11073-206013

о

Transmit-Window

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

о

Reporting-Interval

См. ИИЭР Std 11073-206013

м

Примечания

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

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

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

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

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

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

Событие

Режим

Тип события

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

Event-

repJy.

into

Buf-Scan-

Report-Var

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

MDC NOTI BUF SCAN REPORT.VAR

ScanReporttnfoVar

Buf-Scan-

Report-

Fixed

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

MDC NOTI BUF SCAN

report_f7xed

ScanReportlnfoFixed

Buf-Scan-

Report-

Grouped

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

MDC NOTI BUF SCAN REPORT_GROUPED

ScanReportlnfoGrouped

Buf-Scan-

Report-MP-

Var

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

MDC NOTI BUF SCAN REPORTJv1P_VAR

ScanReportlnfoM P Var

Buf-Scan-

Report-MP-

Fixed

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

MDC NOTI BUF SCAN REPORT_MP_FIXED

ScanReportlnfoMPFixed

Buf-Scan-

Report-MP-

Grouped

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

MDC NOTI BUF SCAN REPORT_MP_GROUPED

Scan Report InfoM PGrouped

29

ГОСТ Р 57299—2016

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

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

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

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

Значение

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

Нал (Эе

См. ИИЭР 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

О

Transmit-Window

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

О

MirvReporting-Interval

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

M

Примечания

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

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

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

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

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

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

Событие

Режим

Тип события

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

Event-

reply-

into

Unbuf-Scarv

Report-Var

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

MDC NOT UNBUF SCAN REPORT.VAR

ScanReportlnfoVar

Unbuf-Scarv

Report-

Fixed

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

MDC NOT UNBUF SCAN REPORT.FIXED

ScanReportlnfoFixed

Unbuf-Scan-

Report-

Grouped

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

MDC NOT UNBUF SCAN REPORT.GROUPED

ScanReportlnfoGrouped

Unbuf-Scan-

Report-MP-

Var

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

MDC NOT UNBUF SCAN REPORT_MP_VAR

ScanReportlnfoMPVar

Unbuf-Scan-

Report-MP-

Fixed

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

MDC NOT UNBUF SCAN REPORT_MP_FIXED

ScanReportlnfoMPFixed

30

ГОСТ Р 57299—2016

Окончание таблицы 23

Событие

Режим

Тип события

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

Event'

reply-

info

Unbuf-Scan-

Report-MP-

Grouped

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

MDC NOT UNBUF SCAN REPORT_MP_GROUPED

ScanReporttnfoMPGrouped

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.11.2 и 6.11.3 для объектов сканера;

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

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

31

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

Cepetc

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

Ражим

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

параметр

Реэулыаг

Примечание

GET

<na>

<*npfced

Confifmed>

«па»

GelArgumentSmple = (obj-handte =0). attribute-id-fcst <cpftana/>

GelResuttSxnpie = (obj-hancfte =0), attribute-fist

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

<па>

<«rpked

Confirmed»

«па»

GetArgumentSimpte «(otf-trandte * идентификатор объекта PM-хранилища), attribute-id-

list <opik)na>

GetResuttSimpte * (obj-handte * идентификатор объекта PM-хранилища), attnbute-itet

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

SET

<па>

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

«па»

SetArgumentSimpte ■ {obfhandte * идеи-тификатор объекта сканера)

SeftesuttSimpie ■ (oljj-handte » идентификатор объекта сканера)

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

EVENT

REPORT

MDS-

Configgration-

Event

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

MDC

NOTI

CONFIG

ConfigReport

ConfigReport

Rsp

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

MDS-Dynamic-Data-

Update-Var

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

MDC

NOTI

SCAN

REPORT

VAR

ScanReportlntoVaf

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

MDS-

Dynamic-

Data-

Update-

Fixed

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

MDC

NOTI

SCAN

REPORT

FIXE.D

ScanReponinfo

Fixed

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

MDS-

Dynarmc-

Data-

Update- MP-Var

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

MDC

NOTI

SCAN

REPORT

MP_VAR

ScanReportlnfo

MPVar

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

MDS-

Dynarrac-

Data-

Update- MP-Fixed

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

MDC NOTI SCAN REPORT MP

FIXED

ScanReportlnfo

MPFixed

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

ГОСТ Р 57299—2016

/продолжение тобпицы 24

Сврмс

на«м«моевиие типе лоясереиса

Режим

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

Параметр

Разул «rar

Примечание

EVENT

REPORT

Segment-Data-Event

Подтвержден

MDC NOTI SEGMENT DATA

SegmentData

Event

Segment

DataReeutt

Событие объекта PM-хранилища для передачи данных, хранящихся a 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-Repon-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 MPG rouped

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

и

ы

ГОСТ Р 57299—2016

£ Продолжение таблицы 24

С«рмс

Нэлмоюеание типа лодс «рейс а

Режим

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

Параметр

Резулыаг

Примечание

EVENT

REPORT

But-Scan-Report-Var

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

MDC NOTI BUF SCAN REPORT VAR

ScanReponinfo

Var

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

But-Scan-

Report-

Fixed

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

MDC NOTI BUF SCAN REPORT FIXED

ScanReportlnfo

Fixed

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

But-Scan-

Report-

Grouped

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

MDC NOTI BUF SCAN REPORT GROUPED

ScanReportlnfo

Grouped

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

But-Scan-Report-MP-Var

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

MDC NOTI BUF SCAN REPORT MP_VAR

ScanReportlnfo

MFVar

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

But-Scan-Report-MP-Fixed

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

MDC NOTI BUF SCAN REPORT MP_FIXED

ScanReportlnfo

MPFixed

Событие периодического конфигурируемого сханера. аналогичное Unbuf-S can-Re port-MP-Faed. но содержащее данные, буферизированные через отчетный интервал

But-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

Seffimelnvofce

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

ГОСТ Р 57299—2016

Окончание таблицы 24

Сер&с

на*м«моееиив типе лодсереиса

Режим

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

Параметр

Резулыат

Примечание

ACTION

Set-Base-Offeet-Trrte

Подтвержден

МОС ACT SET ВО TIME

SefiOTvne Invoke

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

Clear-

Segments

Подтвержден

MDC ACT SEG.CLR

Segm Select on

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

Get-

Segment-

Inb

Подтвержден

MDC ACT SEG GET INFO

Segm Select on

SegmenUnfoLtsI

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

Trig-

Segment-

Dats-Xfer

Подтвержден

MDC ACT SEG TRIG XFER

TrigS eg mData XlerReq

TrigS egm DataXferRsp

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

ы

ГОСТ Р 57299—2016

ГОСТ Р 57299—2016

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) в приложении Е.

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

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

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

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

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

36

ГОСТ Р 57299—2016

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

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

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

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

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

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

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

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

1)    Агент должен поддерживать версию protocol-version2. Поддержка любой другой версии может быть указана путем установки дополнительных битов. Если используются протоколы с номером версии выше, чем protocol-v6fsion2. агент должен продолжать использовать только функции в соответствии с указанием в настоящем стандарте. Если используются протоколы с номером версии ниже, чем 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-ld объекта MOS агента:

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-20601а. Например, если все другие условия протокола ассоциации соблюдены, 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 должно иметь все биты, за исключением тех. что относятся к тестовой ассоциации:

37

ГОСТ Р 57299—2016

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

6)    Поле system-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. 8 этом случае процедура настройки конфигурации, указанная в ИИЭР Std 11073*20601а. должна соблюдаться. Пункт 8.4.2 описывает ответные сообщения и уведомления о конфигурации для агента базового ЭКГ (от 1 до 3 отведений) со стандартной конфигурацией Ю 600 (0x0258). Как правило, менеджер уже будет знать стандартную конфигурацию. Однако в целях приведения данного примера менеджер не знает стандартной конфигурации.

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

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

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

0хЕ7 0x00

Тип APDU CHOICE (PrstApdu)

0x00 0x40

CHOICE.iength = 64

0x00 ОхЗе

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

0x00 Ох 1C

event-type = MDC'NOTl'CONFIG

0x00 0х2е

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

0x02 0x58

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

0x00 0x01

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

0x00 0x28

conftg-obj-list.length = 40

0x00 0x06

obj-class = MDC_MOCVMO_METRIC_NU

0x00 0x01

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

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 0x4В

OxSC MDC PART.SCADA | MDC_ECG_HEART RATE

ОхОА 0x46

attribute-id = MDC_ATTR_METRIC_SPEC_SMALL

0x00 0x02

attribute-value.length = 2

0x40 0x40

Metric-Spec-Small (mss-avaii-stored-data. mss-acc-agent

0x09 0x96

attribute-id * MDC_ATTR_UNIT_CODE

0x00 0x02

attribute-value.length = 2

ОхОА ОхАО

MDC_DIM 8EAT_PER_MIN

ОхОА 0x55

attribute-id = MDC_ATTR_ATTRIBUTE_VAL_MAP

0x00 ОхОС

attribute-value.length = 12

0x00 0x02

AttrValMap.count = 2

0x00 0x08

AttrValMap.length = 8

ОхОА 0х4С 0x00

0x02

MOC ATTR NU VAL OBS BASIC. 2

0x09 0x8F 0x00

0x04

MDC_ATTR_TIME_REL. 4

38

ГОСТ Р 57299—2016

8А.2.2 Процедура менеджера

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

сообщения-уведомления о конфигурации должны быть следующими:

0хЕ7 0x00 0x00 0x16 0x00 0x14 0x00 0x02 0x02 0x01 0x00 ОхОЕ 0x00 0x00

0x00 0x00 0x00 0x00 0x00 0x1С 0x00 0x04 0x02 0x58 0x00 0x00

APDU CHOICE Type (PrstApdu)

CHOICE.tength г 22

OCTET STRING.Iength = 20

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

CHOICE (Remote Operation Response | Confirmed Event Report) CHOICE.tength = 14 obj-handte * 0 (объект MDS) currentTlme = 0

event-type = MDC_NOTI_CONFIG event-reply-info.length = 4 ConfigReportRsp.config-report-id = 600 ConfigReportRsp.config-resutt = accepted-config

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

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

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

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-20601а.

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

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

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

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

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

39

ГОСТ Р 57299—2016

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

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

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

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

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

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

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

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

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

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

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

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

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

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

•    моделям сервисов и протоколов:

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

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

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

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

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

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

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

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

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

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

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

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

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

40

ГОСТ Р 57299—2016

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

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

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

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

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

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

(Стандартнее

документы)

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

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

41

ГОСТ Р 57299—2016

Продолжение таблицы 25

Индекс4'

Свойство

Ссыпка

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

Поддержка

Комментарий

GEN

11073-

10406-4

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

См. 10.3.2

Заявление об основном соответствт. о том. что прибор удовлетворяет требованиям соответствия ИИЭР Sid 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—OxFFFF из ИСО/ИИЭР 11073-10101:2004 [В6))? Частные номенклатурные расширения допускаются только в том случае.

Да/Нет

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

42

ГОСТ Р 57299—2016

Окончание таблицы 25

Индекс*)

Свойство

Ссылка

Требование.'Сосгоянне

Поддержка

Комментарий

GEN

11073-

10406-10

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

GEN

11073-

10406-11

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

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

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

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

Таблица 26 — Образец таблицы DIM МОС ICS

Индекс

Свойство

Ссылка

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

Поддержка

Комментарий

МОС-п

Описание

объекта

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

Реализован

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

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

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

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

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

10.4.41CS атрибута МОС

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

Таблица 27 — Образец таблицы ICS атрибута МОС

Индекс

Свойство

Ссылка

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

Поддержка

Комментарий

ATTR-n-x

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

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

М = Обязательный/

С = Условный /

R = Рекомендованный/

О = Необязательный (согласно определениям в таблице определений атрибута)

Реализован?

(Да/Нет)

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

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

43

ГОСТ Р 57299—2016

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

Индекс о в графе «Индекс» относится к идентификатору управляемого объекта, для которою предоставлена таблица (т. е. индекс объекта менеджера в соответствии с указанием в МОС ICS). Для каждого поддерживаемого управляемого объекта создается отдельная таблица.

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

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

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

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

Таблица 28 — Образец таблицы ICS сообщения МОС

Индекс

Свойство

Ссыпка

Требование/

Состояние

Поддержка

Коммен

тарий

NOTI-o-x

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

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

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

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

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

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

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

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

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

Таблица 29 — Образец таблицы ICS номенклатуры МОС

Индекс»)

Свойство

Ссылка

Требование/

Состояние

Поддеряиа

Коммен

тарий

NOME-/?

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

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

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

8> Индекс л в графе «Индекс» является уникальным серийным номером (1..гл).

44

ГОСТ Р 57299—2016

Приложение А

(справочное)

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

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

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

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

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

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

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

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

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

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

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

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

2) Публикации EN имеются в Европейском комитете по стандартизации (CEN). 36. rue de Stassarl. В-1050 Брюссель. Бельгия ().

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

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

*) Публикации ГГ1) имеются в Международном союзе по телекоммуникациям. Place des Nations. 1211 Женева 20. Швейцария ()

45

ГОСТ Р 57299—2016

Приложение В

(обязательное)

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

Побитовое отображение состояния приборов, отведений или сигналов Объект перечисления состояния прибора требует следующего определения структуры ASN.1 BasicECGDevStat ::= BITS-16 { leadwire-loss(O) leadsignat-loss(l) leadwire4oss-first-lead(2) leads»gnaWoss-firsl4ead{3) leadwire-loss-second-lead(4) leads*gnaWoss-secood-lead{5) leadwire-foss-third-lead(6) leads*gnaHoss-thtrd-lead(7)

>

46

ГОСТ Р 57299—2016

Приложение С

(обязательное)

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

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

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

/

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

7

«define MDC_ATTR_TICK_RES    2693    Л

7

/............*..........................................................................................................................

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

.........................................................................................................................*............../

«define MDC_ECG_TIME_PD_RR_GL    16168    Л

7

/•'*........*..........................................................................................................................

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

........................................................................................................................................

«define MDC_DIM_TICK    6648    Г

7

«define MDC_DIM_MllLI_VOLT    4274 Г mV    7

/............*.........................................................................................................................

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

.............*..........................................................................................................................,

«define MDC_DEV_SPEC_PROFlLE_ECG    4102    Г

7

Г 4236 through 4243 used for IEEE Std 11073-10406 (Basic ECG)    7

«define MDC_DEV_SUB_SPEC_PROFILE_ECG    4236    Г    7

«define MDC_DEV_SUB_SPEC_PROFILE_HR    4237    Г    7

/............*...........................................................................................................................

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

..............................................................................................*........................................./

«define MDC_ECG_DEV_STAT    21976    Г    7

«define MDC_ECG_EVT_CTXT_GEN    21977    Г    7

47

ГОСТ Р 57299—2016

«define MDC_ECG_EVT_CTXT_USER «define MDC_ECG_EVT_CTXT_PERIODlC «define MOC_ECG_EVT_CTXT_DETECTED «define MDC_ECG_EVT_CTXT_EXTERNAL «define MDC ECG HEART RATE INSTANT

21978

r

7

21979

r

7

21980

r

7

21981

r

7

21982

r

7

48

ГОСТ Р 57299—2016

Приложение О

(справочное)

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

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

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

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

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

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

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

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

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

49

ГОСТ Р 57299—2016

(см. 6.2.22) (см. Е^.21)

(ем. Е.Э2 2) (см. Е.Э.2.3)

(См. Е.4.1.2) (см. 6.4.1.3)

(см Е 51)

(см. Е.б.1) (см. Е«2)

Агент

Менеджер

Connectlnfeeeon (lowert_ayennfo}

CoorwctlndicatTon (LcwerUyarirfO)

Запрос на ассоциацию (data-proto-list. system-id. dcv-confcg-id, opfcon-tst)

Ответ на ассоциецио (acoepi_unknown-confie. dau-pfoto-к). syrtenvia.opdon-Sst)

проверить system-id. проверить dev-confo-и

П

Дьнью (Вита I ПодтоорЖАвмный Отчет еСобыпы MOC_NOT_CONF)G, dev-conlig-M. сспвд-object-tel)

Менеджер "i распознает syelenvid Mde^oonfi£id_

Денные (Ответ I Подтвержденный Отчет о Событии. MDC_NOTI_CONFIG. eccapt-config)

хранить Осу-еогЛд-кз и Коифитурацмо

данные (Вызов I Get. handle9*))

Данные (Ответ I Gat Атрибуты MOS)

Дажые (вызов I Ноподтеержаежый Отчет о Событии, M0C_M0T1_SCAN_R£P0«T_FIX£0. evenNnfp)

• ♦ •

Дон то (вызов 1 Неполтвержоежый Отчет о Событии. MQC_40Ti_SCAN_REPQRT_FIXE0. evenl-infe)

Ass «аз sonRe lease Rsquesttfsason) AssociaborAelease Request reason)

Connectlncfccalion (LowerLayertnfo)

ConnectlndicaGon (LowerLayertnfo}

Association Re<jue*1(oaea-proto-M1. syslom-«d, dov-ccnfig-M.opaon4st)

AasodaHonRoquettyaccepted. dola-proio-id, sy* tom-id. optkoNsI)

доверить system-id. проверить flev-contg-a

Данные (Ответ l Подтверждежый Отчет о Событии. MDC_NOTI_SCAN_REPORT_FKEO. event-irfe)

Менеджер распознает system-id Hde^oonfi^jd

Денные (Ответ I неподтвержденный Отчет о Событии. MPC_HOT(_SCAN_R6PORT_FIXEP.Qvent-lnto)

AssocselionReleaee Request reason) AsscdobonRelease Roquost(reaeon)

Рисунок 0.1 —Диаграмма последовательности для примера использования базового ЭЮ* (от 1 до 3 отведений)

50

ГОСТ Р 57299—2016

Приложение Е

(справочное)

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

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

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

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

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

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

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

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

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

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

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

0хЕ2

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-td = 20601

0x00

0x26

data-proto-info length = 38

0x40

0x00

0x00

0x00

protocofVersion

0x80

0x00

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

0x80

0x00

0x00

0x00

nomeoclatureVersion

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-conf»g-kJ — расширенная конфигурация

0x00

0x00

data-req-mode-flags

0x01

0x00

data-req-init-agent-count = 11 data-req-init-manager-count=00x0 0

0x00

0x00

0x00

optionList.count = 0 | opt>onlist.length = 0

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

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

ОхЕЗ 0x00    Тип APOU CHOICE (AareApdu)

0x00    0х2С    длина CHOICE.length =44

0x00    0x03    результат = accepted-unknown-oonfig

0x50    0x79    data-proto-id = 20601

0x00    0x26    длина data-proto-info = 38

51

ГОСТ Р 57299—2016

0x40

0x00

0x00

0x00

protocolVersion

0x80

0x00

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

ОхвО

0x00

0x00

0x00

nomendatureVerston

0x00

0x00

0x00

0x00

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

0x80

0x00

0x00

0x00

system Туре = 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 f data-req-init-manager-countsO

0x00

0x00

0x00

0x00

optionUst.count = 0 | option!.ist.length = 0

Е.2.3 Расширенные конфигурации, известные ранее Е.2.3.1 Общие положения

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

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

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

0xE2

0x00

Тип APDU CHOICE (AarqApdu)

0x00

0x32

CHOICE.Iength = 50

0x80

0x00

0x00

0x00

assoc-version

0x00

0x01

0x00

0x2A

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

0x50

0x79

data-proto-ki = 20601

0x00

0x26

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

0x40

0x00

0x00

0x00

protocolVersion

0x80

0x00

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

0x80

0x00

0x00

0x00

nomendatureVerston

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 = 11 data-req-init-manager-oount=0

0x00

0x00

0x00

0x00

opbonUstxount = 01 optionList.length = 0

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

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

гурацию).

ОхЕЗ

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

nomendatureVersion

0x00

0x00

0x00

0x00

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

0x80

0x00

0x00

0x00

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-oount=0

0x00

0x00

0x00

0x00

opbonlist.counl = 01 optionList.length = 0

52

ГОСТ Р 57299—2016

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

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

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

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

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

0хЕ2

0x00

Тип APDU CHOICE (AarqApdu)

0x00

0x32

CHOICE.length = 50

0x80

0x00

0x00

0x00

assoc-version

0x00

0x01

0x00

0х2А

data-proto-itst.count = 11 length = 42

0x50

0x79

data-proto-id = 20601

0x00

0x26

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

0x40

0x00

0x00

0x00

protocoiVersion

0x80

0x00

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

0x80

0x00

0x00

0x00

версия номенкпагуры

0x00

0x00

0x00

0x00

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

0x00

0x80

0x00

0x00

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

dala-req-mode-flags

0x01

0x00

data-req-init-agent-count = 11 data-req-mit-manager-count=0

0x00

0x00

0x00

0x00

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

protocoiVersion

0x80

0x00

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

0x80

0x00

0x00

0x00

nomenctatureVersion

0x00

0x00

0x00

0x00

functionalUnits

0x80

0x00

0x00

0x00

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-fiags

0x00

0x00

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

0x00

0x00

0x00

0x00

optionList.count = 0 | optionlist.length = 0

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

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

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

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

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

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

53

ГОСТ Р 57299—2016

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

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

0xE7

0x00

Тип APDU CHOICE (PrstApdu)

0x00

0x70

CHOICE.length = 112

0x00

0x6E

OCTET STRING.Iength = 110

0x00

0x02

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

0x01

0x01

CHOICE(Remote Operation Invoke | Confirmed Event Report)

0x00

0x68

CHOICE.Iength = 104

0x00

0x00

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

0x00

0x00

0x00

0x00

event-time = 0

0x00

0x1C

event-type = MDC_NOTI_CONFIG

0x00

0x5E

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

0x40

0x00

config-report-id = 16384

0x00

0x01

config-obj4ist.count = 2 объекта измерения будут ‘названы*

0x00

0x58

config-obj-lisl. length = 88

0x00

0x06

obj-dass = MDC_MOC_VMO_METRIC_NU

0x00

0x01

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

0x00

0x04

attributes.oount = 4

0x00

0x24

attributes.length = 36

0x09

0x2F

attribute-id = MDC_ATTR_ID_TYPE

0x00

0x04

attribute-value.length = 4

0x00

0x02

0x4 В

0x5C

MDC PART SCADA | MDC ECG HEART RATE

OxOA

0x46

aUribute-id = MDC_ATTR_METRIC_SPEC_SMALL

0x00

0x02

aUribute-value.length = 2

0x80

0x80

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

0x09

0x96

attribute-id = MDC_ATTR_UNIT_COOE

0x00

0x02

attribute-value.length = 2

OxOA

OxAO

MDC_DIM_BEAT_PER_M1N

OxOA

0x55

attribute-id = MDC_ATTR_ATTRIBUTE_VAL_MAP

0x00

0x08

attribute-value, length = 12

0x00

0x02

AttrValMap.count = 2

0x00

0x08

AltrValMap.length = 8

OxOA

0x4C

0x00

0x02

MDC ATTR NU VAL OB S BASIC. 2

0x09

0x91

0x00

0x04

MDC ATTR TIME STAMP REL.4

0x00

0x06

ob)-class = MDC_MOC_VMO_METR!C_NU

0x00

0x02

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

0x00

0x05

attributes.count = 5

0x00

0x24

attributes.length = 36

0x09

Gx2F

attribute-id = MDC_ATTR_1D_TYPE

0x00

0x04

attribute-value, length = 4

0x00

0x02

0x3F

0x28

MDC_PART_SCADA | MDC_ECG_TIME_PD_RR_GL

OxOA

0x46

attribute-id = MDC_ATTR_METRIC_SPEC_SMALL

0x00

0x02

attribute-value.length = 2

0x88

0x80

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

0x09

0x96

attribute-id = MDC_ATTR_UNIT_COOE

0x00

0x02

attribute-value.length = 2

0x1A

OxCO

MDC DIM TICK

OxOA

0x55

attribute-id = MDC_ATTR_ATTRIBUTE_VAL_MAP

0x00

OxOC

attribute-value.length = 12

0x00

0x02

AttrValMap.count = 2

0x00

0x08

AtlrValMap.length = 8

OxOA

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

0хЕ7 0x00    Тип APDU CHOICE (PrslApdu)

0x00 0x16    CHOICE.length = 22

0x00 0x14    OCTET STRING.Iength = 20

54

ГОСТ Р 57299—2016

0x02    mvoke-»d = 2 (дублируется из вызове)

0x01    CHOICE (Remote Operation Response | Confirmed Event Report)

OxOE    CHOICE.length = 14

0x00    obj-handte = 0 (MDS object)

0x00 0x00 0x00 current Time = 0 0x1C    event-type = MDC_NOTI_CONFIG

0x04    event-repty-info.length = 4

0x00    ConfigReportRsp.config-report-id * 16384

0x00    ConfigReportRsp.config-result = accepted-oonfig

E.3.3 Известная конфигурация E.3.3.1 Общие положения

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

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

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

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

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

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

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

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

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

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

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

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

0x00

0x02

0x00

0x00

0x00

0x00

0x00

0x40

0x00

Е.4 Сервис GET атрибута MDS Е.4.1.1 Общие сведения

Атрибуты GET MDS вызываются в любое время, копа агент находится в ассоциированном состоянии. Е.4.1.2 Запрос на получение всех атрибутов системы медицинских приборов Менеджер запрашивает у агента его атрибуты объекта MDS.

0хЕ7

0x00

Тип APDU CHOICE (PrstApdu)

0x00

ОхОЕ

CHOICE.length = 14

0x00

ОхОС

OCTET STRING.tength = 12

0x00

0x03

tnvofce-*d = 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

attnbute-kJ-lisilength = 0

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

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

которые необязательные поля.

0хЕ7

0x00

Тип APDU CHOICE (PrstApdu)

0x00

0x64

CHOICE.length = 100

0x00

0x62

OCTET STRING.tength = 98

0x00

0x03

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

0x02

0x03

CHOICE (Remote Operation Response | Get)

0x00

0х5С

CHOICE, length = 92

55

ГОСТ Р 57299—2016

0x00

0x00

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

0x00

0x06

attnbute-hst.count = 6

0x00

0x56

attribute-list.length = 86

ОхОА

0х5А

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

0x00

0x06

attribute-value.length = 8

0x00

0x01

TypeVerList count = 1

0x00

0x04

TypeVerListJength = 4

0x10

0x8D

тип = M0C_DEV_SUB_SPEC_PROFILE_HR

0x00

0x01

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

0x09

0x28

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

0x00

0x22

aUnbute-value.length = 34

0x00

ОхОА

0x54

0x68

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

0x65

0x43

0x6F

0x6D

0x70

0x61

ОхбЕ

0x79

0x00

0x14

0x54

0x68

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

0x65

0x48

0x65

0x61

0x72

0x74

0x52

0x61

0x74

0x65

0x4 D

0x6F

ОхбЕ

0x69

0x74

0x6F

0x72

0x58

0x09

0x84

attribute-id = MDC_ATTR_S Y S_1D

0x00

ОхОА

attribute-value.length = 10

0x00

0x08

0x31

0x32

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

0x33

0x34

0x35

0x36

0x37

0x38

0x0а

0x44

attribute-id = MDC_ATTR_DEV_CONFIGJD

0x00

0x02

attribute-value.length = 2

0x40

0x00

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

0x09

0x6F

attribute-id = MDC_ATTR_TIME_REL

0x00

0x02

attribute-value.length =4

0x00

0x00

0x64

0x00

Relative-Time = 3.2c

ОхОА

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

OxOD

0x1 D

event-type = MDC_NOTI_SCAN_REPORT_FIXED

0x00

0x26

event-info.length = 38

OxFO

0x00

ScanReportlnfoFixed.data-req-kJ = OxFOOO

0x00

0x01

ScanReportlnfoFixed.scarweport-no = 1

0x00

0x01

ScanReportlnfoFixed.obs-scan-fixed.count = 3

0x00

0x1E

ScanReporttntoFixed.obs-scan-fixed.length = 30

0x00

0x01

ScanReportlnfoF ixed. obs-scan-fixed. value (0].obj -handte =1

0x00

0x06

ScanReportlnfoFixed.obs-scan-fixed.vakje[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

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

0x00

0x06

ScanReportinfoFixed.obs-scan-fixed.va!ue[Oj. obs-val-data.iength =6

0x00

0x09

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

0x00

0x00

0xE2

0x90

Relative-Time-Stamp = 7.25 c

56

ГОСТ Р 57299—2016

0x00

0x00

0x00

0x00

0x02

0x06

0x08

0x00

0xF2

ScanReportlnfoFixed.obs-scan-fixed.va>ue[0].obj-han<fte =2 ScanRepor1lnfoFixed.obs-scan-fixed.vaIue[0]. obs-val-data .length =6 Bas>c-Nu*Observed-Value = 509 импульсов 0x19 Relatrve-Time-Slamp = 7.747125 c

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

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

Агент базового ЭКГ (от 1 до 3 отведений) отправляет менеджеру нижеописанное сообщение. 0хЕ4 0x00    Тип APDU CHOICE (RlrqApdu)

0x00 0x02    CHOICE.Iength = 2

0x00 0x00    причина = normal

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

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

0хЕ5 0x00 0x00 0x02 0x00 0x00

Тип APDU CHOICE (RlreApdu) CHOICE.Iength - 2 причина = normal

57

ГОСТ Р 57299—2016

Приложение ДА

(справочное)

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

Таблица ДА.1

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

Степень

соответствия

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

lEEEStd 11073-20601а-2010

в

ISO/IEEE 11073-20601:2010

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

58

ГОСТ Р 57299—2016

УДК 004:61:006.354

ОКС 35.240.80    П85

ОКСТУ 4002

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

59

Редактор А.Ф. Копчин Корректор Е.Р. Ароян Компьютерная верстка Ю.8. Поповой

Слано в набор 02.12.2016. Подписано а печать 25.01.2017. Формат 60 * 04 Vg. Гарнитура Ариал.

Уел. печ. л. 6.98.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Набрано в ИД «Юриспруденция». 115419. Москва, ул. Орджоникидзе. II. >и    

Издано ао ФГУП «СТАНДАРТИНФОРМ*. 12399S. Москва. Гранатный пер.. 4.