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

        ГОСТ Р 56845-2019/ISO/IEEE 11073-20601:2016

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

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

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

 Часть 20601

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

 Health informatics. Personal health device communication. Part 20601. Application profile. Optimized exchange protocol

ОКС 35.240.80

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

 Предисловие

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

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

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

4 Настоящий стандарт идентичен международному стандарту ISO/IEEE 11073-20601:2016* "Информатизация здоровья. Обмен данными с персональными медицинскими приборами. Часть 20601. Прикладной профиль. Оптимизированный протокол обмена" (ISO/IEEE 11073-20601:2016 "Health informatics - Personal health device communication - Part 20601: Application profile - Optimized exchange protocol", IDT)

5 Настоящий стандарт рекомендуется применять совместно с ГОСТ Р 56845-2019/ISO/IEEE 11073-20601:2016/Сог.1:2016

6 ВЗАМЕН ГОСТ Р 56845-2015/ISO/IEEE 11073-20601:2010

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

 Предисловие к ИСО/ИИЭР 11073-20601

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

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

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

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

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

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

Ключевые слова:

ИИЭР 11073-20601

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

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

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

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

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

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

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

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

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

Переводы

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

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

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

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

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

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

Secretary, IEEE-SA Standards Board

445 Hoes Lane

Piscataway, NJ 08854 USA

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

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

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

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

Ксерокопии

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

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

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

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

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

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

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

Патенты

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

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

Участники

На момент отправки этого стандарта в Бюро стандартов IEEE-SA с целью согласования рабочая группа по персональным медицинским приборам имела следующий состав:

Дайди Джонг (Daidi Zhong), сопредседатель   Майкл Дж. Кирван (Michael J. Kirwan), сопредседатель   Дуглас П. Борджиа (Douglas P. Bogia), сопредседатель
Charles R. Abbruscato	Jinhan Chung	Raul Gonzalez Gomez
Nabil Abujbara	Malcolm Clarke	Chris Gough
Maher Abuzaid	John A. Cogan	Channa Gowda
Manfred Aigner	John T. Collins	Charles M. Gropper
Jorge Alberola	Cory Condek	Amit Gupta
Karsten Alders	Todd H. Cooper	Jeff Guttmacher
Murtaza Ali	David Cornejo	Rasmus Haahr
Rolf Ambuehl	Douglas Coup	Christian Habermann
David Aparisi	Nigel Cox	Michael Hagerty
Lawrence Arne	Hans Crommenacker	Jerry Hahn
Diego B. Arquillo	Tomio Crosley	Robert Hall
Serafin Arroyo	David Culp	Nathaniel Hamming
Muhammad Asim	Allen Curtis	Rickey L. Hampton
Merat Bagha	Ndifor Cyril Fru	Sten Hanke
Doug Baird	Jesus Daniel Trigo	Jordan Hartmann
David Baker	Eyal Dassau	Kai Hassing
Anindya Bakshi	David Davenport	Marc Daniel Haunschild
Ananth Balasubramanian	Russell Davis	Wolfgang Heck
Sunlee Bang	Ed Day	Charles Henderson
M. Jonathan Barkley	Sushil K. Deka	Jun-Ho Her
Gilberto Barron	Pedro de-las-Heras-Quiros	Takashi Hibino
David Bean	Jim DelloStritto	Timothy L. Hirou
John Bell	Matthew d’Entremont	Allen Hobbs
Rudy Belliardi	Lane Desborough	Alex Holland
Kathryn M. Bennett	Kent Dicks	Arto Holopainen
Daniel Bernstein	Hyoungho Do	Robert Hoy
George A. Bertos	Xiaolian Duan	Frank Hsu
Chris Biernacki	Brian Dubreuil	Anne Huang
Ola	Jakob Ehrensvard	Sen-Der Huang
Thomas Blackadar	Fredrik Einberg	Zhiqiang Huang
Marc Blanchet	Roger M. Ellingson	Ron Huby
Thomas Bluethner	Michihiro Enokida	Robert D. Hughes
Xavier Boniface	Javier Escayola Calvo	David Hughes
Shannon Boucousis	Leonardo Estevez	Jiyoung Huh
Julius Broma	Roger Feeley	Hugh Hunter
Lyle G. Bullock	Bosco T. Fernandes	Hitoshi Ikeda
Bernard Burg	Christoph Fischer	Yutaka Ikeda
Chris Burns	Morten Flintrup	Philip O. Isaacson
Anthony Butt	Joseph W. Forler	Atsushi Ito
Jeremy Byford-Rew	Russell Foster	Michael Jaffe
Satya Calloji	Eric Freudenthal	Praduman Jain
Carole С. Carey	Matthias Frohner	Danny Jochelson
Santiago Carot-Nemesio	Ken Fuchs	Chris Johnson
Randy W. Carroll	Jing Gao	Phaneeth Junga
Simon Carter	Marcus Garbe	Akiyoshi Kabe
Seungchul Chae	John Garguilo	Steve Kahle
Rahul Chauhan	Rick Geimer	Tomio Kamioka
James Cheng	Igor Gejdos	Kei Kariya
Peggy Chien	Ferenc Gerbovics	Andy Kaschl
Chia-Chin Chong	Nicolae Goga	Junzo Kashihara
Saeed A. Choudhary	Julian Goldman	Kohichi Kashiwagi
Ralph Kent	Jim Niswander	Sternly K. Simon
Laurie M. Kermes	Hiroaki Niwamoto	Marjorie Skubic
Ikuo Keshi	Thomas Norgall	Robert Smith
Junhyung Kim	Anand Noubade	Ivan Soh
Min-Joon Kim	Yoshiteru Nozoe	Motoki Sone
Minho Kim	Abraham Ofek	Emily Sopensky
Taekon Kim	Brett Olive	Rajagopalan Srinivasan
Tetsuya Kimura	Begonya Otal	Andreas Staubert
Alfred Kloos	Charles Palmer	Nicholas Steblay
Jeongmee Koh	Bud Panjwani	Beth Stephen
Jean-Marc Roller	Carl Pantiskas	Lars Steubesand
John Koon	Harry P. Pappas	John (Ivo) Stivoric
Patty Krantz	Mikey Paradis	Raymond A. Strickland
Alexander Kraus	Hanna Park	Hermanni Suominen
Ramesh Krishna	Jong-Tae Park	Lee Surprenant
Geoffrey Kruse	Myungeun Park	Ravi Swami
Falko Kuester	Soojun Park	Ray Sweidan
Rafael Lajara	Phillip E. Pash	Jin Tan
Pierre Landau	TongBi Pei	Haruyuyki Tatsumi
Jaechul Lee	Soren Petersen	John W. Thomas
JongMuk Lee	James Petisce	Brad Tipler
Kyong Ho Lee	Peter Piction	Jonas
Rami Lee	Michael Pliskin	James Tomcik
Sungkee Lee	Jeff Price	Janet Traub
Woojae Lee	Harald Prinzhorn	Gary Tschautscher
Yonghee Lee	John Quinlan	Masato Tsuchid
Joe Lenart	Arif Rahman	Ken Tubman
Kathryn A. Lesh	Tanzilur Rahman	Yoshihiro Uchida
Qiong Li	Steve Ray	Sunil Unadkat
Ying Li	Phillip Raymond	Fabio Urbani
Patrick Lichter	Tim Reilly	Philipp Urbauer
Jisoon Lim	Barry Reinhold	Laura Vanzago
Joon-Ho Lim	Brian Reinhold	Alpo
John Lin	Melvin I. Reynolds	Ciro de la Vega
Jiajia Liu	John G. Rhoads	Dalimar Velez
Wei-Jung Lo	Jeffrey S. Robbins	Naveen Verma
Charles Lowe	Moskowitz Robert	Rudi Voon
Don Ludolph	Timothy Robertson	Isobel Walker
Christian Luszick	David Rosales	David Wang
Bob MacWilliams	Bill Saltzstein	Jerry P. Wang
Srikkanth Madhurbootheswaran	Benedikt Salzbrunn	Yao Wang
Romain Marmot	Giovanna Sannino	Yi Wang
Sandra Martinez	Jose A. Santos-Cadenas	Steve Warren
Miguel Martinez de Espronceda	Stefan Sauermann	Fujio Watanabe
Camara	John Sawyer	Tom Watsuji
Peter Mayhew	Guillaume Schatz	Mike Weng
Jim McCain	Alois Schloegl	Kathleen Wible
Laszlo Meleg	Paul S. Schluter	Paul Williamson
Alexander Mense	Lars Schmitt	Jan Wittenber
Ethan Metsger	Mark G. Schnell	Jia-Rong Wu
Yu Miao	Richard A. Schrenker	Will Wykeham
Jinsei Miyazaki	Antonio Scorpiniti	Ariton Xhafa
Erik Moll	Kwang Seok Seo	Junjie Yang
Darr Moore	Riccardo Serafin	Ricky Yang
Piotr Murawski	Sid Shaw	Melanie Yeung
Soundharya Nagasubramanian	Frank Shen	Done-Sik Yoo
Jae-Wook Nah	Liqun Shen	Jason Zhang
Alex Neefus	Bozhi Shi	Zhiqiang Zhang
Trong-Nghia Nguyen-Dobinsky	Min Shih	Thomas Zhao
Michael E. Nidd	Mazen Shihabi	Miha Zoubek
Tetsu Nishimura	Redmond Shouldice	Szymon Zysko

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

Настоящий стандарт утвержден IEEE-SA 21 августа 2014 года в следующем составе:

________________

* Заслуженный участник

В состав отдела стандартов IEEE-SA также входят следующие участники, которые не голосовали:

Ричард Дэблэсио (Richard DeBlasio), представитель DOE

Майкл Янежич (Michael Janezic), представитель NIST

Дон Мессина (Don Messina)

Издательство IEEE-SA

Кэтрин Беннетт (Kathryn Bennett)

Программы технического сообщества IEEE-SA

 Введение

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

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

Существуют следующие тесно связанные между собой стандарты:

- ИИЭР 11073-00103-2012 [В5]* содержит основные сведения о предметной области личного здоровья, а также определяет базовые варианты и модели использования;

________________

* Числа в скобках соответствуют порядковой нумерации библиографических источников в приложении К.

- ИСО/ИИЭР 11073-10101 [В16] документирует номенклатурные термины, доступные для использования;

- ИСО/ИИЭР 11073-10201:2004 [В17] документирует расширенную информационную модель предметной области (DIM), используемую в настоящем стандарте;

- стандарты ИСО/ИИЭР 11073-104zz определяют конкретные специализации приборов. Например, ИСО/ИИЭР 11073-10404 [В18] указывает, каким образом работают пульсоксиметры, обеспечивающие взаимодействие;

- ИСО/ИИЭР 11073-20101:2004 [В21] определяет правила кодирования медицинских приборов (MDER), используемые в настоящем стандарте.

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

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

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

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

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

      1.2 Цель

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

      1.3 Контекст

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

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

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

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

Рисунок 1 - Общий контекст работы

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

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

Над протоколом обмена находятся специализации приборов, описывающие специфичные сведения об определенном агенте (например, мониторе артериального давления, весах или шагомере). Специализации предоставляют подробную информацию о том, как работают такие агенты, и служат детальным описанием, полезным для создания агента специфичного типа. Кроме того, специализации ссылаются на соответствующие стандарты, содержащие дополнительную информацию. Номера стандартов, посвященных специализациям приборов, варьируются в диапазоне от ИИЭР 11073-10401 до ИИЭР 11073-10499 включительно. При ссылке на стандарты используется указание ИИЭР 11073-104zz, где zz - любое число в диапазоне от 01 до 99 включительно.

