Most healthcare organizations have switched from paper medical records to electronic health records (EHR). But what happens when you cannot access your EHR or other network systems?
The average system downtime[1] costs a healthcare organization $7,900 per minute. These downtimes can compromise patient data and disrupt patient care. Common examples of EHR downtime on third-party systems include cyberattacks on EHR systems, software malfunctions, hardware malfunctions, and Internet problems.
Healthcare organizations are required by the HIPAA Security Rule to have a contingency plan to continue patient care delivery in the event of a system downtime whether caused by their own IT system or by a third-party system.
This article describes how healthcare organizations should respond during EHR downtimes and provides best practices on how to mitigate the extent of downtime caused by a third-party vendor or IT system provider. This article is intended for small physician practices that may not have an internal IT department.
What Should Healthcare Organizations Immediately Do When Their Systems Go Down?
System disruptions due to service downtimes can be frustrating, especially in healthcare. Having a plan in place, though, can alleviate panic and provide actionable steps to begin resolving the problem. First, healthcare organizations should communicate with staff, executives, and necessary third parties about the downtime. During EHR downtime, communication is essential for ensuring a quick and efficient response. In preparation for downtime, healthcare organizations should designate a point of contact for internal and external communications. The point of contact would have the primary responsibility of facilitating a call “command center” so that the point of contact may provide status updates to the clinical staff and necessary personnel during the downtime. These responsibilities may also include notifying vendors accordingly.
General Best Practices for Effectively Responding to Downtimes Caused by a Third Party
1. Create/Implement an Incident Response Plan
An incident response plan is crucial to responding to downtime. Without a strong incident response plan, a healthcare organization can be nonoperational for days, weeks, and even months. To create a good incident response plan, healthcare organizations should ask the following questions:
- Who is in charge of managing the incident?
- Who is the point of contact for internal and external communications?
- What are the roles and responsibilities of each person on the response team?
- Is there a plan for a short-term downtime (e.g., a few hours)? For an extended downtime (e.g., several days, maybe even a week)?
- Is there a plan for every kind of downtime caused by a third party (e.g., internal and external EHR downtimes)?
- If the downtime results from a security incident, does the incident response plan include other policies and procedures such as responding to a cyberattack?
- If the downtime results from a security incident, what vendor is available to conduct a forensic investigation?
Sample incident response plan templates can be found in the MagMutual cyber portal.
After answering these questions in the incident response plan, the incident response team should list circumstances that may lead to short-term disruptions in patient care. Downtimes from a data breach will require different responses from other downtimes. So, for each kind of downtime, the healthcare organization should develop checklists of action items for each type of downtime that staff can use.
Healthcare organizations should routinely run practice drills of each kind of downtime. Practice drills can involve simulations of certain outages, including EHR downtime in certain sectors and certain portions of the physical space not having their IT systems running. Healthcare organizations should also involve third-party vendors in these practice drills, especially in drills involving EHR downtime. After running the drills, healthcare organizations should assess and evaluate the efficiencies and deficiencies of the drills. Future practice drills should focus on improving weaknesses in the incident response time.
Healthcare organizations should institute a plan for transferring information from backup systems (such as paper records) to EHR. This plan will occur at the final steps of an outage. And, organizations should regularly test and maintain these backup systems by conducting regular drills on how to access and restore the backup systems when EHR downtime occurs.
For outages that happen because of a data breach, healthcare organizations should retain outside counsel once they are notified of the data breach. Having legal counsel at the beginning of the process will help organizations strategize how to contain the breach and when and how to notify the correct authorities to ensure compliance with federal, state, and local notification laws. Several disclosure requirements depend on a certain number of patient records being compromised, so healthcare organizations should consider engaging a forensic investigator to determine the full extent and damage of an EHR downtime.
2. Designate an Individual to Document the Downtime
This documentation will be helpful for insurance purposes and for notifying authorities. The documentation should include the date and time the outage occurred, when authorities were notified, and what steps were taken to mitigate the extent of the outage.
Healthcare organizations should involve executive leadership in developing, coordinating, and testing incident response plans. Having executives involved in the incident response plans will reduce confusion among clinical staff and limit delays in patient care delivery.
3. Policies for Preserving EHR
Healthcare organizations should institute and follow policies addressing how they will document phone messages, lab results, diagnostic test results, and patient encounters without EHR. As part of these policies, healthcare organizations should go through each type of documentation used during a patient visit, such as paper records, lab diagnostics, appointment schedules, and patient charge forms, and ensure paper backups are in place for each type of documentation in case of an EHR downtime.
Healthcare organizations should routinely update these paper backups and train clinical staff and third parties on where to find and how to use these paper backups.
4. Run Backups and Store Backups in Different Areas
Failure to conduct routine backups internally can leave healthcare organizations vulnerable to compromising patient data. If systems are not backed up regularly, outages can cause unsaved data to be lost and extend the length of a system outage. Running routine backups on IT systems and EHR can help healthcare organizations preserve the most recently saved data and save time in trying to return to normal operations.
Considering off-site v. on-site backup systems – Healthcare organizations should have a backup system off-site that can be easily accessed in the event of an outage. This backup system can be either a cloud-based storage system or a physical server. Cloud-based storage is an Internet-based system that can be connected to multiple organizations, network systems, and devices. Having a cloud-based system would be more cost-effective than physical servers but may lead to more security risks depending on how much of the healthcare organization’s IT systems are connected to the cloud-based system. Physical servers allow healthcare organizations to control data storage and accessibility to that data. But physical servers are a more expensive investment than cloud-based storage and may not be feasible logistically and financially for some healthcare organizations.
Having a system off-site will help healthcare organizations preserve information and minimize the extent of an outage. This off-site system should be a “read-only” system that is available for any outage or downtime. This “read-only” system should be updated along with other online systems, and healthcare organizations should institute and follow protocols for when and how to access the off-site backup when an outage occurs.
5. If a Data Breach Causes the Outage, Contact the Relevant Authorities and Let Them Know What Happened
Once a breach occurs, healthcare organizations must notify certain authorities of the breach. MagMutual has created separate guidance that goes more into depth about how organizations can respond when they receive notice of a data breach from a third-party vendor. This guidance can be found here.
6. Debrief and Analyze the System Outage
Before analyzing a system outage, healthcare organizations and third parties must first contain the outage, according to the incident response plan. Containing an outage will depend on the type of incident, but common practices include disconnecting affected systems, isolating malware, disabling network access points, and restricting Internet traffic.
After you have contained the system outage and contacted the relevant authorities, healthcare organizations should debrief and analyze why the downtime occurred. When conducting an analysis, organizations and third parties should consider the following questions:
- What happened and at what times?
- How well was the incident handled?
- Were documented procedures followed? Were the documented procedures adequate?
- Were any steps or actions taken that may have inhibited recovery?
- How could communications have been improved during the incident?
- What corrective actions could prevent a future, similar incident?
- Were there signs that were missed? Does monitoring need to be refined?
The next section of this article will address another important part of the analysis: assessing your relationships with your third parties.
What Policies and Procedures Should Be in Place Between Providers and Third Parties to Prevent Future Outages?
To prevent future downtimes, healthcare organizations should treat third-party risk as their own risk. Therefore, organizations should require third parties to maintain compliance on security requirements under applicable privacy and security laws. Compliance on security requirements may include assurance from third parties that their security systems comply with applicable federal, state, and local privacy and security laws.
Healthcare organizations should also review their Business Associate Agreements (BAAs) with third parties. BAAs should have provisions about data storage and disposal, descriptions of vendor’s privacy and security programs, right-to-audit clauses, and protocols for disclosing when deficiencies in security systems have been identified.
How Can Third Parties Make It Right with the Healthcare Organization?
After an outage caused by a third party, a healthcare organization and its third-party vendor may want to maintain their professional relationship. The organization should review its agreement with the third-party vendor to see what services the third party will offer for an EHR downtime. These services may include a discount in services, credit monitoring to patients, ability to modify agreement, and reimbursement for outage-related expenses. If the agreement does not indicate any services, healthcare organizations should reach out to the vendor’s sales representative to see what the vendor offers to other clients in the event of an outage.
If the agreement does not say how third parties will reimburse healthcare organizations for an EHR downtime, organizations should negotiate with third parties on how they will reimburse the organization for expenses related to the EHR downtime, including notification expenses, liability expenses, and other expenses that helped minimize the downtime. If the third-party vendor is not willing to negotiate, consider engaging an outside attorney.
If a healthcare organization believes legal recourse is necessary because of the outage, the organization should review its contract with the third-party vendor to see what legal recourse is available under the contract. Examples of legal recourse include arbitration and mediation. If the healthcare organization decides legal recourse is necessary, consider engaging an outside attorney.