William A. Hyman
Professor Emeritus, Biomedical Engineering
Texas A&M University, w-hyman@tamu.edu
Read other articles by this author
Alert fatigue as it is now described arises from the excessive or otherwise ineffectual presentations of advisories while using an EHR. Alert fatigue parallels another common problem which is audible alarm fatigue from medical devices. In both of these more is not necessarily better, and might be worse. More generally alert and alarm fatigue demonstrate that what may nominally seem like a good idea can be hard to reduce to useful practice while also avoiding unintended consequences.
Alert and alarm fatigue also share that they are at least in part a design problem in that how the alert or alarm affects their usability, as does deciding on when to issue an alert or an alarm in the first place. It is noteworthy then that the people building the systems that generate the signals are for the most part not the ones that have to deal with–or not deal with–the signals when they occur. This cultural disconnect has been cited by The Joint Commission which urged that developers and users actually work together in designing systems, whether hardware or software. Fatigue from one system can also degrade other activities that are not directly related to that system as a result of a generally debilitating effect.
In this context AHRQ has issued a “primer” on the subject of EHR alert fatigue. It notes that EHR alerts arise primarily from drug ordering and other clinical decision support (CDS) systems. AHRQ says that the research shows that alerts are only modestly effective at best in improving the care process. In this regard the reported reduction in prescribing errors arises from supporting the prescribing process itself rather than flagging possible errors. In addition it has been shown that clinicians generally override the vast majority of CPOE warnings. What is not said here is the degree to which the user is correct in doing so. If they are correct then the alerts would seem to be giving them information that is wrong, which has to be the worst kind of alert. If they are incorrect then it means the theoretical value of the alert is not being met, largely as a result of alert design in the context of their excessive numbers. It can also be expected that the routine practice of ignoring alerts is self-propagating, especially as increasing numbers of alerts arrive. The AHRQ reports an anecdote in which a physician was directly advised by colleagues to in general ignore alerts.
When errors are made the alert situation can often be recreated, or the EHR may store the actual events. Therefore when a physician has made what is alleged to be an error despite an alert this may be easily shown, and perhaps used as evidence in a resulting injury claim. The “I never read the alerts” defense will perhaps not be attractive, although in other contexts the “I never read the instructions” excuse is surprisingly popular. An interesting twist on process improvement cited by AHRQ is that once an alert has been designed in developers will be reluctant to take it out lest the absence of that alert become an issue in some subsequent event. The same reasoning can drive providing ever more alerts to avoid an observation that the system provided an alert about this but not about that. On the proverbial other hand, excessive alerts could also be attacked as bad design and therefore subject to compensation claims. Parallel issues occur in alarms in which each manufacturer creates their own alarms without practical regard for the effects of multiple devices from various manufacturers each having multiple alarms. This has lead to local or third party efforts to clean up the mess by creating some level of alarm integration. The multi-vendor alarm problem is not the primary cause of EHR alert fatigue since the EHR is for the most part the product of a single vendor. Even if it does include components from other sources there is still a single integrator who could exercise control.
Another parallel between alerts and alarms is the possibility of building in severity as part of how or if an alert or alarm is presented. This too battles against the resistance of the developer to make and defend such determinations. This resistance is in contrast to another component of CDS defense which is in effect that you weren’t supposed to rely on it in the first place, ie the clinician always has to make their own independent judgment. This too might drive the practice of largely ignoring alerts.
The AHRQ post ends with the ever popular aviation analogy, in this case cockpit design and alert selection and signaling. One might note that a cockpit is designed by a single entity with a high degree of standardization between aircraft and with narrowly focused users. This is quite different from healthcare. Moreover a jaded observer has noted in the past that pilots have a better tuned safety perspective than the one that occurs in healthcare because in a plane crash the pilot dies too.