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

Where Is Your PHI Data Traveling Today?

Understanding "The Cloud" and it's regulatory relationship with HIPAA and PHI.

With most vendors offering and pushing cloud computing solutions and offsite data backup, or guaranteeing offsite backup of data they process for you, many HIPAA covered entities (CEs) and business associates (BAs) are questioning whether and how they can take advantage of cloud computing while complying with regulations protecting the privacy and security of electronic protected health information (ePHI). 

What "Cloud" computing means is that instead of all the computer hardware and software you're using sitting on your desktop, or somewhere inside your company's network, it's provided for you as a service by another company and accessed over the Internet, usually in a completely seamless way. Exactly where the hardware and software is located and how it all works doesn't matter to you, the user -- it's just somewhere up in the nebulous "cloud" that the Internet represents. 

The business decision to "move to the cloud" is often financially motivated. Companies used to have to buy their own hardware equipment, the value of which depreciated over time. But now with the cloud, companies only have to pay for what they use. This model makes it easy to quickly scale use up or down and to have data backed up for you as part of that provided service.

The rise of offshore IT services, including distributed storage, by cloud data providers creates issues that most healthcare providers have not yet realized. Even if some of the issues are realized, many covered entities and their business associates do not know where their data is currently being processed, stored, or backed up. In fact, storage or processing of protected health information (PHI) overseas may or may not be permitted or at least require additional resources, such as additional or more detailed risk assessments.

There are currently no federal regulations or statutes that prevent storing or processing PHI offshore or overseas; however, the Centers for Medicare and Medicaid Services (CMS), the U.S. Department of Health and Human Services (HHS), and the U.S. Office of Civil Rights (OCR) within the HHS, have all issued regulations or provided guidance that restrict storing or processing PHI offshore. In addition, there are four states that ban any Medicaid data from being stored or processed overseas (Arizona, Alaska, Ohio and Wisconsin), two more that only allow offshore contracts under extremely limited circumstances, and nine more that have specific requirements that must be met before any offshore processing or storage of Medicaid data is allowed. 

Even if a healthcare provider is not located in one of the above states, if the provider has treated a patient of those states, state regulators may argue that the healthcare provider must comply with their laws, regulations, and guidance, as applied to the resident of their state. Even more concerning is that even though Delaware does not have any laws or statutes banning offshore processing or data storage, Delaware recently started adding provisions to all of their contracts (similar to Wisconsin) that the State (Delaware) will not permit project work to be done offshore. There may be additional states adding these prohibitions to their contracts in the future.

If extra regulatory burden and potential state law bans were not enough by themselves, any PHI stored offshore likely will be subject to local law of the country in which it is stored. Furthermore, these local laws may allow for actions or even access to the data that directly conflicts with requirements on healthcare providers under HIPAA/HITECH, even if the vendor signed a Business Associate Agreement (BAA). Due to the issues in enforcing HIPAA and HITECH, and even a BAA against an overseas vendor, HHS has basically stated that it is the duty of the healthcare provider or vendor for deciding how to vet data services vendors and comply with expected additional requirements when conducting a risk assessment on overseas providers. 

At this point, most healthcare providers question if any offshore or offsite data storage or processing is worth any potential cost savings, or if OCR has any further guidance. In the fall of 2016, OCR prepared guidance that explained how federal health information privacy and data security rules apply to cloud services. In summary, this guidance helped data service companies, but at the expense of covered entities by primarily placing the burden on the covered entities, specifically hospitals, insurers, doctors, and other healthcare providers.

In looking at data service vendors, OCR decided that data service subcontractors of the covered entities’ business associates are actually business associations of the business associates. According to the OCR, covered entities must assess the cloud services providers’ or offshore providers’ data security efforts, but HIPAA does not require the cloud services providers to allow covered entities audit them. As such, covered entities are required to determine how well a cloud services provider handles system reliability, data security, and data backup and recovery, without the ability to perform an audit. While this is problematic when dealing with domestic cloud service providers, it creates additional issues when dealing with overseas cloud service providers. 

While OCR allows use of overseas providers, as of right now the rules of HIPAA and HITECH fail to address any international aspects, leaving no requirements but also no protections for covered entities. If you select a domestic provider, the laws and regulations regarding PHI apply to both parties, but if an overseas provider is selected, HIPAA and HITECH will not apply, unless they contractually agreed to comply with such laws and regulations. If there is a breach and the overseas provider refuses to defend against or pay any fines or fees levied related to the breach, the covered entity may be liable for paying. It is also important to note that while an international provider may agree to sign a BAA, many international providers do not understand the requirements of HIPAA and HITECH, while most domestic providers have a greater understanding.

Even if you know where the company with whom you are contracting is located, do you know where they send the backup data? Do they send data for processing or backup to other agents, subcontractors, vendors, or other data providers overseas? You may not realize your data is regularly taking international trips, and may be better traveled than you are. In addition, if a relationship is terminated with an international provider, how will you ensure that the data is wiped from the system? Healthcare providers generally must require a certificate of destruction when terminating data services, and will you be able to comply with this provision with an offshore provider?

In contracting with cloud service providers, including backup providers, e-mail providers, and other processing entities, covered entities and their business associates must determine where their data is located, and if it is offshore, they must analyze if any of the information is prohibited from being exported by any state or local regulations. If not, next it must be determined if there is an extra compliance burden associated with the data being offshore, and if that extra compliance burden and the associated risk of being offshore are worth any cost savings by using the offshore provider. If an entity knows that some of its data may be banned from being exported overseas, or would raise too much risk or compliance burden, then language banning such exports should be placed in the agreements, including any BAAs. 

Used with permission from: Craig A. Phillips council member of Dickinson Wright

To subscribe to this blog, enter your email address:


Delivered by FeedBurner

Hold Your Business Associates Feet To The Fire

Documented HIPAA compliance training is NOT an option for your Business Associates!

With the focus of the Office for Civil Rights (OCR) so squarely on the Business Associates of Covered Entities, it is more important than ever to hold your Business Associates feet to the fire when it comes to providing proof of their HIPAA training.

It is strongly recommended that Covered Entities require {45 CFR 164.502(e), 164.504(e), 164.532(d) and (e)} all of their Business Associates to provide them with documented proof of their HIPAA compliance training. This documentation could come in the form of individual employee training certificates or (if the Business Associate does not have training certifications) a signed addendum along with your Business Associate Agreement (BAA) attesting to the fact that the Business Associate's HIPAA training program was completed and will continue to be on an annual basis to maintain a standard for ongoing compliance training and awareness of evolving standards.

Far too often, I have talked with Covered Entities who's Business Associates verbally claimed that all of their employees were HIPAA trained, but could not provided documented proof. Simply saying, "Yah sure, we do HIPAA training..." is not enough proof for OCR. It is vital that Covered Entities are able to provide documentation of their Business Associates claim that they have completed their HIPAA training. If a Covered Entity is working with a Business Associate who either does not have documented proof of their HIPAA training program or refuses to supply the Covered Entity with such documentation, then that Covered Entity has two options:

1. Recommend a BA HIPAA Compliance Training Program to their Business Associate;
2. Begin exploring the option of no longer doing business with that particular Business Associate

Remember a BAA is a binding legal Contract and should be treated accordingly. Having Business Associates provide documented proof of a HIPAA training program will greatly assist in helping to limit additional liabilities for a Covered Entity and their patients.

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