A Model-Based Architecture for Testing MedicalCyber-Physical Systems

Lenardo C. Silva,Mirko Perkusich

Embedded Systems andPervasive Comp. Lab.

Federal University of CampinaGrande

P.O. Box 10.105 – 58.429-900Campina Grande, Brazil

lenardosilva@copin.ufcg.edu.br,mirko.perkusich@copin.ufcg.edu.br

Frederico M. BublitzCenter for Strategic

Technologies in HealthState University of Paraiba

58.429-500Campina Grande, Brazilfredbublitz@uepb.edu.br

Hyggo O. Almeida,Angelo Perkusich

Embedded Systems andPervasive Comp. Lab.

Federal University of CampinaGrande

P.O. Box 10.105 – 58.429-900Campina Grande, Brazilhyggo@dsc.ufcg.edu.br,

perkusic@dee.ufcg.edu.br

ABSTRACTUnderstanding the human body dynamics in response toany medical treatment makes automated decision supportsystems for healthcare quite complex. In this paper, we pre-sent an architecture for Medical Cyber-Physical Systems tohelp developers to generate test cases for their applicationsusing models already validated. It is based on componentmodels to simulate the operation of medical devices and pa-tient data. Medical guidelines and a clinical database havebeen used together with statistical techniques to create re-gression models that simulate vital signs. A controlled expe-riment of a clinical scenario has been developed to validatethe proposed architecture components. The results of thisstudy indicate that models for the healthcare domain are apromising alternative to test their applications.

Categories and Subject DescriptorsH.4 [Information Systems Applications]: Miscellane-ous; D.2.11 [Software Engineering]: Software Architec-tures—Data abstraction, Domain-specific architectures

General TermsDesign, Reliability

KeywordsMedical Cyber-Physical Systems, Architecture, Testing, He-althcare

1. INTRODUCTIONCyber-Physical Systems (CPS) refer to the integration of

computing with physical processes. In CPS, feedback loops

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SAC’14 March 24-28, 2014, Gyeongju, Korea.Copyright 2014 ACM 978-1-4503-2469-4/14/03 ...$15.00.

between physical processes and computing occur. Likewisethe computing interferes in the physical processes [13]. Forinstance, an incubator process control may be automaticallyadjusted based on the environment temperature and humi-dity. In this case, a feedback loop is created to allow thesystem to adapt itself according to the control variables.

The CPS fundamental requirements are security and pre-dictability. Security relates to a guarantee that the impactson the operation remains within desired limits. Predictabi-lity relates to the system ability to act in unexpected con-ditions through self adjustments. For this, it is necessaryto address aspects of time and concurrence [12, 13]. In theearlier mentioned example of the incubator, maintain thecontrol variables within levels suitable for production andreact to power outage to keep the system running throughthe activation of a power generator are key requirements fora successful production process.

When these concepts are applied to the healthcare do-main, applications are classified as Medical Cyber-PhysicalSystems (MCPS) [15]. For example, the human body hasmany feedback-control loops, such as the case in which bloodglucose is regulated by the production of insulin by the pan-creas. Type I diabetes mellitus patients cannot produce in-sulin and must administer insulin shots several times a dayto help regulating their blood glucose level [5]. This mo-tivates the development of insulin delivery systems usingbiological feedback-control loops.

In MCPS, the patient safety is the main concern. Un-derstanding the human body dynamics in response to anymedical treatment is very difficult, making MCPS develop-ment a complex task. With the advent of model-based de-velopment approaches, artifacts and the models themselves,the properties formalized and results of verification and testsmay be used as evidence of the MCPS quality [15].

To allow MCPS developers to test such systems, we pro-pose a model-based approach architecture that provides com-ponents to simulate patients vital signs and emulate medicaldevices for data acquisition and actuation. With these mo-dels, MCPS developers may focus on the specification andmodeling of their applications and their business rules. Suchapplications will be used to integrate the physical processesso that it can be controlled by the computational entities,tested and validated.

