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