THE NATURE OF MEDICAL DEVICE SERVICES

A Multiple-case Study

Christian Mauro, Helmut Krcmar

Information Systems, Technische Universität München, Boltzmannstr. 3, 85748 Garching, Germany

Jan Marco Leimeister

Information Systems, Universität Kassel, Nora-Platiel-Str. 4, 34127 Kassel, Germany

Keywords: Service Oriented Device Architecture, SODA, Service Oriented Architecture, SOA, Medical Devices.

Abstract: The integration of medical devices into the IT infrastructure of hospitals is still a major challenge. Recent

research tries to adapt service oriented concepts to the field of medical devices in order to achieve an easier

and better integration. However, no generalized framework for this kind of integration exists. The purpose

of this paper is to identify the characteristics (the nature) of medical device services. The results were

achieved by conducting a multiple-case study with three cases on two university hospitals. As a result, we

identified twelve specific integration issues of medical devices and deduced eight characteristics. This paper

contributes to the design of a generalized framework for the service oriented integration of medical devices.

The identified characteristics can be interpreted as requirements to such a framework.

1 INTRODUCTION

The integration of medical devices into the IT

infrastructure of hospitals is still an open issue

(Lesh, Weininger, Goldman, Wilson, & Himes,

2007). There is a huge gap between reality and the

vision of seamless healthcare with horizontally and

vertically integrated healthcare processes enabled by

seamless IT support (Schweiger, A., Sunyaev, A.,

Leimeister, J. M., & Krcmar, H., 2007). In order to

bridge this gap several research projects are

exploring the concept of service oriented device

integration. The idea of this concept is the

encapsulation of devices as services, analogous to

enterprise services in service oriented architectures

(SOA) (de Deugd, Carroll, Kelly, Millett, & Ricker,

2006).

As we showed with a literature analysis, some first

prototypical implementations achieved promising

results (Mauro, C., Sunyaev, A., Leimeister, J. M.,

& Krcmar, H., 2009). However, we also revealed

that there is a lack of generalized concepts. In

particular, a general framework for the service

oriented integration of medical devices is missing.

Following a design science approach (according

to Hevner, March, Park, and Ram (2004)), the aim

of our research is to design, implement and evaluate

such a framework. This paper presents an important

step of this research, the exploration of the

characteristics (the nature) of medical device

services. This list of characteristics can be

interpreted as requirements to the integration

framework.

2 SERVICE ORIENTED

INTEGRATION OF LEGACY

SYSTEMS AND DEVICES

From an integration point of view, legacy systems

and medical devices have some common

characteristics (cf. Bennett (1995, p. 19), Bisbal,

Lawless, Bing, & Grimson (1999, p. 103), and Lesh,

et al. (2007)):

 Slow hardware doesn’t allow the use of

modern software communication frameworks.

 A lack of clean interfaces complicates the

integration with other systems.

 A difficult (or impossible) expandability

doesn’t allow modifications of insufficient

interfaces.

250

Mauro C., Krcmar H. and Leimeister J..

THE NATURE OF MEDICAL DEVICE SERVICES - A Multiple-case Study.

DOI: 10.5220/0003172002500255

In Proceedings of the International Conference on Biomedical Electronics and Devices (BIODEVICES-2011), pages 250-255

ISBN: 978-989-8425-37-9

 2011 SCITEPRESS (Science and Technology Publications, Lda.)

Figure 1: Service oriented integration of devices (according to Mauro et al. (2010)).

To overcome the integration issues of legacy

systems a lot of publications and products are

successfully using service oriented concepts (e.g.,

Siebenhaar, Lehrig, Braun, and Görge (2008)). In

recent research, these concepts are adapted to

devices (SODA, Service Oriented Device

Architecture, cf. de Deugd et al. (2006)). Figure 1

shows a conceptual perspective view of the service

oriented integration of devices. Following the

contract-first principle (Erl, 2009), the starting point

is the definition of the service contract followed by

its implementation. An adapter component is

necessary to handle the connection to the proprietary

device interface. The strength of the concept is the

loose coupling of service consumers to medical

devices (Mauro, C., Leimeister, J. M., & Krcmar,

H., 2010). In this paper we use the term “medical

device services” for services that encapsulate

medical devices.

From a static point of view, the concept of the

service oriented integration of legacy systems can

directly be applied to medical devices. However,

from a dynamic point of view we expect additional

integration issues due to the characteristics of

medical devices (e.g., mobility) and therefore of

medical device services. With the following

