Работаем по всей России
Часы работы: Пн-Пт, 10:00-22:00
+7 ()
Обратный звонок

ГОСТ Р 58501-2019 Информатизация здоровья. Обмен данными с персональными медицинскими приборами. Часть 10425. Специализация прибора: глюкометр непрерывного действия (CGM)

Получить консультацию специалиста

Ошибка: Контактная форма не найдена.

Оставляя заявку, вы соглашаетесь с пользовательским соглашением

>

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

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

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

ГОСТР

58501 —

2019/

ISO/IEEE 11073-10425:

2016

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

Обмен данными с персональными медицинскими приборами

Часть 10425

Специализация прибора: глюкометр непрерывного действия (CGM)

(ISO/IEEE 11073-10425:2016, IDT)

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

Москва Стандартинформ 2019

Предисловие

  • 1 ПОДГОТОВЛЕН Федеральным государственным унитарным предприятием «Российский научно-технический центр информации по стандартизации, метрологии и оценке соответствия» ( на основе собственного перевода на русский язык англоязычной версии стан* дарта. указанного в пункте 4

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

  • 3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому ре* гулированию и метрологии от 29 августа 2019 г. № 571-ст

  • 4 Настоящий стандарт идентичен международному стандарту ISO/IEEE 11073*10425:2016 «Ин* форматизация здоровья. Обмен данными с персональными медицинскими приборами. Часть 10425. Специализация прибора: глюкометр непрерывного действия (CGM)» (ISO/IEEE 11073-10425:2016 «Health informatics — Personal health device communication — Part 10425: Device specialization — Continuous glucose monitor (CGM)». IDT).

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

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

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

© ISO. 2016 — Все права сохраняются © Стандартинформ. оформление. 2019

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

Содержание

  • 1 Обзор

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

    • 1.2 Назначение

    • 1.3 Контекст

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

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

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

    • 3.2 Сокращения

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

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

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

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

  • 5 Понятия и модальности мониторинга глюкозы

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

    • 5.2 Типы приборов

    • 5.3 Взаимосвязь агента CGM с менеджером

    • 5.4 Собранные данные

    • 5.5 Хранимые данные

  • 6 Информационная модель предметной области непрерывного мониторинга глюкозы

    • 6.1 Обзор

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

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

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

    • 6.5 Профили

    • 6.6 Объект системы медицинского прибора (MDS)

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

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

    • 6.9 Объекты перечислений

    • 6.10 Объекты PM*store

    • 6.11 Объекты класса Scanner

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

    • 6.13 Правила расширения информационной модели CGM

  • 7 Сервисная модель глюкометра непрерывного действия

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

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

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

  • 8 Коммуникационная модель глюкометра непрерывного действия

    • 8.1 Обзор

    • 8.2 Характеристики коммуникации

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложение В (обязательное) Дополнительные определения АСН.1

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

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

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

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

национальным и межгосударственным стандартам

Предисловие к ISO/IEEE 11073-10425

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

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

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

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

Стандарт ISO/IEEE 11073-10425 подготовлен комитетом по стандартизации 11073 Сообщества ИИЭР по техническим средствам, применяемым в медицине и биологии (как IEEE 11073-10425-2014). Он был одобрен техническим комитетом ISO/TC 215 «Информатизация здоровья» и утвержден членами ИСО по ускоренной процедуре, которая определена в Соглашении о сотрудничестве между ИСО и ИИЭР. ИИЭР отвечает за поддержание настоящего стандарта при содействии со стороны стран—членов ИСО.

Аннотация: в контексте комплекса стандартов ISO/IEEE 11073 по обмену данными с устройствами настоящий стандарт устанавливает нормативное определение обмена данными между глюкометрами непрерывного действия (continuous glucose monitor. CGM) и менеджерами (например, сотовыми телефонами, персональными компьютерами, бытовыми медицинскими приборами контроля, телевизионными приставками), при котором обеспечивается интероперабельность с автоматическим конфигурированием. 8 данном стандарте используются соответствующие части существующих стандартов, включая терминологию и информационные модели ISO/IEEE 11073. 8 нем указывается использование специфичных кодов терминов, форматов и вариантов поведения в телемедицинской среде, ограничивающих необязательность основных инфраструктур в пользу интероперабельности. 8 настоящем стандарте определена общая основа коммуникационной функциональности устройств CGM. В этом контексте CGM относится к регулярному (как правило, через 5 мин) измерению уровня глюкозы в организме с помощью датчика, постоянно закрепленного на теле.

Ключевые слова: глюкометр непрерывного действия. IEEE 11073-10425™. коммуникация с медицинскими приборами, персональные медицинские приборы.

Важные уведомления и отказы от ответственности, касающиеся стандартизирующих до* кументов ИИЭР

Документы ИИЭР доступны для использования в соответствии с важными уведомлениями и от* казами от ответственности. Эти уведомления и отказы от ответственности или ссылка на данную страницу имеются во всех стандартах, и их можно отыскать под заголовком «Важное уведомление» или «Важные уведомления и отказы от ответственности в отношении использования стандартизующих документов ИИЭР».

Уведомление и отказ от ответственности в отношении использования стандартизирующих документов ИИЭР

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

ИИЭР не гарантирует и не подтверждает точность либо содержание материала, включенного в его стандарты, и явным образом отказывается от каких-либо гарантий (явных, неявных и предусмотренных законом), не включенных в этот или любой другой документ, относящийся к стандарту, включая, не ограничиваясь, такие гарантии как: пригодность для продажи: пригодность для конкретной цели; отсутствие нарушения прав, а также качество, точность, эффективность, действительность или полнота материала. Кроме того. ИИЭР отказывается от каких-либо и всех условий, относящихся к результатам; и качественному исполнению. Документы ло стандартам ИИЭР предоставляются «КАК ЕСТЬ» и «БЕЗ ГАРАНТИИ».

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

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

НИ ПРИ КАКИХ УСЛОВИЯХ ИИЭР НЕ БУДЕТ НЕСТИ ОТВЕТСТВЕННОСТЬ ЗА КАКИЕ-ЛИБО ПРЯМЫЕ. КОСВЕННЫЕ. СЛУЧАЙНЫЕ. СПЕЦИАЛЬНЫЕ. ТИПИЧНЫЕ УБЫТКИ ИЛИ ПОСЛЕДУЮЩИЙ УЩЕРБ (ВКЛЮЧАЯ, НЕ ОГРАНИЧИВАЯСЬ. ЗАКУПКУ ЗАМЕЩАЮЩИХ ТОВАРОВ ИЛИ УСЛУГ). А ТАКЖЕ ЗА НЕВОЗМОЖНОСТЬ ИСПОЛЬЗОВАНИЯ ДАННЫХ ИЛИ ДОХОДОВ ЛИБО ЗА ОПЕРАЦИОННЫЙ ПРОСТОЙ. НЕЗАВИСИМО ОТ ПРИЧИН И ОСНОВАНИЙ ВОЗНИКНОВЕНИЯ ОТВЕТСТВЕННОСТИ. БУДЬ ТО НАРУШЕНИЕ УСЛОВИЙ КОНТРАКТА. ПРЯМОЙ ОТВЕТСТВЕННОСТИ ИЛИ ВНЕДО-ГОВОРНОЙ ОТВЕТСТВЕННОСТИ. ВКЛЮЧАЯ ХАЛАТНОСТЬ И ДРУГИЕ ПРИЧИНЫ. ВОЗНИКАЮЩИЕ В РЕЗУЛЬТАТЕ ПУБЛИКАЦИИ. ИСПОЛЬЗОВАНИЯ ИЛИ ОПОРЫ НА ЛЮБОЙ СТАНДАРТ. ДАЖЕ ЕСЛИ БЫЛО СООБЩЕНО О ВОЗМОЖНОСТИ ТАКОГО УЩЕРБА. И ВНЕ ЗАВИСИМОСТИ ОТ ВОЗМОЖНОГО ПРОГНОЗИРОВАНИЯ ТАКОГО УЩЕРБА.

Переводы

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

Официальные заявления

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

Комментарии к стандартам

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

Комментарии к стандартам необходимо направлять по адресу:

Secretary. IEEE-SA Standards Board

445 Hoes Lane

Piscataway. NJ 08854 USA

Нормативно-правовые акты

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

Авторские права

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

Ксерокопии

При условии уплаты соответствующего сбора ИИЭР предоставит пользователям ограниченную, неисключительную лицензию на ксерокопирование частей любого отдельного стандарта только для некоммерческого внутреннего использования физическим лицом или компанией. По вопросам оплаты лицензионных сборов обращайтесь по адресу: Copyright Clearance Center. Customer Service. 222 Rosewood Drive. Danvers. MA 01923 USA. или no телефону: +1 978 750 8400. Кроме того. Copyright Clearance Center может предоставить разрешение на ксерокопирование частей любого отдельного стандарта для образовательных целей.

Обновление стандартизирующих документов ИИЭР

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

Каждый стандарт ИИЭР не реже одного раза в десять лет проходит процедуру пересмотра. Если документ не проходил процедуру пересмотра более десяти лет, разумно предположить, что такой доку* мент по*прежнему имеет определенную ценность, однако не вполне точно характеризует фактическое положение дел. Пользователям настоятельно рекомендуется проверить наличие у них самого послед* него издания необходимого стандарта ИИЭР.

Для определения степени актуальности данного документа и наличия дополнений к нему в виде опубликованных изменений, поправок или списков опечаток посетите веб*сайт IEEE-SAhttp7/ieeexplore. ieee.org/xpl/standards.jep или обратитесь к ИИЭР по ранее указанному почтовому адресу. Дополнительные сведения о IEEE-SA и процессе разработки стандартов ИИЭР доступны на веб*сайте lEEE-SAno адресу: http://standards.ieee.org.

Список опечаток

Со списком опечаток (если имеется) в стандартах ИИЭР можно ознакомиться на веб-сайте ИИЭР-СА по следующему адресу: http://standards.ieee.org/findstds/errata/index.html. Пользователям рекомендуется периодически посещать эту веб-страницу для ознакомления со списком опечаток.

Патенты

Необходимо учесть, что для внедрения настоящего стандарта может потребоваться использование предмета, на которое распространяется действие патентных прав. Опубликование настоящего стандарта не означает, что ИИЭР проведена проверка существования или действительности каких-либо патентных прав в связи с вышеизложенным. Если владелец или заявитель патента зарегистрировал заявление с использованием принятого гарантийного письма, такое заявление публикуется на веб-сайте ИИЭР-СА по адресу: http://standards.ieee.org/about/sasb/patcom/patents.html. Гарантийные письма могут содержать сведения о том, что отправитель готов или не готов предоставить лицензии в рамках патентных прав без компенсации или за разумное вознаграждение при разумных условиях и положениях. которые явно свободны от любой недобросовестной дискриминации заявителей, желающих получить такие лицензии.

Возможно наличие существенных пунктов формулы изобретения, для которых не получено гарантийное письмо. ИИЭР не несет ответственности за идентификацию существенных пунктов формулы изобретения, для которых может потребоваться лицензия, а также за выяснение законности или области применения пунктов формулы изобретения, или за определение разумности или недискрими-национности каких-либо условий или положений лицензии, предоставленной в связи с отправкой гарантийного письма (при наличии) или в любых лицензионных соглашениях. Пользователи настоящего стандарта несут прямую ответственность в части определения законности любых латентных прав и риска нарушения таких прав. IEEE Standards Association может предоставить необходимую дополнительную информацию.

Участники

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

Дайди Джонг (Daidl Zhong), Председатель Майкл Дж. Кирван (Michael J. Kirwan), Председатель Натаниэль М. Хэмминг (Nathaniel М. Hamming), Заместитель председателя

Charles R. Abbruscalo (Чарльз Р. Абрускзто)

Nabd Abujbara (Набил Абухбара)

Maher Abuzaid (Махер Абусаад)

Manfred Aigner (Манфред Эйгнер)

Jcxge Alberola (Йорге Алберола)

Saeed A. Choudhary (Саид А. Чоудхари)

Julian Goldman (Джулиан Голдмэн)

Raul Gonzalez Gomez(Paynb Госапес Гомес)

Chris Gough (Крис Гу)

Channa Gowda (Манна Гоуда)

Charles М. Gropper (Чарльз М. Гроппер)

Jinhan Chung (Дзиньхан Чанг)

Malcolm Clarke (Малкольм Кларке)

John A. Cogan (Джон А Коган)

John Т. Collins (Джопн Т. Коллинз)

Karsten Alders (Кэрстен Элдере)

Murtaza Ali (Муртаза Али)

Rolf Ambuehl (Рогьф Эмбуэл)

David Aparisi (Дэвид Эпаризи)

Lawrence Ате (Лоуренс Арнэ)

Diego В. Arquillo (Диего Б. Аркуилло)

Serafin Arroyo (Серафин Арройо)

Muhammad Asim (Мухаммад Азин)

Merat Bagha (Мерат Багха)

Doug Baird (Дат Бэйард)

David Baker (Дэаид Бейкер)

Anindya Bakshi (Аниндуя Бакши)

Ananth Balasubramanian (Анант Баласубраманиан)

Sunlee Bang (Санли Банг)

М. Jonathan Barkley (М. Джонатан Баркли)

Gdberto Barrdn (Джильберто Бэррон)

Davtd Bean (Дэвид Бин)

John Bell (Джон Бэлл)

Rudy Belliardi (Руди Бельярди)

Daniel Bernstein (Дэниэль Бернстайн)

George A. Bectos (Джордж А. Бертос)

Chris Biemacki (Крис Бьернаки)

Ofa Bjorsne (Ола Бьорсмэ)

Thomas Blackadar (Томас Блэкэдр)

Marc Blanchet (Марк Бланшэ)

Thomas Bluethner (Томас Блютнер)

Cory Condek (Кори Кондек) Todd Н. Cooper (Тодд Г. Купер) David Cornejo (Дэвид Корнехо) Douglas Coup (Дуглас Куп)

Nigel Сох (Найджел Кокс)

Hans Crommenacker (Хэнс Кромменакер)

Tornio Crosley (Томно Кросли) David Culp Дэвид Калп)

/Mien Curtis (Аллен Кертис) Ndifor Cyril Fru (Ндифор Сирил Фру)

Eyal Dassau (Эйал Дассо)

David Davenport (Дэвид Дэвенпорт)

Russell Davis (Рассел Дэвис)

Ed Day (Эд Дэй)

Sushil К. Deka Суши К Дека)

Pedro de-las-Heras-Quiros (Педро де-лас- Херас-Куйрос)

Jim Dello Stntto (Джим Делло Стригго)

Matthew d’Entremont (Мэтью Дэнтермон)

Lane Desborough (Лэйн Десборо)

Kent Dicks (Кент Дикс)

Hyoungho Do (Хюнгхо До) Xiaolian Duan (Сяолиан Дуань) Brian Dubceuil (Брайан Дубреул) Jakob Ehrensvard (Джекоб Эренсвард)

Fredrik Einberg (Фредрик Эйнберг)

Roger М. Ellingson (Роджер Эллингсон)

Amrt Gupta (Амит Гупта)

Jeff Guttmacher (Джефф Гуттмахер)

Rasmus Haahr (Расмус Хаар)

Christian Habermann (Кристиан Хаберыанн)

Michael Hagerty (Майкл Хэгерти)

Jerry Hahn (Джерри Хан)

Robert Hall (Роберт Холл) Rickey L. Hampton (Рики Л. Хэмптон)

Sten Hanke (Стэн Хэнке) Jordan Hartmann (Джордан Хартманн)

Kai Hassing (Кэй Хэссинг) Marc Daniel Haunschild (Марк Дэниэль Хаунсшильд)

Wolfgang Heck (Вольфганг Хек)

Charles Henderson (Чарльз Хэндерсон)

Jun-Но Her (Юн-Хо Хе)

Takashi Hibino (Такаши Хибино)

Timothy L. Hirou (Тимоти Л. Хибино)

Allen Hobbs (Аллен Хоббс)

Alex Holand (Алекс Холланд)

Arto Holopatnefi (Арто Холопайнен)

Robert Ноу (Роберт Хоу) Frank Hsu (Фрэнк Хсу)

Апле Huang (Анне Хуанг) Sen-Der Huang (Сен-Дер Хуанг)

Zhiqiang Huang (Чжицианг Хуанг)

Ron Huby (Рои Хаби)

Douglas Р. Bogta (Дуглас П. Боджиа)

Xavier Boniface (Ксавьер Бонфэйс)

Shannon Bouoousis (Шэннон Боухози)

Julius Broma (Юлиус Брома)

Lyle G. Bullock. Jr.(HaAn Дж. Баллок-мл)

Bernard Burg (Бернард Берг)

Chris Burns (Крис Бернс)

Anthony Butt (Энтони Багг)

Jeremy Byford-Rew

(Джереми Байфорд-Рю)

Satya CaBoji (Сатья Кэллохи)

Carole С. Carey (Кэрол С. Кэри)

Santiago Carot-Nemesio (Сантьяго Кэрот-Немезио)

Randy W. Carrol (Рэнди У. Кэрролл)

Simon Carter (Саймон Каргер)

Seungchul Chae (Сеунгчул Чае) Rahul Chauhan (Рахул Чаухан)

James Cheng (Джеймс Ченг)

Peggy Chien (Пегги Чиен) Chia-Chin Chong (Чиа-Чин Чонг)

Kohichi Kashiwagi (Кохичи Кашиваки) Ralph Kent (Ральф Кент)

Laurie М. Kermes (Лори М. Кермес)

Michihiro Enokida (Мичихиро Энокода)

Javier Escayoia Calvo

(Хавьер Эсхайола Кальво)

Leonardo Estevez (Леонардо Эстееес)

Roger Feeley (Роджер Фиили)

Bosco Т. FemancJes (Боско Т. Фернандес) Christoph Fischer (Кристоф Фишер) Morten Flintrup (Мортен Фгынтрал) Joseph W. Forler (Джозеф У. Форлер) Russell Foster (Рассел Фостер)

Eric Freudenthal (Эрик Фриденталь) Matthias Frohner (Маттиас Фрохнер)

Ken Fuchs (Кен Фухс)

Jtng Gao (Дзинг Гао)

Marcus Garbs (Маркус Гарбе)

John Garguilo (Джон Гаргуйло)

Rick Geimer (Рик Гемер)

Igor Gejdos (Игорь Гейдос)

Ferenc Gerbovics (Ференц Гербовикс) Nicoiae Goga (Николаэ Гога)

Jim Niswander (Джим Нисвандер) Hiroaki Nrwamoto (Хироаки Нивамото)

Thomas Norgall (Томас Норгелл)

Robert D. Hughes (Роберт Д. Хьюз)

David Hughes (Дэвид Хьюз)

Jiyoung Huh (Дзиюнг Ху)

Hugh Hunter (Хью Хантер)

Hitoshi Ikeda (Хигоши Икеда)

