Alert Fatigue in Healthcare: Why CDS Alerts Get Ignored
Clinical Decision Support Systems

Alert Fatigue in Healthcare: Why CDS Alerts Get Ignored

Sandeep Natoo
VP of Data & AI, Mindbowser
TL;DR
  • A 2024 systematic review found physicians override 90% of CDS alerts. For high-severity drug-drug interactions, only 0.5% of those overrides are clinically appropriate.
  • Alert fatigue is not a content problem. It is an architecture problem. Clinicians are not ignoring alerts because they are careless. They are ignoring them because alert systems were designed for liability coverage, not clinical usability.
  • The fix requires four things in sequence: override tracking before any tuning, tiered alert design, sensitivity tuning against real data, and workflow-aware delivery.
  • A perioperative CDS deployment we shipped in Epic reached 87% provider engagement by getting all four right, not by adding smarter alerts, but by reducing the wrong ones.

Watch: Alert Fatigue in Healthcare: Why 90% of CDS Alerts Get Ignored

The Scale of the Problem

In a typical hospital EHR, a clinician sees between 100 and 200 alerts per day. Drug-drug interaction warnings. Lab value flags. Best-practice advisories. Duplicate order checks. Allergy alerts. Preventive care reminders. Each one demands a response: act or click past.

Most get clicked past.

A 2024 systematic review and meta-analysis by Felisberto and colleagues found physician alert override rates average 90% (95% CI, 85-95%), with drug-drug interaction overrides ranging from 55% to 98% across studies. A 2019 JAMIA study by Cho and colleagues examined 10 clinical sites and 16,011 alerts: 95.7% were overridden.

For the highest-severity drug-drug interactions specifically, only 0.5% of overrides were judged clinically appropriate. In the same study, clinicians cited 177 distinct override reasons. Most had nothing to do with the drug interaction itself.

Physicians override about 90% of CDS alerts.
Fig 1: Physicians override about 90% of CDS alerts.

This is the alert fatigue paradox. Systems designed to catch dangerous errors are so noisy that dangerous errors get ignored along with everything else.

The problem compounds. Wong and colleagues studied Brigham and Women’s Hospital in the Journal of General Internal Medicine (2018) after their conversion to a commercial EHR. Drug-drug interaction alerts went from roughly 2 to 11 per 100 orders. Total medication alert burden jumped from 9 to 36 per 100 orders. Same clinicians, same patients, four times the alert volume. Override rates stayed flat at 90% or higher.

Alert volume rises 4×; overrides stay high.
Fig 2: Alert volume rises 4×; overrides stay high.

The math is simple and brutal. Add alerts without removing any, and override rates do not drop. They drift upward. Clinicians learn the noise floor and calibrate their attention to match it. The rare high-stakes alert disappears into the background.

Why Alerts Fail Clinicians

The root causes are structural.

Sensitivity calibrated for liability, not usability: EHR alert defaults are configured to fire for anything that could theoretically cause harm, regardless of clinical probability. The vendor’s liability exposure is limited by firing. The clinician’s efficiency is destroyed by the same logic. Neither outcome was designed to serve the patient.

No feedback loop: Most CDS systems cannot distinguish between “this alert was clinically wrong” and “this alert was right, but the clinician chose to proceed anyway.” Override clicks capture a decision event, not a clinical reason. Without that distinction, there is no data to tune against, and the system cannot learn.

Alerts fire at the wrong moment: An alert that interrupts a physician three steps into an order set requires them to abandon context, process a recommendation, and return. The same information presented before the order began, or surfaced non-interruptively after it completes, carries a fraction of the cognitive cost. Timing is not a UX nicety. It is a determinant of whether the alert gets read at all.

No tiering: In many EHRs, a drug interaction severity-1 warning and a severity-3 advisory look identical. A hard stop blocking a contraindicated medication and a soft reminder suggesting a formulary alternative appear as the same type of interruption. Clinicians respond predictably: they treat all of them the same way, by clicking past.