multiple-case study we try to identify the

characteristics (the “nature”) of medical device

services.

3 CASE STUDY DESIGN

The multiple-case study is composed of three single

cases conducted at two university hospitals (Figure

2). The cases were selected because of their different

disciplines and our access to the field.

We use case studies for the exploration of the nature

of medical device services due to the fact that

different aspects (e.g., processes or the type of data

provided by the devices) have to be considered. The

handling of different kind of sources (observations,

documents, interviews, etc.), as necessary for such

an exploration, is a considerable strength of case

studies (Yin, 2009, p. 11).

Figure 2: Multiple-case study with three cases.

Following Yin (2009, p. 27), the design of a case

study consists of several elements. Table 1 shows

these elements and how they are implemented in our

case study. The strategy used for interpreting the

data is implicit contained in the explanations of

section 4.

Following the process proposed by Yin (2009, p.

57) we write an individual report for each case and

present our cross-case conclusions in another

section.

Table 1: Case study design.

Purpose

Exploring the reasons for the complexity of the

integration of medical devices in order to draw

conclusions regarding the nature of medical device

services

Research Questions (RQ)

RQ1: How many systems might use the data provided

by medical devices?

RQ2: Which processes complicate the integration of

medical devices?

RQ3: Which legal restrictions complicate the

integration of medical devices?

RQ4: What kind of capabilities and data is provided by

the interfaces of medical devices?

RQ5: How are the grade of standardization and the

complexity of the interfaces of medical devices?

Units of analysis

All electronic medical devices of the respective

institution

Multiple-Case

Study

Intensive Care Unit 2

of the Neuro Head

Center

University Hospital I University Hospital II

Ophthalmic

Clinic

Case Study 1

Case Study 2

Neurological

Clinic

Case Study 3

THE NATURE OF MEDICAL DEVICE SERVICES - A Multiple-case Study

251

Table 1: Case study design. (cont.)

Collected data and their link to the research questions

RQ1,

RQ2

Processes using medical devices or data

provided by medical devices

(Source: Observation, interviews)

RQ3 Regulatory

Framework

(Source: literature)

Intended use of the

device interfaces

(Source: specificati-

ons and manuals)

RQ4 Kind of hardware

interfaces

(Source: on-site

analysis and

specifications

Complexity of

software interfaces

(Source: Protocol

specifications)

Kind of data

provided by

software interfaces

(Source: Protocol

specifications)

Capabilities of

software interfaces

(Source: Protocol

specifications)

Grade of standardization of the software

interfaces

(Source: Protocol specifications)

4 CASE STUDY RESULTS

4.1 Case Study 1 – Intensive Care Unit

4.1.1 Medical Devices and their Interfaces

At the Intensive Care Unit 2 (ICU2) the number of

different devices is small. Basically, an intensive

care bed is equipped with four types of devices:

Infusion pumps (B. Braun Infusomat® Space),

Syringe pumps (B. Braun Perfusor® Space),

Respirator (Dräger Evita XL or Evita 4), and Patient

monitor (GE Datex-Ohmeda).

B. Braun infusion and syringe pumps are inserted

into a rack, the B. Braun SpaceStation. An optional

module – the B. Braun SpaceCom – acts as a single

access point for all pumps of a bed. This module has

a number of standard hardware interfaces: Wireless

LAN, Ethernet RJ45, PS/2 for barcode scanner, RS-

232 serial, and USB master/slave. Over these

hardware interfaces three software interfaces are

provided: a) A web server to configure the system

and to access infusion data over a web browser, b)

the medium complex proprietary BCC protocol,

which can be used to access infusion data, and c) the

simple XML based proprietary proposal data

protocol, which can be used to send up to 24

medications to the pumps.

The Dräger Evita XL and Evita 4 respirators

provide a serial RS-232 hardware interface for data

export. The software interface is the proprietary and

very complex Dräger MEDIBUS protocol. It

supports a real time mode, which can be activated by

using specific commands in order to support a

continuous fast data flow.

Unfortunately, we didn’t get access to the GE

Datex-Ohmeda interface specification so far. Instead

of that we analyzed the specification of a

comparable patient monitor, the Dräger Infinity®

Delta. This monitor provides two protocols: a) The

medium complex proprietary RS-232 Export

Protocol (via serial interface), which can be used to

export several vital signs and alarms, and b) the

medium complex proprietary Infinity® protocol (via

LAN or wireless LAN), which provides monitoring

data over network.