Yutaka Ikeda (Ютаки Икеда)

Philip О. Isaacson (Филипп О. Исааксон)

Atsushi Ito (Атсуши Ито)

Michael Jaffe (Майкл Яффе)

Praduman Jain (Прадуман Йейн)

Danny Jochelson (Дэнни Йохепсон)

Chris Johnson (Крис Джонсон)

Phaneeth Junga (Фэйнит Юнга)

Akiyoshi Kabe (Акиолши Кабэ)

Steve Kahle (Стив Капе)

Tornio Kamioka (Томио

Камиока)

Kei Kariya (Кей Карья)

Andy Kaschl (Энди Касчи) Junzo Kashhara (Юнзо Кашихара)

Sternly К. Simon (Стенли К. Саймон)

Marjorie Skubic (Мэрджори Скубич)

Robert Smith (Роберт Смит)

Ikuo Ksshi (Икуо Кеши) Junhyung Kim (Дзюнхюнг Ким) Min-Joon (Минь-Цзун)

Kim Minbo Kim (Ким Минхо Ким)

Anand Noubade (Ананд Нубаде) Yoshiteru Nozoe (Иошитеру Нозое) Abraham Ofek (Абрахам Офек) Brett Olive (Бретт Олив)

Ivan Soh (Айвэн Сох)

Motoki Sone (Мотоки Соне) Emily Sopensky (Эмили Сопенски)

Rajagopalaa Srinivasan

(Раджагапалан Сринизасан)

Taekon Ktm (Таэкон Ким) Tetsuya Kimura (Тецуя Кимура) Alfred Kloos (Альфред Клоос) Jeongmee Koh (Йеонгми Кох)

Ведопуа Otal (Бегонья Отал) Charles Palmer (Чарльз Палмер) Bud Panjwani (Бад Панджаваки) Carl Pantiskas (Карл Пангискас)

Andreas Slaubert (Андреас Стауберт)

Nicholas Sleblay (Николас Стеблэй)

Beth Stephen (Бет Стивен) Lars Steubesand (Ларс Стюбесан)

Jean-Marc Koller (Жан-Марк Коллер) John Кооп (Джон Куун) Patty Krantz (Патти Крантц) Alexander Kraus (Александр Краус)

Harry Р. Pappas (Гэрри П. Паппас) Mikey Paradis (Мики Парадис) Hanna Park (Ханна Парк) Jong-Тае Parte (Джо-Тае Парк)

John (Ivo) Sbvonc (Джон (Иво) Стиворич)

Raymond A. Strickland (Рэймонд Стриклэнд)

Hermanni Suominen (Херманни Суоминен)

Lee Surprenant (Ли Сьюлренант)

Ramesh Krishna (Рамеш Кришна) Geoffrey Kruse (Джеффри Крус) Falko Kuester (Фалко Кюстер) Rafael Lajara (Рафаэль Ламара)

Pierre Landau (Пьер Ландау) Jaechul Lee (Яэкуль Ли) JongMuk Lee (ЮнгМук Ли) Куопд Но Lee (Кунг Хо Ли)

Rami Lee (Рами Ли) Sungkee Lee (Санки Ли) Woojae Lee (Вуцзяэ Ли) Yonghee Lee (Юнгхи Ли)

Myungeun Park (Мунгеун Парк) Soojun Park (Сууцзюн Парк) Pbitlip Е. Pash (Филлип Е. Паш) TongBi Pei (ТонгБи Пэй)

Soren Petersen (Сорен Петерсен) James Petisce (Джеймс Петмсэ) Peter Piction (Питер Пиктион) Michael Pliskin (Майкл Плишкин)

Jeff Price (Джефф Прайс)

Herald Prinzhom (Харальд Принзхорн) John Quinlan (Джон Куинлан)

Arif Rahman (Ариф Рахман)

Ravi Swami (Рави Свами) Ray Sweidan (Рэй Свэйден)

Jin Tan (Цзин Тан)

(Харюуки

Haruyuyki Татсуми)

Tatsumi

John W.

Thomas

(Джон У.

Томас)

Brad Tipier (Брэд Типлер) Jonas Тгёп (Йонас Тирэн) James Tomcik (Джеймс Томчик)

Janet Traub (Джанет Трауб) Jesus Daniel (Джезус Дэниэль) Trigo Gary (Триго Гэри) Tschautscher Masato Tsuchid (Чаучер Масато Тсучид)

Joe Lenart (Джо Ленарт) Kathryn A. Lesh (Кэтрин А. Лэш) Qiong U (Кионг Ли)

Ying Li (Йинг Ли)

Tanzilur Rahman (Танзилур Рахман) Steve Ray (Стив Рэй)

Pbiftip Raymond (Филлип Рэймонд) Tim Reilly (Тим Райли)

Ken Tubman (Кен Табмэн) Yoshihiro Uchida (Йошиширо Учида)

Sunil Unadkal (Санип Унадкат) Fabio Urbani (Фабио Урбани)

Patrick Lichter (Патрик Лихтер) Jisoon Lim (Цзисун Лим) Joon-Ho Lim (Юн-Хо-Лим) John Lin (Джон Лин) Jiajia Liu (Цзяцзя Лиу)

Barry Reinhold (Барри Рэйнолъд) Brian Reinhold (Брайэн Рэйнольд)

Melvin I. Reynolds (Мэлвин А. Рэйнольдс) John G. Rhoads (Джон Г. Родс)

Jeffrey S. Robbins (Джеффри С. Роббинс)

Philipp Urbauer (Филипп Урбайер)

Laura Vanzago (Лаура Ванзаго) Alpo Vdrri (Алпо Варри)

Ciro de la Vega (Циро де ла Вега)

Dafemar Velez (Далмар Велез)

Wei-Jung Lo (Вэй-Цзюмг По) Charles Lowe (Чарльз Лоу) Don Ludolph (Дон Лудолф) Christian Luszick (Кристман Пузик)

Moskowitz Robert (Москоеиц Роберт) Timothy Robertson (Тимоти Робертсон) David Rosales (Дэвид Розалес) BiU Saltzstein (Билл Залстайн)

Naveen Verma (Навин Верма) Rudi Voon (Руди Вуун)

Isobei Walker (Изобель Уолкер) David Wang (Дэвид Ванг)

Bob MacWiliams (Боб Маквильямс) Srikkanth Madhurbootheswaran (Срикант Мадхурбутхешаарн) Romain Marmot (Роман Мэрмог) Sandra Martinez (Сандра Мартинес)

Benedikt Satzbrunn (Бенедикт Зальцбрюн) Jerry R Wang (Джерри П. Ванг)

Giovanna Sannino (Джованна Саннино) Jose A. Sanlos-Cadenas (Жоэе Сактош-Каденас)

Stefan Sauermann (Стефан Зауэрманн)

Yao Wang (Яо Ванг) Yi Wang (И Ванг) Steve Warren (Стив Уоррен)

Miguel Martinez de Espronceda Camara (Мигель Мартинез дэ Эслронседа Камара)

Peter Mayhew (Питер Мэйхью)

John Sawyer (Джон Сойер) Guillaume Schatz (Гильомэ Шатц) Alois Schloegl (Алоиз Шлегль)

Fujio Watanabe (Фуджио Ватанабэ)

Toru Watsuji (Тору Ватиуи) Mike Weng (Майк Венг)

Jim McCain (Джим Маккейн)

L^szto Meteg (Ласло Мележ) Alexander Mense (Александр Менсе) Ethan Melsger (Этан Мецгер)

Yu Miao (Ю Мяо)

Paul S. Schluter (Пол С. Шлютер)

Lars Schmitt (Ларс Шмидт)

Mark G. Schnell (Марк Г. Шнель)

Richard A. Schrenkec (Ричард А. Шренкер) Antonio Scorpiniti (Антонио Скорпинити)

Kathleen Wible (Кэтлин Уайбл)

Paul Williamson (Пол Вильямсон)

Jan Wrttenber (Ян Виттенбер) Jia-Rong Wu (Цзя-Рон By)

Wrll Wykeham (Уилл Вэйкхэм)

Jinsei Miyazaki (Цзинсэй Миядзаки) Erik Moll (Эрик Молл)

Darr Moore (Дарр Мур)

Piotr Murawski (Петр Мурзэский)

Kwang Seok Seo (Квант Сеок Сео) Riccardo Serafin (Рикардо Серафин) Sid Shaw (Сид Шо)

Frank Shen (Франк Шен)

Ariton Xhafa (Эритон Ксхафа) Junjie Yang (Юнье Янг) Ricky Yang (Рики Янг) Melanie Yeung (Мелани Еунг)

Soundharya Nagasubramanian (Саумхарья Нагасубраманьян) Jae-Wook Nah (Яэ-Вук Нах) Alex Neefus (Алекс Нифус) Trong-Nghia Nguyen-Dobinsky (Тронг-Нгха-Нгуен-Добинсхий)

Liqun Shen (Ликун Шен)

Bozhi Shi (Божи Ши)

Min Shih (Мин Ших) Mazen Shihabi (Мазен Шихаби)

Done-Sik Yoo (Дон-Сик Ю) Jason Zhang (Джейсон Чжанг) Zhiqiang Zhang (Чжицианг Чжанг)

Thomas Zhao (Томас Чжао)

Michael Е. Nidd (Майкл Э. Нидд)

Redmond Shouldice (Рэдмонд Шоулдайс)

Miha Zoubek (Миха Зоубек)

Tetsu Nishimura (Тетсу Нишимура)

Szymon Zysko (Симон Зиско)

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

Thomas Blackadar (Томас Блэкдэр)

Lyle G. Bullock. Jr. (Лайл Дж. Беллок, мл.)

Keith Chow (Кейт Чоу)

Werner Hoelzl (Вернер Хётцль)

Noriyuki Ikeuchi (Ноюриюки Икеучи)

Atsushi Ito (Атсуши Ито)

Nick S. A. Nikjoo(HHK С. А.

Никийю)

Melvin I. Reynolds (Мэлвин Ай. Рэйнольдс)

Bartien Sayogo (Бартен Сайото)

Sourav Dutla (Сурав Дутта)

Joseph El Youssef (Джооеф Эль Юсуф) Christoph Father (Кристоф Фишер)

Hector Barron Gonzalez (Гектор Баррон Гонзалес) Randall Groves (Рэндалл Грувс) Kai Massing (Кай Хэосмнг) Wolfgang Heck (Волфганг Хек)

Ra| Jain (Рэй Джейн)

Piotr Karocki (Петр Кароки) Robert Kircher (Роберт Кирхер)

Jong Muk Lee (Йонгмук Ли)

Jie Li (Цзе Ли)

William Lumpkins (Вильям Лампхинс) Greg Luri (Грег Лури)

Paul Schluter (Поль Шлютер)

Lars Schmitt (Ларс Шмидт) Eugene Stoudenmire (Юджин Студенмайер)

Walter Struppler (Уолтер Страпллер)

Jan Wrttenber (Ян Виттенбер) Oren Yuen (Орен Юэн) Daidi Zhong (Дайди Чжунг)

Когда Отдел стандартов Ассоциации стандартов ИИЭР (IEEE-SA Standards Board) утвердил настоящий стандарт 21 августа 2014 г., в его состав входили следующие члены:

Джон Кулик (John Kulick), председатель Йон Уолтер Родел (Jon Walter Rosdahl). заместитель председателя Ричард X. Халетт (Richard Н. Hulett), предыдущий председатель Константинос Карачалиос (Konstantlnos Karachalios). секретарь

Peter Balma (Питер Балма)

Michael Janezic (Майкл Янезич)

Ron Peterson (Рои Петерсон)

Farooq Bari (Фарук Бари) Ted Burse (Тед Берс)

Jeffrey Katz (Джеффри Кац) Joseph L. Koepfinger’ (Джозеф Кепфингер)

Clint Chaplain (Клинт Чаплэйн) Stephen Dukes (Стивен Дьюкс)

David J. Law (Дэвид Дж. Ло) Hung Ung (Ханг Ланг)

Jean-PhilUppe Faure (Жан-Филипп Фаурэ) Oleg Logvinov (Олег Логвинов) Gary Hoffman (Гэри Хоффман) Т. W. Olsen (Т.В. Олсен)

Glenn Parsons (Гленн Парсонс)

Adrian Stephens (Эдриэн Стефенс) Peter Sutherland (Питер Сазерлэнд)

Yatin Trivedi (Йетин Триведи) Phil Winston (Фил Уинстон) Don Wright (Дон Райт) Yu Yuan (Ю Юань)

* Почетный член.

Также включены следующие, не имеющие права голоса, контактные лица Отдела стандартов Ассоциации стандартов ИИЭР:

Ричард Дэблэсио (Richard DeBlasio), представитель DOE Майкл Янежич (Michael Janezic). представитель NIST Дон Мессина (Don Messina) Издание контента ИИЭР Кэтрин Беннетт (Kathryn Bennett) Программы технического сообщества ИИЭР

Введение

Данное введение не является частью стандарта IEEE 11073-10425—2014 «Информатизация здоровья. Обмен данными с персональными медицинскими приборами. Часть 10425. Специализация прибора. Глюкометр непрерывного действия (CGM)».

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

О Информацию по ссылкам можно найти а разделе 2.

ГОСТ Р 58501—2019/ISO/IEEE 11073-10425:2016

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

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

Обмен данными с персональными медицинскими приборами

Часть 10425

Специализация прибора: глюкометр непрерывного действия (CGM)

Health informatics. Personal health device communication. Part 10425. Device specialization: continuous glucose monitor (CGM)

Дата введения — 2020—05—01

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

Данный документ ИИЭР доступен для использования в соответствии с важными уведомлениями и отказами от ответственности. Такие уведомления и отказы содержатся во всех публикациях, содержащих настоящий документ, и выделяются заголовком «Важное уведомление» или «Важные уведомления и отказы от ответственности, касающиеся документов ИИЭР». Их также можно получить, обратившись с запросом к ИИЭР, либо просмотреть на сайте http://standards.ieee.org/IPR/dlsclaimers.htmt.

1 Обзор

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

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

  • 1.2 Назначение

Настоящий стандарт удовлетворяет потребность в открытом для публики, независимом стандарте контроля обмена информацией между персональными медицинскими приборами (ПМП) и еычисли-

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

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

  • 1.3 Контекст

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

Настоящий стандарт создан на основе стандартов IEEE 11073-20601а-2010 и ISO/IEEE 11073-20601:2010. которые, в свою очередь, используют информацию из стандартов ISO/IEEE 11073-10201:2004 [87] и ISO/IEEE 11073-20101:2004 [В8] *).

Правила кодирования для медицинских устройств MDER (medical device encoding rules), использованные в настоящем стандарте, в полном объеме описаны в стандарте ISO/IEEE 11073-20601:2010.

В настоящем стандарте воспроизведены релевантные части номенклатуры, приведенной в стандарте ISO/IEEE 11073-10101:2004 [В6]. а также добавлены новые целевые номенклатурные коды. Сочетание настоящего стандарта со стандартами ISO/IEEE 11073*20601:2010 и IEEE 11073-20601 “*-2014 документирует все номенклатурные коды, требуемые для его реализации.

Примечание 1 —Стандарт IEEE 11073-20601-2014 является редакцией ISO/IEEE 11073-20601:2010. Он содержит новый материал и поправки и не колирует содержание ISO/IEEE 11073-20601:2010. В тексте настоящего стандарта ссылка на стандарт IEEE 11073-20601-2014 относится к документу, получаемому после использования нового материала и поправок в ISO/IEEE 11073-20601:20101 2 3>.

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

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

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

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

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

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

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

8 настоящем стандарте применены следующие термины с соответствующими определениями. Определения терминов, не указанных в данном разделе, см. в Онлайновом словаре по стандартам IEEE (IEEE Standards Dictionary Online)5>.

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

  • 3.1.2 глюкоза в крови (blood glucose): Концентрация глюкозы в крови.

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

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

  • 3.1.5 глюкометр непрерывного действия; CGM (continuous glucose monitor: CGM); Медицинский прибор, выполняющий оценку концентрации глюкозы в крови; как правило, по жидкости тела.

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

  • 3.1.7 глюкоза (glucose): Обычно именуется «сахар» и является основным источником энергии, используемой клетками тела.

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

  • 3.1.9 интерстициальная (тканевая) жидкость; ISF (interstitial fluid; ISF): Тонкий слой жидкости, окружающий клетки тела.

  • 3.1.10 менеджер (manager): Узел, получающий данные от одной или нескольких агентских систем.

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

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

  • 3.1.12 идентификатор объекта (obj-handle): См. идентификатор (handle).

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

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

  • 3.2 Сокращения

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

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

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

AST — получение крови из альтернативных мест (alternative site testing);

8GM — глюкометр (blood glucose meter):

CGM — глюкометр непрерывного действия (continuous glucose monitor);

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

EUI-64 — расширенный уникальный идентификатор (64 бита) [extended unique identifier (64 bits)]; HCP — медицинский специалист (health care professional);

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

ISF — интерстициальная (тканевая) жидкость (interstitial fluid);

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

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

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

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

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

PDU — блок данных протокола (protocol data unit):

PHD — персональный медицинский прибор. ПМП (personal health device};

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приборы, которые соответствуют данному стандарту, также могут (при необходимости) соответствовать другим стандартам специфичных предметных областей и приборов, заменяющих требования настоящего стандарта в различных аспектах, включая безопасность, надежность и управление рисками. Предполагается, что пользователь данного стандарта знаком со всеми другими применимыми стандартами. которые соответствуют спецификациям более высокого уровня. Как правило, медицинские приборы будут соответствовать требованиям базового стандарта МЭК 60601-1:2005 [В1] в части электрической и механической безопасности, а также требованиям стандарта для специфичного прибора, который может быть определен в комплексе стандартов МЭК 60601-2 [В2]. К программным аспектам могут применяться такие стандарты, как МЭК 62304:2006/ЕН 62304:2006 (83].

Приборы, которые соответствуют требованиям настоящего стандарта, реализуют более высокие уровни сетевого программного обеспечения, а также применяют более низкие уровни в зависимости от приложения. Требования к производительности таких приложений и соответствия определены в иных источниках и не входят в область применения настоящего стандарта. Более того, использование любого медицинского оборудования подлежит оценке риска и управлению риском в зависимости от приложения. Уместными примерами могут служить ИСО 14971:2007 [В5] и МЭК 80001-1:2010 [8-4]. Требования оценки и управления подобными рисками, а также соответствия не входят в область применения настоящего стандарта.

5 Понятия и модальности мониторинга глюкозы

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

