A Joint HL7-IHE Gemini Device Interoperability Project

IHE Devices

Technical Framework Supplement

Service-oriented Device Point-of-care

Interoperability (SDPi)

Revision 1.0.0 — Draft for Public Comment


Date:

2023-02-28 17:30:37 UTC

Author:

Devices Technical Committee / DPI Program

Email:

DEV@ihe.net


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


Supplement Forward Declarations

SDPi Supplement Version 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 8.3.2.6

System Type

CS

Central Station

Section 8.3.2.6

System Type

DGW

Data Gateway

Section 8.3.2.6

System Type

DDES

Device Data to Enterprise Systems

Appendix 1:C.5

Use Case

MDPWS

Medical Device Profile for Web Services

[ISO/IEEE 11073-20702:2016]

Standard

SAS

Smart Alerting System

Section 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


Foreword

This is a supplement to the IHE Devices Technical Framework Revision 10.0. 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 February 28, 2023 for Public Comment. Comments are invited and can be submitted at http://www.ihe.net/Public_Comment/#domainname. In order to be considered in development of the Trial Implementation version of the supplement, comments must be received by March 28, 2023.

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

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

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

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

Introduction to this Supplement

SDPi 1.0 Supplement — Public Comment Review Version — Note:

This release of the SDPi 1.0 supplement is intended for IHE Public Comment review, with a focus on both technical content as well editorial maturity (e.g., clarity, grammar, formatting, etc.). It is recognized that there are both technical and editorial issues that need to be resolved before the Trial Implementation version is released. Known issues with this Public Comment version include:

  1. The content is scoped per the SDPi 1.0 version capabilities specification (see wiki article "SDPi Version 1.0 (Detail)"), though future capabilities may be included in a Reviewer Note; continued development of SDPi 1.x and beyond will begin early in 2023 DURING the 1.0 review periods;

  2. Supplement organization is based on the IHE Supplement Template from 2020 and 2022 (v10.6); as a supplement to the IHE Devices technical framework, the section allocation and organization anticipates the IHE PCD 2019 (see Appendix 1:B) being updated into an IHE DEV 2022 version that also conforms to the updated IHE Techncial Feramework template(s);

  3. This supplement includes (4) SDPi profiles; however, the general IHE Supplement Template 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 for clarity;

  4. Open / Closed Issues tables — for SDPi 1.0 there is an initial approach that integrates with the Gemini SES+MDI program work flow (from Confluence issues to Github Issues to specification content); however, there is discussion around how to better improve this in future

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

  6. 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 SDPi 1.x and subsequent versions;

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

  8. FOR THE PUBLIC COMMENT version of the supplement, the document source was migrated from the IHE sdpi-fhir Github to a new IHE DEV.SDPi profile-specific Github repository; links to the old repository may remain or may be updated to the new depending on the material being referenced (e.g., in open / closed issues).

"SDPi 1.0 Supplement Note" boxes are provided throughout the document to help guide reviewers and to ask specific questions for feedback requested by the supplement editors.

REVIEWER FOCUS: Please review the document especially with a technical and general organizational focus. Does the information flow logically and sufficiently for adopters and implementers? Is the text clear and sufficient or do specific subject areas need to be expanded or reworked. Do the links work and lead to the right "best" destinations?

Supplement Forward Declarations

SDPi Supplement Version 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 8.3.2.6

System Type

CS

Central Station

Section 8.3.2.6

System Type

DGW

Data Gateway

Section 8.3.2.6

System Type

DDES

Device Data to Enterprise Systems

Appendix 1:C.5

Use Case

MDPWS

Medical Device Profile for Web Services

[ISO/IEEE 11073-20702:2016]

Standard

SAS

Smart Alerting System

Section 8.3.2.6

System Type

SICDmp

Standalone ICU Dashboard Multiple Patient

Appendix 1:C.4

Use Case

SICDsp

Standalone ICU Dashboard Single Patient

Appendix 1:C.3

Use Case

STAD

Synchronized Time Across Devices

Appendix 1:C.2

Use Case


SDPi Supplement Overview

SDPi Supplement Organization

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

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

  • SDPi-Reporting (SDPi-R) Profile

  • SDPi-Alerting (SDPi-A) Profile

  • SDPi-external Control (SDPi-xC) Profile

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

TF-1 Profiles

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

  • Profile specific sections

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

TF-2 Transactions

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

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

TF-3 Content Modules

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


Joint IHE-HL7 Gemini SES+MDI Project Development

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

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

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

Supplement Support for RI+MC+RR using AsciiDoc

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

  1. Requirements Interoperability + Model Centric + Regulatory Ready

Or RI+MC+RR for short.

These three objectives may be summarized as follows:

  • Requirements Interoperability (RI)

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

  • Model Centric (MC)

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

  • Regulatory Ready (RR)

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

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

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

SDPi Issue Management

SDPi "Topic of Interest" Issue Management

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

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

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

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

Open Issues and Questions

  • Issue: SystemContext Profiling & Use

    • How should SDPi profile(s) use the SDC SystemContext (Location, Patient, Ensemble, Workflow) capabilities? Including device pairing / coupling. Which SystemContext component? Is this an option on the SDPi-P profile? Other profiles? IEEE 11073-1070x PKP requirements?

  • Issue: MDIB Version Update Guidelines

    • SDC provides "version" indicators to enable CONSUMER systems to determine what has changed. However, this can result in considerable "chatter" on the network if not properly managed. What guidelines and requirements should be specified in SDPi-P? Also how managed with waveforms vs. parameters.

  • Issue: Profiling BICEPS Services in SDPi-P

    • SDC/BICEPS provides a general service model that supports many implementation approaches. How should the services be utilized in SDPi-Plug-n-trust 1.0?

  • Issue: Security Certificate Provisioning

    • ISO/IEEE 11073-20702 MDPWS defines how WS-Security w/ X.509 certificates and Extended Key Use (EKU) provisions should be adapted for SDC; however, SDPi profiles will not only add specificity, but also address operationalization challenges including security certificate provisioning. What should be added to the SDPi supplement to support this operationalization? What should be added to the Gemini SDPi+FHIR program, including tooling and testing, to support SDPi security?

  • Issue: BICEPS Extension Model Use in SDPi?

    • SDC provides for extensions, especially in BICEPS. How should these be included and utilized in SDPi? A key issue to avoid is the infamous HL7 V2 "Z" segment, which was over used and negatively impacted interoperability.

  • Issue: Discovery Proxy Actors

    • Note: This issue is targeted for v1.1 but may have some element in v1.0

    • ISO/IEEE 11073 SDC provides for both implicit and explicit discovery; however, for some implementations this may result in unwanted message traffic across the network; the use of a "discovery proxy" has been proposed and could be added as an optional SDPi actor.

  • Issue: SDPi-xC with Mixed Device Safety Classes

Closed Issues

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.x by adding the following:

9.1.5 IEEE 11073 (Health Device Interoperability)

SDPi Supplement Version 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 to use portions of 11073-10207, 11073-20701, 11073-20702 (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 Actor Summary Definitions

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 MDIB information conformant to [ISO/IEEE 11073-10207:2017] BICEPS specifications provided by BICEPS Content Creator systems.

BICEPS Content Creator

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

SOMDS ACM Gateway

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.

SOMDS Connector

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.

SOMDS Consumer

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.) Note: A SOMDS Consumer is the primary actor providing communication for the BICEPS Content Consumer.

SOMDS DEC Gateway

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.

SOMDS FHIR Gateway

A SOMDS Connector that supports use of HL7 FHIR for bi-directional exchange with non-SOMDS Systems.

SOMDS FHIR Medical Data Gateway

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

SOMDS Medical Alert Consumer

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

SOMDS Medical Alert Provider

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

SOMDS Medical Control Consumer

A SOMDS Consumer grouped actor that receives medical device external control service capability information from a SOMDS Medical Control Provider to both invoke the controls and manage the device’s operation.

SOMDS Medical Control Provider

A SOMDS Provider grouped actor that provides medical device external control service capability information to a SOMDS Medical Control Consumer enabling both external control service invocation and allowing management of its operation.

SOMDS Medical Data Consumer

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

SOMDS Medical Data Provider

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

SOMDS Participant

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)

SOMDS Provider

A SOMDS Participant that provides at least one service to the other participant systems. (See [ISO/IEEE 11073-10207:2017] “SERVICE PROVIDER” definition) Note: A SOMDS Provider is the primary actor providing communication for the BICEPS Content Creator.

SOMDS Sensor Gateway

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

SOMDS Smart App Platform

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

SOMDS V2 Gateway

A SOMDS Connector that supports use of HL7 Version 2 (V2) for interoperating with Non-SOMDS Systems.

The table below lists existing Actors that are utilized in this profile.

Table B-1. Complete List of Existing Actors Utilized in this Profile
Existing Actor Name Definition

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

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

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

The Alert Consumer (ACON) Actor 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
(TBD) External to the ACM Gateway …​ but will be indicated …​ externally …​ include?

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

Alert Reporter

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

Device Observation Consumer
(TBD) Needed if any SOMDS-external info coming back; NOT IMPLEMENTED IN SDPi 1.0 but included in the Actor diagram

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) Actor receives data from PCDs, including those based on proprietary formats, and maps the received data to transactions providing consistent syntax and semantics.

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

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

Appendix B Transaction Summary Definitions

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

This transaction is used to 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

This transaction is used to discover and resolve all available SOMDS Providers a SOMDS Consumer is potentially interested in.

DEV-25

Discover BICEPS Services

This transaction is used to exchange the 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

This transaction is used to 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

This transaction is used to notify a SOMDS Consumer about changes in system context and capabilities of a SOMDS Provider.

DEV-29

Publish BICEPS Update Reports

This transaction is used to 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

This transaction is used to 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

This transaction is used to notify all SOMDS Consumers that a SOMDS Provider is leaving the network.

DEV-35

Establish Medical Data Exchange

This transaction is used to establish the exchange of medical data between a SOMDS Provider and a SOMDS Consumer.

DEV-36

Publish Medical Data

This transaction is used to publish medical data from a SOMDS Provider to a SOMDS Consumer.

DEV-37

Retrieve Medical Data

This transaction is used to for a SOMDS Consumer to retrieve medical data from a SOMDS Provider. Note, that there is no particular get operation for retrieving medical alert status information. Thus, the generic GetMdib/GetMdibResponse mechanisms are described here.

DEV-38

Establish Medical Alert Exchange

This transaction is used to establish the exchange of medical alerts from a SOMDS Provider to a SOMDS Consumer.

DEV-39

Publish Medical Alert Update

This transaction is used to notify a SOMDS Consumer about changes in the medical alert status of a SOMDS Provider.

DEV-40

Retrieve Medical Alert Status

This transaction is used to for a SOMDS Consumer to retrieve the medical alert status of a SOMDS Provider. Note, that there is no particular get operation for retrieving medical alert status information. Thus, the generic GetMdib/GetMdibResponse mechanisms are described here.

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

Reserved

DEV-47

Reserved

DEV-48

Reserved

DEV-49

Reserved

DEV-50

Reserved

Appendix D Glossary

SDPi Supplement Version 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. See ANSI.org for more information.

…​

ANSI

Organization

Basic ICE Protocol Specification

General reference to the abstract, implementation technology independent SDC components defined in the ISO/IEEE 11073-10207 standard. (See [ISO/IEEE 11073-10207:2017])

BICEPS

SDC

Central Station

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

See extended description and discussion in Section 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 8.3.2.9.3.

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. See "Local area network" article for more information and references.

LAN

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

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

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

Requirements Interoperability

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

RI+MC+RR

RI

See also MC and RR

Safe, Effective & Secure

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

SES

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

Service-oriented Device Connectivity

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

SDC

[ISO/IEEE 11073-20701:2018]

SDC

Service-oriented Device Point of Care Interoperability

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

SDPi

Profile

Service-oriented Architecture

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

SOA

SDC

Service-oriented Medical Device System

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

SOMDS

[ISO/IEEE 11073-10207:2017]

SDC

Smart Alarm System

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