Некоторые специализации медицинских приборов охватывают широкие категории типов приборов (например, ИИЭР 11073-10441

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

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

профили

. Профиль дополнительно ограничивает модель, определенную в специализации, чтобы повысить интероперабельность (например, профиль шагомеров использует ограниченную часть модели из ИИЭР 11073-10441).

Технический отчет ИИЭР 11073-00103-2012 [В5]

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

_________________

Числа в скобках соответствуют порядковой нумерации библиографических источников в приложении К.

Рисунок 2 - Схема документа

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

- использование базовых идей и/или фрагментов из других документов (пунктирные линии);

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

Настоящий стандарт заимствует информацию из ИСО/ИИЭР 11073-10201:2004 [В17] и ИСО/ИИЭР 11073-20101:2004 [В21] в качестве обязательных приложений. При наличии несоответствий между этими стандартами приоритет имеет настоящий стандарт. В связи с заимствованием структур из этих стандартов некоторые наименования могут оказаться более ориентированными на медицинские учреждения (например, система медицинского прибора (MDS) вместо системы персонального медицинского прибора), однако для сохранения согласованности используются традиционные наименования.

Настоящий стандарт копирует релевантные части стандарта ИСО/ИИЭР 11073-10101 [В16] и добавляет новые номенклатурные коды.

Рисунок 3 - Взаимосвязь с другими документами ИИЭР 11073

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

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

ИИЭР 802

®-2014, IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture (

Стандарт ИИЭР для локальных и городских вычислительных сетей: общие положения и архитектура)

_________________

Публикации ИИЭР распространяются Институтом инженеров по электротехнике и электронике (

http://standards.ieee.org

).

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

ИИЭР 1541

-2002 (подтв. 2008), IEEE Standard for Prefixes for Binary Multiples (Стандарт ИИЭР для префиксов двоичных кратных величин)

ИСО/МЭК 80000-13:2008, Quantities and units - Part 13: Information science and technology (Физические величины и единицы измерения. Часть 13. Информатика и информационные технологии)

_________________

Настоящий стандарт отменяет и замещает разделы 3.8 и 3.9 стандарта МЭК 60027-2 (2005).

Публикации ИСО/МЭК распространяются Международной организацией по стандартизации (

http://www.iso.ch/

). Кроме того, на территории США публикации ИСО/МЭК распространяются компанией Global Engineering Documents (

http://global.ihs.com/

). Электронные копии на территории США распространяются Американским национальным институтом стандартов (

http://www.ansi.org/

).

ITU-T Rec. Х.667 (сентябрь 2004), Information technology - Open Systems Interconnection - Procedures for the operation of OSI Registration Authorities: Generation and registration of universally unique identifiers (UUIDs) and their use as ASN.1 object identifier (Информационная технология. Взаимосвязь открытых систем. Процедуры работы уполномоченных по регистрации ВОС. Создание, регистрация универсально уникальных идентификаторов (УУИд) и их использование в качестве компонентов идентификатора объекта АСН.1)

_________________

Публикации ITU-T распространяются Международным союзом электросвязи (

http://www.itu.int/

).

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

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

В настоящем стандарте применены термины с соответствующими определениями. Определения терминов, не указанных в данном разделе, см. в Онлайновом словаре по стандартам ИИЭР (

IEEE Standards Dictionary Online

)

.

_________________

Подписки на IEEE Standards Dictionary Online доступны по адресу:

http://www.ieee.org/portal/innovate/products/standard/standards_dictionary.html

.

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

3.1.2 атрибут (attribute): Данные, представляющие свойство объекта. Атрибуты совместно с действиями определяют объект.

3.1.3 AttributeChangeSet: Набор изменений значений атрибутов, представляющий атомарное изменение объекта.

Примечание - Система медицинского прибора (MDS) или объект Scanner уведомляются о завершении AttributeChangeSet. Группы этих наборов AttributeChangeSet отображаются системой медицинского прибора или объектом Scanner в одну из структур ObservationScan отчета о событиях сканирования, передаваемого менеджеру. Перед извлечением любого семантического поведения менеджер обновляет свой объект с помощью набора изменений значений атрибутов, содержащихся в ObservationScan.

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

3.1.5 подтверждение (confirmed): Механизм службы прикладного уровня, обеспечивающий уведомление о завершении.

Примечание - Для служб EVENT REPORT (т.е. на уровне данных) подтверждение позволяет агенту узнать, когда менеджер "принял ответственность" за часть данных, после чего агент может ее удалить. Для служб ACTION, GET и SET (т.е. на уровне управления) подтверждение позволяет менеджеру узнать, когда агент "завершил" запрошенную транзакцию.

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

3.1.7 динамический атрибут (dynamic attribute): Атрибут, значение которого может изменяться во время ассоциации.

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

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

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

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

3.1.10 объект Metric (metric): Объект, используемый для моделирования различных видов измерений.

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

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

3.1.12 объект (object): Единица, обладающая некоторой функциональностью, или элемент устройства, свойства которых описываются атрибутами.

Примечание - Объекты Metric представляют измерения (например, артериального давления, веса или температуры), система медицинского прибора (MDS) - устройство, объекты постоянного хранения данных Metric (PM-store) - механизмы постоянного хранения в памяти агента, а объекты Scanner - механизм управления и отчетности.

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

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

3.1.15 статический атрибут (static attribute): Атрибут, значение которого не изменяется (остается фиксированным) на протяжении срока существования ассоциации.

Примечание 1 - Значение передается в отчете о событиях конфигурации. Значение остается действующим до момента выхода системы из состояния ассоциации.

Примечание 2 - Необходимо отличать понятие "статический" (static) в рамках настоящего стандарта от конструкции static в языке программирования С

.

_________________

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

      3.2 Сокращения

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

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

API - прикладной программный интерфейс (Application Programming Interface);

ASCII - американский стандартный код для обмена информацией; код ASCII

(American Standard Code for Information Interchange);

_________________

В настоящем стандарте термин "ASCII" подразумевает набор знаков согласно стандарту ИСО/МЭК 646:1991 [В14].

ASN.1 - Абстрактная синтаксическая нотация версии 1, АСН.1 (Abstract Syntax Notation One);

AVA - объявление значения атрибута (Attribute Value Assertion);

BER - базовые правила кодирования (Binary Encoding Rules);

DIM - информационная модель предметной области (Domain Information Model);

DST - летнее время (Daylight Savings Time);

ECG - Электрокардиограмма или электрокардиограф (ЭКГ);

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

FIFO - первым пришел - первым ушел (First-ln, First-Out);

GMDN - глобальная номенклатура медицинских приборов (Global Medical Device Nomenclature);

ICS - заявление о соответствии реализации, ЗСР (Implementation Conformance Statement);

ID - идентификатор (IDentifier);

LSB - младший значащий бит (Least Significant Bit);

MDER - правила кодирования медицинских приборов (Medical Device Encoding Rules);

MDNF - цифровой формат медицинских приборов (Medical Device Numeric Format);

MDS - система медицинского прибора (Medical Device System);

MOC - класс медицинского объекта (Medical Object Class);

MSB - старший значащий бит (Most Significant Bit);

NaN - не число (Not A Number);

NBO - порядок передачи байтов в сети (Network Byte Order);

NRes - не при этом разрешении экрана (Not at this Resolution);

NTP - сетевой протокол службы времени (Network Time Protocol);

OID - объектный идентификатор, ОИД (Object IDentifier);

OUI - идентификатор, уникальный в пределах организации (Organizationally Unique Identifier);

PDU - блок данных протокола (Protocol Data Unit);

PER - правила уплотненного кодирования (Packed Encoding Rules);

PM - постоянная метрика (Persistent Metric);

РОС - Объект и класс информационной модели предметной области персональных медицинских приборов, ОК ПМП (personal health device domain information model object and class)

RCassoc - Счетчик попыток: процедура ассоциации;

RTC - часы реального времени (Real-Time Clock);

RT-SA - массив считываний в реальном времени (Real-Time Sample Array);

SCADA - система диспетчерского управления и сбора данных (Supervisory Control And Data Acquisition);

SNTP - простой сетевой протокол службы времени (Simple Network Time Protocol);

TCP - протокол управления передачей данных (Transmission Control Protocol);

TOassoc - Тайм-аут: процедура ассоциации;

TOca - Тайм-аут: служба подтвержденного действия;

TOcer-mds - Тайм-аут: служба подтвержденного отчета о событиях для объекта системы медицинского прибора;

TOcer-pms - Тайм-аут: служба подтвержденного отчета о событиях для объекта PM-store;

TOcer-scan - Тайм-аут: служба подтвержденного отчета о событиях для объекта Scanner;

TOclr-pms - Тайм-аут: служба подтвержденного события для очистки объекта PM-store;

TOconfig - Тайм-аут: процедура конфигурации;

TOcs - Тайм-аут: служба подтвержденного набора;

TOget - Тайм-аут: служба GET;

TOrelease - Тайм-аут: процедура завершения ассоциации;

TOsp-mds - Тайм-аут: специальный период времени между службами для объекта системы медицинского прибора;

TOsp-pms - Тайм-аут: специальный период времени передачи сегмента для объекта PM-segment;

USB - универсальная последовательная шина (universal serial bus);

UTC - всемирное координированное время (Coordinated Universal Time);

UUID - универсальный уникальный идентификатор, УУИд (Universally Unique IDentifier);

XER - правила XML-кодирования (Extensible Markup Language (XML) Encoding Rules).

      4 Руководящие принципы

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

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

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

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

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

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

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

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

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

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

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

- Информационная модель коммуникационного профиля строится на информационной модели предметной области (DIM) ИСО/ИИЭР 11073 и подразумевает оптимизацию при наличии возможности.

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

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

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

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

      5 Начальные сведения о персональных медицинских приборах (ИИЭР 11073)

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

Согласно ISO/IEEE 11073 общая модель системы состоит из трех основных частей: информационная модель предметной области, сервисная модель и коммуникационная модель. Эти три модели используются совместно для представления данных, определения методологий команд и доступа к данным, а также для описания передачи данных от агента к менеджеру. Ввиду тесных связей между этими моделями они кратко описаны соответственно в 5.2, 5.3 и 5.4, так что при ознакомлении с разделами 6, 7 и 8, где они описаны более детально, читателю будут известны основные понятия.

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

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

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

Сервисная модель, подробно описанная в разделе 7, предусматривает базовые операции доступа к данным, передаваемые между агентом и менеджером для извлечения данных, описанных в DIM. К базовым операциям относятся такие команды, как Get (получить), Set [задать], Action (выполнить действие) и Event Report (передать отчет о событии).

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

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

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

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

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

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

      5.6 Безопасность

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

      6 Модель предметной области персонального медицинского прибора

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

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

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

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

- отделение спецификации от реализации с помощью принципа инкапсуляции;

- развитие на основе принципа наследования;

- обратную совместимость с помощью принципа полиморфизма.

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

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

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

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

Настоящий стандарт использует информационные классы и объекты, определенные в ИСО/ИИЭР 11073-10201:2004 [В17], однако они следующим образом адаптированы к предметной области коммуникации персональных медицинских приборов:

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

- могут быть определены дополнительные службы объектов;

- могут быть определены дополнительные атрибуты;

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

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

Ключевое свойство модели DIM состоит в том, что ссылки на классы объектов и атрибуты осуществляются с помощью номенклатурных кодов, приведенных в ИСО/ИИЭР 11073-10101 [16]. Применение согласованной номенклатуры улучшает интероперабельность, поскольку все реализации поддерживают одинаковое семантическое значение числовых кодов. Использование номенклатурных кодов способствует также международному применению, поскольку сокращено количество строковых значений.

Номенклатура ИСО/ИИЭР 11073 определена в виде набора контекстно-зависимых разделов. Номенклатурный код в каждом контекстно-зависимом разделе определяется 16-битным кодом, который поддерживает до 65 536 независимых терминов для одного раздела. Ссылка на разделы осуществляется с помощью 16-битного кода раздела. Если код раздела номенклатуры определяется контекстом, возможно использование только 16-битного кода. Если контекст не определен или требуется контекстно-независимый код термина, тогда используется 32-битный код, образованный 16-битным кодом раздела и 16-битным кодом термина. Разделы, которые определены в настоящем стандарте и/или ИСО/ИИЭР 11073-10101 [В16], приведены в таблице 1.

Коды терминов с 0xF000 по 0xFFFF в каждом разделе номенклатуры зарезервированы для местных (определяемых производителем) номенклатурных кодов.

Для каждого номенклатурного термина стандарт ИСО/ИИЭР 11073-10101 [В16] определяет систематическое имя, объясняющее этот термин, значение уникального кода и ссылочный идентификатор (ID). Ссылочный идентификатор указывается в форме MDC_XXX_YYY (MDC означает "коммуникацию с медицинским прибором"). В тексте настоящего стандарта номенклатурные термины и номенклатурные коды указываются с помощью ссылочного идентификатора.

Таблица 1 - Разделы номенклатуры

      6.3 Определения классов персональных медицинских объектов

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

Представление информационных объектов персонального медицинского агента и отношений классов показано на рисунке 4 с помощью Унифицированного языка моделирования (UML). Объект, показанный на самом верхнем уровне, представляет информацию и статус объекта MDS (см. 6.3.2). С этим объектом ассоциированы ноль или более числовых массивов считываний в режиме реального времени (real-time sample array, RT-SA), перечислений Enumeration, объектов Scanner или объектов постоянного хранения измерений (persistent metric store, PM-store). С объектом PM-store ассоциированы ноль или более объектов PM-segment, содержащих постоянные измерения. Объекты Numeric, RT-SA и Enumeration произведены от общего базового класса Metric, который содержит общие и разделяемые атрибуты (см. 6.3.3). В общем случае объекты Numeric представляют эпизодические измерения (см. 6.3.4), объекты RT-SA - непрерывные считывания или биосигналы (см. 6.3.5), объекты Enumeration - аннотации событий (см. 6.3.6), а объекты PM-store (см. 6.3.7) в сочетании с объектами PM-segment (см. 6.3.8) - постоянные механизмы хранения измерений, доступ к которым позже получает менеджер. Кроме того, объект Scanner (подробно определенный в 6.3.9) упрощает информирование о передачах данных, инициированных агентом.

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

Классы информационной модели предметной области персонального медицинского прибора описаны в подразделах 6.3.2-6.3.9. Каждый подраздел использует следующий формат:

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

- атрибуты, определяемые классом;

- доступные методы;

- потенциальные события, генерируемые объектами, являющимися экземплярами класса;

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

Каждый тип данных атрибута определяется с помощью Абстрактной синтаксической нотации версии 1 (АСН.1) [В22]. Определения АСН.1 для всех типов данных и форматов обмена представлены в приложении А.

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

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

В таблицах объектов Metric атрибуты, помеченные как наблюдаемые, могут дополнительно маркироваться как (1) "задаваемые", (2) "вводимые вручную" или (3) "вычисляемые" полностью на основе вводимых вручную и/или задаваемых атрибутов. В этих трех случаях наблюдаемый атрибут должен считаться пригодным для интервала времени с момента первого присвоения значения атрибута до обновления этого или любого другого атрибута его объекта. Предполагается, что без этих настроек атрибут наблюдения действителен только во время его взятия. Агент устанавливает эти флаги в атрибуте Metric-Spec-Small. Типы атрибутов обобщены в таблице 2.

Таблица 2 - Типы атрибутов

Номенклатурный код класса объектов (например, Numeric или RT-SA) передается менеджеру во время конфигурирования, чтобы создать зеркальное представление объекта. Каждый объект обладает атрибутом Handle (дескриптор), который используется для идентификации объекта при выполнении действия (от и к объекту). Остальные атрибуты используются для представления и передачи информации о физическом приборе и его источниках данных. Доступ к атрибутам и их изменение осуществляются с помощью таких методов, как GET (получить) и SET (задать). Данные передают, используя события (EVENT).

      6.3.2 Класс MDS

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

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

6.3.2.2 Идентификация класса MDS

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

6.3.2.3 Атрибуты класса MDS

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

Таблица 3 - Атрибуты класса MDS

Имя атрибута	Идентификатор атрибута	Тип атрибута	Примечание	Квалификаторы
Handle	MDC_ATTR_ID_ HANDLE	HANDLE	Атрибут Handle представляет собой ссылочный идентификатор этого объекта. Значение атрибута Handle объекта MDS должно равняться 0	Обязательный, статический
System- Type	MDC_ATTR_ SYS_TYPE	TYPE	Данный атрибут указывает тип агента согласно определению в номенклатуре (например, весы). Значения должны заимствоваться из раздела nom-part-object и подраздела MD-Gen (общий медицинский прибор), описанных в стандарте ISO/IEEE 11073-10101 [В16]. Должен присутствовать один и только один атрибут System-Type или System-Type-Spec-List	Условно обязательный, статический
System- Model	MDC_ATTR_ID_ MODEL	SystemModel	Данный атрибут указывает производителя и номер модели прибора агента	Обязательный, статический
System-Id	MDC_ATTR_ SYS_ID	OCTET STRING	Данный атрибут имеет тип IEEE EUI-64, состоящий из 24-битного идентификатора, уникального в пределах организации (OUI), и 40-битного идентификатора, определяемого производителем. Значение OUI должно назначаться комитетом IEEE Registration Authority (http://standards.ieee.org/ regauth/index.html ) и использоваться согласно требованиям стандарта IEEE 802-2014	Обязательный, статический
________________       Дополнительные сведения о ссылках см. в разделе 2.
Dev- Configu- ration-ld	MDC_ATTR_ DEV_CONFIG_ID	Configld	Данный атрибут определяет идентификацию конфигурации прибора агента. Атрибут Dev-Configuration-ld статичен на протяжении срока существования ассоциации. Обычно он передается во время процедуры ассоциации. Менеджер может получить этот атрибут во время работы с помощью метода GET. Если этот атрибут запрашивается до того, как агент и менеджер согласуют конфигурацию, агент должен вернуть идентификатор конфигурации, предлагаемый в момент запроса. Дополнительную информацию об этом атрибуте см. в 8.8	Обязательный, статический
Attribute- Value-Map	MDC_ATTR_ ATTRIBUTE_ VAL_MAP	AttrValMap	Данный атрибут определяет атрибуты, передаваемые в сообщениях фиксированного формата об обновлении данных (дополнительные сведения см. в 7.4.5). Если при передаче отчета о динамических данных для объекта агент использует сообщения с фиксированным форматом значений, этот атрибут необходимо задать до отправки такого отчета. Значение этого атрибута может измениться в интервале времени между отправками таких отчетов о событиях, поэтому значение атрибута должно отправляться в отчете о событии, если изменение происходит в состоянии ассоциации	Условно обязательный, динамический
Production- Specification	MDC_ATTR_ID_ PROD_SPECN	Production- Spec	Данный атрибут указывает версии компонента, серийные номера и т.д. в формате, заданном производителем	Необязатель- ный, статический
Mds-Time- Info	MDC_ATTR_ MDS_TIME_INFO	MdsTimelnfo	Данный атрибут указывает возможности обработки времени и статус MDS. Использование этого атрибута требуется в случае поддержки синхронизации или настройки часов	Условно обязательный, динамический
Date-and- Time	MDC_ATTR_ TIME_ABS	AbsoluteTime	Данный атрибут определяет дату и время на часах агента с точностью 1/100 секунды (при наличии такой возможности). Дополнительную информацию об этом атрибуте см. в 8.12. Если в любом сообщении агента указано абсолютное время, этому атрибуту должно присваиваться текущее значение абсолютного времени. Если этот атрибут используется, то атрибут Base-Offset-Time не должен использоваться	Условно обязательный, наблюдаемый
Base-Offset- Time	MDC_ATTR_ TIME_BO	BaseOffset- Time	Данный атрибут определяет дату и время на часах агента в форме базового времени со смещением местного времени в минутах. Дополнительную информацию об этом атрибуте см. в 8.12. Если в любом сообщении агента указано базовое время со смещением (BaseOffsetTime), то должно быть указано текущее значение базового времени в этом атрибуте. Если этот атрибут используется, атрибут Date-and-Time не должен использоваться	Условно обязательный, наблюдаемый
Relative-Time	MDC_ATTR_ TIME_REL	RelativeTime	Агент, передающий относительное время (RelativeTime) в любом сообщении, должен указать его текущее значение в этом атрибуте	Условно обязательный, наблюдаемый
HiRes-Rela- tive-Time	MDC_ATTR_ TIME_REL_HI_ RES	HighResRela- tiveTime	Агент, передающий относительное время с высоким разрешеним (HighResRelative-Time) в любом сообщении, должен указать текущее значение этого времени в данном атрибуте	Условно обязательный, наблюдаемый
Date-and- Time-Adjust- ment	MDC_ATTR_ TIME_ABS_ ADJUST	AbsoluteTime- Adjust	В данном атрибуте сообщаются любые изменения даты и времени, которые вносятся при настройке часов пользователем или при возникновении таких событий, как переход на летнее время. Используется только в отчетах о событиях. Если запрашивается с помощью команды Get MDS Object, данное значение должно отсутствовать или равняться нулю. Если агент осуществляет настройку времени и даты, данный атрибут используется в отчете о событии, чтобы сообщить о таком изменении	Условно обязательный, наблюдаемый
Power-Status	MDC_ATTR_ POWER_STAT	PowerStatus	В данном атрибуте сообщается, осуществляется ли электропитание от батареи или электросети, а также указывается состояние заряда батареи	Необязатель- ный, динамический
Battery-Level	MDC_ATTR_VAL_ BATT_CHARGE	INT-U16	Данный атрибут указывает процент оставшейся емкости батареи (не определен, если значение >100)	Необязатель- ный, наблюдаемый
Remaining- Battery-Time	MDC_ATTR_ TIME_BATT_ REMAIN	BatMeasure	Данный атрибут представляет прогнозируемый объем оставшегося времени работы от батареи. Единицы измерения должны содержать значение MDC_DIM_MIN, MDC_DIM_HR или MDC_DIM_DAY для указания минут, часов или дней соответственно	Необязатель- ный, наблюдаемый
Reg-Cert- Data-List	MDC_REG_ CERT_DATA_ LIST	RegCertDa- taList	В данном атрибуте с информационными целями перечислены различные сведения о соответствии регуляторным и/или сертификационным нормам. Заявления о соответствии реализации (см. раздел 9) имеют приоритет над этим атрибутом и являются документами, имеющими юридическую силу	Необязатель- ный, статический
System- Type-Spec- List	MDC_ATTR_ SYS_TYPE_ SPEC_LIST	TypeVerList	Данный атрибут указывает тип (типы) агента согласно номенклатуре (например, весы). Значения должны заимствоваться из подраздела DEVspec раздела nom-part-in-frastruct, приведенного в ISO/IEEE 11073-10101 [В16] и ссылаться на специализации ISO/IEEE 11073-104zz. Если агент не соответствует ни одной из специализаций, список должен остаться пустым. Если агент соответствует профилю специализации, этот список должен содержать специализации и номенклатурные значения профиля. Данный список должен также содержать версии специализаций/профилей. Должен присутствовать только один из атрибутов, System-Type или System-Type-Spec-List. Данный атрибут должен присутствовать у многофункциональных агентов	Условно обязательный, статический
Confirm- Timeout	MDC_ATTR_ CONFIRM_ TIMEOUT	RelativeTime	Данный информационный атрибут тайм-аута определяет минимальное время, в течение которого агент должен ожидать ответного сообщения от менеджера после передачи ему сообщения вызова подтверждаемого отчета о событиях, прежде чем перейти в состояние "Не ассоциирован". Атрибут является информационным и используется для улучшения работы менеджера. В случае предоставления этого атрибута необходимо обеспечить его соответствие фактическому значению времени ожидания, которое используется агентом для подтверждаемого отчета о событии, сгенерированного объектом MDS. Данный атрибут является информационным для менеджера в том смысле, что менеджер не использует этот атрибут при фактической реализации протокола (например, менеджер не инициирует тайм-аут для переданного агентом подтверждаемого отчета о событии). Однако менеджер может пожелать использовать данную информацию для назначения приоритета обработки сообщения от агента с "коротким" тайм-аутом по отношению к сообщению от агента с "длинным" тайм-аутом	Необязатель- ный, динамический
Transport- Timeout	MDC_ATTR_ TRANSPORT_ TIMEOUT	RelativeTime	Данный тайм-аут определяет минимальное время, в течение которого менеджер должен ожидать ответного сообщения от агента после отправки сообщения через базовый транспортный уровень, прежде чем перейти в состояние "Разъединен". Для любого агента, использующего транспортный протокол, способный вызвать длительную задержку, настоятельно рекомендуется добавить этот атрибут в список параметров структуры PhdAssociationlnformation, чтобы менеджер мог подготовиться к длительной задержке в состоянии "Конфигурирующий"	Необязатель- ный, динамический

Обратите внимание, что атрибут System-Type не зависит от аналогично названного поля System-Type структуры PhdAssociationlnformation, описывающей запрос ассоциации.

Атрибуты MDS обеспечивают представление на аппаратном уровне и не зависят от конкретной предложенной или принятой конфигурации. Например, атрибут System-Type-Spec-List или Reg-Cert-Data-List предоставляет все возможности, которые способен предложить прибор. Текущая конфигурация может предоставить или не предоставить все перечисленное в этом атрибуте.

Типы данных атрибутов определены в приложении А.

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

Таблица 4 указывает методы (действия), доступные для объекта MDS. Данные методы вызываются с помощью службы ACTION. Графа "Метод/Действие" таблицы 4 содержит имя метода. Графа "Режим" указывает, может ли метод вызываться как неподтверждаемое действие (например, roiv-cmip-action из А.10.2) или подтверждаемое действие (например, roiv-cmip-confirmed-action). Столбец "Тип действия" содержит номенклатурный идентификатор для использования в поле action-type запроса действия и ответа на него (см. А.10.6). Графа "action-info-args" определяет ассоциированную структуру данных поля запроса action-info-args, используемую в сообщении действия. Графа "Поле action-info-args результата" указывает структуру, используемую в поле action-info-args ответа.

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

- MDS-Data-Request

Данный метод позволяет системе менеджера разрешить или запретить передачу результатов измерений со стороны агента (описание см. в 8.9.3.3.3).

- Set-Time

Данный метод позволяет системе менеджера настроить часы реального времени (RTC) с помощью абсолютного времени. Агент указывает, допустима ли команда Set-Time, используя бит mds-time-capab-set-clock в атрибуте Mds-Time-lnfo (см. таблицу 3). Агент, поддерживающий Set-Time, должен возвратить параметр rors-cmip-confirmed-action, однако в этом ответе поле action-info-args пустое. Агент, не поддерживающий Set-Time, должен возвратить ошибку no-such-action (roer).

- Set-Base-Offset-Time

Данный атрибут позволяет системе менеджера настроить часы реального времени с помощью базового времени и смещения в минутах по местному времени. Агент указывает, допустима ли команда Set-Base-Offset-Time, используя бит mds-time-capab-set-clock в атрибуте Mds-Time-lnfo (см. таблицу 3). Агент, поддерживающий Set-Base-Offset-Time, должен возвратить параметр rors-cmip-confirmed-action, однако в этом ответе поле action-info-args пустое. Агент, не поддерживающий Set-Base-Offset-Time, должен возвратить ошибку no-such-action (roer). Если поле секунд базового времени и поле дробной части секунд базового времени заданы равными 0x0 в аргументах действия Set-Base-Offset-Time (эти значения не определены в сетевом протоколе службы времени (NTP)), должно задаваться только смещение по местному времени. Если базовое время (поле секунд) согласуется с всемирным координированным временем (UTC) (с точностью, соответствующей применению), это должно быть обозначено, задав бит mds-time-state-bo-time-utc-aligned в атрибуте Mds-Time-lnfo.

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

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

Таблица 5 содержит сведения о потенциальных событиях, передаваемых объектом MDS. Менеджер должен поддерживать все методы, указанные в таблице 5. Если объект MDS использует подтверждаемый отчет о событии, то в любой момент времени допустимо получение от этого объекта не более одного неквитированного подтверждаемого отчета о событии.

Таблица 5 - События объектов MDS

- MDS-Configuration-Event

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

- MDS-Dynamic-Data-Update-Var

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

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

- MDS-Dynamic-Data-Update-Fixed

Данное событие предоставляет динамические данные (обычно результаты измерений) от агента для некоторых или всех объектов результатов измерений либо объекта MDS, поддерживаемых агентом. Данные сообщаются в фиксированном формате, определяемом атрибутом Attribute-Value-Map для сообщаемых объектов результатов измерений или объекта MDS (дополнительные сведения о форматах отчетов о событиях см. в 7.4.5). Событие инициируется запросом MDS-Data-Request от системы менеджера (т.е. передача результатов измерений, инициируемая менеджером) или передается агентом как незапрашиваемое сообщение (т.е. передача результатов измерений, инициируемая агентом). Информация об управлении активацией и/или периодом передачи данных у агентов, поддерживающих инициированную менеджером передачу результатов измерений, представлена в 8.9.3.3.3. Информация об ограниченном управлении со стороны менеджера агентами, не поддерживающими инициируемую менеджером передачу результатов измерений, представлена в 8.9.3.3.2.

- MDS-Dynamic-Data-Update-MP-Var

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

- MDS-Dynamic-Data-Update-MP-Fixed

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

6.3.2.6 Прочие службы MDS

6.3.2.6.1 Служба GET

Для извлечения значений всех реализованных атрибутов объектов MDS любой агент, поддерживающий двустороннюю коммуникацию, должен поддерживать службу GET. Служба GET должна вызываться менеджером сразу после перехода в состояние "Конфигурирующий"/"Передающий GetMDS". Менеджер должен ожидать ответ на GET перед вызовом каких-либо действий. Ожидание ответа на GET позволяет менеджеру определить, нуждается ли агент в настройке времени. Агент, запросивший настройку своего времени, должен ожидать действие Set-Time перед переходом в состояние "Выполнение".

Служба GET может вызываться, когда агент находится в подсостоянии "Конфигурирующий"/"ожидающий MDS", "Конфигурирующий"/"ожидающий SetTime" или "Выполнение".

За исключением атрибута Date-and-Time-Adjustment, если менеджер не имеет текущее значение необходимого атрибута MDS, должна использоваться служба GET. Агент может также отправлять отчеты о событиях сканера, предоставляющие менеджеру обновления текущих значений атрибутов, однако такое поведение агента не обязательно, кроме исключений, описанных для attribute-value-map и date-and-time-adjustment в таблице 3.

Менеджер может запросить атрибуты объекта MDS агента. В этом случае менеджер должен отправить команду "Remote Operation Invoke | Get" (см. описание roiv-cmip-get в А.10.2) с зарезервированным нулевым значением дескриптора. Агент должен сообщить менеджеру свои атрибуты объекта MDS, используя команду ответа "Remote Operation Response | Get" (см. описание rors-cmip-get в А.10.2). В ответ на команду Get MDS Object возвращаются только атрибуты, реализованные агентом. Подробное описание операции GET см. в 8.9.3.2.

Примечание - Некоторые требования (например, агент должен запрашивать у менеджера настройку своего времени или передавать временно хранимые данные в фиксированном формате вместе с Date-and-Time-Adjustment) вынуждают менеджера запрашивать от агента объект MDS. Практика также показала, что запросы, которые уже переданы прибору агента перед отправкой запроса GET после AARE accepted-unknown-config (обязывают агента асинхронно обрабатывать потенциально большие отчеты о конфигурации и ответы на GET), зачастую служили причиной тайм-аутов и прочих проблем. Текущие руководства по отношению к запросам GET сформулированы с целью устранения этих проблем.

6.3.2.6.2 Служба SET

На сегодняшний день служба MDS SET, определенная в настоящем стандарте, не используется, однако могут существовать специализации приборов, определенные в стандартах серии ISO/IEEE 11073-104zz, или местные определения, которые ее задействуют.

      6.3.3 Класс Metric

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

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

6.3.3.2 Идентификация класса Metric

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

6.3.3.3 Атрибуты класса Metric

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

Таблица 6 - Атрибуты класса Metric

Имя атрибута	Идентификатор атрибута	Тип атрибута	Примечание	Квалифи- каторы
Handle	MDC_ATTR_ ID_HANDLE	HANDLE	Атрибут Handle представляет собой ссылочный идентификатор этого объекта. Каждый объект должен иметь уникальный идентификатор, присвоенный агентом. Атрибут Handle идентифицирует объект в отчетах о событиях, передаваемых менеджеру	Обяза- тельный, стати- ческий
Туре	MDC_ATTR_ ID_TYPE	TYPE	Данный атрибут определяет специфичный статический тип этого объекта в соответствии с номенклатурой (например, частота пульса для специфичного экземпляра объекта Numeric). Атрибут Туре содержит идентификаторы раздела номенклатуры и кода термина для контекстно-свободной расширяемой идентификации	Обяза- тельный, стати- ческий
Supplemental- Types	MDC_ATTR_ SUPPLEMENTAL_ TYPES	Supplemental- TypeList	Данный атрибут может использоваться для передачи дополнительной информации об объекте помимо атрибутов Туре и Metric-Id. Дополнительная информация охватывает различные условия, например местоположение датчика или скорость реагирования объекта на изменения. Специализации приборов определяют предполагаемое применение данного атрибута. Например, IEEE 11073-10471 [В11] определяет номенклатуру расположения, указывая местоположение датчика в доме, а ISO/IEEE 11073-10404 [В18] указывает три дополнительных типа для быстрого ответа, медленного ответа и выборочной проверки частоты пульса или насыщения крови кислородом	Необяза- тельный, динами- ческий
Metric-Spec- Small	MDC_ATTR_ METRIC_ SPEC_ SMALL	MetricSpecSmall	Атрибут "Metric-Spec-Small" описывает характеристики измерений. Данный динамический атрибут позволяет агенту изменить значения битов до отправки первых результатов наблюдений (например, настроить стандартную конфигурацию). После отправки результатов наблюдения агент не должен изменять значение этого атрибута	Обяза- тельный, динами- ческий
Metric-Structure- Small	MDC_ATTR_ METRIC_ STRUCT_SMALL	MetricStructure Small	Этот атрибут описывает структуру результатов измерений. В случае отсутствия этого атрибута менеджер должен предполагать, что MetricStructureSmall := {ms- struct-simple, 0}. Данный динамический атрибут позволяет агенту изменить значения параметров до отправки первых результатов наблюдений (например, настроить стандартную конфигурацию). После отправки результатов наблюдения агент не должен изменять значение этого атрибута	Необяза- тельный, динами- ческий
Measurement- Status	MDC_ATTR_ MSMT_STAT	MeasurementStatus	Данный атрибут указывает допустимость конкретного значения или набора считываний. Если объект Scanner предоставляет RTSA и существует вероятность того, что от Scanner может потребоваться отчет об отсутствующих результатах измерений (см. 6.3.9.2), этот атрибут должен присутствовать	Условно обяза- тельный, наблю- даемый
Metric-Id	MDC_ATTR_ ID_PHYSIO	OID-Type	Данный атрибут может использоваться для хранения идентификационной информации, которая более специфична по сравнению с общим идентификатором ID в атрибуте Туре. Если атрибуту Metric-Id-Partition присвоено значение, он определяет номенклатурный раздел для атрибута Metric-Id. Иначе OID-Type заимствуется из номенклатурного раздела, указанного в поле раздела атрибута Туре. Данный атрибут необходим только в случае изменения идентификационной информации во время работы, когда атрибут Туре не обеспечивает полную идентификацию. Например, если атрибут Туре содержит общий код температуры, код (MDC_TEMP), данный атрибут может сообщить специфичную, но изменяющую идентификацию оральной температуры MDC_TEMP_ORAL или ректальной температуры MDC_TEMP_RECT.   Должен присутствовать только один из атрибутов, Metric-Id или Metric-Id-List	Необяза- тельный, динами- ческий
Metric-Id-List	MDC_ATTR_ ID_PHYSIO_LIST	MetricldList	Данный атрибут должен использоваться для составного наблюдаемого значения и непосредственно не включает в себя Metric-Id (например, Соmpound-Simple-Nu-Observed- Value или Compound-Basic-Nu- Observed-Value), чтобы обеспечить возможность индивидуальной идентификации элементов в списке наблюдаемых значений. Порядок элементов Metric-Id-List должен соответствовать порядку элементов в составном наблюдаемом значении. Должен присутствовать только один из атрибутов, Metric-Id или Metric-Id-List	Условно обяза- тельный, динами- ческий
Metric-Id- Partition	MDC_ATTR_ METRIC_ID_PART	NomPartition	Данный атрибут может использоваться для определения раздела, из которого взяты номенклатурные термины для Metric-Id или Metric-Id-List. Если атрибут отсутствует, раздел совпадает с номенклатурным разделом, указанным в поле раздела атрибута Туре	Необяза- тельный, динами- ческий
Unit-Code	MDC_ATTR_ UNIT_CODE	OID-Type	Данный атрибут определяет номенклатурный код единиц измерения, взятый из раздела nom-part-dim (например, MDC_DIM_KILO_G). Префиксы единиц измерения должны генерироваться согласно стандартам IEEE 1541-2002 и ISO/IEC 80000-13:2008	Необяза- тельный, динами- ческий
Attribute- Value- Map	MDC_ATTR_ ATTRIBUTE_ VAL_MAP	AttrValMap	Данный атрибут определяет атрибуты, передаваемые в сообщениях фиксированного формата об изменении данных. Если для отчета о динамических результатах измерений, хранящихся в объекте, агент использует сообщения с фиксированным форматом, то этот атрибут должен быть задан до отправки такого отчета. Значение этого атрибута может меняться между передачами отчетов о событиях	Условно обяза- тельный, динами- ческий
Source- Handle- Reference	MDC_ATTR_ SOURCE_ HANDLE_REF	HANDLE	Данный атрибут устанавливает отношение этого экземпляра объекта к объекту-источнику (например, пульс ссылается на источник SpО2). Данный атрибут используется в тех случаях, когда необходимо моделировать явное соотношение между экземплярами объектов для определения зависимостей. Использование этого атрибута определяется специализациями приборов. Объект Metric может содержать только один из атрибутов, Source-Handle-Reference или Source-Handle-Reference-List	Необяза- тельный, динами- ческий
Source- Handle- Reference-List	MDC_ATTR_ SOURCE_ HANDLE_REF_ LIST	HANDLEList	Данный атрибут устанавливает отношение этого экземпляра объекта к нескольким объектам-источникам (например, индекс массы тела (BMI) ссылается на источники рост и вес). Данный атрибут используется в тех случаях, когда необходимо моделировать явное соотношение между экземплярами объекта для определения зависимостей. Использование этого атрибута определяется специализациями приборов. Объект Metric может содержать только один из атрибутов, Source-Handle- Reference или Source-Handle- Reference-List	Необяза- тельный, динами- ческий
Label-String	MDC_ATTR_ID_ LABEL_STRING	OCTET STRING	Данный атрибут определяет текстовое представление атрибута Туре в печатаемых символах кодировки ASCII. Значение этого атрибута задается по полному усмотрению производителя агента. Потенциально может оказаться полезным для менеджера в качестве изображаемой строки или при принятии решения о выборе поведения, когда он не может понять значение MDC_ATTR_ID_TYPE, отправленное агентом	Необяза- тельный, динами- ческий
Unit- LabelString	MDC_ATTR_ UNIT_LABEL_ STRING	OCTET STRING	Данный атрибут определяет текстовое представление размерности Unit-Code в печатаемых символах кодировки ASCII. Значение этого атрибута задается по полному усмотрению производителя агента. Потенциально может оказаться полезным для менеджера в качестве изображаемой строки или при принятии решения о выборе поведения, когда он не может понять значение MDC_ATTR_UNIT_CODE, отправленное агентом	Необяза- тельный, динами- ческий
Absolute- Time-Stamp	MDC_ATTR_ TIME_STAMP _ABS	AbsoluteTime	Данный атрибут определяет дату и время наблюдения с точностью до 1/100 секунды (если возможно). Дополнительную информацию об этом атрибуте см. в 8.12. Агент, хранящий данные (в объекте PM-store или как "временно хранимые измерения"), должен сопоставлять с этими данными одну и только одну метку времени (Absolute-Time-Stamp, Base-Offset-Time-Stamp, Relative-Time-Stamp или HiRes-Time-Stamp). Если этот атрибут используется, атрибут Base-Offset-Time-Stamp не должен использоваться	Условно обяза- тельный, наблю- даемый
Base-Offset- Time-Stamp	MDC_ATTR_ TIME_STAMP_ BO	BaseOffsetTime	Данный атрибут определяет базовые дату и время наблюдения, а также смещение в минутах по местному времени. Дополнительную информацию об этом атрибуте см. в 8.12. Агент, хранящий данные (в объекте PM-store или как "временно хранимые измерения"), должен сопоставлять с данными одну и только одну метку времени (Absolute-Time-Stamp, Base-Offset-Time-Stamp, Relative-Time-Stamp или HiRes-Time-Stamp). Если этот атрибут используется, атрибут Absolute-Time-Stamp не должен использоваться	Условно обяза- тельный, наблю- даемый
Relative-Time- Stamp	MDC_ATTR_ TIME_STAMP_ REL	RelativeTime	Данный атрибут определяет время наблюдения (метку времени в формате относительного времени/числа тактов часов согласно типу данных RelativeTime). Агент, хранящий данные, должен сопоставлять с данными одну и только одну метку времени (Absolute-Time-Stamp, Base-Offset-Time-Stamp, Relative-Time-Stamp или HiRes-Time-Stamp)	Условно обяза- тельный, наблю- даемый
HiRes-Time- Stamp	MDC_ATTR_ TIME_STAMP_ REL_HI_RES	HighResRelative Time	Данный атрибут определяет время наблюдения (метку времени в формате высокоточного относительного времени/числа тактов часов согласно типу данных HighResRelativeTime). Агент, хранящий данные, должен сопоставлять с данными одну и только одну метку времени (Absolute-Time-Stamp, Base-Offset-Time-Stamp, Relative-Time-Stamp или HiRes-Time-Stamp)	Условно обяза- тельный, наблю- даемый
Measure- Active-Period	MDC_ATTR_ TIME_PD_ MSMT_ACTIVE	FLOAT-Type	Данный атрибут определяет длительность периода наблюдения в секундах.   По умолчанию этот атрибут считается динамическим, однако стандарты ISO/IEEE 11073-104zz могут определять его в качестве наблюдаемого с учетом потребностей варианта использования	Необяза- тельный, динами- ческий или наблю- даемый

6.3.3.4 Методы объектов Metric

В настоящем стандарте отсутствуют определения методов объектов Metric, однако они могут существовать в специализациях приборов ISO/IEEE 11073-104zz или в местных документах.

6.3.3.5 События объектов Metric

Объекты, которые произведены от класса Metric, не сообщают напрямую о результатах наблюдений; эти результаты передаются с помощью другого объекта, например объекта системы MDS, объекта Scanner или объекта PM-store.

6.3.3.6 Прочие службы класса Metric

На сегодняшний день службы SET или GET класса Metric, определенные в настоящем стандарте, не используются, однако могут существовать специализации приборов, определенные в стандартах серии ISO/IEEE 11073-104zz, или местные определения, которые их задействуют.

      6.3.4 Класс Numeric

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

Экземпляр класса Numeric представляет числовой результат измерения. Значения объекта Numeric передаются от агента к менеджеру с помощью службы EVENT REPORT (см. 7.3). Данный класс произведен от базового класса Metric.

6.3.4.2 Идентификация класса Numeric

Для идентификации класса Numeric используется номенклатурный код MDC_MOC_VMO_METRIC_NU.

6.3.4.3 Атрибуты класса Numeric

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

Таблица 7 - Атрибуты класса Numeric

Атрибуты Compound-Simple-Nu-Obs-Value, Compound-Basic-Nu-Obs-Value и Compound-Nu-Observed-Value представляют концепцию списка для наблюдаемых значений. Данную концепцию необходимо использовать в тех случаях, когда между отдельными наблюдаемыми значениями задана сильная взаимосвязь, которая может зависеть от номенклатуры и/или применения. Составные наблюдаемые значения используют общий контекст статической атрибуции, кроме идентификации элементов. Примером этого может служить применение кровяного давления, когда номенклатурный базовый термин обозначает "кровяное давление", а более специфические термины соответствуют "систолическому кровяному давлению", "диастолическому кровяному давлению" и "среднему кровяному давлению". Соответствующий DIM должен содержать только один экземпляр объекта Numeric, который будет использовать один из форматов составных числовых наблюдаемых значений для представления "систолической", "диастолической" и "средней" частей "кровяного давления".

6.3.4.4 Методы объектов Numeric

В настоящем стандарте отсутствуют определения методов объектов Numeric, однако они могут существовать в специализациях приборов ИСО/ИИЭР 11073-104zz или в местных документах.

6.3.4.5 События объектов Numeric

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

6.3.4.6 Прочие службы класса Numeric

На сегодняшний день службы SET или GET класса Numeric, определенные в настоящем стандарте, не используются, однако могут существовать специализации приборов, определенные в стандартах серии ИСО/ИИЭР 11073-104zz, или местные определения, которые их задействуют.

      6.3.5 Класс RT-SA

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

Экземпляр класса RT-SA представляет измерение формы сигнала. Значения объекта RT-SA передаются от агента к менеджеру с помощью службы EVENT REPORT (см. 7.3). Данный класс произведен от базового класса Metric.

6.3.5.2 Идентификация класса RT-SA

Для идентификации класса RT-SA используется номенклатурный код MDC_MOC_VMO_METRIC_SA_RT

6.3.5.3 Атрибуты класса RT-SA

Таблица 8 содержит описание набора атрибутов класса RT-SA, поддерживаемых для обмена данными с персональными медицинскими приборами.

Таблица 8 - Атрибуты класса RT-SA

Характеристики объекта RT-SA можно получить, анализируя атрибут Sa-Specification. Данный атрибут определяет число элементов в массиве и их размер (подробнее см. в А.3.4).

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

- Scale-and-Range-Specification

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

Y=M

X + B,

где

Y = преобразованная абсолютная величина;

М = (верхнее абсолютное значение - нижнее абсолютное значение) / (верхнее масштабированное значение - нижнее масштабированное значение);

В = верхнее абсолютное значение - (М

верхнее масштабированное значение);

X = масштабированное значение.

Пример использования этого алгоритма приведен в приложении В.

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

6.3.5.4 Методы объектов RT-SA

В настоящем стандарте отсутствуют определения методов объектов RT-SA, однако они могут существовать в специализациях приборов ИСО/ИИЭР 11073-104zz или в местных документах.

6.3.5.5 События объектов RT-SA

В настоящем стандарте события объектов RT-SA не определены.

6.3.5.6 Прочие службы класса RT-SA

На сегодняшний день службы SET или GET класса Numeric, определенные в настоящем стандарте, не используются, однако могут существовать специализации приборов, определенные в стандартах серии ИСО/ИИЭР 11073-104zz, или местные определения, которые их задействуют.

      6.3.6 Класс Enumeration

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

Экземпляр класса Enumeration представляет информацию о статусе и/или аннотации. Значения объекта Enumeration кодируются в форме нормативных кодов (согласно ИСО/ИИЭР 11073-10101 [В16]) или произвольного текста. Значения объекта Enumeration передаются от агента к менеджеру с помощью службы EVENT REPORT (см. 7.3). Данный класс произведен от базового класса Metric.

6.3.6.2 Идентификация класса Enumeration

Для идентификации класса Enumeration используется номенклатурный код MDC_MOC_VMO_METRIC_ENUM.

6.3.6.3 Атрибуты класса Enumeration

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

Таблица 9 - Атрибуты класса Enumeration

6.3.6.4 Методы объектов Enumeration

В настоящем стандарте отсутствуют определения методов объектов Enumeration, однако они могут существовать в специализациях приборов ИСО/ИИЭР 11073-104zz или в местных документах.

6.3.6.5 События объектов Enumeration

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

6.3.6.6 Прочие службы объектов Enumeration

На сегодняшний день службы SET или GET класса Enumeration, определенные в настоящем стандарте, не используются, однако могут существовать специализации приборов, определенные в стандартах серии ИСО/ИИЭР 11073-104zz, или местные определения, которые их задействуют.

      6.3.7 Класс PM-store

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

Экземпляр класса PM-store предоставляет возможности длительного хранения данных класса Metric. Данные хранятся в переменном числе объектов (сегментов) PM-segment (см. 6.3.8). Хранимые данные объекта PM-store запрашиваются менеджером у агента с помощью служб доступа к объектам (см. 7.3). Если понятие класса PM-store не известно, то перед тем, как ознакомиться со следующими подпунктами, можно ознакомиться с концептуальным обзором, приведенным в приложении С.

Для описания измерений может потребоваться дополнение значений атрибутов, хранящихся в сегменте PM-segment, дополнительными атрибутами этого объекта. Типичным примером могут служить единицы измерения. Если значение атрибута сегмента PM-segment зависит от значения атрибута, не хранящегося в этом сегменте, то такой зависимый атрибут не должен изменять значение в течение срока существования сегмента PM-segment. Иначе агент должен хранить значение зависимого атрибута в сегменте PM-segment.

6.3.7.2 Идентификация класса PM-store

Для идентификации класса PM-store используется номенклатурный код MDC_MOC_VMO_PMSTORE.

6.3.7.3 Атрибуты класса PM-store

Таблица 10 содержит описание набора атрибутов класса PM-store, поддерживаемых для обмена данными с персональными медицинскими приборами.

Таблица 10 - Атрибуты класса PM-store

Атрибуты Handle и PM-Store-Capab являются частью конфигурации агента; следовательно, менеджер знает значения соответствующих атрибутов после процедуры конфигурирования.

6.3.7.4 Методы объектов PM-store

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

Таблица 11 - Методы объектов PM-store

Если агент поддерживает класс PM-store, поддержка метода Get-Segment-Info или Get-Segment-Id-List обязательна, и поддержка метода Trig-Segment-Data-Xfer также обязательна. Поддержка метода Clear-Segments не обязательна и указывается в атрибуте PM-Store-Capab.

Если менеджер поддерживает класс PM-store, поддержка вызова методов Get-Segment-Info, Get-Segment-Id-List и Trig-Segment-Data-Xfer обязательна. Поддержка вызова метода Clear-Segments не обязательна.

- Clear-Segments

Данный метод позволяет менеджеру удалить данные, хранимые в одном или нескольких выбранных сегментах PM-segment. Все записи в этих объектах удаляются. Если агент поддерживает переменное количество сегментов PM-segment, агент может удалить пустые объекты PM-segment. Кроме того, агент может очистить сегменты PM-segment без команды от менеджера (например, пользователь агента может удалить данные, хранимые агентом), однако, если это действие выполняется в состоянии "Ассоциирован", атрибут Instance-Number должен оставаться действительным и ссылаться на пустой объект PM-segment в течение срока существования ассоциации. Атрибут Instance-Number всех остальных сегментов PM-segment должен оставаться неизменным при очистке сегмента.

Удаление всех выбранных сегментов PM-segment не гарантируется этим методом. Если у сегмента PM-segment атрибут Operational-State активен, то запрошенное удаление не будет выполнено. Кроме того, агент может принять решение о защите определенных сегментов от удаления, присвоив им статус "только для чтения" (например, пользователь агента решил "заблокировать" определенные данные). Защищенные и незащищенные сегменты останутся неизменными при выполнении операции clear-segments.

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

Если все выбранные сегменты оказались неочищенными (вследствие защиты или активного использования), агент должен сообщить об ошибке not-allowed-by-object (roer). Код возврата должен задаваться равным MDC_RET_CODE_OBJ_BUSY, если какие-либо сегменты не удается очистить вследствие активного использования. Иначе код возврата должен равняться MDC_RET_CODE_UNKNOWN, указывая, что во время выполнения операции обнаружены только сегменты, защищенные агентом.

При очистке объектов PM-segment с помощью метода time с использованием абсолютного времени очищаются только те объекты PM-segment, поля Segment-Start-Abs-Time и Segment-End-Abs-Time которых находятся полностью внутри указанного интервала времени.

При очистке объектов PM-segment с помощью метода time с использованием базового времени и смещения очищаются только те объекты PM-segment, поля Segment-Start-BO-Time и Segment-End-BO-Time которых находятся полностью внутри указанного интервала времени. При использовании Segment-Start-BO-Time и Segment-End-BO-Time базовое время должно иметь действительное значение (например, ненулевое значение). Если поле смещения имеет значение 0x7FFF (32767), очищаются только те объекты PM-segment, базовое время которых находится полностью внутри указанного интервала. При любом другом значении поля смещения очищаются только те объекты PM-segment, местное время (базовое время с добавленным смещением) которых находится полностью внутри указанного интервала.

Необходимо отметить, что поведение метода Clear-Segments зависит от конкретного приложения. Метод может удалить все записи из определенного сегмента PM-segment, оставив его пустым, или может полностью удалить указанный сегмент PM-segment. Данное поведение определяется атрибутом PM-Store-Capab. Для специфичных приложений рекомендации формулируются в соответствующих специализациях приборов, применяющих объекты PM-store.

Агент, поддерживающий метод Clear-Segments, должен поддерживать для поля action-info-args типа SegmSelection, передаваемого при вызове этого метода, как минимум вариант all-segments (все сегменты).

Если агент поддерживает вариант all-segments для поля action-info-args типа SegmSelection, передаваемого при вызове метода Clear-Segments, то агент должен установить в атрибуте PM-Store-Capab флаг pmsc-clear-segm-all-sup. Если агент поддерживает вариант segm-id-list (список идентификаторов сегментов) для поля action-info-args типа SegmSelection, передаваемого при вызове метода Clear-Segments, то агент должен установить в атрибуте PM-Store-Capab флаг pmsc-clear-segm-by-list-sup. Если агент поддерживает вариант abs-time-range (диапазон абсолютного времени) или bo-time-range (диапазон базового времени и смещения) для поля action-info-args типа SegmSelection, передаваемого при вызове метода Clear-Segments, то агент должен установить флаг pmsc-clear-segm-by-time-sup в атрибуте PM-Store-Capab.

Если агент не поддерживает действие Clear-Segments, инициированное менеджером, то он должен возвратить ошибку no-such-action (roer).

Если менеджер поддерживает отправку метода Clear-Segments, то он должен поддерживать как минимум вариант all-segments для поля action-info-args типа SegmSelection, передаваемого при вызове этого метода. Менеджер может поддерживать дополнительные варианты выбора.

Если ни один объект PM-segment не соответствует критериям, указанным в поле action-info-args типа SegmSelection, и никакой объект PM-segment не очищается действием, то это не считается ошибкой и передается нормальный ответ.

- Get-Segment-Info

Данный метод позволяет менеджеру извлечь атрибуты объекта PM-segment из одного или нескольких объектов PM-segment, за исключением атрибута Fixed-Segment-Data, который содержит фактические сохраненные данные и извлекается с помощью метода Trig-Segment-Data-Xfer. В частности, метод Get-Segment-Info позволяет менеджеру извлечь атрибуты и их данные из экземпляров объектов PM-segment, идентифицируемых параметром типа SegmSelection.

Агент, поддерживающий метод Get-Segment-Info, должен поддерживать для поля action-info-args типа SegmSelection, передаваемого при вызове этого метода, вариант all-segments. Агент может поддерживать варианты segm-id-list, abs-time-range и/или bo-time-range для поля action-info-args типа SegmSelection, передаваемого при вызове метода Get-Segment-Info. В этом случае агент должен установить флаг pmsc-segm-id-list-select и/или pmsc-abs-time-select атрибута PM-Store-Capab. Если менеджер отправляет метод Get-Segment-Info с вариантом, не поддерживаемым агентом, то агент должен сообщить об ошибке неподдерживаемого варианта (unsupported-choice, roer).

Для информации об объектах PM-segment, возвращаемой по заданному диапазону времени, сегменты выбираются с использованием алгоритма, описанного для метода Clear-Segments.

Если менеджер поддерживает отправку метода Get-Segment-Info, то он должен поддерживать как минимум вариант all-segments для поля action-info-args типа SegmSelection, передаваемого при вызове этого метода. Менеджер может поддерживать дополнительные варианты выбора.

Если стандартная конфигурация содержит какой-либо объект PM-store, менеджер должен отправить метод Get-Segment-Info или Get-Segment-Id-List в начале доступа к любому объекту PM-store.

Если ни один объект PM-segment не соответствует критериям, указанным в поле action-info-args типа SegmSelection, и никакой объект PM-segment не обнаружен, то это не считается ошибкой, передается нормальный ответ, и список информации о сегментах будет просто пустым.

Если для поля action-info-args типа SegmSelection использован вариант segm-id-list, имеющий пустое значение, то ответом должен быть пустой результат segment-info-list.

Если агент поддерживает метод Get-Segment-Info, то он должен установить в атрибуте PM-Store-Capab флаг pmsc-get-segm-info-sup.

- Get-Segment-Id-List

Данный метод позволяет менеджеру извлечь список номеров экземпляров всех PM-segment PM-store. В частности, метод Get-Segm-ld-List позволяет менеджеру затем извлечь атрибуты выбранных экземпляров объектов PM-segment и их данные без необходимости извлечения информации всех PM-segment. Кроме того, менеджер может извлечь несколько PM-segment с помощью последовательности запросов.

Если стандартная конфигурация содержит какой-либо объект PM-store, менеджер должен отправить Get-Segment-Info или Get-Segment-Id-List в начале доступа к любому объекту PM-store.

Если агент поддерживает метод Get-Segment-Id-List, то он должен установить флаг pmsc-get-segm-id-list-sup в атрибуте PM-Store-Capab.

- Trig-Segment-Data-Xfer

Данный метод позволяет менеджеру начать передачу атрибута Fixed-Segment-Data заданного сегмента PM-segment. Агент указывает в ответе, принимает ли он или отклоняет этот запрос. Если агент принимает запрос, то он посылает сообщения Segment-Data-Event в соответствии с 6.3.7.5. Если сегмент PM-segment, указанный в данном методе, имеет активный атрибут Operational-State, то агент должен возвратить ошибку not-allowed-by-object (roer) с кодом возврата MDC_RET_CODE_OBJ_BUSY.

6.3.7.5 События объектов PM-store

Таблица 12 определяет потенциальные события, передаваемые объектом PM-store.

Таблица 12 - События объектов PM-store

- Segment-Data-Event

По этому событию данные, хранящиеся в атрибуте Fixed-Segment-Data сегмента PM-segment, передаются от агента к менеджеру. Данное событие инициируется менеджером с помощью метода Trig-Segment-Data-Xfer. После инициирования передачи данных агент посылает сообщения о событии Segment-Data-Event до момента полной передачи содержания атрибута Fixed-Segment-Data или прерывания передачи со стороны менеджера или агента. Полное описание передачи содержания сегмента PM-segment см. в 8.9.3.4.2.

Рекомендуется помещать в одно сообщение о событии Segment-Data-Event максимально возможное число записей, хранящихся в сегменте PM-segment, чтобы уменьшить количество сообщений, необходимых для передачи содержания сегмента. Агент должен передавать все записи, хранящиеся в сегменте, в порядке "первым пришел - первым ушел" (FIFO: first-in, first-out).

Поддержка события агентом обязательна, если агент поддерживает объекты PM-store.

Если подтверждаемый отчет о событии используется объектом PM-store, то в любой момент времени допустимо получение от этого объекта не более одного неквитированного подтверждаемого отчета о событии.

6.3.7.6 Прочие службы PM-store

6.3.7.6.1 Служба GET

Поддержка службы GET должна обеспечиваться любым агентом, поддерживающим один и более объектов PM-store, только пока находится в состоянии "Выполнение". Менеджер использует службу GET в целях извлечения значений всех атрибутов объекта PM-store. Если менеджер не имеет текущее значение необходимого атрибута PM-store, то должна использоваться служба GET. Агент может также отправлять отчеты о событиях сканера, предоставляющие менеджеру обновления текущих значений атрибутов, однако такое поведение агента не обязательно.

Менеджер может запросить у агента атрибуты объекта PM-store, для чего должен послать команду "Remote Operation Invoke | Get" (см. roiv-cmip-get в А.10.2) со значением дескриптора объекта PM-store, определенного в конфигурации агента. Агент должен возвратить менеджеру отчет с атрибутами объекта PM-store, используя ответ "Remote Operation Response | Get" (см. rors-cmip-get в А.10.2). Подробное описание операции GET см. в 8.9.3.4.2.

6.3.7.6.2 Служба SET

На сегодняшний день служба SET PM-store, определенная в настоящем стандарте, не используется, однако могут существовать специализации приборов, определенные в стандартах серии ИСО/ИИЭР 11073-104zz, или местные определения, которые ее задействуют.

      6.3.8 Класс PM-segment

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

Экземпляр класса PM-segment представляет собой постоянно хранимый эпизод измерений данных. Объект (сегмент) PM-segment не является частью статической конфигурации агента, поскольку количество созданных экземпляров сегментов PM-segment может динамично меняться. Менеджер осуществляет опосредованный доступ к сегментам PM-segment с помощью методов и событий объекта PM-store.

6.3.8.2 Идентификация класса PM-segment

Для идентификации класса PM-segment используется номенклатурный код MDC_MOC_PM_SEGMENT.

6.3.8.3 Атрибуты класса PM-segment

Таблица 13 содержит описание набора атрибутов класса PM-segment, поддерживаемых для обмена данными с персональными медицинскими приборами.

Таблица 13 - Атрибуты класса PM-segment

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

Атрибут Fixed-Segment-Data хранит массив одинаково форматированных записей. Если результаты измерения недоступны в определенный момент времени, значение численного измерения, представленного типом данных (S)FLOAT-type, должно использовать специальное значение NaN (не число) для обозначения недоступности значения.

В зависимости от возможностей агента и приложения атрибут Fixed-Segment-Data может содержать очень большие объемы данных. Агент может ограничить максимальный размер атрибута Fixed-Segment-Data, чтобы таким образом согласовать его с максимальным размером блока передачи транспортной системы. Для реализации такого поведения менеджер, поддерживающий объект PM-store, должен быть способен принимать атрибуты Fixed-Segment-Data в нескольких прикладных сообщениях.

6.3.8.4 Методы объектов PM-segment

В настоящем стандарте методы объектов PM-segment не определены.

6.3.8.5 События объектов PM-segment

В настоящем стандарте события объектов PM-segment не определены.

6.3.8.6 Прочие службы объектов PM-segment

На сегодняшний день службы SET и GET объектов PM-segment, определенные в настоящем стандарте, не используются.

      6.3.9 Классы Scanner

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

Класс Scanner используется для двух целей: (1) обеспечивает менеджеру возможность управления потоком данных, и (2) обеспечивает оптимизированный (по сравнению с использованием событий класса MDS) механизм компоновки и передачи отчетов. Он позволяет более эффективно добавлять в один отчет о событии различные наборы изменений значений атрибутов (AttributeChangeSet), полученные от одного или нескольких объектов Metric. У класса Scanner есть потомки EpCfgScanner и PeriCfgScanner, описывающие соответственно эпизодическое и периодическое сканирование. В отчетах о событиях сканирования оба этих объекта могут передаваться в переменном, фиксированном или групповом формате (см. 7.4.5). Иерархия класса Scanner и его потомков показана на рисунке 5. Каждый класс описан соответственно в 6.3.9.3-6.3.9.6.

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

6.3.9.2 Концептуальная модель

Объект Scanner не сканирует объекты (то есть не считывает состояние объекта и не сообщает о том, произошли или нет какие-либо изменения). Вместо этого объект Scanner собирает наборы AttributeChangeSet и отображает их в структуру ObservationScan отчета о событиях сканирования. Объекты эпизодического сканирования (EpiCfgScanner) передают отчеты о событиях сканирования после завершения эпизода. Что считать эпизодом, определяется приложением, однако обычно он соответствует одному или нескольким наборам AttributeChangeSet (один и тот же объект не генерирует два набоpa AttributeChangeSet), возникающим эпизодически (интервал времени между эпизодами неизвестен). Объекты периодического сканирования (PeriCfgScanner) передают отчеты о событиях сканирования по истечении периода времени, указанного в атрибуте Reporting-lnterval, при этом от одного и того же объекта может быть получено несколько наборов AttributeChangeSet.

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

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

- Любому набору AttributeChangeSet, содержащему значения наблюдаемого атрибута, полученные от объекта Numeric (см. таблицу 7), присваивается значение NaN. Если набор AttributeChangeSet содержит атрибут Measurement-Status, то в зависимости от ситуации он должен указывать, что значение недействительное или недоступное.

- Любой набор AttributeChangeSet, содержащий значения Simple-Sa-Observed-Value объекта RT-SA, должен содержать атрибут Measurement-Status. В зависимости от ситуации атрибут Measurement-Status должен указывать, что значение недействительное или недоступное. В этом случае значения Simple-Sa-Observed-Value не определены и менеджер должен игнорировать сообщаемые значения.

- Любому набору AttributeChangeSet, содержащему значения наблюдаемого атрибута, полученные от объекта Enumeration (см. таблицу 9), должно быть присвоено подходящее перечислимое значение. При необходимости он должен содержать атрибут Measurement-Status. В зависимости от ситуации атрибут Measurement-Status должен указывать, что значение недействительное или недоступное. Если атрибут Measurement-Status используется, чтобы указать недействительность или недоступность, менеджер должен игнорировать сообщаемое значение.

- Если объектом EpiCfgScanner не собран ни один набор AttributeChangeSets, отчет о событиях сканирования не должен передаваться.

- Если объектом PeriCfgScanner не собран ни один набор AttributeChangeSets, должен передаваться пустой отчет о событиях сканирования.

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

- В структуру ObservationScan отображаются только собранные наборы AttributeChangeSet.

- Если объектом EpiCfgScanner не собран ни один набор AttributeChangeSets, отчет о событиях сканирования не должен передаваться.

- Если объектом PeriCfgScanner не собран ни один набор AttributeChangeSets, должен передаваться пустой отчет о событиях сканирования.

Периодический сканер PeriCfgScanner отличается от эпизодического EpiCfgScanner способностью получать несколько наборов AttributeChangeSet от одного объекта перед отправкой. Периодическому Scanner также требуется, чтобы скорость генерирования всех собранных наборов AttributeChangeSet имела постоянную временную связь с периодом сканера. Если набор AttributeChangeSet не имеет явно заданной метки времени, соответствующая метка времени должна определяться на основе метки времени отчета о событии сканирования. Из этого следует, что любой набор AttributeChangeSet, полученный в момент времени, отличающийся от времени отчета о событии сканирования, должен передаваться со своей собственной меткой времени. Периодический сканер должен добавлять наборы AttributeChangeSet одного и того же объекта в отчет о событиях сканирования, соблюдая хронологический порядок, начиная с наиболее старого набора вверху сообщения.

Различные требования, предъявляемые к отчетам о результатах наблюдений, можно выполнить, используя группы периодических и эпизодических Scanner, по одному на каждый поток наблюдений для управления его характеристиками. Например, пульсоксиметр может использовать периодический конфигурируемый сканер со значением атрибута Reporting-lnterval = 50 мc для объекта RT-SA, представляющего плетизмограмму; периодический конфигурируемый сканер со значением атрибута Reporting-lnterval = 1 сек для объектов Numeric, представляющих уровень насыщения кислородом, и объектов Enumeration, сообщающих о событиях, связанных со значением; а также эпизодический конфигурируемый сканер EpiCfgScanner для пульсовых объектов Metric (числовых и перечисляемых).

6.3.9.3 Класс Scanner

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

Класс Scanner (сканер) представляет собой абстрактный класс, определяющий атрибуты, методы, события и службы, являющиеся общими для его подклассов. Поэтому он не имеет экземпляров.

Понятие сканера предусматривает три формата представления отчетов о событиях: переменный, фиксированный и групповой. Сведения о предоставлении атрибутов наблюдаемых объектов см. в 7.4.5. Форматы отчетов о событиях описаны ниже соответственно в 6.3.9.5.5, 6.3.9.6.5 и А.11.5.

Более специализированные классы сканера произведены от базового класса Scanner.

6.3.9.3.2 Идентификация класса Scanner

Для идентификации класса Scanner используется номенклатурный код MDC_MOC_SCAN.

6.3.9.3.3 Атрибуты класса Scanner

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

Таблица 14 - Атрибуты класса Scanner

6.3.9.3.4 Методы объектов Scanner

В настоящем стандарте отсутствуют определения методов объектов Scanner, однако они могут существовать в специализациях приборов ИСО/ИИЭР 11073-104zz или в местных документах.

6.3.9.3.5 События объектов Scanner

Описания событий производных классов см. в 6.3.9.5.5 и 6.3.9.6.5.

6.3.9.3.6 Прочие службы Scanner

- Служба GET

В настоящем стандарте отсутствует определение службы GET, однако оно может существовать в специализациях приборов ИСО/ИИЭР 11073-104zz или в местных документах.

- Служба SET

Агенты, имеющие объекты, произведенные от класса Scanner, должны поддерживать службу SET для атрибута Operational-State этих объектов. Такая служба SET может вызываться как подтверждаемое или неподтверждаемое действие.

6.3.9.4 Класс CfgScanner

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

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

6.3.9.4.2 Идентификация класса CfgScanner

Для идентификации класса CfgScanner используется номенклатурный код MDC_MOC_SCAN_CFG.

6.3.9.4.3 Атрибуты класса CfgScanner

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

Таблица 15 - Атрибуты класса CfgScanner

На рисунке 6 показана обработка необязательной очереди передачи, когда значение Transmit-Window больше 1.

Рисунок 6 - Обработка атрибута Transmit-Window конфигурируемого сканера

6.3.9.4.4 Методы объектов конфигурируемого сканера

В настоящем стандарте отсутствуют определения методов объектов конфигурируемого сканера, однако они могут существовать в специализациях приборов ИСО/ИИЭР 11073-104zz или в местных документах.

6.3.9.4.5 События объектов конфигурируемого сканера

Описания событий производных классов см. в 6.3.9.5.5 и 6.3.9.6.5.

6.3.9.4.6 Прочие службы конфигурируемого сканера

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

6.3.9.5 Класс EpiCfgScanner

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

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

6.3.9.5.2 Идентификация класса EpiCfgScanner

Для идентификации класса EpiCfgScanner используется номенклатурный код MDC_MOC_SCAN_CFG_EPI.

6.3.9.5.3 Атрибуты класса EpiCfgScanner

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

Таблица 16 - Атрибуты класса EpiCfgScanner

6.3.9.5.4 Методы объекта EpiCfgScanner

В настоящем стандарте отсутствуют определения методов объектов эпизодического конфигурируемого сканера, однако они могут существовать в специализациях приборов ИСО/ИИЭР 11073-104zz или в местных документах.

6.3.9.5.5 События объекта EpiCfgScanner

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

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

- Unbuf-Scan-Report-Var

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

- Unbuf-Scan-Report-Fixed

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

- Unbuf-Scan-Report-Grouped

Отчет о событии этого стиля используется, когда объект сканера используется для передачи данных в наиболее компактном формате. Атрибут Scan-Handle-Attr-Val-Map описывает объекты и атрибуты, включенные в отчет, а также формат сообщения.

- Unbuf-Scan-Report-MP-Var

Стиль события полностью совпадает с Unbuf-Scan-Report-Var, но позволяет включать данные нескольких лиц.

- Unbuf-Scan-Report-MP-Fixed

Стиль события полностью совпадает с Unbuf-Scan-Report-Fixed, но позволяет включать данные нескольких лиц.

- Unbuf-Scan-Report-MP-Grouped

Стиль события полностью совпадает с Unbuf-Scan-Report-Grouped, но позволяет включать данные нескольких лиц.

6.3.9.5.6 Прочие службы эпизодического конфигурируемого сканера

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

6.3.9.6 Класс PeriCfgScanner

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

Класс PeriCfgScanner (периодический конфигурируемый сканер) допускает создание экземпляров. Объекты PeriCfgScanner используются для передачи отчетов, содержащих периодические данные. Отчеты о событиях должны передаваться с временным интервалом, равным значению атрибута Reporting-lnterval.

Количество наблюдений для каждого объекта Metric зависит от интервала обновления объекта Metric и значения атрибута сканера Reporting-lnterval.

После того как менеджер активирует периодический конфигурируемый сканер, отчеты о сканировании необходимо передавать в разумные сроки и синхронизировать с интервалом отчетов сканера. Интервал времени между активированием сканера и отправкой первого отчета о сканировании не должен превышать интервал отчетов + 15 секунд.

Примечание - Предполагается, что 15 секунд будет более чем достаточно для инициализации.

Пример - Периодический конфигурируемый сканер настроен на передачу информации о двух объектах Metric с интервалом 1 с. Два объекта периодически обновляют свои соответствующие наблюдаемые значения с интервалом 1 и 1/2 с соответственно. Затем периодический конфигурируемый Scanner генерирует отчеты о событиях каждую секунду, сообщая один скан наблюдения объекта Metric #1 и два скана наблюдения объекта Metric #2. Объекты в атрибуте Scan-Handle-Attr-Val-Map могут содержать две записи для объекта с интервалом обновления

с.

6.3.9.6.2 Идентификация объекта PeriCfgScanner

Для идентификации класса PeriCfgScanner используется номенклатурный код MDC_MOC_SCAN_CFG_PERI.

6.3.9.6.3 Атрибуты класса PeriCfgScanner

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

Таблица 18 - Атрибуты объекта класса PeriCfgScanner

6.3.9.6.4 Методы объекта класса PeriCfgScanner

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

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

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

Примечание - Если от объекта не собрано ни одного набора AttributeChangeSet, то отчеты о сканировании с переменными и фиксированными форматами не будут содержать ни одного набора AttributeChangeSet от этого объекта. Если ни одного набора AttributeChangeSets не собрано, то по истечении периода отправляется пустой отчет о событии сканирования.

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

6.3.9.6.5 Прочие службы периодического конфигурируемого сканера

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

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

Информационная модель может быть расширена при реализации, используя дополнительные атрибуты объектов, определенных в настоящем стандарте, которые определены в ИСО/ИИЭР 11073-10201:2004 [В17].

Другим возможным расширением может стать использование местных (например, специфичных для производителя) атрибутов объектов и/или методов для объектов, определенных в настоящем стандарте. Местные атрибуты должны идентифицироваться путем присвоения номенклатурных кодов из местного пространства нумерации (0xF000 - 0xFFFF) в рамках соответствующего раздела, определенного в ИСО/ИИЭР 11073-10101 [В16].

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

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

      7 Сервисная модель персонального медицинского прибора

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

Сервисная модель определяет концептуальные механизмы служб обмена данными. Такие службы отображаются на сообщения, которыми обмениваются агент и менеджер. Сообщения протокола в рамках серии стандартов ИСО/ИИЭР 11073 определены на языке АСН.1. Сообщения, описанные в настоящем стандарте, могут сосуществовать с сообщениями, описанными в других стандартных профилях, определенных в серии стандартов ИСО/ИИЭР 11073.

Сообщения протокола структурируются следующим образом.

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

- Структура кадра верхнего уровня, в частности, содержит тип сообщения и поле длины.

- При использовании MDER протокол позволяет агентам хранить заранее определенные шаблоны передачи и изменять только фиксированные места шаблона, меняя части перед отправкой.

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

      7.2 Служба ассоциации

Служба ассоциации управляет ассоциацией между агентом и менеджером. Следующие сообщения являются частью службы ассоциации:

- Запрос ассоциации устанавливает соединение верхнего уровня поверх существующего транспортного соединения.

- Если соединение двунаправленное, то ответ на запрос ассоциации сообщает об обработке этого запроса.

- Запрос на разъединение корректно завершает ассоциацию верхнего уровня.

- Если соединение двунаправленное, то ответ на разъединение подтверждает завершение ассоциации верхнего уровня.

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

      7.3 Службы доступа к объектам

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

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

- Служба GET: используется менеджером для получения от агента значений объекта MDS и атрибутов объекта PM-store. Список атрибутов объекта MDS указан в 6.3.2.3, а список атрибутов объекта PM-store - в 6.3.7.3.

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

- Служба EVENT REPORT: используется агентом для передачи менеджеру обновлений конфигурации и результатов измерений. Список отчетов о событиях указан в 6.3.2.5, 6.3.7.5, 6.3.9.5.5 и 6.3.9.6.5.

- Служба ACTION: используется менеджером для вызова действий (или методов), поддерживаемых агентом. Примером может служить действие MDS-Data-Request, используемое для запроса результатов измерений от агента. Список методов указан в 6.3.2.4 и 6.3.7.4.

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

- Агент находится в состоянии "Выполнение", а служба GET ссылается на объект MDS или дескриптор объекта, объявленный во время конфигурирования.

- Агент находится в состоянии "Ассоциирован", а служба GET ссылается на объект MDS.

Менеджер, получающий от агента подтверждаемый отчет о событии, должен возвратить сообщение rors-cmip-confirmed-event-report или соответствующее сообщение об ошибке roer с подходящим кодом возврата.

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

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

      7.4 Специфичное применение служб доступа к объектам EVENT REPORT для персональных медицинских приборов

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

Для агента служба EVENT REPORT является основным механизмом отправки отчетов о результатах измерений и конфигурациях. В настоящем стандарте отчеты о событиях являются свойствами объектов MDS и сканеров. Такие специфичные отчеты о событиях могут иметь разные формы и свойства, указанные в 7.4.2-7.4.7.

      7.4.2 Подтверждаемые и неподтверждаемые отчеты о событиях

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

      7.4.3 Отчет о событиях конфигурации

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

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

7.4.3.2 Конфигурация прибора агента

Набор объектов и атрибутов агента, которые не входят в MDS, обозначает конфигурацию прибора агента и ассоциируется со значением Dev-Configuration-ld (см. таблицу 3). Если агент обладает несколькими конфигурациями прибора, присвоенные значения Dev-Configuration-ld должны быть локально уникальными. На протяжении срока существования ассоциации конфигурация агента должна оставаться постоянной, то есть набор объектов должен оставаться неизменным. Однако агент может добавить объекту новые атрибуты или изменить значения атрибутов в соответствии с 7.4.3.3. Агент, которому требуется другая конфигурация, должен завершить ассоциацию и установить новую ассоциацию с требуемой конфигурацией.

Объект MDS не рассматривается как часть конфигурации. Менеджер, выполняющий повторную ассоциацию с агентом, предоставляющим то же самое значение Dev-Configuration-ld, не может рассчитывать на совпадение значений атрибута MDS. Например, агент может сбросить бит manager-set-time, поскольку время на его часах уже установлено.

7.4.3.3 Отчет о событиях конфигураций

Конфигурация, которую агент желает использовать на время ассоциации с менеджером, указывается в сообщении запроса ассоциации в значении атрибута Dev-Configuration-ld поля dev-config-id. Если менеджеру еще не известна конфигурация прибора агента (например, на основе предыдущего этапа ассоциации), менеджер запрашивает конфигурацию прибора агента. Даже если менеджеру известна конфигурация прибора агента, менеджер может запросить переход в состояние "Конфигурирующий", чтобы проверить атрибуты объекта MDS перед принятием решения о допустимости ассоциации. Агент сообщает менеджеру свою конфигурацию с помощью отчета о событиях конфигурации. Отчет описывает все объекты конфигурации прибора агента вместе с ассоциированным значением Dev-Configuration-ld. На протяжении существования ассоциации конфигурация агента остается неизменной с точки зрения количества объектов. Если агент намеревается использовать другую конфигурацию или желает изменить существующую конфигурацию путем добавления или удаления объектов, агент должен завершить ассоциацию и инициировать новую ассоциацию с новой конфигурацией.

Для каждого объекта кроме MDS отчет о событии конфигурации должен содержать статические атрибуты, а также динамические атрибуты, используемые объектом. Данные атрибуты указываются в списке структур ConfigObject (А.11.5). Значение атрибута Handle указывается в поле obj-handle структуры ConfigObject и не включается в список атрибутов attribute-list структуры ConfigObject. Наблюдаемые атрибуты объектов не должны включаться в структуру ConfigObject. Значения наблюдаемых атрибутов передаются в последующих отчетах о событиях сканирования (см. 7.4.5 и 7.4.6). Агент, находящийся в состоянии "Выполнение", может добавлять новые атрибуты в объект или изменять динамические значения атрибутов, не отправляя новую конфигурацию, даже если данный атрибут первоначально отсутствует в стандартной конфигурации, определенной в некоторой специализации прибора ИСО/ИИЭР 11073-104zz.

Изменения любых значений атрибутов объектов Metric и Scanner должны сообщаться менеджеру в отчетах о событиях сканирования перед отправкой отчетов о событиях, зависящих от этих значений (например, атрибут scan-handle-attr-val-map и отчет о событии в групповом формате, или атрибут единицы измерения unit-code и наблюдаемое значение). Сведения об изменениях значений любых не статических атрибутов объектов PM-store или MDS могут передаваться менеджеру в отчетах о событиях по усмотрению агента. Добавление новых атрибутов возможно только с помощью отчета о событиях переменного формата (дополнительные сведения о форматах отчетов о событиях см. в 7.4.5). Изменяемые значения атрибутов могут в зависимости от конфигурации использовать переменные, фиксированные или групповые отчеты о событиях.

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

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

Менеджер использует информацию о конфигурации для создания эквивалентной модели информации агента. Затем данная информация обновляется агентом по мере сбора измерений.

7.4.3.4 Специализации приборов

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

7.4.3.5 Профили

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

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

Ожидается, что профиль будет идентифицироваться по названию и номенклатурному значению. Например, при реализации стандарта концентратора активности (ИИЭР 11073-10471 [В11]) разработчик может объявить о следовании профилю датчика дыма или профилю датчика угарного газа.

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

7.4.3.5.2 Ограничения информационной модели предметной области

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

- определение дополнительных объектов;

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

- расширение условий, ранее определенных в специализации.

7.4.3.5.3 Ограничения сервисной модели

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

- расширение набора событий, описываемых специализацией;

- расширение набора методов, описываемых специализацией.

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

7.4.3.5.4 Ограничения коммуникационной модели

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

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

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

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

Стандартная конфигурация - конфигурация, описанная в одной из специализаций ИСО/ИИЭР 11073-104zz и имеющая значение атрибута Dev-Configuration-ld, присвоенное из диапазона от standard-config-start до standard-config-end включительно. Такой диапазон имеет 100 зарезервированных идентификаторов для каждой специализации ИСО/ИИЭР 11073-104zz и содержит значения от zz х 100 до zz x 100 + 99 включительно. Например, диапазон 1500-1599 зарезервирован для ИИЭР 11073-10415

[В7]. Все неиспользуемые значения из стандартного диапазона зарезервированы для будущего использования. Менеджер, обнаруживший такое зарезервированное значение, должен рассматривать его как соответствующее неопознанной стандартной конфигурации и обработать согласно 8.7.3.3 и 8.8.3.

Менеджер, который поддерживает одну (или несколько) специализаций прибора ИСО/ИИЭР 11073-104zz, должен оказаться способным принять все стандартные конфигурации приборов, описанные для профилей, указанных в строке Gen-4 таблицы 23 (общие спецификации соответствия). При наличии стандартных конфигураций, которые обычно применимы к поддерживаемым специализациям, менеджер должен оказаться способным принять все эти конфигурации. Каждый раз, когда агент запрашивает ассоциацию с менеджером, используя значение атрибута Dev-Configuration-ld, присвоенное стандартной конфигурации, менеджер может принять ассоциацию без запроса конфигурации агента, поскольку она уже известна. После успешной ассоциации менеджер и агент переходят в состояние "Выполнение". Как вариант менеджер может запросить агента об отправке стандартной конфигурации, чтобы перейти в состояние "Конфигурирующий" и проверить атрибуты объекта MDS перед окончательным принятием (или отклонением) агента.

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

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

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

Расширенная конфигурация агента не является стандартной; она может иметь отличающийся набор объектов, атрибутов и/или значений атрибутов. Агент, использующий расширенные конфигурации, должен выбрать уникальное значение атрибута Dev-Configuration-ld из диапазона от extended-config-start до extended-config-end включительно для каждой расширенной конфигурации. Во время ассоциации агент отправляет значение атрибута Dev-Configuration-ld в поле dev-config-id, чтобы идентифицировать выбранную конфигурацию агента на период существования ассоциации. Если менеджер уже знает эту конфигурацию, поскольку она уже загружена при помощи программы установки или агент ранее уже устанавливал ассоциацию с менеджером, то менеджер должен возвратить сообщение о принятии конфигурации без необходимости пересылки дальнейшей информации о конфигурации. Но если менеджер не знаком с конфигурацией агента, он должен ответить сообщением accepted-unknown-config, после чего агент должен передать информацию о своей конфигурации путем отправки отчета о событии конфигурации. Подробная информация о процедурах ассоциирования и конфигурирования приведена в 8.7 и 8.8. Как только менеджер получает конфигурацию, агент может передать результаты измерений. В целях экономии времени ассоциации агенту следует систематически использовать Dev-Configuration-ld для последующих ассоциаций. Отсюда вытекают следующие два последствия.

a) Один и тот же Dev-Configuration-ld не должен использоваться агентом для последующих ассоциаций, когда необходимо идентифицировать другую конфигурацию устройства.

b) Агенту необходимо использовать то же значение для Dev-Configuration-ld в последующих запросах на ассоциацию с менеджером, чтобы обозначить ту же самую конфигурацию прибора.

