Anomaly Detection Alerts for a Connected Glucose Monitoring Platform
Let's Connect
Overview
What we built
Patients wearing this maker's connected glucose monitors were switching their alerts off because the alarms cried wolf. We built a detection layer that learns each patient's own rhythm and flags what is genuinely unusual, earlier.
In plain terms: the device maker serves around 20,000 patients, and its monitors raised alarms using fixed thresholds, the same cut-off lines for everyone. For some patients that meant constant low-priority pings; for others it meant silence until a problem was already serious. Support logs showed alert fatigue was the top reason patients disabled notifications, which defeats the point of a connected monitor, and care teams had no way to spot unusual overnight patterns at all.
We built an anomaly detection layer that learns what normal looks like for each individual patient and flags deviations from that personal baseline, unusual overnight drift, accelerating trends, or a sensor dropping out, earlier than the fixed thresholds could. Flags are tiered by severity in the companion app and the clinician portal, and the regulatory-cleared alarms keep running untouched underneath. Non-actionable alerts fell 44% per patient, and the share of patients keeping notifications on rose from 61% to 87% within 4 months.
The Problem
Alert fatigue from static thresholds
Static thresholds treat every patient as the same patient. A glucose level that is routine for one person is alarming for another, but the platform's fixed cut-offs could not tell the difference. So the alarms fired either too often, training patients to swipe them away, or too late, activating only after a situation had already crossed a line rather than while it was developing.
The consequences showed up in the support logs: alert fatigue was the top reason patients disabled notifications. For a connected monitoring platform serving around 20,000 patients, that is the failure mode that matters most, because a monitor nobody listens to protects nobody. Patients who silenced the noise also silenced the warnings.
Care teams were flying equally blind at night. Overnight patterns, the slow drift or gradually accelerating trend that precedes a bad morning, are exactly what a human cannot watch for and a threshold cannot describe. There was no mechanism to surface them, so clinicians reviewed what had happened rather than what was building.
One threshold for all
Fixed alarm lines ignored each patient's individual glucose rhythm, so the same setting over-alerted some patients and under-protected others.
Alert fatigue
Repetitive low-priority alerts trained patients to ignore or disable notifications, and support logs ranked fatigue the top reason they switched off.
Invisible overnight patterns
Unusual drift and accelerating trends developed through the night with no mechanism to spot them, leaving care teams to react after the fact.
Late or noisy, never timely
Thresholds only fire once a line is crossed, so warnings arrived either too late to be useful or so often they stopped meaning anything.
What it was costing them
Every patient who disabled notifications turned a connected monitor back into an offline one, eroding the product's core promise for the roughly 20,000 people relying on it. Care teams spent their review time wading through noise rather than acting on genuine signals, developing overnight problems went unremarked until they became threshold events, and the support queue filled with the complaints of patients the alarms had worn down.
The Solution
Personalised anomaly detection layer
The heart of the build is a model that learns each patient's individual glucose rhythm, what their nights normally look like, how their levels typically move, and treats that personal baseline as the reference. Deviation from your own normal is a far more sensitive signal than distance from a universal line, which is how the layer flags unusual overnight drift, accelerating trends and sensor dropouts earlier than fixed thresholds could.
Not every deviation deserves the same urgency, so flags are tiered by severity before they reach anyone. Patients see them in the companion app at a weight that matches their importance; care teams see the same flags in the clinician portal, where the overnight patterns that were previously invisible now queue for morning review.
We were deliberately conservative about the boundary with the medical device itself. The anomaly layer runs alongside the regulatory-cleared alarms, never replacing or suppressing them. The thresholds remain the safety net they were certified to be; the new layer adds an earlier, personalised set of eyes on top.
Key decisions
Baseline per patient
Every patient's model is anchored to their own learned rhythm, so a flag means unusual for this person, not unusual for an average that fits nobody.
Tier flags by severity
Deviations are ranked before they are surfaced, so the app and portal present a graded picture instead of another undifferentiated stream of pings.
Augment, never replace, cleared alarms
The detection layer runs alongside the device's regulatory-cleared alarms rather than touching them, keeping the certified safety path exactly as approved.
Surface overnight patterns to clinicians
Overnight drift and accelerating trends flow to the clinician portal as reviewable flags, giving care teams the night-time visibility they never had.
Measurable Impact
What changed after launch
The noise dropped first: non-actionable alert volume per patient fell by 44% once personalised baselines went live, because alerts calibrated to an individual fire when something is genuinely off. Timeliness improved with it, with 83% of flagged overnight anomalies preceding a threshold alarm by 25 minutes or more, turning the new layer into an early-warning system rather than another siren.
Patients noticed the difference in relevance. The share keeping notifications enabled rose from 61% to 87% within 4 months, reversing the disablement trend the support logs had been recording. Care teams felt it too: clinician review time per flagged patient fell from 9 minutes to 4 in the care portal, because tiered, personalised flags arrive with context instead of demanding interpretation from scratch.
Alert relevance
Static thresholds firing too often or too late
Personalised flags, non-actionable volume down 44%
Early warning
No signal until a threshold line was crossed
83% of overnight flags preceded alarms by 25 minutes or more
Patient trust
61% of patients keeping notifications enabled
87% within 4 months of launch
Clinician review
9 minutes per flagged patient in the portal
4 minutes with tiered, contextualised flags
Headline results
Non-actionable alert volume per patient reduced by 44% after personalised baselines went live
83% of flagged overnight anomalies preceded a threshold alarm by 25 minutes or more
Share of patients keeping notifications enabled rose from 61% to 87% within 4 months
Clinician review time per flagged patient cut from 9 minutes to 4 in the care portal
Tech & Tools Used
What powered the build
Every tool below earned its place in this engagement. Here is the part each one played.
Python
The language of the detection layer itself, from the baseline-learning pipelines to the services that score incoming readings and tier the resulting flags.
PyTorch
Trains the models that learn each patient's individual glucose rhythm and detect drift, accelerating trends and dropouts against that baseline.
Apache Kafka
Streams readings from the device fleet into the detection layer continuously, so anomalies are scored as data arrives rather than in delayed batches.
TimescaleDB
Stores the patient glucose time series and learned baselines, making the historical rhythm queries behind every anomaly decision fast.
AWS IoT Core
The managed ingestion front door for the connected monitors, handling secure device connectivity before readings enter the streaming pipeline.
FastAPI
Serves the flag and severity APIs consumed by the companion app and clinician portal, and exposes the scoring service internally.
React Native
The companion app where patients receive tiered anomaly flags alongside, and clearly distinct from, the device's cleared alarms.
Grafana
Monitors the health of the detection pipeline and visualises flag volumes and model behaviour for the engineering and clinical teams.
Docker
Packages the scoring services and pipelines into consistent containers, keeping deployments reproducible across environments.
Ready to Build your Medical Devices Business with Fraud, Risk & Anomaly Detection
Ask Byte
Ask Byte
Typically replies instantly
just Now
Hi! I'm OrganByte's assistant. How can I help you today?
AI-generated content may be incorrect
