Who Owns the Alert? Building AI Escalation Pathways in the ED

Who Owns the Alert? Building AI Escalation Pathways in the ED

At 2:17 a.m., an alert fires on a patient in hallway bed 6. It says the patient is at elevated risk of deterioration. The nurse sees it. The resident sees it. The attending sees it ten minutes later between procedures. Everyone assumes someone else is acting.

That is not a technology problem. It is an ownership problem.

Emergency departments are adding predictive models, triage scores, deterioration flags, imaging prioritization tools, and documentation assistants faster than they are writing safe operating rules. An alert is a request for a human decision, and it is unsafe when nobody can answer: Who receives it? What must they do? When does it escalate?

After 25 years in emergency medicine, I have learned that the difference between a useful signal and noise is workflow around the algorithm. Here is the framework I would use before allowing an AI alert into a busy ED.

An alert is a clinical handoff, not a pop-up

An ED alert is closer to a handoff than a software notification: it transfers information, attention, and responsibility from a system to a person or team.

That handoff needs the discipline we expect from a verbal sign-out. The receiving clinician needs the patient, concern, evidence, timeframe, and expected next action. If the screen only says “high risk,” it has exported uncertainty to a tired clinician.

The FDA’s 2026 Clinical Decision Support guidance emphasizes the importance of enabling a health professional to independently review the basis for a recommendation. Operationally, that means an alert should expose more than a score. It should show the intended use, the relevant inputs, the known limitations, and patient-specific context in language a clinician can actually use.

Alert design cannot be separated from staffing. A model that expects an attending to review every alert is not a nurse workflow; one that expects a nurse to initiate treatment is not merely informational. Write the action before debating sensitivity.

Start with the decision, then assign the first receiver

Before go-live, write one sentence in this format: “When this alert fires, the first receiver will do ___ within ___ minutes.”

For example: “When the deterioration alert fires, the primary nurse will reassess vital signs and appearance within 10 minutes, then notify the covering physician if concern persists.” Or: “When the imaging prioritization flag fires, the radiology worklist will move the study into a defined review queue; it will not change the ED disposition decision by itself.”

The sentence distinguishes an alert that prompts a check from one that authorizes an action. Most ED tools should make patients easier to notice, not decide for the team.

Then assign the role, not just the individual. The “provider who ordered the test” may be in a resuscitation or no longer responsible for the patient. A robust pathway names the first-response role: primary nurse, triage nurse, charge nurse, treating physician, or surveillance team. The AHRQ primer on alert fatigue makes the safety point plainly: too many low-value alerts make clinicians less responsive to the ones that matter.

The first receiver needs a backup. If that person cannot act, the alert must move through a visible escalation rule. “Someone should notice” is not a policy.

Build a three-level escalation ladder

I use three levels because departments either over-escalate everything or leave escalation undefined. The ladder should be short enough to remember at 3 a.m.

Level 1: acknowledge and assess. The assigned role confirms the alert, checks the patient, and verifies the input data. This catches a cuff error, copied-forward history, old vital sign, discharged patient, or model-population mismatch.

Level 2: act and communicate. If concern survives the check, the receiver performs the predefined action and notifies the next role. It might be a bedside reassessment, repeat vital signs, attending review, sepsis workup, or higher monitoring. It should never be “click acknowledge” and move on.

Level 3: escalate, pause, or override. If the patient worsens, the alert conflicts with bedside findings, false signals repeat, or the system behaves outside intended use, the team needs permission to escalate and pause that workflow. A safe system includes an off-ramp.

NIST’s AI Risk Management Framework calls for human oversight, production monitoring, user feedback, incident response, and mechanisms to supersede or deactivate systems that perform inconsistently with intended use. In the ED, that becomes a charge-nurse escalation number, physician owner, documented override reason, and authority to stop alerts.

Measure response quality, not alert volume

The easiest dashboard metric is the number of alerts. It is also one of the least useful. A busy ED can produce an impressive alert count while failing to improve a single patient outcome.

Track the whole chain:

• How many alerts fired per 100 visits or per 100 monitored patients?
• What percentage reached the intended receiver?
• What was the median time to acknowledgment and bedside assessment?
• How often did the alert lead to a meaningful change in care?
• How often was the input wrong, incomplete, or outside the model’s intended population?
• How often did staff override, dismiss, or report the alert?
• How many near misses or safety events involved a missed, delayed, or misleading alert?

The important metric is not “did the clinician click?” It is “did the pathway produce the right next action?” A high acknowledgment rate can hide a low assessment rate. A low override rate can mean trust or automation bias. Case review tells you the difference.

