Remote Patient Monitoring and Anomaly Detection

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

Remote patient monitoring is the fastest-growing slice of telehealth, and in 2026 Medicare made it easier to bill — so more teams are shipping it, and almost all of them want AI to flag the reading a clinician should see. The promise is real: a stream of home readings is exactly the kind of high-volume, low-attention data where pattern detection earns its keep, catching a slow decline days before it becomes an emergency-room visit. The risk is equally real and easy to miss: an anomaly alert that crosses from "here is a trend" into "do this now" can become a regulated device overnight, a flood of false alarms can train your clinicians to ignore the one that mattered, and a model that is biased on skin tone or age can fail the patients who most need it. This article is for the founder, product manager, or engineer deciding what their RPM alerting feature is allowed to claim, who it speaks to, and where the regulatory and safety lines sit — drawn in plain language so the feature ships as help, not liability.

First, the words: RPM and anomaly detection

Two terms carry this whole article, so define them before using them.

Remote patient monitoring, or RPM, is the practice of collecting a patient's physiological readings — things like blood pressure, body weight, blood glucose, heart rate, or blood-oxygen level — from a connected device in their home and sending those readings to a care team between visits. It is one of the three shapes of telemedicine, distinct from a live video consult (synchronous) and a store-and-forward photo review (asynchronous); the taxonomy and where each fits is covered in our synchronous, asynchronous, and remote patient monitoring article. The defining feature of RPM is volume over time: a single patient can generate dozens of readings a week, and a panel of a thousand patients generates tens of thousands.

Anomaly detection is software that watches that stream and flags the readings that depart from what is expected — a blood-pressure spike, a weight gain that signals fluid retention, a glucose trend drifting out of range. The plain-language version: it is a smoke detector for a data stream, built to catch the reading a tired human reviewer would scroll past. The hard part, as with any smoke detector, is going off for the fire and staying quiet for the burnt toast.

The reason both definitions matter is that the value of RPM is drowned without good anomaly detection, and good anomaly detection is where every regulatory and safety question in this article lives.

Figure 1. Three kinds of RPM alert. The same anomaly can be a wellness nudge, a clinician-facing clinical alert, or a regulated device alert — what separates them is the claim it makes and who it speaks to, not the underlying math.

The line that decides everything: wellness signal vs regulated medical alert

One distinction governs how heavily your feature is regulated, and it is not about the algorithm — it is about the claim. The U.S. Food and Drug Administration regulates software as a medical device when it is intended to diagnose, treat, cure, mitigate, or prevent a disease (the device definition in the Food, Drug, and Cosmetic Act). Software that only supports a healthy lifestyle, and makes no disease-specific claim, sits outside that net under the FDA's General Wellness policy, updated in final form in January 2026.¹

Walk the same heart-rate reading through both worlds. A wellness product can say "your resting heart rate is trending up this week — you might want to rest or talk to your doctor." That is a general-wellness nudge: non-invasive, low-risk, no disease claim, and the FDA's guidance explicitly allows a wellness product to prompt the user to consult a professional when a reading falls outside a normal range. The moment the same reading is presented as "this pattern may indicate atrial fibrillation — seek care," the product is making a disease-specific claim and has stepped toward being a regulated device.

So the practical test for a product team: does your alert describe a state of wellness, or does it name, predict, or act on a disease? The answer decides your regulatory regime before a single line of model code is written. Distinguish "your numbers are trending the wrong way, talk to your clinician" (wellness) from "you are deteriorating, do X" (device territory).

The FDA device line in more detail: who you speak to, and how urgent

The wellness-versus-disease claim is the first cut. The second is the FDA's Clinical Decision Support guidance, issued in final form on January 6, 2026 (docket FDA-2017-D-6569), which draws the line between decision-support software that is not a device and software that is.²

Two parts of that guidance hit RPM anomaly detection directly. First, the "not a device" carve-out applies only to software built for health care professionals who can independently review the basis for a recommendation. Software that delivers recommendations straight to patients or caregivers is generally a device. An RPM alert that pops up on the patient's phone telling them what their reading means and what to do is patient-facing, and that path is regulated by default.

