ГОСТ Р 59524-2021 Информатизация здоровья. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10408. Специализация прибора. Термометр

Обложка ГОСТ Р 59524-2021 Информатизация здоровья. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10408. Специализация прибора. Термометр
Обозначение
ГОСТ Р 59524-2021
Наименование
Информатизация здоровья. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10408. Специализация прибора. Термометр
Статус
Действует
Дата введения
2022.01.01
Дата отмены
-
Заменен на
-
Код ОКС
35.240.80

ГОСТ Р 59524-2021/ISO/IEEE 11073-10408:2010

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

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

СВЯЗЬ С МЕДИЦИНСКИМИ ПРИБОРАМИ ИНДИВИДУАЛЬНОГО КОНТРОЛЯ СОСТОЯНИЯ ЗДОРОВЬЯ

Часть 10408

Специализация прибора. Термометр

Health informatics. Personal health device communication. Part 10408. Device specialization. Thermometer

ОКС 35.240.80

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

Предисловие

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

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 468 "Информатизация здоровья"

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

4 Настоящий стандарт идентичен международному стандарту ISO/IEEE 11073-10408:2010 "Информатизация здоровья. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10408. Специализация прибора. Термометр" (ISO/IEEE 11073-10408:2010 "Health informatics - Personal health device communication - Part 10408: Device specialization - Thermometer", IDT).

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

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

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

Введение

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

Документы по стандартам IEEE разрабатываются в сообществах IEEE и Координационных комитетах по стандартизации Совета по стандартам Ассоциации стандартов IEEE (IEEE-SA). Институт IEEE разрабатывает свои стандарты на основе процесса достижения консенсуса, одобренного Американским национальным институтом стандартов (American National Standards Institute, ANSI), который для достижения конечного результата объединяет добровольцев, представляющих различные точки зрения и интересы. Добровольцы не обязательно являются членами института и работают безвозмездно. Хотя IEEE управляет процессом и устанавливает правила, способствующие обеспечению справедливости в процессе достижения консенсуса, институт не проводит независимую оценку, тестирование или проверку достоверности какой-либо информации, содержащейся в его стандартах.

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

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

ISO/IEEE 11073-10408 был подготовлен Комитетом по стандартам 11073 сообщества IEEE по техническим средствам, применяемым в области медицины и биологии (как IEEE 11073-10417-2015). Он был принят Техническим комитетом ИСО/ТК 215 "Информатизация здоровья" параллельно с его утверждением членами ИСО, в соответствии с ускоренной процедурой, определенной в соглашении о сотрудничестве между ИСО и IEEE в рамках партнерской организации по разработке стандартов. Обе стороны несут ответственность за содержание данного документа.

Серия стандартов ISO/IEEE 11073 под общим названием "Информатизация здоровья. Связь с медицинскими приборами индивидуального контроля состояния здоровья" состоит из следующих частей:

- Часть 10101. Номенклатура;

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

- Часть 10404. Специализация прибора. Пульсовой оксиметр;

- Часть 10407. Специализация прибора. Монитор артериального давления;

- Часть 10408. Специализация прибора. Термометр;

- Часть 10415. Специализация прибора. Весы;

- Часть 10417. Специализация прибора. Глюкометр;

- Часть 10471. Специализация прибора. Автономный центр обеспечения жизнедеятельности;

- Часть 20101. Прикладные профили. Базовый стандарт;

- Часть 20601. Прикладной профиль. Оптимизированный протокол обмена;

- Часть 30200. Транспортный профиль. Кабельное соединение;

- Часть 30300. Транспортный профиль. Инфракрасный канал связи.

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

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

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

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

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

Настоящий стандарт устанавливает нормативное определение обмена данными между персональными телемедицинскими приборами термометра и вычислительными устройствами (например, сотовыми телефонами, персональными компьютерами, бытовыми медицинскими приборами контроля и телевизионными приставками) таким образом, чтобы обеспечить plug-and-play (подключи-и-работай) совместимость. Он использует соответствующие компоненты существующих стандартов, включая терминологию, информационные модели, стандарты прикладного профиля и транспортные стандарты комплекса стандартов ISO/IEEE 11073. Он определяет использование специфических кодов терминов, форматов и моделей поведения в телемедицинских средах, ограничивающих опциональность в базовых интегрированных системах в интересах интероперабельности. Настоящий стандарт определяет общее ядро коммуникационной функциональности для персональных телемедицинских термометров.

1.2 Назначение

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

1.3 Контекст

Обзор условий, в которых применяется настоящий стандарт, приведен в IEEE 11073-20601.

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

Настоящий стандарт основан на IEEE 1073-20601, который, в свою очередь, использует информацию как из ISO/IEEE 11073-10201:2004 [B3]
, так и из ISO/IEEE 11073-20101:2004 [B4]. Правила кодирования медицинских устройств (MDER), используемые в этом стандарте, полностью описаны в IEEE 11073-20601.

________________

Цифры в скобках соответствуют цифрам библиографии в приложении А.

Настоящий стандарт повторяет соответствующие части номенклатуры, содержащейся в ISO/IEEE 11073-10101:2004 [B2], и добавляет новые номенклатурные коды для целей настоящего стандарта. В данном стандарте и в IEEE 11073-20601 задокументированы все необходимые для реализации номенклатурные коды.

Примечание - В настоящем стандарте IEEE 11073-104zz используется для обозначения серии стандартов для устройств различной специализации, которое использует IEEE 11073-20601-2014, где zz может быть любым числом от 01 до 99 включительно
.

________________

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

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

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

IEEE 11073-20601-2008, Health informatics - Personal health device communication - Part 20601: Application Profile - Optimized Exchange Protocol (Информатизация здоровья. Обмен данными с персональными медицинскими приборами. Часть 20601. Прикладной профиль. Оптимизированный протокол обмена данными)

________________

Обозначения стандартов или документов IEEE, указанные в этом разделе, являются товарными знаками Института инженеров по электротехнике и радиоэлектронике (Institute of Electrical and Electronics Engineers, Inc.).
Публикации IEEE доступны в Институте инженеров по электротехнике и радиоэлектронике, 445 Hoes Lane,Piscataway, NJ 08854, США.

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

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

В настоящем стандарте применены термины с соответствующими определениями. Термины, не определенные в данном разделе, должны находиться в онлайн-словаре стандартов IEEE.

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

3.1.2 температура тела (body temperature): Измерение внутренней температуры тела человека.

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

3.1.4 вычислительное устройство (compute engine): См. менеджер.

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

3.1.6 температура конечности (extremity body temperature): Измерение температуры на конечностях тела человека, на пальце руки или ноги.

3.1.7 дескриптор (handle): Локально уникальное 16-разрядное число без знака, идентифицирующее один из экземпляров объекта в агенте.

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

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

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

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

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

3.2 Сокращения

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

APDU

- блок данных прикладного протокола (application protocol data unit);

ASN.1

- абстрактная синтаксическая нотация версии 1 (Abstract Syntax Notation One);

DIM

- информационная модель предметной области (domain information model);

EUI-64

