Nine rules. Three severity levels. Real-time evaluation.
Every incoming reading triggers evaluation across all active surveillance widgets on the person's chronic-condition pathways.
Window-based detection, not single-reading alerts
Legacy threshold alerting fires on every reading that crosses a line. The result: alert fatigue, ignored notifications, missed patterns. The HealthOS deterioration engine evaluates over configurable time windows, detecting sustained trends, rate-of-change patterns and multi-metric clusters that single readings miss.
- BP uncontrolled: the majority of systolic readings above 140 mmHg over 7 days (not a single spike)
- SpO2 sustained: the majority of readings below 92% across the window (not one dip)
- Glucose burst: 3+ hyperglycaemic readings within 24 hours (pattern, not point)
- Weight gain: >2 kg over 7 days signals fluid retention in CKD/HF
- Multi-at-risk cluster: 3+ metrics in concern band simultaneously flags systemic deterioration
- Missed readings: absence of expected data triggers follow-up before deterioration goes undetected
Source-agnostic, one engine, every data path
The deterioration engine reads from a canonical data layer that unifies wearable readings, manually recorded vital signs and data ingested from your existing clinical systems. One reading type normalised to one metric code, regardless of origin.
- Withings cellular devices (BPM Connect, ScanWatch, Body Smart) write to wearable_readings
- Manual vital signs entered by nursing staff write to vital_signs
- Clinical system integrations land in the same canonical tables
- Canonical UNION query normalises reading_type to metric codes for rule evaluation
- Adding a new data source needs no change to the detection rules, the new feed simply lands in the same canonical read
- Same evidence pool regardless of whether reading came from device, nurse or ingested system
Alert lifecycle, accumulate, don't flood
Traditional systems create a new alert for every threshold breach. The result: hundreds of duplicate notifications that clinicians learn to ignore. HealthOS maintains one open alert per rule per person, extending evidence on each evaluation until the alert is acknowledged or resolved.
- One open alert per rule per person, new evidence extends the existing alert rather than spawning a duplicate
- Evidence deduplication by source table and source ID, capped at 50 entries
- Full lifecycle: open → acknowledged → resolved (with clinician attribution)
- Notification fan-out only fires once per alert creation (not per evidence extension)
- Audit trail: every notification logged with channel, recipient, timestamp and delivery status
- Configurable per pathway via surveillance widget config, no code changes to tune
Detection rules by condition pathway
Each chronic-condition pathway seeds surveillance widgets with condition-appropriate detection rules. Severity and routing are configurable per organisation.
- CVD pathway
- bp_uncontrolled (watch), majority of 7-day systolic readings >140.
multi_at_risk_cluster (concern), 3+ metrics in concern band. - Diabetes pathway
- glucose_hyper_burst (concern), 3+ readings >11.1 in 24 hours.
glucose_hypo_event (urgent), any reading <3.0.
multi_at_risk_cluster (concern). - CKD pathway
- bp_uncontrolled (concern), renal risk from sustained hypertension.
weight_gain (concern), >2 kg / 7 days (fluid balance).
missed_readings (watch). - COPD pathway
- spo2_critical (urgent), any reading <88%.
spo2_sustained (concern), majority of readings <92%.
resp_rate_elevated (concern), sustained RR >24/min.