When an EHR goes down, the next 15 minutes are decided long before the outage: by how the incident is classified, how fast a human starts working on it, and whether the practice has downtime procedures ready. A disciplined provider treats EHR inaccessibility as a critical incident, gets an engineer actively working within minutes, and tells the practice what is happening. What usually happens instead is a ticket in a queue, silence, and paper chaos at the front desk.
What should happen in the first 15 minutes?
Minute zero to two: classification. The call or alert comes in and is immediately triaged as critical, because a practice that cannot reach its charts cannot safely see patients. This is not a judgment call made under pressure; it is a rule written into the service agreement in advance. At Evolv IT, EHR inaccessibility carries a 15-minute critical response commitment, which means a person, not an autoresponder, is engaged inside that window.
Minute two to ten: active work, not acknowledgment. Acknowledgment is an email that says your ticket has been received. Active work is an engineer determining whether the failure is local (a server, a switch, a workstation image), the connection (circuit down, DNS, VPN tunnel), or the vendor's cloud. Those three paths have completely different fixes, and the fastest recoveries come from ruling out two of them quickly.
Minute ten to fifteen: communication and downtime mode. Someone tells the practice manager, in plain language, what is known, what is being done, and when the next update will come. At the same time, the practice switches to its downtime procedures so patient flow continues on paper while the fix happens in parallel.
What usually happens instead?
The common sequence looks like this: the front desk calls the IT company and reaches a dispatcher or a voicemail. A ticket is created and lands in a queue behind password resets, because the provider's system has no concept of clinical urgency. Twenty or thirty minutes pass with no word. The practice manager calls again. Meanwhile providers improvise on paper without agreed forms, medication lists get scribbled on notepads, and nobody is sure what will need to be re-entered later or how.
The technical outage might last the same hour in both stories. The operational damage does not. The difference is not talent, it is discipline: classification rules, a real response commitment, and rehearsed downtime procedures. That discipline is exactly what to probe for when evaluating IT support for a medical practice.
Why do downtime procedures matter as much as the fix?
Because the practice does not experience the outage in the server room, it experiences it at the front desk and in the exam room. Downtime procedures answer the questions that otherwise get invented on the spot: how do we see today's schedule, what do we chart on, how do we record medications and orders, and how does all of it get back into the EHR afterward. HIPAA's Security Rule expects covered entities to have contingency plans for exactly this situation, so this is a compliance obligation as well as an operational one.
Good procedures are boring: a printed schedule pulled each morning or accessible offline, paper forms that mirror the EHR's fields, and a named person who owns re-entry when systems return. Boring is what you want at minute ten of an outage.
How do you know your provider is ready before the outage happens?
You cannot test readiness during the emergency, so test it with questions now. Is EHR downtime classified as critical in writing? What is the contractual response time, and is it measured in minutes? Who calls the practice manager, and how often are updates promised? When were our downtime procedures last reviewed with our staff? A provider with real answers will produce documents, not reassurances. Our managed IT and help desk service is built around a 15-minute critical response and 24/7/365 coverage for exactly this reason.
If backups are part of the failure, the questions get sharper still. An EHR restore that has never been tested is a hope, not a plan, which is why tested backup and disaster recovery belongs in the same conversation.