- расширенный уникальный идентификатор (64 бита) [(extended unique identifier (64 bits)];

ICS

- заявление о соответствии реализации (implementation conformance statement);

MDC

- обмен данными с медицинским прибором (medical device communication);

MDER

- правила кодирования для медицинских устройств (medical device encoding rules);

MDS

- система медицинского прибора (medical device system);

MOC

- класс управляемых объектов (managed object class);

PDU

- блок данных протокола (protocol data unit);

PHD

- персональный медицинский прибор (personal health device);

RT-SA

- массив считываний в реальном времени (real-time sample array);

VMO

- виртуальный медицинский объект (virtual medical object);

VMS

- виртуальная медицинская система (virtual medical system).

4 Введение в стандарты комплекса IEEE 11073™ по персональным медицинским приборам

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

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

Стандарт IEEE 11073-20601-2014 поддерживает моделирование и реализацию широкого множества персональных медицинских приборов. Настоящий стандарт определяет требования к прибору термометра. В нем определены все аспекты, необходимые для реализации сервисов прикладного уровня и протокола обмена данными между агентом термометра и менеджером, соответствующих серии стандартов ISO/IEEE 11073, посвященных персональным медицинским приборам (ПМП). Настоящий стандарт определяет подмножество объектов и функциональные возможности, описанные в IEEE 11073-20601-2014, и при необходимости расширяет и добавляет некоторые определения. Все новые определения, приведенные в приложении В, соответствуют абстрактной синтаксической нотации версии 1 (ASN.1). Номенклатурные коды, указанные в настоящем стандарте, которые не определены в ISO/IEEE 11073-20601-2014, представлены в нормативном приложении C.

4.2 Введение в структуры моделирования IEEE 11073-20601

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

В основу серии стандартов ISO/IEEE 11073, и в частности IEEE 11073-20601-2014, положена парадигма управления объектно-ориентированными системами. Общая модель системы состоит из трех основных компонентов: информационная модель предметной области (DIM), сервисная модель и коммуникационная модель. Подробное описание структур моделирования приведено в IEEE 11073-20601.

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

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

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

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

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

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

4.2.5 Реализация моделей

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

5 Концепция устройства термометра и возможные реализации

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

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

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

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

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

5.2 Температура тела

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

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

Основными единицами измерения температуры, используемыми в медицине, являются градусы по Цельсию и по Фаренгейту.

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

6.1 Обзор

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

6.2 Расширение классов

В настоящем стандарте не определены расширения классов по отношению к описанным в IEEE 11073-20601.

6.3 Диаграмма объектов

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

Объекты предметной области (DIM), представленные на рисунке 1, описаны в 6.4-6.12. К ним относятся объекты системы медицинского прибора (MDS) (см. 6.5) и числовые объекты термометра (см. 6.6). Объекты массивов считываний в реальном времени (RT-SA) (см. 6.7), объекты перечислений (см. 6.8), объекты класса постоянного хранения (PM-store) (см. 6.9), а также объекты класса сканера (см. 6.10) не используются в описании термометра. Каждый раздел, описывающий объект термометра, содержит следующую информацию:

- номенклатурный код, используемый для идентификации класса объекта. Одним из примеров использования этого кода является событие конфигурации, в котором для каждого объекта указывается его класс. Это позволяет менеджеру определить, является ли класс указанного объекта числовым (Numeric), массивом считываний в реальном времени (RT-SA), перечислением (Enumeration), классом сканера (Scanner) или классом постоянного хранения (PM-store);

- атрибуты объекта. Каждый объект имеет атрибуты, которые представляют и передают информацию о физическом устройстве и его источниках данных. Каждый объект имеет атрибут Handle (дескриптор), который идентифицирует экземпляр объекта в агенте. Доступ к значениям атрибутов и их изменение осуществляются с помощью таких методов, как GET (получить) и SET (установить). Типы атрибутов определены в нотации ASN.1. Определения в нотации ASN.1 для новых типов атрибутов, специфичных для настоящего стандарта, содержатся в приложении В, а определения в нотации ASN.1 для существующих типов атрибутов, указанных в настоящем стандарте, приведены в IEEE 11073-20601;

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

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

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

Атрибуты каждого класса описаны в таблицах, в которых указаны имя атрибута, его значение и квалификатор. Квалификаторы означают следующее: M - атрибут является обязательным (mandatory), C - атрибут является условно-обязательным (conditional) и зависит от условия, указанного в графах "Примечание" или "Значение" (если имеется ссылка на IEEE 11073-20601, то условия берутся из него), R - атрибут является рекомендуемым (recommended), NR - атрибут является нерекомендуемым (not recommended), а O - атрибут является необязательным (optional). Обязательные атрибуты должны быть реализованы в агенте. Условно-обязательные атрибуты должны быть реализованы при выполнении условия обязательности и могут быть реализованы в противном случае. Рекомендуемые атрибуты по возможности должны быть реализованы в агенте. Нерекомендуемые атрибуты не должны быть реализованы в агенте. Необязательные атрибуты могут быть реализованы в агенте.

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

Рисунок 1 - Информационная модель предметной области термометра

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

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

Согласно IEEE 11073-20601 возможны два типа конфигурации. Пункты 6.4.2 и 6.4.3 кратко описывают стандартную и расширенную конфигурации.

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

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

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

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

6.5 Объект системы медицинских приборов (MDS)

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

В таблице 1 представлены атрибуты объекта термометр MDS. Номенклатурный код для идентификации класса MDS-MDC_MOC_VMS_MDS_SIMP.

В таблице 1 приведены атрибуты объекта MDS термометра. Для идентификации класса MDS используется номенклатурный код MDC_MOC_VMS_MDS_SIMP.

В ответ на команду Get получения данных объекта MDS возвращаются только реализованные атрибуты и соответствующие им значения. Описание отдельных атрибутов, а также сведения об идентификаторе и типе атрибута приведены в IEEE 11073-20601.

Атрибут Dev-Configuration-Id содержит локально уникальный 16-разрядный идентификатор, определяющий конфигурацию прибора. Для агента термометра, использующего расширенную конфигурацию, этот идентификатор выбирается из диапазона значений от extended-config-start до extended-config-end, как показано в таблице 1 (см. IEEE 11073-20601).

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

Имя атрибута

Значение

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

Handle

0

M

System-Type

Атрибут отсутствует. См. IEEE 11073-20601

C

System-Model

{"Производитель", "Модель"}

M

System-Id

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

M

Dev-Configuration-Id

Стандартная конфигурация: 0x0320 (800)

Расширенные конфигурации: 0x4000-0x7FFF

M

Attribute-Value-Map

См. IEEE 11073-20601

C

Production-Specification

См. IEEE 11073-20601

O

Mds-Time-Info

См. IEEE 11073-20601

C

Date-and-Time

См. IEEE 11073-20601

C

Relative-Time

См. IEEE 11073-20601

C

HiRes-Relative-Time

См. IEEE 11073-20601

C

Date-and-Time-Adjustment

См. IEEE 11073-20601

C

Power-Status

onBattery (от батареи) или onMains (от сети)

R

Battery-Level

См. IEEE 11073-20601

R

Remaining-Battery-Time

См. IEEE 11073-20601

R

Reg-Cert-Data-List

См. IEEE 11073-20601

O

System-Type-Spec-List

См. IEEE 11073-20601

M

Confirm-Timeout

См. IEEE 11073-20601

O

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

В состоянии "Ассоциирующий" (Associating) агент передает идентификатор Dev-Configuration-Id (см. 8.3), для идентификации своей конфигурации в течение всего сеанса связи. Если менеджер уже имеет информацию о конфигурации, связанную с идентификатором Dev-Configuration-Id, то он распознает этот идентификатор, пропускает состояние "Конфигурирующий" (Configuring) (см. 8.4), после чего агент и менеджер переходят в состояние "Выполнение" (Operating). Если менеджер не распознает идентификатор Dev-Configuration-Id, то агент и менеджер переходят в состояние "Конфигурирующий" (Configuring).

Если агент реализует несколько типов специализаций IEEE 11073-104zz, то атрибут System-Type-Spec-List содержит список пар тип/версия, каждая из которых указывает соответствующую специализацию устройства и версию этой специализации.

6.5.2 Методы объекта MDS

В таблице 2 приведены методы (действия) объекта MDS. Эти методы вызываются с помощью сервиса Action. В графе "Имя типа субсервиса" (Subservice type name) таблицы 2 указано имя метода; в графе "Режим" (Mode) указано, вызывается ли метод как неподтверждаемое действие (например, roiv-cmip-action из IEEE 11073-20601) или подтверждаемое действие (например, roiv-cmip-confirmed-action); в графе "Тип субсервиса (action-type)" (Subservice type) определен номенклатурный код, используемый в поле action-type запроса на действие и ответа (см. IEEE 11073-20601); в графе "Поле параметров (action-info-args)" (Parameters) указано имя структуры данных, определенной в нотации ASN.1 (определения нотации ASN.1 см. в IEEE 11073-20601), используемое для уведомления о действии в поле action-info-args запроса; и в графе "Поле результатов (action-info-args)" (Results) указано имя структуры данных для использования в поле action-info-args ответа.

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

Сервис

Имя типа субсервиса

Режим

Тип субсервиса (action-type)

Поле параметров (action-info-args)

Поле результатов (action-info-args)

ACTION

Set-Time

Подтверждаемый

MDC_ACT_SET_TIME

SetTimeInvoke

-

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

6.5.3 События объекта MDS

Агенты, соответствующие только данной и никакой другой специализации устройства, должны передавать отчеты о событиях с использованием передачи данных измерений, инициированной агентом. В процессе процедуры ассоциации в поле data-req-mode-capab должно быть установлено подходящее значение data-req-supp-init-agent, определяющее стиль отчета о событии (см. 8.3). При этом менеджер должен исходить из того, что агент термометра не поддерживает ни одну из функций MDS-Data-Request (дополнительная информация приведена в IEEE 11073-20601). Биту data-req-init-manager-count должно быть присвоено значение 0, а биту datareq-init-agent-count - значение 1.

Агенты, следующие этой специализации устройства, так же как и другие агенты, должны отправлять отчеты о событиях в соответствующем порядке. В процессе процедуры ассоциации (см. 8.3) в поле data-req-mode-capab должно быть установлено подходящее значение, определяющее стиль отчета о событии (см. 8.3).

В таблице 3 приведены события, которые могут быть переданы объектом MDS термометра.

Таблица 3 - События объекта MDS термометра

Сервис

Имя типа субсервиса

Режим

Тип субсервиса (event-type)

Поле параметров (event-info)

Поле результатов (event-reply-info)

EVENT REPORT

MDS-Configuration-Event

Подтверждаемый

MDC_NOTI_CONFIG

ConfigReport

Config ReportRsp

MDS-Dynamic-Data-Update-Var

Подтверждаемый

MDC_NOTI_SCAN_REPORT_VAR

ScanReportInfoVar

-

MDS-Dynamic-Data-Update-Fixed

Подтверждаемый

MDC_NOTI_SCAN_REPORT_FIXED

ScanReportInfoFixed

-

MDS-Dynamic-Data-Update-MP-Var

Подтверждаемый

MDC_NOTI_SCAN_REPORT_MP_VAR

ScanReportInfoMPVar

-

MDS-Dynamic-Data-Update-MP-Fixed

Подтверждаемый

MDC_NOTI_SCAN_REPORT_MP_FIXED

ScanReportInfoMPFixed

-

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

MDS-Dynamic-Data-Update-Var: это событие предоставляет динамические данные измерений, хранимые агентом термометра в числовых объектах. Они предоставляются в виде общего списка атрибутов с использованием переменного формата. Событие передается агентом в виде незапрашиваемого сообщения (то есть передачи данных измерений, инициированной агентом). Дополнительные сведения о незапрашиваемых отчетах о событиях приведены в 8.5.3. События считывания температуры, хранящиеся в объекте MDS, должны передаваться не чаще одного раза в секунду.

MDS-Dynamic-Data-Update-Fixed: это событие предоставляет динамические данные измерений агента термометра числового объекта температуры тела. Они передаются в фиксированном формате, определяемом атрибутом 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, но позволяет учитывать данные от нескольких человек.

Примечание - Согласно требованиям IEEE 11073-20601 менеджеры должны поддерживать все перечисленные выше события объектов MDS.

6.5.4 Другие сервисы объекта MDS

6.5.4.1 Сервис GET (получить)

Агент термометра должен поддерживать сервис GET, который предоставляется объектом MDS для получения значений всех реализованных атрибутов объекта MDS. Сервис GET может вызываться, как только агент термометра на запрос ассоциации получает ответ Association Response и переходит в состояние "Ассоциирован" (Associated), включая подсостояния "Выполнение" (Operating) и "Конфигурирующий" (Configuring).

Менеджер может запросить атрибуты объекта MDS агента термометра; в этом случае он должен отправить команду "Remote Operation Invoke | Get" (см. roiv-cmip-get в IEEE 11073-20601) с зарезервированным нулевым значением дескриптора MDS. Агент термометра должен передать свои атрибуты объекта MDS менеджеру с помощью сообщения "Remote Operation Response | Get" (см. rors-cmip-get в IEEE 11073-20601-2014). Сводная информация о сервисе GET, включающая в себя некоторые поля сообщений, приведена в таблице 4.

Таблица 4 - Сервис GET объекта MDS Термометр

Сервис

Имя типа субсервиса

Режим

Тип субсер-

виса

Поле параметров

Поле результатов

GET

-

<потенциально подтверждаемый>

-

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

GetResultSimple = (obj-handle = 0), attributelist

Подробнее процедура получения атрибутов объекта MDS описана в 8.5.2.

6.5.4.2 Сервис SET (установить)

Специализация термометра не требует реализации поддержки сервиса SET объекта MDS.

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

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

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

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

6.6.2 Температура

В таблице 5 представлены атрибуты числового объекта температуры тела. Для идентификации числового класса Numeric используется номенклатурный код MDC_MOC_VMO_METRIC_NU. Агент термометра должен поддерживать числовой объект температуры тела.

Таблица 5 - Атрибуты числового объекта температуры тела

Имя атрибута

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

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

Значение

Ква-

лифи-

катор

Значение

Ква-

лифи-

катор

Handle

См. IEEE 11073-20601

M

1

M

Type

{MDC_PART_SCADA, MDC_TEMP_zzz}

M

{MDC_PART_SCADA, MDC_TEMP_BODY}

M

Supplemental-Types

См. IEEE 11073-20601

NR

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

NR

Metric-Spec-Small

mss-avail-intermittent, mssavail-stored-data, mss-msmtaperiodic, mss-acc-agentinitiated

M

mss-avail-intermittent, mss-avail-stored-data, mss-upd-aperiodic, mss-msmt-aperiodic, mssacc-agent-initiated

M

Metric-Structure-Small

См. IEEE 11073-20601

NR

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

NR

Measurement-Status

См. IEEE 11073-20601

R

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

O

Metric-Id

См. IEEE 11073-20601

C

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

NR

Metric-Id-List

См. IEEE 11073-20601

NR

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

NR

Metric-Id-Partition

См. IEEE 11073-20601

C

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

NR

Unit-Code

MDC_DIM_DEGC или MDC_DIM_FAHR

M

MDC_DIM_DEGC

M

Attribute-Value-Map

См. IEEE 11073-20601

C

MDC_ATTR_NU_VAL_OBS_BASIC, затем MDC_ ATTR_TIME_STAMP_ABS

M

Source-Handle-Reference

См. IEEE 11073-20601

NR

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

NR

Label-String

См. IEEE 11073-20601

O

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

O

Unit-LabelString

См. IEEE 11073-20601

O

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

O

Absolute-Time-Stamp

См. IEEE 11073-20601

C

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

C

Relative-Time-Stamp

См. IEEE 11073-20601

C

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

C

HiRes-Time-Stamp

См. IEEE 11073-20601

C

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

C

Measure-Active-Period

См. IEEE 11073-20601

NR

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

NR

Simple-Nu-Observed-Value

См. IEEE 11073-20601

C

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

в противном случае применяются условия из IEEE 11073-20601

C

Compound-Simple-Nu-Observed-Value

См. IEEE 11073-20601

C

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

C

Basic-Nu-Observed-Value

См. IEEE 11073-20601

C

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

C

Compound-Basic-Nu-Observed-Value

См. IEEE 11073-20601

C

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

C

Nu-Observed-Value

См. IEEE 11073-20601

C

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-2060.

C

Compound-Nu-Observed-Value

См. IEEE 11073-20601

C

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

C

Accuracy

См. IEEE 11073-20601

R

Атрибут изначально отсутствует. Если присутствует, см. IEEE 11073-20601

R

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

Для агента термометра, имеющего стандартную конфигурацию, структура AttrValMap (см. IEEE 11073-20601) атрибута Attribute-Value-Map должна содержать идентификаторы и информацию о длине атрибутов Basic-Nu-Observed-Value и Base-Offset-Time-Stamp в той же последовательности, как указано в таблице 6.

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

Описания отдельных атрибутов, а также сведения об их идентификаторах и типах см. в IEEE 11073-20601.

Идентификатор {MDC_PART_SCADA, MDC_TEMP_BODY} является стандартной конфигурацией и обозначает измерение общей температуры тела.

Как указано в таблице 6, идентификаторы {MDC_PART_SCADA, MDC_TEMP_zzz} используются в расширенных конфигурациях и могут передавать информацию о конкретном типе, месте или специфичном методе измерения температуры.

Таблица 6 - Расширенная конфигурация: тип температуры

Тип

Значение

Место измерения

MDC_TEMP_AXILLA

57380

Подмышечная впадина

MDC_TEMP_BODY

19292

Измерение общей температуры тела

MDC_TEMP_EAR

57356

Ухо (обычно мочка уха)

MDC_TEMP_FINGER

57360

Палец

MDC_TEMP_GIT

57384

Желудочно-кишечный тракт

MDC_TEMP_ORAL

57352

Рот

MDC_TEMP_RECT

57348

Прямая кишка

MDC_TEMP_TOE

57376

Палец ноги

MDC_TEMP_TYMP

19320

Барабанная перепонка

6.7 Объекты массива считываний в реальном времени

Объекты массива считываний в реальном времени настоящим стандартом не требуются.

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

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

6.9 Объекты длительного хранения PM-store

Объекты длительного хранения PM-store настоящим стандартом не требуются.

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

Объекты сканера настоящим стандартом не требуются.

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

В настоящем стандарте не определены никакие объекты расширения класса по отношению к описанным в IEEE 11073-20601.

6.12 Правила расширения информационной модели термометра

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

Агент термометра, имеющий конфигурацию с расширениями, выходящими за рамки стандартной конфигурации, описанной в настоящем стандарте, должен использовать идентификатор конфигурации в диапазоне идентификаторов, зарезервированных для расширенных конфигураций (см. IEEE 11073-20601).

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

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

Сервисная модель определяет концептуальные механизмы сервисов обмена данными. Эти сервисы отображаются на сообщения, которыми обмениваются агент и менеджер. Сообщения протокола в рамках серии стандартов ISO/IEEE 11073 определены в нотации ASN.1. Подробное описание сервисной модели персональных медицинских приборов приведено в IEEE 11073-20601-2014. Подразделы 7.2 и 7.3 определяют специфику служб доступа к объектам и отчетов о событиях для агента термометра в соответствии с настоящим стандартом.

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

Для доступа к объектам, определенным в информационной модели предметной области термометра, используются сервисы доступа к объектам, описанные в IEEE 11073-20601.

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

- сервис GET (получить): используется менеджером для получения от агента значений атрибутов объекта MDS. Список атрибутов объекта MDS термометра приведен в 6.5.4.1;

- сервис SET (установить): используется менеджером для установки значений атрибутов объекта агента. В настоящем стандарте для агента термометра устанавливаемые атрибуты не определены;

- сервис Event Report (отчет о событии): используется агентом для передачи менеджеру обновлений конфигурации и результатов измерений. Список отчетов о событиях для специализации прибора термометра приведен в 6.5.3;

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

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

Таблица 7 - Сервисы доступа к объекту термометр

Сервис

Имя субсервиса

Режим

Тип субсервиса

Поле параметров

Поле результатов

Примечание

GET

-

<потенциально подтверждаемый>

-

GetArgument-Simple=

(obj-handle = 0), attribute-id-list <необязательный>

GetResult-Simple=

(obj-handle =0), attribute-list

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

EVENT REPORT

MDS-Configuration-Event

Подтверждаемый

MDC_

NOTI_

CONFIG

ConfigReport

ConfigReport-Rsp

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

MDS-Dynamic-Data-Update-Var

Подтверждаемый

MDC_

NOTI_

SCAN_

REPORT_

VAR

ScanReportInfo-Var

-

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

EVENT REPORT

MDS-Dynamic-Data-Update-Fixed

Подтверждаемый

MDC_

NOTI_

SCAN_

REPORT_

FIXED

ScanReportInfo-Fixed

-

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

MDS-Dynamic-Data-Update-MP-Var

Подтверждаемый

MDC_

NOTI_

SCAN_

REPORT_

MP_VAR

ScanReport-InfoMPVar

-

Аналогично MDS-Dynamic-Data-Update-Var, но позволяет учитывать данные от нескольких человек

MDS-Dynamic-Data-Update-MP-Fixed

Подтверждаемый

MDC_

NOTI_

SCAN_

REPORT_

MP_FIXED

ScanReport-InfoMPFixed

-

Аналогично MDS-Dynamic-Data-Update-Fixed, но позволяет учитывать данные от нескольких человек

ACTION

Set-Time

Подтверждаемый

MDC_ ACT_ SET_ TIME

SetTimeInvoke

-

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

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

Сервис отчетов о событиях (см. таблицу 7) используется агентом для отправки своей информации (например, измерений). В настоящем стандарте отчеты о событиях являются свойством только объекта MDS. Отчеты о событиях, используемые в настоящем стандарте, определены в IEEE 11073-20601-2014.

К агенту термометра в соответствии с настоящим стандартом применяются следующие требования:

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

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

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

Менеджер должен поддерживать отчеты о событиях с одним лицом и с несколькими лицами. Агент термометра может поддерживать один или оба варианта отчета о событиях, с одним и несколькими лицами. В IEEE 11073-20601 описаны форматы для отчетов о событиях с одним лицом и с несколькими лицами.

8 Коммуникационная модель термометра

8.1 Обзор

В настоящем разделе описаны общая коммуникационная модель и процедуры агента термометра, определенные в IEEE 11073-20601. Поэтому соответствующие части IEEE 11073-20601 не воспроизводятся; вместо этого приведены конкретные варианты и ограничения в отношении необязательных элементов (например, объектов, атрибутов и действий) и конкретных расширений (например, номенклатурных терминов).

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

8.2 Коммуникационные характеристики

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

Для агента термометра, не реализующего никакой другой специализации устройства, кроме настоящего стандарта, максимальный размер отправленного блока APDU не должен превышать Ntx, а размер принимаемого блока APDU не должен превышать Nrx. В настоящем стандарте размер Ntx должен составлять 896 байт, а размер Nrx должен составлять 224 байта.

Для агента термометра, реализующего функции приборов других специализаций, на верхний предел размеров блоков APDU накладываются следующие ограничения: размер блока APDU, передаваемого агентом, не должен превышать сумму величин Ntx всех реализованных специализаций устройств, а размер блока APDU, принимаемого агентом, не должен превышать сумму величин Nrx. Если эти значения превышают максимальный размер, определенный в IEEE 11073-20601, должен применяться последний.

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

8.3 Процедура ассоциирования

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

Процедура ассоциирования агента термометра и менеджера должна осуществляться в соответствии с требованиями IEEE 11073-20601.

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

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

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

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

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

1) агент должен поддерживать protocol-version1 (т.е. версия протокола = 0x80000000);

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

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