4.1.2 Legal Restrictions

In Europe the Medical Device Directive is the most

important legal basis. From an integration point of

view, the two most important aspects are the

upcoming norm IEC 80001, which defines

regulations for the interconnection of medical

devices, as well as the intended use of the device

interface specified by the manufacturer (Mauro, C.,

Sunyaev, A., Dünnebeil, S., Leimeister, J. M., &

Krcmar, H., 2009). If the interface of a device is

used in a way that is not intended by the

manufacturer, the user (i.e., the hospital) is

responsible for all resultant damages to the patient or

other persons.

The intended use of all analyzed devices does not

include the use of the provided data for diagnostic or

therapeutic decisions. In addition, the SpaceCom

specification prohibits a monitoring of alarms only

on the basis of the data provided by the interface.

These restrictions must be taken into consideration

when connecting the devices to other systems.

4.1.3 Process Analysis

By observing the processes at the ICU2 we

identified a number of (future) systems that could

use the data provided by the medical devices:

documentation systems (vital signs, care

documentation, medication documentation, etc.),

therapy planning systems, clinical trial systems,

score calculation system (for the purpose of

accounting a score value is calculated for each

patient), IT supported ward rounds, and the medical

technology database. We also identified a number of

aspects that further complicate the integration of

medical devices:

 Linking medical data to patients: Data provided

by medical devices must be correctly linked to a

BIODEVICES 2011 - International Conference on Biomedical Electronics and Devices

252

patient. Linking data to the wrong patient could

result in misinterpretations.

 Mobility of medical devices: Some devices are

mobile in order to provide continuous care to the

patient. As a consequence, devices may not be

connected to the network at all times.

 Replacement of medical devices: If a device is

defective (or needs to be maintained) it may

dynamically be replaced by another one (other

model, other manufacturer, etc.).

 Operation mode of medical devices: Devices can

be switched on/off at any time, e.g., if a

medication is stopped, the corresponding

infusion pump may be switched off.

4.1.4 Conclusion

We conclude each case study with a reflection of the

case study’s research questions:

RQ1: Several systems (we identified six useful

integration scenarios) may be interested in the data

provided by medical devices (cf. section 4.1.3).

RQ2: The linking of medical data to patients as well

as the mobility and replacement of devices are

critical aspects. Another challenge is the fact that

medical devices may be switched on/off at any time

(cf. section 4.1.3). RQ3: The upcoming norm IEC

80001 must be taken into consideration. In addition,

the data provided by the analyzed medical devices

must not be used for diagnostic or therapeutic

decisions. In addition, the monitoring of alarms only

on the basis of the data provided by the device

interfaces is not allowed (cf. section 4.1.2). RQ4:

The devices provide current vital signs and

information about the current therapy by request or

as continuous data flow. In addition, medications

can be sent to the B. Braun pumps (cf. section 4.1.1).

RQ5: The devices provide standardized hardware

interfaces. However, all software interfaces are

proprietary. The complexity of the protocols ranges

from simple to very complex (cf. section 4.1.1).

4.2 Case Study 2 – Ophthalmic Clinic

4.2.1 Medical Devices and their Interfaces

In this clinic we found 42 different (total number:

49) medical devices of 25 manufactures. Due to the

great number of different devices we will not

explain each device type in detail but summarize the

most important results. Our analysis showed that the

devices are of two kinds: a) Devices with no IT

interface or with printer only (13), and b) devices

that need special software (running on a internal or

external computer) with a graphical user interface in

order to analyze raw data and generate findings (29).

From an integration point of view, devices of the

first category are quite unfavorable. There might be

the possibility for some devices to redirect the

printout into a file. However, e.g., for integrated

thermal printer this is not possible at all. Devices of

the second category cannot be directly integrated

with other systems. Instead of that the corresponding

software has to be integrated. Our analysis showed

that about 50% of these software systems are

supporting standards like DICOM (Digital Imaging

and Communications in Medicine), GDT

(Gerätedatentransfer, a common German standard)

or HL7 (Health Level 7). The other half is providing

proprietary interfaces and data formats.

Due to the specific discipline of the clinic the

majority of the medical devices are producing image

data. Therefore, the size of a dataset of one medical

examination can be up to 200 megabyte.

4.2.2 Legal Restrictions

We couldn’t found any specific legal restrictions in

the documents of the software systems. However,

being software for the purpose of diagnostic the

software itself might be (in future versions of the

software: must be) a class IIa medical device due to

the legal regulations (Mauro et al., 2009). Thus, the

