Clinical alert and notification systems: how escalation works

Sending a clinical alert is the easy part. A critical potassium value hits the lab system, an integration fires, a phone buzzes. Done.

The hard part starts in the four minutes after that. The nurse is in an isolation room with gloves on. The phone is in a pocket under a gown. Nobody has acknowledged anything, and the alert is now sitting in a state your system has no opinion about.

That gap is what a clinical alert and notification system is for. A clinical alert and notification system is the layer that routes a clinical event to the responder who can act on it, tracks whether that person acknowledged it, and escalates to the next responder when acknowledgment doesn't arrive in time. Vendors also sell this as secondary alarm notification, alarm management, or clinical communication and collaboration, and hospitals often call it alerting middleware. The names differ. The job is the same, and the sending is the smallest part of it.

Key takeaways

• A clinical alert and notification system routes clinical events to the right responder, waits for acknowledgment, and escalates when acknowledgment doesn't come.
• The escalation timer is set by your organization, not by a regulator. The Joint Commission requires that you define an acceptable timeframe for critical results, not that you pick a specific number.
• Acknowledgment is the state that matters. Delivered is not the same as seen, and seen is not the same as someone taking the patient.
• Most physiologic monitor alarms are false, so any alert that reaches a human has to earn its place. Tiering and suppression are part of the alerting design, not a cleanup project.
• The audit trail is a deliverable, not a byproduct. You need to show who was notified, through what channel, when, and who took it.

Where clinical alerts come from

Every hospital runs several systems that produce alerts independently, and none of them were designed to coordinate with the others.

Two failure modes come out of running these sources side by side. The same clinician gets three alerts about one patient from three systems that don't know about each other. And an alert falls into the gap between two systems, where neither one owns the follow-up.

The integration surface varies by source. Lab results usually arrive as HL7 v2 messages. Newer EHR integrations expose FHIR Subscriptions, where you register interest in a resource change and receive a webhook when it happens. Epic and athenahealth both support event-driven subscriptions for things like admissions, discharges, and result updates. Whatever the transport, the job on your side is the same: turn a clinical event into an addressed, tracked, closeable notification.

Routing is a question about people, not channels

"Send it to the nurse" isn't a routing rule. It's a placeholder for four questions the system has to answer at send time.

Who is responsible right now? Not who is assigned in the chart, but who is on this shift, on this unit, covering this patient. Assignment data goes stale within hours, so routing has to read from whatever system holds the current truth, usually scheduling or the EHR's coverage tables.

What is their role? A critical lab value goes to a licensed caregiver who can act on it. A room-temperature alarm goes to facilities. Sending both to the same person is how you train them to ignore the phone.

What channel reaches them in this context? A clinician in a procedure isn't reading email. Someone at a workstation isn't looking at a smartwatch. Urgency should pick the channel, and the same alert may need a different channel at 3am than at 3pm.

What do they need to see? An alert that says "abnormal result" forces the recipient to go find the chart. An alert that carries the value, the trend, and the patient location lets them decide before they move. This is where you run into the constraint that shapes every healthcare notification: the more clinically useful the payload, the more carefully it has to be handled. Our post on where PHI should live covers that split in detail.

The escalation loop

Here is the part that most write-ups skip, because it looks trivial and isn't.

An escalation loop has three states and one clock:

Escalation usually goes out on a louder channel than the first attempt, and carries a note that the alert was already tried once so the next responder knows they are the fallback rather than the first call.

The distinction that matters is between delivery and acknowledgment. Delivery receipts tell you a carrier accepted the message. Read receipts tell you a screen rendered it. Neither tells you a person took responsibility for the patient, and only the third thing closes an alert.

The timer is your policy

Teams often go looking for the regulation that tells them how long to wait. It doesn't exist in the form they want.

The Joint Commission's National Patient Safety Goal on critical results (NPSG.02.03.01) requires organizations to report critical test results to a responsible licensed caregiver on a timely basis, and to have a written procedure defining the acceptable length of time between a result becoming available and being reported. The timeframe is yours to set and yours to defend. CLIA underpins the same expectation for lab reporting.

So the design consequence is direct: the escalation interval is a configuration value, not a constant. Sepsis alerts and credential-expiry reminders are the same mechanism with different numbers. Build it so the number lives in the alert type, not in the code.

In practice, alarm escalation on acute units is measured in minutes rather than hours, and hospitals tune it per alert class. Set it too long and the escalation is theater. Set it too short and you page the whole chain for alerts that were being handled.

The chain is already written down