Hard stops misapplied: Hard stops are appropriate for genuinely non-negotiable thresholds: a documented allergy to the prescribed medication, a dose order-of-magnitude above the ceiling for the patient’s weight, a critical lab value requiring immediate action. They are not appropriate for a moderate DDI in a 62-year-old on 11 chronic medications. When every alert is a hard stop, no alert is.

Reasons clinical alerts get ignored.
Fig 3: Reasons clinical alerts get ignored.

The Fix: Building Alerts Clinicians Actually Use

Four components, in order.

Four-step framework for better alerts.
Fig 4: Four-step framework for better alerts.

1. Override Tracking Before Any Tuning

You cannot tune what you cannot measure. Before modifying a single alert, the first requirement is a baseline: which alerts are overridden most, which overrides correlate with adverse outcomes, and what the current alert appropriateness rate looks like across departments and alert types.

That baseline requires structured override reasons, not free text. A fixed list of 6-10 override codes generates tunable signal. “Clinically appropriate,” “patient already on combination,” “monitoring planned,” “alternative not available,” “low risk for this patient,” and “deferred to pharmacist” are the types of categories that distinguish signal from noise. Free-text override boxes generate text strings that cannot be analyzed at scale and do not accumulate into usable data.

One perioperative CDS deployment we shipped started with 12 override codes and reduced to 7 after pilot data showed which codes were never selected. Override-rate trend improved over the following two quarters. The gains came from knowing what to retire, not from guessing.

2. Tiered Alert Design

Every alert should be classified before it fires:

Hard stop: Requires an explicit override action. Genuinely non-negotiable threshold. Used sparingly. Clinicians must be able to trust that every hard stop is real, or the trust breaks, and hard stops get clicked past like everything else.

Soft warning: Interruptive but dismissable. Requires a structured override reason before proceeding. Appropriate for significant DDIs, out-of-range lab values with relevant clinical context, and best-practice advisories where non-compliance is sometimes clinically justified.

Passive info: Non-interruptive. Appears in a sidebar or secondary panel. For moderate risk flags, care gap reminders, and preventive care nudges where the clinician may want the context but does not need their workflow interrupted to receive it.

Three-tier clinical alert design.
Fig 5: Three-tier clinical alert design.

Most clinical systems operate with one tier. The default EHR alert is modal and interruptive, regardless of clinical urgency. Moving to three tiers is the single biggest change in alert fatigue management. It does not require replacing an EHR. It requires re-classifying existing alerts against a defined severity framework and having a clinical informatics team with the authority to retire miscalibrated ones.

3. Sensitivity and Specificity Tuning

Alert rules written by committee get tuned for committee accountability, not for the clinician seeing the patient.

Tuning means taking the override data from step one, identifying the highest-override alerts, and asking whether each one should be retired, reclassified to a lower tier, or narrowed in scope. An alert firing for 2,000 patients per month with a 98% override rate is not catching errors. It is training clinicians to dismiss alerts reflexively. The threshold that triggers it is wrong.

Specificity increases when alerts fire only for patients where clinical action is genuinely warranted. A 60% trigger rate with 40% clinical engagement is more useful than a 100% trigger rate with 2% engagement. The goal is not maximum coverage. It is maximum signal-to-noise ratio.

For rules-based CDS, this is a quarterly process: pull override data, identify high-override alerts, review with clinical informatics and pharmacy, retire or reclassify. For ML-based CDS, the same discipline applies to model outputs. As one risk model practitioner put it: “Models are NOT static. False positives will be your model’s ultimate demise if not properly moderated. Continually update with clinician feedback, new data, new sources.”

4. Workflow-Aware Delivery

The CDS Hooks standard makes this distinction explicit at the technical layer. A hook bound to `order-sign` fires while a physician is completing an order, an interruptive context with high cognitive load and time pressure. A hook bound to `patient-view` fires when a chart opens, a lower-stakes moment where a sidebar card can surface relevant information without blocking workflow.

The same clinical recommendation, delivered at `order-sign` versus `patient-view`, produces a different acceptance rate. Alert design that ignores this is allocating clinical attention budget carelessly.

Non-interruptive CDS also reinforces a principle worth making explicit: most clinical recommendations are suggestions, not mandates. A CDS tool that shows its reasoning earns clinician attention. One that fires a verdict without explanation earns a dismissal.

