an architecture for distributed systems of medical devices ......an architecture for distributed...

1

An Architecture for distributed systems of medical devices in high acuity environments

2014-01-14

An architecture for distributed systems of medical

devices in high acuity environments

- A Proposal for Standards Adoption -

Authors:

Stefan Schlichting,

[email protected]

Drägerwerk AG & Co. KGaA

Moislinger Allee 53─55

23558 Lübeck, Germany

Stephan Pöhlsen,

Dräger Medical GmbH

Moislinger Allee 53─55

23558 Lübeck, Germany

mailto:[email protected]

2


2014-01-14

Table of Contents

1 Executive Summary ........................................................................................................................ 4

2 Introduction ..................................................................................................................................... 5

2.1 Openness ................................................................................................................................ 6

2.2 Scope of this document ........................................................................................................... 7

2.3 Organization of the whitepaper ................................................................................................ 7

3 Related Technologies ..................................................................................................................... 8

3.1 ISO/IEEE 11073 standard series ............................................................................................. 8

3.2 Open Surgical Communication Bus......................................................................................... 8

4 Service-oriented Medical Device Architecture for an ICE ............................................................... 9

4.1 Exemplary setup .................................................................................................................... 10

4.2 Clinical Workplace SOMDA & Web Services ........................................................................ 11

4.2.1 Web Services Profiles.................................................................................................... 11

4.3 Protocol Stack for Medical Device Interoperability ................................................................ 11

5 The Medical Devices Profile for Web Services ............................................................................. 13

5.1 DPWS & Openness ............................................................................................................... 14

5.2 Discovery ............................................................................................................................... 15

5.3 Liveliness ............................................................................................................................... 16

5.4 Service Description ................................................................................................................ 16

5.4.1 Web Services Description Language ............................................................................ 17

5.4.2 WS-Policy ...................................................................................................................... 17

5.5 Events & Streams .................................................................................................................. 18

5.5.1 WS-Eventing .................................................................................................................. 18

5.5.2 SOAP-over-UDP Streaming .......................................................................................... 18

5.6 Safety ..................................................................................................................................... 19

5.6.1 Dual Channel Transmission .......................................................................................... 19

5.6.2 Safety Context ............................................................................................................... 21

5.6.3 WS-SafetyInformation.................................................................................................... 21

5.7 Security .................................................................................................................................. 21

5.7.1 Access Control ............................................................................................................... 22

5.7.2 Public-Key Infrastructure for a clinical workplace SOMDA............................................ 22

5.7.3 Confidentiality & Integrity ............................................................................................... 23

5.8 XML Manifestation ................................................................................................................. 23

6 Basic Integrated Clinical Environment Protocol Specification ...................................................... 25

6.1 General BICEPS Overview .................................................................................................... 25

6.2 Message Information Model .................................................................................................. 26

6.2.1 Service Controller .......................................................................................................... 28

6.2.2 MDIB parts ..................................................................................................................... 28

6.3 Discovery ............................................................................................................................... 29

6.4 Services ................................................................................................................................. 30

3


2014-01-14

6.4.1 Get Service .................................................................................................................... 30

6.4.2 Event Report Service ..................................................................................................... 30

6.4.3 Waveform Service ......................................................................................................... 31

6.4.4 Remote Control Service ................................................................................................ 31

6.4.5 PHI Service .................................................................................................................... 32

6.4.6 Device-specific Services ................................................................................................ 32

6.5 Quality of Service................................................................................................................... 32

6.6 Relationship to MDPWS ........................................................................................................ 32

7 Alternative Technologies .............................................................................................................. 34

7.1.1 Benefits of DDS ............................................................................................................. 35

7.1.2 Weaknesses of DDS...................................................................................................... 35

8 Bibliography .................................................................................................................................. 37

9 Appendix ....................................................................................................................................... 39

9.1 DPWS Specifications ............................................................................................................. 39

4


2014-01-14

1 Executive Summary

In this whitepaper an architecture for distributed systems of medical devices in high acuity

environments is introduced. The proposed architecture is built on the principles of a clinical workplace

service-oriented medical device architecture (SOMDA). The Medical Device Profile for Web Services

(MDPWS) as well as the Basic Integrated Clinical Environment Protocol Specification (BICEPS) are

introduced as new specification and recommended as technical specifications for the communication

inside of the distributed system. MDPWS is based on the Device Profile for Web Services (DPWS).

DPWS is the foundation of the communication protocol stack and provides means for service

discovery including service description at runtime as well as messaging and event propagation over an

IP-based network. MDPWS adds additional means that are needed to fulfill specific requirements for a

clinical workplace like waveform streaming or remote control that ensures patient-safety. On top of

these Web Services profiles BICEPS provides a basic message information model as well as medical

device services to communicate within a clinical workplace context that is based on the ideas of the

ISO/IEEE 11073 standards family.

5


2014-01-14

2 Introduction

There are a lot of use cases where a distributed system of medical devices has the potential to

optimize clinical workflows, improve the outcome for the patient or make treatment safer. Exemplary

use cases are:

A medical device is connected to a patient in ICU. It automatically connects to the point-of-

care network and provides its information both for local and remote viewing.

A medical device connected to a patient provides information for a clinical information system,

general electronic medical record system, or event recording system.

A medical device connected to a patient provides real-time notification of physiological alarm

conditions with timestamps and full supporting detail for display by an acute-care dashboard

display or dispatch through a paging system.

A medical device connected to a patient provides one or more physiological measurements to

another medical device for inclusion in combined displays or calculations.

Medical Device safety-interlocks like for example stopping an infusion at a predetermined

blood pressure value or to prevent intra-abdominal CO2 insufflation if the heart rate and blood

pressure are unmonitored [ASTM-ICE]

For the medical device domain, the definition of a distributed system by Coulouris et al. [1] could be

transferred to:

A distributed system of medical devices is a system in which medical devices and clinical

software components located at networked appliances communicate and coordinate their

actions only by passing messages in order to create clinical benefit in addition to their

standalone function. A medical device or clinical software component that is part of a

distributed system of medical devices is called a participant.

In order to develop, deploy, maintain and operate a distributed system of medical devices efficiently,

medical device interoperability is a key success factor.

Interoperability1 is defined as “ability of two or more systems or components to exchange information

and to use the information that has been exchanged” [2]. To achieve interoperability not only the

capability to exchange data without an error has to be given, but also correct interpretation of data to

utilize it in an algorithm is needed. These two levels of interoperability are depicted in Figure 1.

Moreover, correct interpretation of data and therefore effective use often not only depends on the

interpretation of the meaning of the data, but also on the context how the data has been acquired or

created. This so-called pragmatic interoperability will be for most parts of this paper subsumed under

semantic interoperability.

Based on this general definition of interoperability, medical device interoperability is defined as the

ability of two or more participants of a distributed system of medical devices to exchange information

and to use the information that has been exchanged in order to create clinical benefit.

However, in current distributed systems of medical devices, interoperability is currently achieved in

most cases using proprietary, vendor-dependent communication protocols and middleware. As a

result, the realization of the aforementioned use cases takes time, is cost-intensive, and fits only for

the specific participants of the distributed system of medical devices they were designed for [3].

1 There are other definitions of interoperability that focus on other aspects. One example is the

definition of Lesh et al.[5]. Interoperability is defined as a continuum that distends from the least

complex endpoint of physical interoperability to the most complex of data interoperability. Physical

interoperability as defined by Lesh et al. is not in scope of this document.

6


2014-01-14

Figure 1 Levels of interoperability of medical devices.

The ASTM F2761-1:2009 standard [3] defines a functional conceptual model for the setup of an

Integrated Clinical Environment (ICE). An ICE is a distributed system of medical devices for one

clinical workplace that may have an external interface to other systems. ASTM F2761-1:2009

describes the components that are required for safe and effective “Plug & Play” operation of an ICE in

high acuity environments.

The relevant requirements for medical device interoperability for an architecture and communication

protocol based on the ASTM F2761-1:2009 standard and on a VDE study on risk management for IT-

networks incorporating medical devices [4] in the operating theatre are listed in Table 1.

However, there is no technical specification available that fits these requirements.

Functional Non-Functional

Plug & Play Risk Management

Discovery & Binding Safe communication

Device capability description at runtime Access control

Openness Trust Establishment between participants

Communication (1-1, 1-n, n-m) Privacy of patient-related data

Event Notification Latency in milliseconds range

Data Reporting

Remote Control

Table 1 Functional and non-functional requirements for a communication protocol for medical device

interoperability in an ICE.

2.1 Openness

Openness is defined as the possibility to add a new medical device of a maybe unknown type and an

unknown vendor and make its capabilities available to other participants. This includes also openness

by allowing resource-constrained medical devices to be part of a distributed system of medical

devices.

7


2014-01-14

In order to meets this requirements defined above, the architecture and the protocol stack has to be

developed on the foundation of standardized protocols for the syntactic interoperability that support

extensibility w.r.t to the data that is exchanged in the distributed system. This also includes that the

