The Importance in Healthcare of a Disaster Recovery Plan (DRP) and how to Organize your Risk Analysis into an actionable DRP.

Creating Your Healthcare Disaster Recovery Plan and Best Practices

When a covered entity performs a Security Risk Analysis, this is not the end but a begging to your HIPAA Security procedures and business continuity plan.

Information gained from the risk analysis then needs to further be organized into a tangible, well documented and actionable Disaster Recovery Plan (DRP).

All health care organizations (particularly hospitals and emergency care centers), must maintain a high degree of system and network availability. Patient's lives may depend on systems being up and running, and a patient's health could be jeopardized or negatively impacted by lack of access to health care data in the event of system downtime. 

The disaster recovery plan is a required implementation, defined within the HIPAA Contingency Plan standard in the Administrative Safeguards section of the HIPAA Security Rule. The Rule calls for HIPAA-compliant organizations to anticipate how natural or other disasters could damage systems that contain electronic health information and to develop policies and procedures for responding to such situations.

A HIPAA-compliant disaster recovery plan must state how operations will be conducted in an emergency situation and which workforce members are responsible for carrying out those operations. The plan must also explain how data will be safeguarded or moved without violating HIPAA standards for Privacy and Security.  It must also explain how confidential data and safeguards for that data will be restored.  Although HIPAA doesn't specify exactly how to do this, it does note that failure to adequately recover from a disaster could lead to noncompliance. Failure to comply exposes officers of the organization to repercussions, such as fines or possible jail time.

Unfortunately, when establishing IT budgets, many health care practices and organizations overlook the importance of developing a meaningful, functional and standardized disaster recovery plan. It's important for health care practice Administrators, Compliance Officers and CIOs to make the necessary business case model and receive a useful budget for disaster recovery planning. Making use of the, pay $10 now or $10,000 later, theorem comes to mind.

Formulating a detailed disaster recovery plan should be a primary objective of the entire practice and IT disaster recovery planning project. It is in these plans that you will set out the detailed steps needed to recover your IT EMR systems to a state in which they can support the practice (during, if necessary) and after a disaster.

But before you can create a detailed recovery plan, you will need to perform a Risk Analysis/Assessment (RA) to identify the IT services that support the organization’s critical business activities.

The next step is to establish recovery time objectives (RTOs)* and recovery point objectives (RPOs)**.

*The recovery time objective (RTO) is the targeted duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity. It can include the time for trying to fix the problem without a recovery, the recovery itself, testing, and the communication to the users.

**A recovery point objective (RPO) is defined by business continuity planning. It is the maximum targeted period in which data might be lost from an IT service due to a major incident.

Now that you have that basic information gathering stage compiled, you can move on to the next stage.

Developing Disaster Recovery Strategies

ISO/IEC 27031, which is the global standard for IT disaster recovery, states, “Strategies should define the approaches to implement the required resilience so that the principles of incident prevention, detection, response, recovery and restoration are put in place.” Strategies define what you plan to do when responding to an incident, while plans describe how you will do it.

Once you have identified your critical systems, RTOs, RPOs, etc, create a table, similar to what is shown below, to help you formulate the disaster recovery strategies you will use to protect them.

Critical System(s)	RTO/RPO	Threat	Prevention Strategy	Response Strategy	Recovery Strategy
EMR System	6 hours/ 3 hours	Server Failure/Loss of ePHI	Secure server room; UPS; Regularly backup server	Verify UPS running time, use backup server	Restore/replace primary sever; restore backup date  and input interim records
Accounts Payable/ Billing	8 hours/ 4 hours	Server Failure/Loss of Billing records	Secure equipment room; UPS; Regularly backup server	Maintain paper records for later recovery	Restore/replace primary sever; restore backup date  and input interim records
Building Security	4 hours/ 2 hours	Security System Destroyed	Place system in secure location; UPS; Use protective enclosures for sensors and cameras	Deploy security is available, secure and/or relocate vital system/ records	Repair/Replace security unit and devices

Table 1: Determining disaster recovery Strategies.

Remember to consider issues such as billing, budgets, management’s position with regard to risks, the availability of resources, costs versus benefits, human constraints, technological constraints and regulatory obligations.

Now let’s examine some additional factors in strategy definition:

People

