Implications of electronic health record downtime: an analysis of patient safety event reports

Abstract

Objective

We sought to understand the types of clinical processes, such as image and medication ordering, that are disrupted during electronic health record (EHR) downtime periods by analyzing the narratives of patient safety event report data.

Materials and Methods

From a database of 80 381 event reports, 76 reports were identified as explicitly describing a safety event associated with an EHR downtime period. These reports were analyzed and categorized based on a developed code book to identify the clinical processes that were impacted by downtime. We also examined whether downtime procedures were in place and followed.

Results

The reports were coded into categories related to their reported clinical process: Laboratory, Medication, Imaging, Registration, Patient Handoff, Documentation, History Viewing, Delay of Procedure, and General. A majority of reports (48.7%, n = 37) were associated with lab orders and results, followed by medication ordering and administration (14.5%, n = 11). Incidents commonly involved patient identification and communication of clinical information. A majority of reports (46%, n = 35) indicated that downtime procedures either were not followed or were not in place. Only 27.6% of incidents (n = 21) indicated that downtime procedures were successfully executed.

Discussion

Patient safety report data offer a lens into EHR downtime–related safety hazards. Important areas of risk during EHR downtime periods were patient identification and communication of clinical information; these should be a focus of downtime procedure planning to reduce safety hazards.

Conclusion

EHR downtime events pose patient safety hazards, and we highlight critical areas for downtime procedure improvement.

INTRODUCTION

Electronic health records (EHRs), adopted by over 88% of hospitals as of 2015, have the potential to improve patient safety and quality of care.^1,2 Many health care providers have become reliant on this technology for viewing patient records; ordering medications, labs, and diagnostic tests; and receiving clinical decision support to guide the care process.³ Enhanced safety features compared to paper records, such as alerts when patients are prescribed medications they may be allergic to, are becoming standard in EHRs, and prescribing clinicians are becoming more dependent on these features.^4–6

One challenge with computer-based patient records and other functions that support the care process is that computer systems and software can be unavailable at times. Health care providers experience software downtime periods, when some or all functions within the EHR are unavailable.⁷ Downtimes can be planned, when regular maintenance and updates to the EHR are performed, or unplanned, due to equipment failure, power outages, or cyber-attacks.

Downtime events, particularly unplanned ones, have the potential to result in serious patient safety risks, since EHR functionality and critical patient information, which are needed for effective care delivery, are unavailable.^8–10 Further, alerts and other safety mechanisms of EHRs that clinicians may have become dependent on are unavailable during downtimes. The Office of the National Coordinator of Health Information Technology has recognized the risks associated with downtime and has sponsored development of the Safety Assurance Factors for EHR Resilience (SAFER) guides, which provide high-level guidance and recommend that downtime procedures be put in place and practiced.^11,12 Other research presents suggestions on how to cope with downtime, and while there are worthwhile suggestions, such as using redundant hardware and developing procedures, there is still little to no guidance on what specific downtime procedures should be put in place and where downtime safety hazards exist in the care process.^13,14

To begin to understand the impact of EHR downtime on patient safety, we analyzed patient safety event reports during downtime events to determine their impact on the care process. Most health care systems use a patient safety event reporting system that allows front-line staff to report on safety hazards.^15,16 The reports may contain information on near-misses, where harm almost reaches a patient, and on adverse safety events, where harm reaches the patient.¹⁷ The safety reports generally contain structured data, such as the patient’s name, the site of occurrence, the role of the reporter, and a categorization of the severity and type of event. In addition, the report allows the reporter to input a free-text description of the event, which generally provides more context around the safety hazard.¹⁸

OBJECTIVES

Our objectives were to identify safety reports that were downtime-related and analyze the free-text event descriptions to better understand how downtime affects care processes, which ultimately contributes to patient safety. A code book was developed to describe the clinical care processes that were affected by downtime, and the reports were coded to understand trends and major risk areas.

MATERIALS AND METHODS

Patient safety event data

