An architecture for distributed systems of medical devices in high acuity environments. - A Proposal for Standards Adoption -

An architecture for distributed systems of medical devices in high acuity environments - A Proposal for Standards Adoption - Stefan Schlichting, stefan.schlichting@drager.com Drägerwerk AG & Co. KGaA Moislinger Allee 53 55 23558 Lübeck, Germany Authors: Stephan Pöhlsen, Dräger Medical GmbH Moislinger Allee 53 55 23558 Lübeck, Germany 1

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 2

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 3

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

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-ofcare 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. Interoperability 1 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. 5

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 ITnetworks 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 Plug & Play Discovery & Binding Device capability description at runtime Openness Communication (1-1, 1-n, n-m) Event Notification Non-Functional Risk Management Safe communication Access control Trust Establishment between participants Privacy of patient-related data 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. 6

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, futureproof 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 socalled 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. 7

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

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 registry 4. 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. 9

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 system 5, 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. 10

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

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

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 devicewide 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 13

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

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

- 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 Language 6 (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.1 7, 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 domainspecific 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. 17

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 18

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-Streaming 8 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. 19

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 failure 9 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 validation 10. 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. 20

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

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

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 mechanisms 11 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. 23

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

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 ACSE 12 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 objects 13. 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. 25

In x73 it is specified that managed medical objects are accessible only through services provided by the CMDISE 14. 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 26

Packages in scope of BICEPS-MIM Medical Alert Control Packages out-of-scope of BICEPS-MIM Archival Extended Services 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. 27

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 metainformation that describes this content and allows interpretation. Content data can be 28

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

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

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

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

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

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, lowoverhead, 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. 34

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 wireprotocol. 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 35

model of DDS. This means that transport specific safety aspects will be intermingled with the domain model that is needed for medical device interoperability. 36

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.oasisopen.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 37

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]. 38

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