(PDF) Challenges and Research Directions in Medical Cyber–Physical Systems - DOKUMEN.TIPS (2024)

INV ITEDP A P E R

Challenges and ResearchDirections in MedicalCyber–Physical SystemsA broad overview of emerging applications for these systems is provided in

this paper; challenges, promising solutions, and open problems

are presented.

By Insup Lee, Fellow IEEE, Oleg Sokolsky, Member IEEE, Sanjian Chen, Student Member IEEE,

John Hatcliff, Eunkyoung Jee, Member IEEE, BaekGyu Kim,

Andrew King, Student Member IEEE, Margaret Mullen-Fortino, Soojin Park,

Alexander Roederer, and Krishna K. Venkatasubramanian, Member IEEE

ABSTRACT | Medical cyber–physical systems (MCPS) are life-

critical, context-aware, networked systems of medical devices.

These systems are increasingly used in hospitals to provide

high-quality continuous care for patients. The need to design

complex MCPS that are both safe and effective has presented

numerous challenges, including achieving high assurance in

system software, intoperability, context-aware intelligence,

autonomy, security and privacy, and device certifiability. In

this paper, we discuss these challenges in developing MCPS,

some of our work in addressing them, and several open

research issues.

KEYWORDS | Closed-loop physiological control; cyber–physical

systems (CPSs); design challenges; medical device systems;

model-based design

I . INTRODUCTION

The medical device industry is undergoing a rapid trans-

formation, embracing the potential of embedded softwareand network connectivity. Instead of standalone devices

that can be designed, certified, and used independently of

each other to treat patients, we will be faced in the near

future with distributed systems that simultaneously moni-

tor and control multiple aspects of the patient’s physiology.

The combination of embedded software controlling the

devices, networking capabilities, and complicated physical

dynamics exhibited by patient bodies makes modern me-dical device systems a distinct class of cyber–physical sys-

tems (CPSs). We refer to these as medical cyber–physical

systems (MCPSs).

MCPSs, due to their increased size and complexity

relative to traditional medical systems, present numerous

developmental challenges. The long-term viability of

MCPSs requires addressing these challenges through the

development of new design, composition, verification, andvalidation techniques. These present new opportunities for

researchers in MCPSs and in general embedded and CPSs.

For MCPS, we also believe new regulatory procedures to

approve their use for treating patients will be needed.

The traditional process-based regulatory regime used by

the U.S. Food and Drug Administration (FDA) to approve

medical devices is becoming too lengthy and prohibitively

expensive with the increased MCPS complexity, and wepresent possible solutions to ease this process.

In this paper, we describe some of the research di-

rections that we are taking toward addressing some of the

Manuscript received July 1, 2011; accepted August 10, 2011. Date of publication

October 18, 2011; date of current version December 21, 2011. This work was supported

in part by the National Science Foundation (NSF) under Grants CNS-0834524,

CNS-0930647, and CNS-1035715 and by the National Institutes of Health (NIH) under

Grant 1U01EB012470-01.

I. Lee, O. Sokolsky, S. Chen, B. Kim, A. King, A. Roederer, andK. K. Venkatasubramanian are with the Department of Computer and

Information Science, University of Pennsylvania, Philadelphia, PA 19104 USA

(e-mail: [emailprotected]; [emailprotected]; [emailprotected];

[emailprotected]; [emailprotected]; [emailprotected];

[emailprotected]).

J. Hatcliff is with the Computing and Information Sciences Department,

Kansas State University, Manhattan, KS 66502 USA (e-mail: [emailprotected]).

E. Jee is with the Computer Science Department, KAIST, Daejeon 305-701, Korea

(e-mail: [emailprotected]).

M. Mullen-Fortino and S. Park are with the Hospital of the University of Pennsylvania,

Philadelphia, PA 19104 USA (e-mail: [emailprotected];

[emailprotected]).

Digital Object Identifier: 10.1109/JPROC.2011.2165270

Vol. 100, No. 1, January 2012 | Proceedings of the IEEE 750018-9219/$26.00 �2011 IEEE

challenges involved in building MCPS. The ultimate goal isto develop foundations and techniques for building safe

and effective MCPS.

Overall, we advocate a systematic analysis and design

of MCPS for handling their inherent complexity. Conse-

quently, model-based design techniques should play a

larger role in MCPS design. Models should include devices

and the communications between them, but also, of equal

importance, the relationship of these devices to patientsand caregivers. The use of models will allow developers to

assess system properties early in the development process

and build confidence in the system design, before the

system is built. Analysis of system safety and effectiveness

performed at the modeling level needs to be complemen-

ted by generative implementation techniques that preserve

properties of the model in the implementation. Results of

model analysis, combined with the guarantees of thegeneration process, can form the basis for evidence-based

regulatory approval.

The paper is organized as follows. Section II provides a

conceptual view of MCPSs and their principal challenges.

Sections III–VII present our work in addressing some of

these challenges. Section VIII presents a short discussion

on some of the open research issues associated with MCPS

and Section IX concludes the paper.

II . AN OVERVIEW OF MCPS

MCPSs are safety-critical, interconnected, intelligent systemsof medical devices. Traditional clinical scenarios can be

viewed as closed-loop systems where caregivers are the

controllers, medical devices act as sensors and actuators,

