Every failed RPM rollout has the same diagnosis: alert fatigue. The platform technically works. The devices report data. The dashboards display vitals. The caregivers stopped looking at them three weeks ago because they were buried in alerts that mostly weren't actionable.
Alert fatigue is a design problem, not a data problem. Here's the framework we use to design RPM alert systems that surface the right thing at the right time — and the metrics that tell you it's working before adoption collapses.
What alert fatigue actually is
Alert fatigue isn't "too many alerts." It's a specific cognitive phenomenon: when alerts predict reality poorly, humans learn to ignore them. Once a caregiver has dismissed 30 false positives in a row, the 31st alert — even if it's the real critical one — gets the same dismissive response.
The mechanism is well-documented in aviation, ICU monitoring, and now in RPM. The fix is the same in all three contexts: alerts must predict reality well enough that humans trust them.
Per-patient baselines, not population thresholds
The default RPM alert design uses population thresholds: "BP > 140/90 → alert." This is wrong for almost everyone outside the population mean.
A 78-year-old patient with chronic hypertension on three medications has a stable resting BP of 142/88. They have lived at that BP for five years. The population threshold fires every reading. The caregiver mutes the patient. The patient's BP spikes to 168/102 a week later — and the alert fires identically to the previous 30 false alerts. It's ignored.
The fix: per-patient baselines learned over the first 4–6 weeks of monitoring. Alerts fire on deviations from the patient's individual normal, not from population norms. Same patient, BP 168/102 = deviation from their 142/88 normal = real alert. BP 144/90 = within their normal range = no alert.
This requires more data plumbing but the alert quality improvement is dramatic. Override rates in our deployments drop from 50–70% (population thresholds) to <10% (per-patient baselines) within 90 days.
The four-layer alert hierarchy
Not all alerts are equal. We use a four-layer hierarchy:
- Critical — call now. Maximum 2–3 per caregiver per week. Above-baseline deviation + sustained + worsening trend.
- Concern — review within 4 hours. Deviation but not sustained; may resolve on its own. ~5–10 per caregiver per week.
- Trend — review at shift change. Subtle pattern change; informational. Shows up in a dashboard, not a notification.
- Trace — data only, no caregiver action. Goes into the audit log and clinical history.
The hierarchy isn't visual — it determines the delivery channel. Critical alerts pop. Concern alerts list. Trends sit on a dashboard. Traces are searchable. A patient triggering a trace 50 times a week makes no caregiver noise; a patient triggering one critical alert is a phone call.
Override-rate as a feedback signal
When a caregiver dismisses an alert without action, that's a data point. Aggregated, the override rate per alert type is the most important signal in your RPM platform.
We instrument every dismissal with: timestamp, caregiver, alert type, patient, reason (structured dropdown plus optional free text). The override rate dashboard shows:
- Override rate trending up over weeks → likely alerts are getting noisier (drift, threshold drift, population change). Investigate.
- Override rate spiking for one alert type → that alert type's threshold is wrong. Tune it.
- Override rate spiking for one caregiver → either training gap or workflow issue specific to that caregiver.
- Override rate spiking for one patient → that patient's baseline needs recalibration.
Without override-rate instrumentation, you have no feedback signal. You'll find out about alert fatigue when adoption craters — six months too late.
Shift-aware design
The same alert at 3pm and 3am should behave differently. At 3pm, a "concern" alert can wait until the caregiver finishes their current task. At 3am, there's no current task — the caregiver is asleep. A concern alert at 3am should not wake them, but a critical alert should.
Shift-aware alert routing means encoding caregiver schedules (day shift, night shift, on-call rotation) and adjusting delivery rules:
- During scheduled shift — standard delivery
- Off-shift / asleep — only criticals, with explicit acknowledgment requirement
- On-call — criticals + escalation chain if no acknowledgment in 5 minutes
- Handoff window — re-deliver outstanding concerns to incoming shift
This sounds elaborate. It's the difference between "RPM that worked for 6 months" and "RPM that's still working at year 3."
Soft-mute as a feature
Dismissing an alert as "I saw it, don't show me again for 4 hours" is a useful feature. Dismissing it as "this alert type is wrong and I'm muting it forever" is not — but caregivers will do the latter if you don't give them the former.
We always ship:
- Snooze (dismiss for X hours) — legitimate response to "I'm dealing with this"
- Acknowledge with reason — dismissal with structured input
- Mute alert type for this patient — requires reason; goes to clinical review
We never ship a permanent dismiss button. Permanent dismissal happens via clinical review with an audit trail.
Alert fatigue isn't 'too many alerts.' It's when alerts predict reality poorly enough that humans learn to ignore them — including the one that's right.
Measuring success
Three metrics tell you whether your RPM alert system is working. If any of them moves wrong, the system is broken regardless of what the technical dashboards say.
- Override rate trend — should be flat or declining. Rising = something is changing in your population or your thresholds.
- Critical-alert response time — should be under 30 minutes for true criticals. If it's longer, caregivers don't trust the criticals (alert fatigue).
- Caregiver NPS on the alerting system — measured quarterly. Below 5 (out of 10) = adoption is at risk.
We've shipped RPM with all three metrics in green for 18+ months. We've also rescued RPM platforms where two of three were red — and the fix was almost always alert hierarchy and per-patient baselines, not better devices.
The minimum design before launch
- Per-patient baselines (4–6 weeks of data before alerts fire)
- Four-layer alert hierarchy with distinct delivery channels
- Override-rate instrumentation with weekly review
- Shift-aware delivery rules
- Snooze + structured-reason acknowledgment
Without these, you're shipping a dashboard, not a monitoring system. The dashboard will be ignored within 90 days.
With these, the system survives turnover, scope changes, and the eventual reality that one of your alert types was wrong from day one. Override-rate instrumentation tells you which one before the program collapses.