A Joint HL7-IHE Gemini Device Interoperability Project

IHE Devices

Technical Framework Supplement

Service-oriented Device Point-of-care

Interoperability (SDPi)

Revision 1.4.1 — Standard for Trial Use / Implementation


Publication Date:

October 7, 2024

Build Date:

2024-10-07 15:27:04 UTC

Author:

HL7 Devices Working Group & IHE Devices Technical Committee

Email:

DEV@ihe.net


Please verify you have the most recent version of this document. See HERE for STU/Trial Implementation and Final Text versions and HERE for Public Comment versions.

A PDF version of the specification is available upon request.

Foreword

This Gemini standard is a joint development effort between Health Level Seven International (HL7) and Integrating the Healthcare Enterprise (IHE) devices working groups. Its development and publication adheres to the consensus standards processes of both HL7, an ANSI accredited standards development organization, and IHE. Publication as a Standard for Trial Use (HL7) or Trial Implementation (IHE) reflects the continuous cycle of development, balloting and publication of the specification, to address addition of new capabilities as well as identified safety, effectiveness and security issues and enhancements. Product developers are encouraged to use the standard, recognizing the potential impact of this continuous development cycle.

This is a supplement to the IHE Devices Technical Framework. Each supplement undergoes a process of public comment and trial implementation before being incorporated into the volumes of the Technical Frameworks.

This supplement is published on October 7, 2024 for Trial Implementation and may be available for testing at subsequent IHE Connectathons. The supplement may be amended based on the results of testing. Following successful testing it will be incorporated into the Devices Technical Framework. Comments are invited and can be submitted at Devices Public Comments or by submitting a GitHub Issue.

This supplement describes changes to the existing technical framework documents.

“Boxed” instructions like the sample below indicate to the Volume Editor how to integrate the relevant section(s) into the relevant Technical Framework volume.

Amend section W.X by the following:

Where the amendment adds text, make the added text bold underline. Where the amendment removes text, make the removed text bold strikethrough. When entire new sections are added, introduce with editor’s instructions to “add new text” or similar, which for readability are not bolded or underlined.

General information about IHE can be found at IHE.net.

Information about the IHE Devices domain can be found at IHE Domains.

Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at Profiles and IHE Processes.

The current version of the IHE Devices Technical Framework can be found at DEV Technical Framework.

Introduction to this Supplement

SDPi 1.4 Supplement — STU / TI Version — Note:

This version of the SDPi 1.4 Standard for Trial Use (HL7 STU) / Trial Implementation (IHE TI) supplement is the 3rd release in 2024, continuing the objective to provide three to four releases each year that include both incremental updates (e.g., editorial "fixes"), ballot comment resolutions (e.g., from HL7 ballot cycles), and additional capability enhancements. For this release, key additions include:

  1. SDPi-P Managed Discovery Option

  2. TF-1A enhanced description of requirements modeling and metadata

All changes incorporated in a release are managed through Github Issues and reviewed Pull Requests. For a list of those related to this release, see Section : below. For HL7 ballot comment resolution, links are made from HL7 ballot Jira tickets to IHE DEV.SDPi Github Issues that then enable tracking of the comment resolution implementation in a specific release.

This supplement also includes both normative and informative references to other specifications (see Appendix 1:B), some of which are finalized and published and others that are either being developed or in revision. For example, the IEEE 11073-10702 PKP standard is in development with balloting expected late 2024 and publication mid-2025; however, some requirements from that pre-standard may be included in this SDPi specification, providing a pathway to early experience and validation. When a referenced specification is used that is in development or revision, a note will be provided in the Appendix 1:B.1 clearly indicating its status.

It is recognized that this release is a work-in-progress that will continue to subsequent versions. These known limitations and forward-looking content include:

  1. Releases along with the planned capability additions are managed in the project’s DEV.SDPi "Gemini SDPi Releases" Github project

  2. This supplement includes (4) SDPi Profiles, though the typical IHE supplement is organized for a single profile; as a result, some adjustments have been made, especially in the supplement overview section where there is a general SDPi overview and then basic overviews for each of the Profiles; challenging areas include profile "options" where there are FOUR sections vs. one; it is a work in progress and feedback is appreciated, especially to enhance clarity

  3. Open / Closed Issues tables — starting with SDPi 1.1 and subsequent, the approach for the IHE open / closed issues section has been transitioned to utilize Github Issues that are related to this release; each release will update the changelog file, detailing what is Added, Changed or Removed

  4. Requirements boxes (e.g., "R1234") have been added especially in TF-2, with some also part of TF-1 and TF-3; this is an initial approach that will be significantly expanded in future versions of the supplement; documentation is provided in Appendix 1:A.4, including discussion related to how it will be expanded in future versions of the supplement;

  5. Safe Effective & Secure (SES) Sections (see Appendix 1:A.3) are included in the specification; however, their use and content will be significantly extended in future versions;

  6. This supplement is currently rendered as a "long form" document — one single HTML file; however, in subsequent versions the intent is to consider a multi-page / file HTML rendering + addition of a tabbed menu for navigating the sections of the supplement;

  7. SDPi 1.4 Supplement Note boxes are provided throughout the document to help guide reviewers and implementers.

Supplement Forward Declarations

SDPi 1.4 Supplement Note:

The following table is included in this version of the supplement to capture "forward" declarations of acronyms and labels that are used in the text but are not intended to be part of the General Introduction Appendix D Glossary. "Forward" means that they are used BEFORE the document section in which they are formally defined. Since AsciiDoc is a one-pass processor, forward declarations are required.

There was no clear way of defining these replacement definitions in a way that is "under the hood" and not visible to the reader. The following table was thus created but may be moved or otherwise implemented in subsequent supplement versions.

Suggestions appreciated!

Forward Declarations in the following table are being added "on demand" or when needed and not comprehensively for every acronym defined in the document that is not also included in the Glossary.
Acronym Label Section Defined In Type

AARS

Alerts to Alert Recording Systems

Appendix 1:C.7

Use Case

ACNS

Alerts to Clinician Notification Systems

Appendix 1:C.6

Use Case

AGW

Alert Gateway

Section 3:8.3.2.6

System Type

CS

Central Station

Section 3:8.3.2.6

System Type

DGW

Data Gateway

Section 3:8.3.2.6

System Type

DDES

Device Data to Enterprise Systems

Appendix 1:C.5

Use Case

MDPWS

Medical Devices Communication Profile for Web Services

[ISO/IEEE 11073-20702:2016]

Standard

SAS

Smart Alerting System

Section 3:8.3.2.6

System Type

SICDmp

Standalone ICU Dashboard Multiple Patient

Appendix 1:C.4

Use Case

SICDsp

Standalone ICU Dashboard Single Patient

Appendix 1:C.3

Use Case

STAD

Synchronized Time Across Devices

Appendix 1:C.2

Use Case

SDPi Supplement Overview

SDPi Supplement Organization

This IHE Devices Technical Framework supplement introduces a new family of interoperability profiles, Service-oriented Device Point-of-care Interoperability (SDPi), that comprise (4) separate profiles:

  • SDPi-Plug-and-trust (SDPi-P) Profile

  • SDPi-Reporting (SDPi-R) Profile

  • SDPi-Alerting (SDPi-A) Profile

  • SDPi-external Control (SDPi-xC) Profile

To that end, the supplement includes updates to all (3) IHE DEV TF volumes, including:

TF-1 Profiles

  • General overview of the SDPi architectural approach & integrated set of profiles

  • Profile-specific sections

  • Related appendices, for example the integration of this family of SDPi Profiles with other sources of requirements - use cases or reference standards

TF-2 Transactions

  • Extensive new set of transactions based on ISO/IEEE 11073 Service-oriented Device Connectivity (SDC) medical device interoperability standards.

  • Related appendices, for example the specialized use of web services messaging for device communication and gateways to other protocols or profiles

TF-3 Content Modules

  • New content covering the application of ISO/IEEE 11073 SDC semantic standards to device content modules, with a primary focus on specifications related to the ISO/IEEE 11073-10207 BICEPS standard.

Joint IHE-HL7 Gemini SES+MDI Project Development

This supplement is the result of a joint IHE-HL7 Gemini Device Interoperability program which began early 2020. Extensive notes and discussion materials are provided on the project’s HL7 Confluence site, including a Library with extensive presentations and other materials. This Library also includes briefings (slides and recordings) to provide background for those reviewing the specification.

The joint IHE-HL7 devices team leveraged tools from both organizations, as well as participated jointly throughout the project’s multi-year efforts.

The methods currently employed are provided in the wiki article: Program Coordination & Co-Working Spaces.

Supplement Support for RI+MC+RR using AsciiDoc

In addition to the supplement’s technical specification content, a development approach has been advanced that represents added value to adopters and implementers over the traditional document oriented approach. These are referred to as:

  1. Requirements Interoperability + Model Centric + Regulatory Ready

Or RI+MC+RR for short.

These three objectives may be summarized as follows:

  • Requirements Interoperability (RI)

    • Ability to integrate & automate requirements and capabilities from component specifications & standards to enable traceability & coverage at Conformity Assessment (CA) of the component product interface

  • Model Centric (MC)

    • Transition from a document-centric to a computable model-based "single source of truth" specification from which the Technical Framework becomes a view of the model

  • Regulatory Ready (RR)

    • Enable CA test reports that are genuinely "regulatory submission ready" (e.g., inclusion in a U.S. FDA 510(k) submission package)

The SDPi 1.4.1 version of the supplement continues to make small but significant steps toward support of these objectives, especially Requirements Interoperability, as well as the use of AsciiDoc metadata to annotate the document sources for post-processing. Clearly, moving toward Model-Centric (MC) specifications and full integration of Model-Based Systems Engineering (MBSE) (MBSE) will take considerable effort and time; however, this supplement represents a humble start in that direction. Subsequent supplement versions will build upon these objectives and support a new level of rigor for connectathon and product conformity assessment testing and ultimately test reports that directly impact the challenges around medical product regulatory submissions.

Additional discussion is provided in Appendix 1:A, and on the Gemini project’s confluence pages. See also related discussions on the Gemini Project’s Pathway to an Ecosystem of Plug-and-Trust Products.

Requirements Glossary

Editor’s Note:

This "glossary" provides a defined set of requirements terminology and meta data is required in order to ensure consistency and processing / automation of requirements throughout the specification.

It is differentiated from the IHE TF-0 Glossary in that it is specifically created to support the integration of formal requirements interoperability specification content; whereas, the IHE glossary provides general terminology more at the application level that is used throughout all IHE technical frameworks and profile specifications.

SDPi Issue Management

SDPi "Topic of Interest" Issue Management

All SDPi supplement issues are tracked in the IHE Github DEV.SDPi repository Issues section. Filter the issues on "Topic of Interest" to see a full list.

  • To see the full list of OPEN issues, filter on: is:issue is:open label:"Topic of Interest"

  • To see the full list of CLOSED issues, filter on: is:issue is:closed label:"Topic of Interest"

For more detailed information on how the Gemini SES+MDI program manages issues from identification to resolution to incorporation into this supplement, see the wiki article Overview: From Discussion to Planning to Development and the confluence article Topics of Interest — Topic Resolution Workflow.

IHE Technical Frameworks General Introduction

General

The IHE Technical Frameworks General Introduction is shared by all of the IHE domain technical frameworks. Each technical framework volume contains links to this document where appropriate.

IHE technical documents refer to, and make use of, a number of standards developed and published by several standards development organizations. Please refer to the IHE Technical Frameworks General Introduction, Section 9 - Copyright Licenses for copyright license information for frequently referenced base standards. Information pertaining to the use of IHE International copyrighted materials is also available there.

Amend Section 9.1 by adding the following new Section 9.1.5:

9.1.5 IEEE 11073 (Health Device Interoperability)

