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

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

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

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

ГОСТ Р 71704— 2024

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

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

Часть 20701

Сервис-ориентированная архитектура медицинских приборов и привязка протокола

(ISO/IEEE 11073-20701:2020, NEQ)

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

Москва Российский институт стандартизации 2024

ГОСТ Р 71704—2024

Предисловие

1 РАЗРАБОТАН Обществом с ограниченной ответственностью «ЭОС Тех» (ООО «ЭОС Тех») и Федеральным государственным бюджетным учреждением «Российский институт стандартизации» (ФГБУ «Институт стандартизации»)

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

3 Утвержден И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии России от 17 октября 2024 г. № 1465-ст

4 Настоящий стандарт разработан с учетом основных нормативных положений международного документа ISO/IEEE 11073-20701:2020 «Информатизация здоровья. Интероперабельность устройств. Часть 20701. Обмен данными с медицинскими приборами в местах оказания медицинской помощи. Сервис-ориентированная архитектура обмена данными с медицинскими приборами и привязка протокола» (ISO/IEEE 11073-20701:2020 «Health informatics — Device interoperability — Part 20701: Point-of-care medical device communication — Service oriented medical device exchange architecture and protocol binding», NEQ)

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

6 Федеральное агентство по техническому регулированию и метрологии не несет ответственности за патентную чистоту настоящего стандарта

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

©Оформление. ФГБУ «Институт стандартизации», 2024

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

II

ГОСТ Р 71704—2024

Содержание

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

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

3 Термины и определения................................................................2

4 Условные обозначения.................................................................5

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

6 Сервис-ориентированная архитектура обмена данными с медицинскими приборами.............6

7 Привязка модели участника сервис-ориентированного взаимодействия с приборами (SDC).......7

7.1 Кодированные значения.........................................................7

7.2 Средства удаленного управления.................................................7

7.3 Возможность извлечения элементов дерева включений...............................9

7.4 Динамические изменения дерева включений........................................9

7.5 Управление версиями MDIB.....................................................10

7.6 Классы......................................................................10

8 Привязка коммуникационной модели....................................................11

8.1 Сервис......................................................................11

8.2 Сообщение...................................................................12

9 Привязка обнаружения................................................................14

9.1 Механизм обнаружения........................................................14

9.2 Обнаружение сложных приборов, состоящих из компонентов.........................14

9.3 Обнаружение по основной роли участника SDC....................................15

9.4 Обнаружение по контексту......................................................15

9.5 Объявление об отсутствии......................................................17

10 Нефункциональные атрибуты качества.................................................17

10.1 Безопасность информационных технологий.......................................17

10.2 Безопасность пациентов.......................................................18

10.3 Клиническая эффективность...................................................19

11 Соответствие.......................................................................21

11.1 Общий формат...............................................................21

11.2 Таблицы ICS.................................................................22

Приложение А (обязательное) Константы..................................................23

Приложение Б (обязательное) Описания сервисов WSDL поставщика сервисов SDC.............24

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

III

ГОСТ Р 71704—2024

Введение

Настоящий стандарт принят Техническим комитетом ИСО/ТК 215 «Информатизация здоровья» и утвержден членами международной организации по стандартизации.

Серия стандартов под общим наименованием «Информатизация здоровья» регламентирует обмен данными между медицинскими приборами и внешними компьютерными системами и обеспечивает автоматический электронный сбор подробной информации о жизненно важных показателях пациента и рабочих данных устройства (см. [1], [2]). Основными задачами данной серии стандартов являются:

- обеспечение интероперабельности медицинских приборов в режиме реального времени по принципу «Подключай и работай»;

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

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

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

Настоящий стандарт определяет архитектуру для сервис-ориентированных распределенных систем медицинских приборов РоС и медицинских ИТ-систем, привязку моделей участника, обнаружения и взаимодействия, описанных в [1], к профилю для передачи через веб-службы (см. [2]), а также привязку к протоколу сетевого времени (NTP) и дифференцированным сервисам (DiffServ) для удовлетворения требований к синхронизации времени и качеству транспортного сервиса.

IV

ГОСТ Р 71704—2024

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

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

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

Часть 20701

Сервис-ориентированная архитектура медицинских приборов и привязка протокола

Health informatics. Point-of-care medical device communication. Part 20701. Service-Oriented Medical Device Exchange Architecture and Protocol Binding

Дата введения — 2025—07—01

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

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

Настоящий стандарт описывает архитектуру для сервис-ориентированных распределенных систем медицинских приборов РоС и медицинских ИТ-систем.

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

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

ГОСТ Р 56842—2015/ISO/IEEE 11073-10101:2004 Информатизация здоровья. Информационное взаимодействие с персональными медицинскими приборами. Часть 10101. Номенклатура

ГОСТ Р 70394/ISO/IEEE 11073-10103:2014 Информатизация здоровья. Обмен данными с медицинскими приборами в месте оказания медицинской помощи. Часть 10103. Номенклатура. Имплантируемые кардиологические приборы

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

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

1

ГОСТ Р 71704—2024

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

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

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

Примечания

1 Физиологические сигналы тревоги, связанные с пациентом, а также технические сигналы тревоги являются сигналами тревоги, указывающими на наличие состояний тревоги. Состояние предупреждения об опасности — это состояние тревоги, если оно имеет низкий приоритет, средний приоритет или высокий приоритет, а его источник — физиологическая или техническая причина (см. [3]).

2 Оповещающие сигналы для пользователя оборудования считаются информационными сигналами, указывающими на наличие условий, не являющихся состоянием тревоги. Состояние уведомления — это не состояние тревоги, если оно не имеет ни низкий приоритет, ни средний приоритет, ни высокий приоритет (см. [3]).

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

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

3.3 сервис-ориентированная система медицинских приборов; SOMDS (service-oriented medical device system, SOMDS): Экземпляр распределенной системы, реализующей сервис-ориентированную архитектуру, состоящую из поставщиков сервисов и потребителей сервисов.

Примечание — См. [2].

3.4 SOMDS клинического рабочего места (clinical workplace SOMDS): Подмножество участников сервис-ориентированной системы медицинских приборов, закрепленное за одним клиническим рабочим местом.

3.5 прокси-сервис SOMDS клинического рабочего места (clinical workplace SOMDS proxy service): Прокси-сервис на клиническом рабочем месте, который является внешним интерфейсом по отношению к другим системам.

Примечание — Примерами внешних систем являются сетевые шлюзы, электронные медицинские карты (EHR), центральные станции, беспроводные сенсорные сети или другие SOMDS клинического рабочего места.

3.6 код (code): Идентификатор, используемый для семантического описания объекта на основе системы кодирования.

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

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

3.8 система кодирования (coding system): Совокупность правил кодового обозначения объектов.

3.9 среда места оказания помощи; РоС (point-of-care environment, РоС): Среда, охватывающая определенную диагностическую зону, койко-место или лечебную зону, предназначенную для одного пациента.

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

3.10 медицинский прибор места оказания помощи (point-of-care medical device): Медицинский прибор, обеспечивающий поддержку электронного обмена данными, который напрямую взаимодействует с одним пациентом, осуществляет мониторинг, обеспечивает лечение или каким-либо образом связан с ним.

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

2

ГОСТ Р 71704—2024

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

Примечание — Данная конфигурация моделируется в виде дерева с глубиной четыре.

3.12 элемент дерева включений (containment tree entry): Узел дерева включений, содержащий описание медицинского прибора РоС и информацию о его состоянии.

3.13 контекст (context): Абстракция компонента медицинского прибора среды места оказания помощи, которая определяет взаимосвязь данного медицинского прибора со средой его использования.

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

3.14 дифференцированный сервис; DiffServ (differentiated service, DiffServ): Основанный на классах крупнозернистый механизм управления трафиком, определенный в спецификации DiffServ.

3.15 элемент (element): XML-элемент, определенный в программе Extensible Markup Language (XML) 1.0.

Примечание — См. расширяемый язык разметки XML 1.0 [4].

3.16 интегрированная клиническая среда; ICE (integrated clinical environment, ICE): Среда, которая сочетает в себе разнородные интероперабельные медицинские приборы РоС и другое оборудование, интегрированные с целью создания системы медицинских приборов с целью оказания помощи с высокой чувствительностью одному пациенту.