medical devices that are part of the distributed system may implement their own compliant middleware

and release them not synchronized with the other participants of the distributed system.

Openness also includes that the semantic of the data should be conveyed in standardized way, e.g.

by referencing terms in existing terminologies.

2.2 Scope of this document

This whitepaper is part of the documentation of a Dräger-internal technology project called “Device &

System Connectivity” (DSC) that had the goal to meet the above stated increasing demand for

medical device interoperability in an ICE. The project had the objective to develop an efficient, future-

proof architecture, protocol stack, and middleware that satisfies the derived requirements and

facilitates the implementation of the concept of an ICE.

The objective of this whitepaper is to:

- Introduce an overall architecture for a distributed system of medical devices in an ICE

- Provide background material to support understanding the technical specifications needed for

communication inside an ICE

The intended audiences for this whitepaper are:

- System architects that need to build a distributed system of medical devices in an ICE.

- Developers using the developed DSC middleware in order to build distributed systems of

medical devices and who need an overview of the concepts behind the middleware

2.3 Organization of the whitepaper

First, a range of related technologies and research projects are described in section 3. Afterwards, the

proposed architectural model for medical device interoperability (cf. section 4) in an ICE – the so-

called clinical workplace SOMDA – and the major elements of the communication protocol stack 3 (cf.

sections 5 & 6) are explained. In section 7, alternative technologies for the protocol stack are

discussed.

3 According to Coulouris et al. [1] a complete set of protocol layers is referred to as a protocol suite or

a protocol stack, reflecting the layered structure.

8


2014-01-14

3 Related Technologies

3.1 ISO/IEEE 11073 standard series

In order to overcome the issue of non-interoperable medical devices, the ISO/IEEE 11073 (x73)

standard series [5] has been developed. The x73 standard series is a set of mature standards which

is frequently referenced and used for distributed systems of medical devices. Examples are the

profiles from IHE PCD domain that heavily rely on parts of the ISO/IEEE 11073 standard series.

However, most often only the domain information model (ISO/IEEE 11073-10201:2004, x73-DIM) as

well as the nomenclature (ISO/IEEE 11073-10101:2004, x73-nomenclature) part that facilitate

medical device interoperability on the semantic level are referenced due to the fact that the underlying

transport protocols do not support the needs of current architectures of distributed systems of medical

devices.

3.2 Open Surgical Communication Bus

There is a long history of projects in Germany that deal with the topic of distributed systems of medical

devices. The project is called OR.NET [6] where the insights and concepts of the predecessor projects

should be consolidated. Moreover, the development of a proposal for a standard – the so-called Open

Surgical Communication Bus (OSCB) – is also in scope of the project. Predecessor projects that

developed architectures and middleware that are mostly compatible to the presented approach in this

whitepaper and that are the fundament for the OSCB are:

SOMIT FUSION

SOMIT OrthoMIT

Smart.OR

TeKoMed

DOOP

All of these projects propose an architecture that is based on the idea of a SOMDA (cf. section 4) and

most utilize DPWS as the fundamental transport protocol, a message model that is based on the x73-

DIM, and the x73-nomenclature in order to achieve for medical device interoperability. Moreover, the

projects developed concepts for risk management of distributed systems of medical devices in high

acuity environments and describe the resulting architectural requirements for these distributed

systems.

9


2014-01-14

4 Service-oriented Medical Device Architecture for an ICE

The proposed architecture for a distributed system of medical devices in an ICE is following the

concept of a clinical workplace service-oriented medical device architecture (SOMDA).

A clinical workplace SOMDA is based on the main principles of a SOA and the relationships between

these two are explained subsequently and in compliance with the “Reference Model for Service

Oriented Architecture 1.0” [7].

In a SOA, a service is a mechanism to enable access to one or more capabilities of a participant,

where the access is provided using a prescribed interface and is exercised consistent with constraints

and policies that are specified by the service description. The service description is also called service

contract. A service can send or receive messages over at least one network endpoint – usually an

address. The messages are often SOAP messages (cf. section 9.1) that are transmitted via an

underlying protocol like HTTP.

Besides the service itself, there exist three major roles that a participant in a SOA communication

scenario (see Figure 2) may take.

Figure 2 General functional role model in a SOA following the publish–find–bind–execution paradigm.

A service provider offers the use of its capabilities by means of a service. A service provider

announces itself with its service description of the interface to a service registry4. Hence, the service

registry is itself a service provider that provides the service description to a service consumer and thus

facilitates the discovery/finding of services.

A service consumer needs a service in order to fulfill its intended use. After discovering a matching

service provider the communication is initiated by the service consumer and the communication to the

service provider is established. Between service consumer and service provider information is

exchanged using messages following the remote invocation communication paradigm. For remote

invocation either the request-response or one-way message exchange pattern is used.

The application of SOA principles on device communication is called service-oriented device

architecture (SODA) [8]. In a SODA, a service that encapsulates the functionality or the interface of a

device is called a device service.

In a SODA, events are used to communicate data to service consumers in addition to remote

invocation. In that case, the information stream is initiated by the service provider. A service consumer

receives the information if and only if it has subscribed to the information stream. Event transmission

can either follow the solicited-response or the notification message exchange pattern and follows the

indirect communication paradigm.

4 Even though the described architecture seems to rely on central components like a service registry

all of these components could also be realized in a de-centralized way.

10


2014-01-14

If a SODA is applied to a distributed system of medical device, it is defined as a service-oriented

medical device architecture (SOMDA). Hereinafter, for a service that encapsulates a medical device,

the term medical device service is used.

If the participants of a distributed system of medical devices are either responsible for one clinical

workplace only or are a proxy service for another system5, the SOMDA is called a clinical workplace

SOMDA. It should be noted that the abstract concept of a clinical workplace SOMDA does make any

assumptions of the underlying network topology.

4.1 Exemplary setup

An exemplary setup of a clinical workplace SOMDA is depicted in Figure 3 and explained hereinafter.

In a clinical workplace SOMDA, each medical device is connected to a shared messaging backbone,

e.g. an IP network. The medical device offers and/or uses services, e.g. a vital sign monitoring service,

a ventilation service or an infusion pump service, in order to fulfill its intended use.

For example, to perform an “audio pause” on a specific medical device, e.g. infusion pump, the vital

signs monitor (service consumer) has to discover the medical device service at first using the

capabilities of the service registry.

Afterwards, it sends a message to the discovered network endpoint that is associated with the medical

device service of the infusion pump. If appropriate, the infusion pump will execute the command and

return an acknowledge message to the vital signs monitor.

Communication between a smart app and the anesthesia workstation serves as an example for the

utilization of the publish-subscribe pattern. In order to display waveforms all devices from a clinical

workplace (medical device services) in the depicted setting, a smart app (service consumer) has to

discover all medical devices that offer waveform streams. In Figure 3 the anesthesia workstation as

well as the vital signs monitor possess a waveform component and therefore are relevant medical

device services. After the discovery phase, the smart app subscribes to the network endpoints

specified in the service descriptions of both medical device services. Each medical device service

publishes waveform frames periodically to the described multicast network endpoint. These frames are

used to display the waveforms at the smart app.

Figure 3 Conceptual view of a service-oriented medical device architecture for a clinical workplace.

5 A proxy service in a clinical workplace is an external interface to systems like e.g. network gateways,

EHRs, central stations, wireless sensor networks or even other clinical workplace SOMDAs.

11


2014-01-14

4.2 Clinical Workplace SOMDA & Web Services

In order to implement a clinical workplace SOMDA, the utilization of Web Services (WS-*)

specifications is one possible solution.

4.2.1 Web Services Profiles

In Web Services terms, a Web Services profile is a set of guidelines on how to use a set of Web

Services specifications for a given purpose or application. Web Services specifications allow

implementers to choose from a variety of message representations, text encodings, transport

protocols, and other options, some of which are not interoperable. By constraining these decisions,

Web Services profiles ensure that conforming implementations will work well together. An example for

a profile is the Device Profile for Web Services.

4.3 Protocol Stack for Medical Device Interoperability

For the implementation of a distributed system of medical devices in a high acuity environment based

on the principles of a clinical workplace SOMDA, the Medical Device Profile for Web Services

(MDPWS) as well as the Basic Integrated Clinical Environment Protocol specification (BICEPS) are

recommended as technical specifications for the communication inside of the distributed system.

MDPWS is based on the Device Profile for Web Services (DPWS).

Figure 4 Overview of the proposed protocol stack for Medical Device Interoperability in an ICE.

The proposed communication protocol stack is depicted in Figure 4. DPWS is the foundation of the

communication protocol stack and provides means for service discovery including service description

at runtime as well as messaging and event propagation over an IP-based network. MDPWS adds

additional means that are needed to fulfill specific requirements for a clinical workplace like waveform

streaming or remote control that ensures patient-safety. DPWS and MDPWS are explained in section

5. On top of these Web Services profiles BICEPS provides a basic message information model as well

