Content uploaded by Chris Petersen
Author content
All content in this area was uploaded by Chris Petersen on Aug 19, 2014
Content may be subject to copyright.
A Scheme-Based Closed-Loop Anesthesia System
C. L. Petersen
University of British Columbia
Vancouver, BC Canada
cpetersen@cw.bc.ca
M. Görges
University of British Columbia
Vancouver, BC Canada
mgorges@cw.bc.ca
J. M. Ansermino
University of British Columbia
Vancouver, BC Canada
anserminos@yahoo.ca
G. A. Dumont
University of British Columbia
Vancouver, BC Canada
guyd@ece.ubc.ca
ABSTRACT
Many aspects of modern medicine, including the adminis-
tration of anesthetic agents during general surgery, remain
unautomated and reliant on the vigilance of the attending
clinicians. In other fields where failures can have catas-
trophic consequences, such as the aviation and nuclear power
industry, automated control regimens have been adopted to
reduce the risks and improve performance.
In this paper we discuss many aspects of the implemen-
tation of a complete automated system for intravenous anes-
thetic drug infusion based on feedback from electroencephalo-
graphy (EEG) readings. The system software in its entirety
consists of approximately 22K lines of Scheme code and fea-
tures a client-server implementation interfacing medical de-
vices with a portable graphical user interface. The user in-
terface runs on both mobile devices and dedicated medical
flat panel displays.
The strengths of the Scheme functional language have
been leveraged to build a robust maintainable modular sys-
tem with extensive testing facilities to mitigate the inherent
safety hazards associated with the application.
Categories and Subject Descriptors
D.1.1 [Programming Techniques]: Applicative (Func-
tional) Programming; D.2.3 [Software Engineering]: Cod-
ing Tools and Techniques; J.3 [Life and Medical Sciences]
General Terms
Design, Measurement, Reliability
Keywords
functional programming, Scheme, application programming,
medical systems, anesthesia, closed-loop control, cross-plat-
form development
To appear in the ILC conference, Aug. 15-17 2014, Montreal, QC, Canada
1. INTRODUCTION
Anesthesia is a state of unconsciousness induced before
surgery to prevent pain and stress that would otherwise
harm the patient. It is a compounding of effects on the
central nervous system and other mechanisms in the body,
and generally requires a combination of hypnosis (for pre-
venting traumatic recall and stress) and analgesia (for pain
relief).
With the introduction of short acting drugs and more
elaborate delivery systems, the use of intravenously infused
agents such as propofol (hypnotic) and remifentanil (anal-
gesic), has become preferable for the maintenance of anes-
thesia.
In current practice, intravenous infusions are delivered by
manually setting the infusion rate on syringe pumps. The
pumps are designed to deliver a fixed volume per unit time.
The rate is usually derived from a weight based estimate and
adjusted to the individual patient response and the degree
of surgical stimulation. Infusions are typically started at a
high rate and then manually decreased as the drug starts
to accumulate in the patient. Accurate titration of dose
is especially challenging in children. Children typically re-
quire a 50% higher loading dose of propofol than adults to
achieve a given effect of the drug [5] and have a very wide
range of drug response depending on maturation [6]. Due
to this marked variability, it is difficult to predict a manual
infusion rate that will accurately produce the desired effect.
Too little drug will mean that the patient will move or have
interoperative awareness and too much drug will result in
prolonged recovery and an increase in side effects such as
cardiovascular or respiratory depression.
A closed-loop automated drug delivery system that ad-
ministers drug based on feedback from measurement of a
physiological end point can potentially improve the out-
comes for patients by addressing the inter-patient variabil-
ity, providing greater hemodynamic and respiratory stabil-
ity, more stable depth of anesthesia, and reducing the total
dose of drug delivered. However, there are currently no such
closed-loop anesthesia delivery systems commercially avail-
able. While this form of control has proven beneficial in
many contexts outside medicine, it is only once the safety
has been demonstrated, and large clinical trials subsequently
performed, that it will be possible to determine if closed-loop
control safely provides a better clinical outcome than cur-
rent practice in anesthesia. Performing such trials requires
a robust and safe platform for evaluating new drug infusion
(a)
Surgeon
Assistant
Nurse
Anesthesiologist
Multi-parameter
monitor
Pumps
DoA mon.
iControl
Ventilator
(b)
21" 20"
Pump
Flat Panel
Medical PC
Embedded
Controller
Power
Distribution
Multi-Parameter
Monitor
Pump
66"
DoA
Monitor
UPS
66"
Figure 1: (a) Operating room scenario with closed-loop controller supervised by the attending anesthesiolo-
gist. (b) iControl hardware configuration.
control paradigms.
Over the past ten years the Pediatric Anesthesia Research
Team (PART) has developed and clinically evaluated soft-
ware for control of anesthetic infusions [7, 8] and looked at
many of the clinical safety aspects of software control of in-
fusion devices. These efforts culminated in the creation of a
software tool for closed-loop control of drug delivery called
iControl.
The iControl software system integrates multiple medi-
cal device drivers, control algorithms, expert safety systems
and a graphical user interface runnable on both medical flat
panel displays and mobile devices. All elements of the sys-
tem are written in R5RS Scheme [9, 10], and compiled with
the Gambit Scheme compiler [11] through the cross-platform
LambdaNative development environment [12, 13].
In general we have found benefits to using Scheme that
echoes previously reported experiences [14, 15, 16, 17], in-
cluding fast development times, improved code quality as
compared with prior efforts writing Java and MATLAB code,
and a significantly smaller code base. Despite the many ele-
ments of the system, the full iControl client-server system is
implemented with merely 22,000 lines of code including all
medical device drivers and a complete OpenGL based graph-
ical user interface. This is attributed to the minimal Scheme
syntax and the very expressive nature of the language.
The small size of the source code makes the software man-
ageable by a small team of developers. Two developers have
full comprehension of all the system components, reducing
the potential for introducing unintentional interoperability
problems between the elements of the system.
iControl is heavily modularized, and broken into func-
tional blocks of Scheme modules and plugins, as described
later. A total of twelve modules and six plugins are part of
the system. Many of these code blocks are reused in other
applications, which increases the likelihood of discovering
latent problems in the code and ensuring the stability and
safety of the deployed application.
2. IMPLEMENTATION
2.1 Design considerations
The primary consideration in the design of a closed-loop
anesthesia system is safety. Excessive or insufficient drug
delivery could have potentially deleterious effects on patient
outcomes. To ensure safety, it is essential that the system
operates under the direct supervision of an expert anesthe-
siologist, and provides means for the user to rescue in the
event of a software or hardware malfunction. The user must
be immediately able to revert to manual adjustment of in-
fusion rate at any time, and the possibility of an excessive
dose must be avoided.
The core function of the system is to control the level
of hypnosis and analgesia of a patient undergoing general
surgery by automating the initial drug doses (induction doses)
and the subsequent sustained infusion rates of two drugs
based on physiological monitoring. The system must in-
clude the recommended minimum standards of monitoring
for anesthesia through interfacing to the relevant indepen-
dent medical devices. This includes at least a multi-parameter
patient monitor and a Depth of Anesthesia (DoA) monitor,
in addition to the infusion pumps delivering the drugs (Fig-
ure 1a). Software should continuously calculate predicted
drug concentrations at the effect site (brain/central nervous
system) based on the specific patient characteristics, and dis-
play predicted concentrations and physiological parameters
to enhance safety.
2.2 Hardware Architecture
iControl is a client-server system. The server is respon-
sible for monitoring and controlling drug delivery. It runs
on a fan-less embedded single board computer (Linux or
OpenBSD). The client displays information to the attending
anesthesiologist and provides safety override mechanisms.
The primary client console is a medical grade flat panel dis-
play (Windows XP embedded). Secondary clients can con-
nect wirelessly from mobile devices.
(a)
LambdaNative
Scheduler
PumpInput
PhysMonitor
DoAMonitor
RUPI
DataStore
DecisionSupport
PumpControl
DataOutput
Modules
Plugins
Gambit Scheme
(b)
PumpControl
Calculate
new infusion rates
DOAMonitor
Determine
Depth of Anesthesia
DataOutput
Save case data to disk
DecisionSupport
Generate warnings
from physiological data
and infusion status
PhysMonitor
Determine heart rate,
oxygen saturation and
blood pressure
Pump
Read and set
infusion rate
DataStore
Store data and events
User Programming Interface
Modify/sync state
User Interface
User interaction
Figure 2: Modular iControl software structure built on top of Gambit Scheme and LambdaNative. (a)
Horizontal and vertical function separation into modules and plugins. (b) Central data store organization
concept.
The use in an operating room environment imposes a num-
ber of physical requirements on the iControl system:
•Footprint: Operating room floor space is very limited,
and the iControl system must occupy as little area as
possible;
•Mobility: Operating room equipment has to be mobile,
since positioning is dependent on the type of surgery,
patient conditions, and other factors;
•Physical safety: The system should not pose physi-
cal hazard (e.g. tripping or tipping potential) to the
operator or other people in the operating room;
•Ergonomics/interface: The system must allow a stand-
ing anesthesiologist to perform two main operations:
interaction with the controller touch screen and han-
dling of the propofol and remifentanil syringes, and
•Washdown: The system must be cleanable according
to operating room standards.
In addition, the system must be able to recover from a
momentary loss of main power. These requirements are ad-
dressed by mounting the embedded controller, touch screen
client PC, pumps and DoA monitor on a mobile cart (Anthro
Zido) with 4”casters and 20”x21”floor footprint (Figure 1b).
For optimal ergonomics the pumps are mounted at elbow
height and the touch screen interface at eye/shoulder level,
with the DoA monitor and power distribution and backup at
the bottom of the cart. This provides a low center of gravity
that prevents the cart from tipping over. The only external
wires are the main power, a cable to the multi-parameter
monitor mounted on the anesthesia machine, and the pa-
tient DoA/infusion line hookup, and all internal wiring is
kept as short as possible to minimize the tripping hazard.
The system is compliant to industrial washdown standards
to allow adequate cleaning, and an uninterruptible power
supply (UPS) provides intermittent power to the embed-
ded controller, client PC and DoA monitor in the event of
a power loss (the pumps have their own internal battery
backup).
2.3 Server Architecture
The iControl server software is by design modular, mini-
mal and expandable. Modules interact through modification
of a central data store that contains all system states and
patient information, and a simple plugin system facilitates
the reuse of equipment drivers etc. for concurrent use and
future expansions (Figure 2a,b).
2.3.1 DataStore Module
The DataStore module shares states and parameters be-
tween all modules and plugins running against a particu-
lar patient, and handles storage of trends, waveforms and
events. The module provides a simple framework for stor-
ing/sharing system data and state information.
A DataStore is a database built around hash tables. Each
store has a separate table, enabling multiple stores to coexist
(i.e. allowing a potential future expansion of iControl to
control infusions in multiple patients concurrently). Strings
identify the data store entries, and all data types are handled
transparently. Entries in the store can be tagged with a
category for easy discovery.
For example, a store is created with the command
(define store (make-store "patientA"))
and values can be set and referenced through
(store-set! store "HeartRate" 60.)
(store-ref store "BPsys")
Events and physiological waveforms are special cases. Events
are stored in a list with timestamps and priorities that al-
low the system to identify and process new alarm condi-
tions, greylist redundant events, and timeout past alarm
conditions. Waveforms arrive from the monitors in segments
that are concatenated in separate storage until the qualified
waveform vector can be dispatched into the main store. The
dispatch is conditioned on the availability of scaling infor-
mation, and is driven by the Scheduler module.
2.3.2 Scheduler Module
The Scheduler module is a framework for running the sys-
tem plugins. This forms the main loop of the running iCon-
trol system. It provides a mechanism for instancing proce-
dural plugins that operate on a DataStore, and executing
them in a deterministic control loop according to their func-
tional category. The Scheduler is intentionally implemented
as a single thread to avoid unpredictable timing and debug-
ging problems [18]. The time between calls to the plugins
may vary mainly due to variation in the response of the med-
ical devices (delays due to garbage collection are negligible in
comparison, and have not been found to affect performance),
and the single thread prevents unpredictable interleaving.
The Scheduler and its plugins are designed around the
concept of patient ”cases”. In this context a case refers to
the time starting when a patient is prepared for induction
of anesthesia on the operating table, and ending when the
patient regains consciousness after the surgical procedure.
The Scheduler allows any number of plugins to be reg-
istered at runtime against a given DataStore. The plugins
operate on the DataStore through the following five callback
hooks:
•init: Called once at registration to initialize the plu-
gin state.
•caseinit: Called once at beginning of each new case
to initialize case specific plugin state.
•run: Called repeatedly after initialization to continu-
ously read/write to the data store. The frequency of
invocation depends on the importance and real-time
need of the plugin.
•caseend: Called once at end of case, to close case spe-
cific plugin state (file descriptors etc.)
•end: Called once at system exit.
The scheduler supports four different categories of plugin
types: Input (i.e. equipment interfaces) and Algorithm (i.e.
infusion controller) plugins are real-time sensitive and called
as frequently as the processor will allow. Decision Support
and Output plugins are called at lower rate, typically 1-2
Hz, since their operation is less time critical.
2.3.3 Pump Input Plugin
The Pump plugin provides fault-tolerant communication
with a syringe pump to determine the current infusion rate
and total infused volume, as well as to set a new infusion
rate. Currently supported models are the Alaris TIVA/G5
(CareFusion, San Diego, CA) series and Graseby 3400 (Graseby
Medical Ltd, Herts, UK). The plugin will automatically de-
tect the presence of the pump, initiate communication, and
set/receive information to and from the data store. It sup-
ports repeated connect/disconnect cycles.
The Pump plugin is instantiated with a call to the sched-
uler provided make-instance command, for example:
(make-instance store "pump1" "Pump"
’("Port" "/dev/ttyS0") ’("Drug" "propofol"))
to create a propofol pump instance. The Port and Drug
parameters are attributes used to configure the plugin. The
pump plugin can be instantiated multiple times with dif-
ferent drugs against the same data store. This allows the
system to control both propofol and remifentanil simultane-
ously using two different pumps, and potentially other drugs
in the future. The pump plugin has no interface, as all states
are updated automatically through the data store. Changes
to drug doses and concentration are made through the re-
mote user programming interface (RUPI) module described
later.
2.3.4 DoAMonitor Input Plugin
The DoAMonitor plugin communicates with the Depth
of Anesthesia monitor NeuroSENSE (NeuroWave Systems
Inc., Cleveland Heights, OH) to retrieve the patient depth
of anesthesia level, which is used by the closed-loop con-
troller to adjust the infusion rates. The monitor works by
processing a bilateral electroencephalography (EEG) signal
from electrodes placed on the forehead of the patient. In ad-
dition to the basic communication interface to the monitor,
the DoAMonitor plugin contains a mechanism for automat-
ically switching control to the best of the bilateral brain
signals. This provides a failsafe in the event that one side of
the brain is being affected by noise or electrode problems.
The plugin is instanced as follows:
(make-instance store "neurosense" "DoAMonitor"
’("IP" "195.14.195.100") ’("Port" "5001"))
The DoAMonitor plugin also includes a simulation mode
where the DoA is calculated from a population based model
of drug effect on the DoA. This allows complete system in-
tegration tests to be performed without a patient connected
to the system.
2.3.5 PhysMonitor Input Plugin
The PhysMonitor plugin provides a communication inter-
face to a multi-parameter monitor and retrieves patient vital
signs including heart rate, blood pressure and oxygen sat-
uration, as well as waveforms including electrocardiograms
and plethysmograms. This data is critical for ensuring safe
anesthesia.
The PhysMonitor plugin is designed to accommodate mul-
tiple monitors that are automatically detected upon connec-
tion. Supported monitor types are currently the GE Datex-
Ohmeda S/5 (GE Healthcare, Buckinghamshire, UK) fam-
ily of multi-parameter monitors, and the Philips Intellivue
(Philips, Amsterdam, Netherlands) patient monitor series.
These are two of the most commonly used patient monitor
brands in modern hospitals.
The monitor plugin is instanced as
(make-instance store "monitor" "PhysMonitor"
‘("Port" "/dev/ttyS1") ’("Waveforms" #t))
where the Waveforms attribute toggles the acquisition of
physiological waveforms.
The PhysMonitor plugin has no programming interface,
as it will automatically detect the presence of the monitor,
initiate communication, and save the vital signs to the data
store. Alarms are generated in the event of lost communica-
tion, and the plugin automatically resumes communication
when possible.
2.3.6 PumpControl Algorithm Plugin
The PumpControl plugin is responsible for calculating the
infusion rate based on the current patient state and control
Figure 3: Client-server communication structure.
mode. In automatic mode the plugin automatically adjusts
the infusion rate to achieve the wanted target effect, us-
ing a Proportional Integral Derivative (PID) controller with
population-based robust tuning [19].
The plugin automatically engages safety overrides when
the drug concentrations reach configurable upper and lower
bounds. This greatly reduces the risks of both overdosing
and underdosing.
The plugin also allows the operator to manually switch in
and out of automatic mode in a safe manner without abrupt
changes in the infusion rates (bump-less transfer).
The controller plugin can be instantiated as follows:
(make-instance store "propofol-ctl" "PumpControl"
’("Controller" "PID") ’("Drug" "propofol")
’("Conc" 10.) ’("Model" "Paedfusor")
’("DefMode" "Auto"))
The attribute arguments select the controller type and
mode, drug model and concentration to use with the con-
troller. Optional attributes can be used to define default
safety bounds. Subsequent changes to bounds and control
modes are facilitated by the remote user programming in-
terface (RUPI) described below.
2.3.7 DecisionSupport Algorithm Plugin
The DecisionSupport plugin is a rule based expert system
that monitors the vital signs of the patient and generates
warnings about conditions such as anomalous heart rate,
blood pressure and other warning signs of patient deteriora-
tion. It implements a forward-chaining inference engine for
generating alarms based on a predetermined rule set. The
rule conditions are evaluated continuously in the Scheduler
loop, and operate on dynamic values from the data store and
established facts from evaluation of the other rules. This
allows rules to be nested arbitrarily to detect complex con-
ditions of potential danger to the patient. A condition must
be met continuously for 10 seconds in order for the corre-
sponding event to be triggered, to prevent false alarms [20].
A simple example of instantiating the DecisionSupport
plugin is as follows:
(make-instance store "DSE" "DecisionSupport"
’("Rules" (
("Bradycardia"
((< "HR" "HRmin")) 2)
("Hypertension"
((> "BPsys" "BPmax")) 2)
("Oxygen Saturation Low"
((< "SpO2" "SpO2min")) 4)
("DoA High"
((= "propofolOn" #t)
(> "InductionCompleteSecs" 120)
(> "DoA" 90.)) 3))))
The Rules attribute specifies the rule set used in the in-
stanced plugin. Each rule entry consists of a string identifier
followed by a list of conditions that must all be met for the
rule to trigger, and finally a integer priority between 0 and
4. iControl supports five priority levels of increasing impor-
tance. Each level is assigned a colour coding on the user
interface log and an escalating audible alarm modelled after
medical device standards [21].
2.3.8 DataOutput Output Plugin
The DataOutput plugin is responsible for recording all
relevant data from the case to permanent media. This pro-
vides a history of the patient and system state as well as all
user interactions during the case, tagged with the identity
of the operator. It provides a trace that can be used to both
audit cases and validate the performance of the closed-loop
controller offline.
The DataOutput plugin is configured as follows:
(make-instance store "output" "DataOutput"
’("Trends" (
"propofolRate" "propofolDose"
"propofolTotalDose" "propofolMode"
"remifentanilRate" "remifentanilDose"
"remifentanilTotalDose" "remifentanilMode"
"DoA" "DoASetpoint" "HR"
"BPsys" "BPdia" "SpO2"
... )))
The Trends attribute lists all the store entries that should
be written to file. The DataOutput plugin operates auto-
(a) (b)
Figure 4: iControl user interface running on a mobile platform (a) and a medical display console (b).
matically on the data store, and outputs the data in comma-
separated-value (CSV) format. This format is compatible
with common data manipulation programs such as Excel
(Microsoft, Redmond, WA).
Trends and events are saved together in a single CSV file.
The file contains a header line with the name of the param-
eters, followed by rows of data values. Trends are output at
a rate of 1Hz.
Waveforms are saved at the same sample rate as output
by the originating physiological monitor. The waveforms
are stored independently to allow for differences in sampling
rate. All files related to a specific case are grouped together
in a time stamped directory to allow easy recovery.
2.4 Remote User Programming Interface
iControl separates the control algorithms and device drivers
from the user interface through the Remote User Program-
ming Interface (RUPI) module (Figure 3). This module per-
forms user input validation and dispatch, and forms a single
interface for all interaction with the system.
The RUPI interface is designed to validate a user com-
mand, its context and related parameters, and then execute
the request. Most commands simply change values in the
data store, and all will trigger a corresponding event that is
logged by the DataOutput plugin. This ensures that a com-
plete history of all interactions with the system is recorded.
This is useful when reviewing case files, and also provides a
powerful mechanism to identify potential problems with the
controller.
The RUPI module uses a networked TCP/IP client-server
connection to allow for a physically separated user interface
and controller. The network communication is performed
over a custom compressed (high speed Lempel-ziv) and en-
crypted (using Blowfish (a 16 round symmetric Feistel ci-
pher) with 128 bit key size) protocol. This provides a fast
and secure link and facilitates wireless mobile interfaces.
Multiple clients can be connected to the RUPI server at
any given time.
The current implementation uses a fixed randomized key
for a given version of the client-server system. Databases of
four-digit PIN codes are managed by the research team on
the server side for per-site client authentication.
The module generates events for all issued commands as
well as error events for invalid commands. Many of the input
related events have arguments containing the values to set
through the interface. These arguments are post-fixed in
colon-separated form in the event entries, followed by the
identity of the source of the event.
Clients connecting to the RUPI server are authenticated
using a numeric four digit PIN assigned to the principal in-
vestigators that are authorized to use the iControl system
at a given trial site. Once the connection is established, all
user interactions are tagged with the name of the opera-
tor. For example, if Dr. J. Smith was to use the interface
to change the DoA setpoint to 55, an event with identi-
fier "DoASetpoint:55:DRJSMITH" would be generated and
logged.
2.5 Client Architecture
The iControl Graphical User Interface (GUI) is imple-
mented as a client to the iControl server communicating
through the RUPI interface. The GUI provides a graphi-
cal and audible feedback of state and patient data to the
operator and allows changes to the system parameters in-
cluding control mode and limits, patient demographics and
case initialization/termination.
The GUI is portable and runs on a wide variety of plat-
forms, including Windows, Linux, Mac OS X desktop sys-
tems and mobile devices running Android, iOS or Black-
berry OS. The interface reconfigures itself depending on the
available screen size. On large displays it shows all interface
elements in a single multi-pane window (Figure 4b), while
on mobile devices it separates logging, input and parameter
display into separate screens (Figures 4a, 5). This allows
the GUI to be operational on a wide range of devices.
Similar to the server, the GUI client is implemented as
a number of separate code modules that each implement
distinct functional parts of the system.
The graphical user interface is implemented using OpenGL
primitives. A core graphical module provides a thin univer-
sal wrapper for the OpenGL and OpenGL ES (on mobile de-
vices) APIs through the Gambit Scheme foreign function in-
terface, and a small set of Scheme functions to render graph-
ical primitives. Only a minimal subset of the OpenGL API
Figure 5: Modular user interface input elements.
is exposed, sufficient to render 2D textures. OpenGL based
texture rendering is very efficient on all platforms due to uni-
versally available hardware acceleration. The core graphical
layer automatically handles image bit depths and tools have
been written to automatically generate texture atlases from
truetype fonts at various point sizes and glyph subsets at
build time. These tools are part of the open source Lamb-
daNative project [12, 13].
The iControl GUI elements are built using a widget based
interface module running on top of the OpenGL core mod-
ule. The widget framework is complete with buttons, scrol-
lable lists, containers, modal dialogs etc., and provides the
necessary building elements for complex user interfaces.
The user interface for iControl (Figures 4 and 5) was im-
plemented with a mere 2,182 lines of clean functional style
Scheme code without macros. The input elements of the
interface use a single list based structure that takes advan-
tage of Scheme’s equivalence of data and code to provide
a robust and consistent input mechanism across multiple
parameter panes. In addition to the features directly sup-
porting the controller, this input layer has been extended to
also provide the ability to enter drug injections and input
markers (Figure 5). This allows the system to function as
a full anesthetic record system. Indeed, iControl is able to
output detailed charts (Figure 6) that summarize all infor-
mation pertinent to the case. These charts are generated
with a Scheme based graphing module with Portable Docu-
ment Format (PDF) output.
3. SAFETY
Safety is a great concern for a system like iControl. As
part of the Health Canada approval process, an extensive
hazard analysis was performed, and all conceivable modes of
failures were considered. Each failure mode was examined
and the best strategy for mitigation was adopted.
Failure can result from many unpredictable events, includ-
ing hardware malfunctions, controller problems, software
bugs and user errors. In trying to mitigate these different
sources of errors, we performed numerous tests of the inter-
face, including physical tests, simulation tests and usability
studies, discussed individually below.
3.1 Physical tests
The physical tests of the iControl system were focused on
four major components: the infusion pumps, the iControl
server, the DoA monitor and the multi-parameter physio-
logic monitor, as these are the distinct hardware compo-
nents of the system. The connectivity between all of these
components was tested extensively using serial and Ether-
net cables with quick disconnects to simulate the electrical
failure of one or more wires in the cables. The response of
the system in case of both individual wires and the entire
cables being disconnected was evaluated.
All of the possible alarm conditions were also tested and
the iControl system response to each one was carefully ver-
ified. Some alarm conditions are trigged on the medical
devices (e.g. a pump occlusion or noise from the DoA elec-
trodes), and others are internally generated (e.g. the limits
on drug effect site concentration). In general each alarm
should result in a corresponding visual and auditory alert
from the iControl interface.
Finally, the physical volumes of drug delivered by the in-
fusion pumps were verified to match the numbers reported
by the pumps by means of a burette.
3.2 Simulation tests
To test the controller response, a Read-Eval-Print Loop
(REPL) client was developed that connects to the iCon-
trol server RUPI interface to allow injecting user interface
commands programmatically. This includes entering patient
demographics, starting and stopping cases and changing in-
fusion set points and limits.
More than one hundred ”cases” in the form of scripts for
the REPL client were developed to run against the iControl
server. The scripts were written in the Scheme Infix Syntax
(SIX) extension of the Gambit Scheme compiler. This is a
C/Java like syntax that allows our control engineers to write
tests in a language familiar to them.
Most of the generated cases had a demographic profile
chosen randomly to be representative of the trial popula-
tion. The age and sex of the simulated patients were ran-
domly selected for each case using a computer generated ran-
dom number. Weight was selected across the centile range
weighted according to population prevalence. An infusion
1
2 3
4
5
6
7 8
9
10
11
0 10 20 30 40 50 60 70
0 10 20 30 40 50 60 70
0
25
50
75
100
125
150
175
H.R. / SpO2 / B.P.
Time (min)
(Count / % / mmHg)
0 10 20 30 40 50 60 70
0
2
4
6
8
Propofol Ce / Remi Ce
(mcg/ml) / (ng/ml)
0 10 20 30 40 50 60 70
0
70
140
210
Propofol / Remi Rate
(mcg/kg/min) / (ng/kg/min)
0 10 20 30 40 50 60 70
0
50
100
DOH / EMG / L.R SR
(WAVcns)
Statistics
Total P. Dose : 65.22 ml
No. of P. Bolus: 0
Total R. Dose : 16.91 ml
No. of R. Bolus: 0
2014-03-06 12:05:12
Events
1. Drug: lidocaine 00:30
2. Mark: EyelashReflex 03:09
3. Mark: Other 04:14
4. Drug: ROcuronium 04:20
5. Mark: AirwayInsert 05:13
6. InductionComplete: Neurosense 05:50
7. Mark: ProcedureStart 22:57
8. Drug: fentaNYL 60:20
9. Drug: NEostigmine 60:39
10. Mark: AirwayExtract 66:10
11. Mark: Awake 66:17
70
70
70
70
Figure 6: Example of actual closed-loop case chart as output by the Scheme report generator.
profile was randomly selected for each case. Each case had
four segments with randomly selected durations between 600
and 1200 seconds. The scripted cases also tested other as-
pects of the system, including device communication and
physical drug delivery.
For each simulated case, the full iControl system is run in
real time on the actual system hardware, and the controller
logs subsequently analyzed to verify the dynamic response of
the controller and general performance of the system. The
test suite takes 2 1/2 days to complete, and this is done
for every updated version of the system before deployment.
Several issues have been caught and fixed thanks to these
automated REPL tests.
3.3 Usability studies
In order to reduce the risk of user errors, the iControl
system has undergone formal usability evaluations [22] com-
prised of think-aloud task completion [23] and the standard
Computer System Usability Questionnaire (CSUQ) [24]. The
purpose of these evaluations was to improve the usability of
the system in the hands of expert users. The study resulted
in the identification of problems and inconsistencies in the
interface, which were subsequently addressed.
3.4 Formal Verification
The current version of iControl relies on an extensive suite
of tests to assure reliability and robustness. Modern engi-
neering and computer science methods for formalized verifi-
cation offer a complimentary way to validate the logic and
control aspects of the system. For example, the use of a
strongly statically typed programming language could po-
tentially be used along with a proof assistant to verify the
correctness of the core logic of iControl. Such work is cur-
rently outside the resources available to the authors.
Another aspect to which formal verification can be applied
is control itself. Provably safe controllers can potentially be
constructed that can be shown never to reach a state space
that can cause danger to the patient, regardless of input.
Work in in progress to apply such reachability analysis to
the problem of control of anesthesia [25, 26]. This type of
control technology is already in use in the aerospace industry
to prevent critical events in the air [27].
Formal verification is desirable also from a regulatory ap-
proval perspective, where a proof of safety will provide added
assurance to decision makers. Formal verification is not used
in the medical industry at large today, but may well be an
important element in future approvals in the field of closed-
loop control of anesthesia, as the past have shown there to
be considerable regulatory resistance [28].
However desirable formal verification is, the system is ulti-
mately run on atop of a largely unaudited operating system,
with hundred of thousands of lines of code and hundreds
of latent errors. Even if the core logic and control can be
proven safe, it is not a substitute for extensive full-scale sys-
tem testing.
4. CONCLUSIONS
We have developed a robust controller for closed-loop in-
fusion of anaesthetic drugs using Gambit Scheme and the
LambdaNative cross-platform build environment. The sys-
tem is modular and designed to control and monitor multiple
drug infusions on multiple patients concurrently.
The first version of the iControl system provided closed-
loop control of the anesthetic drug (propofol). Subsequent
to extensive testing and health authority approvals, clini-
cal trials in adults [29, 30] and children [31, 32] have been
undertaken successfully, and the system has been found to
work within specifications. To date iControl has been used
on more than 200 patients in a wide variety of surgical sit-
uations.
The use of Scheme has benefitted many aspects of the
implementation. The small readable code base makes the
system maintainable, and features of the Scheme language
such as the equivalence of code and data and the built-in
REPL have provided efficient ways to develop and test the
system. The Gambit specific Scheme Infix Syntax was also
found useful in the porting of control code from engineering
collaborators. Overall, the lack of null-pointer deference pit-
falls and very clean minimal syntax makes Scheme a great
language for implementing safe and maintainable mission
critical software.
The current version of the iControl system includes closed-
loop control of the analgesic drug (remifentanil) to realize a
fully closed-loop anesthesia system, and the first two-drug
closed-loop trial in adults is currently in progress.
Our plan is to continue extending the system, and ulti-
mately implement a distributed version that integrates in-
formation from all the medical monitors in the operating
room and brings us closer to realizing new practical safety
standards in the field of anesthesia.
5. REFERENCES
[1] Glaisyer HR, Sury MR. Recovery after anaesthesia for
short pediatric oncology procedures: propofol and
remifentanil compared with propofol, nitrous oxide, and
sevoflurane. Anesth Analg 2005; 100: 959-63
[2] Rusch D, Happe W, Wulf H. Postoperative nausea and
vomiting following strabismus surgery in children.
Inhalation anaesthesia with sevoflurane-nitrous oxide in
comparison with intravenous anaesthesia with
propofol-remifentanil. Anaesthesist 1999; 48: 80-8
[3] Grundmann U, Uth M, Eichner A, et al. Total
intravenous anaesthesia with propofol and remifentanil
in paediatric patients: a comparison with a
desflurane-nitrous oxide inhalation anaesthesia. Acta
Anaesthesiol Scand 1998; 42: 845-50
[4] Eyres R. Update on TIVA. Paediatr Anaesth 2004; 14:
374-9
[5] McFarlane CS, Anderson BJ. Short TG. The use of
propofol infusions in paediatric anesthesia: a practical
guide. Paediatric Anaesthesia 1999. 9:209-216
[6] Steur RJ, Perez RS, De Lange JJ. Dosage scheme for
propofol in children under 3 years of age. Paediatric
Anaesthesia 2004 ; 14: 462-7
[7] Mehta D, McCormack J, Fung P, Dumont GA,
Ansermino JM. Target Controlled Infusion for Kids:
Trials and Simulations. 30th IEEE EMBS Annual
International Conference, 20-24 August 2008, Vancouver,
Canada. Conf Proc IEEE Eng Med Biol Soc 2008; 1:
5818-5821
[8] McCormack J, Mehta D, Peiris K, Dumont GA, Fung
P, Lim J, Ansermino JM. The effect of a target
controlled infusion of propofol on predictability of
recovery from anesthesia in children. Paediatr Anaesth.
2010 Jan;20(1):56-62
[9] IEEE Standard for the Scheme Programming
Language, IEEE 1178-1990, ISBN: 1559371250
[10] The Revised6Report on the Algorithmic Language
Scheme, http://www.r6rs.org
[11] Gambit Scheme programming language,
http://gambitscheme.org
[12] Petersen CL, G¨
orges M, Dunsmuir D, Ansermino JM,
Dumont GA. Experience Report: Functional
Programming of mHealth Applications. Proceedings of
the 18th ACM SIGPLAN international conference on
Functional programming - ICFP 13, Pages 357-362,
Boston, MA, USA
[13] LambdaNative open source development framework,
http://lambdanative.org
[14] Wiger, U. Four-fold Increase in Productivity and
Quality - Industrial-Strength Functional Programming
in Telecom-Class Products. FemSys 2001, Munich,
Germany
[15] Gat, E. Lisp an an Alternative to Java. Intelligence,
2001; 11, 4 p 21-24.
[16] R. Fateman. Software Fault Prevention by Language
Choice: Why C is Not My Favorite Language. Technical
report, University of California, Berkeley, 2000
[17] Adams JM, Hawkins R, Myers C, Sontag C, Speck S,
Tanner F. The Planning and Scheduling Working Group
Report on Programming Languages. Space Telescope
Science Institute, April 4, 2003
[18] Lee, E.A.: The Problem with Threads. Technical
Report No. UCB/EECS-2006-1, Electrical Engineering
and Computer Sciences, University of California at
Berkeley (2006)
[19] Dumont GA, Martinez A, Ansermino JM. Robust
Control of Depth of Anesthesia. Int. J. Adapt. Control
Signal Process. 2009; 23:435-454
[20] Gorges M, Markewitz BA, Westenskow DR.
Improving alarm performance in the medical intensive
care unit using delays and clinical context. Anesth
Analg. 2009 May;108(5):1546-52
[21] ISO standard IEC/CD 60601-1-8. Medical electrical
equipment – Part 1-8: General requirements for basic
safety and essential performance. International
Organization for Standardization, Geneva, Switzerland,
2006
[22] West N, Dumont GA, Khosravi S, Talebian K,
Ansermino JM. Usability evaluation of a closed-loop
control anesthesia system. International Society for
Anesthetic Pharmacology annual meeting 2013. San
Francisco, CA, USA. October 11, 2013
[23] Wiklund M, Kendler J, Strochlic A. Usability Testing
of Medical Devices. CRC Press; 2011. p. 374
[24] Lewis, JR. IBM computer usability satisfaction
questionnaires: psychometric evaluation and instructions
for use. International Journal of Human-Computer
Interaction Volume 7 Issue 1, 1995, pp 57-78
[25] Kaynama S, Oishi M, Mitchell IM, Dumont GA. The
Continual Reachability Set and its Computation Using
Maximal Reachability Techniques. Proceedings of the
50th IEEE Conference on Decision and Control,
Orlando, FL; 2011, p. 6110
[26] Kaynama S, Maidens J, Oishi M, Mitchell IM,
Dumont GA. Computing the Viability Kernel Using
Maximal Reachable Sets. Hybrid Systems Computation
and Control, pp. 55-63 (2012)
[27] Bayen A, Mitchell I, Oishi M, Tomlin C. Aircraft
autolander safety analysis through optimal control-based
reach set computation. J. Guid. Contr. Dynam., vol. 30,
no. 1, pp. 68-77, 2007
[28] Manberg PJ, Vozella CM, Kelley SD. Regulatory
Challenges Facing Closed-Loop Anesthetic Drug Infusion
Devices. Clinical Pharmacology & Therapeutics (2008);
84, 1, 166-169
[29] Dumont GA, Liu N, Petersen C, Chazot T, Fischler
M. Closed-Loop Administration of propofol Guided by
the NeuroSense: Clinical Evaluation Using Robust
Proportional-Integral-Derivative Design. American
Society of Anesthesiologists (ASA) Annual Meeting 2011
[30] Umedaly A, West N, van Heusden K, G¨
orges M,
Petersen CL, Dumont GA, Ansermino JM, Merchant
RN. Robust closed-loop control of anesthesia in adults
undergoing elective surgery. Proceedings of Society for
Technology in Anesthesia (STA) 2014
[31] West N, Dumont GA, van Heusden K, Petersen CL,
Khosravi S, Soltesz K, Umedaly A, Reimer E,
Ansermino JM. Robust closed-loop control of induction
and maintenance of propofol anesthesia in children.
Pediatric Anesthesia, vol. 23, 712-719 (2013)
[32] van Heusden K, Dumont GA, Soltesz K, Petersen CL,
Umedaly A, West N, Ansermino JM. Design and Clinical
Evaluation of Robust PID Control of propofol
Anesthesia in Children. IEEE Trans. Control Systems
Technol. 22:491-501 (2014)