IEC 80001 must be taken into consideration when

integrating such software systems (cf. section 4.1.2).

4.2.3 Process Analysis

The number of systems that may be interested in the

data produced by the medical devices is very

limited. In general, the generated findings are

printed out and put into a paper-based medical

record. Thus, after integrating the devices, the

findings could directly be imported to an electronic

medical record. Another system to be integrated may

be the medical technology database (cf. section

4.1.3). Again, we identified a number of aspects that

may complicate the integration of the devices:

 Linking medical data to patients: The linking of

the data is not as difficult as in case study 1.

Administrative patient data (as name, gender,

birthday, etc.) can be entered into the software.

However, this manual step is error-prone, patient

data may be entered incorrect.

 Operation mode of medical devices: This aspect

is not as critical as in case study 1 because the

software systems do not expect any requests.

They may receive administrative patient data

from the hospital information system, but such

THE NATURE OF MEDICAL DEVICE SERVICES - A Multiple-case Study

253

transfers are initiated by the user itself.

The mobility of medical devices is not relevant

in case study 2. Only three of the analyzed devices

are used mobile. None of these devices has an IT

interface, findings can only be printed. Also the

replacement of a device could not be observed in

this case study.

4.2.4 Conclusion

RQ1: Only a small number of systems (we identified

two useful integration scenarios) may be interested

in the data provided by medical devices (cf. section

4.2.3). RQ2: The administrative patient data should

be imported from hospital information system to

avoid manual mistakes. The fact that medical

devices may be switched on/off at any time should

be kept in mind (cf. section 4.2.3). RQ3: Medical

software may be a medical device in the sense of the

Medical Device Directive. In this case, the norm

IEC 80001 has to be taken into consideration (cf.

4.2.2). RQ4: 31% of the analyzed device types do

not provide an IT interface. The remaining 69%

need special software in order to provide findings of

an examination. This includes a textual report as

well as different kind of data, e.g., numeric values or

images up to 200 MB (cf. 4.2.1). RQ5: The software

interfaces are about 50% standardized and 50%

proprietary. The complexity of the protocols ranges

from simple to very complex (cf. 4.2.1).

4.3 Case Study 3 – Neurological Clinic

4.3.1 Medical Devices and their Interfaces

In this clinic we found 26 different (total number:

38) medical devices of 17 manufactures. The results

are very similar to case study 2. To avoid redundant

explanations we will refer to case study 2 at some

places.

Our analysis showed that all devices (except one

device that only has printing capabilities) need

special software (running on an internal or external

computer) with a graphical user interface in order to

analyze raw data and generate findings. Thus, as in

case study 2, the devices cannot be directly

integrated with other systems. Instead of that the

corresponding software has to be integrated.

Again, about 50% of these software systems are

supporting established standards. We also identified

again a number of systems that produce a great

amount of data (up to 400 megabyte when saving

electrocardiogram video sequences).

4.3.2 Legal Restrictions

Regarding legal restrictions our findings of case

study 3 match with the findings of case study 2.

4.3.3 Process Analysis

Regarding the process analysis our findings of case

study 3 match with the findings of case study 2. The

only difference is that the mobility of the medical

device is an important aspect. 15 of the analyzed

medical devices are used mobile and therefore may

be offline or appear in different network segments.

4.3.4 Conclusion

The results of case study 3 are very similar to the

results of case study 2. Thus, we only list the

differences: a) In addition to images also video data

up to 400 MB are provided, b) only one of the

analyzed device types does not provide an IT

interface. All remaining devices need special

software in order to provide findings of an

examination, and c) 58% of the analyzed devices are

used mobile.

4.3 Cross-Case Conclusions

In this section we provide cross-case conclusions in

the form of a consolidated list of reasons for the

complexity of the integration of medical devices.

We compare these reasons with the integration

issues of legacy systems (Table 2).

Table 2: Integration obstacles of medical devices.

Nr. Reason Description LS

Several systems may have to be integrated

with the medical device.

Data provided by medical devices must be

correctly linked to a patient.

Medical devices may be mobile and

therefore are not connected to the network

at all times.

Medical devices (and with it the device’s

hardware and software interfaces) may

dynamically be replaced by another one.

Medical devices can be switched on/off at

any time.

Due to legal restrictions the interface of a

medical device cannot be changed.

A risk management (IEC 80001) must be

conducted when connecting medical

devices with other systems.

The interface of a medical device is only

allowed to be used as intended by the

