11.9 STANDARD: CONTINGENCY PLAN

The Contingency Plan Standard has 5 separate Implementation Specifications, with three specifications required and two addressable:

Data Backup Plan
Disaster Recovery Plan
Emergency Mode Operation Plan
Testing and Revision Procedure
Applications and Data Criticality Analysis

This Standard requires the implementing of policies and procedures for responding to an emergency or other occurrence that damages systems containing EPHI. Contingency Operations allows access to a secure alternate processing site(s) in support of the restoration of EPHI lost as a result of a disaster. Contingency Plans are sometimes referred to as a 'Continuity Plan', or the older term 'Disaster Recovery Plan'. But 'Contingency' is much more encompassing their either of the other terms and involves protecting against any reasonably anticipated threats or hazards to the security, integrity and availability of EPHI.

The HIPAA Security regulations deal specifically with the availability and recovery of EPHI and the systems that protect the security of EPHI and other IT systems and data are not covered. The required Plan is not a 'business' continuity plan in that regard. While two of the specifications are addressable reasonable practices would require some form of plan revision and testing be done yearly. Because the contents of the plan are not regulated , addressable specifications will probably result in increased flexibility and reduced cost of compliance due to the scalability of a contingency plan, and what is deemed 'reasonable and appropriate' including cost, probability of risks and the criticality risks to EPHI.

11.9.1 Data Backup Plan

The first required Implementation Specifications in the Contingency Plan Standard is the Data Backup Plan.

Regulations require the covered entity to establish and implement procedures to create and maintain retrievable exact copies of EPHI.

The Data Back-Up Plan should ensure that critical EPHI are identified and included in the plan, that the plan includes verification of back-ups, including appropriate rotation and retention parameters and a record of that policy, as well as applicable federal, state, regulatory requirements and agreements.

Back-ups should be stored off-site in an environmentally and physically secure location and a secure form of transport of back-up media to/from off-site location should be instituted. The covered entity must implement controls over retrieval of back-up data, restricted of back-up data to appropriate staff, and require a password or other authorization code. To prevent the back-up from being damaged, a copy of each back-up should be made for recovery use. Since an unverified or unreadable back-up could be a nightmare, a process for checking and reading or restoring back-up data should be done periodically.

11.9.2 Disaster Recovery Plan

The second required Implementation Specifications in the Contingency Plan Standard is the Disaster Recovery Plan.

Regulations require the covered entity to establish and implement procedures to restore any loss of data. This component of the contingency plan includes detailed procedures to restore EPHI from back-up media, including detailed procedures to recover operating system, subsystems, utilities, and applications. This documentation should be detailed enough to allow someone not familiar with the function to be able to understand and perform the data restore.

11.9.3 Emergency Mode Operation Plan

The third required Implementation Specifications in the Contingency Plan Standard is the Emergency Mode Operation Plan.

Regulations require the covered entity to establish and implement procedures to enable continuation of critical business processes for protection of the security of EPHI while operating in emergency mode. This component of the contingency plan includes detailed procedures for operations in the event of a disaster. This is really the 'Continuity Plan'-how will data be protected, accessed, during the emergency, to maintain the 'availability' to EPHI.

For instance, if the emergency involves a loss of A/C power, then depending on how widespread the use of uninterruptible power supplies is, or the availability of emergency generator power, there may be limited accessing of EPHI if end users PC's are not functioning or Servers shut down.

Emergency Mode may also involve the use of paper and pen instead of PC and power. Most hospitals and medical centers probably have emergency and disaster plans that are tested regularly, so the HIPAA mandates can be made a part of that plan.

Again, this is a mandate for continuing processes involving the use and protection of EPHI during and immediately after a crisis situation, and not regular hospital or medical center business. The Emergency Mode Operation Plan should include detailed operational recovery procedures not included in the Disaster Recovery plan.

11.9.4 Testing and Revision Procedure

The fourth Implementation Specifications in the Contingency Plan Standard is the Testing and Revision Procedure, an addressable specification.

Regulations require the covered entity to establish and implement procedures for periodic testing and revision of contingency plans.

Some of the following information was taken from a presentation by Tina Field, Disaster Recovery Analyst, Banner Health, Phoenix, Arizona.

11.9.4.1 Recovery Testing Steps:

The objective of recovery testing is not to determine what is right, but what is wrong-test to fail
Testing is the only way to find out before a disaster really occurs what revisions need to be made to a plan
A desktop walk-through is better than nothing
A limited scope recovery test is better than a walk-through
A scheduled full scope recovery test is better still
An unannounced full scope recovery test is the top level test

11.9.4.2 Demonstrated Recovery Capability targeted areas in IT:

Platforms
Applications
Data
Network (LAN, WAN, internet access)
Support Services (e.g., e-mail, Help Desk, Desktop support)
Voice
Web sites

11.9.4.3 Demonstrated Recovery Capability goals:

Within pre-defined Recovery Time Objectives
To pre-defined Recovery Points in Time
Via full scope recovery testing or actual recovery following a disaster
Plan Revisions
- Plans are living documents
- Information contained in plans must be current, valid, and accurate or the plans are of no use

Types of maintenance
- Planned
  - Update call tree and contact lists
- Unplanned
  - As a result of recovery testing
  - As a result of operational or organizational changes

11.9.4.4 Plan Revisions checklist:

Formally assign responsibility for maintenance
If plan maintenance process is de-centralized, assign overall responsibility to one individual (e.g., Disaster Recovery Coordinator)
Embed maintenance triggers in the organization's change management process
Review and update call trees and contact lists at least quarterly
Review and update plan within 30 days of major organizational or operational change

11.9.5 Applications and Data Criticality Analysis

The fifth and final Implementation Specifications in the Contingency Plan Standard is the Applications and Data Criticality Analysis, also an addressable specification.

Regulations require the covered entity to establish and implement procedures to assess the criticality of specific applications and data in support of other contingency plan components .

In other words, this is a business impact analysis for IT. It involves analyzing and mapping critical clinical processes to associated applications, data, and IT infrastructure components and support services to identify internal, external, and processing dependencies and minimum recovery resources needed to recover EPHI, such as hardware, software, etc.

In reality, this Analysis should probably be a continuation of the Gap Analysis and Risk Analysis portions of any covered entity's HIPAA Security plan. As new systems are rolled out and others go off-line, a continuing process of evaluation and analysis is needed to maintain the Contingency Plan.