Skip To Navigation Skip To Content Skip To Footer
    Rater8 - You make patients happy. We make sure everyone knows about it. Try it for free.
    Insight Article
    Home > Articles > Article
    Christian Green
    Christian Green, MA

    For physician practices, establishing a contingency plan is vital when attempting to recover electronic protected health information (ePHI) following a cyberattack or other incident that results in data loss.

    As part of the Department of Health and Human Services (HHS) 2005 HIPAA Security Rule, physician practices and other HIPAA covered entities must “[e]stablish (and implement as needed) policies and procedures for responding to an emergency or other occurrence … that damages systems that contain electronic protected health information.”

    While adhering to the Security Rule is a federal requirement, practices should approach this from a business perspective — as catastrophic loss of patient records, billing and other critical data, the lifeblood of the organization, could significantly affect business operations.

    To be compliant under the Security Rule’s contingency plan provision, practices are required to execute three actions:

    1. Data Backup Plan
    2. Disaster Recovery Plan
    3. Emergency Mode Operation Plan


    The Security Rule also includes two “addressable” implementation specifications:

    1. Testing and Revision Procedures
    2. Applications and Data Criticality Analysis


    In addition to the “traditional” data loss issues such as lost or stolen laptops or other mobile devices or natural disasters such as fire or flood that destroy computers, phishing, ransomware and other types of cyberattacks on computer systems should be included in every practice’s contingency plan. As stated in the Security Rule, practices need to establish “technical safeguards to ensure the confidentiality, integrity, and security (or availability) of [ePHI].” This starts with establishing a comprehensive plan, one that will vary by practice size and technical capabilities.

    According to Rana McSpadden, FACMPE, CPC, medical practice consultant and analyst, SVMIC, Brentwood, Tenn., “There is no one-size-fits-all solution. You can’t just go to the store, pick up a book, put your name on it, and stick it up on your shelf and call it your contingency plan.”

    Rather, practice administrators should create a living document specific to the needs of their organization. After all, each practice handles business and operations in its own way. Typically, practice administrators will want to work directly with their IT staff (or with their third-party vendor if their IT is outsourced) in the development and implementation of their contingency plan, because they are well-versed in the myriad of cyber threats.

    Data backup

    Practices are required, under the Security Rule, to have a data backup plan. As practices develop their data backup plan, they should assess the following:

    • What data to back up: In addition to the data contained in the EHR, practices should strongly consider backing up other important data. This could include claims data in the billing system, benchmarking or quality reporting data, clinical trials data and practice personnel data.
    • What type of storage to employ: Practices also should consider having a physical backup for medical records and other key data, such as a fireproof safe or a bank lockbox. If the practice is large enough, consider engaging a vendor to come in each day to store data off-site.
    • What type of backup to employ: Full (everything as it looks on the computer at a specific time), incremental (any changes since the last backup), differential (any changes since the last full backup) or mirror (exact copy from one to the other). It may be beneficial to utilize more than one backup; for example, a differential every week and a full backup every month. 
    • How often should data be backed up: Quarterly, monthly, weekly, daily or several times a day. This will be dictated by the amount of data the practice has and will go hand in hand with the type(s) of backup employed.


    Another critical issue is the method practices use to back up data. The most common approaches are backing it up on an external hard drive located in the practice or on the cloud, with both having pros and cons.

    Leveraging external hard drives has the advantage of keeping the storage nearby and providing immediate access to the data, if needed. External drives, even those capable of handling many terabytes of data, are relatively inexpensive. The downside of using external drives is that they require practice staff to continually and manually move data from the computers to the external hard drives. In addition, external hard drives located in the practice are susceptible to theft or damage due to fire or floods.

    In many cases, storing backup data in the cloud allows for automatic data transfer that eliminates the need for staff to continuously upload a copy of the data. Also, the data is stored offsite and would not be affected by theft, fire or flood. Although many cloud storage options are reasonably priced, practices must incur the cost of having high-speed broadband internet to ensure that data transfer is efficient and that the upload process doesn’t affect the regular use of the internet by the practice.

    Once these issues are finalized, McSpadden suggests creating a schedule and ensuring it is followed. 

    Disaster recovery plan

    Effectively and efficiently backing up data will go a long way in making a disaster recovery plan easier to carry out. As McSpadden notes, “If you have a good backup, if your computer systems get ransomed, you can actually restore from that backup as if nothing has happened.” However, it’s important to note that ransomware could be in the system for days, weeks or even months before a cyberattacker decides to take over a system, which means ransomware could be in the backup files as well.

    When creating a disaster recovery plan, focus on four aspects of recovery:

    • Hardware: Is the server housed in the practice or is it on the cloud? Each will require a different recovery approach. Also, think beyond the practice’s computers: Consider the printers, diagnostic equipment and any other connected hardware when developing a recovery plan.
    • Software: Beyond EHR software, practices need to consider how software is dependent on other software to function. Will it be necessary to restore certain applications or software integrations before moving on to another?
    • Process for restoration: Practices should have a plan to guide them through a step-by-step restoration process. By having a plan in place, they can confirm what needs to be restored first and what isn’t a priority.
    • Data: Practices need to calculate the amount of data that could be affected during a cyberattack, which is largely dependent on their EHR. Practice staff should speak to the EHR vendor to help determine if their entire system needs to be restored in the event of a cyberattack.

    Emergency mode operation plan

    The final required implementation specification is to have an “emergency mode operation plan” or as McSpadden posits, “what is the minimum we have to have access to in the event of an emergency?”

    • Need vs. security: Practices should know what information they need to treat patients during an emergency. Is there a secure way to access EHR and/or patient billing information? If ePHI is lost or held hostage, to avoid having to shut the doors, is there a process in which physicians and other staff can drop back to paper?
    • Alternative security measures: If the practice doesn’t have access to a secure network, what alternative security measures can be taken? Is a virtual private network (VPN) available for use on staff mobile devices such as phones, tablets or laptops?
    • Personnel: In preparation for an emergency, have staff members been adequately trained to know their responsibilities and where they need to be?

    Testing and revision procedures

    The testing and revision implementation specifications, along with conducting an applications and data criticality analysis, although deemed “addressable” under the Security Rule, still must be carried out by the practice or the practice must document in writing the reasons why they were not. However, from a practical perspective, all practices should strongly consider implementing these specifications. Practices should:

    • Test backup systems: Don’t get caught off guard when systems go down, so regularly test backups to ensure they haven’t also been compromised.
    • Conduct mock scenarios: If backups cannot be tested, practice mock scenarios with your staff.
    • Clarity for personnel: By practicing, staff will be familiar with different scenarios, their duties during emergencies and where they should go.
    • Review results: Once these tests or mock scenarios are carried out, evaluate what worked and what did not.
    • Prioritize: For data backup, restoration and emergency operations, determine the most important data and systems needed when operating under emergency conditions.
    • Document: During this process, make sure everything is documented and verify what needs to be corrected.

    Cyber insurance

    Practices should consider acquiring cyber liability insurance, which is sometimes covered under malpractice insurance or a general liability plan. “It’s not just a cyberattack that cyber insurance will actually cover, they could cover any kind of electronic HIPAA breach, it just depends on the policy,” emphasizes McSpadden. “So they’ll pay for the investigation, they’ll help you pay for the breach notification, they’ll help you pay for the results of all that.”

    By following these implementation specifications to create and carry out a data backup and disaster recovery and contingency plan, practices can better protect patient and practice data from outside threats and safeguard against negative impacts to business operations.


    Christian Green

    Explore Related Content

    More Insight Articles

    Ask MGMA
    An error has occurred. The page may no longer respond until reloaded. Reload 🗙