Review data by role and shift. An alert that works during weekday rounds may fail at night when the covering physician is managing multiple high-acuity patients. A pathway that works in a 20-bed ED may collapse in a 70-bed department with hallway care and boarding. Local performance is the product you are deploying, not the vendor’s validation slide.

This is the same reason I argue that emergency physicians should lead AI governance, a point I make in my Medium essay on why emergency physicians make the best AI governance leaders. The person who understands the clinical decision and the operational bottleneck has to be in the room when thresholds and escalation rules are set.

Make the pathway resilient to bad nights

Every AI alert policy should answer what happens during EHR downtime, network failure, staffing shortages, boarding, a surge, a model update, or a sudden rise in false positives.

Write a paper fallback. If the alert disappears, what observation triggers reassessment? If the system floods the department, who can downgrade or pause it? If the model changes, what validation is required before the new version interrupts care? If a patient is transferred, does the alert follow the patient or stop at the ED boundary?

Do not make the fallback “use clinical judgment.” Name the observable trigger, responsible role, and backup channel. “If the deterioration tool is unavailable, the charge nurse runs the high-risk list every two hours and escalates any change in vitals or appearance to the treating physician” is a workflow. “Be vigilant” is a poster.

Build a feedback loop that does not punish people for reporting bad alerts. The model needs reports on false positives, false negatives, confusing displays, duplicate notifications, and alerts that arrive too late. NIST recommends post-deployment monitoring and processes for users to report problems and appeal outcomes. If reports disappear into an inbox, clinicians will stop sending them and leaders will mistake silence for safety.

Dr. Chet’s Take

The alert is not the product. The response pathway is the product.

If your vendor demo focuses on the model’s AUC but cannot show who receives an alert on nights, how the alert escalates when that person is busy, what data the clinician can inspect, and who can shut the system off, you are not ready for clinical deployment.

Start with one high-value use case. Define the decision. Assign the first receiver and backup. Set a response clock. Audit the real cases. Then earn the right to scale.

AI can help an ED notice risk earlier. It cannot make an undefined responsibility safe. The physician remains accountable for the clinical decision, but the organization is accountable for designing a system in which that decision can actually be made.

Key Takeaways

• Treat an AI alert as a clinical handoff with a receiver, timeframe, evidence, and expected next action.
• Assign ownership by role and shift, with a visible backup when the first receiver is unavailable.
• Use a three-level ladder: acknowledge and assess, act and communicate, then escalate, pause, or override.
• Measure bedside response and patient impact, not just alert counts or click-through rates.
• Build downtime, model-change, false-positive, and pause procedures before go-live.

FAQ

1) Who should own an AI alert in the ED? The role closest to the decision should own the first response, and the policy must name it explicitly. That may be the primary nurse, triage nurse, charge nurse, treating physician, or surveillance team. The ordering clinician is not always the right owner.

2) How quickly should clinicians respond? There is no universal clock. Set one based on predicted harm and intended action. A deterioration signal may require reassessment within minutes; a lower-risk flag may wait for the next workflow. If the team cannot explain the timeframe, the alert is not ready.

3) Does acknowledging an alert satisfy the requirement? No. Acknowledgment only proves that the message was seen. The pathway should require assessment, action, or escalation, and make that response auditable without defensive paperwork.

4) When should an ED pause an AI alerting tool? Pause it when output is inconsistent with intended use, a model or data-feed change is unvalidated, false positives create unsafe overload, or the team cannot complete the response pathway. A pause is a safety control, not leadership failure.

5) What should we ask a vendor before deployment? Ask what data drives the alert, which populations were validated, known failure modes, who receives and escalates the output, how local performance is monitored, and how the system is disabled. If the vendor cannot answer ownership and off-ramp questions, keep the tool in evaluation.

If you're an emergency physician (or any clinician treating patients daily) trying to understand how AI will actually impact your clinical practice -- not just the hype -- I put together a free practical guide. You can download it here: AI in EM Survival Guide

Read more from Dr. Shermer on Medium: Read more from Dr. Shermer on Medium

Sources

1. U.S. Food and Drug Administration. “Clinical Decision Support Software - Guidance.” https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software
2. Agency for Healthcare Research and Quality, Patient Safety Network. “Alert Fatigue.” https://psnet.ahrq.gov/primer/alert-fatigue
3. National Institute of Standards and Technology. “Artificial Intelligence Risk Management Framework (AI RMF 1.0).” https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
4. Shermer, Chester. “Why Emergency Physicians Make the Best AI Governance Leaders.” https://medium.com/@chet.shermer/why-emergency-physicians-make-the-best-ai-governance-leaders-a0d8b05ec7d7?source=rss-d12bed264b1f------2