This case study is the first of six cases used to illustrate aspects of EMR use that pose risks to patient safety. The risks discussed in this case pertain to EMR hardware and software failures. As with most EMR-related problems, the majority of patient safety issues associated with hardware/software failures can be traced back to controllable factors. The safe and meaningful use of EMRs is facilitated by awareness of these risks and controllable factors.
Case Study: At 0900 physicians in hospital-based ambulatory offices were suddenly unable to access their web-based EMR. The hospital’s IT Service Desk reported a wide outage of internet access due a “hardware failure” and the estimated time of repair was “unknown”. The offices activated their paper-based downtime plans, but many patient safety issues were encountered. For example, physicians were solely dependent on the patient’s recollection of allergies because they had no access to allergies recorded in the EMR. A process was developed “on-the-fly” to use a laptop with mobile broadband connectivity to access the EMR, but before these were ready the original problem was resolved at 1130. It was discovered that an IT employee installed a planned “Windows update” to the hospital’s networking hardware that morning with unexpected results. After the problem was identified the update was “backed out” and the problem resolved.
Key Points:
Access to secure and reliable patient data in an EMR is dependent on hardware and software that is properly sized, configured, managed and functioning. Power outages, running out of data storage space, network outages, software conflicts, malicious intrusions and computer device failures are examples of technical problems that threaten safe use of EMRs. Most technical problems, however, are preventable through proactive IT management. For example, an old computer that burns out could have been prevented by proactively replacing old technology equipment at specified intervals. Reputable IT experts know the “best practices” for proactive IT management (such as ITIL and COBIT). In this case basic change management practices were not followed. Physicians should make sure that their EMR hardware and software, whether physically located in their office or located elsewhere, are proactively managed by reputable IT experts.
- Physicians are responsible for developing “downtime plans” that describe how the office will safely care for patients when the EMR is unavailable
HIPAA requires patient data to be “backed up” and physicians need to be able to restore their EMR in the event of a complete hardware or software failure such as a flood, tornado or fire that destroys computer equipment and software. “Disaster planning” addresses these needs and primarily requires the EMR vendor’s technical expertise and advice. “Downtime plans”, on the other hand, primarily need the physician’s expertise to define what needs to happen in order to safely care for patients (what I call clinical continuity) and maintain business operations (commonly referred to as business continuity) when the EMR is unavailable. Downtime planning should identify the critical patient data that is needed when the EMR is down and have written procedures on how that data will be accessed. The plans should also describe procedures for the use of downtime paper forms for patient care tasks, medical record documentation and practice operation tasks (appointments, claims and billing) as well as what to do with them after the downtime.
- “Mock downtime drills” are an effective way to determine whether an office is prepared for an EMR downtime
In this case the physicians deserve applause for developing written downtime plans. However, if they had previously simulated a downtime, then they would have been prepared with back-up laptops ready and available. Although mock drills in themselves create risks, they are much more controllable than the risks inherent to unplanned EMR downtimes.
Comments