This involves availability of staff/contractors, training needs of staff/contractors, duplication of critical skills so there can be a primary and at least one backup person, available documentation to be used by staff, and follow-up (ongoing training) to ensure staff and contractor retention of knowledge.

Physical facilities

Areas to look at are availability of alternate work areas within the same site, at a different company location, at a third-party-provided location, at employees’ homes or at a transportable work facility. Then consider site security, staff access procedures, ID badges and the location of the alternate space relative to the primary site.

Technology

You’ll need to consider access to equipment space that is properly configured for IT systems, with raised floors, for example; suitable heating, ventilation and air conditioning (HVAC) for IT systems; sufficient primary electrical power; suitable voice and data infrastructure; the distance of the alternate technology area from the primary site; provision for staffing at an alternate technology site; availability of failover (to a secondary server of backup system for example) and failback (returning to normal operations) technologies to facilitate recovery; support for legacy systems; and physical and information security capabilities at the alternate site.

Data

Areas to look at include timely backup of critical data to a secure storage area in accordance with RTO/RPO requirements, method(s) of data storage (cloud, disk, tape, optical, etc), connectivity and bandwidth requirements to ensure all critical data can be backed up in accordance with RTO/RPO time scales, data protection capabilities at the alternate storage site, and availability of technical support from qualified third-party service providers.

Suppliers

You’ll need to identify and contract with primary and alternate suppliers, (including all Business Associates), for all critical systems, PHI data and processes, and even the sourcing of specific crucial people. Key areas where alternate suppliers will be important include hardware (such as servers, racks, etc), power (such as batteries, universal power supplies, power protection, etc), networks (voice and data network services), repair and replacement of components, and multiple delivery firms (FedEx, UPS, etc.).

Policies and procedures

Define policies and procedures describing your Disaster Recovery Plan and have them approved by senior management and Compliance Officer(s). Then define the step-by-step procedures to (for example) initiate data backup to secure alternate locations, relocate operations to an alternate space, recover systems and data at the alternate sites, and resume operations at either the original site or at a new location.

Be sure to obtain management sign-off for your strategies and be prepared to demonstrate that your strategies support the practices’ business and compliance goals.

Translating disaster recovery strategies into DR plans

Once your disaster recovery strategies have been developed, you’re ready to translate them into disaster recovery plans. Let’s take Table 1 and recast it into Table 2, seen below. Here we can see the critical system and associated threat, the response strategy and (new) response action steps, as well as the recovery strategy and (new) recovery action steps. This approach can help you quickly drill down and define high-level action steps.

Critical System(s)	Threat	Response Strategy	Response Action Steps	Recovery Strategy	Recovery Action Steps
EMR System	Server Failure/ Loss of ePHI	Switch over to backup server; create paper records	Confirm status of Server; Verify Data has been backed up including testing and restoring; Switch over to alternate server	Restore/replace primary sever; restore backup date  and input interim records	Verify primary system integrity and repair/replace if necessary; restore backups; incorporate offline records; fall back from secondary servers
Accounts Payable/ Billing	Server Failure/Loss of Billing info	Switch over to backup server; create paper records	Confirm status of Server; Verify Data has been backed up including testing and restoring; Switch over to alternate server	Restore/replace primary sever; restore backup date  and input interim records	Verify primary system integrity and repair/replace if necessary; restore backups; incorporate offline billing or accounting information; fall back from secondary servers
Building Security	Security System Destroyed	Deploy guards and/or secure server records room.	Verify status of security system and video storage; Organize guards and define duties;  have available alternative communication methods (2-way radio)	Obtain or re-install new system/sensors, etc.	Contact vendor to identify system failure issues and repair/replace any faulty components.

Table 2: Using strategies to create disaster recovery Plan.

From Table 2 (above) you can expand the high-level steps into more detailed step-by-step procedures, as you deem necessary. Be sure they are organized and linked in the proper sequence.

Developing DR plans

DR plans provide a step-by-step process for responding to a disruptive event. Procedures should ensure an easy-to-use and repeatable process for recovering damaged IT and ePHI assets then returning these hardware items and critical data back to normal operation as quickly as possible. If staff relocation to a third-party “hot site” or other alternate space is necessary, procedures must be developed for those possible scenarios.

Incident response

In addition, IT disaster recovery plans should be an inclusive part of an incident or emergency response plan that addresses the initial stages of the situation and the steps to be taken.

