An Evidence-Based Tool for Safe Configuration of Electronic Health Records: The eSafety Checklist
I applaud the article in Applied Clinical Informatics, “An evidence based tool for safe configuration of electronic health records: the eSafety checklist” by Pritma Dhillon-Chattha et al.[1] It is a comprehensive analysis of efforts to identify and avoid errors associated with electronic health record (EHR) implementation and use. The authors are inventive in developing their checklist: First, they conducted a literature review from which they derived 870 items. Second, and unique for this type of work, they sought to make the list usable via a full toolkit of human factors/human–computer interaction techniques. That latter step is especially noteworthy since lack of usability is an overwhelming complaint by EHR users. Having an unusable checklist to improve EHR safety would be adding, literally, insult to injury. Third, they validated the list with experts.
The authors acknowledged the reality of large-scale and usually unreported errors associated with EHRs. Indeed, as they and others have found, most EHR-related medication prescribing errors are unknown and often unknowable.[2] This diminishes neither the EHRs' myriad benefits nor the need for the authors' work. However, it reiterates the obvious point that something useful can also be made safer and more efficient (think cars, computers, or baby furniture).
So what generates a letter about such good work? There are two reasons.
Reason One: Why is this very long list the responsibility of the clinicians and medical facility information technology people? So many of these safety concerns could have been eliminated, made less difficult to fix, and less dangerous if the makers of the EHRs had focused on better usability, safety, interoperability, integration with other systems, and, perhaps most importantly, on data standards. Even when we acknowledge that EHR software is complex and is sold to facilities with different legacy systems and varying implementation skills, it remains true that many of these safety problems are of the vendor's making. Vendors fought data standards for decades because they wanted to sell suites of products that worked together but excluded the products of other vendors.[3] Also, it was costly for vendors to change the data standards used in their existing systems. The result of their intransience is now our and our patients' problem, but vendors remained resistant to accepting the need for more usable systems, insisting that usability was too subjective too be measured, was the “fault” of poorly trained or inexperienced clinicians, was entirely theoretic, and was not their problem.[1]
As pressures have become unrelenting, vendors are now “singing” the praises of usability. However, this reflects vendors' recent conversions. My concern is that the good work of the authors reflects poorly designed vendor systems that should not need all of this work and these safety interventions in the first place. The hazards become even more painful when we remember that it is the clinician, who is most often held responsible for the resulting errors.
Reason Two: Independent of who is responsible for fixing the vendor systems, the list's daunting number of items (870) is prima facie evidence that the EHRs are remarkably primitive in design, construction, and applicability given their cost and life-critical role. These systems can cost hundreds of millions of dollars even before the cost of implementation; and implementation is usually approximately 3 to 5 times the cost of the software. Put simply, the length of the list is itself frightening. As a thought experiment, imagine if you went to buy a car and you received a list of almost a thousand items which required your attention—sometime years of work—before you could safely drive the vehicle. Yes, I appreciate the analogy is faulty. However, the reader must appreciate that the list—while a valuable guide to reducing errors—is proof that installing and using an EHR is perilous. It should not be, and the list should be significantly shorter.
Neither of my two concerns should reflect negatively on the work of these authors. In a sense, my concerns highlight the need for their work.
