An uptime percentage is the least useful number in an EMR contract. What you actually need in writing is: how downtime is defined, what is excluded from that definition, how fast the vendor must restore service (RTO), how much data you can lose (RPO), whether you get read-only access to charts while the system is down, how and how quickly you are notified, and what happens if the vendor misses those targets repeatedly. A vendor who will promise you 99.9% but will not define "available" has promised you nothing.
The short answer
Negotiate the downtime section like an insurance policy, because that is what it is. The failure mode is not a vendor going bankrupt; it is a Tuesday morning when nobody can open a chart and your contract turns out to say that scheduled maintenance, third-party network issues, and "degraded performance" do not count as downtime. Those carve-outs are standard in vendor paper, and all of them are negotiable.
An uptime percentage is not an SLA
Two vendors can both advertise 99.9% and mean entirely different things, because the percentage is a fraction and vendors control the denominator. Make them define the terms first:
- What counts as "down"? Total unavailability only, or also severe degradation? A system taking forty seconds to load a chart is functionally down in a busy clinic, but most contracts will not call it an outage.
- Down for whom? Some agreements only count an outage affecting all or most customers. Your practice being unable to log in while everyone else is fine may trigger nothing.
- What is excluded? Scheduled maintenance, emergency maintenance, force majeure, your internet connection, and third-party integrations are all common exclusions. Stack enough and the guarantee is decorative.
- Over what period? 99.9% measured annually permits nearly nine hours of downtime; the same figure measured monthly is a much tighter commitment.
- Who measures it? If the vendor is the sole source of truth on its own performance, the metric is self-graded.
What the contract must actually define
| Clause | What to insist on |
|---|---|
| Definition of downtime | Includes material degradation of performance, not just total unavailability. Includes partial outages that affect your site. |
| Maintenance windows | Capped hours per month, outside your clinical hours, with advance notice. Emergency maintenance defined narrowly and reported after the fact. |
| Notification | A committed time to first notice and a named channel. A status page nobody watches is not notice. |
| Recovery time objective (RTO) | A stated maximum, in hours, to restore service after an incident. |
| Recovery point objective (RPO) | A stated maximum data loss, in minutes or hours. This is the one people forget. |
| Read-only / downtime access | A described mechanism for viewing recent charts, meds, allergies, and the schedule while the system is unavailable. |
| Incident reporting | A written root-cause analysis after any significant outage. |
| Chronic failure | Repeated misses constitute material breach, with a right to terminate without penalty. |
| Backups and restore testing | Backup frequency, retention, and evidence restores are tested, not merely scheduled. |
RTO and RPO: the two numbers that matter
Recovery time objective is how long you will be down. Recovery point objective is how much data will be gone when you come back. Practices fixate on the first and ignore the second, which is backwards: you can work around an outage with paper, but not around losing this morning's documentation.
Ask for both in writing, as commitments rather than aspirations. Then ask the question that separates a real answer from a marketing one: when did you last restore a customer's data from backup, and how long did it take? A vendor with mature operations has an answer. A vendor whose backups have never been exercised changes the subject.
Read-only access during an outage
The most valuable downtime provision, and the one most often missing, is a mechanism that lets clinicians see the chart when the EMR is unavailable — a cached read-only copy, a downtime viewer, or an auto-generated daily report of scheduled patients with medications, allergies, and problem lists.
Three things must be true of it: it updates often enough to be clinically useful, it is available when the primary system is not (so it cannot share the same infrastructure), and your staff has practiced using it. A downtime viewer nobody has opened in two years is a line item, not a control.
Service credits are not a remedy
Most EMR contracts remedy downtime with a service credit — a small percentage of one month's fee, usually capped, usually requiring you to claim it within a short window. It refunds a rounding error on your subscription while you absorb the cost of a cancelled clinic day, and it is designed to be the exclusive remedy, which is the part to watch.
So do not spend negotiating capital raising the credit from 5% to 10%. Spend it on what reduces your exposure: a real RTO, a real RPO, a working read-only path, and a termination right if the vendor misses chronically.
What HIPAA already requires of you
Downtime is a compliance issue as well as a commercial one, and the obligation sits with you, not only the vendor. The Security Rule's contingency plan standard at 45 CFR 164.308(a)(7) requires policies and procedures for responding to an emergency or other occurrence that damages systems containing electronic protected health information. Three of its implementation specifications are required: a data backup plan, a disaster recovery plan, and an emergency mode operation plan. Testing and revision procedures, and an applications and data criticality analysis, are addressable — which does not mean optional. It means you must assess whether the safeguard is reasonable and appropriate and, if you conclude it is not, document why and implement an equivalent alternative.
One clarification, because vendors get this wrong: HHS issued a Notice of Proposed Rulemaking in December 2024 that would substantially modify the Security Rule, including its contingency and testing requirements. That rule is proposed, not final. As HHS states plainly, while the Department is undertaking the rulemaking, the current Security Rule remains in effect. Anyone selling you something on the basis that new requirements already bind you is either mistaken or counting on you not to check.
Use the SAFER Contingency Planning Guide
You do not have to invent your evaluation criteria. ONC publishes the SAFER Guides — eight self-assessment guides covering EHR safety, updated in 2025 — and one of them, Contingency Planning, is specifically about planned and unplanned EHR unavailability: the situations where clinicians cannot access all or part of the record.
Use it twice. Run it against your current state before you buy, so you know which gaps are yours. Then hand the relevant recommended practices to the vendor during the demo and ask them to show you how their product supports each one. It moves the conversation from adjectives to demonstrations.
Questions to ask before you sign
- How do you define downtime, and what is excluded from that definition?
- What is your committed RTO and RPO, and are they in the contract or only in the marketing?
- What can our clinicians see while the system is down, and how current is it?
- When did you last perform an actual restore from backup?
- What happens if you miss the SLA three months running? Can we leave?
The takeaway
The downtime section is where a hosted EMR contract quietly transfers risk to you. Vendors will negotiate it, but only if you ask — and most buyers never do, because the section looks like boilerplate and the percentage looks reassuring. Define downtime broadly, get RTO and RPO in writing, insist on a read-only path your staff has actually practiced, and secure a way out if the vendor cannot hold to what it promised.
Common questions
Is 99.9% uptime good for an EMR?
It is meaningless on its own. The figure depends entirely on how the contract defines downtime, what it excludes, and over what measurement period. Compare definitions before you compare percentages.
What is the difference between RTO and RPO?
RTO (recovery time objective) is how long it takes to restore service after an incident. RPO (recovery point objective) is how much data you may lose, measured as a time window. RTO is about the outage; RPO is about the loss.
Does HIPAA require a downtime plan?
Yes. The Security Rule's contingency plan standard at 45 CFR 164.308(a)(7) requires a data backup plan, a disaster recovery plan, and an emergency mode operation plan as required implementation specifications, with testing and criticality analysis as addressable ones.
Do the 2026 HIPAA Security Rule changes apply to my downtime plan?
Not yet. The HHS Office for Civil Rights proposed those updates in a Notice of Proposed Rulemaking issued in December 2024. The proposal is not final, and HHS states that the current Security Rule remains in effect while the rulemaking proceeds.
Common questions
Is 99.9% uptime good for an EMR?
It is meaningless on its own. The figure depends entirely on how the contract defines downtime, what it excludes, and over what measurement period. Compare definitions before you compare percentages.
What is the difference between RTO and RPO?
RTO (recovery time objective) is how long it takes to restore service after an incident. RPO (recovery point objective) is how much data you may lose, measured as a time window. RTO is about the outage; RPO is about the loss.
Does HIPAA require a downtime plan?
Yes. The Security Rule's contingency plan standard at 45 CFR 164.308(a)(7) requires a data backup plan, a disaster recovery plan, and an emergency mode operation plan as required implementation specifications, with testing and criticality analysis as addressable ones.
Do the 2026 HIPAA Security Rule changes apply to my downtime plan?
Not yet. The HHS Office for Civil Rights proposed those updates in a Notice of Proposed Rulemaking issued in December 2024. The proposal is not final, and HHS states that the current Security Rule remains in effect while the rulemaking proceeds.