Примечание — См. [5].

3.17 информационная база медицинских данных; MDIB (medical data information base, MDIB): Структурированный набор любых объектов данных, предоставляемых конкретным медицинским прибором РоС и включающих описательную информацию и информацию о состоянии.

3.18 атрибут версии MDIB (MDIB versioning attribute): Атрибут элемента, который позволяет обнаруживать устаревшие данные и обеспечивать историю дерева включений.

Примечание — Атрибуты версии информационной базы медицинских данных (MDIB) включают следующие: pm:@DescriptorVersion, pm:@StateVersion, pm:@MdibVersion, pm:@Sequenceld, pm:@lnstanceld, pm:Abstract-ContextState/@BindingMdibVersion и pm:AbstractContextState/@UnbindingMdibVersion.

Примечание — См. [1].

3.19 классификация медицинской безопасности (medical safety classification): Классификация качества данных и критичности операций с точки зрения управления рисками в соответствии с элементом дерева включений pm:SafetyClassification, оцениваемая как MedA, MedB или MedC.

Примечание — См. [1].

3.20 сообщение (message): Набор данных в определенном формате, которыми обмениваются участники.

3.21 шаблон обмена сообщениями; МЕР (message exchange pattern, МЕР): Архитектурный шаблон, описывающий, как две разные части приложения или разные системы связываются и взаимодействуют друг с другом.

3.22 метрика (metric): Абстракция компонента медицинского прибора РоС, которая способна генерировать или сохранять прямые и производные, количественные и качественные измерения биосигналов, настройки и значения состояния.

3.23 сетевой узел (network node): Узел в сети, который обменивается сообщениями путем отправки, получения или пересылки.

3.24 уведомление (notification): Шаблон обмена сообщениями, при котором поставщик сервиса использует сервисную операцию для передачи сообщения одному или нескольким потребителям сервиса периодически или при активации события и отправляет потребителю сервиса сообщение с уведомлением, в котором содержатся данные о событии.

3.25 оператор (operator): Лицо, работающее с медицинским прибором РоС или другим оборудованием, которое является частью среды РоС или сервис-ориентированной системы медицинских приборов.

3

ГОСТ Р 71704—2024

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

3.27 пошаговое поведение; РНВ (per-hop behavior, РНВ): Поведение, определяющее свойства пересылки пакетов сетевого узла, связанные с классом сетевого трафика, в соответствии со спецификацией DiffServ.

3.28 первичный UDI (primary UDI): Первый элемент в списке pm:MdsDescriptor/pm:MetaData/ pm:Udi, если для медицинского прибора РоС имеется несколько записей.

3.29 привязка протокола (protocol binding): Спецификация, определяющая способ соединения двух отдельных уровней протокола.

3.30 запрос-ответ (request-response): Шаблон обмена сообщениями, при котором потребитель сервиса вызывает сервисную операцию у поставщика сервиса путем отправки ему сообщения запроса, включающего в себя входную полезную информацию, и получает от поставщика сервиса ответное сообщение, которое включает в себя полезную информацию на выходе.

3.31 риск (risk): Совокупность вероятности причинения вреда и тяжести этого вреда.

Примечание — См. [6].

3.32 основная роль участника SDC (SDC participant key purpose): Набор требований, которым соответствует участник SDC и который позволяет ему соответствующим образом функционировать в сервис-ориентированной системе медицинских приборов.

Примечания

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

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

3.33 сервис (service): Часть программной системы, которая обеспечивает функциональные возможности в коммуникационной магистрали.

3.34 потребитель сервисов (service consumer): Сетевой узел, пользующийся хотя бы одним сервисом.

3.35 сервисный контракт (service contract): Интерфейс сервиса с ограничениями и политиками.

3.36 интерфейс сервиса (service interface): Набор сервисных операций, предоставляемых сервисом для описания его возможностей.

3.37 операция сервиса (service operation): Одна операция, которая может быть выполнена удаленно у поставщика сервиса.

3.38 поставщик сервисов (service provider): Сетевой узел, предоставляющий как минимум один сервис.

3.39 реестр сервисов (service registry): Поставщик сервисов, предоставляющий потребителю сервиса сервисные контракты и, таким образом, облегчает обнаружение сервисов.

Примечание — Реестр сервисов может быть реализован либо как централизованный, либо как распределенный поставщик сервиса.

3.40 потоковая передача (streaming): Специальный шаблон обмена уведомительными сообщениями МЕР, при котором поставщик сервисов использует сервисную операцию для непрерывной передачи сообщений одному или нескольким потребителям сервисов в течение коротких периодов времени без указания начала и окончания.

3.41 класс (type): Определение сложного или простого класса.

Примечание — См. [7].

4

ГОСТ Р 71704—2024

4 Условные обозначения

4.1 Пространства имен XML-схемы

Для описания сервисных интерфейсов настоящий стандарт содержит ссылки на файлы WSDL (см. XML-схемы версии 1.1 [8]). Файлы WSDL и включенные XML-схемы используют пространства имен XML (см. [8]), приведенные в таблице 1.

Таблица 1 — Отображения пространства имен

4.1.1 Ссылки на XML-схемы

Ссылки на определения класса или элемента XML-схемы выполняют с использованием соответствующего полного имени QName (см. [9]). Для ссылки на определение вложенного класса имя QName дополняют цепочкой имен QName и именами необязательных атрибутов, каждое из которых отделено символом — разделителем языка запросов XPath (см. [8]). Примеры ссылок следующие:

- pm:Handle, обозначающая класс Handle, определенный в модели участника;

- msg:OperationlnvokedReport/msg:ReportPart/@OperationTarget, обозначающая атрибут

OperationTarget, который определен как часть элемента ReportPart, входящего в состав OperationlnvokedReport. Так как префиксом имени QName является msg, указанный класс относится к модели сообщения;

- ./@ Activation Duration, обозначающая атрибут в определении произвольного класса.

В XML-схеме используют форму записи в «верблюжьем» регистре:

- каждый объект начинается с заглавной буквы (например, «Handle»);

- имена разделяются заглавной буквой (например, «ActivationState»).

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

Настоящий стандарт состоит из двух основных частей:

- описание сервис-ориентированной архитектуры медицинских приборов;

- спецификация протокола обмена данными BICEPS (см. [1]) и MDPWS (см. [2]) для реализации сервис-ориентированной архитектуры медицинских приборов.

Привязка протокола состоит из следующих четырех частей:

- описание возможностей и состояния медицинского прибора РоС с использованием сервисов;

- описания сообщений, которые передаются между потребителями сервисов, и сервисов для обмена возможностями и состоянием медицинских приборов РоС с потребителями сервисов;

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

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

5

ГОСТ Р 71704—2024

6 Сервис-ориентированная архитектура обмена данными с медицинскими приборами

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

SOMDS клинического рабочего места основана на основных принципах сервис-ориентированной архитектуры (SOA). Взаимосвязи между этими двумя понятиями объясняются далее в соответствии с эталонной моделью для сервис-ориентированной архитектуры 1.0 (см. [10]).

Существуют три основные роли, которые может выполнять сетевой узел в SOA (см. рисунок 1).

1 — публикация; 2 — поиск; 3 — привязка Рисунок 1 — Основные роли в SOA

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

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

Примечания

1 Типичными конечными точками сети являются сетевые адреса, аналогичные IP-адресам.

2 Обычно SOA реализуется с помощью технологии веб-служб. В технологии веб-служб сообщения могут восприниматься как сообщения SOAP (см. [11]), которые передаются, например, по протоколу HTTP.

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

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

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

6

ГОСТ Р 71704—2024

7 Привязка модели участника сервис-ориентированного взаимодействия

с приборами (SDC)

Все требования, изложенные в нижеследующих спецификациях, приведены в качестве справочной информации, за исключением тех случаев, когда они заменены нормативными положениями, приведенными в разделах 5, 6, 8, приложениях А и Б (см. также [1]).

7.1 Кодированные значения

7.1.1 Система кодирования

