EHR Safety

Now is a good time to discuss EMR/EHR safety. The HIT Policy Committee Certification/Adoption Workgroup will be holding a public meeting on HIT Safety on February 25. An impressive group of experts has been assembled to present testimony on this important issue. Much of the literature on EHR safety to date suggests that electronic record systems are safer than a paper-based approach. Yet a few dissenting articles point to the potential for new types of errors and unintended consequences caused by EHRs. One article out of the University of Pennsylvania that stimulated a lot of conversation on the topic was published in JAMA in 2005. I will discuss some of the potential reasons that EHRs could cause errors below.

Software Design: This is probably the most apparent cause of errors. Many of us have had the experience of working with software that was released before all bugs were corrected. For many applications, this can be an annoyance, can delay work, and make us angry, but usually the result is not life-threatening. On the other hand, patient care software must be perfect out of the box. Even a single incidence of imperfect programming can be fatal. Software engineers for EHR applications have to be perfect.

Adults vs. Children. An area in health IT where system design is a recognized safety issue is pediatric care. This belies the truism that kids are not just small adults. Medication administration, blood product transfusion, and lab result interpretation are areas where the treatment of children and infants is different from that of adults. Medication doses are often quite different for pediatric patients compared to adults and need to be adjusted for body weight and organ function (dose adjusted based on lab results.) A criticism of many EHRs is that they don't account for these differences or at least make it difficult to address the pediatric requirements (drug alerts needs to be set up differently, a correct body weight must be available to the pharmacy system, the correct units of measure must be used.) Some pediatric hospitals have designed or contracted for pediatric-specific software.

Regression errors. We all know that EHR software is updated periodically (often an 18-24 month cycle.) When updates are installed, they are usually tested in a non-production environment to make sure they work as designed. Occasionally the updates can cause changes in function that result in errors that were not present in the earlier version of the software. This is more likely when disparate component systems are interfaced to create an enterprise EHR. Special attention must be given to such interfaces when upgrades in software are made. Regression testing to test for this type of error adds to the administrative overhead for system operators.

User Interface: I realize that the graphic user interface is really part of the system design but the emphasis here is on human factors engineering rather than computer science. Usability is the feature we are concerned with here. Consideration of human perception, workplace environment, and human-machine interactions are essential to the design of computer systems that will be used in the health care space. I addressed some common usability issues in a previous post (Nov. 22, 2009.) Critics of electronic medical record systems often cite poor usability as a factor that has contributed to the slow adoption of EHRs by clinicians. Representative examples are: some systems make it easy to click the wrong radio buttons; the need to scroll excessively; having to click through multiple pages to complete a task; inappropriate use of color; alert fatigue; and difficulty to easily undo unintended actions. A good case could also be made that inadequate attention paid to software usability explains some of the safety risks inherent in the use of EHRs. The aircraft/airline industry, on the other hand, has devoted extensive resources to human factors engineering in its successful effort to improve the safety of flight.

Standards: Standards are important to enable interoperability. Further, interoperability is necessary for the electronic transfer of patient specific health information from one provider to another. Information transfer is especially important to the safe care of patients during transitions of care. Many of the extant proprietary systems were not designed with information exchange in mind.

The ultimate goal is semantic interoperability-the ability to exchange information in a format that preserves its original meaning. This has been and will continue to be a problem in health IT. Often standards are written without published implementation guides to explain how to use them. Standards harmonization is not an easy task, is labor intensive, and it is often difficult to achieve solutions that are easy to implement.

Congress recognized the importance of the use of standards in health care IT in the composition of the ARRA legislation of 2009. The recent Interim Final Rule (IFR) on Certification and Standards is the most recent guide to the federal effort to influence standards in health IT. Whether the IFR fulfills the needs of the U.S. health care IT industry is a current topic of hot debate among the various stakeholders.

Clinical Decision Support: Decision support capabilities directly relate to patient safety. Alerts and warnings must be configured properly and implemented appropriately. Expert clinician input is essential. More complex decision support systems, especially those based on evidence-based guidelines are potentially problematic. The challenges become apparent when converting written guidelines to their electronic equivalents. Also, experience has shown that some clinical decision support systems may be sensitive to different geographic environments. Clinical outcomes when these systems are used are not totally predictable across different regions or cultures. Furthermore, many clinical decision support systems are necessarily customized to local policies, procedures, and clinical expertise of the clinicians so each implementation becomes unique.

Security, Privacy, and Infrastructure: These categories also have a significant impact on patient safety. A few examples will be discussed here.

First, let's start with patient identity. Positively identifying patients is essential to the provision of appropriate clinical care. Patient identification in the U.S. is hampered by lack of a nationwide patient identity system. This will become a more critical issue in the near future when cross-community exchange of patient information becomes a reality. Making sure the right records are associated with the right patients will become increasingly difficult as the number of patients included on master patient indices grows. Complicating this issue is the growing threat of medical identity theft.

Clinical IT systems, like other computer systems, are vulnerable to malware, malicious employees, and even cyber-terrorism. Risk assessment and risk mitigation will need to become more robust in the health care IT industry. Larger organizations with specialized IT teams are generally more capable of dealing with these threats than small clinician practices that function without such sophistication.

A final area that has not received adequate attention is data integrity. We need to be sure that data entered into systems is not inadvertently or intentionally changed inappropriately. More widespread use of technical safeguards to assure data integrity will be needed to protect critical clinical information systems. I expect that future iterations of the IFR will include requirements for digital signatures or similar technologies and non-repudiation of origin for producers of clinical data.

Above, I have discussed some topics that I think are important for the safe use of IT in health care environments. It will be interesting to listen to the testimony before the policy committee workgroup on Thursday to learn what their take is on EHR/EMR safety.