8) если агент поддерживает только специализацию термометра, то в поле, указывающем режимы запроса данных (data-req-mode-capab), поддерживаемые агентом термометра, должно быть установлено значение data-req-supp-init-agent. Если агент поддерживает только специализацию термометра, то в поле data-req-init-manager-count должно быть установлено значение 0, а в поле data-req-init-agent-count - значение 1.

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

В ответном сообщении на запрос ассоциации, отправленном менеджером:

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

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

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

1) менеджер, соответствующий данной специализации, должен поддерживать версию протокола protocol-version1 (т.е. protocol-version = 0x80000000);

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

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

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

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 и data-req-init-manage-count должны быть равны 0. Если агент поддерживает только специализацию термометра, то значение поля data-req-init-agent-count должно иметь значение 1.

8.4 Процедура конфигурирования

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

Если в ответ на запрос ассоциации агент получает сообщение accepted-unknown-config, то он переходит в состояние "Конфигурирующий" (Configuring). После этого должна начаться процедура конфигурации, приведенная в IEEE 11073-20601. В 8.4.2 описаны уведомления о конфигурации и ответные сообщения для агента термометра стандартной конфигурации 800, имеющей идентификатор 0x0320. Как правило, менеджер уже распознает стандартную конфигурацию. Однако в данном примере менеджер этого не делает.

