A fixed alert line treats every patient as the same patient. It fires all day for some and stays silent for others. Here is how a personal baseline works, where it goes wrong, and what the software has to get right.
A remote monitoring program usually starts with simple rules. Oxygen saturation below 90%, alert. Blood pressure above 140/90, alert. They are easy to explain, easy to test and easy to sign off.
Then the program grows. A nurse who watched 30 patients now watches 300. Some patients set off an alert with almost every reading. The team learns to skim past them. That is the moment a real decline gets missed.
This post is for the people who design and build the alert logic. It covers why fixed thresholds misfire, what a personal baseline actually computes, and the safety rules that must stay in place around it.
A fixed threshold fails in two ways at once.
Figure 1 shows both cases side by side. The readings are made up to show the pattern, not taken from real patients.
This is not only a theory. In hospitals, The Joint Commission estimated in its 2013 alert on alarm safety that 85% to 99% of alarm signals do not need clinical action, often because alarm settings are too tight (Sentinel Event Alert 50, summarized on PubMed). That figure is about bedside monitors, not home monitoring, but the cause is the same.
For home monitoring, a 2025 study of a Dutch hypertension program ran scenarios on its own alert data. Raising the systolic and diastolic alert limits once, by 10 and 5 mmHg, would have cut alerts by about half and saved the e-nurse an estimated 5,973 minutes a year (van Steenkiste et al., JMIR Medical Informatics, 2025). The authors also call for personal thresholds in some cases, and warn that any change must be weighed against clinical risk and checked again over time.
Note what that study tested: moving a shared line, not a full personal baseline. It shows how much of the alert load sits near the threshold. It does not prove that any given baseline method is safe.
A personal baseline is a learned "normal" for one patient and one signal. In most systems it comes down to four choices.
The output is a band, like the shaded areas in Figure 1. A reading outside the band is a candidate, not yet an alert.
A baseline answers "is this unusual for this person?" It does not answer "is this dangerous for anyone?" You need both.
Keep a set of absolute limits that always fire, whatever the baseline says. A patient whose baseline has drifted low still needs an urgent alert at a dangerous reading. Cardiac device practice works the same way. The 2023 international consensus on remote device clinics recommends a core set of high-priority alerts that stay on, with other alerts tuned to each patient once enough data has come in. The authors note that a core alert set brought alerts down to about one per patient-year while making them more actionable (HRS/EHRA/APHRS/LAHRS consensus, Europace 2023). Implanted devices are a different setting from home wearables, but the design pattern carries over.
A single low oxygen reading is often a cold finger or a loose sensor. Three days drifting the same way is a pattern. Most good alert logic asks two questions after a reading leaves the band: is the reading itself trustworthy, and does the change persist?
Persistence rules look like "outside the band on two of the last three days" or "a steady slope over five days". The exact rule is again a clinical choice. Figure 2 puts the layers in order.
Baselines remove noise, but they bring their own failure modes. Plan for these from day one.
Software that analyzes physiological signals to flag patients for clinical action can fall under medical device rules, depending on what it claims and where it is sold. Treat the alert logic as safety-critical code from the start: requirements, tests per rule and traceable changes. If a learned model is involved and you expect to update it after clearance, our post on FDA predetermined change control plans explains what the pipeline must record. Your regulatory lead should decide the device question, not the engineering team.
Innometrique is a software engineering partner, not a clinical or regulatory adviser, and holds no FDA or CE clearances. Clinical thresholds and band widths must come from your clinical team. Innometrique was founded in 2025. Before that, the founder's earlier company, Hashtaag Technologies (later acquired by Biofourmis), built software including beatHF and the biovitals analytics engine, which learned each patient's own baseline. That is founder background, not Innometrique client work. The founder track record page has the detail.
For the full system around the alert logic, see wearable and remote patient monitoring software. For a rough budget, the AI project cost estimator shows every assumption it uses.
Tell us what your program monitors and how alerts reach your care team today. We will look at your alert logic and data path and tell you plainly where the noise and the blind spots are.
Talk to Us →