and patients are the Bplants.[ MCPSs alter this view byintroducing additional computational entities that aid the

caregiver in controlling the Bplant.[ Fig. 1 shows the con-

ceptual overview of MCPSs. The devices used in MCPSs

can be categorized into two large groups based on their

primary functionality: monitoring devices, such as heart-

rate and oxygen-level monitors and sensors, which provide

information about the patient’s physiologic state; and

delivery devices, such as infusion pumps and ventilators,which actuate therapy capable of changing the patient’s

physiologic state. In MCPSs, the monitoring devices can

feed data collected to a decision support or administrative

support entities, each of which serves a different, albeit

complementary, purpose.

Administrative entities, such as electronic health re-

cords (EHRs) and pharmacy stores, manage patient health

and treatment information collected over a period of time.Given their access to a wealth of personalized information,

they have the potential to provide targeted actuation of

treatment based on a more holistic view of the patient’s

health (e.g., by considering potential drug interactions or

by taking into account the longitudinal evolution of a spe-

cific patient physiological parameter). In this regard, they

can assist in fulfilling the need for the continuous care of

the patient. Continuous data gathering and management isessential for many of today’s health issues such as dealing

with the aging population and the rapid rise in the number

of people with chronic conditions such as asthma and

diabetes.

Decision support entities can process the data collected

and generate alarms for many medical emergencies. Alarms

are necessary to allow clinicians to know when the patient’s

Fig. 1. Medical cyber–physical systems: Conceptual overview.

Lee et al.: Challenges and Research Directions in Medical Cyber–Physical Systems

76 Proceedings of the IEEE | Vol. 100, No. 1, January 2012

state has deteriorated and what information is relevant totreat them. However, it is now clear that we must develop

smart alarm systems that go beyond the current threshold

based methods to provide more accurate, targeted alarms,

along with context information about them. Caregivers can

analyze that information and can use delivery devices to

initiate treatment, thus bringing the caregiver into the

control loop around the patient. Alternatively, the decision

support entities can utilize a smart controller to analyze thedata received from the monitoring devices, estimate the

state of the patient’s health, and automatically initiate

treatment (e.g., drug infusion) by issuing commands to

delivery devices, thereby closing the loop.

MCPS Challenges. Building these sorts of MCPS re-

quires addressing several important challenges.

• High assurance software: Software plays an

increasingly important role in medical devices.Many functions traditionally implemented in

hardwareVincluding safety interlocksVare now

being implemented in software. Thus, high-

confidence software development is critical to as-

sure the safety and effectiveness of MCPS.

• Interoperability: As medical devices get communi-

cation interfaces, it is essential to ensure that the

integrated medical devices are safe, effective, se-cure, and can eventually be certified as such.

• Context awareness: Patient information exchanged

during device interoperation can not only provide

a better understanding of the general health of

the patient, but also enable early detection of

ailments and generation of effective alarms in the

event of emergencies. Given the complexity of the

human body and variations of physiological param-eters over patient population, developing such

computational intelligence is a nontrivial task.

• Autonomy: The computational intelligence that

MCPS possess can be used for increasing the auto-

nomy of the system by enabling actuation of thera-

pies based on the patient’s current health state.

Closing the loop in this manner must be done

safely and effectively.• Security and privacy: Medical data collected and

managed by MCPSs is very critical. Unauthorized

access or tampering with this information can have

severe consequences to the patient in the form of

privacy loss, discrimination, abuse, and physical

harm. Preserving the security of MCPSs is thus

crucial.

• Certifiability: The complex and safety-critical na-ture of MCPSs requires a cost-effective way to de-

monstrate medical device software dependability.

Certification of medical devices provides a way of

achieving this goal. Certifiability is therefore an

essential requirement for the eventual viability

of MCPSs and an important challenge to be

addressed.

In the next several sections, we briefly highlight someof our current work in addressing the various of the chal-

lenges in building MCPSs. We begin with a model-based

development for high assurance medical devices in

Section III. We then present our work on interconnecting

several of these high-assurance medical devices, enabling

them to interoperate in Section IV. The data collected

from such interoperating devices can be processed to

enable the understanding of and informing caregivers ofthe patient context. We describe several smart alarm sys-

tems that can generate effective alarms based on pro-

cessing multiple streams of patient vital signs in Section V.

The availability of context awareness enables autonomous

medical systems. In this regard, building MCPSs for safe

closed-loop control for patient care delivery is described in

Section VI. Finally, we present our work on issues involved

with certification of MCPSs in Section VII.

III . HIGH-CONFIDENCE DEVELOPMENTOF MCPSs

Software plays an increasingly important role in the de-

velopment of new MCPSs. Most new device functionality

is software based, and many functions traditionally imple-

mented in hardwareVincluding safety interlocksVarebeing switched to software. Thus, high-confidence soft-

ware development is very important for the safety and

effectiveness of MCPSs.

Model-based development has emerged as a means of

improving software quality. The model-based approach

allows developers to perform rigorous model verification

with respect to safety and functional requirements, and

then through systematic code generation techniques derivecode that preserves the verified properties of the model.

Such a development process allows one to detect problems

with the design and fix them at the model level, early in the

design cycle, where changes are easier and cheaper to make.

More importantly, it holds the promise of improving the

safety of the system through verification. Model-based

techniques currently used in the medical device industry

rely on semiformal approaches such as UML and Simulink [9]and thus do not allow developers to fully utilize the benefits

of model-based design.

Our Approach. Here we will discuss a model-based de-

velopment process, illustrated by two recent case studies:

an infusion pump [42] and an implantable pacemaker [38].

The process, shown in Fig. 2, relies on well-known formal

modeling and analysis tools, UPPAAL [10] and TIMES [6],

to develop and verify the model of a system and generatecode from it.

We begin with system requirements, which are given as

natural language or using informal state machine notation.

Requirements may also contain tolerance, with which

timing constraints must be satisfied by an implementation.

Based on the requirements, we develop a system model in

UPPAAL. We also formalize requirements in a variant of

Lee et al.: Challenges and Research Directions in Medical Cyber–Physical Systems

Vol. 100, No. 1, January 2012 | Proceedings of the IEEE 77

the CTL temporal logic supported by the UPPAAL model

checker. Then, we perform verification of the UPPAAL

model with respect to the formalized requirements. The

obtained model is an ideal one, in that it satisfies the re-

quirements under the assumption that computation per-formed by the system is instantaneous. From the verified

model, we perform code generation using the TIMES tool

and adapt the code to the selected execution platform. We

then perform validation of the resulting system imple-

mentation with respect to the system requirements. In

addition to testing functional behavior of the system, we

also check that timing constraints are within tolerances

specified in the requirements.Validation results may show that tolerances are not

observed due to nontrivial computation time in the imple-

mentation. In this case, we identify the source of the vio-

lation and modify the model according to measurements

on the implementation, obtained during the validation ex-

periments. We then perform another iteration of the pro-

cess, reverifying the model, performing code generation

again, and repeating the validation. It is possible thatseveral iterations are needed until all constraints are met.

However, in our case studies, we did not have to cycle

more than once. When the process completes, we obtain a

software implementation of the system that runs on the

chosen platform and has been validated against the system

requirements.

Generic PCA Infusion Pump: Patient-controlled analge-

sia (PCA) infusion pumps are widely used for pain controlof postoperative patients. PCA pumps deliver opioid drugs,

which put the patient at risk of respiratory depression and

death in case of overdose. PCA pumps therefore are subject

to stringent safety requirements that aim to prevent

overdose. The generic PCA (GPCA) project, a joint effort

between our group and researchers at the FDA, aims to

develop a series of publicly available artifacts that can be

used as guidance for manufacturers. In the first phase of

the project, a collection of documents has been developed,

including a hazard analysis report, a set of safety require-

ments [39], and a reference model of the state controller.

The model concentrates on the state transitions in thecontroller software and abstracts away much of the func-

tional computation performed by the pump (for example,

estimation of the remaining drug volume to be infused).

Based on these documents, we studied a model-driven

implementation of a PCA infusion pump controller soft-

ware. We used the Hospira LifeCare PCA pump platform,

as the platform of choice in this regard. The platform

contains a microcontroller-equipped pump motor, severalsensors for environmental conditions, and a buzzer for

sounding alarms. Controller software is deployed on a

OMAP3530 processor running Linux OS, which commu-

nicates with the motor microcontroller over a serial line.

The user interface is implemented using an Android

application on a smartphone.

Following the process described above, we formalized

both the model and the requirements in UPPAAL, per-formed formal verification of the model, then generated

code using TIMES. To validate the generated code, we

performed conformance testing using a testbed that moni-

tors the execution of the implementation and compares it

with the corresponding model execution. No violations

were observed during testing.

As part of the formalization process, we categorized

safety requirements according to their precision and levelof abstraction: 1) requirements that are detailed enough

to be formalized and verified on the UPPAAL model;

2) requirements that are beyond the scope of the UPPAAL

model; and 3) requirements that are too imprecise to be

formalized. Only 20 out of 97 requirements fell into the

first category. Most of the requirements in the second

category concern the functional aspects of the system that

Fig. 2. Development process in the pacemaker case study.

Lee et al.: Challenges and Research Directions in Medical Cyber–Physical Systems

78 Proceedings of the IEEE | Vol. 100, No. 1, January 2012

are abstracted away by the UPPAAL model. Implemen-tation of these functional aspects, such as the remaining

drug volume estimation, is performed outside the model-

based process. Thus, these requirements can be validated

on the implementation. An example from the third ca-

tegory is Bflow discontinuity at low flows should be

minimal,[ which does not specify what is a low flow or

what discontinuity can be accepted as minimal. This ex-

ample shows the importance of a model-based process notjust for software design, but also for requirements engi-

neering. Through formalization, we are forced to identify

ambiguous requirements like the one shown above and

provide feedback to the requirements engineers.

Pacemaker Challenge Problem: The second case study

was motivated by the pacemaker challenge, the certifica-

tion challenge problem issued by the software certification

consortium (SCC) [61]. The challenge involves the devel-opment of pacemaker controller software that is formally

verified for compliance with the timing requirements

released by Boston Scientific.

A cardiac pacemaker is an electronic device implanted

into the body to compensate for irregularities in the

intrinsic heart rhythm by delivering electrical stimuli,

called paces, to the heart. The pacemaker may also detect

natural heart activity, called sense signals. Timing require-ments for the pacemaker operation are given by a number

of properties known as timing cycles. The applicable tim-

ing cycles depend on the operating mode of the pace-

maker. The operating mode is set by a physician before the

pacemaker is implanted, depending on the patient condi-

tion. The mode describes what sensing and pacing is

performed and relationship between them. In this paper,

we considered the mode, in which the pacemaker per-forms ventricular sensing and ventricular pacing with

inhibition (VVI). That is, pacing will occur at regular

intervals, unless heart activity in the ventricle is sensed. A

sense will inhibit the next pace, allowing the heart to beat

on its own.

The timing cycles applicable in the VVI mode make

use of the lower rate limit interval (LRI) and the ventri-

cular refractory period (VRP). The LRI specifies themaximum time interval that can elapse between any two

cardiac events (senses or paces). During the VRP, which

begins after every pace, sensing has to be turned off to

avoid pace-induced false senses. In addition to prescribing

the timing cycles, the pacemaker requirements specify

tolerances with which the cycles must be adhered to.

We used the process described above to implement the

pacemaker controller [38]. First, we created a model of thecontroller using timed automata in the UPPAAL tool, then

we converted the applicable timing cycles into temporal

logic properties and verified them using the UPPAAL

model checker, followed by code generation. In this case,

however, validation demonstrated that timing constraints

were not satisfied within their tolerance levels. By ana-

lyzing the timing traces of the controller, we identified

operations that contributed most to the property violationand measured their execution times. We modified the

UPPAAL model by tightening transition guards, making

the offending operations start earlier. After reverifying the

model and generating the code again, the controller imple-

mentation passed the validation phase.

Future Work. The case studies demonstrated that, while

the overall process achieves good results in practice, it is

somewhat ad hoc when iterations of the process occur.Further work is needed to identify, which changes to the

model would make the process converge faster, or to

quickly detect that the timing requirements are not imple-

mentable and no amount of model modification will suc-

ceed. In general, more rigorous development processes are

needed, providing stronger guarantees for timing and

other nonfunctional properties.

IV. SOFTWARE PLATFORMS FORMEDICAL DEVICE INTEROPERABILITY

Engineering MCPS goes beyond considering the individual

medical device: MCPS will consist of networks of medical

devices and computer systems cooperating to provide care

to patients. Conceptually, the set of device types and the

algorithm which defines how those devices should interact

in a given clinical scenario is a virtual medical device

(VMD). VMDs can be instantiated into a VMD instance by

coupling specific1 network-connected devices with theappropriate clinical algorithm executing on a computer.

The software artifact that contains the list of required

devices and the executable clinical algorithm can be

thought of as a VMD App.

To manage the instantiation and shutdown of the

VMD, there should be some systems present on the

hospital network. For example, the medical device plug-

and-play (MD PnP) interoperability initiative [26] hasproposed an interoperability platform and architecture

known as the integrated clinical environment (ICE) which

would serve that purpose. Such a Bplug-and-play[ mech-

anism can be used to support the following clinical

workflow.

1) The clinician decides on the treatment plan for the

patient.

2) The clinician selects medical devices used to applythe treatment.

3) The clinician assembles the treatment system by

connecting the devices to an ICE supervisor

computer and to the patient.

4) The clinician starts the required VMD App,

which will automatically bind the physical de-

vices into the VMD instance and orchestrate

interaction among the devices to execute thetreatment plan.

1The specific devices must possess the capabilities required by thegiven VMD.