The main advantage of the proposed solution is the fle-xibility to be adapted. Also, it ensures the generation ofthe data provided by the models during the simulation toperform tests on the system. Moreover, patients models areformalized by means of statistical techniques applied to cli-nical databases, while medical device models are built inaccordance with actual specifications of devices. Thus, dataprivacy is assured and synthetic populations of patients arestatistically compatible with the reality of the patient groupused as a reference for extraction of their respective models.All models were created using the Ptolemy II (v8.0.1)

framework [21], whose design paradigm adopted is Actor-Oriented Design (AOD) [3], and the clinical database usedfor extraction of information for developing the patient mo-del was MIMIC II Clinical Database v2.6 [20]. To analyzethe feasibility of the proposed solution, a controlled expe-riment of a clinical scenario for continuous monitoring of apatient in intensive care unit was envisioned.The main contributions of this paper are: (1) the propo-

sal of a model-based architecture as alternative for MCPSvalidation; (2) medical device models designed following thedevices specifications; and (3) a patient model representingthe interrelationship between the main vital signs used todetermine the health of a patient. The patient model willserve as a baseline for reuse and adaptation in various clini-cal scenarios.The remainder of the paper is organized as follows. In

Section 2, we present some approaches for MCPS identifiedin the literature. In Section 3, we present an overview of thearchitecture and its components. Lastly, Section 4 presentsa controlled experiment by means of simulation to show themodel applicability and Section 5, the conclusions.

2. RELATED WORKIn the literature, we can find the Integrated Clinical En-

vironment (ICE) conceptual functional model [4]. This isa standard that establishes the requirements for the safeintegration of medical devices and other equipments in amedical system. Its purpose is aiding medical systems tohave greater resistance to errors, improving patient safetyand effectiveness of their treatment.According to Lee et al. (2012) [15] the traditional clinical

scenarios are seen as Closed-Loop Systems in which the care-givers are the controllers, medical devices act as sensors andactuators, and patients are the “physical” plants. As a dis-tinct class of CPS, MCPS modify this vision by introducingadditional computational entities that help the caregiver tocontrol the “plant”, i.e., in the decision support.Some related works that deal with these concepts together

are listed as follows. Lee and Sokolsky (2010) [14] and Pajicet al. (2012) [19] present a clinical scenario for patient-controlled analgesia, which can benefit from the closed-loopapproach to control drug delivery. Both are based on theICE conceptual model.Jiang et al. (2012) [11] provides an environment for tes-

ting closed-loop, whose patient model, specifically a formalmodel of the human heart is the control center of a systemof deployable cardiac pacemaker. The goal is to evaluatethe device operation safety and effectiveness based on thepatient condition.In Miller et al. (2012) [17] an approach of digital mockups

is described as a method for MCPS testing, where thesemodels are used to “stress” such devices by providing input

and analysis of the outputs, enabling the evaluation of theirfunctionalities.

Lastly, Hatcliff et al. (2012) [10] describe a prototype ofthe ICE architecture using the Platform for Medical Applica-tion concept. The idea is to assign meanings to perspectivesof a medical system by means of a CPS.

By analyzing similar works, we notice that they focus onspecific clinical scenarios with models limited to those sce-narios’ components (e.g. device models) and variables of in-terest (e.g. physiological parameters and vital signs). Noneof them contemplate the simultaneous representation of thefour human being’s vital signs: heart and respiratory rates,blood pressure and body temperature. Those that representsome of these signs in patients models do not present evi-dence that the signs are correlated. This opposes the actualbehavior of human beings.

Therefore, there is a need of a more general architecture toaggregate adaptable and reusable components in the deve-lopment of MCPS. In this paper, we propose an architecturecomposed of patient and medical devices models that are in-dependent but integrable to represent clinical scenarios.

3. MCPS ARCHITECTUREThe focus of the architecture proposed in this paper is to

provide reusable components of medical devices and pati-ent types for modeling and simulation of MCPS. Figure 1presents an overview of the proposed architecture. Its com-ponents are described in detail later.

Figure 1: Model-Based Architecture for MCPS.

In general, the application scenarios in MCPS involve theparticipation of caregivers and health professionals with te-chnical skills to assist and treat patients. These are aided bymedical devices with monitoring and actuation capabilities,as well as systems that help such experts in decision making.