В отличие от стандартных конфигураций, два агента с одинаковым расширенным значением Dev-Configuration-ld не обязательно представляют одну и туже конфигурацию. Менеджер должен различать расширенные конфигурации в пределах каждого агента. Для различия расширенных конфигураций агента может использоваться атрибут System-Id, поскольку он обязателен, должен быть уникальным и высылается во время ассоциации, однако вместо этого могут использоваться другие методы (например, передача сведений о производителе/модели/серийном номере) при условии, что они не приведут к использованию менеджером некорректной конфигурации агента.

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

      7.4.4 Передача результатов измерений, инициируемая агентом и менеджером

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

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

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

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

Примечание 1 - Пример 1. Если структура ObservationScan объекта температуры содержит набор значений атрибутов, представляющих температуру, и атрибут Metric-Id, указывающий часть тела, корректная семантическая интерпретация состоит в том, что это одно измерение с соответствующими значениями. Если структура ObservationScan определяется на основе объекта RT-SA, содержащего поток значений температуры и указание части тела, правильная интерпретация подразумевает, что эта часть тела относится ко всему потоку значений температуры. Если структура ObservationScan содержит набор значений атрибутов, представляющих код единицы измерения и часть тела (оба атрибута динамические), правильная интерпретация подразумевает, что новые значения будут применяться к следующему полученному результату наблюдений (предполагается, что эти два динамических значения в дальнейшем не обновляются).

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

      7.4.5 Переменный, фиксированный и групповой форматы отчетов о событиях

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