8.4.2 Термометр - стандартная конфигурация

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

Для передачи своей конфигурации менеджеру агент должен использовать сообщение "Remote Operation Invoke | Confirmed Event Report" с типом события MDC_NOTI_CONFIG (см. IEEE 11073-20601). В поле события event-info используется структура "ConfigReport" (см. таблицу 3). У агента термометра, имеющего стандартную конфигурацию 800 с идентификатором 0x0320, формат и содержание сообщения уведомления о конфигурации выглядят следующим образом:

0xE7

0x00

APDU CHOICE Type (PrstApdu)

0x00

0x44

CHOICE.length = 68

0x00

0x42

OCTET STRING.length = 66

0xXX

0xXX

invoke-id (отличает это сообщение от любого другого известного)

0x01

0x01

CHOICE (Remote Operation Invoke | Confirmed Event Report)

0x00

0x3C

CHOICE.length = 60

0x00

0x00

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

0xXX

0xXX

0xXX

0xXX

event-time (установите значение 0xFFFFFFFF, если не поддерживается относительное время (RelativeTime)

0x0D

0x1C

event-type = MDC_NOTI_CONFIG

0x00

0x32

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

0x03

0x20

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

0x00

0x01

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

0x00

0x2C

config-obj-list.length = 44

0x00

0x06

obj-class = MDC_MOC_VMO_METRIC_NU

0x00

0x01

obj-handle = 1 (-->1-е измерение)

0x00

0x04

attributes.count = 4

0x00

0x24

attributes.length = 36

0x09

0x2F

attribute-id = MDC_ATTR_ID_TYPE

0x00

0x04

attribute-value.length = 4

0x00

0x02

0x4B

0x5C

MDC_PART_SCADA, MDC_TEMP_BODY

0x0A

0x46

attribute-id = MDC_ATTR_METRIC_SPEC_SMALL

0x00

0x02

attribute-value.length = 2

0xF0

0x40

intermittent, stored data, upd & msmt aperiodic, agent init, measured

0x09

0x96

attribute-id = MDC_ATTR_UNIT_CODE

0x00

0x02

attribute-value.length = 2

0x17

0xA0

MDC_DIM_DEGC

0x0A

0x55

attribute-id = MDC_ATTR_ATTRIBUTE_VAL_MAP

0x00

0x0C

attribute-value.length = 12

0x00

0x02

AttrValMap.count = 2

0x00

0x08

AttrValMap.length = 8

0x0A

0x4С

0x00

0x02

MDC_ATTR_NU_VAL_OBS_BASIC| value length = 2

0x09

0x90

0x00

0x08

MDC_ATTR_TIME_STAMP_ABS | value length = 8

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

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

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

0xE7

0x00

APDU CHOICE Type (PrstApdu)

0x00

0x16

CHOICE.length = 22

0x00

0x14

OCTET STRING.length = 20

0xXX

0xXX

invoke-id (отличает это сообщение от любого другого известного)

0x02

0x01

CHOICE (Remote Operation Response | Confirmed Event Report)

0x00

0x0E

CHOICE.length = 14

0x00

0x00

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

0xXX

0xXX

0xXX

0xXX

currentTime

0x0D

0x1C

event-type = MDC_NOTI_CONFIG

0x00

0x04

event-reply-info.length = 4

0x03

0x20

ConfigReportRsp.config-report-id = 1701

0x00

0x00

ConfigReportRsp.config-result = accepted-config.

Значение "0xXX" обозначает заполнитель и указывает фиксированное место переменных частей содержания сообщения.

8.5 Процедура выполнения

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

Передача данных измерений и информации о статусе агента термометра происходит в состоянии "Выполнение" (Operating). Если не указано иное, то процедура "Выполнение" агента термометра настоящего стандарта должна соответствовать требованиям IEEE 11073-20601.

8.5.2 Сервис GET получения атрибутов объекта MDS

Общие сведения о сервисе GET приведены в таблице 4.

Если менеджер оставляет поле списка attribute-id-list в сообщении службы roiv-cmip-get пустым, то агент термометра должен ответить сообщением сервиса rors-cmip-get, в котором атрибут attribute-list содержит список всех реализованных атрибутов объекта MDS.

Если менеджер запрашивает определенные атрибуты объекта MDS, указанные в поле списка attribute-id-list, и агент поддерживает эту возможность, то агент термометра должен ответить сообщением сервиса rors-cmip-get, в котором атрибут attribute-list содержит список реализованных атрибутов объекта MDS из числа запрашиваемых. Поддержка такой возможности для агента термометра не обязательна. Если эта возможность не реализована, то агент термометра должен ответить сообщением сервиса "Remote Operation Error Result" (roer) (см. IEEE 11073-20601-2014) с указанием значения ошибки no-such-action (9) в поле error-value.

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

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

Для агента термометра, соответствующего настоящему стандарту с временным хранением данных измерений, передача этих данных всегда должна инициироваться термометром (передачу данных измерений, инициированную агентом, приведена в IEEE 11073-20601). Чтобы ограничить объем данных, передаваемых в APDU, агент термометра не должен включать в один отчет о событии более 25 временно хранящихся измерений. Если для передачи доступно более 25 измерений, ожидающих отправки, то они должны быть переданы с использованием нескольких отчетов о событиях. Если доступны многократные измерения температуры, то в одном отчете о событии может быть передано до 25 измерений. Кроме того, они могут передаваться с использованием одного отчета о событиях для каждого измерения температуры. Однако для уменьшения общего объема сообщений и энергопотребления рекомендуется использовать первую стратегию.

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

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

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

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

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

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

Агент термометра в течение 30 секунд после входа в состояние "Выполнение" (Operating) должен передать одно имитированное значение температуры со значением 59,99°C (значение, никогда не встречающееся при нормальном использовании и выходящее за пределы нормального диапазона). Если реализован атрибут measurement-status числового объекта, то должен быть установлен бит test-data.

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

9.2 Поведение при расширенных конфигурациях

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

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

10.1 Применимость

Настоящий стандарт должен использоваться в сочетании с IEEE 11073-20601.

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

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

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

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

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

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

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

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

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

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

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

Данный стандарт используется в сочетании с IEEE 11073-20601. Рекомендуется формировать заявление о соответствии реализации (ICS) в первую очередь для настоящего стандарта, чтобы заявления ICS, сформированные для IEEE 11073-20601, могли затем ссылаться на заявления ICS для настоящего стандарта, где это применимо.

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

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

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

10.3.2 Уровень соответствия 1. Базовое соответствие

Приложение использует элементы информационной, сервисной и коммуникационной моделей (иерархия объектов, действия, отчеты о событиях и определения типов данных), а также номенклатурную схему, описанную в IEEE 11073-20601 и IEEE 11073-104zz. Реализованы все обязательные элементы, указанные в таблицах описания объектов и в таблицах заявления ICS. Более того, любые реализуемые условно-обязательные, рекомендуемые или необязательные элементы должны соответствовать требованиям IEEE 11073-20601 и IEEE 11073-104zz.

10.3.3 Уровень соответствия 2. Расширенная номенклатура (нотация ASN.1 и/или ISO/IEEE 11073-10101:2004)

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

Там, где это уместно, расширения информационных или сервисных моделей должны быть полностью определены с использованием нотации ASN.1 и их поведение должно быть полностью описано в соответствии с положениями IEEE 11073-20601 и/или ISO/IEEE 11073-20101. Все расширения должны быть указаны и должны включать ссылку на описание расширения, а при отсутствии общедоступной ссылки к заявлению о соответствии должно быть приложено само описание расширения.

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

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

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

Каждая таблица заявления о соответствии реализации ICS имеет следующие графы:

Индекс

Свойство

Ссылка

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

Поддержка

Комментарии

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

a) индекс: идентификатор (например, метка) конкретного элемента;

