The Health Insurance Portability and Accountability Act (HIPAA) 42 U.S.C. § 1320(d-1)(b) empowered the Secretary of Health and Human Services to promulgate standards for health care providers that “shall be consistent with the objective of reducing the administrative costs of providing and paying for health care.” Under Section 1320(d-2)(d), Congress empowered the Secretary to establish regulations for the security of health information. Under that grant of power, the Secretary promulgated rules on technical security in 45 C.F.R. section 164. Section 164.308(a)(7)(ii)(B), under the heading “disaster recovery plan,” requires that a covered entity establish “procedures to restore any loss of data.” The next section requires that the covered entity be able to operate its critical business processes during an emergency while still protecting the security of its protected health information.
Recovering from a disaster is a relatively complicated matter for most health care providers that have implemented a sufficiently robust system or network. This is because many health care providers regularly use a system for email, a system for managing appointments and billing, a different system for accounting for expenses and payroll, another system for managing health records, and other supporting systems (such as a Windows domain controller, file and print sharing, and other administrative servers). In some cases, rather than hosting these servers in-house, some providers have contracted with outside vendors that provide hosting services, or application service provider (ASP)-models for specific applications used by the provider.
The complexity of a recovery is increased by the nature and number of disasters that could occur to a provider’s information systems. For example, disasters include uncontrollable events such as hurricanes or floods, fires, and other natural disasters, but could also include technical failures such as a widespread and uncontrolled computer virus, or concerted terrorist activities that disrupt electrical power or harm human life.Each risk presents a different set of issues for a health care provider.
The other part of the recovery equation is what the organization’s expectation is for the time to recover from a system failure, and the relative tolerance of the organization for an outage. Some health care providers that operate all the time (like an emergency room) may not be able to tolerate long outages in order to provide care effectively for patients. Smaller providers may not be able to tolerate a long outage because of the financial impact on their practice. However, some systems may be less critical for recovery because their loss will not immediately stop a practice from seeing patients. Sorting out the complexity of recovery requires planning before a disaster hits.
Risk Analysis
Section 164.308(a)(1)(ii)(A)-(B) of the regulations require that all covered entities engage in regular risk analysis and risk planning and take action on this analysis to reduce risks to electronic protected health information. This analytical process is helpful in guiding the development of a disaster recovery plan because the risk analysis identifies all systems and data in use in the business organization, and helps to guide the organization to those systems that are sufficiently critical to require disaster recovery. Of those critical systems, some may require a more complicated or expensive disaster recovery plan in order to make them available more quickly in a disaster. For example, a payroll system, while critical to an organization’s efforts to operate, may not need to be available as quickly as a health record system because the organization may only provide paychecks every other week, whereas users access the health record system for each patient visit on a daily or hourly basis.
Developing A Recovery Plan
Once the organization has assessed its risks, the organization can develop a plan to manage those risks, which includes setting expectations for recovery time, describing particular disaster scenarios and the organization’s response to those scenarios, and identifying the resources needed to effectively recover from particular disasters. The organization’s plan can also identify when an organization will re-open for business following a disaster, whether or not the provider anticipates having to operate during a disaster (such as an emergency room staying open during a bioterrorism event), what the chain of command will be to respond to a disaster, and a communication plan for letting customers and staff know the status of the organization during and after an event.
The systems team can use this high level plan to examine in more detail the individual systems in play in the organization, and can evaluate what methods for recovery can be cost-effectively implemented to meet organizational requirements. For example, a weekly digital tape backup may be adequate for less critical systems that change little from week to week, whereas a real-time replication system may be required for highly critical data.
Testing and Making Plan Changes
Once a systems recovery plan has been developed, testing the plan is absolutely essential to ensure that the plan on paper will actually work in a real disaster. Practice is important for several reasons. First, systems staff that participate in testing will have a better idea of what to expect if a system failure occurs and will be more capable of responding to it. Second, testing helps to identify missing steps or pieces of the plan which can be addressed by the systems department before the next round of testing. Third, testing helps to identify how much training will be required for systems staff to be able to effectively respond to a failure. And finally, involving the end users in the testing cycles helps to set expectations appropriately should an actual disaster occur.
Keeping Up With System Changes
Doing a risk analysis, creating a recovery plan and testing the plan is most of the preparation for recovering from a disaster, but the systems that belong to the plan will change with time. All systems have patches and upgrades that need to be applied each year. In addition, organizations routinely add new systems, which may present new challenges for recovery planning. And, of course, personnel trained to perform recoveries will change with time, which will require that new staff that join the team be trained on system recovery. Do not underestimate the time and effort required to include additional systems in the testing and recovery plan.
Mitigating Disasters
Mitigations, like anti-virus software, automatic patching and control systems, firewalls and other border control devices, organizational policies on system account controls, robust permissions, and other mitigations are also absolutely essential to any disaster recovery process. As any systems veteran will tell you, avoiding a systems recovery is a systems department’s top priority. But mitigations are not an excuse for not having a disaster recovery plan, because no mitigation will be one hundred percent effective at preventing all system failures. Being prepared is always the best policy.
Need help getting your systems department prepared for disasters? Give us a call or send us an email.
Faith At Law LLC 