R0001: во всех случаях, когда имеется соответствующий код, участник SDC должен использовать номенклатуру, представленную в ГОСТ Р 56842, ГОСТ Р 70394, и поправки к ней.

Примечания

1 R0001 ограничивает опциональность требования biceps:R0128, поэтому номенклатура по ГОСТ Р 56842 становится обязательной.

2 Дополнительные коды из других номенклатур можно использовать с помощью элемента pm:CodedValue/ pm:Translation.

R0024: участник SDC должен использовать контекстно-независимое числовое представление кода, если система кодирования поддерживает его.

Примечание — R0024 позволяет напрямую находить код в номенклатуре, так как для поиска понятия, которое представляет код, не требуется дополнительной информации, такой как раздел. Это означает использование не зависящих от контекста кодов номенклатуры, как определено в 7.2.1 ГОСТ Р 56842—2015.

7.2 Средства удаленного управления

7.2.1 Описание средств удаленного управления

R0002: поставщик сервисов SDC должен описать все предлагаемые возможности удаленного вызова для передачи через MDPWS, используя структуру pm:ScoDescriptor в pm:AbstractComplexDevice-ComponentDescriptor/pm:Sco.

Примечание — R0002 уточняет требование biceps:R0011, так что все возможности удаленного управления, использующие в качестве транспортного протокола MPDWS, должны быть описаны как элементы дерева включений.

R0025: поставщик сервисов SDC должен гарантировать, что значение любой операции удаленного вызова определено комбинацией элементов pm:AbstractOperationDescriptor/pm:Type и pm:Abstract-OperationDesriptor/pm:OperationTarget.

Примечание — Для упрощения реализации, не требующей синтаксического анализа pm:AbstractSet-StateOperationDescriptor/pm:ModifiableData, данная спецификация требует, чтобы поставщик сервисов SDC указал pm:AbstractOperationDescriptor/pm:Type.

R0026: если элемент pm:AbstractOperationDescriptor/@Type содержит кодированное значение из частной системы кодирования или частной части системы кодирования, то поставщик сервисов SDC может указать значение с помощью атрибута pm:AbstractSetOperationDescriptor/@ModifiableData.

Примечание — Для того чтобы обеспечить ограниченную интерпретацию результата операции, поставщику сервисов SDC рекомендуется указать атрибут pm:AbstractSetOperationDescriptor/@ModifiedData.

R0027: если во время обмена сообщениями, которые вызывают команду удаленного управления, от потребителя сервисов SDC требуется передача информации по безопасности, поставщик сервисов SDC должен включить в поле ext:Extension дескриптора pm:AbstractOperationDescriptor элемент mdpws:SafetyReq.

Примечание — MDPWS требует, чтобы mdpws:SafetyReq Assertion вставлялся только в местах подключения политики WSDL, что налагает на потребителя сервисов SDC необходимость изучения WSDL. Встраивание mdpws:SafetyReq непосредственно в информационную базу медицинских данных (MDIB) упрощает реализацию, улучшает инкапсуляцию и позволяет потребителю сервисов SDC не заниматься анализом WSDL. Однако поставщик сервисов SDC может по-прежнему включать в WSDL вложения политики WSDL.

7

ГОСТ Р 71704—2024

R0057: если поставщик сервисов SDC требует, чтобы при обмене сообщениями от потребителя сервисов SDC передавалась информация по безопасности, то он должен определить выражения XPath для mdpws:SafetyContextDef/mdpws:Selector с корневым узлом XPath, равным элементу pm:Mdib в текущей версии MDIB данного поставщика сервисов SDC.

Примечания

1 R0057 устанавливает корневой узел XPath, поскольку в [2] не определяется корневой узел.

2 Установка «./Your-XPath-Here» корневого узла XPath в pm:Mdib для mdpws:SafetyContextDef/mdpws:Selector эквивалентна применению следующего выражения XPath к любому информационному набору XML, содержащему класс pm:Mdib:«//Mdib[1]/Your-XPath-Here», где Mdib ссылается на первый элемент pm:Mdib, который является корневым для данного выражения XPath, в соответствии с [12].

R0028: если ошибочный или непреднамеренный вызов операции приводит к неприемлемому риску, поставщик сервисов SDC для всех элементов pm:AbstractOperationDescriptor должен указать атрибут pm:AbstractOperationDescriptor/@SafetyClassification для всех SCO.

Примечание — Для операций удаленного управления для всех элементов pm:AbstractOperation-Descriptor подразумевается классификация безопасности «Inf», что может не соответствовать безопасному состоянию для операции удаленного управления, и поэтому необходимо учитывать, соответствует ли это значению, установленному в рамках управления рисками.

R0060: атрибут pm:AbstractOperationDescriptor/@SafetyClassification каждого элемента pm:AbstractOperationDescriptor должен соответствовать риску, связанному с ошибочным или непреднамеренным вызовом операции.

R0065: поставщик сервисов SDC должен отправлять любые изменения, являющиеся результатом команды удаленного управления в той же версии MDIB, что и msg:OperationlnvokedReport, которое указывает на завершение выполнения.

R0066: если mdpws:SafetyContextDef не ссылается ни на один из атрибутов версии MDIB, потребитель сервисов SDC должен убедиться в том, что оператор осведомлен о содержимом каждого определенного элемента mdpws:SafetyContextDef в pm:AbstractOperationDescriptor до вызова этой операции командой удаленного управления.

Примечания

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

2 Если для оператора требуется знание атрибута версии MDIB, то могут быть использованы суррогаты. Суррогатами могут быть клинически значимые информационные объекты, которые получены из дескрипторов или состояний в данной версии, например: объект «текущее значение» в сочетании с объектом «текущая единица измерения» или с другими атрибутами дескриптора и состояния.

7.2.2 Поведение средств удаленного управления

R0003: поставщик сервисов SDC может отклонить входящую операцию сервиса запрос-ответ, вызываемую сервисом SET, если потребитель сервисов заранее не подписался на сообщения msg:OperationlnvokedReport с помощью:

- msg:lnvocationlnfo/msg:lnvocationState, в котором установлено значение «Fail»;

- msg:lnvocationlnfo/msg:lnvocationError, в котором установлено значение «0th».

Примечания

1 R0003 упрощает требование biceps:R0057, поэтому отсутствие подписки может привести к сбою.

2 Для согласования вызовов операции сервиса запрос-ответ в сервисе SET с предыдущими подписками может быть использована идентификационная информация, приведенная в сертификате Х.509.

R0029: потребитель сервисов SDC не должен вызывать операцию сервиса запрос-ответ, связанную с pm:AbstractOperationDescriptor, не содержащую определенного атрибута pm:AbstractOperationDescriptor/@SafetyClassification.

Примечание — В R0029 слово «определенный» означает, что во время передачи от поставщика сервисов SDC потребителю сервисов SDC любого сообщения, включающего атрибут Safetyclassification, он не был пустым.

8

ГОСТ Р 71704—2024

R0077: для идентификации неизвестного участника SDC, вызвавшего операцию сервиса, поставщик сервисов SDC должен использовать следующие атрибуты pm:Instanceidentifier:

- @Root=“http://standards.ieee.org/downloads/11073/11073-20701-2018”;

- @Extension=“AnonymousSdcParticipant”.

R0078: для идентификации известного участника SDC, вызвавшего операцию сервиса, поставщик сервисов SDC должен использовать следующие атрибуты pm:Instanceidentifier:

- @Root=“http://standards.ieee.org/downloads/11073/11073-20701 -2018/DistinguishedName”;

- @Extension=Oбщee имя УЧАСТНИКА SDC из отличительного имени (DN) сертификата х.509.

7.3 Возможность извлечения элементов дерева включений

R0005: поставщик сервисов SDC должен включить в качестве дескриптора ext:Extension элемент msg:Retrievability для всех элементов дерева включений, которые можно извлечь с помощью сервисов спецификации BICEPS, отличных от сервиса GET.

R0030: потребитель сервисов SDC может предполагать, что любой элемент дерева включений может быть получен с помощью сервиса GET спецификации BICEPS, даже если в расширение дескриптора не включен элемент msg:Retrievability.

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

7.4 Динамические изменения дерева включений

