EHR System Down for Days: Patient Access Rights and HIPAA Obligations

When Your EHR Goes Down, HIPAA Obligations Do Not

Your EHR vendor pushes a bad update. A server failure takes your system offline. A ransomware attack encrypts your database. Whatever the cause, your practice cannot access patient records — and neither can your patients. The immediate operational crisis is obvious: you cannot bill, you cannot review histories, and you may be running on paper. But the compliance question that many practices overlook during the chaos is equally urgent: your patients still have a right to access their records under HIPAA, and that right does not pause because your systems are down.

The HIPAA Right of Access: 45 CFR §164.524

Under the HIPAA Privacy Rule, individuals have the right to access and obtain a copy of their protected health information maintained in a designated record set. This right is codified at 45 CFR §164.524. When a patient submits an access request, your practice must act on it within 30 calendar days, with a single 30-day extension available if you provide the patient written notice of the delay and the reason.

OCR has made patient right of access a top enforcement priority. The HIPAA Right of Access Initiative, launched in 2019, has resulted in dozens of settlements — many against small practices — for failures to provide timely access to patient records. Penalties in these cases have ranged from $3,500 to over $200,000, often accompanied by corrective action plans requiring policy changes and staff training.

An EHR outage does not create an exception to this obligation. If a patient requests their records while your system is down, the 30-day clock still starts on the date of the request.

What to Do When Patients Request Records During an Outage

The practical challenge is real: if you cannot access the records, you cannot produce them. But HIPAA still expects you to take reasonable steps. During an EHR outage, your practice should:

1. Log every access request. Document the patient’s name, the date of the request, what records were requested, and the current status. This log is your compliance evidence that you were tracking obligations even during the disruption.
2. Communicate proactively with patients. If you know your system will be down for more than a day or two, inform patients who have pending requests about the delay. Use the 30-day extension provision if needed — but you must notify the patient in writing and explain the reason (45 CFR §164.524(b)(2)(i)).
3. Check for alternative sources. If paper records, backup systems, or a patient portal that operates independently of your primary EHR are available, use them to fulfill requests where possible.
4. Prioritize access requests when the system is restored. Once your EHR is back online, pending access requests should be among the first items addressed — before the 30-day (or 60-day if extended) deadline expires.

Contingency Planning Under the Security Rule

The HIPAA Security Rule requires covered entities to establish contingency plans that ensure the availability of ePHI during emergencies. Under 45 CFR §164.308(a)(7), your contingency plan must include:

• Data backup plan: Procedures to create and maintain retrievable exact copies of ePHI.
• Disaster recovery plan: Procedures to restore any loss of data, including a defined process for bringing systems back online.
• Emergency mode operation plan: Procedures to enable continuation of critical business processes while operating in emergency mode. This is the plan that governs how your practice functions — including patient care and record access — while the EHR is unavailable.
• Testing and revision: Regular testing of contingency plans and revision based on test results.

If your practice does not have a documented contingency plan, the EHR outage itself exposes a Security Rule compliance gap that could compound any access-related violations. Conducting a thorough security risk assessment that evaluates system availability and downtime scenarios is the foundation of a defensible contingency plan.

When an Outage Becomes a Breach

An EHR outage alone is not automatically a HIPAA breach. The breach definition under 45 CFR §164.402 requires an unauthorized acquisition, access, use, or disclosure of PHI. A system that is offline but whose data has not been accessed by unauthorized parties has not experienced a breach in the HIPAA sense.

However, two situations can convert an outage into a breach:

• The outage was caused by a cyberattack that involved unauthorized access to or acquisition of ePHI. See our guide on ransomware response for the specific breach analysis that applies.
• The outage resulted in ePHI being exposed — for example, if staff printed records and left them unsecured, or if backup data was improperly handled during restoration.

Assess the cause and circumstances of every outage through the lens of potential unauthorized access, not just system availability.

The Operational Impact: What Happens to Patient Care

Beyond compliance, an extended EHR outage creates patient safety risks that have their own legal and regulatory implications:

• Medication errors: Without access to medication lists, allergy information, and prescription history, the risk of adverse drug events increases dramatically.
• Duplicate testing: Providers may order unnecessary labs or imaging because prior results are inaccessible.
• Care delays: Referrals, prior authorizations, and coordination with other providers all depend on record access.
• Documentation gaps: Care provided during the outage on paper must be reconciled into the EHR after restoration, creating opportunities for errors and omissions.

Your emergency mode operation plan should address each of these risks with specific procedures, including how to access critical information (medication lists, allergy alerts) from backup sources and how to document care during downtime in a manner that supports accurate back-entry.

Vendor Accountability and Your BAA

If your EHR vendor caused the outage through negligence, a failed update, or inadequate security, your Business Associate Agreement (BAA) governs the allocation of responsibility. Review your BAA for provisions addressing:

• Uptime guarantees and service level agreements (SLAs)
• The vendor’s obligation to report security incidents
• Indemnification for damages resulting from vendor-caused downtime
• Data recovery obligations and timelines

Even if the vendor bears contractual responsibility, your practice remains the covered entity with direct obligations to patients under HIPAA. You cannot outsource your HIPAA compliance obligations to a vendor — you can only contractually require the vendor to support them.

Building Resilience Before the Next Outage

Every practice will experience system downtime at some point. The question is whether you are prepared. Key resilience measures include:

• Regular backups with tested restores: A backup that has never been tested is not a backup — it is a hope. Test restores quarterly.
• Downtime procedures: Written, accessible (not stored only in the EHR) procedures for how to deliver care, handle patient requests, and document encounters during system unavailability.
• Communication templates: Pre-drafted patient notifications, staff instructions, and vendor escalation contacts that can be deployed immediately when an outage occurs.
• Vendor evaluation: Include uptime history, incident response capability, and data recovery timelines in your vendor risk assessment. A low-cost EHR with poor reliability can be far more expensive than a premium system when the true cost of downtime is calculated.
• Annual testing: Run a tabletop exercise simulating an extended outage. Identify gaps in your downtime procedures before a real event exposes them.

Integrating downtime planning into your overall HIPAA compliance checklist ensures that system availability is treated as the compliance obligation it is, not just an IT concern.

Frequently Asked Questions