8 этом разделе представлены общие концепции приборов CGM. 8 контексте ПМП в данном семействе стандартов CGM представляет собой прибор, оценивающий концентрацию глюкозы в крови, как правило, с помощью измерений, проводящихся в интерстициальной (тканевой) жидкости (ISF). Концентрация глюкозы считывается с датчика непрерывно с периодическими интервалами. Прибор CGM улучшает контроль проведения терапии в отличие от одиночных, эпизодических измерений с помощью глюкометра (blood glucose meter. BGM). Частые измерения, обеспечиваемые приборами CGM, дают пациенту более качественную оценку с точки зрения колебаний уровней глюкозы е крови в течение дня и. в свою очередь, могут снизить риск развития диабетических осложнений.

Глюкоза, или концентрация сахара в крови, является основным источником энергии для клеток тела. Уровень глюкозы строго регулируется в теле человека и обычно поддерживается на уровне примерно 70 мг/дл — 150 мг/дл (4 мкмоль/л — 8 мкмоль/л). Таким образом, общее количество глюкозы в циркулирующей крови составляет примерно 3.5—7.5 г (с учетом того, что общее количество крови у взрослого человека составляет 5 л). У здорового взрослого мужчины весом 75 кг и общим объемом крови 5 л уровень глюкозы в крови составляет 100 мг/дл (5.5 мкмоль/л). что соответствует общему количеству около 5 г (1/5 унции и эквивалентно потребительскому пакетику сахара) глюкозы в крови и примерно 45 г (1.5 унции) во всей жидкости тела (которая включает кровь и ISF). Уровень глюкозы повышается после еды. а самый низкий — обычно утром, до первого приема пищи.

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

Концентрация глюкозы в крови измеряется в мкмоль/л или в мг/дл. В странах, где применяется метрическая система, обычно используются мкмоль/л. Однако в США. а также в других странах используют мг/дл. Для перевода измерений глюкозы в крови из одной системы измерений в другую используются следующие преобразования:

  • – разделить мг/дл на 18.02, чтобы получить мкмоль/л (или умножить на 0,0555).

  • – умножить мкмоль/л на 18,02. чтобы получить мг/дл (или разделить на 0.0555).

Концентрацию глюкозы, измеренную различными методами, можно отнести к различным типам, определяемым тремя элементами: типом образца, источником образца, а также эталонным методом концентрации. В таблице 1 показаны все типы концентрации глюкозы, определенные в данном стандарте.

Таблица 1 — Типы концентрации глюкозы

Тил образца

Источник образца

Эталонный метод

Кровь

Кагмлляры

Цельная кровь

Плазма

Вены

Цельная кровь

Плазма

Артерии

Цельная кровь

Плазма

Неопределенный

Цельная кровь

Плазма

Тканевая жидкость

Подкожная фасция

Нет

Контрольный раствор

Нет

Нет

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

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

  • 5.2 Типы приборов

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

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

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

Передатчик, подсоединенный к датчику, используется для беспроводной передачи результатов измерений приемнику. Этот приемник часто представляет собой физически отдельное устройство, которое может отображать графики трендов и другие статистические данные или уведомления наряду с текущими измерениями уровня глюкозы, как это показано на рисунке 1(a). Дозаторы инсулина, а также другие индивидуальные электронные приборы также могут выполнять функции приемника измерений CGM. как это показано на рисунке 1(b).

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

Для ясности использовались термины «передатчик» и «приемник», однако следует знать, что оба этих устройства в действительности могут быть приемопередатчиками.

  • 5.3 Взаимосвязь агента CGM с менеджером

Как указано в 5.2. прибор CGM может состоять из двух физических частей, например, датчика/ передатчика и приемника. Настоящая специализация устройства описывает стандарт интероперабельности только одной из этих физических частей с вычислительным устройством, выступающим в роли менеджера CGM. Например, он может регламентировать взаимодействие между менеджером и приемником CGM или датчиком/передатчиком CGM, если в системе нет специального приемника CGM. Эти сценарии показаны на рисунке 1. Могут также существовать другие сценарии, которые здесь не обсуждаются.

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

Рисунок 1 — Взаимосвязь агента с менеджером — сценарий обмена данными приемника CGM с менеджером изображен на (а), а вариант связи датчика/передатчика CGM с менеджером изображен на (Ь) (могут существовать другие сценарии, не изображенные на рисунке 1)

  • 5.4 Собранные данные

    • 5.4.1 Общие положения

CGM представляет собой портативное устройство и поэтому при сборе данных может быть не подключен к менеджеру. Ниже приведены два основных варианта подсоединения CGM к менеджеру и отправки данных:

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

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

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

  • 5.4.2 Глюкоза

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

  • 5.4.3 Калибровка датчика

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

  • 5.4.4 Срок службы датчика

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

  • 5.4.5 Интервалы отбора глюкозы

Интервал отбора глюкозы указывает частоту измерений глюкозы.

  • 5.4.6 Тренд глюкозы

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

  • 5.4.7 Нижние/верхние пороговые значения для пациента

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

  • 5.4.8 Критичный диапазон прибора

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

  • 5.4.9 Пороговые значения скорости изменения

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

  • 5.4.10 Статус PHD DM

Статус PHD DM позволяет осуществлять общую обработку уведомлений персонального медицин* ского прибора (ПМП). С помощью меток времени он указывает возникновение информации, предупреждение. ошибку, обслуживание, а также не определенные сообщения.

  • 5.4.11 Статус CGM

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

5.5 Хранимые данные

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

6 Информационная модель предметной области непрерывного мониторинга глюкозы

  • 6.1 Обзор

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

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

8 настоящем стандарте не определены расширения классов, описанных в стандарте IEEE 11073-20601-2014.

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

Диаграмма экземпляров объектов информационной модели предметной области CGM, которая определена для целей настоящего стандарта, показана на рисунке 2. Описания различных объектов CGM [например, объекта системы медицинских приборов (medical device system. MDS) CGM. числовой объект глюкозы, а также перечисляемый статуса CGM] см. в 6.6—6.12. Правила расширения информационной модели предметной области CGM за рамки элементов, описанные в настоящем стандарте, см. в 6.13. Каждый раздел, описывающий объект CGM, содержит следующую информацию;

  • – номенклатурный код. используемый для идентификации класса объекта. Примером использования такого кода служит событие конфигурации, когда для каждого объекта сообщается класс объекта. Это позволяет менеджеру определить, является ли класс указываемого объекта числовым, массивом считываний в режиме реального времени, перечислением, сканером или классом PM-store;

  • – атрибуты объекта. Каждый объект имеет атрибуты, которые отображают и передают информацию о физическом устройстве и его источниках данных. Каждый объект имеет атрибут Handle, идентифицирующий экземпляр объекта в памяти агента. Значения атрибутов доступны и модифицируются с помощью методов, например. GET и SET. Типы атрибутов задаются в нотации АСН.1. Определения АСН.1 для новых типов атрибутов, специфичных для данного стандарта, приведены в Приложении В. а определения АСН.1 для существующих типов атрибутов, на которые дается ссылка в настоящем стандарте. приведены в стандарте IEEE 11073-2060-2014;

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

  • – потенциальные события, генерируемые объектом. Данные передаются менеджеру, используя события;

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

Атрибуты каждого класса определены в таблицах, указывающих наименование атрибута, его значение и его квалификатор. Квалификаторы означают следующее: М — обязательный атрибут (Mandatory). С — условно обязательный атрибут (Conditional), зависящий от условия, заявленного в графе «Примечания» или «Значение» (если дается ссылка на стандарт IEEE 11073-20601-2014, то условие берется из него). R — атрибут рекомендован (Recommended), NR — атрибут не рекомендован (Not Recommended) и О — атрибут не обязателен (Optional). Обязательные атрибуты должны быть реализованы агентами. Условно-обязательные атрибуты по возможности реализуются, если применимо условие и могут быть реализованы в ином случае. Рекомендуемые атрибуты по возможности должны быть реализованы агентом. Не рекомендуемые атрибуты не должны быть реализованы агентом. Необязательные атрибуты могут быть реализованы агентом. Для атрибутов с квалификаторами R (рекомендован) или NR (не рекомендован) должны выполняться требования, указанные в графах «Примечание» и «Значение», приведенные в стандарте IEEE 11073-20601-2014.

Атрибуты могут быть статическими, динамическими или наблюдаемыми, как это указано в стандарте IEEE 11073-20601-2014.

Рисунок 2 — Информационная модель предметной области глюкомегра непрерывного действия

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

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

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

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

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

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

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

  • 6.5 Профили

    • 6.5.1 Общие положения

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

  • 6.6 Объект системы медицинского прибора (MDS)

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

В таблице 2 приведены атрибуты объекта CGM MDS. Номенклатурный код для идентификации класса объекта MDS имеет следующий вид: MDC_MOC_VMS_MDS_S!MP.

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

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

Значение

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

Handle

0

М

System-Type

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

NR

System-Type-Spec-Lisl

(MDC_DEV.SPEC_PROFILE.CGM. 1)

М

System-Model

(«Изготовитель», «модель»}

М

System-И

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

М

Dev-Configurabon-td

Стандартная конфигурация: 0х09С4 Расширенная конфиг: 0x4000—0x7FFF

м

Attribute- Value-Mao

См. стандаот ИИЭР 11073-20601-2014

с

Production-Soeafication

См. стандаот ИИЭР 11073-20601-2014

с

Mds-Time-Info

См. стандаот ИИЭР 11073-20601-2014

с

Date-and-Time

См. стандаот ИИЭР 11073-20601-2014

с

Base-Offset-Time

См. стандаот ИИЭР 11073-20601-2014

R

Relative-Time

См. стандаот ИИЭР 11073-20601-2014

С

HiRes-Relabve-Time

См. стандаот ИИЭР 11073-20601-2014

С

Date-and-Time-Adfustment

См. стандаот ИИЭР 11073-20601-2014

R

Power-Status

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

R

Battery-Level

См. стандаот ИИЭР 11073-20601-2014

R

Remainina-BaHerv-Ttme

См. стандаот ИИЭР 11073-20601-2014

R

Reo-Cert-Data-Ust

См. стандаот ИИЭР 11073-20601-2014

О

Confirm-Timeout

См. стандарт ИИЭР 11073-20601-2014

О

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

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

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

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

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

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

Как определено в ISO/IEEE 11073-20601а-2010. атрибут Production-Specification содержит серийные номера компонентов, редакции и т. д. в формате, специфичном для изготовителя. У объекта CGM MDS атрибут Production-Specification содержит необходимую информацию для всех физических компонентов. например, датчик, передатчик, приемник и т. д. (в зависимости от ситуации). Когда один из этих компонентов меняется или заменяется, то атрибут Production-Specification объекта MDS соответственно уточняется.

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

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

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

Сервис

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

Режим

Тип субсервнса(ас1>оп-1уре)

Параметры (acliorinto-arQe)

Результаты lactoninfoarqsl

ACTION

Set-Time

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

MDC.ACT_SET.T1ME

SetTimelnvoke

ACTION

Set-Base-Offset-Time

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

MDC.ACT_SET_BO.TIME

SetBOTimelnvoke

Set-Time

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

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

Set-flase-Offsef-Time

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

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

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

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

Таблица 4 — События объекта MDS непрерывного мониторинга глюкозы

Сервис

Иыя типа субсераиса

Режим

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

Параметры (event- into)

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

EVENT REPORT

MDS-Configu ration -Event

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

MDC NOTI CONFIG

ConfigReport

ConfigReport Rsp

MDS-Dynamic-Data-Update-Fixed

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

MDC NOTI SCAN REPORT F1XED

ScanReportlnfo-Fixed

MDS-Dynamic-Da-ta-Update-Var

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

MDC NOTI SCAN REPORT.VAR

ScanReportlnfoVar

MDS-Dynamic-Da-ta-Update-MP-Fixed

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

MDC NOTI SCAN REPORT MP FIXED

ScanReportlnfoMP-Fixed

MDS-Dynamic-Da-ta-Update-MP- Var

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

MDC NOTI SCAN REPORT MP VAR

ScanReportlnfoMP-Var

  • • MDS-Configuration-Event:

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

  • • MDS-Dynamic-Data-Update-Var:

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

  • – MDS-Dynamic-Data-Update-Fixed:

Данное событие обеспечивает данные динамических измерений, хранящиеся у агента в числовых объектах и объектах перечислений. Эти данные сообщаются в фиксированном формате, который определяется атрибутом Attribute-Value-Map объекта(ов). Событие передается агентом как незапрашиваемое сообщение (т. е. передача данных измерений, инициированная агентом). Дополнительную информацию об отчете о незапрашиваемом событии см. в 8.5.3.

  • – MDS-Dynamic-Data-Update-MP-Var:

Это событие аналогично MDS-Dynamic-Data-Update-Var. но позволяет включить данные от нескольких лиц.

  • – MDS-Dynamic-Data-Update-MP-Fixed:

Это событие аналогично MDS-Dynamic-Data-Update-Fixed. но позволяет включить данные от нескольких лиц.

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

  • 6.6.4 Другие сервисы MDS

    • 6.6.4.1 Сервис GET

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

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

Таблица 5 — Сервис GET объекта MDS непрерывного мониторинга глюкозы

Сервис

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

Режим

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

Параметры

Результаты

GET

«подразумеваемое подтверждение*

GetArgumentSim-pie = (obj-handle = 0). attribute-id-list «необязательный*

GetResultSimple = (obf-haodle = 0). attribute-list

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

6.Б.4.2 Сервис SET

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

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

    • 6.7.1 Общие положения

Информационная модель предметной области CGM (см. рисунок 2) содержит числовые объекты, представляющие характеристики концентрации глюкозы, калибровки датчика, срока службы датчика, интервала измерений, трендов, пороговых значений для пациента, нижнего и верхнего предела измерений. а также пороговых значений скорости изменения. Эти характеристики описаны е 6.7.2—6.7.9. В таблице 6 показаны атрибуты, общие для всех числовых объектов.

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

Имя атрибута

Значение

Коалифигатор

НапЛе

См. стандарт IEEE 11073-20601-2014

М

Type

Определен в следующих подразделах

м

Supplemental-Types

См. стандарт IEEE 11073-20601-2014

о

Metric-Spec-Small

Определен в следующих подразделах

м

Metric-Structure-Small

См. стандарт IEEE 11073-20601-2014

о

Measurement-Status

См. стандарт IEEE 11073-20601-2014

с

Metric-Id

См. стандарт IEEE 11073-20601-2014

О

Metric-id-List

См. стандарт IEEE 11073-20601-2014

с

Metric-Id-Partition

См. стандарт IEEE 11073-20601-2014

о

Unit-Code

Определен в следующих подразделах

м

Attribute-Value-Map

См. стандарт IEEE 11073-20601-2014

с

So urce-Han Ла-Reference

См. стандарт IEEE 11073-20601-2014

О

Label-String

См. стандарт IEEE 11073-20601-2014

О

Unit-La belString

См. стандарт IEEE 11073-20601-2014

О

Absolute-Time-Stamp

См. стандарт IEEE 11073-20601-2014

с

Base-Offset-Tme-Stamp

См. стандарт IEEE 11073-20601-2014

с

Relative- Time-Stamp

См. стандарт IEEE 11073-20601-2014

с

HiRes-Time-Stamp

См. стандарт IEEE 11073-20601-2014

с

Measure-Active-Period

См. стандарт IEEE 11073-20601-2014

о

Simpta-Nu-Observed-Value

См. стандарт IEEE 11073-20601-2014

с

Compound-Simple-Nu-Observed-Value

См. стандарт IEEE 11073-20601-2014

с

Basic-Nu-Observed-Value

См. стандарт IEEE 11073-20601-2014

с

Compound-Basic-Nu-Observed-Value

См. стандарт IEEE 11073-20601-2014

с

Nu-Observed-Value

См. стандарт IEEE 11073-20601-2014

с

Compound-Nu-Observed-Value

См. стандарт IEEE 11073-20601-2014

с

Accuracy

См. стандарт IEEE 11073-20601-2014

о

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

Примечание 2 — Описания квалификаторов см. в 6.3.

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

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

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

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

Специализация CGM рекомендует использовать атрибут Base-Time-Offset для всех числовых объектов. Атрибут Base-Time-Offset позволяет удобно корректировать время на основе изменения часовых поясов.

  • 6.7.2 Глюкоза

Глюкозой называют измерение концентрации глюкозы в крови. Как правило, в CGM это измерение выполняется с использованием других жидкостей тела (не крови), поэтому для вычисления уровней глюкозы в крови требуется калибровка. В таблице 7 представлены атрибуты числового объекта глюкозы. Числовой объект глюкозы должен поддерживаться агентом CGM.

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

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

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

Измерение глюкозы, превышающее возможности датчика прибора, показывается с наблюдаемым значением + INFINITY, а измерение глюкозы, которое ниже возможностей датчика прибора, показывается с наблюдаемым значением -INFINITY.

Атрибут глюкозы числового типа определяет тип жидкости, которую будет отбирать прибор CGM. Если тип жидкости неизвестен, то должна быть выбрана (по ситуации) не определенная цельная кровь, MDC_CONC_GLU_UDTRM_WHOLEBLOOD. или не определенная плазма, MDC_CONC_GLU_ UDTRM_PLASMA. Числовой атрибут глюкозы дополнительно определяется атрибутом supplemental-type, который указывает, из какого места тела будет отбирать пробы CGM. Если место отбора проб неизвестно, то должен быть выбран MDC_CTXT_GLU_SAMPLELOCATION_UNDETERMINED, а если место отбора проб отсутствует в предоставляемых кодах, то должен быть выбран MDC_CTXT GLU_ SAMPLELOCATION_OTHER.

Атрибут measurement-status используется для квалификации измерения, или обеспечения дополнительных условий работы и рекомендован для использования. Сообщение о статусе измерения calibration-ongoing должно означать, что в момент выполнения измерения CGM находился в процессе калибровки. Сообщение о статусе измерения invalid должно означать, что в момент выполнения измерений CGM не был откалиброван. Сообщение о статусе измерений questionable должно означать, что измерение не надежное. Сообщение о статусе измерения validated-data должно означать, что в момент выполнения измерений CGM был откалиброван и измерение надежное.

Таблица 7 — Атрибуты числового объекта глюкозы

Иыя атрибута

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

Стандартная конфигурация lOev-ConfiQuralion-id » 0х09С4)

Значение

Kean.

Значение

Кеал

Handle

См. стандарт IEEE 11073-20601-2014

М

1

М

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

Имя атрибута

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

Стандартная конфигурация (Dev-Con6gurabon-ld » 0x09C4)

Значение

Ksan

Значение

Kean.

Туре

{MDC PART SCADA, MDC CONC GLU ISF. или MDC CONC GLU CAPILLARY WHOLEBLOOD, или MDC CONC GLU CAPILLARY PLASMA, или MDC CONC GLU VENOUS WHOLEBLOOD, или MDC CONC GLU VENOUS PLASMA. или MDC CONC GLU ARTERIAL WHOLEBLOOD, или MDC CONC GLU ARTERIAL PLASMA, или MDC CONC GLU CONTRO.Lwih MDC CONC GLU UNDETERMINED WHOLEBLOOD, или MDC CONC GLU UNDETERMINED.PLASMA)