as medical device services to communicate within a clinical workplace context. BICEPS is not

intended to be used to communicate between different clinical workplace SOMDAs (see Figure 5).

12


2014-01-14

Figure 5 Relationship between SOMDA, clinical workplace SOMDAs and BICEPS in an exemplary

setup for 5 operating theatres and one ICU (right side)

Moreover, BICEPS may be extended by additional device-specific extension protocols and medical

device services, if additional capabilities of a medical device should be published as a service in an

ICE.

The device-specific extensions may use other Web Services profiles or other network protocols than

MDPWS. For example, an additional medical device service could be offered for example that

transmits medical images using DICOM or

offers video streams using dedicated other protocols or

demographic or lab data of patient.

These medical device services are not in scope of BICEPS, but could of course be offered as a

medical device service or proxy service to the participants of clinical workplace SOMDA.

BICEPS as well as the before stated extensibility concept are explained in more detail in section 6.

13


2014-01-14

5 The Medical Devices Profile for Web Services

The Medical Device Profile for Web Services (MDPWS) is based on the Device Profile for Web

Services (DPWS) [9] – in version 1.1. DPWS is an OASIS standard since June 2009 – and defines a

minimal set of Web Services specifications for resource-constrained devices that possess an IP-based

network interface.

The origins of DPWS are in the consumer electronics domain where it is used in network printers or

image scanners to allow plug & play. It had been pushed forward by Microsoft for printer integration

and consequently all Microsoft Windows OS starting from Vista already include a native DPWS stack.

The main concept behind DPWS is shown in Figure 6. In a DPWS setup there exist at least one client

– an endpoint in the network and service consumer in a SOA – which sends respectively, receives

messages. The partner in the messages exchange is a service (service provider in SOA). There exist

two types of services: Device and hosted service.

Figure 6 Overview of the key components of DPWS. Adapted from [9].

A device is a service, also called hosting service that acts primarily as metadata resource for device-

wide data. A device can contain other services, so called hosted services, which are bound to their

hosting service regarding life-time, but can be addressed separately.

DPWS provides the following functionalities:

- Discovering DPWS-capable devices on the network and their offered hosted services

- Describing services by providing a WSDL file

- Interacting with a service based on its service description

- Subscribing to and receiving notifications from a Web Service

14


2014-01-14

Figure 7 DPWS profiles a set of WS-* specifications.

In order to provide these functionalities, DPWS leverages and profiles a set of other specifications (cf.

Figure 7). Specifications that are not described in the remainder of this section, but that are utilized in

DPWS, are summarized in section 9.1.

For a clinical workplace SOMDA implementation based on DPWS the role model (see Figure 1) looks

like in Figure 8. Starting with subsection 5.2, the requirements for a communication protocol for

medical device interoperability (cf. Table 1) are mapped to the specification of DPWS.

Figure 8 Role model for a SODA based on DPWS. The main differences are due to the multicast

service discovery that does not rely on a central component for the service registry role.

5.1 DPWS & Openness

One major aspect of the requirement openness is the capability of a protocol stack to be extensible for

future communication needs. Web Services are designed for extensibility as they are mostly defining

only abstract mechanisms. How to use these mechanisms in a deployment is up to the application

designer.

Hence, DPWS is also only an enabling technology and provides basic features. These features can be

extended by application specific protocols on a higher level in order to tailor DPWS to each application

scenario. For these application specific extension protocols, the protocol designer decides which and

how the features of DPWS fit to the requirements of the scenario. These decisions are essential for

properties such as performance, reliability, scalability, and extendibility of the resulting application.

15


2014-01-14

This basic principle is not clearly stated in the DPWS specifications and may lead to

misunderstandings.

Besides extending DPWS it is also possible to further restrict the specification as long it is

interoperable with DPWS.

5.2 Discovery

The dynamic discovery feature of DPWS is based on WS-Discovery [10] and SOAP-over-UDP. WS-

Discovery is a service localization protocol and has been standardized in the context of the DPWS

standardization process. Subsequently, WS-Discovery is described in the way it is used in the DPWS

specification and not in its generic form.

For the purpose of discovery, the device acts as a so-called target service and presents a stable

unique identifier (UUID) to the network and one or more transport addresses. In this case stable is

defined that the unique identifier does not change after restarting the device. Hosted services should

not act as target service.

Every device has to announce itself by sending a Hello message, when it is connected to the network

and ready to exchange messages with other endpoints. The Hello message is a SOAP message that

is send via IP multicast and contains at least the unique identifier of the device as well as a metadata

version. When a device is preparing to leave the network, a one-way Bye message should be sent via

IP multicast. This part of the discovery process is called implicit discovery as the device allows other

network endpoints to discover it by implicitly listening to its Hello messages.

Figure 9 Exemplary message sequence for explicitly discovering a service provider [10].

A typical message sequence in order to explicitly discover a service provider is shown in Figure 9.

A client may send a Probe message to find devices of a given type and/or for a given scope.

Alternatively, a Probe message could be used to find any DPWS-compliant device regardless of their

types or scopes. For this purpose, DPWS defines a specific type that allows the identification of

DPWS-compliant devices. The Probe message is sent via IP multicast.

A device has to answer a Probe message if it matches the type and/or scope. The Probe Match

message includes the endpoint reference, a stable unique identifier, as well as the metadata version

16


2014-01-14

of the device. Furthermore, it can include scopes, types and transport addresses of the device. The

Probe Match message is send by UDP unicast.

If a client knows the UUID of a device and the transport address is not already known, it can use a

Resolve message to retrieve the transport addresses of the device. The Resolve message is sent via

IP Multicast. The device that matches the Resolve message has to answer the request. The Resolve

Match message is sent via UDP unicast.

As most of these mechanisms are based on two one-way message exchanges, the complete

discovery scenario can take several seconds. But this complete case is not required in all scenarios. It

should be considered that a client can access device metadata by other means and still conforms to

DPWS. A client can use data about the device that is available in advance, e g., at development time

or can use mechanisms like caching of metadata. Depending on the scenario, these message

exchanges can and should be kept at a minimum. [11]

Figure 10 Exemplary implicit and explicit discovery procedure.

In Figure 10 two discovery procedures are shown. First, the client on the left hand side is already

running and waiting for a service provider. The device, that hosts the service provider, is started and

announces itself. The client receives the Hello message of the device and thus – after resolving the

stable unique identifier – is able to directly start the interaction with the device (service provider). This

prevents periodically polling for a service provider of a specific type.

In the second discovery sequence, the other client on the right hand side is started after the device.

Thus, the client missed the Hello message and must search for that service. The search includes

sending a Probe message and optionally a Resolve message so that afterwards the transport

addresses of the device are known.

5.3 Liveliness

MDPWS defines that a client may send a directed Probe message as specified in DPWS to a device in

order to assure that the medical device service is still active.

5.4 Service Description

Every device is capable of describing itself and all the services it hosts. For this purpose the device

implements the Get message of the WS-Transfer specification. The reply of a Get message contains

the following information:

- The model of the device (name, manufacturer, etc.)

- The device itself (firmware, serial number, etc.)

17


2014-01-14

- Its hosted services (by listing their endpoints, types, …)

Once the endpoint reference of a hosted service has been discovered, a GetMetadata message can

be sent to the hosted service to request its service description. DPWS leverages the WS-

MetaDataExchange specification for that purpose. The response to the GetMetadata message

contains the following information:

- An inline WSDL (see 5.4.1) or a reference to the WSDL, if the hosted service does not include

its WSDL in the GetMetadata response message

- Any policies according to Web Service Policy Framework (WS-Policy) the hosted service

enforces.

5.4.1 Web Services Description Language

Web Services Description Language6 (WSDL) [12] is a specification defining how to describe Web

Services in a common XML grammar. WSDL describes four critical pieces of data:

- Data type information and structure for all incoming and outgoing messages

- Interface information describing all publicly available functions

- Binding information about the transport protocol to be used

- Address information for locating the specified service

Hence, the WSDL service description represents the service contract between a client and the service

provider. There exist two major versions of the WSDL specification. Version 2.0 tries to fix some of

problems of Version 1.17, which is referenced by DPWS, but is not adopted widely.

WSDL is extensible to allow description of service providers and their messages regardless of what

message formats or network protocols are used to communicate, however, the only bindings

described in the specification itself lay down how to use WSDL in conjunction with SOAP, HTTP

GET/POST, and MIME.

5.4.2 WS-Policy

Since Web Services are platform, programming language and transport protocol independent, different

service implementations may have different capabilities, requirements and quality of service

characteristics even if they implement the same interface.

In the WS-* world, there exist two specifications that allow expressing these declarations:

- WS-Policy Framework

- WS-Policy Attachment

WS-Policy Framework defines a framework and a model for expressing policies that refer to domain-

specific capabilities, requirements, and general characteristics of entities in a Web Services-based

system. A policy is a collection of policy alternatives. A policy alternative is a collection of policy

assertions. A policy assertion represents a requirement, capability, or other property of a behavior. A