b) свойство: кратко описывает характерную особенность, о которой делается заявление о соответствии;

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

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

e) поддержка: указывает на наличие или отсутствие свойства и содержит характеристики свойства реализации. Эта графа должна быть заполнена разработчиком;

f) комментарий: содержит любую дополнительную информацию об этом свойстве. Эта графа должна быть заполнена разработчиком.

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

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

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

Общие заявления о соответствии реализации приведены в таблице 8.

Таблица 8 - Таблица общих заявлений о соответствии реализации IEEE 11073-10408

Индекс

Свойство

Ссылка

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

Поддержка

Коммен-

тарии

GEN 11073-10408-1

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

-

Идентификация прибора/приложения. Описание функциональности

GEN 11073-10408-2

Стандарты и их редакции, которым следует реализация

(Документы стандартов)

(Набор существующих редакций)

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

GEN 11073-10408-3

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

(Документы стандартов)

(Набор существующих редакций)

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

GEN 11073-10408-4

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

См. 10.3.2

Основное заявление о соответствии приборов следующим требованиям соответствия стандарту IEEE 11073-10408:

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

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

Да/Нет

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

GEN 11073-10408-5

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

См. 10.3.3

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

Да/Нет

GEN 11073-10408-6

Дерево вложенности объектов

См. 6.3

