EHR Downtime Protocols for Telehealth-Only Practices

EHR downtime protocols built for hospitals assume a building. They assume a waiting room where a nurse can hand someone a clipboard, a pharmacy down the block, a chart cart that still works when the network doesn't. Telehealth-only practices have none of that, and when their systems fail, the visit doesn't get inconvenienced, it simply stops existing.

How often EHR systems go down, and why cyberattacks have made the question urgent

Downtime is not rare. A study published in the International Journal of Medical Informatics found that by 2014, 96% of healthcare institutions had experienced at least one unplanned downtime in the prior three years, and 70% had experienced one lasting more than eight hours. The same study found most of those institutions had only partially built out contingency plans, which means the gap between "this will happen" and "we're ready for it" was already wide a decade ago. It has not closed since.

What's changed is the cause. Healthcare accounted for 22% of all disclosed cyberattacks in 2025, with attack volume up nearly 50% year over year. The Ponemon-Sullivan Cyber Insecurity in Healthcare study found that 93% of surveyed organizations had experienced at least one cyberattack in the prior twelve months, and among those hit, the average number of attacks was 43, up from 40 the year before. Among organizations that experienced one of the four attack types the study tracked, 72% reported disruption to patient care, up from 69% in 2024. These are not marginal increases. They describe an environment where attacks are no longer occasional shocks but a recurring operating condition.

The cost of getting caught by one is severe. When hospitals are forced into downtime procedures after a successful attack, the average duration runs upwards of 24 days, at an average cost of $10 million. In 2024, 181 confirmed ransomware attacks hit US healthcare providers, roughly one every two days. The Change Healthcare attack that began in February 2024 caused more than six weeks of operational downtime across US healthcare payment processing, and because Change Healthcare processes roughly a third of all US healthcare claims, the damage rippled far past the company that got breached.

That ripple effect matters specifically for telehealth. Over 80% of stolen protected health information records originate from third-party vendors, software providers, and business associates. A telehealth-only practice runs entirely on third-party infrastructure: video vendor, cloud host, scheduling platform, billing clearinghouse. There is no internal system to retreat to. And correlated failure is not theoretical. The Cloudflare disruption on November 18, 2025, took down major services and social platforms simultaneously because they all sat on the same CDN layer. A telehealth stack built the same way can lose video, scheduling, and the patient portal in one event, not three separate ones.

What the existing regulatory frameworks require of telehealth-only practices

HIPAA's Security Rule requires covered entities to maintain a data backup plan, a disaster recovery plan, and an emergency mode operation plan, along with testing and revision procedures and an analysis of which applications and data are most critical. None of that responsibility transfers to the vendor. If a hosting provider or scheduling platform fails, the covered entity still answers for it, and the consequences for failing to answer well include civil monetary penalties, corrective action plans, and the kind of reputational damage that's hard to walk back in a small specialty practice. The 2026 update to the Security Rule adds specific requirements for telehealth session security and remote patient monitoring data protection, tightening the bar further.

ONC's SAFER guides treat contingency planning as a patient-safety issue, and the contingency planning worksheet covers scenarios like extended power outages and shifting to backup systems. It's a reasonable foundation, but it was written with a building in mind. The AMC PSO EHR Downtime Task Force recommendations, covering downtime plans, drills, staff training, and communication triage, spend most of their attention on pharmacy, lab, blood bank, and radiology continuity. A telehealth-only practice has none of those departments. The AMA's six-category checklist (communication, patient visits, documentation, billing, prescription management, and orders/referrals) comes closer to something usable, but "patient visits" still assumes a waiting room exists, and "communication" still assumes an on-site phone system that a receptionist can pick up.

One recommendation actually does translate cleanly: ONC's guidance to test redundant systems and backup procedures applies just as well to a video platform and a cloud EHR as it does to a hospital network. CMS has also moved to require that telehealth platforms be HIPAA-compliant and provide audio and visual quality adequate for clinical assessment, phasing out the consumer-grade video workarounds that were tolerated during the public health emergency. That's a tightening, not a relief.

