Who Fixes the EHR When It Goes Down: Vendor vs IT Provider

Ask what layer failed, not who sold you what. If the problem hits every workstation, from every network, for every user, it is almost certainly the application or the hosted platform — vendor territory. If it hits one machine, one exam room, one user, or only people on VPN, it is your infrastructure — your IT provider’s territory.

Teach that test to whoever answers the phone. Have someone try the EHR from a different workstation on a different network segment; that single data point routes the ticket.

One regulatory wrinkle before you dial. An EHR vendor that hosts, stores, or supports systems containing electronic protected health information is a business associate under 45 CFR 160.103 — the test is whether it creates, receives, maintains, or transmits ePHI on your behalf, not whether anyone there reads charts. HHS said an entity maintaining PHI for a covered entity “is a business associate and not a conduit, even if the entity does not actually view the protected health information” the preamble to the 2013 HIPAA Omnibus Final Rule. Your IT provider typically meets the same test. Neither agreement makes the outage someone else’s problem to plan for.

Interfaces are where most finger-pointing happens. Some of what they carry is federally specified — the adopted API base standard for certified health IT is HL7 FHIR Release 4.0.1 under 45 CFR 170.215(a)(1), as amended in August 2025, still R4 even though HL7 has since published FHIR 5.0.0. When someone calls the interface “just a vendor thing”: message content is the vendor’s, the pipe is your IT provider’s. Get both on one bridge. More on that handoff on our EHR integration page.

What administrators get wrong: a signed business associate agreement does not move your contingency planning obligation onto the vendor. Under 45 CFR 164.306(a)(1) you must ensure the confidentiality, integrity, and availability of ePHI. Availability is in the text — which makes EHR downtime a compliance matter, not only an operations headache.

The contingency plan standard at 45 CFR 164.308(a)(7)(i) requires procedures for responding to an emergency or other occurrence — the rule lists fire, vandalism, system failure, and natural disaster — that damages systems containing ePHI. It has exactly five implementation specifications:

• (A) Data backup plan — Required. Create and maintain retrievable exact copies of ePHI.
• (B) Disaster recovery plan — Required. Procedures to restore any loss of data.
• (C) Emergency mode operation plan — Required. Continue critical business processes while protecting ePHI security in emergency mode — the paper-charting workflow, downtime order forms, manual medication reconciliation.
• (D) Testing and revision procedures — Addressable. Periodic testing and revision of contingency plans.
• (E) Applications and data criticality analysis — Addressable. Assess the relative criticality of specific applications and data.

Three Required, two Addressable — a split that gets mis-stated constantly. “Addressable” is not “optional.” Under 45 CFR 164.306(d)(3) you assess whether the safeguard is reasonable and appropriate in your environment, then either implement it or document why it is not and implement an equivalent alternative where one is reasonable and appropriate. HHS has said reading addressable as optional “is incorrect and weakens the cybersecurity posture of regulated entities” (HHS’s HIPAA Security Rule proposed rule, published January 6, 2025) — language from a proposed rule published January 6, 2025 that is still pending and subject to change.

Two things the rule does not specify: a recovery time target and a testing interval. No HIPAA-mandated RTO, no maximum tolerable downtime, no required backup frequency. Specification (D) says “periodic” and nothing more. Anyone quoting you a HIPAA-required number here is inventing it. The rule is deliberately scalable — 45 CFR 164.306(b) tells you to weigh your size, complexity, and capabilities, your technical infrastructure, the cost of the measures, and the probability and criticality of the risks.

Documentation carries a retention clock too: six years from creation or from the date it was last in effect, whichever is later, under 45 CFR 164.316(b)(2)(i). Confirm how this applies to your practice with your own counsel.

Build a single-page escalation card for the front-desk cabinet: vendor support number, your IT provider’s number and after-hours path, who declares downtime, and where the paper packets live.

• Run the cross-workstation test as step one, every time. It routes the call.
• Name the decision-maker. Someone has to say “we are on paper now” and mean it, or the practice loses an hour deciding.
• Print the packets in advance. A downtime plan stored only in the EHR is not a downtime plan.
• Test a restore, not just a backup. A backup nobody has restored from is an assumption.
• Confirm after-hours coverage on both contracts, and what the vendor’s severity levels mean.
• Know your cost of an hour down. Our downtime cost calculator gives you a defensible number for the budget conversation.

Most of this belongs with your risk analysis. If yours is stale, start with the HIPAA risk assessment tool and read it alongside our HIPAA compliance and business continuity pages.

The backup and recovery mechanics behind specifications (A) and (B) are covered separately in our disaster recovery and business continuity guide, and the wider practice-level view in HIPAA-compliant managed IT for Texas medical practices.

Who do I call first when the EHR is down — the vendor or my IT provider?

Call your IT provider first in most cases. They can determine within minutes whether the problem is local — network, workstation, VPN, credentials — or genuinely application-side, then drive the vendor ticket with detail attached. The exception is a vendor-published outage notice, which answers the question before you dial.

Does our BAA with the EHR vendor cover our contingency plan requirement?

No. Under 42 U.S.C. 17931(a), sections 164.308, 164.310, 164.312, and 164.316 apply to a business associate in the same manner they apply to the covered entity. The duty is parallel, not transferable. Your practice still needs its own data backup, disaster recovery, and emergency mode operation plans.

Does HIPAA require our EHR to be restored within a specific number of hours?

No. The Security Rule sets no recovery time objective, no recovery point objective, no maximum tolerable downtime, and no backup frequency. Those are business decisions you make on clinical risk and document. Anyone citing a HIPAA-required recovery number is not quoting the regulation.

Whose fault is it when lab results stop flowing into the chart?

Usually shared, which is why it stalls. Message content and application-side configuration belong to the vendor and the lab system. The connectivity carrying those messages — VPN, firewall rules, certificates, DNS — belongs to your IT provider. Confirm traffic is reaching the endpoint first; that determines who owns the fix.

If your practice cannot answer “who do we call” without a debate, close that gap now. See how we handle the vendor boundary on our EHR integration page, and how it fits with help desk support and our healthcare IT work.