Предоставляет диаграмму вложенности объекта (Object Containment Diagram), показывающую отношения между экземплярами объектов, используемыми приложением. Реализация, соответствующая стандарту, использует только отношения объектов, определенные в DIM

GEN 11073-10408-7

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

(Документы стандартов)

(Набор существующих редакций)

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

GEN 11073-10408-8

Кодирование структур данных

-

-

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

GEN 11073-10408-9

Использование местных объектов

-

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

Да/Нет

(Если "да": поясняют в таблице 9)

GEN 11073-10408-10

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

-

Использует ли реализация местные расширения номенклатуры (т.е. коды 0xF000-0xFFFF из ISO/IEEE 11073-10101)? Местные расширения номенклатуры разрешены лишь в том случае, если стандартная номенклатура не содержит специфичные термины, требуемые приложением

Да/Нет

(Если "да": поясняют в таблице 12)

GEN 11073-10408-11

Соответствие 11073-20601

Обеспечивает отчет по соответствию, требуемый стандартом IEEE 11073-20601

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

10.4.3 Заявления о соответствии реализации класса управляемых объектов информационной модели предметной области

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

Таблица 9 - Шаблон таблицы заявления о соответствии реализации класса управляемых объектов информационной модели предметной области

Индекс

Свойство

Ссылка

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

Поддержка

Коммен-

тарии

MOC-n

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

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

Реализован

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

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

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

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

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

10.4.4 Заявление о соответствии реализации атрибутов класса управляемых объектов

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

Таблица 10 - Шаблон таблицы заявления о соответствии реализации атрибутов класса управляемых объектов

Индекс

Свойство

Ссылка

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

Поддержка

Комментарии

ATTR-n-x

Имя атрибута. Расширенные атрибуты также должны иметь идентификатор атрибута

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

M = Mandatory (обязательный)/

C = Conditional (условно обязательный)/ R = Recommended (рекомендуемый)/

O = Optional (необязательный)

(в соответствии с определением в таблицах определений атрибутов)

Реализован? Да/Нет

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

Указать ограничения (например, диапазоны значений).

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

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

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

Буква x в графе "Индекс" обозначает уникальный порядковый номер (1...m).

10.4.5 Заявление о соответствии реализации уведомлений класса управляемых объектов

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

Таблица 11 - Шаблон таблицы заявления о соответствии реализации уведомлений класса управляемых объектов

Индекс

Свойство

Ссылка

Требование/

Статус

Поддержка

Коммен-

тарии

NOTI-n-x

Имя и идентификатор уведомления

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

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

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

Буква x в графе "Индекс" обозначает уникальный порядковый номер (1...m).

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

10.4.6 Заявление о соответствии номенклатуры класса управляемых объектов

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

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

Индекс

Свойство

Ссылка

Требование/

Статус

Поддержка

Коммен-

тарии

NOME-n

Имя номенклатуры и значение номенклатуры

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

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

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

Приложение A

(справочное)

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

[B1]

IEEE 100
,
The Authoritative Dictionary of IEEE Standards Terms
, Seventh Edition. New York, Institute of Electrical and Electronic Engineers, Inc. (Словарь стандартов IEEE: глоссарий терминов и определений)
.

[B2]

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

[B3]

ISO/IEEE 11073-10201
:2004, Health informatics - Point-of-care medical device communication - Part 10201: Domain information model (Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 10201. Информационная модель предметной области).

[B4]

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

[B5]

ITU-T Rec. X.680-2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation (Информационная технология. Абстрактная синтаксическая нотация версии 1 (АСН.1). Спецификация основной нотации)
.

________________

Публикации IEEE можно получить в Институте инженеров электротехники и радиоэлектроники, 445 Hoes Lane, Piscataway, NJ 08854-4141, USA (
http://standards.ieee.org/
).
Обозначения стандартов или документов IEEE, упомянутые в этом пункте, являются товарными знаками Института инженеров электротехники и радиоэлектроники (Institute of Electrical and Electronics Engineers, Inc.)
Публикации ISO/IEEE можно получить в Центральном секретариате ИСО, Case Postale 56, 1 rue de
, CH-1211,
20, Швейцария/Suisse (
http://www.iso.ch/
). Публикации ISO/IEEE можно также получить в Соединенных Штатах Америки в Институте электротехники и инженеров-электроников, 445 Hoes Lane, Piscataway, NJ 08854, USA (
http://standards.ieee.org/
).
Публикации ITU можно получить в Международном союзе электросвязи, Place des Nations, 1211 Geneva 20, Switzerland. (
http://www.itu.in/
).

Приложение B

(обязательное)

Дополнительные определения в нотации ASN.1

В настоящем стандарте дополнительные определения в нотации ASN.1 не определены.

Приложение C

(обязательное)

Присвоение идентификаторов

В данном приложении приведены номенклатурные коды, используемые в настоящем стандарте и отсутствующие в IEEE 11073-20601. Нормативные определения, отсутствующие в данном приложении, приведены в IEEE 11073-20601-2014.

Использованный ниже формат соответствует формату ISO/IEEE 11073-10101.

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

***

* Медицинское диспетчерское управление и сбор данных (MDC_PART_SCADA)

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

***

/* Копия номенклатурных кодов, определенных в ISO/IEEE 11073-10101.

*/

#define MDC_TEMP_TYMP

19320

/* TEMPtypm

*/

#define MDC_TEMP_RECT

57348

/* KKT

*/

#define MDC_TEMP_ORAL

57352

/* T

*/

#define MDC_TEMP_EAR

57356

/* T

*/

#define MDC_TEMP_FINGER

57360

/* T

*/

#define MDC_TEMP_TOE

57376

/*

*/

/* Новые номенклатурные коды, представленные в настоящем стандарте. */

/#define MDC_TEMP_AXILLA

57380

/*

*/

#define MDC_TEMP_GIT

57384

/*

*/

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

***

* Размерности (единицы измерения) (MDC_PART_DIM)

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

***/

#define MDC_DIM_FAHR

4416

/* °F

*/

Приложение D

(справочное)

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

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

a) Когда пользователь подключает термометр, менеджер не распознает конфигурацию агента и отправляет ему ответ на запрос ассоциации с результатом accepted-unknown-config. Соответствующие примеры PDU приведены в E.2.2.2 и E.2.2.3.

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

c) Затем менеджер запрашивает атрибуты объекта MDS агента, отправляя сообщение, содержащее команду "Remote Operation Invoke | Get". В ответ агент передает менеджеру свои атрибуты объекта MDS, используя сообщение, содержащее команду "Remote Operation Response | Get". Соответствующие примеры PDU приведены в E.4.2 и E.4.3.

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

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

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

g) Наконец, два последних показанных шага аналогичны действиям, описанным в перечислениях d) и e). Пользователь выполняет одно подтверждаемое измерение, за которым следует завершение ассоциации.

Рисунок D.1 - Диаграмма последовательности для примера использования термометра

Приложение E

(справочное)

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

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

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

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

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

Когда установлено транспортное соединение между менеджером и агентом, то они оба переходят в состояние "Не ассоциирован (Unassociated). Когда агент передает запрос ассоциации, то менеджер и агент переходят в состояние "Ассоциирующий" (Associating).

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

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

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

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

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

0xE2

0x00

APDU CHOICE Type (AarqApdu)