Рисунок 7 - Связи между переменным, фиксированным и групповым форматами

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

Отчет о событиях, использующий фиксированный формат, оптимизирует передачу данных с помощью определения конкретного списка передаваемых атрибутов и порядка их следования в сообщении. Это определение включено в атрибут Attribute-Value-Map, соответствующий объекту, и содержит в том числе идентификаторы атрибутов и длины значений атрибутов. Специфичный выбор добавляемых атрибутов зависит от того, какие атрибуты могут изменять свои значения. Например, одна модель весов может передавать результаты измерений веса и метки времени, а другая - результаты измерений веса, статус измерений и метки времени. В первом случае структура attribute-value-map будет содержать идентификатор наблюдаемого атрибута веса (MDC_ATTR_NU_VAL_OBS_SIMP) и его длину (4 байта), за которым следуют идентификатор атрибута метки времени (MDC_ATTR_TIME_STAMP_ABS) и его длина (8 байт). Второй случай похож на первый, однако будут добавлены идентификатор атрибута для статуса измерения (MDC_ATTR_MSMT_STAT) и его длина (2 байта). Атрибут Attribute-Value-Map должен быть определен и передан менеджеру до начала передачи отчета о событии в фиксированном формате. Когда агент передает данные в отчете о событии, имеющем фиксированный формат, он должен сообщать дескриптор объекта и значения атрибутов в том же порядке и с теми же размерами, что указаны в атрибуте Attribute-Value-Map. Таким образом можно избежать издержек, связанных с передачей идентификации и длины атрибутов в каждом отчете о событиях. При получении отчета о событиях в фиксированном формате менеджер использует дескриптор объекта для извлечения ранее предоставленного атрибута Attribute-Value-Map, чтобы получить информацию о способе извлечения данных. Например, в первом ранее описанном случае менеджер знает, что наблюдение веса является первым элементом отчета о событиях с фиксированным форматом и этот элемент имеет длину 4 байта, поэтому его можно извлечь в атрибут Simple-Nu-Observed-Value, а остальные 8 байт - в Absolute-Time-Stamp. Порядок следования этих элементов определяется порядком перечисления идентификаторов атрибутов в атрибуте Attribute-Value-Map. Агент контролирует порядок следования и сообщает его менеджеру с помощью атрибута Attribute-Value-Map.

