Alert fatigue: why most clinical alerts get ignored, and how to design ones that aren't

Every clinician knows the motion: the alert appears, the eyes register its shape, the hand clicks through. That reflex is usually described as a failure of attention. It is better described as a rational response to a signal that is mostly noise. Alert fatigue is a design problem, and it has design answers.

How often alerts are overridden

The numbers have been consistent for two decades. A review of 17 studies found that drug safety alerts were overridden in 49% to 96% of cases, and noted that overriding may often be justified.^[1] In outpatient practice, a study of medication-related alerts found that 52.6% were overridden, and that on average 53% of the overrides were appropriate, ranging from 12% for renal alerts to 92% for allergy alerts.^[2]

Read that second figure carefully. About half the time the clinician who clicked past the alert was correct to do so. An alert that is wrong half the time when it is ignored is training its users to ignore it.

Why it happens

The most useful evidence is not about clinicians being tired. It is about the alerts themselves.

• Repetition. In one primary care system, a quarter of drug alerts and a third of clinical reminders were repeats for the same patient within the same year. Acceptance of reminders dropped by 30% for each additional reminder per encounter, and by 10% for each five-point increase in the proportion of repeated reminders. Workload itself had no effect.^[3]
• Low specificity. One review notes that up to 95% of CDS alerts are inconsequential.^[4]
• Wrong moment. An alert that fires after the decision has been made, or in a part of the record the clinician is not looking at, asks for a change of direction instead of informing the choice.

The pattern is clear: the dose of alerts and their precision matter more than the clinician's stamina.

What works: the design evidence

A systematic review of randomized trials looked for features that predicted whether decision support improved practice. Four stood out: automatic provision as part of the clinician's workflow, recommendations rather than just assessments, delivery at the time and location of decision making, and computer-based delivery. Of 32 systems with all four, 30 (94%) significantly improved clinical practice.^[5]

The older "ten commandments" paper from Brigham and Women's reads like a field manual for the same idea. Among them: speed is everything; anticipate needs and deliver in real time; fit into the user's workflow; physicians will strongly resist stopping, and changing direction is easier than stopping; ask for additional information only when you really need it; monitor impact, get feedback, and respond.^[6]

What works: taking alerts away

Two programs show that the burden can be cut deliberately.

• At one children's hospital, 25 unique alerts accounted for 90% of interruptive alert volume. A quality-improvement effort reduced interruptive alerts from 7,250 to 4,400 per week.^[7]
• The Clickbusters program, in which clinicians reviewed and revised alerts, reduced weekly alert firings by more than 70,000 (15.43%) from a baseline of 488,425.^[8]

Neither paper reported patient-safety outcomes, so "removing alerts is safe" is not something these studies establish. They establish that a small number of alerts drive most of the noise, and that review programs can find them.

Design rules I would hold any system to

These follow from the evidence above. They are the standard I hold our own product to.

1. Specificity before sensitivity for interruptive alerts. If an alert interrupts, it should be right most of the time it fires. Reserve interruption for findings that are both dangerous and well supported by what is in the chart.
2. Recommend, do not just warn. "Potassium is 6.1" is an assessment. "Repeat potassium, ECG now, hold the ACE inhibitor" is a recommendation the clinician can accept in one step.
3. Arrive where the decision is made. Inside the note or the order, not in a separate inbox.
4. Do not repeat what was already addressed. If the chart shows the test was done or the risk was acknowledged, say nothing.
5. Offer, do not impose. Optional tools such as risk calculators should be offered when relevant and run only when the clinician chooses.
6. Measure overrides and act on them. An alert with a high appropriate-override rate is a bug report.

How Pogosh applies this

Pogosh returns a structured set of next steps from the note itself, rather than firing alerts against individual orders. It is built to stay quiet when it has nothing specific to add.

• The emergency check is specificity-first. A separate, strict check looks for time-critical presentations and is designed not to fire on weak or indirect evidence. A false alarm on every chest pain note would teach users to ignore the one that matters.
• It accounts for what has already been done. If the note shows a study was performed, Pogosh does not recommend ordering it again.
• Calculators are offered, never auto-run. When a score is relevant, Pogosh offers it with its inputs and references; the clinician decides whether to use it.
• Everything is a recommendation the clinician can override. Nothing is ordered automatically.

None of this makes Pogosh immune to the problem. Any system that speaks often enough will be tuned out, which is why we treat a recommendation that clinicians routinely override as a defect to fix. Whether we meet that standard is something you can test yourself on your own notes. Alert fatigue is earned one irrelevant alert at a time, and trust is earned the same way.