What none of these frameworks address is the actual failure mode telehealth practices face most: the video platform itself going down mid-visit. No federal guidance says how to maintain continuity of a session across a fallback channel, or how to document a mid-visit platform switch in a way that satisfies both a clinical record and a billing claim. That's the gap a practice has to fill on its own.

The dependency map a telehealth-only practice must build before writing a single protocol step

Before any fallback procedure gets written, someone has to draw the actual dependency map: every service a single visit relies on, and who is responsible for each layer of it. It carries real weight. It's the document every subsequent protocol step will point back to.

The map needs to cover the primary video platform (which vendor, which cloud or CDN it runs on, whether a signed BAA is in place, what the SLA actually promises for uptime), the EHR itself (cloud-hosted or locally installed, whether it supports an offline documentation mode, how often data backs up), scheduling and the patient portal (often the same vendor as the EHR, sometimes not, and critically, whether a portal outage also kills the appointment links patients need to join a visit), billing and claims (the Change Healthcare collapse is the clearest illustration of how a single clearinghouse failure can paralyze billing for a practice that never had an internal problem at all), the patient communication channel (how reminders and outage notices reach patients, and whether that channel depends on the same infrastructure it's supposed to be a fallback from), and connectivity itself, meaning office WAN, clinician home broadband for remote staff, and cellular data, because a failure in this layer produces failures in every layer listed above it and the map must name it as their common cause.

The vendor inventory that comes out of this exercise needs data classifications and risk tiers attached to each entry, tied to PHI exposure and how critical that service is to keeping the practice running. Not just a list of names. Every BAA in that stack should spell out security controls and breach notification timelines, and should include right-to-audit language and a defined path for disclosing security deficiencies when they turn up. Vetting shouldn't stop at onboarding, either: security questionnaires, control evidence, penetration test summaries, and architecture reviews belong at renewal too, given that over 80% of stolen PHI records trace back to third parties rather than the covered entity itself.

The map also needs to surface single points of failure directly. If the video platform and the EHR both sit on the same cloud provider or the same CDN, a regional outage takes both down at once, and no amount of protocol writing fixes that after the fact. The mitigation is structural: pick vendors on different providers. Practices evaluating video vendors should look for ones that describe multi-region routing and peer-to-peer failback explicitly, since the structural answer is distributing vendor infrastructure across different providers and regions. The output of all this work is a one-page document: each service, its owner, its likely failure mode, and the cause that produces that failure mode. Everything after this step references that page.

Building the video and connectivity fallback layer, the piece standard protocols omit entirely

Monitoring comes first, and it has to be independent of the platform being monitored. Synthetic checks (short-cycle WebRTC test calls) with alerts going out over more than one channel give a practice its own signal, rather than waiting to hear about an outage from the vendor's own status page. Subscribing to status pages for the video vendor and for the major CDN or cloud providers underneath it adds a second, earlier warning layer.

A secondary video platform needs to exist before it's needed, not get improvised during a crisis. A lightweight, HIPAA-ready WebRTC backup, pre-configured with accounts for every clinician and patient, running on a different CDN than the primary platform, turns an outage into a manageable disruption instead of a canceled afternoon. One practice with a secondary WebRTC vendor already set up on a separate CDN managed to move a quarter of its scheduled visits over within 20 minutes of a CDN disruption. That kind of speed doesn't happen without the accounts already existing.

The fallback sequence itself should be written down as an ordered list, not left to whatever a clinician decides to try in the moment. If the video feed drops but the session connection holds, step one is switching to audio-only on the same platform and documenting the downgrade in the chart. If the primary platform is unreachable entirely, step two is the secondary WebRTC platform. If both video options are gone, step three is HIPAA-compliant telephony over the standard phone network, under a signed BAA, made possible without delay because the intake form already carries pre-authorized audio-only consent. And if none of that gets the visit to a clinically adequate place, step four is rescheduling or referring out, with a defined clinical threshold for when phone-only care simply isn't enough.

A clinician's work mobile, registered for secure access, can host a session independent of the office network entirely, relying on cellular data that's often still up when broadband isn't. At least one encrypted, locally configured workstation per practice should be able to handle intake and charting on its own if the networked systems go down. And the audio-fallback consent line clinicians use in the moment shouldn't be improvised either: something close to "We lost video but can continue by phone. Do I have your permission to proceed with an audio consultation and to document this change in your medical record?" works, and it should exist as a named, versioned script every clinician has seen before they ever need it. All of this belongs on a single-page checklist, distributed to every clinician, specifying who initiates the fallback, who calls the patient, and how the session gets documented. Not something buried three folders deep on an IT drive.

Patient communication channels during an outage, including SMS limits and reaching patients when the portal is down

The patient portal is often the same channel a practice relies on to explain that the portal is down, which is a problem with no good workaround once the outage has already started. If appointment links and outage notices both route through the one system that just failed, patients are left with no idea what's happening or what they're supposed to do next.

Fixing this requires consent gathered in advance, not during the outage. Intake forms need explicit authorization for the practice to reach a patient by phone or SMS specifically during platform outages, because without it, switching to an alternate channel mid-crisis creates a compliance problem on top of an operational one.

Standard SMS can carry an appointment link, assuming consent is on file and the message body contains no PHI, and it can carry a plain outage notice: something like "We're switching to phone visits today because of a platform issue. We'll call you at your scheduled time," with no clinical content attached. What it cannot carry is anything that qualifies as PHI: results, medication changes, clinical updates of any kind. Those need a secure channel. A workable middle ground some vendors now offer is an SMS that contains no PHI itself but carries a one-time authenticated link into a secure portal session, which gets the patient to protected information without exposing any of it in the text message itself. Whatever secure SMS gateway a practice uses for this needs its own signed BAA, negotiated as infrastructure ahead of time, not scrambled for after the first outage exposes the gap.

Speed depends on roles being assigned before anything goes wrong. That division of labor only works when it is decided in advance, not invented under pressure. Building a communication path that does not depend on the same infrastructure that just failed should also be done ahead of time: a staff phone tree, a personal mobile contact list clinicians can reach for directly, or a status page hosted on a completely separate cloud provider from the EHR itself.

Offline documentation and the uptime reconciliation problem

There's no paper chart sitting in a drawer to fall back on. If the EHR is unreachable, a clinician in a telehealth-only practice has nowhere to write anything down unless an offline workflow was built in advance and everyone already knows how to use it.

Encrypted local chart templates fill that gap: a clinician records the visit locally, then syncs the record back into the EHR once the system comes back up. Some EHR and practice management platforms offer locally stored documentation modes for exactly this purpose, which suggests the industry recognizes the problem even where regulation hasn't caught up to it yet. A 2019 study in Applied Clinical Informatics found that lab testing results were delayed by 62% on average during EHR downtime, and that the paper records generated during those outages were frequently inconsistent or incomplete. The study's authors called for better, more detailed downtime contingency plans focused specifically on communication, resource allocation, and training. A telehealth practice's offline templates are the direct equivalent of those paper records, and they carry the same risk of drifting into inconsistency if they aren't standardized ahead of time.

Every offline record needs a fixed set of minimum elements, regardless of who's filling it out or under what pressure: patient identity and date of birth, pulled from something other than the EHR lookup that just failed; a pre-exported list of active medications and allergies for anyone with a scheduled visit; the actual clinical findings from the encounter; which channel was used to conduct the visit, video, audio-only, or phone, and why; how consent was obtained and in what form; any orders, referrals, or prescriptions issued; and timestamps marking when the downtime started and when service came back. Verbal orders taken during a manual workflow need read-back documentation, a step that's easy to skip when someone is holding a phone in one hand and typing notes with the other, but it's a specific requirement in patient-safety guidance for exactly that reason.

None of this closes the loop by itself. Restoration needs its own defined workflow: who re-enters the offline records into the live EHR, in what order, and who reviews each one for completeness before the chart gets closed out. Skip that step, and the offline record and the official EHR record can drift apart permanently, which turns a temporary outage into a permanent documentation gap. Building in one more layer of preparation, a limited, secure export of allergy, medication, and diagnosis data for high-risk patients with visits scheduled in the next day or two, held locally, means the offline workflow has something to work from even before the outage begins.