M

{MDC PART SCADA. MDC

CONC.GLUJSF)

М

Supplemental-Types

(MDC PART PHD DM. MDC CTXT GLU SAMPLELOCATION FINGER, или MDC CTXT GLU SAMPLELOCATION AST. или MDC CTXT GLU SAMPLELOCATION EARLOBE, или MDC CTXT GLU SAMPLELOCATION CTRLSOLUTION. или MDC CTXT GLU SAMPLELOCATION SUBCUTANEOUS, или MDC CTXT GLU SAMPLELOCATION UNDETERMINED, или MDC CTXT GLU SAMPLELOCATION OTHER)

См. стандарт IEEE 11073-20601-2014 и текст ниже

О

{MDC PART PHD DM. MDC CTXT GLU SAMPLELOCATION-SUBCUTANEOUS)

М

Metric-Spec-Small

mss-avaH-intermittent | mss-avail-stored-data | mss-acc-agent-initiated | mss-cat-catcula-lion

M

mss-avail-intermittent | mss-avail-stored-data | mss-acc-agent-initi-ated | mss-cat-calculation

М

Measurement-Status

См. стандарт ИИЭР 11073-20601-2014 и текст ниже

R

См. стандарт

IEEE 11073-20601-2014

М

Unit-Code

MDC DIM MILLI G PER DL или MDC DIM_MILLI_MOLE_PER_L

M

MDC-DIM- MILLI_G.PER.DL

М

Attribute-Value-Map

См. стандарт IEEE 11073-20601-2014

C

MDC ATTR NU VAL OBS BASIC. затем MDC ATTR TIME STAMP_BO.

М

Base-Offset-Time

См. стандарт IEEE 11073-20601-2014

R

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

М

Basic-Nu-Ob-served-Vatue

См. стандарт IEEE 11073-20601-2014

R

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

М

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

Иыя атрибута

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

Стандартная конфигурация tDev-Configuralion-id и Ох06С4)

Значение

Каап.

Значение

Коал

Measurement-Confidence- 95

См. текст ниже

О

См. текст ниже

NR

Threshold-Notification-Texl-String

См. текст ниже

О

См. текст ниже

NR

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

Примечание 2 — Описания квалификаторов см. в 6.3.

  • 6.7.2.1 Атрибут Measurement-confidence-95

Атрибут measurement-confidence-95 указывает верхнюю и нижнюю границы диапазона, в пределах которого изготовитель на 95 % уверен в том. что хранится действительное значение измерения. Нижняя и верхняя границы имеют те же единицы, что и измерение. Нижняя граница должна быть меньше или равна верхней границе.

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

Таблица 8 — Атрибут measurement-confidence-95 глюкозы

Имя атрибута

ID атрибута

Тип атрибута

Примечание

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

Measure-menl-Confi-dence-95

MDC ATTR MSMT CON-FIDENCE.95

MeasurementConfi-dence95

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

Нижняя и верхняя границы имеют те же единицы, что и измерение

Необязательный Наблюдаемый

Примечание 1 — Определения структуры АСН.1 см. в Приложении8.

  • 6.7.2.2 Атрибуты глюкозы threshold и status

Один атрибут расширяет числовой объект глюкозы и предоставляется с целью сообщения подробной информации о пороговых значениях глюкозы у агента, а второй атрибут сообщает, достигло ли измерение порогового значения либо вышло за него. Для обеспечения сообщения о статусе порогового значения атрибут Measurement-Status был расширен (совместим с ISO/IEEE 11073-10201:2004 [В8]) по сравнению с определением в стандарте IEEE 11073-20601-2014. Следует помнить, что объекты низких/ высоких пороговых значений пациента, а также нижнего и верхнего предела измерений прибора, описанные в 6.7.7 и 6.7.8 соответственно, хранят числовые пороговые значения глюкозы. Дополнительные детали см. в таблице 9.

Таблица 9 — Атрибуты глюкозы threshold и status

Иыя атрибута

10 атрибута

Тип атрибута

Примечание

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

Threshold-Notification-Text-String

MDC ATTR THRES NOT1F .TEXT.STRING

OCTET STRING

Текст, относящийся к текущему уведомлению о пороговом значении

Необязательный Наблюдаемый

Measurement-Status

MDC.ATTR_MSMT.STAT

Measurementstatus

Динамично отражает, находится ли наблюдаемое значение в пределах или за пределами границ пороговых значений. Если пороговые значения должны использоваться, этот атрибут обязателен. Используйте бит ms-mt-state-in-alarm {14) для указания, что измерение находится за пределами пороговых значений. Используйте msmt-state-al-inhib-ited(15) для указания, что индикация пороговых значений не работает и не должна вызывать отображаемое оповещение. Эти биты расширены по сравнению с определением атрибута Measurement-Status. приведенным в ИИЭР 11073-20601. Все остальные биты атрибута MeasurementSta-tus имеют те же определения. что в стандарте ИИЭР 11703-20601

Необязательный Наблюдаемый

Примечание —Определение отображения битое АСН.1 см. в приложении В.

  • 6.7.3 Калибровка датчика

Как было сказано выше, для калибровки CGM. как правило, требуется измерение уровня глюкозы. Это измерение может исходить от BGM. но их следует сохранять в памяти прибора непрерывного мониторинга глюкозы, чтобы иметь журнал выполненных калибровок. В таблице 10 приведены атрибуты числового объекта калибровки датчика.

Таблица 10 — Атрибуты числового объекта калибровки датчика

Имя атрибута

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

Значение

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

Туре

{MDC PART.PHD.DM. MDC.CGM.SENSOR.CAUBRATION}

M

Supplemental-Types

(MDC PART PHD DM. MDC CTXT GLU SAMPLELOCATION FINGER или MDC CTXT GLU SAMPLELOCATION AST. или MDC CTXT GLU SAMPLELOCATION EARLOBE, или MDC CTXT GLU SAMPLELOCATION SUBCUTANEOUS, или MDC CTXT GLU SAMPLELOCATJON UNDETERMINED, или MDC CTXT GLU SAMPLELOCATION OTHER} См. стандарт ИИЭР 11073-20601-2014

О

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

Имя атрибута

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

Значение

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

Melnc-Spec-Small

mss-avait-slored-data | mss-upd-aperiodx: | mss-acc-agent-indiated mss-cat-manuat | mss-cat-setting mss-cat-manuaf устанавливается лишь в том случае, если показания вводятся вручную

М

Measurement-Status

См. стандарт ИИЭР 11073-20601-2014 и текст ниже

R

Unit-Code

MDC.DIM. MILLI.G.PER.DL или MDC DIM MILLI MOLE PER L

М

Base-Offset-Time-Stamp

См. стандарт IEEE11073-20601-2014

R

Bas»c-Nu-Ob-served-Value

См. стандарт IEEE 11073-20601-2014

R

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

Примечание 2 — Описания квалификаторов см. в 6.3.

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

Рекомендуется использовать атрибут measurement-status. Этот атрибут используется для квалификации калибровки или предоставления дополнительных условий калибровки. Статус измерений invalid указывает, что CGM не откалиброван. Статус измерений vatidated-data указывает, что CGM был откалиброван.

Числовое значение калибровки датчика дополнительно определяется атрибутом supplemental-type. который указывает часть тела, используемую для калибровочных измерений глюкозы. Если место взятия проб не известно, то должно быть выбрано значение MDC.CTXT.GLU.SAMPLELOCATION. UNDETERMINED, а если место отбора проб отсутствует в предоставляемых кодах, то должно быть выбрано значение MDC.CTXT.GLU.SAMPLELOCATION.OTHER.

  • 6.7.4 Срок службы датчика

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

Таблица 11 —Атрибуты числового объекта срока службы датчика

Имя атрибута

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

Значение

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

Туре

(MDC PART PHD DM. MDC CGM SENSOR RUN

TIME}

M

Me trie- Spec-Small

mss-upd-aperiodic| mss-msmt-aperiodic | mss-acc-agent-ini-tiated | mss-cat-calculation | mss- avaii-stored-data | mss-cat-setting

Cm. IEEE 11073-20601-2014

M

Unit-Code

mdc_dim.hr

M

Base-Offset-Time-Stamp

Cm. стандарт IEEE 11073-20601-2014

R

Bastc-Nu-Observed- Value

См. стандарт IEEE 11073-20601-2014

r

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

Примечание 2 — Описания квалификаторов см. s 6.3.

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

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

  • 6.7.5 Интервал отбора проб глюкозы

Числовой интервал отбора проб глюкозы указывает частоту выполнения измерений глюкозы прибором CGM. В таблице 12 приведены атрибуты числового объекта интервала отбора проб глюкозы.

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

Имя атрибута

Значение

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

Туре

{MDC PART PHD DM. MDC CGM SENSOR SAMPLE INTERVAL}

M

Metric-Spec-Smalt

mss-upd-aperiodtc | mss-acc-agent-initiated | mss-avail-stored-data | mss-cat-manual | mss- cat-setting

См. стандарт ИИЭР 11073-20601-2014

M

Unit-Code

MDC.DIM.MIN

M

Base-Offset-Time-Stamp

См. стандарт IEEE 11073-20601-2014

R

Basic-Nu-Observed-Value

См. стандарт IEEE 11073-20601-2014

R

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

Примечание 2 — Описания квалификаторов см. в 6.3.

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

Числовым типом интервала отбора проб глюкозы служит DC_CGM_SENSOR_SAMPLE_INTERVAL, а атрибут unit-cods числового интервала отбора проб глюкозы представляет собой минуты.

  • 6.7.6 Тренд глюкозы

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

Таблица 13 —Атрибуты числового объекта тренда глюкозы

Имя атрибута

Значение

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

Type

{MDC.PART.PHD.DM | MDC.CONC.GLU.TREND}

M

Metric-Spec-Small

См. стандарт IEEE 11073-20601-2014

м

Unit-Code

MDC DIM MILLl G PER DL PER MIN или MDC DIM MIL-LI.MOLE_PER_L_PER.MIN

м

Base-Offset-Time-Stamp

См. стандарт IEEE 11073-20601-2014

R

Basic-Nu-Observed-Value

См. стандарт IEEE 11073-20601-2014

R

Threshold-Notification-Text-String

См. текст ниже

О

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

Примечание 2 — Описания квалификаторов см. в 6.3.

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

Числовым типом интервала отбора проб глюкозы служит MDC_CONC_GLU_TREND, а атрибут units-code имеет значение MDC_DIM_MH-LI_G_PER_DL_PER_MIN или MDC_DIM_MILLI_MOLE_ PER_L_PER_MIN, в зависимости от ситуации. Наблюдаемое значение представляет собой изменение измерений концентрации глюкозы в минуту.

  • 6.7.6.1 Атрибуты threshold и status тренда глюкозы

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

Для обеспечения сообщения о статусе порогового значения атрибут Measurement-Status был расширен (совместим с ISO/IEEE 11073-10201:2004 [В8]) по сравнению с определением в стандарте IEEE 11073-20601-2014. Следует помнить, что объекты пороговых значений скорости изменения (см. 6.7.9) хранят числовые пороговые значения скорости изменения глюкозы. Дополнительные детали см. в таблице 14.

Таблица 14 — Атрибуты threshold и status тренда глюкозы

Имя атрибута

IO атрибута

Тип атрибута

Примечание

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

Threshold-Notifica-tion-Text-String

MDC ATTR THRES NOTIF.TEXT.STRING

OCTET STRING

Текст, относящийся к текущему уведомлению о пороговом значении

Необязательный Наблюдаемый

Measurement-Status

MDC ATTR MSMT STAT

Measurement-Status

Динамично отражает, находится ли наблюдаемое значение 8 пределах или за пределами границ пороговых значений. Если пороговые значения должны использоваться. этот атрибут обязателен. Используйте бит msmt-state-m-alarm (14) для указания, что измерение находится за пределами пороговых значений. Используйте msml-state-al-inh»b-rted (15) для указания, что индикация пороговых значений не работает и не должна вызывать отображаемое оповещение. Эти биты расширены по сравнению с определением атрибута Measurementstatus приведенным в IEEE 11073-20601. Все остальные биты атрибута Measurement-Status имеют те же определения, что в стандарте IEEE 11073-20601

Условный Наблюдаемый

Примечание 1 — Определение отображения битов АСН.1 см. е приложении В.

  • 6.7.7 Нижние/верхние пороговые значения для пациента

Числовые нижние/верхние пороговые значения для пациента представляют собой параметры, используемые для указания диапазона концентрации уровня глюкозы, приемлемого для пациента. Если концентрация глюкозы выходит за рамки этого диапазона, то стандартной реакцией будет уведомление пациента и регистрация события в журнале. В таблице 15 приведены атрибуты числового объекта ниж-него/верхнего порогового значения для пациента.

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

Имя атрибута

Значение

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

Туре

(MDC PART PHD DM. MDC CONC GLU PATIENT THRESHOLDS.LOW.HIGH)

M

Metric-Spec-Small

См. стандарт IEEE 11073-20601-2014

M

Metric-Structure-Small

(ms-struct-compound-fix. 2) См. стандарт IEEE 11073-20601-2014

M

Metric-ld-bst

MDC CONC GLU PATIENT THRESHOLD LOW. затем

MDC.CONC.GLU.PATIENT.THRESHOLD.HIGH

M

Unit-Code

MDC DIM MILL! G PER DL или MDC DIM MILLI MOLE PER.L

M

Base-Offset-Time-Stamp

См. стандарт IEEE 11073-20601-2014

R

Compound-Basic-Nu-Ob-served-Vafue

См. стандарт IEEE 11073-20601-2014

R

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

Примечание 2 — Описания квалификаторов см. s 6.3.

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

Числовым типом нижних/верхних пороговых значений для пациента служит MDC_CONC_GLU_ PATIENT_THRESHOLDS_LOW_HIGH, а атрибут units-code имеет значение MDC.DIM.MILLI.G.PER. DL или MDC_DIM_MILLI_MOLE_PER_L. в зависимости от ситуации. Составное наблюдаемое значение атрибута нижнего/верхнего порогового значения для пациента должно содержать сначала нижнее пороговое значение. MDC_CONC_GLU_PATIENT THESHOLD.LOW, а затем верхнее пороговое значение. MDC_CONC_GLU_PATIENT.THESHOLD.HIGH.

  • 6.7.8 Критичный диапазон прибора

Числовой объект критичного диапазона прибора представляют собой параметр, указывающий критичный диапазон концентрации глюкозы. 8 таблице 16 приведены атрибуты числового объекта критичного диапазона прибора.

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

Имя атрибута

Значение

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

Type

(MDC PART PHD DM. MDC CONC GLU

THRESHOLDS.HYPO. HYPER}

M

Metric-Spec-Small

См. стандарт IEEE 11073-20601-2014

M

Metric-Structure-Small

(ms-slruct-oompound-fix. 2} См. стандарт IEEE 11073-20601-2014

M

Metric-ld-bst

MDC CONC GLU THRESHOLD HYPO, затем MDC.CONC.GLU.THRESHOLD.HYPER

M

Unit-Code

MDC DIM MILL! G PER DL или MDC DIM MILLI.MOLE.PER.L

M

Base-Offset-Time-Stamp

См. стандарт IEEE 11073-20601-2014

R

Com pound- Ba s*c-Nu- Observed-Value

См. стандарт IEEE 11073-20601-2014

R

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

Примечание 2 — Описания квалификаторов см. е 6.3.

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

Числовым типом критичного диапазона прибора служит MDC_CONC_GLU_PATIENT_ THRESHOLDS_HYPO_HYPER. а атрибут units-code имеет значение MDC_DIM_MILLI_G_PER_DL или MDC_DIM_MILLI_MOLE_PER_L, в зависимости от ситуации. Составное наблюдаемое значение атрибута критичного диапазона измерений прибора должно содержать сначала нижний предел диапазона. MDC_CONC_GLU_PATIENT_THESHOLD HYPO, а затем верхний предел. MDC.CONC.GLU PATIENT THESHOLD.HYPER.

  • 6.7.9 Пороговые значения скорости изменения глюкозы

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

Таблица 17 — Атрибуты числового объекта пороговых значений скорости изменения уровня глюкозы

Иыа атрибуга

Значение

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

Туре

(MDC PART PHD DM.MDC CONC GLU RATE THRESHOLDS)

М

Metric-Spec-Small

См. стандарт IEEE 11073-20601-2014

M

Metric-Structure-Small

(ms-slruct-compound-fix. 2} См. стандарт IEEE 11073-20601-2014

M

Metric-Id-List

MDC CONC GLU RATE THRESHOLD INCREASE, затем MDC CONC_GLU_RATE_THRESH OLD.DECREASE

M

Unit-Code

MDC DIM MILLI G PER DL PER MIN или MDC DIM MILLI mole per l per min

M

Base-Offset-Time-Stamp

См. стандарт IEEE 11073-20601-2014

R

Compound-Ba-sic-Nu-Observed-\telue

См. стандарт IEEE 11073-20601-2014

R

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

Примечание 2 — Описания квалификаторов см. в 6.3.

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

Числовым типом пороговых значений скорости изменения глюкозы служит MDC_CONC_GLU_ RATE_THRESHOLDS, а атрибут units-code имеет значение MDC_DIM_MILLI_G_PER_DL_PER_MIN или MDC_DIM_MILLI_MOLE_PER_L_PER_MIN. в зависимости от ситуации. Составное наблюдаемое значение атрибута пороговых значений скорости изменения глюкозы должно содержать сначала пороговое значение скорости повышения глюкозы. MDC_CONC_GLU_RATE_THRESHOLDJNCREASE. а затем пороговое значение скорости понижения глюкозы. MDC_CONC_GLU_RATE_THRESHOLD_DECREASE.

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

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

  • 6.9 Объекты перечислений

  • 6.9.1 Общие положения

CGM DIM (см. рисунок 2) содержит объекты перечислений, представляющие общий статус прибора. а также специфичный статус CGM. Класс перечисления идентифицируется номенклатурным кодом MDC_MOC_VMO_METRIC_ENUM. В подразделах 6.9.2 и 6.9.3 даются точные определения объектов перечисления общего и специфичного статуса CGM. В таблице 18 приведены общие атрибуты всех объектов перечислений.

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

Таблица 18 — Общие атрибуты объекта перечисления

Имя атрибута

Значение

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

НапсЯе

См. стандарт IEEE 11073-20601-2014

М

Туре

Определено 8 подразделах ниже

М

Supplemental-Types

См. стандарт IEEE 11073-20601-2014

О

Metric-Spec-Smalt

Определено в подразделах ниже

м

Metric-Structure-Small

См. стандарт IEEE 11073-20601-2014

о

Measurement-Status

См. стандарт IEEE 11073-20601-2014

с

Metric-td

См. стандарт IEEE 11073-20601-2014

о

Metric-Id-List