We examined patient safety event data spanning 3 years from a large health care system in the mid-Atlantic region of the United States. The health care system has 6 different EHRs in place, with a single EHR from a major vendor for most inpatient services. The health care system includes urban, suburban, and rural hospitals. We searched 80 381 patient safety reports collected from January 1, 2013, to January 10, 2016, to identify those that were downtime-related.

The health care system has a single event reporting system, and we focused on the free-text descriptions that were entered by reporters and any additional resolutions or recommendations entered by supervising staff. Supervising staff includes patient safety officers, risk managers, and department leaders who generally review most reports. While there are harm level scores associated with each report, these scores are recognized as being inaccurate, since the reporter often does not know the long-term impact of an incident. Consequently, we did not analyze harm scores as part of this research effort.

Downtime event identification

A list of downtime-related keywords was developed and used to query the free-text description fields in each report. The keywords were: downtime, planned, unplanned, error, help desk, computer, system, outage, vendor name 1, vendor name 2, vendor name 3, vendor name 4, vendor name 5, vendor name 6, network, server, and connection. These were selected based on our manual review of several reports, where we identified these keywords as likely to be mentioned in a downtime incident report. For example, one reaction to downtime is to call the main help desk to determine suspected cause and expected downtime length. The vendor names were selected based on knowledge of the EHR systems implemented by the target organization. The keywords, except the vendor-specific names, could be generalized to any set of event reports to identify downtime events. The free-text descriptions entered by reporters and resolution/recommendation fields by supervisors were searched to determine whether they matched any keywords. In addition, we examined downtime logs to identify known downtime periods. The patient safety event reports entered during these periods were also examined to determine whether they were explicitly downtime-related.

Coding

Because the keyword search resulted in some reports that were not actually downtime-related, a single reviewer first examined all retrieved events to identify those that were explicitly downtime-related. After removing events that were not downtime-related, both reviewers examined a subset of events to formulate a code book that identified and defined the clinical processes affected by downtime. In accordance with the grounded theory approach, this code book was applied to a new subset of data, and the coding was discussed in order to iteratively develop the full code book composed of clinical processes that emerged from the reports (Table 1).^19,20 This approach was used by the authors in previous research.²¹ After the code book was established, 2 reviewers examined all of the explicit downtime events independently and coded them according to the code book.

Table 1.

Clinical care processes impacted by downtime

Care Process	Subcategory	Definition	Frequency of Occurrence
Laboratory	Patient Identification	Improper continuity of patient identification from collection to testing	9
	Lab Ordering	Complications in order placement and receipt	2
	Specimen Labeling and Tracking	Specimen misplaced or mislabeled	11
	Results Reporting	Transmission of results from laboratory to clinician	8
	General	General descriptions of downtime issues with lab (eg, lab results slowed due to downtime)	7
Imaging	Image Ordering	Complications in order placement and receipt	1
	Image Transfer	Relaying image to necessary staff for interpretation	1
	Results Reporting	Transmission of imaging study results to clinician	2
Medication	Issue Entering Order	Placement of medication order disrupted	3
	Administration	Includes: delay, wrong dose, wrong medication, and medication tracking	8
Patient Registration		Issue caused patient registration to be disrupted or incomplete	4
Handoff/Transfer of Patient		Issue transferring or handing off patient at shift change	4
Documentation		Unable to document patient information	3
History Viewing		Unable to view past patient information	1
Delay of Procedure		Delay in medical procedure due to downtime	2
General Delay of Care (No specific process mentioned)		Incident reports describing overall difficulties with downtime operations without specific details (eg, downtime caused delays in patient care)	10

Incidents where the brief, resolution, or recommendation field indicated the potential to fit into multiple categories were coded based on a single primary clinical process. For example, a report that describes a patient who was unable to be properly registered into the EHR and then experienced a delay in receiving medication because of the registration issue would be coded to “Patient Registration,” since this issue likely resulted in the medication delay.

In addition to classifying the description of the incident into a care process category, we also coded each event for whether a downtime procedure was followed or not followed, if that information was available in the report. The details of this coding process are presented in Table 2. Any disagreements regarding the coding of the events were discussed and resolved.

Table 2.

Downtime procedure adherence