Aiming the patient safety, the interaction of computatio-nal entities in an MCPS is performed with a formal modelthat represents the physical dynamics of the patient. Bothin regard to their vital signs and physiological parameters aswell as regarding their reactions by the use of drugs. Thus,

from different sources of clinical data, used in the manage-ment of health information, one can build models of differenttypes of patients, appropriate to an age range and healthconditions. The guarantee of the quality of information pro-vided by these models is ensured by the use of math modelsextracted from statistical techniques, such as regression mo-dels, to generate its signs.The following elements are part of the proposed architec-

ture, according to illustration in Figure 1.

Patient Models: formal models extracted from clinical da-tabases and created based on medical guidelines. Suchpatient models have a direct relationship with the cli-nical database from which they were extracted. There-fore, each patient model is associated with the charac-teristics of the patient medical records. For example,in the simulation presented in the case study, patientsare over 15 years old and are in intensive care units.Patients with other features would produce other re-gression models. Thus, the idea of the architecture isto provide a library of different patient models, onetype for each set of characteristics. As the patient mo-dels actually use mathematical models to simulate thebehavior of the vital signs of human beings, the patientdata privacy is properly protected.

Device Models: formal models built from the technicalspecification of sensor devices and actuators. Exam-ples of such devices include pressure meters, scales,glucometers, and infusion pumps.

MCPS Model (controller): its role is to control the eventsand coordinate the actions of the medical devices, re-presenting the implementation of a MCPS. For this, ituses the patient models and device models to composea MCPS.

To design the architecture components we used the Actor-Oriented Design (AOD) paradigm, i.e., a design methodo-logy based on components called actors [3]. This repre-sents a formalized model of competition, in which an actoris a computational agent that has an independent threadof control and communicate through asynchronous messageexchange. The Ptolemy II (v8.0.1) was the modeling tooladopted to build the models. It is an extensible AOD-based software framework that supports experimentation.Its emphasis is in concurrent components, using computa-tion models that govern the components’ interaction [21].We initially developed two libraries of components for the

proposed architecture, both established from preexisting ac-tors available by Ptolemy II. The first library is composedof medical devices models to simulate the operation of sen-sor devices and actuators, capable of capturing informationabout the health conditions of the patients, and adminis-tering drugs, i.e., to keep the patient in stable condition.The second library represents a patient model that simu-lates the behavior of the human body with regard to theinter-relationship between the four main vital signs of a hu-man being: heart rate, respiratory rate, blood pressure andperipheral body temperature. It is also possible to includeother types of signs, such as physiological. Among these,the blood glucose and blood oxygen saturation levels.

3.1 Medical Devices ModelsThis library is composed of models with actor compositi-

ons. The actors represent medical devices for measurementand actuation. At first it contains a device model for eachvital sign of interest aforementioned, as well as a model fora glucose meter and an insulin pump.

3.1.1 Monitoring DevicesAll models of measurement has an actor of type local clock,

an input port and an output port, as shown in the model ofthe blood pressure meter in Figure 2.

Figure 2: Model of the blood pressure meter.

The local clock (DiscreteClock) must be synchronized withthe MCPS global clock, instantiated at its highest level ofabstraction. With the actor Sampler, it is possible to definethe time interval in which the data should be collected bythe device model. The input port (input) may be used as themedium of interaction between this model and the patientmodel, allowing it to obtain the respective value of the ob-served sign. The output port (BloodPressure) is used as aninterface for communication with the controller componentmodel. The controller is responsible for processing the datacoming from medical devices.

3.1.2 Actuators DevicesAs an actuator devices example, we developed an insu-

lin pump prototype model with two adjustable parameters:cartridge capacity and the activation of the corrective bo-lus’ administration. As shown in Figure 3 the model’s in-puts are: (i) admProfile, insulin administration profile; (ii)baid, basal insulin’s doses; (iii) bold, standard bolus; and (iv)cboid, corrective bolus. These inputs are used to configurethe insulin pump to fit the users’ (i.e. patients) needs. Theoutputs are: (i) insulinPumpStatus, insulin pump’s opera-ting status; (ii) cartridgeStatus, cartridges’s current state ofinsulin level; and (iii) adminsteredDosage, amount of insulinadministered.

Figure 3: Insulin Pump Model.

As shown in Figure 4, the insulin pump model can operatein two modes that are namely stop and executing. Both theoperation modes have the same state refinement, but thevalues of the state variables used in the guard transitionsdetermine the change of modes. We omitted the designedstate refinement’s sub-model due to its complexity.

Figure 4: Insulin Pump Model’s Controller.

Two insulin administration strategies were implementedin the insulin pump model: fixed dose insulin therapy andflexible dose insulin therapy. Fixed dose insulin therapy(standard basal rate) is suitable for patients whose insu-lin dosage are kept fixed because of the regimen based onthe amount of carbohydrate should be consumed throughoutthe day. Flexible dose insulin therapy (specific basal rate)refers to adjusted rates of insulin injection according to thetime of the day [1]. Furthermore, we modeled the procedu-res used for the injection of standard bolus and correctivebolus doses.The models contained in this library were developed accor-

ding to their respective specifications, such models behaveas discrete-event systems. Therefore, the medical devicesmodels represent the cyber world elements.Notice that these actuators models were conceived using

the Modal Model concept which consists of one operationmode for each state of a Finite State Machine (FSM). Thedynamics of a FSM may be specified by a state refinement,which defines the behavior of the system in that mode [13].

3.2 Patient ModelThe vital signs and physiological parameters provided by

the patient model are based on thresholds using regressionmodels to generate them. The parameters that define thethresholds were established in accordance with the ClinicalGuidelines [2, 7, 9, 16, 18]. For this, we also applied somerules on the results of the descriptive statistics of samplesobtained from the MIMIC II Clinical Database v2.6 [20].The same database was used to characterize a population

of individuals, from which it was possible to apply inferen-tial statistical techniques such as generalized linear model(GLM) to obtain regression models for the prediction of theobserved signs to be incorporated in the patient model. Thepopulation contains 38.141 observations relating to 2.245 pa-tients, with approximately 37.4% of the female gender and62.6% of the male gender. From this population, a samplewas obtained with one observation of each patient in themoment that it was admitted in the hospital.Eight variables were selected for the statistical analysis.

These include gender, weight and height as demographic va-riables, heart rate (hr), respiratory rate (rr), systolic bloodpressure (sbp), peripheral body temperature (pt), which re-

late to vital signs, and blood glucose level (gl), as physiologi-cal parameter. It is also important to notice that the sign ofdiastolic blood pressure (dbp) was not used in this analysisbecause it depends on sbp variable. The strong correlationbetween these variables may cause a multicollinearity pro-blem [8]. Thus, we obtained four regression models, one foreach vital sign in study. The details were omitted since it isnot the focus of this paper.

Figure 5 illustrates the model elaborated for incorporatingthe patient characteristics achieved from the implementationof the steps reported. The model parameters are the basisfor generating the values for the vital signs and physiologi-cal parameters provided by the patient model. Moreover,the specifications of the thresholds of each vital sign allowsthe developer to manipulate them during the simulation, torepresent different health conditions for the patient model.Consequently, the behavior analysis of the MCPS is carriedout for various situations.

Notice that for the patient model shown in Figure 5 thereis only the adjusted inverse normal regression model to pre-dict the respiratory rate sign. The regression model uses thecanonical link function described in Equation 1 and 2:

µ = η− 12 (1)

where µ is the mean frequency of respiratory rate which wewant to model and

η = β0 +

4∑i=1

βiXi +

4∑j=2

β5jX5j +

7∑k=6

βkXk (2)

is the systematic component, in which the Equation 2 cor-respond to the coefficients of the intercept and the variablesheart rate (hr), systolic blood pressure (sbp), body tempe-rature (bt), blood glucose level (gl) and group, as well as theinteractions between hr ∗ sbp and hr ∗ gl, respectively. Thegroup variable is used according to the patient classification,given the values of the other predictor variables. Therefore,the X5j variable assumes the value 1 according to the j va-lue that specifies the patient group, and the value 0 for allother possible j values.