Групповой формат отчета о событиях дополнительно оптимизирован с помощью определения формата сообщения, содержащего один или несколько объектов, в атрибуте Scan-Handle-Attr-Val-Map объекта сканера. Оно аналогично определению Attribute-Value-Map, однако атрибут Scan-Handle-Attr-Val-Map позволяет агенту предоставлять сведения одновременно о нескольких объектах с помощью ссылки на другие дескрипторы и атрибуты объектов. Данный атрибут должен быть определен до начала передачи отчета о событиях в групповом формате. Агент, передающий данные в групповом формате отчета о событиях, должен сообщать дескриптор объекта сканера вместе со значениями атрибутов объектов сканера в том же порядке и с теми же размерами, что указаны в атрибуте Scan-Handle-Attr-Val-Map. Таким образом можно избежать издержек, связанных с отправкой дескрипторов объектов сканера, идентификацией их атрибутов и длины данных в каждом отчете о событиях. При получении отчета о событии в групповом формате менеджер использует дескриптор объекта сканера для извлечения ранее переданного атрибута Scan-Handle-Attr-Val-Map, чтобы получить информацию о способе извлечения данных.

Менеджер должен поддерживать отчеты о событиях с переменным или фиксированным форматом, при этом менеджер, поддерживающий сканеры, должен также поддерживать групповой формат отчетов о событиях. Агент может поддерживать любой или все отчеты о событиях с переменным, фиксированным и групповым форматами. Менеджер определяет, какой из форматов может использовать агент, проверяя атрибуты Attribute-Value-Map объектов или атрибут Handle-Attr-Val-Map объектов сканера.

      7.4.6 Отчеты о событиях с одним и несколькими лицами

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

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

      7.4.7 Временно хранящиеся результаты измерений

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

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

