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:
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.
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.
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.
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.
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.).
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.
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.
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
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.ready.gov/, http://www.fema.gov/
