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

Do You Know Who Your Employees Are?

This new monthly cyber awareness alert from the Department of Health and Human Services’ Office for Civil Rights (OCR) prods organizations to closely evaluate the risks their employees pose.

Insider threat is becoming one of the largest threats to organizations and some cyberattacks may be insider-driven. Although all insider threats are not malicious or intentional, the effect of these threats can be damaging to a Covered Entity and Business Associate and have a negative impact on the confidentiality, integrity, and availability of its ePHI. According to a survey recently conducted by Accenture and HfS Research, 69% of organization representatives surveyed had experienced an insider attempt or success at data theft or corruption. Further, it was reported by a Covered Entity that one of their employees had unauthorized access to 5,400 patient’s ePHI for almost 4 years.

US CERT defines a malicious insider threat as a current or former employee, contractor, or business partner who meets the following criteria:

• has or had authorized access to an organization’s network, system, or data;
• has intentionally exceeded or intentionally used that access in a manner that negatively, affected the confidentiality, integrity, or availability of the organization’s information; or information systems.

According to a survey conducted by U.S. Secret Service, CERT Insider Threat Center, CSO Magazine, and Deloitte, the most common e-crimes committed by insiders are:

• unauthorized access to or use of organization information;
• exposure of private or sensitive data;
• installation of viruses, worms, or other malicious code;
• theft of intellectual property.

Covered Entities and Business Associates should consider:

• Developing policies and procedures to mitigate the possibility of theft of ePHI, sabotage of systems or devices containing ePHI, and fraud involving ePHI. These policies and procedures should enforce separation of duties and least privileges, while also applying rules that control and manage access, configuration changes, and authentication to information systems and applications that create, receive, maintain, or transmit ePHI.

• Conducting screening processes on potential employees to determine if they are trustworthy and appropriate for the role for which they are being considered. Effective screening processes can be applied to allow for a range of implementations, from minimal to more stringent procedures based on the risk analysis performed by the entity and role of the potential employee. Examples of potential screening processes could include checks of the HHS OIG LEIE (List of Excluded Individuals and Entities) to check for health care fraud and related issues and criminal history checks to verify past criminal acts. When implementing a screening process, please be sure to review and comply with any applicable federal, state or local laws regarding the use of screening processes as part of the hiring process.

• Following US CERT steps to protect ePHI from insider threats: 

1. Consider threats from insiders and business associates in enterprise-wide risk assessments.

2. Clearly document and consistently enforce policies and controls.

3. Incorporate insider threat awareness into periodic security training for all employees.

4. Beginning with the hiring process, monitor and respond to suspicious or disruptive behavior.

5. Anticipate and manage negative issues in the work environment.

6. Know your assets.

7. Implement strict password and account management policies and practices.

8. Enforce separation of duties and least privilege.

9. Define explicit security agreements for any cloud services, especially access restrictions and monitoring capabilities.

10. Institute stringent access controls and monitoring policies on privileged users.

11. Institutionalize system change controls.

12. Use a log correlation engine or security information and event management (SIEM) system to log, monitor, and audit employee actions.

13. Monitor and control remote access from all end points, including mobile devices.

14. Develop a comprehensive employee termination procedure.

15. Implement secure backup and recovery processes.

16. Develop a formalized insider threat program.

17. Establish a baseline of normal network device behavior.

18. Be especially vigilant regarding social media.

19. Close the doors to unauthorized data exfiltration.

Source(s): US-CERT, http://www.hhs.gov/ocr/, HCSI 

To subscribe to this blog, enter your email address:


Delivered by FeedBurner

Identifying Business Associates

Covered Entities & Business Associates

With business associates and business associate agreements (BAAs) coming under increased scrutiny in the latest round of HIPAA audits, some covered entities are wondering how to identify which vendors are considered business associates, and therefore require a BAA, and which vendors are not.

According to the Privacy Rule, a business associate is a person or entity that performs certain functions or activities that involve the use or disclosure of protected health information (PHI) on behalf of, or provides services to, a covered entity (CE).

Business associate functions and activities include the following:

●        Claims processing or administration;

●        Data analysis;

●        Processing or administration;

●        Utilization review;

●        Quality assurance;

●        Billing;

●        Benefit management;

●        Practice management; and

●        Repricing;

Additionally, any entity that provides any of the following services involving the disclosure of PHI by a CE, is a business associate:

●        Legal;

●        Actuarial;

●        Accounting;

●        Consulting;

●        Data aggregation;

●        Management;

●        Administrative;

●        Accreditation; or

●        Financial.

In addition, the Omnibus Rule includes a new definition of a business associate. A business associate is also defined as an individual or organization that creates, receives, maintains, or transmits PHI on behalf of a CE. In addition, four new categories were added to the definition:

●        Health Information Exchanges;

●        E-prescribing gateways;

●        Data transmission services; and

●        Entities that offer a personal health record to individuals on behalf of a CE.

The following is a list of sample business associates a CE may have. A BAA would need to be initiated for all of these vendors. Examples include

●        IT companies that support health care providers;

●        Electronic Health Record (EHR) system providers;

●        Data centers, online backup companies, cloud service providers, even if they do not access data;

●        Shredding companies;

●        Insurance agents;

●        A CPA firm whose accounting services to a health care provider involve access to PHI;

●        An attorney whose legal services to a health plan or provider involve access to PHI;

●        Any person or entity providing services to a business associate that requires access to PHI; and

●        Data centers, online backup companies, cloud service providers, providing services to a business associate, even if they do not access data.

The Privacy rule also outlines situations where it is not necessary to enter into a BAA. Some examples of when a BAA is not required are the following:

●        When a health care provider discloses PHI to a health plan for payment purposes, or when the health care provider simply accepts a discounted rate to participate in the health plan’s network.

●        With persons or organizations (e.g., janitorial service or electrician) whose functions or services do not involve the use or disclosure of PHI, and where any access to PHI by such persons would be incidental, if at all.

●        Among CEs who participate in an organized health care arrangement (OHCA) to make disclosures that relate to the joint health care activities of the OHCA.

●        Where a group health plan purchases insurance from a health insurance issuer or HMO.

●        Where one CE purchases a health plan product or other insurance, for example, reinsurance, from an insurer.

●        With a person or organization that acts merely as a conduit for PHI, for example, the US Postal Service, certain private couriers, and their electronic equivalents.

●        To disclose PHI to a researcher for research purposes, either with patient authorization, pursuant to a waiver, or as a limited data set.

●        When a financial institution processes consumer-conducted financial transactions by debit, credit, or other payment card, clears checks, initiates or processes electronic funds transfers, or conducts any other activity that directly facilitates or affects the transfer of funds for payment for health care or health plan premiums.

Also included are the following exceptions to the business associate standard. In these situations, a CE is not required to have a BAA or other written agreement in place before PHI may be disclosed to the person or entity.

●        Disclosures by a covered entity to a health care provider for treatment of the individual;

●        Disclosures to a health plan sponsor, such as an employer, by a group health plan, or by the health insurance issuer or HMO that provides the health insurance benefits or coverage for the group health plan, provided that the group health plan’s documents have been amended to limit the disclosures or one of the exceptions at 45 CFR 164.504(f) have been met;

●        The collection and sharing of PHI by a health plan that is a public benefits program, such as Medicare, and an agency other than the agency administering the health plan, such as the Social Security Administration, that collects PHI to determine eligibility or enrollment, or determines eligibility or enrollment, for the government program, where the joint activities are authorized by law; and

●        Patient safety organizations.

Source(s): http://www.hcsiinc.com, http://www.hhs.gov

To subscribe to this blog, enter your email address:


Delivered by FeedBurner