Ember

Overview

Ember is a wearable and monitoring system for people recovering at home between chemotherapy sessions. It tracks heart rate, skin temperature and motion between checks, especially overnight, and when the pattern changes it prompts a real temperature reading. It does not diagnose infection, and it does not replace a thermometer.

The idea is the loop: the wearable notices, the device buzzes, the person takes a real reading, and the system follows up.

We are in a very early phase, so this page is mostly the design.

The problem

Chemotherapy can cause neutropenia, a shortage of the white blood cells that fight infection, and a fever in someone who is neutropenic can progress to sepsis. The CDC tells people on chemotherapy to call their care team immediately at 38°C (100.4°F) or higher, and notes that fever may be the only sign of infection. The risk often peaks around days 7 to 12 after an infusion.

The gap is before a person feels sick, or when nobody is watching. Overnight is the obvious case: routine checks are unlikely during sleep, and low motion makes resting heart rate easier to read, though skin temperature naturally rises then.

What I did

The team splits into hardware (the device and signal quality), data (rules, baselines, tests), scenarios (independent test cases), frontend and backend (dashboard and streaming), and pitch (safety, evidence, demo).

How it works

1. The wearable records heart rate, skin temperature and motion, with a quality flag on every reading.
2. The monitoring engine compares readings with the person’s usual overnight pattern, taking treatment day and data quality into account.
3. A physical prompt. The device vibrates, and a button acknowledges. No response means a re-prompt, then an opt-in caregiver alert. Delivery is logged, “sent” never counts as “answered,” and urgent instructions never wait.
4. Thermometer confirmation. The person enters an oral reading. At 38°C or above, urgent instructions appear immediately, at any hour. Below 38°C, the reading is logged beside the trend, the flag stays on, and a re-check is scheduled.
5. The symptom route. Tapping “I feel unwell” sends urgent symptoms straight to care instructions, with no wearable, thermometer or score in the way.
6. A dashboard shows trends, alert reasons and acknowledgments, with no claim of live clinician monitoring.

What it does overnight, with thresholds that are illustrative:

Situation	Response
Mild deviation, one signal	Log it; show it in the morning check-in
Sustained multi-signal deviation, good data	Buzz once and request a thermometer reading
Oral reading of 38°C or more, or urgent symptoms	Urgent-care instructions immediately; no score overrides this
Thermometer below 38°C, but the trend or symptoms persist	Log it beside the trend, keep the flag, schedule a re-check and symptom check-in; never mark the person safe
Device off, poor contact, stale data	Flag the gap; never report the person as safe

Heart rate drifts noneSkin temperature drifts none

Loosen the bandI feel unwell

Nothing flagged tonight.

Both signals stayed inside this person’s usual night, so Ember stays quiet. It never calls a night safe, only unchanged.

The hardware

Component	Role
Seeed XIAO ESP32-S3	Acquisition, Wi-Fi link, LiPo charging, local buffering when offline
SparkFun MAX30101 (PPG)	Raw green, red and IR PPG for upper-arm heart rate. Placement is experimental; a finger clip is the demo fallback
TMP117	Skin-temperature trend from a separate pad, isolated from the battery and microcontroller. Not oral temperature
LSM6DSOX IMU; DRV2605L and motor; button, LED	Motion artifacts; programmable vibration patterns; acknowledgment
500 mAh protected LiPo and MAX17048	Power and a low-battery warning, since the XIAO has no onboard fuel gauge

The form factor is a removable pod on a soft, adjustable upper-arm band, worn on an arm free of a PICC line, a port or lymphedema risk, at a target of about $110 to $150 per unit.

The measurable goals are modest on purpose. Over 20 resting windows: median absolute error against a reference chest-strap ECG, and the share of readings within ±5 bpm. Shaking that corrupts the signal should be flagged, and gentle motion with a clean signal should not. Every prompt, acknowledgment and dropout is timestamped. These are engineering benchmarks, not clinical validation.

Software and data

Two baselines do the work. A frozen reference from a stable enrollment period tracks long-term change. A recent baseline updates from good-quality nights that weren’t flagged as an acute anomaly, so a bad week never becomes normal. A drift detector raises a separate, non-urgent flag when the recent baseline keeps diverging from the reference, for example resting heart rate up 9 bpm over three cycles.

Quality rejection (bad data) is kept separate from anomaly detection (bad physiology).

There is one record per reading: patient_id, timestamp, signal, value, unit, source, quality and a synthetic flag, with derived values stored separately. Live hardware and synthetic patients run through the same pipeline. The stack is Next.js, Tailwind, Python or TypeScript, and WebSockets, with tests on every alert rule. All patient data is synthetic, and labeled as such.

Decisions worth explaining

It never says “safe.” A missing sensor, poor contact or stale data is reported as a gap, never as reassurance. A normal-looking thermometer reading is logged beside the trend, and the flag stays on until the pattern settles.

“Sent” is not “answered.” Delivery is logged separately from acknowledgment. No response means a re-prompt, then an opt-in caregiver alert.

Urgent instructions never wait. At 38°C or above, or on “I feel unwell,” the instructions appear at once, and no score can override them.

Two baselines, so a bad week never becomes normal. The reference stays frozen; the recent one only learns from good nights.

Bad data is not bad physiology. The system can say “I can’t tell” without that being mistaken for “all clear.”

How we’ll test it

The demo has four scenes. A teammate wears the device, and shaking their arm drops the signal quality so the reading is marked unreliable. A synthetic ten-day cycle runs through the pipeline: infusion on day 1; exercise on day 4 raises heart rate, but the motion data prevents an alert; and on day 8, overnight heart rate and skin temperature drift above the person’s usual night pattern. Then the device buzzes, an oral reading of 38.2°C is entered, and the urgent instructions and timeline update. Last, the device comes off, and the system reports insufficient data instead of reassurance.

To check the rules against something, we compare them with simple thresholds on the same synthetic scenarios, built by a teammate who didn’t write the rules, and including cases where Ember should tie or lose, like an infection with no change in fever or heart rate. That tests the software, not real-world detection.

Where it stands against prior work

Ember doesn’t claim to be first. A 2025 pilot of 15 hematology-oncology patients found continuous temperature monitoring feasible, but recorded missed fevers and false alarms. A 2022 pediatric case series reported earlier wearable fever detection in two bloodstream-infection cases. Clinical alerting may fall under FDA device rules, and a real study would start in silent mode.