Для поддержки временно хранящихся измерений система агента должна вести себя следующим образом:

- как временно хранящиеся результаты измерений поддерживаются только те объекты Metric, которые не являются объектами RT-SA (например, объекты Numeric и Enumeration);

- для временно хранящихся результатов измерений требуется использовать атрибуты меток времени (например, Date-and-Time, Relative-Time или HiRes-Relative-Time);

- агент не должен передавать временно хранящиеся результаты измерений, если известно, что метка времени не точна (например, если база, используемая для меток времени значений, изменилась в период между измерениями на величину, существенную для соответствующего типа измерения), кроме случаев, когда имеется подходящий параметр Date-and-Time-Adjustment в начале отчета о событиях;

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

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

- для ограничения объема данных, передаваемых данным механизмом, агент должен предоставить не более 25 временно хранящихся результатов измерений в любом одном отчете о событии. Если требуется хранение более 25 измерений, следует использовать механизм объекта PM-store для архивирования результатов измерений;

- временно хранящиеся результаты измерений должны передаваться в порядке получения (FIFO).

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

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

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

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

      8.2 Контекст системы

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

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

Рисунок 8 - Контекст системы

В настоящем стандарте используется понятие "тип" для группировки и дифференцирования служб, предлагаемых доступными технологиями транспорта, профилированными для использования в серии стандартов ИСО/ИИЭР 11073. А именно в этой серии выделяются следующие типы транспортных профилей:

