Alert fatigue in healthcare is what happens when an EHR warns clinicians so often that they stop reading the warnings. The alert meant to catch a dangerous dose becomes one more box to close, and it is closed as quickly as the twenty harmless ones before it.
This guide is for CMIOs, clinical informatics teams and the engineers who build or configure decision support. It explains why interruptive alerts get overridden, which alerts deserve to interrupt, how a tuning program runs week to week, what to measure, what ONC's certification rules say about feedback, and where tuning efforts stall.
What is alert fatigue in healthcare?
Tuning decision support in your EHR?
Agnotic builds clinical decision support for health systems and vendors, including alert logic, tiering rules and the analytics to tune them.
Alert fatigue in healthcare is the desensitization clinicians develop when EHR and order-entry systems fire too many low-value alerts. Overwhelmed by warnings that rarely change care, clinicians override nearly all of them, including the few that warn of serious harm, so excess alerting makes patients less safe, not more.
AHRQ's Patient Safety Network describes the problem plainly: most alerts generated by computerized provider order entry are clinically inconsequential, so clinicians learn to ignore them, and then miss the critical ones. An AHRQ WebM&M commentary notes that physicians override computerized alerts up to 95 percent of the time in published studies.
This post deals with alerts inside the EHR: drug interaction, dose, allergy, duplicate order and best practice alerts. Alarms from bedside monitors and remote monitoring programs share the name but need different fixes.
Why do clinicians override EHR alerts?
Clinicians override EHR alerts because most of them are irrelevant to the patient in front of them, arrive at the wrong moment, or go to the wrong person. Overriding is often the correct decision, which is exactly why the habit spreads to alerts that matter.
- Low specificity: Drug interaction rules written at the class level fire for combinations that are routine and monitored.
- Missing context: The rule ignores data already in the chart, such as current kidney function, a documented tolerance or a recent lab.
- Wrong recipient: The alert reaches a resident entering orders on behalf of an attending who made the decision.
- Wrong moment: The warning appears at signing, after the clinical decision is made, instead of while the order is being chosen.
- Repetition: The same alert fires on every renewal of a long-standing medication the clinician has already reviewed.
- Fear of removal: Content owners keep alerts because removing one feels like accepting liability for a future miss.
Each cause has a different fix. Treating alert fatigue as one problem and cutting alerts across the board removes useful warnings along with noise.
Which alerts should interrupt, and which should not?
Only alerts that warn of serious, likely and avoidable harm should interrupt a clinician's workflow. Everything else belongs in a passive display, a worklist or nowhere at all.
AHRQ PSNet's alert fatigue primer lists strategies that informatics teams still use: increase specificity by removing inconsequential alerts, tailor alerts to patient characteristics such as renal function, tier them by severity, make only high-severity alerts interruptive, and apply human factors principles to their design.
- Hard stop: Reserve for contraindications where proceeding is almost never right, and give a documented override path for genuine exceptions.
- Interruptive with reason: Serious harm is likely but clinical judgment may justify proceeding; require a short coded override reason.
- Passive inline: Useful but not urgent information shown beside the order, such as a dose range or a formulary alternative.
- Worklist or inbox: Follow-up items such as an overdue screening, routed to the role that acts on them, not to whoever opened the chart.
- Retire: Alerts with near-total override rates and no evidence of preventing harm, after review by the content owner and pharmacy.
Routing matters as much as tier. A dose alert that a pharmacist resolves during verification does not also need to interrupt the prescriber, unless the two disagree.
How do you run an alert tuning program?
An alert tuning program runs as a regular governance cycle: measure alert volume and responses, pick the worst offenders, redesign or retire them, and measure again. It needs a named committee with clinical, pharmacy and informatics members and the authority to change content.
- 1. Inventory: List every active alert with its owner, trigger logic, display type, target roles and the evidence behind it.
- 2. Baseline: Pull firing counts, override counts and override reasons per alert, per role and per department for a recent period.
- 3. Rank: Sort alerts by volume times override rate, so high-noise alerts rise to the top of the list.
- 4. Diagnose: Read a sample of firings for each top alert to see why it fired and why it was overridden.
- 5. Redesign: Narrow the logic, add patient context, change the tier, retarget the role or retire the alert.
- 6. Test: Run the revised rule silently in production for a period and compare its firings with the original before switching it on.
- 7. Monitor: Track the changed alert for a few months and watch for any rise in the harm it was meant to prevent.
Silent mode is the step that makes clinicians trust the program. It shows, with real patients, how many fewer alerts the new logic would fire and which true positives it would still catch.
How should an interruptive alert be written?
An interruptive alert should state the specific risk for this patient, the evidence for it and the action to take, in a form a clinician can read in a few seconds. If the dialog needs scrolling to understand, it will be closed unread.
- Headline: One line naming the risk and the patient factor, such as a potassium level or a documented allergy, not a generic class warning.
- Data shown: The lab value, date or medication that triggered the rule, so the clinician can judge relevance without leaving the dialog.
- One-click actions: Buttons that cancel, change the dose or order the monitoring test directly from the alert.
- Coded override reasons: A short list that fits the alert, with free text only as a fallback.
- Consistent severity cues: The same colours and signal words for the same tier across every alert in the system.
Timing is part of the design. Showing a formulary or dose message while the clinician is choosing the order, rather than at signing, often removes the need for an interruptive alert altogether.
Test new alert designs with the clinicians who will see them. A short usability session with three or four prescribers, using realistic test patients, catches unclear wording and missing data faster than any review meeting.
What should an alert dashboard measure?
An alert dashboard should measure burden and usefulness for each alert, not just totals. The aim is to see which alerts change decisions and which only add clicks.
- Firings per encounter or per 100 orders: Normalizes alert burden across departments of different sizes.
- Override rate by alert and role: Shows where one role overrides almost everything, often a sign of wrong targeting.
- Action rate: The share of firings followed by the suggested action, such as cancelling or changing the order.
- Override reasons: Coded reasons reveal patterns, such as "patient already tolerating" on repeat medications.
- Time on alert: Seconds spent on the dialog, where very short times suggest the text is no longer read.
- Downstream signal: Related safety events or pharmacy interventions, so a retired alert can be reconsidered if harm appears.
Most of this data sits in EHR audit and decision support logs, which are hard to query in place. Teams usually extract it to an analytics store on a schedule and join it with order and encounter data there.
What does ONC require of certified EHR feedback tools?
ONC's decision support interventions criterion requires certified EHRs to let users give electronic feedback on evidence-based interventions and to export that feedback. The export must include, at a minimum, the intervention, the action taken, any feedback, the user, the date and the location, in a computable format.
That requirement sits in 45 CFR 170.315(b)(11). ONC's HTI-5 final rule, published in the Federal Register on 28 October 2026, removed the criterion's source attribute and predictive risk management requirements but kept the feedback requirement for evidence-based interventions. For tuning teams, this means a certified EHR should already capture structured feedback that can feed the dashboard above.
Certification sets a floor, not a workflow. Someone still has to turn the feedback export on, route it to the governance committee and close the loop by telling clinicians what changed because of their comments.
Where alert tuning efforts go wrong
- No owner: Alerts built years ago have no named clinical owner, so no one can approve changing them.
- Vendor content untouched: Teams tune local rules but leave the drug knowledge base's interaction severities at their defaults.
- Volume as the only goal: Firings drop, but the remaining alerts are still the wrong ones.
- No silent testing: A narrowed rule goes live directly and misses a case that the old rule caught.
- Free-text overrides: Reasons cannot be analyzed, so the committee learns nothing from them.
- One-time project: Alerts are cleaned once, then new ones accumulate without review until the problem returns.
A simple guard helps with the last point: require every new interruptive alert request to name its owner, its expected firing rate and the measure that will show it works, and review it against those numbers after go-live.
How Agnotic can help
Cutting alert noise safely takes data, testing and clear ownership. Agnotic Technologies builds the decision support layer for health systems and vendors: alert logic with patient context, tiering and role routing, CDS Hooks services, silent-mode test rigs, and the analytics store that turns EHR alert logs into a tuning dashboard.
Agnotic also works with informatics teams on the governance tooling, such as an alert inventory with owners and evidence links, and feedback exports wired into the committee's review queue.
Make every alert earn its place
Explore our clinical decision support work, or read more guides for healthcare software teams.
Related reading on Agnotic
Continue with decision support design, CDS Hooks services, remote monitoring alert load and choosing an AI decision support system.