manufacturer.

BIODEVICES 2011 - International Conference on Biomedical Electronics and Devices

254

Table 2: Integration obstacles of medical devices.(Cont.)

Medical devices may provide streaming

data.

Medical devices may provide huge image

or video files.

Medical devices often provide proprietary

and complex interfaces.

Medical devices do not provide modern

communication frameworks.

Nr.= Reason Number, LS = Legacy System,

X = Analogous also valid for legacy systems

5 DEDUCING THE NATURE OF

MEDICAL DEVICE SERVICES

Based on the identified reasons presented in the

previous section we deduced the characteristics of

medical device services. The following list presents

the characteristics as well as the references to the

reasons they were deduced from. Medical device

services

 correctly link their medical data to patients

(Reason 2),

 dynamically appear and disappear at the network

(Reasons 3, 4, and 5),

 automatically publish themselves (as a

consequence of Reasons 3, 4 and 5),

 dynamically communicate with different

hardware interfaces and complex low-level

device interfaces (Reasons 4, 6, 11, and 12),

 have passed a IEC 80001 risk management

process (Reason 7),

 respect the intended use of the device interfaces

(Reason 8),

 may provide streaming data (Reason 9), and

 may provide huge amount of data (Reason 10).

Reason 1 doesn’t result in an item of this list.

Services are intended to be used by several other

systems so this aspect is not a characteristic of

medical device services.

6 CONCLUSIONS AND FUTURE

RESEARCH

In this paper we presented the nature of medical

device services in the form of a list of eight

characteristics. The results were deduced by

conducting a multiple-case study comprised of three

cases at two university hospitals. This list of

characteristics can be considered as a list of

requirements to a service oriented integration

framework for medical devices. Such a concept must

support / realize all items of the list. Thus, our next

step will be designing a service oriented integration

framework for medical devices based on existing

SOA design patterns / SOA best practices. Finally,

we will implement and evaluate the created

framework.

REFERENCES

Bennett, K. (1995). Legacy Systems: Coping with

Success. IEEE Software, 12(1), 19-23.

Bisbal, J., Lawless, D., Bing, W., & Grimson, J. (1999).

Legacy information systems: issues and directions.

IEEE Software, 16(5), 103-111.

de Deugd, S., Carroll, R., Kelly, K. E., Millett, B., &

Ricker, J. (2006). SODA: Service Oriented Device

Architecture. Pervasive Computing, IEEE, 5(3), 94-96.

Erl, T. (2009). SOA Design Patterns. Boston: Prentice

Hall International.

Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004).

Design Science in Information Systems Research. MIS

Quarterly, 28(1), 75-105.

Lesh, K., Weininger, S., Goldman, J. M., Wilson, B., &

Himes, G. (2007). Medical Device Interoperability –

Assessing the Environment. Paper presented at the

Joint Workshop on High Confidence Medical Devices,

Software, and Systems and Medical Device Plug-and-

Play Interoperability.

Mauro, C., Leimeister, J. M., & Krcmar, H. (2010).

Serviceorientierte Integration medizinischer Geräte –

ganzheitliche IT-Unterstützung klinischer Prozesse.

Informatik-Spektrum, Online First.

Mauro, C., Sunyaev, A., Leimeister, J. M., & Krcmar, H.

(2009). Service-orientierte Integration medizinischer

Geräte - eine State of the Art Analyse. Paper presented

at the Wirtschaftsinformatik 2009 - Business Services:

Konzepte, Technologien und Anwendungen.

Mauro, C., Sunyaev, A., Dünnebeil, S., Leimeister, J. M.,

& Krcmar, H. (2009). Mobile Anwendungen im

Kontext des Medizinproduktegesetzes. Paper

presented at the Informatik 2009 - Im Focus das

Leben.

Schweiger, A., Sunyaev, A., Leimeister, J. M., & Krcmar,

H. (2007). Toward Seamless Healthcare with Software

Agents. Communications of the Association for

Information Systems (CAIS), 19, 692-709.

Siebenhaar, M., Lehrig, T., Braun, J., & Görge, T. (2008).

Entwicklung einer SOA-basierten Webanwendung zur

Buchung und Verwaltung von Segeltouren:

Proprietäre Software vs. Open Source

Wirtschaftsinformatik, 50(4), 325-329.

Yin, R. K. (2009). Case study research: design and

methods (4 ed.). California: SAGE Publications.

THE NATURE OF MEDICAL DEVICE SERVICES - A Multiple-case Study

255