Second, the guidance treats time-critical alerting as device territory: tools that alert a clinician to possible patient deterioration — the examples it gives include possible stroke, sepsis, or heart attack — are medical device software because they support time-critical decisions. An anomaly detector that flags "possible deterioration, act now" is in that category even when it speaks only to a clinician. The safe zone is narrower than teams expect: a tool that surfaces a trend to a clinician who reviews it on their own schedule and judgment is far more defensible than one that issues an urgent, directive alarm. The full diagnosis-versus-support treatment for the whole AI block lives in our compliance and safety layer for clinical AI.

Figure 2. What pushes RPM anomaly detection over the FDA line. Speaking directly to the patient or caregiver, issuing a time-critical deterioration alarm, or naming a disease each move the tool from support toward a regulated device.

The real day-to-day problem: alert fatigue

Suppose you keep your feature firmly on the support side. You still have the hardest engineering problem in RPM, and it is not catching anomalies — it is not crying wolf.

Monitoring alarms are mostly false. Across studied hospital settings, 80–99% of alarms are false or clinically insignificant, and in critical-care monitoring as many as 90% of alarms are false positives.³ One detailed study of arrhythmia alarms found 88.8% of 12,671 annotated alarms were false.⁴ The consequence has a name — alarm fatigue — and a well-documented mechanism: when nearly every alarm is noise, clinicians learn to tune them out, and the rare true alarm gets ignored along with the rest. A monitoring system that is technically sensitive but practically ignored is worse than no system, because it manufactures false confidence.

Do the arithmetic a product owner should do. Suppose your detector watches 1,000 patients, each sending one reading a day, and your simple threshold fires on 5% of readings. That is 50 alerts a day, roughly 1,500 a month, landing on a care team that can meaningfully act on a few dozen. If 90% of those are false, the team is wading through about 1,350 non-events a month to find the 150 that matter — and within a week they are skimming. The percentage looks fine; the daily flood is the failure. The goal of anomaly detection in RPM is not maximum sensitivity. It is the highest true-alert rate the care team can actually act on, which means ruthless suppression of noise.

How AI actually helps: baselines, trends, and triage

Used well, this is exactly where machine learning earns its place — not by shouting louder, but by being quieter and more precise.

The biggest lever is the personalized baseline. A fixed threshold ("alert if systolic blood pressure is over 140") fires constantly for the patient who lives at 145 and never fires for the athlete whose jump to 135 is genuinely abnormal for them. A model that learns each patient's normal range and flags departures from their own pattern cuts false alerts sharply — vendors report reductions on the order of 60–80% from patient-specific baselines, a figure worth validating against your own data rather than taking on faith.⁵ The second lever is trend detection: catching the slow three-week drift in weight or glucose that no single reading would trip but that predicts a problem days ahead. The third is triage, not elimination: the model ranks and routes, a clinician decides. The human stays in the loop both because it is safer and because, as the FDA section above showed, keeping a clinician between the model and the action is what keeps the feature on the support side of the device line.

Put together, the safe pattern is: device readings flow in as Protected Health Information, a model under contract computes a personalized baseline and surfaces ranked anomalies, a noise filter suppresses the obvious non-events, and a clinician reviews the short ranked list and acts. The alarm gets quieter and smarter, and a human owns every action.

Figure 3. A safe RPM anomaly-detection pipeline. Readings enter the HIPAA boundary as PHI; a contracted model computes personalized baselines and ranks anomalies; a noise filter and a clinician triage step keep alerts actionable. The consumer wellness app stays outside the boundary.

Every reading is PHI — so the model is a business associate

A stream of a named patient's blood-pressure and glucose readings is Protected Health Information (PHI) — any health data tied to an identifiable person. The moment that stream leaves your servers for a model to analyze, the model's provider is handling PHI on your behalf, which under HIPAA makes it a business associate: a vendor that may not touch PHI until you have signed a Business Associate Agreement, or BAA — the contract in which the vendor promises to guard the data and accept HIPAA liability (45 CFR §160.103 and §164.502(e)).⁶

Think of the BAA as the signed promise every contractor makes before getting a key to the building. No signature, no key — no matter how good the model.

