IHE Devices
Technical Framework Supplement
Service-oriented Device Point-of-care
Interoperability (SDPi)
Revision 1.1.0 — Trial Implementation
Publication Date: |
July 21, 2023 |
Build Date: |
2023-07-20 07:17:08 UTC |
Author: |
Devices Technical Committee / DPI Program |
Email: |
Please verify you have the most recent version of this document. See HERE for Trial Implementation and Final Text versions and HERE for Public Comment versions.
Foreword
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 July 21, 2023 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 some text bold underline. Where the amendment removes text, make the removed text bold strikethrough. When entire new sections are added, introduce with editor’s instructions to “add new text” or similar, which for readability are not bolded or underlined.
General information about IHE can be found at IHE.
Information about the IHE Devices domain can be found at IHE Domains.
Information about the organization of IHE Technical Frameworks and Supplements and the process used to create them can be found at Profiles and IHE Processes.
The current version of the IHE Devices Technical Framework can be found at DEV Technical Framework.
Introduction to this Supplement
|
SDPi 1.1 Supplement — Trial Implementation Version — Note: This release of the SDPi 1.1 Trial Implementation supplement establishes a quarterly update cadence, enabling prototyping and testing of device-to-device plug-and-trust interoperability. It is recognized, though, that this is an incremental 1.1 release and in that sense is understandably incomplete with work continuing for 1.2 and subsequent versions. These known limitations include:
|
Supplement Forward Declarations
|
SDPi Supplement Version Note: The following table is included in this version of the supplement to capture "forward" declarations of acronyms and labels that are used in the text but are not intended to be part of the General Introduction Appendix D Glossary. "Forward" means that they are used BEFORE the document section in which they are formally defined. Since AsciiDoc is a one-pass processor, forward declarations are required. There was no clear way of defining these replacement definitions in a way that is "under the hood" and not visible to the reader. The following table was thus created but may be moved or otherwise implemented in subsequent supplement versions. Suggestions appreciated!
|
| 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.1 version of the supplement has begun to take small steps toward support of these objectives, especially Requirements Interoperability, as well as the use of AsciiDoc metadata to annotate the document sources for post-processing. Clearly, moving toward Model-Centric (MC) specifications and full integration of Model-Based Systems Engineering (MBSE) (MBSE) will take considerable effort and time; however, this supplement represents a humble start in that direction. Subsequent supplement versions will build upon these objectives and support a new level of rigor for connectathon and product conformity assessment testing and ultimately test reports that directly impact the challenges around medical product regulatory submissions.
Additional discussion is provided in Appendix 1:A, and on the Gemini project’s confluence pages. See also related discussions on the Gemini Project’s Pathway to an Ecosystem of Plug-and-Trust Products.
SDPi Issue Management
SDPi "Topic of Interest" Issue Management
All SDPi supplement issues are tracked in the IHE Github 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
Closed Issues
Time synchronisation requirements may contradict BPKP requirements
Security Requirements & Considerations section missing from 1:10.5.4
Collection of SUGGESTIONS on Vol. 0 & 1, discussed and triaged
Consider mapping pm:AbstractMetricDescriptor/@metricAvailability to HL7
Collected reviewer feedback to B.2 SDPi Gateway reviewer question
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 Supplement Version Note: The content below is verbatim from the IEEE permission letter. An abbreviated version may be provided in subsequent supplement versions with a reference to the complete letter. The copyright language will need to be updated to support the PKP standards (e.g., [IEEE 11073-10700:2022]. It may also need to be updated for [IEEE 11073-10101:2020], which is needing to be renewed. Note that NIST and the RTTMS tools are a key factor in the nomenclature aspect of the licensing discussion. |
IEEE® and IEEE 11073® are registered trademarks of the The Institute of Electrical and Electronics Engineers, Inc. IEEE has granted permission to IHE 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. |
|
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 |
||
DEV-46 |
Reserved |
|
DEV-47 |
Reserved |
|
DEV-48 |
Reserved |
|
DEV-49 |
Reserved |
|
DEV-50 |
Reserved |
Appendix D Glossary
SDPi Supplement Version Note: The General Introduction Appendix D Glossary in this initial version of the supplement includes all terms and acronyms that are utilized throughout the other volumes. Subsequent versions of the supplement may re-locate items to other tables and sections within the technical framework. To help differentiate between various classes or categories of terms, a new "Type" column has been added. This could enable future dynamic resorting of the table by those users who are interested in, for example, only organizational definitions. Finally, a References column has been added to pull this information out of the Definition column. |
Add the following new or updated glossary terms to the IHE Technical Frameworks General Introduction Appendix D. |
| New Glossary Term | Definition | Synonyms | Acronyms / Abbreviation | References | Type |
|---|---|---|---|---|---|
The primary United States SDO recognition and facilitation organization. See ANSI.org for more information. |
Organization |
||||
General reference to the abstract, implementation technology independent SDC components defined in the ISO/IEEE 11073-10207 standard. (See [ISO/IEEE 11073-10207:2017]) |
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.9.3. |
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 |
wsa |
||
wsd |
||
wse |
||
wsm |
Volume 1 — Profiles
1:2 Devices Integration Profiles
|
SDPi Supplement Version Note: This supplement is being written after the 2019 reorganization of the IHE Patient Care Devices (PCD) domain to the IHE Devices (DEV) domain. It is intended to amend a new IHE DEV Technical Framework (TF), that covers the expanded areas not only of PCD devices (enterprise integration focused), but also Personal Connected Health (PCH) devices and Device Point-of-care Interoperability (DPI) for device-to-device integration around an acute point-of-care (e.g., operating room table, ICU bed, emergency department bed, etc.). As a result of these basic changes in the scope and organization of the IHE DEV domain, some additional TF sections have been proposed to help the community understand how these technical specifications are integrated. For example,
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 & Security Considerations and Requirements
IHE specifications often include sections for "Security Considerations" and "Safety Considerations", capturing both general and specific guidance and requirements for system implementers. This supplement extends these two concepts to include a third: Effectiveness. The sections are termed: Safe Effective & Secure (SES) Considerations.
The background for SES is discussed in detail in Appendix 1:A.2; however, in general "SES" is used as a reference to the standards encompassed (directly and indirectly by reference) in ISO/IEC Joint Working Group 7 (JWG7), including [ISO/IEC 81001-1:2021] and [ISO/IEC 80001-1:2021]. These standards are primarily, though not exclusively, focused on risk management of health software (including SaMD) and medical devices that are deployed on various kinds of infrastructure, with a focus to managing three key properties: Safety, Effectiveness and Security. Thus the "SES Considerations" sections in this supplement are intended to reflect the results of that risk management and to guide those who are tasked with deploying and managing these interoperable solutions during use.
Note that specific requirements from the above mentioned standards, may also be captured in Appendix 1:B.2. Generally, requirements from these standards would be mapped to the appropriate SES Considerations sections throughout the specification.
1:2.3 Integration Profiles Overview
|
SDPi Supplement Version Note: The template for this section assumes that it will be integrated with the technical framework section that is organized based on TF-1 section headings (e.g., chapter 10 for SDPi- would have a summary here as 2.10. No provision is made, though, for general introductory sections such as the SDPi Overview & Framework discussion below. In this version, the content is added as 2.3.1, and then the profiles as 2.3.10 to 2.3.13. Though the content is valid, it may be repositioned in subsequent versions to better integrate with the IHE DEV TF at a future date. Omitted from this version are profile-specific option summaries (e.g., 3.10.1?). It is unclear where to best place this content, and they are listed explicitly in each profile’s detailed specification. |
1:2.3.1 Service-oriented Device Point-of-care Interoperability (SDPi) – Overview & Framework
The Service-oriented Device Point-of-care Interoperability (SDPi) Profiles are built upon a foundation of standards and profiles from HL7, IEEE, IHE and other organizations. An overview of the profiles and their relationships is provided in Figure 1:2.3.1-1.
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 2023).
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 Supplement Version Note: For SDPi 1.1, 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.1 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 2023 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. Whereas the related SDPi Profiles for reporting, alerting and external control are explicitly intended to support medical care capabilities, the SDPi-P Profile focuses on basic healthcare device interoperability. All the capabilities defined in SDPi-P are leveraged by and extended in the medically focused profiles. This foundational profile not only supports medical device interoperability ("MDI"), providing for “plug-and-play” capabilities, but also with a tightly integrated “trust” framework (see Appendix 1:A). The establishment of a trusted ecosystem of medical and non-medical devices and applications [2] begins at the start of discovery and a secure connection. Therefore, the profile’s name: Plug-and-Trust (PnT).
This is primarily an IHE transport profile [3], although it does define several content modules detailed in IHE Devices TF-3. It supports the transactions and information exchanged in accordance to a Service-Oriented Architecture (SOA) specialized for high-acuity points of care (e.g., operating table or ICU bed), defined as a Service-oriented Medical Device System (SOMDS). All the SDPi-P actors are therefore scoped with “SOMDS” to clearly identify their application context and scope.
Although all information exchanged between SDPi-P SOMDS participating systems and applications must conform to the basic SDC/BICEPS content module requirements [4], content modules have been defined for common high-acuity medical devices such as infusion pumps, ventilators and physiologic monitors.
Note that future IHE workflow profiles may be defined that build upon the transport & content module foundation established by the SDPi-P profile. For example, Operating Room / Surgery Point-of-Care Integration, ICU Point-of-Care Integration, or more service-focused profiles such as Point-of-Care Identity Management (PCIM) for device-patient association management, or Silent ICU & Quiet Hospital, where the acute point-of-care is integrated with enterprise systems around device alerting and alert distribution to provide an improved environment of care (reduced noise level and improved safety) and clinician interaction.
1:10.1 SDPi-P Actors, Transactions, and Content Modules
|
SDPi Supplement Version Note: For SDPi 1.1 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.1-1. Abstract actors (i.e., those that provide common specifications that are utilized in other “concrete” or implementation actors) are indicated by stereotype names in italics (e.g., "<< SOMDS_Participant >>". The actors that inherit their capabilities include the stereotype at the top of their actor box. Alternatively, in accordance with traditional IHE style, the Abstract actor’s name can be in italics with "{abstract}" (e.g., see SOMDS Connector in Figure 1:10.1-1). Actor groupings, including abstract with concrete are detailed in Section 1:10.3.
Table 1:10.1-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 |
|||
Receiver (See Note 2) |
O |
|||
Initiator |
R |
|||
Initiator |
R |
|||
Discover System Context and Capabilities (deferred) |
Initiator |
R |
Deferred to SDPi 1.x |
|
Initiator |
R |
|||
Receiver (See Note 2) |
O |
|||
Receiver (See Note 2) |
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 2) |
O |
|||
See Note 3 |
… |
… |
… |
|
SOMDS FHIR Gateway (deferred) |
… |
… |
… |
… |
See Note 3 |
… |
… |
… |
|
SOMDS Sensor Gateway (deferred) |
… |
… |
… |
… |
SOMDS Smart App Platform (deferred) |
… |
… |
… |
… |
Note 1: “Notify Change in System Context and Capabilities” is required if there are dynamic changes that may need to be sent to subscribing systems. Note 2: “Receiver” is included in this column, in italics, to indicate that though a SOMDS Consumer may "receive" the transaction, there is no response communicated to the message initiator. Note 3: SDPi Version Note: — Full detailing of the transactions related to this actor will be addressed in a subsequent version of this specification. |
||||
Figure 1:10.1-2 shows the content-related actors defined in the SDPi-P Profile and the direction that the content is exchanged.
In general, the SOMDS Provider 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 Supplement Version Note: For SDPi 1.1, 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 Supplement Version 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 Supplement Version 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.2 SDPi-P Actor Options
|
SDPi Supplement Version Note: Profile options are out-of-scope for this version of the supplement. Future versions MAY include options such as the following (not in priority order):
|
1:10.3 SDPi-P Required Actor Groupings
|
SDPi Supplement Version Note: As indicated in Figure 1:10.1-1 above, there are no explicit grouped actors in this 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 searating 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 Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:10.4.1.4 Ensuring Time Synchronization
|
SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:10.4.1.5 Waveform Communication
|
SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:10.4.1.6 Aggregators, Proxies, Sensors
|
SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:10.4.1.7 Protocol-Specific Gateways
|
SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:10.4.1.8 Smart App Platforms
|
SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:10.4.1.9 Workflow vs. Transport Actors and Interactions
|
SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:10.4.1.10 SDC / BICEPS MDIB Versioning Management
|
SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:10.4.2 Use Cases
The SDPi-P Profile supports requirements from use cases detailed in Appendix 1:C. The following subsections identify the specific use case requirements that are fulfilled with capabilities provided by this 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, Security Considerations and Requirements
1:10.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Section Appendix 1:A.4.
1:10.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:10.5.3 Effectiveness Requirements & Considerations
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 Supplement Version 1.1 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, 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 Supplement Version Note: The HL7 FHIR resources and related Point-of-Care Device FHIR Implementation Guide (PoCD FHIR IG) is still under active development. Initial mappings have been made from SDC to FHIR; however, they are not yet ready for profiling and product implementation. When the FHIR specifications are finalized, then this actor will be fully specified in a future SDPI Supplement version. See SOMDS FHIR Gateway for additional information. |
1:11.2 SDPi-R Actor Options
1:11.2.1 Retrieve Remote Data
|
SDPi Supplement Version Note: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi Supplement. This option will enable SOMDS Medical Data Consumer systems to access information in remote systems that are not part of its SOMDS network instance. This access will be provided by either a SOMDS DEC Gateway or SOMDS FHIR Medical Data Gateway. For example, retrieving the latest laboratory information for a specific patient. |
1:11.3 SDPi-R Required Actor Groupings
|
SDPi Supplement Version Note: As indicated in Figure 1:11.1-1 above, there are four grouped actors: This section will be more completely detailed in a future version of the supplement. |
1:11.4 SDPi-R Overview
1:11.4.1 Concepts
|
SDPi Supplement Version Note: An overview of the concepts for this SDPi-R Profile will be provided in a future supplement version. Note that this 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, Security Considerations and Requirements
1:11.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
A primary source of safety requirements for this SDPi-R Profile come from the [IEEE 11073-10701:2022] Metric Participant Key Purposes (PKP) standard.
|
SDPi Supplement Version 1.1 Note: The [IEEE 11073-10700:2022] and [IEEE 11073-10701:2022] standards are currently being published by the IEEE. Once published, their requirements will be integrated into this supplement, with many of them being mapped to elements in this SDPi-R Profile. |
For additional guidance, see Section Appendix 1:A.4.
1:11.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:11.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:11.5.4 Security Requirements & Considerations
No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P Profile (see Appendix 1:A.3), and those specified in the SES General Considerations Section above.
1:11.6 SDPi-R Cross Profile Considerations
No additional cross profile considerations have been identified.
1:12 Service-oriented Device Point-of-care Interoperability - Alerting (SDPi-A) Profile
|
SDPi Supplement Version 1.1 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 late 2023 or early 2024, its requirements will be integrated into this supplement, with its Implementation Conformance Statement (ICS) added to Appendix 1:B.2. Many of those requirements will be mapped to the actors, transactions and other specifications in this 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 Supplement Version 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 Supplement Version Note: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi Supplement. This option will enable SOMDS Medical Alert Provider systems to safely and reliably receive from SOMDS Medical Alert Consumer systems user (clinician) acknowledgement of previously reported alert conditions. This option will enable the Update Alert Acknowledgement Status [DEV-43] transaction. |
1:12.2.3 Remote Alert Signaling
|
SDPi Supplement Version Note: This section is left intentionally blank to indicate capabilities that will be added in a future version of the SDPi Supplement. This option will enable SOMDS ACM Gateway systems to receive [DEV-04]/[PCD-04] transactions from an ACM Alert Manager and then act as a SOMDS Medical Alert Provider to communicate the signals to SOMDS Medical Alert Consumer systems This option will enable the SOMDS ACM Gateway to respond to 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 Supplement Version 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 Supplement Version 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, Security Considerations and Requirements
1:12.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Section Appendix 1:A.4.
1:12.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:12.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:12.5.4 Security Requirements & Considerations
No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P Profile (see Appendix 1:A.3), and those specified in the SES General Considerations Section above.
1:12.6 SDPi-A Cross Profile Considerations
No additional cross profile considerations have been identified.
1:13 Service-oriented Device Point-of-care Interoperability – external Control (SDPi-xC) Profile
|
SDPi Supplement Version Note: This SDPi-xC (External Control) Profile Section is generally out-of-scope for the SDPi 1.1 version (see wiki article "SDPi Version 1.1 (Detail)"); however, it is provided here to indicate the intended direction of the SDPi Profiles, with details being added in subsequent versions. Depending on capabilities, some very basic controls may need to be provided in 2023 as part of the 1.x or 2.0 versions, especially around external adjustment of settings (e.g., alert limits or to trigger a blood-pressure reading). |
The SDPi-External Control ( SDPi-xC) Profile enables external or "remote" control of one device by another. This may be as simple as adjust an alarm limit or triggering a blood pressure cuff reading, to adjusting a respiration rate on a ventilator or titrating a drug dose rate on an infusion pump. Specializes services and semantics are provided to enable safe and secure control invocation.
1:13.1 SDPi-xC Actors, Transactions, and Content Modules
This section defines the actors, transactions, and/or content modules in this 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 Supplement Version 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 Supplement Version 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 Supplement Version Note: For SDPi 1.1, 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, Security Considerations and Requirements
1:13.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Section Appendix 1:A.4.
1:13.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:13.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:13.5.4 Security Requirements & Considerations
No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P Profile (see Appendix 1:A.3), and those specified in the SES General Considerations Section above.
1:13.6 SDPi-xC Cross Profile Considerations
No additional cross profile considerations have been identified.
Appendix 1:A Requirements Management for Plug-and-Trust Interoperability
|
SDPi Supplement Version Note: This appendix provides informative (vs. normative) information related to the unique way in which this supplement integrates requirements, both from referenced foundational standards and within this specification. For SDPi 1.1, given its non-normative nature, full detailing of the concepts and specifications is deferred to a subsequent revision of the specification. So, please excuse the incomplete sections with "placeholder" version notes! There is value, though, in giving the existing content a quick review and providing feedback that would inform subsequent revisions of the specification. |
These SDPi specifications include the model-centric integration of requirements from multiple sources — both within IHE and from other SDOs — enabling a new level of requirements management that provides new value to all stakeholders. Also termed Requirements Interoperability (RI), innovative capabilties include:
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 this 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 requirements, detailing clinical system functions ensure that all requirements and capabilities are rooted in the purposes that technology users are advancing, namely to provide safe;
<inter layer interfaces Requirements → Capabilities API, Req Def → Req Usage >;
<Standards groups / families - internally coherent … hopefully!>;
<Vertical / horizontal>;
<profiles navigate 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!>;
<requirements interoperability traces "profile lines" from top to bottom>;
<requirements TYPEs are rooted in the layers that they represent and link Defs to Usage, see Appendix 1:A.6.1 Section below.>.
| The implementation of this framework will be extended as the specifications and tooling mature. |
1:A.2 Integrating Safety, Effectiveness & Security Requirements & Considerations
In 2007, a joint effort between ISO/TC 215 and IEC/SC 62A was launched — Joint Working Group 7 (JWG7) — to focus on how to apply risk management to medical devices and health information systems and software that needed to interoperate on shared (hospital owned & managed) networking infrastructure. The resulting standard, [ISO/IEC 80001-1:2021], with a first edition published in 2010 and revised in 2021, not only provided a process for performing coordinated multi-stakeholder risk management for these technologies, but recognized the three key properties that would be the focus of that risk management: Safety, Effectiveness & Security (SES) [8].
During the development of the 80001-1 standard, though, it was recognized that risk management is just one of a number of other core themes that had to be managed in concert (e.g., quality management, human factors / usability). Also ensuring SES required processes that involve a total product lifecycle, with responsibilities transitioning across that period. To address these requirements, JWG7 developed the [ISO/IEC 81001-1:2021] standard, which also included The Temple diagram to communicate various aspects of SES that must be considered and managed:
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, Security Considerations and Requirements" 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 SES Considerations sections grew out of the IHE "Security Considerations" sections + the IHE Devices "Safety Considerations" sections, but are now consolidated into a single SES Considerations section that integrates the 3rd risk management property, Effectiveness. Whenever possible, each of these considerations should be associated with the requirements of specific standards (e.g, [IEEE 11073-10700:2022]).
| The moniker SES+MDI is shorthand to refer to the integration of the technical medical device interoperability (MDI) specifications with the application of quality / risk management SES standards and processes. |
How does this address the "interoperability trust gap"? By integrating SES directly into the specifications, especially integrating the ISO/IEC 11073-1070x standards, enabling "plug-and-trust" system product components, the SES implementation and operational requirements and responsibilities are greatly reduced, the "gap" is filled for all stakeholders, and the goals of improved safety, security and clinical effectiveness of technology can be readily realized.
1:A.3 SES Considerations Section Template
|
SDPi Supplement Version Note: For SDPi 1.1, the inclusion of SES Considerations sections is early and will be significantly extended in subsequent versions of the specification. Especially when requirements from the PKP standards are included in SDPi 1.2 and following. |
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.
1:A.4 Safety, Effectiveness, Security Considerations and Requirements
1:A.4.1 SES General Considerations
| This section includes guidance and requirements that are not further specialized for specific SES properties. |
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Section Appendix 1:A.4.
1:A.4.2 Safety Requirements & Considerations
| This section includes guidance and requirements that are focused on unique Safety requirements associated with associated technical framework element. Note: a simple definition of safety within the context of risk management is "freedom from unacceptable harm" (see 81001.org/safety) |
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:A.4.3 Effectiveness Requirements & Considerations
| This section includes guidance and requirements that are focused on unique Effectiveness requirements associated with associated technical framework element. Note: in the context of risk management key properties, effectiveness is the ability to perform the intended use (see 81001.org/effectiveness) |
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
1:A.4.4 Security Requirements & Considerations
| This section includes guidance and requirements that are focused on unique Security requirements associated with associated technical framework element. In the context of risk management key properties, security is a state where information and systems are protected from unauthorized activities to a degree that the related risks to confidentiality, integrity, and availability are maintained at an acceptable level throughout the lifecycle (see 81001.org/security) |
No additional security requirements and considerations are identified for this technical framework element beyond those provided by the SDPi-P profile, and those specified in the SES General Considerations Section above.
1:A.5 Use Cases, MBSE Requirements Modeling & SysML 2.0
|
SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
OMG's Systems Modeling Language 2.0 (see [OMG SysML ® 2.0] and [OMG SysML ® Intro-Graphical Notation 2.0]), provides extended support for requirements modeling that not only provides the foundation for MBSE’s Requirements Modeling, but also a computable specification that enables automated verification (e.g., using "Verification Cases").
1:A.6 SDPi Requirements Modeling & Integration
As pointed out above, requirements interoperability (RI) based on robust model-based metadata is a core, innovative aspect of this SDPi Profiles specification. Given the ultimate intent to realize this description as a Model Centric (MC) single-source-of-truth, computable, simulatable, verifiable and validatable system of systems interoperability specification, and recognizing that it will take a significant transition period from a document-centric approach to a model-centric approach, a simplified requirements model is provided below but is aligned with the [OMG SysML ® 2.0] Section 7.20 Requirements language. Of course, that specification provides for significantly more detailed and complex modeling, the general constructs may be used in this document to start the transition toward that model. Note that SysML 2.0 also better supports model interoperability (tool-independent model exchange) and Model-Based Systems Engineering (MBSE) (see MBSE Wikipedia article and references), as well as the [IHE EU Experience-2021 IHE CA for MedTech Solutions] for an overview presentation of MBSE, MedTech system V&V, and IHE Conformity Assessment.
It should be further noted that though conformity testing aspects are beyond this revision of the SDPi specification, the modeling constructs used below will also be integrated with [OMG SysML ® 2.0] Section 7.23 Verification Cases, to provide for advanced V&V of interoperable system components and entire systems of products.
1:A.6.1 SDPi Requirements Core Model
To formally integrate requirements in to this specification, the following requirements model provides the starting point:
This model identifies a set of requirement "types" that are formalized in the specification. Each type is a source of requirements that are explicitly identified and formalized with appropriate metadata.
| Model Element | Description | AsciiDoc Attribute | Further Specified |
|---|---|---|---|
SDPi Requirement |
A defined stakeholder-imposed constraint that must be satisfied for a design solution to be valid. This is an {abstract} class model element. |
sdpi_requirement |
See subtypes |
SDPi Requirement Group |
Two or more SDPi Requirements may be collected into a group that is focused around a specific subject area. |
sdpi_requirement_group |
|
Usage |
Requirement utilized in a specific use context that provides for its satisfaction. |
sdpi_requirement_usage |
|
Use Case Feature |
A functional "feature" requirement based on clinical use case scenarios. |
sdpi_requirement_use_case |
See TF-1 Appendix C, gherkin model |
Ref. Standard ICS |
Requirement definitions that are specified in a normative reference. |
sdpi_requirement_ref_standard |
|
SES |
sdpi_requirement_ses |
See SES Section Appendix 1:A.2 |
|
Tech Feature |
sdpi_requirement_tech_feature |
1:A.6.2 Requirements Binding Strategies
Although Figure 1:A.6.1-1 generally indicates bi-directional navigation (arrows on both ends of Requirement-Usage pairs, supporting bi-directional bindings and navigation is not always helpful. This is especially the case when considering potential future updates to the profile specifications. In that case, the general rule is:
Add backward references from Requirement Usage to Requirement Definition.
For example, in TF-2 Transactions, each transaction section is paired with a message transport section in Appendix 2:A; however, future versions of the specification may provide options for alternative transports. In this case, the actual transaction definition will remain unchanged, but the bindings to transport messages and services would change. Given the rule above, bindings are made in the current TF-2 Appendix A MDPWS 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 and not the rule.
1:A.6.3 Alignment with SysML 2.0 Requirements Modeling
|
SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:A.6.4 Relationship to Gazelle Master Model + Assertion Tool Model
|
SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
Appendix 1:B References
SDPi Supplement Version Note: The inclusion of a References appendix is unique for IHE Technical Framework specifications. Typically, referenced standards sections are distributed throughout the specifications where appropriate; however, standards from other organizations (e.g., IEEE, ISO, IEC) typically have a "Normative References" clause and when desired a "Bibliography" clause. Also, integration of explicit standards' Implementation Conformance Statement (ICS) specifications (e.g., [ISO/IEEE 11073-10207:2017] ICS tables) is unique, but needed to support requirements interoperability. Ultimately, the content of this appendix may be rearranged and even relocated; however, for early versions of the SDPi supplement, it has proven helpful, and even of critical importance and value. |
1:B.1 Referenced Standards
[AAMI 2700-1:2019] AAMI 2700-1:2019 Medical Devices And Medical Systems - Essential Safety And Performance Requirements For Equipment Comprising The Patient-Centric Integrated Clinical Environment (ICE) - Part 1: General Requirements And Conceptual Model, available at ANSI/AAMI web store.
[HL7 FHIR] HL7® Fast Healthcare Interoperability Resources (FHIR®), available at hl7.org/fhir/.
[HL7 FHIR Point-of-Care Device Implementation Guide] HL7 FHIR Point-of-Care Device Implementation Guide, drafts available on the Devices on FHIR project page, and a continuous build version at Point-of-Care Device Implementation Guide web page.
[HL7 V2] HL7® Version 2 (V2), available at HL7 Version 2 Product Suite web page.
[IEC 60601-1-8:2020], IEC 60601-1-8:2006/AMD2:2020, Medical electrical equipment — Part 1-8: General requirements for basic safety and essential performance — Collateral standard: General requirements, tests and guidance for alarm systems in medical electrical equipment and medical electrical systems; Amendment 1:2020, and Amendment 2:2020. available at IEC Webstore and the ISO standards store.
[IEEE 11073-10101:2020] IEEE 11073-10101™ International Standard - Health informatics—Device interoperability—Part 10101:Point-of-care medical device communication—Nomenclature. Available at hhttps://standards.ieee.org/ieee/11073-10101/10343/[IEEE online standards store].
[IEEE 11073-10201:2004] IEEE 11073-10201™ International Standard - Health informatics—Device interoperability—Part 10201:Point-of-care medical device communication—Domain information model. Note this was updated in 2020. Available at IEEE online standards store.
[ISO/IEEE 11073-10207:2017] ISO/IEEE 11073-10207-2017, Health informatics — Point-of-care medical device communication — Part 10207: Domain Information and Service Model for Service-Oriented Point-of-Care Medical Device Communication, 2017-12, available at https://standards.ieee.org/ieee/11073-10207/6032 [1]
[IEEE 11073-10700:2022] IEEE P11073-10700™/D7 Draft Standard for Health Informatics – Device Interoperability – Part 10700: Point-of-Care Medical Device Communication – Standard for Base Requirements for Participants in a Service-Oriented Device Connectivity (SDC) System.
[IEEE 11073-10701:2022] IEEE P11073-10701™/D4 Draft Standard for Health Informatics – Device Interoperability – Part 10701: Point-of-Care Medical Device Communication - Metric Provisioning by Participants in a Service-Oriented Device Connectivity (SDC) System
[IEEE 11073-10702:202x] IEEE P11073-10702™/D1 Draft Standard for Health Informatics – Device Interoperability – Part 10702: Point-of-Care Medical Device Communication – Alert Provisioning by Participants in a Service-Oriented Device Connectivity (SDC) System
[IEEE 11073-10703:202x] IEEE P11073-10703™/Draft Standard for Health Informatics – Device Interoperability – Part 10703: Point-of-Care Medical Device Communication – External Control by Participants in a Service-Oriented Device Connectivity (SDC) System, in development.
[ISO/IEEE 11073-20701:2018] ISO/IEEE 11073-20701-2018, Health informatics — Point-of-care medical device communication — Part 20701: Service-Oriented Medical Device Exchange Architecture and Protocol Binding, 2018-09, available at https://standards.ieee.org/ieee/11073-20701/6059
[ISO/IEEE 11073-20702:2016] ISO/IEEE 11073-20702-2016, Health informatics — Point-of-care medical device communication — Part 20702: Medical Devices Communication Profile for Web Services, 2016-09, available at https://standards.ieee.org/ieee/11073-20702/6034
[ISO/IEC 80001-1:2021], IEC 80001-1:2021 Application of risk management for IT-networks incorporating medical devices — Part 1: Safety, effectiveness and security in the implementation and use of connected medical devices or connected health software. Available at IEC Webstore and ISO standards store.
[ISO/IEC 81001-1:2021], ISO 81001-1:2021 Health software and health IT systems safety, effectiveness and security — Part 1: Principles and concepts. Availabe at ISO standards store and IEC Webstore.
[IHE PCD TF-1:2019] IHE Patient Care Device Technical Framework, Vol. 1, available at https://www.ihe.net/uploadedFiles/Documents/PCD/IHE_PCD_TF_Vol1.pdf.
[IHE PCD TF-2:2019] IHE Patient Care Device Technical Framework, Vol. 2, available at https://www.ihe.net/uploadedFiles/Documents/PCD/IHE_PCD_TF_Vol2.pdf.
[IHE PCD TF-3:2019] IHE Patient Care Device Technical Framework, Vol. 3, available at https://www.ihe.net/uploadedFiles/Documents/PCD/IHE_PCD_TF_Vol3.pdf.
[RFC 3986] T. Berners-Lee et al., RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, January 2005, available at https://www.rfc-editor.org/rfc/rfc3986
[OASIS DPWS:2009] OASIS Standard, Devices Profile for Web Services Version 1.1, OASIS Standard, 1 July 2009, available at http://docs.oasis-open.org/ws-dd/dpws/wsdd-dpws-1.1-spec.html
[OASIS SOAP-over-UDP Version 1.1] OASIS Standard, SOAP-over-UDP Version 1.1, July 2009, available at http://docs.oasis-open.org/ws-dd/soapoverudp/1.1/os/wsdd-soapoverudp-1.1-spec-os.docx.
[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 Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:B.2.2 Overview of Standards Conformity Statements
|
SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:B.2.3 ISO/IEC 11073-10207 BICEPS ICS Tables
SDPi Supplement Version Note: This section is provided as a placeholder for the ICS table specification that will be added in the subsequent SDPi 1.2 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 Supplement Version 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. Especialy helpful would be references to related standards and materials that would inform the approach taken in this appendix. |
1:C.1.1 Rich History of Medical Device Interoperability (MDI) Use Cases
The vision of plug-and-play medical device interoperability has been an active pursuit since the early 1980’s, with the IEEE 1073 group’s formation in those early years. Over the 40+ years, many projects — both industry and standards-based — have contributed to an ever growing set of real-world use cases, and the ISO/IEEE 11073 SDC program is no different.
Looking to leverage this wealth of use cases in considering SDPi, a "compendium of medical device oriented use cases" was created to facilitate referencing and use. The use cases detailed in this appendix build on those that are captured in this document: [IHE PCD SDPi Use Cases Compendium:2019]
1:C.1.2 Overview of Architectural & Business Systems Concepts
|
SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:C.1.3 Use Case Specification Conventions Using Cucumber/Gherkin
|
SDPi Supplement Version Note: This section contains initial content that will be greatly expanded in future versions. |
Each Use Case (also called a Feature in Gherkin) is organized as follows:
Narrative – a description of the desired functionality from the user perspective
Technical View - graphic representation of typical business system actors utilized in this use case
Technical Pre-Conditions – any assumptions or pre-conditions
Scenario(s) – the scenarios explore both the Happy Path when everything goes according to plan and the Alternative Paths where things do not go according to plan.
1:C.1.4 Use Case Requirements Modeling
|
SDPi Supplement Version Note: This section intentionally left blank for the current version, but is a placeholder for content that will be added in the future. |
1:C.1.5 Application of ISO/IEC 60601-1-8 Concepts & Definitions
1:C.1.5.1 ISO/IEC 60601-1-8 Concepts for DIS, DAS and CDAS
The following is a quick guide to the functionality of DIS, CDIS, DAS and CDAS systems and how we have used and interpreted them for the purpose of this IHE Profile Supplement. Please refer to the next section on Definitions from [IEC 60601-1-8:2020] for normative definitions for these terms.
| Note that the 1.1 version of the SDPi Profile only supports the Distributed Information System (DIS) model detailed below. The other models are anticipated for subsequent versions. |
1:C.1.5.1.1 DIS – Distributed Information System
DIS is a system for reporting alarm signals with no technical confirmation (of receipt).
Cannot rely on it for alarm signaling as a risk control
Optional support operator alarm management response locally
Example — patient remote display, hallway display, one-way pager
1:C.1.5.1.2 CDIS – Distributed Information System with Confirmation
CDIS is a system for reporting alarm signals with no technical confirmation but with operator confirmation (accept/reject).
| CDIS is not recognized in 60601-1-8, however it is implemented in practise and therefore included |
Cannot rely on it for alarm signaling as a risk control
Optional support operator alarm management response locally and remotely
Example –- two-way pager (open loop)
1:C.1.5.1.3 DAS – Distributed Alarm System
DAS is a system for reporting alarm signals with technical confirmation (of receipt).
Can rely on it for alarm signaling as a risk control
Optionally supports local alarm management (alarm acknowledgement)
A communications failure or failure in any remote component of the DAS must initiate a technical alarm.
Example — Central Station
1:C.1.5.1.4 CDAS - Distributed Information System with Confirmation
CDAS is a system for reporting alarm signals with technical and operator confirmation (accept/reject) (of receipt).
Can rely on it for alarm signaling as a risk control
Supports operator confirmation (accept/reject); It may redirect…
Optionally support local/remote alarm management (acknowledgement)
A communications failure or failure in any remote component of the DAS must initiate a technical alarm.
Example — System that sends alarm to caregiver mobile device with accept / reject. Integrator may redirect
| An xDIS can be either a DIS or CDIS. Similarly an xDAS can be either a DAS or CDAS. |
| Description | Type | Technical Delivery Confirmation1 | Operator Delivery Confirmation2 | Optional Alarm Management | Examples |
|---|---|---|---|---|---|
Reports alerts from a single patient (sp) |
DISsp |
No |
No |
Local |
Single-Pt. information Dashboard |
CDISsp |
No |
Yes3 |
Remote3 |
Single-Pt. Remote View w/accept/reject |
|
DASsp |
Yes |
No |
Local |
Single-Pt. Cockpit w/audible alarms |
|
CDASsp |
Yes |
Yes |
Remote |
Single-Pt. Cockpit w/accept/reject |
|
Reports alerts from multiple patients (mp) |
DISmp |
No |
No |
Local |
Multiple-Pt. information Dashboard or View Station |
CDISmp |
No |
Yes3 |
Remote3 |
Multiple-Pt. info. View Station w/accept/reject |
|
DASmp |
Yes |
No |
Local |
Multiple-Pt. Central Station w/audible alarms |
|
CDASmp |
Yes |
Yes |
Remote |
Multiple-Pt. Central Station w/accept/reject |
|
Reports and directs alerts to responsible caregiver (cg) |
DIScg |
No |
No |
Local |
Alerts to caregiver pager, Mobile viewer |
CDIScg |
No |
Yes3 |
Remote3 |
Alerts to caregiver pager, w/accept/reject |
|
DAScg |
Yes |
No |
Local |
Alerts to caregiver w/audible/haptic signals |
|
CDAScg |
Yes |
Yes |
Remote |
Alerts to caregiver w/accept/reject |
|
1 In each communication step the receiving device provides a technical response to the sending device that it received and is taking responsibility for the alert 2 Operator can, at their choice, use the receiving device (communicator) UI to accept or reject responsibility for the alert 3 Not recommended since there is no confirmation that the Source has received the commands |
|||||
1:C.1.5.2 ISO/IEC 60601-1-8 Definitions for DIS, DAS and CDAS
The following content is extracted directly from the [IEC 60601-1-8:2020] standard for reference purposes. Please consult that standard for comprehensive discussion and complete normative requirements, as well as the "rationale" section, which includes many of the concepts identified in this section.
1:C.1.5.2.1 DIS - DISTRIBUTED INFORMATION SYSTEM ABOUT ALARM CONDITIONS
system that involves more than one item of equipment in a ME SYSTEM intended to provide information about ALARM CONDITIONS but does not guarantee delivery of that information
| NOTE 1: A DISTRIBUTED INFORMATION SYSTEM ABOUT ALARM CONDITIONS is not intended to notify OPERATORS of the existence of an ALARM CONDITION as a RISK CONTROL measure. A DISTRIBUTED INFORMATION SYSTEM ABOUT ALARM CONDITIONS is intended to provide information about an ALARM CONDITION while the OPERATOR is aware of the existence of the ALARM CONDITION by an ALARM SYSTEM. |
| NOTE 2: A DISTRIBUTED INFORMATION SYSTEM ABOUT ALARM CONDITIONS is not intended for confirmed delivery of ALARM CONDITIONS |
Examples include:
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 & Security Considerations and Requirements
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 & Security Considerations and Requirements
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.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 & Security Considerations and Requirements
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 & Security Considerations and Requirements
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 Inccessible to the Dashboard
Given Dashboard cannot detect any assigned accessible ICU devices
Then the Dashboard will display an error message
1:C.4.5.3 Scenario: SICDmp 3.3 - One or more ICU Devices are Inccessible to the Dashboard
Given Dashboard cannot detect any previously assigned accessible ICU devices
Then the Dashboard will display an error message
1:C.5 Use Case Feature 4: Device Data to Enterprise Systems (DDES)
1:C.5.1 Narrative
Mercy Hospital is in the middle of a new EHR (Epic, Cerner, etc.) rollout. Joe Furst is responsible for integrating data from their ICU devices (patient monitors, ventilators, infusion devices, etc.) with the new EHR. Once they are done, the data from the devices will be reviewed/validated by the ICU clinicians and then automatically entered into the patient’s clinical record.
1:C.5.2 Benefits
Automatically feeding patient data from the medical devices to medical record applications reduces the documentation burden on the clinicians, improves the accuracy of the medical record and enables 'real-time' analysis of the data which can be used to generate (potentially AI based) smart alerts to the clinical staff.
1:C.5.3 Technical View
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 signalled at the patient bedside thereby reducing the amount of noise that the patient is subjected to and improving their ability to recuperate.
1:C.6.3 Technical View
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, Security Considerations and Requirements
2:3.23.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Appendix 1:A.4.
2:3.23.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.23.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.23.5.4 Security Requirements & Considerations
This transaction is intended to execute over UNSECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management 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, Security Considerations and Requirements
2:3.24.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Appendix 1:A.4.
2:3.24.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.24.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.24.5.4 Security Requirements & Considerations
This transaction is intended to execute over UNSECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management 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, Security Considerations and Requirements
2:3.25.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Appendix 1:A.4.
2:3.25.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.25.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.25.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management 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, Security Considerations and Requirements
2:3.27.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Appendix 1:A.4.
2:3.27.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.27.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.27.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management 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, Security Considerations and Requirements
2:3.28.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Appendix 1:A.4.
2:3.28.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.28.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.28.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management 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, Security Considerations and Requirements
2:3.29.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Appendix 1:A.4.
2:3.29.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.29.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.29.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management 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, Security Considerations and Requirements
2:3.30.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Appendix 1:A.4.
2:3.30.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.30.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.30.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management 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, Security Considerations and Requirements
2:3.34.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Appendix 1:A.4.
2:3.34.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.34.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.34.5.4 Security Requirements & Considerations
This transaction is intended to execute over UNSECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management 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, Security Considerations and Requirements
2:3.35.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Appendix 1:A.4.
2:3.35.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.35.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.35.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management 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, Security Considerations and Requirements
2:3.36.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Appendix 1:A.4.
2:3.36.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.36.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.36.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management 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, Security Considerations and Requirements
2:3.37.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Appendix 1:A.4.
2:3.37.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.37.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.37.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management 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, Security Considerations and Requirements
2:3.38.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Appendix 1:A.4.
2:3.38.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.38.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.38.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management 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, Security Considerations and Requirements
2:3.39.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Appendix 1:A.4.
2:3.39.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.39.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.39.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management 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, Security Considerations and Requirements
2:3.40.5.1 SES General Considerations
Requirements from the [ISO/IEC 81001-1:2021], [ISO/IEC 80001-1:2021], and related standards should be fully applied to this technical framework element.
For additional guidance, see Appendix 1:A.4.
2:3.40.5.2 Safety Requirements & Considerations
No additional safety requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.40.5.3 Effectiveness Requirements & Considerations
No additional effectiveness requirements or considerations are identified for this technical framework element beyond those specified in the SES General Considerations Section above.
2:3.40.5.4 Security Requirements & Considerations
This transaction is intended to execute over SECURED transmission channels.
Protocol-specific security requirements for this transaction are detailed in the related TF-2 messaging technology appendix. For example, Appendix 2:A for MDPWS-based communication.
Appropriate security risk management 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)
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:MedicalDeviceto 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:Scopesagainst 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:ProbeMatchescan contain multiplewsd:ProbeMatchresults. -
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:Deviceand 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>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
<wsd:AppSequence InstanceId="..." MessageNumber="..."/>
</s12:Header>
<s12:Body>
<wsd:ResolveMatches>
<wsd:ResolveMatch>
<wsa:EndpointReference>
<wsa:Address><!-- ... --></wsa:Address>
</wsa:EndpointReference>
<wsd:Types>dpws:Device mdpws:MedicalDevice <!-- ... --></wsd:Types>
<wsd:Scopes>sdc.mds.pkp:1.2.840.10004.20701.1.1 <!-- ... --></wsd:Scopes>
<wsd:XAddrs><!-- ... --></wsd:XAddrs>
<wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
</wsd:ResolveMatch>
</wsd:ResolveMatches>
</s12:Body>
</s12:Envelope>2:A.2.2.4.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 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:Deviceand 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/@Dialectishttp://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:dpws="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"
xmlns:mdpws="http://standards.ieee.org/downloads/11073/11073-20702-2016"
xmlns:s12="http://www.w3.org/2003/05/soap-envelope"
xmlns:wsa="http://www.w3.org/2005/08/addressing"
xmlns:wsd="http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01">
<s12:Header>
<wsa:Action>http://docs.oasis-open.org/ws-dd/ns/discovery/2009/01/Bye</wsa:Action>
<wsa:MessageID><!-- ... --></wsa:MessageID>
<wsa:To>urn:docs-oasis-open-org:ws-dd:ns:discovery:2009:01</wsa:To>
<wsd:AppSequence InstanceId="..." MessageNumber="..."/>
</s12:Header>
<s12:Body>
<wsd:Bye>
<wsa:EndpointReference>
<wsa:Address><!-- ... --></wsa:Address>
</wsa:EndpointReference>
<wsd:Types>dpws:Device mdpws:MedicalDevice</wsd:Types>
<wsd:Scopes><!-- ... --></wsd:Scopes>
<wsd:MetadataVersion><!-- ... --></wsd:MetadataVersion>
</wsd:Bye>
</s12:Body>
</s12:Envelope>2:A.2.8.1.3 Trigger Events
There are no additional or alternative trigger events other than those defined in Section 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.3 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.4 Amendments and Corrigenda
2:A.4.1 Connection Time Delay
When a SOMDS Provider joins a network and sends out a Hello message, depending on the number of SOMDS Consumers that are interested in the data of that SOMDS Provider, the SOMDS Provider can get overwhelmed by incoming TCP connection requests and TLS handshakes. SOMDS Providers and SOMDS Consumers can implement different actions in order to avoid flooding of TCP connection requests and TLS handshakes under normal operating conditions. Each action comes with individual advantages and disadvantages.
2:A.4.1.1 Provider-controlled Delay
[ISO/IEEE 11073-20701:2018] normatively references [OASIS DPWS:2009] which in turn leverages [OASIS WS-Discovery:2009] to provide distributed (ad-hoc) or centralized (managed) service registries. WS-Discovery decomposes into two message sequences, implicit discovery and explicit discovery of which implicit discovery can lead to loss of performance for SOMDS Providers when multiple SOMDS Consumers attempt to connect at the same time.
In order to suppress concurrent connection attempts, in the ad-hoc mode a SOMDS Provider can omit the Transport Address from the Hello message. Subsequently, a SOMDS Consumer needs to send a Resolve message to resolve the SOMDS Provider's Transport Address.
Deferral is controlled by the entity that is affected by concurrent connection attempts.
The deferral does not work in managed mode, i.e., when a discovery proxy is in charge to respond to Resolve messages (unless the discovery proxy implements a similar behavior).
2:A.4.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.4.1.2.1 Default Priority Group
2:A.4.1.2.2 Dynamic Priority Group
2:A.4.1.2.3 Priority Group Guidelines
Table 2:A.4.1.2.3-1 exhibits guidelines to Manufacturers or responsible organizations as to which priority group can be used for a certain SOMDS Consumer system function criticality.
| 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.4.2 MDIB Report Retrofit
In addition to Section 3:8.3.2.11, this section specifies requirements to an MDPWS transport binding. The requirements aim to verify that MDIB versions received by a SOMDS Consumer are not decremented and present no gap.
2:A.4.3 MDPWS Compression Option
MDPWS [ISO/IEEE 11073-20702:2016] defines EXI as the designated means to compress XML data. However, EXI is lagging in adoption. Therefore, instead of using EXI compression, it is recommended to use HTTP compression with gzip (RFC 1952) as the minimum agreement between clients and servers. One issue with that is the missing official support for HTTP compression in HTTP request messages. Request headers are allowed to include Content-Encoding, but those might not be accepted by HTTP servers.
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.4.4 Discovery Scopes
[ISO/IEEE 11073-20701:2018] specifies requirements to the encoding of certain MDIB data as WS-Discovery Scopes provided by SOMDS Providers. This clause further details encoding rules for production specifications and attributes as laid out in the IEEE 11073-10101 nomenclature.
2:A.4.4.1 Encoding of Production Specifications
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 ':' ProductionSpecificationProductionSpecification is specified in Figure 2:A.4.4.1-1. |
2:A.4.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 ':' AttributeAttribute is specified in Figure 2:A.4.4.2-1. |
2:A.4.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.
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
For the HL7 V2 data reporting, it is impportant that the time zone is set correctly at the Point of Care Device (PoCD).
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.
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 identifer. 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
|
SDPi Supplement Version Note: At the moment, there are various opinions on how to map the biological sex vs. the administrative sex (gender) to an IHE DEV/PCD profile conform HL7 V2 message. The SDC BICEPS standard defines a generic field for the patient’s sex (pm:PatientContextState/pm:CoreData/pm:Sex). This field shall be set to the biological sex (or sex for clinical use). In addition, there will be a gender extension that shall be set to the administrative gender (or administrative sex). The HL7 V2.6 messaging standard only supports a "Administrative Sex" field in the PID segment.
See related note in Section 3:8.3.2.9.4. The following list a couple of options and any comments from the reviewers are highly appreciated:
REVIEWER QUESTION: Please review the options listed above and provide comments on the mapping of this semantic content. |
|
The sex and gender of a patient (or a newborn) cannot exactly be mapped from ISO/IEEE 11073-10207 to HL7 V2. The domain information and service model only contains an attribute for sex as defined by biological and physiological characteristics. HL7 V2, on the other hand, only provides a field for the administrative sex as defined by the socially constructed roles, behaviours, activities, and attributes that a given society considers appropriate. The biological sex, however, does not necessarily match a person’s administrative gender. Mapping from one to the other would therefore introduce errors. However, in the clinical context of a point of care device the biological sex, or sex at birth is important for various algorithms, and therefore, is required to be mapped to the PID-8 field. |
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
PID-8/IS-1 |
Administrative Sex |
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-2). |
| SDC Value | SDC Description | HL7 Value | HL7 Description |
|---|---|---|---|
Unspec |
Unspecified. Sex is not designated. |
A |
Ambiguous |
M |
Male. Indicates a male patient. |
M |
Male |
F |
Female. Indicates a female patient. |
F |
Female |
Unkn |
Unknown. Indicates that the sex is unknown for different reasons. |
U |
Unknown |
2:B.2.3.2.7 PID-10 Race
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
PID-10/CWE-1 |
Identifier |
pm:PatientContextState |
|
PID-10/CWE-2 |
Text |
pm:PatientContextState |
|
PID-10/CWE-3 |
Name of Coding System |
pm:PatientContextState |
|
PID-10/CWE-4 |
Alternate Identifier |
pm:PatientContextState |
Note that if pm:Race/@Code contains a private code, the corresponding translation is to be mapped. Otherwise, only the first entry of the pm:Translation element list is to be mapped. |
PID-10/CWE-6 |
Name of Alternate Coding System |
pm:PatientContextState |
Note that if pm:Race/@Code contains a private code, the corresponding translation is to be mapped. Otherwise, only the first entry of the pm:Translation element list is to be mapped. |
PID-10/CWE-7 |
Coding System Version ID |
pm:PatientContextState |
|
PID-10/CWE-8 |
Alternate Coding System Version ID |
pm:PatientContextState |
Note that if pm:Race/@Code contains a private code, the corresponding translation is to be mapped. Otherwise, only the first entry of the pm:Translation element list is to be mapped. |
2:B.2.3.2.8 PID-31 Identity Unknown Indicator
2:B.2.3.3 PV1 - Patient Visit Segment
The HL7 Patient Visit (PV1) segment requires a mapping from the SDC patient and location context information to the PV1 segment fields.
2:B.2.3.3.1 Prerequisite of Valid Patient & Location Context
2:B.2.3.3.2 PV1-2 Patient Class
Usually, a PoC device is used for patients admitted to a care unit in the hospital, and therefore, the field is set to "I" (Inpatient). If the patient class is unknown, the field is set to "U" (Unknown).
The SDC data model does not support the concept of a patient class. Therefore, the field is either set to "U" (Unknown) by default, or set to a configurable value by the gateway.
2:B.2.3.3.3 PV1-3 Assigned Patient Location
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
PV1-3/PL-1 |
Point of Care |
pm:LocationContextState |
Aka. clinical care unit |
PV1-3/PL-2 |
Room |
pm:LocationContextState |
|
PV1-3/PL-3 |
Bed |
pm:LocationContextState |
|
PV1-3/PL-4 |
Facility |
pm:LocationContextState |
HL7 data type HD |
PV1-3/PL-4.1 |
Namespace ID |
/@Facility |
|
PV1-3/PL-7 |
Building |
pm:LocationContextState |
|
PV1-3/PL-8 |
Floor |
pm:LocationContextState |
2:B.2.3.3.4 PV1-19 Visit Number
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
PV1-19/CX-1 |
ID Number |
pm:PatientContextState |
The @Extension attribute contains the unique visit identifier if available. Note that the field may contain a null value indicating that the identifier is missing. |
PV1-19/CX-4 |
Assigning Authority |
pm:PatientContextState |
HL7 data type HD |
PV1-19/CX-4.1 |
Namespace ID |
/@Root |
The @Root contains the unique identification of the HDO. Note that if the HDO identifer is not defined the CX-4 field is required to be left empty. |
PV1-19/CX-5 |
Identifier Type Code |
pm:PatientContextState |
The type of the patient identifier set in the @Code attribute is required to be set to a value from HL7 V2 table 0203. The @CodingSystem is required be set to "urn:oid:2.16.840.1.113883.18.108". Valid "Identifier Type Code" values for a visit number are, for example, "VN" (Visit Number), "AN" (Account Number), etc. |
2:B.2.3.3.5 PV1-44 Admit Time / Date
2:B.2.3.3.6 PV1-51 Visit Indicator
2:B.2.4 HL7 Field Descriptions
The following sections specify the general HL7 V2 field mappings. Please refer to the Appendix B Common Segment Descriptions of the [IHE PCD TF-2:2019] for further information.
2:B.2.4.1 OBX-3 Observation Identifier
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
OBX-3/CWE-1 |
Identifier |
pm:Mds |
|
OBX-3/CWE-2 |
Text |
If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:Mds |
Note that MDC is the default coding system if no coding system is specified. |
OBX-3/CWE-3 |
Name of Coding System |
MDC if no other coding system is specified. In all other cases, the field is set to pm:Mds |
Note that MDC is the default coding system if no coding system is specified. |
OBX-3/CWE-7 |
Coding System Version ID |
pm:Mds |
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
OBX-3/CWE-1 |
Identifier |
pm:Vmd |
|
OBX-3/CWE-2 |
Text |
If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:Vmd |
Note that MDC is the default coding system if no coding system is specified. |
OBX-3/CWE-3 |
Name of Coding System |
MDC if no other coding system is specified. In all other cases, the field is set to pm:Vmd |
Note that MDC is the default coding system if no coding system is specified. |
OBX-3/CWE-7 |
Coding System Version ID |
pm:Vmd |
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
OBX-3/CWE-1 |
Identifier |
pm:Channel |
|
OBX-3/CWE-2 |
Text |
If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:Channel |
Note that MDC is the default coding system if no coding system is specified. |
OBX-3/CWE-3 |
Name of Coding System |
MDC if no other coding system is specified. In all other cases, the field is set to pm:Channel /pm:Type /@CodingSystem. |
Note that MDC is the default coding system if no coding system is specified. |
OBX-3/CWE-7 |
Coding System Version ID |
pm:Channel |
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
OBX-3/CWE-1 |
Identifier |
pm:NumericMetricDescriptor pm:StringMetricDescriptor pm:EnumStringMetricDescriptor |
|
OBX-3/CWE-2 |
Text |
If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:AbstractMetricDescriptor |
Note that MDC is the default coding system if no coding system is specified. |
OBX-3/CWE-3 |
Name of Coding System |
MDC if no other coding system is specified. In all other cases, the field is set to pm:AbstractMetricDescriptor |
Note that MDC is the default coding system if no coding system is specified. |
OBX-3/CWE-7 |
Coding System Version ID |
pm:AbstractMetricDescriptor |
2:B.2.4.2 OBX-4 Observation Sub-ID
2:B.2.4.3 OBX-18 Equipment Instance Identifier
|
SDPi Supplement Version Note: The UDI is not available for all devices and alternatives for uniquely identifying a device shall be defined. The SDC BICEPS standards provides the pm:ProductionSpecification on the MDS and VMD level which is a list of coded product specifications such as serial number, model, product number, manufacture, etc. Another issue is that the field "Universal ID Type" of the HL7 EI date type is bound to HL7 table 0301 which does not contain a "UDI" id type. REVIEWER QUESTION: Please provide feedback on the following questions …
|
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
OBX-18/EI-1 |
Entity Identifier |
pm:Mds /pm:MetaData |
|
OBX-18/EI-2 |
Namespace ID |
pm:Mds |
|
OBX-18/EI-3 |
Universal ID |
pm:Mds |
|
OBX-18/EI-4 |
Universal ID Type |
Set to ""L" |
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
OBX-18/EI-1 |
Entity Identifier |
||
OBX-18/EI-2 |
Namespace ID |
||
OBX-18/EI-3 |
Universal ID |
||
OBX-18/EI-4 |
Universal ID Type |
2:B.3 SDPi DEC Gateway — Mapping
2:B.3.1 Scope
This chapter defines the mapping from the MDIB content as defined in this document and its underlying standards, to IHE Device Enterprise Communication (DEC) Profile messages as defined in the [IHE PCD TF-2:2019].
The SOMDS DEC Gateway represents the Device Observation Reporter (DOR) role of the IHE DEC profile.
The following sections supplement the IHE DEC Profile as appropriate. If there are no supplementing definitions, the definitions as described in the [IHE PCD TF-2:2019] will apply.
2:B.3.2 Referenced Standards & Profiles
This section provides an overview about the referenced standards and profiles used in this chapter:
2:B.3.3 Private MDC Codes Consideration
Please refer to general Section Appendix 2:B.2.2.
2:B.3.4 HL7 Segment Descriptions
The following sections refer to the Appendix B Common Segment Descriptions of the [IHE PCD TF-2:2019].
2:B.3.4.1 MSH - Message Header Segment
Please refer to general Section Appendix 2:B.2.3.1.
2:B.3.4.2 PID - Patient Identification Segment
Please refer to general Section Appendix 2:B.2.3.2.
2:B.3.4.3 Height and Weight Mapping
The pm:PatientContextState/pm:CoreData element may also contain elements for a patient’s height and/or weight.
2:B.3.4.3.1 Height/Weight Observation Date Time Consideration
In the SDC Domain Information and Service Model, there are no explicit timestamps for the height and weight observation in pm:PatientContextState/pm:CoreData element. The only timestamp associated with the current patient context state is the pm:PatientContextState/@BindingStartTime, but this timestamp is set only once when the context was associated regardless whether height and weight has been set or updated later.
The gateway could also keep track of the pm:PatientContextState updates and evaluate height/weight value changes in the state updates. The state update timestamp has to be set by the SDC gateway consumer when it receives the new context state. That timestamp could be used for the height and/or weight observation that has been changed. The problem is that when the gateway loses connection to the PoC device it can only get the latest state update with a new version number but there is no timestamp related to the new state.
2:B.3.4.3.2 Height Mapping
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
OBX-1 |
Set ID - OBX |
Please refer to the [IHE PCD TF-2:2019] OBX-1 Set ID - OBX for further information |
|
OBX-2 |
Value Type |
Set to "NM" since height is always represented as a decimal number. |
|
OBX-3/CWE-1 |
Identifier |
Set to MDC code "68060". |
|
OBX-3/CWE-2 |
Text |
Set to MDC RefId "MDC_ATTR_PT_HEIGHT". |
|
OBX-3/CWE-3 |
Name of Coding System |
Set to coding system "MDC". |
|
OBX-4 |
Observation Sub-ID |
Set to "<MDS>.0.0.1" where <MDS> is the number of the MDS level assigned by the gateway. See Appendix 2:B.3.4.6.4 for further information. |
|
OBX-5 |
Observation Value |
pm:PatientContextState |
Note that the decimal number needs to be formatted according to the HL7 numeric value formatting rules. |
OBX-6 |
Units |
HL7 data type CWE |
|
OBX-6/CWE-1 |
Identifier |
pm:PatientContextState |
|
OBX-6/CWE-2 |
Text |
If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:PatientContextState |
Note that MDC is the default coding system if no coding system is specified. |
OBX-6/CWE-3 |
Name of Coding System |
"MDC" if no other coding system is specified. In all other cases, the field is set to pm:PatientContextState |
Note that MDC is the default coding system if no coding system is specified. |
OBX-6/CWE-7 |
Coding System Version ID |
pm:PatientContextState |
|
OBX-11 |
Observation Result Status |
When the patient context has been associated and a new @BindingStartTime has been set, the field is set to final result status "F". When there are further updates of the height value after the association of the patient context, the field is set to "C". |
|
OBX-14 |
Date/Time of the Observation |
pm:PatientContextState |
Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also Example 2). |
2:B.3.4.3.3 Weight Mapping
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
OBX-1 |
Set ID - OBX |
Please refer to the [IHE PCD TF-2:2019] OBX-1 Set ID - OBX for further information |
|
OBX-2 |
Value Type |
Set to "NM" since weight is always represented as a decimal number. |
|
OBX-3/CWE-1 |
Identifier |
Set to MDC code "68063". |
|
OBX-3/CWE-2 |
Text |
Set to MDC RefId "MDC_ATTR_PT_WEIGHT". |
|
OBX-3/CWE-3 |
Name of Coding System |
Set to coding system "MDC". |
|
OBX-4 |
Observation Sub-ID |
Set to "<MDS>.0.0.2" where <MDS> is the number of the MDS level assigned by the gateway. See Appendix 2:B.3.4.6.4 for further information. |
|
OBX-5 |
Observation Value |
pm:PatientContextState |
Note that the decimal number needs to be formatted according to the HL7 numeric value formatting rules. |
OBX-6 |
Units |
HL7 data type CWE |
|
OBX-6/CWE-1 |
Identifier |
pm:PatientContextState |
|
OBX-6/CWE-2 |
Text |
If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:PatientContextState |
Note that MDC is the default coding system if no coding system is specified. |
OBX-6/CWE-3 |
Name of Coding System |
"MDC" if no other coding system is specified. In all other cases, the field is set to pm:PatientContextState |
Note that MDC is the default coding system if no coding system is specified. |
OBX-6/CWE-7 |
Coding System Version ID |
pm:PatientContextState |
|
OBX-11 |
Observation Result Status |
When the patient context has been associated and a new @BindingStartTime has been set, the field is set to final result status "F". When there are further updates of the weight value after the association of the patient context, the field is set to "C". |
|
OBX-14 |
Date/Time of the Observation |
pm:PatientContextState |
Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also Example 2). |
2:B.3.4.4 PV1 - Patient Visit Segment
Please refer to general Section Appendix 2:B.2.3.3.
2:B.3.4.5 OBR - Observation Request Segment
The HL7 Obervation Request (OBR) segment requires a mapping from the SDC containment tree and metric data to the OBR segment fields.
2:B.3.4.5.1 OBR-2 Placer Order Number
2:B.3.4.5.2 OBR-3 Filler Order Number
2:B.3.4.5.3 OBR-4 Universal Service ID
|
SDPi Supplement Version Note: In this version of the SDPi Supplement, this section needs to be updated in order to be compliant with the [IHE PCD TF-2:2019]. The following issues need more investigations and discussions:
|
2:B.3.4.5.4 OBR-7 Observation Date/Time
The OBR-7 field specifies the time point or start of time interval for all OBX segments within the scope of this OBR segment, that is, OBX segments that are part of the ORDER_OBSERVATION segment group, that do not specify an overriding time point in the OBX-14 field.
The presence of an overriding time point in OBX-14 indicates an episodic measurement such as non-invasive blood pressure.
The absence of an overriding time point in the OBX-14 field implies that this is an instance of a periodically sampled observation with a time stamp given by OBR-7 field.
| Only metrics that fulfil certain criteria are exported by the SOMDS DEC Gateway. Please refer to R8018 and R8017 for further information. |
2:B.3.4.5.5 OBR-8 Observation End Date/Time
2:B.3.4.5.6 OBR-10 Collector Identifier
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
OBR-10/XCN-1 |
ID Number |
pm:OperatorContextState |
The @Extension attribute contains the unique operator identifier. Note that the field may contain a null value indicating that the identifier is missing. |
OBR-10/XCN-2 |
Family Name |
pm:OperatorContextState |
HL7 data type FN |
OBR-10/XCN-2.1 |
Surname |
/pm:Familyname |
|
OBR-10/XCN-3 |
Given Name |
pm:OperatorContextState |
|
OBR-10/XCN-4 |
Second and Further Given Names or Initials |
pm:OperatorContextState |
|
OBR-10/XCN-6 |
Prefix (e.g., DR) |
pm:OperatorContextState /pm:OperatorDetails /pm:Title |
|
OBR-10/XCN-9 |
Assigning Authority |
pm:OperatorContextState /pm:Identification |
HL7 data type HD |
OBR-10/XCN-9.1 |
Namespace ID |
/@Root |
The @Root contains the unique identification of the HDO. Note that if the HDO identifier is not defined, the XCN-9 field is left empty. |
2:B.3.4.6 OBX - Observation/Result Segment
The HL7 Observation/Result (OBX) segment requires a mapping from the SDC containment tree and metric items to the OBX segment fields. More information about the containment tree mapping can be found in Appendix A Mapping ISO/IEEE 11073 Domain Information Model to HL7 in [IHE PCD TF-2:2019].
2:B.3.4.6.1 OBX-1 Set ID - OBX
Please refer to the [IHE PCD TF-2:2019] OBX-1 Set ID - OBX for further information.
2:B.3.4.6.2 OBX-2 Value Type
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
OBX-2/ID-1 |
Coded Value for HL7-Defined Tables |
"NM" if the metric state is of type pm:NumericMetricState. "ST" if the metric state is of type pm:StringMetricState. "CWE" if the metric state is of type pm:EnumStringMetricState. |
2:B.3.4.6.3 OBX-3 Observation Identifier
Please refer to general Section Appendix 2:B.2.4.1.
2:B.3.4.6.4 OBX-4 Observation Sub-ID
Please refer to general Section Appendix 2:B.2.4.2.
2:B.3.4.6.5 OBX-5 Observation Value
2:B.3.4.6.5.1 Numeric Metric
2:B.3.4.6.5.2 String Metric
2:B.3.4.6.5.3 Enumeration String Metric
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
OBX-5/CWE-1 |
Identifier |
pm:EnumStringMetricDescriptor |
|
OBX-5/CWE-2 |
Text |
If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:EnumStringMetricDescriptor |
Note that MDC is the default coding system if no coding system is specified. |
OBX-5/CWE-3 |
Name of Coding System |
"MDC" if no other coding system is specified. In all other cases, the field is set to pm:EnumStringMetricDescriptor |
Note that MDC is the default coding system if no coding system is specified. |
OBX-5/CWE-7 |
Coding System Version ID |
pm:EnumStringMetricDescriptor |
2:B.3.4.6.6 OBX-6 Units
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
OBX-6/CWE-1 |
Identifier |
pm:NumericMetricDescriptor |
|
OBX-6/CWE-2 |
Text |
If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:NumericMetricDescriptor |
Note that MDC is the default coding system if no coding system is specified. |
OBX-6/CWE-3 |
Name of Coding System |
"MDC" if no other coding system is specified. In all other cases, the field is set to pm:NumericMetricDescriptor |
Note that MDC is the default coding system if no coding system is specified. |
OBX-6/CWE-7 |
Coding System Version ID |
pm:NumericMetricDescriptor |
2:B.3.4.6.7 OBX-7 Reference Range
2:B.3.4.6.8 OBX-8 Abnormal Flags
The OBX-8 field is not required to be set since the gateway exports valid and validated metric data only.
2:B.3.4.6.9 OBX-11 Observation Result Status
2:B.3.4.6.10 OBX-14 Date/Time of Observation
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
OBR-14/DTM-1 |
Date/Time |
pm:EnumStringMetricState pm:NumericMetricState pm:StringMetricState |
Note that the HL7 date & time format differs from the xsd date/time formats and requires a mapping accordingly (see also Example 2). |
2:B.3.4.6.11 OBX-16 Responsible Observer
2:B.3.4.6.12 OBX-17 Observation Method
| SDC Category | SDC Derivation | HL7 OBX-17 Field Value |
|---|---|---|
Msmt |
Auto |
OBX-17 field is left empty (recommended). Or set to "AMEAS^auto-measurement^MDC" if required. |
Msmt |
Man |
MMEAS^manual-measurement^MDC |
Clc |
Auto |
ACALC^auto-calculation^MDC |
Clc |
Man |
MCALC^manual-calculation^MDC |
Set |
Auto |
ASET^auto-setting^MDC |
Set |
Man |
MSET^manual-setting^MDC |
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
OBR-17/CWE-1 |
Identifier |
pm:AbstractMetricDescriptor |
2:B.3.4.6.13 OBX-18 Equipment Instance Identifier
Please refer to general Section Appendix 2:B.2.4.3.
2:B.3.4.6.14 OBX-20 Observation Site
| HL7 Field | HL7 Component Name | SDC Attribute/Element | Comments |
|---|---|---|---|
OBX-20/CWE-1 |
Identifier |
pm:AbstractMetricState or pm:AbstractMetricDescriptor |
Note that only the first pm:BodySite element from the list is required to be mapped. |
OBX-20/CWE-2 |
Text |
If @Code is an MDC code, this field contains the RefId of the MDC code. In all other cases, the field is set to the pm:AbstractMetricState or pm:AbstractMetricDescriptor |
Note that MDC is the default coding system if no coding system is specified. Note that only the first pm:BodySite element from the list is required to be mapped. |
OBX-20/CWE-3 |
Name of Coding System |
"MDC" if no other coding system is specified. In all other cases, the field is set to pm:AbstractMetricState or pm:AbstractMetricDescriptor |
Note that MDC is the default coding system if no coding system is specified. Note that only the first pm:BodySite element from the list is required to be mapped. |
OBX-20/CWE-7 |
Coding System Version ID |
pm:AbstractMetricState or pm:AbstractMetricDescriptor |
Note that only the first pm:BodySite element from the list is required to be mapped. |
2:B.4 SDPi ACM Gateway — Mapping
2:B.4.1 Scope
This chapter defines the mapping from the MDIB content as defined in this document and its underlying standards, to IHE Alert Communication Management (ACM) Profile messages as defined in the [IHE PCD TF-2:2019].
The SOMDS ACM Gateway represents the Alarm Reporter (AR) role of the IHE ACM profile.
The following sections supplement the IHE ACM Profile as appropriate. If there are no supplementing definitions, the definitions as described in the [IHE PCD TF-2:2019] apply.
2:B.4.2 Referenced Standards & Profiles
This section provides an overview about the referenced standards and profiles used in this chapter:
2:B.4.3 Private MDC Codes Consideration
Please refer to general Section Appendix 2:B.2.2.
2:B.4.4 HL7 Segment Descriptions
The following sections