As one healthcare technology regulatory advisor noted, what keeps CDS within the non-device classification and within the clinician trust boundary is the ability to “open it up and view what’s the basis for this recommendation.” Explainability is not only a regulatory consideration. It is a usability requirement.

Reduce Alert Fatigue With Guidance From Our Clinical Technology Experts

What 87% Engagement Actually Looks Like

A perioperative CDS deployment we built for a healthcare client integrated decision support into Epic’s ordering workflow using the `sign_order` CDS Hook. When an ordering physician completes a preoperative order, the hook fires. The CDS engine receives the patient context, evaluates it against evidence-based preoperative lab and test requirements for the scheduled procedure, and returns any missing requirements as a CDS Card inside the Epic interface.

Three architectural decisions drove the outcome:

Tier discipline: Hard stops were reserved for genuine clinical risk only. Warnings required a structured override reason before proceeding. Low-severity guidance was non-interruptive and surfaced in a sidebar panel.

Structured override taxonomy: Seven codes, not a text box. The codes generated iterable data: which reasons appeared most often, which correlated with orders that were later flagged, and which alerts were being overridden with reasons that suggested the alert itself was miscalibrated.

Response time budget: CDS Cards had a 500-millisecond end-to-end window. Cards that load slowly get dismissed before they are read. Performance is not a nice-to-have in alert design. Slow delivery trains dismissal.

Results: 87% of providers engage with the recommendations. Missed preoperative labs dropped from 15% to 2%. Lab ordering time fell from 60 minutes per day to 10-15 minutes. Surgery delays caused by missing preoperative labs dropped from 10 per month to 3-5.

Better alert design drives 87% engagement.
Fig 6: Better alert design drives 87% engagement.

Same EHR. Same drug knowledge base. Same clinical staff. Different alert architecture.

Alert Governance: The Problem That Does Not End

Alert fatigue is not a configuration project with a completion date. It is an ongoing governance problem.

Clinical workflows change. New drugs enter formularies. New protocols replace old ones. An alert calibrated correctly in Q1 may be miscalibrated by Q3. Rules drift. Override rates drift with them.

A governance model that holds includes quarterly override reviews with clinical informatics, pharmacy, and department leads; clinician feedback panels that feed into alert reclassification; version control on alert rules that records what changed, when, and who approved; and adverse-event correlation tracking that surfaces overrides followed by adverse outcomes for case review.

Quarterly governance keeps alerts effective.
Fig 7: Quarterly governance keeps alerts effective.

None of this requires new technology. It requires consistent process ownership: a clinical informatics team with data access and decision authority, meeting on a defined cadence, with a documented audit trail. The alternative is watching override rates climb back toward 90% within 18 months, which is the normal trajectory for alert-tuning programmes that treat the tuning as the endpoint.

Conclusion

Alert fatigue is not a symptom of clinicians who are careless or overwhelmed. It is the predictable result of alert systems built to minimize liability exposure rather than to earn clinical attention. A 90% override rate is not a clinician problem to solve with more training. It is an architecture problem to solve with better data.

The fix does not require a new EHR or a new vendor. It requires, in order: override data captured through structured reasons instead of free text, a tiered alert model that reserves hard stops for genuine risk, sensitivity tuning driven by that override data rather than committee guesswork, and delivery timed to the clinical workflow instead of interrupting it by default.

The perioperative deployment covered above did not add intelligence to its alerts. It removed the noise around the alerts worth keeping, and engagement went from being ignored to 87%.

None of this closes out on a fixed date. Clinical workflows, formularies, and protocols keep moving, so the alerts calibrated against them have to keep moving too. Health systems and digital health teams that treat alert tuning as a one-time project should expect override rates to drift back toward 90% within a couple of years. The ones that build a governance cadence around it do not.

What is alert fatigue in healthcare?

Alert fatigue is what happens when clinicians receive so many clinical decision support alerts that they stop reading them and dismiss them reflexively. Published override rates run from 49% to 96%, and at Brigham and Women’s Hospital clinicians were overriding 98% of alerts. It is a design and governance problem, not a clinician-attention problem.