policy expression is an XML Infoset representation of its policy, either in a normal form or in its

equivalent compact form. Some policy assertions specify traditional requirements and capabilities that

will manifest themselves in the messages exchanged (e.g., authentication scheme, transport protocol

selection). Other policy assertions have no wire manifestation in the messages exchanged, yet are

6 This is just a short summary of the WSDL specification. A good introduction can be found on

http://www.developer.com/services/article.php/1602051/WSDL-Essentials.htm.

7 A good overview regarding the differences between WSDL 1.1 and WSDL 2.0 can be found on

http://weblogic.sys-con.com/node/219029.

http://www.developer.com/services/article.php/1602051/WSDL-Essentials.htm

http://weblogic.sys-con.com/node/219029

18


2014-01-14

relevant to service selection and usage (e.g., privacy policy, quality of service). WS-Policy

Framework provides a single policy language to allow both kinds of policy assertions to be expressed

and evaluated in a consistent manner. [13]

Nevertheless, WS-Policy Framework does not cover discovery of policy, policy scopes and subjects,

or their respective attachment mechanisms.

WS-Policy Attachment defines mechanisms especially for associating policies with arbitrary XML

elements or WSDL resources. A policy attachment is a mechanism for associating a policy with one or

more policy scopes. A policy scope is a collection of policy subjects to which a policy applies. A policy

subject is an entity (e.g., an endpoint, message, resource, interaction) with which a policy can be

associated. [14]

5.5 Events & Streams

In the enterprise world, Web Services are normally used in remote invocation scenarios, where a

service consumer invokes the execution of a service operation from the service provider and receives

a response.

In contrast to these scenarios, a lot of communication in a clinical workplace SOMDA is based on

events. For example, alarm information is sent when the triggering event occurs or real-time data is

transmitted periodically. Hence, indirect communication based on solicited-response and notification

message exchange patterns should be supported in addition to remote invocation in order to reduce

network traffic by conveying the information about the event as it happens.

For a clinical workplace SOMDA based on Web Services and especially MDPWS that does not rely on

centralized components, there exist two different solutions that support these message exchange

patterns:

1. An approach based on the publish-subscribe paradigm using WS-Eventing as defined for

DPWS.

2. An approach based on group communication that utilizes SOAP-over-UDP multicast.

Both approaches are described hereinafter.

5.5.1 WS-Eventing

WS-Eventing [15] is a specification that follows the publish-subscribe paradigm and that defines a

protocol for managing subscriptions for a Web Services based event mechanism. The protocol defines

three endpoints: subscriber, event source and subscription manager.

In WS-Eventing the event source can delegate the management of subscriptions and distribution of

events to a subscription manager that is another service. This is practical for scenarios where the

event source cannot or should not handle the list with all subscriptions.

However, WS-Eventing specifies only the management of the subscribers, but not how the events

should be transmitted. Most common is to use SOAP-over-HTTP to transmit the event to the

subscribers.

5.5.2 SOAP-over-UDP Streaming

The second solution is based on the multicast functionality of the underlying network. In this case, a

service provider sends messages via IP multicast to a group of unknown service consumer, which

results in only one message transmission from the publisher to the multicast group. The distribution to

the recipients is managed by the underlying network. The required specification to employ multicast

messaging in Web Services is SOAP-over-UDP [16] which is also included in the OASIS

standardization process of DPWS. SOAP-over-UDP is a specification, which defines that the content

19


2014-01-14

of a message is contained in a SOAP envelope and transmitted via IP Multicast. Besides plain UTF-8

encoded SOAP messages it is also possible to send binary encoded SOAP messages, e.g., using

EXI (see subsection 5.8).

5.5.2.1 WS-Streaming

Even though SOAP-over-UDP is standardized the announcement that this method is utilized for

message transmission has not been standardized. For that reason, WS-Streaming8 has been

developed that defines a policy to embed descriptive information on streams provided by a service in

the WSDL of the service. Furthermore, WS-MetaDataExchange can be utilized to allow a service

consumer to request the defined WS-Streaming policies that might not be included in WSDL.

Like most other WS-* specifications, WS-Streaming does not explicitly define a specific protocol for the

management of subscriptions to the stream or the transport of the stream content. Instead it is a

generic framework to announce the existence and the type of a stream. One possible stream type is

the before mentioned SOAP-over-UDP IP multicast transmission.

5.6 Safety

A communication protocol for remote control in a distributed system of medical devices must ensure

that the patient safety is not compromised. Therefore, the remote control mechanism has to be at least

single fault safe. Moreover, it may be a risk control measure that a service provider allows only those

service consumers to invoke a remote control service operation that transmit the remote invocation

context. Another risk control measure may be that only authorized service consumer can access the

remote control service operations.

The latter requirement is discussed in section 5.7.1. The first two requirements can be addressed by

utilizing two channels to transmit the data and by transmitting the remote invocation context with the

SOAP request message. The specification for the communication protocol that addresses these

requirements is part of MDPWS and is explained hereinafter, but before the mechanisms are

explained.

5.6.1 Dual Channel Transmission

A typical approach to ensure single fault safety inside of a medical device is the utilization of so-called

dual channel architectures for the modification of parameters that are related to patient safety, where

one information is transmitted via two different communication means and only if data from both

channels represent the same information it is assumed that there hasn’t been a communication failure.

This approach can be transferred to a communication protocol for a distributed system of medical

devices. The detailed requirements for such a communication protocol are described in [17].

In general, there exist two concepts for transmitting two channels over one physical communication

channel:

- Separation in Time: Both channels are transmitted in timely separated messages that are

related.

- Separation in Representation: The service provider detects a failure, e.g., by means of an

invalid checksum.

MDPWS utilizes the latter approach that is explained afterwards. On overview about the “Separation in

Time” and examples for the “Separation in Representation” approach is given in Poehlsen et al. [17].

8 WS-Streaming is part of the MDPWS specification and has not been published as an official

standard.

20


2014-01-14

5.6.1.1 Separation in Representation Approach

The problem with the “Separation in Time” approach is that the protocol is a stateful protocol and

hence complex to implement. Furthermore, the network load is high due to three messages that have

to be transmitted. The “Separation in Representation” approach overcomes these drawbacks by

sending both channels in only one message. Therefore, the message has to contain the two channels,

which need to have different representations of the information that should be transmitted.

The process is depicted in Fig. 1. The service consumer is depicted on the left-hand side. It wants to

transmit the same data from two channels to the service provider that is depicted on the right-hand

side. For this purpose the service consumer passes the data from both channels in the programming

language data format (Java object, C struct, ...) to the middleware that implements the communication

protocol. The middleware serializes the data with its serializer components to the “wire-format”, e.g. a

SOAP message. Afterwards the checksum calculator component calculates the checksum. Before

sending the data with the appended checksum, the middleware takes care that no failure9 occurred

during serialization. To verify that the serialized data is valid it is re-parsed into the native data format.

A comparator compares this data object with the second channel. In case of consistency the

middleware is allowed to transmit the serialized data with the checksum.

Fig. 1 “Separation in representation” for functional safety. On the left-hand side, a service consumer

passes data twice to the middleware which takes care about functional safety. On the right-hand side,

the middleware passes both “channels” to the service provider. The middleware components that are

embedded in a gray box control each other by verifying their data output.

On the service provider side it is not possible to start with the checksum validation process, since the

serialized data might have got corrupted directly after validation10

. Thus, the serialized data has to be

parsed first by the middleware. Afterwards, the middleware creates a copy of the data object, re-

9 The serialized data could be corrupted in the RAM directly or corrupted serialized data could be

generated by a corrupted serializer.

10 In other words: validating the checksum before duplicating the data removes the “second channel”.

21


2014-01-14

serializes this data object and compares the checksum of this data with the received checksum. This

is necessary to detect a failure in the parser component or the duplication of the data.

The serialization process on the service consumer is supervised in the sender’s middleware with the

parser component and the following comparison with the second data channel. It can be concluded

that the checksum calculation uses valid data. On the service provider side, the parsing process and

the data duplication generating the second channel are controlled. This is achieved by verifying the

data copy with the received checksum, thus it can be guaranteed that the parsing and data duplication

process did not corrupt the data.

To sum up, in the “Separation in Representation” approach the serializer is supervised by the parser

within the same middleware and vice versa, while the checksum calculation is verified by the

checksum calculation in the middleware.

5.6.2 Safety Context

In order to transmit a remote invocation context a service consumer first needs to know which

information is required by the service provider and then append the information while invoking a

service operation.

Examples for context information required by a service provider may be the value of a setting before

the requested new value has been applied or the unit of the setting. If information for both is attached

to a request message for a remote control service operation, the service provider may use the

information to make sure that the service consumer did the invocation while possessing correct

information about the state of the setting.

5.6.3 WS-SafetyInformation

WS-SafetyInformation is a specification for a communication protocol that allows dual channel

transmission and the transmission of safety context. WS-SafetyInformation has been developed as

