As you probably know, an important requirement of the HIPAA Security Rule, and an IT best practice, is to have a formal IT disaster recovery plan. It must provide for the orderly restoration of your community hospital’s IT systems should an event occur that renders some or all of your systems unusable. While this sounds like a pretty basic, common-sense requirement, many Covered Entities (CE) don’t have one today – so you’re probably not the only one out there reading this.
We know that creating a DR plan isn’t a quick and easy task. In fact, that could be why you are reading this blog in the first place… because your healthcare organization may not have one in place yet and you need to know where to start. Here are 6 steps to put a successful IT disaster recovery plan in place at your hospital or clinic.
Step 1: Compile An IT System Inventory
Begin by assembling a list of application systems (like your EHR, PACS, etc.) so that you have an inventory of what all you need to consider, and go from there. Don’t forget to include things like executive dashboards, shared and departmental file storage, patient portals and your internal Intranet. It’s surprising when you begin to take inventory just how many systems you have in use. This inventory will become the basis for your DR Plan. Don’t stop at just assembling what systems need to be recovered. There are key processes that need to be planned out should the disaster recovery plan ever need to be put in use.
Step 2: Conduct A Business Impact Analysis To Identify Core Requirements
Take the systems inventory and conduct a Business Impact Analysis (BIA) on each System. The advantages to this analysis are many, so I’ll highlight just a few that will help as you construct your plan. A Business Impact Analysis is a tool that gathers important information about the system, such as vendor contract and contacts, hardware/software components, inbound and outbound interfaces, and helps you determine the priority and value to the organization. It will also be where you determine the system’s recovery point objective (RPO) and recovery time objective (RTO). The recovery point objective identifies how far back you’re willing to go to restore from backups. In other words, if you backup systems once each day at 1:00am, that is your recovery point. Your analysis should determine if that is acceptable to the stakeholders of that system. This means that if they only want to have to re-key/capture data back four hours, and you only back up once a day, there is disparity between your RPO and your backups.
Your recovery time objective defines how quickly you’ll need to have the system back up and running. This is determined, in part, by how long the organization can go without the system before it impacts operations. So if it takes 48 hours to procure replacement servers and restore from backups, and you can only go 24 hours without significantly impacting operations, you’ve got a problem that’s not going to make patients and end users happy. This is important to know before you have a loss of systems, not when patient safety and care are on the line.
While there are many different strategies that will help you bring RPO and RTO in line with your organization’s expectations, there will be varying costs that will help define and refine those strategies. Typically, the shorter your recovery point and time objective is, the higher the cost will be to put solutions in place to support them. This is why you’ll need to work in concert with stakeholders to determine the right balance.
Step 3: Create A Contingencies Plan
Your disaster recovery plan should have a site identified for relocation of your datacenter in the event the existing one becomes unusable. In many community healthcare settings, this is sometimes a local school or church. Be sure to work out all the details with these alternate sites as part of your DR plan. Consult with other business and government agencies as they may be looking to use those same facilities during a disaster. You must plan for alternate sites to your main relocation site, as it may be damaged and unusable as well. Having a second and third site pre-determined will save valuable time and confusion during a likely chaotic time. Also, be sure to know what infrastructure is in place at the alternate sites, as each one may have limitations and will require additional equipment, service, supplies, etc. that may be unique to each setting.
Step 4: Identify The Details In Your DR Plan
As you develop your IT disaster recovery plan, you’ll find that the tendency is to keep it fairly high level when it comes to describing the recovery process. That’s because most will assume that the IT staff knows what to do and how to do it. Depending upon the event that occurs, this assumption could hinder and greatly delay your recovery.
Imagine your community hospital’s town is hit by a strong tornado, leaving most of the town in ruins. You have a plan in place that relies on your staff to come in and bring your systems back online. But, with most of your staff personally affected by the tornado as well, you may suddenly find yourself relying on outsiders to bring your systems back up while your staff deals with their personal recovery effort. When you put your plan together, put sufficient detail in it so knowledgeable resources unfamiliar with your particular systems could use your plan to effectively and successfully complete the restore. Better yet, align yourself with a partner and make them a part of your testing and execution strategy. Chances are, even if your staff members are available, the extra hands will be of great value.
Step 5: Be Sure To Test Your Plan
Once you have your DR plan developed (or as you complete sections of the plan), be sure to test it for reasonableness, accuracy and completeness. As you find issues or gaps, revise the plan and retest it. Make sure to schedule annual testing going forward and make the exercise a part of your Strategic IT Plan. Continue with this process until you are confident that it will provide for recovery should the need arise. Remember, patient safety and proper care may be riding on your ability to get the systems back up and running quickly. The DR Plan should define the process that will be undertaken to return to normal operations when that time comes.
Step 6: Make Sure To Share the Plan!
Finally, once you have the plan developed and adequately tested, make sure it is regularly reviewed by the executive team and approved by the board. It is important that they know the contents of the plan, what the process is (who declares a disaster, who initiates the plan, etc.) and are comfortable that the plan meets the needs of the organization. They will also be key to getting initiatives and capital approved for the backup and recovery strategies you will need to meet the RPO & RTO parameters. They should also be briefed annually after the testing has been completed, sharing results of the tests and any revisions that were made to the plan. You should also have the Board approve the IT DR plan each year.
While the task to create an IT DR plan may seem daunting, start with the basics and build up from there. Having something, even though it may not be robust, is better than nothing. Banking on luck and fingers crossed is not going to ease anxiety and promote confidence in the event of a disaster. The important thing is to get started and then be diligent about testing and improving it over time.
Do you have a plan in place if disaster strikes? We can show you how to create and implement DR best practices.
Schedule a FREE Q&A Session With Our Virtual Security Officer To Get Started