# Service-oriented Device Point-of-care Interoperability (SDPi) Technical Framework

A Joint HL7-IHE Gemini Device Interoperability Project

IHE Devices

Technical Framework Supplement

Service-oriented Device Point-of-care

Interoperability (SDPi)

Revision 2.0.0 — Standard for Trial Use / Implementation

Publication Date: | December 13, 2024
Build Date: | 2024-12-13 15:47:24 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 December 13, 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 2.0.0 Supplement —STU / TI Version— Note: This version of the SDPi 2.0 Standard for Trial Use (HL7 STU) / Trial Implementation (IHE TI) supplement is the 4th 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: HL7 2024 January & May ballot comment resolutions applied HL7 FHIR Gateway content added to TF-2B 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 mature development stage; 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: Releases along with the planned capability additions are managed in the project’s DEV.SDPi "Gemini SDPi Releases" Github project This supplement includes four 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 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 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; 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; 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; SDPi 2.0 Supplement Note boxes are provided throughout the document to help guide reviewers and implementers.

## Supplement Forward Declarations

SDPi 2.0 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 four 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 three IHE DEV TF volumes, including:

TF-1 Profiles

- General overview of the SDPi architectural approach and 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.

### Use Cases: Mapping Clinical Scenarios to Profile Requirements

IHE technical framework integration profile specifications include use case sections to ensure that the technical solutions are rooted in real-world application requirements. These sections typically include a basic description of use case scenarios, identify the key systems that exchange information, application-level detail of the information exchanged, and perhaps even some sequence diagrams. This information may also be used to drive the test cases that are used for conformity assessment, ensuring that the resulting specification implementation meets the intended needs.

This supplement includes this same organization; however, it also defines a set of general, non-profile-specific clinical use cases that provide requirements, which may be mapped to multiple SDPi integration profiles. Section Appendix 1:C provides a collection of these high-level clinical use cases.

FOR READERS OF THIS SUPPLEMENT, a good strategy might be to first review the use cases in the Volume 1 appendix (e.g., Appendix 1:C.4 ), and then review the specific profiles to which the clinical scenario requiremets have been mapped. Reviewing the use case specifications in this order will provide the needed context to understand what is presented in each profile.

### 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 and automate requirements and capabilities from component specifications and standards to enable traceability and 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 2.0.0 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) 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 related to any "Topic of Interest".

- To see the full list of OPEN issues, go to https://github.com/IHE/DEV.SDPi/issues?q=is%3Aissue+is%3Aopen+label%3A%22Topic+of+Interest%22

- To see the full list of CLOSED issues, go to https://github.com/IHE/DEV.SDPi/issues?q=is%3Aissue+is%3Aclosed+label%3A%22Topic+of+Interest%22

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.

### Open Issues and Topic of Interests

#### Open Issues

- Table A-1 in Appendix A: Alert Aggregator

- SOMDS ACM gateway Actor definition comments

- R1005 breaks uses cases for partial subscribers by conflating message sequencing and MDIB versioning

- SDPi RI for r2.0

- R1007 breaks use cases with multiple Subscriptions

- Does SDPi need to define a SDC suitable slewing period ?

- Update Profiles Graphic with "HL7-IHE"

- MLJ Pre-publication review (1.2.0)

- Do not break pipeline when using requirement keywords outside requirement

- Non slewing time adjustments

- Consistent Formatting of Actor Links in Supplement

- Editorially incorrect actor references

- SDC:ApprovedJurisdiction + UDI Jurisdiction Profiling

- Append DEV-33 Internationalization / Localization Service

#### Topic of Interests

- Feature request: Matrix metric

- Append ToI: Security Certificate Provisioning

- Append ToI: SystemContext Profiling & Use

- Append TOI: MDIB/MDS Modeling for Device Aggregators

### Closed Issues

- Flag three SDPi requirements for later removal due to SDC BICEPS Standard Corrigendum

- ProbeMatch behaviour potentially inconsistent

- SDPi RI for R1.4

- Example message has wrong action urn for waveform stream.

- HL7 2024-Jan: Enhance explanation of SOA aspects of the SDC/SDPi specification

- HL7 2024-Jan: Misc. Editorial Review / Updates

- HL7 2024-Jan: "Topic of Interest" Issue Management - Update for Clarity

- HL7 2024-Jan: Resolve or Remove "TBD" Statements from Text

- HL7 2024-Jan: SES Section Clarification as Non-Comprehensive

- HL7 2024-Jan: Review IHE Style Conventions regarding Numbers in text, use of em-dashes, punctuation, quotation marks, etc.

- HL7 2024-Jan: Evaluate Readability and the use of Version Note boxes and Placeholders for Future Content

- HL7 2024-Jan: Review Referenced Standards Entries for Consistency of Formation and Content

- HL7 2024-Jan: Clarify rationale for Bibliography Subsections

- HL7 2024-Jan: Clarify FHIR Gateway Actor & Support for Multiple Paradigms

- HL7 2024-Jan: Expand Explanation of how Use Cases are Integrated into the Specification

- HL7 2024-Jan: Perform a Readability Review of the Specification

- Add support for FHIR-based gateways to SDPi-P, -R & -A

- SDPi 2.0

- Time synchronization for real time waveform comparison

- SDPi Actor Renaming Evaluation (from DCC discussion)

- More clarity on advisory alerts

- Cookbook Article - update to 1.0 status

- Repo Articles - Cookbook & Cheat Sheet Updates

# 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.

## 9 Copyright Licenses

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.

### 9.1 Copyright of Base Standards

Amend Section 9.1 by adding the following new Section 9.1.5:

#### 9.1.5 IEEE 11073 (Health Device Interoperability)

SDPi 2.0 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 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).
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 | 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 2.0 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 four 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 2.0 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, Section(s) for General IHE Devices architecture, use contexts, and four Participant Key Purposes (PKP) functions — Connecting, Reporting, Alerting, and Controlling (external) 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.

| The SES sections in this document are not intended to be comprehensive, but provide helpful guidance to risk managers. Implementers must ensure that all appropriate risk management processes have been performed.

### 1:2.3 Integration Profiles Overview

SDPi 2.0 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.

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 four 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. Four 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 four 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 2025).

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 2.0 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 2.0 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 and 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 and 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 and 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 2.0 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 and 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.

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.

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:

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 2.0 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).

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 generally support any of the FHIR architectural approaches: RESTful, messaging, documents, and SOA - although the primary approaches are RESTful and messaging. A specific SOMDS FHIR Gateway specification in Appendix 2:B will constrain to (a) specific approach(es). To facilitate interoperability, named options may be added to specialized actors to clearly indicate what a given implementation supports.

For example, a SOMDS FHIR Gateway could 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 could 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 2.0 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 2.0 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).

##### 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.

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 2.0 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:

Figure 1:10.4.1.1-1. General Service Oriented Architecture (SOA) Model

This generalized model includes three 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.

As SOA concepts and implementations have evolved, many different approaches have been defined, building upon some of the basic principles (as listed above) and adding detail appropriate for their specific application use. A detailed overview of SOA concepts is beyond the scope of this specification; however, a number of foundational references related to how SOA has been leveraged for medical device interoperability have been provided in Appendix 1:B, including:

1. [Connecting the clinical IT infrastructure to a service-oriented architecture of medical devices]

2. [OR.NET: a service-oriented architecture for safe and dynamic medical device intoperability]

3. [Standardized Device Services - A Design Pattern for Service Oriented Integration of Medical Devices]

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

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:

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 SDC / BICEPS MDIB Versioning Management

SDPi 2.0 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:

- System Type: MD LAN supported by SDPi-P PnT capabilities (see Figure 1:10.1.1-1)

- Service Type: TS Service supported by Consistent Time Profile binding

- Technical Pre-Conditions: STAD Appendix 1:C.2.4 are fully supported by SDPi-P

- Scenarios: STAD Appendix 1:C.2.5 are fully supported by SDPi-P

##### 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:

- System Type: MD LAN supported by SDPi-P PnT capabilities (see Figure 1:10.1.1-1)

- System Type: Dashboard is supported by the BICEPS Content Module Systems Types Nomenclature (see Table 3:8.3.2.6-1)

- Technical Pre-Conditions: SICDsp Appendix 1:C.3.4 are fully supported by SDPi-P

- Scenarios: SICDsp Appendix 1:C.3.5 basic communication requirements are supported by SDPi-P

##### 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:

- System Type: MD LAN supported by SDPi-P PnT capabilities (see Figure 1:10.1.1-1)

- System Type: Dashboard is supported by the BICEPS Content Module Systems Types Nomenclature (see Table 3:8.3.2.6-1)

- Technical Pre-Conditions: SICDmp Appendix 1:C.4.4 are fully supported by SDPi-P

- Scenarios: SICDmp Appendix 1:C.4.5 basic communication requirements are supported by SDPi-P

##### 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:

- System Type: Gateway is supported by the BICEPS Content Module Systems Types Nomenclature (see Table 3:8.3.2.6-1)

- Service Type: Data Gateway Service is supported by the BICEPS Content Module Systems Types Nomenclature (see Table 3:8.3.2.6-1)

- Technical Pre-Conditions: DDES Appendix 1:C.5.4 are fully supported by SDPi-P

- Scenarios: DDES Appendix 1:C.5.5 basic communication requirements are supported by SDPi-P

##### 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:

- System Type: Alert Gateway (AGW) is supported by the BICEPS Content Module Systems Types Nomenclature (see Table 3:8.3.2.6-1)

- Service Type: Alert Gateway Service is supported by the BICEPS Content Module Systems Types Nomenclature (see Table 3:8.3.2.6-1)

- Technical Pre-Conditions: ACNS Appendix 1:C.6.4 are fully supported by SDPi-P

- Scenarios: ACNS Appendix 1:C.6.5 basic communication requirements are supported by SDPi-P

##### 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:

- System Type: Alert Gateway (AGW) is supported by the BICEPS Content Module Systems Types Nomenclature (see Table 3:8.3.2.6-1)

- Service Type: Alert Gateway Service is supported by the BICEPS Content Module Systems Types Nomenclature (see Table 3:8.3.2.6-1)

- Technical Pre-Conditions: AARS Appendix 1:C.7.4 are fully supported by SDPi-P

- Scenarios: AARS Appendix 1:C.7.5 basic communication requirements are supported by SDPi-P

### 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.

For additional guidance, see Section Safety, Effectiveness and Security - Requirements and Considerations.

#### 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 2.0 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 full integration of two emerging ISO/IEEE standards: [IEEE 11073-10700:2022] and [IEEE 11073-10701:2022]. 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.

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:

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 2.0 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 2.0 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 2.0 Supplement Note: As indicated in Figure 1:11.1-1 above, there are four grouped actors: SOMDS Medical Data Consumer with SOMDS Consumer SOMDS Medical Data Provider with SOMDS Provider SOMDS DEC Gateway with SOMDS V2 Gateway SOMDS FHIR Medical Data Gateway with SOMDS FHIR Gateway 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 2.0 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:

- System Type: N/A

- Service Type: N/A

- Technical Pre-Conditions: N/A

- Scenarios: SICDsp Appendix 1:C.3.5 communication of medical data to a SOMDS Consumer Dashboard

##### 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:

- System Type: N/A

- System Type: N/A

- Technical Pre-Conditions: N/A

- Scenarios: SICDmp Appendix 1:C.4.5 communication of medical data to a SOMDS Consumer Dashboard

##### 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:

- System Type: N/A

- Service Type: N/A

- Technical Pre-Conditions: N/A

- Scenarios: DDES Appendix 1:C.5.5 communication of medical data to a SOMDS Consumer Gateway

### 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 2.0 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.

For additional guidance, see Section Safety, Effectiveness and Security - Requirements and Considerations.

#### 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 2.0 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, 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., refinement of the FHIR DeviceAlert resource). 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.

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:

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 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 2.0 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:

Figure 1:12.2.1-1. SDPi-A Delegate Medical Alert Example Sequence Diagram

#### 1:12.2.2 Alert User Acknowledgement Option

SDPi 2.0 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 2.0 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 2.0 Supplement Note: As indicated in Figure 1:11.1-1 above, there are four grouped actors: SOMDS Medical Alert Consumer with SOMDS Consumer SOMDS Medical Alert Provider with SOMDS Provider SOMDS ACM Gateway with SOMDS V2 Gateway 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 2.0 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:

- System Type: N/A

- Service Type: N/A

- Technical Pre-Conditions: N/A

- Scenarios: SICDsp Appendix 1:C.3.5 communication of medical alert information to a SOMDS Consumer Dashboard

##### 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:

- System Type: N/A

- System Type: N/A

- Technical Pre-Conditions: N/A

- Scenarios: SICDmp Appendix 1:C.4.5 communication of medical alert information to a SOMDS Consumer Dashboard

##### 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:

- System Type: N/A

- Service Type: N/A

- Technical Pre-Conditions: N/A

- Scenarios: ACNS Appendix 1:C.6.5 communication of medical alert information to a SOMDS Consumer Alert Gateway

##### 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:

- System Type: N/A

- Service Type: N/A

- Technical Pre-Conditions: N/A

- Scenarios: AARS Appendix 1:C.7.5 communication of medical alert information to a SOMDS Consumer Alert Gateway

### 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.

For additional guidance, see Section Safety, Effectiveness and Security - Requirements and Considerations.

#### 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 2.0 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 as part of the 2.X or 3.X 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.

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:

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 2.0 Supplement Note: As indicated in Figure 1:13.1-1 above, there are two grouped actors: SOMDS Medical Control Consumer with SOMDS Consumer SOMDS Medical Control Provider with SOMDS Provider 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 2.0 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 2.0 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.

For additional guidance, see Section Safety, Effectiveness and Security - Requirements and Considerations.

#### 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:

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 and 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:

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

1. Source: [ISO 81001-1 "The Temple"]

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 and 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. For additional guidance, see Section Safety, Effectiveness and Security - Requirements and Considerations. #### 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 2.0 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:

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.

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.

Figure 1:A.4.6-1. Requirement Model — Use Case Feature

SDPi 2.0 Supplement Note: Additional detail will be added in a subsequent version. Additional metadata may include: Use Case Identifier Use case element type and identifier

#### 1:A.4.7 Requirement Type: Referenced Standard ICS

Description: A requirement linked to a referenced standard.

SDPi 2.0 Supplement Note: Additional detail will be added in a subsequent version. Additional metadata may include: Referenced Standard (document identifier, version and date; may be a link to the referenced standard section of the specification) 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

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 2.0 Supplement Note: Additional detail will be added in a subsequent version. Additional metadata may include: SES Type = General, Safety, Effectiveness, Security 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 2.0 Supplement Note: Additional detail will be added in a subsequent version. Additional metadata may include: Unique Identifier (label text + OID) that may be used for external test assertion linkages Fulfillment Level: Complete, partial 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:

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:

Figure 1:A.4.10-2. Gazelle Assertion Manager Tool Information Model

Gazelle Assertion Manager Guide

Gazelle X Validator Rule Editor

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.

| HL7 FHIR includes an assert data element in the TestScript resource.

### 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 2.0 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 2.0 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 https://webstore.ansi.org/Standards/AAMI/ansiaami27002019.