You rarely have to invent the escalation path. Hospitals publish them, and they run in two parallel tracks.

The nursing chain typically runs from the bedside nurse to the charge nurse, then the nursing supervisor or administrative supervisor, then the senior director or administrator on call. The medical chain runs from the covering provider, which may be a resident, hospitalist, PA, or NP, to the attending, then the medical director, section chief, or department chair.

Your system's job is to encode the chain that the hospital already approved, including the branch where a nurse-track alert crosses over to the medical track. Getting this from the policy document rather than from first principles saves an argument later.

When nobody responds

Every chain needs a terminal state, and "keep escalating forever" isn't one. Decide in advance what happens when the last tier doesn't answer:

• Fall back to a location rather than a person, such as the unit's shared device or the charge desk.
• Open a ticket or incident record so the miss is visible in the morning rather than invisible forever.
• Notify a human whose job is coverage, not the patient, so somebody knows staffing failed.

The failure mode to avoid is an alert that quietly exhausts its chain and disappears. That's the one that shows up in a root cause analysis.

Building the escalation layer

The mechanics are the same whether you're building a clinical communication product or adding alerting to a health platform. You need a durable workflow that can wait, check, branch, and stop.

Courier's Journeys is one way to run that workflow without hand-rolling timers and state. The node set maps to the loop directly: send, delay, fetch data, branch, and cancel.

Start the run when the clinical event arrives. Attach a cancellation token built from the alert id, because that token is what lets you stop the whole chain later from anywhere in your stack:

import Courier from "@trycourier/courier";

const courier = new Courier({ apiKey: process.env.COURIER_API_KEY });

// Cancellation token is set in the journey's settings, templated from run data,
// e.g. alert-{{data.alert_id}}
const { runId } = await courier.journeys.invoke("critical-result-escalation", {
  user_id: primaryResponderId,
  data: {
    alert_id: alertId,
    alert_class: "critical_lab",
    escalation_interval: "PT4M",   // the timer travels with the alert
    unit: "5W",
    resource_type: "Observation",
    resource_id: observationId,     // a pointer, not the value
  },
});

Inside the journey, the loop is four nodes. Send to the first responder. Delay for the escalation interval, with the Dynamic Interval option reading escalation_interval off the trigger data so each alert class brings its own timer. Fetch data against your own API to ask whether the alert was acknowledged, since the fetch response merges into the journey context. Then branch on the answer: if acknowledged, exit; if not, send to the on-call responder at the next tier.

The cleaner path, when your application can emit an acknowledgment event, is to skip the polling entirely and cancel the run the moment a human takes the alert:

// Called from your ack endpoint when a clinician accepts the alert.
// Note the spelling: cancelation_token, one L.
await courier.journeys.cancel({ cancelation_token: `alert-${alertId}` });

Cancellation is idempotent and only affects active runs, so a duplicate acknowledgment from two clinicians at once is harmless. It returns 202 with the token. Because the token is a business identifier rather than a run id, you can cancel from the ack endpoint, from a Cancel node on another branch of the journey, or from an admin tool, without tracking run ids anywhere.

A few details worth getting right:

• Set the token from run data, such as alert-{{data.alert_id}}. A static token cancels every run of the journey.
• Fetch nodes require HTTPS, which is what you want for anything touching clinical data anyway.
• Branch nodes take the first path whose conditions match and always have a Default path. Make Default the escalate path, so an unexpected response shape escalates rather than silently ending the run.

That last point is the whole design philosophy in one line. When the system is unsure, it should wake somebody up.

Alarm fatigue is a design constraint

Any discussion of clinical alerting that treats volume as somebody else's problem is incomplete.

The Joint Commission issued a sentinel event alert on alarm safety in 2013 that cited 80 alarm-related deaths over a three and a half year window, and made alarm management a National Patient Safety Goal (NPSG.06.01.01) the following year. The underlying number is the one to design around: published studies of physiologic monitors report false alarm rates between 86% and 99.5%, a range that has held across a decade of alarm-fatigue research. The overwhelming majority of alarms don't need anyone.

You cannot fix a monitor's specificity from the notification layer. You can stop amplifying it:

• Tier by actionability, not by source. An alert that has no action attached shouldn't interrupt anyone. Route it to a dashboard or an in-app feed instead of a push.
• Suppress duplicates across systems. If three systems report the same deterioration, the clinician should get one notification with three inputs.
• Batch what isn't urgent. Credential expiry, routine results, and administrative notices belong in a digest, not in the same channel as a critical value.
• Throttle by recipient. Rate limits on a person are a safety feature, as long as the critical tier bypasses them.

