There was an interesting thread recently on the listserv for the National Patient Safety Foundation on whether medication barcode readers should beep (or make some other noise) when read. Such systems are typically part of medication “verification” and serve to populate the electronic health record. Since the medication administration remains manual in most cases, the barcode interaction can be different from what actually occurs.
Some of the responses provided interesting examples of the value and confusion created by device noises in general. One overriding issue is a lack of standardization when it comes to different systems and the meaning of sounds. As a result, when staff members move from one facility to another, as many regularly do, they are presented with different system behaviors for what should be simple and standardized functions. This variability can lead to the classic exchange in which a new user answers “Yes” when asked, “Do you know how to use an XYZ?” But when asked, “Do you know how to use this XYZ?” the answer might be, “No, I’ve never used that one before.”
There was also the fundamental issue of whether adding more noise to the patient environment is a good idea, especially at night or during other periods of desired rest. As one person noted, “One more alert was not what was needed.” Only one respondent mentioned trying to disable the beep, but that effort was frustrated by the sound returning when the system was reset, which was done regularly. More basic is considering what the beep should mean and what it actually does mean. It seems to me that a single beep (if used) should be heard only on either a successful read or a failed read, but not both. However, it was reported by users that some systems beeped identically for both good and bad read attempts. If you insist on designing a system with a noise for yes and a noise for no, how hard is it to create sounds that are different and therefore informative to at least experienced users? In one case, there was also a green light that flashed—both for good reads and errors. It was also reported that the beep in general could not and should not be relied to indicate that the proper record had been created. The recommended practice was to always visually read the medication record entry to confirm the recorded transaction, regardless of any beeping. While this may be good advice, of what value then is the beep (or light)? Perhaps it helps you manipulate the barcode reader until you hear something before you divert your attention to the computer screen to find out what that something was.
This scenario highlights two important points. One is that the design of medical devices, in this case as it relates to the beeps, has often been criticized for being the creation of engineers who do not have a practical understanding of the clinical environment. As a result, devices can challenge users rather than enhance the performance of their tasks. A related notion is that just because you can add a feature to a medical device doesn’t mean that you should. The feature may, in fact, be deleterious. The second issue is the lack of standardization among different devices that do basically the same thing. This includes the inclusion or omission of one or more beeps, and how one noise can be distinguished from another.
William Hyman, ScD, is professor emeritus of biomedical engineering at Texas A&M University. He now lives in New York where he is adjunct professor of biomedical engineering at The Cooper Union. Hyman may be contacted at firstname.lastname@example.org