Conference PaperPDF Available

Abstract and Figures

Many aspects of modern medicine, including the administration of anesthetic agents during general surgery, remain unautomated and reliant on the vigilance of the attending clinicians. In other fields where failures can have catastrophic 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 implementation of a complete automated system for intravenous anesthetic drug infusion based on feedback from electroencephalography (EEG) readings. The system software in its entirety consists of approximately 22K lines of Scheme code and features a client-server implementation interfacing medical devices with a portable graphical user interface. The user interface 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 system with extensive testing facilities to mitigate the inherent safety hazards associated with the application.
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)
... Experience transfer from aviation to other industries can also be beneficial for safety. Petersen, Görges, Ansermino and Dumont (2014) describe modern medicine and how the use of anesthetics during operations is not automated. Safety is dependent on the healthcare professional's alertness, and Petersen et al. (2014) draws parallels to aviation where human error can also cause serious consequences, and where automated control regimes have been introduced to reduce risk and enhance human performance. ...
... Petersen, Görges, Ansermino and Dumont (2014) describe modern medicine and how the use of anesthetics during operations is not automated. Safety is dependent on the healthcare professional's alertness, and Petersen et al. (2014) draws parallels to aviation where human error can also cause serious consequences, and where automated control regimes have been introduced to reduce risk and enhance human performance. The authors show how a fully automated, closed system for intravenous drug infusion can be designed technically to control and simultaneously monitor multiple simultaneous infusions of drugs on multiple patients. ...
... Petersen, Görges, Ansermino og Dumont (2014) beskriver moderne medisin og hvordan anvendelsen av bedøvelsesmidler under operasjoner per dags dato ikke er automatisert. Sikkerheten er avhengig av helsepersonellets årvåkenhet, hvor Petersen et al., (2014) trekker paralleller til luftfart hvor menneskelige feil også kan medføre alvorlige konsekvenser, og hvor man har innført automatiserte kontrollregimer med tanke på å redusere risiko samt forsterke den menneskelige ytelse. Forfatterne viser hvordan et fullstendig automatisert, lukket system for intravenøs medikamentinfusjon kan designes teknisk for å kontrollere og samtidig overvåke flere samtidige infusjoner av legemidler på flere pasienter. ...
Technical Report
Full-text available
Norsk luftfart er internasjonal og blir påvirket av globale bransjetrender og teknologisk utvikling. Luftfartstilsynet poengterer at flysikkerhetsarbeid fremover vil innebære å opprettholde dagens positive sikkerhetsstatistikk i en bransje som vil oppleve stadig vekst i årene fremover. For å møte fremtidens krav til miljø og sikkerhet er man avhengig av nye teknologier, og autonome og automatiserte transportløsninger er slik sett en viktig driver. I forskningen om autonom transport innen transportsektoren er imidlertid luftfart lite representert - fokus har også blitt flyttet for raskt mot å beskrive fullt ut autonome systemer, mens den viktige overgangsfasen der stadig flere funksjoner blir automatiserte har fått mindre oppmerksomhet. Denne rapporten beskriver erfaringer og kunnskap luftfartsbransjen har opparbeidet over mange år knyttet til forholdet sikkerhet og ulike grader av automatisering, samt peker på utfordringer og muligheter ved autonom luftfart i fremtiden. Rapporten består av litteraturstudie og intervjustudie. Litteraturstudien beskriver automatiseringsparadokset ved at økende grader av automatisering først og fremst har medført økt sikkerhet - imidlertid er forholdet automatisering og sikkerhet sammensatt hvor utfordringer ved sikkerheten kan sees i sammenheng med menneske-automatisering interaksjon, hvor Air France 447 havariet i 2009 er et eksempel. I intervjustudien med aktører i norsk luftfart sees mulighetsrommet fremover i et sikkerhetsperspektiv mot nødvendigheten av å avklare forutsetninger for design og menneskets rolle, samt hvordan fremtidige automatiserte/autonome system kan håndtere unormale og ukjente situasjoner. Rapporten beskriver forsknings og - bransjeanbefalinger for videre arbeid. Oppdragsgiver: Ludvig G. Braathens fond / NHO Luftfart / LO Luftfart
... It is based on the portable Gambit Scheme programming language [8] and provides a flexible cross-platform environment for developing graphical apps on mobile devices as well as medical instrumentation interfaces on embedded platforms [7]. It has been used to create a diverse range of applications, from a mobile data collection tool for a multicenter preeclampsia trial in low resource settings [9], to mission critical, embedded drug delivery as part of a closed-loop anesthesia system [10]. Importantly, we identified strategies to improve medical device data exchange using a data broker concept [11]. ...
Article
Full-text available
Background: In the perioperative environment, a multidisciplinary clinical team continually observes and evaluates patient information. However, data availability may be restricted to certain locations, cognitive workload may be high, and team communication may be constrained by availability and priorities. We developed the remote Portable Operating Room Tracker app (the telePORT app) to improve information exchange and communication between anesthesia team members. The telePORT app combines a real-time feed of waveforms and vital signs from the operating rooms with messaging, help request, and reminder features. Objective: The aim of this paper is to describe the development of the app and the back-end infrastructure required to extract monitoring data, facilitate data exchange and ensure privacy and safety, which includes results from clinical feasibility testing. Methods: telePORT’s client user interface was developed using user-centered design principles and workflow observations. The server architecture involves network-based data extraction and data processing. Baseline user workload was assessed using step counters and communication logs. Clinical feasibility testing analyzed device usage over 11 months. Results: telePORT was more commonly used for help requests (approximately 4.5/day) than messaging between team members (approximately 1/day). Passive operating room monitoring was frequently utilized (34% of screen visits). Intermittent loss of wireless connectivity was a major barrier to adoption (decline of 0.3%/day). Conclusions: The underlying server infrastructure was repurposed for real-time streaming of vital signs and their collection for research and quality improvement. Day-to-day activities of the anesthesia team can be supported by a mobile app that integrates real-time data from all operating rooms.
Conference Paper
Full-text available
Introduction: iControl v3 is a system for closed-loop control of propofol and remifentanil anesthesia in adults. It includes a touch-screen user interface, the NeuroSENSE EEG monitor, two Alaris infusion devices and speakers for audible alarms. Previous versions of the system have been clinically evaluated [1]. The system has been designed for investigational use, with patient safety as a key priority. The aim of this study was to evaluate the system's usability in the hands of expert users. The purpose of this formative evaluation was to guide development of the user interface, verify appropriate configuration of devices and demonstrate that the system can provide a safe and acceptable interface for the clinical evaluation. Results of the study will further inform risk identification, formulation of Instructions for Use (IFU) and design of the training scheme [2]. Methods: Institutional review board approval and informed consent were obtained to conduct the evaluation with staff from the Department of Anesthesia. All participants were given an introduction to the system and were asked to 'think aloud' during the evaluation, while their comments were captured with a voice recorder [3]. After a brief opportunity to use the equipment without instruction, a structured evaluation was conducted, in which participants followed a specific set of verbal prompts for 18 safety-critical tasks and 12 administrative tasks. Each participant provided post-test verbal feedback and completed the Computer System Usability Questionnaire (CSUQ) [4], in which positive statements about the system were scored on a scale of 1 (strongly agree) to 7 (strongly disagree). Results: Usability was evaluated by 15 potential users (12 staff anesthesiologists, 2 residents and 1 anesthesia assistant), all reporting normal or corrected-to-normal vision. Twenty-three usability issues were observed and/or reported by participants. These related to confirmation of data input (n=6), understanding displayed information (n=4), use of the touch screen interface (n=3), identification and interpretation of error messages (n=3), operation of infusion devices (n=3), organisation of lists and graphical information (n=3) and the log-in/-out process (n=1). These issues suggested improvements to the IFU and/or focus points for training; 2 issues were resolved by modifying peripheral equipment and 4 issues prompted minor software changes to the user interface. Participants completed all evaluation tasks: 17/18 safety-critical tasks and 9/12 administrative tasks were completed by more than 90% of participants without assistance; however, for one safety critical-task (identify an infusion rate), 23% of participants needed assistance. The CSUQ (median score 3, inter-quartile range 2-4) suggested the system met user expectations. Discussion: After only a brief informal introduction, representatives of the target user group were able to safely operate the system with minimal assistance. Solutions were provided for the identified usability issues and additional requirements were recorded for consideration in future releases. The system and IFU will be subjected to a summative evaluation prior to the start of clinical testing to verify that identified solutions are effective.
Poster
Full-text available
Background: Closed loop control of total intravenous anesthesia involves the continuous adjustment of drug infusion rates according to measured clinical effect [1]. Depth of Hypnosis (DoH) measures, such as the WAVCNS index [2], can provide feedback suitable for closed loop control. A study that will culminate in the design of a robustly tuned controller automatically determining propofol and remifentanil infusion rates based on WAVCNS¬ is currently ongoing. In the first phase of this study, propofol infusion was controlled by the closed-loop system while remifentanil was administered according to a target controlled infusion (TCI)[3]. The collected data is then used to model the effects of varying remifentanil utilisation on the EEG and design an automated remifentanil infusion controller. In the second phase, remifentanil will be titrated to counteract brief disturbances in the WAVCNS that are assumed to be a result of nociceptive stimulation. Propofol will continue to be used to achieve the overall DoH setpoint. The data reported summarises the initial phase. Methods: With both Health Canada and REB approval and written informed consent, adults ASA I-III, requiring general anesthesia for a wide variety of elective surgical procedures expected to last more than one hour were enrolled in the study. The WAVCNS was used to provide continuous feedback to the control system for induction and maintenance of anesthesia with propofol. An initial WAVCNS setpoint of 50 was used in all cases. Remifentanil was administered according to an effect side target [3] specified by the clinician throughout induction and maintenance of anesthesia. Changes to the WAVCNS setpoint and remifentanil target as well as bolus dosing of both drugs were permitted by the system (Figure 1). Results: Results are reported as median (interquartile range). 45 adults were enrolled with age 63 (49-69) years and body mass index (BMI) 27.7 (25.1-30.2). Length of time required to complete induction (WAVCNS below 60 maintained for 30 seconds) was 3.8 (3.3-4.7) mins. Required induction dosage of propofol was 1.5 (1.1-1.9) mg/kg, which corresponds to a calculated effect-site concentration [4] of 4.6 (3.9-5.8) mg/ml at the end of induction. Propofol utilisation during the maintenance phase of anesthesia was 117.0 (90.3-146.6) μg/kg/min. Remifentanil utilisation during maintenance was 0.10 (0.08-0.14) μg/kg/min. WAVCNS during the maintenance phase remained within 10 units of the specified setpoint for 85% of the time (72%-91%). Conclusion: These results suggest that closed-loop control of propofol with a stable background infusion of remifentanil is feasible for induction and maintenance of total intravenous anesthesia in adults undergoing a wide variety of elective surgical procedures. Additional research will be required to demonstrate the benefit of automatically adjusting the remifentanil infusion rate. References: [1] Anesth Analg. 2013;117(5):1130-8. [2] J Clin Monit Comput. 2011;25(1):81-7. [3] Anesthesiology. 1997;86(1):24-33. [4] Anesthesiology. 1998;88(5):1170-82.
Conference Paper
Full-text available
A modular framework for the development of medical applications that promotes deterministic, robust and correct code is presented. The system is based on the portable Gambit Scheme program-ming language and provides a flexible cross-platform environment for developing graphical applications on mobile devices as well as medical instrumentation interfaces running on embedded plat-forms. Real world applications of this framework for mobile diag-nostics, telemonitoring and automated drug infusions are reported.
Article
Full-text available
The continual reachability set, the set of initial states of a constrained dynamical system that can reach a target at any desired time, is introduced. The properties of this set are investigated and its connection with maximal reachability constructs is examined. Owing to this connection, efficient and scalable maximal reachability techniques can be used to compute the continual reachability set. An approximation of this set based on ellipsoidal techniques is presented. The results are demonstrated on a problem of control of anesthesia.
Article
Full-text available
We present a connection between the viability kernel and maximal reachable sets. Current numerical schemes that compute the viability kernel suffer from a complexity that is exponential in the dimension of the state space. In contrast, extremely efficient and scalable techniques are available that compute maximal reachable sets. We show that under certain conditions these techniques can be used to conservatively approximate the viability kernel for possibly high-dimensional systems. We demonstrate the results on two practical examples, one of which is a seven-dimensional problem of safety in anesthesia.
Book
To paraphrase a popular saying, usability testing should be done early and often. However, it doesn’t have to be an onerous process. Informative, practical, and engaging, Usability Testing of Medical Devices provides a simple, easy to implement general understanding of usability testing. It offers a general understanding of usability testing and reviews key concepts, highlighting the challenges of validating that protects against dangerous errors that could lead to patient injury and death. The book has been carefully designed to be concise and visually, easily read in one sitting or perused from one section to another as needed It begins with a review of human factors engineering and how usability testing fits in, and then discusses the government regulations and industry standards that have motivated many medical device manufacturers to conduct usability tests. It then covers the nitty-gritty of planning, conducting, and reporting the results of a usability test, making the process as smooth and painless as possible for the development team, and therefore making the medical devices they develop as safe, effective, and appealing as possible. As you read the book, keep in mind that, like snowflakes, each usability test is unique. And while 100 usability specialists working independently might take 100 different approaches to testing, albeit with considerable methodological overlap, there would also be meaningful differences that the practitioners would energetically defend as the best given the circumstances. To make your testing process easier, the authors, seasoned human factors specialists who have conducted thousands of test sessions involving medical devices used by physicians, nurses, therapists, technicians, and patients, have painstakingly put together an informative, practical, and engaging handbook for conducting usability tests of medical devices.
Article
This paper describes the design of a robust proportional-integral derivative (PID) controller for propofol infusion in children and presents the results of clinical evaluation of this closed-loop system during endoscopic investigations in children age 6–17. The controller design is based on a set of models that describes the interpatient variability in the response to propofol infusion in the study population. The PID controller is tuned to achieve sufficient robustness margins for the identified uncertainty. 108 children were enrolled in this study, and anesthesia was closed-loop controlled in 102 of these cases. Clinical evaluation of the system shows that closed-loop control of both induction and maintenance of anesthesia in children based on the rmWAVrmCNS{rm WAV}_{rm CNS} index as a measure of clinical effect is feasible. A robustly tuned PID controller can accommodate the interpatient variability in children and spontaneous breathing can be maintained in most subjects.
Article
Background: Postoperative nausea and vomiting (PONV) is still one of the major problems in strabismus surgery, especially in children. In recent years many studies have been published, suggesting that choosing propofol as the anaesthetic agent may help to reduce the high incidence of PONV in children undergoing strabismus surgery. Experience with remifentanil in children is still very limited and little is known,whether propofol in combination with this new short acting opioid is also superior regarding PONV in squint surgery compared to sevoflurane/N(2)0. Additionally, little is known, whether the type of operation or the muscle which is operated on has any influence with respect to PONV. Methods: Following sample size estimation, ethics committee approval and parents informed consent in a prospective, randomised, observer-blind study 105 ASA I and II children aged 3-8 years scheduled for elective strabismus surgery were assigned into one of the following groups: Group TIVA (propofol/remifentanil, n=53): anaesthesia was induced by remifentanil 0.5 mu g kg(-1) min(-1) over 2 min (loading phase), followed by 3 mg kg(-1) propofol along with 30% O-2 in air. After endotracheal intubation anaesthesia was maintained initially with remifentanil 0.25 mu kg(-1) min(-1) and propofol 10 mg kg(-1) h(-1) by constant infusion. In the course of the operation the infusions of the anaesthetics were adjusted to the decreasing need for anaesthesia. Group VOLATIL (sevoflurane/N2O, n=52):anaesthesia was induced by inhalation of sevoflurane along with 50% O-2 in N2O. After endotracheal intubation anaesthesia was maintained with sevoflurane 1.0-1.5 MAC along with 30% O-2 in N2O and in the course of the operation the administration of the inhaled anaesthetics was adjusted correspondingly. Preoperatively collected data included gender, age, weight and history of PONV. Intraoperatively collected data consisted of data belonging to routine monitoring (heart rate, blood pressure, peripheral oxygen saturation and temperature) as well as the duration of the operation and anaesthesia and specific data regarding the operation (including the number and type of muscles as well as the kind of operation). Data collected within the first 24 hours postoperatively in the recovery room and on the ward by blinded observers included any PONV events as well as the antiemetics and analgesics applied. Results: Vomiting was observed less frequently in the TIVA-group than in the VOLATIL-group (21 of 53 vs. 32 of 52, p=0.03) within the first 24 hours postoperatively. Posterior fixation suture ("faden-operation") compared to other operations was followed rather frequently by nausea and vomiting (30 of 44 and 33 of 44, respectively), whereas recessions were rarely associated with nausea and vomiting (12 of 35 and 9 of 35, respectively). Conclusions: TIVA with propofol/remifentanil proved to be a suitable form of anaesthesia for children in this setting. Propofol showed advantages over with respect to PONV after squint surgery in children also when applied in the combination with remifentanil. TIVA with propofol/ remifentanil may therefore be one way to reduce the high incidence of PONV in this setting, bearing in mind, that PONV is not only influenced by the regimen of the general anaesthesia but rather by the combination of many other factors, in particular the type of operation.
Article
During closed-loop control, a drug infusion is continually adjusted according to a measure of clinical effect (e.g., an electroencephalographic depth of hypnosis (DoH) index). Inconsistency in population-derived pediatric pharmacokinetic/pharmacodynamic models and the large interpatient variability observed in children suggest a role for closed-loop control in optimizing the administration of intravenous anesthesia. To clinically evaluate a robustly tuned system for closed-loop control of the induction and maintenance of propofol anesthesia in children undergoing gastrointestinal endoscopy. One hundred and eight children, aged 6–17, ASA I-II, were enrolled. Prior to induction of anesthesia, NeuroSENSE™ sensors were applied to obtain the WAVCNS DoH index. An intravenous cannula was inserted and lidocaine (0.5 mg·kg−1) administered. Remifentanil was administered as a bolus (0.5 μg·kg−1), followed by continuous infusion (0.03 μg·kg−1·min−1). The propofol infusion was closed-loop controlled throughout induction and maintenance of anesthesia, using WAVCNS as feedback. Anesthesia was closed-loop controlled in 102 cases. The system achieved and maintained an adequate DoH without manual adjustment in 87/102 (85%) cases. Induction of anesthesia (to WAVCNS ≤ 60) was completed in median 3.8 min (interquartile range (IQR) 3.1–5.0), culminating in a propofol effect-site concentration (Ce) of median 3.5 μg·ml−1 (IQR 2.7–4.5). During maintenance of anesthesia, WAVCNS was measured within 10 units of the target for median 89% (IQR 79–96) of the time. Spontaneous breathing required no manual intervention in 91/102 (89%) cases. A robust closed-loop system can provide effective propofol administration during induction and maintenance of anesthesia in children. Wide variation in the calculated Ce highlights the limitation of open-loop regimes based on pharmacokinetic/pharmacodynamic models.