См. стандарт IEEE 11073-20601-2014

с

Mefric-ld-Partrtion

См. стандарт IEEE 11073-20601-2014

о

Unit-Code

См. стандарт IEEE 11073-20601-2014

о

Attnbute-Value-Map

См. стандарт IEEE 11073-20601-2014

с

Source-Handle-Reference

См. стандарт IEEE 11073-20601-2014

о

Label-String

См. стандарт IEEE 11073-20601-2014

о

Unit-LabelString

См. стандарт IEEE 11073-20601-2014

о

Absolute-Time-Stamp

См. стандарт IEEE 11073-20601-2014

с

Base-Offset-Time-Stamp

См. стандарт IEEE 11073-20601-2014

с

Relative-Time-Stamp

См. стандарт IEEE 11073-20601-2014

с

HiRes-Time-Stamp

См. стандарт IEEE 11073-20601-2014

с

Measure-Active-Period

См. стандарт IEEE 11073-20601-2014

о

Enum-Observed-Vatue-Simple-OID

См. стандарт IEEE 11073-20601-2014

с

Enum-Observed-Vahje-Simple-Bit-Str

См. стандарт IEEE 11073-20601-2014

с

Enum-Observed-Value-Basic-Bit-Str

См. стандарт IEEE 11073-20601-2014

с

Enum-Observed-Value-Simple-Str

См. стандарт IEEE 11073-20601-2014

с

Enum-Observed-Value

См. стандарт IEEE 11073-20601-2014

с

Enum-Observed-Value-Partxtion

См. стандарт IEEE 11073-20601-2014

О

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

Примечание 2 — Описания квалификаторов см. в 6.3.

  • 6.9.2 Статус PHD DM

Объект статуса PHD DM позволяет регистрировать общие события прибора, чтобы отслеживать важные для пользователя события и информацию по поиску неисправностей для изготовителей. 8 случае. если CGM представляет собой несколько физических приборов, например, датчик, передатчик или приемник, и эти события о статусе PHD DM регистрируются в агенте CGM для каждого физического прибора, то должен быть только один экземпляр объекта статуса PHD DM для каждого физического прибора, а для уточнения физического прибора должен использоваться атрибут Supplemental-Types.

Не должно быть двух объектов статуса PHD DM с тем же самым значением supplemental-type. В таблице 19 приведены определения атрибутов объекта, представляющего статус PHD DM. Объект перечисления статуса PHD DM может поддерживаться агентом CGM.

Таблица 19 — Атрибуты объекта перечисления статуса PHD

Имя атрибута

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

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

Туре

{MDC PART PHD DM. MDC PHD DM DEV STAT}

M

Supplemental-Types

(MDC PART PHD DM. MDC CGM DEV TYPE SENSOR или MDC CGM DEV TYPE TRANSMITTER, или MDC CGM DEV TYPE RECEIVER, или MDC CGM DEV TYPE OTHER}

См. стандарт 1ЕЁЁ 11073-20601-2014

R

Metric-Spec-Small

mss-avail-intermittent | mss-avail-stored-data | mss-upd-apenodic | mss-acc-agent-«nitiated | mss-acc- manager-initiated

М

Base-Offset-Time-Stamp

См. стандарт IEEE 11073-20601-2014

R

Enum-Observed-Value-Simple-Bit-Str

См. текст ниже

М

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

Примечание 2 — Описания квалификаторов см. в 6.3.

Наблюдаемое значение, сообщаемое в данном объекте, является общим статусом объекта.

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

Явное выражение существования оповещения реализуется с помощью установки соответствующего бита в атрибуте Enum-Observed-Value-Simple-Bit-Str в соответствии с определениями, приведенными в таблице 20. Если менеджер поддерживает данный объект, то он должен быть в состоянии интерпретировать весь набор представляемых состояний. Агенту не требуется реализовать все свойства. указанные в таблице 20. Когда изменяется статус какого-либо состояния, мониторинг которого выполняется, то агент должен сообщить статус всех мониторируемых состояний.

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

Если подходящего существующего бита нет. то должен использоваться биг device-status-undetermined. Менеджер должен интерпретировать эти биты только в контексте данного атрибута и только в рамках данной специализации прибора, поскольку другие специализации могут использовать соответствующие термины для других целей.

Таблица 20 — Отображение статуса PHD DM в атрибуте объекта Bit-Str

Бит

Услоеие статуса PKO ОМ

Мнемоника PHDDMSlat

0

Агент сообщает, что возникло не определенное, или не поддерживаемое состояние

device-status-undetermined

1

Агент сообщает, что возникла перезагрузка

device-status-reset

5

Агент сообщает, что возник общий отказ

device-status-error

6

Агент сообщает, что возник механический отказ

device-status-error-mechanical

7

Агент сообщает, что возник отказ электроники

device-status-error-electronic

в

Агент сообщает, что возникла ошибка программного обеспечения

device-status-error-software

9

Агент сообщает, что возник отказ батареи

device-status-error-battery

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

Бит

Условие статуса PHD DM

Мнемоника PHODMStal

15

Агент сообщает, что требуется общее обслуживание

device-status-service

16

Агент сообщает, что требуется синхронизация времени

device-slatus-servioe-tMTte-sync-required

17

Агент сообщает, что требуется калибровка

de vice-status-service-calibration-required

18

Агент сообщает, что требуется пополнение компонента

device-status-service-replenishment-required

25

Агент сообщает, что заряд батареи низкий

de vice-status-battery-tow

26

Агент сообщает, что батарея разряжена

device-status-battery-depleted

27

Агент сообщает, что батарея была заменена

de vice-status-battery-replaced

28

Агент сообщает, что батарея отсоединялась

device-status-battery-interrupted

Примечание 1 — Биты, перечисленные в таблице 20. имеют значения 0 = Нет (False) и 1 = Да (True).

Примечание 2 — Специфичные отображения битое PHDDMStat определены в Приложении В.

Примечание 3 — Все биты, не определенные 8 таблице 20 или Приложении В. зарезервированы для будущего использования.

  • 6.9.3 Статус CGM

Объект перечисления статуса CGM позволяет указать специфичный статус функционирования, состояния калибровки, уведомления, ошибки и т. д. для системы CGM. Данный объект перечисления отличается от статуса PHD DM. описанного в 6.9.2, поскольку предоставляет дополнительные коды статуса. специфичные для системы CGM. Объект перечисления удовлетворяет эту потребность. Если данный объект должен быть реализован, то тип объекта и присваивания битов должны быть реализованы в соответствии с описанием. В таблице 21 приведены атрибуты объекта перечисления статуса CGM.

Таблица 21 —Атрибуты статуса прибора для непрерывного мониторинга глюкозы

Имя атрибута

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

Значение

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

Type

(MDC_PART_PHD_DM. MDC_CGM_DEV_STAT)

M

Metric-Spec-Small

mss-avail-intermittent | mss-avail-stored-da-ta | mss-upd-aperiodic | mss-msmt-apenodw | mss-acc-agent-initiated

М

Base-Offset-Tme-Stamp

См. стандарт IEEE 11073-20601-2014

R

Enum-Observed-Vatue-Simple-Bit-Str

См. текст ниже

R

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

Примечание 2 — Описания квалификаторов см. в 6.3.

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

Агент явным образом выражает существование статуса CGM. устанавливая соответствующие биты в значении атрибута Enum~Obsarved-Value-Simple-BrtStr. как это описано в таблице 22. Рекомендуется использовать атрибут Enum-Observed-Value-Sirnple-Bft-Str, поскольку число имеющихся в данный момент вариантов статуса превышает то. что позволяет атрибут Enum-Observed-Valu&-Bas>c-Bit-Str. Следует помнить, что менеджер должен интерпретировать эти биты только в контексте данного атрибута и только в рамках данной специализации прибора, поскольку другие специализации могут использовать соответствующие термины для других целей.

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

Биг

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

Мнеисникл CGMSlat

0

Сеанс остановлен

sensoc-session-stopped

2

Тип датчика не лсдхсдит для прибора

sensor-type-incorrect

3

Неисправность датчика

sensor-malfunction

4

Предупреждение, специфичное для устройства

device-specific-alerl

7

Калибровка не разрешена

sensor-calibration-not-allowed

8

Рекомендована калибровка

sensor-calibration-recommended

9

Требуется калибровка

sensor-calibration-required

10

Температура датчика слишком высокая для получения действительного теста/результата на момент измерений

sensor-temp-loo-high

11

Температура датчика слишком низкая для получения действительного теста/результата на момент измерений

sensor-temp-too-low

12

Результат датчика мек*>ше нижнего порогового значения для пациента

sensor-resutt-below -patient-low

13

Результат датчика больше верхнего порогового значения для пациента

sensor-resuit-above-patienl-htgh

14

Результат датчика меньше нижнего предела критичного диапазона

sensor-low-hypo

15

Результат датчика больше верхнего предела критичного диапазона

sensor-high-hyper

16

Превышена скорость понижения глюкозы

sensor-rate-decrease-exceeded

17

Превышена скорость повышения глюкозы

sensor-rate-increase-exceeded

18

Результат датчика ниже уровня, который может обработать прибор

sensor-resutt-too-low

19

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

senscr-result-too-high

20

Коммуникация датчика за пределами диапазона

sensor-com-out-of-range

Примечание

1 — Биты, перечисленные в таблице 22. имеют значения 0 = Her (False) и 1 = Да (True).

Примечание

Примечание

2 — Специфичные отображения битов PHDDMStat определены в приложении В.

3 — Все биты, не определенные в таблице 22 или приложении В. зарезервированы для будущего использования.

  • 6.10 Объекты PM-store

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

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

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

Модель долговременного хранения реализуется с помощью объектов PM-store. Любая конфигурация. которая не имеет в своем составе объекта PM-store. для передачи наблюдений использует отчеты о событиях, инициируемые агентом. Использование временно хранящихся данных, определенное в стандарте IEEE 11073-20601*2014. является наиболее удобным вариантом для небольшого количества измерений, которые подлежат автоматическому удалению после загрузки.

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

  • 6.10.2 Модель длительного хранения

Модель PM-store. которая определяется в настоящем стандарте, использует один или несколько сегментов PM-segment для данных каждого объекта, подлежащего длительному хранению (см. в качестве примера рисунок 3). Если объект PM-store реализуется, то в нем должен присутствовать сегмент, содержащий измерения глюкозы. Другие сегменты являются необязательными и хранят наблюдения от реализованных поддерживающих объектов.

Каждая запись данных должна содержать в заголовке segm-entry-header время в одном из форматов. чтобы менеджер мог сопоставлять записи, хранящиеся в различных сегментах. Если конкретный объект не поддерживается, то соответствующий ему сегмент не требуется. Каждый сегмент имеет кратность нуль ко многим или один ко многим, поскольку требуется, чтобы сегменты PM-segment содержали данные для непрерывного периода времени (см. стандарт IEEE 11073-20601*2014). Поэтому изменение времени и/или даты на часах агента, как правило, приводит к созданию новых экземпляров сегментов для поддерживаемых объектов измерений или наблюдений. Далее агент CGM может подразделять данные одного непрерывного периода времени на несколько сегментов с целью дальнейшей кластеризации данных (например, один сегмент на сутки или на непрерывный период времени функционирования CGM). Если конкретный сегмент, создающийся в результате таких изменений времени/даты или объединений в кластеры, не содержит какие-либо записи, то его существование не требуется.

Следует помнить, что объект PM-store не является частью стандартной конфигурации, определенной в настоящем стандарте.

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

Рисунок 3 — Пример модели длительного хранения данных глюкометра непрерывного действия

  • 6.10.3 Атрибуты объекта PM-store

8 таблице 23 перечислены атрибуты объекта PM-store, реализуемого агентом. Объекты PM-store идентифицируются номенклатурным кодом MDC_MOC_VMO_PMSTORE.

Таблица 23 — Атрибуты объекта PM-store

Имя атрибута

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

Значение

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

Handle

См. стандарт IEEE 11073-20601-2014

М

PM-Store-Capab

См. стандарт IEEE 11073-20601-2014

М

Store-Sampte-AJgorithm

См. стандарт IEEE 11073-20601-2014

М

Store-Capacity-Count

См. стандарт IEEE 11073-20601-2014

М

Store-Usage-Count

См. стандарт IEEE 11073-20601-2014

М

Operational-State

См. стандарт IEEE 11073-20601-2014

М

PM-Store-Label

См. стандарт IEEE 11073-20601-2014

О

Sample-Period

См. стандарт IEEE 11073-20601-2014

NR

Number-Of-Segments

См. стандарт IEEE 11073-20601-2014

М

Clear-Timeout

См. стандарт IEEE 11073-20601-2014

М

В атрибуте PM-Store-Capab должны устанавливаться следующие биты:

  • – pmsc-var-no-of-segm:

Если агент создает новые сегменты для хранения данных нескольких сеансов или для учета переустановки времени, как это описано в разделе «Сопоставимое время» (Comparable time) стандарта IEEE 11073-20601-2014. то должен быть установлен бит pmsc-var-no-of-segm.

  • – pmsc-epl-seg-entries:

Бит pmsc-epi-seg-entries должен быть установлен.

• pmsc-peri-seg-entries:

Бит pmsc-peri-seg-entries не должен быть установлен.

Остальные биты атрибута PM-Store-Capab специфичны для конкретного агента и должны устанавливаться соответствующим образом.

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

Примечание 2 — Описания квалификаторов см. в 6.3.

  • 6.10.4 Методы объекта PM-store

8 таблице 24 приведены методы объекта PM-store.

Таблица 24 — Методы объекта PM-store

Сервис

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

Режим

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

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

Результаты (acbon-mfo-atgs)

ACTION

Clear-Segments

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

MDC ACT SEG.CLR

SegmSelection

Get-Segment-Info

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

MDC ACT SEG GETJNFO

SegmSelecbon

SegmenllnfoList

Trig-Segment-Da-ta-Xfer

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

MDC ACT SEG TRIG_XFER

TrigSegmDataX-ferReq

TrigSegmDataX-ferRsp

Clear-Segments

Этот метод позволяет менеджеру удалить все записи данных, хранящиеся в объекте PM-segment. Агент должен поддерживать метод Clear-Segments. устанавливая бит pmsc-ciear-segm-by-all-sup атрибута PM-Store-Capab. Этот метод не гарантирует удаление сегментов PM-segment. См. стандарт IEEE 11073-20601-2014 а части информации о том. что должен ответить агент в том случае, если он решает защитить определенные сегменты от удаления.

Get-Segment-Info

Этот метод позволяет менеджеру извлечь атрибуты объекта PM-segment.

Tng-Segment-Data-Xfer

Этот метод позволяет менеджеру инициировать передачу записей данных, хранящихся е объекте PM-segment. Подробную информацию см. в стандарте IEEE 11073-20601*2014.

  • 6.10.5 События объекта PM-store

В таблице 25 приведены определения событий, передаваемых объектами PM-store.

Таблица 25 — События объекта PM-store

Сервис

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

Режим

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

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

Результаты (event-reply нп to)

EVENT REPORT

Segment-Data-Event

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

MDC NOTI SEO-MENT.DATA

SegmentData-Event

SegmentDataResult

Segment-Data-Event

Это событие позволяет агенту передать записи данных, хранящиеся в объекте PM-segment. Оно инициируется менеджером с использованием действия Tng-Segment-Data-Xfer. Подробную информацию см. в стандарте IEEE 11073-20601-2014.

  • 6.10.6 Сервисы объекта PM-store

  • 6.10.6.1 Сервис GET

Сервис GET должен предоставляться агентом, реализующим объекты PM-store. Данный сервис должен быть доступен только в том случае, когда агент находится в состоянии «Выполнение» (Operating). Подробную информацию см. в стандарте IEEE 11073-20601-2014.

  • 6.10.6.2 Сервис SET

В настоящем стандарте сервисы SET для объектов PM-store не определены.

  • 6.10.7 Объекты PM-segment

В таблице 26 определены атрибуты объекта сегмента PM-segment. создаваемого для периодического сеанса и содержащегося в периодическом объекте PM-store, управляющем хранящимися измерениями или наблюдениями. Класс PM-segment идентифицируется номенклатурным кодом MDC МОС PM SEGMENT.

Таблица 26 — Общие атрибуты объекта PM-segment

Имя атрибута

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

Значение

Кмпификатор

Instance-Number

См. стандарт IEEE 11073-20601-2014

М

PM-Segment-Entry-Map

См. стандарт IEEE 11073-20601-2014

М

PM-Seg-Per son-id

См. стандарт IEEE 11073-20601-2014

С

Operational-State

См. стандарт IEEE 11073-20601-2014

М

Sample-Period

См. стандарт IEEE 11073-20601-2014

С

Segment-Label

См. стандарт IEEE 11073-20601-2014

О

Segment-Start-Abs-Time

См. стандарт IEEE 11073-20601-2014

С

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

Имя атрибута

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

Значение

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

Segment-End-Abs-Time

См. стандарт IEEE 11073-20601-2014

С

Date-and-Tme- Adjustment

См. стандарт IEEE 11073-20601-2014

С

Segment-Start-BO-Time

См. стандарт IEEE 11073-20601-2014

С

Segment-End-BO-Time

См. стандарт IEEE 11073-20601-2014

С

Segment-Usage-Count

См. стандарт IEEE 11073-20601-2014

М

Segment-Stabsbcs

См. стандарт IEEE 11073-20601-2014

О

Fixed-Segment-Data

Данные сегмента, передаваемые как массив записей в формате, указанном в атрибуте PM-Segment-Entry-Map

М

Confirm-Timeout

См. стандарт IEEE 11073-20601-2014

О

Transfer-Timeout

См. стандарт IEEE 11073-20601-2014

М

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

Примечание 2 — Описания квалификаторов см. е 6.3.

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

  • 6.11 Объекты класса Scanner

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

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

8 этом стандарте нет объектов расширения класса, определенных в соответствии со стандартом IEEE 11073-20601-2014.

  • 6.13 Правила расширения информационной модели CGM

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

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

7 Сервисная модель глюкометра непрерывного действия

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

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

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

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

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

  • * Сервис GET: используется менеджером для извлечения значений из системы медицинского прибора агента и атрибутов объекта PM-store. Слисок атрибутов объекта системы медицинского прибора CGM приведен в 6.6.4.1. а список атрибутов PM Store CGM приведен в 6.10.3.

  • * Сервис SET: используется менеджером для установки значений атрибутов объекта агента. Настоящий стандарт не определяет никакие настраиваемые атрибуты для агента CGM.

– Сервис отчетов о событиях: используется агентом для передачи менеджеру отчетов о конфигурациях. а также данных измерений. Список отчетов о событиях для специализации прибора CGM приведен в 6.6.3.

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

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

Таблица 27 — Сервисы доступа к объекту прибора непрерывного мониторинга глюкозы

Сервис

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

Режим

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

Параметры

Результат

Примечание

GET

