Personalized baselines in RPM replace a single cutoff for everyone with a reference built from each patient's own readings. A patient whose blood pressure, weight or oxygen level normally sits outside a population range should not trigger a review every day, and a patient whose numbers look normal but are moving away from their usual level should.
This guide covers how to collect a baseline, which readings to leave out, how a baseline becomes a clinician-approved threshold, when to start again, and how to explain the result to the people who rely on it.
What is a personalized baseline in RPM?
Building per-patient thresholds into an RPM app?
Agnotic builds custom RPM apps for the client, including baseline collection, clinician approval of personal thresholds and versioned resets.
A personalized baseline in RPM is a reference range built from one patient's own readings over a defined collection period, used in place of, or alongside, population cutoffs. The software proposes the range from cleaned readings, a clinician approves it as the patient's personal threshold, and the baseline is reset after events such as a medication or device change.
A baseline does not decide care on its own. It is a reference point that makes a change visible, and the clinical team decides what counts as a meaningful change for each condition and each patient.
How long should the baseline period run?
The baseline period should run long enough to capture the patient's normal day-to-day variation for that measure, and the clinical team sets the length per condition. The software's job is to enforce it, not to choose it.
Make the period a setting with two parts: a minimum number of days and a minimum number of valid readings. A patient who measures twice a day reaches the reading count faster than one who measures every other day, and the baseline should wait for both conditions.
Readings should follow the program's measurement protocol: the same times of day, the same position, and the same rest period before a blood pressure reading. A baseline built from readings taken at random times mixes morning and evening patterns and comes out wider than it should.
Plan for patients who measure less often than expected. A reminder after a missed day, a nurse task when the period runs well past its planned length, and a clear status on the dashboard keep a slow baseline from stalling unnoticed.
During the baseline period, the patient is still monitored. Clinician-set critical limits apply from the first reading, and the dashboard marks the patient as "baseline in progress" so nurses know personal thresholds are not yet active.
Which readings belong in a baseline?
Only readings that reflect the patient's usual state belong in a baseline. Readings with device errors, readings outside the protocol and readings taken during an acute event should be excluded, with the reason recorded.
- Device error flags: Readings the device marks as unreliable, such as cuff errors or motion warnings, are left out.
- Repeated measurements: Several readings taken within minutes are combined into one value under a rule the clinical team chooses, such as the average of the second and third.
- Off-protocol timing: Readings far outside the agreed times of day are kept in the record but excluded from the baseline.
- Manual entries: Values typed by the patient are kept apart from device readings and excluded unless the program says otherwise.
- Acute events: Readings during an illness, a hospital stay or the days after a procedure are excluded, because they describe the event, not the patient's usual state.
Keep separate baselines where the pattern differs. Systolic pressure, diastolic pressure and pulse each need their own, and blood pressure may need separate morning and evening baselines, because a patient's readings can differ between the two times in a consistent way. One blended range hides the pattern the clinician needs to see.
Use statistics that one odd value cannot pull far. A median with a spread measure such as the interquartile range holds steady when a single reading is wildly off, where a mean and standard deviation can shift noticeably. Show the clinician the excluded readings alongside the result, so nothing is hidden.
From baseline to personal threshold
The baseline becomes a threshold only when a clinician approves it. The software proposes a range from the baseline and the condition template, and the clinician accepts, edits or rejects it.
- Proposal: The platform shows the baseline median and spread, the proposed upper and lower limits, and the readings used.
- Bounds: Proposed limits can never be looser than the critical limits set for the condition, whatever the baseline says.
- Form: Limits can be absolute values or offsets from the baseline, such as a set rise above the patient's usual weight. The clinical team chooses the form per measure.
- Approval: The approving clinician, the date and any edits are stored with the threshold as a new version.
- Expiry: Each approved threshold has a review date, after which the platform asks for re-approval.
Store the baseline as its own record, not as a setting on the patient. It needs a start and end date, the measure, the readings used, the readings excluded with reasons, the computed values, and a link to the threshold version it produced. That record is what makes review, audit and reset possible.
Weight in heart failure shows why the form matters. A fixed upper limit says little across patients of different sizes, while a rise above the patient's own recent weight over a short span is a change the care team can act on. The size of that rise is a clinical decision, recorded in the template.
When should a baseline be reset?
Reset a baseline when the patient's usual state has changed or the way it is measured has changed. Treatment changes, new devices and major health events are the usual triggers.
- Medication change: A new drug or dose shifts the expected readings. The clinician can start a fresh baseline period after the change settles.
- Device change: A replacement cuff, scale or meter can read differently from the old one. Start a new baseline and mark the change on the trend chart.
- Hospital stay or procedure: The patient's normal after discharge may differ from before admission.
- Life stage changes: Pregnancy and the postpartum period change blood pressure and weight patterns, and need their own templates.
- Drift without explanation: When readings stay outside the personal range for a long period without a cause, review whether the baseline still fits.
Device changes need care at the source too. Million Hearts, the HHS initiative, points programs to the US Validated Device Listing, a list of clinically validated blood pressure devices based on criteria from the American Medical Association. Replacing a validated cuff with another validated model keeps the new baseline comparable in quality to the old one.
Never overwrite an old baseline. Keep each version with its dates and approver, so any past alert can be traced to the range that was in force when it fired. The same history lets a clinician compare the new baseline with the old one and see how much the change moved it.
How do you explain a personal threshold?
Explain it with the patient's own readings. A clinician should see in one view where the range came from, and a patient should understand why their target differs from a neighbor's.
For clinicians, show the trend chart with the baseline band shaded, the readings that formed it, the excluded readings in a different style, and the approval details. A short sentence such as "Usual morning systolic 128 to 142, based on 24 readings from 3 to 16 March, approved by the RN care manager" says more than a score.
For patients, keep it simple: what their usual range is, what to do if a reading falls outside it, and who to call. The patient view should never suggest changing medication on the basis of the range alone.
Which rules apply to baseline logic?
Baseline logic is software that analyzes device readings to support clinical decisions, so device regulation and anti-discrimination rules both reach it. Plan a regulatory review before launch.
Under FDA's Clinical Decision Support Software guidance, issued in January 2026, Criterion 1 excludes from the non-device CDS category software that analyzes a pattern or signal from a signal acquisition system. Baseline and trend logic over repeated device readings may fall inside that exclusion, so the device question needs a decision, not an assumption.
Under 45 CFR 92.210, a covered entity must not discriminate through patient care decision support tools, and must make reasonable efforts to identify tools that use input variables measuring race, color, national origin, sex, age or disability, then mitigate the risk of discrimination. If templates set different default limits by age or sex, document why, and review outcomes across groups.
Baseline failure points
- Baselines from bad data: Error-flagged or off-protocol readings widen the range until real changes fall inside it.
- Silent activation: Personal thresholds switch on without a clinician's approval, so nobody owns them.
- Looser than critical: A wide baseline produces limits beyond the condition's safety limits.
- Old baselines after a device swap: The new device reads differently, and the patient alerts daily or never.
- No version history: Thresholds are edited in place, and past alerts cannot be explained.
- Endless baseline: A patient who measures rarely never completes the period, and nobody notices.
How Agnotic can help
Personal thresholds only help when the data behind them is clean and the approvals are clear. Agnotic Technologies builds this into RPM apps for the client: configurable baseline periods per condition, exclusion rules with recorded reasons, median-based proposals, clinician approval with versioning and review dates, and reset triggers tied to medication and device changes.
Agnotic also builds the views that explain a threshold, for nurses and for patients, and the audit trail that ties every alert to the baseline version in force at the time.
Build personal thresholds into your RPM program
Start with custom RPM app development, or browse more articles in the remote care hub.
Related reading on Agnotic
Continue with RPM alert fatigue, RPM alerts in Epic, RPM dashboard design, RPM MVP delivery and RPM basics.


