ГОСТ Р 57847-2017/ISO/IEEE 11073-10421:2012. Национальный стандарт Российской Федерации. Информатизация здоровья. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 10421. Специализация прибора. Пневмотахометр

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

Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 27 октября 2017 г. № 1533-ст

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

ИНФОРМАТИЗАЦИЯ ЗДОРОВЬЯ

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

(ISO/IEEE 11073-10421:2012, IDT)

ГОСТ Р 57847-2017/ISO/IEEE 11073-10421:2012

ОКС 35.240.80

ОКПД2 32.50

Предисловие

Введение

• часть 10404: Связь с медицинскими приборами индивидуального контроля состояния здоровья. Специализация прибора. Пульсовой оксиметр;
• часть 10407: Связь с медицинскими приборами индивидуального контроля состояния здоровья. Специализация прибора. Монитор контроля кровяного давления;
• часть 10408: Связь с медицинскими приборами индивидуального контроля состояния здоровья. Специализация прибора. Термометр;

• часть 10421: Связь с медицинскими приборами индивидуального контроля состояния здоровья. Специализация прибора. Пневмотахометр;
• часть 10471: Связь с медицинскими приборами индивидуального контроля состояния здоровья. Специализация прибора. Независимый центр контроля жизнедеятельности;

• часть 30200: Связь с медицинскими приборами на месте лечения. Транспортный профиль. Кабельное соединение;
• часть 30300: Связь с медицинскими приборами на месте лечения. Транспортный профиль. Инфракрасный канал связи;

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

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

1 Обзор

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

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

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

1.2 Цель

1.3 Контекст

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

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

Настоящий стандарт базируется на IEEE 11073-20601-2008, в котором, в свою очередь, использована информация из ISO/IEEE 11073-10201:2004 [2] и ISO/IEEE 11073-20101:2004 [3]. Правила кодирования медицинских приборов, использованные в настоящем стандарте, полностью определены в IEEE 11073-20601-2008.

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

Примечание - В настоящем стандарте обозначение ISO/IEEE 11073-104xx использовано для ссылок на группу стандартов по специализации приборов, в которых использован IEEE 11073-20601-2008, где xx может быть любым числом от 01 до 99 включительно <*>.

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

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

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

IEEE Std 11073-20601-2008, Health informatics — Personal health device communication — Application profile — Optimized exchange protocol (Информатизация здоровья. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Прикладной профиль. Оптимизированный протокол обмена)

Примечания

1 В последующем тексте ссылки на данный стандарт приведены без указания года издания.

2 Все остальные источники, на которые имеются ссылки в настоящем стандарте, приведены в приложении A.

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

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

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

3.1.3 вычислительное устройство (compute engine): См. управляющее устройство.

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

3.1.5 объем форсированного выдоха (forced expiratory volume): Объем выдыхаемого воздуха человеком при форсированных условиях за время t в секундах с начала отсчета времени.

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

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

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

3.1.9 объект (object): В объектно-ориентированном моделировании — конкретная реализация класса. Реализованный объект наследует от класса атрибуты, методы и события.

3.1.10 максимальный экспираторный поток (peak expiratory flow): Максимальный поток, измеренный у рта во время выдоха, произведенного с максимальным усилием, начиная сразу после достижения максимального наполнения легких.

3.1.11 пневмотахометр (peak expiratory flow monitor): Медицинский прибор, предназначенный для измерения респираторной функции при таких респираторных заболеваниях, как астма.

3.1.12 личный рекорд (personal best): Данное значение определяется врачом либо на основании расчетного среднего значения максимального потока. Обычно данное значение равно максимальной амплитуде экспираторного потока, которую может создать человек, находясь в наилучшем состоянии.

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

3.1.14 телемедицинский прибор индивидуального контроля состояния здоровья (personal telehealth device): См. прибор индивидуального контроля состояния здоровья.

3.1.15 расчетное среднее значение максимального потока (predicted average peak flow): Значение максимального экспираторного потока, вычисленное на основе возраста, веса и пола пациента и предназначенное для использования в качестве критерия для измерений пациента.

3.1.16 начало отсчета времени (time zero): В настоящем стандарте за начало отсчета времени принимается момент времени, когда пациент начинает дуть в пневмотахометр, чтобы произвести измерение.

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)];

FEV — объем форсированного выдоха (forced expiratory volume);

FEV1 — объем форсированного выдоха за 1 с (forced expiratory volume in 1 s);

FEV6 — объем форсированного выдоха за 6 с (forced expiratory volume in 6 s);

ICS — заявление о соответствии реализации (implementation conformance statements);

MDC — взаимосвязь медицинских приборов (medical device communication);

MDER — правила кодирования медицинских приборов (medical device encoding rules);

