=Paper=
{{Paper
|id=None
|storemode=property
|title=Towards Dependable Number Entry for Medical Devices
|pdfUrl=https://ceur-ws.org/Vol-727/eics4med10.pdf
|volume=Vol-727
|dblpUrl=https://dblp.org/rec/conf/eics/CauchiCEGHLLMOR11
}}
==Towards Dependable Number Entry for Medical Devices==
https://ceur-ws.org/Vol-727/eics4med10.pdf
Towards Dependable Number Entry for Medical Devices
Abigail Cauchi,1 Paul Curzon,2 Parisa Eslambolchilar,1 Andy Gimblett∗1,
Huayi Huang,2 Paul Lee,3 Yunqiu Li,1 Paolo Masci,2 Patrick Oladimeji,1
Rimvydas Rukšėnas,2 Harold Thimbleby1
(1) Swansea University, (2) Queen Mary University of London, (3) Singleton Hospital, Swansea
CHI-MED: Computer-Human Interaction for Medical Devices
www.chi-med.ac.uk
ABSTRACT into infusion and syringe pumps could lead to incorrect
Number entry is an ubiquitous task in medical devices, doses being delivered, causing harm.
but is implemented in many different ways, from deci-
mal keypads to seemingly simple up/down buttons. Op- There are several inter-related properties of importance
erator manuals often do not give clear and complete ex- in a safety-critical number entry system: efficiency in
planations, and all approaches have subtle variations, entering numbers, the likelihood that errors are made
with details varying from device to device. This paper and the efficiency of recovery from error [1]. In a hos-
explores the design issues, critiques designs, and shows pital it is vital that nurses can use pumps efficiently as
that methods have advantages and disadvantages, par- they are very busy and multitasking is the norm. Ob-
ticularly in terms of undetected error rates. servational studies have suggested that nurses may fre-
quently make minor mistakes in entering numbers, for
Author Keywords
example not following the ‘golden path’ that is the most
efficient way of entering a particular number, but that
Medical devices; modelling; formal methods; HCI; health-
these errors are caught and corrected. Thus it might
care; number entry
be argued that number entry is not a particularly se-
Note. This is a working paper that we will develop vere safety critical problem; however, efficiency remains
further through interactive workshop participation. We an important concern in a busy ward. Therefore a de-
will engage additional authors as necessary for contin- vice where such mistakes do not need to be constantly
ued work to progress towards a high-quality journal pa- corrected or where the golden path is most often the
per fully covering the relationship of all relevant medi- one naturally followed would provide significant bene-
cal, manufacturing and computing factors. It is an im- fit, given the number of times such devices need to be
portant topic that we want to get right. set. Furthermore, work in resilience engineering sug-
gests that single mistakes rarely lead to disasters. It
is when a range of different causes combine. If a large
1. INTRODUCTION number of trivial and normally unproblematic errors are
There are many applications where numbers have to being made then this increases the potential for other
be entered into computer systems, from setting alarm rarer causes to interact with them and lead to a critical
clocks to programming infusion pumps. In most appli- incident—as in Reason’s “swiss cheese model” [5].
cations the consequences of mistakes are limited, but in
many cases—in particular with medical devices—they If a patient is given an incorrect drug dose, perhaps
are potentially critical. Mistakes in entering numbers ten times higher than intended, the patient may die or
∗ have some other adverse outcome. It is therefore cru-
Corresponding author.
cial that number entry is dependable, that there are no
design defects, no mismatches between user conceptual
models and device behaviour, and that users can (so far
as reasonably possible) detect and correct their errors.
This paper shows that this problem is more intricate
than might appear at first sight, that many medical de-
vices and their operator manuals fall short, and that
better solutions are possible.
Submission to EICS4Med Workshop at EICS 2011
53
1
Our goal is to identify a set of properties that pro-
grammers of medical devices should implement—or if
we cannot do that, to recommend a set of key prop-
erties to consider before implementation—to minimize
error rates, specifically for number entry. It is not obvi-
ous how to do this, as it involves a variety of tradeoffs,
and thus we propose a debate within the EICS4Med
workshop to explore the issues. We bring to the de-
bate prepared material and a variety of demonstration
resources to explore ideas. In this paper we highlight
the issues involved to promote that debate.
1.1 Typographic conventions
We render arrow keys pressed by users as: .
We represent number displays with a box around each
visible digit, some of which might be empty. For ex-
ample, 2 0 9 . 4 shows a six-digit display with
two decimal places, showing the number 209.4, with the
cursor in the tens column; if the display were reduced to Figure 1. Screenshot of interactive Alaris GP simulation
only one decimal place, we’d write it as 2 0 9 . 4
2. PRIOR WORK on error management.
There is much prior work on user interface design prin-
ciples in general, such as Nielsen’s Usability Engineer- 3. EXAMPLE DEVICES
ing [4], but they are very vague for programmers. For We have investigated and simulated a number of med-
example, undo (which Nielsen recommends) can be im- ical devices in order to explore their behaviour and re-
plemented in many ways. lated HCI issues; in this section we introduce the two
particular devices, both infusion pumps, whose num-
Work on human computer interaction specifically linked
ber entry behaviour is both typical and interesting, and
to number entry is varied and little has been applied
around which the rest of this paper is built.
specifically in the medical domain.
The Alaris GP infusion pump (figure 1) exemplifies a
For example, Hourizi and Johnson [2] consider a number
number entry interface style found on a variety of sy-
entry error that resulted from a mode error, and which
ringe and infusion pumps: two pairs of buttons change
led to the crash of an A320 airliner with loss of life.
the displayed value; one pair increases the value, the
They argue that this should not be seen as a perception
other decreases it. In each pair, one of the buttons
or knowledge error, but rather as due to an inadequate
causes a bigger change than the other. Each button
communication protocol between pilot and autopilot; a
can also be held down to increase the rate of change of
variation on the design based on this hypothesis was
the number on the screen.
found to eliminate the error in simple user tests.
The B.Braun Infusomat Space pump (figure 2) has three
Brumby et al. [1] investigated trade-offs between effi-
distinct number entry systems used for different tasks,
ciency of entering mobile phone numbers vs avoiding er-
rors in driving. Their analysis suggests that interleaving all based around a set of buttons; it exhibits
number entry at chunk boundaries efficiently trades the a number of interesting behaviours. It is a good exam-
time given up to dialling with that of ensuring enough ple of the way in which number entry is widely perceived
attention is paid to driving to avoid drifting. as unproblematic and trivial, while in fact harbouring
potential for surprises and difficult. Its user manual
has very little to say on the topic: “When editing pa-
It is well known that device design can encourage cer-
tain number entry errors in medicine. For example rameters, switch digits/levels using . White back-
Zhang et al [7] report an incident where a nurse in- ground indicates current digit/level. Use or to
tending to program a pump at 130.1ml/h inadvertently change current setting.” Elsewhere in the manual, the
programmed the pump at 1301ml/h — a rate 10 times arrows are described as: “Arrow up and down: Scroll
larger than the intended rate. Unknown to the nurse, though menus, change setting of numbers from 0-9, an-
the decimal point on the interface of the pump only swer Yes/No questions. Arrow left and right: Select
works for numbers up to 99.9. data from a scale and switch between digits when num-
bers are entered. Open a function while pump is run-
Thimbleby and Cairns [6] show that out by 10 errors ning or stopped with the left arrow key.”
in number entry systems, like the one described above,
can be halved with better interaction design focussing This description is inadequate; for example, it suggests
54
2
Number entry techniques
Serial entry Incremental entry
? Decade Arithmetic
Figure 3. Number entry—basic classification
Figure 2. Screenshot of interactive B.Braun simulation
Commercial simulations — We have some commer-
that if the display is 9 ⋅ (say) and is cial simulations, intended for hospital training purposes,
pressed, then the display will become 0 ⋅ including for versions C and D of the B.Braun; our phys-
In fact, it becomes 1 0 ⋅ , i.e. an arithmetic ical pump is version E. The simulation diverges from
operation was performed (9 + 1). observed behaviour (at least) in that it does not clamp
to a minimum value as described above, but rather to
More concerningly, if the display is 1 0 ⋅ and 0. This suggests that the defaulting minimum value is
is pressed, it becomes 0 0 0 ⋅ 1 . The arith- introduced in version E.
metic operation performed in this case was 10 - 100
= -10, which result was then clamped to a minimum Physical devices and manuals — Finally we will
value, 0.1. It is easy to imagine scenarios in which this bring some real physical devices together with their op-
behaviour leads to an underdose, perhaps harmfully. erator manuals for comparison with our and the com-
The pump has similarly surprising and inconsistent be- mercial simulations.
haviour around the maximum value. These issues are
described further in the next section. 5. A TAXONOMY FOR NUMBER ENTRY
In order to support discussion in the workshop, in this
For a new user, the infusion pump is likely to behave un- section we propose an initial ‘taxonomy’ of features and
predictably, though we do not know what implications behaviours of number entry interfaces, particularly con-
this unpredictability has on safety in medical scenarios. sidering some of the behaviours described above. We
The lack of symmetry between minimum and maximum hope that further debate will refine and augment this
behaviour might have an impact on usability, as do the list. As we describe the taxonomy we make some obser-
arithmetic operations, particularly when subtracting a vations and speculations about relevance to usability,
value which results in a number less than 0. simplicity of conceptual models, etc. but our main pur-
pose in this paper is to ask questions and so promote
4. RESOURCES FOR DEBATE discussion, not provide answers specifically — most of
In order to support debate around these issues, we will this space remains intellectually unexplored.
bring a range of resources to the workshop.
At the top level, we distinguish between serial and incre-
Simulations — We have implemented a variety of user mental entry. Serial entry involves entering the number
interfaces for entering numbers, closely based on real in- as a string, usually via a numeric keypad; consider en-
fusion pumps, specifically those described above. These tering a number into a desktop calculator, for example.
simulations allow detailed exploration of the properties Conversely, incremental entry involves making a series
of the devices’ number entry systems, and comparisons of incremental changes to some displayed value in order
between different designs—there are many possible vari- to obtain the desired value — often but not necessar-
ations to experiment with, as described in more detail ily on a digit-by-digit basis. As incremental entry can
in the next section. In particular, several variants of the be implemented using just a few keys, typically
B.Braun Infusomat Space VTBI number entry interface , which may already be present for navigational
have been implemented. purposes, it is a common style on the kinds of medi-
cal devices we are interested in. As such, and as it is
Workshop annotation mechanism — We also in- used by each of our example devices, we concentrate
troduce the concept of state annotation as a research on issues surrounding this style, though serial entry is
tool to enhance collaborative critique of an interactive still interesting and appropriate further exploration, are
system. Members of this session will be able to add questions as to which style is preferable in general and
annotations to any states in the interactive simulations in particular situations, and why.
to identify or mark issues regarding the usability, safety
or design of the system being evaluated. Annotations Focusing on incremental number entry, we identify three
will be automatically saved with information about the major aspects of interest: basic behaviour (decade vs
current state of the system as well as the user interac- arithmetic, see figure 3); behaviour at minimum and
tions that led to that state starting from power up, and maximum values (see figure 4); and digit visibility.
are automatically shared among all clients connected to
the simulation. First we consider basic behaviour, which may be decade
55
3
or arithmetic style. In decade style, each digit is edited Minimum/maximum value handling
independently, and typically subject to wraparound at
0 and 9. For example, given a display of 1 9 2 . 4 ,
if the user hits , the new value is 1 0 2 . 4 —the Wraparound Clamped
9 increased by 1, modulo 10, wrapping round to 0, and
all other digits are unaffected. In this style the number
really must be dialled in one digit at a time. Absolute Stateful Invertible
In arithmetic style, user actions cause arithmetic modi- Figure 4. Number entry—boundary value handling
fications to the value displayed: add 1, subtract 10, etc.
On the Alaris GP there are dedicated up/down buttons
of differing magnitude; on the B.Braun and nav-
0 0 0 . This retains a clean conceptual model, but
igate between digits and and modify values. Re-
with the danger of allowing large numbers to be easily
peating the previous example in arithmetic style leads
to a display of 2 0 2 . 4 with the increment in the entered accidentally: a single takes us from an ini-
tens column being ‘carried’ to the hundreds. It is un- tial (and safe) 0 to 9 9 9 9 —though at least
clear if or when this would be preferable to users, though this is easy to undo.
one can imagine that for fine adjustments around some
More commonly, arithmetic interfaces restrict (‘clamp’)
value it is easier and would involve less / actions.
numbers to the boundaries. Here, we identify three
Either of these ‘starting points’ may be implemented approaches, which we call absolute clamping, stateful
using little code, and with very simple logic. (See our clamping, and invertible—see figure 4.
example simulations.) They each provide a clear con-
In absolute clamping, an attempt to move the value be-
ceptual model of the interface which users ought to be
able to fathom completely with very little experimenta- yond a limit stops at the limit. E.g., 9 9 4 5 then
tion. Edge cases are often where problems arise; thus, leads to 9 9 9 9 ; similarly, 0 9 5 3 then leads
what happens around the maximum and minimum val- to 0 0 0 0 . This is a fairly natural behaviour, easy to
ues? There are a number of subtleties, not immediately program and conceptually clear once discovered; how-
obvious. First: what are the maximum and minimum ever, as it throws information away it could be annoying
values? Either might be a function of what we can to users. In the face of annoyed users, a natural exten-
fit in the display (which might change over time — sion is stateful clamping where some state is introduced
see below), or some semantically-relevant value. The allowing accidental clamping operations to be undone.
minimum could be the negative of the maximum, or Here 9 9 4 5 then gives 9 9 9 9 but an imme-
(more often) zero, or something else. For VTBI en-
date restores 9 9 4 5 (without state, we would
try on the B.Braun, the minimum is either 1 or 0.1
depending on digit visibility (see below), and can only get 9 8 9 9 ); anything other than throws away
be zeroed by an exact operation. Thus, for example, the state and disallows the undo. This is how VTBI
entry on the B.Braun operates, for example.
0 1 . followed by leads to 0 0 . 1 (‘min-
imum’ value), whereas 1 . followed by leads In decade style and are inverses of each other,
to 0 . (true zero). This leads to some strange and it’s always possible to undo the last change easily.
behaviour and a messy conceptual model, and we are This is lost with absolute clamping, even with state,
presently unable to imagine any user-driven motivation
e.g. 9 9 4 5 then gives 9 9 9 7 not
for implementing this feature, though we note that 0 is
9 9 4 5 . An extension which seeks to fix this without
not an allowed value for VTBI (the OK button doesn’t introducing wraparound is to make all successful oper-
work when the display is 0). ations invertible. Here, if an operation would take the
value beyond its maximum or minimum, it doesn’t hap-
Assuming we know what the maximum and minimum pen, and this is indicated to the user via a beep (say).
ought to be, how should a device behave at those val-
ues? For the decade interface this issue can be ignored: Now 9 9 4 5 then leaves the value unchanged, but
the interface ‘wraps round’ naturally; one could in fact the user is alerted that this is the case. The more gen-
apply the following strategies in that context instead, eral rule is: any operation that does not have an inverse
but doing so breaks the conceptual model badly. has no effect other than a warning such as a beep; now
the user knows, if they hear a beep, the normal inverse
Arithmetic entry can also wrap round between min/max behaviour doesn’t apply; otherwise, they know without
values, but now we are wrapping on the total value, looking that they can undo the last operation.
not individual digits. Consider 0 0 0 on a display
The third general area of interest we identify is that
with boundaries at 0 and 9999, followed by ; this
of digit visibility, around which there are several re-
subtracts 100, taking us to 9 9 0 0 . Then un- lated issues. First, consider a decade-style system im-
does this, adding 100 with wraparound, returning to plemented in hardware — a physical device with one
56
4
● Following good practice, leading and trailing zeroes
are suppressed (shown as ). However, they behave
exactly like 0 in how they are controlled by .
● The number has upper and lower bounds (for the
Figure 5. An improved number entry interface in action. 5-digit example shown below, the bounds must be
within 0 to 999.99).
wheel per digit: spinning the wheel naturally wraps
around modulo 10 (indeed, we obtain the name ‘decade ● There is no hidden state. The behaviour of the inter-
system’ from such devices, which have one wheel per face is predictable from the display alone.
decade to be entered). On such a system, every digit is
always visible, which can lead to confusion: for exam- ● Sometimes keys cannot work: as shown the cannot
ple it can be hard to distinguish 0 8 0 . 0 0 from move the cursor further right; or if the display showed
0 0 0 . 0 0 . We are aware of two strategies for mit- 9 9 9 . 9 9 no digit could be incremented; and so
igating this: blanking leading/trailing zeros, and hiding on. Whenever a key is pressed that cannot do any-
digits entirely. The first strategy is obvious: only show thing, the interface beeps and otherwise does nothing.
significant digits. There are (at least) two questions (Thus adding 1 to 999.00 does not increase it to the
to ask: what to display for blank (a space? an un- maximum value 999.99.)
derscore?) and whether to ‘follow the cursor’ filling in
zeros prospectively (e.g. do you display 1 or ● Always, a key beeps or its effect can be cancelled by
0 0
1 ?); the cognitive implications of either choice pressing the opposite key: thus always and the
remain uninvestigated. On some systems we also see other 3 pairs do nothing unless the first key pressed
use of a second strategy, where digits are shown/hidden causes a beep, in which case the second key behaves
depending on the magnitude of the value being en- normally.
tered, usually on grounds of semantic relevance. For
example and in particular, for VTBI mL entry, the ● The rule above can be followed with the arithmetic
B.Braun hides the hundredths and then tenths digits style of interaction or with decade style. We prefer
if the hundreds and thousands digits (respectively) are the arithmetic style, since after pressing or the
n
non-blank (including while ‘following the cursor’ as de- number is always changed by ±10 or 0 if the key
scribed above.) Similarly, ten-thousands is only shown beeps. With the decade style, there can be a beep
if tenths is hidden. This is semantically sensible, but (if the number would hit a limit) or the number may
slightly disorienting to the user as the display is always change either by ±10n (most often) or at most ±9×10n
right-aligned, so sometimes one digit disappears, an- (about 1 in 10 times); this behaviour is much less
other disappears, and the whole thing shifts to the right. predictable.
Related to this: is the decimal point visible if no frac-
tional digits are filled in? Canada’s Institute for Safe
● Hence, work on arithmetic; that is, they al-
Medication Practices (ISMP) says it should not be — ways add ±10n to the displayed number (n depend-
and also mandates reducing the size of fractional digits, ing solely on the cursor position), or they beep (and
to more clearly distinguish 5.0 from 50 (say); changing otherwise do nothing) if ±10n would have resulted in
colour may also be a worthwhile tactic here [3]. On the overflow.
B.Braun, the decimal point is visible while the tenths
column is visible, whether it is empty or not. ● The design generalises readily, for instance to times
by using different bases for each digit (i.e., base 10,
We’ve identified a large design space for the apparently 10, 6, 10 respectively, with an upper bound of 2359).
simple question of incremental number entry; the task
remains to identify the trade-offs each of these choices ● If the application requires a movable decimal point,
involves, and how they affect the conceptual mappings
then pressed when the cursor is in the right-most
users build between their actions and their effects.
column and the left-most digit is then the decimal
point will move left (and conversely for ). This
6. A SAMPLE BETTER INTERFACE?
behaviour ensures no significant figures are ever lost
Figure 5 shows a working mock-up of a potentially bet-
and that the decimal point is always shown within the
ter user interface, to be operated by keys display. Again, the precision is limited by bounds and
as on the B.Braun. It has several interesting features: if the decimal point cannot move, then the key beeps.
● The cursor (shown on the right-most digit position) Starting with the example on the left in figure 5: press-
and the decimal point are highly salient.
ing (beeps and otherwise does nothing) then
● Digits to the right of the decimal point are high- obtains the view on the left in figure 5. Notice
lighted and smaller. The decimal point remains but number carry, moved cursor and changed decimal point
is dimmed when the decimal digits are zero. style.
57
5
7. DISCUSSION AND FUTURE WORK 8. CONCLUSIONS
Our aim here is to start debate and exploration of these Interactive number entry is deceptively complex, and
issues; future work is to continue that systematically. particularly for dependable applications — medicine and
Here we identify some key challenges and opportunities. healthcare — must be done well on the basis of a thor-
ough analysis of requirements. This paper has therefore
A problem with work of this sort is that seemingly sen- explored the related design issues and principles, and
sible design properties have unexpected impacts on how through case studies and analysis, developed potentially
users behave. Therefore the workshop must help iden- more dependable approaches. Ideally after appropri-
tify issues for empirically-based research. Consider, for ate empirical testing (particularly in real environments)
example, the ‘undo’ design heuristic recommended by and iterative design, this work will lead to a definitive
Nielsen [4]. How might we arrive at a more detailed approach for dependable number entry.
set of properties for programmers of medical devices?
Let us suppose we start by asking the following two re- 9. ACKNOWLEDGMENTS
search questions: 1) Is the ‘undo’ heuristic a significant Funded as part of the CHI+MED: Multidisciplinary
affector for both serial and incremental number entry Computer-Human Interaction research for the design
in terms of error rates? 2) Are error rates on systems in and safe use of interactive medical devices project, EP-
the same ‘class’ effected in similar ways by the level of SRC Grant Number EP/G059063/1 and Formally-based
undo offered? Formally-guided experimental investiga- tools for user interface analysis and design, EPSRC
tion could help answer these questions. To avoid empir- Grant Number EP/F020031/1.
ical experimentation on every possible variant of num-
ber entry, we might identify a set of distinct ‘centroid-
cases’ (specific variants representative of some ‘cluster’ 10. REFERENCES
of similar variants), by preliminary exploration via a 1. D. P. Brumby, D. D. Salvucci, and A. Howes. Focus
formal model of human-device interaction; this process on driving: how cognitive constraints shape the
could also produce a suitable feature-set for classify- adaptation of strategy when dialing while driving.
ing different kinds of number entry system, formalising In Proceedings of the 27th international conference
and completing the taxonomy suggested above. The re- on Human factors in computing systems, CHI ’09,
sults from experimental investigation following the for- pages 1629–1638, New York, NY, USA, 2009. ACM.
mal modelling step would give a more precise descrip- 2. R. Hourizi and P. Johnson. Unmasking mode
tion of the trends seen for these determining features of errors: A new application of task knowledge
keypads with respect to ‘undo’ and error-rate. principles to the knowledge gaps in cockpit design.
In Proceedings of Interact 2001, 8th IFIP TC Conf.
The question of how users’ mental models of number en- on Human Computer Interaction. IOS Press, 2001.
try systems develop and relate to the developers’ models
and the code they write, is of particular interest. We 3. Institute for Safe Medication Practices. List of
propose that users of medical devices largely develop error-prone abbreviations, symbols and dose
their mental models of device behaviour through inter- designations. www.ismp.org/tools/abbreviations,
action with the devices themselves, and by existing con- 2006.
ventions; how can devices be designed to optimise this
learning process, guiding users to the ‘golden path’ ? 4. J. Nielsen. Usability Engineering. Morgan
Kaufmann Publishers Inc., San Francisco, CA,
This paper has mainly described incremental interfaces; USA, 1993.
serial entry of course also needs to be explored. The re-
lated task of time entry is also critical and worthy of 5. J. Reason. Human error: models and management.
attention. For example, in the B.Braun most of the in- BMJ, 320(7237):768–770, March 2000.
terface principles of the VTBI and Rate number entry 6. H. Thimbleby and P. Cairns. Reducing number
interface are found in the time entry interface: pre-set entry errors: Solving a widespread, serious problem.
maximums and minimums, jumping to the minimum if Journal Royal Society Interface, 7(51):1429–1439,
the edited number is less than the minimum, for exam- 2010.
ple. Interestingly, if the VTBI is set to 99999 and we try
to set the time, when we press on any position the 7. J. Zhang, V. L. Patel, T. R. Johnson, and E. H.
time jumps up to 83:20; we remain unable to explain Shortliffe. A cognitive taxonomy of medical errors.
this behaviour. J. of Biomedical Informatics, 37:193–204, June
2004.
58
6