• Print

SAFER Guides

SAFER: Safety Assurance Factors for EHR ResilienceThe Office of the National Coordinator for Health Information Technology
graphic element

Contingency Planning

The Contingency Planning SAFER Guide identifies recommended safety practices associated with planned or unplanned EHR unavailability — instances in which clinicians or other end users cannot access all or part of the EHR. Occasional temporary unavailability of EHRs is inevitable, due to failures of software and hardware infrastructure, as well as power outages and natural and man-made disasters. Such unavailability can introduce substantial safety risks to organizations that have not adequately prepared. Effective contingency planning addresses the causes and consequences of EHR unavailability, and involves processes and preparations that can minimize the frequency and impact of such events, ensuring continuity of care.

EHR unavailability, which will occur in every EHR-enabled healthcare environment,2 represents a significant potential patient safety hazard that directly affects patient care. Documented potential hazards include an increased risk of medication errors,3 unavailability of images,4 and canceled procedures. The potential impact of EHR unavailability increases as such systems are deployed across multiple, geographically dispersed facilities within a healthcare system.1 The contingency planning team should include practicing clinicians to ensure that the technical components align with and support the clinical processes and workflows impacted by their decisions. The substitute workflows that must be designed and then employed during downtimes are particularly sensitive to clinician input and cooperation. In addition to the substantial initial contingency planning effort, a continuous, reliable review and maintenance process must be developed and followed. EHR safety and effectiveness can be improved by establishing proper downtime procedures, policies, and practices. The collaboration between clinicians and staff members in completing the self-assessment in this guide will enable an accurate snapshot of the organization’s EHR contingency planning status (in terms of safety) and, even more importantly, should lead to a consensus about the organization’s future path to optimize EHR-related safety and quality.

Interaction with HIPAA

While this guide focuses on patient safety, many of its recommendations overlap with standards and implementation specifications of the HIPAA Security Rule, which focuses on ensuring the confidentiality, integrity, and availability of electronic protected health information. Because the focus of the guide differs from that of the Security Rule, completing the checklist here will not equate with compliance with HIPAA. However, creating a contingency plan as required by the HIPAA Security Rule will address many, but not all, of the recommended safety-oriented practices in this guide. We encourage coordination of completion of the self-assessment in this SAFER Guide with contingency planning for purposes of HIPAA compliance to provide a uniform approach to patient safety and data protection.

Download the pdf Guide to access the checklist of recommended practices for self assessment and a supporting worksheet to identify action steps to achieve those recommended practices.

1

Hardware that runs applications critical to the organization’s operation is duplicated.

More About This Practice
Rationale:

Organizations should take steps to prevent and minimize the impact of technology failures. A single point of failure greatly increases risks both for the availability and integrity of data.

Examples:
  • The organization has a remotely located (i.e., > 50 miles away and > 20 miles from the coastline) “warm-site” (i.e., a site with current patient data that can be activated in less than 8 hours) backup facility that can run the entire EHR.5
  • The warm-site is tested at least quarterly.
  • The organization maintains a redundant path to the Internet consisting of two different cables, in different trenches (a microwave or other form of wireless connection is also acceptable), provided by two different Internet providers.9
Suggested Sources of Input:
  • Clinicians, support staff, and/or clinical administration
  • EHR developer
  • Health IT support staff
2

An electric generator and sufficient fuel are available to support the EHR during an extended power outage.

More About This Practice
Rationale:

Most health care organizations must be able to continue running their health IT infrastructure and preserve data and communication capabilities in cases of sustained power outages.

Examples:
  • Organizations evaluate the consequences to patient safety and to business operations due to loss of power that shuts down the EHR, and implement concrete plans to keep the EHR running to the extent needed to avoid unacceptable consequences.
  • In the event of a power failure, there is an uninterruptible power supply (UPS), either batteries or a “flywheel,” capable of providing instantaneous power to maintain the EHR for at least 10 minutes.
  • The UPS is tested regularly (optimally on at least a monthly basis).
  • The on-site, backup electrical generator is able to maintain EHR functions critical to the organization's operation (e.g., results review, order entry, clinical documentation).
  • The organization maintains 2 days of fuel for the generator on-site.
  • The generator is tested regularly (optimally at least on a monthly basis).
  • The UPS and the generator are kept in secure locations that are not likely to flood.
Suggested Sources of Input:
  • Clinicians, support staff, and/or clinical administration
  • Health IT support staff
3

Paper forms are available to replace key EHR functions during downtimes.

More About This Practice
Rationale:

Clinical and administrative operations need to continue in the event of a downtime.

Examples:
  • The organization maintains enough paper forms to care for patients on the unit for at least 8 hours. Paper forms could include those required to enter orders and document the administration of medications, labs, and radiology on each unit.7
  • There is a process in place to ensure that the information recorded on paper during the downtime gets entered and reconciled into the EHR following its reactivation (e.g., this could be entering information as coded data or scanning of paper documents).7
Suggested Sources of Input:
  • Clinicians, support staff, and/or clinical administration
4

Patient data and software application configurations critical to the organization's operations are backed up.

More About This Practice
Rationale:

Backup of mission-critical patient data and EHR system configuration allows system restoration to a "pre-failure" state with minimal data loss. In the event of failure, you are able to rely upon reliable back-up data.

