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

Problem Statement

Although SDC allows for an MDIB to have multiple MDS containment trees (all at a single level - not "nested") this results in potentially significant complexity (e.g., maintaining unique handles across an MDIB with multiple MDS's).  A common reason for having multiple MDS's is when you have a device "aggregator" or gateway or similar system.  How should this be modeled using SDPi BICEPS profiling?  


<include "template" info>

Modeling Options Analysis

There are different ways to model aggregators depending on their purpose. The following sections list different aggregator configurations together with pros for and cons against their use.

Aggregating sensors into one MDIB

Sensors provide metrics and alarm conditions through proprietary protocol(s) and are transformed by the aggregator to one logical MDIB instance with a single MDS. The aggregator is in charge of assigning handles to each object from the resulting MDIB. The sensors appear as VMDs beneath the single MDS.

There are no specific advantages or disadvantages involved in this setup. Sensor data is transparently mapped to SDC-compliant entities and viewed by SDC Service Consumers as a single, off-the-shelf medical device.

Aggregating proprietary devices

Devices with proprietary interfaces are aggregated to one MDIB with multiple MDSs 

Devices with proprietary interfaces are combined by the aggregator to one MDIB in which every proprietary device mapping comes as a separate MDS. The aggregator is in charge of assigning handles to each object from the resulting MDIB.

(plus) The aggregator does not need to open multiple ports as only one stream of MDIB reports needs to be provided per consumer

(minus) Provisioning of multiple MDIBs is challenging due to the design of the SDC protocol where every object in the MDIB needs to know its enclosing MDS

(minus) SDC Service Consumers have to understand the concept of MDIBs with multiple MDSs and hence potentially have to implement a different handling opposed to just one MDS 

Devices with proprietary interfaces are aggregated by instantiating logical devices each comprising one MDIB with a single MDS 

The aggregator is in charge of assigning handles to each object from the resulting MDIBs.

(plus) The aggregator is not visible to SDC Service Consumers, the device proxies appear as they would be real SDC Service Providers 

(plus) SDC Service Consumers do not need to implement a different handling for the proxies than they would have to for regular SDC devices 

(minus) Depending on the design, the aggregator has to open multiple ports in order to expose the different proxies, esp. if the proxies run in separate processes

Aggregating SDC-compliant devices

Devices with SDC-compatible interfaces are aggregated to one MDIB with multiple MDSs 

The aggregator subscribes to all incoming MDIB reports from each device and is responsible to align handles names such that there are no duplicates in the resulting aggregated MDIB.

(plus) The aggregator does not need to open multiple ports as only one stream of outgoing MDIB reports needs to be provided per consumer

(minus) Provisioning of multiple MDIBs is challenging due to the design of the SDC protocol as every object in the MDIB needs to know its enclosing MDS

(minus) SDC Service Consumers have to understand the concept of MDIBs with multiple MDSs and hence potentially have to implement a different handling opposed to just one MDS

(minus) The aggregator needs to put in extra effort just for handle renaming without any (clinical) benefit

Devices with SDC-compatible interfaces are aggregated by instantiating logical devices each comprising one MDIB with a single MDS

The aggregator mirrors GET/SET/REPORT services to proxy processes.

(plus) The aggregator is not visible to SDC Service Consumers, the device proxies appear as they would be real SDC Service Providers 

(plus) SDC Service Consumers do not need to implement a different handling for the proxies than they would have to for regular SDC devices 

(plus) There is no effort required for handle renaming

(plus) The aggregator might be a "stupid" piece of software that just collects and forwards data

(minus) Depending on the design, the aggregator has to open multiple ports in order to expose the different proxies, esp. if the proxies run in separate processes

Other cases

There are use-cases conceivable in which aggregators collect data from proprietary and non-proprietary devices and transform/forward the data depending on internal business logic. For the sake of brevity and as such aggregators are just combinations of use-cases mentioned above, they have been omitted from this web page.

2020.07.24 Discussion

  1. David Gregorczyk reviewed an initial set of slides
    1. Consider expanding "happy path" preferred approach with SDC and Non-SDC source devices on the left
    2. David GregorczykProvide slides here 
  2. Discussion
    1. How would the "preferred" approach (one MDS per MDIB) be represented on the net?  Multiple ports is very problematic
    2. Should add right side "consumer side" to understand how that part works
    3. Where does this discussion get captured in SDPi TF?
    4. Aggregator would have its own MDIB ... ?
    5. Aggregator as more than a "router" - like the Bedside Cockpit actor or App Hosting Platform or Central Monitor (!!!)
    6. Does the Aggregator MDIB instead take a subset of a source device's MDIB and add it as a VMD in its own ...
  3. Next Steps
    1. Update slides per today's discussion (e.g., with right side "consumer" actors
    2. Identify requirements / issues on both left and right sides
    3. Identify what real-world systems are impacted - central station (incl. w/ telemetry), simple aggregator / router or gateway, infusion pump integration etc.


2020.08.07 Week Discussions

The following content was exchanged during this week primarily between David Gregorczyk and Peter Kranich on the topic of "MDIB/MDS Modeling for Device Aggregators"

  1. Given:  Current MDIB does not allow nested MDS's & Given:  11073-10201 Classic DIM (and conformant applications) utilize nested MDS ...
    1. How would -10201 Nested MDS applications be mapped into SDC/BICEPS?
    2. For example:
      1. A patient monitor we may use nested MDSs. E.g. a modular measurement server can be plugged to a monitor. In this case, the measurement server MDS is part of the monitor MDS. The measurement server can also be unplugged again and used as an independent monitor and hence, exposed as an individual MDS.
    3. Initial Response:
      1. BICEPS comes with a simplified DIM that provides MDS -> VMD -> Channel only. If you have a measurement server that can be plugged into the monitor, the measurement server would either appear as another MDS in the MDIB or as a VMD of the monitor MDS. How this is modelled depends on the requirements, e.g. does the measurement server need a separate system context -> there should be a separate MDS; if not it might be ok to put it as a VMD.
    4. After discussion:  A ticket for 11073-10207 BICEPS should be created
      • David GregorczykCreate a 11073-10207 BICEPS ticket to consider adding MDS nesting relationships to the model in an addendum 
    5. Additionally, if MDIB handles in nested MDS's need to be made unique, this can be easily accomplished using a UUID
    6. Support for MDS nesting in an MDIB can be an optional capability to the current standard
  2. Additional aggregator use cases to consider ...
    1.  Provide SDC-interface for Non-SDC devices

      Vendors might not implement a SDC interface right in the actual PoC device due to various reasons e.g. effort, complexity, limited device resources, unsecure memory for the certificates, certificate deployment, legacy operating system, etc. An example would be an infusion pump rack system where the infusion pumps are already connected to a data concentrator that provides a single endpoint for the entire rack. The PC-based data concentrator may provide also a SDC interface to the individual infusion pumps.
      Multiple MDIBs with one MDS per MDIB would make sense to us for devices which are used for different patients, in different locations. For example, ventilators which are used in different care units for different patient but which are connected to a single data aggregator in the hospital. This will then provide a clear separation of the devices, and allows other devices and systems to deal only with the MDSs they are interested in.
      One MDIB with multiple MDSs has, as already pointed out, the advantage of a single communication endpoint for multiple device. That would make sense for devices which always belong to the same patient/location context, for example, the infusion pump rack system which cannot be shared between different patients.
      For an enterprise device aggregator that consolidates devices of different types and different locations, we would see practical issues:
        1. Will there be also only one discovery message or multiple per device type or MDS supported by the aggregator?
        2. Other devices and/or clinical systems always have to deal with the entire MDIB in order to find the MDSs they are interested in.
        3. The MDIB could be huge – how can the MDIB be segmented e.g. per care unit?
        4. When there are multiple SDC consumers subscribed to the same device data stream through the aggregator, can the aggregator route the data to the correct connection (multiple connection instances for the same endpoint)
    2. Aggregate devices with SDC-interface WITHOUT a special purpose aggregation (device proxy)
      1. The question is what is the use case for such a solution? We could only imagine that this might be useful for devices with limited resources e.g. device only supports one SDC connection at a time, or in order to support multiple SDC versions for backward- / forward-compatibility (future). In this case,  “Devices with SDC-compatible interfaces are aggregated by instantiating logical devices each comprising one MDIB with a single MDS” makes the most sense to us.
      2. The practical issues with this solution might the discovery:
        1. When the devices and the aggregator are connected to the same network and when both provide device discovery for the individual device, how to ensure the SDC consumer connects to the aggregator and not to the original device?
    3. Aggregate devices with SDC-interface WITH a special purpose aggregation

Another use case for aggregation of SDC devices could be a special service that should be provided to the SDC network.
An example would be a smart alerting system. All devices would delegate their alerts and send their vital signs data to the smart alerting system. The smart alerting system then creates a summary alert, advisories, and - dependent on the configuration - provides the original device alerts to other devices and/or a DAS or CDAS (central station, mobile alerting device, etc.). Any alert acknowledgement on the CDAS device would be routed back from the smart alerting system to the original device.
In this case, the smart alerting system would not expose the entire device MDIB of the connected devices but only an MDIB with MDSs which contain the alert events (per patient/location context).

The practical issues with this solution would be:

        1. How can the DAS/CDAS prioritize the alert event source? When the smart alerting system is available it should use this system; when the smart alerting system is not available it should connect to the original device. Do we need a new device type for such a system or purpose?