MDS — система медицинских приборов (medical device system);

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

OID — идентифицированный объект (object identified);

PDU — модуль данных протокола (protocol data unit);

PEF — максимальный экспираторный поток (peak expiratory flow);

PHD — прибор индивидуального контроля состояния здоровья (personal health device);

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

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

4 Введение в стандарты комплекса ISO/IEEE 11073, посвященные приборам индивидуального контроля состояния здоровья

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

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

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

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

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

В основу стандартов комплекса ISO/IEEE 11073, и в частности IEEE 11073-20601, положена парадигма управления объектно-ориентированными системами. Общая модель системы состоит из трех основных составляющих: информационной модели предметной области (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. Надежность данной взаимосвязи определяется, но не ограничивается физической надежностью прибора наряду с встроенной надежностью транспортного уровня, лежащего в основе данной взаимосвязи. Дополнительные средства обеспечения безопасности могут быть определены в будущих редакциях IEEE 11073-20601.

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

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

5 Понятия и методы, используемые в пневмотахометрах

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

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

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

5.2 PEF

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

Рисунок 1 — Форма графика PEF (график представлен только в качестве иллюстрации, а не реальных данных)

5.3 Личный рекорд

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

5.4 FEV1

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

Рисунок 2 — Вид графика FEV1 (график представлен только в качестве иллюстрации, а не реальных данных)

5.5 FEV6

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

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

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

В данном разделе представлена информационная модель предметной области пневмотахометра.

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

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

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

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

Рисунок 3 — Пневмотахометр: информационная модель предметной области

Объекты модели DIM, представленной на рисунке 3, определены в 6.5 - 6.10: объект система медицинских приборов (MDS) определен в 6.5, числовые объекты — в 6.6, объекты массива образцов реального времени — в 6.7, объекты перечислений — в 6.8, объекты хранилища PM — в 6.9 и объекты сканера — в 6.10. В 6.11 определены правила расширения информационной модели пневмотахометра за пределы, ограниченные объектами, определенными в настоящем стандарте. В подразделах, в которых определены объекты информационной модели пневмотахометра, представлена следующая информация:

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

Атрибуты для каждого класса определены в таблицах, в которых указаны наименование атрибута, его значение и его квалификатор. Квалификаторами атрибута могут быть: M — атрибут является обязательным; C — атрибут является условным, зависящим от условия, указанного в графе «Примечание» или «Значение» (если дана ссылка на IEEE 11073-20601, то условия определены в данном стандарте); R — атрибут является рекомендуемым; NR — атрибут является нерекомендуемым; O — атрибут является факультативным. Условные атрибуты должны быть применены в том случае, если условие выполняется, и могут быть применены в противном случае. Рекомендованные атрибуты должны быть применены агентом. Нерекомендуемые атрибуты не должны быть применены агентом. Факультативные атрибуты могут быть применены агентом.

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

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

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

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

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

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

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

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

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

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

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

Таблица 1

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

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

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

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

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

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

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

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

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

Таблица 2

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

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

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

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

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

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

Таблица 3

События объекта MDS пневмотахометра

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

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

MDS-Dynamic-Data-Update-Fixed: Данное событие предоставляет динамические данные измерений от агента-пневмотахометра для числовых объектов PEF, FEV1 и факультативно для FEV6. Эти данные предоставляются с использованием фиксированного формата, заданного атрибутом Attribute-Value-Map объекта. Данное событие посылается агентом как незатребованное сообщение (то есть как инициированная агентом передача данных измерения). Более подробная информация о незатребованной передаче события приведена в 8.5.3.

Примечание - IEEE 11073-20601 требует, чтобы управляющие устройства поддерживали все перечисленные выше события объекта MDS.

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

6.5.4.1 Сервис GET

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

Запрос GET должен поддерживаться для всех атрибутов. Параметр attribute-id-list может поддерживаться.

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

Таблица 4

Сервис GET объекта MDS пневмотахометра

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

6.5.4.2 Сервис SET

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

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

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

В составе модели DIM пневмотахометра (рисунок 3) содержатся три числовых объекта для PEF, личного рекорда и FEV1. Кроме того, в состав DIM дополнительно может входить четвертый простой числовой объект для FEV6. Данные числовые объекты определены в 6.6.2 - 6.6.5.

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

6.6.2 PEF

В таблице 5 представлены атрибуты простого числового объекта, который представляет PEF. Номенклатурным кодом для идентификации числового класса является MDC_MOC_VMO_METRIC_NU. Числовой объект PEF должен поддерживаться агентом-пневмотахометром.

Таблица 5

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

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

У агента-пневмотахометра со стандартной конфигурацией структура AttrValMap (см. IEEE 11073-20601) атрибута Attribute-Value-Map должна содержать идентификатор (ID) атрибута и информацию о длине атрибута для Simple-Nu-Observed-Value и Absolute-Time-Stamp в том же порядке, который указан в таблице 5 для значения атрибута Attribute-Value-Map.

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

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

6.6.3 Личный рекорд

В таблице 6 представлены атрибуты простого числового объекта Personal Best, который представляет личный рекорд. Номенклатурным кодом для идентификации числового класса является MDC_MOC_VMO_METRIC_NU. Числовой объект личного рекорда должен поддерживаться агентом-пневмотахометром.

Таблица 6

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

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

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

6.6.4 FEV1

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

Таблица 7

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

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

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

6.6.5 FEV6 (дополнительный)

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

Таблица 8

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

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

У агента-пневмотахометра со стандартной конфигурацией структура AttrValMap (см. IEEE 11073-20601) атрибута Attribute-Value-Map должна содержать идентификатор (ID) атрибута и информацию о длине атрибута для Simple-Nu-Observed-Value и Absolute-Time-Stamp в том же порядке, который указан в таблице 8.

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

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

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

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

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

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

6.8.1 Состояние считывания

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

Задания значений разрядов и (OID)-Type данного объекта должны быть реализованы так, как это определено в данном пункте. Номенклатурным кодом обозначения класса объекта перечисления является MDV_MOC_VMO_METRIC_ENUM. В таблице 9 представлены атрибуты данного объекта.

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

Таблица 9

Атрибуты объекта перечисления для состояния считывания

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

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

Таблица 10

Отображение состояния считывания на атрибут Bit-Str объекта

Примечание — Конкретные значения разрядов объекта PEFReadStat определены в приложении B.

6.9 Объекты PM-store

Для целей настоящего стандарта объекты PM-store не требуются.

6.10 Объекты Scanner

Для целей настоящего стандарта объекты Scanner не требуются.

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

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

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

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

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

7 Модель сервисов пневмотахометра

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

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

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

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

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

• сервис GET используется управляющим устройством для получения от агента значений атрибутов объектов MDS. Список атрибутов объектов MDS пневмотахометра представлен в 6.5.4.1;

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

Таблица 11

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

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

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

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

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

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

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

8 Модель взаимосвязей пневмотахометра

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

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

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

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

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

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

Для агента, реализующего помимо пневмотахометра функции специализаций других приборов, верхняя граница размеров APDU устанавливается следующим образом: агент не должен передавать APDU размером больше суммы Ntx всех реализованных специализаций приборов и должен быть способен принимать APDU размером не более суммы Nrx всех реализованных специализаций приборов. Если данные суммы оказываются больше максимального размера, установленного в ИИЭР 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 (то есть protocol-version = 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.

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

8.3.3 Процедура для управляющего устройства — ответ на установление связи

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

Поле result должно иметь значение, установленное в IEEE 11073-20601. Например, если выполняются все другие условия протокола взаимодействия, то управляющее устройство возвращает значение accepted, если оно распознает поле dev-config-id в запросе агента, или возвращает значение 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-agent (то есть system-type = 0x00800000).

6. Поле system-id должно содержать уникальный идентификатор системы, соответствующий прибору, выполняющему функции управляющего устройства. Данный идентификатор должен принадлежать к допустимому типу EUI-64.

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

8. Поле data-req-mode-capab должно содержать значение 0.

9. Поле data-req-init-agent-count должно содержать значение 1, а поле req-init-manager-count должно содержать значение 0.

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

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

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

8.4.2 Пневмотахометр — стандартная конфигурация

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

Агент выполняет процедуру конфигурирования, используя сообщение «Remote Operation Invoke | Confirmed Event Report» с событием MDC_NOTI_CONFIG для того, чтобы передать свою конфигурацию управляющему устройству (см. IEEE 11073-20601). Для поля event-info используется структурный элемент ConfigReport (см. таблицу 3). Для агента-пневмотахометра со стандартной конфигурацией ID 2100 (0x834) формат и содержимое сообщения, содержащего уведомление о конфигурации, имеют следующий вид:

8.4.2.2 Процедура со стороны управляющего устройства

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

8.5 Рабочая процедура

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

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

8.5.2 Получение атрибутов объекта 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, которые были реализованы. Агент-пневмотахометр не обязательно должен поддерживать данную возможность. Если данная возможность не поддерживается, то агент-пневмотахометр должен ответить так, как это определено в разделе IEEE 11073-20601, посвященном атрибутам объекта MDS.

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

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

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

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

8.6 Временная синхронизация

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

9 Тестовые взаимосвязи

Тестовая взаимосвязь дает возможность изготовителю протестировать или продемонстрировать возможности изделия в полной мере. В данном разделе определено поведение стандартного агента-пневмотахометра во время тестовой взаимосвязи. Поддержка тестовой взаимосвязи не является обязательной.

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

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

Агент-пневмотахометр должен посылать единственное смоделированное значение PEF, равное 600 л/мин, и единственное смоделированное значение FEV1, равное 10 л (значения, никогда не встречающиеся при обычном применении и выходящие за границы нормального диапазона), в пределах 30 с после перехода в рабочее состояние. Если используется атрибут measurement-status числового объекта, то должен быть установлен признак test-data.

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

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

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

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

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

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

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

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

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

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

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

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

Спецификации должны быть оформлены в виде набора заявлений о соответствии реализации (ICS) согласно 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)

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

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

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

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

ICS должны быть представлены как документ в виде заявления о полном соответствии, содержащем совокупность таблиц в форматах, заданных шаблонами, представленными в 10.4.2 - 10.4.6.

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

• Индекс;
• Характеристика;
• Ссылка:
• Треб./Статус;
• Поддержка;
• Примечание.

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

Индекс: идентификатор (например, тег) конкретной характеристики.

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

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

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

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

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

В 10.4.2 - 10.4.6 определены форматы конкретных таблиц ICS.

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

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

Таблица 12

Общие ICS по 11073-10421

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

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

Таблица 13

Шаблон для таблицы DIM MOC ICS

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

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

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

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

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

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

Таблица 14

Шаблон для таблицы ICS атрибутов MOC

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

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

Символ x в графе «Индекс» представляет уникальное последовательное число (1...m).

10.4.5 Заявление о соответствии реализации уведомлений MOC

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

Таблица 15

Шаблон для таблицы ICS уведомлений MOC

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

Символ x в графе «Индекс» представляет уникальное последовательное число (1...m).

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

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

ICS номенклатуры MOC определяет все нестандартные номенклатурные коды, используемые агентом. Таблица 16 представляет шаблон для использования. Каждому элементу номенклатуры должна соответствовать одна строка таблицы.

Таблица 16

Шаблон для таблицы ICS номенклатуры MOC

Символ n в графе «Индекс» представляет уникальное последовательное число (1...m).

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

БИБЛИОГРАФИЯ

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

ДОПОЛНИТЕЛЬНЫЕ ОПРЕДЕЛЕНИЯ ИЗ ASN.1

Отображение разряда состояния чтения.

(Разрядам присваивается значение 1 при наступлении соответствующего им события.)

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

НАЗНАЧЕНИЕ ИДЕНТИФИКАТОРОВ

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

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

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

ПРИМЕРЫ ПОСЛЕДОВАТЕЛЬНОСТИ СООБЩЕНИЙ

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

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

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

c) Далее управляющее устройство может запросить у агента атрибуты объекта MDS, посылая сообщение с данными вместе с командой «Remote Operation Invoke | Get». Следует отметить, что управляющее устройство может запросить атрибуты объекта MDS, как только агент перейдет в состояние взаимосвязи (Associated state), включая субсостояния конфигурирования (Configuring substate) и работы (Operating substate). В ответ агент сообщает управляющему устройству атрибуты объекта MDS, используя сообщение с данными вместе с командой «Remote Operation Response | Get». Соответствующие примеры PDU приведены в E.4.1.2 и E.4.1.3.

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

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

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

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

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

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