Code	Definition	Frequency of Occurrence
Yes	Report indicates downtime procedures were properly and successfully executed.	21
Insufficient Information	Report content does not mention downtime procedures, so no conclusion could be drawn.	20
Failure	Downtime procedures described and improperly executed, or it is explicitly mentioned that no downtime procedure exists.	35

RESULTS

Overview

The database query resulted in 7357 reports, and initial review for reports that were explicitly downtime-related yielded 76 incident reports. These events were independently categorized by 2 researchers, and an interrater reliability analysis resulted in a Cohen’s kappa of κ = 0.86. There was initial disagreement on which care process was involved with 10 incident reports, resolved through discussion to reach consensus.

Overall, the Laboratory category had the greatest number of reported downtime incidents, accounting for 48.7% of reports (n = 37), followed by Medication Administration with 14.5% of reports (n = 11). The complete breakdown of categories can be seen in Figure 1 .

Figure 1.

Downtime Incident Category Breakdown (n = 79).

Analysis of incident categories

Laboratory-related incidents

Incidents causing laboratory delay were the largest category of downtime incidents, at 48.7% (n = 37), which was divided into subcategories. Occurring most often was a breakdown in the labeling and tracking of specimens (29.7%, n = 11), followed by a lack of continuity of patient identification from the point of specimen collection to delivery to the laboratory (24.3%, n = 9). Transmission of laboratory results (21.6%, n = 8) was the next most frequent subcategory. Laboratory-related issues during downtime often resulted in specimens having to be redrawn from patients and delays in reporting of results.

Medication-related incidents

Medication Issues, the second most common category, accounted for 14.5% of downtime reports (n = 11). Administration issues were most common, making up 73% of medication issues (n = 8). Administration issues included wrong dose and wrong medication. Medication ordering issues were also present in 27% of reports (n = 3) in the Medication category. These issues included incomplete information on the order forms and difficulties in calculating the dose to be ordered.

Imaging-related incidents

Of the downtime incidents, 5.3% (n = 4) were related to imaging. One report (1.3%) was related to image ordering and described selecting the incorrect X-ray order during a partial downtime. One incident report (1.3%) related to difficulties transferring images to the EHR, and 2 reports (2.6%) were related to results reporting and described delays in communicating results to the ordering physician.

Documentation-related incidents

Documentation-related incidents accounted for 3.9% (n = 3) and were events where downtime prevented charting or made it more difficult, including editing previous notes.

Patient registration–related incidents

Patient registration incidents made up 5.3% of the resulting set (n = 4). Registration issues were particularly challenging for providers, given that registration is the gateway to most EHR capabilities.

Patient handoff/transfer–related incidents

Incidents of patient handoff delay made up 5.3% (n = 4) and shared a common theme of disrupted transfer of patient information, even when downtime procedures were followed. This delay created a ripple effect, as patients admitted to the hospital from the emergency department were held in place while their charts could not be transferred, delaying necessary services and/or transport to hospital rooms.

Procedure-related incidents

Only 2.6% of downtime reports (n = 2) were associated with surgical procedures, and were related to delays in communication and unavailability of equipment.

History viewing–related incidents

History Viewing refers to events where the ability to check prior patient activities was restricted due to the EHR downtime, representing 1.3% (n = 1). The clinical staff was unable to double-check if medications were received by patients previously and view other critical historical information for their patients.

General delay of care

Incidents in this category accounted for 13.2% of the total explicit downtime events (n = 10). These event descriptions focused on high-level downtime-triggered obstructions that related to delays of care and did not have enough detail to be further coded into any of the other categories.

Downtime procedures

Looking at adherence to and execution of downtime procedures, of the 76 incidents, 46% (n = 35) indicated that downtime procedures either were not followed or were not in place. Only 27.6% of incidents (n = 21) indicated that downtime procedures were successfully executed, and 26.3% (n = 20) had insufficient information to determine if downtime procedures were present or followed.

DISCUSSION

Our analysis of patient safety event reports associated with EHR downtime events highlights several areas of risk. Our results have implications for the downtime procedures put in place at hospitals and also have policy implications.

