the other hand, the iPhone is a new approach, so it might not work as well as expected without further development.

Using a conventional calculator, a dose calculation would report very few errors—perhaps an accidental division by zero. It would just display “E” (and a wrong number) when there is an error. Unlike conventional calculators, the iPhone provides a clear explanation and, importantly, no number that could be misinterpreted is displayed. Using the iPhone for the calculation above, potentially 52 errors can be detected, and some are detected during incomplete steps, such as when the nurse is entering 45.57 but has not yet entered the decimal portion of 57.

On the iPhone, a nurse cannot easily do the wrong calculation, whereas on a conventional calculator, it is easy to hit + instead of ÷ and never notice. The iPhone has no operators, and therefore the user cannot employ the wrong ones. The iPhone also uses correct units (mg and so on) and checks that they are used consistently; a conventional calculator has no idea about units and cannot help the user avoid errors related to them (say, mixing up milligrams and micrograms).

To make numbers easier to read, the iPhone shows a clear decimal point with the decimal part smaller, as in 45•57 (see Figures 3 and 4), and large numbers are shown with commas (another recommendation the fluorouracil bag ignored), as this reduces confusion between numbers like 100000 and 1000000. (I don’t currently require users to enter commas; it would be an interesting study to see if their use would reduce errors.)

If the calculator communicated with the electronic patient record, all numbers could be automatically provided—hence, correct— or they could be confirmed by the nurse rather than entered manually. This would avoid transcription errors. If protocol requires nurses to be responsible for calculations, the iPhone could show a checksum for the correct answer: The bag label would say something like “if you don’t get X5Q [the checksum], you’ve got the wrong answer.”

Regulatory bodies should also be vigilant in preventing problematic designs from being approved. Interaction is complex: Program specifications and source code must be checked using formal tools, otherwise inconsistencies and other problems will not be detected (this is a fundamental theorem of computer science). This article addressed “simple” problems with numbers, but no usability study can ensure that all numbers, both well-formed and erroneous, are handled correctly. (And number entry isn’t the only design feature that needs checking.) In short a usability study can help check that a design is appropriate for users and their tasks, but the entire design must also be checked by formal methods. Quality assurance has to be done in the beginning using rigorous manufacturing processes, not later by regulatory bodies or by hospitals—or by users finding the bugs.

There are many more ideas; changing culture is never easy, and it will require many approaches. Lives depend on us.

For more information, I’ve begun to put some resources together at http://harold.thimble-by.net/health.

Conclusions

It is astonishing that a life-threatening problem that has been recognized for a century has had such little impact on interaction design. Why are basic errors ignored by interactive medical devices? As the iPhone showed, better interaction programming is easy to explore.

We could save many lives if we made people aware that poor interaction programming is a significant factor in medication incidents. Lawyers who represent patients and clinicians need to know more. We already have many good recommendations to improve design [ 6]; this article has argued that these recommendations should also be applied to the details of interactive design.

Investigatory bodies, analyzing incidents, must include people trained in HCI. This has already started, and the role of ergonomics and human factors is increasing, but expertise in interaction programming is essential too. It should be normal for manufacturers to employ programmers with appropriate postdoctoral specialist qualifications—just as pharmaceutical companies do.

[ 6] United Kingdom Department of Health. Design for Patient Safety, 2003.

ABOUT THE AUTHOR Harold Thimbleby wrote Press On: Principles of Interaction Programming, which won the American

Publishers Association best book award in Computer and Information Sciences in 2007. Press On has more design recommendations for interactive devices, not just medical devices. Harold is a Royal Society-Leverhulme Trust Senior Research Fellow, and the work here was also supported by EPSRC Grant EP/ F020031. See harold.thimbleby.net.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without the fee, provided that copies are not made or distributed for profit or commercial advantage, and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on services or to redistribute to lists, requires prior specific permission and/or a fee. © ACM 1072-5220/08/0900 $5.00

September + October 2008

DOI 10.1145/1390085.1390098