ПРИМЕРЫ БЛОКОВ ДАННЫХ ПРОТОКОЛА ОБМЕНА

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

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

E.2 Обмен информацией для установления взаимосвязи

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

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

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

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

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

E.2.2.2 Запрос на установление взаимосвязи

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

E.2.2.3 Ответ на установление связи

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

E.2.3.3 Ответ на установление взаимосвязи

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

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

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

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

E.2.4.2 Запрос на установление взаимосвязи

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

E.2.4.3 Ответ на установление взаимосвязи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

E.4 Получение значений атрибутов MDS (сервис GET MDS attributes)

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

Сервис GET MDS attributes может быть активизирован в любое время, когда агент находится в состоянии взаимосвязи (Associated state).

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

Управляющее устройство запрашивает у агента атрибуты его объектов MDS.

E.4.3 Получение ответа со всеми атрибутами MDS

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

E.5 Передача данных

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

Агент посылает показания управляющему устройству, используя подтвержденный фиксированный формат отчетов о событиях. Ниже приведены два примера. В первом примере показания PEF и FEV1 передаются вместе с личным рекордом (Personal Best) и состоянием считывания (Reading Status). Во втором примере передаются только показания FEV6.

Второе дополнительное изменение для FEV6.

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

Управляющее устройство подтверждает получение от агента отчета о событии. Ниже приведены два ответа управляющего устройства, соответствующие двум примерам из E.5.1.

Ответ для PEF, PB, FEV1 и состояния считывания: