Using PVSio-web and SAPERE for rapid prototyping ofuser interfaces in Integrated Clinical Environments

Paolo Masci∗

Queen Mary Univ. of London,United Kingdom

p.m.masci@qmul.ac.uk

Piergiuseppe MallozziUniversity of Pisa, Italy

piergiuseppe.mallozzi@gmail.com

Francesco LucaDe Angelis

University of Geneva, ISSCarouge, Switzerland

francesco.deangelis@unige.chGiovanna Di Marzo

SerugendoUniversity of Geneva, ISS

Carouge, Switzerlandgiovanna.dimarzo@unige.ch

Paul CurzonQueen Mary Univ. of London

United Kingdomp.curzon@qmul.ac.uk

ABSTRACTIntegrated clinical environments (ICEs) consist of interop-erable medical devices that seamlessly exchange data andcommands to create safety interlocks and closed loop con-trols to improve the quality of care delivered to the patient.Currently at the prototype stage, they promise to form thebasis of a new generation of healthcare systems for highacuity patients. Regulators such as the US Food and DrugAdministration are promoting the development of tools andtechniques for verification and validation of essential safetyrequirements for ICEs. To date, little research has focusedon the certification and assurance of their user interfaceswith respect to use errors. In this work, we demonstrate howthe PVSio-web prototyping tool can be conveniently used incombination with the communication framework SAPEREto generate realistic ICE systems prototypes from formalmodels. This approach is particularly suitable for exploringrequirements, design, and regulatory issues of usability andsafety of the user interfaces of ICE systems. An exampleICE system prototype is presented, along with an exampleanalysis demonstrating how the prototype can be used toexplore subtle user interface design issues that could lead tousability and safety hazards in clinical scenarios.

KeywordsInteroperable medical devices, Prototyping toolchain, For-mal methods technologies

∗Corresponding author.

1. INTRODUCTIONModern medical devices have communication capabilitiesthat can be exploited to improve the safety and effectivenessof the overall medical system. For example, consider a clini-cal situation where an infusion pump is infusing a painkiller,such as morphine, into the bloodstream of a critically ill pa-tient. If a monitoring device is connected to the patient,then the monitor could interoperate with the pump to stopthe infusion when the onset of a respiratory depression isdetected, thus saving the patient’s life.

The benefits of interoperable medical devices are clear. How-ever, careful design decisions need to be taken to ensuresafety of operation. For example, in the previous example,what happens if the patient monitor is accidentally mis-configured, operated incorrectly, or malfunctioning? Is itsafe to substitute one interoperable patient monitor withanother interoperable monitor in the middle of a clinical sit-uation? It is certainly desirable to have assurance that theinfusion pump would operate as safely as in a case wherethe pump is not exchanging data and commands with thepatient monitor.

Regulators such as the US Food and Drug Administration(FDA) are promoting the development of experimental plat-forms to facilitate the analysis of requirements and architec-tures for interoperable medical devices. A platform thatis currently gaining traction is the Integrated Clinical En-vironment (ICE) [4]. It is a prototypical model of the nextgeneration medical system for high acuity patients. The con-ceptual architecture of the ICE prototype (adapted from [4])is shown in Figure 1. It includes the following main types oftechnological elements.

I ICE-compatible medical devices: medical devices capableof sending and receiving application data and commandsusing an ICE Network Interface. The ICE Network Inter-face can be either incorporated in the medical device, or beexternal to it.

I An ICE Network Controller, which creates the necessarycommunication infrastructure to enable application-level in-

Figure 1: ICE architecture (adapted from [4]).

teroperability among ICE-compatible equipment.

I An ICE Supervisor, which defines the application logicto orchestrate and combine ICE-compatible medical devicesin a safe manner. Example application logic elements in-clude: safety interlocks, closed-loop controls, and integra-tion of alarm conditions.

I An ICE Data Logger, which timestamps and logs data forretrospective analysis of incidents, near-misses, and perfor-mance figures.

I An ICE External Interface, which connects ICE withother networks, e.g., the hospital’s healthcare facility net-works, or the Internet.

I An ICE Manager, which groups together the four coreelements of the ICE architecture: ICE Supervisor, ICE Net-work Controller, ICE Data Logger and ICE External Inter-face.

To date, little research has focused on the certification andassurance of the user interfaces of ICE systems with respectto use errors. In the present work, we start to address thisgap.

Contribution. We introduce a modelling and analysistoolchain for exploring requirements, design, and regula-tory issues related to the usability and safety of ICE sys-tems user interfaces. The toolchain is based on the PVSio-web [10, 15] prototyping tool, and the communication frame-work SAPERE [1]. It allows developers to generate realisticinteractive prototypes of both ICE-compatible medical de-vices and of the ICE supervisor, and link them togetherusing real communication networks. It uses a model-basedapproach centred on formal methods technologies. An il-lustrative example is presented where the toolchain is usedto develop an ICE system prototype based on commercialmedical devices. An example analysis is also presented todemonstrate how prototypes generated with the toolchaincan be used to explore subtle issues in the design of ICEuser interfaces.

Organisation. The rest of the paper is organised as fol-lows. In Section 2, related work on tools for modelling andanalysis of ICE systems is compared and contrasted to ourwork. In Section 3, PVSio-web and SAPERE are intro-duced, as they are the pillars of our toolchain. Then, themain contributions of our work are presented: our toolchainfor prototyping ICE systems (in Section 4); an example useof our toolchain for rapid prototyping a realistic ICE sys-tem based on commercial medical devices (in Section 5); anexample analysis based on the developed prototype is thenpresented (in Section 6). Finally, Section 7 presents con-cluding remarks and future work.

2. RELATED WORKSeveral research groups have focused on developing testbedsand physical prototypes of ICE systems. The MassachusettsGeneral Hospital MD PnP Lab (www.mdpnp.org), for ex-ample, has developed an ICE testbed to facilitate multi-disciplinary discussion about safety and performance of ICEsystems. In their testbed, they use modified versions of com-mercial medical devices. Similarly, other two research labs— the Precise Research Center (precise.seas.upenn.edu) andSantos Lab (santoslab.org — developed a Java-based pro-gramming environment [7, 17] and a testbed [6] for explor-ing performance requirements and interoperability of dataformats in ICE systems. These approaches are excellent fordemonstrating the technical feasibility of ICE systems, butlack the flexibility needed for systematic exploration of dif-ferent configurations and clinical scenarios. From this per-spective, our toolchain complements their effort well: it fo-cuses on user interfaces, rather than performance and dataformats; it provides a faster and cheaper approach for rapidprototyping with respect to developing physical prototypes;and it enables the use of advanced formal methods technolo-gies (e.g., theorem proving) for the analysis of the businesslogic of the system in addition to testing-based approaches.Also, as will be explained, prototypes developed with ourtoolchain can be used within their testbeds, as our proto-types can use real communication networks to exchange dataand commands with other prototypes and devices connectedto that network.

Other research has focused on requirements for ICE sys-tems. For example, in [19] and [8], high level requirementsare discussed that can be used to assess the safety and effec-tiveness of the ICE system. In [18], a systematic approachis also presented identifying system requirements that canmitigate identified hazards. Our work also complements thisstrand of research well, as prototypes developed with ourtoolchain facilitate multidisciplinary discussion between en-gineers and domain experts for identifying and validatingsystem requirements. Furthermore, our toolchain gives atestbed with which to demonstrate how a variety of for-mal tools can be usefully used to formalise and verify ICErequirements. It can also be used to explore the differentkinds of assurance arguments that can be supported by averification effort. This can be based on concrete examplesdeveloped within the toolchain.

3. BACKGROUNDOur toolchain for model-based generation of ICE systemsprototypes is based on the prototyping tool PVSio-web [10,15] and the communication framework SAPERE [1]. In this

Figure 2: Snapshot of the PVSio-web environment while creating an interactive device prototype, in thiscase an infusion pump used in healthcare to infuse medications or nutrients to patients. Framed boxes of thepicture highlight the interactive parts of the prototype.

section, we therefore introduce these two technologies, andillustrate the main functionalities that we have used in ourtoolchain.

3.1 PVSio-webPVSio-web is a new research tool for modelling, prototyping,and analysis of interactive systems. It is based on the in-dustrial strength formal verification system, PVS [16], whichprovides sophisticated proof, animation, and modelling en-vironment. PVSio-web provides a graphical environmentfor creating realistic stand-alone prototypes based on un-derlying executable formal models (see Figure 2). To in-teract with a PVSio-web prototype, developers click but-tons on the prototype’s user interface, and watch the re-sults of the interactions in real time on its displays. Un-derneath the graphical environment, PVSio-web uses thePVSio [14] component of PVS for model animation. Thetool is particularly suitable for: validating system speci-fications and requirements before starting the verificationprocess; demonstrating formal analysis results to engineersand domain experts in a way that is easy to understand;and enabling lightweight formal analysis based on user cen-tered design methods, such as user testing and expert walk-throughs of prototypes. PVSio-web has been successfullyused to demonstrate previously undetected design flaws inmedical devices [12], and to explore the causal relationshipsbetween user interface design issues and software defects [9].Additional information about how prototypes are generatedusing PVSio-web are presented as needed in Section 5, whileillustrating the development of the ICE system prototype.

3.2 SAPERESAPERE [1] is a communication and coordination frame-work for heterogeneous networked systems. It provides acommon platform to build distributed multi-agent perva-sive systems, and offers automated functionalities for dataexchange and aggregation of heterogeneous services, appli-cations and sensors. The exposed interface infrastructuresupports dynamic discovery of devices and services, as wellas sophisticated nature-inspired aggregation algorithms fordistributed processing of data. The framework has beensuccessfully used to engineer multi-agent systems in the con-text of pervasive scenarios [20], and supports a developmentmethodology that facilitates reusability and composabilityof services in pervasive systems [3].

The SAPERE coordination model is composed of the fol-lowing components.

I Live Semantic Annotations (LSAs): active tuplescomposed of one or several properties of type (name, value)encapsulating information about entities taking part in co-ordination processes. LSAs can interact with each other;such process is guided by predefined laws named Eco-Laws.

I LSA Space: container of shared LSAs hosted in a singlenetwork node. Inside an LSA Space, reactions among LSAsare spontaneously fired by Eco-laws.

I Agents: active entities that coordinate the communica-tion processes between external components (services, sen-

LSA SpaceEco-laws

Bonding Aggregate DiffusionDecay

Service

Agent

Sensor

AgentAgent

Application

LSA

LSA

LSA LSA

LSA

Figure 3: SAPERE coordination model

sors, applications, etc.) and the LSA Space. Each agent isbound to one LSA, and implements the logic for managingnotification of events triggered when the LSA interacts withother LSAs of the same LSA Space.

I Eco-laws: active entities implementing four basic bio-inspired mechanisms that enforce interactions among LSAs.Eco-laws are executed periodically at a specific rate, tunableby the system administrator. In the developed toolchain, weuse the following Eco-laws:

(i) Bonding : instant relationships among LSAs. A bondis a unidirectional link created between an LSA A con-taining a property of type (name x, ∗) or (name x, ?)and a second LSA B containing a property (name x,value x). Once the bond is created, the agent associ-ated with A can read and monitor changes to the valuevalue x of the property in B. Such mechanism repre-sents the main modality to share information amongagents. Values ∗ and ? are named operators and theyallow for the creation respectively of one or severalbounds at the same time.Example: Given LSAs A = [(temperature, ?)] andB = [(temperature, 15)], a bond will be created be-tween A and B because of the property (temperature, ?).Through this bond, the agent associated with A willbe able to read the property (temperature, 15).

(ii) Decay : reduction of information relevance. This mech-anism automatically updates an LSA containing a prop-erty (decay, n) by decreasing the numeric property valuen by one unit at every execution of the Eco-law. Oncen = 0, the whole LSA is removed from the space.Example: the LSA [(temperature, 15), (decay, 10)] willbe deleted from the LSA Space after 10 executions ofthe decay Eco-law.

Eco-laws generate notifications to keep agents updated re-spect to the changes applied to their tuples. Several morecomplex bio-inspired mechanisms (e.g. gradient, chemotaxis,

quorum sensing,...) can be obtained by opportunely com-bining four basic Eco-laws (bonding, decay, aggregate, anddiffusion) provided by SAPERE.

4. OUR TOOLCHAINWe now introduce our modelling and analysis toolchain forexploring requirements, design, and regulatory issues relatedto the usability and safety of ICE systems user interfaces.The PVSio-web prototyping tool is used to generate real-istic interactive prototypes of both ICE-compatible medi-cal devices and of the ICE supervisor. The communicationservices provided by SAPERE are used to enable exchangeof data and commands between prototypes developed us-ing PVSio-web. To enable the combined use of PVSio-weband SAPERE, we have developed a new PVSio-web exten-sion, the PVSio-web Network Controller. This new exten-sion installs virtual communication ports on the PVSio-webprototypes, and allows developers to “plug in” PVSio-webprototypes in to real communication networks to discoverdevices connected to the network, and exchange data andcommands with them.

Our toolchain based on PVSio-web and SAPERE thereforeleads to ICE system prototypes that include the followingelements (see Figure 4):

I A PVSio-web prototype for the ICE Supervisor.A PVS model defines the internal logic of the supervisor andthe behaviour of the supervisor’s user interface. A picture ofthe supervisor’s user interface defines the visual appearanceof the prototype.

I A PVSio-web prototype for each ICE-CompatibleMedical Device in the system. A PVS model definesthe interactive behaviour of each device. A picture of thedevice user interface defines the visual appearance of eachprototype.

I A PVSio-web Network Controller to enable real-time exchange of data and commands between the PVSio-

Figure 4: Logic architecture of the ICE system prototype generated using PVSio-web and SAPERE. Boxesin the picture represent functional modules (black boxes identify new PVSio-web extensions developed tosupport interoperability between prototypes). Arrows between modules represent flow of commands/data.

web prototypes during simulation. The PVSio-web NetworkController uses an instance of SAPERE to implement thecommunication service.

4.1 The PVSio-web Network ControllerThe PVSio-web Network Controller uses SAPERE to mimica publish-subscribe communication protocol. That is, eachPVSio-web prototype includes a Network Controller Agentthat can publish messages for the PVSio-web prototype, andreceive messages published by other PVSio-web prototypesconnected to the same network. To do this, each NetworkController Agent includes a cluster of SAPERE agents (seeFigure 4). Agents in the cluster implement different func-tions: one agent (PublishAgent) is for publishing messages;and one or more agents (SubscribeAgents) are used for re-ceiving messages published by other PVSio-web prototypesthrough their PublishAgent.

The developed PVSio-web Network Controller has a graph-ical user interface to monitor and control the status of thenetwork. A snapshot of the Network Controller user inter-face is in Figure 6. It shows a scenario with three PVSio-webprototypes (represented as labelled boxes with control but-tons disconnect/remove) are connected to the network andexchange messages. One prototype acts as (ICE) supervi-sor, whilst the other two act as (ICE-compatible) medicaldevices. In the snapshot, SAPERE agents are representedas circles. Lines connecting circles represent flow of messagesand commands between prototypes. Note that, in Figure 6,the supervisor prototype has two SubscribeAgents becauseit is designed to receive data published by two device pro-totypes connected to the network. The device prototypes,on the other hand, have just one SubscribeAgent, as theyare designed to receive data only from the supervisor in thiscase.

5. EXAMPLEIn this section, we use our toolchain based on PVSio-web andSAPERE to develop an ICE system prototype. The aim ofthis example is to demonstrate that our toolchain facilitatesthe rapid generation of realistic ICE system prototypes suit-

able to explore usability- and safety-related aspects of ICEuser interfaces. This is especially useful at the early stagesof the development lifecycle of these systems, when physicalprototypes of ICE-compatible devices and the ICE infras-tructure are not readily available, as well as when a fullspecification of the system is still under development.

In the following, we first present a description of the func-tionalities of our example ICE system. Then, we illustratethe steps followed to generate a realistic ICE system proto-type using our toolchain. Then, in Section 6, we discuss thetypes of analysis that can be carried out with the prototype,and illustrate an example analysis that reveals subtle gapsin the interactive behaviour of the system that could lead tousability and safety issues.

5.1 Description of the ICE systemThe considered ICE system is based on one of the represen-tative ICE clinical scenarios illustrated in [4] and [19]. Itincludes two types of medical devices: a patient controlledanalgesia (PCA) pump, which delivers a continuous infu-sion of a pain killer (morphine) into the bloodstream of acritically ill patient; and a patient monitor, which continu-ously measures the patient’s condition by checking her/hisrespiratory rate and blood oxygen saturation level. The ICEsupervisor implements a safety interlock application that au-tomatically stops the infusion when the patient’s monitoredparameters indicate the onset of a respiratory depression.

5.2 Infusion pump prototypeThe infusion pump prototype is based on a commercial med-ical product [2]. The device has a user interface with a dis-play and buttons for setting up the infusion parameters andcontrol the delivery of the therapy. A blueprint of the deviceuser interface is shown in Figure 7(a). It includes:

I A display, capable of rendering the current pump mode,the infusion parameters programmed in the pump; and la-bels for three programmable function keys;

I Two pairs of chevron keys for editing infusion parameters

Figure 5: Architecture of the PVSio-web Network Controller.

and selecting menu items;

I A bolus button, to trigger the delivery of bolus doses;

I A pause button, to pause the infusion;

I A power button, to power the pump on and off

The device has three main modes of operation: infusing,where the pump is infusing; on hold, where the infusion ispaused; and alarm, where the pump signals situations thatneed to be solved by a human operator, e.g., occlusion ofthe infusion line. Setting up the infusion involves interactingwith the pump user interface to configure two main param-eters: infusion rate, and volume to be infused. Once theseparameters are set, the infusion can be started. Infusion pa-rameters can be changed while the infusion is running, e.g.,to adjust the therapy to changed patient conditions. A de-tailed description and analysis of the user interface designof this device is in [11, 15, 5].

Developing the prototype. Using PVSio-web, we gen-erated an interactive prototype of the device using an exe-cutable PVS model of the device and a picture of the realdevice (see Figure 7(b)). That is, we loaded a picture ofthe real device in our PVSio-web prototyping environment,created interactive areas over buttons and displays of thepicture, and linked them with the PVS model of the device.Namely, user actions over buttons in the picture are asso-ciated with state transition functions defined in the PVSmodel. These functions take the current state of the modelas argument, and return the next model state as result ofthe function evaluation. For example, click actions over therun button are associated with a function click_run de-fined in the PVS model. Therefore, every time the run but-ton is clicked by the user, PVSio-web automatically triggers

the evaluation of function click_run over the current modelstate. The next model state is thus obtained, and renderedusing the displays of the prototype. For display elements, in-teractive areas are created over the device displays and LEDlights, and associated with corresponding fields in the PVSmodel state. Complex display elements that render mul-tiple information are segmented into simpler sub-displays.For example, the device display includes a topline, which isassociated with a field topline defined in the state of thePVS model, and 4 additional sub-displays, each renderinga different infusion parameter (in this case, infusion rate,volume to be infused, volume infused, and remaining time).The PVS model used for the prototype includes informationabout which sub-display is visible in which device mode.This information is used by PVSio-web to dynamically re-veal and conceal sub-displays of the prototype, and thusclosely resemble the visual look and feel of the real device indifferent screens.

5.3 Patient monitor prototypeThe patient monitor prototype is based on a commercialmedical product [13]. The device has a touchscreen userinterface, and a mechanical button to power on and off themonitor. A blueprint of the user interface of the device isshown in Figure 8(a). It includes:

I A touchscreen display for rendering the patient’s vitalsigns, and to setup alarm thresholds. Here, we consider twovital signs, as indicated in the clinical scenarios describedin [4] and [19]: the patient’s blood oxygen saturation level(SpO2), and the respiratory rate (RRa).

I A power button, to power on and off the patient monitor.

The device has two main modes of operation: monitoring,and alarming. When in monitoring mode, the device renders

Figure 6: User interface for accessing the functionalities of the PVSio-web Network Controller. Snapshot ofan ongoing simulation. Circles represent SubscribeAgents or PublishAgent. Lines between circles representflow of information between agents.

the current values of SpO2 and RRa, the recent history ofmeasured values, and the alarm levels. When alarming, ablinking alarm icon is rendered next to the current valueof the patient’s vital sign that is generating the alarm. Bydefault, the device is in monitoring mode. The device modechanges into alarming when the current value of at least oneof the monitored vital signs exceeds given alarm thresholdspre-set by the operator (typically, a nurse).

Developing the prototype. Using PVSio-web, we gener-ated an interactive prototype of the device (see Figure 8(b)).As for the infusion pump prototype, we then loaded a pic-ture of the real device in PVSio-web, and created interactiveareas over buttons and displays to link them to the PVSmodel of the device. Button clicks on the power button arethus associated with a function click_onOff defined in thePVS model. Two display elements were created, one foreach monitored vital sign. Each display element is furthersegmented into five sub-displays: three sub-displays rendernumerical data (current value, and maximum and minimumalarm levels); another sub-display renders alarms (in thiscase, an alarm icon); and one additional sub-display rendershistorical values (tracings displays).

5.4 ICE supervisorThe blueprint of an ICE supervisor user interface is shownin Figure 9(a). It includes:

I A touchscreen display for rendering the infusion pumpstatus.

I A touchscreen display for rendering the status of the pa-tient monitor.

I A power button, to power the ICE supervisor on and off.

By default, the ICE supervisor user interface renders thesame information shown on the main screens of the medi-cal devices connected to the system. For the patient moni-tor, the ICE display therefore presents the current value ofthe measured SpO2 and respiratory rate, the alarm levels,and the recent history of measurements. For the infusionpump, the ICE display shows the infusion parameters (infu-sion rate, volume to be infused, volume infused, and remain-ing time), and the current pump status (on hold, infusing,etc.). Additionally, the ICE user interface allows operatorsto view historical data of infusion parameters. This func-tion can be accessed with a touch gesture on the infusionparameters rendered on the prototype display.

(a) Blueprint of the AlarisGP pump, identifying the mainelements of the user interface.

(b) PVSio-web prototype of the AlarisGP pump. The figureshows a snapshot of the prototype executed within PVSio-web.

Figure 7: ICE-compatible infusion pump prototype based on the Alaris GP pump.

(a) Blueprint of the Radical7 patient monitor, iden-tifying the main elements of the user interface.

(b) PVSio-web prototype of the Radical7 monitor. The figure showsa snapshot of the prototype executed within PVSio-web.

Figure 8: ICE-compatible patient monitor prototype based on the Radical7 monitor.

The safety interlock mechanism implemented in the ICE su-pervisor has the following logic. If the measured levels oftwo monitored parameters (in this case, SpO2 and RRa) areoutside given safety thresholds, then a command is automat-ically sent to the pump to stop the infusion, and a respira-tory distress alarm is also generated to alert the nurse. Thegenerated alarm is marked as high priority if the measure-ments are critically low and indicate distress. Otherwise,the alarm is marked as medium priority.

Developing the prototype. Unlike the other two pro-totypes, realistic physical prototypes of ICE supervisors arenot yet publicly available. We therefore borrowed the skin ofanother commercial product, and used it to create the pro-totype (see Figure 9(b)). A PVS model was also developedto specify the internal logic of the supervisor for detectingrespiratory distress and send commands to the pump. Theinternal logic is specified in a function tick, which modelsthe periodic operations performed by the device to checkwhether the conditions are met that trigger a pause com-

mand for the pump. The state of the supervisor includesfields for storing data received from the pump and the mon-itor. For the developed system, the pause command sent bythe ICE supervisor to the pump has the same effect as press-ing the pause button on the infusion pump user interfaces.

6. EXAMPLE ANALYSISUsing the developed prototype, we explored usability- andsafety-related aspects of the ICE user interface. The per-formed analysis is based on simulations, and involved inter-acting with the developed prototypes in different clinical sit-uations. In particular, we were interested in checking whathappens when one of the ICE-compatible devices (either theinfusion pump or the patient monitor) is re-programmed inthe middle of an alarm situation.

Intersting cases were quickly identified where the system be-haved unexpectedly because of subtle combinations of events.For example, we found that the safety interlock applicationcan cause mode changes in the pump while entering infu-

(a) Blueprint of ICE supervisor. (b) PVSio-web prototype of the ICE supervisor executedwithin PVSio-web.

Figure 9: ICE supervisor prototype.

sion parameters. For the specific device used in the ICEprototype, this happened when a pause command sent bythe ICE supervisor is received by the pump while the pumpis infusing and the operator is reprogramming the volume tobe infused (VTBI). Upon receiving the pause command, thepump suddenly changes mode of operation from Edit VTBIto Edit Rate, without halting data entry. The combinationof events could happen either coincidentally at the sametime when the operator is reprogramming the pump, or asa result of the reprogramming of the pump. In either case,if the data entry mode changes and the operator does notnotice the change, a programming error could occur, wherevolume to be infused is accidentally changed. It is worth not-ing that the identified combination of events are unlikely tohappen when the pump is operated as a stand-alone device,disconnected from the ICE system – to reproduce the samesituation, the operator would need to press simultaneouslythe data entry buttons and the pause button on the infusionpump user interface. When connected to ICE, on the otherhand, the pause command is automatically triggered by theICE supervisor, potentially at any time.

Other similar exploratory analyses can be carried to artic-ulate scenarios, requirements, and concerns related to thebehaviour of the system. This is extremely valuable withinthe development lifecycle of ICE systems, as it helps engi-neers to understand what needs to be verified in the systemto ensure safety of operation. Being based on formal mod-els, the same prototypes can then be used for a full formalanalysis of safety and usability properties, e.g., following theapproach described in [12, 5]

7. CONCLUSIONSRigorous analysis tools based on formal methods technolo-gies enable systematic and full exploration of system config-urations and inputs. Tools, however, are needed that can re-

duce the perceived cost of using these powerful technologies.Tools are also needed that can be used by domain expertsthat are not familiar with formal methods to assess whatis being verified. Without a clear understanding of whatis being verified, the verification effort is potentially point-less, e.g., because the verified properties depart from the in-tended meaning of safety requirements used in assurance ar-guments for the system. Our prototyping toolchain moves inthis direction, as it facilitates multi-disciplinary discussion ofsafety- and usability-related aspects of ICE user interfaces.Being based on formal models, the same models developedfor the prototypes can be used for full formal analysis of theICE system behaviour. An aspect that needs investigationis how to best include the ICE Network Controller in theformal analysis of the system. In the developed ICE systemprototypes, in fact, the ICE Network Controller is softwarecode, rather than formal models. A promising solution thatwe are exploring is the definition of abstract models of theICE Network Controller that capture hypotheses about thequality of service offered by the controller, e.g., its abilityto deliver messages to the intended destinations. This wayof proceeding facilitates the verification of ICE systems forbroad classes of ICE Network Controllers (as opposed to spe-cific implementations of the ICE Network Controller). Fur-ther work is also needed to understand how nature-inspiredalgorithms, such as those implemented in SAPERE, can beused to improve the performance of the system. An interest-ing option is, under this perspective, to implement anothervariant of the PVSio-web Network Controller, that includesa different communication middleware. This would give usinsights about the performance and reliability of differentcommunication middleware.

AcknowledgmentsThis work is part of CHI+MED (EPSRC grant EP/G059063/1).

References[1] Developing pervasive multi-agent systems with

nature-inspired coordination. Pervasive and MobileComputing, 17, Part B:236 – 252, 2015. 10 years ofPervasive Computing’ In Honor of ChatschikBisdikian.

[2] Cardinal Health Inc. Alaris GP volumetric pump:directions for use, 2006.

[3] F. L. De Angelis, J. L. Fernandez-Marquez, andG. Di Marzo Serugendo. Self-composition of servicesin pervasive systems: A chemical-inspired approach.In Agent and Multi-Agent Systems: Technologies andApplications, pages 37–46. Springer InternationalPublishing, 2014.

[4] J. M. Goldman. Medical Devices and MedicalSystems-Essential safety requirements for 5 equipmentcomprising the patient-centric integrated clinicalenvironment 6 (ICE)-Part 1: General requirementsand conceptual model 7. ASTM International, 2008.

[5] M. D. Harrison, P. Masci, J. C. Campos, andP. Curzon. Demonstrating that medical devices satisfyuser related safety requirements. In 4th InternationalSymposium on Foundations of Healthcare InformationEngineering and Systems (FHIES2014), 2014.

[6] A. King, D. Arney, I. Lee, O. Sokolsky, J. Hatcliff, andS. Procter. Prototyping closed loop physiologic controlwith the medical device coordination framework. InProceedings of the 2010 ICSE Workshop on SoftwareEngineering in Health Care, pages 1–11. ACM, 2010.

[7] A. King, S. Procter, D. Andresen, J. Hatcliff,S. Warren, W. Spees, R. Jetley, P. Jones, andS. Weininger. An open test bed for medical deviceintegration and coordination. In SoftwareEngineering-Companion Volume, 2009.ICSE-Companion 2009. 31st International Conferenceon, pages 141–151. IEEE, 2009.

[8] B. Larson, J. Hatcliff, S. Procter, and P. Chalin.Requirements specification for apps in medicalapplication platforms. In Proceedings of the 4thInternational Workshop on Software Engineering inHealth Care, pages 26–32. IEEE Press, 2012.

[9] P. Masci, P. Oladimeji, P. Curzon, and H. Thimbleby.Tool demo: Using PVSio-web to demonstrate softwareissues in medical user interfaces. In 4th InternationalSymposium on Foundations of Healthcare InformationEngineering and Systems (FHIES2014), 2014.

[10] P. Masci, P. Oladimeji, P. Curzon, and H. Thimbleby.PVSio-web 2.0: Joining PVS to Human-ComputerInteraction. In 27th International Conference onComputer Aided Verification (CAV2015). Springer,2015. Tool and application examples available athttp://www.pvsioweb.org.

[11] P. Masci, R. Ruksenas, P. Oladimeji, A. Cauchi,A. Gimblett, Y. Li, P. Curzon, and H. Thimbleby. Thebenefits of formalising design guidelines: A case studyon the predictability of drug infusion pumps.Innovations in Systems and Software Engineering,Springer-Verlag London, 2013.

[12] P. Masci, Y. Zhang, P. Jones, P. Curzon, andH. Thimbleby. Formal Verification of Medical DeviceUser Interfaces Using PVS. In ETAPS/FASE2014,17th International Conference on Fundamental

Approaches to Software Engineering, Berlin,Heidelberg, 2014. Springer-Verlag.

[13] Masimo. Radical7 patient monitor: system overview.http://www.masimo.com/rainbow/radical7.htm, 2015.

[14] C. Munoz. Rapid prototyping in PVS. TechnicalReport NIA Report No. 2003-03,NASA/CR-2003-212418, National Institute ofAerospace, 2003.

[15] P. Oladimeji, P. Masci, P. Curzon, and H. Thimbleby.PVSio-web: A tool for rapid prototyping device userinterfaces in PVS. In 5th International Workshop onFormal Methods for Interactive Systems (FMIS2013),2013.

[16] S. Owre, J. Rushby, and N. Shankar. PVS: APrototype Verification System. In 11th InternationalConference on Automated Deduction (CADE), volume607 of Lecture Notes in Artificial Intelligence, pages748–752, 1992.

[17] S. Procter and J. Hatcliff. Anarchitecturally-integrated, systems-based hazardanalysis for medical applications. In Formal Methodsand Models for Codesign (MEMOCODE), 2014Twelfth ACM/IEEE International Conference on,pages 124–133. IEEE, 2014.

[18] S. Proctor, J. Hatcliff, A. Fernando, and S. Weininger.Using stpa to support risk management forinteroperable medical systems. 2015 STAMPWorkshop Presentations, 2015.

[19] S. Weininger, Y. J. Kim, J. Hatcliff, V.-P. Ranganath,and Robby. Integrated clinical environment devicemodel: Stakeholders and high level requirements.2015.

[20] F. Zambonelli, A. Omicini, B. Anzengruber,G. Castelli, F. L. DeAngelis, G. Di Marzo Serugendo,S. Dobson, J. L. Fernandez-Marquez, A. Ferscha,M. Mamei, S. Mariani, A. Molesini, S. Montagna,J. Nieminen, D. Pianini, M. Risoldi, A. Rosi,G. Stevenson, M. Viroli, and J. Ye. Developingpervasive multi-agent systems with nature-inspiredcoordination. Pervasive and Mobile Computing,17:236–252, 2015. Special Issue “10 years of PervasiveComputing” In Honor of Chatschik Bisdikian.