IHE Devices
Technical Framework Supplement
Service-oriented Device Point-of-care
Interoperability (SDPi)
Revision 1.4.1 — Standard for Trial Use / Implementation
Publication Date: |
October 7, 2024 |
Build Date: |
2024-10-07 15:27:04 UTC |
Author: |
HL7 Devices Working Group & IHE Devices Technical Committee |
Email: |
Please verify you have the most recent version of this document. See HERE for STU/Trial Implementation and Final Text versions and HERE for Public Comment versions.
A PDF version of the specification is available upon request.
Foreword
This Gemini standard is a joint development effort between Health Level Seven International (HL7) and Integrating the Healthcare Enterprise (IHE) devices working groups. Its development and publication adheres to the consensus standards processes of both HL7, an ANSI accredited standards development organization, and IHE. Publication as a Standard for Trial Use (HL7) or Trial Implementation (IHE) reflects the continuous cycle of development, balloting and publication of the specification, to address addition of new capabilities as well as identified safety, effectiveness and security issues and enhancements. Product developers are encouraged to use the standard, recognizing the potential impact of this continuous development cycle.
This is a supplement to the IHE Devices Technical Framework. Each supplement undergoes a process of public comment and trial implementation before being incorporated into the volumes of the Technical Frameworks.
This supplement is published on October 7, 2024 for Trial Implementation and may be available for testing at subsequent IHE Connectathons. The supplement may be amended based on the results of testing. Following successful testing it will be incorporated into the Devices Technical Framework. Comments are invited and can be submitted at Devices Public Comments or by submitting a GitHub Issue.
This supplement describes changes to the existing technical framework documents.
“Boxed” instructions like the sample below indicate to the Volume Editor how to integrate the relevant section(s) into the relevant Technical Framework volume.
Amend section W.X by the following: |
Where the amendment adds text, make the added text bold underline. Where the amendment removes text, make the removed text bold strikethrough. When entire new sections are added, introduce with editor’s instructions to “add new text” or similar, which for readability are not bolded or underlined.
General information about IHE can be found at IHE.net.
Information about the IHE Devices domain can be found at IHE Domains.
Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at Profiles and IHE Processes.
The current version of the IHE Devices Technical Framework can be found at DEV Technical Framework.
Introduction to this Supplement
SDPi 1.4 Supplement — STU / TI Version — Note: This version of the SDPi 1.4 Standard for Trial Use (HL7 STU) / Trial Implementation (IHE TI) supplement is the 3rd release in 2024, continuing the objective to provide three to four releases each year that include both incremental updates (e.g., editorial "fixes"), ballot comment resolutions (e.g., from HL7 ballot cycles), and additional capability enhancements. For this release, key additions include:
All changes incorporated in a release are managed through Github Issues and reviewed Pull Requests. For a list of those related to this release, see Section : below. For HL7 ballot comment resolution, links are made from HL7 ballot Jira tickets to IHE DEV.SDPi Github Issues that then enable tracking of the comment resolution implementation in a specific release.
It is recognized that this release is a work-in-progress that will continue to subsequent versions. These known limitations and forward-looking content include:
|
Supplement Forward Declarations
SDPi 1.4 Supplement Note: The following table is included in this version of the supplement to capture "forward" declarations of acronyms and labels that are used in the text but are not intended to be part of the General Introduction Appendix D Glossary. "Forward" means that they are used BEFORE the document section in which they are formally defined. Since AsciiDoc is a one-pass processor, forward declarations are required. There was no clear way of defining these replacement definitions in a way that is "under the hood" and not visible to the reader. The following table was thus created but may be moved or otherwise implemented in subsequent supplement versions. Suggestions appreciated!
|
Acronym | Label | Section Defined In | Type |
---|---|---|---|
Use Case |
|||
Use Case |
|||
System Type |
|||
System Type |
|||
System Type |
|||
Use Case |
|||
Standard |
|||
System Type |
|||
Use Case |
|||
Use Case |
|||
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:
Requirements Interoperability + Model Centric + Regulatory Ready
Or RI+MC+RR for short.
These three objectives may be summarized as follows:
Requirements Interoperability (RI)
Ability to integrate & automate requirements and capabilities from component specifications & standards to enable traceability & coverage at Conformity Assessment (CA) of the component product interface
Model Centric (MC)
Transition from a document-centric to a computable model-based "single source of truth" specification from which the Technical Framework becomes a view of the model
Regulatory Ready (RR)
Enable CA test reports that are genuinely "regulatory submission ready" (e.g., inclusion in a U.S. FDA 510(k) submission package)
The SDPi 1.4.1 version of the supplement continues to make small but significant steps toward support of these objectives, especially Requirements Interoperability, as well as the use of AsciiDoc metadata to annotate the document sources for post-processing. Clearly, moving toward Model-Centric (MC) specifications and full integration of Model-Based Systems Engineering (MBSE) (MBSE) will take considerable effort and time; however, this supplement represents a humble start in that direction. Subsequent supplement versions will build upon these objectives and support a new level of rigor for connectathon and product conformity assessment testing and ultimately test reports that directly impact the challenges around medical product regulatory submissions.
Additional discussion is provided in Appendix 1:A, and on the Gemini project’s confluence pages. See also related discussions on the Gemini Project’s Pathway to an Ecosystem of Plug-and-Trust Products.
Requirements Glossary
Editor’s Note: This "glossary" provides a defined set of requirements terminology and meta data is required in order to ensure consistency and processing / automation of requirements throughout the specification. It is differentiated from the IHE TF-0 Glossary in that it is specifically created to support the integration of formal requirements interoperability specification content; whereas, the IHE glossary provides general terminology more at the application level that is used throughout all IHE technical frameworks and profile specifications. |
SDPi Issue Management
SDPi "Topic of Interest" Issue Management
All SDPi supplement issues are tracked in the IHE Github DEV.SDPi repository Issues section. Filter the issues on "Topic of Interest" to see a full list.
To see the full list of OPEN issues, filter on: is:issue is:open label:"Topic of Interest"
To see the full list of CLOSED issues, filter on: is:issue is:closed label:"Topic of Interest"
For more detailed information on how the Gemini SES+MDI program manages issues from identification to resolution to incorporation into this supplement, see the wiki article Overview: From Discussion to Planning to Development and the confluence article Topics of Interest — Topic Resolution Workflow.
Open Issues and Topic of Interests
Open 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 by adding the following new Section 9.1.5: |
9.1.5 IEEE 11073 (Health Device Interoperability)
SDPi 1.4 Supplement Note: The content below is verbatim from the IEEE permission letter. An abbreviated version may be provided in subsequent supplement versions with a reference to the complete letter. The copyright language will need to be updated to support the PKP standards (e.g., [IEEE 11073-10700:2022]. It may also need to be updated for [IEEE 11073-10101:2020], which is needing to be renewed. Note that NIST and the RTTMS tools are a key factor in the nomenclature aspect of the licensing discussion. |
IEEE® and IEEE 11073® are registered trademarks of the The Institute of Electrical and Electronics Engineers, Inc. IEEE has granted permission to IHE and HL7 to use portions of 11073-10207, 11073-20701, 11073-20702, 11073-10700, 11073-10701 (the “Material”), subject to the following conditions:
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.
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]
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.
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.
The Material is provided “as is,” To the extent permitted by law, IEEE disclaims all representations and warranties to the Material.
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.
IHE understands and agrees that this grant permission may not be transferred or assigned without the express written permission of IEEE.
10 Trademark
IHE® and the IHE logo are trademarks of the Healthcare Information Management Systems Society in the United States and trademarks of IHE Europe in the European Community. Please refer to the IHE Technical Frameworks General Introduction, Section 10 - Trademark for information on their use.
IHE Technical Frameworks General Introduction Appendices
The IHE Technical Framework General Introduction Appendices are components shared by all of the IHE domain technical frameworks. Each technical framework volume contains links to these documents where appropriate.
Appendix A Actors
Add the following new or modified actors to the IHE Technical Frameworks General Introduction Appendix A. |
New (or modified) Actor Name | Definition |
---|---|
Processes BICEPS-conformant content. |
|
Provides BICEPS-conformant content. |
|
Exchanges medical alert information with an IHE ACM-based environment |
|
Enables seamless interaction with systems and software applications that are outside the scope of a SOMDS network. |
|
Discovers and utilizes service(s) exposed by a SOMDS Provider. |
|
Exchanges information between SOMDS and IHE DEC-based environments. |
|
Accepts and makes available SOMDS Provider endpoint metadata in a SOMDS. |
|
Exchanges information between SOMDS and HL7 FHIR-based environments. |
|
Exchanges medical data between SOMDS and HL7 FHIR-based environments. |
|
Receives medical alert information from a SOMDS Medical Alert Provider. |
|
Makes medical alert information and service(s) available to SOMDS Medical Alert Consumers. |
|
Discovers and invokes device-external control services supported by a SOMDS Medical Control Provider. |
|
Supports a set of device-external control services that may be discovered and invoked by a SOMDS Medical Control Consumer. |
|
A SOMDS Consumer grouped actor that receives medical data from a SOMDS Provider. |
|
Sends medical data to a SOMDS Medical Data Consumer. |
|
Provides basic, common connectivity capabilities that are shared by all actors that are part of a SOMDS network. |
|
Makes service(s) available to SOMDS Consumers. |
|
Supports integration of sensors external to a SOMDS network. |
|
Supports connection of software applications to a SOMDS network, including Software as a Medical Device (SaMD). |
|
Exchanges information between SOMDS and HL7 Version 2 (V2) environments. |
The table below lists existing actors that are utilized in this specification.
Existing Actor Name | Definition |
---|---|
This actor receives alerts from the Alert Reporter and collects status events related to the dissemination of the alert. |
|
The Alert Consumer (ACON) receives the alert from the Alert Reporter (AR) and uses the alert information strictly as a consumer of the alert being raised. There is no implementation requirement for how the ACON ultimately uses the alert information. |
|
The Alert Manager (AM) receives the alerts from the Alert Reporter (AR), potentially analyzes the alert, and dispatches the alert to the Alert Communicator (AC), and optionally, provides the alert to the Alert Archiver (AA) or Alert Consumer (ACON) upon subscription. |
|
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. |
|
The actor responsible for receiving PCD data from the Device Observation Reporter, the Device Observation Filter, or both. |
|
The Device Observation Reporter (DOR) receives data from PCDs, including those based on proprietary formats, and maps the received data to transactions providing consistent syntax and semantics. |
|
Time Client |
Establishes time synchronization with one or more Time Servers using the NTP protocol and either the NTP or SNTP algorithms. Maintains the local computer system clock synchronization with UTC based on synchronization with the Time Servers. |
Appendix B Transactions
Add the following new or modified transactions to the IHE Technical Frameworks General Introduction Appendix B. |
New Transaction Number | New Transaction Name | Definition |
---|---|---|
Notify all SOMDS Consumers that a SOMDS Provider is connected to the network and ready to exchange messages with other SOMDS Participants. |
||
Discover and resolve all available SOMDS Providers that a SOMDS Consumer is potentially interested in. |
||
Exchange resources metadata between a SOMDS Provider and a SOMDS Consumer. |
||
Deferred to SDPi 1.x |
||
Establish a publish-subscribe session between a SOMDS Provider, acting as the event source, and a SOMDS Consumer, acting as the event sink. |
||
Notify a SOMDS Consumer about changes in system context and capabilities of a SOMDS Provider. |
||
Notify a SOMDS Consumer about changes in the alert, metric and component reports and in the waveform stream of a SOMDS Provider. |
||
Retrieve the MDIB of a SOMDS Provider a SOMDS Consumer is interested in. |
||
Deferred to SDPi-xC |
||
Deferred to SDPi 1.x |
||
Deferred to SDPi 1.x |
||
Notify all SOMDS Consumers that a SOMDS Provider is leaving the network. |
||
Establish the exchange of medical data between a SOMDS Provider and a SOMDS Consumer. |
||
Publish medical data from a SOMDS Provider to a SOMDS Consumer. |
||
Retrieve medical data from a SOMDS Provider. |
||
Establish the exchange of medical alerts from a SOMDS Provider to a SOMDS Consumer. |
||
Notify a SOMDS Consumer about changes in the medical alert status of a SOMDS Provider. |
||
Retrieve the medical alert status of a SOMDS Provider. |
||
Deferred to SDPi 2.0 |
||
Deferred to SDPi 2.0 |
||
Deferred to SDPi 2.0 |
||
Deferred to SDPi-xC |
||
Deferred to SDPi-xC |
||
Provide network presence and absence of SOMDS Provider Actors in a SOMDS network by updating the metadata in a Discovery Proxy Actor. |
||
Retrieve presence metadata from a Discovery Proxy Actor for a specified set of SOMDS Provider Actors that may be connected to a SOMDS network. |
||
DEV-48 |
Reserved |
|
DEV-49 |
Reserved |
|
DEV-50 |
Reserved |
Appendix D Glossary
SDPi 1.4 Supplement Note: The General Introduction Appendix D Glossary in this initial version of the supplement includes all terms and acronyms that are utilized throughout the other volumes. Subsequent versions of the supplement may re-locate items to other tables and sections within the technical framework. To help differentiate between various classes or categories of terms, a new "Type" column has been added. This could enable future dynamic resorting of the table by those users who are interested in, for example, only organizational definitions. Finally, a References column has been added to pull this information out of the Definition column. |
Add the following new or updated glossary terms to the IHE Technical Frameworks General Introduction Appendix D. |
New Glossary Term | Definition | Synonyms | Acronyms / Abbreviation | References | Type |
---|---|---|---|---|---|
The primary United States SDO recognition and facilitation organization. |
Organization |
||||
General reference to the abstract, implementation technology independent SDC components defined in the ISO/IEEE 11073-10207 standard. |
SDC |
||||
A system that supports a multi-patient workplace with capabilities similar to a Cockpit. |
See extended description and discussion in Section 3:8.3.2.6 |
||||
The foundational domain information model (DIM) that is recognized and implemented in all IEEE 11073 standards and profiles, for both PoCD and PHD devices. |
SDC |
||||
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. |
SDC |
||||
A BICEPS Participant Model extension that allows for a SOMDS Provider to provide attributes from the first partition of the IEEE 11073-10101 nomenclature. Specified in Section 3:8.3.2.10.4. |
SDC |
||||
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. |
SES |
||||
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 |
SDC |
|||
A set of zero to many identifiers that allows for organizing SOMDS Providers into logical groups. |
SDC |
||||
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. |
IHE |
||||
An HL7 standard for health care data exchange, built on RESTful technology that utilizes resources to enable rapid creation of interoperable healthcare applications. |
Standard |
||||
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. |
Organization |
||||
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. |
|||||
Organization dedicated to advancing innovation and technological excellence for the benefit of humanity, and is the world’s largest technical professional society |
Organization |
||||
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. |
SDC |
||||
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. |
Organization |
||||
A globally recognized one-country-one-vote SDO that is composed of 100’s of technical committees and other groups. |
Organization |
||||
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. |
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. |
|||
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 |
||||
Structured collection of any data objects that are provided by a SOMDS Provider or BICEPS Content Creator, including both descriptive and state information. |
SDC |
||||
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. |
|||||
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". |
|||||
The application of informatics technology standards to achieve seamless and dynamic connection of Point of Care Device (PoCD)'s. |
|||||
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). |
|||||
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. |
|||||
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. |
SES |
||||
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. |
SES |
||||
A networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks. |
|||||
An international, membership-driven, not-for-profit consortium SDO. |
Organization |
||||
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. |
SDC |
||||
A healthcare device that is used by individuals for their own personal health purposes. |
|||||
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. |
|||||
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). |
|||||
A system that supports information viewing and control of multiple devices and systems associated with a single patient Point of Care (PoC). |
|||||
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 |
||||
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. |
|||||
XML Schema QName. In this specification, QNames are encoded as |
|||||
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. |
|||||
A subsystem of a SOMDS Provider that can be attached to or removed from the SOMDS Provider and that is represented in the MDIB. |
See also [IEEE 11073-10700:2022] |
||||
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 |
||||
General name given to the requirements, general and specific, derived by the application of medical device and health software quality standards. |
|||||
Application of service-oriented architecture to support healthcare device interoperability. |
SDC |
||||
A set of (4) IHE specifications that profile the SDC standards for device-to-device plug-and-play interoperability. |
Profile |
||||
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. |
SDC |
||||
A point-of-care system of products that implements a service-oriented SDC architecture composed of service providers and service consumers. |
SDC |
||||
A system that provides consolidated alarm and alert events (actionable alerts), and advisories (e.g., patient deterioration alerts). |
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 intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device. |
|||||
A globally unique identifier UID for a SOMDS Provider that is stable across re-initializations. |
SDC |
||||
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) |
Organization |
||||
Function of a SOMDS Participant that contributes to a Clinical Function provided by a Service-oriented Medical Device System (SOMDS). |
Adapted from [IEEE 11073-10700:2022]. |
SDC |
|||
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). |
|||||
A physical endpoint address that can be used to communicate with a SOMDS Provider. |
XAddr |
||||
A core object type in the ISO/IEEE 11073 device communication standards. It represents the second-level containment of the hierarchy of information objects contained in a device. |
XML Namespaces
The XML namespace URI that is used by this specification is: urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1
.
Table 1 lists XML namespaces and prefixes that are used in this specification. The choice of any namespace prefix is arbitrary and not semantically significant.
Prefix | XML Namespace | Specification |
---|---|---|
dpws |
||
sdpi |
urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.1.1 |
This specification, used by BICEPS extensions. |
dp |
urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.2.2 |
This specification, used by the Discovery Proxy actor. |
wsa |
||
wsd |
||
wse |
||
wsm |
Volume 1 — Profiles
1:2 Devices Integration Profiles
SDPi 1.4 Supplement Note: This supplement is being written after the 2019 reorganization of the IHE Patient Care Devices (PCD) domain to the IHE Devices (DEV) domain. It is intended to amend a new IHE DEV Technical Framework (TF), that covers the expanded areas not only of PCD devices (enterprise integration focused), but also Personal Connected Health (PCH) devices and Device Point-of-care Interoperability (DPI) for device-to-device integration around an acute point-of-care (e.g., operating room table, ICU bed, emergency department bed, etc.). As a result of these basic changes in the scope and organization of the IHE DEV domain, some additional TF sections have been proposed to help the community understand how these technical specifications are integrated. For example,
These general concepts will help the technical framework reader understand the broader context into which the profile specifications are intended to be implemented. |
1:2.2 Safety, Effectiveness and Security - Requirements and Considerations
IHE specifications often include sections for "Security Considerations" and "Safety Considerations", capturing both general and specific guidance and requirements for system implementers. This supplement extends these two concepts to include a third: Effectiveness. The sections are titled "Safety, Effectiveness and Security - Requirements and Considerations" and make use of the underlying term Safe Effective & Secure (SES).
The background for SES is discussed in detail in Appendix 1:A.2; however, in general "SES" is used as a reference to the standards encompassed (directly and indirectly by reference) in ISO/IEC Joint Working Group 7 (JWG7), including [ISO/IEC 81001-1:2021] and [ISO/IEC 80001-1:2021]. These standards are primarily, though not exclusively, focused on risk management of health software (including SaMD) and medical devices that are deployed on various kinds of infrastructure, with a focus to managing three key properties: Safety, Effectiveness and Security. Thus the "Safety, Effectiveness and Security - Requirements and Considerations" sections in this supplement are intended to reflect the results of that risk management and to guide those who are tasked with deploying and managing these interoperable solutions during use.
Note that specific requirements from the above mentioned standards, may also be captured in Appendix 1:B.2. Generally, requirements from these standards would be mapped to the appropriate "Safety, Effectiveness and Security - Requirements and Considerations" sections throughout the specification.
1:2.3 Integration Profiles Overview
SDPi 1.4 Supplement Note: The template for this section assumes that it will be integrated with the technical framework section that is organized based on TF-1 section headings (e.g., chapter 10 for SDPi- would have a summary here as 2.10. No provision is made, though, for general introductory sections such as the SDPi Overview & Framework discussion below. In this version, the content is added as 2.3.1, and then the profiles as 2.3.10 to 2.3.13. Though the content is valid, it may be repositioned in subsequent versions to better integrate with the IHE DEV TF at a future date. Omitted from this version are profile-specific option summaries (e.g., 3.10.1?). It is unclear where to best place this content, and they are listed explicitly in each profile’s detailed specification. |
1:2.3.1 Service-oriented Device Point-of-care Interoperability (SDPi)
1:2.3.1.1 SDPi Profiles – Scope of Application
The Service-oriented Device Point-of-care Interoperability (SDPi) Profile specifications provide detailed instructions for seamless plug-and-play interoperability between ISO/IEEE 11073 SDC-based medical devices (including SaMD), as well as between medical devices and health IT systems based on HL7 FHIR and HL7 Version 2. Key considerations include enabling safe, secure and effective interoperability for data reporting, alert notification, device-external control and other high-acuity point-of-care use cases. Provision is made for coordination of individual device functional contributions to support clinical system functions that are provided by two or more participants.
Notes:
High-acuity points of care include operating rooms (OR), intensive care units (ICU), step-down units, and emergency care.
Clinical system function example: Physiological monitoring of a patient’s condition as they are being weaned off of a ventilator.
"SaMD" is Software as a Medical Device, including "clinical apps"; they are a class of Health Software.
ISO/IEEE 11073 Service-oriented Device Connectivity (SDC) standards provide a Services Oriented Architecture (SOA) specification for safe, effective and secure medical device interoperability (SES MDI).
1:2.3.1.2 SDPi Profiles – Overview & Framework
The SDPi Profiles are built upon a foundation of standards and profiles from HL7, IEEE, IHE and other organizations. An overview of the profiles and their relationships is provided in Figure 1:2.3.1.2-1.
There is a particular challenge with SDPi profiling of SDC that resulted in the definition of (4) profiles and not one:
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:
4 Profiles —
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.
Gateway Actors
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.
The actors provide defined mappings from SDPi transactions and semantics to those of other standards and standards profiles (e.g., IHE DEC or ACM).
Gateways can be bi-directional, receiving information from non-SDPi enabled systems, such as patient demographics information from an EHR.
For a more complete "Big Picture" perspective, see the discussion in Appendix 1:A.1.
PKPs for Medical Purposes
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.
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.
These standards represent shared or consensus risk management requirements (e.g., risk mitigations) that together address how to implement SES interoperable medical device technologies.
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:
P → SDPi-Plug-and-trust
R → SDPi-Reporting
A → SDPi-Alerting
C → SDPi-xControl
It should be noted that the primary use context for SDPi-enabled technologies is high acuity points of care, namely Operating Rooms, ICU beds, emergency beds, etc. Within this context, the core focus of these Profiles is direct D2D interactions at the point of care. Gateway actors provide integration with systems beyond the scope of the acute bedside context, typically though not necessarily using other protocols. This D2D is differentiated with the current implementation reality where devices use proprietary protocols to talk with their manufacturer’s gateway server, requiring a level of indirection (server-to-server integration), and the attendant performance, quality and capability limitations.
See Section 1:10.4.1.1 below for additional conceptual overview information on the conceptual foundations of the SDC standards.
1:2.3.10 Service-oriented Device Point-of-care Interoperability - Plug-and-trust (SDPi-P) Profile
Within the framework of the SDPi architecture, the Plug-and-Trust ( SDPi-P) Profile provides for secure plug-and-play connectivity between all actors. The primary use context is acute care beds (e.g., ICU, operating room, emergency department), though it may be used in other healthcare contexts. This specification provides for plug-and-trust (secured) communication for healthcare devices, systems and applications, regardless of whether they are "regulated" medical devices. That said, the SDPi-P Profile fully supports the safety and security requirements specified in the [IEEE 11073-10700:2022] Base PKP standard. Other SDPi Profiles provide direct support for interoperable medical systems. Taking this approach allows non-medical technology to interact with other SDPi-enabled systems but without the added burden of having to support the more rigorous requirements associated with technology intended for a medical purpose (e.g., additional risk control mitigation measures).
This baseline profile supports the core functionality needed by all participating systems. Profile options are provided for additional capabilities that may be required to support extended scenarios (e.g., "ensemble context" management).
1:2.3.11 Service-oriented Device Point-of-care Interoperability - Reporting (SDPi-R) Profile
The SDPi Reporting Profile builds on the basic PnT capabilities of the SDPi-P profile, but adds the requirements to fully support medical data reporting. To that end, this specification fully supports the safety and security requirements in the [IEEE 11073-10701:2022] metric reporting PKP standard.
The profile supports core medical data reporting functionality needed by all participating systems. Profile options are provided for additional capabilities that may be required to support extended scenarios.
1:2.3.12 Service-oriented Device Point-of-care Interoperability - Alerting (SDPi-A) Profile
The SDPi Alerting Profile builds on the basic PnT capabilities of the SDPi-P profile, but adds the requirements to fully support medical alerting. To that end, this specification implements the safety and security requirements of the [IEEE 11073-10702:202x] alert PKP standard (expected to be completed in 2024).
The profile supports core medical alerting functionality needed by all participating systems. Profile options are provided for additional capabilities that may be required to support extended scenarios (e.g., alert delegation).
1:2.3.13 Service-oriented Device Point-of-care Interoperability - External Control (SDPi-xC) Profile
SDPi 1.4 Supplement Note: The SDPi-xC Profile is provided for completeness and to show the general direction of the family of SDPi Profiles. It is not part of the capabilities specified for 1.4 and even basic controls will not be added until SDPi 2.0 or later. |
The SDPi External Control Profile builds on the basic PnT capabilities of the SDPi-P Profile, but adds support for medical device external control capabilities. For example, the ability to have a system initiate a blood pressure reading, or set a breath rate, or titrate an infusion pump’s delivery rate. Given the significant risks associated with allowing device-external control functions in a network of PnT systems, this specification implements the safety and security requirements of the [IEEE 11073-10703:202x] external control PKP standard (in development, anticipated in 2025 or later).
1:2.5 Dependencies between Integration Profiles
Add the following dependencies below to the IHE DEV TF Profile Dependencies table. |
Integration Profile |
Depends on |
Dependency Type |
Purpose |
Consistent Time (CT) |
Each SDPi-P actor implementation (i.e., SOMDS Participant) shall be grouped with the CT Time Client Actor. Note: All SDPi actors are also grouped with the SOMDS Participant Actor. |
Required for consistent time-stamping of transactions and data. |
|
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. |
|
Alert Communication Management (ACM) |
The SOMDS ACM Gateway integrates ACM Alert Reporter (AR) Actor specifications. |
Required for mapping from SDC & BICEPS to HL7 V2 and ACM transactions. |
1:10 Service-oriented Device Point-of-care Interoperability – Plug-and-trust (SDPi-P) Profile
The SDPi-Plug-and-trust ( SDPi-P) Profile supports foundational seamless connectivity, information exchange and service invocation as defined in the SDPi architecture detailed in Section 1:2.3.1.2. Whereas the related SDPi Profiles for reporting, alerting and external control are explicitly intended to support medical care capabilities, the SDPi-P Profile focuses on basic healthcare device interoperability. All the capabilities defined in SDPi-P are leveraged by and extended in the medically focused profiles. This foundational profile not only supports medical device interoperability ("MDI"), providing for “plug-and-play” capabilities, but also with a tightly integrated “trust” framework (see Appendix 1:A). The establishment of a trusted ecosystem of medical and non-medical devices and applications [2] begins at the start of discovery and a secure connection. Therefore, the profile’s name: Plug-and-Trust (PnT).
This is primarily an IHE transport profile [3], although it does define several content modules detailed in IHE Devices TF-3. It supports the transactions and information exchanged in accordance to a Service-Oriented Architecture (SOA) specialized for high-acuity points of care (e.g., operating table or ICU bed), defined as a Service-oriented Medical Device System (SOMDS). All the SDPi-P actors are therefore scoped with “SOMDS” to clearly identify their application context and scope.
Although all information exchanged between SDPi-P SOMDS participating systems and applications must conform to the basic SDC/BICEPS content module requirements [4], content modules have been defined for common high-acuity medical devices such as infusion pumps, ventilators and physiologic monitors.
Note that future IHE workflow profiles may be defined that build upon the transport & content module foundation established by the SDPi-P profile. For example, Operating Room / Surgery Point-of-Care Integration, ICU Point-of-Care Integration, or more service-focused profiles such as Point-of-Care Identity Management (PCIM) for device-patient association management, or Silent ICU & Quiet Hospital, where the acute point-of-care is integrated with enterprise systems around device alerting and alert distribution to provide an improved environment of care (reduced noise level and improved safety) and clinician interaction.
1:10.1 SDPi-P Actors, Transactions, and Content Modules
SDPi 1.4 Supplement Note: Some actors and transactions have been deferred to a subsequent version, but are included here for completeness. Specifically: SOMDS FHIR Gateway, SOMDS Sensor Gateway & SOMDS Smart App Platform, have been deferred. Deferred transactions have been so indicated in the transactions table. |
This section defines the actors, transactions, and/or content modules in this specification. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A. IHE Transactions can be found in the Technical Frameworks General Introduction Appendix B. Both appendices are located at profiles.ihe.net/GeneralIntro.
Figure 1:10.1-1 shows the actors directly involved in the SDPi-P Profile. The relevant transactions between them are detailed in the subsequent Table 1:10.2-1. Abstract actors (i.e., those that provide common specifications that are utilized in other “concrete” or implementation actors) are indicated by stereotype names in italics (e.g., "<< SOMDS_Participant >>". The actors that inherit their capabilities include the stereotype at the top of their actor box. Alternatively, in accordance with traditional IHE style, the Abstract actor’s name can be in italics with "{abstract}" (e.g., see SOMDS Connector in Figure 1:10.1-1). Actor groupings, including abstract with concrete, are detailed in Section 1:10.3.
Table 1:10.2-1 lists the transactions for each actor directly involved in the SDPi-P Profile. To claim conformity with this specification, an actor shall support all required transactions (labeled “R”) and may support the optional transactions (labeled “O”). Note that “Consumer” is indicated for actors that receive but do not directly respond to a specific transaction.
Actors |
Transactions |
Initiator or Responder |
Optionality |
Reference |
NOTE: This abstract actor does not define any specific transactions. |
… |
… |
… |
|
Initiator |
R |
|||
Responder |
R |
|||
Responder |
R |
|||
Discover System Context and Capabilities (deferred) |
Responder |
R |
Deferred to SDPi 1.x |
|
Responder |
R |
|||
Initiator |
O (See Note 1) |
|||
Initiator |
R |
|||
Responder |
O |
|||
Set Provider State (deferred) |
Responder |
O |
Deferred to SDPi-xC |
|
Retrieve Archive Data (deferred) |
Responder |
O |
Deferred to SDPi 1.x |
|
Responder |
O |
Deferred to SDPi 1.x |
||
Initiator |
R |
|||
Initiator |
O (See Note 2) |
|||
Receiver (See Note 3) |
O |
|||
Initiator |
R |
|||
Initiator |
R |
|||
Discover System Context and Capabilities (deferred) |
Initiator |
R |
Deferred to SDPi 1.x |
|
Initiator |
R |
|||
Receiver (See Note 3) |
O |
|||
Receiver (See Note 3) |
R |
|||
Initiator |
O |
|||
Set Provider State (deferred) |
Initiator |
O |
Deferred to SDPi-xC |
|
Retrieve Archive Data (deferred) |
Initiator |
O |
Deferred to SDPi 1.x |
|
Initiator |
O |
Deferred to SDPi 1.x |
||
Receiver (See Note 3) |
O |
|||
Initiator |
O (See Note 2) |
|||
Receiver (See Note 2) |
R |
|||
Responder |
R |
|||
See Note 4 |
… |
… |
… |
|
SOMDS FHIR Gateway (deferred) |
… |
… |
… |
… |
See Note 4 |
… |
… |
… |
|
SOMDS Sensor Gateway (deferred) |
… |
… |
… |
… |
SOMDS Smart App Platform (deferred) |
… |
… |
… |
… |
Note 1: “Notify Change in System Context and Capabilities” is required if there are dynamic changes that may need to be sent to subscribing systems Note 2: Optional transaction is required if the SDPi-P Managed Discovery Option is enabled. Some deployments may support a mix of systems that use the Discovery Proxy Actor as well as the default "ad hoc" discovery mode. Additional details and requirements are provided in the Section 1:10.2.1 discussion. Note 3: “Receiver” is included in this column, in italics, to indicate that though a SOMDS Consumer may "receive" the transaction, there is no response communicated to the message initiator. Note 4: SDPi Version Note: — Full detailing of the transactions related to this actor will be addressed in a subsequent version of this specification. |
Figure 1:10.1-2 shows the content-related actors defined in the SDPi-P Profile and the direction that the content is exchanged.
In general, the SOMDS Provider will create content for consumption by a SOMDS Consumer , but the communication cloud between the two actors indicates that the technical method of exchange is a separate concern for the semantic content. Within the SDPi-P Profile, the general "default" communication methods would be using the SOMDS capabilities illustrated above in Figure 1:10.1-1 with the BICEPS Content Creator communicating content via the SOMDS Provider , and the BICEPS Content Consumer receiving it via the SOMDS Consumer. However, the content might also be formalized in a document as opposed to a message, and a different method of exchange and persistence utilized.
Note that in the case of external control, where a SOMDS Consumer is creating and sending content (e.g., patient demographics information) to a SOMDS Provider , the content module creator / consumer roles will be reversed.
A product implementation using this specification may group from this profile with actors from a workflow or transport profile to be functional. The grouping of the content module described in this profile to specific actors is described in more detail in Section 1:10.3 or in Section 1:10.6.
Table 1:10.1-2 lists the content module(s) defined in the SDPi-P Profile. To claim support with this specification, an actor shall support all required content modules (labeled “R”) and may support optional content modules (labeled “O”).
Actors |
Content Modules |
Optionality |
Reference |
SDC/BICEPS Content Module |
R (See Note 1) |
||
Infusion Pump SDC/BICEPS Content Module |
O |
||
Ventilator SDC/BICEPS Content Module |
O |
||
Physiologic Monitor SDC/BICEPS Content Module |
O |
||
Surgery Devices SDC/BICEPS Content Module |
O |
||
Anesthesia Devices SDC/BICEPS Content Module (deferred) |
O |
||
Dialysis Devices SDC/BICEPS Content Module (deferred) |
O |
||
SDC/BICEPS Content Module |
R (See Note 1) |
||
Infusion Pump SDC/BICEPS Content Module |
O |
||
Ventilator SDC/BICEPS Content Module |
O |
||
Physiologic Monitor SDC/BICEPS Content Module |
O |
||
Surgery Devices SDC/BICEPS Content Module |
O |
||
Anesthesia Devices SDC/BICEPS Content Module (deferred) |
O |
||
Dialysis Devices SDC/BICEPS Content Module (deferred) |
O |
||
Note 1: All content exchanged on a SOMDS shall conform to the general SDPi “BICEPS Content Module” requirements (see Section 3:8.3.2). SOMDS Provider-specific content modules (e.g., infusion pumps) may be optionally supported as indicated. |
1:10.1.1 Actor Descriptions and Actor Profile Requirements
SDPi-P actor roles and responsibilities are described in the subsections below.
Unless otherwise specified below, individual transaction requirements are specified in TF-2 Section 2:3, and requirements related to content modules are detailed in TF-3 Section 3:8. This section documents any additional requirements on the profile’s content actors.
Figure 1:10.1.1-1 illustrates a typical (not comprehensive) exchange scenario between SDPi-P actors:
1:10.1.1.1 SOMDS Participant
Actor Summary Definition:
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:
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:
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:
A SOMDS Participant that enables seamless interaction with systems and software applications that are outside the scope of the SOMDS network instance. This abstract actor provides a consistent method for interacting, as a SOMDS Consumer and / or SOMDS Provider, with a specific SOMDS instance, as the foundation for protocol-specific gateway and platform actors.
Every abstract SOMDS Connector is grouped with (inherits from) the abstract SOMDS Participant.
A SOMDS Connector can implement both SOMDS Consumer and SOMDS Provider.
In the case of a connector implementing a SOMDS Consumer, it is able to interact with other SOMDS Provider to either obtain information that is then made available to Non-SOMDS Systems or invoke services that are requested from the external Non-SOMDS Systems. For example, forwarding patient respiratory rate readings to an external “flow sheet” application or invoking a device’s “pause alert audio” service when a clinician indicates they are responding to a physiological alert condition (e.g., high respiratory rate).
In the case of a connector implementing a SOMDS Provider, service capabilities for interacting with Non-SOMDS Systems are provided to the other networked SOMDS Consumer. For example, an application that wants to retrieve patient information from an EHR or check the latest patient laboratory results.
Note that the term “connector” is used to allow for SOMDS interaction with other systems that do not require protocol “gateway” adaptation, but do require a consistent interface to the other participants within a SOMDS environment. See Section 1:10.1.1.7 and Section 1:10.1.1.8 for examples.
Each SOMDS Connector gateway implementation will include the protocol-specific rules for connecting to and interacting with external non-SOMDS Systems, including semantic mappings, message formats, and interaction sequences. See related discussion at Section 3:8.3.2.4.
SDPi 1.4 Supplement Note: The TF-3 SDC/BICEPS Mapping of SOMDS Connector Content Modules section is out-of-scope., but included above for completeness of this actor overview. |
Although the SDPi-P Profile SOMDS Connector provides for non-SOMDS protocol-specific adaptors, they establish the foundation for specifying system and application-specific interfaces such as for EHR or decision support systems (e.g., sepsis determination). See Section 1:10.4.1.4, and Section 1:10.4.1.6 for additional perspectives and concepts on how SOMDS Connectors may be implemented.
SOMDS Connector system implementations may support multiple protocols where there is one SOMDS-facing participant model or API but with multiple protocols for non-SOMDS system integration. For example, a SOMDS “Alert” Gateway would interact with other SOMDS Participants in a single consistent way but may support both [HL7 FHIR] and [HL7 V2] protocols for interacting with healthcare enterprise systems.
SOMDS Connector may also be utilized in other SDPi Profiles for medical device information reporting (SDPi-R), alerting (SDPi-A) and external control (SDPi-xC). See those profile specifications for detailed usage. In some cases, IHE profiles have been defined for supporting integration with Non-SOMDS Systems, such as the V2-based IHE Devices Device to Enterprise Communication (DEC) profile (See [IHE PCD TF-1:2019]), or the IHE ITI XDS-I for locating and retrieving images for a specific patient using the XDS.b profile. In these cases, profile-specific SOMDS Connector adaptors may be specified as well.
1:10.1.1.5 SOMDS FHIR Gateway
Actor Summary Definition:
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:
A SOMDS Connector that supports use of [HL7 V2] for interoperating with Non-SOMDS Systems.
SOMDS V2 Gateway Actors shall be grouped with (inherit from) the abstract SOMDS Connector Actor. They shall implement either a SOMDS Provider and / or SOMDS Consumer Actor.
The SOMDS V2 Gateway identifies and specifies the logic necessary for connecting a SOMDS network environment with Non-SOMDS Systems that utilize [HL7 V2] for their interoperability protocol. Since V2 is a message-based protocol, the primary implementation guide logic is defined in Appendix 2:B.2. Additional specifications for semantic content modules is detailed in Section 3:8, including Section 3:8.3.2.3.
Generally, the SOMDS V2 Gateway supports messaging from a SOMDS environment to V2-enabled systems, utilizing a SOMDS Consumer to collect information from SOMDS Provider systems and translate them to V2 messages sent to other Non-SOMDS Systems. There are cases, though, where information may be sent to a SOMDS-based system such as an alert conformation utilizing a [DEV-05] (i.e., [PCD-05]) transaction (see Section 1:12 below).
1:10.1.1.7 SOMDS Sensor Gateway
SDPi 1.4 Supplement Note: Detailed specifications for this actor are deferred to a later version of the SDPi Supplement. |
Actor Summary Definition:
A SOMDS Connector that supports integration of sensors external to a SOMDS network.
SOMDS Sensor Gateway Actors shall be grouped with (inherit from) the abstract SOMDS Connector. They shall implement either a SOMDS Provider and / or SOMDS Consumer Actor.
The SOMDS Sensor Gateway identifies and specifies the logic necessary for integration of signals and controls from small sensor and actuator devices that do not have the resources to support direct integration into a SOMDS network. This includes integration of both wired and wireless sensor networks (“WSN”). This also includes SOMDS integration of IoT (“Internet of Things”) architectures / networks.
1:10.1.1.8 SOMDS Smart App Platform
SDPi 1.4 Supplement Note: Detailed specifications for this actor are deferred to a later version of the SDPi Supplement. |
Actor Summary Definition:
A SOMDS Connector that supports connection to a SOMDS network that is optimized for applications, including Software as a Medical Device (SaMD).
SOMDS Smart App Platform Actors shall be grouped with (inherit from) the abstract SOMDS Connector Actor. They shall implement either a SOMDS Provider and / or SOMDS Consumer Actor.
This actor leverages the consistent integration of a SOMDS Connector to a SOMDS network environment but provides a simplified platform specification to support “smart apps” including Software as a Medical Device (SaMD). For example, an application may only need to identify and consume a few parameters from one or more SOMDS Participant systems and not be required to implement a complete SOMDS interface including security, discovery, subscription management, filtering of unneeded MDIB information, etc.
SOMDS Smart App Platform Actors provide an abstraction layer between application software and the requirements for interoperating in a SOMDS network backbone. Since a single platform actor can support multiple Smart Apps, network traffic may be significantly reduced, as well as processing overhead for SOMDS Provider systems that have multiple SOMDS Consumers simultaneously invoking their services.
The platform must support both non-smart app critical functions (such as network topology discovery and maintenance) but also aggregate app requirements (e.g., quality of service necessary to support an application’s algorithms).
See Section 1:10.4.1.8 for additional discussion.
1:10.1.1.9 BICEPS Content Creator
Actor Summary Definition:
Provides MDIB content conformant to [ISO/IEEE 11073-10207:2017] BICEPS specification and for consumption by other BICEPS Content Consumer systems.
All content created and provided by a BICEPS Content Creator shall be conformant to the BICEPS content module specifications in Section 3:8.3.2.1 and related sections.
Note that although this SDPi-P content actor primarily supports information exchange between systems participating in a SOMDS network environment, they may also be utilized by other non-SDPi profiles that support non-SOMDS exchange architectures, transactions and technologies.
Content is provided by one SOMDS Participant to another. Typically, this will be a SOMDS Provider system to a SOMDS Consumer system; however, as noted previously, in some cases such as changing configuration settings within a SOMDS Provider (e.g., Patient Context), content creation and provision is from a SOMDS Consumer (initiating the configuration change request) to a SOMDS Provider system.
1:10.1.1.10 BICEPS Content Consumer
Actor Summary Definition:
Processes MDIB information conformant to [ISO/IEEE 11073-10207:2017] BICEPS specifications provided by BICEPS Content Creator systems.
A BICEPS Content Consumer shall be capable of processing information provided by a BICEPS Content Creator, in accordance to the BICEPS content module specifications in Section 3:8.3.2.1 and related sections.
For robustness, a BICEPS Content Consumer need only process the content that is necessary to support its capabilities, but shall also be able to accept and ignore any additional content that may be provided but is out-of-scope for its internal requirements. [6]
Note that although this SDPi-P content actor primarily supports information exchange between systems participating in a SOMDS network environment, they may be referenced by other non-SDPi profiles that utilize other non-SOMDS exchange architectures, transactions and technologies.
1:10.1.1.11 Discovery Proxy
Actor Summary Definition:
A centralized registry of system network presence and absence metadata.
The Discovery Proxy Actor provides a centralized means for systems connected to a network to update a central registry when they are present and available, as well as notification when they are leaving and will be absent. This is necessary for network configurations that do not support decentralized system discovery.
1:10.2 SDPi-P Actor Options
Options that may be selected for this Integration Profile are listed in the Table 1:10.2-1 along with the actors to which they apply. Dependencies between options when applicable are specified in notes.
Actor |
Option Name |
Vol. & Section |
1:10.2.1 Managed Discovery Option
The Discovery Proxy profile option provides an alternative means for SOMDS Consumer Actors to discover the SOMDS Provider Actors that are present on the network. The default "ad hoc" approach using the Section 2:3.23, Section 2:3.24 and Section 2:3.34 transactions, requires use of unsecured multicast messaging; however, some deployments do not support or allow this mode of discovery. The addition of a Discovery Proxy Actor enables a secure and non-multicast means for managing system discovery across the network. The Discovery Proxy Actor acts as a man-in-the-middle system, with SOMDS Provider Actors using the Section 2:3.46 transaction to provide endpoint metatdata and update their network presence or absence status. SOMDS Consumer Actors may then use the Section 2:3.47 transaction to determine available SOMDS Consumer systems and their endpoint metadata.
Figure 1:10.2.1-1 provides an overview of the interactions of the SOMDS Consumer and SOMDS Provider Actors with the Discovery Proxy Actor.
Once the discovery process is complete, actor interactions continue as normal. See Figure 1:10.1.1-1 for additional detail.
Though it is not recommended, deployments may allow simultaneous use of both the default "ad hoc" discovery mode and the managed proxy-based discovery mode utilizing a Discovery Proxy Actor. In these configurations, SOMDS Consumer and SOMDS Provider systems should prioritize use of the Discovery Proxy Actor.
Provisioning of SOMDS Participant systems to support use of a Discovery Proxy Actor is out-of-scope for this specification. |
1:10.3 SDPi-P Required Actor Groupings
SDPi 1.4 Supplement Note: As indicated in Figure 1:10.1-1 above, there are no explicit grouped actors in this specification; however, there are abstract actors (SOMDS Participant and SOMDS Connector), and the SOMDS Connector may implement interfaces to SOMDS Provider or SOMDS Consumer to provide bidirectional exchanges with non-SOMDS systems. These actor relationships do not represent typical IHE grouped actors, but should be represented in more explicit detail. The best approach for achieving that clarity and specificity will be addressed in a future version after further review and discussion by the supplement development team. |
1:10.4 SDPi-P Overview
1:10.4.1 Concepts
1:10.4.1.1 SOA & SOMDS Architecture Alignment
From a conceptual perspective, SDC implements a SOA architecture for device-to-device Plug-and-Trust (PnT) interoperability. Consider Figure 1:10.4.1.1-1:
This generalized model includes (3) system roles:
Service Providers — indicate the capabilities or services that they support, often published to a centralized registry that all participating systems recognize;
Service Registry — a SOA network capability enabling participating systems to discover or "find" services provided by networked systems, as well as information for how a service consumer system can initiate a connection with specific Service Providers;
Service Consumer — a SOA network system that utilizes the capabilities registered by a Service Provider.
A detailed overview of SOA concepts is beyond the scope of this specification. See Appendix 1:B for additional background materials. |
The SDC BICEPS standard, which SDPi-P profiles, consists of (3) core components, as illustrated in Figure 1:10.4.1.1-2:
The Medical Data Information Base (MDIB) component applies to all participating systems and consists of a descriptive model (e.g., what services and information a SOMDS Provider supports), and a state model. The discovery and communications models combine to enable device-to-device messaging and to identify both systems and services available on the network. The descriptive model is covered in more detail in Section 3:8.3.2.1, but the following Figure 1:10.4.1.1-3 shows how network efficiency is achieved by separating descriptive information from dynamic state information:
For every SOMDS Provider system, there is a descriptive model that includes a detailed specification of every element in the MDIB. For each Descriptor, though, there is a State element (note the inclusion of a State::DescriptorHandle), that can be used to determine the value and change status for the associated descriptor. Therefore, though the MDIB of a SOMDS Provider system must be retrieved at discovery and connection time, subsequent updates can be made upon state changes, greatly reducing network communication overhead.
For an example of how BICEPS components (see Figure 1:10.4.1.1-2) and MDIB descriptors and states (see Figure 1:10.4.1.1-3) support Plug-and-Trust (PnT) interoperability, a typical conversation is provided in Figure 1:10.1.1-1.
1:10.4.1.2 Medical Devices Communication Profile for Web Services (MDPWS)
To support the SOA-based connectivity described above, the default transport technology for this SDPi-P Profile is the XML-based Web Services as specified in [ISO/IEEE 11073-20702:2016]. Additional "glue" constraints for this MDPWS specification are provided in the companion standard: [ISO/IEEE 11073-20701:2018]. Specific SDPi-P Profile transaction message bindings and examples are provided in Appendix 2:A.
1:10.4.1.3 General Healthcare vs. Medical Interoperability Purposes
SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:10.4.1.4 Ensuring Time Synchronization
SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:10.4.1.5 Waveform Communication
SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:10.4.1.6 Aggregators, Proxies, Sensors
SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:10.4.1.7 Protocol-Specific Gateways
SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:10.4.1.8 Smart App Platforms
SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:10.4.1.9 Workflow vs. Transport Actors and Interactions
SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:10.4.1.10 SDC / BICEPS MDIB Versioning Management
SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:10.4.2 Use Cases
The SDPi-P Profile supports requirements from use cases detailed in Appendix 1:C. The following subsections identify the specific use case requirements that are fulfilled with capabilities provided by this specification.
1:10.4.2.1 Synchronized Time Across Devices (STAD)
This use case fully addresses the requirements from Appendix 1:C.2.
Specific capabilities supporting the STAD use case include:
System Type: MD LAN supported by SDPi-P PnT capabilities (see Figure 1:10.1.1-1)
Service Type: TS Service supported by Consistent Time Profile binding (see Section 1:10.4.1.4)
Technical Pre-Conditions: STAD Appendix 1:C.2.4 are fully supported by SDPi-P
Scenarios: STAD Appendix 1:C.2.5 are fully supported by SDPi-P
1:10.4.2.2 Standalone ICU Dashboard Single Patient (SICDsp)
This use case provides capabilities for requirements from Appendix 1:C.3.
Specific capabilities supporting the SICDsp use case include:
System Type: MD LAN supported by SDPi-P PnT capabilities (see Figure 1:10.1.1-1)
System Type: Dashboard is supported by the BICEPS Content Module Systems Types Nomenclature (see Table 3:8.3.2.6-1)
Technical Pre-Conditions: SICDsp Appendix 1:C.3.4 are fully supported by SDPi-P
Scenarios: SICDsp Appendix 1:C.3.5 basic communication requirements are supported by SDPi-P
1:10.4.2.3 Standalone ICU Dashboard Multiple Patient (SICDmp)
This use case provides capabilities for requirements from Appendix 1:C.4.
Specific capabilities supporting the SICDmp use case include:
System Type: MD LAN supported by SDPi-P PnT capabilities (see Figure 1:10.1.1-1)
System Type: Dashboard is supported by the BICEPS Content Module Systems Types Nomenclature (see Table 3:8.3.2.6-1)
Technical Pre-Conditions: SICDmp Appendix 1:C.4.4 are fully supported by SDPi-P
Scenarios: SICDmp Appendix 1:C.4.5 basic communication requirements are supported by SDPi-P
1:10.4.2.4 Device Data to Enterprise Systems (DDES)
This use case provides capabilities for requirements from Appendix 1:C.5.
Specific capabilities supporting the DDES use case include:
System Type: Gateway is supported by the BICEPS Content Module Systems Types Nomenclature (see Table 3:8.3.2.6-1)
Service Type: Data Gateway Service is supported by the BICEPS Content Module Systems Types Nomenclature (see Table 3:8.3.2.6-1)
Technical Pre-Conditions: DDES Appendix 1:C.5.4 are fully supported by SDPi-P
Scenarios: DDES Appendix 1:C.5.5 basic communication requirements are supported by SDPi-P
1:10.4.2.5 Alerts to Clinician Notification Systems (ACNS)
This use case provides capabilities for requirements from Appendix 1:C.6.
Specific capabilities supporting the ACNS use case include:
System Type: Alert Gateway (AGW) is supported by the BICEPS Content Module Systems Types Nomenclature (see Table 3:8.3.2.6-1)
Service Type: Alert Gateway Service is supported by the BICEPS Content Module Systems Types Nomenclature (see Table 3:8.3.2.6-1)
Technical Pre-Conditions: ACNS Appendix 1:C.6.4 are fully supported by SDPi-P
Scenarios: ACNS Appendix 1:C.6.5 basic communication requirements are supported by SDPi-P
1:10.4.2.6 Alerts to Alert Recording Systems (AARS)
This use case provides capabilities for requirements from Appendix 1:C.7.
Specific capabilities supporting the AARS use case include:
System Type: Alert Gateway (AGW) is supported by the BICEPS Content Module Systems Types Nomenclature (see Table 3:8.3.2.6-1)
Service Type: Alert Gateway Service is supported by the BICEPS Content Module Systems Types Nomenclature (see Table 3:8.3.2.6-1)
Technical Pre-Conditions: AARS Appendix 1:C.7.4 are fully supported by SDPi-P
Scenarios: AARS Appendix 1:C.7.5 basic communication requirements are supported by SDPi-P
1:10.5 SDPi-P Safety, Effectiveness and Security - Requirements and Considerations
1:10.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Section Safety, Effectiveness and Security - Requirements and Considerations.
1:10.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:10.5.3 Effectiveness Requirements & Considerations
1:10.5.3.1 Specific Risk Control Measures for SOMDS Consumers
1:10.5.3.2 General Risk Controls
Additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:10.5.4 Security Requirements & Considerations
Security is foundational for all interactions between SOMDS Participant Actors, with a clear distinction being made between information that may be exchanged outside of a secure connection (e.g., during network discovery transactions). Specific security technologies may vary based on the implementation technology being used, and will be detailed in the appropriate TF-2 technology specifications. All transactions indicate whether they require secure or unsecured connections.
For the default SDPi-P connectivity technology, namely ISO/IEEE 11073 Service-oriented Device Connectivity (SDC), TLS 1.2 (or later versions) support is required (See [ISO/IEEE 11073-20701:2018] and [ISO/IEEE 11073-20702:2016]). Additional information and requirements may be provided in Appendix 2:A.
1:10.6 SDPi-P Cross Profile Considerations
No cross profile considerations have been identified.
1:11 Service-oriented Device Point-of-care Interoperability - Reporting (SDPi-R) Profile
SDPi 1.4 Supplement Note: This version of the SDPi-R Profile is built upon the foundational SDPi-P Profile but does not provide substantially more capabilities. This is due to the fact that the primary purpose of this SDPi-R Profile, namely communication of medical data to accomplish intended medical purposes, requires the completion and integration of two emerging ISO/IEEE standards: [IEEE 11073-10700:2022] and [IEEE 11073-10701:2022]. When these are published in 2023 / 2024, their requirements will be integrated into this supplement, with their Implementation Conformance Statement (ICS) added to Appendix 1:B.2 below. Many of those requirements will be mapped to the actors and transactions and other elements in this supplement, including this SDPi-R Profile. Additionally, though the SOMDS DEC Gateway is defined below and fully specified in Appendix 2:B.3, the implementation guide for mapping from BICEPS to HL7 FHIR remains in development, pushing the specification of the SOMDS FHIR Medical Data Gateway to a later version of this supplement. |
The SDPi-Reporting ( SDPi-R) Profile supports the communication of information from one Service-oriented Medical Device System (SOMDS) to other SOMDS systems or to other external non-SOMDS systems utilizing a Data Gateway. Most of the actors and transactions in this specification are specialized versions of their counterparts in the SDPi-P Profile; however, are differentiated in that they are specifically designed to communicate information with an intended medical purpose. As a result, additional requirements are added to each actor and transaction to support address these additional safety and effectiveness requirements (See Section 1:11.5 below).
The profile builds upon the foundational Plug-and-Trust (PnT) capabilities provided by the SDPi-P Profile. These extended capabilities for medical data exchange are achieved by various means, including:
Addressing requirements from the emerging PKP ISO/IEEE standards: [IEEE 11073-10700:2022] and [IEEE 11073-10701:2022]
Requiring capabilities that in the SDPi-P Profile may be optional
Requiring additional BICEPS data elements or content modules
1:11.1 SDPi-R Actors, Transactions, and Content Modules
This section defines the actors, transactions, and/or content modules in this specification. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A. IHE Transactions can be found in the Technical Frameworks General Introduction Appendix B. Both appendices are located at profiles.ihe.net/GeneralIntro.
Figure 1:11.1-1 shows the actors directly involved in the SDPi-R Profile. The relevant transactions between them are detailed in the subsequent Table 1:11.1-1. actor groupings, including abstract with concrete, are detailed in Section 1:11.3.
Actors |
Transactions |
Initiator or Responder |
Optionality |
Reference |
Responder |
R |
|||
Initiator |
R |
|||
Responder |
R |
|||
Initiator |
R |
|||
Responder |
R |
|||
Initiator |
O |
|||
Initiator (See Note 1) |
R |
|||
Responder (See Note 1) |
R |
|||
Initiator (See Note 1) |
O |
|||
Note 1: If the SOMDS DEC Gateway implements the SDPi-R Option: Retrieve Remote Data, then bidirectional exchange is supported and the roles are expanded to "Initiator & Responder". |
1:11.1.1 Actor Descriptions and Actor Profile Requirements
SDPi-R actor roles and responsibilities are described in the subsections below.
Unless otherwise specified below, individual transaction requirements are specified in TF-2 Section 2:3, and requirements related to content modules are detailed in TF-3 Section 3:8. This section documents any additional requirements on the profile’s content actors.
Figure 1:11.1.1-1 illustrates a typical (not comprehensive) exchange scenario between SDPi-R actors:
1:11.1.1.1 SOMDS Medical Data Consumer
Actor Summary Definition:
A SOMDS Consumer grouped actor that receives medical data from a SOMDS Provider.
This actor is designed to process information with an intended medical purpose, and thus will fully address applicable requirements from the core SDC standards ([ISO/IEEE 11073-10207:2017] and [ISO/IEEE 11073-20701:2018]), as well as the PKP standards ([IEEE 11073-10700:2022] and [IEEE 11073-10701:2022]).
Every SOMDS Medical Data Consumer is grouped with an SOMDS Consumer to enable SOMDS-based connectivity. This actor inherits all the capabilities of the paired SOMDS Consumer. Note that optional capabilities for this specification, as specified in Section 1:11.2, may also result in additional requirements for the underlying SOMDS Consumer and SDPi-P Profile.
A system that participates in a SOMDS network instance can integrate both SOMDS Medical Data Consumer and SOMDS Medical Data Provider capabilities.
1:11.1.1.2 SOMDS Medical Data Provider
Actor Summary Definition:
A SOMDS Provider grouped actor that sends medical data to a SOMDS Consumer.
This actor is designed to process information with an intended medical purpose, and thus will fully address applicable requirements from the core SDC standards ([ISO/IEEE 11073-10207:2017] and [ISO/IEEE 11073-20701:2018]), as well as the PKP standards ([IEEE 11073-10700:2022] and [IEEE 11073-10701:2022]).
Every SOMDS Medical Data Provider is grouped with an SOMDS Provider to enable SOMDS-based connectivity. This actor inherits all the capabilities of the paired SOMDS Provider. Note that optional capabilities for this specification, as specified in Section 1:11.2, may also result in additional requirements for the underlying SOMDS Provider and SDPi-P Profile.
A system that participates in a SOMDS network instance can integrate both SOMDS Medical Data Provider and SOMDS Medical Data Consumer capabilities.
1:11.1.1.3 SOMDS DEC Gateway
Actor Summary Definition:
A SOMDS V2 Gateway grouped actor that supports the bi-directional exchange of medical data using IHE Device Enterprise Communication (DEC) messages with non-SOMDS systems and applications.
This actor is designed to process information with an intended medical purpose, and thus will fully address applicable requirements from the core SDC standards ([ISO/IEEE 11073-10207:2017] and [ISO/IEEE 11073-20701:2018]), as well as the PKP standards ([IEEE 11073-10700:2022] and [IEEE 11073-10701:2022]).
Every SOMDS DEC Gateway is grouped with an SOMDS V2 Gateway to enable SOMDS-based connectivity. This actor inherits all the capabilities of the paired SOMDS V2 Gateway. Note that optional capabilities for this specification, as specified in Section 1:11.2, may also result in additional requirements for the underlying SOMDS V2 Gateway and SDPi-P Profile.
This actor shall implement the SOMDS Medical Data Consumer capabilities, receiving information provided by SOMDS Medical Data Provider systems and publishing them as [DEV-01] / [PCD-01] Transactions to external DEC Device Observation Consumer (DOC) systems. If SDPi-R Option: Retrieve Remote Data is implemented, then this actor will also support the SOMDS Medical Data Provider capabilities, receiving [DEV-01] / [PCD-01] Transactions from external DEC Device Observation Reporter (DOR) systems and making them available to other SOMDS Medical Data Consumer systems. Note: Not supported are SOMDS DEC Gateway systems that only implement the SOMDS Medical Data Provider and not SOMDS Medical Data Consumer capabilities.
Detailed specifications for mapping from SOMDS/BICEPS to HL7 V2 / DEC transactions are provided in Appendix 2:B.3.
1:11.1.1.4 SOMDS FHIR Medical Data Gateway
Actor Summary Definition:
A SOMDS FHIR Gateway grouped actor that supports exchange of medical data between SOMDS-based systems and HL7 FHIR-based systems.
SDPi 1.4 Supplement Note: The HL7 FHIR resources and related Point-of-Care Device FHIR Implementation Guide (PoCD FHIR IG) is still under active development. Initial mappings have been made from SDC to FHIR; however, they are not yet ready for profiling and product implementation. When the FHIR specifications are finalized, then this actor will be fully specified in a future SDPI Supplement version. See SOMDS FHIR Gateway for additional information. |
1:11.2 SDPi-R Actor Options
1:11.2.1 Retrieve Remote Data
SDPi 1.4 Supplement Note: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi Supplement. This option will enable SOMDS Medical Data Consumer systems to access information in remote systems that are not part of its SOMDS network instance. This access will be provided by either a SOMDS DEC Gateway or SOMDS FHIR Medical Data Gateway. For example, retrieving the latest laboratory information for a specific patient. |
1:11.3 SDPi-R Required Actor Groupings
SDPi 1.4 Supplement Note: As indicated in Figure 1:11.1-1 above, there are four grouped actors: This section will be more completely detailed in a future version of the supplement. |
1:11.4 SDPi-R Overview
1:11.4.1 Concepts
SDPi 1.4 Supplement Note: An overview of the concepts for this SDPi-R Profile will be provided in a future supplement version. Note that this specification extends the concepts established in the base SDPi-P Profile. |
1:11.4.2 Use Cases
The SDPi-R Profile supports requirements from use cases detailed in Appendix 1:C. The following subsections identify the specific use case requirements that are fulfilled with capabilities provided by this specification.
1:11.4.2.1 Standalone ICU Dashboard Single Patient (SICDsp)
This use case provides capabilities for requirements from Appendix 1:C.3.
Specific capabilities supporting the SICDsp use case include:
System Type: N/A
Service Type: N/A
Technical Pre-Conditions: N/A
Scenarios: SICDsp Appendix 1:C.3.5 communication of medical data to a SOMDS Consumer Dashboard
1:11.4.2.2 Standalone ICU Dashboard Multiple Patient (SICDmp)
This use case provides capabilities for requirements from Appendix 1:C.4.
Specific capabilities supporting the SICDmp use case include:
System Type: N/A
System Type: N/A
Technical Pre-Conditions: N/A
Scenarios: SICDmp Appendix 1:C.4.5 communication of medical data to a SOMDS Consumer Dashboard
1:11.4.2.3 Device Data to Enterprise Systems (DDES)
This use case provides capabilities for requirements from Appendix 1:C.5.
Specific capabilities supporting the DDES use case include:
System Type: N/A
Service Type: N/A
Technical Pre-Conditions: N/A
Scenarios: DDES Appendix 1:C.5.5 communication of medical data to a SOMDS Consumer Gateway
1:11.5 SDPi-R Safety, Effectiveness and Security - Requirements and Considerations
1:11.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
A primary source of safety requirements for this SDPi-R Profile come from the [IEEE 11073-10701:2022] Metric Participant Key Purposes (PKP) standard.
SDPi 1.4 Supplement Note: The [IEEE 11073-10700:2022] and [IEEE 11073-10701:2022] standards are currently being published by the IEEE. Once published, their requirements will be integrated into this supplement, with many of them being mapped to elements in this SDPi-R Profile. |
For additional guidance, see Section Safety, Effectiveness and Security - Requirements and Considerations.
1:11.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:11.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:11.5.4 Security Requirements & Considerations
No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P Profile (see Appendix 1:A.3), and those specified in the SES General Considerations Section above.
1:11.6 SDPi-R Cross Profile Considerations
No additional cross profile considerations have been identified.
1:12 Service-oriented Device Point-of-care Interoperability - Alerting (SDPi-A) Profile
SDPi 1.4 Supplement Note: This initial version of the SDPi-A Profile is built upon the foundational SDPi-P Profile but adds services specialized for the communication and management of medical device alerting. Additionally, since the primary purpose of this specification is the communication of medical alert information to accomplish intended medical purposes, it will require the completion and integration of the emerging ISO/IEEE 11073 Alert PKP standard [IEEE 11073-10702:202x]. When this new standard is published in 2024, its requirements will be integrated into this supplement, with its Implementation Conformance Statement (ICS) added to Appendix 1:B.2. Many of those requirements will be mapped to the actors, transactions and other specifications in this specification. Two of the transactions identified below, [DEV-41] and [DEV-42] are related to Medical Alert Delegation; however, at this stage there is considerable standards development activity to update the current SDC standards, particularly in association with completing the Alert PKP standard [IEEE 11073-10702:202x]. As a result, the completion of these two transactions has been deferred to a subsequent version of the supplement. Similarly, a related transaction, [DEV-43], namely providing clinician alert acknowledgement status information back to the alerting device, is also being discussed further and will be deferred to a subsequent version of the supplement. Finally, it should be noted that SOMDS ACM Gateway is defined below and fully specified in Appendix 2:B.4. Also in development is HL7 FHIR support for medical alerting (e.g., definition of a FHIR DeviceAlert resource); however, that will not be completed until 2024 or beyond. As a result, a "SOMDS Medical Alert FHIR Gateway" is not included as an actor at this stage; however, it is expected to be added in the coming year or two. |
The SDPi-Alerting ( SDPi-A) Profile supports the communication of alert information from one Service-oriented Medical Device System (SOMDS) to other SOMDS systems or to other external non-SOMDS systems utilizing a Alert Gateway. The actors and transactions in this specification are specialized versions of their counterparts in the SDPi-P Profile; however, are differentiated in that they are specifically designed to communicate alert information to fulfill an intended medical purpose, primarily to notify a clinician of a patient or device-related condition that requires their attention. Additional services have been provided to specifically support the exchange and management of this medical device alert information, providing a high-level of reliability and performance, commensurate with the potential risk to the patient if they are not promptly addressed.
The profile builds upon the foundational Plug-and-Trust (PnT) capabilities provided by the SDPi-P Profile. These extended capabilities for medical data exchange are achieved by various means, including:
Addressing requirements from the emerging PKP ISO/IEEE standards: [IEEE 11073-10700:2022] and [IEEE 11073-10701:2022]
Requiring capabilities that in the SDPi-P Profile may be optional
Requiring additional BICEPS data elements or content modules
Additional requirements to addressed safety and effectiveness requirements are provided in Section 1:12.5.
1:12.1 SDPi-A Actors, Transactions, and Content Modules
This section defines the actors, transactions, and/or content modules in this specification. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A. IHE Transactions can be found in the Technical Frameworks General Introduction Appendix B. Both appendices are located at profiles.ihe.net/GeneralIntro.
Figure 1:12.1-1 shows the actors directly involved in the SDPi-A Profile. The relevant transactions between them are detailed in the subsequent Table 1:12.1-1. Actor groupings, including abstract with concrete, are detailed in Section 1:12.3.
Actors |
Transactions |
Initiator or Responder |
Optionality |
Reference |
Responder |
R |
|||
Initiator |
R |
|||
Responder |
R |
|||
Manage Medical Alert Delegation (deferred) |
Responder |
R (See Note 1) |
[DEV-41] Deferred to SDPi 2.0 |
|
Delegate Medical Alert (deferred) |
Initiator |
R (See Note 1) |
[DEV-42] Deferred to SDPi 2.0 |
|
Update Alert Acknowledgement Status (deferred) |
Responder |
R |
[DEV-43] Deferred to SDPi 2.0 |
|
Initiator |
R |
|||
Responder |
R |
|||
Initiator |
O |
|||
Manage Medical Alert Delegation (deferred) |
Initiator |
R (See Note 1) |
[DEV-41] Deferred to SDPi 2.0 |
|
Delegate Medical Alert (deferred) |
Responder |
R (See Note 1) |
[DEV-42] Deferred to SDPi 2.0 |
|
Update Alert Acknowledgement Status (deferred) |
Initiator |
R |
[DEV-43] Deferred to SDPi 2.0 |
|
SOMDS ACM Gateway (See Note 2) |
Initiator |
R |
||
Responder |
R |
|||
Initiator |
O |
|||
Update Alert Acknowledgement Status (deferred) |
Initiator |
O |
[DEV-43] Deferred to SDPi 2.0 |
|
Note 1: Transaction is required if SDPi-A Option: Alert Delegation is supported. Note 2: By default, the SOMDS ACM Gateway acts as a SOMDS Medical Alert Consumer, initiating [DEV-04] transactions when they are received from SOMDS Medical Alert Consumers. If the gateway supports SDPi-A Option: Remote Alert Signaling, then it also acts as a SOMDS Medical Alert Consumer and accepts inbound [DEV-04] transactions from ACM Alert Reporters. In this case, the gateway will support both "Initiator & Responder" for these transactions. |
1:12.1.1 Actor Descriptions and Actor Profile Requirements
SDPi-A actor roles and responsibilities are described in the subsections below.
Unless otherwise specified below, individual transaction requirements are specified in TF-2 Section 2:3, and requirements related to content modules are detailed in TF-3 Section 3:8. This section documents any additional requirements on the profile’s content actors.
Figure 1:12.1.1-1 illustrates a typical (not comprehensive) exchange scenario between SDPi-A actors:
1:12.1.1.1 SOMDS Medical Alert Consumer
Actor Summary Definition:
A SOMDS Consumer grouped actor that receives medical alert information from a SOMDS Medical Alert Provider.
This actor is designed to receive and manage medical device alert information to communicate it safely and reliably to a clinician. Transactions enabled for this actor are identified in Table 1:12.1-1 above.
Given this intended medical purpose, the actor will fully address applicable requirements from the core SDC standards ([ISO/IEEE 11073-10207:2017] and [ISO/IEEE 11073-20701:2018]), as well as the PKP standards [IEEE 11073-10700:2022] and [IEEE 11073-10702:202x] (Alert PKP).
Every SOMDS Medical Alert Consumer is grouped with an SOMDS Consumer to enable SOMDS-based connectivity. This actor inherits all the capabilities of the paired SOMDS Consumer. Note that optional capabilities for this specification, as specified in Section 1:12.2, may also result in additional requirements for the underlying SOMDS Consumer and SDPi-P Profile.
Note that if a Smart Alerting System is being created, it may incorporate both SOMDS Medical Alert Consumer and SOMDS Medical Alert Provider Actors, both receiving and publishing alerts.
1:12.1.1.2 SOMDS Medical Alert Provider
Actor Summary Definition:
A SOMDS Provider grouped actor that sends medical alert information to a SOMDS Medical Alert Consumer.
This actor is designed to publish medical device alert information to a SOMDS Medical Alert Consumer, which in turn can communicate it safely and reliably to a clinician. Transactions enabled for this actor are identified in Table 1:12.1-1 above.
Given this intended medical purpose, the actor will fully address applicable requirements from the core SDC standards ([ISO/IEEE 11073-10207:2017] and [ISO/IEEE 11073-20701:2018]), as well as the PKP standards [IEEE 11073-10700:2022] and [IEEE 11073-10702:202x] (Alert PKP).
Every SOMDS Medical Alert Provider is grouped with an SOMDS Provider to enable SOMDS-based connectivity. This actor inherits all the capabilities of the paired SOMDS Consumer. Note that optional capabilities for this specification, as specified in Section 1:12.2, may also result in additional requirements for the underlying SOMDS Consumer and SDPi-P Profile.
Note that if a Smart Alerting System is being created, it may incorporate both SOMDS Medical Alert Consumer and SOMDS Medical Alert Provider Actors, both receiving and publishing alerts.
1:12.1.1.3 SOMDS ACM Gateway
Actor Summary Definition:
A SOMDS V2 Gateway grouped actor that supports the bi-directional exchange of medical alert information with non-SOMDS systems and applications using IHE Alert Communication Management (ACM) transactions.
This a is designed to exchange medical device alert information to external non-SOMDS systems using the HL7 V2-based Alert Communication Management (ACM) Profile transactions.
Every SOMDS ACM Gateway is grouped with an SOMDS V2 Gateway to enable SOMDS-based connectivity. This actor inherits all the capabilities of the paired SOMDS V2 Gateway. Note that optional capabilities for this specification, as specified in Section 1:11.2, may also result in additional requirements for the underlying SOMDS V2 Gateway and SDPi-P Profile.
Transactions enabled for this actor are identified in Table 1:12.1-1 above.
Given this intended medical purpose, the actor will fully address applicable requirements from the core SDC standards ([ISO/IEEE 11073-10207:2017] and [ISO/IEEE 11073-20701:2018]), as well as the PKP standards [IEEE 11073-10700:2022] and [IEEE 11073-10702:202x] (Alert PKP).
This actor shall implement the SOMDS Medical Alert Consumer capabilities, receiving alert information provided by SOMDS Medical Alert Provider systems and publishing them as [DEV-04] / [PCD-04] Transactions to external ACM Alert Manager (AM) systems. If SDPi-A Option: Remote Alert Signaling is implemented, then this actor will also support the SOMDS Medical Alert Provider capabilities, receiving [DEV-04] / [PCD-04] Transactions from external ACM Device Observation Reporter (DOR) systems and making them available to other SOMDS Medical Data Consumer systems. Note: Not supported are SOMDS DEC Gateway systems that only implement the SOMDS Medical Data Provider and not SOMDS Medical Data Consumer capabilities.
Detailed specifications for mapping from SOMDS/BICEPS to HL7 V2 / ACM [DEV-04]/[PCD-04] transactions are provided in Appendix 2:B.4.
This actor is not intended to play the role of an ACM Alert Manager. If [DEV-04] transactions are received by the gateway, they will be simply mapped to SOMDS/BICEPS semantics and provided to SOMDS Medical Alert Consumer systems. |
If a Smart Alerting System is being created, it may incorporate both SOMDS Medical Alert Consumer and SOMDS Medical Alert Provider Actors, both receiving and publishing alerts to external ACM-based systems.
1:12.2 SDPi-A Actor Options
1:12.2.1 Alert Delegation Option
SDPi 1.4 Supplement Note: This section is intentionally left incomplete blank to indicate capabilities that will be added in a future version of the SDPi Supplement. As stated elsewhere, the completion of the [IEEE 11073-10702:202x] standard is required before this profile can be completed (beyond alert reporting for DIS capabilities), and that is especially the case for alert delegation. The sequence diagram below for delegation is provided for informative purposes only and will be finalized when the IEEE standard and this profile option are completed. This option will enable SOMDS Medical Alert Provider systems to safely and reliably transfer or "delegate" audible annunciation of alert conditions to another system. This option will enable both the Manage Medical Alert Delegation [DEV-41] and Delegate Medical Alert [DEV-42] transactions. |
Figure 1:12.2.1-1 illustrates a typical (not comprehensive) alert delegation scenario between SDPi-A actors:
1:12.2.2 Alert User Acknowledgement Option
SDPi 1.4 Supplement Note: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi Supplement. This option will enable SOMDS Medical Alert Provider systems to safely and reliably receive from SOMDS Medical Alert Consumer systems user (clinician) acknowledgement of previously reported alert conditions. This option will enable the Update Alert Acknowledgement Status [DEV-43] transaction. |
1:12.2.3 Remote Alert Signaling
SDPi 1.4 Supplement Note: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi Supplement. This option will enable SOMDS ACM Gateway systems to receive [DEV-04]/[PCD-04] transactions from an ACM Alert Manager and then act as a SOMDS Medical Alert Provider to communicate the signals to SOMDS Medical Alert Consumer systems This option will enable the SOMDS ACM Gateway to respond to Establish Medical Alert Exchange [DEV-38] and Retrieve Medical Alert Status [DEV-40] transactions, and to initiate Publish Medical Alert Update [DEV-39] transactions. |
1:12.3 SDPi-A Required Actor Groupings
SDPi 1.4 Supplement Note: As indicated in Figure 1:11.1-1 above, there are four grouped actors: This section will be more completely detailed in a future version of the supplement. |
1:12.4 SDPi-A Overview
1:12.4.1 Concepts
SDPi 1.4 Supplement Note: An overview of the concepts for this SDPi-A Profile will be provided in a future supplement version. Note that this specification extends the concepts established in the base SDPi-P Profile. |
1:12.4.2 Use Cases
The SDPi-A Profile supports requirements from use cases detailed in Appendix 1:C. The following subsections identify the specific use case requirements that are fulfilled with capabilities provided by this SDPi-A Profile.
1:12.4.2.1 Standalone ICU Dashboard Single Patient (SICDsp)
This use case provides capabilities for requirements from Appendix 1:C.3.
Specific capabilities supporting the SICDsp use case include:
System Type: N/A
Service Type: N/A
Technical Pre-Conditions: N/A
Scenarios: SICDsp Appendix 1:C.3.5 communication of medical alert information to a SOMDS Consumer Dashboard
1:12.4.2.2 Standalone ICU Dashboard Multiple Patient (SICDmp)
This use case provides capabilities for requirements from Appendix 1:C.4.
Specific capabilities supporting the SICDmp use case include:
System Type: N/A
System Type: N/A
Technical Pre-Conditions: N/A
Scenarios: SICDmp Appendix 1:C.4.5 communication of medical alert information to a SOMDS Consumer Dashboard
1:12.4.2.3 Alerts to Clinician Notification Systems (ACNS)
This use case provides capabilities for requirements from Appendix 1:C.6.
Specific capabilities supporting the ACNS use case include:
System Type: N/A
Service Type: N/A
Technical Pre-Conditions: N/A
Scenarios: ACNS Appendix 1:C.6.5 communication of medical alert information to a SOMDS Consumer Alert Gateway
1:12.4.2.4 Alerts to Alert Recording Systems (AARS)
This use case provides capabilities for requirements from Appendix 1:C.7.
Specific capabilities supporting the AARS use case include:
System Type: N/A
Service Type: N/A
Technical Pre-Conditions: N/A
Scenarios: AARS Appendix 1:C.7.5 communication of medical alert information to a SOMDS Consumer Alert Gateway
1:12.5 SDPi-A Safety, Effectiveness and Security - Requirements and Considerations
1:12.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Section Safety, Effectiveness and Security - Requirements and Considerations.
1:12.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:12.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:12.5.4 Security Requirements & Considerations
No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P Profile (see Appendix 1:A.3), and those specified in the SES General Considerations Section above.
1:12.6 SDPi-A Cross Profile Considerations
No additional cross profile considerations have been identified.
1:13 Service-oriented Device Point-of-care Interoperability – external Control (SDPi-xC) Profile
SDPi 1.4 Supplement Note: This SDPi-xC (External Control) Profile Section is generally out-of-scope for this version of the profile (see "Gemini SDPi Releases" Github project); however, it is provided here to indicate the intended direction of the SDPi Profiles, with details being added in subsequent versions. Depending on capabilities, some very basic controls may need to be provided in 2024 as part of the 1.x or 2.0 versions, especially around external adjustment of settings (e.g., alert limits or to trigger a blood-pressure reading). |
The SDPi-External Control ( SDPi-xC) Profile enables external or "remote" control of one device by another. This may be as simple as adjust an alarm limit or triggering a blood pressure cuff reading, to adjusting a respiration rate on a ventilator or titrating a drug dose rate on an infusion pump. Specializes services and semantics are provided to enable safe and secure control invocation.
1:13.1 SDPi-xC Actors, Transactions, and Content Modules
This section defines the actors, transactions, and/or content modules in this specification. General definitions of actors are given in the Technical Frameworks General Introduction Appendix A. IHE Transactions can be found in the Technical Frameworks General Introduction Appendix B. Both appendices are located at profiles.ihe.net/GeneralIntro.
Figure 1:13.1-1 shows the actors directly involved in the SDPi-xC profile. The relevant transactions between them are detailed in the subsequent Table 1:13.1-1. actor groupings, including abstract with concrete, are detailed in Section 1:13.3.
Actors |
Transactions |
Initiator or Responder |
Optionality |
Reference |
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 |
|
Manage Medical External Control (deferred) |
Initiator |
R |
[DEV-44] Deferred to SDPi 3.0 or later |
|
Invoke Medical Control Services (deferred) |
Initiator |
R |
[DEV-45] Deferred to SDPi 3.0 or later |
1:13.1.1 Actor Descriptions and Actor Profile Requirements
SDPi-xC actor roles and responsibilities are described in the subsections below.
Unless otherwise specified below, individual transaction requirements are specified in TF-2 Section 2:3, and requirements related to content modules are detailed in TF-3 Section 3:8. This section documents any additional requirements on the profile’s content actors.
Figure 1:13.1.1-1 illustrates a typical (not comprehensive) exchange scenario between SDPi-xC actors:
1:13.1.1.1 SOMDS Medical Control Consumer
Actor Summary Definition:
A SOMDS Consumer grouped actor that invokes operational control services on a SOMDS Medical Control Provider.
This actor is designed to invoke and manage medical device control operations, safely, effectively and securely. Transactions enabled for this actor are identified in Table 1:13.1-1 above.
Given this intended medical purpose, the actor will fully address applicable requirements from the core SDC standards ([ISO/IEEE 11073-10207:2017] and [ISO/IEEE 11073-20701:2018]), as well as the PKP standards [IEEE 11073-10700:2022] and [IEEE 11073-10703:202x] (Control PKP).
Every SOMDS Medical Control Consumer is grouped with an SOMDS Consumer to enable SOMDS-based connectivity. This actor inherits all the capabilities of the paired SOMDS Consumer. Note that optional capabilities for this specification, as specified in Section 1:12.2, may also result in additional requirements for the underlying SOMDS Consumer and SDPi-P Profile.
1:13.1.1.2 SOMDS Medical Control Provider
Actor Summary Definition:
A SOMDS Provider grouped actor that provides operational control services to a SOMDS Medical Control Consumer.
This actor is designed to publish medical device operational control services to a SOMDS Medical Control Consumer, which in turn can invoke the services and remotely manage the device, safely and securely. Transactions enabled for this actor are identified in Table 1:13.1-1 above.
Given this intended medical purpose, the actor will fully address applicable requirements from the core SDC standards ([ISO/IEEE 11073-10207:2017] and [ISO/IEEE 11073-20701:2018]), as well as the PKP standards [IEEE 11073-10700:2022] and [IEEE 11073-10703:202x] (Control PKP).
Every SOMDS Medical Control Provider is grouped with an SOMDS Provider to enable SOMDS-based connectivity. This actor inherits all the capabilities of the paired SOMDS Consumer. Note that optional capabilities for this specification, as specified in Section 1:12.2, may also result in additional requirements for the underlying SOMDS Consumer and SDPi-P Profile.
1:13.2 SDPi-xC Actor Options
No options are specified for this specification.
1:13.3 SDPi-xC Required Actor Groupings
SDPi 1.4 Supplement Note: As indicated in Figure 1:13.1-1 above, there are two grouped actors: This section will be more completely detailed in a future version of the supplement. |
1:13.4 SDPi-xC Overview
1:13.4.1 Concepts
SDPi 1.4 Supplement Note: An overview of the concepts for this SDPi-A Profile will be provided in a future supplement version. Note that this specification extends the concepts established in the base SDPi-P Profile. |
1:13.4.2 Use Cases
SDPi 1.4 Supplement Note: No use cases have been included that provide functional requirements for device external control. These will be added to a future version of the SDPi supplement. Therefore, with this release of the SDPi specification, this section remains incomplete. |
1:13.5 SDPi-xC Safety, Effectiveness and Security - Requirements and Considerations
1:13.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Section Safety, Effectiveness and Security - Requirements and Considerations.
1:13.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:13.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:13.5.4 Security Requirements & Considerations
No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P Profile (see Appendix 1:A.3), and those specified in the SES General Considerations Section above.
1:13.6 SDPi-xC Cross Profile Considerations
No additional cross profile considerations have been identified.
Appendix 1:A Requirements Management for Plug-and-Trust Interoperability
These SDPi specifications include the model-centric integration of requirements from multiple sources — both within IHE and from other SDOs — enabling a new level of requirements management that provides new value to all stakeholders. Also termed Requirements Interoperability (RI), innovative capabilities include:
Explicit linking of requirements from their definition to their satisfaction / utilization in defined capabilities;
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;
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 ;
Referenced standard traceability and coverage is enabled by this linkage from each requirement to testable interface capabilities;
Both SES and MDI standards are supported, enabling true SES+MDI integration;
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:
Though a full explanation of the framework is beyond this discussion [7], some general observations will help understand the value and use of the framework:
Real-world Requirements are at the top — use case-based requirements that detail clinical system function scenarios, ensuring that all requirements and capabilities in the specifications are rooted in the healthcare purposes that technology users are expecting to be supported: effectively, safely and securely;
Each layer or "garden" and contained specification(s) define - implicitly or explicitly - how they integrate with other layers: *capabilities* that are provided (to meet the needs of other layers), and *requirements* (needed capabilities) for other layers and implementations;
Standards are sometimes grouped into families (e.g., ISO/IEEE 11073 SDC) - this indicates that they are internally cohesive as well as able to be integrated as a group with other areas;
*Vertical* groupings on the left indicate standards that apply to all of the *horizontal* layers in the core of the model;
Profile standards, such as the SDPi+FHIR, generally integrate specifications through the layers from the top to the bottom similar, with each layer contributing to those below and converging in a single interface capability bundle;
Physical layers are leveraged, not re-invented, which is why there is no color in the bottom layer;
*Requirements interoperability* is achieved by tracing "profile lines" from top to bottom, integrating requirements from one layer’s specification to the capabilities provided by another layer;
Requirement TYPEs are rooted in the layers that they represent and link type definitions to their use in this specification; see Appendix 1:A.4.1 Section below.
The implementation of this high-level framework will be extended as the specifications and tooling mature. |
1:A.2 Integrating Safety, Effectiveness and Security Requirements and Considerations
In 2007, a joint effort between ISO/TC 215 and IEC/SC 62A was launched — Joint Working Group 7 (JWG7) — to focus on how to apply risk management to medical devices and health information systems and software that needed to interoperate on shared (hospital owned & managed) networking infrastructure. The resulting standard, [ISO/IEC 80001-1:2021], with a first edition published in 2010 and revised in 2021, not only provided a process for performing coordinated multi-stakeholder risk management for these technologies, but recognized the three key properties that would be the focus of that risk management: Safety, Effectiveness & Security (SES) [8].
During the development of the 80001-1 standard, though, it was recognized that risk management is just one of a number of other core themes that had to be managed in concert (e.g., quality management, human factors / usability). Also ensuring SES required processes that involve a total product lifecycle, with responsibilities transitioning across that period. To address these requirements, JWG7 developed the [ISO/IEC 81001-1:2021] standard, which also included The Temple diagram to communicate various aspects of SES that must be considered and managed:
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:
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;
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;
"Safety, Effectiveness and Security - Requirements and Considerations" sections are integrated throughout the profile specifications to link from the PKP ICS table requirements to the satisfying capabilities.
Additional non-PKP risk management will also be performed by subject matter experts and formalized in these SES Considerations sections, where appropriate.
These "Safety, Effectiveness and Security - Requirements and Considerations" sections grew out of the IHE "Security Considerations" sections + the IHE Devices "Safety Considerations" sections, but are now consolidated into a single SES section that integrates the 3rd risk management property, Effectiveness. Whenever possible, each of these considerations should be associated with the requirements of specific standards (e.g, [IEEE 11073-10700:2022]).
The moniker SES+MDI is shorthand to refer to the integration of the technical medical device interoperability (MDI) specifications with the application of quality / risk management SES standards and processes. |
How does this address the "interoperability trust gap"? By integrating SES directly into the specifications, especially integrating the ISO/IEC 11073-1070x standards, enabling "plug-and-trust" system product components, the SES implementation and operational requirements and responsibilities are greatly reduced, the "gap" is filled for all stakeholders, and the goals of improved safety, security and clinical effectiveness of technology can be readily realized.
1:A.3 SES Considerations Section Template
Given the forgoing discussion in Section 1:2.2, a standardized template is defined for addressing SES requirements as appropriate, including within the scope of profiles, actors, transactions, and content modules. The content in the following sections should be included and then specialized as appropriate for the associated technical framework element.
SES Section Template: Safety, Effectiveness and Security - Requirements and ConsiderationsSES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element. For additional guidance, see Section Safety, Effectiveness and Security - Requirements and Considerations. 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. 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
No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P profile, and those specified in the SES General Considerations Section above. |
1:A.4 SDPi Requirements Modeling & Integration
SDPi 1.4 Supplement Note: The information in this section includes both general requirements modeling information that captures the metadata that is ultimately exported for document-external use. It also includes specific AsciiDoc information (e.g., element labels) to facilitate review by providing all the related information in one location. Ultimately, the AsciiDoc and related information that is used for specification production and requirement exportation (e.g., export JSON mapping and file format), will be moved to a separate article or paper. |
As pointed out above, requirements interoperability (RI) based on robust model-based metadata is a core, innovative aspect of this specification. Given the ultimate intent for this document to be a Model Centric (MC) single-source-of-truth, computable, simulatable, verifiable and validatable system of systems interoperability specification, and recognizing that it will take a significant transition period from a document-centric approach to a model-centric approach, the simplified requirements model provided below represents a significant step toward realizing these objectives. See section Figure 1:A.4.1-1 below for possible pathways for fully achieving the vision above.
It should be further noted that though conformity testing aspects are beyond this revision of the SDPi specification, the modeling constructs used below will also be directly associated with test assertions and integrated into test / verification cases to provide for advanced V&V of interoperable system components and entire systems of products.
1:A.4.1 SDPi Requirements Core Model
To formally integrate requirements in to this specification, the following model details the core types of requirements that will be utilized:
This model identifies the set of requirement "types" that are integrated into the specification. Each type defines a unique class of requirements that build upon a foundational Requirement Definition (abstract) definition that is specialized with additional metata to better capture the unique source and role of each requirement.
Model Element | Description | AsciiDoc Attribute | Further Specified |
---|---|---|---|
Requirement Definition |
A defined stakeholder-imposed constraint that must be satisfied for a design solution to be valid. This is an {abstract} class model element. |
sdpi_requirement |
NOTE: parent / sibling optional relationships provide for linking related requirements |
Requirement Fulfillment |
A capability provided in the specification that fulfills part or all of one or more requirements, and may be directly linked to a test assertion (external to the specification). |
sdpi_requirement_fulfillment |
|
IHE Profile |
Each IHE profile specification has a set of requirements that must be captured. For example, Actor X in Profile Y requires support for Transaction A + B + C. NOTE: These requirements provide the anchor for all conformity assessment, since implementations will identify the actors + profile + profile option + role + transactions that they support. See also "AIPO" discussion below. |
sdpi_requirement_ihe_profile |
|
Use Case Feature |
A functional "feature" requirement based on clinical use case scenarios. |
sdpi_requirement_use_case |
See TF-1 Appendix C, Gherkin-based model |
Referenced Standard ICS |
Requirement definitions that are specified in a normative reference. |
sdpi_requirement_ref_standard |
|
SES |
Non-technical requirements related to Safety, Effectiveness, and Security are captured in these blocks. These are especially relevant to mapping ISO/IEEE 11073-1070x Participant Key Purposes standard requirements to elements within the SDPi specification. |
sdpi_requirement_ses |
See SES Section Appendix 1:A.2 |
Tech Feature |
Technology focused requirements result from the use of a particular implementation approach. For example, use of TLS 1.3 may also result in the need to address related technical capabilities. |
sdpi_requirement_tech_feature |
"ICS" = Implementation Conformance Statement (e.g., a table identify how conformance to a standard may be detailed) |
The following subsections provide additional detail for each element of the above requirements model. Note that each item includes metadata that is used for computability purposes as well as textual elements that are visibly rendered in the document. All content may be exported from the specification and contained in a requirements summary specification in a common format (e.g., JSON), which may be used for additional purposes such as integration into requirements management tools and conformity assessment testing artifacts.
1:A.4.2 Requirement Type: Requirement Definition
Each type of requirement shares a common set of metadata represented by the abstract "Requirement Definition" in the model above. This metadata supports the basic capabilities of each requirement including classification (subtype), navigation (traceability), and grouping.
Metadata Element | Description | AsciiDoc | Example | Additional Consideations |
---|---|---|---|---|
Unique Identifier |
Each requirement instance must include an identifier that is unique within the scope of the specification, and may be rendered in human-readable form |
sdpi_requirement |
[sdpi_requirement#r7009] |
See Appendix 1:A.4.2.1 for additional discussion; note this identifier may be used for tracking in systems such as requirement management tools |
Requirement OID |
An ISO Object Identifier that is aligned with the IHE OID tree for the specific requirement. |
sdpi_req_oid |
[sdpi_req_oid=1.3.6.1.4.1.19376.1.6.2.11.2.123456] |
This OID identifier is in addition to the Unique Identifier element, but is not considered human-readable and is not intended to be rendered in the document; this identifier is a type of URI |
Requirement Type |
Each requirement instance is identified by its subtype |
sdpi_req_type |
[sdpi_req_type=use_case_feature] |
See specific subtype sections below for additional enumerations |
Requirement Level |
Each requirement instance includes a conformance level: shall, should, may |
sdpi_req_level |
[sdpi_req_level=shall] |
Conditional requirements may need additional specification. |
Requirement Text |
Textual description of the requirement, intended for rendering in the specification |
"All requirements shall be identified as one of the core subtypes." |
The requirement text should be kept simple and clear. Additional explanatory text should be contained in requirement notes (see below) |
|
Requirement Note(s) |
Additional textual detail that supplements the Requirement Text |
Free form text contained in a "NOTE" |
"NOTE: The mapping for the height observation is defined in table …" |
|
Requirement Parent |
Identifies a more general or related requirement that a requirement specializes |
sdpi_req_parent |
[sdpi_req_parent=r6789] |
Unique identifiers may be used to link requirements |
Requirement Sibling |
Identifies one or more requirements that are related to this requirement |
sdpi_req_sibling |
[sdpi_req_sibling=r1234] |
|
Requirement Group(s) |
A label that may be used to group related requirements |
sdpi_req_group |
[sdpi_req_group=ws_security] |
Requirement groups or categories may be used independently of the parent/sibling linkages |
The following sections discuss additional aspects of requirements formalization using this foundational Requirement Definition metadata.
1:A.4.2.1 Assigning Unique Identifiers
Every requirement must have a unique instance identifier that is used for:
Human-readable display in the rendered document
Requirements management systems (external)
Conformity Assessment tooling (external)
Uniqueness must be achieved within the scope of the given specification (e.g., SDPi), and in the future, across specifications, both IHE technical frameworks as well as related standards that may use the same scheme.
Two requirement identifiers are currently specified:
Unique Identifier
Human-readable text that is displayed with detailed requirement content in the specification
Example: "R1234"
Identifiers have a simple numeric value, with four digits sufficient for most applications
Identifier letters may be enhanced from a simple "R" to include a type (e.g., RSR for Referenced Standard Requirement, or UCR for Use Case Requirement, etc.)
Requirement OID
A machine-readable URI style identifier that ensures global uniqueness
Root OID is based on the specification scope with IHE: 1.3.6.1.4.1.19376.1.6.2.11 = IHE DEV TF SDPi-P profile
Addition of .2.x is for a profile-specific requirement; for example: 1.3.6.1.4.1.19376.1.6.2.11.2.1234 = an SDPi-P Requirement "R1234"
Version can also be added to this OID in the future; for example: 1.3.6.1.4.1.19376.1.6.2.11.2.1234.1.0 for requirement version 1.0
FOR THE CURRENT SPECIFICATION, these identifiers are assigned manually, with an automated uniqueness check performed by the asciidoc-converter to HTML application. Assignment may evolve with experience and extended use.
1:A.4.2.2 Usage Levels
Requirement Level must be valued as one of the following strings: "shall", "should", "may". For example, "sdpi_req_level=should"
"Conditional" requirements may also need to be indicated in metadata; however, that is beyond the scope of the current specification revision. For example, there are some cases where the conditional logic might be included in the requirement specification:
IF <condition #1>
THEN <R1234 should be fulfilled>
Requirement conditionality may be easily added as a Requirement Note; however, that is not computable metadata. Another approach, would be to add a Requirement Condition data element that included some logic, perhaps linking to the presence of some configuration (such as a profile option selection) or other requirement. This will be addressed in subsequent versions of this specification.
1:A.4.2.3 Requirement Grouping
Some requirements may be grouped beyond their specification scope, requirement type or inter-requirement linkages. For example, security related requirements may include a "security" group label, regardless of where they are located in the specification. This provices a simple, easily extensible way for showing ad hoc associations between classes of requirements.
Requirement group labels may be included in a comma-separated list. For example: sdpi_req_group=security,real-time
This element should only be used when other association mechanisms do not easily meet the need.
1:A.4.3 Requirement Navigation
Although Figure 1:A.4.1-1 generally indicates bi-directional navigation (arrows on both ends of Requirement-Usage pairs, supporting bi-directional bindings and navigation is not always helpful and is never easy. This is especially the case when considering potential future updates to the profile specifications. In that case, the general rule is:
Add backward references from Requirement Fulfillment to Requirement Definition.
For example, in TF-2 Transactions, each transaction section is paired with a message transport section in Appendix 2:A; however, future versions of the specification may provide options for alternative transports. In this case, the actual transaction definition will remain unchanged, but the bindings to transport messages and services would change. Given the rule above, bindings are made in the current TF-2 Appendix A MDPWS specification pointing backward (or upward!) to the transaction requirements that they satisfy. There are no bindings in the opposite direction. Taking this approach, a new transport appendix could be added in the future without impacting the core transaction specifications.
Application of this rule would also hold true in other places such as backward references from a profile’s Use Case section to the specific Appendix 1:C use case and scenario requirements that they satisfy.
In some cases, it may be necessary to provide bi-directional bindings; however, that would be the exception, not the rule.
1:A.4.4 Requirement Type: Technical Feature
Description: A basic technical requirement that is not one of the other catageories and does not require additional metadata.
Requirement Metadata:
Requirement Definition Metadata: Unique Identifier, Requirement OID, Requirement Type, Requirement Level, Requirement Text
Requirement Type = tech_feature
Requirement Tech Feature: No additional data elements
Example: A SOMDS Participant should use a dynamically configured IP address.
1:A.4.5 Requirement Type: IHE Profile
Description: Requirement associated to an aspect of an IHE profile specification
Each of the top-level profile elements in Figure 1:A.4.5-1 may require additional sub-elements; however, care must be taken not to replicate the entire specification in requirements metadata! This reflects the ultimate objective of having a fully modeled specification, with the documentation generated automatically (see Appendix 1:A.5). At this point, only what is required to provide the intended capabilities (see below) should be included. Heuristic: start with less and add as needed.
Requirement Metadata:
Requirement Definition Metadata: Unique Identifier, Requirement OID, Requirement Type, Requirement Level, Requirement Text
Requirement Type = ihe_profile
IHE Profile Metadata:
TF Element = actor, profile, transaction, profile_option, profile_actor_option, content_module, actor_transaction_model
AIPO = string representing unique Actor + Integration Profile + Profile Option combination
Example #1:
Metadata: ihe_profile + R1234 + 1.3.6.1.4.1.19376.1.6.3.23 + actor + shall
Requirement: The SOMDS Provider shall support the Section 2:3.24 transaction.
Example #2:
Question: What requirements shall a SOMDS Provider support?
Answer: Search exported requirements for Requirement Type=IHE Profile + AIPO=somds-provider_sdpi-p
1:A.4.6 Requirement Type: Use Case Feature
Description: A requirement in a high-level, profile-independent use case specification
Ultimately, test cases should reflect the detailed content of the use case requirements associated with each integration profile. Test assertions associated with a Requirement Fulfillment capability should then enabling traceability through the various Requirement Definitions that ultimately are linked to a Use Case Feature. The level of use case granularity may vary depending on whether the requirement is associated with the entire Use Case Feature, a specific Scenario, a Scenario’s Background Pre-Condition(s), etc.
SDPi 1.4 Supplement Note: Additional detail will be added in a subsequent version. Additional metadata may include:
|
1:A.4.7 Requirement Type: Referenced Standard ICS
Description: A requirement linked to a referenced standard.
SDPi 1.4 Supplement Note: Additional detail will be added in a subsequent version. Additional metadata may include:
|
1:A.4.8 Requirement Type: SES
Description: Requirement that represents a quality aspect of the specification typically related to risk management activities and resulting mitigations
Generally, SES sections are associated with major elements of the specification and provide guidance for what an implementation must do to ensure trustworthy operation.
Requirements from SES referenced standards such as [IEEE 11073-10700:2022] may be linked (e.g., as a parent) to an SES requirement type. |
SDPi 1.4 Supplement Note: Additional detail will be added in a subsequent version. Additional metadata may include:
|
1:A.4.9 Requirement Use Type: Requirement Fulfillment
Description: Provides a link from a capability that may be associated with a test assertion to one or more requirements that it fulfills.
SDPi 1.4 Supplement Note: Additional detail will be added in a subsequent version. Additional metadata may include:
|
1:A.4.10 Relationship to Gazelle Master Model + Assertion Manager Tool
IHE formalizes all profile conformity assessment elements in the Gazelle Master Model (GMM), including actors, transactions, profiles, profile options, and the test cases that are needed to ensure implementation conformance to each profile specification requirement. To associate groups of conformity tests with systems being tested, Gazelle defines an "AIPO" bundle: * Actor * Integration Profile (in which the actor being tested is included) * Profile Option
For example, a system under test may declare AIPO support for: Discovery Proxy + SDPi-P + Managed Discovery
The following graphic illustrates the information managed in the GMM:
The Gazelle Assertion Manager tool associates test assertions with IHE profile elements as follows:
The RI model specified here provides for explicit declaration of AIPO requirement bundles, facilitating the association of Gazelle-based test sequences for a given system under test.
Additionally, a Gazelle Assertion Manager Tool has been created to link testable assertions to sections within a specification and then to specific test scenarios; however, this tool is not currently in active use, and it is anticipated that it will serve to inform new test assertion management tooling required by this specification. There are fundamental differences, though, such as explicit requirement identifier numbering that allows assertions to be linked directly to requirements, as opposed to specification section numbers.
HL7 FHIR includes an assert data element in the TestScript resource. |
1:A.5 Future extensibility: Use Cases, MBSE Requirements Modeling & SysML 2.0
OMG's Systems Modeling Language 2.0 (see [OMG SysML ® 2.0] Section 7.20 Requirements language and [OMG SysML ® Intro-Graphical Notation 2.0]), provides extended support for requirements modeling that not only provides the foundation for implementation of Model-Based Systems Engineering (MBSE) methodology (see MBSE Wikipedia article and references), but also a computable specification that enables automated verification (e.g., using "Verification Cases"). As these technologies evolve and are more generally accessible to standards communities, it will be possible to align the above requirements model with that specified in SysML 2.0 and ultimately to provide a specification that can be verified correct and validated through simulation.
Appendix 1:B References
SDPi 1.4 Supplement Note: The inclusion of a References appendix is unique for IHE Technical Framework specifications. Typically, referenced standards sections are distributed throughout the specifications where appropriate; however, standards from other organizations (e.g., IEEE, ISO, IEC) typically have a "Normative References" clause and when desired a "Bibliography" clause. Also, integration of explicit standards' Implementation Conformance Statement (ICS) specifications (e.g., [ISO/IEEE 11073-10207:2017] ICS tables) is unique, but needed to support requirements interoperability. Ultimately, the content of this appendix may be rearranged and even relocated; however, for early versions of the SDPi supplement, it has proven helpful, and even of critical importance and value. |
1:B.1 Referenced Standards
SDPi 1.4 Supplement Note: The standards listed in this section are predominantly published. However, in the current version, three of them are unpublished drafts and are hence subject to requirement changes once they are published: [HL7 FHIR Point-of-Care Device Implementation Guide], [IEEE 11073-10702:202x] and [IEEE 11073-10703:202x]. No content from those three standards - including their requirements - is normatively used in the current version. |
[AAMI 2700-1:2019] AAMI 2700-1:2019 Medical Devices And Medical Systems - Essential Safety And Performance Requirements For Equipment Comprising The Patient-Centric Integrated Clinical Environment (ICE) - Part 1: General Requirements And Conceptual Model, available at ANSI/AAMI web store.
[HL7 FHIR] HL7® Fast Healthcare Interoperability Resources (FHIR®), available at hl7.org/fhir/.
[HL7 FHIR Point-of-Care Device Implementation Guide] HL7 FHIR Point-of-Care Device Implementation Guide, drafts available on the Devices on FHIR project page, and a continuous build version at Point-of-Care Device Implementation Guide web page.
[HL7 V2] HL7® Version 2 (V2), available at HL7 Version 2 Product Suite web page.
[IEC 60601-1-8:2020], IEC 60601-1-8:2006/AMD2:2020, Medical electrical equipment — Part 1-8: General requirements for basic safety and essential performance — Collateral standard: General requirements, tests and guidance for alarm systems in medical electrical equipment and medical electrical systems; Amendment 1:2020, and Amendment 2:2020. available at IEC Webstore and the ISO standards store.
[IEEE 11073-10101:2020] IEEE 11073-10101™ International Standard - Health informatics—Device interoperability—Part 10101:Point-of-care medical device communication—Nomenclature. Available at IEEE online standards store.
[IEEE 11073-10201:2004] IEEE 11073-10201™ International Standard - Health informatics—Device interoperability—Part 10201:Point-of-care medical device communication—Domain information model. Note this was updated in 2020. Available at IEEE online standards store.
[ISO/IEEE 11073-10207:2017] ISO/IEEE 11073-10207-2017, Health informatics — Point-of-care medical device communication — Part 10207: Domain Information and Service Model for Service-Oriented Point-of-Care Medical Device Communication, 2017-12, available at https://standards.ieee.org/ieee/11073-10207/6032 [1]
[IEEE 11073-10700:2022] IEEE P11073-10700™/D7 Draft Standard for Health Informatics – Device Interoperability – Part 10700: Point-of-Care Medical Device Communication – Standard for Base Requirements for Participants in a Service-Oriented Device Connectivity (SDC) System.
[IEEE 11073-10701:2022] IEEE P11073-10701™/D4 Draft Standard for Health Informatics – Device Interoperability – Part 10701: Point-of-Care Medical Device Communication - Metric Provisioning by Participants in a Service-Oriented Device Connectivity (SDC) System
[IEEE 11073-10702:202x] IEEE P11073-10702™/D1 Draft Standard for Health Informatics – Device Interoperability – Part 10702: Point-of-Care Medical Device Communication – Alert Provisioning by Participants in a Service-Oriented Device Connectivity (SDC) System
[IEEE 11073-10703:202x] IEEE P11073-10703™/Draft Standard for Health Informatics – Device Interoperability – Part 10703: Point-of-Care Medical Device Communication – External Control by Participants in a Service-Oriented Device Connectivity (SDC) System, in development.
[ISO/IEEE 11073-20701:2018] ISO/IEEE 11073-20701-2018, Health informatics — Point-of-care medical device communication — Part 20701: Service-Oriented Medical Device Exchange Architecture and Protocol Binding, 2018-09, available at https://standards.ieee.org/ieee/11073-20701/6059
[ISO/IEEE 11073-20702:2016] ISO/IEEE 11073-20702-2016, Health informatics — Point-of-care medical device communication — Part 20702: Medical Devices Communication Profile for Web Services, 2016-09, available at https://standards.ieee.org/ieee/11073-20702/6034
[ISO/IEC 80001-1:2021], IEC 80001-1:2021 Application of risk management for IT-networks incorporating medical devices — Part 1: Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software. Available at IEC Webstore and ISO standards store.
[ISO/IEC 81001-1:2021], ISO 81001-1:2021 Health software and health IT systems safety, effectiveness and security — Part 1: Principles and concepts. Availabe at ISO standards store and IEC Webstore.
[IHE PCD TF-1:2019] IHE Patient Care Device Technical Framework, Vol. 1, available at https://www.ihe.net/uploadedFiles/Documents/PCD/IHE_PCD_TF_Vol1.pdf.
[IHE PCD TF-2:2019] IHE Patient Care Device Technical Framework, Vol. 2, available at https://www.ihe.net/uploadedFiles/Documents/PCD/IHE_PCD_TF_Vol2.pdf.
[IHE PCD TF-3:2019] IHE Patient Care Device Technical Framework, Vol. 3, available at https://www.ihe.net/uploadedFiles/Documents/PCD/IHE_PCD_TF_Vol3.pdf.
[RFC 3986] T. Berners-Lee et al., RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, January 2005, available at https://www.rfc-editor.org/rfc/rfc3986
[OASIS DPWS:2009] OASIS Standard, Devices Profile for Web Services Version 1.1, OASIS Standard, 1 July 2009, available at http://docs.oasis-open.org/ws-dd/dpws/wsdd-dpws-1.1-spec.html
[OASIS SOAP-over-UDP Version 1.1] OASIS Standard, SOAP-over-UDP Version 1.1, July 2009, available at http://docs.oasis-open.org/ws-dd/soapoverudp/1.1/os/wsdd-soapoverudp-1.1-spec-os.docx.
[W3C Recommendation, WS-Addressing:2006] Web Services Addressing 1.0 - Core (WS-Eventing), W3C Recommendation 9 May 2006, available at https://www.w3.org/TR/2006/REC-ws-addr-core-20060509/
[OASIS WS-Discovery:2009] OASIS Standard, Web Services Dynamic Discovery (WS-Discovery) Version 1.1, OASIS Standard, 1 July 2009, available at http://docs.oasis-open.org/ws-dd/discovery/1.1/wsdd-discovery-1.1-spec.html
[W3C Submission, WS-Eventing:2006] W3C Web Services Eventing (WS-Eventing), W3C Member Submission 15 March 2006, available at https://www.w3.org/Submission/2006/SUBM-WS-Eventing-20060315/
[W3C Submission, WS-MetadataExchange:2008] Web Services Metadata Exchange 1.1 (WS-MetadataExchange), W3C Member Submission 13 August 2008, available at https://www.w3.org/Submission/2008/SUBM-WS-MetadataExchange-20080813/
[WC3 Standard, WS-Transfer:2006] WC3 Web Services Transfer (WS-Transfer), W3C Standard, 27 September 2006, available at https://www.w3.org/Submission/WS-Transfer/
1:B.2 Referenced Standards Conformance
1:B.2.1 Mapping Foundational Standard Requirements to SDPi Constructs
SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:B.2.2 Overview of Standards Conformity Statements
SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:B.2.3 ISO/IEC 11073-10207 BICEPS ICS Tables
SDPi 1.4 Supplement Note: This section is provided as a placeholder for the ICS table specification that will be added in a subsequent SDPi supplement version. The tables will have an additional SDPi column added to the right side that indicates if and TBD where the requirement is satisfied. Requirement Definition (this table’s rows) will be referenced where they are satisfied; however, these tables may also include forward references, at least in general, to what capabilities / requirements satisfy the referenced standard requirement. |
Standard Version: IEEE 11073-10207:2017
1:B.2.3.1 General
GEN-1 & GEN-4 are broken references, GEN-2 and GEN-3 are satisfied by Glue, GEN-4 should be mandatory as extensions. |
ADD IEEE: Table 20 — General ICSs table here
1:B.2.3.2 Service Provider
Optional requirements for the service provider side excluding contexts and external control.
ADD IEEE: Service Provider ICS table here
1:B.2.3.3 Service Consumer
CONS-1 is broken; R0115 is not optional in the released document. |
ADD IEEE: Service Consumer ICS table here
1:B.2.3.4 Remote Control
ADD IEEE: Remote Control ICS table here
1:B.2.3.5 Context Processing
Context processing pertains to effective utilization of context information like workflow (e.g., orders) info, patient demographics and locations. A general concept should be described how to cope with contexts in terms of SDPi, i.e., device coupling mechanisms should be described informally in TF-1 and formally in TF-2 (as transaction?). |
ADD IEEE: Context Processing ICS table here
1:B.3 Bibliography
In addition to Referenced Standards, which include normative requirements and capabilities that this technical framework utilizes, there are other standards, specifications, publications, presentations, materials, etc. that have proven valuable in both developing and understanding the framework’s content. This list identifies those items, including many of which are referenced throughout the specifications.
1:B.3.1 Media (non-standards) References
[ISO 81001-1 "The Temple"], ISO/IEC 81001-1 Figure 1 "The Temple" Diagram, Copyright © 2019 NHS Digital, licensed via Wikimedia Commons, Greg Wye, NHS Digital, OGL 3, available at 81001.org Framework.
1:B.3.2 Standards & Publications
[IHE PCD SDPi Use Cases Compendium:2019] IHE Patient Care Devices (PCD) Compendium of Medical Device Oriented Use Cases, Companion to the "Service-oriented Device Point-of-Care Interoperability (SDPi)" White Paper, Revision 1.1, November 1, 2019. Available at profiles.ihe.net/DEV/.
[IHE PCD SDPi White Paper:2019] IHE Patient Care Devices (PCD) Service-oriented Device Point-of-Care Interoperability (SDPi) White Paper, Revision 1.1, November 1, 2019. Available at profiles.ihe.net/DEV/.
[ISO/IEC 14977:1996] ISO/IEC 14977, Information technology - Syntactic metalanguage - Extended BNF, 15 December 1996, available at https://standards.iso.org/ittf/PubliclyAvailableStandards/s026153_ISO_IEC_14977_1996(E).zip
[OMG SysML <sup>®</sup> Intro-Graphical Notation 2.0] OMG Systems Modeling Language™ (SysML®), Version 2.0, Introduction to the Graphical Model, Object Management Group (OMG) standard. Available at github.com/Systems-Modeling/SysML-v2-Release/doc/
[OMG SysML <sup>®</sup> 2.0] OMG Systems Modeling Language ™ (SysML®), Version 2.0, Object Management Group (OMG) specification. Available at github.com/Systems-Modeling/SysML-v2-Release/doc/
[HL7-GENDER] HL7 gender harmony project, available at https://confluence.hl7.org/display/VOC/The+Gender+Harmony+Project
1:B.3.3 Presentations
[IHE EU Experience-2021 IHE CA for MedTech Solutions], "IHE & IHE Catalyst: Advancing Interoperable MedTec Solutions with "Regulatory Submission Ready" Conformity Assessment", presentation by Todd Cooper and Dr. Stefan Schlichting, available at IHE Europe Experience 2021 Presentations web page.
Appendix 1:C Device Point-of-care Interoperability (DPI) Use Cases
1:C.1 General Overview of DPI Use Cases & Analysis
SDPi 1.4 Supplement Note: This initial section of Appendix C is informative and is still being detailed. Completion is deferred to version 1.x or later. It provides general background detail around how general (non-technology specific) clinical use case specifications are being utilized in this supplement. REVIEWER QUESTION: Please review the intended topics and identify any additional content that should be considered. Especially helpful would be references to related standards and materials that would inform the approach taken in this appendix. |
1:C.1.1 Rich History of Medical Device Interoperability (MDI) Use Cases
The vision of plug-and-play medical device interoperability has been an active pursuit since the early 1980’s, with the IEEE 1073 group’s formation in those early years. Over the 40+ years, many projects — both industry and standards-based — have contributed to an ever growing set of real-world use cases, and the ISO/IEEE 11073 SDC program is no different.
Looking to leverage this wealth of use cases in considering SDPi, a "compendium of medical device oriented use cases" was created to facilitate referencing and use. The use cases detailed in this appendix build on those that are captured in this document: [IHE PCD SDPi Use Cases Compendium:2019]
1:C.1.2 Overview of Architectural & Business Systems Concepts
SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:C.1.3 Use Case Specification Conventions Using Cucumber/Gherkin
SDPi 1.4 Supplement Note: This section contains initial content that will be greatly expanded in future versions. |
Each Use Case (also called a Feature in Gherkin) is organized as follows:
Narrative – a description of the desired functionality from the user perspective
Technical View - graphic representation of typical business system actors utilized in this use case
Technical Pre-Conditions – any assumptions or pre-conditions
Scenario(s) – the scenarios explore both the Happy Path when everything goes according to plan and the Alternative Paths where things do not go according to plan.
1:C.1.4 Use Case Requirements Modeling
SDPi 1.4 Supplement Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:C.1.5 Application of ISO/IEC 60601-1-8 Concepts & Definitions
1:C.1.5.1 ISO/IEC 60601-1-8 Concepts for DIS, DAS and CDAS
The following is a quick guide to the functionality of DIS, CDIS, DAS and CDAS systems and how we have used and interpreted them for the purpose of this IHE Profile Supplement. Please refer to the next section on Definitions from [IEC 60601-1-8:2020] for normative definitions for these terms.
Note that the 1.4 version of the SDPi Profile only supports the Distributed Information System (DIS) model detailed below. The other models are anticipated for subsequent versions. |
1:C.1.5.1.1 DIS – Distributed Information System
DIS is a system for reporting alarm signals with no technical confirmation (of receipt).
Cannot rely on it for alarm signaling as a risk control
Optional support operator alarm management response locally
Example — patient remote display, hallway display, one-way pager
1:C.1.5.1.2 CDIS – Distributed Information System with Confirmation
CDIS is a system for reporting alarm signals with no technical confirmation but with operator confirmation (accept/reject).
CDIS is not recognized in 60601-1-8, however it is implemented in practice and therefore included |
Cannot rely on it for alarm signaling as a risk control
Optional support operator alarm management response locally and remotely
Example –- two-way pager (open loop)
1:C.1.5.1.3 DAS – Distributed Alarm System
DAS is a system for reporting alarm signals with technical confirmation (of receipt).
Can rely on it for alarm signaling as a risk control
Optionally supports local alarm management (alarm acknowledgement)
A communications failure or failure in any remote component of the DAS must initiate a technical alarm.
Example — Central Station
1:C.1.5.1.4 CDAS - Distributed Alarm System with Confirmation
CDAS is a system for reporting alarm signals with technical and operator confirmation (accept/reject) (of receipt).
Can rely on it for alarm signaling as a risk control
Supports operator confirmation (accept/reject); It may redirect…
Optionally support local/remote alarm management (acknowledgement)
A communications failure or failure in any remote component of the DAS must initiate a technical alarm.
Example — System that sends alarm to caregiver mobile device with accept / reject. Integrator may redirect
An xDIS can be either a DIS or CDIS. Similarly an xDAS can be either a DAS or CDAS. |
Description | Type | Technical Delivery Confirmation1 | Operator Delivery Confirmation2 | Optional Alarm Management | Examples |
---|---|---|---|---|---|
Reports alerts from a single patient (sp) |
DISsp |
No |
No |
Local |
Single-Pt. information Dashboard |
CDISsp |
No |
Yes3 |
Remote3 |
Single-Pt. Remote View w/accept/reject |
|
DASsp |
Yes |
No |
Local |
Single-Pt. Cockpit w/audible alarms |
|
CDASsp |
Yes |
Yes |
Remote |
Single-Pt. Cockpit w/accept/reject |
|
Reports alerts from multiple patients (mp) |
DISmp |
No |
No |
Local |
Multiple-Pt. information Dashboard or View Station |
CDISmp |
No |
Yes3 |
Remote3 |
Multiple-Pt. info. View Station w/accept/reject |
|
DASmp |
Yes |
No |
Local |
Multiple-Pt. Central Station w/audible alarms |
|
CDASmp |
Yes |
Yes |
Remote |
Multiple-Pt. Central Station w/accept/reject |
|
Reports and directs alerts to responsible caregiver (cg) |
DIScg |
No |
No |
Local |
Alerts to caregiver pager, Mobile viewer |
CDIScg |
No |
Yes3 |
Remote3 |
Alerts to caregiver pager, w/accept/reject |
|
DAScg |
Yes |
No |
Local |
Alerts to caregiver w/audible/haptic signals |
|
CDAScg |
Yes |
Yes |
Remote |
Alerts to caregiver w/accept/reject |
|
1 In each communication step the receiving device provides a technical response to the sending device that it received and is taking responsibility for the alert 2 Operator can, at their choice, use the receiving device (communicator) UI to accept or reject responsibility for the alert 3 Not recommended since there is no confirmation that the Source has received the commands |
1:C.1.5.2 ISO/IEC 60601-1-8 Definitions for DIS, DAS and CDAS
The following content is extracted directly from the [IEC 60601-1-8:2020] standard for reference purposes. Please consult that standard for comprehensive discussion and complete normative requirements, as well as the "rationale" section, which includes many of the concepts identified in this section.
1:C.1.5.2.1 DIS - DISTRIBUTED INFORMATION SYSTEM ABOUT ALARM CONDITIONS
system that involves more than one item of equipment in a ME SYSTEM intended to provide information about ALARM CONDITIONS but does not guarantee delivery of that information
NOTE 1: A DISTRIBUTED INFORMATION SYSTEM ABOUT ALARM CONDITIONS is not intended to notify OPERATORS of the existence of an ALARM CONDITION as a RISK CONTROL measure. A DISTRIBUTED INFORMATION SYSTEM ABOUT ALARM CONDITIONS is intended to provide information about an ALARM CONDITION while the OPERATOR is aware of the existence of the ALARM CONDITION by an ALARM SYSTEM. |
NOTE 2: A DISTRIBUTED INFORMATION SYSTEM ABOUT ALARM CONDITIONS is not intended for confirmed delivery of ALARM CONDITIONS |
Examples include:
Sometimes referred to as secondary alerting devices: Hallway display of active alarms; Hallway light over room door; Caregiver worn device;
1:C.1.5.2.2 DAS - DISTRIBUTED ALARM SYSTEM
ALARM SYSTEM that involves more than one item of equipment in a ME SYSTEM intended for delivery of ALARM CONDITIONS with technical confirmation
NOTE 1: The parts of a DISTRIBUTED ALARM SYSTEM can be widely separated in distance. |
NOTE 2: A DISTRIBUTED ALARM SYSTEM is intended to notify OPERATORS of the existence of an ALARM CONDITION. |
NOTE 3: For the purposes of this document, technical confirmation means that each element of a DISTRIBUTED ALARM SYSTEM confirms or guarantees the successful delivery of the ALARM CONDITION to the next element or appropriate TECHNICAL ALARM CONDITIONS are created as described in clause 6.11.2.2.1 of [IEC 60601-1-8:2020]. |
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.
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:
symbol ISO 7000-6334A (2015-06) (see Symbol 13 of Table C.1) for RESPONSIBILITY ACCEPTED; or
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
1:C.2.4 Technical Pre-Conditions
Given All devices communicate using a common MD LAN protocol
And A Time Source (TS) Service is on the MD LAN network
1:C.2.5 Scenarios
1:C.2.5.1 Scenario: STAD 1.1 - Device is connected to the MD LAN network with a Time Source service
Given Device has detected at least one TS Service
When The TS Service is operational
Then The device will synchronize its time with the TS Service
1:C.2.5.1.1 Safety, Effectiveness and Security - Requirements and Considerations
1:C.2.5.2 Scenario: STAD 1.2 - Device is connected to the MD LAN network and a user wants to change the device’s time
Given Device is operational in MD LAN network
When The user attempts to change the time on the device manually
Then The device will disable the ability to change its time manually
1:C.2.5.2.1 Safety, Effectiveness and Security - Requirements and Considerations
1:C.2.5.3 Scenario: STAD 1.3 - Device is connected to the MD LAN network and cannot connect to a TS Service
Given Device has just connected to the MD LAN network and has not detected any TS Services
When The TS Service is not operational or inaccessible
Then The device will not participate on the MD LAN network until it detects and connects to a TS Service
1:C.2.5.3.1 Safety, Effectiveness and Security - Requirements and Considerations
1:C.2.5.4 Scenario: STAD 1.4 - Devices are operational in the MD LAN network but cannot access the TS Service
Given Device is operational on the MD LAN network
When The TS Service is no longer operational or otherwise inaccessible
Then The device will rely on its internal clock for time synchronization
And The device will provide the accuracy of its clock in its MDIB
And The device will periodically attempt to reconnect to the TS Service
And The device will notify the user about the fact, that the TS Service cannot be reached
And The device will create a log entry noting the disconnection from the TS Service
And The ability to change the device time manually will remain disabled
Device internal clocks are usually accurate enough to bridge short periods of time when no time-servers are accessible. Manual time synchronization is considered too inaccurate for SDC System Functionality. |
By using the device’s clock accuracy, a consumer can decide if received data is accurate enough for its use case. This may cause the consumer to disconnect from the device. |
A Manufacturer may decide to limit user notification of technical issues to certain user groups (e.g., biomed). |
1:C.2.5.4.1 Safety, Effectiveness and Security - Requirements and Considerations
REVIEWER QUESTION:Do we need a requirement, for notifying the biomed in case the TS Service is no longer reachable? Or is the following logging requirement sufficient?
REVIEWER QUESTION:Do we need a requirement stating this explicitly, or is BPKP TR0916 sufficient, since a TS Service not being available can be considered as a change in the TS Service.
1:C.2.5.5 Scenario: STAD 1.5 - Devices are operational in the MD LAN network but cannot access the TS Service and clock drift is unacceptable
Given The SOMDS Consumer is operational on the MD LAN network
And The TS Service is no longer operational or otherwise inaccessible
When The clock drift of the device internal clock exceeds an internal threshold
Or The timestamps of the received data are no longer accurate enough
Then The device will notify the user that time synchronization is no longer functional, which will limit the availability of SDC System Functionality
And The device will create a log entry noting inaccurate time synchronization
And The device will periodically attempt to reconnect to the MD LAN and TS Service
And Based on a Manufacturer's risk management, the device may be disconnected entirely from the MD LAN network.
It is the SOMDS Consumer's responsibility to decide if timestamps are accurate enough to execute its System Function Contribution (SFC). |
1:C.2.5.5.1 Safety, Effectiveness and Security - Requirements and Considerations
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
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.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
1:C.4.4 Technical Pre-Conditions
Given All devices communicate using a common MD LAN protocol
And At least one ICU Dashboard display
And Devices from specific ICU rooms have been assigned to the Dashboard
1:C.4.5 Scenarios
1:C.4.5.1 Scenario: SICDmp 3.1 - ICU Devices are Accessible to the Dashboard
Given Dashboard has detected at least one assigned accessible ICU device
When the ICU Devices are communicating on the MD LAN
Then the Dashboard will display parameter, waveform, setting, alarm, imaging, etc. information from those devices (based on configuration)
1:C.4.5.2 Scenario: SICDmp 3.2 - ICU Devices are Inaccessible to the Dashboard
Given Dashboard cannot detect any assigned accessible ICU devices
Then the Dashboard will display an error message
1:C.4.5.3 Scenario: SICDmp 3.3 - One or more ICU Devices are Inaccessible to the Dashboard
Given Dashboard cannot detect any previously assigned accessible ICU devices
Then the Dashboard will display an error message
1:C.5 Use Case Feature 4: Device Data to Enterprise Systems (DDES)
1:C.5.1 Narrative
Mercy Hospital is in the middle of a new EHR (Epic, Cerner, etc.) rollout. Joe Furst is responsible for integrating data from their ICU devices (patient monitors, ventilators, infusion devices, etc.) with the new EHR. Once they are done, the data from the devices will be reviewed/validated by the ICU clinicians and then automatically entered into the patient’s clinical record.
1:C.5.2 Benefits
Automatically feeding patient data from the medical devices to medical record applications reduces the documentation burden on the clinicians, improves the accuracy of the medical record and enables 'real-time' analysis of the data which can be used to generate (potentially AI based) smart alerts to the clinical staff.
1:C.5.3 Technical View
1:C.5.4 Technical Pre-Conditions
Given All devices communicate using a common MD LAN protocol
And All devices report either a device label and/or location
And A DGW Service is associated with a specific set of device labels, and/or location(s) (i.e., devices in scope)
1:C.5.5 Scenarios
1:C.5.5.1 Scenario: DDES 4.1 - New in scope device is connected to network with DGW service
Given The DGW Service has detected a new in scope device
When The DGW Service is operational
Then The DGW Service will connect to the device and export data to the EHR using the HL7 v2 based IHE DEV DOR actor of the DEV DEC Profile
1:C.5.5.2 Scenario: DDES 4.2 - Data Gateway Service is connected to the EHR
Given The DGW Service is exporting data to the EHR
Then The DGW Service will comply with all IHE DEV / PCD DEC Profile DOR actor functional and test requirements
1:C.5.5.3 Scenario: DDES 4.3 - Data Gateway Service has a failure
Given The DGW Service was connected to in scope devices and to an Enterprise system and fails
Then The DGW Service will backfill its data store and then backfill to the EHR when it recovers from its failure
1:C.5.5.4 Scenario: DDES 4.4 - Data Gateway Service connection to the Enterprise System fails
Given The Enterprise System stops receiving data from the DGW Service
When There is a communications failure between the DGW Service and the Enterprise System
Then The DGW Service will backfill missed data to the Enterprise System when communications resumes
1:C.6 Use Case Feature 5: Alerts to Clinician Notification Systems (ACNS)
1:C.6.1 Narrative
Bonjour Hospital is in the process of installing a nurse alert notification system which will communicate alerts from the ICU devices (patient monitors, ventilators, infusion devices, etc.) directly to nurse devices such as pagers or smartphones. Bobby Thornton is responsible for integrating data from their ICU devices with the alert notification system. Once they are done, the alerts from the devices will be forwarded by the gateway to the nurse devices for viewing in a timely manner.
1:C.6.2 Benefits
The ability of the system to share alert events directly with the responsible nurse allows that nurse to be aware of issues with the patient without being next to or near the patient. It is also the first step in implementing a Quiet Hospital or Silent Hospital approach where alerts are not signaled at the patient bedside thereby reducing the amount of noise that the patient is subjected to and improving their ability to recuperate.
1:C.6.3 Technical View
1:C.6.4 Technical Pre-Conditions
Given All devices communicate using a common MD LAN protocol
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
1:C.7.4 Technical Pre-Conditions
Given All devices communicate using a common MD LAN protocol
And At least one Alert Gateway (AGW) Service on the MD LAN
And At least one Alert Recording System is connected to the Alert Gateway (AGW) Service
And All devices report either a device label and/or location and/or patient ID
And The AGW Service is associated with a specific set of device labels, and/or location(s)
1:C.7.5 Scenarios
1:C.7.5.1 Scenario: AARS 6.1 - New device is connected to network with AGW service
Given the AGW Service has detected a new device in its scope
When the AGW Service is operational
Then the AGW Service will connect to the device and communicate alerts to the Alert Recording System
1:C.7.5.2 Scenario: AARS 6.2 - The AGW service loses connectivity with the ICU devices
Given the AGW Service no longer communicates with ICU devices in its scope
When There is a communications failure
Then the AGW will notify the Alert Recording System of the failure
Then when the AGW regains communication with the devices it will resume reporting active alerts to the Alert Recording System and attempt to backfill any missing alerts
1:C.7.5.3 Scenario: AARS 6.3 - The AGW service fails
Given the AGW fails
Then the Alert Recording System will detect a loss of communications with the AGW
Then when the AGW Service recovers it will resume reporting active alerts to the Alert Recording System and attempt to backfill any missing alerts
1:C.7.5.4 Scenario: AARS 6.4 - The Alert Recording System loses connectivity with the AGW
Given the Alert Recording System can no longer communicate with the AGW
Then the Alert Recording System will detect a loss of communications with the AGW Service
Then when the AGW Service regains communication with the Alert Recording System it will resume reporting active alerts to the Alert Recording System and backfill any missing alerts.
Volume 2 — Transactions
2:3 Transactions
2:3.23 Announce Network Presence [DEV-23]
2:3.23.1 Scope
Notify all SOMDS Consumers that a SOMDS Provider is connected to the network and ready to exchange messages with other SOMDS Participants.
2:3.23.2 Actor Roles
Actor | Roles |
---|---|
Announces its presence by multicasting Hello messages to all listening systems. |
|
Listens for Hello messages to identify any SOMDS Providers that it may exchange messages with and further retrieve a SOMDS Provider's service capabilities. |
2:3.23.3 Referenced Standards
[ISO/IEEE 11073-10207:2017] Section 9.2 Implicit Discovery
2:3.23.4 Messages
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
whenever a SOMDS Provider joins an MD LAN,
when a SOMDS Provider returns to normal on-line operation after having indicated temporary suspension of message exchanges, or
when a SOMDS Provider changes its Discovery Scope.
2:3.23.4.1.2 Message Semantics
- Provider UID
-
The SOMDS Provider UID.
- Discovery Scope
-
The Discovery Scope of the SOMDS Provider.
2:3.23.4.1.3 Expected Actions
When a SOMDS Provider sends this message, there is no expected or required responses. This is due to the fact that either there are no SOMDS Consumers listening for announcement messages, or the information in the message (e.g., Discovery Type) is not of interest to any receiving SOMDS Consumers.
2:3.23.5 Safety, Effectiveness and Security - Requirements and Considerations
2:3.23.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.
2:3.23.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.23.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.23.5.4 Security Requirements & Considerations
This transaction is intended to execute over UNSECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management is performed in order to ensure that no unintended information is disclosed during UNSECURED message exchange.
2:3.24 Discover Network Topology [DEV-24]
2:3.24.1 Scope
Discover and resolve all available SOMDS Providers that a SOMDS Consumer is potentially interested in.
2:3.24.2 Actor Roles
Actor | Roles |
---|---|
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. |
|
Listens for Probe and Resolve messages, which it responds to with ProbeMatch or ResolveMatch messages, respectively. |
2:3.24.3 Referenced Standards
[ISO/IEEE 11073-10207:2017] Section 9.3 Explicit Discovery
2:3.24.4 Messages
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
whenever a SOMDS Consumer joins an MD LAN and is ready to exchange messages with SOMDS Providers or
when a SOMDS Consumer runs in a mode where it periodically checks for availability of SOMDS Providers matching a specific SOMDS Provider UID.
2:3.24.4.3.2 Message Semantics
- Provider UID
-
The SOMDS Provider UID to resolve.
2:3.24.4.3.3 Expected Actions
When a SOMDS Consumer sends this message, every receiving SOMDS Provider that matches the requested SOMDS Provider UID responds with a ResolveMatch message.
2:3.24.4.4 ResolveMatch Message
The ResolveMatch message is sent as part of the BICEPS explicit discovery protocol in response to an incoming Resolve message.
Note that the ResolveMatch message described in this clause is a generic/abstract concept that can be implemented differently. It should not be confused with actual transport message specifications like, e.g., the WS-Discovery ResolveMatch message as described in Appendix 2:A.2.2.
The ResolveMatch message is a uni-cast message that is sent by a SOMDS Provider when an incoming Resolve message contains a Provider UID that matches the SOMDS Provider's SOMDS Provider UID. Limited but sufficient information is provided with the message to enable SOMDS Consumers to determine a matching SOMDS Provider's Transport Address.
2:3.24.4.4.1 Trigger Events
The ResolveMatch message is sent whenever a SOMDS Provider receives a Resolve message that contains a Provider UID that is equal to the SOMDS Provider's SOMDS Provider UID.
2:3.24.4.4.2 Message Semantics
- Provider UID
-
The SOMDS Provider UID.
- Transport Address
-
The Transport Address under which the SOMDS Provider can receive secured messages.
2:3.24.4.4.3 Expected Actions
The SOMDS Consumer that receives a ResolveMatch message can use the Transport Address to exchange secured messages with the SOMDS Provider from which it received the ResolveMatch message.
2:3.24.5 Safety, Effectiveness and Security - Requirements and Considerations
2:3.24.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.
2:3.24.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.24.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.24.5.4 Security Requirements & Considerations
This transaction is intended to execute over UNSECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management is performed in order to ensure that no unintended information is disclosed during UNSECURED message exchange.
2:3.25 Discover BICEPS Services [DEV-25]
2:3.25.1 Scope
Exchange resources metadata between a SOMDS Provider and a SOMDS Consumer.
2:3.25.2 Actor Roles
Actor | Roles |
---|---|
Asks for the resource representation of the SOMDS Provider via the GetMetadata message. |
|
Sends its resource representation to the SOMDS Consumer via the GetMetadataResponse message. |
2:3.25.3 Referenced Standards
[ISO/IEEE 11073-10207:2017] Section 9 Discovery Model
[ISO/IEEE 11073-10207:2017] Section 7.3 Service Model
2:3.25.4 Messages
2:3.25.4.1 GetMetadata Message
The GetMetadata message is used by a SOMDS Consumer to request the resource representation data of a SOMDS Provider.
2:3.25.4.1.1 Trigger Events
This message is sent when a SOMDS Consumer has discovered a Transport Address for a SOMDS Provider.
2:3.25.4.1.2 Expected Actions
When a SOMDS Consumer sends this message, the GetMetadataResponse message is expected as a response.
2:3.25.4.2 GetMetadataResponse Message
The GetMetadataResponse message is sent in response to an incoming GetMetadata message.
2:3.25.4.2.1 Trigger Events
The GetMetadataResponse message is sent whenever a SOMDS Provider receives a GetMetadata message.
2:3.25.4.2.2 Message Semantics
- BICEPS Services
-
Collection of BICEPS services the SOMDS Provider offers, including but not limited to one or multiple of the following BICEPS services ([ISO/IEEE 11073-10207:2017] Section 7.3 Service Model):
GET SERVICE (mandatory)
SET SERVICE
DESCRIPTION EVENT SERVICE
STATE EVENT SERVICE
CONTEXT SERVICE
WAVEFORM SERVICE
There is currently no mandatory support for provision of the LOCALIZATION SERVICE, CONTAINMENT TREE SERVICE and ARCHIVE SERVICE. |
- Device Metadata
-
Expresses SOMDS Provider characteristics that typically vary from one SOMDS Provider to another of the same kind, for example:
Friendly name
Firmware version
Serial number
- Model Metadata
-
Expresses SOMDS Provider characteristics that are typically fixed across all SOMDS Providers of the same model by their Manufacturer, for example:
Model name
Model number
2:3.25.4.2.3 Expected Actions
When a SOMDS Provider sends this message, there is no expected or required response.
2:3.25.5 Safety, Effectiveness and Security - Requirements and Considerations
2:3.25.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.
2:3.25.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.25.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.25.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.
2:3.27 Manage BICEPS Subscription [DEV-27]
2:3.27.1 Scope
Establish a publish-subscribe session between a SOMDS Provider, acting as the event source, and a SOMDS Consumer, acting as the event sink.
2:3.27.2 Actor Roles
Actor | Roles |
---|---|
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. |
|
Listens for Subscribe, Renew and Unsubscribe messages, which it responds to with SubscribeResponse, RenewResponse or UnsubscribeResponse messages respectively. While a subscription is running, the SOMDS Provider delivers Notification messages. When at some point the subscription has to be ended, the SOMDS Provider sends a SubscriptionEnd message. |
2:3.27.3 Referenced Standards
[ISO/IEEE 11073-10207:2017] Section 7.2.3 Request-Response
[ISO/IEEE 11073-10207:2017] Section 7.2.4 Streaming
[ISO/IEEE 11073-10207:2017] Annex C
2:3.27.4 Messages
Transaction [DEV-27] supports a general Section 2:3.27.4.3 message. Specialized notification messages are detailed in Section 2:3.28 and Section 2:3.29, based on payload content and trigger events. |
2:3.27.4.1 Subscribe Message
The Subscribe message is sent as part of the BICEPS publish-subscribe and streaming message exchange for allowing SOMDS Consumers to subscribe to data changes of SOMDS Providers.
2:3.27.4.1.1 Trigger Events
The Subscribe message is sent whenever a SOMDS Consumer intends to get notified on certain changes of a SOMDS Provider comprising
publish-subscribe message exchange and
stream message exchange.
2:3.27.4.1.2 Message Semantics
- Filter
-
A filter to subscribe to a certain set of data items, including but not limited to one or multiple of the following:
DescriptionModificationReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.5
EpisodicAlertReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.11
EpisodicComponentReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.12
EpisodicContextReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.13
EpisodicMetricReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.14
EpisodicOperationalStateReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.15
OperationInvokedReport as specified in [ISO/IEEE 11073-10207:2017], Annex C.77
WaveformStream as specified in [ISO/IEEE 11073-10207:2017], Annex C.112
- Expiration Time
-
A time requested for subscription expiration.
2:3.27.4.1.3 Expected Actions
When a SOMDS Consumer sends this message, the receiving SOMDS Provider responds with a SubscribeResponse message.
2:3.27.4.2 SubscribeResponse Message
The SubscribeResponse message is sent as part of the BICEPS publish-subscribe and streaming message exchange in response to a Subscribe message to confirm a subscription.
2:3.27.4.2.1 Trigger Events
The SubscribeResponse message is sent whenever a SOMDS Provider receives a Subscribe message.
2:3.27.4.2.2 Message Semantics
- Subscription Manager
-
Dedicated instance that manages the subscription, i.e., allows for a SOMDS Consumer to renew or cancel the subscription.
- Expiration Time
-
Actual expiration time, which does not necessarily equal the requested expiration time.
2:3.27.4.2.3 Expected Actions
The SOMDS Consumer that receives a SubscribeResponse message can use the Subscription Manager to renew the subscription shortly before the Expiration Time exceeds or cancel the subscription if it is no longer interested in updates.
Once received, the SOMDS Consumer listens for Notification messages.
2:3.27.4.3 Notification Message
The Notification message contains updated data and is delivered by a SOMDS Provider to subscribed SOMDS Consumers.
The data items conveyed in Notification messages depend on the Filter that was requested as part of the Subscribe message.
2:3.27.4.3.1 Trigger Events
A Notification message is sent whenever a SOMDS Provider detects a change to its internal representation that is intended to be communicated to SOMDS Consumers. The SOMDS Provider sends a Notification message to a SOMDS Consumer if and only if a matching Filter has been requested by the SOMDS Consumer.
2:3.27.4.3.2 Message Semantics
- Payload
-
Payload specific to the Filter that was subscribed by the SOMDS Consumer that receives the Notification message.
2:3.27.4.3.3 Expected Actions
When a SOMDS Provider sends this message, there is no expected or required responses.
2:3.27.4.4 Renew Message
The Renew message is sent as part of the BICEPS publish-subscribe and streaming message exchange to renew a subscription when it is about to expire.
2:3.27.4.4.1 Trigger Events
The Renew message is sent whenever a subscription is about to expire according to the subscribe response Expiration Time or renew response Expiration Time respectively.
2:3.27.4.4.2 Message Semantics
- Subscription Manager
-
Dedicated instance that manages the subscription, i.e., allows for a SOMDS Consumer to renew or cancel the subscription.
- Expiration Time
-
A new time requested for subscription expiration.
2:3.27.4.4.3 Expected Actions
When a SOMDS Consumer sends this message, the receiving SOMDS Provider responds with a RenewResponse message.
2:3.27.4.5 RenewResponse Message
The RenewResponse message is sent as part of the BICEPS publish-subscribe and streaming message exchange in response to a Renew message to confirm renewal of a subscription.
2:3.27.4.5.1 Trigger Events
The RenewResponse message is sent whenever a SOMDS Provider receives a Renew message.
2:3.27.4.5.2 Message Semantics
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
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
2:3.27.4.8.3 Expected Actions
Once received, the SOMDS Consumer cannot expect any further incoming Notification messages.
2:3.27.5 Safety, Effectiveness and Security - Requirements and Considerations
2:3.27.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.
2:3.27.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.27.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.27.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.
2:3.28 Notify Change in System Context and Capabilities [DEV-28]
2:3.28.1 Scope
Notify a SOMDS Consumer about changes in system context and capabilities of a SOMDS Provider.
2:3.28.2 Actor Roles
Actor | Roles |
---|---|
Listens for a Notification message to retrieve context updates. |
|
While a subscription is running, the SOMDS Provider delivers Notification messages. |
2:3.28.3 Referenced Standards
[ISO/IEEE 11073-10207:2017] Section 7.4 Message Model
2:3.28.4 Messages
Transaction [DEV-28] supports a specialized instance of the general Section 2:3.27.4.3 message, based on payload content and trigger events. |
2:3.28.4.1 Notification Message
The Notification message contains updated context data and is delivered by a SOMDS Provider to subscribed SOMDS Consumers.
2:3.28.4.1.1 Trigger Events
The Notification message is sent whenever a context of a SOMDS Provider is updated and a SOMDS Consumer is subscribed to context reports of a SOMDS Provider.
2:3.28.4.1.2 Message Semantics
2:3.28.4.1.3 Expected Actions
When a SOMDS Provider sends this message, there is no expected action or required responses.
2:3.28.5 Safety, Effectiveness and Security - Requirements and Considerations
2:3.28.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.
2:3.28.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.28.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.28.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.
2:3.29 Publish BICEPS Update Reports [DEV-29]
2:3.29.1 Scope
Notify a SOMDS Consumer about changes in the alert, metric and component reports and in the waveform stream of a SOMDS Provider.
2:3.29.2 Actor Roles
Actor | Roles |
---|---|
Listens for a Notification message to retrieve update reports. |
|
While a subscription is running, the SOMDS Provider delivers Notification messages. |
2:3.29.3 Referenced Standards
[ISO/IEEE 11073-10207:2017] Section 7.4 Message Model
2:3.29.4 Messages
Transaction [DEV-29] supports a specialized instance of the general Section 2:3.27.4.3 message, based on payload content and trigger events. |
2:3.29.4.1 Notification Message
The Notification messages contain updated reports and is delivered by a SOMDS Provider to subscribed SOMDS Consumers.
2:3.29.4.1.1 Trigger Events
The Notification message is sent whenever a report of a SOMDS Provider is updated and a SOMDS Consumer is subscribed to reports of a SOMDS Provider.
2:3.29.4.1.2 Message Semantics
- EpisodicAlertReport
-
A change report that contains updated alert information.
- EpisodicMetricReport
-
A change report that contains updated metric information.
- EpisodicComponentReport
-
A change report that contains updated component information.
- WaveformStream
-
A message to transmit a set of samples of one or more waveforms.
2:3.29.4.1.3 Expected Actions
When a SOMDS Provider sends this message, there is no expected action or required responses.
2:3.29.5 Safety, Effectiveness and Security - Requirements and Considerations
2:3.29.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.
2:3.29.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.29.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.29.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.
2:3.30 Retrieve BICEPS Content [DEV-30]
2:3.30.1 Scope
Retrieve the MDIB of a SOMDS Provider a SOMDS Consumer is interested in.
2:3.30.2 Actor Roles
Actor | Roles |
---|---|
Initiates communication by sending a GetMdib message to a SOMDS Provider. Then listens for a GetMdibResponse message to retrieve the SOMDS Provider's MDIB. |
|
Listens for GetMdib messages, which it responds to with GetMdibResponse messages respectively. |
2:3.30.3 Referenced Standards
[ISO/IEEE 11073-10207:2017] Section 7.3.2 Get Service
2:3.30.4 Messages
2:3.30.4.1 GetMdib Message
The GetMdib message is sent as part of the BICEPS GET SERVICE for allowing SOMDS Consumers to retrieve the description and state of an MDIB from a SOMDS Provider.
2:3.30.4.1.1 Trigger Events
The GetMdib message is sent whenever a SOMDS Consumer wants to retrieve the description and state of an MDIB of a SOMDS Provider.
2:3.30.4.1.2 Message Semantics
The GetMdib message does not contain any further semantics.
2:3.30.4.1.3 Expected Actions
When a SOMDS Consumer sends this message, the receiving SOMDS Provider responds with a GetMdibResponse message.
2:3.30.4.2 GetMdibResponse Message
The GetMdibResponse message is sent as part of the BICEPS GET SERVICE in response to an incoming GetMdib message.
2:3.30.4.2.1 Trigger Events
The GetMdibResponse message is sent whenever a SOMDS Provider receives a GetMdib message.
2:3.30.4.2.2 Message Semantics
- MdDescription
-
The descriptive part of an MDIB.
- MdState
-
The state part of an MDIB. (As the communication is encrypted, this can include ContextStates without violating [ISO/IEEE 11073-10207:2017] R0121.)
2:3.30.4.2.3 Expected Actions
When a SOMDS Provider sends this message, there is no expected or required response.
2:3.30.5 Safety, Effectiveness and Security - Requirements and Considerations
2:3.30.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.
2:3.30.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.30.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.30.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.
2:3.34 Announce Network Departure [DEV-34]
2:3.34.1 Scope
Notify all SOMDS Consumers that a SOMDS Provider is leaving the network.
2:3.34.2 Actor Roles
Actor | Roles |
---|---|
Announces its departure by multicasting Bye messages to all listening systems. |
|
Listens for Bye messages to identify any SOMDS Providers that will leave the Medical Device LAN (MD LAN). |
2:3.34.3 Referenced Standards
[ISO/IEEE 11073-10207:2017] Section 9.2 Implicit Discovery
2:3.34.4 Messages
2:3.34.4.1 Bye Message
The Bye message is part of the BICEPS implicit discovery protocol for allowing SOMDS Consumers to receive a notification when a SOMDS Provider is leaving the network.
The Bye is a multicast message that is sent from each SOMDS Provider to all listening SOMDS Consumers (zero to many).
2:3.34.4.1.1 Trigger Events
This message is sent whenever a SOMDS Provider leaves a network.
2:3.34.4.1.2 Message Semantics
- Provider UID
-
The SOMDS Provider UID.
2:3.34.4.1.3 Expected Actions
When a SOMDS Provider sends this message, there is no expected or required response.
2:3.34.5 Safety, Effectiveness and Security - Requirements and Considerations
2:3.34.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.
2:3.34.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.34.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.34.5.4 Security Requirements & Considerations
This transaction is intended to execute over UNSECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management is performed in order to ensure that no unintended information is disclosed during UNSECURED message exchange.
2:3.35 Establish Medical Data Exchange [DEV-35]
2:3.35.1 Scope
Establish the exchange of medical data between a SOMDS Provider and a SOMDS Consumer.
2:3.35.2 Actor Roles
Actor |
Roles |
Initiates communication by first subscribing to a SOMDS Provider by sending a Subscribe message. |
|
Listens for Subscribe messages, which it responds to with SubscribeResponse. |
2:3.35.3 Referenced Standards
[ISO/IEEE 11073-10207:2017] Section 7.2.3 Request-Response
[ISO/IEEE 11073-10207:2017] Section 7.2.4 Streaming
[ISO/IEEE 11073-10207:2017] Annex C
2:3.35.4 Messages
Transaction [DEV-35] syntactically duplicates [DEV-27] (Section 2:3.27) and [DEV-38] (Section 2:3.38). This a deliberate action as [DEV-35] is expected to receive SES constraints in the future which will require exclusive conformity statements. For the sake of brevity this clause does not duplicate the trigger events, message semantics and expected actions. |
2:3.35.5 Safety, Effectiveness and Security - Requirements and Considerations
2:3.35.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.
2:3.35.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.35.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.35.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.
2:3.36 Publish Medical Data [DEV-36]
2:3.36.1 Scope
Publish medical data from a SOMDS Provider to a SOMDS Consumer.
2:3.36.2 Actor Roles
Actor | Roles |
---|---|
Listens for a Notification message to retrieve medical data updates. |
|
While a subscription is running, the SOMDS Provider delivers Notification messages. |
2:3.36.3 Referenced Standards
[ISO/IEEE 11073-10207:2017] Section 7.4 Message Model
2:3.36.4 Messages
Transaction [DEV-36] syntactically duplicates [DEV-29] (Section 2:3.29) and [DEV-39] (Section 2:3.39). This a deliberate action as [DEV-36] is expected to receive SES constraints in the future which will require exclusive conformity statements. For the sake of brevity this clause does not duplicate the trigger events, message semantics and expected actions. |
2:3.36.5 Safety, Effectiveness and Security - Requirements and Considerations
2:3.36.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.
2:3.36.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.36.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.36.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.
2:3.37 Retrieve Medical Data [DEV-37]
2:3.37.1 Scope
Retrieve medical data from a SOMDS Provider.
2:3.37.2 Actor Roles
Actor | Roles |
---|---|
Initiates communication by sending a GetMdib message to a SOMDS Provider. Then listens for a GetMdibResponse message to retrieve the SOMDS Provider's MDIB. |
|
Listens for GetMdib messages, which it responds to with GetMdibResponse messages respectively. |
2:3.37.3 Referenced Standards
[ISO/IEEE 11073-10207:2017] Section 7.3.2 Get Service
2:3.37.4 Messages
Note that there is no particular get operation for retrieving medical alert status information. Thus, the generic GetMdib/GetMdibResponse mechanisms are described here.
Transaction [DEV-37] syntactically duplicates [DEV-30] (Section 2:3.30). This a deliberate action as [DEV-37] is expected to receive SES constraints in the future which will require exclusive conformity statements. For the sake of brevity this clause does not duplicate the trigger events, message semantics and expected actions. |
2:3.37.5 Safety, Effectiveness and Security - Requirements and Considerations
2:3.37.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.
2:3.37.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.37.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.37.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.
2:3.38 Establish Medical Alert Exchange [DEV-38]
2:3.38.1 Scope
Establish the exchange of medical alerts from a SOMDS Provider to a SOMDS Consumer.
2:3.38.2 Actor Roles
Actor |
Roles |
Initiates communication by first subscribing to a SOMDS Provider by sending a Subscribe message. |
|
Listens for Subscribe messages, which it responds to with SubscribeResponse. |
2:3.38.3 Referenced Standards
[ISO/IEEE 11073-10207:2017] Section 7.2.3 Request-Response
[ISO/IEEE 11073-10207:2017] Section 7.2.4 Streaming
[ISO/IEEE 11073-10207:2017] Annex C
2:3.38.4 Messages
Transaction [DEV-38] syntactically duplicates [DEV-27] (Section 2:3.27) and [DEV-35] (Section 2:3.35). This a deliberate action as [DEV-38] is expected to receive SES constraints in the future which will require exclusive conformity statements. For the sake of brevity this clause does not duplicate the trigger events, message semantics and expected actions. |
2:3.38.5 Safety, Effectiveness and Security - Requirements and Considerations
2:3.38.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.
2:3.38.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.38.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.38.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.
2:3.39 Publish Medical Alert Update [DEV-39]
2:3.39.1 Scope
Notify a SOMDS Consumer about changes in the medical alert status of a SOMDS Provider.
2:3.39.2 Actor Roles
Actor | Roles |
---|---|
Listens for a Notification message to retrieve medical alert updates. |
|
While a subscription is running, the SOMDS Provider delivers Notification messages. |
2:3.39.3 Referenced Standards
[ISO/IEEE 11073-10207:2017] Section 7.4 Message Model
2:3.39.4 Messages
2:3.39.5 Safety, Effectiveness and Security - Requirements and Considerations
2:3.39.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.
2:3.39.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.39.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.39.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.
2:3.40 Retrieve Medical Alert Status [DEV-40]
2:3.40.1 Scope
Retrieve the medical alert status of a SOMDS Provider.
2:3.40.2 Actor Roles
Actor | Roles |
---|---|
Initiates communication by sending a GetMdib message to a SOMDS Provider. Then listens for a GetMdibResponse message to retrieve the SOMDS Provider's MDIB. |
|
Listens for GetMdib messages, which it responds to with GetMdibResponse messages respectively. |
2:3.40.3 Referenced Standards
[ISO/IEEE 11073-10207:2017] Section 7.3.2 Get Service
2:3.40.4 Messages
Note that there is no particular get operation for retrieving medical alert status information. Thus, the generic GetMdib/GetMdibResponse mechanisms are described here.
Transaction [DEV-40] syntactically duplicates [DEV-30] (Section 2:3.30) and [DEV-37] (Section 2:3.37). This a deliberate action as [DEV-40] is expected to receive SES constraints in the future which will require exclusive conformity statements. For the sake of brevity this clause does not duplicate the trigger events, message semantics and expected actions. |
2:3.40.5 Safety, Effectiveness and Security - Requirements and Considerations
2:3.40.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.
2:3.40.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.40.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.40.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.
2:3.46 Update Network Presence [DEV-46]
2:3.46.1 Scope
Provide network presence and absence of SOMDS Provider Actors in a SOMDS network by updating the metadata in a Discovery Proxy Actor.
2:3.46.2 Actor Roles
Actor | Roles |
---|---|
Listens for Hello or Bye messages to add or remove SOMDS Provider endpoint metadata to/from its internal database. |
|
When joining a SOMDS, it announces its presence to the Discovery Proxy. When deliberately leaving the SOMDS, it announces its absence to the Discovery Proxy. |
2:3.46.3 Referenced Standards
[ISO/IEEE 11073-10207:2017] Section 9. Discovery Model
2:3.46.4 Messages
2:3.46.4.1 Hello Message
BICEPS specifies an implicit discovery protocol for allowing SOMDS Consumers to receive a notification when a SOMDS Provider is ready to exchange messages with other SOMDS Consumers. If a SOMDS Provider uses a Discovery Proxy, network presence is announced to the Discovery Proxy by using the Hello message of this transaction.
2:3.46.4.1.1 Trigger Events
If a Discovery Proxy is known to the SOMDS Provider, this message is sent
whenever a SOMDS Provider joins an MD LAN,
when a SOMDS Provider returns to normal on-line operation after having indicated temporary suspension of message exchanges, or
when a SOMDS Provider changes its Discovery Scope.
2:3.46.4.1.2 Message Semantics
- Provider UID
-
The SOMDS Provider UID.
- Discovery Scope
-
The Discovery Scope of the SOMDS Provider.
2:3.46.4.1.3 Expected Actions
When a SOMDS Provider sends this message, there is no expected or required response. The Discovery Proxy is supposed to internally store the SOMDS Provider's endpoint Provider UID and Discovery Scope in order to make it available to SOMDS Consumers via DEV-47 Retrieve Network Presence (see Section 2:3.47).
2:3.46.4.2 Bye Message
If a SOMDS Provider uses a Discovery Proxy, network absence is announced to the Discovery Proxy by using the Bye message of this transaction.
2:3.46.4.2.1 Trigger Events
If a Discovery Proxy is known to the SOMDS Provider, this message is sent whenever a SOMDS Provider leaves the MD LAN it previously joined via the Hello message.
2:3.46.4.2.2 Message Semantics
- Provider UID
-
The SOMDS Provider UID.
2:3.46.4.2.3 Expected Actions
When a SOMDS Provider sends this message, there is no expected or required response. The Discovery Proxy is supposed to remove the SOMDS Provider's Provider UID and Discovery Scope from its internal database and exposes the removal to SOMDS Consumers via DEV-47 Retrieve Network Presence (see Section 2:3.47).
2:3.46.5 Safety, Effectiveness and Security - Requirements and Considerations
2:3.46.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.
2:3.46.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.46.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.46.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.
2:3.47 Retrieve Network Presence [DEV-47]
2:3.47.1 Scope
Retrieve presence metadata from a Discovery Proxy Actor for a specified set of SOMDS Provider Actors that may be connected to a SOMDS network.
2:3.47.2 Actor Roles
Actor | Roles |
---|---|
Forwards Hello and Bye messages received from SOMDS Providers. Responds to incoming Probe and Resolve messages. |
|
Uses Probe and Resolve messages to seek endpoint metadata. Optionally subscribes to a Discovery Proxy in order to receive Hello and Bye messages. |
2:3.47.3 Referenced Standards
[ISO/IEEE 11073-10207:2017] Section 9. Discovery Model
2:3.47.4 Messages
2:3.47.4.1 Hello Message
BICEPS specifies an implicit discovery protocol for allowing SOMDS Consumers to receive a notification when a SOMDS Provider is ready to exchange messages with other SOMDS Consumers. If a SOMDS Consumer uses a Discovery Proxy, network presence is announced to the SOMDS Consumer by using the Hello message of this transaction.
2:3.47.4.1.1 Trigger Events
If a Discovery Proxy is known to the SOMDS Consumer and the SOMDS Consumer is interested in Hello messages, this message is sent
whenever a SOMDS Provider known to the Discovery Proxy joins an MD LAN,
when a SOMDS Provider known to the Discovery Proxy returns to normal on-line operation after having indicated temporary suspension of message exchanges, or
when a SOMDS Provider known to the Discovery Proxy changes its Discovery Scope.
2:3.47.4.1.2 Message Semantics
- Provider UID
-
The SOMDS Provider UID.
- Discovery Scope
-
The Discovery Scope of the SOMDS Provider.
2:3.47.4.1.3 Expected Actions
When a Discovery Proxy sends this message, there is no expected or required response.
2:3.47.4.2 Bye Message
If a SOMDS Consumer uses a Discovery Proxy, network absence is announced to the SOMDS Consumer by using the Bye message of this transaction.
2:3.47.4.2.1 Trigger Events
If a Discovery Proxy is known to the SOMDS Consumer and the SOMDS Consumer is interested in Bye messages, this message is sent whenever a SOMDS Provider leaves the MD LAN it previously joined via the Hello message.
2:3.47.4.2.2 Message Semantics
- Provider UID
-
The SOMDS Provider UID.
2:3.47.4.2.3 Expected Actions
When a Discovery Proxy sends this message, there is no expected or required response.
2:3.47.4.3 Probe Message
BICEPS specifies an explicit discovery protocol for allowing SOMDS Consumers to discover all SOMDS Providers that are ready to exchange messages with SOMDS Consumers. The corresponding message to seek SOMDS Providers based on filter criteria is called Probe.
If a SOMDS Consumer uses a Discovery Proxy, the SOMDS Consumer can send a Probe message to the Discovery Proxy to seek endpoint information based on filter criteria.
2:3.47.4.3.1 Trigger Events
The Probe message is sent to a Discovery Proxy
whenever a SOMDS Consumer joins an MD LAN and is ready to exchange messages with SOMDS Providers or
when a SOMDS Consumer runs in a mode where it periodically checks for availability of SOMDS Providers matching specific filter criteria.
2:3.47.4.3.2 Message Semantics
- Discovery Scope
-
A Discovery Scope to filter against.
2:3.47.4.3.3 Expected Actions
When a SOMDS Consumer sends this message, the Discovery Proxy answers with all endpoint records that match the requested Discovery Scope by sending a ProbeMatch message.
2:3.47.4.4 ProbeMatch Message
The ProbeMatch message is sent as part of the BICEPS explicit discovery protocol in response to an incoming Probe message.
2:3.47.4.4.1 Trigger Events
The ProbeMatch message is sent whenever a Discovery Proxy receives a Probe message that contains a Discovery Scope that matches zero or more SOMDS Provider's Discovery Scopes.
2:3.47.4.4.2 Message Semantics
- Provider UID
-
The SOMDS Provider UID.
- Transport Address
-
The Transport Address under which the SOMDS Provider can receive secured messages.
2:3.47.4.4.3 Expected Actions
The SOMDS Consumer that receives a ProbeMatch message can use the Transport Address to exchange secured messages with the SOMDS Providers for which it received the ProbeMatch message.
2:3.47.4.5 Resolve Message
BICEPS specifies an explicit discovery protocol for allowing SOMDS Consumers to discover all SOMDS Providers that are ready to exchange messages with SOMDS Consumers. The corresponding message to seek SOMDS Providers based on a unique identifier is called Resolve.
If a specific SOMDS Provider UID is known to a SOMDS Consumer, the SOMDS Consumer can send a Resolve message to a Discovery Proxy.
2:3.47.4.5.1 Trigger Events
The Resolve message is sent to a Discovery Proxy
whenever a SOMDS Consumer joins an MD LAN and is ready to exchange messages with a specific SOMDS Provider for which it knows its SOMDS Provider UID or
when a SOMDS Consumer runs in a mode where it periodically checks for availability of SOMDS Providers matching a specific SOMDS Provider UID.
2:3.47.4.5.2 Message Semantics
- Provider UID
-
The SOMDS Provider UID to resolve.
2:3.47.4.5.3 Expected Actions
When a SOMDS Consumer sends this message, the Discovery Proxy answers with the endpoint record that matches the requested Provider UID.
2:3.47.4.6 ResolveMatch Message
The ResolveMatch message is sent as part of the BICEPS explicit discovery protocol in response to an incoming Resolve message.
2:3.47.4.6.1 Trigger Events
The ResolveMatch message is sent whenever a Discovery Proxy receives a Resolve message.
2:3.47.4.6.2 Message Semantics
- Provider UID
-
The SOMDS Provider UID.
- Transport Address
-
The Transport Address under which the SOMDS Provider can receive secured messages.
A ResolveMatch message may not include a Provider UID and Transport Address if there was no match found for Provider UID. |
2:3.47.4.6.3 Expected Actions
The SOMDS Consumer that receives a ResolveMatch message can use the Transport Address to exchange secured messages with the SOMDS Provider for which it received the ResolveMatch message.
2:3.47.5 Safety, Effectiveness and Security - Requirements and Considerations
2:3.47.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Safety, Effectiveness and Security - Requirements and Considerations.
2:3.47.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.47.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.47.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management is performed in order to ensure that no unacceptable harm results during SECURED message exchange.
Appendix 2:A ISO/IEEE 11073 SDC / MDPWS Message Specifications (Normative)
Message outlines do not contain information regarding required/optional elements/attributes nor cardinalities. In order to produce valid messages, the implementation of a SOMDS Participant needs to conform to the referenced standards of which the message outlines herein were generated. |
2:A.1 Service Mapping
MDPWS is based on DPWS which in turn leverages a profiled SOAP-based Web Services protocol stack to establish a service-oriented system of devices (SOMDS).
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 |
2:A.2 Message Mapping
2:A.2.1 MDPWS: Announce Network Presence [DEV-23]
This section specifies the MDPWS data transmission for messages defined in Section 2:3.23.
2:A.2.1.1 Hello Message
The Hello message is encoded by using WS-Discovery Hello.
2:A.2.1.1.1 Referenced Standards
[ISO/IEEE 11073-20702:2016] mdpws:MedicalDevice
[ISO/IEEE 11073-20701:2018] sdc.mds.pkp:1.2.840.10004.20701.1.1
2:A.2.1.1.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<s12:Header>
<wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Hello</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
<wsd:AppSequence InstanceId="..." MessageNumber="..."/>
</s12:Header>
<s12:Body>
<wsd:Hello>
<wsa:EndpointReference>
<wsa:Address><!-- ... --></wsa:Address>
</wsa:EndpointReference>
<wsd:Types>dpws:Device mdpws:MedicalDevice</wsd:Types>
<wsd:Scopes>sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
<wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
</wsd:Hello>
</s12:Body>
</s12:Envelope>
2:A.2.1.1.3 Message Semantics
-
s12:Envelope/s12:Body/wsd:Hello/wsa:EndpointReference/wsa:Address
-
The SOMDS Provider's Provider UID as URI.
-
s12:Envelope/s12:Body/wsd:Hello/wsd:Scopes
-
The SOMDS Provider's Discovery Scope as a list of URIs.
2:A.2.1.1.4 Trigger Events
The abstracted trigger events as listed in Section 2:3.23.4.1.1 are specialized as follows:
This message is sent
when a SOMDS Provider is assigned an IP address after having joined the network,
when a SOMDS Provider is reassigned an IP address, or
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).
2:A.2.1.1.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.23.4.1.
2:A.2.1.1.6 Additional Consideration
2:A.2.1.1.6.1 Recurring Hello
In addition to the Hello message trigger events defined in Appendix 2:A.2.1.1.4, recurring Hello messages are needed to decrease the likelihood of missed discovery messages in case of network topology changes during operation, e.g., when operational networks are extended by plugging switches (together) at runtime.
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.
2:A.2.2 MDPWS: Discovery Network Topology [DEV-24]
This section specifies the MDPWS data transmission for messages defined in Section 2:3.24.
2:A.2.2.1 Probe Message
The Probe message is encoded by using WS-Discovery Probe.
2:A.2.2.1.1 Referenced Standards
[ISO/IEEE 11073-20702:2016] mdpws:MedicalDevice
[ISO/IEEE 11073-20701:2018] sdc.mds.pkp:1.2.840.10004.20701.1.1
2:A.2.2.1.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<s12:Header>
<wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Probe</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
</s12:Header>
<s12:Body>
<wsd:Probe>
<wsd:Types>mdpws:MedicalDevice</wsd:Types>
<wsd:Scopes MatchBy="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/rfc3986">sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
</wsd:Probe>
</s12:Body>
</s12:Envelope>
2:A.2.2.1.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.24.4.1.
2:A.2.2.1.4 Message Semantics
-
s12:Envelope/s12:Body/wsd:Probe/wsa:Types
-
List that contains at least
mdpws:MedicalDevice
to express seeking SOMDS Providers that conform to MDPWS. -
s12:Envelope/s12:Body/wsd:Probe/wsd:Scopes/@MatchBy
-
The algorithm used to compare the
s12:Envelope/s12:Body/wsd:Probe/wsd:Scopes
against the SOMDS Provider's scopes. -
s12:Envelope/s12:Body/wsd:Probe/wsd:Scopes
-
The Discovery Scope as a list of URIs to probe for.
2:A.2.2.1.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.24.4.2.
2:A.2.2.1.6 Additional Consideration
2:A.2.2.1.6.1 Recurring Probe
While the number of Hello messages scales linearly with the number of SOMDS Providers, in the worst case the number of Probe / ProbeMatch messages is the product of the number of SOMDS Providers and the number of SOMDS Consumers. Therefore, in order to prevent the network congestion from Probe / ProbeMatch messages, the following requirements are defined:
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
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
[ISO/IEEE 11073-20702:2016] mdpws:MedicalDevice
[ISO/IEEE 11073-20701:2018] sdc.mds.pkp:1.2.840.10004.20701.1.1
2:A.2.2.2.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<s12:Header>
<wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ProbeMatches</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
<wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>
<wsd:AppSequence InstanceId="..." MessageNumber="..."/>
</s12:Header>
<s12:Body>
<wsd:ProbeMatches>
<wsd:ProbeMatch>
<wsa:EndpointReference>
<wsa:Address><!-- ... --></wsa:Address>
</wsa:EndpointReference>
<wsd:Types>dpws:Device mdpws:MedicalDevice <!-- ... --></wsd:Types>
<wsd:Scopes>sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
<wsd:XAddrs><!-- ... --></wsd:XAddrs>
<wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
</wsd:ProbeMatch>
</wsd:ProbeMatches>
</s12:Body>
</s12:Envelope>
2:A.2.2.2.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.24.4.2.
2:A.2.2.2.4 Message Semantics
-
s12:Envelope/s12:Body/wsd:ProbeMatches
-
In cases where multiple SOMDS Providers are running on a single machine,
wsd:ProbeMatches
can contain multiplewsd:ProbeMatch
results. -
s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsa:EndpointReference/wsa:Address
-
The SOMDS Provider's SOMDS Provider UID encoded as URI.
-
s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsd:Types
-
List of types that contains at least
dpws:Device
and mdpws:MedicalDevice`, which expresses the SOMDS Provider to conform to DPWS and MDPWS. -
s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsd:Scopes
-
The Discovery Scope of the SOMDS Provider, encoded as a list of URIs.
-
s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsd:XAddrs
-
A list of HTTPS addresses under which the SOMDS Provider receives secured messages.
-
s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsd:MetadataVersion
-
A metadata version of the SOMDS Provider. To be ignored as the transmission of the Probe Match message is unsecure.
2:A.2.2.2.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.24.4.2.
2:A.2.2.3 Resolve Message
The Resolve message is encoded by using WS-Discovery Resolve.
2:A.2.2.3.1 Referenced Standards
2:A.2.2.3.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<s12:Header>
<wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Resolve</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
</s12:Header>
<s12:Body>
<wsd:Resolve>
<wsa:EndpointReference>
<wsa:Address><!-- ... --></wsa:Address>
</wsa:EndpointReference>
</wsd:Resolve>
</s12:Body>
</s12:Envelope>
2:A.2.2.3.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.24.4.3.
2:A.2.2.3.4 Message Semantics
-
s12:Envelope/s12:Body/wsd:Resolve/wsa:EndpointReference/wsa:Address
-
The Provider UID to resolve, encoded as URI.
2:A.2.2.3.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.24.4.3.
2:A.2.2.4 ResolveMatch Message
The ResolveMatch message is encoded by using WS-Discovery Resolve Match.
2:A.2.2.4.1 Referenced Standards
[ISO/IEEE 11073-20702:2016] mdpws:MedicalDevice
[ISO/IEEE 11073-20701:2018] sdc.mds.pkp:1.2.840.10004.20701.1.1
2:A.2.2.4.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<s12:Header>
<wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ResolveMatches</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
<wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>
<wsd:AppSequence InstanceId="..." MessageNumber="..."/>
</s12:Header>
<s12:Body>
<wsd:ResolveMatches>
<wsd:ResolveMatch>
<wsa:EndpointReference>
<wsa:Address><!-- ... --></wsa:Address>
</wsa:EndpointReference>
<wsd:Types>dpws:Device mdpws:MedicalDevice <!-- ... --></wsd:Types>
<wsd:Scopes>sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
<wsd:XAddrs><!-- ... --></wsd:XAddrs>
<wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
</wsd:ResolveMatch>
</wsd:ResolveMatches>
</s12:Body>
</s12:Envelope>
2:A.2.2.4.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.24.4.4.
2:A.2.2.4.4 Message Semantics
-
s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsa:EndpointReference/wsa:Address
-
The SOMDS Provider's SOMDS Provider UID encoded as URI.
-
s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsd:Types
-
List of types that contains at least
dpws:Device
and mdpws:MedicalDevice`, which expresses the SOMDS Provider to conform to DPWS and MDPWS. -
s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsd:Scopes
-
The Discovery Scope of the SOMDS Provider, encoded as a list of URIs.
-
s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsd:XAddrs
-
A list of HTTPS addresses under which the SOMDS Provider receives secured messages.
-
s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsd:MetadataVersion
-
A metadata version of the SOMDS Provider. To be ignored as the transmission of the Resolve Match message is unsecure.
2:A.2.2.4.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.24.4.4.
2:A.2.3 MDPWS: Discover BICEPS Services [DEV-25]
This section specifies the MDPWS data transmission for messages defined in Section 2:3.25.
2:A.2.3.1 GetMetadata Message
The GetMetadata message is encoded by using WS-Get.
2:A.2.3.1.1 Referenced Standards
2:A.2.3.1.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<s12:Header>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/Get</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To><!-- ... --></wsa:To>
</s12:Header>
<s12:Body/>
</s12:Envelope>
2:A.2.3.1.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.25.4.1.
2:A.2.3.1.4 Message Semantics
The GetMetadata message does not contain any further semantics.
2:A.2.3.1.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.25.4.1.
2:A.2.3.2 GetMetadataResponse Message
The GetMetadataResponse message is encoded by using WS-Get.
2:A.2.3.2.1 Referenced Standards
2:A.2.3.2.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsm="http://schemas.xmlsoap.org/ws/2004/09/mex"
xmlns:s12="http://www.w3.org/2003/05/soap-envelope">
<s12:Header>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/09/transfer/GetResponse</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
</s12:Header>
<s12:Body>
<wsm:Metadata>
<wsm:MetadataSection Dialect="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01/ThisModel">
<dpws:ThisModel>
<dpws:Manufacturer xml:lang="..."><!-- ... --></dpws:Manufacturer>
<dpws:ManufacturerUrl><!-- ... --></dpws:ManufacturerUrl>
<dpws:ModelName><!-- ... --></dpws:ModelName>
<dpws:ModelNumber><!-- ... --></dpws:ModelNumber>
<dpws:PresentationUrl><!-- ... --></dpws:PresentationUrl>
</dpws:ThisModel>
</wsm:MetadataSection>
<wsm:MetadataSection Dialect="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01/ThisDevice">
<dpws:ThisDevice>
<dpws:FriendlyName xml:lang="..."><!-- ... --></dpws:FriendlyName>
<dpws:FirmwareVersion><!-- ... --></dpws:FirmwareVersion>
<dpws:SerialNumber><!-- ... --></dpws:SerialNumber>
</dpws:ThisDevice>
</wsm:MetadataSection>
<wsm:MetadataSection Dialect="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01/Relationship">
<dpws:Relationship Type="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01/host">
<dpws:Host>
<wsa:EndpointReference>
<wsa:Address><!-- ... --></wsa:Address>
</wsa:EndpointReference>
<dpws:Types xmlns="http://standards.ieee.org/downloads/11073/11073-20702-2016"><!-- ... --></dpws:Types>
</dpws:Host>
<dpws:Hosted>
<wsa:EndpointReference>
<wsa:Address><!-- ... --></wsa:Address>
</wsa:EndpointReference>
<dpws:Types><!-- ... --></dpws:Types>
<dpws:ServiceId><!-- ... --></dpws:ServiceId>
</dpws:Hosted>
</dpws:Relationship>
</wsm:MetadataSection>
</wsm:Metadata>
</s12:Body>
</s12:Envelope>
2:A.2.3.2.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.25.4.2.
2:A.2.3.2.4 Message Semantics
-
s12:Envelope/s12:Body/wsm:Metadata/wsm:MetadataSection/dpws:ThisModel
-
The SOMDS Provider's metadata that maps to the Model Metadata.
-
s12:Envelope/s12:Body/wsm:Metadata/wsm:MetadataSection/dpws:ThisDevice
-
The SOMDS Provider's metadata that maps to the Device Metadata.
-
s12:Envelope/s12:Body/wsm:Metadata/wsm:MetadataSection/dpws:Relationship/dpws:Hosted/dpws:Types
-
Designates available BICEPS Services by providing a list of service types that contains at least one or more of the BICEPS services as mapped in Table 2:A.2.3.2.4-1.
BICEPS service | Web Service XML Schema QName |
---|---|
GET SERVICE (mandatory) as specified in [ISO/IEEE 11073-10207:2017] Section 7.3 Service Model |
{http://standards.ieee.org/downloads/11073/11073-20701-2018}GetService |
SET SERVICE as specified in [ISO/IEEE 11073-10207:2017] Section 7.3 Service Model |
{http://standards.ieee.org/downloads/11073/11073-20701-2018}SetService |
DESCRIPTION EVENT SERVICE as specified in [ISO/IEEE 11073-10207:2017] Section 7.3 Service Model |
{http://standards.ieee.org/downloads/11073/11073-20701-2018}DescriptionEventService |
STATE EVENT SERVICE as specified in [ISO/IEEE 11073-10207:2017] Section 7.3 Service Model |
{http://standards.ieee.org/downloads/11073/11073-20701-2018}StateEventService |
CONTEXT SERVICE as specified in [ISO/IEEE 11073-10207:2017] Section 7.3 Service Model |
{http://standards.ieee.org/downloads/11073/11073-20701-2018}ContextService |
WAVEFORM SERVICE as specified in [ISO/IEEE 11073-10207:2017] Section 7.3 Service Model |
{http://standards.ieee.org/downloads/11073/11073-20701-2018}WaveformService |
2:A.2.3.2.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.25.4.2.
2:A.2.4 MDPWS: Manage BICEPS Subscription [DEV-27]
This section specifies the MDPWS data transmission for messages defined in Section 2:3.27.
2:A.2.4.1 Subscribe Message
The Subscribe message is encoded by using WS-Eventing Subscribe.
2:A.2.4.1.1 Referenced Standards
2:A.2.4.1.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing">
<s12:Header>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/Subscribe</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
</s12:Header>
<s12:Body>
<wse:Subscribe>
<wse:EndTo>
<wsa:Address><!-- ... --></wsa:Address>
</wse:EndTo>
<wse:Delivery Mode="http://schemas.xmlsoap.org/ws/2004/08/eventing/DeliveryModes/Push">
<wse:NotifyTo>
<wsa:Address><!-- ... --></wsa:Address>
</wse:NotifyTo>
</wse:Delivery>
<wse:Expires><!-- ... --></wse:Expires>
<wse:Filter Dialect="..."><!-- ... --></wse:Filter>
</wse:Subscribe>
</s12:Body>
</s12:Envelope>
2:A.2.4.1.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.27.4.1.
2:A.2.4.1.4 Message Semantics
-
s12:Envelope/s12:Body/wse:Subscribe/wse:EndTo/wsa:Address
-
HTTPS server address at which SubscriptionEnd messages are supposed to be delivered.
-
s12:Envelope/s12:Body/wse:Subscribe/wse:Delivery/wse:NotifyTo/wsa:Address
-
HTTPS server address at which Notification messages are supposed to be delivered.
-
s12:Envelope/s12:Body/wse:Subscribe/wse:Expires
-
Expiration Time as an XML Schema duration, constrained to hours, minutes and seconds (regular expression:
^PT(\d+H)?(\d+M)?(\d+(.\d+)?S)?(?<!PT)$
) -
s12:Envelope/s12:Body/wse:Subscribe/wse:Filter/@Dialect
-
In accordance with DPWS, support for at least
http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01/Action
. -
s12:Envelope/s12:Body/wse:Subscribe/wse:Filter
-
If
s12:Envelope/s12:Body/wse:Subscribe/wse:Filter/@Dialect
ishttp://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.
2:A.2.4.1.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.27.4.1.
2:A.2.4.2 SubscribeResponse Message
The SubscribeResponse message is encoded by using WS-Eventing SubscribeResponse.
2:A.2.4.2.1 Referenced Standards
2:A.2.4.2.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing">
<s12:Header>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/SubscribeResponse</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
</s12:Header>
<s12:Body>
<wse:SubscribeResponse>
<wse:SubscriptionManager>
<wsa:Address><!-- ... --></wsa:Address>
</wse:SubscriptionManager>
<wse:Expires><!-- ... --></wse:Expires>
</wse:SubscribeResponse>
</s12:Body>
</s12:Envelope>
2:A.2.4.2.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.27.4.2.
2:A.2.4.2.4 Message Semantics
-
s12:Envelope/s12:Body/wse:SubscribeResponse/wse:SubscriptionManager/wsa:Address
-
URI that serves as an access point to manage the subscription, which satisfies Subscription Manager.
-
s12:Envelope/s12:Body/wse:SubscribeResponse/wse:Expires
-
Expiration Time as an XML Schema duration, constrained to hours, minutes and seconds (regular expression:
^PT(\d+H)?(\d+M)?(\d+(.\d+)?S)?(?<!PT)$
).
2:A.2.4.2.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.27.4.2.
2:A.2.4.2.6 Additional Consideration
2:A.2.4.2.6.1 Path dispatching
2:A.2.4.2.6.2 Subscription Expiration
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
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing">
<s12:Header>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/Renew</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To><!-- ... --></wsa:To>
</s12:Header>
<s12:Body>
<wse:Renew>
<wse:Expires><!-- ... --></wse:Expires>
</wse:Renew>
</s12:Body>
</s12:Envelope>
2:A.2.4.4.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.27.4.4.
2:A.2.4.4.4 Message Semantics
-
s12:Envelope/s12:Body/wse:Renew/wse:Expires
-
Expiration Time as an XML Schema duration, constrained to hours, minutes and seconds (regular expression:
^PT(\d+H)?(\d+M)?(\d+(.\d+)?S)?(?<!PT)$
)
2:A.2.4.4.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.27.4.4.
2:A.2.4.5 RenewResponse Message
The RenewResponse message is encoded by using WS-Eventing RenewResponse.
2:A.2.4.5.1 Referenced Standards
2:A.2.4.5.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing">
<s12:Header>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/RenewResponse</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
</s12:Header>
<s12:Body>
<wse:RenewResponse>
<wse:Expires><!-- ... --></wse:Expires>
</wse:RenewResponse>
</s12:Body>
</s12:Envelope>
2:A.2.4.5.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.27.4.5.
2:A.2.4.5.4 Message Semantics
-
s12:Envelope/s12:Body/wse:RenewResponse/wse:Expires
-
Expiration Time as an XML Schema duration, constrained to hours, minutes and seconds (regular expression:
^PT(\d+H)?(\d+M)?(\d+(.\d+)?S)?(?<!PT)$
).
2:A.2.4.5.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.27.4.5.
2:A.2.4.5.6 Additional Consideration
2:A.2.4.5.6.1 Subscription Expiration
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
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing">
<s12:Header>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/Unsubscribe</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To><!-- ... --></wsa:To>
</s12:Header>
<s12:Body>
<wse:Unsubscribe/>
</s12:Body>
</s12:Envelope>
2:A.2.4.6.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.27.4.6.
2:A.2.4.6.4 Message Semantics
The WS-Eventing RenewResponse message does not contain any further semantics.
2:A.2.4.6.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.27.4.6.
2:A.2.4.7 UnsubscribeResponse Message
The UnsubscribeResponse message is encoded by using WS-Eventing UnsubscribeResponse.
2:A.2.4.7.1 Referenced Standards
2:A.2.4.7.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<s12:Header>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/UnsubscribeResponse</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
</s12:Header>
<s12:Body/>
</s12:Envelope>
2:A.2.4.7.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.27.4.7.
2:A.2.4.7.4 Message Semantics
The WS-Eventing UnsubscribeResponse message does not contain any further semantics.
2:A.2.4.7.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.27.4.7.
2:A.2.4.8 SubscriptionEnd Message
The SubscriptionEnd message is encoded by using WS-Eventing Subscription End.
2:A.2.4.8.1 Referenced Standards
2:A.2.4.8.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing">
<s12:Header>
<wsa:Action>http://schemas.xmlsoap.org/ws/2004/08/eventing/SubscriptionEnd</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To><!-- ... --></wsa:To>
</s12:Header>
<s12:Body>
<wse:SubscriptionEnd>
<wse:SubscriptionManager>
<wsa:Address><!-- ... --></wsa:Address>
</wse:SubscriptionManager>
<wse:Status><!-- ... --></wse:Status>
</wse:SubscriptionEnd>
</s12:Body>
</s12:Envelope>
2:A.2.4.8.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.27.4.8.
2:A.2.4.8.4 Message Semantics
-
s12:Envelope/s12:Body/wse:SubscriptionEnd/wse:SubscriptionManager/wsa:Address
-
URI of the Subscription Manager that manages the subscription that ended.
-
s12:Envelope/s12:Body/wse:SubscriptionEnd/wse:Status
-
Status which is encoded in accordance with WS-Eventing to one of http://schemas.xmlsoap.org/ws/2004/08/eventing/DeliveryFailure, http://schemas.xmlsoap.org/ws/2004/08/eventing/SourceShuttingDown or http://schemas.xmlsoap.org/ws/2004/08/eventing/SourceCancelling.
2:A.2.4.8.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.27.4.8.
2:A.2.5 MDPWS: Notify Change in System Context and Capabilities [DEV-28]
This section specifies the MDPWS data transmission for messages defined in Section 2:3.28.
2:A.2.5.1 Notification Message
The Notification message is encoded by using DPWS Messaging.
2:A.2.5.1.1 Referenced Standards
[ISO/IEEE 11073-10207:2017] msg:EpisodicContextReport
2:A.2.5.1.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<s12:Header>
<wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/EpisodicContextReport</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To><!-- ... --></wsa:To>
</s12:Header>
<s12:Body>
<msg:EpisodicContextReport MdibVersion="..." SequenceId="..." InstanceId="...">
<!-- ... -->
</msg:EpisodicContextReport>
</s12:Body>
</s12:Envelope>
2:A.2.5.1.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.28.4.1.
2:A.2.5.1.4 Message Semantics
-
s12:Envelope/s12:Body/msg:EpisodicContextReport
-
Updated context information of a SOMDS Provider.
2:A.2.5.1.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.28.4.1.
2:A.2.6 MDPWS: Publish BICEPS Update Reports [DEV-29]
This section specifies the MDPWS data transmission for messages defined in Section 2:3.29.
2:A.2.6.1 EpisodicAlertReport Message
The EpisodicAlertReport message is encoded by using DPWS Messaging.
2:A.2.6.1.1 Referenced Standards
[ISO/IEEE 11073-10207:2017] msg:EpisodicAlertReport
2:A.2.6.1.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<s12:Header>
<wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/EpisodicAlertReport</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To><!-- ... --></wsa:To>
</s12:Header>
<s12:Body>
<msg:EpisodicAlertReport MdibVersion="..." SequenceId="..." InstanceId="...">
<!-- ... -->
</msg:EpisodicAlertReport>
</s12:Body>
</s12:Envelope>
2:A.2.6.1.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.29.4.1.
2:A.2.6.1.4 Message Semantics
-
s12:Envelope/s12:Body/msg:EpisodicAlertReport
-
Updated alert information of a SOMDS Provider.
2:A.2.6.1.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.29.4.1.
2:A.2.6.2 EpisodicMetricReport Message
The EpisodicMetricReport message is encoded by using DPWS Messaging.
2:A.2.6.2.1 Referenced Standards
[ISO/IEEE 11073-10207:2017] msg:EpisodicMetricReport
2:A.2.6.2.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<s12:Header>
<wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/EpisodicMetricReport</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To><!-- ... --></wsa:To>
</s12:Header>
<s12:Body>
<msg:EpisodicMetricReport MdibVersion="..." SequenceId="..." InstanceId="...">
<!-- ... -->
</msg:EpisodicMetricReport>
</s12:Body>
</s12:Envelope>
2:A.2.6.2.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.29.4.1.
2:A.2.6.2.4 Message Semantics
-
s12:Envelope/s12:Body/msg:EpisodicMetricReport
-
Updated metric information of a SOMDS Provider.
2:A.2.6.2.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.29.4.1.
2:A.2.6.3 EpisodicComponentReport Message
The EpisodicComponentReport message is encoded by using DPWS Messaging.
2:A.2.6.3.1 Referenced Standards
[ISO/IEEE 11073-10207:2017] msg:EpisodicComponentReport
2:A.2.6.3.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<s12:Header>
<wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/EpisodicComponentReport</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To><!-- ... --></wsa:To>
</s12:Header>
<s12:Body>
<msg:EpisodicComponentReport MdibVersion="..." SequenceId="..." InstanceId="...">
<!-- ... -->
</msg:EpisodicComponentReport>
</s12:Body>
</s12:Envelope>
2:A.2.6.3.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.29.4.1.
2:A.2.6.3.4 Message Semantics
-
s12:Envelope/s12:Body/msg:EpisodicComponentReport
-
Updated component information of a SOMDS Provider.
2:A.2.6.3.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.29.4.1.
2:A.2.6.4 WaveformStream Message
The WaveformStream message is encoded by using DPWS Messaging.
2:A.2.6.4.1 Referenced Standards
[ISO/IEEE 11073-10207:2017] msg:WaveformStream
2:A.2.6.4.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<s12:Header>
<wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/StateEventService/WaveformStream</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To><!-- ... --></wsa:To>
</s12:Header>
<s12:Body>
<msg:WaveformStream MdibVersion="..." SequenceId="..." InstanceId="...">
<!-- ... -->
</msg:WaveformStream>
</s12:Body>
</s12:Envelope>
2:A.2.6.4.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.29.4.1.
2:A.2.6.4.4 Message Semantics
-
s12:Envelope/s12:Body/msg:WaveformStream
-
Waveform stream of a SOMDS Provider.
2:A.2.6.4.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.29.4.1.
2:A.2.7 MDPWS: Retrieve BICEPS Content [DEV-30]
This section specifies the MDPWS data transmission for messages defined in Section 2:3.30.
2:A.2.7.1 GetMdib Message
The GetMdib message is encoded by using DPWS Messaging.
2:A.2.7.1.1 Referenced Standards
2:A.2.7.1.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message"
xmlns:wsa="http://www.w3.org/2005/08/addressing" >
<s12:Header>
<wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/GetService/GetMdib</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
</s12:Header>
<s12:Body>
<msg:GetMdib/>
</s12:Body>
</s12:Envelope>
2:A.2.7.1.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.30.4.1.
2:A.2.7.1.4 Message Semantics
The GetMdib message does not contain any further semantics.
2:A.2.7.1.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.30.4.1.
2:A.2.7.2 GetMdibResponse Message
The GetMdibResponse message is encoded by using DPWS Messaging.
2:A.2.7.2.1 Referenced Standards
[ISO/IEEE 11073-10207:2017] msg:GetMdibResponse
2:A.2.7.2.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:pm="http://standards.ieee.org/downloads/11073/11073-10207-2017/participant"
xmlns:msg="http://standards.ieee.org/downloads/11073/11073-10207-2017/message"
xmlns:wsa="http://www.w3.org/2005/08/addressing">
<s12:Header>
<wsa:Action>http://standards.ieee.org/downloads/11073/11073-20701-2018/GetService/GetMdibResponse</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
</s12:Header>
<s12:Body>
<msg:GetMdibResponse MdibVersion="..." SequenceId="..." InstanceId="...">
<msg:Mdib MdibVersion="..." SequenceId="..." InstanceId="...">
<pm:MdDescription DescriptionVersion="...">
</pm:MdDescription>
<pm:MdState StateVersion="...">
</pm:MdState>
</msg:Mdib>
</msg:GetMdibResponse>
</s12:Body>
</s12:Envelope>
2:A.2.7.2.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.30.4.2.
2:A.2.7.2.4 Message Semantics
-
s12:Envelope/s12:Body/msg:GetMdibResponse/msg:Mdib/pm:MdDescription
-
The SOMDS Provider's descriptive part of the MDIB.
-
s12:Envelope/s12:Body/msg:GetMdibResponse/msg:Mdib/pm:MdState
-
The SOMDS Provider's state part of the MDIB.
2:A.2.7.2.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.30.4.2.
2:A.2.7.2.6 Additional Consideration
2:A.2.7.2.6.1 Context States
2:A.2.8 MDPWS: Announce Network Departure [DEV-34]
This section specifies the MDPWS data transmission for messages defined in Section 2:3.34.
2:A.2.8.1 Bye Message
The Bye message is encoded by using WS-Discovery Bye.
2:A.2.8.1.1 Referenced Standards
2:A.2.8.1.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<s12:Header>
<wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Bye</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
</s12:Header>
<s12:Body>
<wsd:Bye>
<wsa:EndpointReference>
<wsa:Address><!-- ... --></wsa:Address>
</wsa:EndpointReference>
</wsd:Bye>
</s12:Body>
</s12:Envelope>
2:A.2.8.1.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.34.4.1.
2:A.2.8.1.4 Message Semantics
-
s12:Envelope/s12:Body/wsd:Bye/wsa:EndpointReference/wsa:Address
-
The SOMDS Provider's Provider UID as URI.
2:A.2.8.1.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.34.4.1.
2:A.2.9 MDPWS: Update Network Presence [DEV-46]
This section specifies the MDPWS data transmission for messages defined in Section 2:3.46.
Additional implementation directions are defined in Appendix 2:A.3.
2:A.2.9.1 Hello Message
The Hello message is encoded by using DPWS Messaging.
2:A.2.9.1.1 Referenced Standards
2:A.2.9.1.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<s12:Header>
<wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Hello</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
</s12:Header>
<s12:Body>
<wsd:Hello>
<wsa:EndpointReference>
<wsa:Address><!-- ... --></wsa:Address>
</wsa:EndpointReference>
<wsd:Types>dpws:Device mdpws:MedicalDevice</wsd:Types>
<wsd:Scopes>sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
<wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
</wsd:Hello>
</s12:Body>
</s12:Envelope>
2:A.2.9.1.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.46.4.1.
2:A.2.9.1.4 Message Semantics
-
s12:Envelope/s12:Body/wsd:Hello/wsa:EndpointReference/wsa:Address
-
The SOMDS Provider's Provider UID as URI.
-
s12:Envelope/s12:Body/wsd:Hello/wsd:Scopes
-
The SOMDS Provider's Discovery Scope as a list of URIs.
2:A.2.9.1.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.46.4.1.
2:A.2.9.2 Bye Message
The Bye message is encoded by using DPWS Messaging.
2:A.2.9.2.1 Referenced Standards
2:A.2.9.2.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<s12:Header>
<wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Bye</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
</s12:Header>
<s12:Body>
<wsd:Bye>
<wsa:EndpointReference>
<wsa:Address><!-- ... --></wsa:Address>
</wsa:EndpointReference>
</wsd:Bye>
</s12:Body>
</s12:Envelope>
2:A.2.9.2.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.46.4.2.
2:A.2.9.2.4 Message Semantics
-
s12:Envelope/s12:Body/wsd:Bye/wsa:EndpointReference/wsa:Address
-
The SOMDS Provider's Provider UID as URI.
2:A.2.9.2.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.46.4.2.
2:A.2.9.3 DirectedProbe Message
In addition to Hello and Bye, this section proposes a Discovery Proxy to periodically probe all SOMDS Providers it has recorded as present in the SOMDS by using a DirectedProbe message. This allows for the Discovery Proxy to verify if SOMDS Providers reachable.
The DirectedProbe message is encoded by using DPWS Messaging.
2:A.2.9.3.1 Referenced Standards
2:A.2.9.3.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<s12:Header>
<wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Probe</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
</s12:Header>
<s12:Body>
<wsd:Probe/>
</s12:Body>
</s12:Envelope>
2:A.2.9.3.3 Trigger Events
A Discovery Proxy may periodically send DirectedProbe messages to all present SOMDS Providers. The periodicity can be determined by the Discovery Proxy.
2:A.2.9.3.4 Message Semantics
No payload is required as the probe is intended to be used for watchdog purposes only.
2:A.2.9.3.5 Expected Actions
If the request succeeds, there is no additional action required.
If the request fails, the Discovery Proxy removes the SOMDS Provider endpoint metadata from its databases and informs SOMDS Consumers about the SOMDS Provider's absence.
2:A.2.10 MDPWS: Retrieve Network Presence [DEV-47]
This section specifies the MDPWS data transmission for messages defined in Section 2:3.47.
Additional implementation directions are defined in Appendix 2:A.3.
2:A.2.10.1 Hello Message
The Hello message is encoded by using DPWS Messaging.
2:A.2.10.1.1 Referenced Standards
2:A.2.10.1.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<s12:Header>
<wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Hello</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
</s12:Header>
<s12:Body>
<wsd:Hello>
<wsa:EndpointReference>
<wsa:Address><!-- ... --></wsa:Address>
</wsa:EndpointReference>
<wsd:Types>dpws:Device mdpws:MedicalDevice</wsd:Types>
<wsd:Scopes>sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
<wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
</wsd:Hello>
</s12:Body>
</s12:Envelope>
2:A.2.10.1.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.47.4.1.
2:A.2.10.1.4 Message Semantics
-
s12:Envelope/s12:Body/wsd:Hello/wsa:EndpointReference/wsa:Address
-
The SOMDS Provider's Provider UID as URI.
-
s12:Envelope/s12:Body/wsd:Hello/wsd:Scopes
-
The SOMDS Provider's Discovery Scope as a list of URIs.
2:A.2.10.1.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.47.4.1.
2:A.2.10.2 Bye Message
The Bye message is encoded by using DPWS Messaging.
2:A.2.10.2.1 Referenced Standards
2:A.2.10.2.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<s12:Header>
<wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Bye</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
</s12:Header>
<s12:Body>
<wsd:Bye>
<wsa:EndpointReference>
<wsa:Address><!-- ... --></wsa:Address>
</wsa:EndpointReference>
</wsd:Bye>
</s12:Body>
</s12:Envelope>
2:A.2.10.2.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.47.4.2.
2:A.2.10.2.4 Message Semantics
-
s12:Envelope/s12:Body/wsd:Bye/wsa:EndpointReference/wsa:Address
-
The SOMDS Provider's Provider UID as URI.
2:A.2.10.2.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.47.4.2.
2:A.2.10.3 Probe Message
The Probe message is encoded by using WS-Discovery Probe.
2:A.2.10.3.1 Referenced Standards
[ISO/IEEE 11073-20702:2016] mdpws:MedicalDevice
[ISO/IEEE 11073-20701:2018] sdc.mds.pkp:1.2.840.10004.20701.1.1
2:A.2.10.3.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<s12:Header>
<wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Probe</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
</s12:Header>
<s12:Body>
<wsd:Probe>
<wsd:Types>mdpws:MedicalDevice</wsd:Types>
<wsd:Scopes MatchBy="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/rfc3986">sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
</wsd:Probe>
</s12:Body>
</s12:Envelope>
2:A.2.10.3.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.47.4.3.
2:A.2.10.3.4 Message Semantics
-
s12:Envelope/s12:Body/wsd:Probe/wsa:Types
-
List that contains at least
mdpws:MedicalDevice
to express seeking SOMDS Providers that conform to MDPWS. -
s12:Envelope/s12:Body/wsd:Probe/wsd:Scopes/@MatchBy
-
The algorithm used to compare the
s12:Envelope/s12:Body/wsd:Probe/wsd:Scopes
against the SOMDS Provider's scopes. -
s12:Envelope/s12:Body/wsd:Probe/wsd:Scopes
-
The Discovery Scope as a list of URIs to probe for.
2:A.2.10.3.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.47.4.4.
2:A.2.10.3.6 Additional Consideration
All additional considerations specified in Appendix 2:A.2.2.1.6 do also apply to Appendix 2:A.2.10.
2:A.2.10.4 ProbeMatch Message
The ProbeMatch message is encoded by using WS-Discovery Probe Match.
2:A.2.10.4.1 Referenced Standards
[ISO/IEEE 11073-20702:2016] mdpws:MedicalDevice
[ISO/IEEE 11073-20701:2018] sdc.mds.pkp:1.2.840.10004.20701.1.1
2:A.2.10.4.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<s12:Header>
<wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ProbeMatches</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
<wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>
</s12:Header>
<s12:Body>
<wsd:ProbeMatches>
<wsd:ProbeMatch>
<wsa:EndpointReference>
<wsa:Address><!-- ... --></wsa:Address>
</wsa:EndpointReference>
<wsd:Types>dpws:Device mdpws:MedicalDevice <!-- ... --></wsd:Types>
<wsd:Scopes>sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
<wsd:XAddrs><!-- ... --></wsd:XAddrs>
<wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
</wsd:ProbeMatch>
</wsd:ProbeMatches>
</s12:Body>
</s12:Envelope>
2:A.2.10.4.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.47.4.4.
2:A.2.10.4.4 Message Semantics
-
s12:Envelope/s12:Body/wsd:ProbeMatches
-
All matches found by the Discovery Proxy.
-
s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsa:EndpointReference/wsa:Address
-
The SOMDS Provider's SOMDS Provider UID encoded as URI.
-
s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsd:Types
-
List of types that contains at least
dpws:Device
and mdpws:MedicalDevice`, which expresses the SOMDS Provider to conform to DPWS and MDPWS. -
s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsd:Scopes
-
The Discovery Scope of the SOMDS Provider, encoded as a list of URIs.
-
s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsd:XAddrs
-
A list of HTTPS addresses under which the SOMDS Provider receives secured messages.
-
s12:Envelope/s12:Body/wsd:ProbeMatches/wsd:ProbeMatch/wsd:MetadataVersion
-
A metadata version of the SOMDS Provider.
2:A.2.10.4.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.47.4.4.
2:A.2.10.5 Resolve Message
The Resolve message is encoded by using WS-Discovery Resolve.
2:A.2.10.5.1 Referenced Standards
2:A.2.10.5.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<s12:Header>
<wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Resolve</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
</s12:Header>
<s12:Body>
<wsd:Resolve>
<wsa:EndpointReference>
<wsa:Address><!-- ... --></wsa:Address>
</wsa:EndpointReference>
</wsd:Resolve>
</s12:Body>
</s12:Envelope>
2:A.2.10.5.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.47.4.5.
2:A.2.10.5.4 Message Semantics
-
s12:Envelope/s12:Body/wsd:Resolve/wsa:EndpointReference/wsa:Address
-
The Provider UID to resolve, encoded as URI.
2:A.2.10.5.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.47.4.5.
2:A.2.10.6 ResolveMatch Message
The ResolveMatch message is encoded by using WS-Discovery Resolve Match.
2:A.2.10.6.1 Referenced Standards
[ISO/IEEE 11073-20702:2016] mdpws:MedicalDevice
[ISO/IEEE 11073-20701:2018] sdc.mds.pkp:1.2.840.10004.20701.1.1
2:A.2.10.6.2 Message Outline
<?xml version="1.0" encoding="UTF-8"?>
<s12:Envelope
xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<s12:Header>
<wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ResolveMatches</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:RelatesTo><!-- ... --></wsa:RelatesTo>
<wsa:To>http://www.w3.org/2005/08/addressing/anonymous</wsa:To>
</s12:Header>
<s12:Body>
<wsd:ResolveMatches>
<wsd:ResolveMatch>
<wsa:EndpointReference>
<wsa:Address><!-- ... --></wsa:Address>
</wsa:EndpointReference>
<wsd:Types>dpws:Device mdpws:MedicalDevice <!-- ... --></wsd:Types>
<wsd:Scopes>sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
<wsd:XAddrs><!-- ... --></wsd:XAddrs>
<wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
</wsd:ResolveMatch>
</wsd:ResolveMatches>
</s12:Body>
</s12:Envelope>
2:A.2.10.6.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 2:3.47.4.6.
2:A.2.10.6.4 Message Semantics
-
s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsa:EndpointReference/wsa:Address
-
The SOMDS Provider's SOMDS Provider UID encoded as URI.
-
s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsd:Types
-
List of types that contains at least
dpws:Device
and mdpws:MedicalDevice`, which expresses the SOMDS Provider to conform to DPWS and MDPWS. -
s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsd:Scopes
-
The Discovery Scope of the SOMDS Provider, encoded as a list of URIs.
-
s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsd:XAddrs
-
A list of HTTPS addresses under which the SOMDS Provider receives secured messages.
-
s12:Envelope/s12:Body/wsd:ResolveMatches/wsd:ResolveMatch/wsd:MetadataVersion
-
A metadata version of the SOMDS Provider.
2:A.2.10.6.5 Expected Actions
There are no additional or alternative expected actions other than those defined in Section 2:3.47.4.6.
2:A.3 Discovery Proxy implementation requirements
This chapter describes requirements to the Discovery Proxy MDPWS binding that go beyond message outlines and semantics specified in Section 2:3.46 and Section 2:3.47.
2:A.3.1 Utilized OIDs
All object identifiers used by the Discovery Proxy are specified in Table 2:A.3.1-1.
Primary identifier | Concept description | Secondary identifier |
---|---|---|
1.3.6.1.4.1.19376.1.6.2.10 |
Profile specific OID for SDPi |
sdpi |
1.3.6.1.4.1.19376.1.6.2.10.1 |
Describes namespaces for different purposes as specified by its sub-nodes |
namespaces |
1.3.6.1.4.1.19376.1.6.2.10.1.2 |
Identifies Discovery Proxy objects. |
discovery-proxy |
1.3.6.1.4.1.19376.1.6.2.10.1.2.1 |
Subscription filter dialect used to identify Hello/Bye subscriptions provided by a Discovery Proxy. |
subscription-filter |
1.3.6.1.4.1.19376.1.6.2.10.1.2.2 |
WSDL target namespace identifier for the Discovery Proxy actor. |
wsdl |
2:A.3.2 Discovery Proxy WSDL
Figure 2:A.3.2-1 shows the WSDL file that specifies the Discovery Proxy Web Service interface.
<wsdl:definitions
targetNamespace="urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.2.2"
xmlns:dp="urn:oid:1.3.6.1.4.1.19376.1.6.2.10.1.2.2"
xmlns:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
xmlns:s12="http://schemas.xmlsoap.org/wsdl/soap12/"
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
xmlns:wsdd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wse="http://schemas.xmlsoap.org/ws/2004/08/eventing"
xmlns:wsp="http://www.w3.org/ns/ws-policy">
<wsdl:import namespace="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01" location="http://docs.oasis-open.org/ws-dd/discovery/1.1/os/wsdd-discovery-1.1-schema-os.xsd"/>
<wsdl:message name="HelloMessage">
<wsdl:part name="parameters" element="wsdd:Hello"/>
</wsdl:message>
<wsdl:message name="ByeMessage">
<wsdl:part name="parameters" element="wsdd:Bye"/>
</wsdl:message>
<wsdl:message name="ProbeMessage">
<wsdl:part name="parameters" element="wsdd:Probe"/>
</wsdl:message>
<wsdl:message name="ProbeMatchMessage">
<wsdl:part name="parameters" element="wsdd:ProbeMatches"/>
</wsdl:message>
<wsdl:message name="ResolveMessage">
<wsdl:part name="parameters" element="wsdd:Resolve"/>
</wsdl:message>
<wsdl:message name="ResolveMatchMessage">
<wsdl:part name="parameters" element="wsdd:ResolveMatches"/>
</wsdl:message>
<wsdl:portType name="DiscoveryProxy" wse:EventSource="true">
<wsdl:operation name="HelloReport">
<wsdl:output message="dp:HelloMessage" wsam:Action="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Hello"/>
</wsdl:operation>
<wsdl:operation name="ByeReport">
<wsdl:output message="dp:ByeMessage" wsam:Action="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Bye"/>
</wsdl:operation>
<wsdl:operation name="Hello">
<wsdl:input message="dp:HelloMessage" wsam:Action="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Hello"/>
</wsdl:operation>
<wsdl:operation name="Bye">
<wsdl:input message="dp:ByeMessage" wsam:Action="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Bye"/>
</wsdl:operation>
<wsdl:operation name="Probe">
<wsdl:input message="dp:ProbeMessage" wsam:Action="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Probe"/>
<wsdl:output message="dp:ProbeMatchMessage" wsam:Action="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ProbeMatches"/>
</wsdl:operation>
<wsdl:operation name="Resolve">
<wsdl:input message="dp:ResolveMessage" wsam:Action="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Resolve"/>
<wsdl:output message="dp:ResolveMatchMessage" wsam:Action="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/ResolveMatches"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="DiscoveryProxyBinding" type="dp:DiscoveryProxy">
<s12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsp:Policy>
<dpws:Profile wsp:Optional="true"/>
</wsp:Policy>
<wsdl:operation name="HelloReport">
<s12:operation soapAction="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Hello"/>
<wsdl:output>
<s12:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="ByeReport">
<s12:operation soapAction="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Bye"/>
<wsdl:output>
<s12:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="Hello">
<s12:operation soapAction="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Hello"/>
<wsdl:input>
<s12:body use="literal"/>
</wsdl:input>
</wsdl:operation>
<wsdl:operation name="Bye">
<s12:operation soapAction="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Bye"/>
<wsdl:input>
<s12:body use="literal"/>
</wsdl:input>
</wsdl:operation>
<wsdl:operation name="Probe">
<s12:operation soapAction="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Probe"/>
<wsdl:input>
<s12:body use="literal"/>
</wsdl:input>
<wsdl:output>
<s12:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="Resolve">
<s12:operation soapAction="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Resolve"/>
<wsdl:input>
<s12:body use="literal"/>
</wsdl:input>
<wsdl:output>
<s12:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>
2:A.4 Security Considerations
In TR1164, IEEE 11073-10700 requires a SOMDS Provider to protect BICEPS services against unauthenticated access. In order to fulfill TR1164, IEEE 11073-20701 specifies the need to establish secure channels between SOMDS Participant by using TLS with mutual authentication.
This appendix does not specify any processes towards certificate governance. Certificate governance is a separate topic that needs to be addressed in future revisions of this specification. |
2:A.5 Amendments and Corrigenda
2:A.5.1 Connection Time Delay
When a SOMDS Provider joins a network and sends out a Hello message, depending on the number of SOMDS Consumers that are interested in the data of that SOMDS Provider, the SOMDS Provider can get overwhelmed by incoming TCP connection requests and TLS handshakes. SOMDS Providers and SOMDS Consumers can implement different actions in order to avoid flooding of TCP connection requests and TLS handshakes under normal operating conditions. Each action comes with individual advantages and disadvantages.
2:A.5.1.1 Provider-controlled Delay
[ISO/IEEE 11073-20701:2018] normatively references [OASIS DPWS:2009] which in turn leverages [OASIS WS-Discovery:2009] to provide distributed (ad-hoc) or centralized (managed) service registries. WS-Discovery decomposes into two message sequences, implicit discovery and explicit discovery of which implicit discovery can lead to loss of performance for SOMDS Providers when multiple SOMDS Consumers attempt to connect at the same time.
In order to suppress concurrent connection attempts, in the ad-hoc mode a SOMDS Provider can omit the Transport Address from the Hello message. Subsequently, a SOMDS Consumer needs to send a Resolve message to resolve the SOMDS Provider's Transport Address.
Deferral is controlled by the entity that is affected by concurrent connection attempts.
The deferral does not work in managed mode, i.e., when a discovery proxy is in charge to respond to Resolve messages (unless the discovery proxy implements a similar behavior).
2:A.5.1.2 Consumer-controlled Delay
[ISO/IEEE 11073-20701:2018] introduces the concept of priority groups. According to glue:R0076, a SOMDS Consumer is required to have a priority group assigned, which causes the SOMDS Consumer to postpone initial connection requests by a certain time once it retrieved the Transport Address of a SOMDS Provider. Depending on the priority groups 0 to 9, with increasing group numbers the initial connection delay increases linearly based on random or fixed durations in predefined intervals.
[ISO/IEEE 11073-20701:2018] does not define numbers for specific purposes but rather appeal to Manufacturers to implement priority groups meaningful to their SOMDS Consumer's purpose.
The deferral works in ad-hoc and managed mode discovery.
Deferral is not controlled by the entity that is affected by concurrent connection attempts but by the entity that initiates the connection.
2:A.5.1.2.1 Default Priority Group
2:A.5.1.2.2 Dynamic Priority Group
2:A.5.1.2.3 Priority Group Guidelines
Table 2:A.5.1.2.3-1 exhibits guidelines to Manufacturers or responsible organizations as to which priority group can be used for a certain SOMDS Consumer system function criticality.
System Function Criticality | Priority Group Range | System Function | Examples |
---|---|---|---|
High |
0 - 1 |
|
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 |
|
|
Low |
7 - 9 |
|
|
2:A.5.2 MDIB Report Retrofit
In addition to Section 3:8.3.2.12, this section specifies requirements to an MDPWS transport binding. The requirements aim to verify that MDIB versions received by a SOMDS Consumer are not decremented and present no gap.
2:A.5.3 MDPWS Compression Option
MDPWS [ISO/IEEE 11073-20702:2016] defines EXI as the designated means to compress XML data. However, EXI is lagging in adoption. Therefore, instead of using EXI compression, it is recommended to use HTTP compression with gzip (RFC 1952) as the minimum agreement between clients and servers. One issue with that is the missing official support for HTTP compression in HTTP request messages. Request headers are allowed to include Content-Encoding, but those might not be accepted by HTTP servers.
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.
2:A.5.4 Discovery Scopes
[ISO/IEEE 11073-20701:2018] specifies requirements to the encoding of certain MDIB data as WS-Discovery Scopes provided by SOMDS Providers. This clause further details encoding rules for production specifications and attributes as laid out in the IEEE 11073-10101 nomenclature.
2:A.5.4.1 Encoding of Production Specifications
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 ]
|
Scheme ::= 'sdc.mds.prodspec'
MdsProductionSpecification ::= Scheme ':' ProductionSpecification
ProductionSpecification is specified in Figure 2:A.5.4.1-1. |
2:A.5.4.2 Encoding of Attributes
Char ::= unreserved | pct-encoded
CharSequenceNz ::= Char { Char }
CodingSystem ::= CharSequenceNz
CodingSystemVersion ::= CharSequenceNz
Code ::= CharSequenceNz
CodedValue ::= Code [ ',' CodingSystem [ ',' CodingSystemVersion ] ]
AttributeValue ::= { Char }
AttributeCode ::= CodedValue
Attribute ::= AttributeValue ':' AttributeCode
|
Scheme ::= 'sdc.mds.attr'
MdsAttribute ::= Scheme ':' Attribute
Attribute is specified in Figure 2:A.5.4.2-1. |
2:A.5.5 XML Pretty-Print
XML processor implementations may pretty-print XML by default when serializing XML instance documents, which can cause unexpected errors for validating XML parsers. Pretty-printed XML aligns XML elements in new lines and adds indentation where necessary to beautify serialized data and therewith increase human-readability. However, if the serializer is not XML-Schema-agnostic, it ignores mixed content declarations and hence can change the meaning of elements in instance documents that are supposed to contain mixed content.
R0013 requires XML serializers to be XML Schema agnostic. If, e.g., for technical reasons, a serializer cannot be XML Schema agnostic, it is not allowed to pretty-print XML data as it may generate invalid XML markup.
2:A.5.6 Processing of QNames
QNames are problematic when used in XML element content or attribute values (see Section 3:8.3.2.10.1.2). Unfortunately, the BICEPS Participant and Message Model as well some Web Services standards that are normatively referenced by DPWS, use QNames in XML element content or attribute values.
In order to increase interoperability between implementations of this profile, this section specifies requirements towards QName handling in XML instances.
Appendix 2:B Gateways (Normative)
2:B.1 Overview SDC Gateways
2:B.2 SDPi Gateway — HL7 V2 General Mapping
This section specifies general HL7 V2 requirements and mappings, which apply to the Appendix 2:B.3 as well as to the Appendix 2:B.4 sections below.
2:B.2.1 Time Zone Setting
Timestamps can be specified in HL7 v2 in both UTC and local time.
As stated in [IHE PCD TF-2:2019] all observation times reported SHOULD be UTC, as indicated by including a time zone offset of +0000. |
If the timestamps are to be specified in local time, it is important that the time zone is set correctly at the Point of Care Device (PoCD). |
It is not always guaranteed that the timezone configured at the SOMDS Provider and/or SOMDS DEC Gateway / SOMDS ACM Gateway corresponds with the timezone of the MDS entities, for example, when a SOMDS Provider acting as device aggregator and/or the SOMDS DEC Gateway / SOMDS ACM Gateway are running in a data center located in a different timezone than the MDS entities. |
2:B.2.2 Private MDC Codes Consideration
The default coding system utilized in SDC is "MDC" (Medical Device Communications) also known as "ISO/IEEE 11073-10101" nomenclature.
In addition to the standard codes, MDC defines private code ranges that can be used by medical device vendors for defining their own codes, for example, for concepts for which standard codes do not exist. Private codes should be avoided whenever possible since this undermines interoperability.
Coded elements in SDC using MDC private codes require also to contain a pm:Translation element that defines the vendor-specific coding system. Please refer to [IEEE 11073-10700:2022] TR1358 for further information.
Section Section 3:8.3.2.7 describes how a globally unique vender-specific coding system identifier can be defined.
The following example uses the SDC pm:Type to demonstrate the mapping of private MDC codes.
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
---|---|---|---|
CWE-1 |
Identifier |
pm:Type |
This attribute contains the private MDC code. |
CWE-2 |
Text |
If available: pm:Type |
If pm:Type |
CWE-3 |
Name of Coding System |
Set to coding system "MDC". |
|
CWE-4 |
Alternate Identifier |
pm:Type |
This code is required to be identical with the pm:Type/@Code attribute. |
CWE-6 |
Name of Alternate Coding System |
pm:Type |
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 |
|
CWE-8 |
Alternate Coding System Version ID |
pm:Type |
123455^MDC_PRIVATE_123455^MDC^123455^^urn:oid:1.3.6.1.4.1.1234.2
123455^MDC_PRIVATE_123455^MDC^123455^^99PHL
2:B.2.3 HL7 Segment Descriptions
The following sections specify the general HL7 V2 segment mappings. Please refer to the Appendix B Common Segment Descriptions of the [IHE PCD TF-2:2019] for further information.
2:B.2.3.1 MSH - Message Header Segment
The HL7 Message Header (MSH) segment requires a mapping between the MDIB content and the MSH segment fields.
2:B.2.3.1.1 MSH-11 Processing ID
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
---|---|---|---|
MSH-11/PT-1 |
Processing ID |
pm:MdsState |
Note that the HL7 Processing ID value set (HL7 table 0103) differs from the SDC pm:MdsOperatingMode value set and requires a mapping accordingly (see also Table 2:B.2.3.1.1-2). |
SDC Value | SDC Description | HL7 Value | HL7 Description |
---|---|---|---|
Nml |
Nml = Normal |
P |
Production |
Dmo Srv Mtn |
Dmo = Demo Srv = Service Mtn = Maintenance |
D |
Debugging |
2:B.2.3.2 PID - Patient Identification Segment
The HL7 Patient Identification (PID) segment requires a mapping from the MDIB patient context information element pm:PatientContextState to the PID segment fields.
2:B.2.3.2.1 Prerequisite of Valid Patient Context
2:B.2.3.2.2 PID-3 Patient Identifier List
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
---|---|---|---|
PID-3/CX-1 |
ID Number |
pm:PatientContextState |
The @Extension attribute contains the unique patient identifier. Note that the field may contain a null value indicating that the identifier is missing. |
PID-3/CX-4 |
Assigning Authority |
pm:PatientContextState |
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 |
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 |
The following identifier type codes are proposed to be used for the patient identifier in the point of care device:
Value | Description |
---|---|
AN |
Account Number |
MR |
Medical Record Number |
PI |
Patient Internal Identifier |
U |
Unspecified Identifier |
VN |
Visit Number |
2:B.2.3.2.3 PID-5 Patient Name
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
---|---|---|---|
PID-5/XPN-1 |
Family Name |
pm:PatientContextState |
HL7 data type FN |
PID-5/XPN-1.1 |
Surname |
/pm:Familyname |
|
PID-5/XPN-2 |
Given Name |
pm:PatientContextState |
|
PID-5/XPN-3 |
Second and Further Given Names or Initials |
pm:PatientContextState |
|
PID-5/XPN-5 |
Prefix (e.g., DR) |
pm:PatientContextState |
|
PID-5/XPN-7 |
Name Type Code |
pm:PatientContextState |
This field is set to "L" when a patient name is available, or "U" when the patient name is not set. Please refer also to the corresponding section in the [IHE PCD TF-2:2019]. |
2:B.2.3.2.4 PID-6 Mother’s Maiden Name
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
---|---|---|---|
PID-6/XPN-1 |
Family Name |
pm:PatientContextState |
HL7 data type FN |
PID-6/XPN-1.1 |
Surname |
/pm:Birthname |
2:B.2.3.2.5 PID-7 Date/Time of Birth
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
---|---|---|---|
PID-7/DTM-1 |
Date/Time |
pm:PatientContextState |
Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also Example 2). |
xsd:dateTime: 2001-10-26T21:32:52 → HL7 DTM: 20011026213252
xsd:date: 2001-10-26 → HL7 DTM: 20011026
2:B.2.3.2.6 PID-8 Administrative Sex
The sex and gender of a patient (or a newborn) cannot exactly be mapped from [ISO/IEEE 11073-10207:2017] to [HL7 V2]. The BICEPS model only contains an attribute for sex (pm:PatientContextState/pm:CoreData/pm:Sex) as defined by biological and physiological characteristics. [HL7 V2], on the other hand, only provides a field for the administrative sex as defined by the socially constructed roles, behaviours, activities, and attributes that a given society considers appropriate. The biological sex, however, does not necessarily match a person’s administrative gender or sex. Mapping from one to the other would therefore introduce errors. However, in the clinical context of a PoCD the sex for clinical use is important for various algorithms, range and limit settings, and so on.
In order to avoid an erroneous mapping of potentially different sex concept interpretations, the sex as defined in BICEPS is required to be mapped to a separate OBX segment as defined in R8120.
Mappings to the PID-8 Administrative Sex field are allowed in certain cases as defined in R8121 and R8107.
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
---|---|---|---|
OBX-1 |
Set ID - OBX |
Please refer to the [IHE PCD TF-2:2019] OBX-1 Set ID - OBX for further information. |
|
OBX-2 |
Value Type |
Set to "ST". |
|
OBX-3/CWE-1 |
Identifier |
Set to LOINC code "46098-0". |
|
OBX-3/CWE-2 |
Text |
Set to LOINC fully-specified name "Sex". |
|
OBX-3/CWE-3 |
Name of Coding System |
Set to coding system "https://loinc.org". |
|
OBX-4 |
Observation Sub-ID |
Set to "<MDS>.0.0.3" where <MDS> is the number of the MDS level assigned by the gateway. See Appendix 2:B.3.4.6.4 for further information. |
|
OBX-5 |
Observation Value |
pm:PatientContextState |
Note that the HL7 Administrative Sex value set (HL7 table 0001) differs from the SDC pm:Sex value set and requires a mapping accordingly (see also Table 2:B.2.3.2.6-3). |
OBX-11 |
Observation Result Status |
When the patient context has been associated and a new @BindingStartTime has been set, the field is set to final result status "F". When there are further updates of the sex value after the association of the patient context, the field is set to "C". |
|
OBX-14 |
Date/Time of the Observation |
pm:PatientContextState |
Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also Example 2). |
HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
---|---|---|---|
PID-8/IS-1 |
Administrative Sex |