«подразумеваемое подтверждение*

GetArgumentSim-pie = (obj-handle = 0). attribute-id- list «необязательный*

Get Result-Simple = (obj-handte = 0). attribute- list

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

«подразумеваемое подтверждение*

GetArgumentSim-ple = (obj-handle = дескриптор объекта PM- store). attribute-id-list «необязательный*

GetResult-Simple = (obj-handte = дескриптор объекта PM-store). attribute-list

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

EVENT REPORT

MDS-Configuration -Event

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

MDC NOT1 CONFIG

ConfigReport

ConftgRepor-tRsp

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

MDS-Dy-namic-

Data-Up-date-Var

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

MDC NOT1 SCAN RE PORT

VAR

ScanReportlnfo\tar

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

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

Сервис

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

Режим

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

Параметр»

Результат

Примечание

EVENT REPORT

MDS-Dynamtc-Data-Updale-Fixed

Подгеерждаемьм

MDC

NOTI SCAN RE

PORT

FIXEO

ScanReportinfoFixed

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

MDS-Dynamic-Data-Up-date-MP-Var

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

MDC NOTI SCAN RE PORT MP.VAR

ScanReportlnfo-MPVbr

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

MDS-Dy-namic-Data-Up-date-MP-Fixed

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

MDC NOTI SCAN REPORT MP FIXED

ScanReportlnfo-MPFixed

То же самое, что и MDS-Dynarrbc-Da-ta-Update-Fixed. но позволяет включить данные от нескольких лиц

Segment-Data-Event

Подтверждаешь»

MDC NOTI SEGMENT DATA

SegmentDataEvent

SegmentData-Result

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

ACTION

Set-Time

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

MDC ACT SET TIME

SetTimelnvoke

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

Set-Base-Offset-Time

Подтверждаешь»

MDC ACT SET BO.TI ME

SetBOTmelnvoke

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

Clear-Segments

Подтверждаешь»

MOC ACT SEG.CLR

SegmSetection

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

Get-Seg-ment-lnfo

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

MDC ACT SEG GET INFO

SegmSelection

SegmentlnfoList

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

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

Сервис

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

Режим

Тил суб-сервиса

Параметры

Результат

Примечание

Trig-Segment-Data-ХГег

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

MDC ACT SEG TRIG” xfer”

TrigSegmDataXfer-Req

TrigSegmData-XferRsp

Позволяет менеджеру инициировать передачу атрибута Ftxed-Segment-Dala сегмента РМ-segment агента

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

Сервис отчета о событии (event report, см. таблицу 27) используется агентом для передачи его информации (например, измерений). Согласно настоящему стандарту, отчеты о событиях являются свойством системы медицинского прибора (см. таблицу 4). а также объекта PM-store (см. таблицу 25). Отчеты о событиях, используемые в настоящем стандарте, определены в стандарте IEEE 11073-20601-2014.

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

  • * Отчеты о событиях MDS должны использоваться в подтверждаемом режиме.

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

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

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

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

Менеджер должен поддерживать отчеты о событиях и по одному лицу, и по нескольким лицам. Агент CGM может поддерживать один или оба типа отчетов о событиях (по одному лицу и по нескольким лицам). Форматы отчетов по одному лицу и нескольким лицам описаны в стандарте IEEE 11073* 20601*2014.

8 Коммуникационная модель глюкометра непрерывного действия

  • 8.1 Обзор

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

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

  • 8.2 Характеристики коммуникации

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

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

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

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

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

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

Если не заявлено иное, то в соответствии с настоящим стандартом процедура ассоциации агента и менеджера CGM выполняется, как это указано в стандарте IEEE 11073-20601-2014.

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

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

  • – Версия процедуры ассоциации, используемая агентом, должна иметь значение a$$oc-ver$ion1 (т, е. assoc-version – 0x80000000).

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

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

  • 1) Агент должен поддерживать protocol-version2. Поддержка любой другой версии может быть указана с помощью установки дополнительных битов. Когда используются протоколы выше protocol-version2, то агент должен продолжать использование только тех свойств, которые указаны в настоящем стандарте. Когда используются протоколы ниже protocol-version2. то агент должен использовать только свойства, определенные в этом протоколе.

  • 2) По меньшей мере должны поддерживаться правила кодирования MDER (т.е. encoding-rules -= 0x8000).

  • 3) Версия используемой номенклатуры должна иметь значение nom-version1 (т.е. nomendature-version – 0x80000000).

  • 4) Поле functional-units может иметь установленными биты тестовой ассоциации, но не должно иметь каких-либо других установленных битов.

  • 5) Поле system-type должно иметь значение sys-type-agent (т.е. system-type – 0x00800000).

  • 6) Поле system-id должно иметь значение атрибута System-Id объекта системы медицинского прибора агента. Менеджер может использовать это поле для определения идентичности CGM. с которым он ассоциируется, а также необязательно для реализации простой политики ограничения доступа.

  • 7) Поле dev-config-id должно иметь значение атрибута Dev-Configuration-ld объекта системы медицинского прибора агента.

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

  • 9) Если агент поддерживает только специализацию CGM. то data-feq-init-manager-count должен иметь значение 0. a data-req-init-agent-count — значение 1.

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

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

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

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

  • – Поле data-proto-info заполняется структурой PhdAssociationlnformation. содержащей следующие значения параметров:

  • 1) Менеджер, следующий данной специализации, должен поддерживать protocol-versk>n2. Менед* жер может поддерживать дополнительные версии протокола и выбирать их. если агент их предлагает.

  • 2) Менеджер должен отвечать с помощью одного выбранного правила кодирования, которое поддерживается агентом и менеджером. Менеджер должен поддерживать по меньшей мере правила кодирования MDER.

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

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

  • 5) Поле system-type должно иметь значение sys-type-manager (т. е. system-type – 0x80000000).

  • 6) Поле system-id должно содержать уникальный системный идентификатор менеджера, который должен быть действительным идентификатором типа EUI-64.

  • 7) Поле dev-config-id должно иметь значение manager-config-response (0).

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

  • 9) Если агент поддерживает только специализацию CGM. то data-req-initagent-count должен иметь значение 1. a data-req-init-manager-count должен иметь значение 0.

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

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

Агент переходит в состояние «Конфигурирующий» (Configuring), если получает ответ на запрос ассоциации accepted-unknown-config. В этом случае должна выполняться процедура конфигурирования, определенная в стандарте IEEE 11073-20601-2014. В подразделе 8.4.2 описаны сообщения уведомления о конфигурации и ответа для агента CGM. имеющего идентификатор стандартной конфигурации 2500 (0х09С4). Как правило, менеджер уже должен знать стандартную конфигурацию. Однако в данном примере предполагается, что он ее не знает.

  • 8.4.2 CGM — стандартная конфигурация (0х09С4)

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

Агент выполняет процедуру конфигурирования, используя для отправки своей конфигурации менеджеру сообщение «Remote Operation Invoke | Confirmed Event Report» о событии MDC_NOTI_CONFIG (см. стандарт IEEE 11073-20601-2014). Для поля event-info используется структура ConfigReport (см. таблицу 4). Для агента CGM с идентификатором стандартной конфигурации 2500 (ОхО9С4) формат и содержание сообщения уведомления о конфигурации будут следующими:

0хЕ7

0x00

ТипАРОи CHOICE (PrstApdu)

0x00

0x50

CHOICE.Iength – 80

0x00

0х4Е

OCTET STRING.Iength = 78

0x00

0x02

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

0x01

0x01

CHOICE(Remote Operation Invoke | Confirmed Event Report)

0x00

0x48

CHOICE.Iength = 72

0x00

0x00

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

OxFF

OxFF

OxFF

OxFF

event-time (устанавливается равным OxFFFFFFFF, если RelativeTime не поддерживается)

0x00

0x1 С

event-type = MDC_NOTI_CONFIG

0x00

ОхЗЕ

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

0x09

0хС4

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

0x00

0x01

config-obj-list.count = 1 будет «объявлен» объект Measurement

0x00

0x38

config-obj-list.tength = 56

0x00

0x06

obj-class = MDC_MOC_VMO_METRIC_NU

0x00

0x01

obj-handle = 1 (1-е измерение — глюкоза)

0x00

0x05

attributes.count = 5

0x00

0x30

attributes.length = 48

0x09

0x2F

attribute-id = MDC_ATTR_ID_TYPE

0x00

0x04

attribute-value.length = 4

0x00

0x02

0x71

0xD4

MDC.PART.SCADA | MDC_CONC_GLU_ISF

ОхОА

0x61

attribute-id = MDC_ATTR_SUPPLEMENTAL_TYPES

0x00

0x08

attribute-value.length – 8

0x00

0x01

SupptementalTypeList. count = 1

0x00

0x04

SupplementalTypeList. length = 4

0x00

0x80

0x72 0x39

MDC PART PHD DM | MDC CTXT GLU SAMPLELOCATION SUBCUTANEOUS

ОхОА

0x46

attribute-id = MDC_ATTR_METRIC_SPEC_SMALL

0x00

0x02

attribute-value.length – 2

ОхСО

0x42

mss-avail-intermittent, mss-avail-stored-data. mss-acc-agent-initiated. mss-cat-calculation

0x09

0x96

attribute-id = MDC_ATTR_UNIT_CODE

0x00

0x02

attribute-value.length = 2

0x08

0x52

MDC_DIM_ MILLI.G.PER DL

ОхОА

0x55

attribute-id = MDC_ATTR_ATTRIBUTE_VALUE_MAP

0x00

ОхОС

attribute-value.length = 12

0x00

0x02

AttrValMap.count = 2

0x00

0x08

AttrValMap. length = 8

ОхОА

0х4С

0x00 0x02

MDC_ATTR NU_VAL_OBS_BASIC | value length = 2

ОхОА

0x82

0x00 0x08

MDC_ATTR_TIME_STAMP_BO | value length = 8

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

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

0xE7

0x00

0x00

0x16

0x00

0x14

0x00

0x02

0x02

0x01

0x00

OxOE

0x00

0x00

0x00

0x00 0x00 0x00

OxOD 0x00 0x09 0x00

0x1C 0x04 0x04 0x00

APDU CHOICE Type (PrstApdu)

CHOICE.length = 22

OCTET STRING.length = 20 invoke-id (отличает это сообщение от любых других) CHOICE (Remote Operation Response | Confirmed Event Report) CHOICE.length = 14 obj-handle – 0 (объект MOS) currentTIme = 0 event-type = MDC_NOTI_CONFIG event-reply-info.length – 4 ConfigReportRsp.config-report-id – 2500 ConfigReportRsp.config-resutt – accepted-config

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

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

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

  • 8.5.2 Атрибуты сервиса GET системы медицинского прибора CGM

Краткий обзор сервиса GET см. в таблице 5.

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

Если менеджер запрашивает специфичные атрибуты объекта системы медицинского прибора, указанные в элементах поля attribute-id-list, и агент поддерживает эту возможность, то агент CGM отвечает сообщением сервиса rors-cmip-get. в котором поле attribute-list содержит список тех запрошенных атрибутов объекта системы медицинского прибора, которые реализованы. Не требуется, чтобы агент CGM поддерживал эту возможность. Если она не реализована, то агент CGM отвечает, как это указано в разделе стандарта IEEE 11073-20601-2014. посвященном атрибутам объекта системы медицинского прибора.

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

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

Чтобы ограничить количество данных, передаваемых в блоке APDU. агент CGM не должен включать в отчет об одном событии более 25 временно хранящихся измерений. Если для передачи имеются более 25 измерений, то они должны быть переданы с использованием отчетов о нескольких событиях. Если имеется несколько измерений глюкозы, то вплоть до 25 измерений следует передать в отчете об одном событии. Как альтернатива, они могут быть переданы, используя отчет об одном событии для каждого измерения глюкозы. Однако в целях уменьшения общей длины сообщений и расхода производительности рекомендуется использовать предыдущую стратегию.

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

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

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

Тестовые ассоциации (Test Association) предоставляет изготовителю механизм тестирования или комплексной демонстрации свойств продукта. В этом разделе определяется поведение стандартного агента CGM в процессе тестовой ассоциации. Поддержка тестовой ассоциации не обязательна.

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

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

В течение 30 с после входа в состояние «Выполнение» (Operating) агент должен передать одно имитируемое измерение глюкозы 999 мг/дл (значение, никогда не появляющееся при нормальной работе и находящееся за пределами диапазона нормы). Если атрибут measurement-status числового объекта реализован, то должен быть установлен бит test-data.

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

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

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

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

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

Настоящий стандарт должен использоваться вместе со стандартом IEEE 11073-20601-2014. Реализация или система может соответствовать следующим элементам настоящего стандарта:

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

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

  • • модели протоколов и сервисной модели;

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

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

8 настоящем стандарте предлагаются уровни соответствия по отношению к строгому соблюдению требований к стандартному прибору, а также к использованию следующих расширений;

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

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

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

Спецификации предоставляются в форме набора заявлений о соответствии реализации (implementation conformance statement, ICS), как это детализировано в 10.4.

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

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

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

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

  • 10.3.2 Уровень соответствия 1: базовое соответствие

В приложении используются элементы информационной модели, сервисной модели и коммуникационной модели (иерархия объекта, действия, отчеты о событиях, а также определения типов данных), а также номенклатурная схема, определенная в стандартах IEEE 11073-20601-2014 и ISO/IEEE 11073-10422. Реализованы все обязательные свойства, приведенные в таблицах определений объектов, а также в таблице заявлений о соответствии реализации. Кроме того, любые условно обязательные, рекомендованные или необязательные реализованные свойства должны отвечать требованиям стандартов IEEE 11073-20601-2014 и ISO/IEEE 11073-104ZZ.

  • 10.3.3 Уровень соответствия 2: расширенная номенклатура (АСН.1 и/или ISO/1EEE 11073-10101:2004 [86])

Уровень соответствия 2 удовлетворяет уровню соответствия 1. но также использует или добавляет расширения по меньшей мере в одной из моделей (информационную, сервисную, коммуникационную, номенклатурную). Расширения номенклатурных кодов должны соответствовать положениям стандарта ИСО/ИИЭР 11073*10101:2004 [В6] и располагаться в диапазоне местных расширений номенклатуры (OxFOOO — OxFFFF).

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

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

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

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

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

Индекс

Свойство

Ссылка

Зэпрос/Статус

Поддержка

Комментарии

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

– индекс: идентификатор (например, метка) специфичного свойства.

  • * Свойство: кратко описывает характеристики, для которых было сделано заявление о соответ* ствии.

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

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

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

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

В 10.4.2—10.4.6 указаны форматы конкретных таблиц Заявления о соответствии реализации.

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

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

Таблица 28— IEEE 11073-10425, таблица общих заявлений о соответствии реализации

Индекс4

Свойство

Ссыпка

Залрос/Статус

Поддержка