Note: Emergency management activities that may be needed to address situations where humans are injured or situations such as fires may be a concern must be addressed by local fire departments and/or other first responders.

The DR plan structure

The following section details the elements in a DR plan in the sequence defined by ISO 27031 and ISO 24762.

Important note: Best practice DR plans should begin with a few pages that summarize key action steps (such as where to assemble employees if forced to evacuate the building) and lists of key contacts and their contact information for ease of coordinating, authorizing and launching the plan.

1. Introduction.  Following the initial emergency pages, DR plans have an introduction that includes the purpose and scope of the plan. This section should specify who has approved the plan, those who are authorized to activate it and a list of linkages to other relevant plans and documents.
2. Roles and responsibilities. The next section should define roles and responsibilities of DR recovery team members, their contact details, spending limits (for example, if equipment has to be purchased) and the limits of their authority in a disaster situation.
3. Incident response. During the incident response process, we typically become aware of an out-of-normal situation (such as being alerted by various system-level alarms), quickly assess the situation (and any damage) to make an early determination of its severity, attempt to contain the incident and bring it under control, and notify management and other key stakeholders.
4. Plan activation. Based on the findings from incident response activities, the next step is to determine if disaster recovery plans should be launched, and which ones in particular should be invoked. If DR plans are to be invoked, incident response activities can be scaled back or terminated, depending on the incident, allowing for launch of the DR plans. This section defines the criteria for launching the plan, what data is needed and who makes the determination. Included within this part of the plan should be assembly areas for staff (primary and alternates), procedures for notifying and activating DR team members, and procedures for standing down the plan if management determines the DR plan response is not needed.
5. Document history. A section on plan document dates and revisions is essential, and should include dates of revisions, what was revised and who approved the revisions. This can be located at the front of the plan document.
6. Procedures. Once the plan has been launched, DR teams take the materials assigned to them and proceed with response and recovery activities as specified in the plans. The more detailed the plan is, the more likely the affected IT asset will be recovered and returned to normal operation. Technology DR plans can be enhanced with relevant recovery information and procedures obtained from system vendors. Check with your vendors while developing your DR plans to see what they have in terms of emergency recovery documentation.
7. Appendixes. Located at the end of the plan, these can include systems inventories, hardware logs, software license keys, Insurance policies and/or agent contacts, application inventories, network asset inventories, contracts and service-level agreements, supplier contact data, and any additional documentation that will facilitate recovery.

Additional follow up activities:

Once your DR plans have been completed, they are ready to be exercised and most importantly, TESTED.

Don't neglect DRP testing, modification and critical system updates.

This Identifies most of the critical components of any DRP needed to respond to HIPAA disaster recovery requirements. Although not discussed above, addressable policies could be dealt with inside or outside the DRP. Nonetheless, as ePHI applications can be added to, deleted or modified, periodic planed tests and resultant corrections are vital to the continuing success of any HIPAA disaster recovery plan while supporting regulatory requirements. 

This process, along with controlled testing, will serve to verify and determine whether recovery, fail-over and restoration processes with records and IT assets function as planned.

In parallel to these activities are these additional and necessary supplementary requirements:

Create and implement employee awareness training, documented policies and records management procedures. These are essential in that they ensure employees are fully aware of DR plans and their responsibilities in a disaster, and DR team members have been trained in their roles and responsibilities as defined in the plans. And since DR planning generates a significant amount of documentation, records management (and change management) activities should also be initiated. If your organization already has records management or process management implementation and change management programs, incorporate them in your DR planning.

With natural disasters, security breaches (external and internal) along with cyber attacks occurring more and more frequently, the need for a practicable DRP is more essential than ever. In fact, having a viable DRP is something all covered entities and supporting Business Associates should have in place for their own business integrity and survival along with patient record and health data integrity, regardless of HIPAA or other governmental regulatory disaster recovery requirements.

Note: When developing your IT/EMR DR plans, be sure to review the global standards ISO/IEC 24762 for disaster recovery and ISO/IEC 27035 (formerly ISO 18044) for incident response activities.

Source(s):http://www.hcsiinc.com, https://www.iso.org/, http://searchhealthit.techtarget.com, 

https://www.ready.gov, http://www.computerweekly.com, https://www.iso.org/, https://en.wikipedia.org

To subscribe to this blog, enter your email address:

Delivered by FeedBurner