While most of the reports focused on laboratory-related events, across the clinical domains and categories, patient identification and tracking of patient information were common areas for concern. EHRs are the primary platform for tracking patients and their associated clinical information, and without these capabilities, clinicians face difficulties. During downtimes, the inability to easily identify patients and access their information results in serious patient safety hazards. Patient identification, particularly during unplanned EHR downtime, is a major challenge, and we are unaware of rigorous and validated solutions to this challenge. We have observed clinicians adapting and creating different methods to track patients, including using an “offline” computer and printer during EHR downtime to manually create labels to support patient identification; however, it is unclear how safe and effective these methods are. Developing and testing patient identification methods for EHR downtime is an area ripe for future research.

Surprisingly, nearly half of the patient safety event reports analyzed indicated that downtime procedures either were not followed or were not in place. This finding further highlights the need to ensure that effective downtime procedures are developed, implemented, and practiced by all hospital staff.^6,22,23 Many downtime procedures are examined only in the days after an unplanned downtime event and then kept on file until they need to be implemented during the next downtime. Few provider organizations practice their downtime procedures or assess their ability to safely and effectively deliver care during EHR downtime. Without downtime procedure practice, gap analysis, and iterative development of more robust downtime procedures, major safety hazards will persist.

Based on our results, hospitals should consider the following when designing and practicing downtime procedures:

• At the organizational level, hospitals must recognize the importance of rigorous and well-practiced downtime procedures, despite the perception that downtimes are infrequent.

• Most hospitals have basic paper processes in place for all ordering (eg, medications, labs, diagnostic tests); they should continue to refine these procedures to ensure that unnecessary redundancies are removed to expedite efficiency.

• Downtime paper processes should not simply be printouts of the electronic records or ordering processes; these processes should be tailored to the unique needs of the downtime event.

• Recognize that downtime results in considerably slower processing of laboratory and imaging studies; determine how challenges with volumes will be addressed, particularly for extended downtime periods.⁸

• Determine the communication processes required to convey orders and results across hospital departments; create clear procedures for communication of information and practice these procedures.

• Focus on patient identification during downtime procedure creation, training, and practice.

From a policy perspective, while the Office of the National Coordinator of Health Information Technology has sponsored important work like the SAFER guides, which highlight the importance of downtime procedures, our results suggest that complete downtime procedures may not always be in place to cover all clinical processes, and procedures may not be known to all clinical staff. Policymakers may want to consider other mechanisms to encourage hospitals, and other health information technology stakeholders, to develop rigorous downtime procedures and practice them on a more regular basis. Further, sharing best practices from institutions that have firsthand experience with downtime should be encouraged.

There are limitations to our approach of analyzing patient safety event data to better understand downtime events. During downtimes, certain reporting systems may not be available, and staff members often have very high workloads, which may prevent them from entering patient safety event reports. Research into voluntary patient safety incident reporting systems have found that a significant number of incidents go unreported.²⁴ Further, patient safety event reports do not provide insight into the magnitude of the hazards that are identified; rather, they provide a lens to identify where some safety hazards may exist. The harm levels associated with safety reports are generally unreliable and were not analyzed. Finally, when the reports indicated that a downtime procedure was followed, it is unclear whether the procedure resulted in safe patient care. This is a ripe area for future research.

CONCLUSION

Our analysis of EHR downtime–associated patient safety events identifies particular areas of risk. Downtime incidents related to labs and medications were the most frequently reported. Cutting across clinical areas were challenges with patient identification and communicating clinical information. Many downtime-related incident reports indicated that procedures were not properly followed or did not exist, suggesting that improved downtime procedures are needed.

Funding

This project was funded under contract/grant number 1 R21 HS024350‐01A1 from the Agency for Healthcare Research and Quality, US Department of Health and Human Services. The opinions expressed in this document are those of the authors and do not reflect the official position of the Agency for Healthcare Research and Quality or the Department of Health and Human Services.

Competing Interests

The authors have no competing interests to declare.

Contributors

Each author contributed to the conception or design of the work, data analysis and interpretation, critical revision of the article, and final approval of the version to be published.