R0031: для обозначения изменений, которые по определению поставщика сервисов SDC могут негативно повлиять на использование потребителем сервисов SDC элемента дерева включений, поставщик должен использовать msg:DescriptionModificationReport с атрибутом @ModificationType=“Upt”.

Примечания

1 R0031 затрагивает критические изменения, например обновление атрибута pm:AbstractMetricDescriptor/@ Safetyclassification. Модификации считают критическими изменениями, если они могут негативно повлиять на использование элемента дерева включений, т. е. если потребитель сервисов SDC может неправильно интерпретировать устаревшие состояния, применяя обновленный дескриптор к ранее сохраненным значениям. Например, если классификация безопасности изменяется на классификацию медицинской безопасности, а потребитель сервисов SDC применяет это изменение к предыдущим версиям состояния, которые не имеют классификации медицинской безопасности, он может ложно отобразить их как подходящие для медицинских целей, например в представлении тенденций.

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

R0073: для указания изменений, которые по определению поставщика сервисов SDC не могут негативно повлиять на использование потребителем сервисов SDC элемента дерева включений, он должен использовать сообщение msg:DescriptionModificationReport, имеющее атрибут msgDescripti onModificationReport/msg:ReportPart/@ModificationType=“Del” или msg description Modification Report/ msg:ReportPart/@ModificationType=“Crt”.

Примечание — R0073 затрагивает некритические изменения, например добавление в виртуальный медицинский прибор (VMD) нового канала или изменение клинической значимости метрик в канале путем обращения к списку pm:VmdDescriptor/pm:Channel.

R0059: если медицинский прибор PoS способен определять значение метрики с использованием более чем одной единицы измерения, то поставщик сервисов SDC должен выделить отдельный элемент дерева включений для каждой метрики.

Примечание — Для всех метрик такого типа, имеющих другие единицы измерения, которые не активированы в данный момент, но могут быть активированы без необходимости перезагрузки, поставщик сервисов SDC устанавливает для атрибута pm:AbstractMetricState/@ActivationState значение StndBy.

9

ГОСТ Р 71704—2024

7.4.1 Модульные медицинские приборы РоС

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

- для атрибута pm:AbstractDeviceComponentState/@ActivationState удаленной подсистемы установлено значение Off в соответствии с требованием biceps:R00254;

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

Примечания

1 Подсистема представлена виртуальным медицинским прибором (VMD) или каналом.

2 Элементами дерева включений, которые могут ссылаться на элементы дерева включений удаленной подсистемы, могут быть, например:

- pm:AlertConditionDescriptor для pm:AlertSystemDescriptor, где pm:AlertSystemDescriptor находится на родительском уровне по отношению к элементу дерева включений удаленной подсистемы, или

- pm:AbstractOperationDescriptors для pm:ScoDescriptor, где pm:ScoDescriptor находится на родительском уровне по отношению к элементу дерева включений удаленной подсистемы.

7.5 Управление версиями MDIB

Если медицинский прибор РоС имеет как минимум один UDI, поставщик сервисов SDC определяет атрибут pm:MdibVersionGroup/@Sequenceld с использованием алгоритма UUIDv5, где:

- пространство имен представляет собой первичный UDI медицинского прибора РоС в формате UUIDv5, в котором первичный UDI рассчитывают на основе данных для пространства имен UUIDv5 по таблице 2 и pm :MdsDescriptor/pm:MetaData/pm: Udi/pm:HumanReadableForm для имени UUIDv5;

- имя является уникальным идентификатором Instanceld, если оно существует.

Примечания

1 Для того чтобы система сбора данных могла хранить сообщения, полученные от поставщика сервисов SDC, целесообразно, чтобы атрибут MdibVersionGroup/@Sequenceld был уникальным. Атрибут MdibVersionGroup/@ Sequenceld, если он указан, уникален только в пределах одного экземпляра MdibVersionGroup/@lnstanceld, но не для разных поставщиков сервисов SDC (см. [2]).

2 Уникальным идентификатором может быть либо атрибут pm:MdibVersionGroup/@lnstanceld, если он используется, либо UUID любого типа, например UUIDv4.

3 Базовое пространство имен SDC для генерации UUIDv5 определено в приложении А.