part of the MDPWS specification, but is not yet standardized. It specifies policy assertions that signal a

service consumer to attach safety context information to a remote invocation message or to utilize dual

channel transmission for remote invocation. The policy assertions may be embedded in the WSDL of

the service. Furthermore, WS-MetaDataExchange can be utilized to allow a service consumer to

request the defined policy assertions that might not be included in the WSDL. Moreover, the policy

assertions can also be attached to any other extension point in a message where policy assertions are

allowed. Additionally, the definition of message parts for a dual channel SOAP header element and a

safety context SOAP header element are also part of the WS-SafetyInformation specification.

The dual channel SOAP header element contains the information of the second channel. The default

representation is a Base64-encoded SHA-1 digest of the XML element that contains the information of

the first channel after an optional transformation has been applied. The default transformation is

exclusive XML canonicalization which is the recommended standard of the W3C.

The safety context SOAP header element possesses two parts: the information itself and an

identification of the information so that it could be associated with the requirement of the service

provider.

5.7 Security

DPWS provides a flexible security mechanism by means of security profiles. A security profile is

defined as a set of rules service provider agree upon for securing their communication.

In a clinical workplace SOMDA, the security goals are Access Control, Confidentiality, and Integrity.

22


2014-01-14

5.7.1 Access Control

Access control is based on authentication and authorization. In a SOMDA, both service provider and

service consumer are security principals that can be authenticated by proving their identity to some

other party. Authorization means the determination of the access rights a security principal has.

Regarding authentication, an important aspect concerning the technical realization is the decision

whether each security principal should be treated individually, i.e., with specific access credentials, or

whether multiple security principal share a “group key”. Typically, individual access control is realized

by cryptographic algorithms with asymmetric keys, e.g., using X.509 certificates. An example for a

shared secret key method are private wireless networks (WLANs), where all eligible participants share

a common password, the so-called “pre-shared key” (PSK). If this shared secret key is uncovered or if

access of a single principle shall be withdrawn, the PSK needs to be exchanged for all principles.

For this reason, MDPWS specifies that if access control is needed it is handled on the level of

individual security principals by utilizing a public-key infrastructure based on X.509 certificates for

each security principal. The X.509 certificates are the basis for securing the message exchange via

HTTPS with mutual authentication and/or signed SOAP messages based on WS-Security.

MDPWS specifies that a service provider may control access to a service by HTTPS with mutual

authentication. This also applies to the subscription manager where the credentials may be used to

determine if a service consumer has the right to subscribe to an event. For repudiation purposes a

service provider may require the service consumer to sign the request.

5.7.2 Public-Key Infrastructure for a clinical workplace SOMDA

DPWS specifies that each service provider possesses a UUID. MDPWS specifies that the X.509

certificate is issued to the service provider’s UUID. Furthermore, MPDWS specifies that also a service

consumer is uniquely identifiable by a UUID and that the X.509 certificate is issued to that UUID.

MDPWS defines that a service consumer or service provider may have a Device Access Control List

(DACL). The DACL contains the subject identities of security principals and the associated granted

access rights. If the DACL is configurable only by the manufacturer, the DACL is called manufacturer

DACL.

Nevertheless, a X.509 certificate per security principal on its own is not efficient for access control as

a third party would need to know all subject identities (UUIDs) and the associated granted access

rights. Hence, it is necessary to allow groups of security principals. In the DACL the group subject

identities would be stored in that case. Examples for such groups are a group of all devices of the

same kind or a group of all devices of a manufacturer.

As a central, cross-manufacturer certification authority for medical devices may not be established in

the near future, an obvious solution is that each manufacturer issues own X.509 certificats for its

security principals.

If the manufacturer places the subject identity of their manufacturer certificate in the DACL of every

service consumer or service provider, these could check the affiliation of the security principals of the

same manufacturer. Furthermore, it is possible that a manufacturer deposits subject identities of other

manufacturers in the manufacturer DACL of its service consumer or service provider to identify

security principals of that second manufacturer. Individual access control cannot be achieved with this

approach, as it only checks for the manufacturer’s identity. Nevertheless, it is assumed that all devices

of the same manufacturer implicitly trust each other. For security principals of third parties it has to be

determined during the risk management process if it is acceptable for a manufacturer to trust all

service principals of a second manufacturer. An alternative is that the first manufacturer grants access

for a group of service principals of the second manufacturer by utilizing the related group subject

identity instead of the manufacturer’s subject identity.

23


2014-01-14

The integration of additional security principals by a responsible organization as defined by IEC

80001-1 is also possible. The IEC 80001-1 [18] stipulates the role of a Medical IT-Network Risk

Manager. This role is responsible for the risk assessment when integrating medical devices into an IT

network. Therefore, if access control in addition to that defined by the manufacturer is necessary as a

risk control measure, the Medical IT-Network Risk Manager is the responsible person.

To support the Medical IT-Network Risk Manager, a manufacturer may offer the possibility to grant

additional access rights to Medical IT-Network Risk Managers by uploading an additional DACL.

5.7.3 Confidentiality & Integrity

MDPWS defines that if confidentiality and integrity of message transmission is required, SOAP-over-

HTTPS should be applied. SOAP-over-HTTPS may also be used for the transmission of events. The

service provider may require a service consumer to provide a secured network endpoint as event sink.

As SOAP-over-UDP is mostly used for streaming of real-time data (WS-Streaming), no confidentiality

mechanism is defined by MDPWS as all available mechanisms11

may not be suitable due to the

cryptographic burden.

5.8 XML Manifestation

Like Web Services in general, DPWS uses XML in its human readable UTF-8 encoded manifestation.

The advantages of using the human readable manifestation may imply overhead during transmission.

A common misunderstanding concerning encoding is the obligation to encode everything in UTF-8. If

there is no need for the flexibility given by UTF-8 XML encoding, binary encodings for data can be

used. DPWS offers several mechanisms to use binary data. On the one hand, there is the attachment

mechanism that enables the attachment of arbitrary binary data. These attachments use the SOAP

Message Transmission Optimization Mechanism (MTOM) [19] that leaves further space for

optimizations. On the other hand, it is possible to use an alternative encoding of the XML data itself.

SOAP is based on the XML Infoset specification, which defines an abstract data set that can be used

to represent information in well-formed XML documents. [20]

Binary XML refers to any specification which defines a compact representation of XML in a binary

format. Using a binary XML format generally reduces the verbosity of XML documents and cost of

parsing, but hinders the use of ordinary text editors and third-party tools to view and edit the

document. Binary XML is typically used in applications where standard XML is not an option due to

performance limitations. While there are several competing formats, none has been accepted as a de

facto standard.

Alternatives to Binary XML include using traditional file compression methods on XML documents (for

example gzip) or using ASN.1. Traditional compression methods, however, offer only the advantage of

compression, without the advantage of decreased parsing time or random access. ASN.1 is being

used as the basis of Fast Infoset [21] which is one binary XML standard.

The major challenge for binary encoded XML is to create a single, widely adopted standard. The

International Organization for Standardization (ISO) and the International Telecommunications Union

(ITU) published the Fast Infoset standard in 2005 and 2007, respectively. The World Wide Web

Consortium (W3C) has released the Efficient XML Interchange (EXI) [22] format specification as a

recommendation. A good overview of compression performance is given G. Moritz et al. [23].

11 Due to the fact, that TLS is not feasible for SOAP-over-UDP, a different mechanism either based

on SRTP[http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol], DTLS