Lee et al.: Challenges and Research Directions in Medical Cyber–Physical Systems

Vol. 100, No. 1, January 2012 | Proceedings of the IEEE 79

At the moment steps 3 and 4 are infeasible, because

out-of-the-box medical devices do not have the ability to

communicate with each other. Further, they are neither

interoperable (i.e., expose interfaces for remote control to

the network), nor safely composable. This also severely

limits the choices for the first and second steps, becausethe clinician must take the availability and quality of only

single devices into consideration when deciding on the

treatment plan.

Our Approach. As shown in Fig. 3, a critical

component in interoperability platforms is the interoper-ability manager. The interoperability manager tracks

which medical devices are connected to the network,

binds connected medical devices into VMD instances,provides an execution environment for a VMD’s work-

flow algorithms, detects device or network faults, and

ensures that concurrently executing VMD instances do

not interfere with one another. We have been building

an open-source, prototype, interoperability manager

known as the medical device coordination framework

(MDCF) [44].

Medical Device Coordination Framework Overview: TheMDCF is middleware designed to facilitate and manage

the composition of medical devices and clinical algorithms

into VMD instances. The middleware consists of a server

process that runs on a computer and a lightweight com-

munications library that can be incorporated into the

software of the individual medical devices. The server

process and communications library work in tandem to

provide the following.1) Publish–Subscibe Messaging Service: Data between

the MDCF and the devices are published as mes-

sages to topics. Publish–subscribe communication

facilitates easy sharing of data (e.g., physiologic

data from one device can easily be shared among

multiple concurrent VMD instances).

2) Device Management: The MDCF only allowsdevices approved by the MDCF administrator to

associate (connect) with the middleware. The

status of associated devices is tracked via a heart-

beat mechanism.

3) VMD App Management: The MDCF facilitates the

instantiation and deactivation of VMD instances.

Clinicians instantiate a VMD by selecting a VMD

App and the currently connected devices to use inthe VMD. The MDCF will load the VMD App’s

clinical algorithm into a virtual machine and

then bind the selected devices to the algorithm.

The VMD deactivates a VMD instance by notify-

ing each device that it is no longer bound and

by releasing any resources used by the clinical

algorithm.

Additionally, the MDCF provides an integrated devel-opment environment (IDE), which is a separate program

VMD App developers can use to design and implement

VMD Apps as well as define the logical interfaces (i.e.,

capabilities) of MDCF devices. In particular, developers

can use the IDE to do the following.

1) Define Device Types: A device can be abstractly

described in terms of the data it publishes (out-

put ports) and the data it subscribes to (inputports).

2) Automatically Generate Code: The IDE can auto-

matically generate the communications library for

a specific device type. The generated code handles

all the communications between the MDCF and

the device (including an implementation of the

MDCF association protocol). Because the gener-

ated code conforms to the MDCF specification forthe device type, device developers only need to

write the Badapter code[ required to convert data

between the MDCF data format and the device’s

native data format.

3) Specify VMD Apps: VMD App developers can de-

fine their application by specifying what device

types are used in the VMD, what clinical algo-

rithms are used, and what topics each device andalgorithm should subscribe to. Fig. 4 shows how

Fig. 3. Relationship between devices, interoperability manager,

and clinical algorithms.

Fig. 4. Dataflow specification for a closed-loop PCA application.

Lee et al.: Challenges and Research Directions in Medical Cyber–Physical Systems

80 Proceedings of the IEEE | Vol. 100, No. 1, January 2012

the closed-loop PCA application (described laterin Section VI) looks like in the IDE’s graphical

VMD App editor.

While the MDCF is a prototype and under develop-

ment, we have used the MDCF to implement a number of

different medical device integration scenarios such as a

closed-loop PCA application (see Section VI) using a com-

bination of real and simulated devices [43], and a smartalarm (see Section V) for postcoronary artery bypass graftsurgery patients [45].

Future Work. A number of open problems remain to be

addressed in VMD instantiation. Support for real-time

communication, which requires runtime allocation of

processor and network resources to VMD Apps, is cur-

rently missing. A large part of the challenge is to imple-

ment such allocation in hospital communication network,

which are open to various sources of interference fromother traffic. We also need to establish a sufficient level

of confidence in both the interoperability framework,

such as MDCF, and VMD Apps. For this, verification of

association and communication protocols used by MDCF

is necessary, as well as establishing conformance of MDCF

software implementation to formal design specifications.

A process similar to the one discussed in Section III should

be used for the development of high-confidence VMDApps and their instantiation over MDCF. Additionally,

open challenges in medical device interoperability include

security and privacy concerns (see Section VIII) and

certification of VMDs (see Section VII).

V. SMART ALARMS AND CLINICALDECISION SUPPORT

Achieving medical device interoperability will allow me-

dical information to be streamed from multiple devices

into central locations in real time. This presents unique

opportunities to significantly improve clinical care. Mod-

ern hospital rooms are commonly equipped with many

such medical devices, currently used to continuously mo-

nitor their patients’ vital signs. These vital sign monitors

give clinicians a window into the patient’s state and can beconfigured to alert clinicians to a deterioration in state.

Most medical devices currently in use can only be con-

figured with threshold alarms, i.e., alarms which activate

when a vital sign crosses a predefined threshold. While

threshold alarms can be vital in the timely detection of

emergency states, they have been shown to be unscientific

[47], cause a high number of alarms [33], and have a high

rate of false alarms [17], [35], which fatigues caretakers[60] and leads them to ignore or turn off many alarms [21].

This has been shown to decrease quality of care [17], [20],

[34]. Also, these alarms only alert clinicians to the fact that

some threshold was crossed; they fail to provide any

physiologic or diagnostic information about the current

state of the patient that might help reveal the underlying

cause of the patient’s distress.

Creating MCPSs which stream real-time medical in-formation from different devices and combine it with

information from the patient’s health record would im-

prove the accuracy and usefulness of alarms [11], [13], [14].

Such systems could then be equipped to automatically

suppress irrelevant alarms and provide summaries of the

patient’s state, as well as predict future trends in the pa-

tient. These MCPSs, realized as VMDs, would act as high

accuracy smart alarms, which would alert clinicians todeterioration in the patient’s state quickly and precisely,

while providing them with access to the data that evi-

dences the deterioration [34]. There have been many calls

for a focus on evidence-based medicine as standard prac-

tice [22], [57], and smart alarms would help to satisfy these

calls.

Smart alarm systems in particular require achieving

some level of context-aware computational intelligence inMCPSs. Relevant information from multiple medical

device data streams must be extracted and filtered [15],

[34] and used in concert with a patient model to create a

