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

Notes:

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

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

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

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

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.

Actor Summary 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.

Actor Summary 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.

Actor Summary Definition:

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.

Actor Summary Definition:

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.

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.

Actor Summary Definition:

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.

Actor Summary Definition:

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

Actor Summary Definition:

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.

Actor Summary Definition:

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.

Actor Summary Definition:

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.

Actor Summary Definition:

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.

Actor Summary Definition:

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

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:

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

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

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

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

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.

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

Specific capabilities supporting the STAD use case include:

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

Specific capabilities supporting the SICDsp use case include:

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

Specific capabilities supporting the SICDmp use case include:

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

Specific capabilities supporting the DDES use case include:

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

Specific capabilities supporting the ACNS use case include:

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

Specific capabilities supporting the AARS use case include:

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

Actor Summary Definition:

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.

Actor Summary Definition:

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.

Actor Summary Definition:

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.

Actor Summary Definition:

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

Specific capabilities supporting the SICDsp use case include:

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

Specific capabilities supporting the SICDmp use case include:

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

Specific capabilities supporting the DDES use case include:

Actor Summary Definition:

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.

Actor Summary Definition:

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.

Actor Summary Definition:

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.

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.

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

Specific capabilities supporting the SICDsp use case include:

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

Specific capabilities supporting the SICDmp use case include:

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

Specific capabilities supporting the ACNS use case include:

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

Specific capabilities supporting the AARS use case include:

Actor Summary Definition:

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.

Actor Summary Definition:

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.

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

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

Two requirement identifiers are currently specified:

Unique Identifier

Requirement OID

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

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

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

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

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

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

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

ADD IEEE: Table 20 — General ICSs table here

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

ADD IEEE: Service Provider ICS table here

ADD IEEE: Service Consumer ICS table here

ADD IEEE: Remote Control ICS table here

ADD IEEE: Context Processing ICS table here

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.

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.

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