- Тип 1. Транспортные профили, содержащие "надежные" и "лучшие из возможных" транспортные службы, в которых должны быть один или несколько виртуальных каналов "надежных" транспортных служб и ноль или более виртуальных каналов "лучших из возможных" транспортных служб;

- Тип 2. Транспортные профили, содержащие только однонаправленную транспортную службу.

- Тип 3. Транспортные профили, содержащие только "лучшие из возможных" транспортные службы, в которых должен быть один или несколько виртуальных каналов "лучших из возможных" транспортных служб.

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

Более полное описание различных типов транспортных профилей и вариантов их взаимодействия с подтверждаемыми и неподтверждаемыми механизмами служб см. в приложении D.

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

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

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

Согласно настоящему стандарту каждый прибор должен поддерживать основной виртуальный канал. Основной виртуальный канал должен являться надежным виртуальным каналом (то есть надежной транспортной службой) из транспортного профиля типа 1. См. рисунок 9.

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

- Все сообщения, относящиеся к процедуре ассоциации:

- aare, aarq, rlre, rlrq, abrt.

- Все сообщения, относящиеся к подтверждаемому сервисному механизму:

- prst.roiv-cmip-confirmed-action, prst.roiv-cmip-confirmed-event-report, prst.roiv-cmip-get, prst.roiv-cmip-confirmed-set;