0x00

0x32

CHOICE.length = 50

0x80

0x00

0x00

0x00

assoc-version

0x00

0x01

0x00

0x2A

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

0x50

0x79

data-proto-id = 20601

0x00

0x26

data-proto-info length = 38

0x80

0x00

0x00

0x00

protocolVersion

0xА0

0x00

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

0x80

0x00

0x00

0x00

nomenclatureVersion

0x00

0x00

0x00

0x00

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

0x00

0x80

0x00

0x00

systemType = sys-type-agent

0x00

0x08

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

0x40

0x00

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

0x00

0x01

data-req-mode-flags

0x01

0x00

data-req-init-agent-count, data-req-init-manager-count

0x00

0x00

0x00

0x00

optionList.count = 0 | optionList.length = 0

E.2.2.3 Ответ на запрос ассоциации

Менеджер отвечает агенту, что он может установить ассоциацию, но не имеет расширенной конфигурации термометра (т.е. агент должен послать свою конфигурацию).

0xE3

0x00

APDU CHOICE Type (AareApdu)

0x00

0x2C

CHOICE.length = 44

0x00

0x03

result = accepted-unknown-config

0x50

0x79

data-proto-id = 20601

0x00

0x26

data-proto-info length = 38

0x80

0x00

0x00

0x00

protocolVersion

0x80

0x00

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

0x80

0x00

0x00

0x00

nomenclatureVersion

0x00

0x00

0x00

0x00

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

0x80

0x00

0x00

0x00

systemType = sys-type-manager

0x00

0x08

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

0x38

0x37

0x36

0x35

0x34

0x33

0x32

0x31

0x00

0x00

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

0x00

0x00

Ответ менеджера на data-req-mode-flags всегда 0

0x00

0x00

data-req-init-agent-count и data-req-init-manager-count всегда 0

0x00

0x00

0x00

0x00

optionList.count = 0 | optionList.length = 0

E.2.3 Ранее известная расширенная конфигурация

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

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

E.2.3.2 Запрос ассоциации

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

Это точно такое же сообщение, как и в E.2.2.2; коды приведены там.

E.2.3.3 Ответ на запрос ассоциации

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

0xE3

0x00

APDU CHOICE Type (AareApdu)

0x00

0x2C

CHOICE.length = 44

0x00

0x00

result = accepted

0x50

0x79

data-proto-id = 20601

0x00

0x26

data-proto-info length = 38

0x80

0x00

0x00

0x00

protocolVersion

0x80

0x00

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

0x80

0x00

0x00

0x00

nomenclatureVersion

0x00

0x00

0x00

0x00

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

0x80

0x00

0x00

0x00

systemType = sys-type-manager

0x00

0x08

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

0x38

0x37

0x36

0x35

0x34

0x33

0x32

0x31

0x00

0x00

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

0x00

0x00

Ответ менеджера на data-req-mode-flags всегда 0

0x00

0x00

data-req-init-agent-count и data-req-init-manager-count всегда 0

0x00

0x00

0x00

0x00

optionList.count = 0 | optionList.length = 0

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

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

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

E.2.4.2 Запрос ассоциации

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

0xE2

0x00

APDU CHOICE Type (AarqApdu)

0x00

0x32

CHOICE.length = 50

0x80

0x00

0x00

0x00

assoc-version

0x00

0x01

0x00

0x2A

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

0x50

0x79

data-proto-id = 20601

0x00

0x26

data-proto-info length = 38

0x80

0x00

0x00

0x00

protocolVersion

0xA0

0x00

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

0x80

0x00

0x00

0x00

nomenclatureVersion

0x00

0x00

0x00

0x00

functionalUnits

0x00

0x80

0x00

0x00

systemType = sys-type-agent

0x00

0x08

system-id length

0x31

0x32

0x33

0x34

0x35

0x36

0x37

0x38

System ID

0x03

0x20

dev-config-id: 800 - стандартная конфигурация

0x00

0x01

data-req-mode-flags

0x01

0x00

data-req-init-agent-count, data-req-manager-count

0x00

0x00

0x00

0x00

optionList.count = 0 | optionList.length = 0

E.2.4.3 Ответ на запрос ассоциации

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

0xE3

0x00

APDU CHOICE Type (AareApdu)

0x00

0x2C

CHOICE.length = 44

0x00

0x00

Result = accepted

0x50

0x79

data-proto-id = 20601

0x00

0x26

data-proto-info length = 38

0x80

0x00

0x00

0x00

protocolVersion

0x80

0x00

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

0x80

0x00

0x00

0x00

nomenclatureVersion

0x00

0x00

0x00

0x00

functionalUnits

0x80

0x00

0x00

0x00

systemType = sys-type-manager

0x00

0x08

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

0x38

0x37

0x36

0x35

0x34

0x33

0x32

0x31

System ID

0x00

0x00

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

0x00

0x00

Ответ менеджера на data-req-mode-flags всегда 0

0x00

0x00

data-req-init-agent-count и data-req-init-manager-count всегда 0

0x00

0x00

0x00

0x00

optionList.count = 0 | optionList.length = 0

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

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

Если ассоциация не отклонена или не прекращена, то агент и менеджер переходят из состояния "Ассоциирующий" (Associating) в одно из двух состояний. Если менеджер возвращает код результата ассоциирования "accepted", то агент и менеджер переходят в состояние "Выполнение" (Operating). Если менеджер возвращает код результата ассоциирования "accepted-unknown-config", то агент и менеджер переходят в состояние "Конфигурирующий" (Configuring).

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

E.3.2.1 Общие положения

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

E.3.2.2 Удаленный вызов операции события отчета о конфигурации

Агент термометра передает описание своей расширенной конфигурации. Он делает это с помощью передачи подтверждаемого отчета о событии типа MDC_NOTI_CONFIG.

0xE7

0x00

APDU CHOICE Type (PrstApdu)

0x00

0x44

CHOICE.length = 68

0x00

0x42

OCTET STRING.length = 70

0x00

0x03

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

0x01

0x01

CHOICE(Remote Operation Invoke | Confirmed Event Report)

0x01

0x3C

CHOICE.length = 60

0x00

0x00

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

0xFF

0xFF

0xFF

0xFF

event-time = 0xFFFFFFFF

0x0D

0x1C

event-type = MDC_NOTI_CONFIG

0x00

0x32

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

0x40

0x00

config-report-id 16384

0x00

0x01

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

0x00

0x2C

config-obj-list.length = 44

0x00

0x06

obj-class = MDC_MOC_VMO_METRIC_NU

0x00

0x01

obj-handle = 1 (--> 1-е измерение - уровень глюкозы в крови)

0x00

0x04

attributes.count = 4

0x00

0x24

attributes.length = 36

0x09

0x2F

attribute-id = MDC_ATTR_ID_TYPE

0x00

0x04

attribute-value.length = 4

0x00

0x02

0x4B

0x5C

MDC_PART_SCADA, MDC_TEMP_BODY

0x0A

0x46

attribute-id = MDC_ATTR_METRIC_SPEC_SMALL

0x00

0x02

attribute-value.length = 2

0xF0

0x40

0x09

0x96

attribute-id = MDC_ATTR_UNIT_CODE

0x00

0x02

attribute-value.length = 2

0x17

0xA0

MDC_DIM_DEGC

0x0A

0x55

attribute-id = MDC_ATTR_ATTRIBUTE_VAL_MAP

0x00

0x0C

attribute-value.length = 16

0x00

0x02

AttrValMap.count = 2

0x00

0x08

AttrValMap.length = 8

0x09

0x4С

0x00

0x02

MDC_ATTR_NU_VAL_OBS_SIMP, 4

0x09

0x90

0x00

0x08

MDC_ATTR_TIME_STAMP_ABS, 8

E.3.2.3 Ответ на удаленный вызов операции отчета о событии конфигурации

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

0xE7

0x00

APDU CHOICE Type (PrstApdu)

0x00

0x16

CHOICE.length = 22

0x00

0x14

OCTET STRING.length = 20

0x00

0x03

invoke-id = 0x1235 (повторяется зеркально из вызова)

0x02

0x01