SDPi 1.4 Supplement Note: The content below is verbatim from the IEEE permission letter. An abbreviated version may be provided in subsequent supplement versions with a reference to the complete letter. The copyright language will need to be updated to support the PKP standards (e.g., [IEEE 11073-10700:2022]. It may also need to be updated for [IEEE 11073-10101:2020], which is needing to be renewed. Note that NIST and the RTTMS tools are a key factor in the nomenclature aspect of the licensing discussion.

IEEE® and IEEE 11073® are registered trademarks of the The Institute of Electrical and Electronics Engineers, Inc. IEEE has granted permission to IHE and HL7 to use portions of 11073-10207, 11073-20701, 11073-20702, 11073-10700, 11073-10701 (the “Material”), subject to the following conditions:

  1. IHE’s use of the Material shall be for the following purpose: (the “Purpose”):

    • IHE specification developers want to include the Implementation Conformance Specification (ICS) tables from each of these standards and add to the "Support" column the specifics of how and where the IHE specifications address the SDC capability.

    • Additionally, the IHE profile specifications may include summarization and references to specific content and in a few cases, inclusion of a graphic that would then point the reader back to standard for detailed review. For example, 11073-10207, Figure 2 "BICEPS component decomposition".

    • Finally, all three of these standards have integrated requirement designations. For example, 11073-20701, Section (10.1) "R0064: An SDC PARTICIPANT SHOULD utilize the highest TLS version." These requirements may also be referenced (at least by Rxxxx designator) to indicate when and how they are addressed in the IHE specification(s). IHE agrees to share with the 11073 working groups any iteration of its derivative work for the benefits of the 11073 community of users.

  2. IHE understands and agrees that the following shall appear in each section where the material is used:

    • Adapted and reprinted with permission from IEEE. Copyright IEEE Year. All rights reserved.* [1]

  3. IHE understands and agrees that the Material is the intellectual property of IEEE. Except as provided in this agreement no ownership rights to the Material shall be transferred to IHE.

  4. Except as necessary to give effect to the Purpose, no other use of the Material including, but not limited to, reproduction or distribution of the IEEE Standards in any format is prohibited without prior written consent of IEEE.

  5. The Material is provided “as is,” To the extent permitted by law, IEEE disclaims all representations and warranties to the Material.

  6. IHE shall note that any comments or interpretations of the Material are its own and do not represent the views of IEEE, its members or affiliates.

  7. IHE understands and agrees that this grant permission may not be transferred or assigned without the express written permission of IEEE.

10 Trademark

IHE® and the IHE logo are trademarks of the Healthcare Information Management Systems Society in the United States and trademarks of IHE Europe in the European Community. Please refer to the IHE Technical Frameworks General Introduction, Section 10 - Trademark for information on their use.

IHE Technical Frameworks General Introduction Appendices

The IHE Technical Framework General Introduction Appendices are components shared by all of the IHE domain technical frameworks. Each technical framework volume contains links to these documents where appropriate.

Appendix A Actors

Add the following new or modified actors to the IHE Technical Frameworks General Introduction Appendix A.

New (or modified) Actor Name Definition

BICEPS Content Consumer

Processes BICEPS-conformant content.

BICEPS Content Creator

Provides BICEPS-conformant content.

SOMDS ACM Gateway

Exchanges medical alert information with an IHE ACM-based environment

SOMDS Connector

Enables seamless interaction with systems and software applications that are outside the scope of a SOMDS network.

SOMDS Consumer

Discovers and utilizes service(s) exposed by a SOMDS Provider.

SOMDS DEC Gateway

Exchanges information between SOMDS and IHE DEC-based environments.

Discovery Proxy

Accepts and makes available SOMDS Provider endpoint metadata in a SOMDS.

SOMDS FHIR Gateway

Exchanges information between SOMDS and HL7 FHIR-based environments.

SOMDS FHIR Medical Data Gateway

Exchanges medical data between SOMDS and HL7 FHIR-based environments.

SOMDS Medical Alert Consumer

Receives medical alert information from a SOMDS Medical Alert Provider.

SOMDS Medical Alert Provider

Makes medical alert information and service(s) available to SOMDS Medical Alert Consumers.

SOMDS Medical Control Consumer

Discovers and invokes device-external control services supported by a SOMDS Medical Control Provider.

SOMDS Medical Control Provider

Supports a set of device-external control services that may be discovered and invoked by a SOMDS Medical Control Consumer.

SOMDS Medical Data Consumer

A SOMDS Consumer grouped actor that receives medical data from a SOMDS Provider.

SOMDS Medical Data Provider

Sends medical data to a SOMDS Medical Data Consumer.

SOMDS Participant

Provides basic, common connectivity capabilities that are shared by all actors that are part of a SOMDS network.

SOMDS Provider

Makes service(s) available to SOMDS Consumers.

SOMDS Sensor Gateway

Supports integration of sensors external to a SOMDS network.

SOMDS Smart App Platform

Supports connection of software applications to a SOMDS network, including Software as a Medical Device (SaMD).

SOMDS V2 Gateway

Exchanges information between SOMDS and HL7 Version 2 (V2) environments.

The table below lists existing actors that are utilized in this specification.

Table A-1. Complete List of Existing Actors Utilized in this specification
Existing Actor Name Definition

Alert Aggregator
(TBD) — If the ACM Gateway uses this

This actor receives alerts from the Alert Reporter and collects status events related to the dissemination of the alert.

Alert Consumer

The Alert Consumer (ACON) receives the alert from the Alert Reporter (AR) and uses the alert information strictly as a consumer of the alert being raised. There is no implementation requirement for how the ACON ultimately uses the alert information.

Alert Manager

The Alert Manager (AM) receives the alerts from the Alert Reporter (AR), potentially analyzes the alert, and dispatches the alert to the Alert Communicator (AC), and optionally, provides the alert to the Alert Archiver (AA) or Alert Consumer (ACON) upon subscription.

Alert Reporter

This actor originates the alert (an alarm, either physiological or technical, or an advisory). May also query the Alert Aggregator for the status of the alert.

Device Observation Consumer

The actor responsible for receiving PCD data from the Device Observation Reporter, the Device Observation Filter, or both.

Device Observation Reporter

The Device Observation Reporter (DOR) receives data from PCDs, including those based on proprietary formats, and maps the received data to transactions providing consistent syntax and semantics.

Time Client
(TBD — Do dependent profile actors like CT TC get included in this table?)

Establishes time synchronization with one or more Time Servers using the NTP protocol and either the NTP or SNTP algorithms. Maintains the local computer system clock synchronization with UTC based on synchronization with the Time Servers.

Appendix B Transactions

Add the following new or modified transactions to the IHE Technical Frameworks General Introduction Appendix B.

New Transaction Number New Transaction Name Definition

DEV-23

Announce Network Presence

Notify all SOMDS Consumers that a SOMDS Provider is connected to the network and ready to exchange messages with other SOMDS Participants.

DEV-24

Discover Network Topology

Discover and resolve all available SOMDS Providers that a SOMDS Consumer is potentially interested in.

DEV-25

Discover BICEPS Services

Exchange resources metadata between a SOMDS Provider and a SOMDS Consumer.

DEV-26

Discover System Context and Capabilities

Deferred to SDPi 1.x

DEV-27

Manage BICEPS Subscription

Establish a publish-subscribe session between a SOMDS Provider, acting as the event source, and a SOMDS Consumer, acting as the event sink.

DEV-28

Notify Change in System Context and Capabilities

Notify a SOMDS Consumer about changes in system context and capabilities of a SOMDS Provider.

DEV-29

Publish BICEPS Update Reports

Notify a SOMDS Consumer about changes in the alert, metric and component reports and in the waveform stream of a SOMDS Provider.

DEV-30

Retrieve BICEPS Content

Retrieve the MDIB of a SOMDS Provider a SOMDS Consumer is interested in.

DEV-31

Set Provider State

Deferred to SDPi-xC

DEV-32

Retrieve Archive Data

Deferred to SDPi 1.x

DEV-33

Retrieve Localization Information

Deferred to SDPi 1.x

DEV-34

Announce Network Departure

Notify all SOMDS Consumers that a SOMDS Provider is leaving the network.

DEV-35

Establish Medical Data Exchange

Establish the exchange of medical data between a SOMDS Provider and a SOMDS Consumer.

DEV-36

Publish Medical Data

Publish medical data from a SOMDS Provider to a SOMDS Consumer.

DEV-37

Retrieve Medical Data

Retrieve medical data from a SOMDS Provider.

DEV-38

Establish Medical Alert Exchange

Establish the exchange of medical alerts from a SOMDS Provider to a SOMDS Consumer.

DEV-39

Publish Medical Alert Update

Notify a SOMDS Consumer about changes in the medical alert status of a SOMDS Provider.

DEV-40

Retrieve Medical Alert Status

Retrieve the medical alert status of a SOMDS Provider.

DEV-41

Manage Medical Alert Delegation

Deferred to SDPi 2.0

DEV-42

Delegate Medical Alert

Deferred to SDPi 2.0

DEV-43

Update Alert Acknowledgement Status

Deferred to SDPi 2.0

DEV-44

Manage Medical External Control

Deferred to SDPi-xC

DEV-45

Invoke Medical Control Services

Deferred to SDPi-xC

DEV-46

Update Network Presence

Provide network presence and absence of SOMDS Provider Actors in a SOMDS network by updating the metadata in a Discovery Proxy Actor.

DEV-47

Retrieve Network Presence

Retrieve presence metadata from a Discovery Proxy Actor for a specified set of SOMDS Provider Actors that may be connected to a SOMDS network.

DEV-48

Reserved

DEV-49

Reserved

DEV-50

Reserved

Appendix D Glossary

SDPi 1.4 Supplement Note: The General Introduction Appendix D Glossary in this initial version of the supplement includes all terms and acronyms that are utilized throughout the other volumes. Subsequent versions of the supplement may re-locate items to other tables and sections within the technical framework. To help differentiate between various classes or categories of terms, a new "Type" column has been added. This could enable future dynamic resorting of the table by those users who are interested in, for example, only organizational definitions. Finally, a References column has been added to pull this information out of the Definition column.

Add the following new or updated glossary terms to the IHE Technical Frameworks General Introduction Appendix D.

New Glossary Term Definition Synonyms Acronyms / Abbreviation References Type

American National Standards Institute

The primary United States SDO recognition and facilitation organization.

ANSI

ANSI.org

Organization

Basic ICE Protocol Specification

General reference to the abstract, implementation technology independent SDC components defined in the ISO/IEEE 11073-10207 standard.

BICEPS

[ISO/IEEE 11073-10207:2017]

SDC

Central Station

A system that supports a multi-patient workplace with capabilities similar to a Cockpit.

See extended description and discussion in Section 3:8.3.2.6

Classic Domain Information Model (DIM)

The foundational domain information model (DIM) that is recognized and implemented in all IEEE 11073 standards and profiles, for both PoCD and PHD devices.

DIM

[IEEE 11073-10201:2004]

SDC

Clinical Function

Function or feature intended to be used for one or more specific medical purposes including but not limited to examination, monitoring, or modification of the structure or function of an individual’s body; prediction, prevention, diagnosis, prognosis, treatment, or alleviation of a medical condition.

CF

[IEEE 11073-10700:2022]

SDC

Coded Attribute

A BICEPS Participant Model extension that allows for a SOMDS Provider to provide attributes from the first partition of the IEEE 11073-10101 nomenclature. Specified in Section 3:8.3.2.10.4.

See NIST CA resources page

SDC

Conformity Assessment

The activity of verifying that a standard or technical specification was applied in the design, manufacturing, installation, maintenance or repair of a device or system. "Product CA" is often mentioned to clarify its use in the context of this document.

CA

SES

Device-to-Device

Direct communication between two devices across a communications infrastructure. It is used here to differentiate between "device gateway-to-gateway" or intermediary-based communication.

peer-to-peer, machine to machine

D2D

Device-to-device wikipedia article with references

SDC

Discovery Scope

A set of zero to many identifiers that allows for organizing SOMDS Providers into logical groups.

SDC

Electronic Health Record

An electronic record derived from a computer system that maintains a longitudinal view of a patient’s history. It contains comprehensive information on a patient’s health used primarily for delivering patient care in a clinical setting.

EHR

IHE General Introduction Appendix D Glossary

IHE

Fast Healthcare Interoperability Resources

An HL7 standard for health care data exchange, built on RESTful technology that utilizes resources to enable rapid creation of interoperable healthcare applications.

FHIR

HL7 FHIR home

Standard

Health Level Seven International

Organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services.

HL7

About — HL7

Organization

Implementation Conformance Statement

A clause in many standards that specifies how conformance claims to that standard should be formalized, including identification of any deviations, extensions and option selection.

ICS

Institute of Electrical and Electronic Engineers

Organization dedicated to advancing innovation and technological excellence for the benefit of humanity, and is the world’s largest technical professional society

IEEE

About — History of IEEE

Organization

Integrated Clinical Environment

Environment that combines interoperable heterogeneous POINT-OF-CARE (PoC) MEDICAL DEVICEs and other equipment integrated to create a medical device system for the care of a single high acuity patient.

ICE

[ISO/IEEE 11073-20701:2018]; [AAMI 2700-1:2019]

SDC

International Medical Device Regulators Forum

A voluntary group of medical device regulators from around the world who have come together to build on the strong foundational work of the Global Harmonization Task Force on Medical Devices (GHTF) and aim to accelerate international medical device regulatory harmonization and convergence.

IMDRF

IMDRF.org

Organization

International Standards Organization

A globally recognized one-country-one-vote SDO that is composed of 100’s of technical committees and other groups.

ISO

www.ISO.org

Organization

ISO/IEC Joint Working Group 7

A joint standardization group between ISO/TC 215 and IEC/SC 62A focused on the Safe Effective & Secure (SES) health software and health IT systems, including those incorporating medical devices.

JWG7

ISO/TC 215 Health Informatics, IEC SC/62A

Organization

Local Area Network

A computer network that interconnects computers within a limited area such as a hospital, ICU bed, laboratory, or office building. By contrast, a wide area network (WAN) not only covers a larger geographic distance, but also generally involves leased telecommunication circuits.

LAN

See "Local area network" article for more information and references.

Manufacturer

Natural or legal person with responsibility for the design, manufacture, packaging, or labeling of medical electrical equipment, assembling a medical electrical system, or adapting medical electrical equipment or a medical electrical system, regardless of whether these operations are performed by that person or on that person’s behalf.

Organization

Medical Data Information Base

Structured collection of any data objects that are provided by a SOMDS Provider or BICEPS Content Creator, including both descriptive and state information.

MDIB

[ISO/IEEE 11073-10207:2017]

SDC

Medical Device

A device that is used to diagnose, monitor and treat disease. Formal definitions may vary per legal jurisdictions; however, the international, harmonized (and very lengthy) definition is available from the International Medical Device Regulators Forum (IMDRF) web site.

MD

International Medical Device Regulators Forum (IMDRF)

Medical Device Communication

A general term that refers to all aspects of standards-based exchanges between medical (and health) devices, including PoCD and PHD; in some contexts, for example HL7, it refers to the ISO/IEEE 11073-10101 Nomenclature or "coding system".

MDC

[IEEE 11073-10101:2020]

Medical Device Interoperability

The application of informatics technology standards to achieve seamless and dynamic connection of Point of Care Device (PoCD)'s.

MDI

See also U.S. FDA MDI Definition

Medical Device LAN

A local area network that integrates Medical Device (MD)s often around a single bedside Point of Care (PoC) or care area (e.g., operating room, ICU or Emergency Department).

SDC LAN

MD LAN

Medical Device System

A core object type in the ISO/IEEE 11073 device communication standards. It represents the top-level containment of the hierarchy of information objects contained in a device.

MDS

[ISO/IEEE 11073-10207:2017], [IEEE 11073-10201:2004]

Model-Based Systems Engineering

An approach to systems engineering where a single, highly integrated, executable model is created (often using OMG System’s Modeling Language (e.g., [OMG SysML ® 2.0]), to capture all elements, from requirements to system components to Verification & Validation test cases.

MBSE

See also RI, MC and RR

SES

Model-Centric

An approach to systems specification that captures all information in a single model (e.g., using MBSE), and from which "views" are generated to support all specification stakeholders and usages. elements, from requirements to system components to Verification & Validation test cases. Note: The model-centric approach replaces the traditional document-centric approach.

RI+MC+RR

MC

See also RI and RR

SES

Network Time Protocol

A networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks.

NTP

NTP wikipedia article

Object Management Group

An international, membership-driven, not-for-profit consortium SDO.

OMG

OMG.org

Organization

Participant Key Purposes

These generally refer to the ISO/IEEE 11073-1070x standards that provide a consensus set of risk control measures aligned with the four core MDI functions: Plug-and-Trust (PnT), reporting, alerting and external control.

PKP

[IEEE 11073-10700:2022]

SDC

Personal Health Device

A healthcare device that is used by individuals for their own personal health purposes.

PHD

Plug-and-Trust

The integration of an SES framework and MDI plug-and-play technology to enable the dynamic establishment of trust between participant systems at the point of connection to a SOMDS network.

SES+MDI

PnT

Point of Care

Typically where the patient is, such as their clinical bedside; although, it may also be used to include mobile patients (e.g., that are connected to telemetry monitoring).

PoC

Point of Care Cockpit

A system that supports information viewing and control of multiple devices and systems associated with a single patient Point of Care (PoC).

Cockpit

Point of Care Dashboard

A system that displays information from one or more SOMDS Participant systems associated with a single patient. Similar to a Cockpit but without device-external control capabilities. May include both metric and alert information.

Dashboard

Point of Care Device

A healthcare device that is used at a Point of Care (PoC), typically at a patient’s clinical bedside. May include patient-connected mobile devices, such as telemetry monitors.

PoCD

QName

XML Schema QName. In this specification, QNames are encoded as {<namespace>}<local-name>.

Regulatory Ready

For regulated medical device technology, integrating SES and RI content such that conformity assessment test reports may be directly included as supporting evidence in pre-market submissions to regulatory agencies. It is part of the Requirements Interoperability + Model Centric + Regulatory Ready (RI+MC+RR) focus of the IHE Devices Technical Framework.

RI+MC+RR

RR

See also RI and MC

Removable Subsystem

A subsystem of a SOMDS Provider that can be attached to or removed from the SOMDS Provider and that is represented in the MDIB.

See also [IEEE 11073-10700:2022]

Requirements Interoperability

The ability to specify the requirements of one specification in such a way that they can be connected with capabilities of other specifications. It is part of the Requirements Interoperability + Model Centric + Regulatory Ready (RI+MC+RR) focus of the IHE Devices Technical Framework.

RI+MC+RR

RI

See also MC and RR

Safe, Effective & Secure

General name given to the requirements, general and specific, derived by the application of medical device and health software quality standards.

SES

[ISO/IEC 81001-1:2021]; [ISO/IEC 80001-1:2021]

Service-oriented Device Connectivity

Application of service-oriented architecture to support healthcare device interoperability.

SDC

[ISO/IEEE 11073-20701:2018]

SDC

Service-oriented Device Point of Care Interoperability

A set of (4) IHE specifications that profile the SDC standards for device-to-device plug-and-play interoperability.

SDPi

Profile

Service-oriented Architecture

An architectural style that focuses on discrete services, where provider components supply services (discrete units of functionality) to consumer components across a communications network infrastructure.

SOA

SDC

Service-oriented Medical Device System

A point-of-care system of products that implements a service-oriented SDC architecture composed of service providers and service consumers.

SOMDS

[ISO/IEEE 11073-10207:2017]

SDC

Smart Alarm System

A system that provides consolidated alarm and alert events (actionable alerts), and advisories (e.g., patient deterioration alerts).

SAS

Note: This is based on the initial description in Table 3:8.3.2.6-1. SDPi 2.0 will more fully define the term.

Software as a Medical Device

Software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.

SaMD

Source: IMDRF

SOMDS Provider UID

A globally unique identifier UID for a SOMDS Provider that is stable across re-initializations.

UID

SDC

Standards Development Organization

An organization that has a core objective of developing consensus-based standards, typically recognized or accredited by national and international organizations (e.g., ANSI or ISO)

SDO

"Standards organization" wikipedia article

Organization

System Function Contribution

Function of a SOMDS Participant that contributes to a Clinical Function provided by a Service-oriented Medical Device System (SOMDS).

SFC

Adapted from [IEEE 11073-10700:2022].

SDC

Time Synchronization Service

A general network service capability that enables systems to obtain and synchronize to a common and accurate time source. For example, Network Time Protocol (NTP).

TS Service

Transport Address

A physical endpoint address that can be used to communicate with a SOMDS Provider.

XAddr

Virtual Medical Device

A core object type in the ISO/IEEE 11073 device communication standards. It represents the second-level containment of the hierarchy of information objects contained in a device.

VMD

[ISO/IEEE 11073-10207:2017], [IEEE 11073-10201:2004]

XML Namespaces

The XML namespace URI that is used by this specification is: urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1.

Table 1 lists XML namespaces and prefixes that are used in this specification. The choice of any namespace prefix is arbitrary and not semantically significant.

Table 1. Prefixes and XML namespaces used in this specification.
Prefix XML Namespace Specification

dpws

http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01

[OASIS DPWS:2009]

sdpi

urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1

This specification, used by BICEPS extensions.

dp

urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.2.2

This specification, used by the Discovery Proxy actor.

wsa

http://www.w3.org/2005/08/addressing

[W3C Recommendation, WS-Addressing:2006]

wsd

http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01

[OASIS WS-Discovery:2009]

wse

http://schemas.xmlsoap.org/ws/2004/08/eventing

[W3C Submission, WS-Eventing:2006]

wsm

http://schemas.xmlsoap.org/ws/2004/09/mex

[W3C Submission, WS-MetadataExchange:2008]

Volume 1 — Profiles

1:2 Devices Integration Profiles

SDPi 1.4 Supplement Note: This supplement is being written after the 2019 reorganization of the IHE Patient Care Devices (PCD) domain to the IHE Devices (DEV) domain. It is intended to amend a new IHE DEV Technical Framework (TF), that covers the expanded areas not only of PCD devices (enterprise integration focused), but also Personal Connected Health (PCH) devices and Device Point-of-care Interoperability (DPI) for device-to-device integration around an acute point-of-care (e.g., operating room table, ICU bed, emergency department bed, etc.). As a result of these basic changes in the scope and organization of the IHE DEV domain, some additional TF sections have been proposed to help the community understand how these technical specifications are integrated. For example,

  1. Section(s) for General IHE Devices architecture, use contexts, and (4) Participant Key Purposes (PKP) functions — Connecting, Reporting, Alerting, and Controlling (external)

  2. Section addressing "What is a device?" (aligned with a similar topic within the joint IHE-HL7 Gemini project); especially relevant given the differences between Personal Health Device (PHD) and Point of Care Device (PoCD) as well as the increasing prevalence of Software as a Medical Device (SaMD) applications. (See "Paper: What is a device?" for additional background.)

These general concepts will help the technical framework reader understand the broader context into which the profile specifications are intended to be implemented.

1:2.2 Safety, Effectiveness and Security - Requirements and Considerations

IHE specifications often include sections for "Security Considerations" and "Safety Considerations", capturing both general and specific guidance and requirements for system implementers. This supplement extends these two concepts to include a third: Effectiveness. The sections are titled "Safety, Effectiveness and Security - Requirements and Considerations" and make use of the underlying term Safe Effective & Secure (SES).

The background for SES is discussed in detail in Appendix 1:A.2; however, in general "SES" is used as a reference to the standards encompassed (directly and indirectly by reference) in ISO/IEC Joint Working Group 7 (JWG7), including [ISO/IEC 81001-1:2021] and [ISO/IEC 80001-1:2021]. These standards are primarily, though not exclusively, focused on risk management of health software (including SaMD) and medical devices that are deployed on various kinds of infrastructure, with a focus to managing three key properties: Safety, Effectiveness and Security. Thus the "Safety, Effectiveness and Security - Requirements and Considerations" sections in this supplement are intended to reflect the results of that risk management and to guide those who are tasked with deploying and managing these interoperable solutions during use.

Note that specific requirements from the above mentioned standards, may also be captured in Appendix 1:B.2. Generally, requirements from these standards would be mapped to the appropriate "Safety, Effectiveness and Security - Requirements and Considerations" sections throughout the specification.

1:2.3 Integration Profiles Overview

SDPi 1.4 Supplement Note: The template for this section assumes that it will be integrated with the technical framework section that is organized based on TF-1 section headings (e.g., chapter 10 for SDPi- would have a summary here as 2.10. No provision is made, though, for general introductory sections such as the SDPi Overview & Framework discussion below.

In this version, the content is added as 2.3.1, and then the profiles as 2.3.10 to 2.3.13. Though the content is valid, it may be repositioned in subsequent versions to better integrate with the IHE DEV TF at a future date.

Omitted from this version are profile-specific option summaries (e.g., 3.10.1?). It is unclear where to best place this content, and they are listed explicitly in each profile’s detailed specification.

1:2.3.1 Service-oriented Device Point-of-care Interoperability (SDPi)

1:2.3.1.1 SDPi Profiles – Scope of Application

The Service-oriented Device Point-of-care Interoperability (SDPi) Profile specifications provide detailed instructions for seamless plug-and-play interoperability between ISO/IEEE 11073 SDC-based medical devices (including SaMD), as well as between medical devices and health IT systems based on HL7 FHIR and HL7 Version 2. Key considerations include enabling safe, secure and effective interoperability for data reporting, alert notification, device-external control and other high-acuity point-of-care use cases. Provision is made for coordination of individual device functional contributions to support clinical system functions that are provided by two or more participants.

Notes:

  1. High-acuity points of care include operating rooms (OR), intensive care units (ICU), step-down units, and emergency care.

  2. Clinical system function example: Physiological monitoring of a patient’s condition as they are being weaned off of a ventilator.

  3. "SaMD" is Software as a Medical Device, including "clinical apps"; they are a class of Health Software.

  4. ISO/IEEE 11073 Service-oriented Device Connectivity (SDC) standards provide a Services Oriented Architecture (SOA) specification for safe, effective and secure medical device interoperability (SES MDI).

1:2.3.1.2 SDPi Profiles – Overview & Framework

The SDPi Profiles are built upon a foundation of standards and profiles from HL7, IEEE, IHE and other organizations. An overview of the profiles and their relationships is provided in Figure 1:2.3.1.2-1.

vol1 diagram sdpi profiles
Figure 1:2.3.1.2-1. IHE SDPi Profiles & Foundational Standards

There is a particular challenge with SDPi profiling of SDC that resulted in the definition of (4) profiles and not one:

  1. How to represent a SOA-based architecture supporting an interactive Plug-and-Trust (PnT) device-to-device (multi-way, M:N) interoperability specification using established IHE technical framework constructs?

The arrows indicate reference relationships and not specializations. For example, The three SDPi-R, -A and -xC Profiles refer to the foundational SDPi-P profile. This is achieved by the use of IHE "grouped actors". Or IHE "gateway" actors include mappings to the foundational, non-SDC standards.

The above figure illustrates how this balance was achieved, including:

  1. 4 Profiles — 

    1. By separating SDPi into four separate but integrated profiles, the complexity of the Plug-and-Trust (PnT) system-to-system interactions + the optionality of real-world systems is better managed.

  2. Gateway Actors

    1. The Profiles are built upon a solid foundation of existing standards from various SDOs and that are currently implemented for device information exchange, albeit in different use contexts such as healthcare enterprise / EHR integration.

    2. The actors provide defined mappings from SDPi transactions and semantics to those of other standards and standards profiles (e.g., IHE DEC or ACM).

    3. Gateways can be bi-directional, receiving information from non-SDPi enabled systems, such as patient demographics information from an EHR.

    4. For a more complete "Big Picture" perspective, see the discussion in Appendix 1:A.1.

  3. PKPs for Medical Purposes

    1. A unique aspect of the IEEE 11073 SDC family of standards are the inclusion of the Participant Key Purposes (PKP) standards that advance Safe Effective & Secure (SES) "medical" interoperability.

    2. The separation of interoperability purposes across four aspects both simplifies the complexity of each functional area, as well as implementation optionality, where some systems may only need to support connectivity and reporting but not alerting nor external control.

    3. These standards represent shared or consensus risk management requirements (e.g., risk mitigations) that together address how to implement SES interoperable medical device technologies.

    4. The diagram illustrates how the SDC Core Standards provide for basic healthcare connectivity; whereas the PKP standards add a requirements layer for devices that have a medical interoperability purpose.

"PRACtical" Device Interoperability may be a bit "cute"; however, it does map to the (4) Profiles, which together provide a practical, pragmatic way toward genuine PnT interoperability:

  1. P → SDPi-Plug-and-trust

  2. R → SDPi-Reporting

  3. A → SDPi-Alerting

  4. C → SDPi-xControl

It should be noted that the primary use context for SDPi-enabled technologies is high acuity points of care, namely Operating Rooms, ICU beds, emergency beds, etc. Within this context, the core focus of these Profiles is direct D2D interactions at the point of care. Gateway actors provide integration with systems beyond the scope of the acute bedside context, typically though not necessarily using other protocols. This D2D is differentiated with the current implementation reality where devices use proprietary protocols to talk with their manufacturer’s gateway server, requiring a level of indirection (server-to-server integration), and the attendant performance, quality and capability limitations.

See Section 1:10.4.1.1 below for additional conceptual overview information on the conceptual foundations of the SDC standards.

1:2.3.10 Service-oriented Device Point-of-care Interoperability - Plug-and-trust (SDPi-P) Profile

Within the framework of the SDPi architecture, the Plug-and-Trust ( SDPi-P) Profile provides for secure plug-and-play connectivity between all actors. The primary use context is acute care beds (e.g., ICU, operating room, emergency department), though it may be used in other healthcare contexts. This specification provides for plug-and-trust (secured) communication for healthcare devices, systems and applications, regardless of whether they are "regulated" medical devices. That said, the SDPi-P Profile fully supports the safety and security requirements specified in the [IEEE 11073-10700:2022] Base PKP standard. Other SDPi Profiles provide direct support for interoperable medical systems. Taking this approach allows non-medical technology to interact with other SDPi-enabled systems but without the added burden of having to support the more rigorous requirements associated with technology intended for a medical purpose (e.g., additional risk control mitigation measures).

This baseline profile supports the core functionality needed by all participating systems. Profile options are provided for additional capabilities that may be required to support extended scenarios (e.g., "ensemble context" management).

1:2.3.11 Service-oriented Device Point-of-care Interoperability - Reporting (SDPi-R) Profile

The SDPi Reporting Profile builds on the basic PnT capabilities of the SDPi-P profile, but adds the requirements to fully support medical data reporting. To that end, this specification fully supports the safety and security requirements in the [IEEE 11073-10701:2022] metric reporting PKP standard.

The profile supports core medical data reporting functionality needed by all participating systems. Profile options are provided for additional capabilities that may be required to support extended scenarios.

1:2.3.12 Service-oriented Device Point-of-care Interoperability - Alerting (SDPi-A) Profile

The SDPi Alerting Profile builds on the basic PnT capabilities of the SDPi-P profile, but adds the requirements to fully support medical alerting. To that end, this specification implements the safety and security requirements of the [IEEE 11073-10702:202x] alert PKP standard (expected to be completed in 2024).

The profile supports core medical alerting functionality needed by all participating systems. Profile options are provided for additional capabilities that may be required to support extended scenarios (e.g., alert delegation).

1:2.3.13 Service-oriented Device Point-of-care Interoperability - External Control (SDPi-xC) Profile

SDPi 1.4 Supplement Note: The SDPi-xC Profile is provided for completeness and to show the general direction of the family of SDPi Profiles. It is not part of the capabilities specified for 1.4 and even basic controls will not be added until SDPi 2.0 or later.

The SDPi External Control Profile builds on the basic PnT capabilities of the SDPi-P Profile, but adds support for medical device external control capabilities. For example, the ability to have a system initiate a blood pressure reading, or set a breath rate, or titrate an infusion pump’s delivery rate. Given the significant risks associated with allowing device-external control functions in a network of PnT systems, this specification implements the safety and security requirements of the [IEEE 11073-10703:202x] external control PKP standard (in development, anticipated in 2025 or later).

1:2.5 Dependencies between Integration Profiles

Add the following dependencies below to the IHE DEV TF Profile Dependencies table.

Table 1:2.5-1. Devices Integration Profile Dependencies

Integration Profile

Depends on

Dependency Type

Purpose

SDPi-P

Consistent Time (CT)

Each SDPi-P actor implementation (i.e., SOMDS Participant) shall be grouped with the CT Time Client Actor. Note: All SDPi actors are also grouped with the SOMDS Participant Actor.

Required for consistent time-stamping of transactions and data.

SDPi-R

Device Enterprise Communication (DEC))

The SOMDS DEC Gateway integrates DEC Device Observation Reporter (DOR) Actor specifications.

Required for mapping from SDC & BICEPS to HL7 V2 and DEC transactions.

SDPi-A

Alert Communication Management (ACM)

The SOMDS ACM Gateway integrates ACM Alert Reporter (AR) Actor specifications.

Required for mapping from SDC & BICEPS to HL7 V2 and ACM transactions.

1:10 Service-oriented Device Point-of-care Interoperability – Plug-and-trust (SDPi-P) Profile

The SDPi-Plug-and-trust ( SDPi-P) Profile supports foundational seamless connectivity, information exchange and service invocation as defined in the SDPi architecture detailed in Section 1:2.3.1.2. Whereas the related SDPi Profiles for reporting, alerting and external control are explicitly intended to support medical care capabilities, the SDPi-P Profile focuses on basic healthcare device interoperability. All the capabilities defined in SDPi-P are leveraged by and extended in the medically focused profiles. This foundational profile not only supports medical device interoperability ("MDI"), providing for “plug-and-play” capabilities, but also with a tightly integrated “trust” framework (see Appendix 1:A). The establishment of a trusted ecosystem of medical and non-medical devices and applications [2] begins at the start of discovery and a secure connection. Therefore, the profile’s name: Plug-and-Trust (PnT).

This is primarily an IHE transport profile [3], although it does define several content modules detailed in IHE Devices TF-3. It supports the transactions and information exchanged in accordance to a Service-Oriented Architecture (SOA) specialized for high-acuity points of care (e.g., operating table or ICU bed), defined as a Service-oriented Medical Device System (SOMDS). All the SDPi-P actors are therefore scoped with “SOMDS” to clearly identify their application context and scope.

Although all information exchanged between SDPi-P SOMDS participating systems and applications must conform to the basic SDC/BICEPS content module requirements [4], content modules have been defined for common high-acuity medical devices such as infusion pumps, ventilators and physiologic monitors.

Note that future IHE workflow profiles may be defined that build upon the transport & content module foundation established by the SDPi-P profile. For example, Operating Room / Surgery Point-of-Care Integration, ICU Point-of-Care Integration, or more service-focused profiles such as Point-of-Care Identity Management (PCIM) for device-patient association management, or Silent ICU & Quiet Hospital, where the acute point-of-care is integrated with enterprise systems around device alerting and alert distribution to provide an improved environment of care (reduced noise level and improved safety) and clinician interaction.

1:10.1 SDPi-P Actors, Transactions, and Content Modules

SDPi 1.4 Supplement Note: Some actors and transactions have been deferred to a subsequent version, but are included here for completeness. Specifically: SOMDS FHIR Gateway, SOMDS Sensor Gateway & SOMDS Smart App Platform, have been deferred.

Deferred transactions have been so indicated in the transactions table.

This section defines the actors, transactions, and/or content modules in this specification. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A. IHE Transactions can be found in the Technical Frameworks General Introduction Appendix B. Both appendices are located at profiles.ihe.net/GeneralIntro.

Figure 1:10.1-1 shows the actors directly involved in the SDPi-P Profile. The relevant transactions between them are detailed in the subsequent Table 1:10.2-1. Abstract actors (i.e., those that provide common specifications that are utilized in other “concrete” or implementation actors) are indicated by stereotype names in italics (e.g., "<< SOMDS_Participant >>". The actors that inherit their capabilities include the stereotype at the top of their actor box. Alternatively, in accordance with traditional IHE style, the Abstract actor’s name can be in italics with "{abstract}" (e.g., see SOMDS Connector in Figure 1:10.1-1). Actor groupings, including abstract with concrete, are detailed in Section 1:10.3.

vol1 diagram sdpi p actor
Figure 1:10.1-1. SDPi-P Actor Diagram

Table 1:10.2-1 lists the transactions for each actor directly involved in the SDPi-P Profile. To claim conformity with this specification, an actor shall support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”). Note that “Consumer” is indicated for actors that receive but do not directly respond to a specific transaction.

Table 1:10.1-1. SDPi-P Profile - Actors and Transactions

Actors

Transactions

Initiator or Responder

Optionality

Reference

SOMDS Participant

NOTE: This abstract actor does not define any specific transactions.

…​

…​

…​

SOMDS Provider

Announce Network Presence

Initiator

R

Section 2:3.23

Discover Network Topology

Responder

R

Section 2:3.24

Discover BICEPS Services

Responder

R

Section 2:3.25

Discover System Context and Capabilities (deferred)

Responder

R

Deferred to SDPi 1.x

Manage BICEPS Subscription

Responder

R

Section 2:3.27

Notify Change in System Context and Capabilities

Initiator

O (See Note 1)

Section 2:3.28

Publish BICEPS Update Reports

Initiator

R

Section 2:3.29

Retrieve BICEPS Content

Responder

O

Section 2:3.30

Set Provider State (deferred)

Responder

O

Deferred to SDPi-xC

Retrieve Archive Data (deferred)

Responder

O

Deferred to SDPi 1.x

Retrieve Localization Information

Responder

O

Deferred to SDPi 1.x

Announce Network Departure

Initiator

R

Section 2:3.34

Update Network Presence

Initiator

O (See Note 2)

Section 2:3.46

SOMDS Consumer

Announce Network Presence

Receiver (See Note 3)

O

Section 2:3.23

Discover Network Topology

Initiator

R

Section 2:3.24

Discover BICEPS Services

Initiator

R

Section 2:3.25

Discover System Context and Capabilities (deferred)

Initiator

R

Deferred to SDPi 1.x

Manage BICEPS Subscription

Initiator

R

Section 2:3.27

Notify Change in System Context and Capabilities

Receiver (See Note 3)

O

Section 2:3.28

Publish BICEPS Update Reports

Receiver (See Note 3)

R

Section 2:3.29

Retrieve BICEPS Content

Initiator

O

Section 2:3.30

Set Provider State (deferred)

Initiator

O

Deferred to SDPi-xC

Retrieve Archive Data (deferred)

Initiator

O

Deferred to SDPi 1.x

Retrieve Localization Information

Initiator

O

Deferred to SDPi 1.x

Announce Network Departure

Receiver (See Note 3)

O

Section 2:3.34

Retrieve Network Presence

Initiator

O (See Note 2)

Section 2:3.47

Discovery Proxy

Update Network Presence

Receiver (See Note 2)

R

Section 2:3.46

Retrieve Network Presence

Responder

R

Section 2:3.47

SOMDS Connector

See Note 4

…​

…​

…​

SOMDS FHIR Gateway (deferred)

…​

…​

…​

…​

SOMDS V2 Gateway

See Note 4

…​

…​

…​

SOMDS Sensor Gateway (deferred)

…​

…​

…​

…​

SOMDS Smart App Platform (deferred)

…​

…​

…​

…​

Note 1: “Notify Change in System Context and Capabilities” is required if there are dynamic changes that may need to be sent to subscribing systems

Note 2: Optional transaction is required if the SDPi-P Managed Discovery Option is enabled. Some deployments may support a mix of systems that use the Discovery Proxy Actor as well as the default "ad hoc" discovery mode. Additional details and requirements are provided in the Section 1:10.2.1 discussion.

Note 3: “Receiver” is included in this column, in italics, to indicate that though a SOMDS Consumer may "receive" the transaction, there is no response communicated to the message initiator.

Note 4: SDPi Version Note:  — Full detailing of the transactions related to this actor will be addressed in a subsequent version of this specification.

Figure 1:10.1-2 shows the content-related actors defined in the SDPi-P Profile and the direction that the content is exchanged.

In general, the SOMDS Provider will create content for consumption by a SOMDS Consumer , but the communication cloud between the two actors indicates that the technical method of exchange is a separate concern for the semantic content. Within the SDPi-P Profile, the general "default" communication methods would be using the SOMDS capabilities illustrated above in Figure 1:10.1-1 with the BICEPS Content Creator communicating content via the SOMDS Provider , and the BICEPS Content Consumer receiving it via the SOMDS Consumer. However, the content might also be formalized in a document as opposed to a message, and a different method of exchange and persistence utilized.

Note that in the case of external control, where a SOMDS Consumer is creating and sending content (e.g., patient demographics information) to a SOMDS Provider , the content module creator / consumer roles will be reversed.

A product implementation using this specification may group from this profile with actors from a workflow or transport profile to be functional. The grouping of the content module described in this profile to specific actors is described in more detail in Section 1:10.3 or in Section 1:10.6.

vol1 diagram sdpi p content actor
Figure 1:10.1-2. SDPi-P BICEPS Content Actor Diagram

Table 1:10.1-2 lists the content module(s) defined in the SDPi-P Profile. To claim support with this specification, an actor shall support all required content modules (labeled “R”) and may support optional content modules (labeled “O”).

Table 1:10.1-2. SDPi-P — Actors and Content Modules

Actors

Content Modules

Optionality

Reference

BICEPS Content Creator

SDC/BICEPS Content Module

R (See Note 1)

Section 3:8.3.2.1

Infusion Pump SDC/BICEPS Content Module

O

Section 3:8.7.1

Ventilator SDC/BICEPS Content Module

O

Section 3:8.7.2.6

Physiologic Monitor SDC/BICEPS Content Module

O

Section 3:8.7.3.17

Surgery Devices SDC/BICEPS Content Module

O

Section 3:8.7.4.1

Anesthesia Devices SDC/BICEPS Content Module (deferred)

O

Dialysis Devices SDC/BICEPS Content Module (deferred)

O

BICEPS Content Consumer

SDC/BICEPS Content Module

R (See Note 1)

Section 3:8.3.2.1

Infusion Pump SDC/BICEPS Content Module

O

Section 3:8.7.1

Ventilator SDC/BICEPS Content Module

O

Section 3:8.7.2.6

Physiologic Monitor SDC/BICEPS Content Module

O

Section 3:8.7.3.17

Surgery Devices SDC/BICEPS Content Module

O

Section 3:8.7.4.1

Anesthesia Devices SDC/BICEPS Content Module (deferred)

O

Dialysis Devices SDC/BICEPS Content Module (deferred)

O

Note 1: All content exchanged on a SOMDS shall conform to the general SDPi “BICEPS Content Module” requirements (see Section 3:8.3.2). SOMDS Provider-specific content modules (e.g., infusion pumps) may be optionally supported as indicated.

1:10.1.1 Actor Descriptions and Actor Profile Requirements

SDPi-P actor roles and responsibilities are described in the subsections below.

Unless otherwise specified below, individual transaction requirements are specified in TF-2 Section 2:3, and requirements related to content modules are detailed in TF-3 Section 3:8. This section documents any additional requirements on the profile’s content actors.

Figure 1:10.1.1-1 illustrates a typical (not comprehensive) exchange scenario between SDPi-P actors:

puml sdpi p example sequence diagram
Figure 1:10.1.1-1. SDPi-P Example Sequence Diagram
1:10.1.1.1 SOMDS Participant

Actor Summary Definition:

  1. A foundational abstract actor that provides the SOA architectural constructs for interoperating in a Service-Oriented Medical Device System (SOMDS) network instance, including information, messaging and dynamic behavior models. (See [ISO/IEEE 11073-10207:2017] “PARTICIPANT” definition)

All systems participating in a SOMDS network instance must implement this Abstract actor.

All SDPi Profiles actors are grouped with (inherit from) this actor, including both transport / transaction actors and content module actors. This required grouping ensures that all systems connecting to a SOMDS network support the SES+MDI requirements [5] necessary for establishing a Plug-and-Trust (PnT) ecosystem, including the secure and dynamic provision of an implementation’s System Function Contribution (SFC). See Appendix 1:A.1 for additional discussion.

1:10.1.1.2 SOMDS Provider

Actor Summary Definition:

  1. A SOMDS Participant that provides at least one service to the other participant systems. (See [ISO/IEEE 11073-10207:2017] “SERVICE PROVIDER” definition.)

Every SOMDS Provider is paired with (inherits from) the abstract SOMDS Participant Actor.

A system that participates in a SOMDS network instance can include both SOMDS Consumer and SOMDS Provider Actors.

1:10.1.1.3 SOMDS Consumer

Actor Summary Definition:

  1. A SOMDS Participant that discovers and utilizes at least one service, functional capability, exposed to a network communications backbone by a SOMDS Provider. (See [ISO/IEEE 11073-10207:2017] “SERVICE CONSUMER” and “SERVICE” definitions.)

Every SOMDS Consumer is paired with (inherits from) the abstract SOMDS Participant Actor.

A system that participates in a SOMDS network instance can include both SOMDS Consumer and SOMDS Provider.

1:10.1.1.4 SOMDS Connector

Actor Summary Definition:

  1. A SOMDS Participant that enables seamless interaction with systems and software applications that are outside the scope of the SOMDS network instance. This abstract actor provides a consistent method for interacting, as a SOMDS Consumer and / or SOMDS Provider, with a specific SOMDS instance, as the foundation for protocol-specific gateway and platform actors.

Every abstract SOMDS Connector is grouped with (inherits from) the abstract SOMDS Participant.

A SOMDS Connector can implement both SOMDS Consumer and SOMDS Provider.

In the case of a connector implementing a SOMDS Consumer, it is able to interact with other SOMDS Provider to either obtain information that is then made available to Non-SOMDS Systems or invoke services that are requested from the external Non-SOMDS Systems. For example, forwarding patient respiratory rate readings to an external “flow sheet” application or invoking a device’s “pause alert audio” service when a clinician indicates they are responding to a physiological alert condition (e.g., high respiratory rate).

In the case of a connector implementing a SOMDS Provider, service capabilities for interacting with Non-SOMDS Systems are provided to the other networked SOMDS Consumer. For example, an application that wants to retrieve patient information from an EHR or check the latest patient laboratory results.

Note that the term “connector” is used to allow for SOMDS interaction with other systems that do not require protocol “gateway” adaptation, but do require a consistent interface to the other participants within a SOMDS environment. See Section 1:10.1.1.7 and Section 1:10.1.1.8 for examples.

Each SOMDS Connector gateway implementation will include the protocol-specific rules for connecting to and interacting with external non-SOMDS Systems, including semantic mappings, message formats, and interaction sequences. See related discussion at Section 3:8.3.2.4.

SDPi 1.4 Supplement Note: The TF-3 SDC/BICEPS Mapping of SOMDS Connector Content Modules section is out-of-scope., but included above for completeness of this actor overview.

Although the SDPi-P Profile SOMDS Connector provides for non-SOMDS protocol-specific adaptors, they establish the foundation for specifying system and application-specific interfaces such as for EHR or decision support systems (e.g., sepsis determination). See Section 1:10.4.1.4, and Section 1:10.4.1.6 for additional perspectives and concepts on how SOMDS Connectors may be implemented.

SOMDS Connector system implementations may support multiple protocols where there is one SOMDS-facing participant model or API but with multiple protocols for non-SOMDS system integration. For example, a SOMDS “Alert” Gateway would interact with other SOMDS Participants in a single consistent way but may support both [HL7 FHIR] and [HL7 V2] protocols for interacting with healthcare enterprise systems.

SOMDS Connector may also be utilized in other SDPi Profiles for medical device information reporting (SDPi-R), alerting (SDPi-A) and external control (SDPi-xC). See those profile specifications for detailed usage. In some cases, IHE profiles have been defined for supporting integration with Non-SOMDS Systems, such as the V2-based IHE Devices Device to Enterprise Communication (DEC) profile (See [IHE PCD TF-1:2019]), or the IHE ITI XDS-I for locating and retrieving images for a specific patient using the XDS.b profile. In these cases, profile-specific SOMDS Connector adaptors may be specified as well.

1:10.1.1.5 SOMDS FHIR Gateway

Actor Summary Definition:

  1. A SOMDS Connector that supports use of [HL7 FHIR] for interoperating with Non-SOMDS Systems.

SOMDS FHIR Gateway Actors shall be grouped with (inherit from) the abstract SOMDS Connector Actor. They shall implement either a SOMDS Provider and / or SOMDS Consumer Actor.

The SOMDS FHIR Gateway actor identifies and specifies the logic necessary for connecting a SOMDS network environment with Non-SOMDS Systems that utilize [HL7 FHIR] for their interoperability protocol. Generally, this logic is defined in the HL7 [HL7 FHIR Point-of-Care Device Implementation Guide].

Gateways implementing this actor can support any of the FHIR architectural approaches: RESTful, messaging, documents, and SOA. For example, a SOMDS FHIR Gateway can utilize a SOMDS Consumer to retrieve information from other SOMDS Participant systems, map it into FHIR Bundle resources and forward it on to non-SOMDS systems in a FHIR message.

Alternatively, the SOMDS FHIR Gateway could implement a FHIR server and provide support for systems to discover and retrieve information asynchronously, including the use of FHIR publication / subscription (“pub/sub”) services.

The SOMDS FHIR Gateway can also support SOMDS services invoked by FHIR-based systems, such as requesting a snapshot of the latest vital signs measurements for a specific patient and triggering a blood-pressure cuff reading.

1:10.1.1.6 SOMDS V2 Gateway

Actor Summary Definition:

  1. A SOMDS Connector that supports use of [HL7 V2] for interoperating with Non-SOMDS Systems.

SOMDS V2 Gateway Actors shall be grouped with (inherit from) the abstract SOMDS Connector Actor. They shall implement either a SOMDS Provider and / or SOMDS Consumer Actor.

The SOMDS V2 Gateway identifies and specifies the logic necessary for connecting a SOMDS network environment with Non-SOMDS Systems that utilize [HL7 V2] for their interoperability protocol. Since V2 is a message-based protocol, the primary implementation guide logic is defined in Appendix 2:B.2. Additional specifications for semantic content modules is detailed in Section 3:8, including Section 3:8.3.2.3.

Generally, the SOMDS V2 Gateway supports messaging from a SOMDS environment to V2-enabled systems, utilizing a SOMDS Consumer to collect information from SOMDS Provider systems and translate them to V2 messages sent to other Non-SOMDS Systems. There are cases, though, where information may be sent to a SOMDS-based system such as an alert conformation utilizing a [DEV-05] (i.e., [PCD-05]) transaction (see Section 1:12 below).

1:10.1.1.7 SOMDS Sensor Gateway

SDPi 1.4 Supplement Note: Detailed specifications for this actor are deferred to a later version of the SDPi Supplement.

Actor Summary Definition:

  1. A SOMDS Connector that supports integration of sensors external to a SOMDS network.

SOMDS Sensor Gateway Actors shall be grouped with (inherit from) the abstract SOMDS Connector. They shall implement either a SOMDS Provider and / or SOMDS Consumer Actor.

The SOMDS Sensor Gateway identifies and specifies the logic necessary for integration of signals and controls from small sensor and actuator devices that do not have the resources to support direct integration into a SOMDS network. This includes integration of both wired and wireless sensor networks (“WSN”). This also includes SOMDS integration of IoT (“Internet of Things”) architectures / networks.

1:10.1.1.8 SOMDS Smart App Platform

SDPi 1.4 Supplement Note: Detailed specifications for this actor are deferred to a later version of the SDPi Supplement.

Actor Summary Definition:

  1. A SOMDS Connector that supports connection to a SOMDS network that is optimized for applications, including Software as a Medical Device (SaMD).

SOMDS Smart App Platform Actors shall be grouped with (inherit from) the abstract SOMDS Connector Actor. They shall implement either a SOMDS Provider and / or SOMDS Consumer Actor.

This actor leverages the consistent integration of a SOMDS Connector to a SOMDS network environment but provides a simplified platform specification to support “smart apps” including Software as a Medical Device (SaMD). For example, an application may only need to identify and consume a few parameters from one or more SOMDS Participant systems and not be required to implement a complete SOMDS interface including security, discovery, subscription management, filtering of unneeded MDIB information, etc.

SOMDS Smart App Platform Actors provide an abstraction layer between application software and the requirements for interoperating in a SOMDS network backbone. Since a single platform actor can support multiple Smart Apps, network traffic may be significantly reduced, as well as processing overhead for SOMDS Provider systems that have multiple SOMDS Consumers simultaneously invoking their services.

The platform must support both non-smart app critical functions (such as network topology discovery and maintenance) but also aggregate app requirements (e.g., quality of service necessary to support an application’s algorithms).

See Section 1:10.4.1.8 for additional discussion.

1:10.1.1.9 BICEPS Content Creator

Actor Summary Definition:

  1. Provides MDIB content conformant to [ISO/IEEE 11073-10207:2017] BICEPS specification and for consumption by other BICEPS Content Consumer systems.

All content created and provided by a BICEPS Content Creator shall be conformant to the BICEPS content module specifications in Section 3:8.3.2.1 and related sections.

Note that although this SDPi-P content actor primarily supports information exchange between systems participating in a SOMDS network environment, they may also be utilized by other non-SDPi profiles that support non-SOMDS exchange architectures, transactions and technologies.

Content is provided by one SOMDS Participant to another. Typically, this will be a SOMDS Provider system to a SOMDS Consumer system; however, as noted previously, in some cases such as changing configuration settings within a SOMDS Provider (e.g., Patient Context), content creation and provision is from a SOMDS Consumer (initiating the configuration change request) to a SOMDS Provider system.

1:10.1.1.10 BICEPS Content Consumer

Actor Summary Definition:

  1. Processes MDIB information conformant to [ISO/IEEE 11073-10207:2017] BICEPS specifications provided by BICEPS Content Creator systems.

A BICEPS Content Consumer shall be capable of processing information provided by a BICEPS Content Creator, in accordance to the BICEPS content module specifications in Section 3:8.3.2.1 and related sections.

For robustness, a BICEPS Content Consumer need only process the content that is necessary to support its capabilities, but shall also be able to accept and ignore any additional content that may be provided but is out-of-scope for its internal requirements. [6]

Note that although this SDPi-P content actor primarily supports information exchange between systems participating in a SOMDS network environment, they may be referenced by other non-SDPi profiles that utilize other non-SOMDS exchange architectures, transactions and technologies.

1:10.1.1.11 Discovery Proxy

Actor Summary Definition:

  1. A centralized registry of system network presence and absence metadata.

The Discovery Proxy Actor provides a centralized means for systems connected to a network to update a central registry when they are present and available, as well as notification when they are leaving and will be absent. This is necessary for network configurations that do not support decentralized system discovery.

1:10.2 SDPi-P Actor Options

Options that may be selected for this Integration Profile are listed in the Table 1:10.2-1 along with the actors to which they apply. Dependencies between options when applicable are specified in notes.

Table 1:10.2-1. SDPi-P Profile - Actors and Options

Actor

Option Name

Vol. & Section

SOMDS Consumer

Managed Discovery Option

Section 1:10.2.1

Discovery Proxy

Managed Discovery Option

Section 1:10.2.1

SOMDS Provider

Managed Discovery Option

Section 1:10.2.1

1:10.2.1 Managed Discovery Option

The Discovery Proxy profile option provides an alternative means for SOMDS Consumer Actors to discover the SOMDS Provider Actors that are present on the network. The default "ad hoc" approach using the Section 2:3.23, Section 2:3.24 and Section 2:3.34 transactions, requires use of unsecured multicast messaging; however, some deployments do not support or allow this mode of discovery. The addition of a Discovery Proxy Actor enables a secure and non-multicast means for managing system discovery across the network. The Discovery Proxy Actor acts as a man-in-the-middle system, with SOMDS Provider Actors using the Section 2:3.46 transaction to provide endpoint metatdata and update their network presence or absence status. SOMDS Consumer Actors may then use the Section 2:3.47 transaction to determine available SOMDS Consumer systems and their endpoint metadata.

Figure 1:10.2.1-1 provides an overview of the interactions of the SOMDS Consumer and SOMDS Provider Actors with the Discovery Proxy Actor.

target=puml sdpi p managed discovery option sequence diagram
Figure 1:10.2.1-1. SDPi-P Managed Discovery Option - transaction Sequence Diagram

Once the discovery process is complete, actor interactions continue as normal. See Figure 1:10.1.1-1 for additional detail.

R1021

When the Managed Discovery Option is enabled for a SOMDS Provider Actor, then it shall use the DEV-46 transaction to update the Discovery Proxy Actor on its network presence and departure.

R1022

If a SOMDS Provider Actor is configured or provisioned for the Managed Discovery Option, but the proxy system is not available, then the SOMDS Provider shall revert back to "ad hoc" discovery mode.

R1023

When the Managed Discovery Option is enabled for a SOMDS Consumer Actor, then it shall use the DEV-47 transaction to retrieve SOMDS Provider network presence metadata from the Discovery Proxy Actor.

When retrieving network presence metadata from a Discovery Proxy Actor, a Discovery Scope may be specified as a filter to identify a specific subset of SOMDS Provider systems.
A SOMDS Consumer may optionally use the Section 2:3.47 transaction to subscribe to all metadata updates from a set of SOMDS Consumer systems, essentially using the Discovery Proxy Actor as a pass through for SOMDS Provider Section 2:3.23 and Section 2:3.34 transactions.
R1024

If a SOMDS Consumer Actor is configured or provisioned for the Managed Discovery Option, but the proxy system is not available, then the SOMDS Consumer shall revert back to "ad hoc" discovery mode.

R1025

In order to ensure that a system’s network presence information is up-to-date and valid, during the period when the Discovery Proxy indicates that a system is present, it shall provide some means to determine that this state is still true.

For example, issuing a periodic "heartbeat" check message or cable-connected check. Specification of these means will be provided for in the transport-specific implementation specification for the DEV-46 transaction.

Though it is not recommended, deployments may allow simultaneous use of both the default "ad hoc" discovery mode and the managed proxy-based discovery mode utilizing a Discovery Proxy Actor. In these configurations, SOMDS Consumer and SOMDS Provider systems should prioritize use of the Discovery Proxy Actor.

Provisioning of SOMDS Participant systems to support use of a Discovery Proxy Actor is out-of-scope for this specification.

1:10.3 SDPi-P Required Actor Groupings

SDPi 1.4 Supplement Note: As indicated in Figure 1:10.1-1 above, there are no explicit grouped actors in this specification; however, there are abstract actors (SOMDS Participant and SOMDS Connector), and the SOMDS Connector may implement interfaces to SOMDS Provider or SOMDS Consumer to provide bidirectional exchanges with non-SOMDS systems.

These actor relationships do not represent typical IHE grouped actors, but should be represented in more explicit detail. The best approach for achieving that clarity and specificity will be addressed in a future version after further review and discussion by the supplement development team.

1:10.4 SDPi-P Overview

1:10.4.1 Concepts

1:10.4.1.1 SOA & SOMDS Architecture Alignment

From a conceptual perspective, SDC implements a SOA architecture for device-to-device Plug-and-Trust (PnT) interoperability. Consider Figure 1:10.4.1.1-1:

vol1 diagram sdc soa conceptual model
Figure 1:10.4.1.1-1. General Service Oriented Architecture (SOA) Model

This generalized model includes (3) system roles:

  1. Service Providers — indicate the capabilities or services that they support, often published to a centralized registry that all participating systems recognize;

  2. Service Registry — a SOA network capability enabling participating systems to discover or "find" services provided by networked systems, as well as information for how a service consumer system can initiate a connection with specific Service Providers;

  3. Service Consumer — a SOA network system that utilizes the capabilities registered by a Service Provider.

A detailed overview of SOA concepts is beyond the scope of this specification. See Appendix 1:B for additional background materials.

The SDC BICEPS standard, which SDPi-P profiles, consists of (3) core components, as illustrated in Figure 1:10.4.1.1-2:

vol1 diagram sdc biceps component view
Figure 1:10.4.1.1-2. SDC/BICEPS Components Model

The Medical Data Information Base (MDIB) component applies to all participating systems and consists of a descriptive model (e.g., what services and information a SOMDS Provider supports), and a state model. The discovery and communications models combine to enable device-to-device messaging and to identify both systems and services available on the network. The descriptive model is covered in more detail in Section 3:8.3.2.1, but the following Figure 1:10.4.1.1-3 shows how network efficiency is achieved by separating descriptive information from dynamic state information:

vol1 diagram sdc biceps mdib description state
Figure 1:10.4.1.1-3. SDC/BICEPS MDIB Descriptors & States

For every SOMDS Provider system, there is a descriptive model that includes a detailed specification of every element in the MDIB. For each Descriptor, though, there is a State element (note the inclusion of a State::DescriptorHandle), that can be used to determine the value and change status for the associated descriptor. Therefore, though the MDIB of a SOMDS Provider system must be retrieved at discovery and connection time, subsequent updates can be made upon state changes, greatly reducing network communication overhead.

For an example of how BICEPS components (see Figure 1:10.4.1.1-2) and MDIB descriptors and states (see Figure 1:10.4.1.1-3) support Plug-and-Trust (PnT) interoperability, a typical conversation is provided in Figure 1:10.1.1-1.

1:10.4.1.2 Medical Devices Communication Profile for Web Services (MDPWS)

To support the SOA-based connectivity described above, the default transport technology for this SDPi-P Profile is the XML-based Web Services as specified in [ISO/IEEE 11073-20702:2016]. Additional "glue" constraints for this MDPWS specification are provided in the companion standard: [ISO/IEEE 11073-20701:2018]. Specific SDPi-P Profile transaction message bindings and examples are provided in Appendix 2:A.

1:10.4.1.3 General Healthcare vs. Medical Interoperability Purposes

SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.

1:10.4.1.4 Ensuring Time Synchronization

SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.

1:10.4.1.5 Waveform Communication

SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.

1:10.4.1.6 Aggregators, Proxies, Sensors

SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.

1:10.4.1.7 Protocol-Specific Gateways

SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.

1:10.4.1.8 Smart App Platforms

SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.

1:10.4.1.9 Workflow vs. Transport Actors and Interactions

SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.

1:10.4.1.10 SDC / BICEPS MDIB Versioning Management

SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.

1:10.4.2 Use Cases

The SDPi-P Profile supports requirements from use cases detailed in Appendix 1:C. The following subsections identify the specific use case requirements that are fulfilled with capabilities provided by this specification.

1:10.4.2.1 Synchronized Time Across Devices (STAD)

This use case fully addresses the requirements from Appendix 1:C.2.

Specific capabilities supporting the STAD use case include:

1:10.4.2.2 Standalone ICU Dashboard Single Patient (SICDsp)

This use case provides capabilities for requirements from Appendix 1:C.3.

Specific capabilities supporting the SICDsp use case include:

1:10.4.2.3 Standalone ICU Dashboard Multiple Patient (SICDmp)

This use case provides capabilities for requirements from Appendix 1:C.4.

Specific capabilities supporting the SICDmp use case include:

1:10.4.2.4 Device Data to Enterprise Systems (DDES)

This use case provides capabilities for requirements from Appendix 1:C.5.

Specific capabilities supporting the DDES use case include:

1:10.4.2.5 Alerts to Clinician Notification Systems (ACNS)

This use case provides capabilities for requirements from Appendix 1:C.6.

Specific capabilities supporting the ACNS use case include:

1:10.4.2.6 Alerts to Alert Recording Systems (AARS)

This use case provides capabilities for requirements from Appendix 1:C.7.

Specific capabilities supporting the AARS use case include:

1:10.5 SDPi-P Safety, Effectiveness and Security - Requirements and Considerations

1:10.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

1:10.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

1:10.5.3 Effectiveness Requirements & Considerations

1:10.5.3.1 Specific Risk Control Measures for SOMDS Consumers
R1542

When a SOMDS Consumer disables one or more System Function Contribution (SFC)s, the SOMDS Consumer shall inform the affected users.

R1543

If a SOMDS Consumer disables one or more System Function Contribution (SFC)s, the SOMDS Consumer shall create a log entry, noting the disabled System Function Contribution (SFC)s as well as the cause for disabling them.

1:10.5.3.2 General Risk Controls

Additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

1:10.5.4 Security Requirements & Considerations

Security is foundational for all interactions between SOMDS Participant Actors, with a clear distinction being made between information that may be exchanged outside of a secure connection (e.g., during network discovery transactions). Specific security technologies may vary based on the implementation technology being used, and will be detailed in the appropriate TF-2 technology specifications. All transactions indicate whether they require secure or unsecured connections.

For the default SDPi-P connectivity technology, namely ISO/IEEE 11073 Service-oriented Device Connectivity (SDC), TLS 1.2 (or later versions) support is required (See [ISO/IEEE 11073-20701:2018] and [ISO/IEEE 11073-20702:2016]). Additional information and requirements may be provided in Appendix 2:A.

1:10.6 SDPi-P Cross Profile Considerations

No cross profile considerations have been identified.

1:11 Service-oriented Device Point-of-care Interoperability - Reporting (SDPi-R) Profile

SDPi 1.4 Supplement Note: This version of the SDPi-R Profile is built upon the foundational SDPi-P Profile but does not provide substantially more capabilities. This is due to the fact that the primary purpose of this SDPi-R Profile, namely communication of medical data to accomplish intended medical purposes, requires the completion and integration of two emerging ISO/IEEE standards: [IEEE 11073-10700:2022] and [IEEE 11073-10701:2022]. When these are published in 2023 / 2024, their requirements will be integrated into this supplement, with their Implementation Conformance Statement (ICS) added to Appendix 1:B.2 below. Many of those requirements will be mapped to the actors and transactions and other elements in this supplement, including this SDPi-R Profile.

Additionally, though the SOMDS DEC Gateway is defined below and fully specified in Appendix 2:B.3, the implementation guide for mapping from BICEPS to HL7 FHIR remains in development, pushing the specification of the SOMDS FHIR Medical Data Gateway to a later version of this supplement.

The SDPi-Reporting ( SDPi-R) Profile supports the communication of information from one Service-oriented Medical Device System (SOMDS) to other SOMDS systems or to other external non-SOMDS systems utilizing a Data Gateway. Most of the actors and transactions in this specification are specialized versions of their counterparts in the SDPi-P Profile; however, are differentiated in that they are specifically designed to communicate information with an intended medical purpose. As a result, additional requirements are added to each actor and transaction to support address these additional safety and effectiveness requirements (See Section 1:11.5 below).

The profile builds upon the foundational Plug-and-Trust (PnT) capabilities provided by the SDPi-P Profile. These extended capabilities for medical data exchange are achieved by various means, including:

  1. Grouping SDPi-R actors with their SDPi-P counterparts

  2. Addressing requirements from the emerging PKP ISO/IEEE standards: [IEEE 11073-10700:2022] and [IEEE 11073-10701:2022]

  3. Requiring capabilities that in the SDPi-P Profile may be optional

  4. Requiring additional BICEPS data elements or content modules

1:11.1 SDPi-R Actors, Transactions, and Content Modules

This section defines the actors, transactions, and/or content modules in this specification. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A. IHE Transactions can be found in the Technical Frameworks General Introduction Appendix B. Both appendices are located at profiles.ihe.net/GeneralIntro.

Figure 1:11.1-1 shows the actors directly involved in the SDPi-R Profile. The relevant transactions between them are detailed in the subsequent Table 1:11.1-1. actor groupings, including abstract with concrete, are detailed in Section 1:11.3.

vol1 diagram sdpi r actor
Figure 1:11.1-1. SDPi-R Actor Diagram
Table 1:11.1-1. SDPi-R Profile - Actors and Transactions

Actors

Transactions

Initiator or Responder

Optionality

Reference

SOMDS Medical Data Provider

Establish Medical Data Exchange

Responder

R

Section 2:3.35

Publish Medical Data

Initiator

R

Section 2:3.36

Retrieve Medical Data

Responder

R

Section 2:3.37

SOMDS Medical Data Consumer

Establish Medical Data Exchange

Initiator

R

Section 2:3.35

Publish Medical Data

Responder

R

Section 2:3.36

Retrieve Medical Data

Initiator

O

Section 2:3.37

SOMDS DEC Gateway

Establish Medical Data Exchange

Initiator (See Note 1)

R

Section 2:3.35

Publish Medical Data

Responder (See Note 1)

R

Section 2:3.36

Retrieve Medical Data

Initiator (See Note 1)

O

Section 2:3.37

Note 1: If the SOMDS DEC Gateway implements the SDPi-R Option: Retrieve Remote Data, then bidirectional exchange is supported and the roles are expanded to "Initiator & Responder".

1:11.1.1 Actor Descriptions and Actor Profile Requirements

SDPi-R actor roles and responsibilities are described in the subsections below.

Unless otherwise specified below, individual transaction requirements are specified in TF-2 Section 2:3, and requirements related to content modules are detailed in TF-3 Section 3:8. This section documents any additional requirements on the profile’s content actors.

Figure 1:11.1.1-1 illustrates a typical (not comprehensive) exchange scenario between SDPi-R actors:

puml sdpi r example sequence diagram
Figure 1:11.1.1-1. SDPi-R Example Sequence Diagram
1:11.1.1.1 SOMDS Medical Data Consumer

Actor Summary Definition:

  1. A SOMDS Consumer grouped actor that receives medical data from a SOMDS Provider.

This actor is designed to process information with an intended medical purpose, and thus will fully address applicable requirements from the core SDC standards ([ISO/IEEE 11073-10207:2017] and [ISO/IEEE 11073-20701:2018]), as well as the PKP standards ([IEEE 11073-10700:2022] and [IEEE 11073-10701:2022]).

Every SOMDS Medical Data Consumer is grouped with an SOMDS Consumer to enable SOMDS-based connectivity. This actor inherits all the capabilities of the paired SOMDS Consumer. Note that optional capabilities for this specification, as specified in Section 1:11.2, may also result in additional requirements for the underlying SOMDS Consumer and SDPi-P Profile.

A system that participates in a SOMDS network instance can integrate both SOMDS Medical Data Consumer and SOMDS Medical Data Provider capabilities.

1:11.1.1.2 SOMDS Medical Data Provider

Actor Summary Definition:

  1. A SOMDS Provider grouped actor that sends medical data to a SOMDS Consumer.

This actor is designed to process information with an intended medical purpose, and thus will fully address applicable requirements from the core SDC standards ([ISO/IEEE 11073-10207:2017] and [ISO/IEEE 11073-20701:2018]), as well as the PKP standards ([IEEE 11073-10700:2022] and [IEEE 11073-10701:2022]).

Every SOMDS Medical Data Provider is grouped with an SOMDS Provider to enable SOMDS-based connectivity. This actor inherits all the capabilities of the paired SOMDS Provider. Note that optional capabilities for this specification, as specified in Section 1:11.2, may also result in additional requirements for the underlying SOMDS Provider and SDPi-P Profile.

A system that participates in a SOMDS network instance can integrate both SOMDS Medical Data Provider and SOMDS Medical Data Consumer capabilities.

1:11.1.1.3 SOMDS DEC Gateway

Actor Summary Definition:

  1. A SOMDS V2 Gateway grouped actor that supports the bi-directional exchange of medical data using IHE Device Enterprise Communication (DEC) messages with non-SOMDS systems and applications.

This actor is designed to process information with an intended medical purpose, and thus will fully address applicable requirements from the core SDC standards ([ISO/IEEE 11073-10207:2017] and [ISO/IEEE 11073-20701:2018]), as well as the PKP standards ([IEEE 11073-10700:2022] and [IEEE 11073-10701:2022]).

Every SOMDS DEC Gateway is grouped with an SOMDS V2 Gateway to enable SOMDS-based connectivity. This actor inherits all the capabilities of the paired SOMDS V2 Gateway. Note that optional capabilities for this specification, as specified in Section 1:11.2, may also result in additional requirements for the underlying SOMDS V2 Gateway and SDPi-P Profile.

This actor shall implement the SOMDS Medical Data Consumer capabilities, receiving information provided by SOMDS Medical Data Provider systems and publishing them as [DEV-01] / [PCD-01] Transactions to external DEC Device Observation Consumer (DOC) systems. If SDPi-R Option: Retrieve Remote Data is implemented, then this actor will also support the SOMDS Medical Data Provider capabilities, receiving [DEV-01] / [PCD-01] Transactions from external DEC Device Observation Reporter (DOR) systems and making them available to other SOMDS Medical Data Consumer systems. Note: Not supported are SOMDS DEC Gateway systems that only implement the SOMDS Medical Data Provider and not SOMDS Medical Data Consumer capabilities.

Detailed specifications for mapping from SOMDS/BICEPS to HL7 V2 / DEC transactions are provided in Appendix 2:B.3.

1:11.1.1.4 SOMDS FHIR Medical Data Gateway

Actor Summary Definition:

  1. A SOMDS FHIR Gateway grouped actor that supports exchange of medical data between SOMDS-based systems and HL7 FHIR-based systems.

SDPi 1.4 Supplement Note: The HL7 FHIR resources and related Point-of-Care Device FHIR Implementation Guide (PoCD FHIR IG) is still under active development. Initial mappings have been made from SDC to FHIR; however, they are not yet ready for profiling and product implementation. When the FHIR specifications are finalized, then this actor will be fully specified in a future SDPI Supplement version.

See SOMDS FHIR Gateway for additional information.

1:11.2 SDPi-R Actor Options

1:11.2.1 Retrieve Remote Data

SDPi 1.4 Supplement Note: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi Supplement.

This option will enable SOMDS Medical Data Consumer systems to access information in remote systems that are not part of its SOMDS network instance. This access will be provided by either a SOMDS DEC Gateway or SOMDS FHIR Medical Data Gateway. For example, retrieving the latest laboratory information for a specific patient.

1:11.3 SDPi-R Required Actor Groupings

SDPi 1.4 Supplement Note: As indicated in Figure 1:11.1-1 above, there are four grouped actors:

This section will be more completely detailed in a future version of the supplement.

1:11.4 SDPi-R Overview

1:11.4.1 Concepts

SDPi 1.4 Supplement Note: An overview of the concepts for this SDPi-R Profile will be provided in a future supplement version. Note that this specification extends the concepts established in the base SDPi-P Profile.

1:11.4.2 Use Cases

The SDPi-R Profile supports requirements from use cases detailed in Appendix 1:C. The following subsections identify the specific use case requirements that are fulfilled with capabilities provided by this specification.

1:11.4.2.1 Standalone ICU Dashboard Single Patient (SICDsp)

This use case provides capabilities for requirements from Appendix 1:C.3.

Specific capabilities supporting the SICDsp use case include:

1:11.4.2.2 Standalone ICU Dashboard Multiple Patient (SICDmp)

This use case provides capabilities for requirements from Appendix 1:C.4.

Specific capabilities supporting the SICDmp use case include:

1:11.4.2.3 Device Data to Enterprise Systems (DDES)

This use case provides capabilities for requirements from Appendix 1:C.5.

Specific capabilities supporting the DDES use case include:

1:11.5 SDPi-R Safety, Effectiveness and Security - Requirements and Considerations

1:11.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

A primary source of safety requirements for this SDPi-R Profile come from the [IEEE 11073-10701:2022] Metric Participant Key Purposes (PKP) standard.

SDPi 1.4 Supplement Note: The [IEEE 11073-10700:2022] and [IEEE 11073-10701:2022] standards are currently being published by the IEEE. Once published, their requirements will be integrated into this supplement, with many of them being mapped to elements in this SDPi-R Profile.

1:11.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

1:11.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

1:11.5.4 Security Requirements & Considerations

No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P Profile (see Appendix 1:A.3), and those specified in the SES General Considerations Section above.

1:11.6 SDPi-R Cross Profile Considerations

No additional cross profile considerations have been identified.

1:12 Service-oriented Device Point-of-care Interoperability - Alerting (SDPi-A) Profile

SDPi 1.4 Supplement Note: This initial version of the SDPi-A Profile is built upon the foundational SDPi-P Profile but adds services specialized for the communication and management of medical device alerting. Additionally, since the primary purpose of this specification is the communication of medical alert information to accomplish intended medical purposes, it will require the completion and integration of the emerging ISO/IEEE 11073 Alert PKP standard [IEEE 11073-10702:202x]. When this new standard is published in 2024, its requirements will be integrated into this supplement, with its Implementation Conformance Statement (ICS) added to Appendix 1:B.2. Many of those requirements will be mapped to the actors, transactions and other specifications in this specification.

Two of the transactions identified below, [DEV-41] and [DEV-42] are related to Medical Alert Delegation; however, at this stage there is considerable standards development activity to update the current SDC standards, particularly in association with completing the Alert PKP standard [IEEE 11073-10702:202x]. As a result, the completion of these two transactions has been deferred to a subsequent version of the supplement.

Similarly, a related transaction, [DEV-43], namely providing clinician alert acknowledgement status information back to the alerting device, is also being discussed further and will be deferred to a subsequent version of the supplement.

Finally, it should be noted that SOMDS ACM Gateway is defined below and fully specified in Appendix 2:B.4. Also in development is HL7 FHIR support for medical alerting (e.g., definition of a FHIR DeviceAlert resource); however, that will not be completed until 2024 or beyond. As a result, a "SOMDS Medical Alert FHIR Gateway" is not included as an actor at this stage; however, it is expected to be added in the coming year or two.

The SDPi-Alerting ( SDPi-A) Profile supports the communication of alert information from one Service-oriented Medical Device System (SOMDS) to other SOMDS systems or to other external non-SOMDS systems utilizing a Alert Gateway. The actors and transactions in this specification are specialized versions of their counterparts in the SDPi-P Profile; however, are differentiated in that they are specifically designed to communicate alert information to fulfill an intended medical purpose, primarily to notify a clinician of a patient or device-related condition that requires their attention. Additional services have been provided to specifically support the exchange and management of this medical device alert information, providing a high-level of reliability and performance, commensurate with the potential risk to the patient if they are not promptly addressed.

The profile builds upon the foundational Plug-and-Trust (PnT) capabilities provided by the SDPi-P Profile. These extended capabilities for medical data exchange are achieved by various means, including:

  1. Grouping SDPi-R actors with their SDPi-P counterparts

  2. Addressing requirements from the emerging PKP ISO/IEEE standards: [IEEE 11073-10700:2022] and [IEEE 11073-10701:2022]

  3. Requiring capabilities that in the SDPi-P Profile may be optional

  4. Requiring additional BICEPS data elements or content modules

Additional requirements to addressed safety and effectiveness requirements are provided in Section 1:12.5.

1:12.1 SDPi-A Actors, Transactions, and Content Modules

This section defines the actors, transactions, and/or content modules in this specification. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A. IHE Transactions can be found in the Technical Frameworks General Introduction Appendix B. Both appendices are located at profiles.ihe.net/GeneralIntro.

Figure 1:12.1-1 shows the actors directly involved in the SDPi-A Profile. The relevant transactions between them are detailed in the subsequent Table 1:12.1-1. Actor groupings, including abstract with concrete, are detailed in Section 1:12.3.

vol1 diagram sdpi a actor
Figure 1:12.1-1. SDPi-A Actor Diagram
Table 1:12.1-1. SDPi-A Profile - Actors and Transactions

Actors

Transactions

Initiator or Responder

Optionality

Reference

SOMDS Medical Alert Provider

Establish Medical Alert Exchange

Responder

R

Section 2:3.38

Publish Medical Alert Update

Initiator

R

Section 2:3.39

Retrieve Medical Alert Status

Responder

R

Section 2:3.40

Manage Medical Alert Delegation (deferred)

Responder

R (See Note 1)

[DEV-41] Deferred to SDPi 2.0

Delegate Medical Alert (deferred)

Initiator

R (See Note 1)

[DEV-42] Deferred to SDPi 2.0

Update Alert Acknowledgement Status (deferred)

Responder

R

[DEV-43] Deferred to SDPi 2.0

SOMDS Medical Alert Consumer

Establish Medical Alert Exchange

Initiator

R

Section 2:3.38

Publish Medical Alert Update

Responder

R

Section 2:3.39

Retrieve Medical Alert Status

Initiator

O

Section 2:3.40

Manage Medical Alert Delegation (deferred)

Initiator

R (See Note 1)

[DEV-41] Deferred to SDPi 2.0

Delegate Medical Alert (deferred)

Responder

R (See Note 1)

[DEV-42] Deferred to SDPi 2.0

Update Alert Acknowledgement Status (deferred)

Initiator

R

[DEV-43] Deferred to SDPi 2.0

SOMDS ACM Gateway (See Note 2)

Establish Medical Alert Exchange

Initiator

R

Section 2:3.38

Publish Medical Alert Update

Responder

R

Section 2:3.39

Retrieve Medical Alert Status

Initiator

O

Section 2:3.40

Update Alert Acknowledgement Status (deferred)

Initiator

O

[DEV-43] Deferred to SDPi 2.0

Note 1: Transaction is required if SDPi-A Option: Alert Delegation is supported.

Note 2: By default, the SOMDS ACM Gateway acts as a SOMDS Medical Alert Consumer, initiating [DEV-04] transactions when they are received from SOMDS Medical Alert Consumers. If the gateway supports SDPi-A Option: Remote Alert Signaling, then it also acts as a SOMDS Medical Alert Consumer and accepts inbound [DEV-04] transactions from ACM Alert Reporters. In this case, the gateway will support both "Initiator & Responder" for these transactions.

1:12.1.1 Actor Descriptions and Actor Profile Requirements

SDPi-A actor roles and responsibilities are described in the subsections below.

Unless otherwise specified below, individual transaction requirements are specified in TF-2 Section 2:3, and requirements related to content modules are detailed in TF-3 Section 3:8. This section documents any additional requirements on the profile’s content actors.

Figure 1:12.1.1-1 illustrates a typical (not comprehensive) exchange scenario between SDPi-A actors:

puml sdpi a example sequence diagram
Figure 1:12.1.1-1. SDPi-A Example Sequence Diagram
1:12.1.1.1 SOMDS Medical Alert Consumer

Actor Summary Definition:

  1. A SOMDS Consumer grouped actor that receives medical alert information from a SOMDS Medical Alert Provider.

This actor is designed to receive and manage medical device alert information to communicate it safely and reliably to a clinician. Transactions enabled for this actor are identified in Table 1:12.1-1 above.

Given this intended medical purpose, the actor will fully address applicable requirements from the core SDC standards ([ISO/IEEE 11073-10207:2017] and [ISO/IEEE 11073-20701:2018]), as well as the PKP standards [IEEE 11073-10700:2022] and [IEEE 11073-10702:202x] (Alert PKP).

Every SOMDS Medical Alert Consumer is grouped with an SOMDS Consumer to enable SOMDS-based connectivity. This actor inherits all the capabilities of the paired SOMDS Consumer. Note that optional capabilities for this specification, as specified in Section 1:12.2, may also result in additional requirements for the underlying SOMDS Consumer and SDPi-P Profile.

Note that if a Smart Alerting System is being created, it may incorporate both SOMDS Medical Alert Consumer and SOMDS Medical Alert Provider Actors, both receiving and publishing alerts.

1:12.1.1.2 SOMDS Medical Alert Provider

Actor Summary Definition:

  1. A SOMDS Provider grouped actor that sends medical alert information to a SOMDS Medical Alert Consumer.

This actor is designed to publish medical device alert information to a SOMDS Medical Alert Consumer, which in turn can communicate it safely and reliably to a clinician. Transactions enabled for this actor are identified in Table 1:12.1-1 above.

Given this intended medical purpose, the actor will fully address applicable requirements from the core SDC standards ([ISO/IEEE 11073-10207:2017] and [ISO/IEEE 11073-20701:2018]), as well as the PKP standards [IEEE 11073-10700:2022] and [IEEE 11073-10702:202x] (Alert PKP).

Every SOMDS Medical Alert Provider is grouped with an SOMDS Provider to enable SOMDS-based connectivity. This actor inherits all the capabilities of the paired SOMDS Consumer. Note that optional capabilities for this specification, as specified in Section 1:12.2, may also result in additional requirements for the underlying SOMDS Consumer and SDPi-P Profile.

Note that if a Smart Alerting System is being created, it may incorporate both SOMDS Medical Alert Consumer and SOMDS Medical Alert Provider Actors, both receiving and publishing alerts.

1:12.1.1.3 SOMDS ACM Gateway

Actor Summary Definition:

  1. A SOMDS V2 Gateway grouped actor that supports the bi-directional exchange of medical alert information with non-SOMDS systems and applications using IHE Alert Communication Management (ACM) transactions.

This a is designed to exchange medical device alert information to external non-SOMDS systems using the HL7 V2-based Alert Communication Management (ACM) Profile transactions.

Every SOMDS ACM Gateway is grouped with an SOMDS V2 Gateway to enable SOMDS-based connectivity. This actor inherits all the capabilities of the paired SOMDS V2 Gateway. Note that optional capabilities for this specification, as specified in Section 1:11.2, may also result in additional requirements for the underlying SOMDS V2 Gateway and SDPi-P Profile.

Transactions enabled for this actor are identified in Table 1:12.1-1 above.

Given this intended medical purpose, the actor will fully address applicable requirements from the core SDC standards ([ISO/IEEE 11073-10207:2017] and [ISO/IEEE 11073-20701:2018]), as well as the PKP standards [IEEE 11073-10700:2022] and [IEEE 11073-10702:202x] (Alert PKP).

This actor shall implement the SOMDS Medical Alert Consumer capabilities, receiving alert information provided by SOMDS Medical Alert Provider systems and publishing them as [DEV-04] / [PCD-04] Transactions to external ACM Alert Manager (AM) systems. If SDPi-A Option: Remote Alert Signaling is implemented, then this actor will also support the SOMDS Medical Alert Provider capabilities, receiving [DEV-04] / [PCD-04] Transactions from external ACM Device Observation Reporter (DOR) systems and making them available to other SOMDS Medical Data Consumer systems. Note: Not supported are SOMDS DEC Gateway systems that only implement the SOMDS Medical Data Provider and not SOMDS Medical Data Consumer capabilities.

Detailed specifications for mapping from SOMDS/BICEPS to HL7 V2 / ACM [DEV-04]/[PCD-04] transactions are provided in Appendix 2:B.4.

This actor is not intended to play the role of an ACM Alert Manager. If [DEV-04] transactions are received by the gateway, they will be simply mapped to SOMDS/BICEPS semantics and provided to SOMDS Medical Alert Consumer systems.

If a Smart Alerting System is being created, it may incorporate both SOMDS Medical Alert Consumer and SOMDS Medical Alert Provider Actors, both receiving and publishing alerts to external ACM-based systems.

1:12.2 SDPi-A Actor Options

1:12.2.1 Alert Delegation Option

SDPi 1.4 Supplement Note: This section is intentionally left incomplete blank to indicate capabilities that will be added in a future version of the SDPi Supplement. As stated elsewhere, the completion of the [IEEE 11073-10702:202x] standard is required before this profile can be completed (beyond alert reporting for DIS capabilities), and that is especially the case for alert delegation.

The sequence diagram below for delegation is provided for informative purposes only and will be finalized when the IEEE standard and this profile option are completed.

This option will enable SOMDS Medical Alert Provider systems to safely and reliably transfer or "delegate" audible annunciation of alert conditions to another system. This option will enable both the Manage Medical Alert Delegation [DEV-41] and Delegate Medical Alert [DEV-42] transactions.

Figure 1:12.2.1-1 illustrates a typical (not comprehensive) alert delegation scenario between SDPi-A actors:

puml sdpi a delegation example sequence diagram
Figure 1:12.2.1-1. SDPi-A Delegate Medical Alert Example Sequence Diagram

1:12.2.2 Alert User Acknowledgement Option

SDPi 1.4 Supplement Note: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi Supplement.

This option will enable SOMDS Medical Alert Provider systems to safely and reliably receive from SOMDS Medical Alert Consumer systems user (clinician) acknowledgement of previously reported alert conditions. This option will enable the Update Alert Acknowledgement Status [DEV-43] transaction.

1:12.2.3 Remote Alert Signaling

SDPi 1.4 Supplement Note: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi Supplement.

This option will enable SOMDS ACM Gateway systems to receive [DEV-04]/[PCD-04] transactions from an ACM Alert Manager and then act as a SOMDS Medical Alert Provider to communicate the signals to SOMDS Medical Alert Consumer systems This option will enable the SOMDS ACM Gateway to respond to Establish Medical Alert Exchange [DEV-38] and Retrieve Medical Alert Status [DEV-40] transactions, and to initiate Publish Medical Alert Update [DEV-39] transactions.

1:12.3 SDPi-A Required Actor Groupings

SDPi 1.4 Supplement Note: As indicated in Figure 1:11.1-1 above, there are four grouped actors:

This section will be more completely detailed in a future version of the supplement.

1:12.4 SDPi-A Overview

1:12.4.1 Concepts

SDPi 1.4 Supplement Note: An overview of the concepts for this SDPi-A Profile will be provided in a future supplement version. Note that this specification extends the concepts established in the base SDPi-P Profile.

1:12.4.2 Use Cases

The SDPi-A Profile supports requirements from use cases detailed in Appendix 1:C. The following subsections identify the specific use case requirements that are fulfilled with capabilities provided by this SDPi-A Profile.

1:12.4.2.1 Standalone ICU Dashboard Single Patient (SICDsp)

This use case provides capabilities for requirements from Appendix 1:C.3.

Specific capabilities supporting the SICDsp use case include:

1:12.4.2.2 Standalone ICU Dashboard Multiple Patient (SICDmp)

This use case provides capabilities for requirements from Appendix 1:C.4.

Specific capabilities supporting the SICDmp use case include:

1:12.4.2.3 Alerts to Clinician Notification Systems (ACNS)

This use case provides capabilities for requirements from Appendix 1:C.6.

Specific capabilities supporting the ACNS use case include:

1:12.4.2.4 Alerts to Alert Recording Systems (AARS)

This use case provides capabilities for requirements from Appendix 1:C.7.

Specific capabilities supporting the AARS use case include:

1:12.5 SDPi-A Safety, Effectiveness and Security - Requirements and Considerations

1:12.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

1:12.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

1:12.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

1:12.5.4 Security Requirements & Considerations

No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P Profile (see Appendix 1:A.3), and those specified in the SES General Considerations Section above.

1:12.6 SDPi-A Cross Profile Considerations

No additional cross profile considerations have been identified.

1:13 Service-oriented Device Point-of-care Interoperability – external Control (SDPi-xC) Profile

SDPi 1.4 Supplement Note: This SDPi-xC (External Control) Profile Section is generally out-of-scope for this version of the profile (see "Gemini SDPi Releases" Github project); however, it is provided here to indicate the intended direction of the SDPi Profiles, with details being added in subsequent versions. Depending on capabilities, some very basic controls may need to be provided in 2024 as part of the 1.x or 2.0 versions, especially around external adjustment of settings (e.g., alert limits or to trigger a blood-pressure reading).

The SDPi-External Control ( SDPi-xC) Profile enables external or "remote" control of one device by another. This may be as simple as adjust an alarm limit or triggering a blood pressure cuff reading, to adjusting a respiration rate on a ventilator or titrating a drug dose rate on an infusion pump. Specializes services and semantics are provided to enable safe and secure control invocation.

1:13.1 SDPi-xC Actors, Transactions, and Content Modules

This section defines the actors, transactions, and/or content modules in this specification. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A. IHE Transactions can be found in the Technical Frameworks General Introduction Appendix B. Both appendices are located at profiles.ihe.net/GeneralIntro.

Figure 1:13.1-1 shows the actors directly involved in the SDPi-xC profile. The relevant transactions between them are detailed in the subsequent Table 1:13.1-1. actor groupings, including abstract with concrete, are detailed in Section 1:13.3.

vol1 diagram sdpi xc actor
Figure 1:13.1-1. SDPi-xC Actor Diagram
Table 1:13.1-1. SDPi-xC Profile - Actors and Transactions

Actors

Transactions

Initiator or Responder

Optionality

Reference

SOMDS Medical Control Provider

Manage Medical External Control (deferred)

Responder

R

[DEV-44] Deferred to SDPi 3.0 or later

Invoke Medical Control Services (deferred)

Responder

R

[DEV-45] Deferred to SDPi 3.0 or later

SOMDS Medical Control Consumer

Manage Medical External Control (deferred)

Initiator

R

[DEV-44] Deferred to SDPi 3.0 or later

Invoke Medical Control Services (deferred)

Initiator

R

[DEV-45] Deferred to SDPi 3.0 or later

1:13.1.1 Actor Descriptions and Actor Profile Requirements

SDPi-xC actor roles and responsibilities are described in the subsections below.

Unless otherwise specified below, individual transaction requirements are specified in TF-2 Section 2:3, and requirements related to content modules are detailed in TF-3 Section 3:8. This section documents any additional requirements on the profile’s content actors.

Figure 1:13.1.1-1 illustrates a typical (not comprehensive) exchange scenario between SDPi-xC actors:

puml sdpi xc example sequence diagram
Figure 1:13.1.1-1. SDPi-xC Example Sequence Diagram
1:13.1.1.1 SOMDS Medical Control Consumer

Actor Summary Definition:

  1. A SOMDS Consumer grouped actor that invokes operational control services on a SOMDS Medical Control Provider.

This actor is designed to invoke and manage medical device control operations, safely, effectively and securely. Transactions enabled for this actor are identified in Table 1:13.1-1 above.

Given this intended medical purpose, the actor will fully address applicable requirements from the core SDC standards ([ISO/IEEE 11073-10207:2017] and [ISO/IEEE 11073-20701:2018]), as well as the PKP standards [IEEE 11073-10700:2022] and [IEEE 11073-10703:202x] (Control PKP).

Every SOMDS Medical Control Consumer is grouped with an SOMDS Consumer to enable SOMDS-based connectivity. This actor inherits all the capabilities of the paired SOMDS Consumer. Note that optional capabilities for this specification, as specified in Section 1:12.2, may also result in additional requirements for the underlying SOMDS Consumer and SDPi-P Profile.

1:13.1.1.2 SOMDS Medical Control Provider

Actor Summary Definition:

  1. A SOMDS Provider grouped actor that provides operational control services to a SOMDS Medical Control Consumer.

This actor is designed to publish medical device operational control services to a SOMDS Medical Control Consumer, which in turn can invoke the services and remotely manage the device, safely and securely. Transactions enabled for this actor are identified in Table 1:13.1-1 above.

Given this intended medical purpose, the actor will fully address applicable requirements from the core SDC standards ([ISO/IEEE 11073-10207:2017] and [ISO/IEEE 11073-20701:2018]), as well as the PKP standards [IEEE 11073-10700:2022] and [IEEE 11073-10703:202x] (Control PKP).

Every SOMDS Medical Control Provider is grouped with an SOMDS Provider to enable SOMDS-based connectivity. This actor inherits all the capabilities of the paired SOMDS Consumer. Note that optional capabilities for this specification, as specified in Section 1:12.2, may also result in additional requirements for the underlying SOMDS Consumer and SDPi-P Profile.

1:13.2 SDPi-xC Actor Options

No options are specified for this specification.

1:13.3 SDPi-xC Required Actor Groupings

SDPi 1.4 Supplement Note: As indicated in Figure 1:13.1-1 above, there are two grouped actors:

This section will be more completely detailed in a future version of the supplement.

1:13.4 SDPi-xC Overview

1:13.4.1 Concepts

SDPi 1.4 Supplement Note: An overview of the concepts for this SDPi-A Profile will be provided in a future supplement version. Note that this specification extends the concepts established in the base SDPi-P Profile.

1:13.4.2 Use Cases

SDPi 1.4 Supplement Note: No use cases have been included that provide functional requirements for device external control. These will be added to a future version of the SDPi supplement. Therefore, with this release of the SDPi specification, this section remains incomplete.

1:13.5 SDPi-xC Safety, Effectiveness and Security - Requirements and Considerations

1:13.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

1:13.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

1:13.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

1:13.5.4 Security Requirements & Considerations

No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P Profile (see Appendix 1:A.3), and those specified in the SES General Considerations Section above.

1:13.6 SDPi-xC Cross Profile Considerations

No additional cross profile considerations have been identified.

Appendix 1:A Requirements Management for Plug-and-Trust Interoperability

These SDPi specifications include the model-centric integration of requirements from multiple sources — both within IHE and from other SDOs — enabling a new level of requirements management that provides new value to all stakeholders. Also termed Requirements Interoperability (RI), innovative capabilities include:

  1. Explicit linking of requirements from their definition to their satisfaction / utilization in defined capabilities;

  2. Explicit linking of requirements from external sources (e.g., normative standards references) to where they are supported in the profile specification, either completely, partially, unsupported or out-of-scope;

  3. Requirement "chains" — sequences of requirement-capability links, including requirement-to-requirement and capability-to-capability — that enable traceability from capability conformance testing to the multiple requirements that the function satisfies ;

  4. Referenced standard traceability and coverage is enabled by this linkage from each requirement to testable interface capabilities;

  5. Both SES and MDI standards are supported, enabling true SES+MDI integration;

  6. Test reports and declarations of conformity can be created to support the needs of and increase the confidence of all stakeholders, from technology product developers, to public regulatory agencies, to system integrators, to healthcare delivery organizations that manage and use the systems, to patients who will directly benefit from improved healthcare and health!

These combine to establish RI as the door to a new generation of truly "computable" specifications.

From another perspective, requirements interoperability looks at one standard as having both a set of requirements that must be satisfied for a system to be conformant, and a set of capabilities that it provides that can be utilized to meet the requirements of other standards. Requirements interoperability essentially looks at each standard as a set of building blocks that can be snapped together and integrated into a coherent and cohesive structure.

The following sections in this appendix provide background on the concepts and rationale behind requirements interoperability and the details for how it is implemented in this specification.

1:A.1 Requirements: From Narratives to Plug-and-Trust Interfaces

For every device or system interface that supports the elements specified in this technical framework, requirements and capabilities are derived from many different standards, types of standards, and standards development organizations (SDO). Some are technology focused, such as the ISO/IEEE 11073 standards for health device communication, and others are more focused on quality and risk management, such as the ISO/IEC 80001-1 and ISO 14971 standards. They are all profiled and implemented and tested in a single interface point, and thus need to be integrated in a coherent and cohesive manner.

In order to manage this diversity and wealth of specifications and standards, the Hanging Gardens Framework graphic as specified in Figure 1:A.1-1 was created:

vol1 diagram hanging gardens
Figure 1:A.1-1. Hanging Gardens Framework

Though a full explanation of the framework is beyond this discussion [7], some general observations will help understand the value and use of the framework:

  1. Real-world Requirements are at the top — use case-based requirements that detail clinical system function scenarios, ensuring that all requirements and capabilities in the specifications are rooted in the healthcare purposes that technology users are expecting to be supported: effectively, safely and securely;

  2. Each layer or "garden" and contained specification(s) define - implicitly or explicitly - how they integrate with other layers: *capabilities* that are provided (to meet the needs of other layers), and *requirements* (needed capabilities) for other layers and implementations;

  3. Standards are sometimes grouped into families (e.g., ISO/IEEE 11073 SDC) - this indicates that they are internally cohesive as well as able to be integrated as a group with other areas;

  4. *Vertical* groupings on the left indicate standards that apply to all of the *horizontal* layers in the core of the model;

  5. Profile standards, such as the SDPi+FHIR, generally integrate specifications through the layers from the top to the bottom similar, with each layer contributing to those below and converging in a single interface capability bundle;

  6. Physical layers are leveraged, not re-invented, which is why there is no color in the bottom layer;

  7. *Requirements interoperability* is achieved by tracing "profile lines" from top to bottom, integrating requirements from one layer’s specification to the capabilities provided by another layer;

  8. Requirement TYPEs are rooted in the layers that they represent and link type definitions to their use in this specification; see Appendix 1:A.4.1 Section below.

The implementation of this high-level framework will be extended as the specifications and tooling mature.

1:A.2 Integrating Safety, Effectiveness and Security Requirements and Considerations

In 2007, a joint effort between ISO/TC 215 and IEC/SC 62A was launched — Joint Working Group 7 (JWG7) — to focus on how to apply risk management to medical devices and health information systems and software that needed to interoperate on shared (hospital owned & managed) networking infrastructure. The resulting standard, [ISO/IEC 80001-1:2021], with a first edition published in 2010 and revised in 2021, not only provided a process for performing coordinated multi-stakeholder risk management for these technologies, but recognized the three key properties that would be the focus of that risk management: Safety, Effectiveness & Security (SES) [8].

During the development of the 80001-1 standard, though, it was recognized that risk management is just one of a number of other core themes that had to be managed in concert (e.g., quality management, human factors / usability). Also ensuring SES required processes that involve a total product lifecycle, with responsibilities transitioning across that period. To address these requirements, JWG7 developed the [ISO/IEC 81001-1:2021] standard, which also included The Temple diagram to communicate various aspects of SES that must be considered and managed:

vol1 diagram 81001 temple
Figure 1:A.2-1. ISO/IEC 81001-1 — The "Temple" Diagram

One of the key challenges for implementing this standard, though, is what might be labeled: The Interoperability Trust Gap. This is the technology "hand off" space between the left side of the lifecycle — Design and development phase, where key responsibility is by each of the "Accountable Manufacturer" organizations, and the right side of the lifecycle — Implementation phase & Clinical use phase, where key responsibility is on the Accountable Healthcare Delivery Organization (HDO). Though this reads well in the standards and the model organizes everything in a clear fashion, operationalizing this in real world use remains a Sisyphean effort, primarily due to the amount of expertise, time and resources needed to effectively implement the SES standards as part of normal operating business in HDOs.

To address this SES implementation problem, the SDPi Profiles:

  1. Leverage the ISO/IEEE 11073-1070x Participant Key Purposes (PKP) standards, which represent a consensus standard for risk management of technologies that are implemented in that left-right gap on the Temple model;

  2. Implementation Conformance Statement (ICS) tables from each of these PKP standards is included in Appendix 1:B of this specification, with indication as to whether, how and where each requirement is addressed;

  3. "Safety, Effectiveness and Security - Requirements and Considerations" sections are integrated throughout the profile specifications to link from the PKP ICS table requirements to the satisfying capabilities.

    1. Additional non-PKP risk management will also be performed by subject matter experts and formalized in these SES Considerations sections, where appropriate.

These "Safety, Effectiveness and Security - Requirements and Considerations" sections grew out of the IHE "Security Considerations" sections + the IHE Devices "Safety Considerations" sections, but are now consolidated into a single SES section that integrates the 3rd risk management property, Effectiveness. Whenever possible, each of these considerations should be associated with the requirements of specific standards (e.g, [IEEE 11073-10700:2022]).

The moniker SES+MDI is shorthand to refer to the integration of the technical medical device interoperability (MDI) specifications with the application of quality / risk management SES standards and processes.

How does this address the "interoperability trust gap"? By integrating SES directly into the specifications, especially integrating the ISO/IEC 11073-1070x standards, enabling "plug-and-trust" system product components, the SES implementation and operational requirements and responsibilities are greatly reduced, the "gap" is filled for all stakeholders, and the goals of improved safety, security and clinical effectiveness of technology can be readily realized.

1:A.3 SES Considerations Section Template

Given the forgoing discussion in Section 1:2.2, a standardized template is defined for addressing SES requirements as appropriate, including within the scope of profiles, actors, transactions, and content modules. The content in the following sections should be included and then specialized as appropriate for the associated technical framework element.

SES Section Template:

Safety, Effectiveness and Security - Requirements and Considerations

SES General Considerations

This section includes guidance and requirements that are not further specialized for specific SES properties.

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

Safety Requirements & Considerations

This section includes guidance and requirements that are focused on unique Safety requirements associated with associated technical framework element. Note: a simple definition of safety within the context of risk management is "freedom from unacceptable harm" (see 81001.org/safety)

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

Effectiveness Requirements & Considerations

This section includes guidance and requirements that are focused on unique Effectiveness requirements associated with associated technical framework element. Note: in the context of risk management key properties, effectiveness is the ability to perform the intended use (see 81001.org/effectiveness)

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

Security Requirements & Considerations

This section includes guidance and requirements that are focused on unique Security requirements associated with associated technical framework element. In the context of risk management key properties, security is a state where information and systems are protected from unauthorized activities to a degree that the related risks to confidentiality, integrity, and availability are maintained at an acceptable level throughout the lifecycle (see 81001.org/security)

No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P profile, and those specified in the SES General Considerations Section above.

1:A.4 SDPi Requirements Modeling & Integration

SDPi 1.4 Supplement Note: The information in this section includes both general requirements modeling information that captures the metadata that is ultimately exported for document-external use. It also includes specific AsciiDoc information (e.g., element labels) to facilitate review by providing all the related information in one location. Ultimately, the AsciiDoc and related information that is used for specification production and requirement exportation (e.g., export JSON mapping and file format), will be moved to a separate article or paper.

As pointed out above, requirements interoperability (RI) based on robust model-based metadata is a core, innovative aspect of this specification. Given the ultimate intent for this document to be a Model Centric (MC) single-source-of-truth, computable, simulatable, verifiable and validatable system of systems interoperability specification, and recognizing that it will take a significant transition period from a document-centric approach to a model-centric approach, the simplified requirements model provided below represents a significant step toward realizing these objectives. See section Figure 1:A.4.1-1 below for possible pathways for fully achieving the vision above.

It should be further noted that though conformity testing aspects are beyond this revision of the SDPi specification, the modeling constructs used below will also be directly associated with test assertions and integrated into test / verification cases to provide for advanced V&V of interoperable system components and entire systems of products.

1:A.4.1 SDPi Requirements Core Model

To formally integrate requirements in to this specification, the following model details the core types of requirements that will be utilized:

vol1 diagram sdpi req types model
Figure 1:A.4.1-1. SDPi Requirement Categories - Core Model

This model identifies the set of requirement "types" that are integrated into the specification. Each type defines a unique class of requirements that build upon a foundational Requirement Definition (abstract) definition that is specialized with additional metata to better capture the unique source and role of each requirement.

Table 1:A.4.1-1. SDPi Requirement - Core Model Element Descriptions
Model Element Description AsciiDoc Attribute Further Specified

Requirement Definition

A defined stakeholder-imposed constraint that must be satisfied for a design solution to be valid. This is an {abstract} class model element.

sdpi_requirement

NOTE: parent / sibling optional relationships provide for linking related requirements

Requirement Fulfillment

A capability provided in the specification that fulfills part or all of one or more requirements, and may be directly linked to a test assertion (external to the specification).

sdpi_requirement_fulfillment

IHE Profile

Each IHE profile specification has a set of requirements that must be captured. For example, Actor X in Profile Y requires support for Transaction A + B + C. NOTE: These requirements provide the anchor for all conformity assessment, since implementations will identify the actors + profile + profile option + role + transactions that they support. See also "AIPO" discussion below.

sdpi_requirement_ihe_profile

Use Case Feature

A functional "feature" requirement based on clinical use case scenarios.

sdpi_requirement_use_case

See TF-1 Appendix C, Gherkin-based model

Referenced Standard ICS

Requirement definitions that are specified in a normative reference.

sdpi_requirement_ref_standard

SES

Non-technical requirements related to Safety, Effectiveness, and Security are captured in these blocks. These are especially relevant to mapping ISO/IEEE 11073-1070x Participant Key Purposes standard requirements to elements within the SDPi specification.

sdpi_requirement_ses

See SES Section Appendix 1:A.2

Tech Feature

Technology focused requirements result from the use of a particular implementation approach. For example, use of TLS 1.3 may also result in the need to address related technical capabilities.

sdpi_requirement_tech_feature

"ICS" = Implementation Conformance Statement (e.g., a table identify how conformance to a standard may be detailed)

The following subsections provide additional detail for each element of the above requirements model. Note that each item includes metadata that is used for computability purposes as well as textual elements that are visibly rendered in the document. All content may be exported from the specification and contained in a requirements summary specification in a common format (e.g., JSON), which may be used for additional purposes such as integration into requirements management tools and conformity assessment testing artifacts.

1:A.4.2 Requirement Type: Requirement Definition

Each type of requirement shares a common set of metadata represented by the abstract "Requirement Definition" in the model above. This metadata supports the basic capabilities of each requirement including classification (subtype), navigation (traceability), and grouping.

Table 1:A.4.2-1. SDPi Requirement - Core Model Element Descriptions
Metadata Element Description AsciiDoc Example Additional Consideations

Unique Identifier

Each requirement instance must include an identifier that is unique within the scope of the specification, and may be rendered in human-readable form

sdpi_requirement

[sdpi_requirement#r7009]

See Appendix 1:A.4.2.1 for additional discussion; note this identifier may be used for tracking in systems such as requirement management tools

Requirement OID

An ISO Object Identifier that is aligned with the IHE OID tree for the specific requirement.

sdpi_req_oid

[sdpi_req_oid=1.3.6.1.4.1.19376.1.6.2.11.2.123456]

This OID identifier is in addition to the Unique Identifier element, but is not considered human-readable and is not intended to be rendered in the document; this identifier is a type of URI

Requirement Type

Each requirement instance is identified by its subtype

sdpi_req_type

[sdpi_req_type=use_case_feature]

See specific subtype sections below for additional enumerations

Requirement Level

Each requirement instance includes a conformance level: shall, should, may

sdpi_req_level

[sdpi_req_level=shall]

Conditional requirements may need additional specification.

Requirement Text

Textual description of the requirement, intended for rendering in the specification

"All requirements shall be identified as one of the core subtypes."

The requirement text should be kept simple and clear. Additional explanatory text should be contained in requirement notes (see below)

Requirement Note(s)

Additional textual detail that supplements the Requirement Text

Free form text contained in a "NOTE"

"NOTE: The mapping for the height observation is defined in table …​"

  • More than one note may be included in a requirement specification.

  • The AsciiDoc [%collapsable] block option may be used to simplify the rendered text

Requirement Parent

Identifies a more general or related requirement that a requirement specializes

sdpi_req_parent

[sdpi_req_parent=r6789]

Unique identifiers may be used to link requirements

Requirement Sibling

Identifies one or more requirements that are related to this requirement

sdpi_req_sibling

[sdpi_req_sibling=r1234]

  • Unique identifiers may be used to link requirements

  • This is differentiated from a Requirement Fulfillment

Requirement Group(s)

A label that may be used to group related requirements

sdpi_req_group

[sdpi_req_group=ws_security]

Requirement groups or categories may be used independently of the parent/sibling linkages

The following sections discuss additional aspects of requirements formalization using this foundational Requirement Definition metadata.

1:A.4.2.1 Assigning Unique Identifiers

Every requirement must have a unique instance identifier that is used for:

  1. Human-readable display in the rendered document

  2. Requirements management systems (external)

  3. Conformity Assessment tooling (external)

Uniqueness must be achieved within the scope of the given specification (e.g., SDPi), and in the future, across specifications, both IHE technical frameworks as well as related standards that may use the same scheme.

Two requirement identifiers are currently specified:

Unique Identifier

  • Human-readable text that is displayed with detailed requirement content in the specification

  • Example: "R1234"

  • Identifiers have a simple numeric value, with four digits sufficient for most applications

  • Identifier letters may be enhanced from a simple "R" to include a type (e.g., RSR for Referenced Standard Requirement, or UCR for Use Case Requirement, etc.)

Requirement OID

  • A machine-readable URI style identifier that ensures global uniqueness

  • Root OID is based on the specification scope with IHE: 1.3.6.1.4.1.19376.1.6.2.11 = IHE DEV TF SDPi-P profile

  • Addition of .2.x is for a profile-specific requirement; for example: 1.3.6.1.4.1.19376.1.6.2.11.2.1234 = an SDPi-P Requirement "R1234"

  • Version can also be added to this OID in the future; for example: 1.3.6.1.4.1.19376.1.6.2.11.2.1234.1.0 for requirement version 1.0

FOR THE CURRENT SPECIFICATION, these identifiers are assigned manually, with an automated uniqueness check performed by the asciidoc-converter to HTML application. Assignment may evolve with experience and extended use.

1:A.4.2.2 Usage Levels

Requirement Level must be valued as one of the following strings: "shall", "should", "may". For example, "sdpi_req_level=should"

"Conditional" requirements may also need to be indicated in metadata; however, that is beyond the scope of the current specification revision. For example, there are some cases where the conditional logic might be included in the requirement specification:

  1. IF <condition #1>

  2. THEN <R1234 should be fulfilled>

Requirement conditionality may be easily added as a Requirement Note; however, that is not computable metadata. Another approach, would be to add a Requirement Condition data element that included some logic, perhaps linking to the presence of some configuration (such as a profile option selection) or other requirement. This will be addressed in subsequent versions of this specification.

1:A.4.2.3 Requirement Grouping

Some requirements may be grouped beyond their specification scope, requirement type or inter-requirement linkages. For example, security related requirements may include a "security" group label, regardless of where they are located in the specification. This provices a simple, easily extensible way for showing ad hoc associations between classes of requirements.

Requirement group labels may be included in a comma-separated list. For example: sdpi_req_group=security,real-time

This element should only be used when other association mechanisms do not easily meet the need.

1:A.4.3 Requirement Navigation

Although Figure 1:A.4.1-1 generally indicates bi-directional navigation (arrows on both ends of Requirement-Usage pairs, supporting bi-directional bindings and navigation is not always helpful and is never easy. This is especially the case when considering potential future updates to the profile specifications. In that case, the general rule is:

  1. Add backward references from Requirement Fulfillment to Requirement Definition.

For example, in TF-2 Transactions, each transaction section is paired with a message transport section in Appendix 2:A; however, future versions of the specification may provide options for alternative transports. In this case, the actual transaction definition will remain unchanged, but the bindings to transport messages and services would change. Given the rule above, bindings are made in the current TF-2 Appendix A MDPWS specification pointing backward (or upward!) to the transaction requirements that they satisfy. There are no bindings in the opposite direction. Taking this approach, a new transport appendix could be added in the future without impacting the core transaction specifications.

Application of this rule would also hold true in other places such as backward references from a profile’s Use Case section to the specific Appendix 1:C use case and scenario requirements that they satisfy.

In some cases, it may be necessary to provide bi-directional bindings; however, that would be the exception, not the rule.

1:A.4.4 Requirement Type: Technical Feature

Description: A basic technical requirement that is not one of the other catageories and does not require additional metadata.

Requirement Metadata:

  1. Requirement Definition Metadata: Unique Identifier, Requirement OID, Requirement Type, Requirement Level, Requirement Text

  2. Requirement Type = tech_feature

  3. Requirement Tech Feature: No additional data elements

Example: A SOMDS Participant should use a dynamically configured IP address.

1:A.4.5 Requirement Type: IHE Profile

Description: Requirement associated to an aspect of an IHE profile specification

Each of the top-level profile elements in Figure 1:A.4.5-1 may require additional sub-elements; however, care must be taken not to replicate the entire specification in requirements metadata! This reflects the ultimate objective of having a fully modeled specification, with the documentation generated automatically (see Appendix 1:A.5). At this point, only what is required to provide the intended capabilities (see below) should be included. Heuristic: start with less and add as needed.

vol1 diagram sdpi req ihe profile
Figure 1:A.4.5-1. Requirement Model — IHE Profile

Requirement Metadata:

  1. Requirement Definition Metadata: Unique Identifier, Requirement OID, Requirement Type, Requirement Level, Requirement Text

  2. Requirement Type = ihe_profile

  3. IHE Profile Metadata:

    1. TF Element = actor, profile, transaction, profile_option, profile_actor_option, content_module, actor_transaction_model

    2. AIPO = string representing unique Actor + Integration Profile + Profile Option combination

Example #1:

  1. Metadata: ihe_profile + R1234 + 1.3.6.1.4.1.19376.1.6.3.23 + actor + shall

  2. Requirement: The SOMDS Provider shall support the Section 2:3.24 transaction.

Example #2:

  1. Question: What requirements shall a SOMDS Provider support?

  2. Answer: Search exported requirements for Requirement Type=IHE Profile + AIPO=somds-provider_sdpi-p

1:A.4.6 Requirement Type: Use Case Feature

Description: A requirement in a high-level, profile-independent use case specification

Ultimately, test cases should reflect the detailed content of the use case requirements associated with each integration profile. Test assertions associated with a Requirement Fulfillment capability should then enabling traceability through the various Requirement Definitions that ultimately are linked to a Use Case Feature. The level of use case granularity may vary depending on whether the requirement is associated with the entire Use Case Feature, a specific Scenario, a Scenario’s Background Pre-Condition(s), etc.

vol1 diagram sdpi req use case feature
Figure 1:A.4.6-1. Requirement Model — Use Case Feature

SDPi 1.4 Supplement Note: Additional detail will be added in a subsequent version. Additional metadata may include:

  1. Use Case Identifier

  2. Use case element type and identifier

1:A.4.7 Requirement Type: Referenced Standard ICS

Description: A requirement linked to a referenced standard.

SDPi 1.4 Supplement Note: Additional detail will be added in a subsequent version. Additional metadata may include:

  1. Referenced Standard (document identifier, version and date; may be a link to the referenced standard section of the specification)

  2. Source requirement identifier in referenced standard

1:A.4.8 Requirement Type: SES

Description: Requirement that represents a quality aspect of the specification typically related to risk management activities and resulting mitigations

vol1 diagram sdpi req ses
Figure 1:A.4.8-1. Requirement Model — SES

Generally, SES sections are associated with major elements of the specification and provide guidance for what an implementation must do to ensure trustworthy operation.

Requirements from SES referenced standards such as [IEEE 11073-10700:2022] may be linked (e.g., as a parent) to an SES requirement type.

SDPi 1.4 Supplement Note: Additional detail will be added in a subsequent version. Additional metadata may include:

  1. SES Type = General, Safety, Effectiveness, Security

  2. Testability = Inspection, Interoperability ("on-the-wire" verification)

1:A.4.9 Requirement Use Type: Requirement Fulfillment

Description: Provides a link from a capability that may be associated with a test assertion to one or more requirements that it fulfills.

SDPi 1.4 Supplement Note: Additional detail will be added in a subsequent version. Additional metadata may include:

  1. Unique Identifier (label text + OID) that may be used for external test assertion linkages

  2. Fulfillment Level: Complete, partial

  3. Description of the implementation (e.g., "means for detecting 'heartbeat'")

1:A.4.10 Relationship to Gazelle Master Model + Assertion Manager Tool

IHE formalizes all profile conformity assessment elements in the Gazelle Master Model (GMM), including actors, transactions, profiles, profile options, and the test cases that are needed to ensure implementation conformance to each profile specification requirement. To associate groups of conformity tests with systems being tested, Gazelle defines an "AIPO" bundle: * Actor * Integration Profile (in which the actor being tested is included) * Profile Option

For example, a system under test may declare AIPO support for: Discovery Proxy + SDPi-P + Managed Discovery

The following graphic illustrates the information managed in the GMM:

vol1 diagram sdpi req gazelle master model
Figure 1:A.4.10-1. Gazelle Master Model (GMM) Information Model

The Gazelle Assertion Manager tool associates test assertions with IHE profile elements as follows:

vol1 diagram sdpi req gazelle assertion manager
Figure 1:A.4.10-2. Gazelle Assertion Manager Tool Information Model

The RI model specified here provides for explicit declaration of AIPO requirement bundles, facilitating the association of Gazelle-based test sequences for a given system under test.

Additionally, a Gazelle Assertion Manager Tool has been created to link testable assertions to sections within a specification and then to specific test scenarios; however, this tool is not currently in active use, and it is anticipated that it will serve to inform new test assertion management tooling required by this specification. There are fundamental differences, though, such as explicit requirement identifier numbering that allows assertions to be linked directly to requirements, as opposed to specification section numbers.

1:A.5 Future extensibility: Use Cases, MBSE Requirements Modeling & SysML 2.0

OMG's Systems Modeling Language 2.0 (see [OMG SysML ® 2.0] Section 7.20 Requirements language and [OMG SysML ® Intro-Graphical Notation 2.0]), provides extended support for requirements modeling that not only provides the foundation for implementation of Model-Based Systems Engineering (MBSE) methodology (see MBSE Wikipedia article and references), but also a computable specification that enables automated verification (e.g., using "Verification Cases"). As these technologies evolve and are more generally accessible to standards communities, it will be possible to align the above requirements model with that specified in SysML 2.0 and ultimately to provide a specification that can be verified correct and validated through simulation.

Appendix 1:B References

SDPi 1.4 Supplement Note: The inclusion of a References appendix is unique for IHE Technical Framework specifications. Typically, referenced standards sections are distributed throughout the specifications where appropriate; however, standards from other organizations (e.g., IEEE, ISO, IEC) typically have a "Normative References" clause and when desired a "Bibliography" clause. Also, integration of explicit standards' Implementation Conformance Statement (ICS) specifications (e.g., [ISO/IEEE 11073-10207:2017] ICS tables) is unique, but needed to support requirements interoperability.

Ultimately, the content of this appendix may be rearranged and even relocated; however, for early versions of the SDPi supplement, it has proven helpful, and even of critical importance and value.

1:B.1 Referenced Standards

SDPi 1.4 Supplement Note: The standards listed in this section are predominantly published. However, in the current version, three of them are unpublished drafts and are hence subject to requirement changes once they are published: [HL7 FHIR Point-of-Care Device Implementation Guide], [IEEE 11073-10702:202x] and [IEEE 11073-10703:202x]. No content from those three standards - including their requirements - is normatively used in the current version.

  • [AAMI 2700-1:2019] AAMI 2700-1:2019 Medical Devices And Medical Systems - Essential Safety And Performance Requirements For Equipment Comprising The Patient-Centric Integrated Clinical Environment (ICE) - Part 1: General Requirements And Conceptual Model, available at ANSI/AAMI web store.

  • [HL7 FHIR] HL7® Fast Healthcare Interoperability Resources (FHIR®), available at hl7.org/fhir/.

  • [HL7 FHIR Point-of-Care Device Implementation Guide] HL7 FHIR Point-of-Care Device Implementation Guide, drafts available on the Devices on FHIR project page, and a continuous build version at Point-of-Care Device Implementation Guide web page.

  • [HL7 V2] HL7® Version 2 (V2), available at HL7 Version 2 Product Suite web page.

  • [IEC 60601-1-8:2020], IEC 60601-1-8:2006/AMD2:2020, 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; Amendment 1:2020, and Amendment 2:2020. available at IEC Webstore and the ISO standards store.

  • [IEEE 11073-10101:2020] IEEE 11073-10101™ International Standard - Health informatics—​Device interoperability—​Part 10101:Point-of-care medical device communication—​Nomenclature. Available at IEEE online standards store.

  • [IEEE 11073-10201:2004] IEEE 11073-10201™ International Standard - Health informatics—​Device interoperability—​Part 10201:Point-of-care medical device communication—​Domain information model. Note this was updated in 2020. Available at IEEE online standards store.

  • [ISO/IEEE 11073-10207:2017] ISO/IEEE 11073-10207-2017, Health informatics — Point-of-care medical device communication — Part 10207: Domain Information and Service Model for Service-Oriented Point-of-Care Medical Device Communication, 2017-12, available at https://standards.ieee.org/ieee/11073-10207/6032 [1]

  • [IEEE 11073-10700:2022] IEEE P11073-10700™/D7 Draft Standard for Health Informatics – Device Interoperability – Part 10700: Point-of-Care Medical Device Communication – Standard for Base Requirements for Participants in a Service-Oriented Device Connectivity (SDC) System.

  • [IEEE 11073-10701:2022] IEEE P11073-10701™/D4 Draft Standard for Health Informatics – Device Interoperability – Part 10701: Point-of-Care Medical Device Communication - Metric Provisioning by Participants in a Service-Oriented Device Connectivity (SDC) System

  • [IEEE 11073-10702:202x] IEEE P11073-10702™/D1 Draft Standard for Health Informatics – Device Interoperability – Part 10702: Point-of-Care Medical Device Communication – Alert Provisioning by Participants in a Service-Oriented Device Connectivity (SDC) System

  • [IEEE 11073-10703:202x] IEEE P11073-10703™/Draft Standard for Health Informatics – Device Interoperability – Part 10703: Point-of-Care Medical Device Communication – External Control by Participants in a Service-Oriented Device Connectivity (SDC) System, in development.

  • [ISO/IEEE 11073-20701:2018] ISO/IEEE 11073-20701-2018, Health informatics — Point-of-care medical device communication — Part 20701: Service-Oriented Medical Device Exchange Architecture and Protocol Binding, 2018-09, available at https://standards.ieee.org/ieee/11073-20701/6059

  • [ISO/IEEE 11073-20702:2016] ISO/IEEE 11073-20702-2016, Health informatics — Point-of-care medical device communication — Part 20702: Medical Devices Communication Profile for Web Services, 2016-09, available at https://standards.ieee.org/ieee/11073-20702/6034

  • [ISO/IEC 80001-1:2021], IEC 80001-1:2021 Application of risk management for IT-networks incorporating medical devices — Part 1: Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software. Available at IEC Webstore and ISO standards store.

  • [ISO/IEC 81001-1:2021], ISO 81001-1:2021 Health software and health IT systems safety, effectiveness and security — Part 1: Principles and concepts. Availabe at ISO standards store and IEC Webstore.

  • [IHE PCD TF-1:2019] IHE Patient Care Device Technical Framework, Vol. 1, available at https://www.ihe.net/uploadedFiles/Documents/PCD/IHE_PCD_TF_Vol1.pdf.

  • [IHE PCD TF-2:2019] IHE Patient Care Device Technical Framework, Vol. 2, available at https://www.ihe.net/uploadedFiles/Documents/PCD/IHE_PCD_TF_Vol2.pdf.

  • [IHE PCD TF-3:2019] IHE Patient Care Device Technical Framework, Vol. 3, available at https://www.ihe.net/uploadedFiles/Documents/PCD/IHE_PCD_TF_Vol3.pdf.

  • [RFC 3986] T. Berners-Lee et al., RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, January 2005, available at https://www.rfc-editor.org/rfc/rfc3986

  • [OASIS DPWS:2009] OASIS Standard, Devices Profile for Web Services Version 1.1, OASIS Standard, 1 July 2009, available at http://docs.oasis-open.org/ws-dd/dpws/wsdd-dpws-1.1-spec.html

  • [OASIS SOAP-over-UDP Version 1.1] OASIS Standard, SOAP-over-UDP Version 1.1, July 2009, available at http://docs.oasis-open.org/ws-dd/soapoverudp/1.1/os/wsdd-soapoverudp-1.1-spec-os.docx.

  • [W3C Recommendation, WS-Addressing:2006] Web Services Addressing 1.0 - Core (WS-Eventing), W3C Recommendation 9 May 2006, available at https://www.w3.org/TR/2006/REC-ws-addr-core-20060509/

  • [OASIS WS-Discovery:2009] OASIS Standard, Web Services Dynamic Discovery (WS-Discovery) Version 1.1, OASIS Standard, 1 July 2009, available at http://docs.oasis-open.org/ws-dd/discovery/1.1/wsdd-discovery-1.1-spec.html

  • [W3C Submission, WS-Eventing:2006] W3C Web Services Eventing (WS-Eventing), W3C Member Submission 15 March 2006, available at https://www.w3.org/Submission/2006/SUBM-WS-Eventing-20060315/

  • [W3C Submission, WS-MetadataExchange:2008] Web Services Metadata Exchange 1.1 (WS-MetadataExchange), W3C Member Submission 13 August 2008, available at https://www.w3.org/Submission/2008/SUBM-WS-MetadataExchange-20080813/

  • [WC3 Standard, WS-Transfer:2006] WC3 Web Services Transfer (WS-Transfer), W3C Standard, 27 September 2006, available at https://www.w3.org/Submission/WS-Transfer/

1:B.2 Referenced Standards Conformance

1:B.2.1 Mapping Foundational Standard Requirements to SDPi Constructs

SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.

1:B.2.2 Overview of Standards Conformity Statements

SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.

1:B.2.3 ISO/IEC 11073-10207 BICEPS ICS Tables

SDPi 1.4 Supplement Note: This section is provided as a placeholder for the ICS table specification that will be added in a subsequent SDPi supplement version. The tables will have an additional SDPi column added to the right side that indicates if and TBD where the requirement is satisfied. Requirement Definition (this table’s rows) will be referenced where they are satisfied; however, these tables may also include forward references, at least in general, to what capabilities / requirements satisfy the referenced standard requirement.

Standard Version: IEEE 11073-10207:2017

1:B.2.3.1 General
GEN-1 & GEN-4 are broken references, GEN-2 and GEN-3 are satisfied by Glue, GEN-4 should be mandatory as extensions.

ADD IEEE: Table 20 — General ICSs table here

1:B.2.3.2 Service Provider

Optional requirements for the service provider side excluding contexts and external control.

ADD IEEE: Service Provider ICS table here

1:B.2.3.3 Service Consumer
CONS-1 is broken; R0115 is not optional in the released document.

ADD IEEE: Service Consumer ICS table here

1:B.2.3.4 Remote Control

ADD IEEE: Remote Control ICS table here

1:B.2.3.5 Context Processing
Context processing pertains to effective utilization of context information like workflow (e.g., orders) info, patient demographics and locations. A general concept should be described how to cope with contexts in terms of SDPi, i.e., device coupling mechanisms should be described informally in TF-1 and formally in TF-2 (as transaction?).

ADD IEEE: Context Processing ICS table here

1:B.3 Bibliography

In addition to Referenced Standards, which include normative requirements and capabilities that this technical framework utilizes, there are other standards, specifications, publications, presentations, materials, etc. that have proven valuable in both developing and understanding the framework’s content. This list identifies those items, including many of which are referenced throughout the specifications.

1:B.3.1 Media (non-standards) References

1:B.3.2 Standards & Publications

1:B.3.3 Presentations

  • [IHE EU Experience-2021 IHE CA for MedTech Solutions], "IHE & IHE Catalyst: Advancing Interoperable MedTec Solutions with "Regulatory Submission Ready" Conformity Assessment", presentation by Todd Cooper and Dr. Stefan Schlichting, available at IHE Europe Experience 2021 Presentations web page.

Appendix 1:C Device Point-of-care Interoperability (DPI) Use Cases

1:C.1 General Overview of DPI Use Cases & Analysis

SDPi 1.4 Supplement Note: This initial section of Appendix C is informative and is still being detailed. Completion is deferred to version 1.x or later. It provides general background detail around how general (non-technology specific) clinical use case specifications are being utilized in this supplement.

REVIEWER QUESTION: Please review the intended topics and identify any additional content that should be considered. Especially helpful would be references to related standards and materials that would inform the approach taken in this appendix.

1:C.1.1 Rich History of Medical Device Interoperability (MDI) Use Cases

The vision of plug-and-play medical device interoperability has been an active pursuit since the early 1980’s, with the IEEE 1073 group’s formation in those early years. Over the 40+ years, many projects — both industry and standards-based — have contributed to an ever growing set of real-world use cases, and the ISO/IEEE 11073 SDC program is no different.

Looking to leverage this wealth of use cases in considering SDPi, a "compendium of medical device oriented use cases" was created to facilitate referencing and use. The use cases detailed in this appendix build on those that are captured in this document: [IHE PCD SDPi Use Cases Compendium:2019]

1:C.1.2 Overview of Architectural & Business Systems Concepts

SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.

1:C.1.3 Use Case Specification Conventions Using Cucumber/Gherkin

SDPi 1.4 Supplement Note: This section contains initial content that will be greatly expanded in future versions.

Each Use Case (also called a Feature in Gherkin) is organized as follows:

  • Narrative – a description of the desired functionality from the user perspective

  • Technical View - graphic representation of typical business system actors utilized in this use case

  • Technical Pre-Conditions – any assumptions or pre-conditions

  • Scenario(s) – the scenarios explore both the Happy Path when everything goes according to plan and the Alternative Paths where things do not go according to plan.

1:C.1.4 Use Case Requirements Modeling

SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.

1:C.1.5 Application of ISO/IEC 60601-1-8 Concepts & Definitions

1:C.1.5.1 ISO/IEC 60601-1-8 Concepts for DIS, DAS and CDAS

The following is a quick guide to the functionality of DIS, CDIS, DAS and CDAS systems and how we have used and interpreted them for the purpose of this IHE Profile Supplement. Please refer to the next section on Definitions from [IEC 60601-1-8:2020] for normative definitions for these terms.

Note that the 1.4 version of the SDPi Profile only supports the Distributed Information System (DIS) model detailed below. The other models are anticipated for subsequent versions.
1:C.1.5.1.1 DIS – Distributed Information System

DIS is a system for reporting alarm signals with no technical confirmation (of receipt).

  • Cannot rely on it for alarm signaling as a risk control

  • Optional support operator alarm management response locally

  • Example — patient remote display, hallway display, one-way pager

1:C.1.5.1.2 CDIS – Distributed Information System with Confirmation

CDIS is a system for reporting alarm signals with no technical confirmation but with operator confirmation (accept/reject).

CDIS is not recognized in 60601-1-8, however it is implemented in practice and therefore included
  • Cannot rely on it for alarm signaling as a risk control

  • Optional support operator alarm management response locally and remotely

  • Example –- two-way pager (open loop)

1:C.1.5.1.3 DAS – Distributed Alarm System

DAS is a system for reporting alarm signals with technical confirmation (of receipt).

  • Can rely on it for alarm signaling as a risk control

  • Optionally supports local alarm management (alarm acknowledgement)

  • A communications failure or failure in any remote component of the DAS must initiate a technical alarm.

  • Example — Central Station

1:C.1.5.1.4 CDAS - Distributed Alarm System with Confirmation

CDAS is a system for reporting alarm signals with technical and operator confirmation (accept/reject) (of receipt).

  • Can rely on it for alarm signaling as a risk control

  • Supports operator confirmation (accept/reject); It may redirect…

  • Optionally support local/remote alarm management (acknowledgement)

  • A communications failure or failure in any remote component of the DAS must initiate a technical alarm.

  • Example — System that sends alarm to caregiver mobile device with accept / reject. Integrator may redirect

An xDIS can be either a DIS or CDIS. Similarly an xDAS can be either a DAS or CDAS.
Description Type Technical Delivery Confirmation1 Operator Delivery Confirmation2 Optional Alarm Management Examples

Reports alerts from a single patient (sp)

DISsp

No

No

Local

Single-Pt. information Dashboard

CDISsp

No

Yes3

Remote3

Single-Pt. Remote View w/accept/reject

DASsp

Yes

No

Local

Single-Pt. Cockpit w/audible alarms

CDASsp

Yes

Yes

Remote

Single-Pt. Cockpit w/accept/reject

Reports alerts from multiple patients (mp)

DISmp

No

No

Local

Multiple-Pt. information Dashboard or View Station

CDISmp

No

Yes3

Remote3

Multiple-Pt. info. View Station w/accept/reject

DASmp

Yes

No

Local

Multiple-Pt. Central Station w/audible alarms

CDASmp

Yes

Yes

Remote

Multiple-Pt. Central Station w/accept/reject

Reports and directs alerts to responsible caregiver (cg)

DIScg

No

No

Local

Alerts to caregiver pager, Mobile viewer

CDIScg

No

Yes3

Remote3

Alerts to caregiver pager, w/accept/reject

DAScg

Yes

No

Local

Alerts to caregiver w/audible/haptic signals

CDAScg

Yes

Yes

Remote

Alerts to caregiver w/accept/reject

1 In each communication step the receiving device provides a technical response to the sending device that it received and is taking responsibility for the alert

2 Operator can, at their choice, use the receiving device (communicator) UI to accept or reject responsibility for the alert

3 Not recommended since there is no confirmation that the Source has received the commands

1:C.1.5.2 ISO/IEC 60601-1-8 Definitions for DIS, DAS and CDAS

The following content is extracted directly from the [IEC 60601-1-8:2020] standard for reference purposes. Please consult that standard for comprehensive discussion and complete normative requirements, as well as the "rationale" section, which includes many of the concepts identified in this section.

1:C.1.5.2.1 DIS - DISTRIBUTED INFORMATION SYSTEM ABOUT ALARM CONDITIONS

system that involves more than one item of equipment in a ME SYSTEM intended to provide information about ALARM CONDITIONS but does not guarantee delivery of that information

NOTE 1: A DISTRIBUTED INFORMATION SYSTEM ABOUT ALARM CONDITIONS is not intended to notify OPERATORS of the existence of an ALARM CONDITION as a RISK CONTROL measure. A DISTRIBUTED INFORMATION SYSTEM ABOUT ALARM CONDITIONS is intended to provide information about an ALARM CONDITION while the OPERATOR is aware of the existence of the ALARM CONDITION by an ALARM SYSTEM.
NOTE 2: A DISTRIBUTED INFORMATION SYSTEM ABOUT ALARM CONDITIONS is not intended for confirmed delivery of ALARM CONDITIONS

Examples include:

  1. Sometimes referred to as secondary alerting devices: Hallway display of active alarms; Hallway light over room door; Caregiver worn device;

1:C.1.5.2.2 DAS - DISTRIBUTED ALARM SYSTEM

ALARM SYSTEM that involves more than one item of equipment in a ME SYSTEM intended for delivery of ALARM CONDITIONS with technical confirmation

NOTE 1: The parts of a DISTRIBUTED ALARM SYSTEM can be widely separated in distance.
NOTE 2: A DISTRIBUTED ALARM SYSTEM is intended to notify OPERATORS of the existence of an ALARM CONDITION.
NOTE 3: For the purposes of this document, technical confirmation means that each element of a DISTRIBUTED ALARM SYSTEM confirms or guarantees the successful delivery of the ALARM CONDITION to the next element or appropriate TECHNICAL ALARM CONDITIONS are created as described in clause 6.11.2.2.1 of [IEC 60601-1-8:2020].
vol1 diagram 60601 1 8 2020 figure 2
Figure 1:C.1.5.2.2-1. IEC 60601-1-8:2020, Figure 2 — Functions of a DISTRIBUTED ALARM SYSTEM utilizing a MEDICAL IT NETWORK

Examples include:

  • EXAMPLE 1 – A central station

  • EXAMPLE 2 – An electronic record-keeping device

  • EXAMPLE 3 – Remote viewing from home or office

  • EXAMPLE 4 – Bed-to-bed viewing of ALARM CONDITIONS (e.g., one nurse for two beds).

  • EXAMPLE 5 – Transmission of ALARM CONDITIONS to pagers, cell phones, hand-held computers, etc.

1:C.1.5.2.3 CDAS - DISTRIBUTED ALARM SYSTEM WITH OPERATOR CONFIRMATION

DISTRIBUTED ALARM SYSTEM that includes the capability to receive an OPERATOR response

Examples include:

  • Traditional Central Station;

  • Bed to Bed alarm feature supporting alarm acknowledge;

  • Caregiver worn device supporting alarm acknowledge

1:C.1.5.2.3.1 IEC 60601-1-8:2020, Subclause 6.11.2.4 CDAS

In a CDAS, the COMMUNICATOR that receives an ALARM CONDITION shall have means to create the OPERATOR responses (RESPONSIBILITY ACCEPTED or RESPONSIBILITY REJECTED) and transfer them to the INTEGRATOR.

  1. In a CDAS, the COMMUNICATOR that receives an ALARM CONDITION and initiates an OPERATOR response (RESPONSIBILITY ACCEPTED or RESPONSIBILITY REJECTED) shall indicate the OPERATOR response state (RESPONSIBILITY ACCEPTED or RESPONSIBILITY REJECTED).

The means of control used to initiate an OPERATOR response or indication of state may be marked with:

  1. symbol ISO 7000-6334A (2015-06) (see Symbol 13 of Table C.1) for RESPONSIBILITY ACCEPTED; or

  2. symbol ISO 7000-6335A (2015-06) (see Symbol 16 of Table C.1) for RESPONSIBILITY REJECTED.

Means shall be provided for the OPERATOR to terminate RESPONSIBILITY ACCEPTED or RESPONSIBILITY REJECTED while the related ALARM CONDITION is active. Initiating RESPONSIBILITY REJECTED may be used to terminate RESPONSIBILITY ACCEPTED. Initiating RESPONSIBILITY ACCEPTED may be used to terminate RESPONSIBILITY REJECTED.

In a CDAS, RESPONSIBILITY ACCEPTED may initiate an ALARM SIGNAL inactivation state.

NOTE RESPONSIBILITY ACCEPTED is a different function than an ALARM SIGNAL inactivation state.

In a CDAS, the INTEGRATOR shall have means to accept OPERATOR responses from the COMMUNICATOR.

In a CDAS, the SOURCE may receive OPERATOR responses from the INTEGRATOR.

1:C.1.5.2.3.2 IEC 60601-1-8:2020, Subclause 6.11.2.4 – CDAS

The terms RESPONSIBILITY ACCEPTED, RESPONSIBILITY REJECTED, and RESPONSIBILITY UNDEFINED are new to this document. They are most often applicable to a DISTRIBUTED ALARM SYSTEM for use in an intensive care setting or a hospital ward setting, in which each OPERATOR has a COMMUNICATOR (example: pocket pager or phone) that provides an ALARM CONDITION to a specific OPERATOR. If the DISTRIBUTED ALARM SYSTEM presents an ALARM CONDITION to a specific OPERATOR, then there can be three possibilities:

  • the specific OPERATOR accepts responsibility for the ALARM CONDITION, and the state RESPONSIBILITY ACCEPTED becomes true;

  • the specific OPERATOR is busy and therefore rejects responsibility, the state RESPONSIBILITY REJECTED becomes true, and the DISTRIBUTED ALARM SYSTEM redirects the ALARM CONDITION to a different COMMUNICATOR, hence OPERATOR;

  • the OPERATOR does not respond to the ALARM SIGNAL within the timeframe established by the RESPONSIBLE ORGANIZATION in the INTEGRATOR, the state RESPONSIBILITY UNDEFINED becomes true, and the INTEGRATOR redirects the ALARM CONDITION to a different COMMUNICATOR, hence OPERATOR in this instance also.

A similar configuration might be provided for other DISTRIBUTED ALARM SYSTEMS, for instance, from a bedside monitor to a different bedside monitor, or from a beside monitor to a central station.

Care is needed in the design of a CDAS when there is a non-homogenous set of SOURCES. The logic (REDIRECTION and ESCALATION) behind the processing of RESPONSIBILITY UNDEFINED can become very complex and needs to take into account how each SOURCE responds to the resulting states. These complex systems can inadvertently cause ALARM FLOOD or ‘lost’ ALARM CONDITIONS (i.e., no assigned COMMUNICATOR).

Such a configuration would not be expected in ME EQUIPMENT without a DISTRIBUTED ALARM SYSTEM. For example, an anaesthesia workstation, for which an OPERATOR is normally present during all PATIENT care, would not be expected to provide these functions.

1:C.2 Use Case Feature 1: Synchronized Time Across Devices (STAD)

1:C.2.1 Narrative

Nurse Jean attaches a ventilator to the medical device network in the ICU. It automatically obtains the correct time.

1:C.2.2 Benefits

Automatically acquiring the time saves the user from spending time entering the time into the device. It also guarantees that the correct time will be entered. It is also important for all devices to have a consistent time since the data being exported to consuming devices and systems will use the time stamps from the device to mark the time that the clinical data was acquired. Since this is part of the clinical record, accuracy is very important.

1:C.2.3 Technical View

vol1 diagram use case stad tech view
Figure 1:C.2.3-1. Synchronized Time Across Devices (STAD) — Technical View

1:C.2.4 Technical Pre-Conditions

Given All devices communicate using a common MD LAN protocol

And A Time Source (TS) Service is on the MD LAN network

1:C.2.5 Scenarios

1:C.2.5.1 Scenario: STAD 1.1 - Device is connected to the MD LAN network with a Time Source service

Given Device has detected at least one TS Service

When The TS Service is operational

Then The device will synchronize its time with the TS Service

1:C.2.5.1.1 Safety, Effectiveness and Security - Requirements and Considerations
R1520

The Manufacturer of a SOMDS Participant shall include all of the following information in the accompanying documentation:

Notes
The 50ms target accuracy is suitable for highly demanding use cases like real time waveform comparison.
1:C.2.5.2 Scenario: STAD 1.2 - Device is connected to the MD LAN network and a user wants to change the device’s time

Given Device is operational in MD LAN network

When The user attempts to change the time on the device manually

Then The device will disable the ability to change its time manually

1:C.2.5.2.1 Safety, Effectiveness and Security - Requirements and Considerations
R1510

A SOMDS Participant shall not allow manual configuration of its internal clock while the device is operational in an MD LAN network.

Notes
Since manual time adjustments of the device’s internal clock would lead to plausible but still inaccurate timestamps, this requirement also prohibits manual adjustments when the TS Service is not available.
1:C.2.5.3 Scenario: STAD 1.3 - Device is connected to the MD LAN network and cannot connect to a TS Service

Given Device has just connected to the MD LAN network and has not detected any TS Services

When The TS Service is not operational or inaccessible

Then The device will not participate on the MD LAN network until it detects and connects to a TS Service

1:C.2.5.3.1 Safety, Effectiveness and Security - Requirements and Considerations
R1540

When a SOMDS Participant connects to the MD LAN, it shall not execute System Function Contribution (SFC)s until it detects and connects to a TS Service.

Notes
Without a TS Service, there is no way for a SOMDS Participant to ensure that its communication partner has a valid certificate.
1:C.2.5.4 Scenario: STAD 1.4 - Devices are operational in the MD LAN network but cannot access the TS Service

Given Device is operational on the MD LAN network

When The TS Service is no longer operational or otherwise inaccessible

Then The device will rely on its internal clock for time synchronization

And The device will provide the accuracy of its clock in its MDIB

And The device will periodically attempt to reconnect to the TS Service

And The device will notify the user about the fact, that the TS Service cannot be reached

And The device will create a log entry noting the disconnection from the TS Service

And The ability to change the device time manually will remain disabled

Device internal clocks are usually accurate enough to bridge short periods of time when no time-servers are accessible. Manual time synchronization is considered too inaccurate for SDC System Functionality.
By using the device’s clock accuracy, a consumer can decide if received data is accurate enough for its use case. This may cause the consumer to disconnect from the device.
A Manufacturer may decide to limit user notification of technical issues to certain user groups (e.g., biomed).
1:C.2.5.4.1 Safety, Effectiveness and Security - Requirements and Considerations
R1530

If a SOMDS Participant is operational and loses connection to the TS Service, it shall use its internal clock.

Notes
It is likely that a SOMDS Participant needs multiple attempts to connect to a TS service a few times during the day. The system needs to be stable against these kind of short term interruptions.
R1531

For every MDS of a SOMDS Provider, the SOMDS Provider shall provide pm:ClockState/@Accuracy.

R1532

The Manufacturer of a SOMDS Consumer shall consider the risk of providing the SOMDS Consumer's System Function Contribution (SFC) if the accuracy of the device internal clock decreases due to an unreachable TS Service.

R1533

The Manufacturer of a SOMDS Consumer shall consider the risk of providing the SOMDS Consumer's System Function Contribution (SFC) if the accuracy of the SOMDS Provider's clock decreases.

Notes
This goes beyond considering the risk of erroneous timestamps required by the Base PKP Standard, since it forces the Manufacturer of a SOMDS Consumer to define a minimum accuracy acceptable for a System Function Contribution (SFC).

REVIEWER QUESTION:Do we need a requirement, for notifying the biomed in case the TS Service is no longer reachable? Or is the following logging requirement sufficient?

R1534

If a SOMDS Participant cannot reach the TS Service, the SOMDS Participant shall create a log entry.

REVIEWER QUESTION:Do we need a requirement stating this explicitly, or is BPKP TR0916 sufficient, since a TS Service not being available can be considered as a change in the TS Service.

1:C.2.5.5 Scenario: STAD 1.5 - Devices are operational in the MD LAN network but cannot access the TS Service and clock drift is unacceptable

Given The SOMDS Consumer is operational on the MD LAN network

And The TS Service is no longer operational or otherwise inaccessible

When The clock drift of the device internal clock exceeds an internal threshold

Or The timestamps of the received data are no longer accurate enough

Then The device will notify the user that time synchronization is no longer functional, which will limit the availability of SDC System Functionality

And The device will create a log entry noting inaccurate time synchronization

And The device will periodically attempt to reconnect to the MD LAN and TS Service

And Based on a Manufacturer's risk management, the device may be disconnected entirely from the MD LAN network.

It is the SOMDS Consumer's responsibility to decide if timestamps are accurate enough to execute its System Function Contribution (SFC).
1:C.2.5.5.1 Safety, Effectiveness and Security - Requirements and Considerations
R1500

The Manufacturer of a SOMDS Participant shall consider the risk of workflow interruption due to misaligned clocks.

Notes
Clocks of SOMDS Participants run apart due to lack of synchronization with NTP servers, different clock drifts or cyberattacks.
This requirement supplements RR1162 in [IEEE 11073-10700:2022]: The MANUFACTURER of an SDC BASE CONSUMER SHALL consider the RISKs resulting from erroneous timestamps.

1:C.3 Use Case Feature 2: Standalone ICU Dashboard Single Patient (SICDsp)

1:C.3.1 Narrative

Dr. Reich is in one of her patient’s ICU room checking on their status. She can view previous radiology results, electrosurgical equipment settings, patient readings such as HR, Blood Pressure, SpO2 and associated waveforms integrated on his real-time ‘Dashboard’ display. The dashboard display can display visual alarms but does not sound alerts or provide any remote-control capabilities. (This display can be considered an xDISsp as described in Appendix 1:C.1.5.1.)

1:C.3.2 Benefits

The concept of a 'dashboard display' supports the display of data in various locations in a care facility with reduced functionality and therefore reduced risk. By removing the requirement that the device annunciate alerts and support remote control the potential types of users is expanded improving access to the patient’s data and status.

1:C.3.3 Technical View

vol1 diagram use case sicdsp tech view
Figure 1:C.3.3-1. Standalone ICU Dashboard Single Patient (SICDsp) — Technical View

1:C.3.4 Technical Pre-Conditions

Given All devices communicate using a common MD LAN protocol

And At least one ICU Dashboard display

And Devices in the room have already been assigned to the Dashboard

1:C.3.5 Scenarios

1:C.3.5.1 Scenario: SICDsp 2.1 - Devices are Accessible to the Dashboard

Given Dashboard has detected at least one assigned accessible ICU device

When the ICU devices are communicating on the MD LAN

Then the Dashboard will display parameter, waveform, alarm, setting, imagine, etc. information from all assigned accessible devices

1:C.3.5.2 Scenario: SICDsp 2.2 - ICU Devices are Inaccessible to the Dashboard

Given Dashboard cannot detect any assigned accessible ICU devices

Then the Dashboard will display an error message

1:C.3.5.3 Scenario: SICDsp 2.3 - One or more ICU devices become Inaccessible to the Dashboard

Given Dashboard cannot detect a previously detected assigned ICU device

Then the Dashboard will display an error message

1:C.4 Use Case Feature 3: Standalone ICU Dashboard Multiple Patient (SICDmp)

1:C.4.1 Narrative

Dr. Presky is in the ICU evaluating a trauma patient from a remote location in the ICU. The dashboard allows access to multiple patients, so he first needs to select the patient of interest. This can be done by location or by patient name (if available).

He can view previous radiology results, electrosurgical equipment settings, patient readings such as HR, Blood Pressure, SpO2 and associated waveforms integrated on his real-time ‘Dashboard’ display. The dashboard display can display visual alarms but does not sound alerts or provide any remote-control capabilities. (This display can be considered an xDISmp as described in Appendix 1:C.1.5.1.)

1:C.4.2 Benefits

The concept of a 'dashboard display' supports the display of data in various locations in a care facility with reduced functionality and therefore reduced risk. By removing the requirement that the device annunciate alerts and support remote control the potential types of users is expanded improving access to multiple patient’s data and status.

1:C.4.3 Technical View

vol1 diagram use case sicdmp tech view
Figure 1:C.4.3-1. Standalone ICU Dashboard Multiple Patient (SICDmp) — Technical View

1:C.4.4 Technical Pre-Conditions

Given All devices communicate using a common MD LAN protocol

And At least one ICU Dashboard display

And Devices from specific ICU rooms have been assigned to the Dashboard

1:C.4.5 Scenarios

1:C.4.5.1 Scenario: SICDmp 3.1 - ICU Devices are Accessible to the Dashboard

Given Dashboard has detected at least one assigned accessible ICU device

When the ICU Devices are communicating on the MD LAN

Then the Dashboard will display parameter, waveform, setting, alarm, imaging, etc. information from those devices (based on configuration)

1:C.4.5.2 Scenario: SICDmp 3.2 - ICU Devices are Inaccessible to the Dashboard

Given Dashboard cannot detect any assigned accessible ICU devices

Then the Dashboard will display an error message

1:C.4.5.3 Scenario: SICDmp 3.3 - One or more ICU Devices are Inaccessible to the Dashboard

Given Dashboard cannot detect any previously assigned accessible ICU devices

Then the Dashboard will display an error message

1:C.5 Use Case Feature 4: Device Data to Enterprise Systems (DDES)

1:C.5.1 Narrative

Mercy Hospital is in the middle of a new EHR (Epic, Cerner, etc.) rollout. Joe Furst is responsible for integrating data from their ICU devices (patient monitors, ventilators, infusion devices, etc.) with the new EHR. Once they are done, the data from the devices will be reviewed/validated by the ICU clinicians and then automatically entered into the patient’s clinical record.

1:C.5.2 Benefits

Automatically feeding patient data from the medical devices to medical record applications reduces the documentation burden on the clinicians, improves the accuracy of the medical record and enables 'real-time' analysis of the data which can be used to generate (potentially AI based) smart alerts to the clinical staff.

1:C.5.3 Technical View

vol1 diagram use case ddes tech view
Figure 1:C.5.3-1. Device Data to Enterprise Systems (DDES) — Technical View

1:C.5.4 Technical Pre-Conditions

Given All devices communicate using a common MD LAN protocol

And There is at least one Data Gateway (DGW) Service

And All devices report either a device label and/or location

And A DGW Service is associated with a specific set of device labels, and/or location(s) (i.e., devices in scope)

1:C.5.5 Scenarios

1:C.5.5.1 Scenario: DDES 4.1 - New in scope device is connected to network with DGW service

Given The DGW Service has detected a new in scope device

When The DGW Service is operational

Then The DGW Service will connect to the device and export data to the EHR using the HL7 v2 based IHE DEV DOR actor of the DEV DEC Profile

1:C.5.5.2 Scenario: DDES 4.2 - Data Gateway Service is connected to the EHR

Given The DGW Service is exporting data to the EHR

Then The DGW Service will comply with all IHE DEV / PCD DEC Profile DOR actor functional and test requirements

1:C.5.5.3 Scenario: DDES 4.3 - Data Gateway Service has a failure

Given The DGW Service was connected to in scope devices and to an Enterprise system and fails

Then The DGW Service will backfill its data store and then backfill to the EHR when it recovers from its failure

1:C.5.5.4 Scenario: DDES 4.4 - Data Gateway Service connection to the Enterprise System fails

Given The Enterprise System stops receiving data from the DGW Service

When There is a communications failure between the DGW Service and the Enterprise System

Then The DGW Service will backfill missed data to the Enterprise System when communications resumes

1:C.6 Use Case Feature 5: Alerts to Clinician Notification Systems (ACNS)

1:C.6.1 Narrative

Bonjour Hospital is in the process of installing a nurse alert notification system which will communicate alerts from the ICU devices (patient monitors, ventilators, infusion devices, etc.) directly to nurse devices such as pagers or smartphones. Bobby Thornton is responsible for integrating data from their ICU devices with the alert notification system. Once they are done, the alerts from the devices will be forwarded by the gateway to the nurse devices for viewing in a timely manner.

1:C.6.2 Benefits

The ability of the system to share alert events directly with the responsible nurse allows that nurse to be aware of issues with the patient without being next to or near the patient. It is also the first step in implementing a Quiet Hospital or Silent Hospital approach where alerts are not signaled at the patient bedside thereby reducing the amount of noise that the patient is subjected to and improving their ability to recuperate.

1:C.6.3 Technical View

vol1 diagram use case acns tech view
Figure 1:C.6.3-1. Alerts to Clinician Notification Systems (ACNS) — Technical View

1:C.6.4 Technical Pre-Conditions

Given All devices communicate using a common MD LAN protocol

And At least one Alert Gateway (AGW) Service on the MD LAN network

And At least one Clinical Notification System is connected to the AGW Service

And All devices report either a device label and/or location and/or patient ID

And The AGW Service is associated with a specific set of device labels, and/or location(s) (Scope)

1:C.6.5 Scenarios

1:C.6.5.1 Scenario: ACNS 5.1 - New device is connected to network with AGW service

Given the AGW Service has detected a new device in its scope

When the AGW Service is operational

Then the AGW Service will connect to the device and communicate alerts to the Clinician Notification System

1:C.6.5.2 Scenario: ACNS 5.2 - The AGW service loses connectivity with the ICU devices

Given the AGW Service no longer communicates with ICU devices in its scope

When There is a communications failure

Then the AGW Service will notify the Clinician Notification System of the failure

Then when the AGW Service regains communication with the devices it will resume reporting active alerts to the Clinician Notification System

1:C.6.5.3 Scenario: ACNS 5.3 - The AGW service fails

Given the AGW Service fails

Then the Clinician Notification System will detect a loss of communications with the AGW Service

Then when the AGW Service recovers it will resume reporting active alerts to the Clinician Notification System

1:C.6.5.4 Scenario: ACNS 5.4 - The Clinician Notification System loses connectivity with the AGW

Given the Clinician Notification System can no longer communicate with the AGW Service

Then the Clinician Notification System will detect a loss of communications with the AGW Service

Then when connectivity recovers, the Clinician Notification System will resume reporting active alerts

1:C.7 Use Case Feature 6: Alerts to Alert Recording Systems (AARS)

1:C.7.1 Narrative

Mumbai General is in the process of installing an IT system which will capture alerts from their ICU devices (patient monitors, ventilators, infusion devices, etc.) for the purposes of occasional review by physicians and post-discharge analysis. (Other related use cases could include EHR capture of alerts or alert analysis).

1:C.7.2 Benefits

The ability to review alerts allows clinicians to track the condition of a patient over a longer time span. For example to see whether a medication is reducing the occurrence of specific events such as ventricular beats or tachycardia events.

1:C.7.3 Technical View

vol1 diagram use case aars tech view
Figure 1:C.7.3-1. Alerts to Alert Recording Systems (AARS) — Technical View

1:C.7.4 Technical Pre-Conditions

Given All devices communicate using a common MD LAN protocol

And At least one Alert Gateway (AGW) Service on the MD LAN

And At least one Alert Recording System is connected to the Alert Gateway (AGW) Service

And All devices report either a device label and/or location and/or patient ID

And The AGW Service is associated with a specific set of device labels, and/or location(s)

1:C.7.5 Scenarios

1:C.7.5.1 Scenario: AARS 6.1 - New device is connected to network with AGW service

Given the AGW Service has detected a new device in its scope

When the AGW Service is operational

Then the AGW Service will connect to the device and communicate alerts to the Alert Recording System

1:C.7.5.2 Scenario: AARS 6.2 - The AGW service loses connectivity with the ICU devices

Given the AGW Service no longer communicates with ICU devices in its scope

When There is a communications failure

Then the AGW will notify the Alert Recording System of the failure

Then when the AGW regains communication with the devices it will resume reporting active alerts to the Alert Recording System and attempt to backfill any missing alerts

1:C.7.5.3 Scenario: AARS 6.3 - The AGW service fails

Given the AGW fails

Then the Alert Recording System will detect a loss of communications with the AGW

Then when the AGW Service recovers it will resume reporting active alerts to the Alert Recording System and attempt to backfill any missing alerts

1:C.7.5.4 Scenario: AARS 6.4 - The Alert Recording System loses connectivity with the AGW

Given the Alert Recording System can no longer communicate with the AGW

Then the Alert Recording System will detect a loss of communications with the AGW Service

Then when the AGW Service regains communication with the Alert Recording System it will resume reporting active alerts to the Alert Recording System and backfill any missing alerts.

Volume 2 — Transactions

2:3 Transactions

2:3.23 Announce Network Presence [DEV-23]

2:3.23.1 Scope

Notify all SOMDS Consumers that a SOMDS Provider is connected to the network and ready to exchange messages with other SOMDS Participants.

2:3.23.2 Actor Roles

Table 2:3.23.2-1. Actor Roles [DEV-23]
Actor Roles

SOMDS Provider

Announces its presence by multicasting Hello messages to all listening systems.

SOMDS Consumer

Listens for Hello messages to identify any SOMDS Providers that it may exchange messages with and further retrieve a SOMDS Provider's service capabilities.

2:3.23.3 Referenced Standards

2:3.23.4 Messages

puml dev 23 sequence
Figure 2:3.23.4-1. Message Interaction Diagram [DEV-23]
2:3.23.4.1 Hello Message

BICEPS specifies an implicit discovery protocol for allowing SOMDS Consumers to receive a notification when a SOMDS Provider is ready to exchange messages with other SOMDS Consumers. The corresponding message for this transaction is called Hello.

Note that the Hello message described in this clause is a generic/abstract concept that can be implemented differently. It should not be confused with actual transport message specifications like, e.g., the WS-Discovery Hello message as described in Appendix 2:A.2.1.

The Hello is a multicast message that is sent from each SOMDS Provider to all listening SOMDS Consumers (zero to many). Limited but sufficient information is provided with the message to enable SOMDS Consumers to determine if they are interested in connecting with the SOMDS Provider discovering additional information.

2:3.23.4.1.1 Trigger Events

This message is sent

  1. whenever a SOMDS Provider joins an MD LAN,

  2. when a SOMDS Provider returns to normal on-line operation after having indicated temporary suspension of message exchanges, or

  3. when a SOMDS Provider changes its Discovery Scope.

2:3.23.4.1.2 Message Semantics
Provider UID

The SOMDS Provider UID.

Discovery Scope

The Discovery Scope of the SOMDS Provider.

2:3.23.4.1.3 Expected Actions

When a SOMDS Provider sends this message, there is no expected or required responses. This is due to the fact that either there are no SOMDS Consumers listening for announcement messages, or the information in the message (e.g., Discovery Type) is not of interest to any receiving SOMDS Consumers.

2:3.23.5 Safety, Effectiveness and Security - Requirements and Considerations

2:3.23.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

2:3.23.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.23.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.23.5.4 Security Requirements & Considerations

This transaction is intended to execute over UNSECURED transmission channels.

Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.

Appropriate security risk management is performed in order to ensure that no unintended information is disclosed during UNSECURED message exchange.

2:3.24 Discover Network Topology [DEV-24]

2:3.24.1 Scope

Discover and resolve all available SOMDS Providers that a SOMDS Consumer is potentially interested in.

2:3.24.2 Actor Roles

Table 2:3.24.2-1. Actor Roles [DEV-24]
Actor Roles

SOMDS Consumer

Initiates communication by sending Probe or Resolve messages to SOMDS Providers. Then listens for ProbeMatch and ResolveMatch messages to discover those SOMDS Providers that it intends to exchange messages with and further retrieves the SOMDS Provider's service capabilities.

SOMDS Provider

Listens for Probe and Resolve messages, which it responds to with ProbeMatch or ResolveMatch messages, respectively.

2:3.24.3 Referenced Standards

2:3.24.4 Messages

puml dev 24 sequence
Figure 2:3.24.4-1. Message Interaction Diagram [DEV-24]
2:3.24.4.1 Probe Message

BICEPS specifies an explicit discovery protocol for allowing SOMDS Consumers to discover all SOMDS Providers that are ready to exchange messages with SOMDS Consumers. The corresponding message to seek SOMDS Provider based on filter criteria is called Probe.

Note that the Probe message described in this clause is a generic/abstract concept that can be implemented differently. It should not be confused with actual transport message specifications like, e.g., the WS-Discovery Probe message as described in Appendix 2:A.2.2.

If a specific SOMDS Provider UID is unknown to a SOMDS Consumer, the SOMDS Consumer can send a Probe multicast message to all listening SOMDS Providers. Limited but sufficient information is provided with the message to enable SOMDS Providers to determine if they match the Discovery Scope requested by the SOMDS Consumer.

2:3.24.4.1.1 Trigger Events

The Probe message is sent whenever a SOMDS Consumer joins an MD LAN and is ready to exchange messages with SOMDS Providers.

2:3.24.4.1.2 Message Semantics
Discovery Scope

A Discovery Scope to filter against.

2:3.24.4.1.3 Expected Actions

When a SOMDS Consumer sends this message, every receiving SOMDS Provider that matches the requested Discovery Scope responds with a ProbeMatch message.

2:3.24.4.2 ProbeMatch Message

The ProbeMatch message is sent as part of the BICEPS explicit discovery protocol in response to an incoming Probe message.

Note that the ProbeMatch message described in this clause is a generic/abstract concept that can be implemented differently. It should not be confused with actual transport message specifications like, e.g., the WS-Discovery ProbeMatch message as described in Appendix 2:A.2.2.

The ProbeMatch message is a uni-cast message that is sent by a SOMDS Provider when an incoming Probe message contains a Discovery Scope that matches the SOMDS Provider's Discovery Scope. Limited but sufficient information is provided with the message to enable SOMDS Consumers to determine a matching SOMDS Provider's Provider UID and Transport Address.

2:3.24.4.2.1 Trigger Events

The ProbeMatch message is sent whenever a SOMDS Provider receives a Probe message that contains a Discovery Scope that matches the SOMDS Provider's Discovery Scope.

2:3.24.4.2.2 Message Semantics
Provider UID

The SOMDS Provider UID.

Transport Address

The Transport Address under which the SOMDS Provider can receive secured messages.

2:3.24.4.2.3 Expected Actions

The SOMDS Consumer that receives a ProbeMatch message can use the Transport Address to exchange secured messages with the SOMDS Provider from which it received the ProbeMatch message.

2:3.24.4.3 Resolve Message

BICEPS specifies an explicit discovery protocol for allowing SOMDS Consumers to discover all SOMDS Providers that are ready to exchange messages with SOMDS Consumers. The corresponding message to seek SOMDS Providers based on a unique identifier is called Resolve.

Note that the Resolve message described in this clause is a generic/abstract concept that can be implemented differently. It should not be confused with actual transport message specifications like, e.g., the WS-Discovery Resolve message as described in Appendix 2:A.2.2.

If a specific SOMDS Provider UID is known to a SOMDS Consumer, the SOMDS Consumer can send a Resolve multicast message to all listening SOMDS Providers. Limited but sufficient information is provided with the message to enable SOMDS Providers to determine if they match the SOMDS Provider UID requested by the SOMDS Consumer.

2:3.24.4.3.1 Trigger Events

The Resolve message is sent

  1. whenever a SOMDS Consumer joins an MD LAN and is ready to exchange messages with SOMDS Providers or

  2. when a SOMDS Consumer runs in a mode where it periodically checks for availability of SOMDS Providers matching a specific SOMDS Provider UID.

2:3.24.4.3.2 Message Semantics
Provider UID

The SOMDS Provider UID to resolve.

2:3.24.4.3.3 Expected Actions

When a SOMDS Consumer sends this message, every receiving SOMDS Provider that matches the requested SOMDS Provider UID responds with a ResolveMatch message.

2:3.24.4.4 ResolveMatch Message

The ResolveMatch message is sent as part of the BICEPS explicit discovery protocol in response to an incoming Resolve message.

Note that the ResolveMatch message described in this clause is a generic/abstract concept that can be implemented differently. It should not be confused with actual transport message specifications like, e.g., the WS-Discovery ResolveMatch message as described in Appendix 2:A.2.2.

The ResolveMatch message is a uni-cast message that is sent by a SOMDS Provider when an incoming Resolve message contains a Provider UID that matches the SOMDS Provider's SOMDS Provider UID. Limited but sufficient information is provided with the message to enable SOMDS Consumers to determine a matching SOMDS Provider's Transport Address.

2:3.24.4.4.1 Trigger Events

The ResolveMatch message is sent whenever a SOMDS Provider receives a Resolve message that contains a Provider UID that is equal to the SOMDS Provider's SOMDS Provider UID.

2:3.24.4.4.2 Message Semantics
Provider UID

The SOMDS Provider UID.

Transport Address

The Transport Address under which the SOMDS Provider can receive secured messages.

2:3.24.4.4.3 Expected Actions

The SOMDS Consumer that receives a ResolveMatch message can use the Transport Address to exchange secured messages with the SOMDS Provider from which it received the ResolveMatch message.

2:3.24.5 Safety, Effectiveness and Security - Requirements and Considerations

2:3.24.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

2:3.24.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.24.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.24.5.4 Security Requirements & Considerations

This transaction is intended to execute over UNSECURED transmission channels.

Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.

Appropriate security risk management is performed in order to ensure that no unintended information is disclosed during UNSECURED message exchange.

2:3.25 Discover BICEPS Services [DEV-25]

2:3.25.1 Scope

Exchange resources metadata between a SOMDS Provider and a SOMDS Consumer.

2:3.25.2 Actor Roles

Table 2:3.25.2-1. Actor Roles [DEV-25]
Actor Roles

SOMDS Consumer

Asks for the resource representation of the SOMDS Provider via the GetMetadata message.

SOMDS Provider

Sends its resource representation to the SOMDS Consumer via the GetMetadataResponse message.

2:3.25.3 Referenced Standards

2:3.25.4 Messages

puml dev 25 sequence
Figure 2:3.25.4-1. Message Interaction Diagram [DEV-25]
2:3.25.4.1 GetMetadata Message

The GetMetadata message is used by a SOMDS Consumer to request the resource representation data of a SOMDS Provider.

2:3.25.4.1.1 Trigger Events

This message is sent when a SOMDS Consumer has discovered a Transport Address for a SOMDS Provider.

2:3.25.4.1.2 Expected Actions

When a SOMDS Consumer sends this message, the GetMetadataResponse message is expected as a response.

2:3.25.4.2 GetMetadataResponse Message

The GetMetadataResponse message is sent in response to an incoming GetMetadata message.

2:3.25.4.2.1 Trigger Events

The GetMetadataResponse message is sent whenever a SOMDS Provider receives a GetMetadata message.

2:3.25.4.2.2 Message Semantics
BICEPS Services

Collection of BICEPS services the SOMDS Provider offers, including but not limited to one or multiple of the following BICEPS services ([ISO/IEEE 11073-10207:2017] Section 7.3 Service Model):

  • GET SERVICE (mandatory)

  • SET SERVICE

  • DESCRIPTION EVENT SERVICE

  • STATE EVENT SERVICE

  • CONTEXT SERVICE

  • WAVEFORM SERVICE

There is currently no mandatory support for provision of the LOCALIZATION SERVICE, CONTAINMENT TREE SERVICE and ARCHIVE SERVICE.
Device Metadata

Expresses SOMDS Provider characteristics that typically vary from one SOMDS Provider to another of the same kind, for example:

  • Friendly name

  • Firmware version

  • Serial number

Model Metadata

Expresses SOMDS Provider characteristics that are typically fixed across all SOMDS Providers of the same model by their Manufacturer, for example:

2:3.25.4.2.3 Expected Actions

When a SOMDS Provider sends this message, there is no expected or required response.

2:3.25.5 Safety, Effectiveness and Security - Requirements and Considerations

2:3.25.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

2:3.25.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.25.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.25.5.4 Security Requirements & Considerations

This transaction is intended to execute over SECURED transmission channels.

Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.

Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.

2:3.27 Manage BICEPS Subscription [DEV-27]

2:3.27.1 Scope

Establish a publish-subscribe session between a SOMDS Provider, acting as the event source, and a SOMDS Consumer, acting as the event sink.

2:3.27.2 Actor Roles

Table 2:3.27.2-1. Actor Roles [DEV-27]
Actor Roles

SOMDS Consumer

Initiates communication by first subscribing to a SOMDS Provider by sending a Subscribe message. While the subscription is running, the subscription is kept alive by sending Renew messages and receiving Notification messages.

Finally, the SOMDS Consumer unsubscribes from a SOMDS Provider by sending an Unsubscribe message.

SOMDS Provider

Listens for Subscribe, Renew and Unsubscribe messages, which it responds to with SubscribeResponse, RenewResponse or UnsubscribeResponse messages respectively.

While a subscription is running, the SOMDS Provider delivers Notification messages.

When at some point the subscription has to be ended, the SOMDS Provider sends a SubscriptionEnd message.

2:3.27.3 Referenced Standards

2:3.27.4 Messages

puml dev 27 sequence
Figure 2:3.27.4-1. Message Interaction Diagram [DEV-27]
Transaction [DEV-27] supports a general Section 2:3.27.4.3 message. Specialized notification messages are detailed in Section 2:3.28 and Section 2:3.29, based on payload content and trigger events.
2:3.27.4.1 Subscribe Message

The Subscribe message is sent as part of the BICEPS publish-subscribe and streaming message exchange for allowing SOMDS Consumers to subscribe to data changes of SOMDS Providers.

2:3.27.4.1.1 Trigger Events

The Subscribe message is sent whenever a SOMDS Consumer intends to get notified on certain changes of a SOMDS Provider comprising

  • publish-subscribe message exchange and

  • stream message exchange.

2:3.27.4.1.2 Message Semantics
Filter

A filter to subscribe to a certain set of data items, including but not limited to one or multiple of the following:

Expiration Time

A time requested for subscription expiration.

2:3.27.4.1.3 Expected Actions

When a SOMDS Consumer sends this message, the receiving SOMDS Provider responds with a SubscribeResponse message.

2:3.27.4.2 SubscribeResponse Message

The SubscribeResponse message is sent as part of the BICEPS publish-subscribe and streaming message exchange in response to a Subscribe message to confirm a subscription.

2:3.27.4.2.1 Trigger Events

The SubscribeResponse message is sent whenever a SOMDS Provider receives a Subscribe message.

2:3.27.4.2.2 Message Semantics
Subscription Manager

Dedicated instance that manages the subscription, i.e., allows for a SOMDS Consumer to renew or cancel the subscription.

Expiration Time

Actual expiration time, which does not necessarily equal the requested expiration time.

2:3.27.4.2.3 Expected Actions

The SOMDS Consumer that receives a SubscribeResponse message can use the Subscription Manager to renew the subscription shortly before the Expiration Time exceeds or cancel the subscription if it is no longer interested in updates.

Once received, the SOMDS Consumer listens for Notification messages.

2:3.27.4.3 Notification Message

The Notification message contains updated data and is delivered by a SOMDS Provider to subscribed SOMDS Consumers.

The data items conveyed in Notification messages depend on the Filter that was requested as part of the Subscribe message.

2:3.27.4.3.1 Trigger Events

A Notification message is sent whenever a SOMDS Provider detects a change to its internal representation that is intended to be communicated to SOMDS Consumers. The SOMDS Provider sends a Notification message to a SOMDS Consumer if and only if a matching Filter has been requested by the SOMDS Consumer.

2:3.27.4.3.2 Message Semantics
Payload

Payload specific to the Filter that was subscribed by the SOMDS Consumer that receives the Notification message.

2:3.27.4.3.3 Expected Actions

When a SOMDS Provider sends this message, there is no expected or required responses.

2:3.27.4.4 Renew Message

The Renew message is sent as part of the BICEPS publish-subscribe and streaming message exchange to renew a subscription when it is about to expire.

2:3.27.4.4.1 Trigger Events

The Renew message is sent whenever a subscription is about to expire according to the subscribe response Expiration Time or renew response Expiration Time respectively.

2:3.27.4.4.2 Message Semantics
Subscription Manager

Dedicated instance that manages the subscription, i.e., allows for a SOMDS Consumer to renew or cancel the subscription.

Expiration Time

A new time requested for subscription expiration.

2:3.27.4.4.3 Expected Actions

When a SOMDS Consumer sends this message, the receiving SOMDS Provider responds with a RenewResponse message.

2:3.27.4.5 RenewResponse Message

The RenewResponse message is sent as part of the BICEPS publish-subscribe and streaming message exchange in response to a Renew message to confirm renewal of a subscription.

2:3.27.4.5.1 Trigger Events

The RenewResponse message is sent whenever a SOMDS Provider receives a Renew message.

2:3.27.4.5.2 Message Semantics
Expiration Time

Actual new expiration time, which does not necessarily equal the requested expiration time.

2:3.27.4.5.3 Expected Actions

Once received, the SOMDS Consumer keeps listening for Notification messages.

2:3.27.4.6 Unsubscribe Message

The Unsubscribe message is sent as part of the BICEPS publish-subscribe and streaming message exchange to unsubscribe from a running subscription.

2:3.27.4.6.1 Trigger Events

The Unsubscribe message is sent by a SOMDS Consumer whenever it intends to end a running subscription of a SOMDS Provider.

2:3.27.4.6.2 Message Semantics
Subscription Manager

The subscription manager for which a subscription is requested to be unsubscribed.

2:3.27.4.6.3 Expected Actions

When a SOMDS Consumer sends this message, the receiving SOMDS Provider responds with a UnsubscribeResponse message.

2:3.27.4.7 UnsubscribeResponse Message

The UnsubscribeResponse message is sent as part of the BICEPS publish-subscribe and streaming message exchange in response to a Unsubscribe message to confirm the termination of the subscription.

2:3.27.4.7.1 Trigger Events

The UnsubscribeResponse message is sent whenever a SOMDS Provider receives a Unsubscribe message.

2:3.27.4.7.2 Message Semantics

The UnsubscribeResponse message does not contain any further semantics.

2:3.27.4.7.3 Expected Actions

Once received, the SOMDS Consumer cannot expect any further incoming Notification messages.

2:3.27.4.8 SubscriptionEnd Message

The SubscriptionEnd is delivered by a SOMDS Provider to signify the expected or unexpected end of a subscription, e.g., due to a shutdown of the SOMDS Provider.

2:3.27.4.8.1 Trigger Events

A SubscriptionEnd message is sent whenever a SOMDS Provider intends to communicate the end of a subscription.

2:3.27.4.8.2 Message Semantics
Subscription Manager

The subscription manager that was closed.

Status

Status that signifies the general reason for the subscription end.

2:3.27.4.8.3 Expected Actions

Once received, the SOMDS Consumer cannot expect any further incoming Notification messages.

2:3.27.5 Safety, Effectiveness and Security - Requirements and Considerations

2:3.27.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

2:3.27.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.27.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.27.5.4 Security Requirements & Considerations

This transaction is intended to execute over SECURED transmission channels.

Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.

Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.

2:3.28 Notify Change in System Context and Capabilities [DEV-28]

2:3.28.1 Scope

Notify a SOMDS Consumer about changes in system context and capabilities of a SOMDS Provider.

2:3.28.2 Actor Roles

Table 2:3.28.2-1. Actor Roles [DEV-28]
Actor Roles

SOMDS Consumer

Listens for a Notification message to retrieve context updates.

SOMDS Provider

While a subscription is running, the SOMDS Provider delivers Notification messages.

2:3.28.3 Referenced Standards

2:3.28.4 Messages

puml dev 28 sequence
Figure 2:3.28.4-1. Message Interaction Diagram [DEV-28]
Transaction [DEV-28] supports a specialized instance of the general Section 2:3.27.4.3 message, based on payload content and trigger events.
2:3.28.4.1 Notification Message

The Notification message contains updated context data and is delivered by a SOMDS Provider to subscribed SOMDS Consumers.

2:3.28.4.1.1 Trigger Events

The Notification message is sent whenever a context of a SOMDS Provider is updated and a SOMDS Consumer is subscribed to context reports of a SOMDS Provider.

2:3.28.4.1.2 Message Semantics
EpisodicContextReport

A change report that contains context information.

2:3.28.4.1.3 Expected Actions

When a SOMDS Provider sends this message, there is no expected action or required responses.

2:3.28.5 Safety, Effectiveness and Security - Requirements and Considerations

2:3.28.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

2:3.28.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.28.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.28.5.4 Security Requirements & Considerations

This transaction is intended to execute over SECURED transmission channels.

Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.

Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.

2:3.29 Publish BICEPS Update Reports [DEV-29]

2:3.29.1 Scope

Notify a SOMDS Consumer about changes in the alert, metric and component reports and in the waveform stream of a SOMDS Provider.

2:3.29.2 Actor Roles

Table 2:3.29.2-1. Actor Roles [DEV-29]
Actor Roles

SOMDS Consumer

Listens for a Notification message to retrieve update reports.

SOMDS Provider

While a subscription is running, the SOMDS Provider delivers Notification messages.

2:3.29.3 Referenced Standards

2:3.29.4 Messages

puml dev 29 sequence
Figure 2:3.29.4-1. Message Interaction Diagram [DEV-29]
Transaction [DEV-29] supports a specialized instance of the general Section 2:3.27.4.3 message, based on payload content and trigger events.
2:3.29.4.1 Notification Message

The Notification messages contain updated reports and is delivered by a SOMDS Provider to subscribed SOMDS Consumers.

2:3.29.4.1.1 Trigger Events

The Notification message is sent whenever a report of a SOMDS Provider is updated and a SOMDS Consumer is subscribed to reports of a SOMDS Provider.

2:3.29.4.1.2 Message Semantics
EpisodicAlertReport

A change report that contains updated alert information.

EpisodicMetricReport

A change report that contains updated metric information.

EpisodicComponentReport

A change report that contains updated component information.

WaveformStream

A message to transmit a set of samples of one or more waveforms.

2:3.29.4.1.3 Expected Actions

When a SOMDS Provider sends this message, there is no expected action or required responses.

2:3.29.5 Safety, Effectiveness and Security - Requirements and Considerations

2:3.29.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

2:3.29.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.29.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.29.5.4 Security Requirements & Considerations

This transaction is intended to execute over SECURED transmission channels.

Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.

Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.

2:3.30 Retrieve BICEPS Content [DEV-30]

2:3.30.1 Scope

Retrieve the MDIB of a SOMDS Provider a SOMDS Consumer is interested in.

2:3.30.2 Actor Roles

Table 2:3.30.2-1. Actor Roles [DEV-30]
Actor Roles

SOMDS Consumer

Initiates communication by sending a GetMdib message to a SOMDS Provider. Then listens for a GetMdibResponse message to retrieve the SOMDS Provider's MDIB.

SOMDS Provider

Listens for GetMdib messages, which it responds to with GetMdibResponse messages respectively.

2:3.30.3 Referenced Standards

2:3.30.4 Messages

puml dev 30 sequence
Figure 2:3.30.4-1. Message Interaction Diagram [DEV-30]
2:3.30.4.1 GetMdib Message

The GetMdib message is sent as part of the BICEPS GET SERVICE for allowing SOMDS Consumers to retrieve the description and state of an MDIB from a SOMDS Provider.

2:3.30.4.1.1 Trigger Events

The GetMdib message is sent whenever a SOMDS Consumer wants to retrieve the description and state of an MDIB of a SOMDS Provider.

2:3.30.4.1.2 Message Semantics

The GetMdib message does not contain any further semantics.

2:3.30.4.1.3 Expected Actions

When a SOMDS Consumer sends this message, the receiving SOMDS Provider responds with a GetMdibResponse message.

2:3.30.4.2 GetMdibResponse Message

The GetMdibResponse message is sent as part of the BICEPS GET SERVICE in response to an incoming GetMdib message.

2:3.30.4.2.1 Trigger Events

The GetMdibResponse message is sent whenever a SOMDS Provider receives a GetMdib message.

2:3.30.4.2.2 Message Semantics
MdDescription

The descriptive part of an MDIB.

MdState

The state part of an MDIB. (As the communication is encrypted, this can include ContextStates without violating [ISO/IEEE 11073-10207:2017] R0121.)

2:3.30.4.2.3 Expected Actions

When a SOMDS Provider sends this message, there is no expected or required response.

2:3.30.5 Safety, Effectiveness and Security - Requirements and Considerations

2:3.30.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

2:3.30.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.30.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.30.5.4 Security Requirements & Considerations

This transaction is intended to execute over SECURED transmission channels.

Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.

Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.

2:3.34 Announce Network Departure [DEV-34]

2:3.34.1 Scope

Notify all SOMDS Consumers that a SOMDS Provider is leaving the network.

2:3.34.2 Actor Roles

Table 2:3.34.2-1. Actor Roles [DEV-34]
Actor Roles

SOMDS Provider

Announces its departure by multicasting Bye messages to all listening systems.

SOMDS Consumer

Listens for Bye messages to identify any SOMDS Providers that will leave the Medical Device LAN (MD LAN).

2:3.34.3 Referenced Standards

2:3.34.4 Messages

puml dev 34 sequence
Figure 2:3.34.4-1. Message Interaction Diagram [DEV-34]
2:3.34.4.1 Bye Message

The Bye message is part of the BICEPS implicit discovery protocol for allowing SOMDS Consumers to receive a notification when a SOMDS Provider is leaving the network.

The Bye is a multicast message that is sent from each SOMDS Provider to all listening SOMDS Consumers (zero to many).

2:3.34.4.1.1 Trigger Events

This message is sent whenever a SOMDS Provider leaves a network.

2:3.34.4.1.2 Message Semantics
Provider UID

The SOMDS Provider UID.

2:3.34.4.1.3 Expected Actions

When a SOMDS Provider sends this message, there is no expected or required response.

2:3.34.5 Safety, Effectiveness and Security - Requirements and Considerations

2:3.34.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

2:3.34.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.34.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.34.5.4 Security Requirements & Considerations

This transaction is intended to execute over UNSECURED transmission channels.

Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.

Appropriate security risk management is performed in order to ensure that no unintended information is disclosed during UNSECURED message exchange.

2:3.35 Establish Medical Data Exchange [DEV-35]

2:3.35.1 Scope

Establish the exchange of medical data between a SOMDS Provider and a SOMDS Consumer.

2:3.35.2 Actor Roles

Table 2:3.35.2-1. Actor Roles [DEV-35]

Actor

Roles

SOMDS Consumer

Initiates communication by first subscribing to a SOMDS Provider by sending a Subscribe message.

SOMDS Provider

Listens for Subscribe messages, which it responds to with SubscribeResponse.

2:3.35.3 Referenced Standards

2:3.35.4 Messages

puml dev 35 sequence
Figure 2:3.35.4-1. Message Interaction Diagram [DEV-35]
Transaction [DEV-35] syntactically duplicates [DEV-27] (Section 2:3.27) and [DEV-38] (Section 2:3.38). This a deliberate action as [DEV-35] is expected to receive SES constraints in the future which will require exclusive conformity statements. For the sake of brevity this clause does not duplicate the trigger events, message semantics and expected actions.

2:3.35.5 Safety, Effectiveness and Security - Requirements and Considerations

2:3.35.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

2:3.35.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.35.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.35.5.4 Security Requirements & Considerations

This transaction is intended to execute over SECURED transmission channels.

Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.

Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.

2:3.36 Publish Medical Data [DEV-36]

2:3.36.1 Scope

Publish medical data from a SOMDS Provider to a SOMDS Consumer.

2:3.36.2 Actor Roles

Table 2:3.36.2-1. Actor Roles [DEV-36]
Actor Roles

SOMDS Consumer

Listens for a Notification message to retrieve medical data updates.

SOMDS Provider

While a subscription is running, the SOMDS Provider delivers Notification messages.

2:3.36.3 Referenced Standards

2:3.36.4 Messages

puml dev 36 sequence
Figure 2:3.36.4-1. Message Interaction Diagram [DEV-36]
Transaction [DEV-36] syntactically duplicates [DEV-29] (Section 2:3.29) and [DEV-39] (Section 2:3.39). This a deliberate action as [DEV-36] is expected to receive SES constraints in the future which will require exclusive conformity statements. For the sake of brevity this clause does not duplicate the trigger events, message semantics and expected actions.

2:3.36.5 Safety, Effectiveness and Security - Requirements and Considerations

2:3.36.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

2:3.36.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.36.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.36.5.4 Security Requirements & Considerations

This transaction is intended to execute over SECURED transmission channels.

Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.

Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.

2:3.37 Retrieve Medical Data [DEV-37]

2:3.37.1 Scope

Retrieve medical data from a SOMDS Provider.

2:3.37.2 Actor Roles

Table 2:3.37.2-1. Actor Roles [DEV-37]
Actor Roles

SOMDS Consumer

Initiates communication by sending a GetMdib message to a SOMDS Provider. Then listens for a GetMdibResponse message to retrieve the SOMDS Provider's MDIB.

SOMDS Provider

Listens for GetMdib messages, which it responds to with GetMdibResponse messages respectively.

2:3.37.3 Referenced Standards

2:3.37.4 Messages

puml dev 37 sequence
Figure 2:3.37.4-1. Message Interaction Diagram [DEV-37]

Note that there is no particular get operation for retrieving medical alert status information. Thus, the generic GetMdib/GetMdibResponse mechanisms are described here.

Transaction [DEV-37] syntactically duplicates [DEV-30] (Section 2:3.30). This a deliberate action as [DEV-37] is expected to receive SES constraints in the future which will require exclusive conformity statements. For the sake of brevity this clause does not duplicate the trigger events, message semantics and expected actions.

2:3.37.5 Safety, Effectiveness and Security - Requirements and Considerations

2:3.37.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

2:3.37.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.37.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.37.5.4 Security Requirements & Considerations

This transaction is intended to execute over SECURED transmission channels.

Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.

Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.

2:3.38 Establish Medical Alert Exchange [DEV-38]

2:3.38.1 Scope

Establish the exchange of medical alerts from a SOMDS Provider to a SOMDS Consumer.

2:3.38.2 Actor Roles

Table 2:3.38.2-1. Actor Roles [DEV-38]

Actor

Roles

SOMDS Consumer

Initiates communication by first subscribing to a SOMDS Provider by sending a Subscribe message.

SOMDS Provider

Listens for Subscribe messages, which it responds to with SubscribeResponse.

2:3.38.3 Referenced Standards

2:3.38.4 Messages

puml dev 38 sequence
Figure 2:3.38.4-1. Message Interaction Diagram [DEV-38]
Transaction [DEV-38] syntactically duplicates [DEV-27] (Section 2:3.27) and [DEV-35] (Section 2:3.35). This a deliberate action as [DEV-38] is expected to receive SES constraints in the future which will require exclusive conformity statements. For the sake of brevity this clause does not duplicate the trigger events, message semantics and expected actions.

2:3.38.5 Safety, Effectiveness and Security - Requirements and Considerations

2:3.38.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

2:3.38.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.38.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.38.5.4 Security Requirements & Considerations

This transaction is intended to execute over SECURED transmission channels.

Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.

Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.

2:3.39 Publish Medical Alert Update [DEV-39]

2:3.39.1 Scope

Notify a SOMDS Consumer about changes in the medical alert status of a SOMDS Provider.

2:3.39.2 Actor Roles

Table 2:3.39.2-1. Actor Roles [DEV-39]
Actor Roles

SOMDS Consumer

Listens for a Notification message to retrieve medical alert updates.

SOMDS Provider

While a subscription is running, the SOMDS Provider delivers Notification messages.

2:3.39.3 Referenced Standards

2:3.39.4 Messages

puml dev 39 sequence
Figure 2:3.39.4-1. Message Interaction Diagram [DEV-39]

2:3.39.5 Safety, Effectiveness and Security - Requirements and Considerations

2:3.39.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

2:3.39.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.39.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.39.5.4 Security Requirements & Considerations

This transaction is intended to execute over SECURED transmission channels.

Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.

Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.

2:3.40 Retrieve Medical Alert Status [DEV-40]

2:3.40.1 Scope

Retrieve the medical alert status of a SOMDS Provider.

2:3.40.2 Actor Roles

Table 2:3.40.2-1. Actor Roles [DEV-40]
Actor Roles

SOMDS Consumer

Initiates communication by sending a GetMdib message to a SOMDS Provider. Then listens for a GetMdibResponse message to retrieve the SOMDS Provider's MDIB.

SOMDS Provider

Listens for GetMdib messages, which it responds to with GetMdibResponse messages respectively.

2:3.40.3 Referenced Standards

2:3.40.4 Messages

puml dev 40 sequence
Figure 2:3.40.4-1. Message Interaction Diagram [DEV-40]

Note that there is no particular get operation for retrieving medical alert status information. Thus, the generic GetMdib/GetMdibResponse mechanisms are described here.

Transaction [DEV-40] syntactically duplicates [DEV-30] (Section 2:3.30) and [DEV-37] (Section 2:3.37). This a deliberate action as [DEV-40] is expected to receive SES constraints in the future which will require exclusive conformity statements. For the sake of brevity this clause does not duplicate the trigger events, message semantics and expected actions.

2:3.40.5 Safety, Effectiveness and Security - Requirements and Considerations

2:3.40.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

2:3.40.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.40.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.40.5.4 Security Requirements & Considerations

This transaction is intended to execute over SECURED transmission channels.

Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.

Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.

2:3.46 Update Network Presence [DEV-46]

2:3.46.1 Scope

Provide network presence and absence of SOMDS Provider Actors in a SOMDS network by updating the metadata in a Discovery Proxy Actor.

2:3.46.2 Actor Roles

Table 2:3.46.2-1. Actor Roles [DEV-46]
Actor Roles

Discovery Proxy

Listens for Hello or Bye messages to add or remove SOMDS Provider endpoint metadata to/from its internal database.

SOMDS Provider

When joining a SOMDS, it announces its presence to the Discovery Proxy. When deliberately leaving the SOMDS, it announces its absence to the Discovery Proxy.

2:3.46.3 Referenced Standards

2:3.46.4 Messages

puml dev 46 sequence
Figure 2:3.46.4-1. Message Interaction Diagram [DEV-46]
2:3.46.4.1 Hello Message

BICEPS specifies an implicit discovery protocol for allowing SOMDS Consumers to receive a notification when a SOMDS Provider is ready to exchange messages with other SOMDS Consumers. If a SOMDS Provider uses a Discovery Proxy, network presence is announced to the Discovery Proxy by using the Hello message of this transaction.

2:3.46.4.1.1 Trigger Events

If a Discovery Proxy is known to the SOMDS Provider, this message is sent

  1. whenever a SOMDS Provider joins an MD LAN,

  2. when a SOMDS Provider returns to normal on-line operation after having indicated temporary suspension of message exchanges, or

  3. when a SOMDS Provider changes its Discovery Scope.

2:3.46.4.1.2 Message Semantics
Provider UID

The SOMDS Provider UID.

Discovery Scope

The Discovery Scope of the SOMDS Provider.

2:3.46.4.1.3 Expected Actions

When a SOMDS Provider sends this message, there is no expected or required response. The Discovery Proxy is supposed to internally store the SOMDS Provider's endpoint Provider UID and Discovery Scope in order to make it available to SOMDS Consumers via DEV-47 Retrieve Network Presence (see Section 2:3.47).

2:3.46.4.2 Bye Message

If a SOMDS Provider uses a Discovery Proxy, network absence is announced to the Discovery Proxy by using the Bye message of this transaction.

2:3.46.4.2.1 Trigger Events

If a Discovery Proxy is known to the SOMDS Provider, this message is sent whenever a SOMDS Provider leaves the MD LAN it previously joined via the Hello message.

2:3.46.4.2.2 Message Semantics
Provider UID

The SOMDS Provider UID.

2:3.46.4.2.3 Expected Actions

When a SOMDS Provider sends this message, there is no expected or required response. The Discovery Proxy is supposed to remove the SOMDS Provider's Provider UID and Discovery Scope from its internal database and exposes the removal to SOMDS Consumers via DEV-47 Retrieve Network Presence (see Section 2:3.47).

2:3.46.5 Safety, Effectiveness and Security - Requirements and Considerations

2:3.46.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

2:3.46.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.46.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.46.5.4 Security Requirements & Considerations

This transaction is intended to execute over SECURED transmission channels.

Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.

Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.

2:3.47 Retrieve Network Presence [DEV-47]

2:3.47.1 Scope

Retrieve presence metadata from a Discovery Proxy Actor for a specified set of SOMDS Provider Actors that may be connected to a SOMDS network.

2:3.47.2 Actor Roles

Table 2:3.47.2-1. Actor Roles [DEV-47]
Actor Roles

Discovery Proxy

Forwards Hello and Bye messages received from SOMDS Providers. Responds to incoming Probe and Resolve messages.

SOMDS Consumer

Uses Probe and Resolve messages to seek endpoint metadata. Optionally subscribes to a Discovery Proxy in order to receive Hello and Bye messages.

2:3.47.3 Referenced Standards

2:3.47.4 Messages

puml dev 47 sequence
Figure 2:3.47.4-1. Message Interaction Diagram [DEV-47]
2:3.47.4.1 Hello Message

BICEPS specifies an implicit discovery protocol for allowing SOMDS Consumers to receive a notification when a SOMDS Provider is ready to exchange messages with other SOMDS Consumers. If a SOMDS Consumer uses a Discovery Proxy, network presence is announced to the SOMDS Consumer by using the Hello message of this transaction.

2:3.47.4.1.1 Trigger Events

If a Discovery Proxy is known to the SOMDS Consumer and the SOMDS Consumer is interested in Hello messages, this message is sent

  1. whenever a SOMDS Provider known to the Discovery Proxy joins an MD LAN,

  2. when a SOMDS Provider known to the Discovery Proxy returns to normal on-line operation after having indicated temporary suspension of message exchanges, or

  3. when a SOMDS Provider known to the Discovery Proxy changes its Discovery Scope.

2:3.47.4.1.2 Message Semantics
Provider UID

The SOMDS Provider UID.

Discovery Scope

The Discovery Scope of the SOMDS Provider.

2:3.47.4.1.3 Expected Actions

When a Discovery Proxy sends this message, there is no expected or required response.

2:3.47.4.2 Bye Message

If a SOMDS Consumer uses a Discovery Proxy, network absence is announced to the SOMDS Consumer by using the Bye message of this transaction.

2:3.47.4.2.1 Trigger Events

If a Discovery Proxy is known to the SOMDS Consumer and the SOMDS Consumer is interested in Bye messages, this message is sent whenever a SOMDS Provider leaves the MD LAN it previously joined via the Hello message.

2:3.47.4.2.2 Message Semantics
Provider UID

The SOMDS Provider UID.

2:3.47.4.2.3 Expected Actions

When a Discovery Proxy sends this message, there is no expected or required response.

2:3.47.4.3 Probe Message

BICEPS specifies an explicit discovery protocol for allowing SOMDS Consumers to discover all SOMDS Providers that are ready to exchange messages with SOMDS Consumers. The corresponding message to seek SOMDS Providers based on filter criteria is called Probe.

If a SOMDS Consumer uses a Discovery Proxy, the SOMDS Consumer can send a Probe message to the Discovery Proxy to seek endpoint information based on filter criteria.

2:3.47.4.3.1 Trigger Events

The Probe message is sent to a Discovery Proxy

  1. whenever a SOMDS Consumer joins an MD LAN and is ready to exchange messages with SOMDS Providers or

  2. when a SOMDS Consumer runs in a mode where it periodically checks for availability of SOMDS Providers matching specific filter criteria.

2:3.47.4.3.2 Message Semantics
Discovery Scope

A Discovery Scope to filter against.

2:3.47.4.3.3 Expected Actions

When a SOMDS Consumer sends this message, the Discovery Proxy answers with all endpoint records that match the requested Discovery Scope by sending a ProbeMatch message.

2:3.47.4.4 ProbeMatch Message

The ProbeMatch message is sent as part of the BICEPS explicit discovery protocol in response to an incoming Probe message.

2:3.47.4.4.1 Trigger Events

The ProbeMatch message is sent whenever a Discovery Proxy receives a Probe message that contains a Discovery Scope that matches zero or more SOMDS Provider's Discovery Scopes.

2:3.47.4.4.2 Message Semantics
Provider UID

The SOMDS Provider UID.

Transport Address

The Transport Address under which the SOMDS Provider can receive secured messages.

2:3.47.4.4.3 Expected Actions

The SOMDS Consumer that receives a ProbeMatch message can use the Transport Address to exchange secured messages with the SOMDS Providers for which it received the ProbeMatch message.

2:3.47.4.5 Resolve Message

BICEPS specifies an explicit discovery protocol for allowing SOMDS Consumers to discover all SOMDS Providers that are ready to exchange messages with SOMDS Consumers. The corresponding message to seek SOMDS Providers based on a unique identifier is called Resolve.

If a specific SOMDS Provider UID is known to a SOMDS Consumer, the SOMDS Consumer can send a Resolve message to a Discovery Proxy.

2:3.47.4.5.1 Trigger Events

The Resolve message is sent to a Discovery Proxy

  1. whenever a SOMDS Consumer joins an MD LAN and is ready to exchange messages with a specific SOMDS Provider for which it knows its SOMDS Provider UID or

  2. when a SOMDS Consumer runs in a mode where it periodically checks for availability of SOMDS Providers matching a specific SOMDS Provider UID.

2:3.47.4.5.2 Message Semantics
Provider UID

The SOMDS Provider UID to resolve.

2:3.47.4.5.3 Expected Actions

When a SOMDS Consumer sends this message, the Discovery Proxy answers with the endpoint record that matches the requested Provider UID.

2:3.47.4.6 ResolveMatch Message

The ResolveMatch message is sent as part of the BICEPS explicit discovery protocol in response to an incoming Resolve message.

2:3.47.4.6.1 Trigger Events

The ResolveMatch message is sent whenever a Discovery Proxy receives a Resolve message.

2:3.47.4.6.2 Message Semantics
Provider UID

The SOMDS Provider UID.

Transport Address

The Transport Address under which the SOMDS Provider can receive secured messages.

A ResolveMatch message may not include a Provider UID and Transport Address if there was no match found for Provider UID.
2:3.47.4.6.3 Expected Actions

The SOMDS Consumer that receives a ResolveMatch message can use the Transport Address to exchange secured messages with the SOMDS Provider for which it received the ResolveMatch message.

2:3.47.5 Safety, Effectiveness and Security - Requirements and Considerations

2:3.47.5.1 SES General Considerations

Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.

2:3.47.5.2 Safety Requirements & Considerations

No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.47.5.3 Effectiveness Requirements & Considerations

No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.

2:3.47.5.4 Security Requirements & Considerations

This transaction is intended to execute over SECURED transmission channels.

Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.

Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.

Appendix 2:A ISO/IEEE 11073 SDC / MDPWS Message Specifications (Normative)

Message outlines do not contain information regarding required/optional elements/attributes nor cardinalities. In order to produce valid messages, the implementation of a SOMDS Participant needs to conform to the referenced standards of which the message outlines herein were generated.

2:A.1 Service Mapping

MDPWS is based on DPWS which in turn leverages a profiled SOAP-based Web Services protocol stack to establish a service-oriented system of devices (SOMDS).

R0500

A SOMDS Provider shall at least provide the port types as specified in Table 2:A.1-1.

Notes
According to BICEPS, the GET SERVICE is the only mandatory service to be implemented. This specification extends the list of mandatory services to increase interoperability between SOMDS Participants.
All port types of SDC are available for download.
Other port types are currently out of scope of this specification and may be added in a future revision.
Table 2:A.1-1. Minimum required port types
Port Type (as QName) BICEPS service [ISO/IEEE 11073-10207:2017]

{http://standards.ieee.org/downloads/11073/11073-20701-2018}GetService

GET SERVICE

{http://standards.ieee.org/downloads/11073/11073-20701-2018}DescriptionEventService

DESCRIPTION EVENT SERVICE

{http://standards.ieee.org/downloads/11073/11073-20701-2018}StateEventService

STATE EVENT SERVICE

{http://standards.ieee.org/downloads/11073/11073-20701-2018}ContextService

CONTEXT SERVICE

{http://standards.ieee.org/downloads/11073/11073-20701-2018}WaveformService

WAVEFORM SERVICE

R0501

A SOMDS Consumer should not request context states by using the GetContextStatesByIdentification and GetContextStatesByFilter operations of the {http://standards.ieee.org/downloads/11073/11073-20701-2018}ContextService port type.

Notes
GetContextStatesByIdentification and GetContextStatesByFilter are insufficiently defined in [ISO/IEEE 11073-10207:2017] and are likely to be obsoleted in a future revision of the specification.
A SOMDS Consumer may retrieve context states by using GetContextStates and perform filtering by itself.

2:A.2 Message Mapping

2:A.2.1 MDPWS: Announce Network Presence [DEV-23]

This section specifies the MDPWS data transmission for messages defined in Section 2:3.23.

2:A.2.1.1 Hello Message

The Hello message is encoded by using WS-Discovery Hello.

2:A.2.1.1.1 Referenced Standards
2:A.2.1.1.2 Message Outline
Figure 2:A.2.1.1.2-1. Hello message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
        xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
    <s12:Header>
        <wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Hello</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
        <wsd:AppSequence InstanceId="..." MessageNumber="..."/>
    </s12:Header>
    <s12:Body>
        <wsd:Hello>
            <wsa:EndpointReference>
                <wsa:Address><!-- ... --></wsa:Address>
            </wsa:EndpointReference>
            <wsd:Types>dpws:Device mdpws:MedicalDevice</wsd:Types>
            <wsd:Scopes>sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
            <wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
        </wsd:Hello>
    </s12:Body>
</s12:Envelope>
2:A.2.1.1.3 Message Semantics
s12:Envelope/s12:Body/wsd:Hello/wsa:EndpointReference/wsa:Address

The SOMDS Provider's Provider UID as URI.

s12:Envelope/s12:Body/wsd:Hello/wsd:Scopes

The SOMDS Provider's Discovery Scope as a list of URIs.

2:A.2.1.1.4 Trigger Events

The abstracted trigger events as listed in Section 2:3.23.4.1.1 are specialized as follows:

This message is sent

  1. when a SOMDS Provider is assigned an IP address after having joined the network,

  2. when a SOMDS Provider is reassigned an IP address, or

  3. when a SOMDS Provider changes its Discovery Scope.

IP address reassignment can occur because of intended or unintended interruptions in the network connection, network reconfiguration during operation (e.g., by plugging of Ethernet switches), or other causes.

It is assumed that SOMDS Participant are connected to an IP network that uses dynamic IP address assignment managed by a DHCP server. The use of static IP addresses is discouraged as it may lead to IP address conflicts, and hence severe communication disruption, in case of network reconfiguration during operation (e.g., by plugging of Ethernet switches).

R2000

A SOMDS Participant should use a dynamically configured IP address.

2:A.2.1.1.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.23.4.1.

2:A.2.1.1.6 Additional Consideration
2:A.2.1.1.6.1 Recurring Hello

In addition to the Hello message trigger events defined in Appendix 2:A.2.1.1.4, recurring Hello messages are needed to decrease the likelihood of missed discovery messages in case of network topology changes during operation, e.g., when operational networks are extended by plugging switches (together) at runtime.

R2001

A SOMDS Provider shall periodically send Hello messages at random intervals between 60 seconds and 120 seconds.

Notes
The random interval between 60 seconds and 120 seconds aims to prevent SOMDS Providers from congesting the network by sending recurring Hello messages at the same time.
2:A.2.1.1.6.2 Hello Message Size

In IT networks such as WLAN, messages can get lost or fragmented and data can consequently be delivered in the wrong order, especially with increasing concurrent data traffic caused by an increasing number of SOMDS Participants. This becomes crucial when connectionless transport protocols like UDP are used. [ISO/IEEE 11073-20701:2018] leverages UDP for service discovery and hence suffers from the aforementioned issue. To mitigate this, SOMDS Providers are advised to create Hello messages of less than the MTU size over UDP, in accordance requirement R0029 in [OASIS DPWS:2009].

Moreover, as further mitigation measure, note that [OASIS SOAP-over-UDP Version 1.1] already defines a non-normative retry and back-off algorithm.

R2002

A SOMDS Participant should implement the retry and back-off algorithm defined in SOAP-over-UDP, Appendix A.

2:A.2.2 MDPWS: Discovery Network Topology [DEV-24]

This section specifies the MDPWS data transmission for messages defined in Section 2:3.24.

2:A.2.2.1 Probe Message

The Probe message is encoded by using WS-Discovery Probe.

2:A.2.2.1.1 Referenced Standards
2:A.2.2.1.2 Message Outline
Figure 2:A.2.2.1.2-1. WS-Discovery Probe message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
    <s12:Header>
        <wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Probe</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
    </s12:Header>
    <s12:Body>
        <wsd:Probe>
            <wsd:Types>mdpws:MedicalDevice</wsd:Types>
            <wsd:Scopes MatchBy="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/rfc3986">sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
        </wsd:Probe>
    </s12:Body>
</s12:Envelope>
2:A.2.2.1.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.24.4.1.

2:A.2.2.1.4 Message Semantics
s12:Envelope/s12:Body/wsd:Probe/wsa:Types

List that contains at least mdpws:MedicalDevice to express seeking SOMDS Providers that conform to MDPWS.

s12:Envelope/s12:Body/wsd:Probe/wsd:Scopes/@MatchBy

The algorithm used to compare the s12:Envelope/s12:Body/wsd:Probe/wsd:Scopes against the SOMDS Provider's scopes.

s12:Envelope/s12:Body/wsd:Probe/wsd:Scopes

The Discovery Scope as a list of URIs to probe for.

2:A.2.2.1.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.24.4.2.

2:A.2.2.1.6 Additional Consideration
2:A.2.2.1.6.1 Recurring Probe

While the number of Hello messages scales linearly with the number of SOMDS Providers, in the worst case the number of Probe / ProbeMatch messages is the product of the number of SOMDS Providers and the number of SOMDS Consumers. Therefore, in order to prevent the network congestion from Probe / ProbeMatch messages, the following requirements are defined:

R3001

A SOMDS Consumer should not periodically send Probe messages.

Notes
If Probe messages are sent periodically, a rationale needs to be provided, since SOMDS Providers send Hello messages periodically.
R3002

A SOMDS Consumer may re-send Probe messages if demanded by a dedicated user interaction.

Notes
A dedicated user interaction can be a button press on a SOMDS Consumer's display or any other manual activation.

In addition, SOMDS Consumer may set filter criteria for Probe messages to reduce the amount of Probe Match messages. For example, Probe messages are sent only if a SOMDS Consumer is assigned to a patient and lost network connection.

2:A.2.2.1.6.2 Scope Matching
R7000

A SOMDS Provider shall implement the scope matching rule http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/rfc3986 as specified by [OASIS WS-Discovery:2009] in a way that the use of prefix refers to the definition of a prefix in formal theory.

Notes
This requirement erases disambiguation since there are multiple definitions of the term prefix.
From this it follows that a prefix can be empty as otherwise the term proper prefix would have to be used.
2:A.2.2.2 ProbeMatch Message

The ProbeMatch message is encoded by using WS-Discovery Probe Match.

2:A.2.2.2.1 Referenced Standards
2:A.2.2.2.2 Message Outline
Figure 2:A.2.2.2.2-1. WS-Discovery Probe Match message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
        xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
    <s12:Header>
        <wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ProbeMatches</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
        <wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>
        <wsd:AppSequence InstanceId="..." MessageNumber="..."/>
    </s12:Header>
    <s12:Body>
        <wsd:ProbeMatches>
            <wsd:ProbeMatch>
                <wsa:EndpointReference>
                    <wsa:Address><!-- ... --></wsa:Address>
                </wsa:EndpointReference>
                <wsd:Types>dpws:Device mdpws:MedicalDevice <!-- ... --></wsd:Types>
                <wsd:Scopes>sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
                <wsd:XAddrs><!-- ... --></wsd:XAddrs>
                <wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
            </wsd:ProbeMatch>
        </wsd:ProbeMatches>
    </s12:Body>
</s12:Envelope>
2:A.2.2.2.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.24.4.2.

2:A.2.2.2.4 Message Semantics
s12:Envelope/s12:Body/wsd:ProbeMatches

In cases where multiple SOMDS Providers are running on a single machine, wsd:ProbeMatches can contain multiple wsd:ProbeMatch results.

s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsa:EndpointReference/wsa:Address

The SOMDS Provider's SOMDS Provider UID encoded as URI.

s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsd:Types

List of types that contains at least dpws:Device and mdpws:MedicalDevice`, which expresses the SOMDS Provider to conform to DPWS and MDPWS.

s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsd:Scopes

The Discovery Scope of the SOMDS Provider, encoded as a list of URIs.

s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsd:XAddrs

A list of HTTPS addresses under which the SOMDS Provider receives secured messages.

s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsd:MetadataVersion

A metadata version of the SOMDS Provider. To be ignored as the transmission of the Probe Match message is unsecure.

2:A.2.2.2.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.24.4.2.

2:A.2.2.3 Resolve Message

The Resolve message is encoded by using WS-Discovery Resolve.

2:A.2.2.3.2 Message Outline
Figure 2:A.2.2.3.2-1. WS-Discovery Resolve message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
    <s12:Header>
        <wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Resolve</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
    </s12:Header>
    <s12:Body>
        <wsd:Resolve>
            <wsa:EndpointReference>
                <wsa:Address><!-- ... --></wsa:Address>
            </wsa:EndpointReference>
        </wsd:Resolve>
    </s12:Body>
</s12:Envelope>
2:A.2.2.3.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.24.4.3.

2:A.2.2.3.4 Message Semantics
s12:Envelope/s12:Body/wsd:Resolve/wsa:EndpointReference/wsa:Address

The Provider UID to resolve, encoded as URI.

2:A.2.2.3.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.24.4.3.

2:A.2.2.4 ResolveMatch Message

The ResolveMatch message is encoded by using WS-Discovery Resolve Match.

2:A.2.2.4.1 Referenced Standards
2:A.2.2.4.2 Message Outline
Figure 2:A.2.2.4.2-1. WS-Discovery Resolve Match message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
        xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
    <s12:Header>
        <wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ResolveMatches</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
        <wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>
        <wsd:AppSequence InstanceId="..." MessageNumber="..."/>
    </s12:Header>
    <s12:Body>
        <wsd:ResolveMatches>
            <wsd:ResolveMatch>
                <wsa:EndpointReference>
                    <wsa:Address><!-- ... --></wsa:Address>
                </wsa:EndpointReference>
                <wsd:Types>dpws:Device mdpws:MedicalDevice <!-- ... --></wsd:Types>
                <wsd:Scopes>sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
                <wsd:XAddrs><!-- ... --></wsd:XAddrs>
                <wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
            </wsd:ResolveMatch>
        </wsd:ResolveMatches>
    </s12:Body>
</s12:Envelope>
2:A.2.2.4.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.24.4.4.

2:A.2.2.4.4 Message Semantics
s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsa:EndpointReference/wsa:Address

The SOMDS Provider's SOMDS Provider UID encoded as URI.

s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsd:Types

List of types that contains at least dpws:Device and mdpws:MedicalDevice`, which expresses the SOMDS Provider to conform to DPWS and MDPWS.

s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsd:Scopes

The Discovery Scope of the SOMDS Provider, encoded as a list of URIs.

s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsd:XAddrs

A list of HTTPS addresses under which the SOMDS Provider receives secured messages.

s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsd:MetadataVersion

A metadata version of the SOMDS Provider. To be ignored as the transmission of the Resolve Match message is unsecure.

2:A.2.2.4.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.24.4.4.

2:A.2.3 MDPWS: Discover BICEPS Services [DEV-25]

This section specifies the MDPWS data transmission for messages defined in Section 2:3.25.

2:A.2.3.1 GetMetadata Message

The GetMetadata message is encoded by using WS-Get.

2:A.2.3.1.2 Message Outline
Figure 2:A.2.3.1.2-1. GetMetadata message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <s12:Header>
        <wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/Get</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To><!-- ... --></wsa:To>
    </s12:Header>
    <s12:Body/>
</s12:Envelope>
2:A.2.3.1.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.25.4.1.

2:A.2.3.1.4 Message Semantics

The GetMetadata message does not contain any further semantics.

2:A.2.3.1.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.25.4.1.

2:A.2.3.2 GetMetadataResponse Message

The GetMetadataResponse message is encoded by using WS-Get.

2:A.2.3.2.2 Message Outline
Figure 2:A.2.3.2.2-1. GetMetadataResponse message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsm="http://schemas.xmlsoap.org/ws/2004/09/mex"
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope">
    <s12:Header>
        <wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/GetResponse</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
    </s12:Header>
    <s12:Body>
        <wsm:Metadata>
            <wsm:MetadataSection Dialect="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01/ThisModel">
                <dpws:ThisModel>
                    <dpws:Manufacturer xml:lang="..."><!-- ... --></dpws:Manufacturer>
                    <dpws:ManufacturerUrl><!-- ... --></dpws:ManufacturerUrl>
                    <dpws:ModelName><!-- ... --></dpws:ModelName>
                    <dpws:ModelNumber><!-- ... --></dpws:ModelNumber>
                    <dpws:PresentationUrl><!-- ... --></dpws:PresentationUrl>
                </dpws:ThisModel>
            </wsm:MetadataSection>
            <wsm:MetadataSection Dialect="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01/ThisDevice">
                <dpws:ThisDevice>
                    <dpws:FriendlyName xml:lang="..."><!-- ... --></dpws:FriendlyName>
                    <dpws:FirmwareVersion><!-- ... --></dpws:FirmwareVersion>
                    <dpws:SerialNumber><!-- ... --></dpws:SerialNumber>
                </dpws:ThisDevice>
            </wsm:MetadataSection>
            <wsm:MetadataSection Dialect="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01/Relationship">
                <dpws:Relationship Type="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01/host">
                    <dpws:Host>
                        <wsa:EndpointReference>
                            <wsa:Address><!-- ... --></wsa:Address>
                        </wsa:EndpointReference>
                        <dpws:Types xmlns="http://standards.ieee.org/downloads/11073/11073-20702-2016"><!-- ... --></dpws:Types>
                    </dpws:Host>
                    <dpws:Hosted>
                        <wsa:EndpointReference>
                            <wsa:Address><!-- ... --></wsa:Address>
                        </wsa:EndpointReference>
                        <dpws:Types><!-- ... --></dpws:Types>
                        <dpws:ServiceId><!-- ... --></dpws:ServiceId>
                    </dpws:Hosted>
                </dpws:Relationship>
            </wsm:MetadataSection>
        </wsm:Metadata>
    </s12:Body>
</s12:Envelope>
2:A.2.3.2.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.25.4.2.

2:A.2.3.2.4 Message Semantics
s12:Envelope/s12:Body/wsm:Metadata/wsm:MetadataSection/dpws:ThisModel

The SOMDS Provider's metadata that maps to the Model Metadata.

s12:Envelope/s12:Body/wsm:Metadata/wsm:MetadataSection/dpws:ThisDevice

The SOMDS Provider's metadata that maps to the Device Metadata.

s12:Envelope/s12:Body/wsm:Metadata/wsm:MetadataSection/dpws:Relationship/dpws:Hosted/dpws:Types

Designates available BICEPS Services by providing a list of service types that contains at least one or more of the BICEPS services as mapped in Table 2:A.2.3.2.4-1.

Table 2:A.2.3.2.4-1. Filter mapping of BICEPS services to QNames.
BICEPS service Web Service XML Schema QName

GET SERVICE (mandatory) as specified in [ISO/IEEE 11073-10207:2017] Section 7.3 Service Model

{http://standards.ieee.org/downloads/11073/11073-20701-2018}GetService

SET SERVICE as specified in [ISO/IEEE 11073-10207:2017] Section 7.3 Service Model

{http://standards.ieee.org/downloads/11073/11073-20701-2018}SetService

DESCRIPTION EVENT SERVICE as specified in [ISO/IEEE 11073-10207:2017] Section 7.3 Service Model

{http://standards.ieee.org/downloads/11073/11073-20701-2018}DescriptionEventService

STATE EVENT SERVICE as specified in [ISO/IEEE 11073-10207:2017] Section 7.3 Service Model

{http://standards.ieee.org/downloads/11073/11073-20701-2018}StateEventService

CONTEXT SERVICE as specified in [ISO/IEEE 11073-10207:2017] Section 7.3 Service Model

{http://standards.ieee.org/downloads/11073/11073-20701-2018}ContextService

WAVEFORM SERVICE as specified in [ISO/IEEE 11073-10207:2017] Section 7.3 Service Model

{http://standards.ieee.org/downloads/11073/11073-20701-2018}WaveformService

2:A.2.3.2.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.25.4.2.

2:A.2.4 MDPWS: Manage BICEPS Subscription [DEV-27]

This section specifies the MDPWS data transmission for messages defined in Section 2:3.27.

2:A.2.4.1 Subscribe Message

The Subscribe message is encoded by using WS-Eventing Subscribe.

2:A.2.4.1.2 Message Outline
Figure 2:A.2.4.1.2-1. WS-Eventing Subscribe message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing">
    <s12:Header>
        <wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
    </s12:Header>
    <s12:Body>
        <wse:Subscribe>
            <wse:EndTo>
                <wsa:Address><!-- ... --></wsa:Address>
            </wse:EndTo>
            <wse:Delivery Mode="http://schemas.xmlsoap.org/ws/2004/08/eventing/DeliveryModes/Push">
                <wse:NotifyTo>
                    <wsa:Address><!-- ... --></wsa:Address>
                </wse:NotifyTo>
            </wse:Delivery>
            <wse:Expires><!-- ... --></wse:Expires>
            <wse:Filter Dialect="..."><!-- ... --></wse:Filter>
        </wse:Subscribe>
    </s12:Body>
</s12:Envelope>
2:A.2.4.1.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.27.4.1.

2:A.2.4.1.4 Message Semantics
s12:Envelope/s12:Body/wse:Subscribe/wse:EndTo/wsa:Address

HTTPS server address at which SubscriptionEnd messages are supposed to be delivered.

s12:Envelope/s12:Body/wse:Subscribe/wse:Delivery/wse:NotifyTo/wsa:Address

HTTPS server address at which Notification messages are supposed to be delivered.

s12:Envelope/s12:Body/wse:Subscribe/wse:Expires

Expiration Time as an XML Schema duration, constrained to hours, minutes and seconds (regular expression: ^PT(\d+H)?(\d+M)?(\d+(.\d+)?S)?(?<!PT)$)

s12:Envelope/s12:Body/wse:Subscribe/wse:Filter/@Dialect

In accordance with DPWS, support for at least http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01/Action.

s12:Envelope/s12:Body/wse:Subscribe/wse:Filter

If s12:Envelope/s12:Body/wse:Subscribe/wse:Filter/@Dialect is http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01/Action, Filter is specified by a list of action URIs as defined in Table 2:A.2.4.1.4-1 that contains at least one URI. There is no normative support for other filters at the moment.

Table 2:A.2.4.1.4-1. Filter mapping of BICEPS reports to action URIs
BICEPS report type Action URI

DescriptionModificationReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.5

http://standards.ieee.org/downloads/11073/11073-20701-2018/DescriptionEventService/DescriptionModificationReport

EpisodicAlertReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.11

http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/EpisodicAlertReport

EpisodicComponentReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.12

http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/EpisodicComponentReport

EpisodicContextReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.13

http://standards.ieee.org/downloads/11073/11073-20701-2018/ContextService/EpisodicContextReport

EpisodicMetricReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.14

http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/EpisodicMetricReport

EpisodicOperationalStateReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.15

http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/EpisodicOperationalStateReport

OperationInvokedReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.77

http://standards.ieee.org/downloads/11073/11073-20701-2018/SetService/OperationInvokedReport

WaveformStream as specified in [ISO/IEEE 11073-10207:2017], Annex C.112

http://standards.ieee.org/downloads/11073/11073-20701-2018/WaveformService/WaveformStream

R7001

When a SOMDS Consumer requests http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01/Action filter processing in a Subscribe message, the SOMDS Consumer shall assume the receiving SOMDS Provider to perform the http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/strcmp0 matching rule.

Notes
The http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/rfc3986 matching rule definition implemented by SOMDS Providers ambiguously includes the term prefix. As http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/rfc3986 subsumes http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/strcmp0, a fallback to case-sensitive string comparison is explicit and failsafe.
2:A.2.4.1.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.27.4.1.

2:A.2.4.2 SubscribeResponse Message

The SubscribeResponse message is encoded by using WS-Eventing SubscribeResponse.

2:A.2.4.2.2 Message Outline
Figure 2:A.2.4.2.2-1. WS-Eventing SubscribeResponse message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing">
    <s12:Header>
        <wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/SubscribeResponse</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
    </s12:Header>
    <s12:Body>
        <wse:SubscribeResponse>
            <wse:SubscriptionManager>
                <wsa:Address><!-- ... --></wsa:Address>
            </wse:SubscriptionManager>
            <wse:Expires><!-- ... --></wse:Expires>
        </wse:SubscribeResponse>
    </s12:Body>
</s12:Envelope>
2:A.2.4.2.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.27.4.2.

2:A.2.4.2.4 Message Semantics
s12:Envelope/s12:Body/wse:SubscribeResponse/wse:SubscriptionManager/wsa:Address

URI that serves as an access point to manage the subscription, which satisfies Subscription Manager.

s12:Envelope/s12:Body/wse:SubscribeResponse/wse:Expires

Expiration Time as an XML Schema duration, constrained to hours, minutes and seconds (regular expression: ^PT(\d+H)?(\d+M)?(\d+(.\d+)?S)?(?<!PT)$).

2:A.2.4.2.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.27.4.2.

2:A.2.4.2.6 Additional Consideration
2:A.2.4.2.6.1 Path dispatching
R7003

A SOMDS Participant shall leverage HTTP path dispatching to identify subscription managers and notification/end-to sinks.

Notes
WS-Eventing allows for an event source or sink to make use of WS-Addressing endpoint reference parameters in order to identify endpoints, which is discouraged because of additional unnecessary complexity in processing complex XML elements.
2:A.2.4.2.6.2 Subscription Expiration
R7004

In a SubscribeResponse message, a SOMDS Provider shall provide an Expires element.

Notes
The WS-Eventing specification that is normatively included in [OASIS DPWS:2009] explains the absence of Expires in a SubscribeResponse message (see [W3C Submission, WS-Eventing:2006], Section 3.1), which is actually prohibited according to the XML Schema. This specification underlines the need to provide an Expires element in SubscribeResponse messages.
2:A.2.4.3 Notification Message

Production of Notification messages is not constrained herein as - depending on the subscription filter - any message can be a notification.

2:A.2.4.4 Renew Message

The Renew message is encoded by using WS-Eventing Renew.

2:A.2.4.4.2 Message Outline
Figure 2:A.2.4.4.2-1. WS-Eventing Renew message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing">
    <s12:Header>
        <wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/Renew</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To><!-- ... --></wsa:To>
    </s12:Header>
    <s12:Body>
        <wse:Renew>
            <wse:Expires><!-- ... --></wse:Expires>
        </wse:Renew>
    </s12:Body>
</s12:Envelope>
2:A.2.4.4.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.27.4.4.

2:A.2.4.4.4 Message Semantics
s12:Envelope/s12:Body/wse:Renew/wse:Expires

Expiration Time as an XML Schema duration, constrained to hours, minutes and seconds (regular expression: ^PT(\d+H)?(\d+M)?(\d+(.\d+)?S)?(?<!PT)$)

2:A.2.4.4.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.27.4.4.

2:A.2.4.5 RenewResponse Message

The RenewResponse message is encoded by using WS-Eventing RenewResponse.

2:A.2.4.5.2 Message Outline
Figure 2:A.2.4.5.2-1. WS-Eventing RenewResponse message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing">
    <s12:Header>
        <wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/RenewResponse</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
    </s12:Header>
    <s12:Body>
        <wse:RenewResponse>
            <wse:Expires><!-- ... --></wse:Expires>
        </wse:RenewResponse>
    </s12:Body>
</s12:Envelope>
2:A.2.4.5.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.27.4.5.

2:A.2.4.5.4 Message Semantics
s12:Envelope/s12:Body/wse:RenewResponse/wse:Expires

Expiration Time as an XML Schema duration, constrained to hours, minutes and seconds (regular expression: ^PT(\d+H)?(\d+M)?(\d+(.\d+)?S)?(?<!PT)$).

2:A.2.4.5.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.27.4.5.

2:A.2.4.5.6 Additional Consideration
2:A.2.4.5.6.1 Subscription Expiration
R7005

In a RenewResponse message, a SOMDS Provider shall provide an Expires element.

Notes
The WS-Eventing specification that is normatively included in [OASIS DPWS:2009] does not explain the absence of Expires in a RenewResponse message (see [W3C Submission, WS-Eventing:2006], Section 3.2). This specification prohibits the absence of Expires in RenewResponse messages to avoid subscriptions that run infinitely.
2:A.2.4.6 Unsubscribe Message

The Unsubscribe message is encoded by using WS-Eventing Unsubscribe.

2:A.2.4.6.2 Message Outline
Figure 2:A.2.4.6.2-1. WS-Eventing Unsubscribe message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing">
    <s12:Header>
        <wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/Unsubscribe</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To><!-- ... --></wsa:To>
    </s12:Header>
    <s12:Body>
        <wse:Unsubscribe/>
    </s12:Body>
</s12:Envelope>
2:A.2.4.6.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.27.4.6.

2:A.2.4.6.4 Message Semantics

The WS-Eventing RenewResponse message does not contain any further semantics.

2:A.2.4.6.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.27.4.6.

2:A.2.4.7 UnsubscribeResponse Message

The UnsubscribeResponse message is encoded by using WS-Eventing UnsubscribeResponse.

2:A.2.4.7.2 Message Outline
Figure 2:A.2.4.7.2-1. WS-Eventing UnsubscribeResponse message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <s12:Header>
        <wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/UnsubscribeResponse</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
    </s12:Header>
    <s12:Body/>
</s12:Envelope>
2:A.2.4.7.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.27.4.7.

2:A.2.4.7.4 Message Semantics

The WS-Eventing UnsubscribeResponse message does not contain any further semantics.

2:A.2.4.7.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.27.4.7.

2:A.2.4.8 SubscriptionEnd Message

The SubscriptionEnd message is encoded by using WS-Eventing Subscription End.

2:A.2.4.8.2 Message Outline
Figure 2:A.2.4.8.2-1. WS-Eventing SubscriptionEnd message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
		xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
		xmlns:wsa="http://www.w3.org/2005/08/addressing"
		xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing">
	<s12:Header>
		<wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/SubscriptionEnd</wsa:Action>
		<wsa:MessageID><!-- ... --></wsa:MessageID>
		<wsa:To><!-- ... --></wsa:To>
	</s12:Header>
	<s12:Body>
		<wse:SubscriptionEnd>
			<wse:SubscriptionManager>
				<wsa:Address><!-- ... --></wsa:Address>
			</wse:SubscriptionManager>
			<wse:Status><!-- ... --></wse:Status>
		</wse:SubscriptionEnd>
	</s12:Body>
</s12:Envelope>
2:A.2.4.8.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.27.4.8.

2:A.2.4.8.4 Message Semantics
s12:Envelope/s12:Body/wse:SubscriptionEnd/wse:SubscriptionManager/wsa:Address

URI of the Subscription Manager that manages the subscription that ended.

s12:Envelope/s12:Body/wse:SubscriptionEnd/wse:Status

Status which is encoded in accordance with WS-Eventing to one of http://schemas.xmlsoap.org/ws/2004/08/eventing/DeliveryFailure, http://schemas.xmlsoap.org/ws/2004/08/eventing/SourceShuttingDown or http://schemas.xmlsoap.org/ws/2004/08/eventing/SourceCancelling.

2:A.2.4.8.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.27.4.8.

2:A.2.5 MDPWS: Notify Change in System Context and Capabilities [DEV-28]

This section specifies the MDPWS data transmission for messages defined in Section 2:3.28.

2:A.2.5.1 Notification Message

The Notification message is encoded by using DPWS Messaging.

2:A.2.5.1.1 Referenced Standards
2:A.2.5.1.2 Message Outline
Figure 2:A.2.5.1.2-1. EpisodicContextReport message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message"
        xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <s12:Header>
        <wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/EpisodicContextReport</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To><!-- ... --></wsa:To>
    </s12:Header>
    <s12:Body>
        <msg:EpisodicContextReport MdibVersion="..." SequenceId="..." InstanceId="...">
            <!-- ... -->
        </msg:EpisodicContextReport>
    </s12:Body>
</s12:Envelope>
2:A.2.5.1.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.28.4.1.

2:A.2.5.1.4 Message Semantics
s12:Envelope/s12:Body/msg:EpisodicContextReport

Updated context information of a SOMDS Provider.

2:A.2.5.1.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.28.4.1.

2:A.2.6 MDPWS: Publish BICEPS Update Reports [DEV-29]

This section specifies the MDPWS data transmission for messages defined in Section 2:3.29.

2:A.2.6.1 EpisodicAlertReport Message

The EpisodicAlertReport message is encoded by using DPWS Messaging.

2:A.2.6.1.1 Referenced Standards
2:A.2.6.1.2 Message Outline
Figure 2:A.2.6.1.2-1. EpisodicAlertReport message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message"
        xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <s12:Header>
        <wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/EpisodicAlertReport</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To><!-- ... --></wsa:To>
    </s12:Header>
    <s12:Body>
        <msg:EpisodicAlertReport MdibVersion="..." SequenceId="..." InstanceId="...">
            <!-- ... -->
        </msg:EpisodicAlertReport>
    </s12:Body>
</s12:Envelope>
2:A.2.6.1.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.29.4.1.

2:A.2.6.1.4 Message Semantics
s12:Envelope/s12:Body/msg:EpisodicAlertReport

Updated alert information of a SOMDS Provider.

2:A.2.6.1.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.29.4.1.

2:A.2.6.2 EpisodicMetricReport Message

The EpisodicMetricReport message is encoded by using DPWS Messaging.

2:A.2.6.2.1 Referenced Standards
2:A.2.6.2.2 Message Outline
Figure 2:A.2.6.2.2-1. EpisodicMetricReport message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message"
        xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <s12:Header>
        <wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/EpisodicMetricReport</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To><!-- ... --></wsa:To>
    </s12:Header>
    <s12:Body>
        <msg:EpisodicMetricReport MdibVersion="..." SequenceId="..." InstanceId="...">
            <!-- ... -->
        </msg:EpisodicMetricReport>
    </s12:Body>
</s12:Envelope>
2:A.2.6.2.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.29.4.1.

2:A.2.6.2.4 Message Semantics
s12:Envelope/s12:Body/msg:EpisodicMetricReport

Updated metric information of a SOMDS Provider.

2:A.2.6.2.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.29.4.1.

2:A.2.6.3 EpisodicComponentReport Message

The EpisodicComponentReport message is encoded by using DPWS Messaging.

2:A.2.6.3.1 Referenced Standards
2:A.2.6.3.2 Message Outline
Figure 2:A.2.6.3.2-1. EpisodicComponentReport message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message"
        xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <s12:Header>
        <wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/EpisodicComponentReport</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To><!-- ... --></wsa:To>
    </s12:Header>
    <s12:Body>
        <msg:EpisodicComponentReport MdibVersion="..." SequenceId="..." InstanceId="...">
            <!-- ... -->
        </msg:EpisodicComponentReport>
    </s12:Body>
</s12:Envelope>
2:A.2.6.3.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.29.4.1.

2:A.2.6.3.4 Message Semantics
s12:Envelope/s12:Body/msg:EpisodicComponentReport

Updated component information of a SOMDS Provider.

2:A.2.6.3.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.29.4.1.

2:A.2.6.4 WaveformStream Message

The WaveformStream message is encoded by using DPWS Messaging.

2:A.2.6.4.1 Referenced Standards
2:A.2.6.4.2 Message Outline
Figure 2:A.2.6.4.2-1. WaveformStream message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message"
        xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <s12:Header>
        <wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/WaveformStream</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To><!-- ... --></wsa:To>
    </s12:Header>
    <s12:Body>
        <msg:WaveformStream MdibVersion="..." SequenceId="..." InstanceId="...">
            <!-- ... -->
        </msg:WaveformStream>
    </s12:Body>
</s12:Envelope>
2:A.2.6.4.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.29.4.1.

2:A.2.6.4.4 Message Semantics
s12:Envelope/s12:Body/msg:WaveformStream

Waveform stream of a SOMDS Provider.

2:A.2.6.4.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.29.4.1.

2:A.2.7 MDPWS: Retrieve BICEPS Content [DEV-30]

This section specifies the MDPWS data transmission for messages defined in Section 2:3.30.

2:A.2.7.1 GetMdib Message

The GetMdib message is encoded by using DPWS Messaging.

2:A.2.7.1.1 Referenced Standards
2:A.2.7.1.2 Message Outline
Figure 2:A.2.7.1.2-1. GetMdib message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message"
        xmlns:wsa="http://www.w3.org/2005/08/addressing" >
    <s12:Header>
        <wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/GetService/GetMdib</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
    </s12:Header>
    <s12:Body>
        <msg:GetMdib/>
    </s12:Body>
</s12:Envelope>
2:A.2.7.1.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.30.4.1.

2:A.2.7.1.4 Message Semantics

The GetMdib message does not contain any further semantics.

2:A.2.7.1.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.30.4.1.

2:A.2.7.2 GetMdibResponse Message

The GetMdibResponse message is encoded by using DPWS Messaging.

2:A.2.7.2.1 Referenced Standards
2:A.2.7.2.2 Message Outline
Figure 2:A.2.7.2.2-1. GetMdibResponse message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:pm="http://standards.ieee.org/downloads/11073/11073-10207-2017/participant"
        xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message"
        xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <s12:Header>
        <wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/GetService/GetMdibResponse</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
    </s12:Header>
    <s12:Body>
        <msg:GetMdibResponse MdibVersion="..." SequenceId="..." InstanceId="...">
            <msg:Mdib MdibVersion="..." SequenceId="..." InstanceId="...">
                <pm:MdDescription DescriptionVersion="...">
                </pm:MdDescription>
                <pm:MdState StateVersion="...">
                </pm:MdState>
            </msg:Mdib>
        </msg:GetMdibResponse>
    </s12:Body>
</s12:Envelope>
2:A.2.7.2.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.30.4.2.

2:A.2.7.2.4 Message Semantics
s12:Envelope/s12:Body/msg:GetMdibResponse/msg:Mdib/pm:MdDescription

The SOMDS Provider's descriptive part of the MDIB.

s12:Envelope/s12:Body/msg:GetMdibResponse/msg:Mdib/pm:MdState

The SOMDS Provider's state part of the MDIB.

2:A.2.7.2.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.30.4.2.

2:A.2.7.2.6 Additional Consideration
2:A.2.7.2.6.1 Context States
R7002

A SOMDS Provider shall enclose all context states in pm:GetMdibResponse messages.

Notes

This requirement restricts optionality in including context states in GetMdibResponse messages as specified in [ISO/IEEE 11073-10207:2017], C.57 GetMdibResponse:

Since contexts might include privacy-related information, a SERVICE PROVIDER MAY decide to leave the MDS contexts empty.

Since transmission of GetMdibResponse messages is required to be secured, there is no need for omitting context states to meet confidentiality; R0121 in [ISO/IEEE 11073-10207:2017] is still met.

2:A.2.8 MDPWS: Announce Network Departure [DEV-34]

This section specifies the MDPWS data transmission for messages defined in Section 2:3.34.

2:A.2.8.1 Bye Message

The Bye message is encoded by using WS-Discovery Bye.

2:A.2.8.1.2 Message Outline
Figure 2:A.2.8.1.2-1. Bye message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
    <s12:Header>
        <wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Bye</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
    </s12:Header>
    <s12:Body>
        <wsd:Bye>
            <wsa:EndpointReference>
                <wsa:Address><!-- ... --></wsa:Address>
            </wsa:EndpointReference>
        </wsd:Bye>
    </s12:Body>
</s12:Envelope>
2:A.2.8.1.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.34.4.1.

2:A.2.8.1.4 Message Semantics
s12:Envelope/s12:Body/wsd:Bye/wsa:EndpointReference/wsa:Address

The SOMDS Provider's Provider UID as URI.

2:A.2.8.1.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.34.4.1.

2:A.2.9 MDPWS: Update Network Presence [DEV-46]

This section specifies the MDPWS data transmission for messages defined in Section 2:3.46.

Additional implementation directions are defined in Appendix 2:A.3.

2:A.2.9.1 Hello Message

The Hello message is encoded by using DPWS Messaging.

2:A.2.9.1.2 Message Outline
Figure 2:A.2.9.1.2-1. Hello message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
        xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
    <s12:Header>
        <wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Hello</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
    </s12:Header>
    <s12:Body>
        <wsd:Hello>
            <wsa:EndpointReference>
                <wsa:Address><!-- ... --></wsa:Address>
            </wsa:EndpointReference>
            <wsd:Types>dpws:Device mdpws:MedicalDevice</wsd:Types>
            <wsd:Scopes>sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
            <wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
        </wsd:Hello>
    </s12:Body>
</s12:Envelope>
2:A.2.9.1.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.46.4.1.

2:A.2.9.1.4 Message Semantics
s12:Envelope/s12:Body/wsd:Hello/wsa:EndpointReference/wsa:Address

The SOMDS Provider's Provider UID as URI.

s12:Envelope/s12:Body/wsd:Hello/wsd:Scopes

The SOMDS Provider's Discovery Scope as a list of URIs.

2:A.2.9.1.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.46.4.1.

2:A.2.9.2 Bye Message

The Bye message is encoded by using DPWS Messaging.

2:A.2.9.2.2 Message Outline
Figure 2:A.2.9.2.2-1. Bye message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
    <s12:Header>
        <wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Bye</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
    </s12:Header>
    <s12:Body>
        <wsd:Bye>
            <wsa:EndpointReference>
                <wsa:Address><!-- ... --></wsa:Address>
            </wsa:EndpointReference>
        </wsd:Bye>
    </s12:Body>
</s12:Envelope>
2:A.2.9.2.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.46.4.2.

2:A.2.9.2.4 Message Semantics
s12:Envelope/s12:Body/wsd:Bye/wsa:EndpointReference/wsa:Address

The SOMDS Provider's Provider UID as URI.

2:A.2.9.2.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.46.4.2.

2:A.2.9.3 DirectedProbe Message

In addition to Hello and Bye, this section proposes a Discovery Proxy to periodically probe all SOMDS Providers it has recorded as present in the SOMDS by using a DirectedProbe message. This allows for the Discovery Proxy to verify if SOMDS Providers reachable.

The DirectedProbe message is encoded by using DPWS Messaging.

2:A.2.9.3.2 Message Outline
Figure 2:A.2.9.3.2-1. DirectedProbe message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
    <s12:Header>
        <wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Probe</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
    </s12:Header>
    <s12:Body>
        <wsd:Probe/>
    </s12:Body>
</s12:Envelope>
2:A.2.9.3.3 Trigger Events

A Discovery Proxy may periodically send DirectedProbe messages to all present SOMDS Providers. The periodicity can be determined by the Discovery Proxy.

2:A.2.9.3.4 Message Semantics

No payload is required as the probe is intended to be used for watchdog purposes only.

2:A.2.9.3.5 Expected Actions

If the request succeeds, there is no additional action required.

If the request fails, the Discovery Proxy removes the SOMDS Provider endpoint metadata from its databases and informs SOMDS Consumers about the SOMDS Provider's absence.

R7006

If Discovery Proxy sends DirectedProbe messages to verify presence of SOMDS Providers, the Discovery Proxy shall notify all SOMDS Consumers subscribed to Bye messages about the SOMDS Provider's absence.

Absence of SOMDS Providers is notified to SOMDS Consumers by using the Bye message as specified in Appendix 2:A.2.10.2.

2:A.2.10 MDPWS: Retrieve Network Presence [DEV-47]

This section specifies the MDPWS data transmission for messages defined in Section 2:3.47.

Additional implementation directions are defined in Appendix 2:A.3.

2:A.2.10.1 Hello Message

The Hello message is encoded by using DPWS Messaging.

2:A.2.10.1.2 Message Outline
Figure 2:A.2.10.1.2-1. Hello message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
        xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
    <s12:Header>
        <wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Hello</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
    </s12:Header>
    <s12:Body>
        <wsd:Hello>
            <wsa:EndpointReference>
                <wsa:Address><!-- ... --></wsa:Address>
            </wsa:EndpointReference>
            <wsd:Types>dpws:Device mdpws:MedicalDevice</wsd:Types>
            <wsd:Scopes>sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
            <wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
        </wsd:Hello>
    </s12:Body>
</s12:Envelope>
2:A.2.10.1.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.47.4.1.

2:A.2.10.1.4 Message Semantics
s12:Envelope/s12:Body/wsd:Hello/wsa:EndpointReference/wsa:Address

The SOMDS Provider's Provider UID as URI.

s12:Envelope/s12:Body/wsd:Hello/wsd:Scopes

The SOMDS Provider's Discovery Scope as a list of URIs.

2:A.2.10.1.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.47.4.1.

2:A.2.10.2 Bye Message

The Bye message is encoded by using DPWS Messaging.

2:A.2.10.2.2 Message Outline
Figure 2:A.2.10.2.2-1. Bye message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
    <s12:Header>
        <wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Bye</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
    </s12:Header>
    <s12:Body>
        <wsd:Bye>
            <wsa:EndpointReference>
                <wsa:Address><!-- ... --></wsa:Address>
            </wsa:EndpointReference>
        </wsd:Bye>
    </s12:Body>
</s12:Envelope>
2:A.2.10.2.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.47.4.2.

2:A.2.10.2.4 Message Semantics
s12:Envelope/s12:Body/wsd:Bye/wsa:EndpointReference/wsa:Address

The SOMDS Provider's Provider UID as URI.

2:A.2.10.2.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.47.4.2.

2:A.2.10.3 Probe Message

The Probe message is encoded by using WS-Discovery Probe.

2:A.2.10.3.1 Referenced Standards
2:A.2.10.3.2 Message Outline
Figure 2:A.2.10.3.2-1. WS-Discovery Probe message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
    <s12:Header>
        <wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Probe</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
    </s12:Header>
    <s12:Body>
        <wsd:Probe>
            <wsd:Types>mdpws:MedicalDevice</wsd:Types>
            <wsd:Scopes MatchBy="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/rfc3986">sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
        </wsd:Probe>
    </s12:Body>
</s12:Envelope>
2:A.2.10.3.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.47.4.3.

2:A.2.10.3.4 Message Semantics
s12:Envelope/s12:Body/wsd:Probe/wsa:Types

List that contains at least mdpws:MedicalDevice to express seeking SOMDS Providers that conform to MDPWS.

s12:Envelope/s12:Body/wsd:Probe/wsd:Scopes/@MatchBy

The algorithm used to compare the s12:Envelope/s12:Body/wsd:Probe/wsd:Scopes against the SOMDS Provider's scopes.

s12:Envelope/s12:Body/wsd:Probe/wsd:Scopes

The Discovery Scope as a list of URIs to probe for.

2:A.2.10.3.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.47.4.4.

2:A.2.10.3.6 Additional Consideration

All additional considerations specified in Appendix 2:A.2.2.1.6 do also apply to Appendix 2:A.2.10.

2:A.2.10.4 ProbeMatch Message

The ProbeMatch message is encoded by using WS-Discovery Probe Match.

2:A.2.10.4.1 Referenced Standards
2:A.2.10.4.2 Message Outline
Figure 2:A.2.10.4.2-1. WS-Discovery Probe Match message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
        xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
    <s12:Header>
        <wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ProbeMatches</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
        <wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>
    </s12:Header>
    <s12:Body>
        <wsd:ProbeMatches>
            <wsd:ProbeMatch>
                <wsa:EndpointReference>
                    <wsa:Address><!-- ... --></wsa:Address>
                </wsa:EndpointReference>
                <wsd:Types>dpws:Device mdpws:MedicalDevice <!-- ... --></wsd:Types>
                <wsd:Scopes>sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
                <wsd:XAddrs><!-- ... --></wsd:XAddrs>
                <wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
            </wsd:ProbeMatch>
        </wsd:ProbeMatches>
    </s12:Body>
</s12:Envelope>
2:A.2.10.4.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.47.4.4.

2:A.2.10.4.4 Message Semantics
s12:Envelope/s12:Body/wsd:ProbeMatches

All matches found by the Discovery Proxy.

s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsa:EndpointReference/wsa:Address

The SOMDS Provider's SOMDS Provider UID encoded as URI.

s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsd:Types

List of types that contains at least dpws:Device and mdpws:MedicalDevice`, which expresses the SOMDS Provider to conform to DPWS and MDPWS.

s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsd:Scopes

The Discovery Scope of the SOMDS Provider, encoded as a list of URIs.

s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsd:XAddrs

A list of HTTPS addresses under which the SOMDS Provider receives secured messages.

s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsd:MetadataVersion

A metadata version of the SOMDS Provider.

2:A.2.10.4.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.47.4.4.

2:A.2.10.5 Resolve Message

The Resolve message is encoded by using WS-Discovery Resolve.

2:A.2.10.5.2 Message Outline
Figure 2:A.2.10.5.2-1. WS-Discovery Resolve message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
    <s12:Header>
        <wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Resolve</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
    </s12:Header>
    <s12:Body>
        <wsd:Resolve>
            <wsa:EndpointReference>
                <wsa:Address><!-- ... --></wsa:Address>
            </wsa:EndpointReference>
        </wsd:Resolve>
    </s12:Body>
</s12:Envelope>
2:A.2.10.5.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.47.4.5.

2:A.2.10.5.4 Message Semantics
s12:Envelope/s12:Body/wsd:Resolve/wsa:EndpointReference/wsa:Address

The Provider UID to resolve, encoded as URI.

2:A.2.10.5.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.47.4.5.

2:A.2.10.6 ResolveMatch Message

The ResolveMatch message is encoded by using WS-Discovery Resolve Match.

2:A.2.10.6.1 Referenced Standards
2:A.2.10.6.2 Message Outline
Figure 2:A.2.10.6.2-1. WS-Discovery Resolve Match message
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
        xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:wsa="http://www.w3.org/2005/08/addressing"
        xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
    <s12:Header>
        <wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ResolveMatches</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
        <wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>
    </s12:Header>
    <s12:Body>
        <wsd:ResolveMatches>
            <wsd:ResolveMatch>
                <wsa:EndpointReference>
                    <wsa:Address><!-- ... --></wsa:Address>
                </wsa:EndpointReference>
                <wsd:Types>dpws:Device mdpws:MedicalDevice <!-- ... --></wsd:Types>
                <wsd:Scopes>sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
                <wsd:XAddrs><!-- ... --></wsd:XAddrs>
                <wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
            </wsd:ResolveMatch>
        </wsd:ResolveMatches>
    </s12:Body>
</s12:Envelope>
2:A.2.10.6.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 2:3.47.4.6.

2:A.2.10.6.4 Message Semantics
s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsa:EndpointReference/wsa:Address

The SOMDS Provider's SOMDS Provider UID encoded as URI.

s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsd:Types

List of types that contains at least dpws:Device and mdpws:MedicalDevice`, which expresses the SOMDS Provider to conform to DPWS and MDPWS.

s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsd:Scopes

The Discovery Scope of the SOMDS Provider, encoded as a list of URIs.

s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsd:XAddrs

A list of HTTPS addresses under which the SOMDS Provider receives secured messages.

s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsd:MetadataVersion

A metadata version of the SOMDS Provider.

2:A.2.10.6.5 Expected Actions

There are no additional or alternative expected actions other than those defined in Section 2:3.47.4.6.

2:A.3 Discovery Proxy implementation requirements

This chapter describes requirements to the Discovery Proxy MDPWS binding that go beyond message outlines and semantics specified in Section 2:3.46 and Section 2:3.47.

R7007

A Discovery Proxy shall provide the Discovery Proxy service by implementing the port type with the QName dp:DiscoveryProxy.

The Discovery Proxy port type is defined in Figure 2:A.3.2-1.
The OID used for the target namespace of the Discovery Proxy WSDL file is listed in Table 2:A.3.1-1.
R7008

A Discovery Proxy shall accept the WS-Eventing wse:Filter@Dialect urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.2.1.

The OID used for the filter dialect is listed in Table 2:A.3.1-1.
R7009

A SOMDS Consumer shall add the filter dialect urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.2.1 to every Subscribe request to a Discovery Proxy.

The OID used for the filter dialect is listed in Table 2:A.3.1-1.

2:A.3.1 Utilized OIDs

All object identifiers used by the Discovery Proxy are specified in Table 2:A.3.1-1.

Table 2:A.3.1-1. WS-Eventing subscription filter dialect and WSDL target namespace OID assignments
Primary identifier Concept description Secondary identifier

1.3.6.1.4.1.19376.1.6.2.10

Profile specific OID for SDPi

sdpi

1.3.6.1.4.1.19376.1.6.2.10.1

Describes namespaces for different purposes as specified by its sub-nodes

namespaces

1.3.6.1.4.1.19376.1.6.2.10.1.2

Identifies Discovery Proxy objects.

discovery-proxy

1.3.6.1.4.1.19376.1.6.2.10.1.2.1

Subscription filter dialect used to identify Hello/Bye subscriptions provided by a Discovery Proxy.

subscription-filter

1.3.6.1.4.1.19376.1.6.2.10.1.2.2

WSDL target namespace identifier for the Discovery Proxy actor.

wsdl

2:A.3.2 Discovery Proxy WSDL

Figure 2:A.3.2-1 shows the WSDL file that specifies the Discovery Proxy Web Service interface.

Figure 2:A.3.2-1. Discovery Proxy WSDL outline
<wsdl:definitions
		targetNamespace="urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.2.2"
		xmlns:dp="urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.2.2"
		xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
		xmlns:s12="http://schemas.xmlsoap.org/wsdl/soap12/"
		xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
		xmlns:wsdd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01"
		xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
		xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing"
		xmlns:wsp="http://www.w3.org/ns/ws-policy">
	<wsdl:import namespace="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01" location="http://docs.oasis-open.org/ws-dd/discovery/1.1/os/wsdd-discovery-1.1-schema-os.xsd"/>
	<wsdl:message name="HelloMessage">
		<wsdl:part name="parameters" element="wsdd:Hello"/>
	</wsdl:message>
	<wsdl:message name="ByeMessage">
		<wsdl:part name="parameters" element="wsdd:Bye"/>
	</wsdl:message>
	<wsdl:message name="ProbeMessage">
		<wsdl:part name="parameters" element="wsdd:Probe"/>
	</wsdl:message>
	<wsdl:message name="ProbeMatchMessage">
		<wsdl:part name="parameters" element="wsdd:ProbeMatches"/>
	</wsdl:message>
	<wsdl:message name="ResolveMessage">
		<wsdl:part name="parameters" element="wsdd:Resolve"/>
	</wsdl:message>
	<wsdl:message name="ResolveMatchMessage">
		<wsdl:part name="parameters" element="wsdd:ResolveMatches"/>
	</wsdl:message>
	<wsdl:portType name="DiscoveryProxy" wse:EventSource="true">
		<wsdl:operation name="HelloReport">
			<wsdl:output message="dp:HelloMessage" wsam:Action="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Hello"/>
		</wsdl:operation>
		<wsdl:operation name="ByeReport">
			<wsdl:output message="dp:ByeMessage" wsam:Action="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Bye"/>
		</wsdl:operation>
		<wsdl:operation name="Hello">
			<wsdl:input message="dp:HelloMessage" wsam:Action="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Hello"/>
		</wsdl:operation>
		<wsdl:operation name="Bye">
			<wsdl:input message="dp:ByeMessage" wsam:Action="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Bye"/>
		</wsdl:operation>
		<wsdl:operation name="Probe">
			<wsdl:input message="dp:ProbeMessage" wsam:Action="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Probe"/>
			<wsdl:output message="dp:ProbeMatchMessage" wsam:Action="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ProbeMatches"/>
		</wsdl:operation>
		<wsdl:operation name="Resolve">
			<wsdl:input message="dp:ResolveMessage" wsam:Action="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Resolve"/>
			<wsdl:output message="dp:ResolveMatchMessage" wsam:Action="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ResolveMatches"/>
		</wsdl:operation>
	</wsdl:portType>
	<wsdl:binding name="DiscoveryProxyBinding" type="dp:DiscoveryProxy">
		<s12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
		<wsp:Policy>
			<dpws:Profile wsp:Optional="true"/>
		</wsp:Policy>
		<wsdl:operation name="HelloReport">
			<s12:operation soapAction="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Hello"/>
			<wsdl:output>
				<s12:body use="literal"/>
			</wsdl:output>
		</wsdl:operation>
		<wsdl:operation name="ByeReport">
			<s12:operation soapAction="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Bye"/>
			<wsdl:output>
				<s12:body use="literal"/>
			</wsdl:output>
		</wsdl:operation>
		<wsdl:operation name="Hello">
			<s12:operation soapAction="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Hello"/>
			<wsdl:input>
				<s12:body use="literal"/>
			</wsdl:input>
		</wsdl:operation>
		<wsdl:operation name="Bye">
			<s12:operation soapAction="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Bye"/>
			<wsdl:input>
				<s12:body use="literal"/>
			</wsdl:input>
		</wsdl:operation>
		<wsdl:operation name="Probe">
			<s12:operation soapAction="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Probe"/>
			<wsdl:input>
				<s12:body use="literal"/>
			</wsdl:input>
			<wsdl:output>
				<s12:body use="literal"/>
			</wsdl:output>
		</wsdl:operation>
		<wsdl:operation name="Resolve">
			<s12:operation soapAction="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Resolve"/>
			<wsdl:input>
				<s12:body use="literal"/>
			</wsdl:input>
			<wsdl:output>
				<s12:body use="literal"/>
			</wsdl:output>
		</wsdl:operation>
	</wsdl:binding>
</wsdl:definitions>

2:A.4 Security Considerations

In TR1164, IEEE 11073-10700 requires a SOMDS Provider to protect BICEPS services against unauthenticated access. In order to fulfill TR1164, IEEE 11073-20701 specifies the need to establish secure channels between SOMDS Participant by using TLS with mutual authentication.

R0502

A SOMDS Participant shall use HTTPS with mutual authentication for those transactions that are required to be secured.

Notes
Each section that specifies a transaction indicates security requirements in the Security Requirements & Considerations subsection beneath the Safety, Effectiveness and Security - Requirements and Considerations of each transaction.
Essentially, this specification asks for secured transmission of data except when ad-hoc discovery is performed.
This appendix does not specify any processes towards certificate governance. Certificate governance is a separate topic that needs to be addressed in future revisions of this specification.

2:A.5 Amendments and Corrigenda

2:A.5.1 Connection Time Delay

When a SOMDS Provider joins a network and sends out a Hello message, depending on the number of SOMDS Consumers that are interested in the data of that SOMDS Provider, the SOMDS Provider can get overwhelmed by incoming TCP connection requests and TLS handshakes. SOMDS Providers and SOMDS Consumers can implement different actions in order to avoid flooding of TCP connection requests and TLS handshakes under normal operating conditions. Each action comes with individual advantages and disadvantages.

2:A.5.1.1 Provider-controlled Delay

[ISO/IEEE 11073-20701:2018] normatively references [OASIS DPWS:2009] which in turn leverages [OASIS WS-Discovery:2009] to provide distributed (ad-hoc) or centralized (managed) service registries. WS-Discovery decomposes into two message sequences, implicit discovery and explicit discovery of which implicit discovery can lead to loss of performance for SOMDS Providers when multiple SOMDS Consumers attempt to connect at the same time.

In order to suppress concurrent connection attempts, in the ad-hoc mode a SOMDS Provider can omit the Transport Address from the Hello message. Subsequently, a SOMDS Consumer needs to send a Resolve message to resolve the SOMDS Provider's Transport Address.

  • Deferral is controlled by the entity that is affected by concurrent connection attempts.

  • The deferral does not work in managed mode, i.e., when a discovery proxy is in charge to respond to Resolve messages (unless the discovery proxy implements a similar behavior).

R0001

A SOMDS Provider may delay sending a Resolve Match response to a Resolve message.

Notes
It is up to the Manufacturer of the SOMDS Provider to choose a delay that fits the hardware capabilities of the SOMDS Provider for concurrent connection requests.
2:A.5.1.2 Consumer-controlled Delay

[ISO/IEEE 11073-20701:2018] introduces the concept of priority groups. According to glue:R0076, a SOMDS Consumer is required to have a priority group assigned, which causes the SOMDS Consumer to postpone initial connection requests by a certain time once it retrieved the Transport Address of a SOMDS Provider. Depending on the priority groups 0 to 9, with increasing group numbers the initial connection delay increases linearly based on random or fixed durations in predefined intervals.

[ISO/IEEE 11073-20701:2018] does not define numbers for specific purposes but rather appeal to Manufacturers to implement priority groups meaningful to their SOMDS Consumer's purpose.

  • The deferral works in ad-hoc and managed mode discovery.

  • Deferral is not controlled by the entity that is affected by concurrent connection attempts but by the entity that initiates the connection.

R0002

A SOMDS Consumer should be configurable with a priority group number in accordance with [ISO/IEEE 11073-20701:2018] R0076.

Notes
As it is not trivial to determine the priority of a SOMDS Consumer in all and every circumstance, the Manufacturer can provide configurable options that allow for flexible adaptation on environmental changes.
2:A.5.1.2.1 Default Priority Group
R0003

If a Manufacturer does not intend to enforce configuration of priority groups during installation of its SOMDS Consumer, the manufacturer shall pre-configure priority groups to a reasonable default value that reflects the highest criticality of the SOMDS Consumer's system function.

Notes
This does not necessarily prevent the user from changing the priority group after the installation process is finished.
Guidelines for reasonable default values are shown in Table 2:A.5.1.2.3-1.
2:A.5.1.2.2 Dynamic Priority Group
R0004

If a Manufacturer does not intend to allow for a user to configure a priority group after the installation process of its SOMDS Consumer is finished, the manufacturer may dynamically determine a reasonable priority group for its SOMDS Consumer according to the highest criticality of the SOMDS Consumer's system function on startup.

Notes
In order to dynamically determine the priority group within a certain range, a SOMDS Consumer can use, for example, a random number generator function or a real-time clock.
Guidelines for reasonable priority group ranges are shown in Table 2:A.5.1.2.3-1.
2:A.5.1.2.3 Priority Group Guidelines

Table 2:A.5.1.2.3-1 exhibits guidelines to Manufacturers or responsible organizations as to which priority group can be used for a certain SOMDS Consumer system function criticality.

Table 2:A.5.1.2.3-1. Exemplary priority group assignments
System Function Criticality Priority Group Range System Function Examples

High

0 - 1

  • Closed loop application

A ventilator and a patient monitor are set up for a closed loop application that automatically controls the oxygen level at the ventilator dependent on the oxygen saturation measured by the patient monitor.

Normal

2 - 6

  • Distributed Alarm System

  • Clinical Decision Support (CDS)

  • A central alarm manager that provides a distributed alarm system according to the IEC 60601-1-8 standard with connected mobile phones

  • Alerting devices used by the caregivers

  • Real-time analytics system that analyzes patient data and detects the deterioration of patients, which is annunciated on mobile phones

Low

7 - 9

  • Display vital signs parameters and alerts

  • Export vital signs parameters and alerts to other systems

  • A dashboard that provides an overview of all the current vital signs and active alerts for a patient

  • A gateway that exports the vital signs data and the alert events from the PoC device to an EMR system

2:A.5.2 MDIB Report Retrofit

In addition to Section 3:8.3.2.12, this section specifies requirements to an MDPWS transport binding. The requirements aim to verify that MDIB versions received by a SOMDS Consumer are not decremented and present no gap.

R1001

A SOMDS Provider shall only establish one TCP connection at a time for every subscribed SOMDS Consumer.

R1002

A SOMDS Participant shall utilize TCP to exchange messages with other SOMDS Participants except for messages exchanged in the WS-Discovery Ad-hoc mode.

Notes
The WS-Discovery Ad-hoc mode utilizes UDP to exchange messages, see [OASIS WS-Discovery:2009].
R1003

A SOMDS Participant shall only utilize HTTP 1.1 without HTTP pipelining for any HTTP traffic.

Notes
Enforces use of HTTP 1.1 in order to limit choices by which a re-ordering of message delivery can be implemented.
R1004

A SOMDS Provider shall transmit msg:WaveformStream, msg:AbstractMetricReport, msg:AbstractOperationalStateReport, msg:AbstractComponentReport, msg:AbstractAlertReport, msg:ObservedValueStream, msg:DescriptionModificationReport, and msg:AbstractContextReport messages sequentially.

Notes
This allows for a SOMDS Consumer to apply report data on internal MDIB data structures before receiving the next report without buffering.
R1005

A SOMDS Consumer should reconnect or go into a fail-safe mode when it receives a report with an MDIB version that is either lower than the last received version or more than one version higher than the last received version.

R1014

A SOMDS Provider shall not send a notification of a subscription as long as there is another notification pending for that subscription.

This also requires SOMDS Providers to serialize delivery of msg:OperationInvokedReport messages.

2:A.5.3 MDPWS Compression Option

MDPWS [ISO/IEEE 11073-20702:2016] defines EXI as the designated means to compress XML data. However, EXI is lagging in adoption. Therefore, instead of using EXI compression, it is recommended to use HTTP compression with gzip (RFC 1952) as the minimum agreement between clients and servers. One issue with that is the missing official support for HTTP compression in HTTP request messages. Request headers are allowed to include Content-Encoding, but those might not be accepted by HTTP servers.

R0005

In its role as an HTTP client, a SOMDS Participant should request gzip compression by using Accept-Encoding with "gzip".

Examples
HTTP request header to request compression
GET /path/to/resource HTTP/1.1
Host: www.example.com
Accept-Encoding: gzip

The client indicates gzip compression to be an accepted response encoding. Note that the server is nevertheless free to send the response without compression.

HTTP response header indicating compressed content
HTTP/1.1 200 OK
Date: sun, 26 June 2016 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix)  (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2020 23:11:55 GMT
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/xml; charset=UTF-8
Content-Encoding: gzip

The HTTP server decided to encode the response with the gzip compression. Note that servers are not required to actually compress (e.g., due to load conditions or unknown algorithms they are entitled to answer with identity encoding).

Unluckily, SDC makes heavy use of request payloads when delivering notifications. Hence, it is further recommended to allow for SOMDS Providers to send compressed WS-Eventing Notification requests if a Subscribe request already included an accepted encoding.

R0006

If a SOMDS Consumer includes an Accept-Encoding header field in an HTTP header in a WS-Eventing Subscribe request, the SOMDS Provider may transmit Notifications related to that subscription encoded with the encoding that was defined in the Subscribe request.

2:A.5.4 Discovery Scopes

[ISO/IEEE 11073-20701:2018] specifies requirements to the encoding of certain MDIB data as WS-Discovery Scopes provided by SOMDS Providers. This clause further details encoding rules for production specifications and attributes as laid out in the IEEE 11073-10101 nomenclature.

2:A.5.4.1 Encoding of Production Specifications
R0010

If a Manufacturer of a SOMDS Provider intends to include MDS production specifications in the WS-Discovery Scopes of the SOMDS Provider, the SOMDS Provider shall encode the production specifications by using the rules in Figure 2:A.5.4.1-2.

Notes
The URI encoding of production specifications is defined in Figure 2:A.5.4.1-1.
Manufacturers can also encode metadata information as production specification, according to the mapping in Table 3:8.3.2.10.2-2.
Examples

URIs of a Manufacturer name and serial number:

  • sdc.mds.prodspec:MediHealth:531970

  • sdc.mds.prodspec:DE12345678:531972,urn%3Aoid%3A1.3.111.2.11073.10101.3

Figure 2:A.5.4.1-1. Extended Backus-Naur Form for the encoding of production specifications
Char ::= unreserved | pct-encoded
CharSequenceNz ::= Char { Char }
CodingSystem ::= CharSequenceNz
CodingSystemVersion ::= CharSequenceNz
Code ::= CharSequenceNz
CodedValue ::= Code [ ',' CodingSystem [ ',' CodingSystemVersion ] ]
Root ::= CharSequenceNz
Extension ::= CharSequenceNz
InstanceIdentifier ::= Root [ ',' Extension ]
ProductionSpec ::= { Char }
SpecType ::= CodedValue
ComponentId ::= InstanceIdentifier
ProductionSpecification ::= ProductionSpec ':' SpecType [ ':' ComponentId ]
Figure 2:A.5.4.1-2. Extended Backus-Naur Form for the encoding of MDS production specifications
Scheme ::= 'sdc.mds.prodspec'
MdsProductionSpecification ::= Scheme ':' ProductionSpecification
ProductionSpecification is specified in Figure 2:A.5.4.1-1.
2:A.5.4.2 Encoding of Attributes
R0011

If a Manufacturer of a SOMDS Provider intends to include MDS attributes in the WS-Discovery Scopes of the SOMDS Provider, the SOMDS Provider shall encode the attributes by using the rules in Figure 2:A.5.4.2-2.

Notes
The URI encoding of attributes is defined by the Extended Backus-Naur Form [ISO/IEC 14977:1996] in Figure 2:A.5.4.2-1.
Examples

URI of a Soft ID named PatMon 03: sdc.mds.attr:PatMon%2003:67886

Figure 2:A.5.4.2-1. Extended Backus-Naur Form for the encoding of attributes
Char ::= unreserved | pct-encoded
CharSequenceNz ::= Char { Char }
CodingSystem ::= CharSequenceNz
CodingSystemVersion ::= CharSequenceNz
Code ::= CharSequenceNz
CodedValue ::= Code [ ',' CodingSystem [ ',' CodingSystemVersion ] ]
AttributeValue ::= { Char }
AttributeCode ::= CodedValue
Attribute ::=  AttributeValue ':'  AttributeCode
Figure 2:A.5.4.2-2. Extended Backus-Naur Form for the encoding of MDS attribute specifications
Scheme ::= 'sdc.mds.attr'
MdsAttribute ::= Scheme ':' Attribute
Attribute is specified in Figure 2:A.5.4.2-1.

2:A.5.5 XML Pretty-Print

XML processor implementations may pretty-print XML by default when serializing XML instance documents, which can cause unexpected errors for validating XML parsers. Pretty-printed XML aligns XML elements in new lines and adds indentation where necessary to beautify serialized data and therewith increase human-readability. However, if the serializer is not XML-Schema-agnostic, it ignores mixed content declarations and hence can change the meaning of elements in instance documents that are supposed to contain mixed content.

R0013 requires XML serializers to be XML Schema agnostic. If, e.g., for technical reasons, a serializer cannot be XML Schema agnostic, it is not allowed to pretty-print XML data as it may generate invalid XML markup.

R0013

A SOMDS Participant shall serialize XML instance documents in accordance to its applicable XML Schema definitions.

Notes
This requirement stems from the need to avoid pretty-print output if an XML serializer does not understand or know the underlying XML Schema definitions.

2:A.5.6 Processing of QNames

QNames are problematic when used in XML element content or attribute values (see Section 3:8.3.2.10.1.2). Unfortunately, the BICEPS Participant and Message Model as well some Web Services standards that are normatively referenced by DPWS, use QNames in XML element content or attribute values.

In order to increase interoperability between implementations of this profile, this section specifies requirements towards QName handling in XML instances.

R1012

A SOMDS Participant shall resolve the namespace of a prefixed QName in XML attribute values and content of elements to the namespace that is associated with its prefix and is valid for the smallest element, which encloses the QName, by XML content.

R1013

A SOMDS Participant shall resolve the namespace of an unprefixed QName in XML attribute values and content of elements to the default namespace that is valid for the smallest element, which encloses the QName, by XML content.

Appendix 2:B Gateways (Normative)

2:B.1 Overview SDC Gateways

2:B.2 SDPi Gateway — HL7 V2 General Mapping

This section specifies general HL7 V2 requirements and mappings, which apply to the Appendix 2:B.3 as well as to the Appendix 2:B.4 sections below.

2:B.2.1 Time Zone Setting

Timestamps can be specified in HL7 v2 in both UTC and local time.

As stated in [IHE PCD TF-2:2019] all observation times reported SHOULD be UTC, as indicated by including a time zone offset of +0000.
If the timestamps are to be specified in local time, it is important that the time zone is set correctly at the Point of Care Device (PoCD).
It is not always guaranteed that the timezone configured at the SOMDS Provider and/or SOMDS DEC Gateway / SOMDS ACM Gateway corresponds with the timezone of the MDS entities, for example, when a SOMDS Provider acting as device aggregator and/or the SOMDS DEC Gateway / SOMDS ACM Gateway are running in a data center located in a different timezone than the MDS entities.

2:B.2.2 Private MDC Codes Consideration

The default coding system utilized in SDC is "MDC" (Medical Device Communications) also known as "ISO/IEEE 11073-10101" nomenclature.

In addition to the standard codes, MDC defines private code ranges that can be used by medical device vendors for defining their own codes, for example, for concepts for which standard codes do not exist. Private codes should be avoided whenever possible since this undermines interoperability.

Coded elements in SDC using MDC private codes require also to contain a pm:Translation element that defines the vendor-specific coding system. Please refer to [IEEE 11073-10700:2022] TR1358 for further information.

Section Section 3:8.3.2.7 describes how a globally unique vender-specific coding system identifier can be defined.

R8119

For each private code a SOMDS Provider shall provide exactly one pm:Translation where pm:Translation/@Code is identical with pm:CodedValue/@Code.

Notes
Multiple translations are allowed, but exactly one translation is specified for a private code.

The following example uses the SDC pm:Type to demonstrate the mapping of private MDC codes.

Table 2:B.2.2-1. Private Code Mapping (CWE data type example)
HL7 Field HL7 Component Name SDC Attribute/Element Comments

CWE-1

Identifier

pm:Type/@Code

This attribute contains the private MDC code.

CWE-2

Text

If available: pm:Type/@SymbolicCodeName, otherwise: "MDC_PRIVATE_<CWE-1>"

If pm:Type/@SymbolicCodeName is available for a private code, this value is used. Otherwise, the field is required to be set to a private RefId that consists of the prefix "MDC_PRIVATE_" plus the private code defined in CWE-1.

CWE-3

Name of Coding System

Set to coding system "MDC".

CWE-4

Alternate Identifier

pm:Type/pm:Translation/@Code

This code is required to be identical with the pm:Type/@Code attribute.

CWE-6

Name of Alternate Coding System

pm:Type/pm:Translation/@CodingSystem

This attribute specifies the vendor-specific or local coding system that has defined the private MDC code.

CWE-7

Coding System Version ID

pm:Type/@CodingSystemVersion

CWE-8

Alternate Coding System Version ID

pm:Type/pm:Translation/@CodingSystemVersion

Example 1. MDC Private Code Mapping Output

123455^MDC_PRIVATE_123455^MDC^123455^^urn:oid:1.3.6.1.4.1.1234.2

123455^MDC_PRIVATE_123455^MDC^123455^^99PHL

2:B.2.3 HL7 Segment Descriptions

The following sections specify the general HL7 V2 segment mappings. Please refer to the Appendix B Common Segment Descriptions of the [IHE PCD TF-2:2019] for further information.

2:B.2.3.1 MSH - Message Header Segment

The HL7 Message Header (MSH) segment requires a mapping between the MDIB content and the MSH segment fields.

R8100

If not differently specified in this section, the MSH segment fields shall be in compliance with the [PCD-01] or [PCD-04] transaction, retrospectively, as described in the [IHE PCD TF-2:2019].

R8101

For each MDS element in the MDIB, a separate [PCD-01] message shall be exported.

Notes
The HL7 segments MSH, PID, and PV1 contain information which can differ between multiple PoC devices represented as MDS elements in the MDIB (e. g. operating mode, patient demographics, patient location, etc.). Since these segments are commonly defined for all MDS elements in the HL7 [PCD-01] message, separate HL7 [PCD-01] messages per PoCD are required to be exported.
2:B.2.3.1.1 MSH-11 Processing ID
R8118

A SOMDS DEC Gateway / SOMDS ACM Gateway shall set the MSH-11 field to the code for the processing ID, which is either be "P" (Production) or "D" (Debugging).

Notes
Table 2:B.2.3.1.1-1 defines the mapping of the SDC MDS information to the data fields of the HL7 data type PT used in the MSH-11 field.
Table 2:B.2.3.1.1-1. MSH-11 Processing ID Mapping
HL7 Field HL7 Component Name SDC Attribute/Element Comments

MSH-11/PT-1

Processing ID

pm:MdsState/@OperatingMode

Note that the HL7 Processing ID value set (HL7 table 0103) differs from the SDC pm:MdsOperatingMode value set and requires a mapping accordingly (see also Table 2:B.2.3.1.1-2).

Table 2:B.2.3.1.1-2. pm:mdsOperatingMode to Processing ID Value Set Mapping
SDC Value SDC Description HL7 Value HL7 Description

Nml

Nml = Normal

P

Production

Dmo

Srv

Mtn

Dmo = Demo

Srv = Service

Mtn = Maintenance

D

Debugging

2:B.2.3.2 PID - Patient Identification Segment

The HL7 Patient Identification (PID) segment requires a mapping from the MDIB patient context information element pm:PatientContextState to the PID segment fields.

2:B.2.3.2.1 Prerequisite of Valid Patient Context
R8102

The SDC patient context information shall only be mapped to the corresponding fields in the HL7 PID segment when the requirements for a valid SDC patient context as defined in [IEEE 11073-10700:2022] are fulfilled.

Notes
For a valid pm:PatientContextState, the pm:AbstractContextState/@ContextAssociation attribute is set to "Assoc" and the pm:AbstractContextState/pm:Validator is set to a valid validator. A corresponding inferred patient ensemble context is not required for the SOMDS DEC Gateway / SOMDS ACM Gateway.
If the SDC patient context information is not intended to be used for the mapping, please refer to the [IHE PCD TF-2:2019] on how to populate the fields of the PID segment in this case.
2:B.2.3.2.2 PID-3 Patient Identifier List
R8103

If R8102 is met, then a SOMDS DEC Gateway / SOMDS ACM Gateway shall map the patient identifiers to the PID-3 field.

Notes
The PID-3 is a list of patient identifiers (e.g., medical record number, social security number, visit number, account number, etc.)
Table 2:B.2.3.2.2-1 defines the mapping of the MDIB patient identification to the data fields of the HL7 data type CX used in the PID-3 field.
If the MDIB patient identification element pm:PatientContextState/pm:Identification contains more than one patient identifier, each SDC patient identifier is mapped according to the Table 2:B.2.3.2.2-1 table and added to the PID-3 patient identifier list.
Table 2:B.2.3.2.2-1. PID-3 Patient Identifier List Mapping
HL7 Field HL7 Component Name SDC Attribute/Element Comments

PID-3/CX-1

ID Number

pm:PatientContextState/pm:Identification/@Extension

The @Extension attribute contains the unique patient identifier.

Note that the field may contain a null value indicating that the identifier is missing.

PID-3/CX-4

Assigning Authority

pm:PatientContextState/pm:Identification

HL7 data type HD

PID-3/CX-4.1

Namespace ID

/@Root

The @Root contains the unique identification of the HDO.

Note that if the HDO identifier is not defined the CX-4 field is left empty.

PID-3/CX-5

Identifier Type Code

pm:PatientContextState/pm:Identification/pm:Type/@Code

The type of the patient identifier set in the @Code attribute is set to a value from HL7 V2 table 0203. The @CodingSystem is set to urn:oid:2.16.840.1.113883.18.108.

The following identifier type codes are proposed to be used for the patient identifier in the point of care device:

Table 2:B.2.3.2.2-2. Patient Identifier Type Code Value Set
Value Description

AN

Account Number

MR

Medical Record Number

PI

Patient Internal Identifier

U

Unspecified Identifier

VN

Visit Number

2:B.2.3.2.3 PID-5 Patient Name
R8104

If R8102 is met, then a SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PID-5 field to the patient name information.

Notes
Table 2:B.2.3.2.3-1 defines the mapping of the SDC patient name information to the data fields of the HL7 data type XPN used in the PID-5 field.
Table 2:B.2.3.2.3-1. PID-5 Patient Name Mapping
HL7 Field HL7 Component Name SDC Attribute/Element Comments

PID-5/XPN-1

Family Name

pm:PatientContextState/pm:CoreData

HL7 data type FN

PID-5/XPN-1.1

Surname

/pm:Familyname

PID-5/XPN-2

Given Name

pm:PatientContextState/pm:CoreData/pm:Givenname

PID-5/XPN-3

Second and Further Given Names or Initials

pm:PatientContextState/pm:CoreData/pm:Middlename

PID-5/XPN-5

Prefix (e.g., DR)

pm:PatientContextState/pm:CoreData/pm:Title

PID-5/XPN-7

Name Type Code

pm:PatientContextState/pm:CoreData

This field is set to "L" when a patient name is available, or "U" when the patient name is not set.

Please refer also to the corresponding section in the [IHE PCD TF-2:2019].

2:B.2.3.2.4 PID-6 Mother’s Maiden Name
R8105

If R8102 is met, then a SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PID-6 field to the mother’s maiden name or birth name before marriage.

Notes
Table 2:B.2.3.2.4-1 defines the mapping of the SDC patient name information to the data fields of the HL7 data type XPN used in the PID-6 field.
Table 2:B.2.3.2.4-1. PID-6 Mother’s Maiden Name Mapping
HL7 Field HL7 Component Name SDC Attribute/Element Comments

PID-6/XPN-1

Family Name

pm:PatientContextState/pm:CoreData

HL7 data type FN

PID-6/XPN-1.1

Surname

/pm:Birthname

2:B.2.3.2.5 PID-7 Date/Time of Birth
R8106

If R8102 is met, then a SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PID-7 field to the date & time of birth.

Notes
Table 2:B.2.3.2.5-1 defines the mapping of the SDC patient’s date of birth information to the data fields of the HL7 data type DTM used in the PID-7 field.
Table 2:B.2.3.2.5-1. PID-7 Date/Time of Birth Mapping
HL7 Field HL7 Component Name SDC Attribute/Element Comments

PID-7/DTM-1

Date/Time

pm:PatientContextState/pm:CoreData/pm:DateOfBirth

Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also Example 2).

Example 2. Date/Time Format Mapping

xsd:dateTime: 2001-10-26T21:32:52 → HL7 DTM: 20011026213252

xsd:date: 2001-10-26 → HL7 DTM: 20011026

2:B.2.3.2.6 PID-8 Administrative Sex

The sex and gender of a patient (or a newborn) cannot exactly be mapped from [ISO/IEEE 11073-10207:2017] to [HL7 V2]. The BICEPS model only contains an attribute for sex (pm:PatientContextState/pm:CoreData/pm:Sex) as defined by biological and physiological characteristics. [HL7 V2], on the other hand, only provides a field for the administrative sex as defined by the socially constructed roles, behaviours, activities, and attributes that a given society considers appropriate. The biological sex, however, does not necessarily match a person’s administrative gender or sex. Mapping from one to the other would therefore introduce errors. However, in the clinical context of a PoCD the sex for clinical use is important for various algorithms, range and limit settings, and so on.

In order to avoid an erroneous mapping of potentially different sex concept interpretations, the sex as defined in BICEPS is required to be mapped to a separate OBX segment as defined in R8120.

Mappings to the PID-8 Administrative Sex field are allowed in certain cases as defined in R8121 and R8107.

R8120

If R8102 is met, then a SOMDS DEC Gateway / SOMDS ACM Gateway shall export the patient’s sex as OBX segment on the MDS level.

Notes
The mapping for the patient’s sex is defined in table Table 2:B.2.3.2.6-1.
R8121

If R8102 is met and the patient’s sex in the MDIB is sourced from the PID-8 field in HL7 V2 ADT messages provided by the hospital ADT system, then a SOMDS DEC Gateway / SOMDS ACM Gateway may set the PID-8 field to the code for the administrative sex.

Notes
Table 2:B.2.3.2.6-2 defines the mapping of the SDC patient’s sex information to the data fields of the HL7 data type IS used in the PID-8 field.
R8107

If R8102 is met and the SOMDS V2 Gateway provides the Healthcare Delivery Organization (HDO) the possibility to configure the export of the patient’s sex set in the MDIB in the PID-8 field, then a SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PID-8 field to the code for the administrative sex.

Notes
Table 2:B.2.3.2.6-2 defines the mapping of the SDC patient’s sex information to the data fields of the HL7 data type IS used in the PID-8 field.
R8122

If the SOMDS V2 Gateway provides the Healthcare Delivery Organization (HDO) the possibility to configure the export of the patient’s sex in the PID-8 field, the manufacturer of the SOMDS V2 Gateway shall require in the ACCOMPANYING INFORMATION that the HDO has to consider the risk that the patient’s sex set in the MDIB and mapped to the PID-8 field does not lead to a misinterpretation of the sex concept on SOMDS V2 Gateway consumer side.

Table 2:B.2.3.2.6-1. OBX Sex Mapping
HL7 Field HL7 Component Name SDC Attribute/Element Comments

OBX-1

Set ID - OBX

Please refer to the [IHE PCD TF-2:2019] OBX-1 Set ID - OBX for further information.

OBX-2

Value Type

Set to "ST".

OBX-3/CWE-1

Identifier

Set to LOINC code "46098-0".

OBX-3/CWE-2

Text

Set to LOINC fully-specified name "Sex".

OBX-3/CWE-3

Name of Coding System

Set to coding system "https://loinc.org".

OBX-4

Observation Sub-ID

Set to "<MDS>.0.0.3" where <MDS> is the number of the MDS level assigned by the gateway. See Appendix 2:B.3.4.6.4 for further information.

OBX-5

Observation Value

pm:PatientContextState/pm:CoreData/pm:Sex

Note that the HL7 Administrative Sex value set (HL7 table 0001) differs from the SDC pm:Sex value set and requires a mapping accordingly (see also Table 2:B.2.3.2.6-3).

OBX-11

Observation Result Status

When the patient context has been associated and a new @BindingStartTime has been set, the field is set to final result status "F".

When there are further updates of the sex value after the association of the patient context, the field is set to "C".

OBX-14

Date/Time of the Observation

pm:PatientContextState/@BindingStartTime

Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also Example 2).

Table 2:B.2.3.2.6-2. PID-8 Administrative Sex Mapping
HL7 Field HL7 Component Name SDC Attribute/Element Comments

PID-8/IS-1

Administrative Sex