Wrist-worn health monitor: battery, false alarms and privacy
Tamariki Health is piloting a wrist-worn device for 500 adolescents at risk of seizures. The prototype samples the accelerometer at 50 Hz and streams raw data over Bluetooth Low Energy to a paired phone, which uploads it to a cloud model. The 300 mAh battery lasts about 9 hours; the clinical team wants 24-hour wear. The device microcontroller has 256 KB RAM and 1 MB flash. A quantised on-device model needs 180 KB of flash and about 40 ms per inference at 5 Hz. The heart-rate sensor runs at 1 Hz. In a 30-day pilot the cloud model produced 12 false alarms per day, and 3 of 14 true seizure events were missed. The privacy officer notes that continuous accelerometer traces can reveal sleep, gait and possibly medication adherence.
1. Recommend an architecture that meets the 24-hour battery target while preserving seizure detection. Justify the sampling rate, where inference should run, and what data should leave the device.
Read the worked answer
The current design spends most of its energy budget on the radio, not the sensor. Streaming 50 Hz raw accelerometer data continuously over BLE keeps the radio and phone link active, which is consistent with a 9-hour battery on 300 mAh. Moving inference on-device removes the continuous uplink and allows the radio to sleep.
Sampling. Seizure-related movement is typically in the 1–10 Hz band, so 50 Hz is oversampled for this purpose. A 10–20 Hz accelerometer rate with an anti-aliasing filter would capture the relevant signal while cutting samples by 60–80%. The on-device model is specified at 5 Hz inference, so the sensor can batch windows and the CPU can sleep between them. A useful design is 20 Hz sampling, 5 Hz inference on 2-second windows, and a low-power motion threshold that wakes the model only when movement exceeds a baseline.
Inference placement. With 180 KB of 1 MB flash and 40 ms per inference at 5 Hz, the quantised model fits comfortably and uses about 20% of one core's time. That is feasible on the microcontroller. The cloud model should not be removed entirely; it can serve as a second-stage reviewer for ambiguous events, but only on short event snippets, not continuous raw data.
Data leaving the device. Send event snippets (e.g. 30 seconds before and after a candidate event), model confidence, and device health metrics. Do not send continuous accelerometer traces. That reduces bandwidth, battery use, and privacy exposure. The phone can relay events when connectivity exists, with local buffering for offline periods. Heart rate at 1 Hz is low-cost and can remain local unless an event is flagged.
Validation. The architecture must be re-validated against the same 30-day dataset; a lower sampling rate could reduce sensitivity, so the missed-event rate must be measured, not assumed.
2. The pilot had 12 false alarms per day and missed 3 of 14 true events. Evaluate whether the system is fit for clinical pilot, and explain how you would reason about the trade-off between sensitivity and false alarms.
Read the worked answer
Missing 3 of 14 events is a sensitivity of about 79%, which is not acceptable for a seizure-detection claim without a clear caveat. Twelve false alarms per day is also operationally corrosive: caregivers who receive frequent false alerts may start ignoring them, which indirectly increases risk. The two errors are linked by the decision threshold. Lowering the threshold catches more true events but increases false alarms; raising it does the opposite. The judgement is not “maximise accuracy” but “choose an operating point that matches the clinical response”.
I would separate the use case. If the alarm triggers a caregiver check, a moderate false-alarm rate may be tolerable because the cost of a check is low and the cost of a miss is high. If the alarm triggers emergency services or medication, false alarms carry much higher cost. The pilot should define the response before tuning the threshold, then select an operating point using a cost matrix rather than raw accuracy. With only 14 true events, the confidence interval on sensitivity is wide; a single event changes the rate by about 7 percentage points. The team should not claim a precise sensitivity from this sample.
A better design is a two-tier alert: a high-confidence tier that notifies the caregiver immediately, and a lower-confidence tier that logs the event for clinician review. That preserves sensitivity while reducing alarm fatigue. The team should also report precision, time-to-detection, and the false-alarm burden per user-day, not just sensitivity. Before a wider clinical pilot, I would require a prespecified threshold, a blinded validation set, and a safety monitoring plan that records every missed event and every alarm response.
3. The privacy officer is concerned about continuous accelerometer traces. Recommend what the team should do, and explain how technical design and consent interact.
Read the worked answer
Continuous accelerometer traces are more revealing than they appear. Over days they can infer sleep timing, gait changes, tremor, exercise, and maybe adherence to rest recommendations. For adolescents, that is sensitive health and lifestyle data. Consent is necessary but not sufficient: a 13-year-old may not meaningfully understand a multi-year data footprint, and consent does not excuse collecting more than the purpose requires.
The technical design should enforce data minimisation by default. Raw traces should stay on the device or phone, encrypted, with a short retention window (e.g. rolling 7 days) and automatic deletion. Only event snippets and derived features should go to the cloud. If clinicians need raw data for model improvement, that should be a separate, opt-in research pathway with a defined retention period, de-identification, and ethics approval, not a condition of using the device.
The consent process should describe, in plain language, what leaves the device, who can see it, how long it is kept, and how a participant withdraws. Withdrawal must actually delete data, not just stop collection. The team should also consider a “privacy dashboard” showing the adolescent what has been shared.
There is a governance point: the cloud provider's terms may permit secondary use. The team must verify the data-processing agreement, encryption, access controls, and breach notification. If the vendor cannot guarantee no secondary use, the team should keep inference on-device and send only alerts. Consent and architecture should reinforce each other; consent without technical minimisation is paperwork, and minimisation without consent is paternalism.