[http://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security] or WS-Security may be possible.

http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol

http://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security

24


2014-01-14

EXI has been defined by MDPWS as the means for compact message representation if this required.

25


2014-01-14

6 Basic Integrated Clinical Environment Protocol Specification

The Basic Integrated Clinical Environment Protocol Specification (BICEPS) is a communication

protocol specification that facilitates medical device interoperability in a distributed system of medical

devices that follows the SOMDA architecture paradigm. BICEPS has the objective to allow

communication between participants in a distributed system of medical devices in high acuity

environments that directly interact with, monitor, provide treatment to, or are by some other means

directly associated with a single patient.

BICEPS is in parts inspired and based on the ideas of the x73 standard series, especially the x73-

DIM standard. Moreover, BICEPS defines that the primary nomenclature source should be the x73-

nomenclature.

6.1 General BICEPS Overview

BICEPS specifies a message information model (BICEPS-MIM) for the domain of distributed systems

of medical devices as well as associated services. BICEPS does not define a specific communication

protocol that should be utilized to transport the messages. The conceptual model of a medical device

service interface that utilizes BICEPS for communication follows in large parts the ideas of the x73 as

depicted in Figure 11.

Figure 11 conceptual model of a medical device service and the corresponding model of x73.

The ACSE12

component is a means for establishing a logical connection between communication

partners and is similar to the discovery component of BICEPS. BICEPS discovery facilitates Plug &

Play in a distributed system of medical devices and relies on one part for describing the clinical data

and remote control capabilities of a participant and another one that allows the discovery of a

participant’s services. The BICEPS discovery component is explained in section 6.3.

The Medical Device Information Base (MDIB) is in x73 as well as in BICEPS an object-oriented

database storing the state of a medical device in terms of managed medical objects13

. The MDIB is in

both specifications a conceptual model only and a BICEPS service provider is not required to

implement the MDIB in form of a database.

12

association control service element of X73

13 A managed medical object may for example be physiological data of a patient, data on device

configuration or a remote invocation operation.

26


2014-01-14

In x73 it is specified that managed medical objects are accessible only through services provided by

the CMDISE14

. BICEPS also defines a set of services that control access to the managed medical

objects of the participant’s MDIB. These services are called BICEPS services. The relationship

between the CMDISE services and the BICEPS service interfaces is depicted in Figure 12.

Figure 12 Relationship between CMDISE services in x73 and BICEPS service interfaces. It should be

noted that this is not an exact mapping

6.2 Message Information Model

A typical communication message, which is exchanged in a distributed system of medical devices in a

high acuity environment, contains state data about clinical measurements of a patient or a medical

device associated with a patient. Moreover, a communication message may contain remote invocation

commands to control the state of a medical device. In order to facilitate medical device interoperability,

it is necessary for a participant of a distributed system of medical devices to exchange descriptive

meta-information about the state data as well as contextual information that describes in which context

the state data has been acquired.

The BICEPS message information model (BICEPS-MIM) defines a set of communication messages of

the above defined types. It should be noted that the BICEPS-MIM does not define a communication

message for every possible kind of measurement data, setting data, contextual information or remote

invocation command, but rather provides extensibility mechanism as part of the BICEPS-MIM that

make it possible for a participant to convey additional data in a message or to transmit a completely

new type of message.

The BICEPS-MIM is closely related to the x73-DIM, but it is not an exact copy of it. As the BICEPS

has been designed with the idea in mind to specify only the essential messages that are needed in a

distributed system of medical devices in a high acuity environment, only a subset of the packages of

the x73-DIM have been used to model the BICEPS-MIM. Those packages as well as those that have

not been included into the BICEPS-MIM are shown in Table 2.

It should be noted that most objects from the packages in scope have been revised substantially and

that even if a package is in scope of the BICEPS-MIM not all objects of the x73-DIM package are part

of the BICEPS-MIM.

14 Common medical device information service element

27


2014-01-14

Packages in scope of BICEPS-MIM Packages out-of-scope of BICEPS-MIM

Medical Archival

Alert Extended Services

Control Communication

System

Patient

Table 2 Package of x73-DIM that are in and out-of-scope of BICEPS

The BICEPS-MIM has two components: the message definitions and the MDIB component. Figure 13

shows both a top-level view of the x73-DIM packages and major classes as well as a top level view of

parts of the MDIB component of the BICEPS-MIM. The message component is explained in detail in

the context of the BICEPS services (see section 6.4).

Figure 13 Packages of the x73-DIM and a top level overview of the BICEPS-MIM (right). 15

The BICEPS-MIM MDIB component defines the following structure to model a medical device:

Medical Device System (MDS): Abstract representation of a physical medical device that

exposes its capabilities as a medical device service. Unlike the x73-DIM, BICEPS-MIM

defines just one specific subclass for an MDS: a HydraMDS. A HydraMDS may contain

multiple VMDs.

Virtual Medical Device (VMD): Representation of a sub-system of a MDS, which may contain

channels and an alert system.

15 The BICEPS-MIM are depicted in the XML Schema Notation from Altova XML Spy.

28


2014-01-14

Channel: Representation of a group of related metrics and an optional alert system. A

Channel is not depicted in Figure 13.

Metric: Abstract representation of a measurement, setting, or status information. A Metric is

not depicted in Figure 13. BICEPS-MIM specifies the following subtypes of a metric:

o Numeric metric: Representation of numerical measurements, settings, or status

information.

o String metric: Representation of textual information.

o Enumeration metric: Representation of textual information where the possible content

is constrained by defined enumerated values.

o Real Time Sample Array metric: Representation of a sample array of numerical

measurements.

Context: Representation of the context the MDS is currently working in.

SCO: Representation of a service controller (see section 6.2.1) that comprises offered remote

invocation capabilities and on which objects they could be executed. Moreover, this contains

the associated QoS parameter for each operation.

Alert System: Representation of an alert system that detects alert conditions and as

appropriate may signal alert signals.

Alert Condition: Representation of an alert condition that contains information about a

potentially or actually hazardous situation. An alert condition is not depicted in Figure 13.

Alert Signal: Representation of an alert signal that contains information about how an alert

condition potentially or actually is signaled to an operator. An alert signal is not depicted

Figure 13.

Moreover, all objects in the model possesses extension points, which allow the definition and adding

of completely new types or adding of extended types instead of those defined in the BICEPS-MIM.

6.2.1 Service Controller

The service controller comprises the set of remotely invocable operations that if appropriate modify the

state of parts of the medical device.

The BICEPS-MIM MDIB component defines among others the following set of modifying remotely

invocable operations:

SetValue: Modification of a numeric attribute of an object.

SetString: Modification of a string attribute of an object.

SetAlertState: Modification of an alert state.

Activate: Trigger execution of an operation that makes (complex) changes to the state.

It should be noted, that the remotely invocable operations of the BICEPS-MIM MDIB component don’t

define the message that needs to be transmitted to the medical device service by a service consumer,

but rather a proxy that describe what effect the message will have on the state and which QoS

requirements a service consumer may need to fulfill in order that its modification request will be

processed.

The BICEPS-MIM does not define any QoS requirements itself as most QoS requirements are not

related to the message model but to the actual transport of messages and the risk management of the

individual medical device. Therefore, a remotely invocable operation provides only an extension point

where the QoS requirements can be added.

6.2.2 MDIB parts

In contrast to the x73-DIM, the BICEPS-MIM explicitly distinguishes between content data and meta-

information that describes this content and allows interpretation. Content data can be

29


2014-01-14

measurement/setting data or contextual information. As depicted in Figure 14, the BICEPS-MIM MDIB

component comprises two parts: a descriptive part and a state part. The descriptive part holds the

meta-information and the state part the content data.

Figure 14 The BICEPS-MIM MDIB component is comprised of two parts: descriptive and state.

The descriptive part of the MDIB component describes the capabilities of the medical device with

respect to offered metrics, remotely invocable operations, alert management, and context handling.

Most descriptors make use of referencing externally defined “concepts”, e.g. for types of

measurements or units of measurements. Every description possesses a so-called handle that is

unique identification of the description inside the MDIB of a medical device service. Depending on the

type of medical device, the descriptive part is normally quite static over the lifetime of a medical device

service. Nevertheless, it is possible to notify interested service consumers about changes of the

description.

The state part of the MDIB component comprises the current dynamic state of the medical device, e.g.

the current value of a measurement and the quality of the measurement. A state of a medical device

object that is stored in the MDIB also possesses a unique handle, but moreover it also references to

its related description by means of a handle reference. The current state can be conveyed to

interested service consumers by different means that are explained in section 6.4.2.

6.3 Discovery

BICEPS discovery fosters Plug & Play by defining requirements for a transport communication

protocol as well as by defining a set of medical device service operations that allow a service

consumer to retrieve a description of the capabilities of the medical device offered on the network

BICEPS Discovery defines that a transport communication protocol must allow implicit and explicit

discovery of BICEPS medical device service either via proxy or directly. For that purpose, BICEPS

Discovery defines a discovery type that every medical device service that is BICEPS compliant has to

listen to in a discovery message.

The set of medical device service operations is closely related to the descriptive component of the

BICEPS-MIM MDIB component and the related messages to retrieve the description are explained in

section 6.4.1.

An exemplary discovery sequence is depicted in Figure 15.

30


2014-01-14

Figure 15 Exemplary discovery sequence: the Smart App client searched for a participant in the

distributed system that offers certain capabilities. In this case it looks for a possibility to control a vital

signs monitor.

6.4 Services

BICEPS services defines a set of services that control access to the managed medical objects of the

participant’s MDIB. The service interfaces are grouped according to functional groups. It should be

noted that a BICEPS compliant medical device service does not need to implement all BICEPS

services. The only mandatory service interface that needs to be implements is the BICEPS Get

Service. As mentioned beforehand, BICEPS-MIM possesses a message component that comprises

the message definitions that can be used to convey data between participants . The message

definitions will be explained with their related BICEPS services.

6.4.1 Get Service

The mandatory BICEPS Get Service defines an interface that allows a client to retrieve the current

description and state of the medical device in a polling mode.

The defined medical device service operations to retrieve the description part of the MDIB are:

GetMDDescription: Allows retrieval of the description part of the MDIB.

GetMDIB: Allows retrieval of the description and state part of the MDIB with one request.

The defined medical device service operations to retrieve the state part of the MDIB are:

GetMDState: Allows retrieval of all currently stored states of the MDIB.

GetMetricStates: Allows retrieval of only the metric states that are currently stored in the

MDIB.

GetAlertStates: Allows retrieval of only the alert states that are currently stored in the MDIB.

6.4.2 Event Report Service

The optional BICEPS Event Report Service defines an interface that allows a client to retrieve

notifications about either changes of the description part of the MDIB or a state that is stored in the

MDIB.

The defined medical device service notifications can be classified either as description update

notifications or as state update notifications. The latter can be furthermore distinguished into periodic

state update notifications and episodic update notifications. Examples for state update notifications

are:

31


2014-01-14

MetricReports

AlertReports

ContextReport

OperationInvokedReport

Examples for description update reports are:

MDSCreatedReport

MDSDeletedReport

ObjectCreatedReport

ObjectDeletedReport

The BICEPS Services specification does not define a means to subscribe to notifications of the

service, but rather specifies a requirement for the transport communication protocol to support

subscription management.

6.4.3 Waveform Service

The optional BICEPS Waveform Service defines an interface that allows a client to retrieve the state of

a stream for real time sample array metrics (e.g. waveforms).

Only the WaveformStream medical device service operation is defined for this BICEPS service. The

BICEPS Services specification does not define a means to subscribe to streams of the service, but

rather specifies a requirement for the transport communication protocol to support subscription

management.

6.4.4 Remote Control Service

The optional BICEPS Remote Control Service defines an interface that allows a client to change the

state of the medical device.

The defined medical device service operations are:

SetValue

SetString

SetRange

Activate

It should be noted that all operations are defined as a pair of request and response message. The

response message does not contain the resulting new state of the managed medical object caused by

the remote invocation, but rather the state of the execution of the remote invocation request.

Subsequent state changes of the execution of the remote invocation request are conveyed to a client

by OperationInvokedReport notifications. The resulting state of the managed medical object is also

conveyed using the respective event notification from the BICEPS Event Report service.

In Figure 16 an exemplary remote invocation of a SetValue medical device service operation by a

Smart App on a vital signs monitor is depicted. The Smart App has discovered the medical device

service beforehand, and subscribes to OperationInvokedReport as well as the MetricReport.

Afterwards, it sends a SetValue request to the BICEPS Set Service of the vital signs monitor in order

to change the current value “Old” to the requested value “New”. The SetString response contains the

first state of the execution of the remote invocation: “Queued”. After some time, the MDIB of the vital

signs monitor starts to process the remote invocation request and changes the value to the requested

one. It then sends two event reports via its BICEPS Event Report Service: an OperationInvokedReport

with the state set to “Finished” and an EpisodicMetricReport containing the new state of the

StringMetric.

32


2014-01-14

Figure 16 Exemplary remote invocation of a SetValue medical device service operation by a Smart

App on a vital signs monitor.

6.4.5 PHI Service

The optional Protected Health Information (PHI) Service possesses a service interface that allows

retrieval and modification of data about the patient. The patient data is a special type of contextual

data and is encapsulated in this special service as it may be required to be protected specially w.r.t.

security for example due to regulatory requirements like HIPAA.

6.4.6 Device-specific Services

If a medical device service needs to offer data or remotely invocable operations that are not defined in

the BICEPS-MIM resp. BICEPS Services specification, it is possible to describe the medical device

service operations in the description part of the MDIB. The descriptor allows defining the type of the

operation and the interface name where the operation is included. Additional information may be

added using the extensibility mechanisms defined in the descriptor.

6.5 Quality of Service

BICEPS does not define any QoS requirements on its own as all QoS requirements are related to the

transport communication protocol. Hence, the BICEPS-MIM rather defines extensibility points in the

descriptors that allow embedding of QoS requirements for a transport communication protocol.

6.6 Relationship to MDPWS

BICEPS does not define any specific transport communication protocol, but has some requirements

that need to be fulfilled in order to for a transport communication protocol to be suitable for a BICEPS

middleware implementation.

A suitable transport communication protocol for BICEPS is MDPWS. It fulfills the requirements of

BICEPS discovery and supports the required request-response message pattern for remote invocation

as well as notification message exchange pattern for transmission of event reports. Moreover,

MDPWS defines QoS policies that can be added to medical devices service operations if needed.

These QoS policies comprise safety, security, and message representation.

33


2014-01-14

An exemplary utilization of MDPWS to implement a BICEPS compliant middleware is shown in Figure

17.

Figure 17 Exemplary utilization of MDPWS to implement a BICEPS compliant middleware.

34


2014-01-14

7 Alternative Technologies

The Data Distribution Service for Real-Time Systems (DDS) [24] is the Object Management Group

(OMG) standard for distributed systems that utilize an architecture that relies on the indirect

communication paradigm that is based on a data-centric publish-subscribe (DCPS) model. The DDS

specification defines an application programming interface (API) for communication in those types of

systems.

DCPS facilitates decoupling of senders from receivers and thus supports extensibility of the distributed

system. In DDS, a sender becomes a publisher that publishes its contribution to the so-called “global

data space” while a receiver subscribes to that data. The underlying DDS middleware propagates all

necessary data to all relevant subscribers.

The published data is written to so-called “topics”. A topic consists of a name and a defined data type.

For the data type representation, the Interface Description Language (IDL) from the CORBA standard

is used. For a specific topic a publisher has a data writer. With its help the publisher “writes” data to

the global data space. On the subscriber side a data reader is required for each topic that should be

received. The data reader is able to “take” data from the global data space.

Additionally, DDS supports several QoS features which can be associated with topics for data writers

and data readers. The DDS middleware takes care that these QoS features are met. That means for

publishers that they can just “fire and forget” the data. If the reliability QoS feature is set to reliable, the

middleware retransmits the data if necessary. This is only the case if the data writer supports reliable

transmission and a data reader requires it. Otherwise it will be best-effort, for example when the data

writer supports reliable transmission, but the data reader just needs best-effort transmission. Other

QoS features are history and partition. The history QoS feature controls how many “old” samples

should be kept in the global data space. This QoS feature may be useful in case a data reader has not

taken the samples fast enough out of the global data space. If the history QoS feature is set to “keep

last only”, the global data space would discard all older samples even if the data reader has not taken

all of them. With the partition QoS feature it is possible to logically separate data readers and data

writers additionally to a separation on the underlying network layer into different domains. Data

readers can read only the data that is written to their associated topic in their logical partition within

their network domain.

As DDS specifies just an API and not a communication protocol, different DDS middlewares may be

incompatible with each other. To address this issue the Real-Time Publish Subscribe (RTPS)

protocol [25] has been specified as an extension for DDS. RTPS defines platform independent

modules for structure, a discovery mechanism, and the behavior of participants. Moreover, one

platform dependent module is specified that maps the modules to transport communication protocol

based on UDP messages.

As mentioned before, DDS has been designed to support statically defined data models for the global

data space. This allows an implementation to assume that the data types used by DDS topics are

known at compile time and that every participant of the DDS global data space agrees precisely on

the same data type for a topic. This facilitates features such as static type checking and efficient, low-

overhead, implementations of DDS in a compliant middleware. Nevertheless, it also suffers a few

drawbacks as stated in [26]:

It is hard to cope with data models evolving over time unless all the elements of the

system affected by that change are upgraded consistently. For example, the addition

or removal of a field in the data type it is not possible unless all the components in the

system that use that data type are upgraded with the new type.

35


2014-01-14

Applications using a data type must know the details of the data type at compile time,

preventing use cases that would require dynamic discovery of the data types and their

manipulation without compile-time knowledge. For example, a data-visualization tool

cannot discover dynamically the type of a particular topic and extract the data for

presentation in an interface.

To address these drawbacks, the DDS-XTypes [26] specification has been developed that defines a

mechanism, which supports evolving data types without requiring all components using that type to be

upgraded simultaneously. Moreover it specifies an API that facilitates dynamic discovery of the data

types and their manipulation without compile-time knowledge.

7.1.1 Benefits of DDS

If DDS is evaluated regarding the requirements of a communication protocol for a distributed system of

medical devices, there are a lot of benefits. DDS is a non-proprietary specification that has proven to

allow the implementation of highly scalable distributed systems requiring extensive support for defining

QoS requirements.

The broad range of supported QoS policies especially regarding real-time data distribution is very

good and could also be useful for applications of the medical device domain, where data needs to be

distributed inside a distributed system. An example of such a QoS policy is RELIABILITY as a

participant can choose which mode it needs for a specific topic. Moreover, the discovery module

facilitates Plug & Play in a distributed system of medical devices. Furthermore, the DDS-XTypes

specification supports extensibility and RTPS make it possible to implement a distributed system using

different implementation of DDS middleware within one distributed system of medical devices so that a

vendor lock-in on the transport communication protocol level could be avoided.

7.1.2 Weaknesses of DDS

Even though DDS fulfills a lot of the requirements for a communication protocol for a distributed

system of medical devices, there are also major gaps that cannot easily be implemented when using

DDS as foundation for such a communication protocol.

First, in order to fulfill the requirement for openness, not the DDS specification itself is relevant, but

rather only the RTPS specification can be consulted. DDS defines only an API and not the wire-

protocol. If one would use DDS as foundation for a communication protocol for a distributed system of

medical devices that would require that all medical device services need to be implemented with the

product(s) of one vendor. Even though the standardized API would allow changing the vendor, this

would require a change of all implementations on all medical device services. Hence, only the RTPS

specification is suitable to fulfill the requirement of Openness. For this reason, hereinafter only the

RTPS specifications as well as other wire-protocol specifications like DDS-XTypes are evaluated.

Second, a major drawback of RTPS is that there is no transport security defined for the UDP/IP

communication protocol. RTPS also restricts the set of available QoS policies defined by DDS. One

reason is that some QoS policies are not transport-related, but define the behavior of the participant in

the network. Example for this kind of QoS policies are DEADLINE, HISTORY or RESOURCE_LIMITS.

A QoS Policy that is transport-related but that is not fully supported by RTPS is DURABILITY in the

transient or persistent mode.

Third, remote control of a participant in a distributed system of medical devices needs to be modeled

on top of the data distribution centric middleware as RTPS only support the indirect communication

paradigm. This needs to be considered especially w.r.t to risk management and trust establishment

between a medical device and participant that needs to control that medical device. Moreover, if dual

channel or other safety aspects are required those have to be modeled into the topic-based data

36


2014-01-14

model of DDS. This means that transport specific safety aspects will be intermingled with the domain

model that is needed for medical device interoperability.

37


2014-01-14

8 Bibliography

[1] Coulouris, Dollimore, Kindberg and Blair, Distributed Systems: Concepts and Design, Addison-

Wesley, 2011.

[2] IEEE, IEEE Standard Computer Dictionary, IEEE, 1991.

[3] ASTM, Medical Devices and Medical Systems — Essential safety requirements for equipment

comprising the patient-centric integrated clinical environment (ICE) — Part 1: General

requirements and conceptual model, 2009.

[4] VDE, Risikomanagement für IT-Netzwerke mit Medizinprodukten im Operationssaal - Anwendung

des Entwurfs, VDE, 2010.

[5] ISO/IEEE, Health informatics -- Point-of-care medical device communication, ISO/IEEE, 2004.

[6] OR.NET, “OR.NET,” [Online]. Available: http://mis.klinikum.uni-heidelberg.de/wp_ornet/?lang=en.

[Accessed 12 12 2013].

[7] OASIS, “Reference Model for Service Oriented Architecture 1.0,” 12 Oct 2006. [Online]. Available:

http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.html. [Accessed 12 12 2013].

[8] d. Deugd, Carroll, Kelly, Milett and Ricker, “SODA: Service Oriented Device Architecture,” IEEE

Pervasive Computing, pp. 94-96, July 2006.

[9] OASIS, “Devices Profile for Web Services Version 1.1,” 2009. [Online]. Available:

http://docs.oasis-open.org/ws-dd/dpws/wsdd-dpws-1.1-spec.html.

[10] OASIS, “Web Services Dynamic Discovery (WS-Discovery) Version 1.1,” 1 July 2009. [Online].

Available: http://docs.oasis-open.org/ws-dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.html.

[Accessed 12 12 2013].

[11] W3C, “Web Services Metadata Exchange 1.1 (WS-MetadataExchange),” 13 Aug 2008. [Online].

Available: http://www.w3.org/Submission/WS-MetadataExchange/. [Accessed 12 12 2013].

[12] W3C, “Web Services Description Language (WSDL) 1.1,” March 2001. [Online]. Available:

http://www.w3.org/TR/wsdl. [Accessed 12 12 2013].

[13] W3C, “Web Services Policy 1.5 - Framework,” 04 Sept 2007. [Online]. Available:

http://www.w3.org/TR/ws-policy/. [Accessed 12 12 2013].

[14] W3C, “Web Services Policy 1.5 - Attachment,” 04 Sept 2007. [Online]. Available:

http://www.w3.org/TR/ws-policy-attach/. [Accessed 12 12 2013].

[15] W3C, “Web Services Eventing (WS-Eventing),” 15 March 2006. [Online]. Available:

http://www.w3.org/Submission/2006/SUBM-WS-Eventing-20060315/. [Accessed 12 12 2013].

[16] OASIS, “SOAP-over-UDP Version 1.1,” 1 July 2009. [Online]. Available: http://docs.oasis-

open.org/ws-dd/soapoverudp/1.1/os/wsdd-soapoverudp-1.1-spec-os.html. [Accessed 12 12

2013].

[17] Pöhlsen, Schöch and Schlichting, “ A Protocol for Dual Channel Transmission in Service-Oriented

38


2014-01-14

Medical Device Architectures based on Web Services,” in Proceedings of HCMDSS, 2011.

[18] IEC, Application of risk management for IT-networks incorporating medical devices -- Part 1:

Roles, responsibilities and activities, IEC, 2001.

[19] W3C, “SOAP Message Transmission Optimization Mechanism,” 25 Jan 2005. [Online]. Available:

http://www.w3.org/TR/soap12-mtom/. [Accessed 12 12 2013].

[20] Moritz, Zeeb, Prüter, Golatowski, Timmermann and Stoll, “Devices Profile for Web Services and

the REST,” in 8th IEEE International Conference on Industrial Informatics (INDIN), 2010.

[21] ISO/IEC, 24824-1 - Information technology -- Generic applications of ASN.1: Fast infoset,

ISO/IEC, 2007.

[22] W3C, “Efficient XML Interchange (EXI) Format 1.0,” 10 March 2011. [Online]. Available:

http://www.w3.org/TR/exi/. [Accessed 12 12 2013].

[23] Moritz, Timmermann, Stoll and Golatowski, “Encoding and Compression for the Devices Profile

for Web Services,” in IEEE 24th International Conference on Advanced Information Networking

and Applications Workshops, 2010.

[24] OMG, “Data Distribution Service for Real-time Systems Version 1.2,” Jan. 2007. [Online].

Available: http://www.omg.org/cgi-bin/doc?formal/07-01-01. [Accessed 12 12 2013].

[25] OMG, “The Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol

Specification,” 2009. [Online]. Available: http://www.omg.org/spec/DDSI/2.1.

[26] OMG, “Extensible and Dynamic Topic Types for DDS Version 1.0,” 2012. [Online]. Available:

http://www.omg.org/spec/DDS-XTypes/1.0/. [Accessed 12 12 2013].

[27] Lesh, Weininger and Goldmann, “Medical Device Interoperability – Assessing the Environment,”

in HCMDSS-MDPnP, Joint Workshop on High Confidence Medical Devices, Software, and

Systems and Medical Device Plug-and-Play Interoperability, 2007.

[28] OASIS, “OASIS standards,” [Online]. Available: https://www.oasis-open.org/standards. [Accessed

12 12 2013].

