"ГОСТ Р 71704-2024. Национальный стандарт Российской Федерации. Информатизация здоровья. Связь с медицинскими приборами индивидуального контроля состояния здоровья. Часть 20701. Сервис-ориентированная архитектура медицинских приборов и привязка протокола"
(утв. и введен в действие Приказом Росстандарта от 17.10.2024 N 1465-ст)

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

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

3 Утвержден И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии России от 17 октября 2024 г. N 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 Федеральное агентство по техническому регулированию и метрологии не несет ответственности за патентную чистоту настоящего стандарта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 среда места оказания помощи; PoC (point-of-care environment, PoC): Среда, охватывающая определенную диагностическую зону, койко-место или лечебную зону, предназначенную для одного пациента.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

Примечание - Для упрощения реализации, не требующей синтаксического анализа pm:AbstractSetStateOperationDescriptor/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:SafetyReqAssertion вставлялся только в местах подключения политики WSDL, что налагает на потребителя сервисов SDC необходимость изучения WSDL. Встраивание mdpws:SafetyReq непосредственно в информационную базу медицинских данных (MDIB) упрощает реализацию, улучшает инкапсуляцию и позволяет потребителю сервисов SDC не заниматься анализом WSDL. Однако поставщик сервисов SDC может по-прежнему включать в WSDL вложения политики WSDL.

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:AbstractOperationDescriptor подразумевается классификация безопасности "Inf", что может не соответствовать безопасному состоянию для операции удаленного управления, и поэтому необходимо учитывать, соответствует ли это значению, установленному в рамках управления рисками.

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

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

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

Примечания

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

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

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

- msg:InvocationInfo/msg:InvocationState, в котором установлено значение "Fail";

- msg:InvocationInfo/msg:InvocationError, в котором установлено значение "Oth".

Примечания

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

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

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

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

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

- @Root="/template/go.php?url=https://standards.ieee.org/downloads/11073/11073-20701-2018";

- @Extension="AnonymousSdcParticipant".

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

- @Root="/template/go.php?url=https://standards.ieee.org/downloads/11073/11073-20701-2018/DistinguishedName";

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

Примечания

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

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

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

4 Например, для первичного UDI медицинского прибора PoC пространством имен для FDA UDI, pm:MdsDescriptor/pm:MetaData/pm:Udi/pm:HumanReadableForm которого равен "(01)00884838038752(21)DE35115712", является 845754B1-8934-51D7-9EA1-203FB7A8B1B9=uuidv5("6F8C705D-3A57-5736-A501-972E826947E8", "(01)00884838038752(21)DE35115712").

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

- pm:AbstractComplexDeviceComponentDescriptor;

- pm:ChannelDescriptor;

- pm:AbstractOperationDescriptor;

- pm:AlertConditionDescriptor;

- pm:AbstractMetricDescriptor.

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

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

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

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

Примечания

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

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

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

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

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:DescriptionModificationReport, поставщик сервисов SDC должен отправить сообщение msg:DescriptionModificationReport.

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

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

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

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

Примечания

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

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

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

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

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

Примечания

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

Полнофункциональный дескриптор наряду с классом pm:HandleRef подразумевает комбинацию атрибутов @SequenceId и @InstanceID в 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:FilteringRequestedUnavailable. Подписка не создается.

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

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

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

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

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

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

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

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

Примечания

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

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

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

Scheme ::= 'sdc.cdc.type'

CodingSystem ::= Segment

CodingSystemVersion ::= Segment

Code ::= SegmentNz

CdcType ::= '/' CodingSystem '/' CodingSystemVersion '/' Code

CdcTypeUri ::= Scheme ':' CdcType

где:

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

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

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

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

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

Примечания

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.

Для каждой основной роли участника 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).

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

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

NullFlavorRoot ::= 'biceps.uri.unk'

Root ::= NullFlavorRoot | SegmentNz

Extension ::= Segment

InstanceIdentifier ::= '/' Root '/' Extension

ContextUri ::= Scheme ':' InstanceIdentifier ('?' Query)?

где:

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

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

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

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

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

Примечания

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

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

Так как контексты местоположения наиболее значимы для формирования 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 ::= '/'

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, при его наличии;

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

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

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

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

- LocationDetail/@Facility;

- LocationDetail/@PoC;

- LocationDetail/@Bed.

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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:CalibrationInfo/@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.

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- C - условный;

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

Целевым пространством имен WSDL должно быть /template/go.php?url=https://standards.ieee.org/downloads/11073/11073-20701-2018, как определено в настоящем стандарте.

Примечание - Префиксом пространства имен для /template/go.php?url=https://standards.ieee.org/downloads/11073/11073-20701-2018 обычно является "sdc.".

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

PortType: sdc:GetService

PortType: sdc:SetService

PortType: sdc:DescriptionEventService

PortType: sdc:StateEventService

PortType: sdc:ContextService

PortType: sdc:WaveformService

PortType: sdc:ContainmentTreeService

PortType: sdc:ArchiveService

PortType: sdc:LocalizationService