- [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 at https://confluence.hl7.org/display/DOF/Devices+On+FHIR and (continuous build version) at https://build.fhir.org/ig/HL7/uv-pocd/.

- [HL7 V2] HL7® Version 2 (V2), available at https://www.hl7.org/implement/standards/product_brief.cfm?product_id=185.

- [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 https://webstore.iec.ch/publication/59648 and https://www.iso.org/standard/41986.html.

- [IEEE 11073-10101:2020] IEEE 11073-10101™ International Standard - Health informatics—​Device interoperability—​Part 10101:Point-of-care medical device communication—​Nomenclature, available at https://standards.ieee.org/ieee/11073-10101/10343/.

- [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 https://standards.ieee.org/ieee/11073-10201/10263/.

- [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 11073-10700™ IEEE Standard — 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, available at https://standards.ieee.org/ieee/11073-10700/10630/.

- [IEEE 11073-10701:2022] IEEE 11073-10701™ IEEE 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, available at https://standards.ieee.org/ieee/11073-10701/7538/.

- [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, in development.

- [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 https://webstore.iec.ch/publication/34263 and https://www.iso.org/standard/72026.html.

- [ISO/IEC 81001-1:2021], ISO 81001-1:2021 Health software and health IT systems safety, effectiveness and security — Part 1: Principles and concepts, available at https://www.iso.org/standard/71538.html and https://webstore.iec.ch/publication/34286.

- [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 2.0 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 2.0 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 2.0 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 and 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.

| The subcategories for the following sections are solely intended to provide organization to the list of entries, facilitating the use of this section.

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

The following bibliographic references include graphics, "infographic", and similar media.

- [ISO 81001-1 "The Temple"], ISO/IEC 81001-1 Figure 1 "The Temple" Diagram, Copyright © 2019 NHS Digital, licensed via Wikimedia Commons, Greg Wye, NHS Digital, OGL 3, available at 81001.org Framework.

#### 1:B.3.2 Standards & Publications

The following bibliographic references include standards that are related to this specification but do not contain normative requirements, as well as papers that are useful in understanding related concepts.

- [IHE PCD SDPi Use Cases Compendium:2019] IHE Patient Care Devices (PCD) Compendium of Medical Device Oriented Use Cases, Companion to the "Service-oriented Device Point-of-Care Interoperability (SDPi)" White Paper, Revision 1.1, November 1, 2019. Available at profiles.ihe.net/DEV/.

- [IHE PCD SDPi White Paper:2019] IHE Patient Care Devices (PCD) Service-oriented Device Point-of-Care Interoperability (SDPi) White Paper, Revision 1.1, November 1, 2019. Available at profiles.ihe.net/DEV/.

- [ISO/IEC 14977:1996] ISO/IEC 14977, Information technology - Syntactic metalanguage - Extended BNF, 15 December 1996, available at https://standards.iso.org/ittf/PubliclyAvailableStandards/s026153_ISO_IEC_14977_1996(E).zip

- [OMG SysML <sup>®</sup> Intro-Graphical Notation 2.0] OMG Systems Modeling Language™ (SysML®), Version 2.0, Introduction to the Graphical Model, Object Management Group (OMG) standard. Available at github.com/Systems-Modeling/SysML-v2-Release/doc/

- [OMG SysML <sup>®</sup> 2.0] OMG Systems Modeling Language ™ (SysML®), Version 2.0, Object Management Group (OMG) specification. Available at github.com/Systems-Modeling/SysML-v2-Release/doc/

- [HL7-GENDER] HL7 gender harmony project, available at https://confluence.hl7.org/display/VOC/The+Gender+Harmony+Project

- [Connecting the clinical IT infrastructure to a service-oriented architecture of medical devices] Paper reviewing use of SOA architecture to integrate medical devices into clinical IT infrastructure, available at https://pubmed.ncbi.nlm.nih.gov/29272252/

- [OR.NET: a service-oriented architecture for safe and dynamic medical device intoperability] Paper reviewing use of SOA architecture to enable an interoperable and safe ecosystem of medical devices, available at https://pubmed.ncbi.nlm.nih.gov/29346114/

- [Standardized Device Services - A Design Pattern for Service Oriented Integration of Medical Devices] C. Mauro, A. Sunyaev, J. M. Leimeister, and H. Krcmar, 2010 43rd Hawaii International Conference on System Sciences, Honolulu, HI, USA: IEEE, Jan. 2010, pp. 1–10. doi: 10.1109/HICSS.2010.347.

#### 1:B.3.3 Presentations

The following bibliographic references include slide decks and recordings that are helpful in understanding these specifications.

- [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 2.0 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 2.0 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 2.0 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 2.0 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 2.0 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].

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

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:

- The responsible organization needs to provide a TS Service with 50 millisecond accuracy.

- The responsible organization needs to provide a redundant TS Service configuration with at least one backup server.

- The responsible organization needs to configure the same TS Service for SOMDS Participants that execute System Function Contribution (SFC)s together.

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

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

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

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

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

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

- [ISO/IEEE 11073-10207:2017] Section 9.2 Implicit Discovery

#### 2:3.23.4 Messages

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.

For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.

##### 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

- [ISO/IEEE 11073-10207:2017] Section 9.3 Explicit Discovery

#### 2:3.24.4 Messages

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.

For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.

##### 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

- [ISO/IEEE 11073-10207:2017] Section 9 Discovery Model

- [ISO/IEEE 11073-10207:2017] Section 7.3 Service Model

#### 2:3.25.4 Messages

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:

  - Manufacturer

  - Model name

  - Model number

###### 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.

For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.

##### 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

- [ISO/IEEE 11073-10207:2017] Section 7.2.3 Request-Response

- [ISO/IEEE 11073-10207:2017] Section 7.2.4 Streaming

- [ISO/IEEE 11073-10207:2017] Annex C

#### 2:3.27.4 Messages

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:

  - DescriptionModificationReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.5

  - EpisodicAlertReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.11

  - EpisodicComponentReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.12

  - EpisodicContextReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.13

  - EpisodicMetricReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.14

  - EpisodicOperationalStateReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.15

  - OperationInvokedReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.77

  - WaveformStream as specified in [ISO/IEEE 11073-10207:2017], Annex C.112

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.

For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.

##### 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

- [ISO/IEEE 11073-10207:2017] Section 7.4 Message Model

#### 2:3.28.4 Messages

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.

For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.

##### 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

- [ISO/IEEE 11073-10207:2017] Section 7.4 Message Model

#### 2:3.29.4 Messages

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.

For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.

##### 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

- [ISO/IEEE 11073-10207:2017] Section 7.3.2 Get Service

#### 2:3.30.4 Messages

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.

For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.

##### 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

- [ISO/IEEE 11073-10207:2017] Section 9.2 Implicit Discovery

#### 2:3.34.4 Messages

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.

For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.

##### 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

- [ISO/IEEE 11073-10207:2017] Section 7.2.3 Request-Response

- [ISO/IEEE 11073-10207:2017] Section 7.2.4 Streaming

- [ISO/IEEE 11073-10207:2017] Annex C

#### 2:3.35.4 Messages

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.

For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.

##### 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

- [ISO/IEEE 11073-10207:2017] Section 7.4 Message Model

#### 2:3.36.4 Messages

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.

For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.

##### 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

- [ISO/IEEE 11073-10207:2017] Section 7.3.2 Get Service

#### 2:3.37.4 Messages

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.

For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.

##### 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

- [ISO/IEEE 11073-10207:2017] Section 7.2.3 Request-Response

- [ISO/IEEE 11073-10207:2017] Section 7.2.4 Streaming

- [ISO/IEEE 11073-10207:2017] Annex C

#### 2:3.38.4 Messages

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.

For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.

##### 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

- [ISO/IEEE 11073-10207:2017] Section 7.4 Message Model

#### 2:3.39.4 Messages

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.

For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.

##### 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

- [ISO/IEEE 11073-10207:2017] Section 7.3.2 Get Service

#### 2:3.40.4 Messages

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.

For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.

##### 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

- [ISO/IEEE 11073-10207:2017] Section 9. Discovery Model

#### 2:3.46.4 Messages

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.

For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.

##### 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

- [ISO/IEEE 11073-10207:2017] Section 9. Discovery Model

#### 2:3.47.4 Messages

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.

| The Discovery Proxy always responds to the Probe message of the SOMDS Consumer with a ProbeMatch message, even when there are zero Discovery Scope matches. Thus, the SOMDS Consumer can always recognize whether the Discovery Proxy has completed the transaction. This is possible in this transaction because of the non-multicast nature of its Probe and ProbeMatch messages. The behavior is different in the DEV-24 Discover Network Topology transaction, which uses multicast messaging.

###### 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.

For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.

##### 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

- [OASIS WS-Discovery:2009] Section 4.1 Hello

- [OASIS DPWS:2009] Section 3 Discovery

- [ISO/IEEE 11073-20702:2016] mdpws:MedicalDevice

- [ISO/IEEE 11073-20701:2018] sdc.mds.pkp:1.2.840.10004.20701.1.1

###### 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

- [OASIS WS-Discovery:2009] Section 5.2 Probe

- [OASIS DPWS:2009] Section 3 Discovery

- [ISO/IEEE 11073-20702:2016] mdpws:MedicalDevice

- [ISO/IEEE 11073-20701:2018] sdc.mds.pkp:1.2.840.10004.20701.1.1

###### 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

- [OASIS WS-Discovery:2009] Section 5.3 Probe Match

- [OASIS DPWS:2009] Section 3 Discovery

- [ISO/IEEE 11073-20702:2016] mdpws:MedicalDevice

- [ISO/IEEE 11073-20701:2018] sdc.mds.pkp:1.2.840.10004.20701.1.1

###### 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.1 Referenced Standards

- [OASIS WS-Discovery:2009] Section 6.2 Resolve

- [OASIS DPWS:2009] Section 3 Discovery

###### 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

- [OASIS WS-Discovery:2009] Section 6.3 Resolve Match

- [OASIS DPWS:2009] Section 3 Discovery

- [ISO/IEEE 11073-20702:2016] mdpws:MedicalDevice

- [ISO/IEEE 11073-20701:2018] sdc.mds.pkp:1.2.840.10004.20701.1.1

###### 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.1 Referenced Standards

- [WC3 Standard, WS-Transfer:2006] Section 3.1 Get

- [OASIS DPWS:2009] Section 4

###### 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.1 Referenced Standards

- [WC3 Standard, WS-Transfer:2006] Section 3.1 Get

- [OASIS DPWS:2009] Section 4

###### 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.1 Referenced Standards

- [W3C Submission, WS-Eventing:2006] Section 3.1 Subscribe

- [OASIS DPWS:2009] Section 5 Eventing

###### 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.1 Referenced Standards

- [W3C Submission, WS-Eventing:2006] Section 3.1 Subscribe

- [OASIS DPWS:2009] Section 5 Eventing

###### 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.3.1 Referenced Standards

- [W3C Submission, WS-Eventing:2006] Section 4 Notifications

- [OASIS DPWS:2009] Section 5 Eventing

##### 2:A.2.4.4 Renew Message

The Renew message is encoded by using WS-Eventing Renew.

###### 2:A.2.4.4.1 Referenced Standards

- [W3C Submission, WS-Eventing:2006] Section 3.2 Renew

- [OASIS DPWS:2009] Section 5 Eventing

###### 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.1 Referenced Standards

- [W3C Submission, WS-Eventing:2006] Section 3.2 Renew

- [OASIS DPWS:2009] Section 5 Eventing

###### 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.1 Referenced Standards

- [W3C Submission, WS-Eventing:2006] Section 3.4 Unsubscribe

- [OASIS DPWS:2009] Section 5 Eventing

###### 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.1 Referenced Standards

- [W3C Submission, WS-Eventing:2006] Section 3.4 Unsubscribe

- [OASIS DPWS:2009] Section 5 Eventing

###### 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.1 Referenced Standards

- [W3C Submission, WS-Eventing:2006] Section 3.5 Subscription End

- [OASIS DPWS:2009] Section 5 Eventing

- [ISO/IEEE 11073-20702:2016]

- [ISO/IEEE 11073-20701:2018]

###### 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

- [OASIS DPWS:2009] Section 2 Messaging

- [ISO/IEEE 11073-10207:2017] msg:EpisodicContextReport

###### 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

- [OASIS DPWS:2009] Section 2 Messaging

- [ISO/IEEE 11073-10207:2017] msg:EpisodicAlertReport

###### 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

- [OASIS DPWS:2009] Section 2 Messaging

- [ISO/IEEE 11073-10207:2017] msg:EpisodicMetricReport

###### 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

- [OASIS DPWS:2009] Section 2 Messaging

- [ISO/IEEE 11073-10207:2017] msg:EpisodicComponentReport

###### 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

- [OASIS DPWS:2009] Section 2 Messaging

- [ISO/IEEE 11073-10207:2017] msg:WaveformStream

###### 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/WaveformService/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

- [OASIS DPWS:2009] Section 2 Messaging

- [ISO/IEEE 11073-10207:2017] msg:GetMdib

###### 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

- [OASIS DPWS:2009] Section 2 Messaging

- [ISO/IEEE 11073-10207:2017] msg:GetMdibResponse

###### 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.1 Referenced Standards

- [OASIS WS-Discovery:2009] Section 4.2 Bye

- [OASIS DPWS:2009] Section 3 Discovery

- [ISO/IEEE 11073-20702:2016]

- [ISO/IEEE 11073-20701:2018]

###### 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.1 Referenced Standards

- [OASIS DPWS:2009] Section 2 Messaging

- [OASIS WS-Discovery:2009] Section 4.1 Hello

###### 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.1 Referenced Standards

- [OASIS DPWS:2009] Section 2 Messaging

- [OASIS WS-Discovery:2009] Section 4.2 Bye

###### 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.1 Referenced Standards

- [OASIS DPWS:2009] Section 2 Messaging

- [OASIS DPWS:2009] Section 3 Discovery

- [OASIS WS-Discovery:2009] Section 5.2 Probe

###### 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.1 Referenced Standards

- [OASIS DPWS:2009] Section 2 Messaging

- [OASIS WS-Discovery:2009] Section 4.1 Hello

- [OASIS WS-Discovery:2009] Section 4.1 Hello

###### 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.1 Referenced Standards

- [OASIS DPWS:2009] Section 2 Messaging

- [OASIS WS-Discovery:2009] Section 4.2 Bye

###### 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

- [OASIS WS-Discovery:2009] Section 5.2 Probe

- [OASIS DPWS:2009] Section 3 Discovery

- [ISO/IEEE 11073-20702:2016] mdpws:MedicalDevice

- [ISO/IEEE 11073-20701:2018] sdc.mds.pkp:1.2.840.10004.20701.1.1

###### 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

- [OASIS WS-Discovery:2009] Section 5.3 Probe Match

- [OASIS DPWS:2009] Section 3 Discovery

- [ISO/IEEE 11073-20702:2016] mdpws:MedicalDevice

- [ISO/IEEE 11073-20701:2018] sdc.mds.pkp:1.2.840.10004.20701.1.1

###### 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.1 Referenced Standards

- [OASIS WS-Discovery:2009] Section 6.2 Resolve

- [OASIS DPWS:2009] Section 3 Discovery

###### 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

- [OASIS WS-Discovery:2009] Section 6.3 Resolve Match

- [OASIS DPWS:2009] Section 3 Discovery

- [ISO/IEEE 11073-20702:2016] mdpws:MedicalDevice

- [ISO/IEEE 11073-20701:2018] sdc.mds.pkp:1.2.840.10004.20701.1.1

###### 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 ]

| `unreserved` is specified in [RFC 3986], 2.3. Unreserved Characters `pct-encoded` is specified in [RFC 3986], 2.1. Percent-Encoding

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

| `unreserved` is specified in [RFC 3986], 2.3. Unreserved Characters `pct-encoded` is specified in [RFC 3986], 2.1. Percent-Encoding

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 and 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 and 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 and 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 | 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).

Table 2:B.2.3.2.6-3. Patient’s Sex Value Set Mapping
SDC Value | SDC Description | HL7 Value | HL7 Description
--- | --- | --- | ---
Unspec | Unspecified. Sex is not designated. | A | Ambiguous
M | Male. Indicates a male patient. | M | Male
F | Female. Indicates a female patient. | F | Female
Unkn | Unknown. Indicates that the sex is unknown for different reasons. | U | Unknown

###### 2:B.2.3.2.7 PID-10 Race

R8108

If R8102 is met, then a SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PID-10 field to the patient’s race.

Notes

| Table 2:B.2.3.2.7-1 defines the mapping of the SDC patient’s race information to the data fields of the HL7 data type CWE used in the PID-10 field.

Table 2:B.2.3.2.7-1. PID-10 Race Mapping
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
PID-10/CWE-1 | Identifier | pm:PatientContextState/pm:CoreData/pm:Race /@Code |
PID-10/CWE-2 | Text | pm:PatientContextState/pm:CoreData/pm:Race /@SymbolicCodeName |
PID-10/CWE-3 | Name of Coding System | pm:PatientContextState/pm:CoreData/pm:Race /@CodingSystem |
PID-10/CWE-4 | Alternate Identifier | pm:PatientContextState/pm:CoreData/pm:Race/pm:Translation /@Code | Note that if pm:Race/@Code contains a private code, the corresponding translation is to be mapped. Otherwise, only the first entry of the pm:Translation element list is to be mapped.
PID-10/CWE-6 | Name of Alternate Coding System | pm:PatientContextState/pm:CoreData/pm:Race/pm:Translation /@CodingSystem | Note that if pm:Race/@Code contains a private code, the corresponding translation is to be mapped. Otherwise, only the first entry of the pm:Translation element list is to be mapped.
PID-10/CWE-7 | Coding System Version ID | pm:PatientContextState/pm:CoreData/pm:Race /@CodingSystemVersion |
PID-10/CWE-8 | Alternate Coding System Version ID | pm:PatientContextState/pm:CoreData/pm:Race/pm:Translation /@CodingSystemVersion | Note that if pm:Race/@Code contains a private code, the corresponding translation is to be mapped. Otherwise, only the first entry of the pm:Translation element list is to be mapped.

###### 2:B.2.3.2.8 PID-31 Identity Unknown Indicator

R8109

If R8102 is met, then a SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PID-31 field to an indicator whether the patient’s identity is known.

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. In this case, the value is set to "N".

| In all other cases, the value is set to "Y".

| A corresponding inferred patient ensemble context is not required for the SOMDS DEC Gateway / SOMDS ACM Gateway in order to determine a valid pm:PatientContextState.

##### 2:B.2.3.3 PV1 - Patient Visit Segment

The HL7 Patient Visit (PV1) segment requires a mapping from the SDC patient and location context information to the PV1 segment fields.

###### 2:B.2.3.3.1 Prerequisite of Valid Patient & Location Context

R8111

The SDC patient and location context information shall only be mapped to the corresponding fields in the HL7 PV1 segment when the requirements for a valid SDC patient and location context as defined in the [IEEE 11073-10700:2022] are fulfilled.

Notes

| For a valid pm:PatientContextState or pm:LocationContextSate, 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 or location ensemble context is not required for the SOMDS DEC Gateway / SOMDS ACM Gateway.

| If the SDC patient and/or location context information is not be used for the mapping, please refer to the [IHE PCD TF-2:2019] on how to populate the fields of the PV1 segment in this case.

###### 2:B.2.3.3.2 PV1-2 Patient Class

R8112

A SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PV1-2 field to the code for the patient class.

Notes

| The HL7 table 0004 - Patient Class defines a set of recommended codes to be used for the data fields of the HL7 data type IS used in the PV1-2 field.

Usually, a PoC device is used for patients admitted to a care unit in the hospital, and therefore, the field is set to "I" (Inpatient). If the patient class is unknown, the field is set to "U" (Unknown).

The SDC data model does not support the concept of a patient class. Therefore, the field is either set to "U" (Unknown) by default, or set to a configurable value by the gateway.

###### 2:B.2.3.3.3 PV1-3 Assigned Patient Location

R8113

If R8111 is met, then a SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PV1-3 field to the patient’s assigned location.

Notes

| Table 2:B.2.3.3.3-1 defines the mapping of the SDC patient location information to the data fields of the HL7 data type PL used in the PV1-3 field.

Table 2:B.2.3.3.3-1. PV1-3 Patient Location Mapping
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
PV1-3/PL-1 | Point of Care | pm:LocationContextState/pm:LocationDetail/@PoC | Aka. clinical care unit
PV1-3/PL-2 | Room | pm:LocationContextState/pm:LocationDetail/@Room |
PV1-3/PL-3 | Bed | pm:LocationContextState/pm:LocationDetail/@Bed |
PV1-3/PL-4 | Facility | pm:LocationContextState/pm:LocationDetail | HL7 data type HD
PV1-3/PL-4.1 | Namespace ID | /@Facility |
PV1-3/PL-7 | Building | pm:LocationContextState/pm:LocationDetail/@Building |
PV1-3/PL-8 | Floor | pm:LocationContextState/pm:LocationDetail/@Floor |

###### 2:B.2.3.3.4 PV1-19 Visit Number

R8114

If R8111 is met, then a SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PV1-19 field to the patient’s visit identifier.

If the SDC patient identifier element pm:PatientContextState/pm:Identification contains more than one patient identifier, only the unique identifier assigned to the patient’s visit is mapped according to the Table 2:B.2.3.3.4-1 table.

When there is no unique visit identifier assigned to the patient’s visit, the field is left empty.

Notes

| Table 2:B.2.3.3.4-1 defines the mapping of the SDC patient identifier to the data fields of the HL7 data type CX used in the PV1-19 field.

| A visit identifier could be a visit number, an account number, or any other identifier that relates to the patient’s visit.

Table 2:B.2.3.3.4-1. PV1-19 Visit Number Mapping
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
PV1-19/CX-1 | ID Number | pm:PatientContextState/pm:Identification/@Extension | The @Extension attribute contains the unique visit identifier if available. Note that the field may contain a null value indicating that the identifier is missing.
PV1-19/CX-4 | Assigning Authority | pm:PatientContextState/pm:Identification | HL7 data type HD
PV1-19/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 required to be left empty.
PV1-19/CX-5 | Identifier Type Code | pm:PatientContextState/pm:Identification/pm:Type/@Code | The type of the patient identifier set in the @Code attribute is required to be set to a value from HL7 V2 table 0203. The @CodingSystem is required be set to "urn:oid:2.16.840.1.113883.18.108". Valid "Identifier Type Code" values for a visit number are, for example, "VN" (Visit Number), "AN" (Account Number), etc.

###### 2:B.2.3.3.5 PV1-44 Admit Time / Date

R8115

If R8111 is met, then a SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PV1-44 field to the patient’s admission date/time.

The SDC data model does not support the concept of an admission date/time. There are also different types of admissions; e.g., hospital admission, care unit admission, etc.

This said, it is up to the SOMDS DEC Gateway / SOMDS ACM Gateway to figure out the admission date/time to be set in the PV1-44 field. If the gateway is not able to determine the admission date/time, the field is left empty.

###### 2:B.2.3.3.6 PV1-51 Visit Indicator

R8116

If R8111 is met, then a SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PV1-51 field to the code for the visit indicator.

If "pm:PatientContextState/pm:Identification/pm:Type/@Code" is "VN" (Visit Number), the field is set to "V".

Otherwise, the field is left empty by default.

Notes

| The HL7 table 0326 - Visit Indicator defines a set of recommended codes to be used for the data fields of the HL7 data type IS used in the PV1-51 field.

#### 2:B.2.4 HL7 Field Descriptions

The following sections specify the general HL7 V2 field mappings. Please refer to the Appendix B Common Segment Descriptions of the [IHE PCD TF-2:2019] for further information.

##### 2:B.2.4.1 OBX-3 Observation Identifier

R8012

A SOMDS DEC Gateway / SOMDS ACM Gateway shall set the OBX-3 field to the identifier of the element in the hierarchical containment tree such as MDS, VMD, CHAN, or the actual related metric to be exported.

Notes

| Table 2:B.2.4.1-1, Table 2:B.2.4.1-2, Table 2:B.2.4.1-3 and Table 2:B.2.4.1-4 define the mapping of the SDC containment tree element to the data fields of the HL7 data type CWE used in the OBX-3 field.

R8013

If a private MDC code is used for the coding of the SDC containment tree element, the SOMDS DEC Gateway / SOMDS ACM Gateway shall map an identifier of the element in the hierarchical containment tree such as MDS, VMD, CHAN, or the actual related metric as described in Section Appendix 2:B.2.2.

Table 2:B.2.4.1-1. OBX-3 Observation Identifier Mapping - MDS Level
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
OBX-3/CWE-1 | Identifier | pm:Mds/pm:Type/@Code |
OBX-3/CWE-2 | Text | If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:Mds/pm:Type/@SymbolicCodeName. | Note that MDC is the default coding system if no coding system is specified.
OBX-3/CWE-3 | Name of Coding System | MDC if no other coding system is specified. In all other cases, the field is set to pm:Mds/pm:Type/@CodingSystem. | Note that MDC is the default coding system if no coding system is specified.
OBX-3/CWE-7 | Coding System Version ID | pm:Mds/pm:Type/@CodingSystemVersion. |

Table 2:B.2.4.1-2. OBX-3 Observation Identifier Mapping - VMD Level
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
OBX-3/CWE-1 | Identifier | pm:Vmd/pm:Type/@Code |
OBX-3/CWE-2 | Text | If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:Vmd/pm:Type/@SymbolicCodeName. | Note that MDC is the default coding system if no coding system is specified.
OBX-3/CWE-3 | Name of Coding System | MDC if no other coding system is specified. In all other cases, the field is set to pm:Vmd/pm:Type/@CodingSystem. | Note that MDC is the default coding system if no coding system is specified.
OBX-3/CWE-7 | Coding System Version ID | pm:Vmd/pm:Type/@CodingSystemVersion. |

Table 2:B.2.4.1-3. OBX-3 Observation Identifier Mapping - CHAN Level
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
OBX-3/CWE-1 | Identifier | pm:Channel/pm:Type/@Code |
OBX-3/CWE-2 | Text | If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:Channel/pm:Type/@SymbolicCodeName. | Note that MDC is the default coding system if no coding system is specified.
OBX-3/CWE-3 | Name of Coding System | MDC if no other coding system is specified. In all other cases, the field is set to pm:Channel /pm:Type /@CodingSystem. | Note that MDC is the default coding system if no coding system is specified.
OBX-3/CWE-7 | Coding System Version ID | pm:Channel/pm:Type/@CodingSystemVersion. |

Table 2:B.2.4.1-4. OBX-3 Observation Identifier Mapping - Metric Level
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
OBX-3/CWE-1 | Identifier | pm:NumericMetricDescriptor/pm:Type/@Code pm:StringMetricDescriptor/pm:Type/@Code pm:EnumStringMetricDescriptor/pm:Type/@Code |
OBX-3/CWE-2 | Text | If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:AbstractMetricDescriptor/pm:Type/@SymbolicCodeName. | Note that MDC is the default coding system if no coding system is specified.
OBX-3/CWE-3 | Name of Coding System | MDC if no other coding system is specified. In all other cases, the field is set to pm:AbstractMetricDescriptor/pm:Type/@CodingSystem. | Note that MDC is the default coding system if no coding system is specified.
OBX-3/CWE-7 | Coding System Version ID | pm:AbstractMetricDescriptor/pm:Type/@CodingSystemVersion. |

##### 2:B.2.4.2 OBX-4 Observation Sub-ID

R8014

A SOMDS DEC Gateway / SOMDS ACM Gateway shall set the OBX-4 field to a hierarchical representation of the SDC element in the hierarchical containment tree.

Notes

| Please refer to the IHE technical framework [IHE PCD TF-2:2019] for further information.

R8015

A SOMDS DEC Gateway / SOMDS ACM Gateway shall assign the handles (which are required to be unique in the same MDIB) of the containment tree elements representing MDSs, VMDs, channels and metrics to unique integer numbers per child level of the same parent.

Notes

| This implies that, e.g., channel elements may use the same numbers as VMD elements but on the channel level the numbers must be unique for the channels related to the same VMD.

| There is no requirement to preserve the same assigned number for a containment tree element from message to message, but it is highly recommended since this makes it much easier for the DOC to process the HL7 V2 messages.

Examples

Example for Containment Tree Element Handle Assignment:

The gateway assigns the handles of the containment tree elements to

- `3` for pm:MdsDescriptor/@Handle = "My1Mds",

- `1` for pm:VmdDescriptor/@Handle = "Vmd.1",

- `2` for pm:ChannelDescriptor/@Handle = "Chan.4 and

- `1` for pm:AbstractMetricDescriptor/@Handle = "Metric.Spo2".

The OBX-4 field for the containment tree elements is set to

- `3.0.0.0` for the MDS OBX segment,

- `3.1.0.0` for the VMD OBX segment,

- `3.1.2.0` for the CHAN OBX segment and

- `3.1.2.1` for the Metric OBX segment.

##### 2:B.2.4.3 OBX-18 Equipment Instance Identifier

R8117

A SOMDS DEC Gateway / SOMDS ACM Gateway shall set the OBX-18 field to the equipment (or device) identifier on the MDS level and/or the measurement module identifier of the equipment on the VMD level as defined in section Section 3:8.3.2.10.6.

Notes

| Table 2:B.2.4.3-1 defines the mapping of the MDIB MDS meta data to the data fields of the HL7 data type EI used in the OBX-18 field.

| Table 2:B.2.4.3-2 defines the mapping of the MDIB VMD information to the data fields of the HL7 data type EI used in the OBX-18 field.

Table 2:B.2.4.3-1. OBX-18 Equipment Instance Identifier Mapping - MDS level
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
OBX-18/EI-1 | Entity Identifier | pm:Mds/ext:Extension/sdpi:EquipmentIdentifier | Universal Unique Identifier (UUID) without the prefix "urn:uuid:".
OBX-18/EI-2 | Namespace ID |  | This field is left empty.
OBX-18/EI-3 | Universal ID | pm:Mds/ext:Extension/sdpi:EquipmentIdentifier | Universal Unique Identifier (UUID) without the prefix "urn:uuid:".
OBX-18/EI-4 | Universal ID Type |  | Set to "UUID"

Table 2:B.2.4.3-2. OBX-18 Equipment Instance Identifier Mapping - VMD level
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
OBX-18/EI-1 | Entity Identifier | pm:Vmd/ext:Extension/sdpi:EquipmentIdentifier | Universal Unique Identifier (UUID) without the prefix "urn:uuid:".
OBX-18/EI-2 | Namespace ID |  | This field is left empty.
OBX-18/EI-3 | Universal ID | pm:Vmd/ext:Extension/sdpi:EquipmentIdentifier | Universal Unique Identifier (UUID) without the prefix "urn:uuid:".
OBX-18/EI-4 | Universal ID Type |  | Set to "UUID"

### 2:B.3 SDPi DEC Gateway — Mapping

#### 2:B.3.1 Scope

This chapter defines the mapping from the MDIB content as defined in this document and its underlying standards, to IHE Device Enterprise Communication (DEC) Profile messages as defined in the [IHE PCD TF-2:2019].

The SOMDS DEC Gateway represents the Device Observation Reporter (DOR) role of the IHE DEC profile.

The following sections supplement the IHE DEC Profile as appropriate. If there are no supplementing definitions, the definitions as described in the [IHE PCD TF-2:2019] will apply.

#### 2:B.3.2 Referenced Standards & Profiles

This section provides an overview about the referenced standards and profiles used in this chapter:

- [IHE PCD TF-2:2019]

- [IEEE 11073-10701:2022]

- [IEEE 11073-10700:2022]

- [ISO/IEEE 11073-10207:2017]

#### 2:B.3.3 Private MDC Codes Consideration

Please refer to general Section Appendix 2:B.2.2.

#### 2:B.3.4 HL7 Segment Descriptions

The following sections refer to the Appendix B Common Segment Descriptions of the [IHE PCD TF-2:2019].

##### 2:B.3.4.1 MSH - Message Header Segment

Please refer to general Section Appendix 2:B.2.3.1.

##### 2:B.3.4.2 PID - Patient Identification Segment

Please refer to general Section Appendix 2:B.2.3.2.

##### 2:B.3.4.3 Height and Weight Mapping

The pm:PatientContextState/pm:CoreData element may also contain elements for a patient’s height and/or weight.

R8001

If available, the SOMDS DEC Gateway shall export height and weight as OBX segments on the MDS level.

Notes

| The mapping for the height observation is defined in table Table 2:B.3.4.3.2-1 and the weight mapping in table Table 2:B.3.4.3.3-1.

###### 2:B.3.4.3.1 Height/Weight Observation Date Time Consideration

In the SDC Domain Information and Service Model, there are no explicit timestamps for the height and weight observation in pm:PatientContextState/pm:CoreData element. The only timestamp associated with the current patient context state is the pm:PatientContextState/@BindingStartTime, but this timestamp is set only once when the context was associated regardless whether height and weight has been set or updated later.

The gateway could also keep track of the pm:PatientContextState updates and evaluate height/weight value changes in the state updates. The state update timestamp has to be set by the SDC gateway consumer when it receives the new context state. That timestamp could be used for the height and/or weight observation that has been changed. The problem is that when the gateway loses connection to the PoC device it can only get the latest state update with a new version number but there is no timestamp related to the new state.

R8002

A SOMDS DEC Gateway shall use the pm:PatientContextState/@BindingStartTime as the timestamp for the height and weight observation and send new values as corrected results.

###### 2:B.3.4.3.2 Height Mapping

Table 2:B.3.4.3.2-1. OBX Height 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 "NM" since height is always represented as a decimal number.
OBX-3/CWE-1 | Identifier |  | Set to MDC code "68060".
OBX-3/CWE-2 | Text |  | Set to MDC RefId "MDC_ATTR_PT_HEIGHT".
OBX-3/CWE-3 | Name of Coding System |  | Set to coding system "MDC".
OBX-4 | Observation Sub-ID |  | Set to "<MDS>.0.0.1" 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:Height/@MeasuredValue | Note that the decimal number needs to be formatted according to the HL7 numeric value formatting rules.
OBX-6 | Units |  | HL7 data type CWE
OBX-6/CWE-1 | Identifier | pm:PatientContextState/pm:CoreData/pm:Height/pm:MeasurementUnit/@Code |
OBX-6/CWE-2 | Text | If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:PatientContextState/pm:CoreData/pm:Height/pm:MeasurementUnit/@SymbolicCodeName. | Note that MDC is the default coding system if no coding system is specified.
OBX-6/CWE-3 | Name of Coding System | "MDC" if no other coding system is specified. In all other cases, the field is set to pm:PatientContextState/pm:CoreData/pm:Height/pm:MeasurementUnit/@CodingSystem. | Note that MDC is the default coding system if no coding system is specified.
OBX-6/CWE-7 | Coding System Version ID | pm:PatientContextState/pm:CoreData/pm:Height/pm:MeasurementUnit/@CodingSystemVersion. |
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 height 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 and time format differs from the xsd date/time formats and requires a mapping accordingly (see also Example 2).

###### 2:B.3.4.3.3 Weight Mapping

Table 2:B.3.4.3.3-1. OBX Weight 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 "NM" since weight is always represented as a decimal number.
OBX-3/CWE-1 | Identifier |  | Set to MDC code "68063".
OBX-3/CWE-2 | Text |  | Set to MDC RefId "MDC_ATTR_PT_WEIGHT".
OBX-3/CWE-3 | Name of Coding System |  | Set to coding system "MDC".
OBX-4 | Observation Sub-ID |  | Set to "<MDS>.0.0.2" 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:Weight/@MeasuredValue | Note that the decimal number needs to be formatted according to the HL7 numeric value formatting rules.
OBX-6 | Units |  | HL7 data type CWE
OBX-6/CWE-1 | Identifier | pm:PatientContextState/pm:CoreData/pm:Weight/pm:MeasurementUnit /@Code |
OBX-6/CWE-2 | Text | If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:PatientContextState/pm:CoreData/pm:Weight/pm:MeasurementUnit /@SymbolicCodeName. | Note that MDC is the default coding system if no coding system is specified.
OBX-6/CWE-3 | Name of Coding System | "MDC" if no other coding system is specified. In all other cases, the field is set to pm:PatientContextState/pm:CoreData/pm:Weight/pm:MeasurementUnit /@CodingSystem. | Note that MDC is the default coding system if no coding system is specified.
OBX-6/CWE-7 | Coding System Version ID | pm:PatientContextState/pm:CoreData/pm:Weight/pm:MeasurementUnit/@CodingSystemVersion. |
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 weight 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 and time format differs from the xsd date/time formats and requires a mapping accordingly (see also Example 2).

##### 2:B.3.4.4 PV1 - Patient Visit Segment

Please refer to general Section Appendix 2:B.2.3.3.

##### 2:B.3.4.5 OBR - Observation Request Segment

The HL7 Observation Request (OBR) segment requires a mapping from the SDC containment tree and metric data to the OBR segment fields.

###### 2:B.3.4.5.1 OBR-2 Placer Order Number

R8003

For the IHE DEC profile, the SOMDS DEC Gateway shall set the OBR-2 field to the identifier of the Device Observation Reporter (DOR) of the IHE DEC gateway (not the individual device identifier).

Notes

| For further information, please refer to the [IHE PCD TF-2:2019].

###### 2:B.3.4.5.2 OBR-3 Filler Order Number

R8004

For the IHE DEC profile, the SOMDS DEC Gateway shall set the OBR-3 field to the identifier of the Device Observation Reporter (DOR) of the IHE DEC gateway (not the individual device identifier).

Notes

| For further information, please refer to the [IHE PCD TF-2:2019].

###### 2:B.3.4.5.3 OBR-4 Universal Service ID

R8005

For the IHE DEC profile, the SOMDS DEC Gateway shall set the OBR-4 field to the service identifier of the SOMDS Provider.

Notes

| For further information, please refer to the [IHE PCD TF-2:2019].

SDPi 2.0 Supplement Note: In this version of the SDPi Supplement, this section needs to be updated in order to be compliant with the [IHE PCD TF-2:2019]. The following issues need more investigations and discussions: Mapping of the MDIB-provided device types to SNOMED codes Licensing requirements for utilizing SNOMED codes Utilizing MDC codes instead of SNOMED which requires a change in the [IHE PCD TF-2:2019] Defining the special requirements for infusion pumps Finalization of service ids

###### 2:B.3.4.5.4 OBR-7 Observation Date/Time

The OBR-7 field specifies the time point or start of time interval for all OBX segments within the scope of this OBR segment, that is, OBX segments that are part of the ORDER_OBSERVATION segment group, that do not specify an overriding time point in the OBX-14 field.

The presence of an overriding time point in OBX-14 indicates an episodic measurement such as non-invasive blood pressure.

The absence of an overriding time point in the OBX-14 field implies that this is an instance of a periodically sampled observation with a time stamp given by OBR-7 field.

R8037

A SOMDS DEC Gateway shall export continuously (periodically) measured metrics periodically at a defined interval.

Notes

| It is up to the SOMDS DEC Gateway how the export interval is defined. The interval might be a fixed interval of e.g., 30 seconds, or a configurable interval ranging e.g., between 10 seconds and 2 minutes.

R8038

A SOMDS DEC Gateway shall set the OBR-7 field to the start date and time of current export interval.

Notes

| If, for example, the export interval is set to 30 seconds, the SOMDS DEC Gateway will export HL7 messages every 30 seconds with the OBR-7 field set to start date and time of the interval e.g., 20231030155930, 20231030160000, 20231030160030, and so on.

R8006

A SOMDS DEC Gateway shall export the latest metric value of all continuously (periodically) measured metrics with a pm:AbstractMetricState/pm:MetricValue/@DeterminationTime which is equal or greater than the start date and time of the current interval, and less than the start date and time of the next export interval.

Notes

| The OBR-7 field is set to the start time of the interval. The individual periodic metric value @DeterminationTime is basically ignored, but has to be within the time boundaries of the current export interval.

R8007

For exporting episodic metric values and the absence of any continuously measured metric values for the current export interval, a SOMDS DEC Gateway shall set the OBR-7 field to the start date and time of current export interval.

Notes

| Episodic metric values are usually exported along with the periodic metric values in the same export intervals. However, if a device does not provide periodic metric values in the current export interval, episodic metric values are exported in current export interval without periodic metric values.

| The pm:AbstractMetricState/pm:MetricValue/@DeterminationTime of an episodic metric value is set in the OBX-14 field and will override the timestamp defined in the OBR-7 field.

| Only metrics that fulfil certain criteria are exported by the SOMDS DEC Gateway. Please refer to R8018 and R8017 for further information.

###### 2:B.3.4.5.5 OBR-8 Observation End Date/Time

R8008

A SOMDS DEC Gateway may set the OBR-8 field to the end date and time of the current export interval.

Notes

| This requirement relates to the OBR-7 field mapping. Please refer to Appendix 2:B.3.4.5.4 for further information.

| If, for example, the export interval is set to 30 seconds, the SOMDS DEC Gateway will export HL7 messages every 30 seconds with the OBR-7 field set to start date and time of the current interval and the OBR-8 field set to the start date and time of the next interval e.g., 20231030155930|20231030160000, 20231030160000|20231030160030, and so on.

###### 2:B.3.4.5.6 OBR-10 Collector Identifier

R8009

A SOMDS DEC Gateway shall set the OBR-10 field to the operator (user) information if available.

The field is left empty if there is no valid SDC operator context.

Notes

| Table 2:B.3.4.5.6-1 defines the mapping of the SDC operator context information to the data fields of the HL7 data type XCN used in the OBR-10 field.

| The SDC operator context is only valid when the pm:OperatorContextState/@ContextAssociation is set to "Assoc" and a pm:OperatorContextState/@BindingStartTime is set.

Table 2:B.3.4.5.6-1. OBR-10 Operator Information Mapping
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
OBR-10/XCN-1 | ID Number | pm:OperatorContextState/pm:Identification /@Extension | The @Extension attribute contains the unique operator identifier. Note that the field may contain a null value indicating that the identifier is missing.
OBR-10/XCN-2 | Family Name | pm:OperatorContextState/pm:OperatorDetails | HL7 data type FN
OBR-10/XCN-2.1 | Surname | /pm:Familyname |
OBR-10/XCN-3 | Given Name | pm:OperatorContextState/pm:OperatorDetails/pm:Givenname |
OBR-10/XCN-4 | Second and Further Given Names or Initials | pm:OperatorContextState/pm:OperatorDetails/pm:Middlename |
OBR-10/XCN-6 | Prefix (e.g., DR) | pm:OperatorContextState /pm:OperatorDetails /pm:Title |
OBR-10/XCN-9 | Assigning Authority | pm:OperatorContextState /pm:Identification | HL7 data type HD
OBR-10/XCN-9.1 | Namespace ID | /@Root | The @Root contains the unique identification of the HDO. Note that if the HDO identifier is not defined, the XCN-9 field is left empty.

##### 2:B.3.4.6 OBX - Observation/Result Segment

The HL7 Observation/Result (OBX) segment requires a mapping from the SDC containment tree and metric items to the OBX segment fields. More information about the containment tree mapping can be found in Appendix A Mapping ISO/IEEE 11073 Domain Information Model to HL7 in [IHE PCD TF-2:2019].

###### 2:B.3.4.6.1 OBX-1 Set ID - OBX

Please refer to the [IHE PCD TF-2:2019] OBX-1 Set ID - OBX for further information.

###### 2:B.3.4.6.2 OBX-2 Value Type

R8010

A SOMDS DEC Gateway shall set the OBX-2 field to the metric value type code as defined in HL7 table 0125.

Notes

| Table 2:B.3.4.6.2-1 defines the mapping of the SDC metric type to the data fields of the HL7 data type ID used in the OBX-2 field.

R8011

A SOMDS DEC Gateway shall leave the OBX-2 field empty for OBX segments defining the SOMDS Provider's MDS, VMD, or CHAN containment tree elements.

Table 2:B.3.4.6.2-1. OBX-2 Value Type Mapping
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
OBX-2/ID-1 | Coded Value for HL7-Defined Tables | "NM" if the metric state is of type pm:NumericMetricState. "ST" if the metric state is of type pm:StringMetricState. "CWE" if the metric state is of type pm:EnumStringMetricState. |

###### 2:B.3.4.6.3 OBX-3 Observation Identifier

Please refer to general Section Appendix 2:B.2.4.1.

###### 2:B.3.4.6.4 OBX-4 Observation Sub-ID

Please refer to general Section Appendix 2:B.2.4.2.

###### 2:B.3.4.6.5 OBX-5 Observation Value

R8016

A SOMDS DEC Gateway shall set the OBX-5 field to the value of the SDC metric.

Notes

| The formatting of the data depends on the data type.

R8036

For a device-related element such as MDS, VMD, or channel, the OBX-5 field shall be left empty.

R8017

A SOMDS DEC Gateway shall only export metrics with a pm:AbstractMetricValue/pm:MetricQuality/@Validity set to Vld (Valid) or Vldated (Validated Data).

Notes

| Metrics with a different @Validity are skipped/ignored.

R8018

A SOMDS DEC Gateway shall only export metrics with the pm:AbstractMetricDescriptor/@MetricCategory set to Msrmt (Measurement), Clc (Calculation) or Set (Setting).

Notes

| Metrics with a different @MetricCategory are skipped/ignored.

###### 2:B.3.4.6.5.1 Numeric Metric

R8019

For each numeric metric that complies with R8017 and R8018, a SOMDS DEC Gateway shall set the OBX-5 field to the pm:NumericMetricState/pm:MetricValue/@Value.

Notes

| Note that the decimal number needs to be formatted according to the HL7 numeric value formatting rules.

| Note that sample array metrics are not supported by the SOMDS DEC Gateway.

###### 2:B.3.4.6.5.2 String Metric

R8020

For each string metric that complies with R8017 and R8018, a SOMDS DEC Gateway shall set the OBX-5 field to the pm:StringMetricState/pm:MetricValue/@Value.

###### 2:B.3.4.6.5.3 Enumeration String Metric

R8021

For each enumeration string metric that complies with R8017 and R8018, a SOMDS DEC Gateway shall set the OBX-5 field to a coded element value.

Notes

| Table 2:B.3.4.6.5.3-1 defines the mapping of the SDC coded element value to the data fields of the HL7 data type CWE used in the OBX-5 field.

| The pm:EnumStringMetricState/pm:MetricValue/@Value contains the string of the selected enumerated element. The actual coded element value can be retrieved from the pm:EnumStringMetricDescriptor/pm:AllowedValue list by comparing the pm:EnumStringMetricState/pm:MetricValue/@Value with the pm:EnumStringMetricDescriptor/pm:AllowedValue/pm:Value.

| If a match has been found, the pm:EnumStringMetricDescriptor/pm:AllowedValue/pm:Type is required to be mapped as defined in Table 2:B.3.4.6.5.3-1.

| If no matching value has been found, the enumeration is treated as a string metric and the pm:EnumStringMetricState/pm:MetricValue/@Value is required to be set in the OBX-5 field, and the OBX-2 is required to be set to "ST" (see also Table 2:B.3.4.6.2-1 and R8020).

R8022

If a private MDC code is used for the coding of the SDC coded element value in OBX-5 mapping, a SOMDS DEC Gateway shall map the identifier as described in Section Appendix 2:B.2.2.

Table 2:B.3.4.6.5.3-1. OBX-5 Enumeration String Metric Value Mapping
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
OBX-5/CWE-1 | Identifier | pm:EnumStringMetricDescriptor/pm:AllowedValue/pm:Type/@Code |
OBX-5/CWE-2 | Text | If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:EnumStringMetricDescriptor/pm:AllowedValue/pm:Type/@SymbolicCodeName. | Note that MDC is the default coding system if no coding system is specified.
OBX-5/CWE-3 | Name of Coding System | "MDC" if no other coding system is specified. In all other cases, the field is set to pm:EnumStringMetricDescriptor/pm:AllowedValue/pm:Type/@CodingSystem. | Note that MDC is the default coding system if no coding system is specified.
OBX-5/CWE-7 | Coding System Version ID | pm:EnumStringMetricDescriptor/pm:AllowedValue/pm:Type/@CodingSystemVersion. |

###### 2:B.3.4.6.6 OBX-6 Units

R8023

For each numeric metric, a SOMDS DEC Gateway shall set the OBX-6 field to a measurement unit.

Notes

| Table 2:B.3.4.6.6-1 defines the mapping of the SDC measurement unit to the data fields of the HL7 data type CWE used in the OBX-6 field.

| For a device-related element such as MDS, VMD, CHANNEL, or other metric types, the OBX-6 field is left empty.

R8024

If a private MDC code is used for the coding of the SDC measurement unit of a metric, a SOMDS DEC Gateway shall map the identifier as described in Section Appendix 2:B.2.2.

Table 2:B.3.4.6.6-1. OBX-6 Measurement Unit Mapping
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
OBX-6/CWE-1 | Identifier | pm:NumericMetricDescriptor/pm:Unit/@Code |
OBX-6/CWE-2 | Text | If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:NumericMetricDescriptor/pm:Unit/@SymbolicCodeName. | Note that MDC is the default coding system if no coding system is specified.
OBX-6/CWE-3 | Name of Coding System | "MDC" if no other coding system is specified. In all other cases, the field is set to pm:NumericMetricDescriptor/pm:Unit/@CodingSystem. | Note that MDC is the default coding system if no coding system is specified.
OBX-6/CWE-7 | Coding System Version ID | pm:NumericMetricDescriptor/pm:Unit/@CodingSystemVersion. |

###### 2:B.3.4.6.7 OBX-7 Reference Range

R8026

A SOMDS DEC Gateway shall define the range of the alert limits on the metric level, if the @Handle of the metric is referenced by a pm:LimitAlertConditionDescriptor in the pm:LimitAlertConditionDescriptor/pm:Source list, by the format `<Lower Limit> - <Upper Limit>` where

- `<Lower Limit>` is set to pm:LimitAlertConditionState/pm:Limits/@Lower and

- `<Upper Limit>` is set to pm:LimitAlertConditionState/pm:Limits/@Upper.

Notes

| Note that the decimal number needs to be formatted according to the HL7 numeric value formatting rules.

R8025

A SOMDS DEC Gateway shall not set this field to the device measurement range capability for device related segments.

Notes

| As stated in [IHE PCD TF-2:2019] the reference range can only be set for device related segments (e.g., Channel). Within SDC the device measurement range refers to each metric and cannot be populated on higher levels in the containment tree.

###### 2:B.3.4.6.8 OBX-8 Abnormal Flags

The OBX-8 field is not required to be set since the gateway exports valid and validated metric data only.

R8027

A SOMDS DEC Gateway shall leave the OBX-8 field empty as specified in the [IHE PCD TF-2:2019] for valid and validated metric values.

###### 2:B.3.4.6.9 OBX-11 Observation Result Status

R8028

For a device-related element such as MDS, VMD, or CHANNEL, a SOMDS DEC Gateway shall set the OBX-11 field to "X".

R8029

For metrics with the pm:AbstractMetricValue/pm:MetricQuality/@Validity set to Vld (Valid), a SOMDS DEC Gateway shall set the OBX-11 field to "R".

R8030

For metrics with the pm:AbstractMetricValue/pm:MetricQuality/@Validity set to Vldated (Validated Data), a SOMDS DEC Gateway shall set the OBX-11 field to "F".

###### 2:B.3.4.6.10 OBX-14 Date/Time of Observation

R8031

A SOMDS DEC Gateway shall set the OBX-14 field to the date and time of the intermittently measured metric value.

Notes

| Intermittently measured metrics have the pm:AbstractMetricDescriptor/@MetricAvailability set to "Intr".

| Table 2:B.3.4.6.10-1 defines the mapping of the SDC metric measurement timestamp to the data fields of the HL7 data type DTM used in the OBX-14 field.

Table 2:B.3.4.6.10-1. OBX-14 Metric Measurement Timestamp Mapping
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
OBR-14/DTM-1 | Date/Time | pm:EnumStringMetricState/pm:MetricValue/@DeterminationTime pm:NumericMetricState/pm:MetricValue/@DeterminationTime pm:StringMetricState/pm:MetricValue/@DeterminationTime | Note that the HL7 date and time format differs from the xsd date/time formats and requires a mapping accordingly (see also Example 2).

###### 2:B.3.4.6.11 OBX-16 Responsible Observer

R8032

If available, a SOMDS DEC Gateway shall set the OBX-16 field to the operator.

Notes

| Please refer to Appendix 2:B.3.4.5.6 for further information.

| The [IHE PCD TF-2:2019] requires only the map the "ID Number", and optionally the "Family Name" and "Given Name" in this field, whereas the OBR-10 field may contain additional information about the operator.

###### 2:B.3.4.6.12 OBX-17 Observation Method

R8033

A SOMDS DEC Gateway shall set the OBX-17 field to one of the coded terms as specified in Table 2:B.3.4.6.12-1, depending on the pm:AbstractMetricDescriptor/@MetricCategory (Category) and the pm:AbstractMetricDescriptor/@DerivationMethod (Derivation).

R8039

A SOMDS DEC Gateway should repeat the OBX-17 field to express the pm:AbstractMetricDescriptor/@MetricAvailability as specified in Table 2:B.3.4.6.12-2.

Table 2:B.3.4.6.12-1. OBX-17 Observation Method Mapping
SDC Category | SDC Derivation | HL7 OBX-17 Field Value
--- | --- | ---
Msmt | Auto | AMEAS^auto-measurement^MDC
Msmt | Man | MMEAS^manual-measurement^MDC
Clc | Auto | ACALC^auto-calculation^MDC
Clc | Man | MCALC^manual-calculation^MDC
Set | Auto | ASET^auto-setting^MDC
Set | Man | MSET^manual-setting^MDC

Table 2:B.3.4.6.12-2. OBX-17 Observation Method Mapping
SDC MetricAvailability | HL7 OBX-17 Field Value
--- | ---
Cont | 69123^MDC_OBS_CTS^MDC
Int | 69124^MDC_OBS_NONCTS^MDC

###### 2:B.3.4.6.13 OBX-18 Equipment Instance Identifier

Please refer to general Section Appendix 2:B.2.4.3.

###### 2:B.3.4.6.14 OBX-20 Observation Site

R8034

If available for the metric, a SOMDS DEC Gateway shall set the OBX-20 field to body site.

Notes

| If the pm:AbstractMetricState/pm:BodySite element and the pm:AbstractMetricDescriptor/pm:BodySite element are available, the body site defined in the pm:AbstractMetricState is the preferred pm:BodySite element to be mapped.

| If pm:BodySite element list contains more than one pm:BodySite element, only the first entry of the list is used for the mapping.

| Table 2:B.3.4.6.14-1 defines the mapping of the SDC body site element to the data fields of the HL7 data type CWE used in the OBX-20 field.

| For a device-related element such as MDS, VMD, or CHANNEL, the OBX-20 field is left empty.

R8035

If a private MDC code is used for the coding of a body site, a SOMDS DEC Gateway shall map the identifier as described in Section Appendix 2:B.2.2.

Table 2:B.3.4.6.14-1. OBX-20 Observation Site (Body Site) Mapping
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
OBX-20/CWE-1 | Identifier | pm:AbstractMetricState/pm:BodySite/@Code or pm:AbstractMetricDescriptor/pm:BodySite/@Code, if pm:BodySite is not available in pm:AbstractMetricState | Note that only the first pm:BodySite element from the list is required to be mapped.
OBX-20/CWE-2 | Text | If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:AbstractMetricState/pm:BodySite/@SymbolicCodeName or pm:AbstractMetricDescriptor/pm:BodySite@SymbolicCodeName, if pm:BodySite is not available in pm:AbstractMetricState | Note that MDC is the default coding system if no coding system is specified. Note that only the first pm:BodySite element from the list is required to be mapped.
OBX-20/CWE-3 | Name of Coding System | "MDC" if no other coding system is specified. In all other cases, the field is set to pm:AbstractMetricState/pm:BodySite/@CodingSystem or pm:AbstractMetricDescriptor/pm:BodySite/@CodingSystem, if pm:BodySite is not available in pm:AbstractMetricState | Note that MDC is the default coding system if no coding system is specified. Note that only the first pm:BodySite element from the list is required to be mapped.
OBX-20/CWE-7 | Coding System Version ID | pm:AbstractMetricState/pm:BodySite/@CodingSystemVersion or pm:AbstractMetricDescriptor/pm:BodySite/@CodingSystemVersion, if pm:BodySite is not available in pm:AbstractMetricState | Note that only the first pm:BodySite element from the list is required to be mapped.

### 2:B.4 SDPi ACM Gateway — Mapping

#### 2:B.4.1 Scope

This chapter defines the mapping from the MDIB content as defined in this document and its underlying standards, to IHE Alert Communication Management (ACM) Profile messages as defined in the [IHE PCD TF-2:2019].

The SOMDS ACM Gateway represents the Alarm Reporter (AR) role of the IHE ACM profile.

The following sections supplement the IHE ACM Profile as appropriate. If there are no supplementing definitions, the definitions as described in the [IHE PCD TF-2:2019] apply.

#### 2:B.4.2 Referenced Standards & Profiles

This section provides an overview about the referenced standards and profiles used in this chapter:

- [IHE PCD TF-2:2019]

- [IEEE 11073-10702:202x]

- [IEEE 11073-10701:2022]

- [IEEE 11073-10700:2022]

- [ISO/IEEE 11073-10207:2017]

#### 2:B.4.3 Private MDC Codes Consideration

Please refer to general Section Appendix 2:B.2.2.

#### 2:B.4.4 HL7 Segment Descriptions

The following sections refer to the Appendix B Common Segment Descriptions of the [IHE PCD TF-2:2019].

##### 2:B.4.4.1 MSH - Message Header Segment

Please refer to general Section Appendix 2:B.2.3.1.

##### 2:B.4.4.2 PID - Patient Identification Segment

Please refer to general Section Appendix 2:B.2.3.2.

##### 2:B.4.4.3 PV1 - Patient Visit Segment

Please refer to general Section Appendix 2:B.2.3.3.

##### 2:B.4.4.4 OBR - Observation Request Segment

The HL7 Observation Request (OBR) segment requires a mapping from the SDC containment tree and metric data to the OBR segment fields.

###### 2:B.4.4.4.1 OBR-2 Placer Order Number

R8050

For the IHE ACM profile, the SOMDS ACM Gateway shall set the OBR-2 field to the identifier of the Alarm Reporter (AR) of the IHE ACM gateway (not the individual device identifier).

Notes

| For further information, please refer to the [IHE PCD TF-2:2019].

###### 2:B.4.4.4.2 OBR-3 Filler Order Number

R8051

A SOMDS ACM Gateway shall set the OBR-3 field to a unique identifier for the status to the alert indication.

Notes

| For further information, please refer to the [IHE PCD TF-2:2019].

The content depends on the state of the alert event:

R8052

For the initial alert event announcement message, a SOMDS ACM Gateway shall set the OBR-3/EI-1 field to the unique identifier for the alert event.

Notes

| This identifier consists of the pm:AlertConditionState/@DescriptorHandle plus the SequenceId plus the pm:AlertConditionState/@StateVersion of the state report.

Examples

Unique Alert Event Identifier:

"0x5C00009D.ae3170b5-4fd7-43b5-94c6-71b933342ffe.45"

R8053

For the subsequent alert event messages for the same alert event, a SOMDS ACM Gateway shall set the OBR-3/EI-1 field to the unique identifier of the alert event message that relates to the same alert event as announced in the initial alert event message.

Notes

| This identifier is usually defined by the gateway.

Examples

Unique Alert Event Message Identifier:

"bd3170b6-4fd7-43b5-94c6-71b935642fac"

The table Table 2:B.4.4.4.2-1 defines the mapping of the Alert Event Identifier to the data fields of the HL7 data type EI used in the OBR-3 field.

Table 2:B.4.4.4.2-1. OBR-3 Filler Order Number Mapping
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
OBR-3/EI-1 | Entity Identifier |  | Set either to the unique alert event identifier or alert event message identifier. Please refer to the description above for further information.
OBR-3/EI-2 | Namespace ID |  | Field is required to be set to the EI-2 field as defined in table Appendix 2:B.4.4.7.
OBR-3/EI-3 | Universal ID |  | Field is required to be set to the EI-3 field as defined in table Appendix 2:B.4.4.7.
OBR-3/EI-4 | Universal ID Type |  | Field is required to be set to the EI-4 field as defined in table Appendix 2:B.4.4.7.

###### 2:B.4.4.4.3 OBR-4 Universal Service Identifier

R8054

A SOMDS ACM Gateway shall set the OBR-4 field to "196616^MDC_EVT_ALARM^MDC".

###### 2:B.4.4.4.4 OBR-7 Observation Date/Time

R8055

A SOMDS ACM Gateway shall set the OBR-7 field to the date and time at which the Alert Reporter (AR) of the IHE ACM gateway created the alert event message to be sent.

Notes

| Please refer to the Appendix B B.7.1 OBR Observation Request Segment in ACM Transaction [PCD-04] of the [IHE PCD TF-2:2019] for further information.

###### 2:B.4.4.4.5 OBR-29 Parent

R8056

A SOMDS ACM Gateway shall set the OBR-29 field to the unique alert event identifier of the initial alert event message as defined for the OBR-3 field.

Notes

| Please refer to Table 2:B.4.4.4.2-1 for further information.

| The field is left empty for the initial alert event announcement message which contains the unique alert event identifier in the OBR-3 field.

| In all subsequent alert event messages, the OBR-29 field is set to the initial unique alert event identifier from the OBR-3 field.

| The table Table 2:B.4.4.4.5-1 defines the mapping of the Alert Event Identifier to the data fields of the HL7 data type EIP used in the OBR-29 field.

Table 2:B.4.4.4.5-1. OBR-29 Parent Mapping
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments
--- | --- | --- | ---
OBR-29/EIP-2 | Filler Assigned Identifier |  | HL7 data type EI
OBR-29/EIP-2/EI-1 | Entity Identifier |  | Set to the unique alert event identifier. Please refer to the Table 2:B.4.4.4.2-1 for further information.
OBR-29/EIP-2/EI-2 | Namespace ID |  | Field is required to be set to the EI-2 field as defined in table Appendix 2:B.4.4.7.
OBR-29/EIP-2/EI-3 | Universal ID |  | Field is required to be set to the EI-3 field as defined in table Appendix 2:B.4.4.7.
OBR-29/EIP-2/EI-4 | Universal ID Type |  | Field is required to be set to the EI-4 field as defined in table Appendix 2:B.4.4.7.

##### 2:B.4.4.5 OBX - Observation/Result Segment

The OBX segment is utilized to export seven alert event attributes in the following order as defined in the [IHE PCD TF-2:2019]:

- Event identification

- Source identification

- Event phase

- Alert state

- Inactivation State

- Alert Priority

- Alert Type

The OBX segments representing the alert event attributes are preceded by up to three device-related OBX segments for the MDS, VMD and CHANNEL (see also Appendix 2:B.4.4.7.1 for further information).

##### 2:B.4.4.6 Containment Tree Hierarchy Representation

Please refer to general Section Appendix 2:B.2.4.2.

##### 2:B.4.4.7 Equipment Instance Identifier Mapping

Please refer to general Section Appendix 2:B.2.4.3.

###### 2:B.4.4.7.1 Device-related OBX Segments

R8057

A SOMDS ACM Gateway shall export device-related OBX segments, which define the hierarchical relationship of the alert event in the device’s containment tree.

Notes

| There might be up to three device-related OBX segments for the MDS, VMD, and CHANNEL dependent on the specific device’s containment tree. The general mapping of the device-related OBX segments is defined in table Table 2:B.4.4.7.1-1.

R8058

If a private MDC code is used for the coding of the SDC device-related element, the identifier shall be mapped as described in Section Appendix 2:B.2.2.

Table 2:B.4.4.7.1-1. OBX Device-related Element 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 |  | Field is required to be left empty.
OBX-3 | Observation Identifier | pm:Mds or pm:Vmd or pm:Channel/pm:Type/@Code | Please refer to Appendix 2:B.4.4.7.1.1 for further information.
OBX-4 | Observation Sub-ID |  | Set to "<MDS>.<VMD>.<CHAN>.0" where <MDS>, <VMD>, and <CHAN> are the numbers of the device’s containment tree levels assigned by the gateway. Please refer to Appendix 2:B.4.4.6 for further information.
OBX-5 | Observation Value |  | Always left empty.
OBX-11 | Observation Result Status |  | Set to "X".
OBX-18 | Equipment Instance Identifier |  | Please refer to Appendix 2:B.4.4.7 for further information. Note that this field is only required to be set for the MDS and/or the VMD element if applicable. Otherwise, this field is required to be left empty or omitted.

###### 2:B.4.4.7.1.1 Observation Identifier Mapping

Please refer to general Section Appendix 2:B.2.4.1.

| The Observation Identifier Mapping on metric level is only used for the Source Identification OBX segment (please refer to Appendix 2:B.4.4.7.3 for further information).

Example 3. OBX Device-related Elements Mapping

OBX|1||69965^MDC_DEV_MON_PHYSIO_MULTI_PARAM_MDS^MDC|1.0.0.0|||||||X|||||||XY150Z0409^^0009FBFFFF059322^EUI-64

OBX|2||69710^MDC_DEV_ANALY_PRESS_BLD_VMD^MDC|1.1.0.0|||||||X

OBX|3||69855^MDC_DEV_METER_PRESS_BLD_CHAN^MDC|1.1.1.0|||||||X

###### 2:B.4.4.7.2 Event Identification OBX Segment

R8061

A SOMDS ACM Gateway shall export an Event Identification OBX segment which identifies the alert event.

Notes

| The mapping differs for physiological alert events and technical/advisory alert events (please refer also to Table 2:B.4.4.7.8-1 for further information).

R8077

A SOMDS ACM Gateway shall report the Alert Event Phase as "update" when there are more updates than just the Alert Priority as specified in Table 2:B.4.4.7.2.1-1 for the "update" Alert Event Phase.

###### 2:B.4.4.7.2.1 Date/Time Mapping

R8062

A SOMDS ACM Gateway shall set the OBX-14 field of the Event Identification OBX segment to the date/time of the alert event status change.

Notes

| This either applies to a change of the pm:AlertConditionState or the pm:AlertSignalState of the signals related to the alert condition.

| The date/time to be set in the OBX-14 field relates to the alert event phase. Table 2:B.4.4.7.2.1-1 defines the date/time mapping per alert event phase.

| The HL7 date and time format differs from the xsd date/time formats and requires a mapping accordingly (please refer to Example 2 for further information).

Table 2:B.4.4.7.2.1-1. Date/Time Alert Event Phase Mapping
IHE ACM Alert Event Phase | SDC Alert Condition/Signal State
--- | ---
start | pm:AlertConditionState/pm:DeterminationTime which represents the alert onset date/time.
continue | The gateway may resend the unchanged alert event information, for example, on a regular basis in order to mitigate the risk of an alert message loss, or after a reconnection to the Alert Manager or Alert Consumer in order to synchronize the current alert status. In this case, the date/time is determined by the gateway for this message.
end | pm:AlertConditionState/pm:DeterminationTime which represents the end of the alert condition without latching.
update | pm:AlertConditionState/pm:DeterminationTime or pm:AlertSignalState/pm:DeterminationTime for any updates/changes to be reported but does not match any other Alert Event Phase mapping criteria. Note that the pm:AlertConditionState/pm:DeterminationTime changes only when the @Presence attribute is updated. The gateway has to determine the date/time by itself when other attributes have changed (e.g., alert priority).
escalate | pm:AlertConditionState/pm:DeterminationTime which represents the change of the alert priority. Please refer to R8077. Note that the pm:AlertConditionState/pm:DeterminationTime changes only when the @Presence attribute is updated. The gateway has to determine the date/time by itself when other attributes have changed (e.g., alert priority).
deescalate | pm:AlertConditionState/pm:DeterminationTime which represents the change of the alert priority. Please refer to R8077. Note that the pm:AlertConditionState/pm:DeterminationTime changes only when the @Presence attribute is updated. The gateway has to determine the date/time by itself when other attributes have changed (e.g., alert priority).
reset | pm:AlertSignalState/pm:DeterminationTime which represents the end of a latched alert event state.

###### 2:B.4.4.7.2.2 Physiological Alerts

The event identification mapping for a physiological alert (alarm or advisory) is defined in table Table 2:B.4.4.7.2.2-1.

R8063

If a private MDC code is used for the coding of the SDC coded element value, the identifier shall be mapped as described in Section Appendix 2:B.2.2.

Table 2:B.4.4.7.2.2-1. OBX Event Identification Mapping - Physiological Alert Event
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 | pm:AlertConditionDescriptor/pm:Type/@Code |
OBX-3/CWE-2 | Text | If @Code is an MDC code, this field is required to contain the RefId of the MDC code. In all other cases, the field is required to be set to the pm:AlertConditionDescriptor/pm:Type/@SymbolicCodeName. | Note that MDC is the default coding system if no coding system is specified.
OBX-3/CWE-3 | Name of Coding System | "MDC" if no other coding system is specified. In all other cases, the field is required to be set to pm:AlertConditionDescriptor/pm:Type/@CodingSystem. | Note that MDC is the default coding system if no coding system is specified.
OBX-3/CWE-7 | Coding System Version ID | pm:AlertConditionDescriptor/pm:Type/@CodingSystemVersion. |
OBX-4 | Observation Sub-ID |  | Set to "<MDS>.<VMD>.<CHAN>.<METRIC>.1" where <MDS>, <VMD>, <CHAN>, and <METRIC> are the numbers of the device’s containment tree levels assigned by the gateway. Please refer to Appendix 2:B.4.4.6 for further information.
OBX-5 | Observation Value | pm:AlertConditionDescriptor/pm:Type/pm:ConceptDescription |
OBX-11 | Observation Result Status |  | Set to "R".
OBX-14 | Date/Time of Observation |  | Please refer to Appendix 2:B.4.4.7.2.1 for further information.
OBX-18 | Equipment Instance Identifier |  | Please refer to Appendix 2:B.4.4.7 for further information.

Example 4. OBX Event Identification Mapping - Physiological Alert Event

OBX|4|ST|196648^MDC_EVT_HI^MDC|1.1.1.1.1|**ABPs 119>110||||||R|||20191121102600||||2A144AFE-7AD5-4549-95F9-BD805319CB47^^2A144AFE-7AD5-4549-95F9-BD805319CB47^UUID

###### 2:B.4.4.7.2.3 Technical Alerts

The event identification mapping for a technical alert (alarm or advisory) is defined in table Table 2:B.4.4.7.2.3-1.

R8064

If a private MDC code is used for the coding of the SDC coded element value, the identifier shall be mapped as described in Section Appendix 2:B.2.2.

Table 2:B.4.4.7.2.3-1. OBX Event Identification Mapping - Technical Alert Event
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 "CWE".
OBX-3/CWE-1 | Identifier |  | Set to MDC code "196616".
OBX-3/CWE-2 | Text |  | Set to MDC RefId "MDC_EVT_ALARM".
OBX-3/CWE-3 | Name of Coding System |  | Set to coding system "MDC".
OBX-4 | Observation Sub-ID |  | Set to "<MDS>.<VMD>.<CHAN>.<METRIC>.1" where <MDS>, <VMD>, <CHAN>, and <METRIC> are the numbers of the device’s containment tree levels assigned by the gateway. Please refer to Appendix 2:B.4.4.6 for further information.
OBX-5 | Observation Value |  | HL7 data type CWE
OBX-5/CWE-1 | Identifier | pm:AlertConditionDescriptor/pm:Type /@Code |
OBX-5/CWE-2 | Text | If @Code is an MDC code, this field is required to contain the RefId of the MDC code. In all other cases, the field is required to be set to the pm:AlertConditionDescriptor/pm:Type/@SymbolicCodeName. | Note that MDC is the default coding system if no coding system is specified.
OBX-5/CWE-3 | Name of Coding System | "MDC" if no other coding system is specified. In all other cases, the field is required to be set to pm:AlertConditionDescriptor/pm:Type/@CodingSystem. | Note that MDC is the default coding system if no coding system is specified.
OBX-5/CWE-7 | Coding System Version ID | pm:AlertConditionDescriptor/pm:Type/@CodingSystemVersion. |
OBX-5/CWE-9 | Original Text | pm:AlertConditionDescriptor/pm:Type /pm:ConceptDescription |
OBX-14 | Date/Time of Observation |  | Please refer to Appendix 2:B.4.4.7.2.1 for further information.
OBX-11 | Observation Result Status |  | Set to "R".
OBX-18 | Equipment Instance Identifier |  | Please refer to Appendix 2:B.4.4.7 for further information.

Example 5. OBX Event Identification Mapping - Technical Alert Event

OBX|4|CWE|196616^MDC_EVT_ALARM^MDC|1.1.1.1.1|196882^MDC_EVT_LEADS_OFF^MDC^^!! ECG Leads Off||||||R|||||||2A144AFE-7AD5-4549-95F9-BD805319CB47^^2A144AFE-7AD5-4549-95F9-BD805319CB47^UUID

###### 2:B.4.4.7.3 Source Identification OBX Segment

R8065

A SOMDS ACM Gateway shall export a Source Identification OBX segment, which identifies the source that led to the alert event.

Notes

| The mapping differs for physiological alert events and technical/advisory alert events (refer to Table 2:B.4.4.7.8-1 for further information).

| For physiological alert conditions, the alert event usually relates to a metric and its corresponding value that triggered the alert event. The pm:AlertConditionDescriptor/pm:Source element contains the handle to the related metric for the alert condition.

| For technical alert conditions, the alert event usually relates to a device-related element such as the MDS, a VMD, a CHANNEL, or METRIC. The pm:AlertConditionDescriptor/pm:Source element usually contains the handle to the device-related element. If pm:Source is empty, the alert condition relates to the device-related element which is the parent of the alert system to which the alert condition is assigned to.

R8059

For a physiological alert event, a SOMDS ACM Gateway shall set the OBX-3 field in the Appendix 2:B.4.4.7.3 to the source identifier.

R8060

For a technical or advisory alert event, a SOMDS ACM Gateway shall set the OBX-5 field in the Appendix 2:B.4.4.7.3 to the source identifier.

###### 2:B.4.4.7.3.1 Physiological Alerts

R8066

A SOMDS ACM Gateway shall map the source identification for physiological alerts (alarms or advisories) to an OBX segment as defined in Appendix 2:B.3.4.6. The gateway captures the state of the related metric at the time the alert event occurred.

Notes

| In SDC, the metric value that led to the physiological alert event is required to be reported in a state update before the pm:AlertConditionState update is reported. That is, the latest state of the metric related to the alert condition contains the value that led to the alert event when the pm:AlertConditionState/@Presence changed from "false" to "true".

R8067

A SOMDS ACM Gateway shall set the OBX-4 Observation Sub-ID to "<MDS>.<VMD>.<CHAN>.<METRIC>.2" where <MDS>, <VMD>, <CHAN>, and <METRIC> are the numbers of the device’s containment tree levels assigned by the gateway.

R8068

A SOMDS ACM Gateway shall set the OBX-11 Observation Result Status to "R".

Example 6. OBX Source Identification Mapping - Physiological Alert Event

OBX|5|NM|150037^MDC_PRESS_BLD_ART_ABP_SYS^MDC|1.1.1.1.2|119|266016^MDC_DIM_MMHG^MDC|90-110||||R

###### 2:B.4.4.7.3.2 Technical Alerts

The source identification mapping for a technical alert (alarm or advisory) is defined in table Table 2:B.4.4.7.3.2-1.

R8069

If a private MDC code is used for the coding of the SDC coded element value, the identifier shall be mapped as described in Section Appendix 2:B.2.2.

Table 2:B.4.4.7.3.2-1. OBX Source Identification Mapping - Technical Alert Event
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 "CWE".
OBX-3/CWE-1 | Identifier |  | Set to MDC code "68480".
OBX-3/CWE-2 | Text |  | Set to MDC RefId "MDC_ATTR_ALERT_SOURCE".
OBX-3/CWE-3 | Name of Coding System |  | Set to coding system "MDC".
OBX-4 | Observation Sub-ID |  | Set to "<MDS>.<VMD>.<CHAN>.<METRIC>.2" where <MDS>, <VMD>, <CHAN>, and <METRIC> are the numbers of the device’s containment tree levels assigned by the gateway. Please refer to Appendix 2:B.4.4.6 for further information.
OBX-5 | Observation Value |  | HL7 data type CWE
OBX-5/CWE-1 | Identifier | pm:Mds or pm:Vmd or pm:Channel or pm:Metric /pm:Type /@Code |
OBX-5/CWE-2 | Text | If @Code is an MDC code, this field is required to contain the RefId of the MDC code. In all other cases, the field is required to be set to the pm:Mds or pm:Vmd or pm:Channel or pm:Metric/pm:Type/@SymbolicCodeName. | Note that MDC is the default coding system if no coding system is specified.
OBX-5/CWE-3 | Name of Coding System | "MDC" if no other coding system is specified. In all other cases, the field is required to be set to pm:Mds or pm:Vmd or pm:Channel or pm:Metric/pm:Type/@CodingSystem. | Note that MDC is the default coding system if no coding system is specified.
OBX-5/CWE-7 | Coding System Version ID | pm:Mds or pm:Vmd or pm:Channel or pm:Metric/pm:Type/@CodingSystemVersion. |
OBX-11 | Observation Result Status |  | Set to "R".

Example 7. OBX Source Identification Mapping - Technical Alert

OBX|5|CWE|68480^MDC_ATTR_ALERT_SOURCE^MDC|1.1.1.1.2|131328^MDC_ECG_ELEC_POTL^MDC||||||R

###### 2:B.4.4.7.4 Event Phase OBX Segment

R8070

A SOMDS ACM Gateway shall export an Event Phase OBX segment, which identifies the alert event phase.

Notes

| The actual value of the IHE ACM Alert Event Phase attribute depends on a combination of SDC alert condition/signal states. The mapping is defined in table Table 2:B.4.4.7.4-1.

| All pm:AlertSignalState attributes, which are referred in table Table 2:B.4.4.7.4-2 and needed to determine the actual alert phase, relate to pm:AlertSignalState elements with the @Location set to "Loc".

| Unless the pm:AlertConditionState/@ActivationState is set to "On", the pm:AlertConditionState/@Presence is always set to "false"; that is, the gateway will not export any IHE ACM alert event messages.

Examples

OBX|6|ST|68481^MDC_ATTR_EVENT_PHASE^MDC|1.1.1.1.3|start||||||R

R8078

A SOMDS ACM Gateway shall report the Alert Event Phase as "update" when there are more updates than just the Alert Priority as specified in Table 2:B.4.4.7.4-2 for the "update" Alert Event Phase.

Table 2:B.4.4.7.4-1. OBX Alert Event Phase 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 MDC code "68481".
OBX-3/CWE-2 | Text |  | Set to MDC RefId "MDC_ATTR_EVENT_PHASE".
OBX-3/CWE-3 | Name of Coding System |  | Set to coding system "MDC".
OBX-4 | Observation Sub-ID |  | Set to "<MDS>.<VMD>.<CHAN>.<METRIC>.3" where <MDS>, <VMD>, <CHAN>, and <METRIC> are the numbers of the device’s containment tree levels assigned by the gateway. Please refer to Appendix 2:B.4.4.6 for further information.
OBX-5 | Observation Value | The actual value of OBX-5 depends on a combination of various SDC alert attributes and states. | Please refer to the table Table 2:B.4.4.7.4-2 to determine actual value of this field.
OBX-11 | Observation Result Status |  | Set to "R".

Table 2:B.4.4.7.4-2. Alert Event Phase Mapping
IHE ACM Alert Event Phase | SDC Alert Condition/Signal State
--- | ---
start | pm:AlertConditionState/@Presence transitioned from "false" to "true" indicating the start of a new alert event.
continue | The gateway may resend the unchanged alert event information, for example, on a regular basis in order to mitigate the risk of an alert message loss, or after a reconnection to the Alert Manager or Alert Consumer in order to synchronize the current alert status. Note that the Appendix 2:B.4.4.4.2 has to be updated with a new identification number.
end | pm:AlertConditionState/@Presence transitioned from "true" to "false" AND none of the pm:AlertSignalState elements with @ActivationState set to "On" have @Presence set to "Latch". This state ends the current alert event for this condition. Note that for latching alert signals, the Alert State (see also Table 2:B.4.4.7.5-2) transitioned from "Active" to "Latched". In this case, the Alert Event Phase is required to be reported as "update".
update | Any updates/changes to be reported but does not match any other Alert Event Phase mapping criteria.
escalate | Alert Priority (see also Appendix 2:B.4.4.7.7) changed to a higher priority; e.g., from "PM" to "PH". Please refer to R8078.
deescalate | Alert Priority (see also Appendix 2:B.4.4.7.7) changed to a lower priority; e.g., from "PH" to "PM". Please refer to R8078.
reset | pm:AlertConditionState/@Presence is set to "false" AND all the pm:AlertSignalState elements with @ActivationState set to "On" transitioned from @Presence set to "Latch" to @Presence set to "Off" or "Ack". This state ends the current alert event for this condition.

###### 2:B.4.4.7.5 Alert State OBX Segment

R8071

A SOMDS ACM Gateway shall export an Alert State OBX segment, which defines the current state of the alert event.

Notes

| The actual value of the IHE ACM Alert State attribute depends on a combination of SDC alert condition/signal states. The mapping is defined in table Table 2:B.4.4.7.5-1.

| All pm:AlertSignalState attributes, which are referred in table Table 2:B.4.4.7.5-2 and needed to determine the actual alert phase, relate to pm:AlertSignalState elements with the @Location set to "Loc".

| Unless the pm:AlertConditionState/@ActivationState is set to "On", the pm:AlertConditionState/@Presence is always set to "false"; that is, the gateway will not export any IHE ACM alert event messages.

Examples

OBX|7|ST|68482^MDC_ATTR_ALARM_STATE^MDC|1.1.1.1.4|active||||||R

R8072

A SOMDS ACM Gateway shall only report an inactive alert condition when the alarm condition transitioned from active or latched to inactive.

Table 2:B.4.4.7.5-1. OBX Alert State 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 MDC code "68482".
OBX-3/CWE-2 | Text |  | Set to MDC RefId "MDC_ATTR_ALARM_STATE".
OBX-3/CWE-3 | Name of Coding System |  | Set to coding system "MDC".
OBX-4 | Observation Sub-ID |  | Set to "<MDS>.<VMD>.<CHAN>.<METRIC>.4" where <MDS>, <VMD>, <CHAN>, and <METRIC> are the numbers of the device’s containment tree levels assigned by the gateway. Please refer to Appendix 2:B.4.4.6 for further information.
OBX-5 | Observation Value | The actual value of OBX-5 depends on a combination of various SDC alert attributes and states. | Please refer to the table Table 2:B.4.4.7.5-2 to determine actual value of this field.
OBX-11 | Observation Result Status |  | Set to "R".

Table 2:B.4.4.7.5-2. Alert State Mapping
IHE ACM Alert State | SDC Alert Condition/Signal State
--- | ---
Active | pm:AlertConditionState/@Presence is set to "true"
Inactive | pm:AlertConditionState/@Presence is set to "false" AND none of the pm:AlertSignalState elements with @ActivationState set to "On" have @Presence set to "Latch"
Latched | pm:AlertConditionState/@Presence is set to "false" AND at least one of the pm:AlertSignalState elements with @ActivationState set to "On" and @Presence set to "Latch"

###### 2:B.4.4.7.6 Inactivation State OBX Segment

R8073

A SOMDS ACM Gateway shall export an Inactivation State OBX segment, which defines the current inactivation state of the alert event.

Notes

| The actual value of the IHE ACM Alert Inactivation State attribute depends on a combination of SDC alert condition/signal states. The mapping is defined in table Table 2:B.4.4.7.6-1.

| The OBX-5 field can contain multiple inactivation states separated by the HL7 message 'repeating field' character (usually '~'). Example: "audio-off~alert-acknowledged"

| All pm:AlertSignalState attributes, which are referred in table Table 2:B.4.4.7.6-2 and needed to determine the actual alert phase, relate to pm:AlertSignalState elements with the @Location set to "Loc".

| Unless the pm:AlertConditionState/@ActivationState is set to "On", the pm:AlertConditionState/@Presence is always set to "false"; that is, the gateway will not export any IHE ACM alert event messages.

Examples

OBX|8|ST|68483^MDC_ATTR_ALARM_INACTIVATION_STATE^MDC|1.1.1.1.5|enabled||||||R

Table 2:B.4.4.7.6-1. OBX Inactivation State 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 MDC code "68483".
OBX-3/CWE-2 | Text |  | Set to MDC RefId "MDC_ATTR_ALARM_INACTIVATION_STATE".
OBX-3/CWE-3 | Name of Coding System |  | Set to coding system "MDC".
OBX-4 | Observation Sub-ID |  | Set to "<MDS>.<VMD>.<CHAN>.<METRIC>.5" where <MDS>, <VMD>, <CHAN>, and <METRIC> are the numbers of the device’s containment tree levels assigned by the gateway. Please refer to Appendix 2:B.4.4.6 for further information.
OBX-5 | Observation Value | The actual value of OBX-5 depends on a combination of various SDC alert attributes and states. | Please refer to the table Table 2:B.4.4.7.6-2 to determine actual value of this field.
OBX-11 | Observation Result Status |  | Set to "R".

Table 2:B.4.4.7.6-2. Alert Inactivation State Mapping
IHE ACM Inactivation State | SDC Alert Condition/Signal State
--- | ---
enabled | Default inactivation state when not overridden by one of the states below.
audio-paused | pm:AlertConditionState/@Presence set to "true" AND only the pm:AlertSignalState element with the pm:AlertSignalDescriptor/@Manifestation set to "Aud" has its @ActivationState set to "Psd"
audio-off | pm:AlertConditionState/@Presence set to "true" AND only the pm:AlertSignalState element with the pm:AlertSignalDescriptor/@Manifestation set to "Aud" has its @ActivationState set to "Off" OR @ActivationState set to "On" and @Presence set to "Off" or "Ack"
alarm-paused | pm:AlertConditionState/@Presence set to "true" AND all pm:AlertSignalState elements have their @ActivationState set to "Psd"
alarm-off | pm:AlertConditionState/@Presence set to "true" AND all pm:AlertSignalState elements have their @ActivationState set to "Off" OR have their @ActivationState set to "On" and @Presence set to "Off"
alert-acknowledged | At least one of the pm:AlertSignalState elements has its @Presence set to "Ack"

###### 2:B.4.4.7.7 Alert Priority OBX Segment

R8074

A SOMDS ACM Gateway shall map the SDC pm:AlertConditionDescriptor/@Priority attribute to an IHE ACM Alert Priority OBX segment as defined in the [IHE PCD TF-2:2019].

Notes

| The mapping is defined in table Table 2:B.4.4.7.7-1.

Examples

OBX|9|ST|68484^MDC_ATTR_ALARM_PRIORITY^MDC|1.1.1.1.6|PM||||||R

R8075

In the case of an alert priority escalation or deescalation, the pm:AlertConditionState/@ActualPriority is updated with a new priority that differs from the previous @ActualPriority in the state or the @Priority in the descriptor.

In this case, the gateway shall send a new alert event message with the updated priority.

Table 2:B.4.4.7.7-1. OBX Alert Priority 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 MDC code "68484".
OBX-3/CWE-2 | Text |  | Set to MDC RefId "MDC_ATTR_ALARM_PRIORITY".
OBX-3/CWE-3 | Name of Coding System |  | Set to coding system "MDC".
OBX-4 | Observation Sub-ID |  | Set to "<MDS>.<VMD>.<CHAN>.<METRIC>.6" where <MDS>, <VMD>, <CHAN>, and <METRIC> are the numbers of the device’s containment tree levels assigned by the gateway. Please refer to Appendix 2:B.4.4.6 for further information.
OBX-5 | Observation Value | if pm:AlertConditionState /@ActualPriority is available, use pm:AlertConditionState /@ActualPriority Otherwise, use pm:AlertConditionDescriptor /@Priority | Note that the IHE ACM value set for the Alert Priorities differs from the SDC pm:AlertConditionPriority value set and requires a mapping accordingly. Please refer to table Table 2:B.4.4.7.7-2.
OBX-11 | Observation Result Status |  | Set to "R".

Table 2:B.4.4.7.7-2. Alert Priorities Value Set Mapping
SDC Value | SDC Description | HL7 Value | HL7 Description
--- | --- | --- | ---
Lo | Lo = Low. Awareness of the ALERT CONDITION is required. | PL | Low
Me | Me = Medium. Prompt response to remove the ALERT CONDITION is required. | PM | Medium
Hi | Hi = High. Immediate response to remove the ALERT CONDITION is required. | PH | High
None | No awareness of the ALERT CONDITION is required. | PN | not indicated

| If a SDC ALERT CONDITION represents an advisory signal, the alert priority is set to "None" for this SDC ALERT CONDITION, and therefore, mapped to "PN" in the IHE ACM Alert Priority OBX segment.

###### 2:B.4.4.7.8 Alert Type OBX Segment

R8076

A SOMDS ACM Gateway shall map the SDC pm:AlertConditionDescriptor/@Kind to an IHE ACM Alert Type OBX segment as defined in the [IHE PCD TF-2:2019].

Notes

| The mapping is defined in table Table 2:B.4.4.7.8-1.

Examples

OBX|10|ST|68485^MDC_ATTR_ALERT_TYPE^MDC|1.1.1.1.7|ST||||||R

R8079

If pm:AlertConditionState/@ActualPriority is available and set to "None", or if pm:AlertConditionState/@ActualPriority is NOT available and pm:AlertConditionDescriptor/@Priority set to "None", then the SDC ALERT CONDITION is an advisory, and the alert type shall be set to "SA" in the IHE ACM Alert Type OBX segment.

Examples

OBX|10|ST|68485^MDC_ATTR_ALERT_TYPE^MDC|1.1.1.1.7|SA||||||R

Table 2:B.4.4.7.8-1. OBX Alert Type 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 MDC code "68485".
OBX-3/CWE-2 | Text |  | Set to MDC RefId "MDC_ATTR_ALERT_TYPE".
OBX-3/CWE-3 | Name of Coding System |  | Set to coding system "MDC".
OBX-4 | Observation Sub-ID |  | Set to "<MDS>.<VMD>.<CHAN>.<METRIC>.7" where <MDS>, <VMD>, <CHAN>, and <METRIC> are the numbers of the device’s containment tree levels assigned by the gateway. Please refer to Appendix 2:B.4.4.6 for further information.
OBX-5 | Observation Value | pm:AlertConditionDescriptor /@Kind | Note that the IHE ACM value set for the Alert Types differs from the SDC pm:AlertConditionKind value set and requires a mapping accordingly. Please refer to table Table 2:B.4.4.7.8-2.
OBX-11 | Observation Result Status |  | Set to "R".

Table 2:B.4.4.7.8-2. Alert Types Value Set Mapping
SDC Value | SDC Description | HL7 Value | HL7 Description
--- | --- | --- | ---
Phy | Phy = Physiological. The condition arises from a patient-related variable. | SP | Alert is Alarm – Physiological See exception when R8079 is met.
Tec | Tec = Technical. The condition arises from a monitored equipment-related or ALERT SYSTEM-related variable. | ST | Alert is Alarm – Technical See exception when R8079 is met.
Oth | Oth = Other. The condition arises from another origin, e.g., equipment-user advisory condition. | SA | Alert is Advisory

##### 2:B.4.4.8 PRT - Participation Information Segment

The PRT segment is optional for the [PCD-04] transaction and currently not supported by the ACM gateway actor.

### 2:B.5 SDPi FHIR Gateway

#### 2:B.5.1 Scope

This chapter defines the mapping from the MDIB content as defined in this document and its underlying standards, to HL7 FHIR resources.

The SOMDS FHIR Gateway represents a PoCD data and/or alert reporter, which is defined in the [HL7 FHIR Point-of-Care Device Implementation Guide].

The section SDC to FHIR Mapping of the [HL7 FHIR Point-of-Care Device Implementation Guide] details the mapping from the MDIB content to HL7 FHIR resources.

#### 2:B.5.2 Referenced Standards & Profiles

This section provides an overview about the referenced standards and profiles used in this chapter:

- [HL7 FHIR Point-of-Care Device Implementation Guide]

# Volume 3 — Content Modules

## 3:8 DEV Semantic Content Modules

SDPi 2.0 Supplement Note: The organization of this Volume 3 supplement factors in two major changes: IHE Supplement template (2020), with content mapped from the [IHE PCD TF-3:2019] specification; Addition of BICEPS content to a volume that is organized according to the "classic" [IEEE 11073-10201:2004] domain information model (DIM). For this version of the supplement, content from the 2019 version that was in sections 3 and 7 has now been collected into a single Section 8. In order to clearly identify the supplement content that is related to BICEPS, specific sections with BICEPS in the title have been added. Although this results in a fairly clean supplement document, the flow of the outline is at times non sequitur. To address that problem — again arising from the original volume organization never contemplating additional semantic content standards alignment beyond the Classic DIM — subsections that are aligned with the Classic DIM have been organized in a subsection with that scope. That new content which is based on BICEPS is also contained within a similarly labeled set of subsections — both at the same outline level. For the existing TF-3 content in the [IHE PCD TF-3:2019], especially Section 3, though this supplement includes editor guidance for which sections are mapped where in the updated outline, the actual content is a mix of general device informatics topics and details that are based on the "classic" [IEEE 11073-10201:2004] DIM. Updating the existing IHE DEV Technical Framework content will be either deferred to a later version of this SDPi supplement or will be accomplished through a specific Change Proposal (CP) to the published IHE DEV TF-3. Additionally, for this version of SDPi, it isn’t clear how best to address a similar division of the device specialization sections (e.g., infusion pump or ventilator). Version note boxes (like this one) have therefore been added to the specializations section and a single BICEPS subsection has been added. Subsequent versions of the specification may address this more comprehensively. REVIEWER QUESTION: Please consider not only the BICEPS-related updates but also the changes to the general organization and provide guidance as to whether this TF-3 is better organized for clarity and future extensions, or if a different approach should be taken.

### 3:8.1 Overview of device semantic content

Move IHE PCD 2019 TF-3 Section 3 (text immediately after the section header) to this SDPi 2.0 TF-3 Section 8.1

### 3:8.2 General device content considerations

Move IHE PCD 2019 TF-3 sections 3.1 to this SDPi 2.0 TF-3 Section 8.2

SDPi 2.0 Supplement Note: The content in the IHE PCD 2019 TF-3 3.1 Section will need to be edited to be agnostic to the underlying protocol, with protocol specifics being relegated to subsections in Section 3:8.3 below.

### 3:8.3 Protocol-Specific Content Module Considerations

#### 3:8.3.1 IEEE 11073-10201 Classic DIM Content Modules

Move IHE PCD 2019 TF-3 sections 3.2 to 3.7 to this SDPi 2.0 TF-3 Section 8.3.1.2 TO 8.3.1..7 A new 8.3.1.1 Section should be added to the Classic DIM content section that addresses basic reporting. This content would be extracted from the existing (2019) Section 3.1, where that content is specific to the Classic DIM (see related note above).

#### 3:8.3.2 IEEE 11073-10207 BICEPS Content Modules

##### 3:8.3.2.1 SDC/BICEPS Content Module

The BICEPS standard, [ISO/IEEE 11073-10207:2017], provides an extensive semantic model for all information exchanged between SOMDS Participant systems. This section provides a general background for BICEPS-based content, including both what is unique to this standard (e.g., different from the Classic DIM), and any extensions that are made by this SDPi supplement.

R0701

All SOMDS Participant systems shall fully implement the semantic content requirements in the [ISO/IEEE 11073-10207:2017] BICEPS standard.

Notes

| This includes strict implementation of the BICEPS MDIB specification, as well as use of the MDC nomenclature.

##### 3:8.3.2.2 BICEPS Descriptive Model

As described in Section 1:10.4.1.1 (see Figure 1:10.4.1.1-3), all SOMDS Participant systems support an MDIB model that has both medical device description and state components. Figure 3:8.3.2.2-1 below provides the next level of detail for the descriptive part of the MDIB:

Figure 3:8.3.2.2-1. SDC/BICEPS MDIB Descriptive Model Components

This model, detailed in [ISO/IEEE 11073-10207:2017], provides a basic set of objects and containment relationships for describing the information and services supported by a medical device.

The core Medical Device System (MDS), Virtual Medical Device (VMD), Channel, and Metric objects are utilized for communicating basic information; whereas, the Alert System objects (not all are included on this diagram) support the specialized information around medical device alerts, alarms, and special events. What is unique to this descriptor model, though, is the inclusion of a set of SystemContext objects, as identified in Figure 3:8.3.2.2-2 below:

Figure 3:8.3.2.2-2. SDC/BICEPS MDIB System Context Types Model

These context types combine to support description of the operational environment for a device. Depending on a systems capabilities, they may be configured — statically or dynamically — with context information such as location or patient identification, or they may discover a SOMDS Provider on the network from which they can retrieve the information. These context types represent a significant improvement over previous medical device MDIB description capabilities.

| A detailed description of this BICEPS description information model is beyond the scope of this specification. Detailed information is available in the [ISO/IEEE 11073-10207:2017] standard and other materials identified in Appendix 1:B.

SDPi 2.0 Supplement Note: This version of the supplement does not fully support profiles of all the elements in the descriptive model, including: Service Control Object (SCO) and Operations Battery objects Additionally, only limited support for the AlertSystem (and related objects), and for the SystemContext types are provided in SDPi 2.0. Subsequent versions of the specification will address complete functionality.

##### 3:8.3.2.3 BICEPS Relationship to Classic DIM

As can be seen from Figure 3:8.3.2.2-1 above, the core elements of the Classic DIM (as specified in [IEEE 11073-10201:2004] and described in Section 3:8.3.1), are directly supported by the BICEPS model above in Figure 3:8.3.2.2-1. The basic containment from MDS to VMD to Channel to Metric is maintained within BICEPS, ensuring continuity with the broadly-implemented Classic DIM

##### 3:8.3.2.4 BICEPS Mapping using SOMDS Connector content modules

SDPi 2.0 Supplement Note: This clause is intentionally left blank for this version. Future versions will include general discussion about how BICEPS-based content is formally mapped to that of other protocols, typically utilizing a SOMDS Connector.

##### 3:8.3.2.5 Nomenclature Considerations – Private Extensions & External Systems

The BICEPS specification fully supports the private nomenclature extensions as defined in [IEEE 11073-10101:2020]. Additionally it supports integration of other non-MDC terminology systems.

See [ISO/IEEE 11073-10207:2017] for additional details.

##### 3:8.3.2.6 System Type Nomenclature Extensions

In addition to specific device specializations (see Section 3:8.7 below), SDPi specifications, especially TF-1 use cases, refer to a number of general classes or types of systems. These systems provide common services to all other SOMDS Participant's; however, in order to be discovered on the network, they must have system type identifiers that can be recognized by these other systems (explicitly / implicitly).

Table 3:8.3.2.6-1. MDC Nomenclature System Type Extensions
MDS System Type | MDC Term Identifier | Acronym | Description
Central Station | (tba) | CS | A system that supports a multi-patient workplace with capabilities similar to a Cockpit.
Clinical Notification System | (tba) | CNS | A system that supports sending notifications (e.g., alerts) to individual clinicians
Cockpit | (tba) |  | Supports information viewing and control of multiple devices and systems associated with a single patient.
Device Aggregator | (tba) |  | A system that discovers and integrates or "aggregates" information from one or more devices and makes them accessible from a single SOMDS Provider MDIB. Aggregated devices may be SOMDS Participants that support SDC connectivity or may be interfaced to the aggregator system by some other non-standardized means (e.g., analog sensors or proprietary protocols).
Dashboard | (tba) |  | 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.
Gateway | (tba) | DGW, AGW | Gateway PARTICIPANT that provides, for example, ADT information or laboratory results (inbound). Note: AGW is for an Alert Gateway system. (For example, see Appendix 1:C.6.4)
Smart Alerting | (tba) | SAS | Smart Alerting system that provides consolidated alert event (actionable alerts), advisories such as patient deteriorations, etc.

##### 3:8.3.2.7 Globally Unique Vendor-specific Coding System Identifier

The [IEEE 11073-10101:2020] nomenclature standard gives medical device vendors the freedom to define their own codes for new concepts which are currently not part of the standard nomenclature.

The [IEEE 11073-10700:2022] Base Requirements for Participants in a Service-Oriented Device Connectivity (SDC) System defines two requirements for use of private codes as detailed in [IEEE 11073-10101:2020]:

- TR1357: If there is no standardized code to convey semantics, an SDC BASE PARTICIPANT S-H-O-U-L-D populate pm:CodedValue with a private code as detailed in [IEEE 11073-10101].

- TR1358: If an SDC BASE PARTICIPANT uses a private code as detailed in [IEEE 11073-10101], the SDC BASE PARTICIPANT S-H-A-L-L refer to its definition by providing a pm:Translation with a @CodingSystem that uniquely identifies the private coding system that contains the code.

| This implies that a MANUFACTURER that needs to use private codes has to keep a private coding system for these codes. Following the concept of private codes that is defined in [IEEE 11073-10101:2020], a MANUFACTURER introduces and maintains a set of codes that adhere to the principles of the [IEEE 11073-10101:2020] nomenclature standards.

There are different ways to define a globally unique identifier for the vendor-specific private coding system (e. g. URL, OID, etc.). In the context of medical device interoperability, the recommendation is to use an "object identifier" (OID) for private codes as detailed in [IEEE 11073-10101:2020] and other purposes (e. g. private SDC extensions):

- Compared with other identifiers (e.g. URLs) OIDs are very compact, which helps to keep the size of data messages low

- It is free of charge to register a globally unique enterprise OID with IANA.

An enterprise OID assigned by IANA always starts with the prefix iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). The actual enterprise node number, which follows the prefix, is globally unique to the medical device vendor (e. g. "1.3.6.1.4.1.12345" for the Medical Device XYZ Ltd. company).

Once the enterprise OID is registered, it is up to the medical device vendor to extend the OID by adding child nodes. The child nodes don’t have a globally unique meaning, but the enterprise OID plus the child nodes are required to be globally unique. It is recommended to define a child node schema, and assign unique numbers to the concepts on each node level.

Example 8. OID Vendor-specific Child Node Schema

- 1.3.6.1.4.1.12345.<Namespace>: this could be, for example, the business group id within the enterprise ("Patient Monitoring" = 1, "Ventilation" = 2, etc.).

- 1.3.6.1.4.1.12345.<Namespace>.<Type>: this could be, for example, the id of the type defined within the business group of the enterprise ("Private Code System" = 1, "SDC Extensions" = 2, etc.)

- 1.3.6.1.4.1.12345.<Namespace>.<Type>.<Version>: it is highly recommended to define the version number as the last child node in the OID. Different versions indicate a major (maybe breaking) change to the Type defined by the parent node.

In the example above, the OID "1.3.6.1.4.1.12345.2.1.1" would represent a private coding system identifier in version 1 issued by the ventilation business group of the Medical Device XYZ Ltd. company.

R0702

The Manufacturer shall disclose the OIDs that it uses throughout SDC communication.

Notes

| This includes OIDs for private codes as detailed in [IEEE 11073-10101:2020], for private SDC extensions and for private PKPs.

##### 3:8.3.2.8 Safety, Effectiveness and Security - Requirements and Considerations

SDPi 2.0 Supplement Note: The SDC standards community is evaluating the use of safety class elements in the BICEPS specification (see [ISO/IEEE 11073-10207:2017]), and the related Github Issue #11 Topic: SDPi-xC with Mixed Device Safety Classes. The result of that discussion will directly impact the BICEPS SES Considerations Section below. For this version of the specification, the following wording has been suggested: The purpose of the BICEPS attribute @SafetyClassification is to classify the quality and criticality of data and operations. The usage of this attribute is under discussion in IEEE 11073 PoCD and IHE DEV DPI. Additionally, the value set definition in BICEPS is under discussion. Consequently, this document version does not yet include guidance or requirements on the usage of @SafetyClassification.

###### 3:8.3.2.8.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.

For additional guidance, see Section Safety, Effectiveness and Security - Requirements and Considerations.

###### 3:8.3.2.8.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.

###### 3:8.3.2.8.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.

###### 3:8.3.2.8.4 Security Requirements & Considerations

Secure exchange of content between medical devices is a foundational requirement for all system-to-system interactions. Though management of secure connections is generally a technical issue and not one specific to semantic content, close consideration should be made to ensure that information exchanged in potentially unsecured contexts does not pose an unacceptable risk.

Additional security requirements and considerations may be identified in the SDPi-P profile, and those specified in the SES General Considerations Section above.

##### 3:8.3.2.9 BICEPS Conventions for device specialization content modules

##### 3:8.3.2.10 BICEPS Extension Model

IEEE 11073-10207 provides a flexible extension model. This enables manufacturers to add information that does not fit into the defined structure. Therefore, nearly every element in the participant and message model contains an extension point (`ext:Extension`). However, the fundamental rules are: Do not use a proprietary extension if the purpose of the extension can be expressed by (in the specified order)

1. the given participant and message models,

2. a standardized coded value,

3. a standardized extension, or

4. a private coded value.

The borders of using extension are given by:

- [ISO/IEEE 11073-10207:2017] Clause 8, especially R0109, and

- [IEEE 11073-10700:2022] Clause 6.7

There are two kinds of extensions, those the SOMDS Consumer must understand to perform system functions safely with the SOMDS Provider, and those the SOMDS Consumer does not have to understand. This is indicated by the Boolean attribute `@ext:MustUnderstand`. Consequently, a manufacturer of a SOMDS Provider should be careful defining extensions with `@ext:MustUnderstand = true`, as this potentially reduces interoperability.

There are standardized extensions, like those that are specified in the PKP standards or this specification, which can be considered common knowledge and therefore do not break interoperability between different manufacturers.

###### 3:8.3.2.10.1 Extension Constraints

###### 3:8.3.2.10.1.1 Mixed Content

Some XML processor APIs do not support ordered access to XML mixed content, which is the interlacing of XML elements with text content.

Figure 3:8.3.2.10.1.1-1. Example of mixed content in an XML instance

    <foo>
        <bar>
            Here
            <interlaced1/>
            is some
            <interlaced2/>
            <interlaced3/>
            interlaced
            <interlaced4/>
            text
        </bar>
    </foo>

There are APIs that do not fully implement the XML Document Object Model and hence cannot individually access text nodes (e.g. as in Figure 3:8.3.2.10.1.1-1: "Here", "is some", "interlaced", and "text") in between the interlaced elements but only as concatenated text. This makes verification measures unnecessarily complicated. As mixed content is not required to be available in device to device communication, R0019 prohibits the use of mixed content types in BICEPS extensions.

R0019

A SOMDS Participant shall not provide BICEPS extensions that use XML mixed content.

###### 3:8.3.2.10.1.2 QName

An expanded QName is a tuple of an optional namespace plus a local name. In its serialized form, a QName is represented by either a prefix plus the local name or without a prefix, which translates to the default namespace or no namespace if no default is specified. As long as QNames are used as part of element or attribute names within an XML instance, its usage is well-defined.

The use in element content or attribute values however is specific to the application and hence not standardized at all. Depending on the XML Schema awareness, each XML processor handles QNames in element content or attribute values differently, to the extent that some are not round-trip-safe and others just pass through the element value to the user of the API. While the former may lead to interoperability issues, the latter is a leaky abstraction and requires API users to gain access to the XML instance that included the QName.

In order to strengthen interoperability and avoid leaky abstraction, R0020 prohibits the use of QName types in BICEPS extensions.

R0020

A SOMDS Participant shall not provide BICEPS extensions that are based on or use the XML Schema QName type.

###### 3:8.3.2.10.2 Applicable Production Specification Type Codes

R0008

If available by the Manufacturer of a SOMDS Provider, the SOMDS Provider shall include every production specification listed in Table 3:8.3.2.10.2-1 in its MDSs, unless a mapping to the BICEPS Participant Model exists.

Notes

| Table 3:8.3.2.10.2-2 shows the mapping between IEEE 11073-10101 RefIds and the BICEPS Participant Model. A dash in the column BICEPS Participant Model Mapping signifies a non-existent mapping.

| Other production specifications may be used for types that are not listed in Table 3:8.3.2.10.2-1.

Table 3:8.3.2.10.2-1. Production specification provisions by SOMDS Providers
RefId | Description | IEEE 11073-10101 <Partition>::<Code> | Context-free Code
--- | --- | --- | ---
MDC_ID_MODEL_MANUFACTURER | The manufacturer sub-element of the MDC_ATTR_ID_MODEL attribute | 8::7682 | 531970
MDC_ID_MODEL_NUMBER | The model number sub-element of the MDC_ATTR_ID_MODEL attribute | 8::7681 | 531969
MDC_ID_PROD_SPEC_FW | The firmware-revision component id group of the MDC_ATTR_ID_PROD_SPECN attribute | 8::7688 | 531977
MDC_ID_PROD_SPEC_GMDN | The prod-spec-gmdn component id group of the MDC_ATTR_ID_PROD_SPECN attribute | 8::7690 | 531979
MDC_ID_PROD_SPEC_HW | The hardware-revision component id group of the MDC_ATTR_ID_PROD_SPECN attribute | 8::7686 | 531974
MDC_ID_PROD_SPEC_PART | The part-number component id group of the MDC_ATTR_ID_PROD_SPECN attribute | 8::7685 | 531973
MDC_ID_PROD_SPEC_PROTOCOL_REV | The protocol-revision component id group of the MDC_ATTR_ID_PROD_SPECN attribute | 8::7689 | 531978
MDC_ID_PROD_SPEC_SERIAL | The serial-number component id group of the MDC_ATTR_ID_PROD_SPECN attribute | 8::7684 | 531972
MDC_ID_PROD_SPEC_SW | The software-revision component id group of the MDC_ATTR_ID_PROD_SPECN attribute | 8::7687 | 531975
MDC_ID_PROD_SPEC_UNSPECIFIED | The unspecified component id group of the MDC_ATTR_ID_PROD_SPECN attribute | 8::7683 | 531971

Table 3:8.3.2.10.2-2. Production specification mappings to the BICEPS Participant Model
RefId | BICEPS Participant Model Mapping
--- | ---
MDC_ID_MODEL_MANUFACTURER | `pm:MdsDescriptor/pm:MetaData/pm:Manufacturer`
MDC_ID_MODEL_NUMBER | `pm:MdsDescriptor/pm:MetaData/pm:ModelName`
MDC_ID_PROD_SPEC_FW | -
MDC_ID_PROD_SPEC_GMDN | -
MDC_ID_PROD_SPEC_HW | -
MDC_ID_PROD_SPEC_PART | `pm:MdsDescriptor/pm:MetaData/pm:LotNumber`
MDC_ID_PROD_SPEC_PROTOCOL_REV | -
MDC_ID_PROD_SPEC_SERIAL | `pm:MdsDescriptor/pm:MetaData/pm:SerialNumber`
MDC_ID_PROD_SPEC_SW | -
MDC_ID_PROD_SPEC_UNSPECIFIED | -

###### 3:8.3.2.10.3 Applicable Attribute Type Codes

R0009

If available by the Manufacturer of a SOMDS Provider, the SOMDS Provider shall include every attribute listed in Table 3:8.3.2.10.3-1 in its MDS descriptors.

Notes

| Other attributes may be used for types that are not listed in Table 3:8.3.2.10.3-1.

Table 3:8.3.2.10.3-1. Attribute provisions by SOMDS Providers in MDS descriptors
RefId | Description | IEEE 11073-10101 <Partition>::<Code> | Context-free Code
--- | --- | --- | ---
MDC_ATTR_ID_SOFT | Identifier specific to a hospital (non-manufacturer) that is configured by (service) personnel, e.g., a hospital inventory number. Synonyms used by different manufacturers: Equipment label Device name Friendly name Example values: TMC Vent 42 PatMon03 | 1::2350 | 67886

###### 3:8.3.2.10.4 Coded Attribute

BICEPS does not provide means to generically add attributes from the first partition of the IEEE 11073-10101 nomenclature to the MDIB. This becomes challenging if there are attributes required by SOMDS Providers to provide information that is not covered by the BICEPS Participant Model.

For example, BICEPS only supports the following MDS meta information below the `pm:Mds/pm:MetaData` element:

- UDI

- Lot number

- Manufacturer name

- Expiration date

- Model name

- Model number

- Serial number

Some statically configured meta information like firmware versions or software versions can be added by means of production specification elements. However, attributes like equipment labels do not exist and cannot be conveyed by using production specifications.

This specification specifies the Coded Attribute extension that allows for a SOMDS Provider to provide attributes from the first partition of the IEEE 11073-10101 nomenclature for which there is no information item specified in the BICEPS Participant Model.

###### 3:8.3.2.10.4.1 Model

The CodedAttribute XML Schema is available in Appendix 3:A.1. Example 9 shows an exemplary XML instance of a GetMdibResponse including the `MDC_ATTR_ID_SOFT` attribute as an additional metadata item.

Example 9. MDS with CodedAttribute representing a Soft ID

    <?xml version="1.0" encoding="UTF-8"?>
    <msg:GetMdibResponse
            SequenceId="urn:uuid:09578906-7efd-43a7-8344-8bf37b674524"
            xmlns:ext="http://standards.ieee.org/downloads/11073/11073-10207-2017/extension"
            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:sdpi="urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1">
        <msg:Mdib SequenceId="urn:uuid:09578906-7efd-43a7-8344-8bf37b674524">
            <pm:MdDescription>
                <pm:Mds Handle="mds0">
                    <ext:Extension>
                        <sdpi:CodedAttributes>
                            <sdpi:CodedStringAttribute>
                                <sdpi:MdcAttribute Code="67886" SymbolicCodeName="MDC_ATTR_ID_SOFT"/>
                                <sdpi:Value>PatMon03</sdpi:Value>
                            </sdpi:CodedStringAttribute>
                        </sdpi:CodedAttributes>
                    </ext:Extension>
                    <!-- containment subtree -->
                </pm:Mds>
            </pm:MdDescription>
            <pm:MdState>
                <!-- states -->
            </pm:MdState>
        </msg:Mdib>
    </msg:GetMdibResponse>

###### 3:8.3.2.10.4.2 Requirements

R0007

A SOMDS Provider shall set `sdpi:MdcAttribute/@Code` to any code from the first partition of the IEEE 11073-10101 nomenclature in the range of 67841 (1::2305) to 68609 (1::3073).

Notes

| This prevents Manufacturers from using codes outside the intended range of attributes.

###### 3:8.3.2.10.5 Gender

SDPi 2.0 Supplement Note: As mentioned in the main text below, BICEPS does not currently provide sex and gender semantic support at the same level of detail as foundational existing and emerging standards. The following sex and gender harmonization policy will be taken in this and future SDPi specification versions until clear direction is available. STANDARDIZATION NOTE: There is active work to finalize the informatics standards related to sex and gender, including within HL7, SNOMED, ISO/TC215 and in other standards development organizations. Once this standardization is complete, especially within HL7 FHIR and Version 2, the SDC standards and the SDPi Profiles and gateway specifications will be harmonized. Until that time, the mappings below represent a "best effort" given the status of the underlying standards. See the related note on sex and gender in the gateway mappings specified in Appendix 2:B.

BICEPS does not provide means to convey the administrative gender in the pm:PatientDemographicsCoreData element. As nowadays the distinction between biological sex and administrative gender is an essential feature of patient demographics and required by protocols such as HL7 FHIR, this specification adds an extension to the BICEPS Participant Model in order to allow for a SOMDS Participant to provide the administrative gender in addition to the already existing biological sex (as specified in pm:PatientDemographicsCoreData/pm:Sex).

The extension is based on the terminology of [HL7 FHIR]: https://hl7.org/fhir/valueset-administrative-gender.html.

###### 3:8.3.2.10.5.1 Model

The Gender XML Schema is available in Appendix 3:A.2. Example 10 shows an exemplary XML instance of a GetMdibResponse including the Gender extension in the state part of the MDIB.

Example 10. Patient demographics core data with added gender

    <?xml version="1.0" encoding="UTF-8"?>
    <msg:GetMdibResponse
            SequenceId="urn:uuid:09578906-7efd-43a7-8344-8bf37b674524"
            xmlns:ext="http://standards.ieee.org/downloads/11073/11073-10207-2017/extension"
            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:sdpi="urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <msg:Mdib SequenceId="urn:uuid:09578906-7efd-43a7-8344-8bf37b674524">
            <pm:MdDescription>
                <pm:Mds Handle="mds0">
                    <pm:SystemContext Handle="system_context">
                        <pm:PatientContext Handle="patient_context"/>
                    </pm:SystemContext>
                    <!-- containment subtree -->
                </pm:Mds>
            </pm:MdDescription>
            <pm:MdState StateVersion="10">
                <pm:State xsi:type="pm:PatientContextState" ContextAssociation="Pre" Handle="patient_context_state" StateVersion="8" DescriptorHandle="patient_context">
                    <pm:Identification Root="http://www.sdpi.org" Extension="SamplePatientId123"/>
                    <pm:CoreData>
                        <ext:Extension>
                            <sdpi:Gender>Other</sdpi:Gender>
                        </ext:Extension>
                        <pm:Givenname>John</pm:Givenname>
                        <pm:Middlename>Donnelly</pm:Middlename>
                        <pm:Familyname>Doe</pm:Familyname>
                        <pm:Sex>M</pm:Sex>
                    </pm:CoreData>
                </pm:State>
                <!-- states -->
            </pm:MdState>
        </msg:Mdib>
    </msg:GetMdibResponse>

###### 3:8.3.2.10.5.2 Requirements

R0012

If the administrative gender of a patient described by a pm:PatientDemographicsCoreData element is available, a SOMDS Participant shall at least add the sdpi:Gender extension to the pm:PatientDemographicsCoreData/ext:Extension element.

###### 3:8.3.2.10.6 Equipment Identifier

BICEPS does not provide means to convey any metadata that allows for identification of MDSs or VMDs inside an MDIB other than by UDIs. UDIs however are not unique when used in different jurisdictions or for multiple instances of a SaMD.

This extension fulfills the need to identify MDSs and VMDs across re-initializations of a SOMDS Provider by means of stable and globally unique URIs that are constant across re-initializations of the SOMDS Provider.

###### 3:8.3.2.10.6.1 Model

The Equipment Identifier XML Schema is available in Appendix 3:A.3. Example 11 shows an exemplary XML instance of a GetMdibResponse including the Equipment Identifier extension in the descriptive part of the MDIB.

Example 11. MDS and VMD with Equipment Identifier extension

    <?xml version="1.0" encoding="UTF-8"?>
    <msg:GetMdibResponse
            SequenceId="urn:uuid:09578906-7efd-43a7-8344-8bf37b674524"
            xmlns:ext="http://standards.ieee.org/downloads/11073/11073-10207-2017/extension"
            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:sdpi="urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1">
        <msg:Mdib SequenceId="urn:uuid:09578906-7efd-43a7-8344-8bf37b674524">
            <pm:MdDescription>
                <pm:Mds Handle="mds0">
                    <ext:Extension>
                        <sdpi:EquipmentIdentifier>urn:uuid:9c057bb4-8d83-4fc1-9ad1-832ad543e2b2</sdpi:EquipmentIdentifier>
                    </ext:Extension>
                    <pm:Vmd Handle="vmd0">
                        <ext:Extension>
                            <sdpi:EquipmentIdentifier>urn:uuid:84051cdb-5353-47af-a916-b1f007e08ed8</sdpi:EquipmentIdentifier>
                        </ext:Extension>
                        <!-- containment subtree elements -->
                    </pm:Vmd>
                    <!-- other containment subtree elements -->
                </pm:Mds>
            </pm:MdDescription>
            <pm:MdState StateVersion="10">
                <!-- states -->
            </pm:MdState>
        </msg:Mdib>
    </msg:GetMdibResponse>

###### 3:8.3.2.10.6.2 Requirements

R0014

For the `sdpi:EquipmentIdentifier` extension, a SOMDS Provider shall use a stable, globally unique URI that is constant across re-initializations of the SOMDS Provider and uniquely refers to a physical or virtual entity.

R0015

For the `sdpi:EquipmentIdentifier` extension, a SOMDS Provider shall use URI-encoded UUIDs or OIDs.

R0016

To test if two equipment identifiers are equal, a SOMDS Participant shall perform case-sensitive string comparison.

R0017

A SOMDS Provider shall provide the `sdpi:EquipmentIdentifier` extension for each pm:MdsDescriptor in its MDIB.

| This requirement allows a SOMDS Consumer to rely on the `sdpi:EquipmentIdentifier` to be present in each MDS at any time.

| If a Manufacturer provides a globally unique UDI, it can generate a the `sdpi:EquipmentIdentifier` UUID from that UDI. Alternatively, UUIDs can also be generated from UUIDv5 having a manufacturer specific namespace and the serial number as a name.

R0018

For each Removable Subsystem VMD of a SOMDS Provider, the SOMDS Provider should provide the `sdpi:EquipmentIdentifier` extension for the pm:VmdDescriptor in its MDIB.

###### 3:8.3.2.10.7 Compound Metric Modelling

BICEPS does not natively support the concept of compound metrics. An example of compound metrics are blood pressures with their systolic, diastolic, and mean pressure components.

However, BICEPS supports the concept of relations in the pm:AbstractMetricDescriptor element that can be utilized to model compound metrics.

###### 3:8.3.2.10.7.1 Model

This section defines the modelling of compound metrics.

In order to define which metrics belong to the same compound metric, the pm:AbstractMetricDescriptor/pm:Relation element of each metric points to the other metrics which are also part of the same compound metric.

The pm:AbstractMetricDescriptor/pm:Relation/pm:Code element defines the compound metric and is set to the same concept on all metrics belonging to this compound metric.

Example 12. Non-invasive Blood Pressure Metric Compound Descriptor Example

    <?xml version="1.0" encoding="UTF-8"?>
    <msg:GetMdibResponse
            SequenceId="urn:uuid:09578906-7efd-43a7-8344-8bf37b674524"
            xmlns:ext="http://standards.ieee.org/downloads/11073/11073-10207-2017/extension"
            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:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xmlns:sdpi="urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1">
        <msg:Mdib SequenceId="urn:uuid:09578906-7efd-43a7-8344-8bf37b674524">
            <pm:MdDescription>
                <pm:Mds Handle="mds0">
    				<!-- containment subtree -->
    				<pm:Vmd Handle="vmd0" SafetyClassification="MedA">
    					<!-- containment subtree -->
    					<pm:Channel Handle="chan0" SafetyClassification="MedA">
    						<!-- containment subtree -->
    						<pm:Metric xsi:type="pm:NumericMetricDescriptor"
    								           Handle="metric0.sys"
    								           SafetyClassification="MedA"
    								           Resolution="1.0"
    								           MetricCategory="Msrmt"
    								           DerivationMethod="Auto"
    								           MetricAvailability="Intr"
    								           LifeTimePeriod="PT300S">
    							<pm:Type Code="150021">
    								<pm:ConceptDescription>Noninvasive systolic blood pressure</pm:ConceptDescription>
    							</pm:Type>
    							<pm:Unit Code="266016">
    								<pm:ConceptDescription>mmHg</pm:ConceptDescription>
    							</pm:Unit>
    							<pm:Relation Kind="SST" Entries="metric0.dia metric0.mean">
    								<pm:Code Code="150020">
    									<pm:ConceptDescription>Noninvasive blood pressure</pm:ConceptDescription>
    								</pm:Code>
    							</pm:Relation>
    						</pm:Metric>
    						<pm:Metric xsi:type="pm:NumericMetricDescriptor"
    								           Handle="metric0.dia"
    								           SafetyClassification="MedA"
    								           Resolution="1.0"
    								           MetricCategory="Msrmt"
    								           DerivationMethod="Auto"
    								           MetricAvailability="Intr"
    								           LifeTimePeriod="PT300S">
    							<pm:Type Code="150022">
    								<pm:ConceptDescription>Noninvasive diastolic blood pressure</pm:ConceptDescription>
    							</pm:Type>
    							<pm:Unit Code="266016">
    								<pm:ConceptDescription>mmHg</pm:ConceptDescription>
    							</pm:Unit>
    							<pm:Relation Kind="SST" Entries="metric0.sys metric0.mean">
    								<pm:Code Code="150020">
    									<pm:ConceptDescription>Noninvasive blood pressure</pm:ConceptDescription>
    								</pm:Code>
    							</pm:Relation>
    						</pm:Metric>
    						<pm:Metric xsi:type="pm:NumericMetricDescriptor"
    								           Handle="metric0.mean"
    								           SafetyClassification="MedA"
    								           Resolution="1.0"
    								           MetricCategory="Msrmt"
    								           DerivationMethod="Auto"
    								           MetricAvailability="Intr"
    								           LifeTimePeriod="PT300S">
    							<pm:Type Code="150023">
    								<pm:ConceptDescription>Noninvasive mean blood pressure</pm:ConceptDescription>
    							</pm:Type>
    							<pm:Unit Code="266016">
    								<pm:ConceptDescription>mmHg</pm:ConceptDescription>
    							</pm:Unit>
    							<pm:Relation Kind="SST" Entries="metric0.sys metric0.dia">
    								<pm:Code Code="150020">
    									<pm:ConceptDescription>Noninvasive blood pressure</pm:ConceptDescription>
    								</pm:Code>
    							</pm:Relation>
    						</pm:Metric>
    					</pm:Channel>
    				</pm:Vmd>
                </pm:Mds>
            </pm:MdDescription>
            <pm:MdState>
                <!-- states -->
            </pm:MdState>
        </msg:Mdib>
    </msg:GetMdibResponse>

###### 3:8.3.2.10.7.2 Requirements

This section defines the requirements to compound metrics provided in the MDIB descriptive and state parts.

###### 3:8.3.2.10.7.2.1 Descriptor Part

R0703

For each compound metric, the SOMDS Provider shall provide a pm:Relation element to relate to all metrics belonging to the same compound metric.

R0704

For each pm:Relation of a SOMDS Provider that expresses membership in a compound metric, the SOMDS Provider shall set pm:Code to the coded term of the compound metric it belongs to.

R0705

For each pm:Relation of a SOMDS Provider that expresses membership in a compound metric, the SOMDS Provider shall set @Kind to SST.

R0706

For each pm:Relation of a SOMDS Provider that expresses membership in a compound metric, the SOMDS Provider shall include all handle references of those metrics that belong to the same compound metric in pm:Relation/@Entries excluding the handle of the metric that contains the pm:Relation.

###### 3:8.3.2.10.7.2.2 State Part

R0707

For each compound metric of a SOMDS Provider, if @StartTime and @StopTime are available, the SOMDS Provider shall provide the same values for @StartTime and @StopTime in each metric of the compound metric to signify the same measurement cycle.

| @DeterminationTime may vary between individual metrics of the compound metric.

R0708

For each compound metric of a SOMDS Provider, if @StartTime and @StopTime are not available, the SOMDS Provider shall provide the same value for @DeterminationTime in each metric of the compound metric to signify the same measurement cycle.

##### 3:8.3.2.11 MDIB Efficiency Considerations

Typically, the product software of a medical device is neither designed to internally process data in accordance with the BICEPS Participant and Message Model nor does it natively implement an MDIB for use in an SDC System. This results in the need for a Manufacturer to transform a device’s internal data model into the BICEPS Participant Model.

This clause gives guidance regarding efficient distribution of MDIB data, which reduces processor load as well as bandwidth consumption in the MD LAN.

###### 3:8.3.2.11.1 Compression

Messages should be compressed such that the overall data rate in the MD LAN is reduced (see Appendix 2:A.5.3). Even though compression and decompression of data requires devices to consume additional CPU cycles, the transmission of data in the MD LAN is more expensive especially when using wireless technology.

###### 3:8.3.2.11.2 Modelling

The modelling of MDSs plays a crucial role in the efficiency of data distribution. The MDIB should be modelled in a minimalistic way, which results in the following recommendations:

Low-frequent @DeterminationPeriod

  Determination periods of metrics should be short enough such that data remains clinically relevant when transmitted, but long enough such that data transmission does not cause high processor and network load.

Metrics having a common @DeterminationPeriod

  This allows for the SOMDS Provider to collect updates in a single metric report instead of clustering updates across many metric reports.

Waveforms having a common @DeterminationPeriod

  Real-time sample array metrics are used to model waveforms and are distributed by using the BICEPS WAVEFORM service. Analogous to other metric types, real-time sample array metrics should also share the same @DeterminationPeriod. This optimization is even more relevant since in general the determination period of real-time sample array metrics is significantly lower than of other metrics.

Localization

  By moving the provision of texts in different languages and sizes from the MDIB to the BICEPS LOCALIZATION SERVICE, a SOMDS Provider can tremendously reduce the overall size of the MDIB, which in turn reduces the workload required to initially retrieve BICEPS contents (see Section 2:3.30).

##### 3:8.3.2.12 MDIB Report Retrofit

A SOMDS Provider sends out episodic reports every time descriptors or states in the MDIB change. Descriptor changes cause corresponding states to also change whereas state changes do not cause descriptors to change. A SOMDS Provider is supposed to transmit every change of a descriptor and its corresponding states in the msg:DescriptionModificationReport message. Changes to states are transmitted in msg:ObservedValueStream, msg:WaveformStream, msg:EpisodicAlertReport, msg:EpisodicComponentReport, msg:EpisodicContextReport, msg:EpisodicMetricReport, and msg:EpisodicOperationalStateReport messages.

BICEPS also supports periodic reports, which are out of scope for this section.

The following list of requirements enhances the processing of reports in order to reduce optionality and hence increase interoperability between SOMDS Participants.

###### 3:8.3.2.12.1 Amendments

R1006

A SOMDS Provider shall send messages that convey msg:WaveformStream, msg:AbstractMetricReport, msg:AbstractOperationalStateReport, msg:AbstractComponentReport, msg:AbstractAlertReport, msg:ObservedValueStream, msg:DescriptionModificationReport, and msg:AbstractContextReport elements to a SOMDS Consumer in the ascending order of the MDIB's pm:MdibVersionGroup/@MdibVersion.

Notes

| BICEPS does not specify the order in which report messages are sent to SOMDS Consumers. This requirement restricts messages to be transmitted in the ascending order of the SOMDS Provider's MDIB version.

R1007

Within an MDIB sequence, a SOMDS Provider shall send msg:WaveformStream, msg:EpisodicMetricReport, msg:EpisodicOperationalStateReport, msg:EpisodicComponentReport, msg:EpisodicAlertReport, msg:ObservedValueStream, msg:DescriptionModificationReport, and msg:EpisodicContextReport messages with a strictly increasing msg:AbstractReport/@MdibVersion.

Notes

| This requirement verifies that for a SOMDS Provider there will be no two reports with the same MDIB version. Furthermore, it prohibits decrementing version numbers within an MDIB sequence.

R1008

A SOMDS Provider shall not send msg:DescriptionModificationReport messages in which any two descriptors have the same handle.

Notes

| This requirement simplifies processing of changes for a SOMDS Consumer in a way that the SOMDS Consumer can apply description modification changes one by one without additional consistency checks. If deletion and re-insertion of objects is needed, a SOMDS Provider sends out two description modification reports successively.

| DEPRECATION NOTICE - This requirement is being incorporated into the IEEE 11073-10207 BICEPS standard through a corrigendum. Once IEEE has published the IEEE 11073-10207 BICEPS Corrigenda, this SDPi requirement will be no longer needed, and will hence be removed.

R1009

A SOMDS Provider shall order msg:DescriptionModificationReport/msg:ReportPart elements in a way that for an inserted parent descriptor, inserted child descriptors appear after that parent descriptor.

Notes

| This explicitly requires to only communicate children as inserted if the parent has been inserted already, which simplifies insertion of descriptors on the SOMDS Consumer side.

| DEPRECATION NOTICE - This requirement is being incorporated into the IEEE 11073-10207 BICEPS standard through a corrigendum (albeit without the clarification note immediately above). Once IEEE has published the IEEE 11073-10207 BICEPS Corrigenda, this SDPi requirement will be no longer needed, and will hence be removed.

###### 3:8.3.2.12.2 Corrigenda

Requirement R1010 replaces biceps:R5024.

R1010

A SOMDS Provider shall not add pm:AbstractDescriptor elements to pm:AbstractDescriptors below msg:DescriptionModificationReport/msg:ReportPart.

Notes

| Replaces biceps:R5024: "Descriptors in this list SHALL not include nested descriptors."

Requirement R1011 replaces biceps:R5046.

R1011

A SOMDS Provider shall communicate a parent descriptor as deleted only if it does not include any child descriptors.

Notes

| Replaces biceps:R5046: "If a parent descriptor is deleted, then all child descriptors of that parent SHALL communicated as deleted in advance."

| DEPRECATION NOTICE - This requirement is being incorporated into the IEEE 11073-10207 BICEPS standard through a corrigendum. Once IEEE has published the IEEE 11073-10207 BICEPS Corrigenda, this SDPi requirement will be no longer needed, and will hence be removed.

#### 3:8.3.3 RESERVED

SDPi 2.0 Supplement Note: This is a place holder section for content modules related to the Personal Health Device (PHD) semantics defined in the IEEE 11073-10206 and 11073-20601 standards. Though there are no PHD requirements in this supplement, there are PHD profiles that may be integrated into the IHE DEV Technical Framework, and as a result may add content to this section.

### 3:8.4 RESERVED

Move IHE PCD 2019 TF-3 Section 4 Reserved to this SDPi 2.0 TF-3 Section 8.4

### 3:8.5 RESERVED

Move IHE PCD 2019 TF-3 Section 5 Reserved to this SDPi 2.0 TF-3 Section 8.5

### 3:8.6 RESERVED

Move IHE PCD 2019 TF-3 Section 6 Reserved to this 2.0 TF-3 Section 8.6

### 3:8.7 Device specialization content modules

#### 3:8.7.1 Device: Infusion Pump

Add the following BICEPS subsection to the end of the Infusion Pump specification content.

##### 3:8.7.1.4 SDC/BICEPS content module

SDPi 2.0 Supplement Note: Content for this section will be extended in SDPi 1.x and subsequent versions. The initial content will reflect what is provided in SDPi 2.0 Section 3:8.7.3.17.

#### 3:8.7.2 Device: Ventilator

Add the following BICEPS subsection to the end of the Ventilator specification content.

##### 3:8.7.2.6 SDC/BICEPS content module

SDPi 2.0 Supplement Note: Content for this section will be extended in SDPi 1.x and subsequent versions. The initial content will reflect what is provided in SDPi 2.0 Section 3:8.7.3.17.

Add the following BICEPS subsection to the end of the Physiologic monitor specification content.

#### 3:8.7.3 Device: Physiologic monitor

##### 3:8.7.3.17 SDC/BICEPS content module

The following BICEPS containment tree represents a highly-simplified physiologic monitor example. The represented physiologic monitor’s Medical Device System (MDS) comprises a blood pressure Virtual Medical Device (VMD), a Context and an AlertSystem:

Figure 3:8.7.3.17-1. Physiologic Monitor Containment Tree Example

The following XML snippet profiles BICEPS semantics in line with the containment tree shown in Figure 3:8.7.3.17-1. The snippet focuses on the descriptive part of the MDIB file and, more specifically, on the VMDs / Channels / Metrics substructure (i.e., the leftmost branch of Figure 3:8.7.3.17-1):

BICEPS MDIB snippet of physiologic monitor describing VMDs / Channels / Metrics

    <?xml version="1.0" encoding="UTF-8"?>
    	<msg:Mdib MdibVersion="........" SequenceId="urn:uuid:.........">
    		<pm:MdDescription DescriptionVersion="..">
    			<pm:Mds Handle="1" DescriptorVersion=".." SafetyClassification="MedA">
    				<pm:Type Code="69837">
    					<pm:ConceptDescription>MDC_DEV_METER_PHYSIO_MULTI_PARAM_MDS</pm:ConceptDescription>
    				</pm:Type>
    				<pm:AlertSystem Handle="Alertsystem.mds0" SafetyClassification="MedA" SelfCheckPeriod="PT4S">
    					<!-- This (non-displayed) AlertSystem section describes the AlertConditions and AlertSignals -->
    				</pm:AlertSystem>
    				<pm:SystemContext Handle="Systemcontext.mds0">
    					<!-- This (non-displayed) SystemContext section describes the different contexts, such as PatientContext, LocationContext and EnsembleContext -->
    				</pm:SystemContext>
    				<pm:Vmd Handle="1.1" SafetyClassification="MedA">
    					<pm:Type Code="69854">
    						<pm:ConceptDescription>MDC_DEV_METER_PRESS_BLD_VMD</pm:ConceptDescription>
    					</pm:Type>
    					<pm:Channel Handle="1.1.1" SafetyClassification="MedA">
    						<ext:Extension>
    							<msg:Retrievability xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message">
    								<msg:By Method="Get"/>
    								<msg:By Method="Ep"/>
    							</msg:Retrievability>
    						</ext:Extension>
    						<pm:Type Code="70687">
    							<pm:ConceptDescription>MDC_DEV_PRESS_BLD_NONINV_CHAN</pm:ConceptDescription>
    						</pm:Type>
    						<pm:Metric xsi:type="pm:NumericMetricDescriptor" Handle="0x0000B10D" SafetyClassification="MedA" Resolution="1" MetricCategory="Msrmt" MetricAvailability="Intr" LifeTimePeriod="PT24H">
    							<ext:Extension>
    								<msg:Retrievability xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message">
    									<msg:By Method="Get"/>
    									<msg:By Method="Ep"/>
    								</msg:Retrievability>
    							</ext:Extension>
    							<pm:Type Code="150021">
    								<pm:ConceptDescription>MDC_PRESS_BLD_NONINV_SYS</pm:ConceptDescription>
    							</pm:Type>
    							<pm:Unit Code="266016">
    								<pm:ConceptDescription>mmHg</pm:ConceptDescription>
    							</pm:Unit>
    							<pm:TechnicalRange Lower="0" Upper="400"/>
    						</pm:Metric>
    						<pm:Metric xsi:type="pm:NumericMetricDescriptor" Handle="0x0000B10E" SafetyClassification="MedA" Resolution="1" MetricCategory="Msrmt" MetricAvailability="Intr" LifeTimePeriod="PT24H">
    							<ext:Extension>
    								<msg:Retrievability xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message">
    									<msg:By Method="Get"/>
    									<msg:By Method="Ep"/>
    								</msg:Retrievability>
    							</ext:Extension>
    							<pm:Type Code="150022">
    								<pm:ConceptDescription>MDC_PRESS_BLD_NONINV_DIA</pm:ConceptDescription>
    							</pm:Type>
    							<pm:Unit Code="266016">
    								<pm:ConceptDescription>mmHg</pm:ConceptDescription>
    							</pm:Unit>
    							<pm:TechnicalRange Lower="0" Upper="400"/>
    						</pm:Metric>
    					</pm:Channel>
    				</pm:Vmd>
    			</pm:Mds>
    		</pm:MdDescription>
    		<pm:MdState StateVersion="...">
    			<!-- This (non-displayed) MdState section contains the state of Metrics, Channels, VMDs, Context, AlertSystems, AlertConditions, AlertSignals, LimitsAlertConditions, etc. - referring to the handles defined in the MdDescription section -->
    		</pm:MdState>
    	</msg:Mdib>

Add the following Surgical device section after the Physiologic Monitor specification.

#### 3:8.7.4 Device: Surgical

##### 3:8.7.4.1 SDC/BICEPS content module

SDPi 2.0 Supplement Note: Content for this section will be extended in SDPi 1.x and subsequent versions. The initial content will reflect what is provided in SDPi 2.0 Section 3:8.7.3.17.

## Appendix 3:A BICEPS Extension Provisions XML Schemas

XML Schemas in this appendix include the BICEPS message, participant and extension Model files as provided as an additional resource at https://standards.ieee.org/ieee/11073-10207/6032/.

### 3:A.1 Coded Attribute XML Schema

    <?xml version="1.0" encoding="UTF-8"?>
    <xsd:schema
    		xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    		xmlns:ext="http://standards.ieee.org/downloads/11073/11073-10207-2017/extension"
    		xmlns:sdpi="urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1"
    		xmlns:pm="http://standards.ieee.org/downloads/11073/11073-10207-2017/participant"
    		targetNamespace="urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1"
    		elementFormDefault="qualified"
    		attributeFormDefault="unqualified"
    		xml:lang="en">
    	<xsd:import namespace="http://standards.ieee.org/downloads/11073/11073-10207-2017/extension" schemaLocation="../ExtensionPoint.xsd"/>
    	<xsd:import namespace="http://standards.ieee.org/downloads/11073/11073-10207-2017/participant" schemaLocation="../BICEPS_ParticipantModel.xsd"/>
    	<!---->
    	<!---->
    	<!--CodedStringAttribute-->
    	<xsd:element name="CodedAttributes" type="sdpi:CodedAttributesType"/>
    	<xsd:complexType name="CodedAttributesType">
    		<xsd:sequence>
    			<xsd:element ref="sdpi:CodedStringAttribute" minOccurs="0" maxOccurs="unbounded"/>
    			<xsd:element ref="sdpi:CodedIntegerAttribute" minOccurs="0" maxOccurs="unbounded"/>
    			<xsd:element ref="sdpi:CodedDecimalAttribute" minOccurs="0" maxOccurs="unbounded"/>
    		</xsd:sequence>
    		<xsd:attribute ref="ext:MustUnderstand" use="optional"/>
    	</xsd:complexType>
    	<!---->
    	<!---->
    	<xsd:element name="CodedStringAttribute" type="sdpi:CodedStringAttributeType">
    		<xsd:annotation>
    			<xsd:documentation>A key value pair to include string attributes of the IEEE 11073 classic domain information model that are not available from the BICEPS participant model.</xsd:documentation>
    		</xsd:annotation>
    	</xsd:element>
    	<xsd:complexType name="CodedStringAttributeType">
    		<xsd:annotation>
    			<xsd:documentation>Type definition of CodedStringAttribute.</xsd:documentation>
    		</xsd:annotation>
    		<xsd:sequence>
    			<xsd:element ref="sdpi:MdcAttribute">
    				<xsd:annotation>
    					<xsd:documentation>Key of the key value pair. Describes the meaning of Value.</xsd:documentation>
    				</xsd:annotation>
    			</xsd:element>
    			<xsd:element name="Value" type="xsd:string">
    				<xsd:annotation>
    					<xsd:documentation>Value (user data) of the key value pair.</xsd:documentation>
    				</xsd:annotation>
    			</xsd:element>
    		</xsd:sequence>
    	</xsd:complexType>
    	<!---->
    	<!---->
    	<!--CodedIntegerAttribute-->
    	<xsd:element name="CodedIntegerAttribute" type="sdpi:CodedIntegerAttributeType">
    		<xsd:annotation>
    			<xsd:documentation>A key value pair to include integer attributes of the IEEE 11073 classic domain information model that are not available from the BICEPS participant model.</xsd:documentation>
    		</xsd:annotation>
    	</xsd:element>
    	<xsd:complexType name="CodedIntegerAttributeType">
    		<xsd:annotation>
    			<xsd:documentation>Type definition of CodedIntegerAttribute.</xsd:documentation>
    		</xsd:annotation>
    		<xsd:sequence>
    			<xsd:element ref="sdpi:MdcAttribute">
    				<xsd:annotation>
    					<xsd:documentation>Key of the key value pair. Describes the meaning of Value.</xsd:documentation>
    				</xsd:annotation>
    			</xsd:element>
    			<xsd:element name="Value" type="xsd:integer">
    				<xsd:annotation>
    					<xsd:documentation>Value (user data) of the key value pair.</xsd:documentation>
    				</xsd:annotation>
    			</xsd:element>
    		</xsd:sequence>
    	</xsd:complexType>
    	<!---->
    	<!---->
    	<!--CodedDecimalAttribute-->
    	<xsd:element name="CodedDecimalAttribute" type="sdpi:CodedDecimalAttributeType">
    		<xsd:annotation>
    			<xsd:documentation>A key value pair to include decimal attributes of the IEEE 11073 classic domain information model that are not available from the BICEPS participant model.</xsd:documentation>
    		</xsd:annotation>
    	</xsd:element>
    	<xsd:complexType name="CodedDecimalAttributeType">
    		<xsd:annotation>
    			<xsd:documentation>Type definition of CodedDecimalAttribute.</xsd:documentation>
    		</xsd:annotation>
    		<xsd:sequence>
    			<xsd:element ref="sdpi:MdcAttribute">
    				<xsd:annotation>
    					<xsd:documentation>Key of the key value pair. Describes the meaning of Value.</xsd:documentation>
    				</xsd:annotation>
    			</xsd:element>
    			<xsd:element name="Value" type="xsd:decimal">
    				<xsd:annotation>
    					<xsd:documentation>Value (user data) of the key value pair.</xsd:documentation>
    				</xsd:annotation>
    			</xsd:element>
    		</xsd:sequence>
    	</xsd:complexType>
    	<!---->
    	<!---->
    	<xsd:element name="MdcAttribute" type="sdpi:MdcAttributeType">
    		<xsd:annotation>
    			<xsd:documentation>Specifies the concept of the key in a key value pair as laid out by coded attributes.</xsd:documentation>
    		</xsd:annotation>
    	</xsd:element>
    	<xsd:complexType name="MdcAttributeType">
    		<xsd:annotation>
    			<xsd:documentation>Type definition of MdcAttribute.</xsd:documentation>
    		</xsd:annotation>
    		<xsd:attribute name="Code" type="pm:CodeIdentifier" use="required"/>
    		<xsd:attribute name="CodingSystem" type="xsd:anyURI" use="optional">
    			<xsd:annotation>
    				<xsd:documentation>The coding system of the this coded attribute. The implied value is "urn:oid:1.3.111.2.11073.10101.1".</xsd:documentation>
    			</xsd:annotation>
    		</xsd:attribute>
    		<xsd:attribute name="CodingSystemVersion" type="xsd:string" use="optional">
    			<xsd:annotation>
    				<xsd:documentation>CodingSystemVersion can be used to discriminate between different versions of a coding system. CodingSystemVersion is an optional value and can be omitted in cases where a coding system is backwards compatible or CodingSystem includes versioning information.</xsd:documentation>
    			</xsd:annotation>
    		</xsd:attribute>
    		<xsd:attribute name="SymbolicCodeName" type="pm:SymbolicCodeName" use="optional">
    			<xsd:annotation>
    				<xsd:documentation>If present, SymbolicCodeName is an alternative representation that can be used to perform a plausibility check against Code.</xsd:documentation>
    			</xsd:annotation>
    		</xsd:attribute>
    	</xsd:complexType>
    </xsd:schema>

### 3:A.2 Gender XML Schema

    <?xml version="1.0" encoding="UTF-8"?>
    <xsd:schema
    		xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    		xmlns:ext="http://standards.ieee.org/downloads/11073/11073-10207-2017/extension"
    		xmlns:sdpi="urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1"
    		targetNamespace="urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1"
    		elementFormDefault="qualified"
    		attributeFormDefault="unqualified"
    		xml:lang="en">
    	<xsd:import namespace="http://standards.ieee.org/downloads/11073/11073-10207-2017/extension" schemaLocation="../ExtensionPoint.xsd"/>
    	<!---->
    	<!---->
    	<!--Gender-->
    	<xsd:element name="Gender">
    		<xsd:annotation>
    			<xsd:documentation>An extension to qualify the administrative gender for patients in BICEPS.

    This extension can be attached to the pm:PatientDemographicsCoreData/ext:Extension element.
    		</xsd:documentation>
    		</xsd:annotation>
    		<xsd:complexType>
    			<xsd:simpleContent>
    				<xsd:extension base="sdpi:GenderType">
    					<xsd:attribute ref="ext:MustUnderstand" use="optional"/>
    				</xsd:extension>
    			</xsd:simpleContent>
    		</xsd:complexType>
    	</xsd:element>
    	<xsd:simpleType name="GenderType">
    		<xsd:annotation>
    			<xsd:documentation>Type defining the gender information of a patient.

    This allows the differentiation between Sex and Gender in a pm:PatientDemographicsCoreData as in HL7 FHIR (https://hl7.org/fhir/valueset-administrative-gender.html).</xsd:documentation>
    		</xsd:annotation>
    		<xsd:restriction base="xsd:string">
    			<xsd:enumeration value="Male"/>
    			<xsd:enumeration value="Female"/>
    			<xsd:enumeration value="Other"/>
    			<xsd:enumeration value="Unknown"/>
    		</xsd:restriction>
    	</xsd:simpleType>
    </xsd:schema>

### 3:A.3 Equipment Identifier XML Schema

    <?xml version="1.0" encoding="UTF-8"?>
    <xsd:schema
    		xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    		xmlns:ext="http://standards.ieee.org/downloads/11073/11073-10207-2017/extension"
    		xmlns:sdpi="urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1"
    		targetNamespace="urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1"
    		elementFormDefault="qualified"
    		attributeFormDefault="unqualified"
    		xml:lang="en">
    	<xsd:import namespace="http://standards.ieee.org/downloads/11073/11073-10207-2017/extension" schemaLocation="../ExtensionPoint.xsd"/>
    	<!---->
    	<!---->
    	<!--Equipment Identifier-->
    	<xsd:element name="EquipmentIdentifier">
    		<xsd:annotation>
    			<xsd:documentation>An extension to identify equipment provided by the MDIB of a SOMDS Provider.

    This extension can be attached to the pm:MdsDescriptor/ext:Extension or pm:VmdDescriptor/ext:Extension element.
    		</xsd:documentation>
    		</xsd:annotation>
    		<xsd:complexType>
    			<xsd:simpleContent>
    				<xsd:extension base="sdpi:EquipmentIdentifierType">
    					<xsd:attribute ref="ext:MustUnderstand" use="optional"/>
    				</xsd:extension>
    			</xsd:simpleContent>
    		</xsd:complexType>
    	</xsd:element>
    	<xsd:simpleType name="EquipmentIdentifierType">
    		<xsd:annotation>
    			<xsd:documentation>Type defining the EquipmentIdentifier.

    The equipment identifier is an URI. It is stable, globally unique and constant across re-initializations of the SOMDS Provider.</xsd:documentation>
    		</xsd:annotation>
    		<xsd:restriction base="xsd:anyURI">
    			<xsd:minLength value="1"/>
    		</xsd:restriction>
    	</xsd:simpleType>
    </xsd:schema>

## Appendix 3:B BICEPS Extension Namespace

Extensions to the BICEPS Participant and Message Model defined in this specification utilize the XML Schema target namespace URI `urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1`, of which the OID is further detailed in Table 3:B-1.

IHE Devices domain top-level OIDs are available at the IHE Domain Namespaces wiki. A comprehensive listing of OIDs within the IHE Devices namespace is shown at the IHE PCD OID Management wiki page.

Table 3:B-1. SDPi BICEPS Extension Namespace OID Assignment
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.1 | Extensions to the BICEPS Participant and Message Model | biceps-extensions
1.3.6.1.4.1.19376.1.6.2.10.1.1.1 | Major version 1 for extensions to the BICEPS Participant and Message Model. In order to avoid proliferation of OIDs below `1.3.6.1.4.1.19376.1.6.2.10.1.1`, versions are incremented only if incompatible changes are made to an extension. | version1
1.3.6.1.4.1.19376.1.6.2.10.1.2 | Subscription filter dialect used to identify Hello/Bye subscriptions provided by a Discovery Proxy. | subscription-filter

1. Adapted and reprinted with permission from IEEE. Copyright IEEE Year. All rights reserved.
2. Note that SDPi-P supports application interoperability including “Software as a Medical Device” (SaMD).
3. See the IHE Technical Frameworks General Introduction for a more detailed description of IHE profile types, published at profiles.ihe.net/GeneralIntro/.
4. See Section 3:8.3.2.1.
5. See #General Introduction Appendix A for more detail on SES+MDI
6. Apply Postel’s Law: Send conservatively, Accept liberally.
7. A more detailed explanation of this model is provided on the IHE-HL7 Gemini Hanging Gardens Framework confluence page. Last accessed 2022.10.04.
8. For definitions of these and other related terms, consult the NHS 81001.org web page. Last accessed 2022.10.04.