CHOICE (Remote Operation Response | Confirmed Event Report)

0x00

0x0Е

CHOICE.length = 14

0x00

0x00

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

0x00

0x00

0х00

0х00

currentTime = 0

0x0D

0x1C

event-type = MDC_NOTI_CONFIG

0x00

0x04

event-reply-info.length = 4

0x40

0x00

ConfigReportRsp.config-report-id = 0x4000

0x00

0x00

ConfigReportRsp.config-result = accepted-config

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

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

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

E.3.3.2 Удаленный вызов операции события отчета о конфигурации

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

E.3.3.3 Ответ на удаленный вызов операции события отчета о конфигурации

Состояние "Конфигурирующий" (Configuring) было пропущено. Агентом не сформирован отчет о событии, поэтому менеджер не генерирует никакого ответа.

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

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

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

E.3.4.2 Удаленный вызов операции события отчета о конфигурации

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

E.3.4.3 Ответ на удаленный вызов операции события отчета о конфигурации

Состояние "Конфигурирующий" (Configuring) было пропущено. Агентом не сформирован отчет о событии, поэтому менеджер не генерирует никакого ответа.

E.4 Сервис GET для получения атрибутов системы медицинского прибора (MDS)

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

Сервис GET для получения атрибутов MDS вызывается в любое время, когда агент находится в состоянии "Ассоциирован" (Associated).

E.4.2 Запрос сервиса GET на получение всех атрибутов MDS

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

0xE7

0x00

APDU CHOICE Type (PrstApdu)

0x00

0x0Е

CHOICE.length = 14

0x00

0x0С

OCTET STRING.length = 12

0x00

0x05

invoke-id = 5 (отличает это сообщение от любого другого известного, выбор специфичен для конкретной реализации)

0х01

0х03

CHOICE (Remote Operation Invoke | Get)

0х00

0х06

CHOICE.length = 6

0х00

0х00

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

0х00

0х00

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

0х00

0х00

attribute-id-list.length = 0

E.4.3 Ответ на запрос сервиса GET всех атрибутов MDS

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

0xE7

0x00

APDU CHOICE Type (PrstApdu)

0x00

0x58

CHOICE.length = 88

0x00

0x56

OCTET STRING.length = 86

0x00

0x05

invoke-id = 5 (повторяется зеркально из вызова)

0х02

0х03

CHOICE (Remote Operation Response | Get)

0х00

0х50

CHOICE.length = 80

0х00

0х00

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

0х00

0х05

attribute-id-list.count = 5

0х00

0х60

attribute-list.length = 96

0х00

0х4A

attribute id = MDC_ATTR_SYS_TYPE_SPEC_LIST

0х00

0х08

attribute-value.length = 8

0х00

0х01

TypeVerList count = 1

0х00

0х04

TypeVerList length = 4

0х10

0х08

type = MDC_DEV_SPEC_PROFILE_TEMP

0x00

0x01

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

0x09

0x28

attribute-id = MDC_ATTR_ID_MODEL

0x00

0x1A

attribute-value.length = 26

0x00

0x0A

0x54

0x68

string length = 10 | "TheCompany"

0x65

0x43

0x6F

0x6D

0x70

0x61

0x6E

0x79

0x00

0x0C

0x54

0x68

string length = 12 | "Termometer\0"

0x65

0x72

0x6D

0x6F

0x6D

0x65

0x74

0x65

0x72 0x00

0x09

0x84

attribute-id = MDC_ATTR_SYS_ID

0x00

0x0A

attribute-value.length = 10

0x00

0x08

0x31

0x32

0x33 0x34

0x35

0x36

0x37

0x38

octet string length = 8 | EUI-64

0x0A

0x44

attribute-id = MDC_ATTR_DEV_CONFIG_ID

0x00

0x02

attribute-value.length = 2

0x40

0x00

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

0x09

0x87

attribute-id =MDC_ATTR_TIME_ABS

0x00

0x08

attribute-value.length = 8

0x20

0x08

0x05

0x06

Absolute-Time-Stamp = 2008-05-06T08:00:0000

0x08

0x00

0x00

0x00

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

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

0x00

0x2A

CHOICE.length = 42

0x00

0x28

OCTET STRING.length = 40

0x00

0x08

invoke-id = 8

0x01

0x01

CHOICE (Remote Operation Invoke | Confirmed Event Report)

0x00

0x22

CHOICE.length = 34

0x00

0x00

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

0xFF

0xFF

0xFF

0xFF

event-time = 0

0x0D

0x1D

event-type = MDC_NOTI_SCAN_REPORT_FIXED

0x00

0x18

event-info.length = 24

0xF0

0x00

ScanReportInfoFixed.data-req-id = 0xF000

0x00

0x00

ScanReportInfoFixed.scan-report-no = 0

0x00

0x01

ScanReportInfoFixed.obs-scan-fixed.count = 1

0x00

0x10

ScanReportInfoFixed.obs-scan-fixed.length = 16

0x00

0x01

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

0x00

0x0C

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

0xFB

0x38

0x75

0x20

Simple-Nu-Observed-Value = 37.0 (Degrees C)

0x20

0x08

0x05

0x06

Absolute-Time-Stamp = 2008-05-06T08:30:0000

0x08

0x30

0x00

0x00

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

0xE7

0x00

APDU CHOICE Type (PrstApdu)

0x00

0x2A

CHOICE.length = 42

0x00

0x28

OCTET STRING.length = 40

0x00

0x08

invoke-id = 8

0х01

0х01

CHOICE (Remote Operation Invoke | Confirmed Event Report)

0х00

0х22

CHOICE.length = 34

0х00

0х00

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

0xFF

0xFF

0xFF

0xFF

event-time = 0

0x0D

0x1D

event-type = MDC_NOTI_SCAN_REPORT_FIXED

0x00

0x18

event-info.length = 24

0xF0

0x00

ScanReportInfoFixed.data-req-id = 0xF000

0x00

0x00

ScanReportInfoFixed.scan-report-no = 0

0x00

0x01

ScanReportInfoFixed.obs-scan-fixed.count = 1

0x00

0x10

ScanReportInfoFixed.obs-scan-fixed.length = 16

0x00

0x01

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

0x00

0x0C

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

0xFB

0x38

0x75

0x20

Simple-Nu-Observed-Value = 37.0 (Degrees C)

0x20

0x08

0x05

0x06

Absolute-Time-Stamp = 2008-05-06T08:30:0000

0x08

0x30

0x00

0x00

E.5.2 Ответ на подтверждаемую передачу данных измерений

Менеджер подтверждает получение от агента отчета о событии.

0xE7

0x00

APDU CHOICE Type (PrstApdu)

0x00

0x12

CHOICE.length = 18

0x00

0x10

OCTET STRING.length = 16

0x00

0x04

invoke-id = 4 (повторяется зеркально из вызова)

0х02

0х01

CHOICE (Remote Operation Response | Confirmed Event Report)

0х00

0х0А

CHOICE.length = 10

0х00

0х00

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

0х00

0х00

0х00

0х00

currentTime = 0

0x0D

0x1D

event-type = MDC_NOTI_SCAN_REPORT_FIXED

0x00

0x00

event-reply-info.length = 0

E.6 Завершение ассоциации

E.6.1 Запрос завершения ассоциации

Агент термометра отправляет менеджеру следующее сообщение:

0xE4

0x00

APDU CHOICE Type (RlrqApdu)

0x00

0x02

CHOICE.length = 2

0x00

0x00

reason = нормальное завершение

E.6.2 Ответ на запрос завершения ассоциации

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

0xE5

0x00

APDU CHOICE Type (RlreApdu)

0x00

0x02

CHOICE.length = 2

0x00

0x00

reason = нормальное завершение

Приложение ДА

(справочное)

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

Таблица ДА

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

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

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

IEEE 11073-20601-2008

IDT

ГОСТ Р 56845-2019/ISO/IEEE 11073-20601:2016 "Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 20601. Прикладной профиль. Оптимизированный протокол обмена"

Примечание - В настоящей таблице использовано следующее условное обозначение степени соответствия стандарта:

- IDT - идентичный стандарт.

УДК 61:004:006.354

ОКС 35.240.80

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