context-aware clinical Bpicture[ of the patient. Developing

context-aware computational intelligence is difficult. Pos-

sible solutions, such as encoding hospital guidelines, ex-

tracting mental models from medical professionals, and

learning the models statistically from data all pose uniquechallenges.

Many efforts have been made to improve the accuracy

of threshold alarms [16], [23], [52], [58]. Likewise, many

clinical decision support systems, which are inherently

evidence based, have been shown to hold promise in im-

proving care [25], [32]. Initial successes in the area high-

light the need for a cohesive, unified effort to improve all

alarms used in hospitals.Our Approach. Achieving context awareness in MCPSs

requires the ability to preprocess and store patient data

from patient streams. Techniques can be simple, such as

downsampling or capturing trends, or they can be com-

plex, such as using time series analysis to extract mean-

ingful characteristics from a waveform. These techniques

are well understood and can be employed to this end.

Determining the best technique to use in any application,however, is difficult.

Data thus acquired must be compared with some sort of

clinical model to be used in an intelligent fashion. As with

preprocessing, this multitude of available techniques

makes choosing the best technique difficult. Additionally,

few machine learning techniques have been rigorously

analyzed in the context of medicine. Chosen algorithms

must be equipped to handle missing values and effectivelyaccount for the passage of time.

Generic Smart Alarm: We are addressing these chal-

lenges by building smart alarm systems subscribing to a

generic architecture which is flexible enough to rapidly

prototype reconfigurable and verifiable systems. This ar-

chitecture consists of: several stages of preprocessing

modules which process the raw data from the medical

Lee et al.: Challenges and Research Directions in Medical Cyber–Physical Systems

Vol. 100, No. 1, January 2012 | Proceedings of the IEEE 81

devices and deliver it to the inference modules; a stage of

inference modules which combine these data streams to

produce some high-level output (e.g., an alarm level); and

a visualization component. This architecture is shown in

Fig. 5.We are working closely with doctors and nurses at the

Hospital of the University of Pennsylvania on specific

implementations of the generic smart alarm. The smart

alarm is designed to target areas of the ICU in which

alarms are perceived as inadequate. We also plan to intro-

duce smart alarms in areas where no alarm exists, owing to

the difficulty to diagnose some particular alarmable patient

state. Each of these implementations has begun to shedlight on possible solutions to the challenges outlined

above.

Smart Alarm for CABG Patients: After undergoing artery

bypass graft (CABG) surgery, patients are at high risk of

physiologic instability [49] which causes a high level of

false alarms. To attempt to improve the accuracy of alarms

in this domain, and to begin testing the generic smart

alarm architecture, we created a straightforward instanti-ation of the GSA, using simple preprocessing and inference

modules. We interviewed ICU nurses to create preprocess-

ing modules which classified four major vital signs com-

monly monitored in the ICU (heart rate, blood pressure,

blood oxygen saturation, and respiratory rate) into catego-

ries based on ranges (Blow,[ Bnormal,[ Bhigh,[ Bvery

high,[ etc.). Afterwards, nurses determined rules that

identified combinations of these vital sign categorieswhich they deemed would be cause for concern. The

smart alarm monitors a patient’s four vitals, classifies those

into categories, and searches the rule table for a corre-

sponding alarm level to output. Combining vital signs

produced a 57.13% reduction in false alarms generated

without suppressing any true alarms [45].

Seizure Smart Alarm: Brain tissue oxygen monitors are

currently utilized in a threshold-based fashion. Some prac-tice guidelines suggest that a seizure is a potential culprit

when brain tissue oxygen crosses a particular threshold.

We have conducted preliminary studies which seem to

indicate that this threshold may not be substantiated [54].We are currently integrating multiple vital signs including

brain tissue oxygen to create a Bsmart alarm[ for seizures

in the context of neurocritical care which goes beyond

simple thresholds.

Vasospasm Smart Alarm: After aneurysmal subarachnoid

hemorrhage, patients are kept in the ICU for up to 14 days

to monitor for cerebral vasospasm (VSP), a narrowing of

the blood vessels in the brain. The VSP condition, ifundiagnosed or untreated, can lead to cerebral ischemia

and neurologic dysfunction. While there are clinical factors

which increase suspicion for VSP, the ability to define onset

of this clinical syndrome is made difficult by the poor

sensitivity of available tests. The only definitive measure of

its presence is a cerebral angiogram, which is an invasive

and resource-intensive study whose repetition is limited by

radiation and contrast exposure to the patient. There isbenefit to detecting VSP early, and risk to the patient from

overtesting with cerebral angiogram. Integrating signals

from multiple patient monitors, we strive to reduce the

number of false alarms for VSP, as well as enable discovery

of significant features that would improve the timeliness of

diagnosis.

Future Work. As mentioned above, these sorts of smart

alarms have been developed in the past, and most havebeen shown to improve care when utilized in hospitals.

Few of these systems, however, have gained widespread

use, due to several shortcomings.

1) Data: Current systems often combine only a few

vital signs, limiting their scope. Most do not

address issues with sparse data, or with capturing

data not collected electronically. Significant

challenges still exist in determining which patientmodel generation technique is most advantageous

in any given context. Future work must expand the

number of vital signs considered, and justify

choice of model generator.

2) Workflow: Due to their experimental nature,

published smart alarm systems are often highly

complex and rarely incorporate user-centered

design. Work is needed to ensure that smartalarm systems are clear and simple to use, which

will help to justify their integration into clinician

workflow.

3) Practicality: These systems are often domain and

hospital specific, making reuse in wider contexts

difficult. Additionally, these systems are rarely

certified to be safe. Significant challenge still

exists in understanding what safety means in thecase of Bsmart[ systems and in creating systems

that are both safe and reusable.

Future smart alarms must take the form of a tool to be

utilized to improve patient care, and not constitute a chore

to be completed or a replacement for physician reasoning

[59]. Smart alarms, however, have the potential to go

beyond advisory roles.

Fig. 5. Generic smart alarm architecture, instantiated as a

smart alarm for CABG patients.

Lee et al.: Challenges and Research Directions in Medical Cyber–Physical Systems

82 Proceedings of the IEEE | Vol. 100, No. 1, January 2012

VI. PHYSIOLOGICAL CLOSED-LOOPSYSTEMS

In smart alarm systems, physiological data are integrated

and processed to provide clinical decision support.

Integrated physiological data can also be used to directly

control therapeutic delivery devices, forming a physiolog-

ical closed-loop system. Automatic controllers have been

successfully deployed in many safety critical systems, e.g.,

auto pilot in avionics and active cruise control in auto-

mobiles. In patient care, it is possible to construct a phy-

siological closed-loop system by continuously monitoring

patients’ states, automatically reconfiguring delivery de-

vices, and only alerting caregivers if patients’ states divert

from the normal range. Caregivers can then concentrate

on making important clinical decisions, reducing the

chances of missing critical events, thereby improving pa-

tient safety.

Closed-loop control has been deployed in some medical

applications, but mostly in implantable devices such as

cardioverter defibrillators, and other special purpose

devices that do not need to be interconnected with other

devices for routine operations. This need not be the case. A

physiological closed-loop system can be modeled as a VMD

and can be built in a cost-effective way by networking

existing medical devices, such as infusion pumps and vital

sign monitors. However, such a system also introduces

new hazards that need to be systematically identified and

mitigated.

One critical issue in applying the model-driven devel-

opment to such systems is the patient modeling. There has

been much work in patient modeling; for example,

glucose–insulin kinetics have been extensively studied

and modeled. Several control strategies, such as the model

predictive control [46], [54], have been developed and

evaluated on these specific biochemical models. However,

most previous studies [12], [18] on physiological control

assume no communication failures or delays. Our work, on

the other hand, considers failures that networked closed-

loop systems may suffer from in practice.

Fig. 6 shows how medical devices can be intercon-

nected to form a physiological closed-loop system. We first

give a high-level overview of two clinical cases that can

benefit from closed-loop systems, and we will revisit them

to address the technical challenges after introducing our

general approach. The systems in the two cases share the

same structure shown in the figure.

Closed-Loop Patient Controlled Analgesia (PCA): As

mentioned in Section III, a major safety concern in PCA

pump use is that an overdose of analgesic can cause

respiratory failure. However, the existing safety me-

chanisms are considered insufficient to cover all possible

scenarios [51]. A closed-loop solution to address the safety

issues of PCA pump use is proposed in our previous work

[7]. Here, a pulse oximeter is used to continuously

monitor two respiratory-related vital signs, heart rate

(HR), and blood oxygen saturation (SpO2), and transmit

the readings to a controller. The controller can stop the

PCA infusion if it detects possible respiratory failures

based on the HR/SpO2 readings, and thus overdosing is

prevented.

Closed-Loop Blood Glucose (BG) Regulation: Diabeticsand some ICU patients depend on external insulin and

glucose administration to maintain their BG level within a

reference range, e.g., 70–130 mg/dl [1]. Traditionally,

nurses take glucose measurements regularly and manually

adjust the insulin infusion rate or administrate glucose.

The problem is that the interval between two check points

may be rather long, which limits the quality of control

leading to severe oscillations of BG levels. In addition, themanual measurement and adjustment process is prone to

human errors. In a closed-loop BG control system, a con-

troller continuously monitors the BG and adjusts the

insulin infusion rate. Caregivers are alerted if an adverse

event such as hypoglycemia occurs. Such a closed-loop

system can improve the quality of BG control.

In the above two cases, networked closed-loop systems

can be used to improve clinical care, but networks alsointroduce new hazards that could compromise patient

safety. Our research goal is to develop networked physio-

logical closed-loop systems that assure patient safety. The

key issue here is to identify and mitigate hazards intro-

duced by the networked closed-loop systems, and ensure

that the hazardous situations do not happen.

Our Approach. For the design of a safe physiological

closed-loop system, we follow the iterative verification andvalidation approach shown in Fig. 7. First, we identify

concrete use cases. We then model individual components

of the system as shown in Fig. 6: the patient, monitoring

and delivery devices, and network. The patient model is

developed by implementing physiological models on ve-

rification and simulation tools, such as UPPAAL and

Simulink. We model the input–output behavior of

Fig. 6. PCA/BG closed-loop system.

Lee et al.: Challenges and Research Directions in Medical Cyber–Physical Systems

Vol. 100, No. 1, January 2012 | Proceedings of the IEEE 83

monitoring and delivery devices by considering the

measurement and delivery errors that realistic devices

may exhibit [41]. For example, to model a glucometer that

has 10% measurement errors, our glucometer modelintroduces 10% errors onto the BG value it gets from the

patient model, and transmits the resulting value to the

controller. The network model describes the statistical

behavior of network communication.

Next, we model a controller and design the entire sys-

tem by connecting and defining interfaces between indi-

vidual components. We then perform a hazard analysis and

identify possible causes for each hazard. For example, inthe PCA case, a possible cause of overdosing is that a

Bstop[ command fails to reach the PCA pump due to

network failure. We systematically identify such failure

conditions and check whether all safety properties are

satisfied in all scenarios, by running simulation on

Simulink and formal verification on UPPAAL. We revise

controller and system designs until all hazards are proved

to be properly mitigated. The final step is instantiating oursafe design of physiological closed-loop VMD as a VMD

instance.

We next describe how we have applied this design

process to the PCA and BG case studies.

Closed-Loop PCA: We have developed a patient model

from [48] to represent the effect of drug level to HR and

SpO2. The model can be tuned to capture the variation of

patient dynamics. We have constructed a Simulink modelto precisely capture the continuous dynamics of the

patient model and validated it by simulation. To formally

verify the timing properties of the model, we also con-

structed a UPPAAL model that abstracts continuous dy-

namics, but preserves the timing behavior of components,

which allows us to reason about the maximum end-to-

end delay in delivering commands to the pump. We

identified two types of failure in the PCA closed-loopsystem:

• sensor failures, e.g., the pulse oximeter leads get

detached from the patient so that the controller

cannot receive correct HR/SpO2 readings;

• network failures, in which case the controller

cannot receive any readings from the sensor and

the pump cannot receive any commands from the

controller.To mitigate hazards due to these failures, we refined

the system design so that open-loop stability is guaranteed;

that is, if the controller cannot receive readings or the

pump cannot receive control commands, the system can

automatically go into a safe mode to prevent overdosing.

One possible solution to achieve such open-loop stability,

or fail-safe operation, is to let the controller instruct the

PCA pump the duration of each drug delivery requested bythe patient. The controller calculates this duration at run

time based on the difference between the patient’s current

drug level and the safety limit. Therefore, it is guaranteed

that the patient cannot be overdosed within the instructed

time duration. Doing so, even if the sensor or network

fails, the pump will stop infusion based on the last duration

command it received, thus the system can fail-safe.

Another possible solution is let the controller set a max-imum drug dosage.

Closed-Loop BG Control: We have implemented the

glucose–insulin patient model introduced in [55] in

Simulink. As a start point of controller design, we have

modeled and implemented several BG control guidelines

being used at the Hospital of the University of Pennsylva-

nia. We have run closed-loop simulations by connecting

the patient model with the guideline-based controllers.Our preliminary simulation results show that long

intervals between two check points may indeed limit the

quality of control and result in severe overshooting of BG

trajectories.

We have found that the complexity of hazard analysis is

closely related to control objectives. Specifically, the ob-

jective of maintaining BG within a certain range makes the

hazards identification and mitigation in the BG case morecomplicated than the PCA case. This is because there is no

trivial fail-safe mode for BG control (e.g., simply stopping

infusion is no longer a safe default option), and a miti-

gation strategy design is more challenging because both

hyperglycemia and hypoglycemia need to be avoided.

Future Work. Validation of physiological closed-loop

systems remains a major challenge. Ultimately, clinical

outcomes delivered by a closed-loop system need to becompared with current caregiver-centric approaches. We

are exploring the use of SimMan [2], which provides a

controlled, realistic caregiving environment with patient

simulator. More generally, we will explore the notion of

virtual clinical trial, which so far has been considered only

in drug development. Also, the role of a caregiver in a

closed-loop system needs to be studied more carefully.

Fig. 7. Development of a distributed physiological

closed-loop system.

Lee et al.: Challenges and Research Directions in Medical Cyber–Physical Systems

84 Proceedings of the IEEE | Vol. 100, No. 1, January 2012

After all, we are not aiming at fully autonomous systemsthat exclude humans. We expect that work on smart alarm

systems (see Section V) will provide useful insights.

VII. CERTIFICATION ANDREGULATORY ISSUES

Like most safety-critical system, MCPSs are subject to

regulatory oversight through a certification or approvalprocess. The fundamental goal of certification of MCPSs is

to assess safety and effectiveness of MCPSs. The tradi-

tional process-based regulatory regime used currently by

the FDA to approve medical devices is becoming inade-

quate for the MCPS complexity [31]. A new, evidence-

based regulatory regime is being put in place. Within the

infusion pump improvement initiative [63], the FDA now

requires assurance cases as part of the documentationsubmitted for approval. We can expect that similar re-

quirements will be extended to MCPSs in general.

An important part of the challenge is software cer-

tification and ways to incorporate it into the regulatory

approval process for the device as a whole. Medical devices

have increasingly large amounts of software, performing

various monitoring and care delivery tasks. Software-

specific risks are not as well understood, and evidence ofsoftware quality is harder to evaluate. Current design prac-

tice places verification and certification at the end of the

design cycle, when it is frequently too late to change design

choices. As medical devices become more complex and

more interconnected, it is becoming increasingly evident

that verification and certification should be incorporated in

early design stages. This can be done in two ways: on the

one hand, the Bdesign for verification[ approach [5] canhelp verification techniques scale better and make gener-

ation of verification evidence easier; on the other hand,

model-based generative techniques can be used to enable

one to perform verification early in the design and then

extend the guarantees provided by verification to the

implementation through code generation.

Throughout the domain of software-intensive embed-

ded and CPS systems, a new regulatory approach to certi-fication has been advocated [36], based on collecting and

reviewing evidence that the system achieves its goals.

Model-driven techniques can help with the transition to

evidence-based certification, from the current process-

based approach. Using compositional modeling techniques

and assume-guarantee reasoning may enable incrementalcertification, which would allow us to recertify MCPSs after

component upgrades without reconsidering the wholeassurance case from scratch.

Our Approach. Model-based development processes

produce a number of artifacts that can be used as evidence

of system quality. The artifacts include models, formalized

properties, results of verification and testing, etc. Assur-

ance cases have been suggested for organizing the gene-

rated evidence for the purpose of regulatory approval or

certification [36]. An assurance case is a documented body

of evidence that provides a convincing and valid argumentthat a specified set of critical claims about a system’s pro-

perties are adequately justified for a given application in a

given environment [4]. Assurance cases hold the promise

of both reducing certification costs and improving the

quality of certification by tying it to evidence. Yet, there

are few commonly accepted ways of constructing assurance

cases. A poorly structured assurance case, however, can

hamper the evaluation process, rather than help it [66].Clearly, there is no Bone-size-fits-all[ structure, and

software developed through different processes is likely

to require different arguments about its safety. In [37], we

aimed to discover appropriate assurance case structures for

model-driven development.

Using the pacemaker case study described in

Section III, we constructed an assurance case for the con-

troller developed by our iterative-model-based process.The structure of the assurance case, shown in Fig. 8, re-

flects the main steps of the process. The top-level claim of

the assurance case is that the pacemaker software is accep-

tably safe to operate. The two main subclaims decompose

the argument into assessment of the system requirements

and assessment of the requirements satisfaction. That is,

we argue that requirements guarantee safety, and once that

is established, argue that the developed system satisfies therequirements. Our case study, however, did not include

development of the requirements, and thus we introduce

an assumption that the requirements are adequate and

concentrate on the second subclaim. It states that the code

satisfies the timing properties with the specified tolerance.

We then decompose the claim further into three subclaims

according to the steps of the process: 1) the model satisfies

Fig. 8. Top-level claims of the pacemaker assurance case.

Lee et al.: Challenges and Research Directions in Medical Cyber–Physical Systems

Vol. 100, No. 1, January 2012 | Proceedings of the IEEE 85

the timing properties, demonstrated by the UPPAAL veri-fication results; 2) code generation preserves model pro-

perties, demonstrated by the correctness proof of the

TIMES tool algorithm; and 3) the generated code exhibits

the required timing properties with the prescribed tole-

rance, demonstrated by measurements during testing.

Future Work. Assurance Case Templates: The con-

structed assurance case captures the source of our con-

fidence in the design as well as in the model-based processwe used. Ultimately, we would like to develop assurance

case templates for various development processes in order

to simplify construction of cases for future systems de-

veloped through the same process. An important aspect of

the assurance case framework, which remains a significant

challenge for their application in practice, is evaluation of

assurance cases. We need to develop means of rigorous, if

informal, ways of quantifying the level of confidence de-livered by an assurance case. This will be an important

direction of our future work.

Certification of Virtual Medical Devices: Certification of

virtual medical devices is another major challenge of

MCPSs. It requires a fundamental change in the regulatory

process. Standalone medical devices are certified (or ap-

proved) by a rigorous analysis of the device’s design,

manufacturing process, and final testing. However, VMDinstances are instantiated in hospitals in different ways and

cannot be certified individually. Ideally, a VMD should be

certified as a specification, so that as long as a VMD in-

stance is instantiated according to the respective VMD, it

is guaranteed to be safe. Note also that VMD instances are

not built from scratch, but from standalone medical de-

vices, which were themselves certified, and an assurance

case for a VMD instance should be able to rely on thesecertificates. A vision for VMD instance certification has

been put forth under the names of compositional, runtime,

or just-in-time certification [56]. However, to this date, the

vision remains largely unrealized and requires further re-

search. A regulatory framework based on third-party certi-

fication approach for VMDs is proposed in [29]. It lays out

primary verification tasks associated with each VMD

component and tool support necessary for the verificationand certification activities. The framework is supported by

a security and authentication layer in the interoperability

platform that establishes trust in the safety and correctness

of VMDs used in building the VMD instance.

VIII. OPEN ISSUES

In this section, we present some of the open issues that stillrequire addressing in the domain of MCPS.

Security and Privacy. While interoperability capabilities

allow medical devices to be incorporated into MCPS,

acquiring functionality that was never possible previously,

they also open the door to a host of security and privacy

concerns [3]. An attacker who penetrates an MCPS net-

work has the potential to harm or kill patients by reprog-

ramming devices [27]. The increased autonomy of MCPSwith closed-loop control, automated therapy delivery, and

alarm capabilities has the potential to exacerbate the prob-

lem. In general, when attacking an MCPS, adversaries can

choose from four classes of targets [8].

• Patient: An attacker directly targets the patient’s

health. This is usually achieved by targeting the

sensing, processing, communication, and treat-

ment delivery aspects of the MCPS. One examplemight involve an attacker programming an infu-

sion pump to administer a larger than necessary

dose of medicine.

• Data: An attacker accesses an individual patient’s

health data from the MCPS in an unauthorized

manner. The consequence is loss of patient privacy

leading to potential discrimination and abuse [64].

• Device: An attacker mounts a denial of service(DoS) on the MCPS in some form so that it cannot

perform its task, thus limiting device availability.

This can also result in loss of privacy in systems

that are designed to fail-open as suggested in [19].

• Institution: The goal is to compromise the interac-

tion between the MCPS and the internal network

of the institution it is deployed in to obtain access,

at a large scale, to patient data or network opera-tional information.

The approach usually taken by most device manufac-

turers today is to limit the functionality that can be in-

voked through the network interface. In most cases, the

device can send out data, such as sensor readings or event

logs, but not accept commands from the network. Al-

though such an approach improves security of the system,

it severely limits the ability to deploy closed-loop scena-rios. In other cases, device manufacturers introduce pro-

prietary security solutions and rely on Bsecurity through

obscurity.[ This attitude has been shown to be problem-

atic, as adversaries will always be able to break into such a

system [24].

Recent years have seen the issue of medical device

security addressed for different classes of medical devices

such as implantable [19], [27] or interoperable devices [64].However, in most of these cases, the focus is on specific

aspects of MCPS operation, namely secure communication,

and effective access control. Fundamentally, the challenge

of targeting security for MCPS involves developing flexibleand open solutions while addressing the following four

issues: 1) minimizing the overhead that security solutions

inevitably bring; 2) dealing with the heterogeneity of MCPS

that precludes system-wide solutions; 3) improving usabil-ity (even transparency) of security solutions developed; and

4) considering safety implications of security solutions and

decisions.

As a first step in securing MCPS, we are extending the

MDCF to support encrypted communications between the

devices and MDCF. Additionally, the middleware server

needs to establish trust in the devices, and the devices need

Lee et al.: Challenges and Research Directions in Medical Cyber–Physical Systems

86 Proceedings of the IEEE | Vol. 100, No. 1, January 2012

to establish trust in the middleware (i.e., only known,certified devices should be bound into a VMD) [29]. Fur-

thermore, the MDCF needs to ensure that the set of me-

dical devices are indeed connected to the same patient.

Eventually, more holistic solutions for MCPS that look at

security in the larger context of their deployment in

clinical workflows will need to be created.

Patient Modeling and Simulation. A closely related chal-

lenge is that of patient modeling. Patient models areneeded for the design of closed-loop control, as well as for

the safety analysis of scenarios. For example, the closed-

loop PCA scenario requires a model of drug absorption by

the patient body, as well as the relationship between the

drug dose and concentration and patient vital signs, such

as heart rates and respiratory rates. Pharmaco*kinetic

models of drug absorption are known from the literature

(e.g., [48]), and there is statistical data on the effect of thedrug on vital signs. However, comprehensive models are

too complex to be used in the design and analysis. Thus,

development of new abstraction techniques is paramount

for addressing this challenge.

User-Centered Design. Caregiver errors in using medical

devices are a major source of adverse events [30], [65].

Undoubtedly, some of these errors are due to stress and

overload that caregivers experience daily. Poor user-interface design also has been attributed for many of these

errors. If a device is hard to operate, has a counterintuitive

interface, or responds to user inputs in an unexpected

manner, user errors are much easier to occur. Design and

validation of medical devices needs to take into account

user expectations. To use model-based design for interac-

tive medical devices, we have to incorporate models of

caregiver behavior. Such user modeling is a notoriouslychallenging problem. However, incorporating information

about likelihood of certain actions into caregiver models

opens the way for quantitatively reasoning about device

safety.

Compositionality. Interoperable network-enabled med-

ical devices will increasingly be composed into MCPS

dynamically. Compositional reasoning is the only rigorous

way to ensure safety of such systems. A particularly chal-lenging problem is predicting the possibilities of unex-

pected interactions between devices in the system. For

example, devices providing different treatments to the

same patient may incur radio interference because of close

proximity to each other. More importantly, treatmentsthemselves can interfere with each other by affecting

physiological responses [28]. MCPS designers should be

aware of these interferences and ensure that the system

providing a treatment is made aware of potentially inter-

fering treatments through sufficient context information.

Continuous Monitoring and Care. One of the most im-

portant needs of modern medicine is to develop medical

devices capable of providing continuous care (i.e., moni-toring, decision support, and delivery of therapy). Such

devices are expected to decrease healthcare cost by ena-

bling alternatives such as home-based or ambulatory care.

Caregivers can have a detailed picture of the patient’s

health at all times, enabling them to better tune the

treatment provided. Such a system also allows for real-

time notification in the event of emergencies and pro-

viding first-responders with accurate and completeinformation about the patient’s health. Continuous care

systems are being designed to monitor a plethora of

ailments such as cardiovascular diseases [40], neurological

problems [62], collecting meta-physiological state infor-

mation (sleep, awake, fatigue) [55], circadian activity

monitoring [67], and extreme environment medical

monitoring (e.g., space) [50].

IX. CONCLUSION

In this paper, we considered MCPSs as a distinct CPS

domain. Due to increasing societal pressures and new

technological capabilities, the field of MCPSs is on the

verge of a substantial transformation that will change the

ways these systems are developed and approved, as well as

expand features and strengthen safety guarantees theMCPS offer to caregivers and patients. This transformation

will lead to a further increase in the complexity of MCPS

and the degree of integration within them.

Thus, the domain of MCPS offers a unique set of chal-

lenges, distinct from any other CPS domain [31]. The

challenges facing MCPSs are formidable, yet they present

vast opportunities for research with immediate practical

impact. We identified major challenges in MCPS devel-opment and discussed promising research directions that

may help to overcome some of these challenges. We en-

vision that these challenges will provide major opportuni-

ties for R&D communities in the next ten years. h

RE FERENCES

[1] American Diabetes Association, accessedJun. 15, 2011. [Online]. Available: http://www.diabetes.org/living-with-diabetes/treatment-and-care/blood-glucose-control/tight-diabetes-control.html

[2] Laerdal SimMan, Jun. 17, 2011. [Online].Available: http://www.laerdal.com/us/doc/86/SimMan

[3] M. J. Ackerman, L. P. Burgess, R. Filart,I. Lee, and R. K. Poropatich, BDeveloping nextgeneration telehealth tools and technologies:Patients, systems, and data perspectives,[

Telemedicine and e-Health, vol. 16, no. 1,pp. 93–95, Jan./Feb. 2010.

[4] ASCADVThe Adelard Safety Case Development(ASCAD) Manual, Adelard, 1998.

[5] K. Alexander and P. Clarkson, BGooddesign practice for medical devices andequipmentVPart II: Design for verification,[J. Med. Eng. Technol., vol. 24, no. 2, pp. 53–62,2000.

[6] T. Amnell, E. Fersman, L. Mokrushin,P. Pettersson, and W. Yi, BTIMES: A tool forschedulability analysis and code generationof real-time systems,[ in Proc. 1st Int.

Workshop Formal Modeling Anal. Timed Syst.(FORMATS 2003), 2003, pp. 60–72.

[7] D. Arney, M. Pajic, J. Goldman, I. Lee,R. Mangharam, and O. Sokolsky, BTowardpatient safety in closed-loop medical devicesystems,[ in Proc. 1st Int. Conf. Cyber-PhysicalSyst., Apr. 2010, DOI: 10.1145/1795194.1795214.

[8] D. Arney, K. Venkatasubramanian,O. Sokolsky, and I. Lee, BBiomedicaldevices and systems security,[ in Proc.33rd Annu. Int. Conf. IEEE Eng. Med. Biol.Soc., 2011.

Lee et al.: Challenges and Research Directions in Medical Cyber–Physical Systems

Vol. 100, No. 1, January 2012 | Proceedings of the IEEE 87

[9] U. Becker, BModel-based developmentof medical devices,[ Proc. Workshop Comput.Safety, Reliability, Security (SAFECERT ’09),vol. 5775. Berlin, Germany:Springer-Verlag, 2009, pp. 4–17,ser. Lecture Notes in Computer Science.

[10] G. Behrmann, A. David, and K. Larsen,BA tutorial on UPPAAL,[ Formal Methodsfor the Design of Real-Time Systems(Revised Lectures), vol. 3185.Berlin, Germany: Springer-Verlag, 2004,pp. 200–237, ser. Lecture Notes in ComputerScience.

[11] M. Borowski, M. Gorges, R. Fried, O. Such,C. Wrede, and M. Imhoff, BMedical devicealarms,[ Biomed. Tech., vol. 56, pp. 73–83,2011.

[12] B. P. Kovatchev, M. Breton, C. D. Man, andC. Cobelli, BIn silico preclinical trials: A proofof concept in closed-loop control of type 1diabetes,[ Diabetes Sci. Technol., vol. 3, no. 1,pp. 44–55, 2009.

[13] J. H. Burton, J. D. Harrah, C. A. Germann,and D. C. Dillon, BDoes end-tidal carbondioxide monitoring detect respiratoryevents prior to current sedation monitoringpractices?[ Acad. Emergency Med., vol. 13,pp. 500–504, May 2006.

[14] M.-C. Chambrin, BAlarms in the intensivecare unit: How can the number of falsealarms be reduced?[ Critical Care, vol. 5,pp. 184–188, 2001.

[15] S. Charbonnier and S. Gentil, BA trend-basedalarm system to improve patient monitoringin intensive care units,[ Control Eng. Practice,vol. 15, no. 9, pp. 1039–1050, Sep. 2007.

[16] G. Clifford, W. Long, G. Moody, andP. Szolovits, BRobust parameter extraction fordecision support using multimodal intensivecare data,[ Philosoph. Trans. Roy. Soc. A, Math.Phys. Eng. Sci., vol. 367, pp. 411–429, 2009.

[17] Clinical Alarms Task Force, BImpact ofclinical alarms on patient safety,[ J. Clin. Eng.,vol. 32, no. 1, pp. 22–33, 2007.

[18] D. Bruttomesso, A. Farret, S. Costa,M. C. Marescotti, M. Vettore, A. Avogaro,A. Tiengo, C. Man, J. Place, A. Facchinetti,S. Guerra, L. Magni, G. Nicolao, C. Cobelli,E. Renard, and A. Maran, BClosed-loopartificial pancreas using subcutaneous glucosesensing and insulin delivery and a modelpredictive control algorithm: Preliminarystudies in Padova and Montpellier,[ DiabetesSci. Technol., vol. 3, no. 5, pp. 1014–1021,2009.

[19] T. Denning, K. Fu, and T. Kohno, BAbsencemakes the heart grow fonder: New directionsfor implantable medical device security,[ inProc. 3rd Conf. Hot Topics Security, 2008,pp. 5:1–5:7.

[20] Y. Donchin and F. J. Seagull, BThe hostileenvironment of the intensive care unit,[Current Opinion Critical Care, vol. 8,pp. 316–320, 2002.

[21] J. Edworthy and E. Hellier, BAlarmsand human behaviour: Implications formedical alarms,[ British J. Anaesthesia,vol. 97, pp. 12–17, 2006.

[22] Evidence-Based Medicine WorkingGroup, BEvidence-based medicine.A new approach to teaching the practiceof medicine,[ J. Amer. Med. Assoc.,vol. 268, pp. 2420–2425, 1992.

[23] J. M. Feldman and M. H. Ebrahim,BRobust sensor fusion improves heartrate estimation: Clinical evaluation,[J. Clin. Monitor. Comput., vol. 13,pp. 379–384, 1997.

[24] N. Ferguson, B. Schneier, and T. Kohno,Cryptography Engineering: Design Principles

and Practical Applications. New York:Wiley, 2010.

[25] A. X. Garg, N. K. J. Adhikari, H. McDonald,M. P. Rosas-Arellano, P. J. Devereaux,J. Beyene, J. Sam, and R. B. Haynes, BEffectsof computerized clinical decision supportsystems on practitioner performance andpatient outcomes: A systematic review,[ J.Amer. Med. Assoc., vol. 293, pp. 1223–1238,2005.

[26] J. Goldman, R. Schrenker, J. Jackson, andS. Whitehead, BPlug-and-play in the operatingroom of the future,[ Biomed. Instrum.Technol., vol. 39, no. 3, pp. 194–199,2005.

[27] D. Halperin, T. Heydt-Benjamin, K. Fu,T. Kohno, and W. Maisel, BSecurity andprivacy for implantable medical devices,[Perv. Comput., vol. 7, no. 1, pp. 30–39,Jan.–Mar. 2008.

[28] M. B. Happ, BTreatment interference inacutely and critically ill adults,[ Amer. J.Critical Care, vol. 7, no. 3, pp. 224–235,May 1998.

[29] J. Hatcliff, E. Vasserman, S. Weininger, andJ. Goldman, BAn overview of regulatoryand trust issues for the integrated clinicalenvironment,[ in Proc. 3rd Joint WorkshopHigh Confidence Med. Devices, Software, Syst.Med. Device Plug-and-Play Interoperability(HCMDSS/MDPnP 2011), 2011, pp. 1–10.

[30] R. W. Hicks, V. Sikirica, W. Nelson,J. R. Schein, and D. D. Cousins, BMedicationerrors involving patient-controlled analgesia,[Amer. J. Health-Syst. Pharmacy, vol. 65, no. 5,pp. 429–440, Mar. 2008.

[31] High Confidence Software and SystemsCoordinating Group, BHigh-confidencemedical devices: Cyber-physical systems for21st century health care. A research anddevelopment needs report,[ NCO/NITRD,Feb. 2009.

[32] D. L. Hunt, R. B. Haynes, S. E. Hanna, andK. Smith, BEffects of computerized clinicaldecision support systems on physicianperformance and patient outcomes: Asystematic review,[ J. Amer. Med. Assoc.,vol. 280, pp. 1339–1346, 1998.

[33] M. Imhoff and R. Fried, BThe crying wolf:Still crying?[ Anesthesia Analgesia, vol. 108,no. 5, pp. 1382–1383, 2009.

[34] M. Imhoff and S. Kuhls, BAlarm algorithmsin critical care monitoring,[ AnesthesiaAnalgesia, vol. 102, no. 5, pp. 1525–1536,2006.

[35] M. Imhoff, S. Kuhls, U. Gather, and R. Fried,BSmart alarms from medical devices in the ORand ICU,[ Best Practice Res. Clin. Anaesthesiol.,vol. 23, no. 1, pp. 39–50, 2009.

[36] D. Jackson, M. Thomas, and L. I. Millett, Eds.,BSoftware for dependable systems: Sufficientevidence?[ Committee on CertifiablyDependable Software Systems, NationalResearch Council, National Academies Press,New York, May 2007.

[37] E. Jee, I. Lee, and O. Sokolsky, BAssurancecases in model-driven development of thepacemaker software,[ Proc. Int. Symp.Leveraging Appl. Formal Methods, Verification,Validation (ISoLA 2010), vol. 6416. Berlin,Germany: Springer-Verlag, Oct. 2010,pp. 343–356, ser. Lecture Notes in ComputerScience.

[38] E. Jee, S. Wang, J. K. Kim, J. Lee, O. Sokolsky,and I. Lee, BA safety-assured developmentapproach for real-time software,[ in Proc. 16thIEEE Int. Conf. Embedded Real-Time Comput.Syst. Appl., Aug. 2010, pp. 133–142.

[39] R. P. Jetley and P. L. Jones, BSafetyrequirements based analysis of infusion pump

software,[ Proc. Workshop Softw. Syst. Med.Devices Services, held in conjunction withIEEE Real Time Syst. Symp., Tucson, AZ,pp. 21–24, Dec. 2007.

[40] Z. Jin, J. Oresko, S. Huang, and A. C. Cheng,BHeartToGo: A personalized medicietechnology for cardiovascular diseaseprevention and detection,[ in Proc. IEEE/NIHLife Sci. Syst. Appl. Workshop, 2009,pp. 80–83.

[41] K. E. Anger and P. M. Szumita, BBarriers toglucose control in the intensive care unit,[Pharmacotherapy, vol. 26, no. 2, pp. 214–228,2006.

[42] B. Kim, A. Ayoub, O. Sokolsky, and I. Lee,BThe safety-assured development of theGPCA infusion pump,[ Proc. Int. Conf.Embedded Softw. (EMSOFT 2011), Taipei,Taiwan, Oct. 2011, (To Appear).

[43] A. King, D. Arney, I. Lee, O. Sokolsky,J. Hatcliff, and S. Procter, BPrototypingclosed loop physiologic control with themedical device coordination framework,[ inProc. ICSE Workshop Softw. Eng. Health Care,2010, DOI: 10.1145/1809085.1809086.

[44] A. King, S. Procter, D. Andresen, J. Hatcliff,S. Warren, W. Spees, R. P. Jetley, P. L. Jones,and S. Weininger, BAn open test bed formedical device integration and coordination,[in Proc. Int. Conf. Softw. Eng. CompanionVolume, May 2009, pp. 141–151.

[45] A. L. King, A. Roederer, D. Arney,S. Chen, M. Fortino-Mullen, A. Giannareas,W. Hanson, III, V. Kern, N. Stevens,J. Tannen, A. V. Trevino, S. Park, O. Sokolsky,and I. Lee, BGSA: A framework for rapidprototyping of smart alarm systems,[ inProc. 1st ACM Int. Health Inf. Symp., 2010,pp. 487–491.

[46] L. Magni, D. M. Raimondo, L. Bossi,C. D. Man, G. Nicolao, B. Kovatchev, andC. Cobelli, BModel predictive control oftype 1 diabetes: An in silico trial,[ DiabetesSci. Technol., vol. 1, no. 6, pp. 804–812, 2007.

[47] L. A. Lynn and J. P. Curry, BPatterns ofunexpected in-hospital deaths: A root causeanalysis,[ Patient Safety in Surgery, p. 5, 2011.

[48] J. X. Mazoit, K. Butscher, and K. Samii,BMorphine in postoperative patients:Pharmaco*kinetics and pharmacodynamicsof metabolites,[ Anesthesia Analgesia,vol. 105, no. 1, pp. 70–78, 2007.

[49] M. Mullen-Fortino and N. O’Brien,BCaring for a patient after coronaryartery bypass graft surgery,[ Nursing,vol. 38, no. 3, pp. 46–52, Mar. 2008.

[50] C. Mundt, K. N. Montgomery, U. E. Udoh,V. N. Barker, G. C. Thonier, A. M. Tellier,R. D. Ricks, R. B. Darling, Y. D. Cagle,N. A. Cabrol, S. J. Ruoss, J. L. Swain, J. Hines,and G. T. A. Kovacs, BA multiparameterwearable physiological monitoring systemfor space and terrestrial applications,[ IEEETrans. Inf. Technol. Biomed., vol. 9, no. 3,pp. 382–391, Sep. 2005.

[51] T. K. Nuckols, A. G. Bower, S. M. Paddock,L. H. Hilborne, P. Wallace, J. M. Rothschild,A. Griffin, R. J. Fairbanks, B. Carlson,R. J. Panzer, and R. H. Brook, BProgrammableinfusion pumps in ICUs: An analysis ofcorresponding adverse drug events,[ J. Gen.Internal Med., vol. 23, no. Supplement 1,pp. 41–45, Jan. 2008.

[52] C. Oberli, C. Saez, A. Cipriano, G. Lema, andC. Sacco, BAn expert system for monitoralarm integration,[ J. Clin. Monitor. Comput.,vol. 15, pp. 29–35, 1999.

[53] S. Park, A. Roederer, R. Mani, S. Schmitt,P. D. LeRoux, L. H. Ungar, I. Lee, andS. E. Kasner, BLimitations of threshold-based

Lee et al.: Challenges and Research Directions in Medical Cyber–Physical Systems

88 Proceedings of the IEEE | Vol. 100, No. 1, January 2012

brain oxygen monitoring for seizuredetection,[ Neurocritical Care, Apr. 2011.

[54] R. Hovorka, V. Canonico, L. J. Chassin,U. Haueter, M. Massi-Benedetti, M. Federici,T. R. Pieber, H. C. Schaller, L. Schaupp,T. Vering, and M. E. Wilinska, BNonlinearmodel predictive control of glucoseconcentration in subjects with type 1diabetes,[ Physiol. Meas., vol. 25, no. 4,pp. 905–920, Aug. 2004.

[55] M. D. Rienzo, F. Rizzo, G. Parati,G. Brambilla, M. Ferratini, and P. Castiglioni,BMagic system: A new textile-based wearabledevice for biological signal monitoringapplicability in daily life and clinical setting,[in Proc. 27th Annu. Int. Conf. IEEE Eng. Med.Biol. Soc., 2005, pp. 7167–7169.

[56] J. Rushby, BRuntime certification,[ inRuntime Verification, vol. 5289,M. Leucker, Ed. Berlin, Germany:Springer-Verlag, 2008, pp. 21–35.

[57] D. L. Sackett and W. M. C. Rsenberg, BTheneed for evidence-based medicine,[ J. Roy.Soc. Med., vol. 88, pp. 620–624, 1995.

[58] R. Schoenberg, D. Z. Sands, and C. Safran,BMaking ICU alarms meaningful: A

comparison of traditional vs. trend-basedalgorithms,[ in Proc. Amer. Med. Inf. Assoc.Symp., 1999, pp. 379–383.

[59] E. H. Shortliffe, B. G. Buchanan, andE. A. Feigenbaum, BKnowledge engineeringfor medical decision making: A reviewof computer-based clinical decision aids,[Proc. IEEE, vol. 67, no. 9, pp. 1207–1224,Sep. 1979.

[60] S. Siebig, L. Juhls, M. Imhoff, U. Gather,U. Scholmerich, and C. Wrede,BPlug-and-play for medical devices:Experiences from a case study,[ Crit. CareMed., vol. 38, no. 2, pp. 451–455, 2010.

[61] Pacemaker Formal Methods Challenge,Software Quality Research Laboratory,McMaster University, Hamilton, ON, Canada,accessed Jun. 6, 2011. [Online]. Available:http://sqrl.mcmaster.ca/pacemaker.htm.

[62] M. Sung, C. Marci, and A. Pentland,BWearable feedback systems forrehabilitation,[ J. NeuroEng. Rehabil.,p. 2, Jun. 2005.

[63] U.S. Food and Drug Administration,Center for Devices and Radiological Health,

Infusion Pump Improvement Initiative, WhitePaper, Apr. 2010.

[64] K. Venkatasubramanian, S. K. S. Gupta,R. P. Jetley, and P. L. Jones, BInteroperablemedical devices,[ IEEE Pulse, vol. 1, no. 2,pp. 16–27, Sep./Oct. 2010.

[65] K. J. Vicente, K. Kada-Bekhaled,G. Hillel, A. Cassano, and B. A. Orser,BProgramming errors contribute to deathfrom patient-controlled analgesia: Casereport and estimate of probability,[ Can. J.Anesthesiol., vol. 50, no. 4, pp. 328–332, 2003.

[66] A. Wassyng, T. Maibaum, M. Lawford, andH. Bherer, BSoftware certification: Is therea case against safety-cases,[ Proc.WorkshopModeling, Development, Verification AdaptiveComput. Syst., vol. 6662. Berlin, Germany:Springer-Verlag, Apr. 2010, pp. 206–227,ser. Lecture Notes in Computer Science.

[67] A. Wood, G. Virone, T. Doan, Q. Cao,L. Selavo, Y. Wu, L. Fang, Z. He, S. Lin, andJ. Stankovic, BAlarm-net: Wireless sensornetworks for assisted-living and residentialmonitoring,[ Dept. Comput. Sci., Univ.Virginia, Charlottesville, VA, Tech. Rep.CS-2006-11, 2006.

ABOUT T HE AUTHO RS

Insup Lee (Fellow, IEEE) received the Ph.D. degree

in computer science from the University of

Wisconsin, Madison, in 1983.

He is Cecilia Fitler Moore Professor of Com-

puter and Information Science and Director of

PRECISE Center at the University of Pennsylvania,

Philadelphia. He holds a secondary appointment

in the Department of Electrical and Systems En-

gineering. His research interests include cyber–

phsyical systems, real-time and embedded

systems, runtime assurance and verification, formal methods and tools,

trust management, and high-confidence medical systems.

Dr. Lee received the IEEE TC-RTS Outstanding Technical Achievement

and Leadership Award in 2008.

Oleg Sokolsky (Member, IEEE) received the Ph.D.

degree in computer science from Stony Brook

University, Stony Brook, NY, in 1996.

He is a Research Associate Professor of Com-

puter and Information Science at the University of

Pennsylvania, Philadelphia. His research interests

include the application of formal methods to the

development of cyber–physical systems, architec-

ture modeling and analysis, specification-based

monitoring, as well as software safety certification.

Sanjian Chen (Student Member, IEEE) is currently

working towards the Ph.D. degree in computer

and information science at the University of

Pennsylvania, Philadelphia.

His research interests include modeling, sim-

ulation, and formal analysis of networked cyber–

physical systems, compositional design and

analysis of real-time systems, and real-time vir-

tualization on multiprocessors.

John Hatcliff received the Ph.D. degree in

computer science from Kansas State University,

Manhattan, in 1994.

He is a University Distinguished Professor in

the Computing and Information Sciences Depart-

ment, Kansas State University, Manhattan. His

research interests include medical device integ-

ration and coordination, verification and valida-

tion, certification and regulatory issues for

medical devices, formal methods, and software

engineering.

Eunkyoung Jee (Member, IEEE) received the B.S.,

M.S., and Ph.D. degrees in computer science from

KAIST, Daejeon, Korea, in 1999, 2001, and 2009,

respectively.

She is a Research Assistant Professor in the

Computer Science Department, KAIST. She was a

Postdoctoral Researcher in the Computer and

Information Science Department at the University

of Pennsylvania, Philadelphia. Her research inter-

est includes safety-critical software, software

testing, formal method, and safety analysis.

BaekGyu Kim is currently working towards the

Ph.D. degree in computer science at the University

of Pennsylvania, Philadelphia.

His research interests include modeling and

verification of safety-critical systems, and the

automated implementation of such systems

through formal method. Currently, he is working

on applying safety-assured model-driven engi-

neering to PCA pump implementation as a part of

generic infusion pump project.

Lee et al.: Challenges and Research Directions in Medical Cyber–Physical Systems

Vol. 100, No. 1, January 2012 | Proceedings of the IEEE 89

Andrew King (Student Member, IEEE) received

the B.S. and M.S. degrees in computer science

from Kansas State University, Manhattan, in 2005

and 2009, respectively. He is currently working

towards the Ph.D. degree in computer science

at the University of Pennsylvania, Philadelphia.

His research interests include modeling, veri-

fication, and certification of distributed systems

and software, in particular systems that can be

integrated and reconfigured at runtime.

Margaret Mullen-Fortino is currently working

towards the Ph.D. degree in health policy at the

University of the Sciences, Philadelphia, PA.

She is the Operations Director for Penn e-lert

eICU, the University of Pennsylvania Health Sys-

tem critical care telemedicine program. She is a

nurse clinical consultant on the MCPS project,

offering health care and nursing domain knowl-

edge to enhance medical software development.

Her research interests include informatics and

telemedicine.

Soojin Park received the B.Sc. degree from Brown

University, Providence, RI, in 1997, the M.D.

degree from Drexel University, Philadelphia, PA,

in 2002, the Residency from Boston University,

Boston, MA, in 2006, and the Fellowship from

Massachusetts General Hospital, Boston, MA, in

2008.

She is a Neurointensive Care Physician at the

Hospital of the University of Pennsylvania,

Philadelphia, where she is the Director of Neuro-

critical Care Monitoring and Informatics. She is an Assistant Professor of

Neurology at the Perelman School of Medicine and holds secondary

academic appointments in the Departments of Neurosurgery and

Anesthesiology & Critical Care. Her research interests include the

development of clinical decision support tools for real-time decision

making in the intensive care unit.

Alexander Roederer received the B.S. degree in

computer science and mathematics from the

University of Miami, Miami, FL, in 2009. He is cur-

rently working towards the Ph.D. degree in

computer and information science at the Univer-

sity of Pennsylvania, Philadelphia.

His research interests include the integration

of machine learning methods and cyber–physical

systems to develop medical decision support

systems.

Krishna K. Venkatasubramanian (Member,

IEEE) received the Ph.D. degree in computer

science from Arizona State University, Tempe, in

2009.

He is a Postdoctoral Researcher with the

Department of Computer and Information Science,

University of Pennsylvania, Philadelphia. His re-

search interests include secure cyber–physical

systems, body area networks, trust management,

and medical device security.

Lee et al.: Challenges and Research Directions in Medical Cyber–Physical Systems

90 Proceedings of the IEEE | Vol. 100, No. 1, January 2012