Page tree
Skip to end of metadata
Go to start of metadata

Building on the IHE SDPi technical framework (TF) concept established in 2019, the models below provide the detailed elements that will be integrated into volumes 1 & 2.   

Note that narrative-specific models will be handled in those discussions but will reference the content below.

<what about BICEPS models for TF-3>

What Lays Below ...

Inline PlantUML files

Do not alter the diagram sources listed herein. The original sources are stored somewhere else and should be the only sources to be changed.

Remarks and Notational Conventions

General

  • Diagrams are built using PlantUML 
  • Messages exchanged between participants are described using a name and general payload in parenthesis
  • Payload in brackets is optional payload
  • Payload in curly brackets describes a set of data
  • For the sake of readability, message and payload names do not perfectly match the message names from SDC
  • Any name that cannot be derived from its simplified representation is mentioned separately by the diagram that uses the name

Participants

  • SC stands for [SDC] Service Consumer
  • SP stands for [SDC] Service Provider
  • In some circumstances a third participant is required that carries a distinguishable name

Message sections

  • unsecured: An unsecured section denotes message exchange that is not protected w.r.t. confidentiality and integrity which is essentially UDP traffic
  • secured: A secured section denotes message exchange that is protected w.r.t. confidentiality and integrity which is essentially HTTPS (TLS) traffic
  • par: message exchange potentially takes place in parallel
  • alt: alternative message exchange depending on the described condition
  • opt: optional message exchange depending on the described condition
  • loop: message exchange is repeated 0..n times
  • one or more of: one or many of the messages within the enclosing section are exchanged

Arrows

  • A thin arrow head indicates multicast traffic
  • A thick arrow head indicates unicast traffic
  • Synchronous message responses are designated by dotted arrow lines

Basic SDC Service Model

The sequence diagram below shows the general message flow for finding devices and establishing an event-based stream of MDIB changes. It is assembled from SDPi-P and SDPi-R transactions.

Activities listed in the sequence diagram above

  • 1 to 5: Network topology discovery - unsecure, enables plug-and-play discovery of service-hosting devices
  • 6 to 11: Reception of available BICEPS service interfaces
  • 10 to 11: Plain HTTP GET request to retrieve Web Service interface descriptions in case those have not been incorporated in a WS-Metadata Get response. As the WSDL is identical for every SDC powered device, there is no need for a service consumer to request it
  • 12 to 17: Subscription of data to be delivered episodically on change; buffered until the initial MDIB snaphot becomes available
  • 18 to 23: Retrieve proxy MDIB including the provider's context information and apply reports buffered meanwhile
  • 24 to 25: Keep retrieving MDIB changes and apply them on the proxy MDIB
  • 26 to 29: Service consumer or provider are shut down
  • 29: Note that the Bye message is unsecured and should be ignored by service consumers as it can be exploited to prevent any service consumer from connecting to service providers

SDPi-P for Plug-and-play Connectivity

Network Topology Discovery

BICEPS Services Discovery

SDPi-R for Medical Device Information Reporting

General MDIB Changes Tracking

Activities listed in the sequence diagram above

  • 1 to 2: The service consumer subscribes for every topic it is interested in
  • 3 to 6: In accordance with IEEE 11073-20701 potential DescriptionModificationReports are always delivered prior to any state changes that come along with description modifications. 
  • 7 to 9: At some point either the service consumer is not interested in reports anymore such that is unsubscribes, or the service provider cancels the subscription for some reason

Localization Information Retrieval

Activities listed in the sequence diagram above

  • 1 to 2: Typically, a service consumer requests all supported languages in advance
  • 3 to 5: Once it knows all available languages, it leverages the GetLocalizedText request-reponse message exchange to retrieve all localized text translations it needs for its user interface. Depending on the filter, multiple requests might be required to get all data

Archive Data Retrieval

Activities listed in the sequence diagram above

  • 1 to 2: The service consumer first requests historical descriptor information
  • 3 to 4: Once descriptors are known, depending on the desired amount of data the service consumer retrieves all states by gradually requesting the Archive service. The exact requesting sequence depends on the use-case.

SDPi-A for Medical Device Alerting

Alert Reporting

Alert Reporting follows the same procedure as the general MDIB changes tracking.

Alert Signal Delegation

Alert Signal Delegation depicts the key workflow that facilitates service consumers to take over alarming from a service provider.

Alert Signal Delegation (timeout)

Alert Signal Delegation with Rejection

This sequence diagram shows how to react if two service consumers want to take over primary alert signal delegation.


SDPi-xC for Medical Device External Control

Immediate Operation Invocation

Activities listed in the sequence diagram above

  • 1 to 2: The service consumer subscribes topics at the service provider. A service consumer that intends to invoke operation is supposed to subscribe to OperationInvokedReports and OperationalStateReports in order to get notified on invocation steps. Moreover, the service consumer needs to subscribe for the objects that it intends to modify as it's not informed on the operation progress otherwise.
  • 3 to 4: The actual operation invocation based on a request-response message exchange. Here, the consumer requests a SetValue operation and receives a transaction id to listen for reports generated as events for the OperationInvokedReport subscription topic. In case of immediate results the service consumer does not necessarily needs to wait for the OperationInvokedReport message to receive as the initial response provides the final result already. 
  • 5 to 8: Dependent on the order of reception the invocation state and result of an operation is communicated
  • 9 to 11: At some point either the service consumer is not interested in reports anymore such that is unsubscribes, or the service provider cancels the subscription for some reason

Delayed Operation Invocation

Activities listed in the sequence diagram above

  • 1 to 4: see 1 to 4 in Immediate Operation Invocation
  • 5 to 6: Right after the invocation has been triggered, the service provider subsequently delivers further invocation states. Waiting indicates that the operation has been queued; Started indicates that processing of the operation request has started
  • 7 to 10: The service consumer receives the final invocation state together with the result of the operation, see 5 to 8 in Immediate Operation Invocation
  • 11 to 13: At some point either the service consumer is not interested in reports anymore such that is unsubscribes, or the service provider cancels the subscription for some reason

SDC/BICEPS Device Specialization Models

<TF-3 Semantic Content BICEPS models ... based on current device specializations>