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

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

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

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

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

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

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

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

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

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

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

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

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

- часть 10101: Связь с медицинскими приборами на месте лечения. Номенклатура;

- часть 10201: Связь с медицинскими приборами на месте лечения. Информационная модель предметной области;

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

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

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

- часть 10415: Связь с медицинскими приборами индивидуального контроля состояния здоровья. Специализация прибора. Весы;

- часть 10417: Связь с медицинскими приборами индивидуального контроля состояния здоровья. Специализация прибора. Глюкометр;

- часть 10420: Связь с медицинскими приборами индивидуального контроля состояния здоровья. Специализация прибора. Анализатор состава тела;

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

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

- часть 10472: Связь с медицинскими приборами индивидуального контроля состояния здоровья. Специализация прибора. Монитор медикаментозного лечения;

- часть 20101: Связь с медицинскими приборами на месте лечения. Прикладные профили. Основной стандарт;

- часть 20601: Связь с медицинскими приборами индивидуального контроля состояния здоровья. Прикладной профиль. Оптимизированный протокол обмена;

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

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

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

- часть 90101: Связь с медицинскими приборами на месте лечения. Аналитические приборы. Тест на месте лечения;

- часть 91064: Стандартный коммуникационный протокол. Компьютерная электрокардиография;

- часть 92001: Формат медицинских сигналов. Правила кодирования.

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

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

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

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

Настоящий стандарт определяет моделирование данных и их промежуточный транспортный уровень согласно IEEE 11073-20601-2008, но не определяет метод измерения.

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

Обзор внешней среды, на которую распространяются требования настоящего стандарта, представлен в 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 включительно <*>.

--------------------------------

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

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

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

Примечания

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

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

В настоящем стандарте применены следующие термины с соответствующими определениями. Термины, определения которых не представлены в настоящем разделе, приведены в [5].

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

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

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

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

Настоящий стандарт и другие стандарты комплекса 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

Диаграмма экземпляров объектов информационной модели предметной области пневмотахометра, определенная в настоящем стандарте, показана на рисунке 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 - атрибут является факультативным. Условные атрибуты должны быть применены в том случае, если условие выполняется, и могут быть применены в противном случае. Рекомендованные атрибуты должны быть применены агентом. Нерекомендуемые атрибуты не должны быть применены агентом. Факультативные атрибуты могут быть применены агентом.

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

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

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

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

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

Примечание - Информация о том, является атрибут статическим или динамическим, приведена в 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 содержит список пар "тип-версия", которые ссылаются на соответствующую специализацию прибора и версию данной специализации.

В таблице 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 ответа на действие.

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.

В таблице 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.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, включая некоторые поля сообщения.

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

6.5.4.2 Сервис SET

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- сервис EVENT REPORT используется агентом для посылки отчетов о конфигурации и данных измерений управляющему устройству. Список отчетов о событиях для специализации прибора пневмотахометра представлен в 6.5.3;

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

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

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

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

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

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

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

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

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

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

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

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

Для агента, реализующего помимо пневмотахометра функции специализаций других приборов, верхняя граница размеров APDU устанавливается следующим образом: агент не должен передавать APDU размером больше суммы N_tx всех реализованных специализаций приборов и должен быть способен принимать APDU размером не более суммы N_rx всех реализованных специализаций приборов. Если данные суммы оказываются больше максимального размера, установленного в ИИЭР 11073-20601, то должен быть применен установленный максимальный размер.

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

Если не установлено иное, то процедура установления связи между агентом-пневмотахометром и управляющим устройством, используемая в настоящем стандарте, должна соответствовать процедуре, определенной в IEEE 11073-20601.

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

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

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

Поле 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.

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

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, имеют следующий вид:

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

Сведения о сервисе 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.

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

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

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

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

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

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

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

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

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

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

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

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

- значениям кодов обозначений;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Индекс;

- Характеристика;

- Ссылка:

- Треб./Статус;

- Поддержка;

- Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На рисунке 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). Пользователь выполняет одно подтвержденное измерение, за которым следует разрыв связи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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