The remaining regression models were not incorporatedinto this patient model. The goal of this simplification isto improve the understanding of the model. The way ofintegrating other regression models to the patient model isto create feedback loops among all models. This will enablethe user to change the value of a particular variable andautomatically the values of other variables in the model willalso be modified as the respective regression models.

The patient model also has only output ports for each vi-tal sign and physiological parameter modeled. To be ableto receive the feedback control actions by actuator models,input ports must be added to the patient model and adaptit to embed the pharmacokinetic model1 corresponding tothe drug type to be administered. In addition, the pati-ent models adopt the continuous-time semantics to betterrepresent the physical world.

4. CONTROLLED EXPERIMENTIn this section, we demonstrate how the components de-

veloped for the proposed architecture were validated. For1Pharmacokinetic models describe the time course of observed drug

concentrations within the body [6].

Figure 5: Patient model with regression model for respiratory rate.

this purpose, a clinical scenario was envisioned and will bepresented in this case study.The scenario describes the situation in which patients stay

in intensive care unit (ICU) in a hospital and continuousmonitoring is required to record vital signs, as depicted inFigure 6. Such information is used to assess the patienthealth conditions during the treatment period.

Figure 6: Clinical scenario of a patient in ICU.

To design the model for the clinical scenario described ear-lier, we instantiated, using drag-and-drop actions, the mo-dels developed for MCPS architecture using actors (autono-mous components). These actors were incorporated into thecomponent library of Ptolemy II.The monitoring devices actors are connected to the pa-

tient actor via ports, allowing capturing the data provided

by this model. To allow the communication between medi-cal devices and MCPS, an actor for a centralizer device wasbuilt, whose model is illustrated in Figure 7.

Figure 7: Model of the centralizer device.

One communication channel in the centralizer device wasdefined for each monitoring device. The centralizer job is toreceive the medical devices data through wireless interfaces,and make them available to the MCPS controller model.

The results obtained from combined efforts to integratethe medical devices models and the patient model in thiscase study suggests that a model-based architecture is a pro-mising solution to generate test cases to validate MCPS.

An advantage of the proposed solution is that it allowsto perform simulation with the instantiation of several pati-ents simultaneously running. This allows adding scalabilityfeatures and generating inputs for testing a MCPS. Further-more, the procedure applied to design the patient modelallows creating different patient model types, using as basisfor different clinical data sources available in the literature,

despite the difficulties for accessing them. Furthermore, thedeveloped models use reusable, adaptable and replaceablecomponents, providing versatility to the solution.

5. CONCLUSIONIn this paper, we presented a model-based architecture for

validating Medical Cyber-Physical Systems. The proposedarchitecture includes components that represent models formedical devices and a patient model.To verify the behavior of components designed for the

proposed architecture, a controlled experiment that allowedanalyzing the interaction among them was performed. Con-sidering that, in MCPS, the patient safety is the main con-cern, the experiment results demonstrated that the proposedsolution can provide enough information to perform tests inthese systems.One of the most important aspects related to the use of

the proposed architecture is that developers can test theirapplications MCPS without the risk of compromising thesecurity of actual patients. Also, the data privacy is main-tained, while keeping the generated data statistically com-patible with real data.As future works, to reduce the MCPS developers effort, we

intend to expand the proposed architecture library compo-nents with other medical devices models. Furthermore, weplan to develop case studies to cover how to extend the pa-tient model and to close the MCPS feedback-control loop byintegrating the models designed for the proposed architec-ture. Finally, we intend to define checkable formal propertiesfor the architecture’s components.

AcknowledgmentsThis research was supported by the “Coordenacao de Aper-feicoamento de Pessoal de Nıvel Superior (CAPES)” andCenter for Strategic Technologies in Health (NUTES) at theState University of Paraiba (UEPB) – Brazil.

6. REFERENCES[1] ACCU-CHEK. ACCU-CHEK Spirit Insulin Pump

System: Pump User Guide. ACCU-CHEKR⃝ (Roche),May. 2008.

[2] ADA. Diagnosis and classification of diabetes mellitus.Diabetes Care, 27(1):s5–s10, Jan. 2004. AmericanDiabetes Association (ADA).