SAS

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

Software as a Medical Device

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

SaMD

Source: IMDRF

SOMDS Provider UID

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

UID

SDC

Standards Development Organization

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

SDO

"Standards organization" wikipedia article

Organization

System Function Contribution

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

SFC

Adapted from [IEEE 11073-10700:2022].

SDC

Time Synchronization Service

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

TS Service

Transport Address

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

XAddr

QName

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

…​

…​

Volume 1 — Profiles

1:2 Devices Integration Profiles

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

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

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

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

REVIEWER QUESTION:

  1. Should the sections above be included in an updated IHE DEV TF specification?

  2. If so, should they be added in this SDPi Supplement or should they be added as a separate Change Proposal to the main IHE DEV TF (version 2022 or later)?

1:2.2 Safety, Effectiveness & Security Considerations and Requirements

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 termed: Safe Effective & Secure (SES) Considerations.

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 "SES 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 SES Considerations sections throughout the specification.

1:2.3 Integration Profiles Overview

SDPi Supplement Version 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) – Overview & Framework

The Service-oriented Device Point-of-care Interoperability (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-1.

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

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

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

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

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

  1. 4 Profiles — 

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

  2. Gateway Actors

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

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

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

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

  3. PKPs for Medical Purposes

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

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

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

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

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

  1. P → SDPi-Plug-and-trust

  2. R → SDPi-Reporting

  3. A → SDPi-Alerting

  4. C → SDPi-xControl

It should be noted that the primary use context for SDPi-enabled technologies is high acuity points of care, namely Operating Rooms, ICU beds, emergency beds, etc. The intent is D2D interactions with Gateway Actors providing integration with systems beyond the bedside, 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 Section 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 (SPDi-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 profile 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).

The baseline profile supports core functionality needed by all participating systems; whereas, profile options are provided for those additional capabilities that may be added (e.g., "ensemble context" management).

1:2.3.11 Service-oriented Device Point-of-care Interoperability - Reporting (SPDi-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 profile 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; whereas, profile options are provided for those additional capabilities that may be added.

1:2.3.12 Service-oriented Device Point-of-care Interoperability - Alerting (SPDi-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 profile implements the safety and security requirements of the [IEEE 11073-10702:202x] alert PKP standard (expected to be completed in 2023).

The profile supports core medical alerting functionality needed by all participating systems; whereas, profile options are provided for those additional capabilities that may be added (e.g., alert delegation).

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

SDPi Supplement Version Note: For SDPi 1.0, the SDPi-xC profile is provided for completeness and to show the general direction of the family of SDPi profiles. It is not part of the capabilities specified for 1.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 tritrate an infusion pump’s delivery rate. Given the significant risks associated with allowing device-external control functions in a network of PnT systems, this profile implements the safety and security requirements of the [IEEE 11073-10703:202x] external control PKP standard (in development, anticipated in 2023 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 based on the SOMDS Participant actor.

Required for consistent time-stamping of transactions and data.

SDPi-R

Device Enterprise Communication (DEC))

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

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

SDPi-A

Alert Communication Management (ACM)

The SOMDS ACM Gateway integrates ACM Alert Reporter (AR) actor specifications

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

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

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

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

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

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

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

SDPi Supplement Version Note: For SDPi 1.0 some Actors and transactions have been deferred to a subsequent version, but are included here for completeness. Specifically: SOMDS FHIR Gateway, SOMDS Sensor Gateway & SOMDS Smart App Platform, have been deferred.

Deferred transactions have been so indicated in the transactions table.

This section defines the Actors, transactions, and/or content modules in this profile. 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.1-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 10.3.

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

Table 1:10.1-1 lists the transactions for each Actor directly involved in the SDPi-P Profile. To claim conformity with this profile, 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 3.23

Discover Network Topology

Responder

R

Section 3.24

Discover BICEPS Services

Responder

R

Section 3.25

Discover System Context and Capabilities (deferred)

Responder

R

Deferred to SDPi 1.x

Manage BICEPS Subscription

Responder

R

Section 3.27

Notify Change in System Context and Capabilities

Initiator

O (See Note 1)

Section 3.28

Publish BICEPS Update Reports

Initiator

R

Section 3.29

Retrieve BICEPS Content

Responder

O

Section 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 3.34

SOMDS Consumer

Announce Network Presence

Receiver (See Note 2)

O

Section 3.23

Discover Network Topology

Initiator

R

Section 3.24

Discover BICEPS Services

Initiator

R

Section 3.25

Discover System Context and Capabilities (deferred)

Initiator

R

Deferred to SDPi 1.x

Manage BICEPS Subscription

Initiator

R

Section 3.27

Notify Change in System Context and Capabilities

Receiver (See Note 2)

O

Section 3.28

Publish BICEPS Update Reports

Receiver (See Note 2)

R

Section 3.29

Retrieve BICEPS Content

Initiator

O

Section 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 2)

O

Section 3.34

SOMDS Connector

See Note 3

…​

…​

…​

SOMDS FHIR Gateway (deferred)

…​

…​

…​

…​

SOMDS V2 Gateway

See Note 3

…​

…​

…​

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: “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 3: 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 actor will create content for consumption by a SOMDS Consumer actor, 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 actor communicating content via the SOMDS Provider actor, and the BICEPS Content Consumer actor receiving it via the SOMDS Consumer actor. 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 actor is creating and sending content (e.g., patient demographics information) to a SOMDS Provider actor, the content module creator / consumer roles will be reversed.

A product implementation using this profile may group Actors 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 10.3 or in Section 10.6.


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

Table 1:10.1-2 lists the content module(s) defined in the SDPi-P Profile. To claim support with this profile, 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 8.3.2.1

Infusion Pump SDC/BICEPS Content Module

O

Section 8.7.1

Ventilator SDC/BICEPS Content Module

O

Section 8.7.2.6

Physiologic Monitor SDC/BICEPS Content Module

O

Section 8.7.3.17

Surgery Devices SDC/BICEPS Content Module

O

Section 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 8.3.2.1

Infusion Pump SDC/BICEPS Content Module

O

Section 8.7.1

Ventilator SDC/BICEPS Content Module

O

Section 8.7.2.6

Physiologic Monitor SDC/BICEPS Content Module

O

Section 8.7.3.17

Surgery Devices SDC/BICEPS Content Module

O

Section 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 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 3, and requirements related to content modules are detailed in TF-3 Section 8. This section documents any additional requirements on the profile’s content Actors.

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

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

Actor Summary Definition:

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

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

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

1:10.1.1.2 SOMDS Provider

Actor Summary Definition:

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

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

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

1:10.1.1.3 SOMDS Consumer

Actor Summary Definition:

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

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

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

1:10.1.1.4 SOMDS Connector

Actor Summary Definition:

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

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

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

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

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

Note that the term “connector” is used to allow for SOMDS interaction with other systems that do not require protocol “gateway” adaptation, but do require a consistent interface to the other participants within a SOMDS environment. See Section 10.1.1.7 and Section 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 8.3.2.4.

SDPi Supplement Version Note: For SDPi 1.0, the TF-3 SDC/BICEPS Mapping of SOMDS Connector Content Modules section is out-of-scope., but included above for completeness of this Actor overview.

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

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

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

1:10.1.1.5 SOMDS FHIR Gateway

Actor Summary Definition:

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

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

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

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

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

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

1:10.1.1.6 SOMDS V2 Gateway

Actor Summary Definition:

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

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

The SOMDS V2 Gateway actor 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 8, including Section 8.3.2.3.

Generally, the SOMDS V2 Gateway actor supports messaging from a SOMDS environment to V2-enabled systems, utilizing a SOMDS Consumer actor 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 the Section 12 below).

1:10.1.1.7 SOMDS Sensor Gateway

SDPi Supplement Version 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 actor. They shall implement either a SOMDS Provider and / or SOMDS Consumer actor.

The SOMDS Sensor Gateway actor 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 Supplement Version Note: Detailed specifications for this actor are deferred to a later version of the SDPi Supplement.

Actor Summary Definition:

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

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

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

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

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

See Section 10.4.1.8 for additional discussion.

1:10.1.1.9 BICEPS Content Creator

Actor Summary Definition:

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

All content created and provided by a BICEPS Content Creator shall be conformant to the BICEPS content module specifications in Section 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 actor shall be capable of processing information provided by a BICEPS Content Creator, in accordance to the BICEPS content module specifications in Section 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.2 SDPi-P Actor Options

SDPi Supplement Version Note: Profile options are out-of-scope for this version of the supplement. Future versions MAY include options such as the following (not in priority order):

  • Retrieve Remote Data

  • Streaming / Waveforms

  • Safe Data Transmission

  • Compact Representation

  • Patient Context Management

  • Archive Service

  • Localization Service

  • Ensemble Participation

  • Mobile Health / Cloud Connected

1:10.3 SDPi-P Required Actor Groupings

SDPi Supplement Version Note: As indicated in Figure 1:10.1-1 above, there are no explicit grouped actors in this profile; however, there are abstract Actors (SOMDS Participant and SOMDS Connector), and the SOMDS Connector may implement interfaces to SOMDS Provider or SOMDS Consumer to provide bidirectional exchanges with non-SOMDS systems. These actor relationships do not represent typical IHE grouped actors, but should be represented in more explicit detail. The best approach for achieving that clarity and specificity will be addressed in a future version after further review and discussion by the supplement development team.

1:10.4 SDPi-P Overview

1:10.4.1 Concepts

1:10.4.1.1 SOA & SOMDS Architecture Alignment

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

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

This generalized model includes (3) system roles:

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

  2. Service Registry — a SOA network capability enabling participating systems to discover services provided by networked systems, as well as information for how a service consumer system can

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

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

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

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

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

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

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

1:10.4.1.2 Medical Device Profile for Web Services (MDPWS)

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

1:10.4.1.3 General Healthcare vs. Medical Interoperability Purposes

SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.
1:10.4.1.4 Ensuring Time Synchronization

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

SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.
1:10.4.1.6 Aggregators, Proxies, Sensors

SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.
1:10.4.1.7 Protocol-Specific Gateways

SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.
1:10.4.1.8 Smart App Platforms

SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.
1:10.4.1.9 Workflow vs. Transport Actors and Interactions

SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.
1:10.4.1.10 SDC / BICEPS MDIB Versioning Management

SDPi Supplement Version 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 profile.

1:10.4.2.1 Synchronized Time Across Devices (STAD)

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

Specific capabilities supporting the STAD use case include:

1:10.4.2.2 Standalone ICU Dashboard Single Patient (SICDsp)

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

Specific capabilities supporting the SICDsp use case include:

1:10.4.2.3 Standalone ICU Dashboard Multiple Patient (SICDmp)

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

Specific capabilities supporting the SICDmp use case include:

1:10.4.2.4 Device Data to Enterprise Systems (DDES)

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

Specific capabilities supporting the DDES use case include:

1:10.4.2.5 Alerts to Clinician Notification Systems (ACNS)

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

Specific capabilities supporting the ACNS use case include:

1:10.4.2.6 Alerts to Alert Recording Systems (AARS)

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

Specific capabilities supporting the AARS use case include:

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

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 Appendix 1:A.4.

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

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 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 Supplement Version 1.0 Note: This initial 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 profile, namely communication of medical data to accomplish intended medical purposes, requires the completion and integration of two emerging ISO/IEEE standards: [IEEE 11073-10700:2022] and [IEEE 11073-10701:2022]. When these are published in early 2023, 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 specifications in this 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 profile 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 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 profile. 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 11.3.

vol1 diagram sdpi r actor
Figure 1:11.1-1. SDPi-R Actor Diagram


Table 1:11.1-1. SDPi-R Profile - Actors and Transactions

Actors

Transactions

Initiator or Responder

Optionality

Reference

Section 11.1.1.2

Establish Medical Data Exchange

Responder

R

Section 3.35

Publish Medical Data

Initiator

R

Section 3.36

Retrieve Medical Data

Responder

R

Section 3.37

SOMDS Medical Data Consumer

Establish Medical Data Exchange

Initiator

R

Section 3.35

Publish Medical Data

Responder

R

Section 3.36

Retrieve Medical Data

Initiator

O

Section 3.37

SOMDS DEC Gateway

Establish Medical Data Exchange

Initiator (See Note 1)

R

Section 3.35

Publish Medical Data

Responder (See Note 1)

R

Section 3.36

Retrieve Medical Data

Initiator (See Note 1)

O

Section 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

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 profile, as specified in Section 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 profile, as specified in Section 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 profile, as specified in Section 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 Supplement Version 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 Supplement Version 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 Supplement Version Note: As indicated in Figure 1:11.1-1 above, there are four grouped actors:

  1. SOMDS Medical Data Consumer with SOMDS Consumer

  2. SOMDS Medical Data Provider with SOMDS Provider

  3. SOMDS DEC Gateway with SOMDS V2 Gateway

  4. 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 Supplement Version Note: An overview of the concepts for this SDPi-R Profile will be provided in a future supplement version. Note that this profile 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 profile.

1:11.4.2.1 Standalone ICU Dashboard Single Patient (SICDsp)

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

Specific capabilities supporting the SICDsp use case include:

1:11.4.2.2 Standalone ICU Dashboard Multiple Patient (SICDmp)

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

Specific capabilities supporting the SICDmp use case include:

1:11.4.2.3 Device Data to Enterprise Systems (DDES)

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

Specific capabilities supporting the DDES use case include:

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

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 Supplement Version 1.0 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 Appendix 1:A.4.

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 Supplement Version 1.0 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 profile is the communication of medical alert information to accomplish intended medical purposes, it will require the completion and integration of the emerging ISO/IEEE 11073 Alert PKP standard [IEEE 11073-10702:202x]. When this new standard is published in late 2023 or early 2024, its requirements will be integrated into this supplement, with its Implementation Conformance Statement (ICS) added to Appendix 1:B.2. Many of those requirements will be mapped to the Actors, Transactions and other specifications in this profile.

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

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

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

The SDPi-Alerting ( SDPi-A) Profile supports the communication of alert information from one Service-oriented Medical Device System (SOMDS) to other SOMDS systems or to other external non-SOMDS systems utilizing a Alert Gateway. The Actors and Transactions in this profile 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 12.5.

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

This section defines the actors, transactions, and/or content modules in this profile. 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 12.3.

vol1 diagram sdpi a actor
Figure 1:12.1-1. SDPi-A Actor Diagram


Table 1:12.1-1. SDPi-A Profile - Actors and Transactions

Actors

Transactions

Initiator or Responder

Optionality

Reference

SOMDS Medical Alert Provider

Establish Medical Alert Exchange

Initiator

R

Section 3.38

Publish Medical Alert Update

Responder

R

Section 3.39

Retrieve Medical Alert Status

Initiator

R

Section 3.40

Manage Medical Alert Delegation (deferred)

Responder

R

DEV-41 Deferred to SDPi 2.0

Delegate Medical Alert (deferred)

Initiator

R

DEV-42 Deferred to SDPi 2.0

Update Alert Acknowledgement Status (deferred)

Initiator

R

DEV-43 Deferred to SDPi 2.0

SOMDS Medical Alert Consumer

Establish Medical Alert Exchange

Responder

R

Section 3.38

Publish Medical Alert Update

Initiator

R

Section 3.39

Retrieve Medical Alert Status

Responder

O

Section 3.40

Manage Medical Alert Delegation (deferred)

Responder

R

DEV-41 Deferred to SDPi 2.0

Delegate Medical Alert (deferred)

Initiator

R

DEV-42 Deferred to SDPi 2.0

Update Alert Acknowledgement Status (deferred)

Initiator

R

DEV-43 Deferred to SDPi 2.0

SOMDS ACM Gateway

Establish Medical Alert Exchange

Initiator

R

Section 3.38

Publish Medical Alert Update

Responder

R

Section 3.39

Retrieve Medical Alert Status

Initiator

O

Section 3.40

Update Alert Acknowledgement Status (deferred)

Initiator

O

dev-43 Deferred to SDPi 2.0

Note 1: If the SOMDS ACM Gateway supports Section 12.2.3, then bidirectional exchange is supported and the roles are expanded to "Initiator & Responder".

1:12.1.1 Actor Descriptions and Actor Profile Requirements

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 profile, as specified in Section 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 profile, as specified in Section 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 Actor 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 profile, as specified in Section 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 Supplement Version 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 transfer or "delegate" audible annunciation of alert conditions to another system. This option will enable both the DEV-41 Manage Medical Alert Delegation and DEV-42 Delegate Medical Alert transactions.

1:12.2.2 Alert User Acknowledgement Option

SDPi Supplement Version 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 DEV-43 Update Alert Acknowledgement Status transaction.

1:12.2.3 Remote Alert Signaling

SDPi Supplement Version 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 DEV-38 Establish Medical Alert Exchange and DEV-40 Retrieve Medical Alert Status transactions, and to initiate DEV-39 Publish Medical Alert Update transactions.

1:12.3 SDPi-A Required Actor Groupings

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

  1. SOMDS Medical Alert Consumer with SOMDS Consumer

  2. SOMDS Medical Alert Provider with SOMDS Provider

  3. 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 Supplement Version Note: An overview of the concepts for this SDPi-A Profile will be provided in a future supplement version. Note that this profile 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 profile.

1:12.4.2.1 Standalone ICU Dashboard Single Patient (SICDsp)

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

Specific capabilities supporting the SICDsp use case include:

1:12.4.2.2 Standalone ICU Dashboard Multiple Patient (SICDmp)

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

Specific capabilities supporting the SICDmp use case include:

1:12.4.2.3 Alerts to Clinician Notification Systems (ACNS)

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

Specific capabilities supporting the ACNS use case include:

1:12.4.2.4 Alerts to Alert Recording Systems (AARS)

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

Specific capabilities supporting the AARS use case include:

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

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 Appendix 1:A.4.

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 Supplement Version Note: This SDPi-xC (External Control) profile section is generally out-of-scope for the SDPi 1.0 version (see wiki article "SDPi Version 1.0 (Detail)"); however, it is provided here to indicate the intended direction of the SDPi profiles, with details being added in subsequent versions. Depending on capabilities, some very basic controls may need to be provided in 2023 as part of the 1.x or 2.0 versions, especially around external adjustment of settings (e.g., alert limits or to trigger a blood-pressure reading).

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

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

This section defines the actors, transactions, and/or content modules in this profile. 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 13.3.

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

Actors

Transactions

Initiator or Responder

Optionality

Reference

SOMDS Medical Control Provider

Manage Medical External Control (deferred)

Responder

R

DEV-44 Deferred to SDPi 3.0 or later

Invoke Medical Control Services (deferred)

Responder

R

DEV-45 Deferred to SDPi 3.0 or later

SOMDS Medical Control Consumer

Manage Medical External Control (deferred)

Initiator

R

DEV-44 Deferred to SDPi 3.0 or later

Invoke Medical Control Services (deferred)

Initiator

R

DEV-45 Deferred to SDPi 3.0 or later

1:13.1.1 Actor Descriptions and Actor Profile Requirements

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 profile, as specified in Section 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 profile, as specified in Section 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 profile.

1:13.3 SDPi-xC Required Actor Groupings

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

  1. SOMDS Medical Control Consumer with SOMDS Consumer

  2. 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 Supplement Version Note: An overview of the concepts for this SDPi-A Profile will be provided in a future supplement version. Note that this profile extends the concepts established in the base SDPi-P Profile.

1:13.4.2 Use Cases

SDPi Supplement Version Note: *For SDPi 1.0*, 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. For this SDPi 1.0 DEV Internal Review Version, this profile section remains incomplete, with significant content needing to be migrated from the Word version of the supplement and then integrated into this AsciiDoc specification. This will be completed in January and an updated DEV Internal Review Version published by mid-January.

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

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 Appendix 1:A.4.

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

SDPi Supplement Version Note: This appendix provides informative (vs. normative) information related to the unique way in which this supplement integrates requirements, both from referenced foundational standards and within this specification. For SDPi 1.0, given its non-normative nature, full detailing of the concepts and specifications is deferred to a subsequent revision of the specification. So, please excuse the incomplete sections with "placeholder" version notes! There is value, though, in giving the existing content a quick review and providing feedback that would inform subsequent revisions of the specification.

REVIEWER QUESTION: Please consider the topics that are included in this section and are either detailed or have version notes and provide feedback on:

  1. What additional topics should be included?

  2. What is the priority for the detailing and integration of these topics?

  3. Are there any that should be moved elsewhere — noting that the content of this appendix is intended to be considered for the IHE DEV Technical Framework as Final Text.

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 capabilties include:

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

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

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

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

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

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

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

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

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

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

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

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

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

Though a full explanation of the this 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 requirements, detailing clinical system functions ensure that all requirements and capabilities are rooted in the purposes that technology users are advancing, namely to provide safe;

  2. <inter layer interfaces Requirements → Capabilities API, Req Def → Req Usage >;

  3. <Standards groups / families - internally coherent …​ hopefully!>;

  4. <Vertical / horizontal>;

  5. <profiles navigate 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!>;

  7. <requirements interoperability traces "profile lines" from top to bottom>;

  8. <requirements TYPEs are rooted in the layers that they represent and link Defs to Usage, see <<vol1_clause_sdpi_requirements_core_model> section below.>.

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

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

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

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

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

  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 & 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, Security Considerations and Requirements" 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 SES Considerations sections grew out of the IHE "Security Considerations" sections + the IHE Devices "Safety Considerations" sections, but are now consolidated into a single SES Considerations 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

SDPi Supplement Version Note: For SDPi 1.0, the inclusion of SES Considerations sections is early and will be significantly extended in subsequent versions of the specification. Especially when requirements from the PKP standards are included in SDPi 1.1 and following.

Note: When the PKP standards are integrated into this specification, then specific requirements will be directly linked to these SES Considerations sections.

Given the forgoing discussion in section Section 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.

1:A.4 Safety, Effectiveness, Security Considerations and Requirements

1:A.4.1 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 Appendix 1:A.4.

1:A.4.2 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.

1:A.4.3 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.

1:A.4.4 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.5 Use Cases, MBSE Requirements Modeling & SysML 2.0

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

OMG's Systems Modeling Language 2.0 (see [OMG SysML ® 2.0] and [OMG SysML ® Intro-Graphical Notation 2.0]), provides extended support for requirements modeling that not only provides the foundation for MBSE’s Requirements Modeling, but also a computable specification that enables automated verification (e.g., using "Verification Cases").

1:A.6 SDPi Requirements Modeling & Integration

As pointed out above, requirements interoperability (RI) based on robust model-based metadata is a core, innovative aspect of this SDPi profiles specification. Given the ultimate intent to realize this description as 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, a simplified requirements model is provided below but is aligned with the [OMG SysML ® 2.0] section 7.20 Requirements language. Of course, that specification provides for significantly more detailed and complext modeling, the general constructs may be used in this document to start the transition toward that model. Note that SysML 2.0 also better supports model interoperability (tool-independent model exchange) and Model-Based Systems Engineering (MBSE) (see MBSE Wikipedia article and references), as well as the [IHE EU Experience-2021 IHE CA for MedTech Solutions] for an overview presentation of MBSE, MedTech system V&V, and IHE Conformity Assessment.

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 integrated with [OMG SysML ® 2.0] section 7.23 Verification Cases, to provide for advanced V&V of interoperable system components and entire systems of products.

1:A.6.1 SDPi Requirements Core Model

To formally integrate requirements in to this specification, the following requirements model provides the starting point:

vol1 diagram sdpi req types model
Figure 1:A.6.1-1. SDPi Requirements - Core Model

This model identifies a set of requirement "types" that are formalized in the specification. Each type is a source of requirements that are explicitly identified and formalized with appropriate metadata.

Model Element Description AsciiDoc Attribute Further Specified

SDPi Requirement

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

See subtypes

SDPi Requirement Group

Two or more SDPi Requirements may be collected into a group that is focused around a specific subject area.

sdpi_requirement_group

Usage

Requirement utilized in a specific use context that provides for its satisfaction.

sdpi_requirement_usage

Use Case Feature

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

sdpi_requirement_use_case

See TF-1 Appendix C, gherkin model

Ref. Standard ICS

Requirement definitions that are specified in a normative reference.

sdpi_requirement_ref_standard

SES

sdpi_requirement_ses

See SES section Appendix 1:A.2

Tech Feature

sdpi_requirement_tech_feature

1:A.6.2 Requirements Binding Strategies

Although Figure 1:A.6.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. 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 Usage 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 profile 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 and not the rule.

1:A.6.3 Alignment with SysML 2.0 Requirements Modeling

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

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

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

Appendix 1:B References

SDPi Supplement Version 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

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

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

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

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

  • [IEC 60601-1-8:2020], IEC 60601-1-8:2006/AMD2:2020, Medical electrical equipment — Part 1-8: General requirements for basic safety and essential performance — Collateral standard: General requirements, tests and guidance for alarm systems in medical electrical equipment and medical electrical systems; Amendment 1:2020, and Amendment 2:2020. available at IEC Webstore and the ISO standards store.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [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

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

Standard Version: IEEE 11073-10207:2017

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

ADD IEEE: Table 20 — General ICSs table here

1:B.2.3.2 Service Provider

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

ADD IEEE: Service Provider ICS table here

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

ADD IEEE: Service Consumer ICS table here

1:B.2.3.4 Remote Control

ADD IEEE: Remote Control ICS table here

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

ADD IEEE: Context Processing ICS table here

1:B.3 Bibliography

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

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

1:B.3.2 Standards & Publications

1:B.3.3 Presentations

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

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

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

SDPi Supplement Version Note: This initial section of Appendix C is mostly informative and is still being detailed. Completion is deferred until the Public Comment version or 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. Especialy 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 Supplement Version 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 Supplement Version 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 Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future.

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

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

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

Note that the 1.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 practise 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 Information 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 6.11.2.2.1.


vol1 diagram 60601 1 8 2020 figure 2
Figure 1:C.1.5.2.2-1. IEC 60601-1-8:2020, Figure 2 — Functions of a DISTRIBUTED ALARM SYSTEM utilizing a MEDICAL IT NETWORK

Examples include:

  • EXAMPLE 1 – A central station

  • EXAMPLE 2 – An electronic record-keeping device

  • EXAMPLE 3 – Remote viewing from home or office

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

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

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

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

Examples include:

  • Traditional Central Station;

  • Bed to Bed alarm feature supporting alarm acknowledge;

  • Caregiver worn device supporting alarm acknowledge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1:C.2.1 Narrative

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

1:C.2.2 Benefits

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

1:C.2.3 Technical View

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

1:C.2.4 Technical Pre-Conditions

Given All devices communicate using a common MD LAN protocol

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

1:C.2.5 Scenarios

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

Given Device has detected at least one TS Service

When The TS Service is operational

Then The device will synchronize its time with the TS Service

1:C.2.5.2 Scenario: STAD 1.2 - Device is connected to the MD LAN network with a TS Service and a user wants to change the device’s time

Given Device has detected at least one TS Service

When The TS Service is operational

And 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.3 Scenario: STAD 1.3 - Device is connected to the MD LAN network and cannot connect to a TS Service

SDPi Supplement Version Note: This scenario is currently out of scope

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.4 Scenario: STAD 1.4 - Devices are connected to the MD LAN network but cannot connect to a TS Service and a device’s time setting is changed manually

SDPi Supplement Version Note: This scenario is currently out of scope

Given Device has not detected any TS Services

When The TS Service is not operational or inaccessible

And The time at the device is changed manually

Then The device will resync its clock when the TS Service is operational or accessible

And The devices on the network will maintain their own clocks until the TS Service is operational or accessible.

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

1:C.3.1 Narrative

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

1:C.3.2 Benefits

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

1:C.3.3 Technical View

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

1:C.3.4 Technical Pre-Conditions

Given All devices communicate using a common MD LAN protocol

And At least one ICU Dashboard display

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

1:C.3.5 Scenarios

1:C.3.5.1 Scenario: SICDsp 2.1 - Devices are Accessible to the Dashboard

Given Dashboard has detected at least one assigned accessible ICU device

When the ICU devices are communicating on the MD LAN

Then the Dashboard will display parameter, waveform, alarm, setting, imagine, etc. information from all assigned accessible devices

1:C.3.5.2 Scenario: SICDsp 2.2 - ICU Devices are Inaccessible to the Dashboard

Given Dashboard cannot detect any assigned accessible ICU devices

Then the Dashboard will display an error message

1:C.3.5.3 Scenario: SICDsp 2.3 - One or more ICU devices become Inaccessible to the Dashboard

Given Dashboard cannot detect a previously detected assigned ICU device

Then the Dashboard will display an error message

1:C.4 Use Case Feature 3: Standalone ICU Dashboard Multiple Patient (SICDmp)

1:C.4.1 Narrative

Dr. Presky is in the ICU evaluating a trauma patient from a remote location in the ICU. The dashboard allows access to multiple patients, so he first needs to select the patient of interest. This can be done by location or by patient name (if available).

He can view previous radiology results, electrosurgical equipment settings, patient readings such as HR, Blood Pressure, SpO2 and associated waveforms integrated on his real-time ‘Dashboard’ display. The dashboard display can display visual alarms but does not sound alerts or provide any remote-control capabilities. (This display can be considered an xDISmp as described in Appendix 1:C.1.5.1.)

1:C.4.2 Benefits

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

1:C.4.3 Technical View

vol1 diagram use case sicdmp tech view
Figure 1:C.4.3-1. Standalone ICU Dashboard Multiple Patient (SICDmp) — Technical View

1:C.4.4 Technical Pre-Conditions

Given All devices communicate using a common MD LAN protocol

And At least one ICU Dashboard display

And Devices from specific ICU rooms have been assigned to the Dashboard

1:C.4.5 Scenarios

1:C.4.5.1 Scenario: SICDmp 3.1 - ICU Devices are Accessible to the Dashboard

Given Dashboard has detected at least one assigned accessible ICU device

When the ICU Devices are communicating on the MD LAN

Then the Dashboard will display parameter, waveform, setting, alarm, imaging, etc. information from those devices (based on configuration)

1:C.4.5.2 Scenario: SICDmp 3.2 - ICU Devices are Inccessible 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 Inccessible to the Dashboard

Given Dashboard cannot detect any previously assigned accessible ICU devices

Then the Dashboard will display an error message

1:C.5 Use Case Feature 4: Device Data to Enterprise Systems (DDES)

1:C.5.1 Narrative

Mercy Hospital is in the middle of a new EHR (Epic, Cerner, etc.) rollout. Joe Furst is responsible for integrating data from their ICU devices (patient monitors, ventilators, infusion devices, etc.) with the new EHR. Once they are done, the data from the devices will be reviewed/validated by the ICU clinicians and then automatically entered into the patient’s clinical record.

1:C.5.2 Benefits

Automatically feeding patient data from the medical devices to medical record applications reduces the documentation burden on the clinicians, improves the accuracy of the medical record and enables 'real-time' analysis of the data which can be used to generate (potentially AI based) smart alerts to the clinical staff.

1:C.5.3 Technical View

vol1 diagram use case ddes tech view
Figure 1:C.5.3-1. Device Data to Enterprise Systems (DDES) — Technical View

1:C.5.4 Technical Pre-Conditions

Given All devices communicate using a common MD LAN protocol

And There is at least one Data Gateway (DGW) Service

And All devices report either a device label and/or location

And A DGW Service is associated with a specific set of device labels, and/or location(s) (i.e. devices in scope).

1:C.5.5 Scenarios

1:C.5.5.1 Scenario: DDES 4.1 - New in scope device is connected to network with DGW service

Given The DGW Service has detected a new in scope device

When The DGW Service is operational

Then The DGW Service will connect to the device and export data to the EHR using the HL7 v2 based IHE DEV DOR actor of the DEV DEC profile

1:C.5.5.2 Scenario: DDES 4.2 - Data Gateway Service is connected to the EHR

Given The DGW Service is exporting data to the EHR

Then The DGW Service will comply with all IHE DEV 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 signalled at the patient bedside thereby reducing the amount of noise that the patient is subjected to and improving their ability to recuperate.

1:C.6.3 Technical View

vol1 diagram use case acns tech view
Figure 1:C.6.3-1. Alerts to Clinician Notification Systems (ACNS) — Technical View

1:C.6.4 Technical Pre-Conditions

Given All devices communicate using a common MD LAN protocol

And At least one Alert Gateway (AGW) Service on the MD LAN network

And At least one Clinical Notification System is connected to the AGW Service.

And All devices report either a device label and/or location and/or patient ID

And The AGW Service is associated with a specific set of device labels, and/or location(s) (Scope)

1:C.6.5 Scenarios

1:C.6.5.1 Scenario: ACNS 5.1 - New device is connected to network with AGW service

Given the AGW Service has detected a new device in its scope

When the AGW Service is operational

Then the AGW Service will connect to the device and communicate alerts to the Clinician Notification System

1:C.6.5.2 Scenario: ACNS 5.2 - The AGW service loses connectivity with the ICU devices

Given the AGW Service no longer communicates with ICU devices in its scope

When There is a communications failure

Then the AGW Service will notify the Clinician Notification System of the failure

Then when the AGW Service regains communication with the devices it will resume reporting active alerts to the Clinician Notification System

1:C.6.5.3 Scenario: ACNS 5.3 - The AGW service fails

Given the AGW Service fails

Then the Clinician Notification System will detect a loss of communications with the AGW Service

Then when the AGW Service recovers it will resume reporting active alerts to the Clinician Notification System

1:C.6.5.4 Scenario: ACNS 5.4 - The Clinician Notification System loses connectivity with the AGW

Given the Clinician Notification System can no longer communicate with the AGW Service

Then the Clinician Notification System will detect a loss of communications with the AGW Service

Then when connectivity recovers, the Clinician Notification System will resume reporting active alerts

1:C.7 Use Case Feature 6: Alerts to Alert Recording Systems (AARS)

1:C.7.1 Narrative

Mumbai General is in the process of installing an IT system which will capture alerts from their ICU devices (patient monitors, ventilators, infusion devices, etc.) for the purposes of occasional review by physicians and post-discharge analysis. (Other related use cases could include EHR capture of alerts or alert analysis).

1:C.7.2 Benefits

The ability to review alerts allows clinicians to track the condition of a patient over a longer time span. For example to see whether a medication is reducing the occurrence of specific events such as ventricular beats or tachycardia events.

1:C.7.3 Technical View

vol1 diagram use case aars tech view
Figure 1:C.7.3-1. Alerts to Alert Recording Systems (AARS) — Technical View

1:C.7.4 Technical Pre-Conditions

Given All devices communicate using a common MD LAN protocol

And At least one Alert Gateway (AGW) Service on the MD LAN

And At least one Alert Recording System is connected to the Alert Gateway (AGW) Service.

And All devices report either a device label and/or location and/or patient ID

And The AGW Service is associated with a specific set of device labels, and/or location(s) .

1:C.7.5 Scenarios

1:C.7.5.1 Scenario: AARS 6.1 - New device is connected to network with AGW service

Given the AGW Service has detected a new device in its scope

When the AGW Service is operational

Then the AGW Service will connect to the device and communicate alerts to the Alert Recording System

1:C.7.5.2 Scenario: AARS 6.2 - The AGW service loses connectivity with the ICU devices

Given the AGW Service no longer communicates with ICU devices in its scope

When There is a communications failure

Then the AGW will notify the Alert Recording System of the failure

Then when the AGW regains communication with the devices it will resume reporting active alerts to the Alert Recording System and attempt to backfill any missing alerts

1:C.7.5.3 Scenario: AARS 6.3 - The AGW service fails

Given the AGW fails

Then the Alert Recording System will detect a loss of communications with the AGW

Then when the AGW Service recovers it will resume reporting active alerts to the Alert Recording System and attempt to backfill any missing alerts

1:C.7.5.4 Scenario: AARS 6.4 - The Alert Recording System loses connectivity with the AGW

Given the Alert Recording System can no longer communicate with the AGW

Then the Alert Recording System will detect a loss of communications with the AGW Service

Then when the AGW Service regains communication with the Alert Recording System it will resume reporting active alerts to the Alert Recording System and backfill any missing alerts.

Volume 2 — Transactions

2:3 Transactions

2:3.23 Announce Network Presence [DEV-23]

2:3.23.1 Scope

This transaction is used to notify all SOMDS Consumers that a SOMDS Provider is connected to the network and ready to exchange messages with other SOMDS Participants.

2:3.23.2 Actor Roles

Table 2:3.23.2-1. Actor Roles DEV-23
Actor Roles

SOMDS Provider

Announces its presence by multicasting Hello messages to all listening systems.

SOMDS Consumer

Listens for Hello messages to identify any SOMDS Providers that it may exchange messages with and further retrieve a SOMDS Provider's service capabilities.

2:3.23.3 Referenced Standards

2:3.23.4 Messages

puml dev 23 sequence
Figure 2:3.23.4-1. Message Interaction Diagram DEV-23
2:3.23.4.1 Hello Message

BICEPS specifies an implicit discovery protocol for allowing SOMDS Consumers to receive a notification when a SOMDS Provider is ready to exchange messages with other SOMDS Consumers. The corresponding message for this transaction is called Hello.

Note that the Hello message described in this clause is a generic/abstract concept that can be implemented differently. It should not be confused with actual transport message specifications like, e.g. the WS-Discovery Hello message as described in Appendix 2:A.2.1.

The Hello is a multicast message that is sent from each SOMDS Provider to all listening SOMDS Consumers (zero to many). Limited but sufficient information is provided with the message to enable SOMDS Consumers to determine if they are interested in connecting with the SOMDS Provider discovering additional information.

2:3.23.4.1.1 Trigger Events

This message is sent

  1. whenever a SOMDS Provider joins an MD LAN,

  2. when a SOMDS Provider returns to normal on-line operation after having indicated temporary suspension of message exchanges, or

  3. when a SOMDS Provider changes its Discovery Scope.

2:3.23.4.1.2 Message Semantics
Provider UID

The SOMDS Provider UID.

Discovery Scope

The Discovery Scope of the SOMDS Provider.

2:3.23.4.1.3 Expected Actions

When a SOMDS Provider sends this message, there is no expected or required responses. This is due to the fact that either there are no SOMDS Consumers listening for announcement messages, or the information in the message (e.g., Discovery Type) is not of interest to any receiving SOMDS Consumers.

2:3.23.5 Safety, Effectiveness, Security Considerations and Requirements

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 Appendix 1:A.4.

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 shall be performed 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

This transaction is used to discover and resolve all available SOMDS Providers a SOMDS Consumer is potentially interested in.

2:3.24.2 Actor Roles

Table 2:3.24.2-1. Actor Roles DEV-24
Actor Roles

SOMDS Consumer

Initiates communication by sending Probe or Resolve messages to SOMDS Providers. Then listens for ProbeMatch and ResolveMatch messages to discover those SOMDS Providers that it intends to exchange messages with and further retrieves the SOMDS Provider's service capabilities.

SOMDS Provider

Listens for Probe and Resolve messages, which it responds to with ProbeMatch or ResolveMatch messages, respectively.

2:3.24.3 Referenced Standards

2:3.24.4 Messages

puml dev 24 sequence
Figure 2:3.24.4-1. Message Interaction Diagram DEV-24
2:3.24.4.1 Probe Message

BICEPS specifies an explicit discovery protocol for allowing SOMDS Consumers to discover all SOMDS Providers that are ready to exchange messages with SOMDS Consumers. The corresponding message to seek SOMDS Provider based on filter criteria is called Probe.

Note that the Probe message described in this clause is a generic/abstract concept that can be implemented differently. It should not be confused with actual transport message specifications like, e.g. the WS-Discovery Probe message as described in Appendix 2:A.2.2.

If a specific SOMDS Provider UID is unknown to a SOMDS Consumer, the SOMDS Consumer can send a Probe multicast message to all listening SOMDS Providers. Limited but sufficient information is provided with the message to enable SOMDS Providers to determine if they match the Discovery Scope requested by the SOMDS Consumer.

2:3.24.4.1.1 Trigger Events

The Probe message is sent whenever a SOMDS Consumer joins an MD LAN and is ready to exchange messages with SOMDS Providers.

2:3.24.4.1.2 Message Semantics
Discovery Scope

A Discovery Scope to filter against.

2:3.24.4.1.3 Expected Actions

When a SOMDS Consumer sends this message, every receiving SOMDS Provider that matches the requested Discovery Scope responds with a ProbeMatch message.

2:3.24.4.2 ProbeMatch Message

The ProbeMatch message is sent as part of the BICEPS explicit discovery protocol in response to an incoming Probe message.

Note that the ProbeMatch message described in this clause is a generic/abstract concept that can be implemented differently. It should not be confused with actual transport message specifications like, e.g. the WS-Discovery ProbeMatch message as described in Appendix 2:A.2.2.

The ProbeMatch message is a uni-cast message that is sent by a SOMDS Provider when an incoming Probe message contains a Discovery Scope that matches the SOMDS Provider's Discovery Scope. Limited but sufficient information is provided with the message to enable SOMDS Consumers to determine a matching SOMDS Provider's Provider UID and Transport Address.

2:3.24.4.2.1 Trigger Events

The ProbeMatch message is sent whenever a SOMDS Provider receives a Probe message that contains a Discovery Scope that matches the SOMDS Provider's Discovery Scope.

2:3.24.4.2.2 Message Semantics
Provider UID

The SOMDS Provider UID.

Transport Address

The Transport Address under which the SOMDS Provider can receive secured messages.

2:3.24.4.2.3 Expected Actions

The SOMDS Consumer that receives a ProbeMatch message can use the Transport Address to exchange secured messages with the SOMDS Provider from which it received the ProbeMatch message.

2:3.24.4.3 Resolve Message

BICEPS specifies an explicit discovery protocol for allowing SOMDS Consumers to discover all SOMDS Providers that are ready to exchange messages with SOMDS Consumers. The corresponding message to seek SOMDS Providers based on a unique identifier is called Resolve.

Note that the Resolve message described in this clause is a generic/abstract concept that can be implemented differently. It should not be confused with actual transport message specifications like, e.g. the WS-Discovery Resolve message as described in Appendix 2:A.2.2.

If a specific SOMDS Provider UID is known to a SOMDS Consumer, the SOMDS Consumer can send a Resolve multicast message to all listening SOMDS Providers. Limited but sufficient information is provided with the message to enable SOMDS Providers to determine if they match the SOMDS Provider UID requested by the SOMDS Consumer.

2:3.24.4.3.1 Trigger Events

The Resolve message is sent

  1. whenever a SOMDS Consumer joins an MD LAN and is ready to exchange messages with SOMDS Providers or

  2. when a SOMDS Consumer runs in a mode where it periodically checks for availability of SOMDS Providers matching a specific SOMDS Provider UID.

2:3.24.4.3.2 Message Semantics
Provider UID

The SOMDS Provider UID to resolve.

2:3.24.4.3.3 Expected Actions

When a SOMDS Consumer sends this message, every receiving SOMDS Provider that matches the requested SOMDS Provider UID responds with a ResolveMatch message.

2:3.24.4.4 ResolveMatch Message

The ResolveMatch message is sent as part of the BICEPS explicit discovery protocol in response to an incoming Resolve message.

Note that the ResolveMatch message described in this clause is a generic/abstract concept that can be implemented differently. It should not be confused with actual transport message specifications like, e.g. the WS-Discovery ResolveMatch message as described in Appendix 2:A.2.2.

The ResolveMatch message is a uni-cast message that is sent by a SOMDS Provider when an incoming Resolve message contains a Provider UID that matches the SOMDS Provider's SOMDS Provider UID. Limited but sufficient information is provided with the message to enable SOMDS Consumers to determine a matching SOMDS Provider's Transport Address.

2:3.24.4.4.1 Trigger Events

The ResolveMatch message is sent whenever a SOMDS Provider receives a Resolve message that contains a Discovery Scope that matches the SOMDS Provider's Discovery Scope.

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, Security Considerations and Requirements

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 Appendix 1:A.4.

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 shall be performed 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

This transaction is used to exchange the resources metadata between a SOMDS Provider and a SOMDS Consumer.

2:3.25.2 Actor Roles

Table 2:3.25.2-1. Actor Roles DEV-25
Actor Roles

SOMDS Consumer

Asks for the resource representation of the SOMDS Provider via the GetMetadata message.

SOMDS Provider

Sends its resource representation to the SOMDS Consumer via the GetMetadataResponse message.

2:3.25.3 Referenced Standards

2:3.25.4 Messages

puml dev 25 sequence
Figure 2:3.25.4-1. Message Interaction Diagram DEV-25
2:3.25.4.1 GetMetadata Message

The GetMetadata message is used by a SOMDS Consumer to request the resource representation data of a SOMDS Provider.

2:3.25.4.1.1 Trigger Events

This message is sent when a SOMDS Consumer has discovered a Transport Address for a SOMDS Provider.

2:3.25.4.1.2 Expected Actions

When a SOMDS Consumer sends this message, the GetMetadataResponse message is expected as a response.

2:3.25.4.2 GetMetadataResponse Message

The GetMetadataResponse message is sent in response to an incoming GetMetadata message.

2:3.25.4.2.1 Trigger Events

The GetMetadataResponse message is sent whenever a SOMDS Provider receives a GetMetadata message.

2:3.25.4.2.2 Message Semantics
BICEPS Services

Collection of BICEPS services the SOMDS Provider offers, including but not limited to one or multiple of the following BICEPS services ([ISO/IEEE 11073-10207:2017] Section 7.3 Service Model):

  • GET SERVICE (mandatory)

  • SET SERVICE

  • DESCRIPTION EVENT SERVICE

  • STATE EVENT SERVICE

  • CONTEXT SERVICE

  • WAVEFORM SERVICE

There is currently no mandatory support for provision of the LOCALIZATION SERVICE, CONTAINMENT TREE SERVICE and ARCHIVE SERVICE.
Device Metadata

Expresses SOMDS Provider characteristics that typically vary from one SOMDS Provider to another of the same kind, e.g.:

  • 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, e.g.:

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, Security Considerations and Requirements

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 Appendix 1:A.4.

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 shall be performed to ensure that no unacceptable harm results during SECURED message exchange.

2:3.27 Manage BICEPS Subscription [DEV-27]

2:3.27.1 Scope

This transaction is used to establish a publish-subscribe session between a SOMDS Provider, acting as the event source, and a SOMDS Consumer, acting as the event sink.

2:3.27.2 Actor Roles

Table 2:3.27.2-1. Actor Roles DEV-27
Actor Roles

SOMDS Consumer

Initiates communication by first subscribing to a SOMDS Provider by sending a Subscribe message. While the subscription is running, the subscription is kept alive by sending Renew messages and receiving Notification messages.

Finally, the SOMDS Consumer unsubscribes from a SOMDS Provider by sending an Unsubscribe message.

SOMDS Provider

Listens for Subscribe, Renew and Unsubscribe messages, which it responds to with SubscribeResponse, RenewResponse or UnsubscribeResponse messages respectively.

While a subscription is running, the SOMDS Provider delivers Notification messages.

When at some point the subscription has to be ended, the SOMDS Provider sends a SubscriptionEnd message.

2:3.27.3 Referenced Standards

2:3.27.4 Messages

puml dev 27 sequence
Figure 2:3.27.4-1. Message Interaction Diagram DEV-27
2:3.27.4.1 Subscribe Message

The Subscribe message is sent as part of the BICEPS publish-subscribe and streaming message exchange for allowing SOMDS Consumers to subscribe to data changes of SOMDS Providers.

2:3.27.4.1.1 Trigger Events

The Subscribe message is sent whenever a SOMDS Consumer intends to get notified on certain changes of a SOMDS Provider comprising

  • publish-subscribe message exchange and

  • stream message exchange.

2:3.27.4.1.2 Message Semantics
Filter

A filter to subscribe to a certain set of data items, including but not limited to one or multiple of the following:

Expiration Time

A time requested for subscription expiration.

2:3.27.4.1.3 Expected Actions

When a SOMDS Consumer sends this message, the receiving SOMDS Provider responds with a SubscribeResponse message.

2:3.27.4.2 SubscribeResponse Message

The SubscribeResponse message is sent as part of the BICEPS publish-subscribe and streaming message exchange in response to a Subscribe message to confirm a subscription.

2:3.27.4.2.1 Trigger Events

The SubscribeResponse message is sent whenever a SOMDS Provider receives a Subscribe message.

2:3.27.4.2.2 Message Semantics
Subscription Manager

Dedicated instance that manages the subscription, i.e. allows for a SOMDS Consumer to renew or cancel the subscription.

Expiration Time

Actual expiration time, which does not necessarily equals 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
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 equals 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

The Unsubscribe message does not contain any further semantics.

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, Security Considerations and Requirements

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 Appendix 1:A.4.

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 shall be performed 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

This transaction is used to notify a SOMDS Consumer about changes in system context and capabilities of a SOMDS Provider.

2:3.28.2 Actor Roles

Table 2:3.28.2-1. Actor Roles DEV-28
Actor Roles

SOMDS Consumer

Listens for a Notification message to retrieve context updates.

SOMDS Provider

While a subscription is running, the SOMDS Provider delivers Notification messages.

2:3.28.3 Referenced Standards

2:3.28.4 Messages

puml dev 28 sequence
Figure 2:3.28.4-1. Message Interaction Diagram DEV-28
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, Security Considerations and Requirements

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 Appendix 1:A.4.

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 shall be performed 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

This transaction is used to notify a SOMDS Consumer about changes in the alert, metric and component reports and in the waveform stream of a SOMDS Provider.

2:3.29.2 Actor Roles

Table 2:3.29.2-1. Actor Roles DEV-29
Actor Roles

SOMDS Consumer

Listens for a Notification message to retrieve update reports.

SOMDS Provider

While a subscription is running, the SOMDS Provider delivers Notification messages.

2:3.29.3 Referenced Standards

2:3.29.4 Messages

puml dev 29 sequence
Figure 2:3.29.4-1. Message Interaction Diagram DEV-29
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, Security Considerations and Requirements

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 Appendix 1:A.4.

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 shall be performed to ensure that no unacceptable harm results during SECURED message exchange.

2:3.30 Retrieve BICEPS Content [DEV-30]

2:3.30.1 Scope

This transaction is used to retrieve the MDIB of a SOMDS Provider a SOMDS Consumer is interested in.

2:3.30.2 Actor Roles

Table 2:3.30.2-1. Actor Roles DEV-30
Actor Roles

SOMDS Consumer

Initiates communication by sending a GetMdib message to a SOMDS Provider. Then listens for a GetMdibResponse message to retrieve the SOMDS Provider's MDIB.

SOMDS Provider

Listens for GetMdib messages, which it responds to with GetMdibResponse messages respectively.

2:3.30.3 Referenced Standards

2:3.30.4 Messages

puml dev 30 sequence
Figure 2:3.30.4-1. Message Interaction Diagram DEV-30
2:3.30.4.1 GetMdib Message

The GetMdib message is sent as part of the BICEPS GET SERVICE for allowing SOMDS Consumers to retrieve the description and state of an MDIB from a SOMDS Provider.

2:3.30.4.1.1 Trigger Events

The GetMdib message is sent whenever a SOMDS Consumer wants to retrieve the description and state of an MDIB of a SOMDS Provider.

2:3.30.4.1.2 Message Semantics

The GetMdib message does not contain any further semantics.

2:3.30.4.1.3 Expected Actions

When a SOMDS Consumer sends this message, the receiving SOMDS Provider responds with a GetMdibResponse message.

2:3.30.4.2 GetMdibResponse Message

The GetMdibResponse message is sent as part of the BICEPS GET SERVICE in response to an incoming GetMdib message.

2:3.30.4.2.1 Trigger Events

The GetMdibResponse message is sent whenever a SOMDS Provider receives a GetMdib message.

2:3.30.4.2.2 Message Semantics
MdDescription

The descriptive part of an MDIB.

MdState

The state part of an MDIB. (As the communication is encrypted, this can include ContextStates without violating [ISO/IEEE 11073-10207:2017] R0121.)

2:3.30.4.2.3 Expected Actions

When a SOMDS Provider sends this message, there is no expected or required response.

2:3.30.5 Safety, Effectiveness, Security Considerations and Requirements

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 Appendix 1:A.4.

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 shall be performed to ensure that no unacceptable harm results during SECURED message exchange.

2:3.34 Announce Network Departure [DEV-34]

2:3.34.1 Scope

This transaction is used to notify all SOMDS Consumers that a SOMDS Provider is leaving the network.

2:3.34.2 Actor Roles

Table 2:3.34.2-1. Actor Roles DEV-34
Actor Roles

SOMDS Provider

Announces its departure by multicasting Bye messages to all listening systems.

SOMDS Consumer

Listens for Bye messages to identify any SOMDS Providers that will leave the Medical Device LAN (MD LAN).

2:3.34.3 Referenced Standards

2:3.34.4 Messages

puml dev 34 sequence
Figure 2:3.34.4-1. Message Interaction Diagram DEV-34
2:3.34.4.1 Bye Message

The Bye message is part of the BICEPS implicit discovery protocol for allowing SOMDS Consumers to receive a notification when a SOMDS Provider is leaving the network.

The Bye is a multicast message that is sent from each SOMDS Provider to all listening SOMDS Consumers (zero to many).

2:3.34.4.1.1 Trigger Events

This message is sent whenever a SOMDS Provider leaves a network.

2:3.34.4.1.2 Message Semantics
Provider UID

The SOMDS Provider UID.

2:3.34.4.1.3 Expected Actions

When a SOMDS Provider sends this message, there is no expected or required response.

2:3.34.5 Safety, Effectiveness, Security Considerations and Requirements

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 Appendix 1:A.4.

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 shall be performed 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

This transaction is used to establish the exchange of medical data between a SOMDS Provider and a SOMDS Consumer.

2:3.35.2 Actor Roles

Table 2:3.35.2-1. Actor Roles DEV-35

Actor

Roles

SOMDS Consumer

Initiates communication by first subscribing to a SOMDS Provider by sending a Subscribe message.

SOMDS Provider

Listens for Subscribe messages, which it responds to with SubscribeResponse.

2:3.35.3 Referenced Standards

2:3.35.4 Messages

puml dev 35 sequence
Figure 2:3.35.4-1. Message Interaction Diagram DEV-35
Transaction DEV-35 syntactically duplicates DEV-27 (Section 3.27) and DEV-38 (Section 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, Security Considerations and Requirements

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 Appendix 1:A.4.

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 shall be performed to ensure that no unacceptable harm results during SECURED message exchange.

2:3.36 Publish Medical Data [DEV-36]

2:3.36.1 Scope

This transaction is used to publish medical data from a SOMDS Provider to a SOMDS Consumer.

2:3.36.2 Actor Roles

Table 2:3.36.2-1. Actor Roles DEV-36
Actor Roles

SOMDS Consumer

Listens for a Notification message to retrieve medical data updates.

SOMDS Provider

While a subscription is running, the SOMDS Provider delivers Notification messages.

2:3.36.3 Referenced Standards

2:3.36.4 Messages

puml dev 36 sequence
Figure 2:3.36.4-1. Message Interaction Diagram DEV-36
Transaction DEV-36 syntactically duplicates DEV-29 (Section 3.29) and DEV-39 (Section 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, Security Considerations and Requirements

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 Appendix 1:A.4.

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 shall be performed to ensure that no unacceptable harm results during SECURED message exchange.

2:3.37 Retrieve Medical Data [DEV-37]

2:3.37.1 Scope

This transaction is used to for a SOMDS Consumer to retrieve medical data from a SOMDS Provider. Note, that there is no particular get operation for retrieving medical alert status information. Thus, the generic GetMdib/GetMdibResponse mechanisms are described here.

2:3.37.2 Actor Roles

Table 2:3.37.2-1. Actor Roles DEV-37
Actor Roles

SOMDS Consumer

Initiates communication by sending a GetMdib message to a SOMDS Provider. Then listens for a GetMdibResponse message to retrieve the SOMDS Provider's MDIB.

SOMDS Provider

Listens for GetMdib messages, which it responds to with GetMdibResponse messages respectively.

2:3.37.3 Referenced Standards

2:3.37.4 Messages

puml dev 37 sequence
Figure 2:3.37.4-1. Message Interaction Diagram DEV-37

2:3.37.5 Safety, Effectiveness, Security Considerations and Requirements

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 Appendix 1:A.4.

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 shall be performed 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

This transaction is used to establish the exchange of medical alerts from a SOMDS Provider to a SOMDS Consumer.

2:3.38.2 Actor Roles

Table 2:3.38.2-1. Actor Roles DEV-38

Actor

Roles

SOMDS Consumer

Initiates communication by first subscribing to a SOMDS Provider by sending a Subscribe message.

SOMDS Provider

Listens for Subscribe messages, which it responds to with SubscribeResponse.

2:3.38.3 Referenced Standards

2:3.38.4 Messages

puml dev 38 sequence
Figure 2:3.38.4-1. Message Interaction Diagram DEV-38
Transaction DEV-38 syntactically duplicates DEV-27 (Section 3.27) and DEV-35 (Section 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, Security Considerations and Requirements

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 Appendix 1:A.4.

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 shall be performed 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

This transaction is used to notify a SOMDS Consumer about changes in the medical alert status of a SOMDS Provider.

2:3.39.2 Actor Roles

Table 2:3.39.2-1. Actor Roles DEV-39
Actor Roles

SOMDS Consumer

Listens for a Notification message to retrieve medical alert updates.

SOMDS Provider

While a subscription is running, the SOMDS Provider delivers Notification messages.

2:3.39.3 Referenced Standards

2:3.39.4 Messages

puml dev 39 sequence
Figure 2:3.39.4-1. Message Interaction Diagram DEV-39

2:3.39.5 Safety, Effectiveness, Security Considerations and Requirements

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 Appendix 1:A.4.

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 shall be performed 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

This transaction is used to for a SOMDS Consumer to retrieve the medical alert status of a SOMDS Provider. Note, that there is no particular get operation for retrieving medical alert status information. Thus, the generic GetMdib/GetMdibResponse mechanisms are described here.

2:3.40.2 Actor Roles

Table 2:3.40.2-1. Actor Roles DEV-40
Actor Roles

SOMDS Consumer

Initiates communication by sending a GetMdib message to a SOMDS Provider. Then listens for a GetMdibResponse message to retrieve the SOMDS Provider's MDIB.

SOMDS Provider

Listens for GetMdib messages, which it responds to with GetMdibResponse messages respectively.

2:3.40.3 Referenced Standards

2:3.40.4 Messages

puml dev 40 sequence
Figure 2:3.40.4-1. Message Interaction Diagram DEV-40
Transaction DEV-40 syntactically duplicates DEV-30 (Section 3.30) and DEV-37 (Section 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, Security Considerations and Requirements

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 Appendix 1:A.4.

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 shall be performed to ensure that no unacceptable harm results during SECURED message exchange.

Appendix 2:A ISO/IEEE 11073 SDC / MDPWS Message Specifications (Normative)

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
All port types of SDC are available for download.
Other port types are currently out of scope of this profile 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 3.23.

2:A.2.1.1 Hello Message

The Hello message is encoded by using WS-Discovery Hello.

2:A.2.1.1.1 Referenced Standards
2:A.2.1.1.2 Message Outline
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><!-- ... --></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 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 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 3.24.

2:A.2.2.1 Probe Message

The Probe message is encoded by using WS-Discovery Probe.

2:A.2.2.1.1 Referenced Standards
2:A.2.2.1.2 Message Outline
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"><!-- ... --></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 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:Hello/wsd:Scopes/@MatchBy

The algorithm used to compare the s12:Envelope/s12:Body/wsd:Hello/wsd:Scopes against the SOMDS Provider's scopes.

s12:Envelope/s12:Body/wsd:Hello/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 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.

Note

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.

Note

A dedicated user interaction can be a button press on a SOMDS Consumer's display or any other manual activation.

In addition, SOMDS Consumer may set filter criteria for Probe messages to reduce the amount of Probe Match messages. For example, Probe messages are sent only if a SOMDS Consumer is assigned to a patient and lost network connection.

2:A.2.2.1.6.2 Scope Matching
R7000

A SOMDS Provider shall implement the scope matching rule http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/rfc3986 as specified by [OASIS WS-Discovery:2009] in a way that the use of prefix refers to the definition of a prefix in formal theory.

Notes
This requirement erases disambiguation since there are multiple definitions of the term prefix.
From this it follows that a prefix can be empty as otherwise the term proper prefix would have to be used.
2:A.2.2.2 ProbeMatch Message

The ProbeMatch message is encoded by using WS-Discovery Probe Match.

2:A.2.2.2.1 Referenced Standards
2:A.2.2.2.2 Message Outline
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 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: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:Scopes

The Discovery Scope of the SOMDS Provider, encoded as a list of URIs.

s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:XAddrs

A list of HTTPS addresses under which the SOMDS Provider receives secured messages.

s12:Envelope/s12:Body/wsd:ProbeMatches/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 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
2:A.2.2.3.2 Message Outline
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 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 3.24.4.3.

2:A.2.2.4 ResolveMatch Message

The ResolveMatch message is encoded by using WS-Discovery Resolve Match.

2:A.2.2.4.1 Referenced Standards
2:A.2.2.4.2 Message Outline
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>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</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 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: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:Scopes

The Discovery Scope of the SOMDS Provider, encoded as a list of URIs.

s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:XAddrs

A list of HTTPS addresses under which the SOMDS Provider receives secured messages.

s12:Envelope/s12:Body/wsd:ResolveMatches/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 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 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
2:A.2.3.1.2 Message Outline
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 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 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
2:A.2.3.2.2 Message Outline
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 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 [message_semantics_discover_biceps_services_modelafebf313-ed8b-4252-9849-837f9cd49f57Model+Metadata].

s12:Envelope/s12:Body/wsm:Metadata/wsm:MetadataSection/dpws:ThisDevice

The SOMDS Provider's metadata that maps to the [message_semantics_discover_biceps_services_deviceafebf313-ed8b-4252-9849-837f9cd49f57Device+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 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 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
2:A.2.4.1.2 Message Outline
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 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 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
2:A.2.4.2.2 Message Outline
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 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 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.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
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
2:A.2.4.4.2 Message Outline
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 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 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
2:A.2.4.5.2 Message Outline
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 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 3.27.4.5.

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
2:A.2.4.6.2 Message Outline
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 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 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
2:A.2.4.7.2 Message Outline
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 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 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
2:A.2.4.8.2 Message Outline
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 3.27.4.8.

2:A.2.4.8.4 Message Semantics
s12:Envelope/s12:Body/wse:SubscriptionEnd/wse:SubscriptionManager/wsa:Address

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: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 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 3.28.

2:A.2.5.1 Notification Message

The Notification message is encoded by using DPWS Messaging.

2:A.2.5.1.1 Referenced Standards
2:A.2.5.1.2 Message Outline
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 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 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 3.29.

2:A.2.6.1 EpisodicAlertReport Message

The EpisodicAlertReport message is encoded by using DPWS Messaging.

2:A.2.6.1.1 Referenced Standards
2:A.2.6.1.2 Message Outline
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 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 3.29.4.1.

2:A.2.6.2 EpisodicMetricReport Message

The EpisodicMetricReport message is encoded by using DPWS Messaging.

2:A.2.6.2.1 Referenced Standards
2:A.2.6.2.2 Message Outline
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 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 3.29.4.1.

2:A.2.6.3 EpisodicComponentReport Message

The EpisodicComponentReport message is encoded by using DPWS Messaging.

2:A.2.6.3.1 Referenced Standards
2:A.2.6.3.2 Message Outline
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 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 3.29.4.1.

2:A.2.6.4 WaveformStream Message

The WaveformStream message is encoded by using DPWS Messaging.

2:A.2.6.4.1 Referenced Standards
2:A.2.6.4.2 Message Outline
WaveformStream message 
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
        xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
        xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message"
        xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <s12:Header>
        <wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/WaveformStream</wsa:Action>
        <wsa:MessageID><!-- ... --></wsa:MessageID>
        <wsa:To><!-- ... --></wsa:To>
    </s12:Header>
    <s12:Body>
        <msg:WaveformStream MdibVersion="..." SequenceId="..." InstanceId="...">
            <!-- ... -->
        </msg:WaveformStream>
    </s12:Body>
</s12:Envelope>
2:A.2.6.4.3 Trigger Events

There are no additional or alternative trigger events other than those defined in Section 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 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 3.30.

2:A.2.7.1 GetMdib Message

The GetMdib message is encoded by using DPWS Messaging.

2:A.2.7.1.1 Referenced Standards
2:A.2.7.1.2 Message Outline
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 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 3.30.4.1.

2:A.2.7.2 GetMdibResponse Message

The GetMdibResponse message is encoded by using DPWS Messaging.

2:A.2.7.2.1 Referenced Standards
2:A.2.7.2.2 Message Outline
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 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 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 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
2:A.2.8.1.2 Message Outline
Bye 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/Bye</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:Bye>
            <wsa:EndpointReference>
                <wsa:Address><!-- ... --></wsa:Address>
            </wsa:EndpointReference>
            <wsd:Types>dpws:Device mdpws:MedicalDevice</wsd:Types>
            <wsd:Scopes><!-- ... --></wsd:Scopes>
            <wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
        </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 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 3.34.4.1.

2:A.3 Security Considerations

In TR1164, [ref_ieee_11073_10700_2022afebf313-ed8b-4252-9849-837f9cd49f57IEEE+11073-10700] requires a SOMDS Provider to protect BICEPS services against unauthenticated access. In order to fulfill TR1164, [ref_ieee_11073_20701_2018afebf313-ed8b-4252-9849-837f9cd49f57IEEE+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, Security Considerations and Requirements of each transaction.
Essentially, this profile 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 profile.

2:A.4 Amendments and Corrigenda

2:A.4.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.4.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.4.1.2 Consumer-controlled Delay

[ISO/IEEE 11073-20701:2018] proposes the concept of priority groups. If a priority group is configured for a SOMDS Consumer, it postpones initial connection requests once in 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.4.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.4.1.2.3-1.
2:A.4.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.4.1.2.3-1.
2:A.4.1.2.3 Priority Group Guidelines

Table 2:A.4.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.4.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.4.2 MDIB Report Retrofit

In addition to Section 8.3.2.11, 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.

2:A.4.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.4.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.4.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 [ref_iso_iec_14977_1996afebf313-ed8b-4252-9849-837f9cd49f57Extended+Backus-Naur+Form] for the encoding of MDS production specifications.

Notes
The URI encoding of production specifications is defined in [ref_iso_iec_14977_1996afebf313-ed8b-4252-9849-837f9cd49f57Extended+Backus-Naur+Form] for the encoding of production specifications.
Manufacturers can also encode metadata information as production specification, according to the mapping in Table 3:8.3.2.9.1-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

[ref_iso_iec_14977_1996afebf313-ed8b-4252-9849-837f9cd49f57Extended+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 ]
[ref_iso_iec_14977_1996afebf313-ed8b-4252-9849-837f9cd49f57Extended+Backus-Naur+Form] for the encoding of MDS production specifications 
Scheme ::= 'sdc.mds.prodspec'
MdsProductionSpecification ::= Scheme ':' ProductionSpecification
ProductionSpecification is specified in [ref_iso_iec_14977_1996afebf313-ed8b-4252-9849-837f9cd49f57Extended+Backus-Naur+Form] for the encoding of production specifications.
2:A.4.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 [ref_iso_iec_14977_1996afebf313-ed8b-4252-9849-837f9cd49f57Extended+Backus-Naur+Form] for the encoding of MDS attribute specifications.

Notes
The URI encoding of attributes is defined by the Extended Backus-Naur Form [ISO/IEC 14977:1996] in [ref_iso_iec_14977_1996afebf313-ed8b-4252-9849-837f9cd49f57Extended+Backus-Naur+Form] for the encoding of attributes.
Examples

URI of a Soft ID named PatMon 03: sdc.mds.attr:PatMon%2003:67886

[ref_iso_iec_14977_1996afebf313-ed8b-4252-9849-837f9cd49f57Extended+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
[ref_iso_iec_14977_1996afebf313-ed8b-4252-9849-837f9cd49f57Extended+Backus-Naur+Form] for the encoding of MDS attribute specifications 
Scheme ::= 'sdc.mds.attr'
MdsAttribute ::= Scheme ':' Attribute
Attribute is specified in [ref_iso_iec_14977_1996afebf313-ed8b-4252-9849-837f9cd49f57Extended+Backus-Naur+Form] for the encoding of attributes.

Appendix 2:B Gateways (Normative)

2:B.1 Overview SDC Gateways

2:B.2 SDPi Gateway — HL7 V2 General Mapping

SDPi Supplement Version Note: Complete mappings from SDC to HL7 V2 are specified in the Appendix 2:B.3 and Appendix 2:B.4 sections below. This includes general SDC-to-HL7 V2 mappings that are common in both gateway specifications. This general V2 mapping section will be editorially updated with the content from these two gateway specifications before Public Comment Publication.

REVIEWER QUESTION: Issue: HL7 Local Time vs. SDC UTC time: SDC requires that all timestamps are in UTC. The time zone is optional. In HL7 V2 all timestamps are local time and the time zone is optional as well.

Do Device Observation Consumer (DOC) and Alarm Manager (AM) expect the gateway to convert UTC to local time?

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:

2:B.3.3 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.

The following example uses the SDC pm:Type to demonstrate the mapping of private MDC codes.

Table 2:B.3.3-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.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

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

If the MDIB contains several MDS elements that could operate in different pm:MdsState/@OperatingMode states, there shall be a separate [PCD-01] message per MDS.

2:B.3.4.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.4.4.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.3.4.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.4.4.1.1-2).
Table 2:B.3.4.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.3.4.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.3.4.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.3.4.2.2 PID-3 Patient Identifier List
R8103

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, socal security number, visit number, account number, etc.)
Table 2:B.4.4.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.4.4.2.2-1 table and added to the PID-3 patient identifier list.
Table 2:B.3.4.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 identifer.

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.3.4.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.3.4.2.3 PID-5 Patient Name
R8104

A SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PID-5 field to the patient name information.

Notes
Table 2:B.4.4.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.3.4.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.3.4.2.4 PID-6 Mother’s Maiden Name
R8105

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.4.4.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.3.4.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.3.4.2.5 PID-7 Date/Time of Birth
R8106

A SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PID-7 field to the date & time of birth.

Notes
Table 2:B.4.4.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.3.4.2.5-1. PID-7 Date/Time of Birth Mapping
HL7 Field HL7 Component Name SDC Attribute/Element Comments

PID-6/DTM-1

Date/Time

pm:PatientContextState/pm:CoreData/pm:DateOfBirth

Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also Example 2).
Example 2. Date/Time Format Mapping

xsd:dateTime: 2001-10-26T21:32:52 → HL7 DTM: 20011026213252

xsd:date: 2001-10-26 → HL7 DTM: 20011026

2:B.3.4.2.6 PID-8 Administrative Sex

SDPi Supplement Version Note: At the moment, there are various opinions on how to map the biological sex vs. the administrative sex (gender) to an IHE PCD profile conform HL7 V2 message.

The SDC BICEPS standard defines a generic field for the patient’s sex (pm:PatientContextState/pm:CoreData/pm:Sex). This field shall be set to the biological sex (or sex for clinical use). In addition, there will be a gender extension that shall be set to the administrative gender (or administrative sex).

The HL7 V2.6 messaging standard only supports a "Administrative Sex" field in the PID segment.

  1. 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 related note in Section 8.3.2.10.1.

The following list a couple of options and any comments from the reviewers are highly appreciated:

  1. No mapping of sex/gender information at all: the information of the patient’s sex and gender shall not be mapped at all. Pros: no risk of mapping incorrect information. Cons: no information about the sex set at the device which may have influenced certain clinical calculations and algorithms.

  2. Map the "sex for clinical use" to the PID-8 Administrative Sex field: in the context of a PoC device the sex for clinical use is the most important information for clinical calculations and algorithm. Therefore, this information shall be mapped to the PID-8 Administrative Sex field - even this is not necessarily the administrative gender. In addition, the Administrative Sex/Gender may be mapped to a separate OBX segment (only possible for DEC profile). Pros: this is backward compatible to the existing IHE PCD profiles. Cons: the information are not set in the correct field and may lead to wrong interpretations.

  3. Map the "sex for clinical use" in a separate OBX segment (only possible for DEC profile but not for ACM) and the Administrative Sex/Gender to the PID-8 Administrative Sex field: the administrative sex/gender information is mapped to the correctly named PID-8 "Administrative Sex" field, and the sex for clinical use is provided in a separate OBX segment in the IHE DEC profile conform export. The sex for clinical use information will be not available in the ACM profile conform export. Pros: the information are mapped to the correct fields. Cons: this mapping might not be backward compatible to the existing IHE PCD profile actors (reporter/consumer). Information of the sex for clinical use may get lost in some profiles such as ACM.

REVIEWER QUESTION: Please review the options listed above and provide comments on the mapping of this semantic content.
R8107

A SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PID-8 field to the code for the administrative sex.

However, in the clinical context of a point of care device the biological sex, or sex at birth is important for various algorithms.

Notes
Table 2:B.4.4.2.6-1 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.

The sex and gender of a patient (or a newborn) cannot exactly be mapped from ISO/IEEE 11073-10207 to HL7 V2. The domain information and service model only contains an attribute for 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. Mapping from one to the other would therefore introduce errors. However, in the clinical context of a point of care device the biological sex, or sex at birth is important for various algorithms, and therefore, is required to be mapped to the PID-8 field.
Table 2:B.3.4.2.6-1. 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.4.4.2.6-2).
Table 2:B.3.4.2.6-2. 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.3.4.2.7 PID-10 Race
R8108

A SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PID-10 field to the patient’s race.

Notes
Table 2:B.4.4.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.3.4.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 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 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 only the first entry of the pm:Translation element list is to be mapped.
2:B.3.4.2.8 PID-31 Identity Unknown Indicator
R8109

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

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

2:B.3.4.4.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.3.4.4.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.3.4.4.3 PV1-3 Assigned Patient Location
R8113

A SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PV1-3 field to the patient’s assigned location.

Notes
Table 2:B.4.4.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.3.4.4.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.3.4.4.4 PV1-19 Visit Number
R8114

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.4.4.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.4.4.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.3.4.4.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 identifer 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.3.4.4.5 PV1-44 Admit Time / Date
R8115

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.3.4.4.6 PV1-51 Visit Indicator
R8116

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.3.4.5 OBR - Observation Request Segment

The HL7 Obervation 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 Supplement Version Note: For SDPi 1.0 DEV Internal Review Version, this profile 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.

R8006

A SOMDS DEC Gateway shall set the OBR-7 field to the date and time of all continuously (periodically) measured metrics reported by a msg:PeriodicMetricReport to be exported within the same msg:RetrievabilityInfo/@UpdatePeriod.

Notes
If, for example, the @UpdatePeriod is set to one second, a msg:PeriodicMetricReport is expected every second with new periodic metric states to be exported within this one second interval. The OBR-7 field is set to the start time of the interval. The individual periodic metric @DeterminationTime is basically ignored, but has to be within the time boundaries of the current export interval.
Table 2:B.3.4.5.4-1 defines the mapping of the SDC metric measurement timestamp to the data fields of the HL7 data type DTM used in the OBR-7 field.
R8007

For episodic measurements and the absence of any continuously measured metrics for this export interval, a SOMDS DEC Gateway shall set the OBR-7 field to the oldest measurement timestamp of the episodic metrics to be exported in the current export interval.

Notes
Episodic metric measurements are usually exported along with the periodic metric measurements in the same export intervals triggered by msg:PeriodicMetricReport events. However, if a device does not provide periodic metric measurements, or if the @UpdatePeriod is too long, episodic metric measurements are exported independently of the periodic metric measurements in separate HL7 data export messages.
Table 2:B.3.4.5.4-1 defines the mapping of the SDC metric measurement timestamp to the data fields of the HL7 data type DTM used 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.
Table 2:B.3.4.5.4-1. OBR-7 Metric Measurement Timestamp Mapping
HL7 Field HL7 Component Name SDC Attribute/Element Comments

OBR-7/DTM-1

Date/Time

pm:EnumStringMetricState/pm:MetricValue/@DeterminationTime

pm:NumericMetricState/pm:MetricValue/@DeterminationTime

pm:StringMetricState/pm:MetricValue/@DeterminationTime

If pm:AbstractMetricDescriptor/@MetricAvailability is set to "Cont", the field is set to the start time of the msg:PeriodicMetricReport event. The @DeterminationTime of the pm:AbstractMetricState of continuously measured metrics to be exported in the same export interval has to be within the start time of the msg:PeriodicMetricReport event and the msg:RetrievabilityInfo/@UpdatePeriod.

New pm:AbstractMetricState elements of episodically measured metrics are exported in the same HL7 message with the @DeterminationTime set in HL7 OBX-14 field overriding the time point in the OBR-7 field.

If pm:AbstractMetricDescriptor/@MetricAvailability is set to "Intr" and if there are no continuously measured metrics to be exported, the field is set to the oldest @DeterminationTime of the episodic metrics to be exported in the same HL7 message.

Note that the HL7 date and time format differs from the XML Schema date/time formats and requires a mapping accordingly (see also Example 2).
2:B.3.4.5.5 OBR-8 Observation End Date/Time
R8008

A SOMDS DEC Gateway shall not use the OBR-8 field.

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 define 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 left 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
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.4.4.7.1.1-1, Table 2:B.4.4.7.1.1-2, Table 2:B.4.4.7.1.1-3 and Table 2:B.4.4.7.1.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.4.3.

Table 2:B.3.4.6.3-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.
Table 2:B.3.4.6.3-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.
Table 2:B.3.4.6.3-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.
Table 2:B.3.4.6.3-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.
2:B.3.4.6.4 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.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.4.3.

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.
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-releted 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.4.3.

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

Table 2:B.3.4.6.12-1. OBX-17 Observation Method Mapping
SDC Category SDC Derivation HL7 OBX-17 Field Value

Msmt

Auto

OBX-17 field is left empty (recommended).

Or set to "AMEAS^auto-measurement^MDC" if required.

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
2:B.3.4.6.13 OBX-18 Equipment Instance Identifier

SDPi Supplement Version Note: The UDI is not available for all devices and alternatives for uniquely identifying a device shall be defined. The SDC BICEPS standards provides the pm:ProductionSpecification on the MDS and VMD level which is a list of coded product specifications such as serial number, model, product number, manufacture, etc.

Another issue is that the field "Universal ID Type" of the HL7 EI date type is bound to HL7 table 0301 which does not contain a "UDI" id type.

REVIEWER QUESTION: Please provide feedback on the following questions …​

  1. Are there any general rules that can be applied to generate a unique deivce id? Or are there any information each device has to provide to generate a unique device id?

  2. Which unique VMD identifier are provided by devices?

  3. Which code should be used in the case of an UDI?
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.

Notes
Table 2:B.4.4.7-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.4.4.7-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.3.4.6.13-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 /pm:MetaData/pm:Udi/pm:DeviceIdentifier

OBX-18/EI-2

Namespace ID

pm:Mds/pm:MetaData/pm:Udi/pm:Issuer/@Root

OBX-18/EI-3

Universal ID

pm:Mds/pm:MetaData/pm:Udi/pm:DeviceIdentifier

OBX-18/EI-4

Universal ID Type

Set to ""L"
Table 2:B.3.4.6.13-2. OBX-18 Equipment Instance Identifier Mapping - VMD level
HL7 Field HL7 Component Name SDC Attribute/Element Comments

OBX-18/EI-1

Entity Identifier

OBX-18/EI-2

Namespace ID

OBX-18/EI-3

Universal ID

OBX-18/EI-4

Universal ID Type
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-releted 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.4.3.

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.

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:

2:B.4.3 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.

The following example uses the SDC pm:Type to demonstrate the mapping of private MDC codes.

Table 2:B.4.3-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 3. 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.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

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

If the MDIB contains several MDS elements that could operate in different pm:MdsState/@OperatingMode states, there shall be a separate [PCD-01] message per MDS.

2:B.4.4.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.4.4.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.4.4.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.4.4.1.1-2).
Table 2:B.4.4.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.4.4.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.4.4.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.4.4.2.2 PID-3 Patient Identifier List
R8103

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, socal security number, visit number, account number, etc.)
Table 2:B.4.4.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.4.4.2.2-1 table and added to the PID-3 patient identifier list.
Table 2:B.4.4.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 identifer.

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.4.4.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.4.4.2.3 PID-5 Patient Name
R8104

A SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PID-5 field to the patient name information.

Notes
Table 2:B.4.4.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.4.4.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.4.4.2.4 PID-6 Mother’s Maiden Name
R8105

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.4.4.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.4.4.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.4.4.2.5 PID-7 Date/Time of Birth
R8106

A SOMDS DEC Gateway / SOMDS ACM Gateway shall set the PID-7 field to the date & time of birth.

Notes
Table 2:B.4.4.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.4.4.2.5-1. PID-7 Date/Time of Birth Mapping
HL7 Field HL7 Component Name SDC Attribute/Element Comments

PID-6/DTM-1

Date/Time

pm:PatientContextState/pm:CoreData/pm:DateOfBirth

Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also Example 2).
Example 4. Date/Time Format Mapping

xsd:dateTime: 2001-10-26T21:32:52 → HL7 DTM: 20011026213252

xsd:date: 2001-10-26 → HL7 DTM: 20011026

2:B.4.4.2.6 PID-8 Administrative Sex

SDPi Supplement Version Note: At the moment, there are various opinions on how to map the biological sex vs. the administrative sex (gender) to an IHE PCD profile conform HL7 V2 message.

The SDC BICEPS standard defines a generic field for the patient’s sex (pm:PatientContextState/pm:CoreData/pm:Sex). This field shall be set to the biological sex (or sex for clinical use). In addition, there will be a gender extension that shall be set to the administrative gender (or administrative sex).

The HL7 V2.6 messaging standard only supports a "Administrative Sex" field in the PID segment.

  1. 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 related note in Section 8.3.2.10.1.

The following list a couple of options and any comments from the reviewers are highly appreciated:

  1. No mapping of sex/gender information at all: the information of the patient’s sex and gender shall not be mapped at all. Pros: no risk of mapping incorrect information. Cons: no information about the sex set at the device which may have influenced certain clinical calculations and algorithms.

  2. Map the "sex for clinical use" to the PID-8 Administrative Sex field: in the context of a PoC device the sex for clinical use is the most important information for clinical calculations and algorithm. Therefore, this information shall be mapped to the PID-8 Administrative Sex field - even this is not necessarily the administrative gender. In addition, the Administrative Sex/Gender may be mapped to a separate OBX segment (only possible for DEC profile). Pros: this is backward compatible to the existing IHE PCD profiles. Cons: the information are not set in the correct field and may lead to wrong interpretations.

  3. Map the "sex for clinical use" in a separate OBX segment (only possible for DEC profile but not for ACM) and the Administrative Sex/Gender to the PID-8 Administrative Sex field: the administrative sex/gender information is mapped to the correctly