4 Например, для первичного UDI медицинского прибора РоС пространством имен для FDA UDI, pm:MdsDescriptor/pm:MetaData/pm:Udi/pm:HumanReadableForm которого равен «(01 )00884838038752(21) DE35115712», является 845754В1 -8934-51D7-9EA1-203FB7A8B1 B9=uuidv5(“6F8C705D-3A57-5736-A501 -

972Е826947Е8”, “(01 )00884838038752(21 )DE35115712").

Таблица 2 — Рассчитанное отображение пространства имен первичного UDI в первичный UDI UUIDv5

7.6 Классы

R0080: поставщик сервисов SDC должен определить pm:AbstractDescriptor/pm:Type для элементов следующих классов или любых классов, производных от указанных:

- pm:AbstractComplexDeviceComponentDescriptor;

- pm:ChannelDescriptor;

- pm:AbstractOperationDescriptor;

- pm:AlertConditionDescriptor;

- pm:AbstractMetricDescriptor.

10

ГОСТ Р 71704—2024

Примечание — R0080 определяет, что для облегчения семантической интерпретации элементов некоторые необязательные классы для pm:AbstractDescriptor/pm:Type являются обязательными.

8 Привязка коммуникационной модели

Все требования, содержащиеся в [1] (7.1, раздел 8 и приложение А), приведены качестве справочной информации, за исключением тех случаев, когда они заменены нормативными положениями, приведенными в настоящем стандарте.

8.1 Сервис

Все требования, содержащиеся в [1] (7.1) и в [2] (раздел 6), приведены в качестве справочной информации, за исключением тех случаев, когда они заменены нормативными положениями, приведенными в настоящем стандарте.

R0058: для любого сервиса, размещенного в профиле MDPWS, участник SDC может использовать ТСР-порт 6464.

Примечания

1 В соответствии с настоящим стандартом ТСР-порт 6464 зарезервирован администрацией IANA для взаимодействия с медицинскими приборами.

2 Поставщик сервисов SDC может использовать порт 6464 для сервиса хостинга MDPWS и/или размещенных в MDPWS сервисов.

3 Потребитель сервисов SDC может использовать порт 6464 для приема событий MDPWS.

Все входящие и исходящие сообщения операций сервисов WSDL поставщика сервисов SDC представлены в приложении Б.

8.1.1 Обработка подписки

R0034: если поставщик сервисов SDC обладает возможностями, для которых требуется сервис спецификации BICEPS, поставщик сервисов SDC на основе одного размещенного в MDPWS сервиса должен реализовать, по крайней мере, следующие сервисы BICEPS:

- Description Event (событий описания);

- State Event (событий состояния);

- Context (контекста);

- Waveform (биосигналов).

R0035: потребитель сервисов SDC должен подписаться на сообщения уведомления и потоковой передачи от перечисленных ниже сервисов спецификации BICEPS с помощью одного сообщения wse:Subscribe, если потребителю сервисов SDC требуются данные, передаваемые с этими сообщениями, и данные сервисы BICEPS передаются с использованием механизмов, определенных в [2] (раздел 7):

- Description Event (событий описания);

- State Event (событий состояния);

- Context (контекста);

- Waveform (биосигналов).

R0056: перед любым сообщением от сервиса State Event, сервиса Waveform или сервиса Context спецификации BICEPS, имеющим измененный pm:AbstractState, который также содержится в msg:De-scriptionModificationReport, поставщик сервисов SDC должен отправить сообщение msg:DescriptionModi-ficationReport.

Примечание — Требования R0035 и R0056 гарантируют, что изменения в MDIB передаются в правильном порядке сообщений. Единственным исключением является msg:OperationlnvokedReport, так как он не передает состояние MDIB напрямую.

R0036: поставщик сервисов SDC должен прекратить отправку сообщений уведомления или потоковой передачи подписанному потребителю сервисов SDC, если доставка одного сообщения, связанного с подпиской этого потребителя сервисов SDC, завершилась неудачей и если эти сообщения передаются с использованием механизмов, определенных в [2] (раздел 7).

Примечание — Если поставщик сервисов SDC прекратил отправку сообщений потребителю сервисов SDC из-за сбоя доставки и если потребитель сервисов SDC со своим сообщением wse:Subscribe передает

11

ГОСТ Р 71704—2024

wse:EndTo, то поставщик сервисов SDC отправляет сообщение wseiSubscriptionEnd с wse:Status, указывающим на сбой доставки.

8.1.2 Большие полезные нагрузки

R0067: поставщик сервисов SDC должен использовать код состояния HTTP 413 (чрезмерно большая полезная нагрузка), чтобы указать, что ответ на сообщение запроса может быть исполнен, но длина содержимого превысит максимальную длину сообщения, определенную в MDPWS:R0006.

Примечания

1 Вероятнее всего, R0067 будет использован для ответных сообщений, полученных от сервиса GET, сервиса ARCHIVE и сервиса LOCALIZATION спецификации BICEPS.

2 R0067 позволяет потребителю сервисов SDC вызывать ту операцию спецификации BICEPS, для которой он получил код состояния HTTP 413, используя фильтр, ограничивающий ожидаемый ответ, например разбивает запрошенный диапазон дескрипторов.

8.1.3 Сервис Description event (сервис события описания)

Если медицинский прибор РоС может быть дополнен съемными подсистемами, то поставщик сервисов SDC для этого медицинского прибора РоС должен предоставить сервис Description event спецификации BICEPS.

8.1.4 Сервис Localization (сервис локализации)

R0068: если для обнаружения медицинский прибор PoS поддерживает более одного языка, то поставщик сервисов SDC должен предоставить такие языки.

R0069: если поставщик сервисов SDC предоставляет более одного языка, он должен предоставить сервис Localization спецификации BICEPS.

Примечания

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

2 Медицинский прибор РоС может быть обнаружен как поставщик сервисов SDC, если он отвечает на сообщения явного обнаружения и отправляет сообщения неявного обнаружения, как определено в 9.1.

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

8.1.5 Определение приоритетности установления соединения

R0076: потребитель сервисов SDC должен задержать отправку первого сообщения HTTP(S) независимо от его типа в конечную точку после получения сообщения неявного обнаружения на время задержки Td, где:

- существует 10 классов приоритетов с идентификаторами 0—9, где 0 — наиболее высокий приоритет, 9 — наиболее низкий приоритет, а потребитель сервисов SDC сконфигурирован в один из классов приоритета, и

- время задержки Td — это случайное число, отвечающее следующим условиям: prio_group_ id*5[s]<Td<(prio_group_id*5[s])+15 [s].

Примечания

1 R0076 допускает различные конфигурации классов приоритетов потребителя сервисов SDC для разных поставщиков сервисов SDC.

2 R0076 позволяет поставщику сервисов SDC ограничить число на основе сконфигурированного приоритета, так как сервисы устанавливают соединение в определенной последовательности.

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

8.2 Сообщение

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

12

ГОСТ Р 71704—2024

8.2.1 Передача

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

Примечания

1 Привязка BICEPS должна предусматривать средства, позволяющие различать уникальные сообщения в последовательности сообщений с потенциальными дубликатами, что соответствует требованию biceps:R0093 (см. [2], раздел 4).

2 Сериализация сообщений (см. [2], раздел 11) позволяет использовать компактную передачу, что отражено в [13].

8.2.2 Запрос-ответ

Примечание — См. [2], раздел 9.

8.2.3 Опубликовать-подписаться

Примечание — См. [2], раздел 7.

8.2.4 Настраиваемая фильтрация подписок

R0038: диалект фильтра на основе дескриптора обозначается как «sdc.filter://Handle» и включает следующие характеристики:

- на этом диалекте фильтр содержит разделенный пробелами список класса pm:HandleRef, а также прикрепленные к wse:Filter атрибуты pm:MdibVersionGroup/@Sequenceld и pm:MdibVersionGroup/@lnstanceld, указывающие полные дескрипторы необходимых элементов дерева вложений;

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

Примечание — На этом диалекте фильтр, в котором не указан pm:HandleRef или pm:MdibVersionGroup, определяет подписку на пустой набор, и поэтому уведомления по этой подписке передаваться не будут.

Полнофункциональный дескриптор наряду с классом pm:HandleRef подразумевает комбинацию атрибутов @Sequenceld и @lnstancelD в pm:MdibVersionGroup.

R0070: заданный класс pm:HandleRef в фильтре на основе дескриптора подразумевает подписку на все уведомления данного определенного элемента дерева вложений.

Примечания

1 R0070 не учитывает объекты, связанные с элементом дерева вложений, на который ссылается класс pm:HandleRef, или те, на которые ссылается элемент дерева вложения, например сигналы предупреждения об опасности, или операции, или элементы pm:AbstractMetricDescriptor/pm:Relation.

2 Этотакже подразумевает, что в случае атрибута pm:AbstractDescriptor/@Handle, где для pm:AbstractDescriptor существует несколько состояний, создается подписка на уведомления обо всех этих состояниях.

R0037: потребитель сервисов SDC должен подписаться на источники событий, используя диалект фильтра на основе дескриптора в сообщении wse:Subscribe, если его интересуют только некоторые изменения элемента дерева вложений с определенным набором pm:Handle.

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

R0039: поставщик сервисов SDC должен поддерживать фильтрацию с помощью диалекта фильтра на основе дескриптора.

Примечание — Если поставщик сервисов SDC не поддерживает диалект фильтра на основе дескриптора, он должен ответить на сообщение wse:Subscribe, содержащее wse:Filter, сообщением об ошибке класса wse :FilteringRequestedllnavailable. Подписка не создается.

8.2.5 Потоковая передача

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

13

ГОСТ Р 71704—2024

R0040: поставщик сервисов SDC должен в каждое потоковое сообщение включать ссылку на конечную точку в элемент wsa:From (см. [14]).

Примечание — Поле заголовка wsa:From определено как необязательное (см. [2]). Чтобы обеспечить определение происхождения пакета потоковой передачи, заголовка wsa:From в качестве исходного IP-адреса может быть недостаточно, особенно в тех случаях, когда на одном сетевом узле функционируют несколько поставщиков сервисов SDC.

R0041: поставщик сервисов SDC для организации потоковой передачи может использовать механизм WS-Eventing (см. [2], раздел 7).

Примечание — Пояснение к [2] (раздел 8) состоит в том, что даже при указании потоковой передачи фактически используемый транспорт может быть не тем, который определен в указанном разделе, а тем, который определен в [2] (раздел 7).

9 Привязка обнаружения

R0042: поставщик сервисов SDC должен включить атрибут dpws:DiscoveryType со значением http:// standards.ieee.org/downloads/11073/11073-10207-2017/ServiceProvider в свое WSDL-описание portType.

Примечание — R0042 соответствует требованию biceps:R0123: привязка BICEPS должна определять тип обнаружения (см. [2]).

9.1 Механизм обнаружения

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

Примечания

1 Привязка BICEPS должна обеспечивать средства для неявного обнаружения согласно требованию biceps:R0078 (см. [2], раздел 4).

2 Привязка BICEPS должна обеспечивать средства для явного обнаружения согласно требованию biceps:R0078 (см. [2], раздел 5).

9.2 Обнаружение сложных приборов, состоящих из компонентов

Для каждого экземпляра, созданного из pm:AbstractComplexDeviceComponentDescriptor в MDIB, поставщик сервисов SDC должен в качестве dpws:Scope сообщений обнаружения MDPWS указать pm :AbstractComplexDeviceComponentDescriptor/pm:Type в кодировке URI. Кодировка URI соответствует следующей расширенной форме Бэкуса — Наура:

Scheme ::= ‘sdc.cdc.type’

CodingSystem ::= Segment

CodingSystemVersion ::= Segment

Code ::= SegmentNz

CdcType ::= 7’ CodingSystem 7’ CodingSystemVersion 7’ Code

CdcTypeUri ::= Scheme ':' CdcType

где:

- Scheme — это класс URI-схемы «Компонент сложного устройства»;

- содержание CodingSystem — это атрибут pm:CodedValue/@CodingSystem из pm:AbstractComp-lexDeviceComponentDescriptor/pm:Type. Пустой CodingSystem означает использование системы кодирования по умолчанию, как определено в pm:CodedValue;

- содержание CodingSystemVersion — это атрибут pm:CodedValue/@CodingSystemVersion из pm:AbstractComplexDeviceComponentDescriptor/pm:Type или пустая строка, если она не указана;

- содержание из Code — это атрибут pm:CodedValue/@Code из pm:AbstractComplexDeviceCompo-nentDescriptor/pm:Type;

- CdcTypeUri — это закодированный URI.

14

ГОСТ Р 71704—2024

Примечания

1 Segment соответствует сегменту, определенному в [15] (3.3).

2 SegmentNz соответствует сегменту nz, который является сегментом ненулевой длины.

3 Требование данного подраздела соответствует требованию biceps:R0134: привязка BICEPS должна обеспечивать доступность классов MDS для обнаружения.

4 Примером для MDS аппарата искусственной вентиляции легких является sdc.cdc.type:///70001. 70001 — это контекстно-независимый код из 1::4465 по ГОСТ Р 56842, который соответствует системе кодирования по умолчанию. Таким образом, атрибуты системы кодирования и версии системы кодирования не указаны.

5 Переводы элементов pm:CodedValue могут быть добавлены как отдельные элементы dpws:Scope.

9.3 Обнаружение по основной роли участника SDC

Для каждой основной роли участника SDC, которая также определяется с помощью механизмов создания доверительного отношения (см. 10.2.3), поставщик сервисов SDC должен в качестве dpws:Scope сообщений обнаружения MDPWS указать основную роль участника SDC в кодировке URI. Кодировка URI соответствует следующей расширенной форме Бэкуса — Наура:

Scheme ::= ‘sdc.mds.pkp’

CodingSystem ::= Segment

CodingSystemVersion ::= Segment

Code ::= SegmentNz

Pkp ::= KeyPurposeOid

PkpTypeUri ::= Scheme ':’ Pkp где:

- Scheme — это класс URI-схемы «основная роль участника SDC»;

- содержание KeyPurposeOid — это текстовое представление идентификатора объекта основная роль участника SDC;

- PkpTypeUri — это закодированный URI.

R0079: участник SDC должен в качестве dpws:Scope сообщений обнаружения MDPWS указать основную роль участника SDC в кодировке URI, определенную в настоящем пункте для объявления своих сертифицированных функций (см. 10.2.3).

9.4 Обнаружение по контексту

Для каждого ассоциированного в MDIB контекста поставщик сервисов SDC должен в качестве dpws:Scope сообщений обнаружения MDPWS указать pm:AbstractContextState/pm:ldentification в кодировке URI. Кодировка URI соответствует следующей расширенной форме Бэкуса — Наура:

Scheme := ‘sdc.ctxt.’ (‘loc’ | ‘pat’ | ‘ens’ | ‘wfl’ | ‘opr’ | mns’)

NullFlavorRoot ::= ‘biceps.uri.unk’

Root ::= NullFlavorRoot | SegmentNz

Extension ::= Segment

Instanceidentifier ::= 7’ Root 7’ Extension

ContextUri ::= Scheme “:’ Instanceidentifier (‘?’ Query)? где:

- Scheme определяет URI-схему, в которой также кодируется класс контекста местоположения, т. е. loc — это контекст местоположения, pat — это контекст пациента, ens — это контекст коллектива, wfl — это контекст рабочего процесса, орг — это контекст оператора, a mns — это контекст средства;

- NullFlavorRoot кодирует корень нулевого флейвора, как определено в требовании biceps:R0135;

- Root соответствует или кодировке нулевого флейвора, или атрибуту pm:AbstractContextState/ pm:ldentification/@Root, если он не нулевой;

- Extension соответствует атрибуту pm:AbstractContextState/pm:ldentification/@Extension и не учитывается, если указан только атрибут pm:AbstractContextState/pm:ldentification/@Root;

- ContextUri — это закодированный URI.

Примечания

1 Segment соответствует сегменту, определенному в [15] (3.3).

2 Query соответствует запросу и содержит неиерархические идентификационные данные. LocCtxtQuery — это особый экземпляр запроса, описание которого приведено в 9.4.1.2.

15

ГОСТ Р 71704—2024

9.4.1 Контекст местоположения

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

R0006: поставщик сервисов SDC должен определить идентификатор экземпляра для контекста местоположения, используя резервный алгоритм идентификации экземпляра, как определено в 9.4.1.1, если SOMDS не имеет полномочий по присвоению идентификатора экземпляра.

9.4.1.1 Резервный алгоритм идентификации экземпляра

Поставщик сервисов SDC должен поддерживать следующий алгоритм определения идентификатора экземпляра для контекста местоположения из pm:LocationContextState\pm:LocationDetail, описанный в расширенной форме Бэкуса — Наура:

Facility ::= SegmentNz

Building ::= SegmentNz

PointOfCare ::= SegmentNz

Floor ::= SegmentNz

Room ::= SegmentNz

Bed ::= SegmentNz

Delim ::= 7’

LocRootSegment ::= ‘sdc.ctxt.loc.detail’

LocExtensionSegment ::= ((Facility)? Delim (Building)? Delim (Floor)?

Delim (PointOfCare)? Delim (Room)? Delim (Bed)?) — (Delim Delim Delim

Delim Delim) // хотя бы один элемент, содержащий один символ

где:

- Facility заимствован из атрибута pm:LocationContextState\pm:LocationDetail/@Facility, при его наличии;

- Building заимствован из атрибута pm:LocationContextState\pm:LocationDetail/@Building, при его наличии;

- PointOfCare заимствован из атрибута pm:LocationContextState\pm:LocationDetail/@PointOfCare, при его наличии;

- Floor заимствован из атрибута pm:LocationContextState\pm:LocationDetail/@Floor, при его наличии;

- Room заимствован из атрибута pm:LocationContextState\pm:LocationDetail/@Room, при его наличии;

- Bed заимствован из атрибута pm:LocationContextState\pm:LocationDetail/@Bed, при его наличии;

- LocRootSegment — это корень идентификатора экземпляра для определения конкретного местоположения;

- LocExtensionSegment — это расширение идентификатора экземпляра для определения конкретного местоположения.

Примечание — SegmentNz соответствует сегменту nz, который является сегментом ненулевой длины.

9.4.1.2 Преобразование запроса контекста местоположения

Поставщик сервисов SDC должен преобразовать класс pm:LocationDetail ассоциированного контекста в компоненты URI, где запрос соответствует следующей расширенной форме Бэкуса — Наура:

Queryitem ::= (‘fac=’ Facility) | (‘bldng=’ Building) | (‘poc=’PointOfCare) | (‘flr=’ Floor) | (‘rm=’ Room) | (‘bed=’ Bed)

LocCtxtQuery ::= (Queryitem ('&’ Queryitem)*)?

где:

- Facility заимствован из атрибута pm:LocationContextState\pm:LocationDetail/@Facility, при его наличии;

- Building заимствован из атрибута pm:LocationContextState\pm:LocationDetail/@Building, при его наличии;

- PointOfCare заимствован из атрибута pm:LocationContextState\pm:LocationDetail/@PointOfCare, при его наличии;

- Floor заимствован из атрибута pm:LocationContextState\pm:LocationDetail/@Floor, если доступно;

- Room заимствован из атрибута pm:LocationContextState\pm:LocationDetail/@Room, при его наличии;

16

ГОСТ Р 71704—2024

- Bed заимствован из атрибута pm:LocationContextState\pm:LocationDetail/@Bed, при его наличии;

- LocCtxtQuery вводится как запрос к компонентам URI контекста местоположения.

9.4.1.3 Данные контекста местоположения

Если поставщик сервисов SDC предоставляет класс pm: LocationContextState\pm: Location Detail, он должен указать в нем следующие атрибуты:

- LocationDetail/@Facility;

- LocationDetail/@PoC;

- LocationDetail/@Bed.

9.5 Объявление об отсутствии

Примечание — Потребителям сервисов рекомендуется обнаруживать отсутствие приборов, даже если поставщик сервисов SDC должен отправлять извещение в случае сбоев связи, например в случае потери сообщения.

10 Нефункциональные атрибуты качества

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

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

10.1 Безопасность информационных технологий

Специальная категория персональных данных, передаваемых медицинскими приборами, подлежит защите в соответствии с [12]—[18].

Реализация протокола TLS с использованием криптографических алгоритмов должна быть выполнена в соответствии с положениями [19] (TLS 1.2) и [20] (TLS 1.3).

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

Примечания

1 Привязка к требованиям, определенным в [2] (раздел 10), в частности к TLS, соответствует требованию biceps:R0087: привязка должна обеспечивать средства, реализующие конфиденциальную передачу сообщения между двумя участниками (см. [2]).

2 Привязка к требованиям, определенным в [2] (раздел 10), в частности к TLS, соответствует требованию biceps:R0088: привязка должна обеспечивать средства, реализующие целостность сообщения во время транспортировки между двумя участниками (см. [2]).

3 Привязка к требованиям, определенным в [2] (раздел 10), в частности к взаимной аутентификации TLS, соответствует требованию biceps:R0089: привязка должна обеспечивать средства, позволяющие определить отправителя сообщения (см. [2]).

4 Привязка к требованиям, определенным [2] (раздел 10), в частности к взаимной аутентификации TLS, соответствует требованию biceps:R0084: привязка BICEPS должна обеспечивать средства, позволяющие обнаруживать поврежденные данные в сообщении.

R0063: участник SDC не должен использовать SSL2.0 (см. [2]), SSL3.0, TLS 1.0 или TLS1.1.

R0064: участник SDC должен использовать последнюю версию TLS.

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

R0074: участник SDC должен установить защищенный канал MDPWS только с другими участниками SDC, если обмен сообщениями сданным участником SDC не может привести к неприемлемому риску.

Примечание — R0074 ограничивает использование защищенного канала доверенными участниками SDC на основании информации о сертификате и цепочки сертификации.

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

17

ГОСТ Р 71704—2024

Примечания

1 R0043 соответствует требованию biceps:R0120, так как защищенный канал для всех сообщений определяют только по протоколу TLS с взаимной аутентификацией (см. [2]).

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

R0044: участник SDC должен передавать любое сообщение, содержащее контекстную информацию, только участникам SDC.

Примечание — R0044 ограничивает передачу от любого участника только участниками SDC.

R0045: в качестве общего имени отличительного имени в сертификатах Х.509 участник SDC должен использовать первичный UDI медицинского прибора РоС в формате UUIDv5, как описано в 7.5.

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

R0046: участник SDC не должен отправлять конверт SOAP без защиты целостности любых блоков заголовка информации сообщения, соответствующих следующим выражениям XPath:

a) /soap:Envelope/soap:Header/wsa: Action,

б) /soap:Envelope/soap:Header/wsa:MessagelD,

в) /soap:Envelope/soap:Header/wsa:To,