(оиыентарми

GEN11073-10425-1

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

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

GEN11073-10425-2

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

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

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

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

GEN11073-10425-3

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

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

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

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

GEN11073-10425-4

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

См.10.3.3

Базовая декларация соответствия о том. что прибор выполняет следующие требования соответствия стандарту IEEE 11073-10425:

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

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

Да/Нет («Нет» не предполагается. поскольку «Нет» подразумевает. что реализация не соответствует требованиям)

GEN11073-10425-5

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

См. 6.3

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

Да/Нет

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

Инде«са

Свойство

Ссылке

Запрос/Статус

Поэдержка

Комментарии

GEN11073-10425-6

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

См. 6.3

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

GEN11073-10425-7

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

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

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

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

GEN11073-10425-8

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

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

GEN11073-10425-9

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

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

Да/Нет

(Если «да», то объяснить е таблице 29)

GEN11073-10425-10

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

Использует ли реагмза-ция местные расширения номенклатуры (т.е. ходы OxFOOO-OxFFFF из ISO/ IEEE 11073-10101:2004 [В6])? Местные расширения номенклатуры разрешены лишь в том случае, если стандартная номенклатура не содержит специфичные термины, требуемые приложена

Да/Нет (Если «да»: объяснить в Таблице 32)

GEN11073-

10425-11

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

11073-20601

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

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

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

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

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

Индекс

Свойство

Ссыпка

Запрос/Ctaiyc

Поддержка

Комментарии

МОС-л

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

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

Реализован

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

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

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

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

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

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

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

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

Индекс

Свойство

Ссылка

Запрос/Статус

Поддержка

Комментарии

ATTR-

л-х

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

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

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

С = Conditional (условно обязательный)/

R = Recommended (рекомендуемый)/

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

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

Реализован? Да/Нет Статический/Динэмический Указать ограничения (например. диапазоны значений). Описать, как осуществляется доступ к атрибуту (например. Get. Set. передается в отчете о событии конфигурирования. передается в отчете о событии с данными). Описать любые специфичные ограничения

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

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

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

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

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

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

Индекс

Свойство

Ссылка

Запрос/ Статус

Поддержка

Комментарии

NOTkn-x

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

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

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

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

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

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

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

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

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

Индекс

Свойство

Ссылка

Эапрос/Статус

Поддержка

Комментарии

NOME-л

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

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

Описывает, как используется номен

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

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

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

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

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

(В1] IEC 60601-1:2005, Ed. 3. Medical electrical equipment — Part 1: General requirements for basic safety and essential performance (Из. 3. Изделия медицинские электрические. Часть 1. Общие требования безопасности с уметом основных функциональных характеристик)’

(В2] IEC 60601-2. Medical electrical equipment — Part 2: Particular requirements for the basic safety and essential performance for specific device (See the entire series of standards. Part 2-1 through Part 2-51) (Изделия медицинские электрические. Часть 2. Частные требования к безопасности с учетом основных функциональных характеристик специального оборудования (См. всю серию стандартов. Часть 2-1 до Часть 2-5t))

[ВЗ] IEC 62304:2006/EN 62304:2006. Medical device software — Software hfe cycle processes (Изделия медицинские. Программное обеспечение. Процессы жизненного цикла)2

(B4J IEC 80001-1:2010, Appbcation of risk managemwit for IT-networks incorporating medical devices — Part 1: Roles, responsibilities, and activities (Информатизация здоровья. Менеджмент рисков в информационно-вычислительных сетях с медицинскими приборами. Часть 1. Роты, ответственности и действия)

(B5J ISO 14971:2007, Medical devices — Application of risk management to medical devices (Изделия медицинские. Применение менеджмента риска к медицинским изделиям)3

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

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

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

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

Публикации МЭК ЕСможно получить в Международной электротехнической комиссии (http7Avww.iec.ch/). Публикации МЭК также можно получить в США в Американском национальном институте стандартов (htlp7Avww. ansi.org/).

Публикации ЕН по европейским стандартам можно получить в Европейском комитете по стандартизации (СЕН) (http://www.cen.eu/).

Публикации ИСО можно получить в Центральном секретариате ИСО (http7Zwww.iso.org/). Публикации ИСО также можно получить в США в Американском национальном институте стандартов ((http7Zwww.ansi.org/).

Публикации ISO/IEEE можно получить в Центральном секретариате ИСО. 1. ch. de la Voie-Creuse. Case Postale 56, CH-1211, Geneva 20. Switzerland (http://www.iso.ch/). Публикации ISO/IEEE также можно получить в Институте инженеров по электротехнике и радиоэлектронике (http7Zstandards.ieee.org/).

Публикации МСЭ можно получить в Международном союзе электросвязи (http://www.itu.int/). Данную спецификацию можно найти по адресу htlp7/www.itu.int/lTU-T/studygroups/com17/languages/X.680-0207.pdf.

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

Дополнительные определения АСН.1

В.1 Статус PHD DM. статус CGM. а также отображения битов статуса измерений

Расширение класса перечислений для статуса PHD DM требует следующего определения структуры в нотации АСН.1:

PHDDMStal ::= BITS-32 ( device-status-undetermmed (0). device-status-reset (1).

  • – зарезервирован для будущего расширения (2).

  • – зарезервирован для будущего расширения (3).

  • – зарезервирован для будущего расширения (4). device-status-error (5).

device-status-error-mechanical (б), device-status-error-electronic (7). device-status-error-software (8). device-status-error-battery (9).

  • – зарезервирован для будущего расширения (10).

  • – зарезервирован для будущего расширения (11).

  • – зарезервирован для будущего расширения (12).

  • – зарезервирован для будущего расширения (13).

  • – зарезервирован для будущего расширения (14). device-status-service (15).

device-status-service-time-sync-required (16) device-status-service-catibration-required (17). device-status-service-reptenishment-required (18).

  • – зарезервирован для будущего расширения (19).

  • – зарезервирован для будущего расширения (20).

  • – зарезервирован для будущего расширения (21).

  • – зарезервирован для будущего расширения (22).

  • – зарезервирован для будущего расширения (23).

  • – зарезервирован для будущего расширения (24). device-status-battery-low (25).

device-status-batlery-depleted (26).

device-status-battery-repiaced (27). device-status-battery-inten’upted (28).

  • – зарезервирован для будущего расширения (29).

  • – зарезервирован для будущего расширения (30).

  • – зарезервирован для будущего расширения (31)

)

Объект перечисления для статуса CGM требует следующего определения структуры в нотации АСН. 1: CGMStat::= BITS-32 { sensor-session-stopped(O). sensor-type-incorrect(2).

sensor-maKunction(3).

device- specific-atert(4),

sensor-calibration-not-allowed(7).

sensor-calibration -recommended(8).

sensor-calibration-requked(9). sensor-temp-too-high( 10). sensor-temp-loo-low( 11). sensor-result-below-pa tient-low( 12). sensor-result-above-patient-h*gh(13),

sensor-low-hypo( 14), sensor-h»gh-hyper( 15).

sensor-rate-decreasB-exceededf 16).

sensor-rate-increase -exceeded( 17). sensor-result-too-low( 18).

sensor-result-too-high( 19).

sensor-com-out-of-range(20)

}

Расширение атрибута Metric Measurement-Status требует следующего определения структуры а нотации АСН.1;

MeasurementstatusBITS-16{

invalid(O).

questionable^).

not-availabie(2).

calibration -ongoing(3).

tsst-data(4).

demo-data(5).

validatsd-data{8).

early-indicabon(9).

msmt-ongoing(IO), msmt-state-in-alarm( 14). msmt-slate-al-inhitxted{ 15} }

B.2 Числовое расширение для доверия к измерению

Расширения объекта глюкозы, характеризующие доверие к измерению, требуют следующего определения структуры в нотации АСН.1:

  • – Атрибут Measurement-Confidence-95 определяет нижнюю и верхнюю границы диапазона.

  • – в котором изготовитель на 95 % уверен, что значения измерений действительны

•• Примечание — Единица измерения для нижних и верхних границ та же, что и для измерений.

MeasurementConfidence95 ::= SEQUENCE {

lower-bound SFLOAT-type.

upper-bound SFLOAT-type

}

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

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

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

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

С.2 Определение терминов и кодов

Использованная ниже форма позаимствована из стандарта ISO/IEEE 11073-10101:2004 (B6J.

I……………………………………………………………………………………*…………………

  • * Из блока «Коммуникационная инфраструктура» (MDC_PART_INFRA)

•***•’*………………………………………………*………….*”…………………………………../

«define MDC_DEV_SPEC_PROFILE_CGM 4122 I* Профиль специализации глюкометра непре

рывного действия*/

г-………………………-……..**…………….*………………………………*………………….

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

…………*…..*……*……*……………*………………………….*…………….. I

«define MDC.CONC.GLU.CAPILLARY.WHOLEBLOOD

29112

Г Концентрация глюкозы

в капиллярной цельной крови */

«define MDC.CONC.GLU.CAPILLARY.PLASMA

29116

Г Концентрация глюкозы

в калилярной плазме 7

«define MDC_CONC_GLU_VENOUS_WHOLEBLOOD

29120

Г Концентрация глюкозы

8 венозной цельной крови 7

«define MDC_CONC_GLU_VENOUS_ PLASMA

29124

Г Концентрация глюкозы

в венозной плазме 7

«define MDC_CONC_GLU_ARTERIAL_WHOLEBLOOD

29128

Г Концентрация глюкозы

в артериальной цельной крови 7

«define MDC_CONC_GLU_ARTER1AL_ PLASMA

29132

Г Концентрация глюкозы

в артериальной плазме 7

«define MDC.CONC.GLU.CONTROL

29136

Г Концентрация глюкозы

в контрольном растворе 7 «define MDC_CONC_GLU_ISF

29140

Г Концентрация глюкозы

в тканевой жидкости*/

«define MDC_CONC_GLU_UNDETERMlNED_WHOLEBLOOD

29292

Г Концентрация глюкозы

в не определенной цвгъной крови */

«define MDC.CONC.GLU.UNDETERMINED. PLASMA

29296

Г Концентрация глюкозы

в не определенной плазме 7

* Из блока «Управление заболеванием с помощью персонального медицинского прибора» (MDC_PART_PHD DM)

«define MDC_PHD_DM_DEV_STAT

20000

1

Г Общее управление

заболеванием с помощью ПМП. Статус прибора */

«define MDC.CTXT.GLU.SAMPLELOCATION.UNDETERMINED

29237

Г Контекст измерения

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

«define MDC_CTXT_GLU_SAMPLELOCATION_OTHER

29238

/* Контекст измерения

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

определить DC_CTXT_GLU_SAMPLELOCATION_FINGER

29240

/* Контекст измерения

глюкозы, указывающий, что место взятия проб — палец*/

«define MDC.CTXT.GLU.SAMPLELOCATION.SUBCUTANEOUS

29241

Г Контекст измерения

глюкозы, указывающий, что место взятия проб — подкожное6/ «define MDC.CTXT_GLU_SAMPLELOCAT1ON.AST

29244

Л Контекст измерения

глюкозы, указывающий, что место взятия проб — альтернативное */

«define MDC.CTXT.GLU.SAMPLELOCATION.EARLOBE

29248

Л Контекст измерения

глюкозы, указывающий, что место взятия проб — мочка уха’/ «define MDC.CTXT.GLU.SAMPLELOCATION.CTRLSOLUTION

29252

Л Контекст измерения

глюкозы, указывающий, что место взятия проб — контрольный раствор 6/

«define MDC.CONC.GLU.TREND

29400

Л Выявление тренда

концентрации глюкозы Ч

«define MDC.CONC_GLU_PAT1ENT_THRESHOLDS_LOW.HIGH

29404

Л Нижнее и верхнее

пороговое значение концентрации глюкозы для пациента 7 «define MDC.CONC_GLU_PAT1ENT_THRESHOLD.LOW

29405

Л Нижнее пороговое

значение концентрации глюкозы для пациента 7 «define MDC_CONC_GLU_PAT1ENT_THRESHOLD_HIGH

29406

Л Верхнее пороговое

значение концентрации глюкозы для пациента 7 «define MDC.CONC.GLU.THRESHOLDS.HYPO.HYPER

29408

Л Критичный

диапазон концентрации глюкозы 7 «define MDC.CONC.GLU.THRESHOLD.HYPO

29409

Л Нижнее

критичное значение концентрации глюкозы6/ «define MDC.CONC.GLU.THRESHOLD.HYPER

29410

Л Верхнее

критичное значение концентрации глюкозы6/ «define MDC.CONC.GLU.RATE.THRESHOLDS

29412

Л Пороговые значения

скорости изменения концентрации глюкозы6/

«define MDC.CONC.GLU.RATE.THRESHOLD.INCREASE

29413

Л Пороговое значение

скорости возрастания концентрации глюкозы 7

«define MDC.CONC.GLU.RATE.THRESHOLD.DECREASE

29414

Л Пороговое значение

скорости убывания концентрации глюкозы 6/

«define MDC.CGM.SENSOR.CAL1BRATION

29428

Л Калибровка датчика

непрерывного мониторинга концентрации глюкозы6/ «define MDC.CGM_SENSOR_RUN.T1ME

29432

Л Срок службы

датчика непрерывного мониторинга концентрации глюкозы6/ «define MDC.CGM.SENSOR.SAMPLE.INTERVAL

29436

Л Интервал отбора

проб датчиком непрерывного мониторинга концентрации глюкозы*/

«define MDC.CGM_DEV.STAT непрерывного мониторинга концентрации глюкозы ‘/

29452

Л Статус прибора

«define MDC.CGM.DEV.TYPE.SENSOR

29460

Л Тип датчика

прибора мониторинга 7

«define MDC.CGM.DEV.TYPE.TRANSMITTER

29461

Л Тип передатчика

прибора мониторинга 7

«define MDC.CGM.DEV.TYPE.RECEIVER

29462

Л Тип приемника

прибора мониторинга 7

«define MDC.CGM.DEV.TYPE.OTHER

29463

Л Другой тип

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

*/

I…………………………………………………………..**…………….*………*………………………..

«define MDC_ATTR_MSMT_CONFIDENCE_95 объекта — доверие к измерение */

2700

/• Атрибут числового

/••••••••••……………………

• Из блока «Размерности» (MDC.PART.DIM)

«define MDC.DIM. MILU.G_PER.DL мг/дп 7

2130

……………………….*……./ Г Общая размерность

«define MDC.DIM.MILLI.MOLE.PER.L мкмоль/n 7

4722

/* Общая размерность

«define MDC.DIM.HR час 7

2240

/• Общая размерность

«define MDC.DIM.MIN минута 7

2208

Г Общая размерность

«define MDC.DIM. MILLi.G_PER_DL_PER.MIN мг/дп в минуту 7

4724

Г Общая размерность

«define MDC.DIM_MILLI_MOLE_PER_L_PER.MIN

мк могъ/л 8 минуту 7

С.З Систематическое создание терминов и кодов

4728

/• Общая размерность

Систематическое создание терминов и кодов описано в таблице С.1.

Таблица С.1 — Систематическое создание терминов и кодов

Систематическое имя

Общий тернии

Обозначение

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

10 ссылки

Код

Disease Man

agement | Device Status | Personal Health Device

Статус PHD DM

Объект, содержащий общий статус прибора при управлении заболеванием с помощью ПМП

MDC.PHD_DM_DEV.STAT

20000

Glucose | Concentration | Trend

Тренд глюкозы

Объект, содержащий тренд концентрации глюкозы

MDC.CONC.GLU.TREND

29400

Glucose | Concentration | Thresholds | Patient Low High

Нижнее и верхнее пороговое значение глюкозы для пациента

Объект, содержащий нижнее и верхнее пороговое значение концентрации глюкозы для пациента

MDC CONC GLU PATIENT THRESHOLDS LOW.HIGH

29404

Glucose | Concentration | Threshold | Patient Low

Нижнее пороговое значение ггеокозы для пациента

Нижнее пороговое значение концентрации глюкозы для пациента

MDC CONC GLU PA-TIENT.THRESHOLD.LOW

29405

Glucose | Concentration | Threshold | Patient High

Верхнее пороговое значение глюкозы для пациента

Верхнее пороговое значение концентрации глюкозы для пациента

MDC CONC GLU PA-TIENT.THRESHOLD.HtGH

29406

Glucose | Concentration | Thresholds | Hypo Hyper

Критичный диапазон концентрации глюкозы

Объект, содержащий гипогликемические и гипергликемические пороговые значения концентрации глюкозы

MDC CONC GLU THRESHOLDS HYPO HYPER

29408

Glucose [Concentration | Threshold 1 Hypo

Нижний предел критичного диапазона концентрации глюкозы

Гипогликемическое пороговое значение концентрации глюкозы

MDC CONC GLU THRESHOLD.HYPO

29409

Продолжение таблицы С. 1

Систематическое

имя

Общий термин

Обозначение

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

tD ссылки

Код

Glucose (Concentration | Threshold 1 Hyper

Верхний предел критичного диапазона концентрации глюкозы

Гипергликемическое пороговое значение концентрации ггажозы

MDC CONC GLU THRESHOLD.HYPER

29410

Glucose (Concentration [ Rate | Thresholds

Пороговые значения скорости изменения глюкозы

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

MDC CONC GLU RATE THRESHOLDS

29412

Glucose (Concentration (Rate | Threshold | Increase

Пороговое значение скорости повышения глюкозы

Пороговое значение скорости повышения концентрации глюкозы

MDC CONC GLU RATE THRESHOLD-INCREASE*

29413

Glucose | Concentration | Rate | Threshold | decrease

Пороговое значение скорости понижения глюкозы

Пороговое значение скорости понижения концентрации глюкозы

MDC CONC GLU RATE THRESHOLD-DECREASE

29414

CGM | Sensor | Calibration

Калибровка датчика CGM

Объект, содержащий характеристику калибровки датчика CGM

MDC CGM SENSOR CALIBRATION

29428

CGM | Sensor | Run Типе

Срок службы датчика CGM

Объект, содержащий срок службы датчика CGM

MDC CGM SENSOR RUN.TIME

29432

CGM | Sensor | Sampling | Interval

Интервал отбора проб датчика CGM

Объект, содержащий интервал отбора проб датчика CGM

MDC CGM SENSOR SAMPLE-INTERVAL

29436

CGM | Device Status

Статус прибора CGM

Объект, содержащий статус прибора CGM

MDC.CGM.DEV.STAT

29452

CGM | Device | Type | Sensor

Датчик CGM

Тип датчика прибора CGM

MDC CGM DEV TYPE SENSOR

29460

CGM | Device | Type | Transmitter

Передатчик CGM

Тип передатчика прибора CGM

MDC CGM DEV TYPE TRANSMITTER

29461

CGM | Device | Type | Receiver

Приемник CGM

Тип приемника прибора CGM

MDC CGM DEV TYPE RECEIVER

29462

CGM | Device | Type | Other

Иной тип прибора CGM

Иной тип прибора CGM.

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

MDC CGM DEV TYPE OTHER

29463

Attribute | Threshold | Notification

Текстовая строка уведомления о пороговом значении

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

MDC ATTR THRES N0-TIF.TEXT.STRING

2696

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

Систематическое имя

Общий тернии

Обозначение

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

10 ссыпки

Код

Attribute | Measurement | Confidence

Границы

95 %-ного доверия к измерению

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

значения измерения

MDC ATTR MSMT CONFIDENCE,^

2700

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

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

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

  • a) Когда пользователь подсоединяет CGM, то менеджер не распознает конфигурацию агента и передает ответ на запрос ассоциации, поступивший от агента, с результатом accepted-unknown-config.

  • b) В связи с этим агент передает менеджеру информацию о своей конфигурации. После получения подтверждения от менеджера о приеме конфигурации агента, прибор агента готов передавать измерения. Оба прибора переходят в состояние «Выполнение» (Operating).

  • c) После этого менеджер может запросить атрибуты объекта системы медицинского прибора агента, отправив сообщение сданными, содержащими команду «Remote Operation Invoke | Get» (вызов удаленной операции | получить). Следует помнить, что менеджер может запросить атрибуты объекта системы медицинского прибора, как только агент перейдет в состояние «Ассоциирован» (Associated), включая подсостояния «Конфигурирующий» (Configuring) и «Выполнение» (Operating). В качестве ответа агент передает менеджеру свои атрибуты объекта системы медицинского прибора, используя сообщение с данными, содержащими команду «Remote Operation Response | Get».

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

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

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

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

(О.Е2£2)

(Ом. F 223)

СО. вдед

(Сы.Е.323)

(СМ.ЕА1Л)

(О.Е4.1Д)

(O.ES.1)

(Cm.E«.1)

(СМ.ЕС2)

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

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

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

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

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

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

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

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

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

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

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

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

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

0хЕ2

0x00

APDU CHOICE Type (AarqApdu)

0x00

0x32

CHOICE.length = 50

0x80

0x00

0x00

0x00

assoc-version

0x00

0x01

0x00

0х2А

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

0x50

0x79

dala-proto-id = dala-proto-id-20601

0x00

0x26

data-proto-info length = 38

0x80

0x00

0x00

0x00

protocotVersion

0x80

0x00

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

0x80

0x00

0x00

0x00

nomenclature Version

0x00

0x00

0x00

0x00

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

0x00

0x80

0x00

0x00

systemType = sys-type-agent

0x00

0x08

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

0x11

0x22

ОхЗЭ

0x44

0x55 0x66 0x77 0x88

0x40

0x00

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

0x00

0x01

data-req-mode-flags

0x01

0x00

data-req-inil-agent-count = 11 data-req-init-manager-count = 0

0x00

0x00

0x00

0x00

optionList.count = 0 | optonList.length = 0

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

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

0xE3

0x00

APDU CHOICE Type (AareApdu)

0x00

0x2C

CHOICE.length = 44

0x00

0x03

result = accepted-unknown-config

0x50

0x79

dala-proto-id – 20601

0x00

0x26

data-proto-info length = 38

0x80

0x00

0x00

0x00

protocofVersion

0x80

0x00

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

0x80

0x00

0x00

0x00

nomenclatureversion

0x00

0x00

0x00

0x00

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

0x80

0x00

0x00

0x00

systemType = sys-type-manager

0x00

0x08

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

0x88

0x77

0x66

0x55 0x44

0x33 0x22 0x11

0x00

0x00

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

0x00

0x00

0x00

0x00

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

0x00

0x00

0x00

0x00

optionLislcount = 0 | optionListlength = 0

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

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

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

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

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

0хЕ2

0x00

APDU CHOICE Type (AarqApdu)

0x00

0x32

CHOICE.Iength = 50

0x80

0x00

0x00

0x00

assoc-version

0x00

0x01

0x00

0х2А

data-proto-iist.oount = 1 | length = 42

0x50

0x79

data-proto-id = data-proto-»d-20601

0x00

0x26

data-proto-info length = 38

0x80

0x00

0x00

0x00

protocolversion

0x80

0x00

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

0x80

0x00

0x00

0x00

nomenclatureversion

0x00

0x00

0x00

0x00

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

0x00

0x80

0x00

0x00

systemType = sys-type-agent

0x00

0x08

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

0x11

0x22

0x33

0x44 0x55

0x66 0x77 0x88

0x40

0x00

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

0x00

0x01

data-req-mode-ftags

0x01

0x00

data-req-init-agenl-count = 11 data-req-irwt-manager-count = 0

0x00

0x00

0x00

0x00

optionList.count = 0 | optionListlength = 0

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

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

конфигурацию CGM (т.е. агенту не нужно передавать свою конфигурацию).

0xE3

0x00

APDU CHOICE Type (AareApdu)

0x00

0x2C

CHOICE.Iength =44

0x00

0x00

result = accepted

0x50

0x79

data-proto-id = 20601

0x00

0x26

data-proto-info length = 38

0x80

0x00

0x00

0x00

protocolversion

0x80

0x00

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

0x80

0x00

0x00

0x00

nomenclatureversion

0x00

0x00

0x00

0x00

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

0x80

0x00

0x00

0x00

systemType = sys-type-manager

0x88

0x77

0x66

0x55 0x44

0x33 0x22 0x11

0x00

0x00

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

0x00

0x00

0x00

0x00

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

0x00

0x00

0x00

0x00

opbonList.count = 01 optionList length = 0

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

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

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

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

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

0хЕ2

0x00

APDU CHOICE Type (AarqApdu)

0x00

0x32

CHOICE.fength = 50

0x80

0x00

0x00

0x00

assoc-versron

0x00

0x01

0x00

0х2А

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

0x50

0x79

data-proto-id = 20601

0x00

0x26

data-proto-info length = 38

0x80

0x00

0x00

0x00

protocolversion

0x80

0x00

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

0x80

0x00

0x00

0x00

nomenclatureversion

0x80

0x00

0x00

0x00

functionaJUnits = может войти в тестовую ассоциацию

0x00

ОхВО

0x00

0x00

systemType = sys-type-agent

0x00

0x08

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

0x11

0x22

0x33

0x44

0x55 0x66 0x77 0x88

0x09

0хС4

dev-config-id: 2500

0x00

0x01

da la-req-mode-Bags

0x01

0x00

data-req-init-agent-count = 11 dala-req-init-manager-count=0

0x00

0x00

0x00

0x00

optionlist.count – 0 | optionlist, length = 0

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

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

0xE3

0x00

APDU CHOICE Type (AareApdu)

0x00

0x2C

CHOICE.length = 44

0x00

0x00

result = accepted

0x50

0x79

data-proto-id – 20601

0x00

0x26

data-proto-info length = 38

0x80

0x00

0x00

0x00

protocolversion

0x80

0x00

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

0x80

0x00

0x00

0x00

nomenclatureversion

0x00

0x00

0x00

0x00

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

0x80

0x00

0x00

0x00

systemType = sys-type-manager

0x00

0x08

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

0x88

0x77

0x66

0x55 0x44

0x33 0x22 0x11

0x00

0x00

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

0x00

0x00

0x00

0x00

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

0x00

0x00

0x00

0x00

optionList.count = 0 | optronlisllenglh = 0

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

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

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

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

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

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

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

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

тзерждаемосо отчета о событии типа MDC.NOTI.CONF1G.

0хЕ7

0x00

APOU CHOICE Type (PrstApdu)

0x00

0х9С

CHOICE.tength = 156

0x00

0х9А

OCTET STRING.Iength = 154

0x43

0x21

invoke-id = 0x4321 (начало DalaApdu. кодировка MDER)

0x01

0x01

CHOICE(Remote Operation Invoke | Confirmed Event Report)

0x00

0x96

obj-handfe = 0 (объект MOS)

0x00

0x00

event-time = OxFFFFFFFF

OxFF

OxFF

OxFF

OxFF

event-type = MDC.NOTI.CONFIG

0x0D

OxtC

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

0x00

0х8Е

config-report-id = идентификатор расширенной конфигурации

0x40

0x00

config-obj-Hst.count = 3 Объекты измерений будут «объявлены»

0x00

0x03

oonfig-obj-tist.length = 138

0x00

0х8А

conRg-obj-iist.iength = 138

0x00

0x06

obj-ctass = MDC.MOC_VMO_METRiC.NU

0x00

0x01

obj-handte = 1 (1-е измерение — глюкоза)

0x00

0x05

attributes.count = 5

0x00

0x30

attributes.length – 48

0x09

Ox2F

attribute-id = MDC.ATTR.ID.TYPE

0x00

0x04

attribute-value.length = 4

0x00

0x02

0x71

0xD4

MDC.PART.SCADA | MDC.CONC.GLU.ISF

0х0А

0x61

attribute-id = MDC.ATTR.SUPPLEMENTAL.TYPES

0x00

0x08

attribute-value.length = 8

0x00

0x01

SupplementaTTypeListcount = 1

0x00

0x04

SupplementafTypeListlength = 4

0x00

0x80

0x72

0x39

MDC PART PHD DM | MDC CTXT GLU SAMPLELOCATION SUBCUTANEOUS

0х0А

0x46

attribute-id = MDC.ATTR.METRIC.SPEC.SMALL

0x00

0x02

attribute-value.length = 2

ОхСО

0x42

mss-avai-intermittent. mss-avail-storod-data. mss-acc-agent-initiated. mss-cat-calculation

0x09

0x96

attribute-id = MDC.ATTR.UNIT.CODE

0x00

0x02

attribute-value.length = 2

0x08

0x52

MDC.DIM_MILLI_G_PER.DL

ОхОА

0x55

attribute-id = MDC.ATTR_ATTRIBUTE_VALUE.MAP

0x00

ОхОС

attribute-value.length = 12

0x00

0x02

AttrVblMap.counl – 2

0x00

0x08

AttrValMap.length = 8

ОхОА

0х4С

0x00

0x02

MDC.ATTR.NU.VAL.OBS.BASIC | длина значения = 2

ОхОА

0x82

0x00

0x08

MDC.ATTR_T1ME_STAMP.BO | длина значения = 8

0x00

0x06

obj-dass = MDC_MOC.VMO_METRIC.NU

0x00

0x02

obj-handle = 2 (2-е измерение — калибровка датчика)

0x00

0x04

attributes.count = 4

0x00

0x24

attributes.length = 36

0x09

0x2F

attribute-id = MDC.ATTR.ID.TYPE

0x00

0x04

attribute-value.length – 4

0x00

0x80

0x72

OxFO

MDC_PART_PHD_DM | MDC.CGM.SENSOR.CALIBRATION

ОхОА

0x46

attribute-id = MDC_ATTR_METRIC_SPEC_SMALL

0x00

0x02

attribute-value.length = 2

0x60

0х4С

mss-avail-stored-data. mss-upd-aperiodic. mss-acc-agent-irwtiated. mss_cat_ manual. mss_cat_settng

0x09

0x96

attnbute-td = MDC_ATTR_UNIT_CODE

0x00

0x02

attribute-value.length – 2

0x08

0x52

MDC_DIM_MILLI_G_PER_DL

ОхОА

0x55

attnbute-td = MDC_AnR_ATTRIBUTE_VAL_MAP

0x00

ОхОС

attribute-value.length = 12

0x00

0x02

AttrValMap.oount = 2

0x00

0x08

AttrValMap.length = 8

ОхОА

0х4С

0x00

0x02

MDC_ATTR_NU_VAL_OBS_BASIC | длина значения = 2

ОхОА

0x82

0x00

0x08

MDC_ATTR_TIME_STAMP_BO | длина значения = 8

0x00

0x05

obj-class = MDC_MOC_VMO_METRIC_ENUM

0x00

0x03

obj-handle = 3 (3-е измерение — статус CGM)

0x00

0x03

attributes.counl – 3

0x00

0х1Е

attributes.length = 30

0x09

0x2F

attnbute-td = MDC_ATTR_ID_TYPE

0x00

0x04

attribute-value.length = 4

0x00

0x80

0x72

0хЕ4

MDC_PART_PHD_DM | MDC_CGM_DEV_STAT

ОхОА

0x46

attribute-id = MDC_ATTR_METRIC_SPEC_SMALL

0x00

0x02

attnbute-value.length = 2

OxFO

0x40

mss-avail-intermrttent. mss-avail-stored-data, mss-upd-aperiodic. mss-msmt-aperiodtc, mss-aoc-agent-initiated

ОхОА

0x55

attribute-id = MDC_ATTR_ATTRIBUTE_VAL_MAP

0x00

ОхОС

attribute-value.length – 12

0x00

0x02

AttrValMap.oount = 2

0x00

0x08

AttrValMap.length = 8

ОхОА

0x82

0x00

0x08

MDC_ATTR_TIME_STAMP_BO | длина значения = 8

ОхОА

0x66

0x00

0x04

MDC_ATTR_ENUM_OBS_VAL_BASIC_B1T_STR | длина значения = 4

Е.3.2.3 Ответ на удаленную операцию события отчета о конфигурации

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

0xE7

0x00

APDU CHOICE Type (PrstApdu)

0x00

0x16

CHOICE.length = 22

0x00

0x14

OCTET STRINGJength = 20

0x43

0x21

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

0x02

0x01

CHOICE (Remote Operation Response | Confirmed Event Report)

0x00

0x0E

CHOICE.Iength = 14

0x00

0x00

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

0x00

0x00

0x00

0x00

currentTime = 0

0x00

0x1C

event-type = MDC_NOTI_CONFIG

0x00

0x04

event-reply-info.length = 4

0x40

0x00

ConfigReportRsp.config-report-id = 0x4000

0x00

0x00

ConfigReportRsp.config-result = accepted-config

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Е.4 Сервис GET для получения атрибутов MDS

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

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

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

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

0хЕ7

0x00

APDU CHOICE Type (PrstApdu)

0x00

ОхОЕ

CHOICE.Iength = 14

0x00

ОхОС

OCTET STRING.Iength = 12

0x34

0x56

invoke-id = 0x3456 (начало OataApdu. кодировка MDER)

0x01

ОхОЭ

CHOICE (Remote Operation invoke | Get)

0x00

0x06

CH01CE.Iength = 6

0x00

0x00

handle = 0 (MDS object)

0x00

0x00

attribute-id4>sl.count – 0 (все атрибуты)

0x00

0x00

attribute-id-lisl.tength = 0

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

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

0xE7

0x00

APDU CHOICE Type (PrstApdu)

0x00

0x6A

CHOICE.Iength -106

0x00

0x68

OCTET STRING.Iength = 104

0x34

0x56

invoke-»d = 0x3456 (зеркально отражается из запроса)

0x02

0x03

CHOICE (Remote Operation Response | Get)

0x00

0x62

CHOICE.Iength = 98

0x00

0x00

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

0x00

0x06

attribute-listcount = 6

0x00

0x5C

atlribute-listJength = 92

OxOA

0x5A

attribute id = MDC.ATTR_SYS_TYPE_SPEC.LIST

0x00

0x08

attribute-value.length = 8

0x00

0x01

system-type-spec-lisLcount = 1

0x10

0x04

system-type-spec-lrsl. length = 4

0x10

0x1A

type = MDC.DEV_SPEC_PROFILE.CGM

0x00

0x01

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

0x09

0x28

attribute id = MDC.ATTR.ID.MODEL

0x00

0x16

attribute-value.length – 22

0x00

ОхОА

0x54

0x68

string length = 10 | «TheCompany»

0x65

0x43

0x6F

0x6D

0x70

0x61

ОхбЕ

0x79

0x00

0x08

0x54

0x68

string length = 81 «TheCGMXtO»

0x65

0x43

0x47

0x4D

0x58

0x00

0x09

0x84

attribute-id = MDC.ATTR.SYS.ID

0x00

ОхОА

attribute-value.length = 10

0x00

0x08

0x88

0x77

octet string length = 8 | EUI-64

0x66

0x55

0x44

0x33

0x22

0x11

ОхОА

0x44

attribute-id = MDC.ATTR.DEV.CONFIGJD

0x00

0x02

attribute-value.length = 2

0x40

0x00

dev-config-id = 0x4000 (extended-config-start)

0x09

0x20

attribute id = MDC_ATTR_1D_PROO_SPECN

0x00

0x12

attribute-value.length = 18

0x00

0x01

ProductionSpec.count = 1

0x00

ОхОЕ

ProductionSpec. length = 14

0x00

0x01

ProdSpecEntry.spec-type = 1 {serial-number)

0x00

0x00

ProdSpecEntry.component-id = 0

0x00

0x08

0x44

0x45

0x31

0x32

0x34

0x35

0x36

0x37

ОхОА

0x81

attribute id = MDC_ATTR_T1ME_BO

0x00

0x08

attribute-value.length = 8

0x51

ОхЗР

0x46

0x38

Base-Offset-Time-Stamp = 2013-03-12T15:14:00.00

0x00

0x00

0x00

0x00

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

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

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

0xE7

0x00

APDU CHOICE Type (PrstApdu)

0x00

0x28

CHOICE.length = 40

0x00

0x26

OCTET STRING.Ienglh = 38

0x12

0x36

invoke-»d = 0x1236

0x01

0x01

CHOiCE(Remote Operation Invoke | Confirmed Event Report)

0x00

0x20

CHOICE.Iength = 32

0x00

0x00

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

OxFF

OxFF

OxFF

OxFF

event-time = OxFFFFFFFF

0x00

0x10

event-type = MOC_NOTI_SCAN_REPORT_FIXED

0x00

0x16

event-info.length = 22

OxFO

0x00

ScanReportlnfoFixed.data-req-id = OxFOOO (agent-initiated)

0x00

0x00

ScanReportlnfoFixed. scan-report-no = 0

0x00

0x01

ScanReporUnfoFixed.obs-scan-fixed.count = 1

0x00

ОхОЕ

ScanReportlnfoFixed.obs-scan-fixed.length = 14

0x00

0x01

ScanReportinfoFixed.obs-scan-fixed.vaJue[0].obj-handle = 1

0x00

ОхОА

ScanReportlnfoFixed.obs-scan-fixed.vaiu6(0].obs-val-data.length = 10

0x40

0x66

Basic-Nu-Observed-Value = 6.7 mmot/L

0x52

0х9С

ОхАЗ

0хВ8

Base-Off set-Trne-Stamp = 2013-03-12T15:14:00.00

0x00

0x00

0x00

0x00

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

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

Агент CGM посылает менеджеру следующее сообщение.

0xE4

0x00

APDU CHOICE Type (RlrqApdu)

0x00

0x02

CHOICE.length – 2

0x00

0x00

причина = нормальная

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

0xE5

0x00

APDU CHOICE Type (RlreApdu)

0x00

0x02

CHOICE.tength = 2

0x00

0x00

причина = нормальная

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

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

Таблица ДА.1

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

Степень соотоетстен»

Обозначение и наименование соответствующего нацнонапьного>’ыежгосударственмого стандарта

ISO/IEEE 11073-20601:2010

IEEE 11073-20601а-2010

е

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

УДК 004:61:006.354 ОКС 35.240.80

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

БЗ 10—2019/131

Редактор П.К. Одинцов

Технический редактор И.Е. Черепкова Корректор ИЛ. Королева Компьютерная верстка АН. Золотаревой

Сдано а набор 11.09.201d. Подписано о печать 16.10.2019. Формат 60 * 84 Vg. Гарнитура Ариал Усп. леч. л. 8.04. Уч.-иад. л. 7.96.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Создано а единичном исполнении во . 117418 Москва. Нахимовский пр-т. д. 3t, я. 2.

1

Информацию по ссылкам можно найти в разделе 2.

2

> Цифры в скобках соответствуют номеру источника в разделе «Библиография» приложения А.

3

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

4

) Публикации ISO/IEEE получены из Центрального секретариата ИСО (http://www.tso.org/). В США публикации tSO/lEEE можно получить также от Института инженеров по электротехнике и электронике (http://standards. ieee.oro/1

s) Публикации ИИЭР получены от Института инженеров по электротехнике и радиоэлектронике (htto://standards, ieee.org).

Наименования стандартов IEEE или продуктов, на которые дается ссылка в этом разделе, являются товарными знаками Института инженеров по электротехнике и радиоэлектронике.

5

Подписка на IEEE Standards Dictionary Online доступна no адресу: htlD^/www.ieee.ora/oortaVtnnovate/Drod-ucts/standard/standards diciionarv.html.

6

Из блока «Инфраструктура объектен {MDC.PART.OBJ)

«define MDC.ATTR.THRES.NOTIF.TEXT.STRING 2696 Г Атрибут числового

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

*/

Выполненные работы

Натуральные чаи «Чайные технологии»
Натуральные чаи «Чайные технологии»
О проекте

Производитель пищевой продукции «Чайные технологии» заключил контракт с федеральной розничной сетью «АЗБУКА ВКУСА» на поставку натуральных чаев.

Под требования заказчика был оформлен следующий комплект документов: технические условия с последующей регистрацией в ФБУ ЦСМ; технологическая инструкция; сертификат соответствия ГОСТ Р сроком на 3 года; декларация соответствия ТР ТС ЕАС сроком на 3 года с внесение в госреестр (Росаккредитация) с протоколами испытаний; Сертификат соответствия ISO 22 000; Разработан и внедрен на производство план ХАССП.

Выдали полный комплект документов, производитель успешно прошел приемку в «АЗБУКЕ ВКУСА». Срок реализации проекта составил 35 дней.

Что сертифицировали

Азбука Вкуса

Кто вёл проект
Дарья Луценко - Специалист по сертификации

Дарья Луценко

Специалист по сертификации

Оборудования для пожаротушения IFEX
Оборудования для пожаротушения IFEX
О проекте

Производитель оборудования для пожаротушения IFEX открыл представительство в России. Заключив договор на сертификацию продукции, организовали выезд экспертов на производство в Германию для выполнения АКТа анализа производства, часть оборудования провели испытания на месте в испытательной лаборатории на производстве, часть продукции доставили в Россию и совместно с МЧС РОССИИ провели полигонные испытания на соответствия требованиям заявленным производителем.

По требованию заказчика был оформлен сертификат соответствия пожарной безопасности сроком на 5 лет с внесением в госреестр (Росаккредитация) и протоколами испытаний, а также переведена и разработана нормативное документация в соответствии с ГОСТ 53291.

Выдали полный комплект документации, а производитель успешно реализовал Госконтракт на поставку оборудования. Срок реализации проекта составил 45 дней.

Что сертифицировали

Международный производитель оборудования
для пожаротушения IFEX

Кто вёл проект
Василий Орлов - Генеральный директор

Василий Орлов

Генеральный директор

Рассчитать стоимость оформления документации

Специалист свяжется с Вами в ближайшее время

Получить консультацию специалиста

Ошибка: Контактная форма не найдена.

Оставляя заявку, вы соглашаетесь с пользовательским соглашением