This disqualifies the free consumer AI endpoints a team often reaches for first; they ship no BAA and are not built for PHI. The enterprise model services from the major cloud providers are offered under a BAA, but you must use the covered enterprise service, confirm the BAA names it, and add a no-training clause so your patients' readings are never absorbed into the vendor's future models. If you want to run analytics on monitoring data outside the strict clinical loop, the safer route is to de-identify it first under HIPAA's Safe Harbor or Expert Determination methods (45 CFR §164.514(b)), which is the subject of our de-identification and analytics on health data article. The full PHI-handling and model-vendor-BAA pattern for every AI feature lives in the compliance and safety layer for clinical AI.

The bias trap: an anomaly model is only as fair as its data

An anomaly detector makes a decision about a patient, and that makes it subject to a duty most teams overlook. Under Section 1557 of the Affordable Care Act, a covered entity must identify and mitigate the risk of discrimination when it uses a patient care decision support tool — a category the 2024 final rule defines broadly to include AI and machine-learning models — with the core prohibition effective May 1, 2025 (45 CFR §92.210).⁷ An RPM anomaly model that decides whose reading gets a clinician's attention is squarely in scope.

The reason this is not abstract has a textbook example. Pulse oximeters — the clip-on devices that feed oxygen readings into many RPM programs — overestimate blood-oxygen levels in patients with darker skin, by roughly 1–1.5% on average, enough that real low-oxygen events were missed; in COVID-19 studies, Black patients were over-represented among those whose need for treatment went unrecognized, and an FDA advisory panel in 2024 confirmed the disparate performance.⁸ An anomaly detector trained on that biased signal inherits the bias: it will under-alert for exactly the patients the data already fails. The lesson generalizes beyond skin tone to age, body type, and any group under-represented in the training data. The duty — and the engineering practice — is to test alert performance across patient subgroups, document what you found, and mitigate the gaps, not to assume the model is neutral because the math is.

A common, expensive mistake

The signature failure in RPM anomaly detection is the patient-facing auto-alert with a disease claim: wiring the model to message the patient directly — "your readings suggest a heart problem, take action" — because it feels responsive and saves the care team a step. In one move the team has crossed two lines at once. It has made a disease-specific, directive claim to a patient or caregiver, which the FDA's 2026 CDS and General Wellness guidance treat as a regulated medical device, and it has removed the clinician who keeps the feature defensible and safe. The feature that was meant to reduce risk has become a regulatory and patient-safety liability.

The quieter cousin is the threshold-flood: shipping fixed-threshold alerts with no personalized baseline because they are simple to build, and watching the care team drown in false positives until they mute the whole system. It passes a demo and fails in production the first busy month. Keep the model on the support side, keep a clinician in the loop, and invest in noise suppression before sensitivity, and neither mistake survives contact with real patients.

The 2026 reimbursement reality — why product teams should care

A product decision that used to feel purely clinical now has a billing dimension worth understanding, because it shapes what your alerting feature is for. For 2026, Medicare expanded how remote monitoring is paid. The CY2026 Physician Fee Schedule final rule added a new code, 99445, that reimburses RPM for as few as 2–15 days of readings in a 30-day period, alongside the long-standing 99454 that requires 16 or more days, and a new shorter treatment-management code, 99470 (first 10 minutes), alongside the existing 99457 (first 20 minutes); both new codes took effect January 1, 2026.⁹ The older rule effectively required 16 days of data before a practice could bill, which pushed products toward "collect everything." The new shorter-duration option rewards programs that can act on fewer, better readings.

The connection to anomaly detection is direct. When reimbursement rewarded sheer days of data, the incentive was volume; when it rewards acting on what the data shows, the incentive is a system that surfaces the readings worth a clinician's time. Good anomaly detection is now the difference between a monitoring program that bills for collecting noise and one that bills for clinical action — and the full RPM product, devices, and care-team workflow are covered in our chronic care management and remote patient monitoring playbook.

Figure 4. RPM alerting approaches compared. Read the last two columns first: who acts on the alert and whether a clinician stays in the loop decide both the false-alarm load and the regulatory posture.

Where Fora Soft fits in

The requirement comes first: an RPM alerting feature must keep its claims on the wellness or clinician-support side of the FDA's device line, keep a clinician between the model and any action, suppress false alarms hard enough that the true ones get seen, hold every reading inside a BAA-covered boundary, and test its alerts for bias across patient groups. Fora Soft has built real-time video, conferencing, surveillance, and connected-device software since 2005, including telemedicine platforms where home-device readings, anomaly alerts, and a clinician's worklist are one connected flow. We wire anomaly detection in as a triage aid — personalized baselines, ranked alerts, a noise filter, and a clinician review step — rather than as an autonomous alarm that speaks to patients or names diseases. The same anomaly-detection engineering, on video rather than vitals, is covered in the AI for Video Engineering section's anomaly detection playbook.