г) /soap:Envelope/soap:Header/wsa:ReplyTo,

д) /soap:Envelope/soap:Header/wsa:RelatesTo,

e) /soap:Envelope/soap:Header/wsa:FaultTo, и

ж) /soap:Envelope/soap:Header/*[@isReferenceParameter=’true’].

Примечание — R0046 снижает требование mdpws:R0018.

10.2 Безопасность пациентов

10.2.1 Использование информации

R0047: участник SDC должен снизить риски, связанные с задержкой или потерей сообщений, если они приводят к неприемлемому риску.

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

R0061: если участник SDC использует информацию, полученную от другого участника SDC, способом, который не предусмотрен атрибутом pm:AbstractDescriptor/@SafetyClassification, он должен снизить риски, связанные с ошибочной информацией.

Примечания

1 Производитель устройства потребителя сервисов SDC может считать, что риски, относящиеся к использованию в соответствии с атрибутом pm:AbstractDescriptor/@SafetyClassification, не приводят к неприемлемым рискам из-за ошибочной информации.

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

R0048: если ошибочная информация приводит к неприемлемому риску, потребитель сервисов SDC должен использовать только те метрики, для которых атрибут pm:MetricQuality/@Validity является действительным или подтвержденным.

10.2.2 Использование операции

R0062: потребитель сервисов SDC должен снизить риски, связанные с ошибочным или непреднамеренным вызовом операции в соответствии с атрибутом pm:AbstractOperationDescriptor/@ Safetyclassification.

Примечание — Производитель устройства потребителя сервисов SDC должен учитывать, что ошибочный или случайный вызов pm:ScoDescriptor/pm:Operation может привести к опасным ситуациям.

10.2.3 Создание доверительного отношения

Как определено в 10.1, для обеспечения безопасности взаимодействия между участниками использован протокол TLS.

18

ГОСТ Р 71704—2024

R0051: при необходимости предотвращения неприемлемого риска участник SDC должен использовать расширение Extended Key Usage (EKU) сертификата x.509 потребителя сервисов для ограничения модификаций, которые изменяют рабочие характеристики.

Примечания

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

2 R0051 соответствует требованию biceps:R0083: привязка BICEPS должна обеспечивать средства авторизации участников.

R0052: участник SDC в расширении EKU сертификата х.509 должен указать основную роль участника SDC для объявления своих сертифицированных функций, как определено в таблице 3.

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

Таблица 3 — Основные роли для объявления функций

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

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

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

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

R0054: поставщик сервисов SDC может обнаруживать потери подключений к потребителю сервисов SDC, устанавливая короткий срок действия подписки.

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

Примечание — R0054 и R0055 соответствуют требованию biceps:R0127: привязка BICEPS должна обеспечивать средства, позволяющие обнаруживать потерю подключения одного участника к другому участнику.

10.3 Клиническая эффективность

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

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

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

19

ГОСТ Р 71704—2024

R0007: участник SDC должен поддерживать синхронизацию времени, используя протоколы NTP версии 3 или другой совместимой версии, указанной ранее.

Примечания

1 R0007 соответствует требованию biceps:R0090: привязка, соответствующая [2], должна обеспечивать средства, позволяющие синхронизировать время в SOMDS.

2 NTP версии 4 являются примером совместимой версии.

3 Протоколы SNTP имеют недостатки, касающиеся временной корреляции данных из-за возможных скачков во времени, поэтому они не рекомендуются в SOMDS.

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

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

R0010: поставщик сервисов SDC должен указать pm:ClockDescriptor и pm:ClockState.

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

R0071: поставщик сервисов SDC должен обеспечить метки времени для требуемых и выполненных калибровок в атрибуте pm:Calibrationlnfo/@Time.

R0012: поставщик сервисов SDC должен обеспечить метки времени для атрибутов pm: AlertConditionState/@DeterminationTime и pm:AlertSystemState/@LastSelfCheck.

Примечание — Соответствующие атрибуты см. в biceps:B.452 (метка времени), например pm:AbstractMetricValue/@DeterminationTime или pm:AlertConditionState/@DeterminationTime.

R0013: поставщик сервисов SDC должен обеспечить метки времени для атрибута pm:AbstractContextState/@BindingStartTime, если указан атрибут pm:AbstractContextState/@ BindingMdibVersion.

R0072: поставщик сервисов SDC должен обеспечить метки времени для атрибута pm:AbstractContextState/@BindingEndTime, если указан атрибут pm:AbstractContextState/@ UnbindingMdibVersion.

R0014: поставщик сервисов SDC должен указать метки времени для тех моментов, когда часы были синхронизированы с помощью атрибута pm:ClockState/@LastSet.

10.3.2 Качество сервиса при передаче

R0015: участник SDC при маркировке сообщений должен руководствоваться спецификацией DiffServ в отношении качества сервиса, необходимого для достижения клинической эффективности.

Примечания

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

2 R0015 соответствует требованию biceps:R0092: привязка, соответствующая [2], должна обеспечивать средства для определения показателей качества сервиса при взаимодействии между двумя участниками.

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

4 Маркировка сообщений относительно качества сервиса участником SDC, использующим спецификацию DiffServ, будет эффективной только в том случае, если сетевая инфраструктура для передачи сообщений также поддерживает спецификацию DiffServ.

R0016: участник SDC не должен маркировать какое-либо сообщение символом ускоренной пересылки (EF) РНВ.

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

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

20

ГОСТ Р 71704—2024

R0017: участник SDC должен маркировать сообщения, содержащие информацию, задержка или потеря которой может привести к риску для пациента, символом гарантированной пересылки (AF) РНВ, если не применены возможности R0019.

R0018: участник SDC должен использовать один и тот же класс гарантированной пересылки (AF) РНВ для всех сообщений, передаваемых другим участникам, если не применены возможности R0019.

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

R0021: если участник SDC передает метрики с классификацией медицинской безопасности, то он должен маркировать сообщения в своем классе AF РНВ как имеющие средний или низкий приоритет удаления, если не применены возможности R0019.

R0023: участник SDC должен маркировать любое сообщение, содержащее информацию только с немедицинской классификацией безопасности, как имеющую РНВ по умолчанию, если не применены возможности R0019.

11 Соответствие

Соответствующая реализация должна удовлетворять всем требованиям уровней «должен» и «требуется», определенным в настоящем стандарте.

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

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

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

ICS должны быть представлены в виде таблиц. Шаблоны для таких таблиц ICS приведены в таблицах 4—8. Таблицы должны быть заполнены и предоставлены в качестве документа общего заявления о соответствии.

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

- индекс, который является идентификатором конкретной функции;

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

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

- статус, который определяет требование соответствия (т. е. требования для определенной реализации в отношении функции). В некоторых случаях в настоящем стандарте не указаны требования соответствия, но тем не менее требуется определение статуса конкретной функции;

- поддержка, которая заполняется разработчиком и указывает характеристики функции в реализации;

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

Значение граф «Состояние» и «Поддержка» может варьироваться от простых до сложных записей. Примеры простых значений:

- М — обязательный;

- О — необязательный;

- X — запрещенный;

- С — условный;

- н/п — не применимо.

21

ГОСТ Р 71704—2024

11.2 Таблицы ICS

Таблица 4 — Версия MDIB

Таблица 5 — Фильтрация по дескриптору

Таблица 6 — Обнаружение

Таблица 7 — Безопасность информационных технологий

Таблица 8 — Качество сервиса при передаче

22

Таблица А.1—Константы

ГОСТ Р 71704—2024

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

Константы

23

ГОСТ Р 71704—2024

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

Описания сервисов WSDL поставщика сервисов SDC

Целевым пространством имен WSDLдoлжнo быть http://standards.ieee.Org/downloads/11073/11073-20701-2018, как определено в настоящем стандарте.

Примечание — Префиксом пространства имен для http://standards.ieee.org/downloads/11073/11073-20701-2018 обычно является «sdc.».

В таблицах Б.1 — Б.9 представлены входящие и исходящие сообщения операций сервисов WSDL поставщика сервисов SDC.

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

PortType: sdc:GetService

Таблица Б.1 — Операции сервиса SDC Get

Б.2 Сервис SET (установить)

PortType: sdc:SetService

Таблица Б.2 — Операции сервиса SDC Set

Б.З Сервис Description Event (событие описания)

PortType: sdc:DescriptionEventService

Таблица Б.З — Операции сервиса SDC Description Event

Б.4 Сервис State Event (событие состояния)

PortType: sdc:StateEventService

Таблица Б.4 — Операции сервиса SDC State Event

24

Окончание таблицы Б. 4

ГОСТ Р 71704—2024

Б.5 Сервис Context (контекст)

PortType: sdc:ContextService

Таблица Б.5 — Операции сервиса SDC Context

Б.6 Сервис Waveform (биосигнал)

PortType: sdc:WaveformService

Таблица Б.6 — Операции сервиса SDC Waveform

Б.7 Сервис Containment Tree (дерево включений)

PortType: sdc:ContainmentTreeService

Таблица Б.7 — Операции сервиса SDC Containment Tree

25

ГОСТ Р 71704—2024

Б.8 Сервис Archive (архив)

PortType: sdc:ArchiveService

Таблица Б.8 — Операции сервиса SDC Archive

Б.9 Сервис Localization (локализация)

PortType: sdc:LocalizationService

Таблица Б.9 — Операции сервиса SDC Localization

26

ГОСТ Р 71704—2024

[1] IEEE 11073-10207—2017

[2] IEEE 11073-20702—2016

[3] MOK 60601-1-

8:2006+AMD1:2012 CSV (консолидированная версия) [IEC 60601-1-8:2006+AMD1:2012 CSV (Consolidated version)]

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

Информатизация здоровья. Обмен данными с медицинскими приборами на месте оказания помощи. Часть 10207. Информация о предметной области и сервисная модель сервис-ориентированного обмена данными с медицинскими приборами на месте оказания помощи (Health informatics — Point-of-care medical device communication — Part 10207: Domain Information and Service Model for Service-Oriented Point-of-Care Medical Device Communication)

Информатизация здоровья. Обмен данными с медицинскими приборами на месте оказания помощи. Часть 20702. Профиль обмена данными с медицинскими приборами для веб-служб (Health informatics — Point-of-care medical device communication — Part 20702: Medical Devices Communication Profile for Web Services)

Медицинское электрическое оборудование. Часть 1—8. Общие требования к базовой безопасности и основным характеристикам. Сопутствующий стандарт: Общие требования, испытания и рекомендации для систем сигнализации в медицинском электрическом оборудовании и медицинских электрических системах (Medical electrical equipment. Part 1—8: General requirements for basic safety and essential performance. Collateral standard: General requirements, tests, and guidance for alarm systems in medical electrical equipment and medical electrical systems)

[4] W3C Extensible Markup Language (XML) 1.0 (Fifth Edition), Tim Bray et al., 28 November 2008

[7] W3C XML Schema 1.1, W3C, 28 October 2004

[8] W3C XML Path Language (XPath) Version 1.0, J. Clark et al., 7 September 2015

[9] W3C Namespaces in XML 1.0 (Third Edition), Bray T. et al., World Wide Web Consortium (W3C), 8 December 2009

[10] OASIS, Reference Model for Service Oriented Architecture 1.0, C. MacKenzie et al., October 2006

[11] W3C Note, Simple Object Access Protocol (SOAP) 1.1, D. Box, etal, Editors. World Wide Web Consortium (W3C), 8 May 2000

[12] Федеральный закон Российской Федерации от 27 июля 2006 г. № 152-ФЗ «О персональных данных»

[13] W3C Efficient XML Interchange (EXI) Format 1.0 (Second Edition), J. Schneider, and T. Kamiya, Editors. World Wide Web Consortium (W3C), 11 February 2014

[14] OASIS, Devices Profile for Web Services (DPWS) Version 1.1, T. Nixon, et al, Editors. 1 July 2009

[15] JETF RFC 3986, Uniform Resource Identifier (URI). Generic Syntax. 1 January 2005)

[16] Приказ ФСБ России от 10 июля 2014 г. № 378 г. Москва «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности»

[17] Приказ ФСТЭК России от 18 февраля 2013 г. № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»

27

ГОСТ Р 71704—2024

[18] Приказ Министерства здравоохранения России от 24 декабря 2018 г. № 911 н «Об утверждении требований к государственным информационным системам в сфере здравоохранения субъектов Российской Федерации, медицинским информационным системам медицинских организаций и информационным системам фармацевтических организаций»

[19] Р 1323565.1.020—2020

[20] Р 1323565.1.030—2020

Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.2)

Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.3)

[21] Kipp Е.В. Hickman, The SSL Protocol, Netscape Communications Corp., February 1995

УДК 61:004:006.354

OKC 35.240.80

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

Редактор Л. С. Зимилова

Технический редактор И.Е. Черепкова

Корректор О.В. Лазарева

Компьютерная верстка М.В. Малеевой

Сдано в набор 29.10.2024. Подписано в печать 07.11.2024. Формат 60x84%. Гарнитура Ариал.

Усл. печ. л. 3,72. Уч.-изд. л. 3,16.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Создано в единичном исполнении в ФГБУ «Институт стандартизации» , 117418 Москва, Нахимовский пр-т, д. 31, к. 2.