[3] G. Agha. Actors: a model of concurrent computationin distributed systems. MIT Press, Cambridge, MA,USA, 1986.

[4] ASTM International. STAM F2761–2009. MedicalDevices and Medical Systems – Essential SafetyRequirements for Equipment Comprising thePatient-Centric Integrated Clinical Environment(ICE), Part 1: General Requirements and ConceptualModel, 2009.

[5] B. W. Bequette, editor. Process control: modeling,design, and simulation. Prentice Hall, 2003.

[6] M. Bewernitz and H. Derendorf.Electroencephalogram-based pharmacodynamicmeasures: a review. Int J Clin Pharmacol Ther,50(3):162–184, Mar. 2012.

[7] A. E. Buxton, H. Calkins, D. J. Callans, J. P.DiMarco, et al. ACC/AHA/HRS 2006 Key Data

Elements and Definitions for ElectrophysiologicalStudies and Procedures: A Report of the AmericanCollege of Cardiology/American Heart AssociationTask Force on Clinical Data Standards. J Am CollCardiol., 48(11):2360–2396, Dec. 2006.

[8] B. Gavish., I. Z. Ben-Dov, and M. Bursztyn. Linearrelationship between systolic and diastolic bloodpressure monitored over 24 h: assessment andcorrelates. J Hypertens., 26(2):199–209, 2008.

[9] Y. Handelsman, J. Mechanick, L. Blonde,G. Grunberger, et al. American association of clinicalendocrinologists medical guidelines for clinical practicefor developing a diabetes mellitus comprehensive careplan: Executive summary. Endocrine Practice,17(2):287–302, Mar. 2011. American Association ofClinical Endocrinologists (AACE).

[10] J. Hatcliff, A. King, I. Lee, A. Macdonald, et al.Rationale and architecture principles for medicalapplication platforms. In Proceedings of the 2012IEEE/ACM Third International Conference onCyber-Physical Systems, ICCPS ’12, pages 3–12,Washington, DC, USA, 2012. IEEE Computer Society.

[11] Z. Jiang, M. Pajic, and R. Mangharam.Cyber-physical modeling of implantable cardiacmedical devices. Proceedings of the IEEE,100(1):122–137, 2012.

[12] E. A. Lee. Cyber physical systems: Design challenges.In Proceedings of the 2008 11th IEEE Symposium onObject Oriented Real-Time Distributed Computing,ISORC ’08, pages 363–369, Washington, DC, USA,2008. IEEE Computer Society.

[13] E. A. Lee and S. A. Seshia. Introduction to EmbeddedSystems, A Cyber-Physical Systems Approach. 2011.ISBN 978-0-557-70857-4.

[14] I. Lee and O. Sokolsky. Medical cyber physicalsystems. In Design Automation Conference (DAC),2010 47th ACM/IEEE, pages 743–748, 2010.

[15] I. Lee, O. Sokolsky, S. Chen, J. Hatcliff, et al.Challenges and research directions in medicalcyber-physical systems. Proceedings of the IEEE,100(1):75–90, 2012.

[16] S. R. McGee. Evidence-based physical diagnosis,chapter Respiratory Rate and Abnormal BreathingPatterns, pages 187–202. Saunders Elsevier, St. Louis,2 edition, 2007.

[17] B. Miller, F. Vahid, and T. Givargis. Digital mockupsfor the testing of a medical ventilator. In Proceedingsof the 2nd ACM SIGHIT International HealthInformatics Symposium, IHI ’12, pages 859–862, NewYork, NY, USA, 2012. ACM.

[18] NHBPEP. The fourth report on the diagnosis,evaluation, and treatment of high blood pressure inchildren and adolescents. Pediatrics, 114(Supplement2):555–576, 2004.

[19] M. Pajic, R. Mangharam, O. Sokolsky, D. Arney,J. Goldman, and I. Lee. Model-driven safety analysisof closed-loop medical systems, 2012.

[20] PHYSIONET. MIMIC II Databases.<http://physionet.org/mimic2>., Oct. 2012.

[21] UC Berkeley. The ptolemy project: heterogeneous,modeling and design, 2012.