39


2014-01-14

9 Appendix

9.1 DPWS Specifications

Specifications that are not described in detail in this document, but that are utilized in DPWS, are:

- IPv4/ IPv6, IP Multicast; UDP; TCP; HTTP: Network protocols on the levels 3-7 of the

ISO/OSI model. IP addresses can be assigned statically or dynamically. For dynamic

assignment DHCP resp. autoconfiguration could be used. Furthermore, dynamic assigment is

recommended in order to achieve plug & play experience.

- XML Schema: Offers facilities for describing the structure and constraining the contents of

XML 1.0 documents, including those which exploit the XML namespace facility. The schema

language is itself represented in XML 1.0 and uses namespaces.

- SOAP: SOAP is an extensible protocol intended for exchanging structured information in a

decentralized, distributed environment. It uses XML technologies in order to provide a

message construct that can be exchanged over a variety of underlying protocols. It has been

designed to be independent of any particular programming model and other implementation

specific semantics. SOAP exists in two versions: SOAP 1.1 and SOAP 1.2. It is

recommended to use SOAP 1.2 only.

- WS-Addressing: Provides transport-neutral mechanisms to address Web Services and

messages by introducing the concept of an endpoint reference (EPR) as well as message

information headers. WS-Addressing is necessary to overcome the lack of SOAP

independence of underlying transport protocols as well as to support asynchronous message

exchange.

- WS-Transfer: Describes a general SOAP-based protocol for accessing predefined XML

representation of Web Service-based resources by defining Create, Get, Put and Delete

service operations which have almost the same semantics as HTTP requests. In DPWS, WS-

Transfer Get is used, to retrieve an XML representation of the device-wide metadata in the

WS-MetadataExchange Metadata representation.

- WS-MetadataExchange: Defines how metadata associated with a Web Service endpoint can

be represented as WS-Transfer resources for retrieval purposes. Moreover, WS-

MetadataExchange defines a service operation to retrieve all or specific parts of the metadata

of an endpoint where the XML representation is not known beforehand. DPWS utilizes WS-

MetadataExchange GetMetadata to retrieve the metadata of a hosted service.

an architecture for distributed systems of medical devices ......an architecture for distributed...

Documents