Examples:
  • The organization has a daily, off-site, complete, encrypted backup of patient data.6
  • The off-site backup is tested regularly (optimally on at least a monthly basis, i.e., complete restore).7
  • The content required to configure the system is backed up on a regular basis (optimally on a monthly basis and before every system upgrade).
  • The organization maintains multiple backups, created at different times.
  • Backup media are physically secured.
  • Backup media are rendered unreadable (i.e., use software to scramble media contents or physically destroy/shred media) before disposal.
  • The organization has a “read-only” backup EHR system that is updated frequently (optimally at least hourly).
  • The read-only EHR system is tested regularly (optimally at least weekly).
  • Users can print from the read-only EHR system.
  • If there is a “unit-level” read-only backup EHR system, it is connected to a local UPS or “red plug.”
Suggested Sources of Input:
  • Clinicians, support staff, and/or clinical administration
  • EHR developer
  • Health IT support staff
5

Policies and procedures are in place to ensure accurate patient identification when preparing for, during, and after downtimes.

More About This Practice
Rationale:

Without policies, procedures, and processes in place to manage patient identification during downtimes, mismatches and lost records could compromise patient confidentiality, data integrity, and patient safety.

Examples:
  • The read-only EHR system should have user-specific passwords (i.e., should not employ a shared password for all users).
  • There is a mechanism in place to register new patients during downtime, including assignment of unique temporary patient record numbers along with a process for reconciling these new patient IDs once the EHR comes back online.
  • Ensure that paper documents created during downtime are protected using standard HIPAA safeguards and policies.
Suggested Sources of Input:
  • Clinicians, support staff, and/or clinical administration
  • EHR developer
6

Staff are trained and tested on downtime and recovery procedures.

More About This Practice
Rationale:

In organizations that have not had a significant downtime in more than a year, there is an increased risk of having employees who do not know how to function in a paper environment.

Examples:
  • Organizations establish and follow training requirements so that each employee knows what to do to keep the organization operating safely during EHR downtimes.
  • Clinicians are trained in use of the paper-based ordering and charting tools.
  • The organization conducts unannounced EHR "downtime drills" at least once a year.8
  • Clinicians have been trained on how and when to activate and use the "read-only" backup EHR system.
Suggested Sources of Input:
  • Clinicians, support staff, and/or clinical administration
7

A communication strategy that does not rely on the computing infrastructure exists for downtime and recovery periods.

More About This Practice
Rationale:

Institutions need to be prepared to communicate with key personnel without use of the computer.

Examples:
  • The organization has methods other than electronic (i.e., not email, Twitter, voice-over-IP, etc.) to notify key organizational administrators and clinicians about times when the EHR is down (either planned or unplanned).9
  • The organization has a mechanism in place to activate the read-only backup EHR system and notify clinicians how to access it.
  • The organization has a mechanism in place to notify clinicians when the EHR is back online (either planned or unplanned).
Suggested Sources of Input:
  • Clinicians, support staff, and/or clinical administration
  • Health IT support staff
8

Written policies and procedures on EHR downtimes and recovery processes ensure continuity of operations with regard to safe patient care and critical business operations.

More About This Practice
Rationale:

Policies and procedures on EHR downtime and recovery keep everyone "on the same page" so they are able to care for patients and maintain critical business operations during inevitable downtimes, whether planned or unplanned.

Examples:
  • The organization has a written EHR downtime and recovery policy that describes key elements such as when a downtime should be called; how often further communication will be delivered; who will be in-charge during the downtime (both on the clinical and technical side); how everyone will be notified; and how information collected during the downtime is entered into the EHR.10
  • The EHR downtime policy is reviewed at least every 2 years.
  • The EHR downtime policy describes when the warm-site backup process should be activated (ideally, before the system has been down for 2 hours).
  • A paper copy of the current EHR downtime and recovery policy is available on clinical units.
  • A paper copy of the current EHR downtime and recovery policy is stored in a safe, off-site location.
Suggested Sources of Input:
  • Clinicians, support staff, and/or clinical administration
  • Health IT support staff
9

The user interface of the locally maintained backup, read-only EHR system is clearly differentiated from the live/production EHR system.

More About This Practice
Rationale:

When the usual system is unavailable, a read-only copy can enable access to patient records, though it can’t support adding or editing patient data. If it looks the same to users it could easily result in attempts to enter data that will not be recorded.

Examples:
  • Access to the "read-only" backup EHR is disabled (e.g., icons on the computer screens are "greyed out" or not available) during periods of normal EHR operations.
  • The user interface of the read-only backup EHR system is visibly different than the fully operational system (e.g., there is a different background color for screens, a watermark across screens, or data entry fields are greyed out).
  • Clinicians are trained on appropriate use of the read-only backup EHR.
Suggested Sources of Input:
  • Clinicians, support staff, and/or clinical administration
  • EHR developer
10

There is a comprehensive testing and monitoring strategy in place to prevent and manage EHR downtime events.

More About This Practice
Rationale:

Comprehensive testing and monitoring strategies can prevent and minimize the impact of technology failures.

Examples:
  • The organization regularly monitors and reports on system downtime events.
  • The organization regularly monitors and reports on system response time (optimally under 2 seconds).11
  • The organization has a written policy describing the different hardware, software, process, and people-related testing procedures.
  • The organization maintains a log of all testing activities.
  • Unplanned downtimes and the effectiveness of follow-up to prevent them from recurring are monitored by the top leadership.
Suggested Sources of Input:
  • Clinicians, support staff, and/or clinical administration
  • EHR developer
  • Health IT support staff
{@Thursday, January 30, 2014@}
{@Thursday, January 30, 2014@}