What to read next

• Where AI fits in a telemedicine product — the map
• The compliance and safety layer for clinical AI
• Chronic care management and remote patient monitoring

Download the RPM Anomaly-Detection Safety & Compliance Checklist (PDF)

Call to action

• Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your rpm anomaly detection plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the RPM Anomaly-Detection Safety & Compliance Checklist — One page: run a remote-patient-monitoring anomaly-detection feature through four gates — the wellness-vs-device claim line, alarm-fatigue suppression and clinician triage, the PHI boundary and BAA, and bias testing across patient groups….

References

1. General Wellness: Policy for Low Risk Devices — Guidance for Industry and FDA Staff (Final, January 2026) — U.S. Food and Drug Administration. Tier 1. A general-wellness product promotes a healthy lifestyle without a disease-specific claim, is low-risk and non-invasive, and may prompt a user to consult a professional when a reading is outside a normal range — but a disease claim moves it toward device regulation. Time-sensitive — confirm the current version.
2. Clinical Decision Support Software — Guidance for Industry and FDA Staff (Final, January 2026) — U.S. Food and Drug Administration, docket FDA-2017-D-6569. Tier 1. The "not a device" carve-out applies only to software for health care professionals who can review the basis; patient/caregiver-facing tools are generally devices, and time-critical deterioration alerts are device software. Time-sensitive.
3. Alarm Fatigue — Making Healthcare Safer III — U.S. Agency for Healthcare Research and Quality (AHRQ) / NCBI Bookshelf. Tier 1. 80–99% of clinical alarms are false or clinically insignificant; high false-alarm rates desensitize clinicians and cause true alarms to be missed.
4. Insights into the problem of alarm fatigue with physiologic monitor devices: a comprehensive observational study — PLOS ONE (2014). Tier 5. In a detailed observational study, 88.8% of 12,671 annotated arrhythmia alarms were false positives.
5. Classification of Methods to Reduce Clinical Alarm Signals for Remote Patient Monitoring: A Critical Review — arXiv (2023). Tier 5. Reviews intelligent-filtering and patient-specific methods to suppress false alarms in remote monitoring; vendor and research reductions of roughly 60–80% from personalized baselines should be validated against local data. Illustrative — verify against your own data.
6. HIPAA Privacy Rule — Business Associates (45 CFR §160.103, §164.502(e)) — U.S. Department of Health and Human Services. Tier 1. Any model provider that receives PHI is a business associate and needs a signed BAA before any reading reaches it.
7. Section 1557 — Nondiscrimination; patient care decision support tools (45 CFR §92.210) — HHS (eCFR), 89 FR 37692, May 6, 2024. Tier 1. A covered entity must identify and mitigate the risk of discrimination from patient care decision support tools, including AI; the core prohibition is effective May 1, 2025. Time-sensitive — confirm provisions remain in force.
8. Review of Pulse Oximeters and Factors That Can Impact Accuracy (FDA Executive Summary, 2024 advisory committee) — U.S. Food and Drug Administration. Tier 1. Pulse oximeters can overestimate oxygen saturation in patients with darker skin pigmentation, with documented clinical consequences; the 2024 panel reviewed the disparate performance and testing standards.
9. Medicare and Medicaid Programs; CY 2026 Payment Policies Under the Physician Fee Schedule (Final Rule) — Centers for Medicare & Medicaid Services, Federal Register 90 FR (Nov 5, 2025). Tier 1. Adds RPM code 99445 (2–15 days of data) alongside 99454 (16+ days) and treatment-management code 99470 (first 10 minutes) alongside 99457 (first 20 minutes), effective January 1, 2026. Time-sensitive — re-verify rates and codes at publication.
10. Software as a Medical Device (SaMD) and the device definition (FD&C Act §201(h)) — U.S. Food and Drug Administration. Tier 1. Software intended to diagnose, treat, cure, mitigate, or prevent a disease meets the device definition; intended use and claims, not the algorithm, decide whether RPM software is a regulated device.