Why do doctors override 90% of CDS alerts?

Because most alert systems were built for liability coverage rather than clinical usability, and because almost none of them capture why an alert was dismissed. Without structured override reasons, a genuinely useless alert and a good alert firing on the wrong patients produce identical data, so nobody can tell them apart and nobody can tune.

Does reducing the number of alerts fix alert fatigue?

Not on its own. In one study, cutting alert volume by 10% left the override rate unchanged. An across-the-board trim removes good alerts and bad alerts in the same proportion, so precision does not improve. Selective tuning requires knowing which alerts are failing, which requires override data.

What is a tiered alert design?

Instead of making every alert modal and interruptive, alerts are classified by clinical severity and routed accordingly: hard stops for genuine safety risks, passive or deferred presentation for informational ones, and role-based routing so alerts a nurse cannot resolve go to whoever can. Moving from one tier to three is usually the single largest improvement available without replacing an EHR.

How do you measure whether CDS alert tuning is working?

Against an honest pre-tuning baseline, on override rate per rule rather than in aggregate. Aggregate override rate hides the fact that a handful of rules usually generate most of the noise. The target is not zero overrides; it is that the remaining overrides are clinically appropriate ones.

Can alert fatigue be fixed without replacing the EHR?

Yes, in most cases. It requires reclassifying existing alerts against a defined severity framework, capturing structured override reasons, and giving a clinical informatics team the authority to retire miscalibrated rules on a set cadence. The constraint is governance ownership, not technology.

Frequently Asked Questions

Alert fatigue is what happens when clinicians receive so many clinical decision support alerts that they stop reading them and dismiss them reflexively. Published override rates run from 49% to 96%, and at Brigham and Women’s Hospital clinicians were overriding 98% of alerts. It is a design and governance problem, not a clinician-attention problem.

Because most alert systems were built for liability coverage rather than clinical usability, and because almost none of them capture why an alert was dismissed. Without structured override reasons, a genuinely useless alert and a good alert firing on the wrong patients produce identical data, so nobody can tell them apart and nobody can tune.

Not on its own. In one study, cutting alert volume by 10% left the override rate unchanged. An across-the-board trim removes good alerts and bad alerts in the same proportion, so precision does not improve. Selective tuning requires knowing which alerts are failing, which requires override data.

Instead of making every alert modal and interruptive, alerts are classified by clinical severity and routed accordingly: hard stops for genuine safety risks, passive or deferred presentation for informational ones, and role-based routing so alerts a nurse cannot resolve go to whoever can. Moving from one tier to three is usually the single largest improvement available without replacing an EHR.

Against an honest pre-tuning baseline, on override rate per rule rather than in aggregate. Aggregate override rate hides the fact that a handful of rules usually generate most of the noise. The target is not zero overrides; it is that the remaining overrides are clinically appropriate ones.

Yes, in most cases. It requires reclassifying existing alerts against a defined severity framework, capturing structured override reasons, and giving a clinical informatics team the authority to retire miscalibrated rules on a set cadence. The constraint is governance ownership, not technology.

Sandeep Natoo

Sandeep Natoo

VP of Data & AI, Mindbowser

Connect Now

Sandeep Natoo is VP of Data & AI at Mindbowser. He has 12+ years of experience in software engineering and data science, with deep expertise in GenAI for healthcare, RAG architecture design, and predictive analytics.
He has built large-dataset forecasting models that inform clinical and operational decisions, led AI/ML initiatives across Mindbowser’s healthcare product portfolio, and serves as the company’s technical authority on emerging AI technologies for health systems.

Share This Blog

Read More Similar Blogs

Let’s #Transform Healthcare,# Together.

Partner with us to design, build, and scale digital solutions that drive better outcomes.

Location

Global Tech Teams LLC, 525 Washington Blvd, Industrious at Newport Tower, Jersey City, NJ 07310, United States.

Contact

+1 408 786 5974
contact@mindbowser.com
BOOK A QUICK CONSULTATION

Have a Healthcare Project in Mind?

Let’s discuss your goals, workflows, and next steps in a focused consultation call.

Calendar icon Schedule a Call

Contact form