- prst.rors-cmip-confirmed-action, prst.rors-cmip-confirmed-event-report, prst.rors-cmip-get, prst.rors-cmip-confirmed-set.

- Все сообщения, относящиеся к условиям сбоя или аномалии:

- roer, rorj.

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

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

- prst.roiv-cmip-action, prst.roiv-cmip-event-report, prst.roiv-cmip-set

Рисунок 9 - Общая коммуникационная модель

Обычно термин "метаданные" означает данные о данных. В контексте коммуникационных характеристик, описанных в ИСО/ИИЭР 11073-20601, термин "метаданные" используется для обозначения вспомогательной информации или данных, относящихся к блоку APDU. Можно привести следующие примеры:

- специфический транспортно-технологический адрес для передачи блока APDU определенному агенту или менеджеру;

- надежность и/или задержка, необходимая определенному блоку APDU;

- размер или длина определенного блока APDU.

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

- APDU-metadata.address (для конечной точки USB) = 1 - 1023;

- APDU-metadata.address (для сети IPv4) = 0.0.0.0 - 255.255.255.255;

- APDU-metadata.size = 1 - 64512.

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

- APDU-metadata.latency = (10 мс | 100 мс | 1 с | 10 с);

- APDU-metadata.reliability = (высокий | средний | низкий);

- APDU-metadata.bandwidth = (100 бит/с | 1 Кбит/с | 10 Кбит/с | 100 Кбит/с | 1 Мбит/с).

В последующих подразделах описываются общие характеристики (см. 8.3.2) и уникальные характеристики надежных (см. 8.3.3) и лучших из возможных (см. 8.3.4) виртуальных каналов применительно к настоящему стандарту.

      8.3.2 Общие коммуникационные характеристики

Существует ряд следующих общих коммуникационных характеристик, применимых к надежным и лучшим из возможных коммуникациям:

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

b) Блоки APDU могут сегментироваться и собираться повторно во время передачи или они могут отправляться как единое целое.

c) Размер блоков APDU, отправляемых агентом менеджеру, не должен превышать 63 КБ (64512 байт). Специфичные специализации приборов, профили или реализации могут анализировать переданные сообщения с целью определения конкретного размера реализации для приемного буфера менеджера, меньшего, чем максимальный размер блока APDU, передаваемого агентом менеджеру. Если менеджер получает блок APDU, который больше размера его приемного буфера, то ответное сообщение должно содержать код ошибки (roer) protocol-violation (нарушение протокола). Размер приемного буфера менеджера должен как минимум равняться размеру наибольшего буфера, указанному в специализациях, поддерживаемых менеджером. Ограничения размера буфера, указанные в этом и следующем пунктах перечисления, применяются ко всем блокам APDU независимо от использования стандартной или расширенной конфигурации.

d) Размер блоков APDU, отправляемых менеджером агенту, не должен превышать 8 КБ (8192 байт). Специфичные специализации устройств, профилей или реализаций могут анализировать передаваемые сообщения с целью определения конкретного размера реализации для приемного буфера агента, меньшего, чем максимальный размер блока APDU, передаваемого менеджером агенту. Агент, получивший блок APDU большего размера, должен ответить, указав код ошибки (roer) protocol-violation (нарушение протокола).

e) Общая длина блока APDU должна передаваться между коммуникационными уровнями как метаданные.

f) Коммуникационные уровни должны указывать общую длину блока APDU для его однорангового коммуникационного уровня.

      8.3.3 Характеристики надежных коммуникаций

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

a) Блоки APDU должны приниматься в порядке их отправки.

b) Блоки APDU не должны содержать обнаруживаемых ошибок.

c) Блоки APDU не должны дублироваться.

d) Блоки APDU не должны быть утеряны.

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

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

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

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

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

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

      8.3.4 Характеристики наилучших коммуникаций

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

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

b) Блок APDU может теряться или дублироваться.

c) Скорость передачи пакетов APDU может привести к переполнению буфера получателя.

      8.4 Конечные автоматы

      8.4.1 Конечный автомат агента

Общая схема конечного автомата агента показана на рисунке 10.

Подробная таблица состояний агента представлена в Е.2.

Таблица 20 содержит описание каждого из этих состояний.

Описание каждого изменения состояния представлено в таблице 21.

Рисунок 10 - Схема конечного автомата агента

Таблица 20 - Описание состояний агента

Состояние	Описание
Отсоединен	Предполагается, что при начальном включении агент находится в состоянии "Отсоединен", означающем отсутствие транспортного соединения между агентом и менеджером. После установления транспортного соединения можно вернуться в состояние "Отсоединен", если транспортное соединение намеренно или непреднамеренно прекращено
Соединен	После установления транспортного соединения агент получает от транспортного уровня индикацию транспортного соединения, что приводит к переходу в состояние "Соединен" (см. 8.4.3). Агент остается в состоянии "Соединен" до тех пор, пока поддерживается транспортное соединение. Изначально агент начинает работу в состоянии "Не ассоциирован" (подсостояние состояния "Соединен")
Не ассоциирован	Агент находится в состоянии "Не ассоциирован", когда не имеет ассоциацию прикладного уровня с менеджером. Такая ситуация может возникнуть вследствие любого из следующих обстоятельств:   - новое соединение только что установлено;   - менеджер отклоняет запрос ассоциации;   - любая из сторон завершает или разрывает активную ассоциацию в любой момент при наличии соединения.   Агент остается в состоянии "Не ассоциирован", пока не определит, что должен начать ассоциирование с менеджером
Ассоциирующий	Когда агент определяет, что должен создать ассоциацию, то переходит в состояние "Ассоциирующий" и посылает менеджеру запрос ассоциации (см. 8.6). Если ассоциацию не удается создать, но возможны альтернативные параметры ассоциации, агент может попытаться связаться с помощью каждого нового набора параметров ассоциации. В случае тайм-аута агент должен продолжать попытки установления ассоциации до тех пор, пока не будет достигнуто максимальное количество повторных попыток или ассоциация не будет создана
Ассоциирован	Если менеджер определяет, что агент и менеджер используют общие версии и протоколы, он посылает агенту ответ на запрос ассоциации с параметром "accepted" (см. 8.7.3.3). Агент, получивший это сообщение, переходит в состояние "Ассоциирован" и остается в этом состоянии до тех пор, пока не отправит или не получит запрос на завершение или разрыв ассоциации. Начальное подсостояние после перехода в состояние "Ассоциирован" зависит от ответа менеджера на запрос ассоциации, в котором указано, распознана ли конфигурация агента
Выполнение	Описания процедур, возможных в состоянии "Выполнение", см. в 8.9.
Конфигурирующий	Если менеджер не распознал конфигурацию агента, то он информирует его об этом, посылая ответ на запрос ассоциации с параметром "accepted-unknown-config", чтобы указать, что ассоциация принята, но необходимо передать конфигурацию. Агент остается в состоянии "Конфигурирующий" до тех пор, пока не передаст информацию о конфигурации, получение которой менеджер подтвердит (см. 8.8)   Если менеджер распознал конфигурацию агента, он информирует его об этом, посылая ответ на запрос ассоциации с параметром "accepted", чтобы перевести агента в подсостояние "Ожидает GetMDS".   На протяжении секунд после перехода агента в подсостояние "Ожидает GetMDS" менеджер должен вызвать службу GET. Получив этот вызов, отправляет менеджеру ответ на GET. Если бит mds-time-mgr-set-time не установлен, агент сразу переходит в состояние "Выполнение". Если бит mds-time-mgr-set-time установлен, агент должен ожидать секунд получения от менеджера команды действия Set-time. После получения действия Set-Time агент должен очистить бит mds-time-mgr-set-time перед отправкой подтверждения Set-Time. После отправки подтверждения Set-Time агент переходит в состояние "Выполнение".   Если для передачи отчета агент использует базовое время со смещением, в вышеуказанном описании вместо действия Set-Time должно использоваться действие Set-Base-Offset-Time.   В случае тайм-аута агент посылает запрос на завершение ассоциации и переходит в состояние отсутствия состояния
Завершает ассоциацию	Когда агент определяет, что должен завершить текущую ассоциацию, то переходит в состояние "Завершает ассоциацию" и посылает менеджеру запрос на завершение ассоциации (см. 8.10). В случае тайм-аута агент посылает запрос на прекращение ассоциации и переходит в состояние "Не ассоциирован"

Таблица 21 - Описание переходов состояния агента

Переход	Описание
Индикация транспортного соединения	Передача индикации транспортного соединения происходит всякий раз, когда транспортный уровень (или вспомогательный промежуточный уровень) указывает на успешное установление соединения
assocReq	Когда агент определяет, что должен попытается создать ассоциацию с менеджером, он переходит в состояние "Ассоциирующий"
RxAssocRsp (accepted или accepted-unknown-config)	Агент, пытающийся создать ассоциацию с менеджером, посылает запрос ассоциации (или несколько запросов при наличии тайм-аута) и ожидает ответа на запрос ассоциации от менеджера. После получения одобрения ассоциации агент переходит в состояние "Ассоциирован"
RxAssocRsp (отклонен)	Если после получения запроса ассоциации менеджер определяет, что не может ассоциироваться с агентом, то он посылает ответ на запрос ассоциации с кодом отклонения ассоциации (постоянного или временного), чтобы перевести агента обратно в состояние "Не ассоциирован"
RxAssocRelReq/TxAssoc- RelRsp	Если агент ассоциирован с менеджером и получает запрос на завершение ассоциации, то он отвечает ему и переходит в состояние "Не ассоциирован"
RxAssocAbort или TxAssocAbort	В любое время, когда агент и менеджер создают ассоциацию, ассоциированы или завершают ассоциацию, агент может отправить или получить сообщение о прекращении ассоциации. При возникновении данной ситуации агент переходит из текущего состояния в состояние "Не ассоциирован". Ассоциированный агент может отправить сообщение о прекращении ассоциации, чтобы сообщить менеджеру о возникновении серьезного сбоя. Оно должно передаваться в самом крайнем случае, поскольку предпочтительнее отправка запроса на завершение ассоциации, чтобы корректно перейти в состояние "Не ассоциирован". Если агент получает сообщение о прекращении ассоциации, ответ от него не требуется, поскольку это сообщение может быть получено только в случае прекращения ассоциации менеджером (например, при аварии)
assocRelReq	Агент, решивший завершить ассоциацию, переходит в состояние "Завершает ассоциацию" и посылает запрос на завершение ассоциации. Такой переход используется во время обычной последовательности отключения с помощью отправки в параметре ReleaseRequestReason кода nomal при обычных условиях или, если конфигурация агента изменилась, из-за чего необходимо завершить ассоциацию, агент отправляет в параметре ReleaseRequestReason код configuration-changed. В любом случае при следующей ассоциации агент указывает в запросе ассоциации конфигурацию, необходимую для использования, и менеджер определяет, знакома ли ему эта конфигурация
RxAssocRelRsp	Данный переход указывает на принятие запроса о завершении текущей ассоциации. Если перед этим агент послал запрос на завершение ассоциации, это означает, что получен ответ, указывающий на одобрение завершения со стороны менеджера
RxGetMdsReq/TxGetMdsR- sp	На протяжении секунд после перехода агента в подсостояние "Конфигурирующий"/"Ожидает GetMDS" менеджер должен вызвать службу GET, при этом агент отправляет менеджеру ответ на действие GET вместе с реализованными атрибутами объекта MDS. После этого агент переходит в состояние "Выполнение" или подсостояние "Ожидает SetTime" (зависит от значения бита mds-time-mgr-set-time). Если бит mds-time-mgr-set-time установлен, агент переходит в подсостояние "Конфигурирующий"/"Ожидает SetTime", иначе он переходит в состояние "Выполнение"
RxSetTimeReq/TxSetTim- eRsp	На протяжении секунд после перехода агента в подсостояние "Ожидает Set-Time" менеджер должен отправить агенту команду действия Set-Time (или Set-Base-Offset-Time). После завершения операции настройки внутреннего времени агент отправляет менеджеру ответ и переходит в состояние "Выполнен"
Индикация транспортного разъединения	В любой момент времени агент или менеджер может разорвать транспортное соединение. Также возможна потеря соединения вследствие аварийных условий. Если получена индикация об отсоединении транспорта, агент переходит в состояние "Отсоединен"

      8.4.2 Конечный автомат менеджера

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

- Менеджер должен ждать в состоянии "Ожидает конфигурацию" как минимум TOconfig секунд перед отправкой сообщения о прекращении ассоциации.

- Если менеджер не принимает конфигурацию, то он должен отправить ответ на конфигурацию с указанием результата unsupported-config.

- Если менеджер принимает конфигурацию, то он должен отправить ответ на конфигурацию с указанием результата accepted-config.

- Менеджер должен вызвать службу GET не позже TOget секунд после перехода агента в подсостояние "Конфигурирующий"/"Ожидает GetMDS".

- Менеджер должен отправить агенту команду действия Set-Time (или Set-Base-Offset-Time) не позже ТОса секунд после перехода агента в подсостояние "Конфигурирующий"/"Ожидает SetTime".

Подробная таблица состояний менеджера представлена в Е.4.

     Рисунок 11 - Схема конечного автомата менеджера

      8.4.3 Переменные тайм-аута

В протоколе персонального медицинского прибора есть несколько мест, где используются тайм-ауты. Существуют тайм-ауты периодов повтора и счетчики повторов (RC). Чтобы облегчить управление документом в течение длительного периода времени и упростить электронный "поиск" разных значений тайм-аута, конкретные числовые значения удалены из содержания настоящего стандарта и заменены соответствующими переменными тайм-аута. Их отображения на числовые значения указаны в таблице 22.

Таблица 22 - Переменные тайм-аута