The rule of thumb: every alert that interrupts a human should imply a decision. If the honest answer to "what do they do with this?" is "nothing, it's for awareness," it isn't an alert.

The audit trail is a deliverable

For clinical alerting, delivery records are evidence. When a case is reviewed, the question is not whether the system worked in general. It's what happened with this alert, for this patient, on this date.

A defensible clinical alert audit trail retains, per alert: what triggered it, who it was addressed to and why they were the right recipient at that moment, which channels were tried in what order, what each provider returned, when acknowledgment arrived, and who escalation reached. Courier keeps message-level delivery and engagement records for this, with log retention running 30, 90, or 365 days depending on plan, so match the retention to what your review process actually needs.

Two cautions. Those logs are sensitive in their own right, because a recipient plus a sender plus a timestamp can identify a patient's condition without a single clinical word. And read receipts are not acknowledgment. Store the clinical acknowledgment as its own event in your own system, because that's the one a reviewer will ask about.

Why hospitals buy this layer

The market has answered the build-or-buy question fairly clearly, and the shape of the spending says what's actually hard.

The clinical alert and notification market is projected to reach $5.9 billion by 2032, growing at 12.3% annually, covering hardware, software, and services together. Hardware is the commoditized part. Nurse call buttons, wearables, and sensors get cheaper every year. The differentiation sits in the layer that decides who gets told, in what order, and what happens when they don't answer.

The acquisitions point the same way. Stryker paid $3 billion for Vocera in 2022. symplr acquired Halo Health in 2024, with the stated goal of consolidating pagers, feature phones, and legacy texting into one system. The companies being bought solved orchestration, not hardware.

Regulation adds a floor under the demand. Since May 2021, the CMS Conditions of Participation at 42 CFR 482.24(d) have required hospitals to send electronic patient event notifications on admission, discharge, and transfer to the patient's established care providers. That's an event-driven notification requirement written into the terms of participating in Medicare.

What this looks like in production

Healthcare workforce platforms run the same loop for a different event class. When a shift goes uncovered, the system identifies qualified available staff, notifies them through their preferred channels, waits, and escalates to the next group or to a manager when nobody accepts.

Trusted Health uses Courier to power exactly this in its workforce management platform, alongside credentialing alerts and onboarding communications. The mechanics are identical to clinical escalation: an event, a timer, an acknowledgment, and a fallback. Only the urgency and the chain change.

That's the useful way to think about the whole category. A clinical alert system isn't a messaging feature. It's a state machine with a clock, and the messages are how it talks.

Frequently asked questions

What is a clinical alert and notification system?

It's the layer that takes clinical events from systems like lab, monitoring, pharmacy, and the EHR, routes each one to the responder who can act on it, waits for acknowledgment, and escalates to the next person when acknowledgment doesn't arrive in time. The routing and escalation logic is what distinguishes it from plain message delivery.

How long should a clinical alert wait before escalating?

That's your organization's decision. The Joint Commission requires a written procedure defining an acceptable timeframe for reporting critical results rather than mandating a specific interval. Acute alarm escalation is generally tuned in minutes and varies by alert class, so build the interval as a per-alert configuration value rather than a fixed constant.

What is the difference between alert delivery and alert acknowledgment?

Delivery means a provider accepted the message for transmission. Acknowledgment means a person confirmed they have taken responsibility for the alert. Only acknowledgment should stop an escalation clock, because a delivered message can sit unread on a phone in a pocket.

How do you reduce alarm fatigue without missing critical alerts?

Tier alerts by whether they imply an action, suppress duplicates when several systems report the same event, batch non-urgent notices into a digest, and rate-limit per recipient while letting the critical tier bypass the limits. The goal is to cut volume in the tiers where nothing happens, not to slow the tier where something does.

Can you send patient data in a clinical alert?

Keep protected health information out of channels you don't control, such as SMS, push, and email bodies. Send an alert that says something needs attention and carry a pointer the clinician resolves after authenticating. Anything that stores the clinical content, including your notification layer, comes into scope for encryption, access control, and a BAA.

Related resources:

• HIPAA-compliant notifications: where PHI should live
• The developer's guide to healthcare notifications
• Courier for healthcare

Sources: Joint Commission Sentinel Event Alert 50 (2013), Joint Commission NPSG.06.01.01 and NPSG.02.03.01; CLIA 1988; CMS Conditions of Participation, 42 CFR 482.24(d); Persistence Market Research; Stryker-Vocera acquisition; symplr-Halo Health acquisition.