The Data Nobody Has Time to Read
A patient with hypertension straps on a blood-pressure cuff every morning. Another wears an Apple Watch that logs heart rate around the clock. A third checks a continuous glucose monitor a dozen times a day. Multiply that by a few hundred enrolled patients and you have a firehose of readings — tens of thousands of data points a week — arriving at a care team that has, realistically, no capacity to read them.
So most of it goes unread. The data exists, it's often clinically meaningful, and it sits in a dashboard nobody opens until a patient calls with a problem that the numbers had been quietly signalling for a fortnight. That gap — between data collected and data acted on — is the actual problem remote patient monitoring (RPM) has always faced. Collecting the readings was never the hard part. Reading them was.
This is where AI earns its place. Not as a device that diagnoses, and not as a crystal ball that predicts discrete events, but as the layer that watches the stream continuously, learns what "normal" looks like for each patient, and raises a hand when a trend starts drifting somewhere concerning — so a clinician looks at the right patient at the right time. This guide covers how that's built, where it goes wrong, and what it costs to do properly. It sits alongside our broader healthcare AI development guide.
Getting the Data In: Integration and Normalisation
The unglamorous truth is that most of the engineering effort in an RPM platform goes into ingestion, not intelligence. Devices don't agree on anything. An Apple Watch reports through HealthKit; a Fitbit through its own cloud API; a connected blood-pressure monitor might push readings over Bluetooth to a phone app that then forwards them; a glucose monitor has its own ecosystem again. Units differ, sampling rates differ, timestamps arrive in different time zones, and every vendor has its own idea of what a "reading" is.
Before any AI can do anything useful, all of that has to be normalised into a single, consistent representation — ideally mapped to healthcare standards like FHIR observations and LOINC codes so the data means the same thing across sources. This is the same integration discipline that governs FHIR and EHR work elsewhere in a clinical platform, and it's just as load-bearing here.
The signal is also noisy. A smartwatch records a spiking heart rate because the patient ran for a bus, not because anything is wrong. A blood-pressure reading taken immediately after climbing stairs is meaningless. A glucose sensor drops out for an hour. If the platform treats every raw number as a clinical fact, it will drown the care team in nonsense. So a real ingestion pipeline includes cleaning, artefact rejection, gap handling, and context — distinguishing a genuine physiological trend from the ordinary noise of a human living their life.
Baselines and Thresholds: What "Normal" Means for This Patient
The single most important design decision in an RPM platform is that "normal" is per-patient, not universal. A resting heart rate of 58 is unremarkable for a fit 40-year-old and a possible concern for someone whose baseline has sat at 75 for months. A fasting glucose that would alarm one patient is routine for another. Fixed, population-level thresholds produce two failure modes at once: they miss meaningful changes in patients whose numbers stay within "normal" ranges, and they cry wolf constantly for patients whose baseline sits near a threshold.
So the platform establishes a personal baseline for each patient over an initial period, then watches for deviation from that baseline rather than crossing an absolute line. This is fundamentally a trend- and anomaly-detection problem: the system isn't asking "is this number high?" but "is this patient's pattern moving in a direction that, over days or weeks, looks concerning relative to where they've been?" A gradual upward creep in resting blood pressure across three weeks matters more than a single high reading, and a slow flattening of heart-rate variability can be more informative than any one data point.
Thresholds also need to be tunable per patient and per programme. A newly discharged heart-failure patient warrants tighter monitoring than someone in a stable chronic-care programme. The clinician, not the algorithm, should own those settings — the AI proposes and detects; the care team decides what warrants attention for whom.
The Escalation Workflow: From Signal to Clinician
Detecting a concerning trend is worthless if nothing happens next. The escalation workflow is where an RPM platform lives or dies, and it needs to be designed as carefully as the detection itself.
When the system identifies a trend worth attention, it should package the finding for a human: which patient, what changed, over what period, with the relevant data visualised — not a bare alert saying "anomaly detected," but enough context for a nurse or physician to make a fast triage decision. From there, a tiered response works well: lower-concern trends go into a review queue a nurse works through during the day; higher-concern trends generate a prompt, time-sensitive alert routed to the right person.
Crucially, the AI's role ends at "here is a patient and a trend worth your attention." It does not diagnose, it does not decide the clinical response, and it does not act autonomously on the patient. A licensed clinician reviews the flag, decides whether it's real, and chooses what to do — call the patient, adjust medication, bring them in, or note it and keep watching. This human-in-the-loop structure is the same principle that runs through all responsible AI agents in healthcare: the software escalates; the professional decides.
Alert Fatigue: The Thing That Quietly Kills RPM Programmes
Here is the failure mode that sinks more monitoring programmes than any technical problem: too many alerts. If a care team gets fifty flags a day and forty-five are noise, two things happen. First, the team stops trusting the system. Second — and worse — they start ignoring it, and the one genuinely important flag gets dismissed along with the false alarms. A monitoring system that erodes clinician trust is worse than no system, because it consumes attention while providing false reassurance.
This is why per-patient baselines, trend-based detection, and tunable sensitivity aren't nice-to-haves — they're what stands between a useful programme and one that gets switched off in month three. The goal isn't to catch everything; it's to maintain a high enough signal-to-noise ratio that clinicians keep believing the alerts. That often means deliberately tuning toward fewer, higher-confidence escalations, accepting that the system stays quiet most of the time, and measuring false-alarm rates as a first-class metric rather than an afterthought.
A concrete, illustrative example of how a tiered design keeps the noise down:
| Signal | What the AI does | Who acts, and when |
|---|---|---|
| Single high BP reading after exercise | Recognised as likely artefact; logged, no alert | No one — noise filtered out |
| Resting heart rate drifting up over 2 weeks | Flagged as a trend for review | Nurse reviews in daily queue |
| Steady worsening of BP trend across weeks | Escalated as higher concern | Clinician prompted to review, may contact patient |
| Sudden, sustained deviation far from baseline | Priority escalation with context | Time-sensitive alert to care team |
None of those rows involves the AI diagnosing anything or deciding treatment. Each one ends with a human deciding what the finding means.
Security, PHI, and the Regulatory Line
Everything in an RPM platform is protected health information. Continuous physiological data streamed from a patient's home is PHI, and it has to be treated with the full weight that implies: encryption in transit and at rest, strict access controls, audit logging of who viewed what, and a signed Business Associate Agreement with every vendor in the chain — including the device platforms and any cloud services in the pipeline. Device-sourced data adds its own wrinkles: consent for collection, clarity on data ownership, and secure handling of the pathway from the device through a phone app to your servers. The HIPAA-compliant architecture discipline that governs any clinical AI applies here without exception.
The regulatory framing matters just as much, and it's easy to overclaim. An RPM platform that surfaces trends for clinician review is generally an administrative and workflow tool, not a diagnostic medical device. But that line depends entirely on what the software actually does. The moment a function starts making an autonomous clinical determination — diagnosing, or driving a treatment decision without a clinician in the loop — it may fall under the FDA's Software as a Medical Device (SaMD) framework and require separate clearance. This is a strong architectural reason to keep the AI firmly in an assistive, human-reviewed role: it's both safer clinically and cleaner regulatorily. Treat "is this function SaMD?" as a question to answer explicitly during scoping, not one to discover later.
What Good Looks Like
A well-built RPM platform has a recognisable shape:
Reliable ingestion. Data from every supported device lands consistently, normalised to a common standard, with noise and artefacts handled rather than passed through raw.
Per-patient baselines. Normal is defined for each individual, and detection is based on deviation from that baseline, not fixed population thresholds.
Trend-based, not point-based. The system watches for patterns moving in a concerning direction over time, which is where the clinical signal actually lives.
A disciplined escalation workflow. Every flag reaches the right person with enough context to act, tiered by urgency, and always ends with a clinician's decision.
A relentless focus on signal-to-noise. False-alarm rates are measured and managed as a primary metric, because alert fatigue is the number-one killer of these programmes.
Full PHI handling. Encryption, access control, audit logging, BAAs across the device and cloud chain, and clear consent.
Questions to Ask
Before commissioning an RPM build, ask directly:
"How are per-patient baselines established, and can clinicians tune thresholds?" If the answer is fixed population thresholds, expect alert fatigue.
"What's the false-alarm rate, and how is it measured?" A team that can't answer this hasn't thought about the thing that matters most.
"Exactly what does the AI decide, and what does a clinician decide?" The correct answer keeps the AI at detection and escalation, with a human owning every clinical decision.
"How is device data secured from the device to our servers, and who has BAAs?" You want the whole chain accounted for, not just your own database.
"Which functions, if any, might count as SaMD?" A credible team has already asked this and can tell you where the regulatory line sits for your design.
What It Costs and How Long It Takes
Honest, illustrative ranges only — every programme differs. A production RPM platform is a multi-month engagement, and the cost is driven less by the AI than by the integration and compliance work around it. Supporting several device ecosystems, normalising their data, building the escalation workflow into a care team's actual routine, and standing up HIPAA-grade infrastructure is where the time goes. Supporting one or two device types is meaningfully faster than supporting a dozen, so scope tends to expand cost quickly.
On the return side, US providers and payers increasingly fund preventive and chronic-care programmes, and RPM has established reimbursement pathways — there are CPT codes specifically for remote monitoring setup, device supply, and monitoring time. We'd point you to current CMS guidance rather than quote specifics, because billing rules and code details change and vary by payer; treat reimbursement as a real but moving target to confirm with your billing team. The broader business case is preventive: catching a deteriorating trend early and intervening is both better care and cheaper than the emergency it might otherwise become. Whether that maths works for your programme depends on your population and payer mix — model it honestly rather than assuming.
Related guides
- Healthcare AI development: the full map
- HIPAA-compliant AI architecture
- Medical LLMs, RAG and human-in-the-loop
- From services to SaaS: building a healthcare AI product
- AI agents for healthcare: reducing admin burden
- Our AI development services
We Build Monitoring That Clinicians Actually Trust
Remote patient monitoring only works if the care team believes the alerts — which means the hard problems are the unglamorous ones: clean ingestion across messy devices, per-patient baselines, disciplined escalation, and a signal-to-noise ratio that keeps clinicians engaged rather than exhausted. We build these platforms HIPAA-aware from the first architecture decision, with the AI firmly in an assistive role that flags trends and escalates to a licensed clinician, never diagnosing or acting autonomously.
If you're planning an RPM programme — whether for a chronic-care population, a post-discharge cohort, or a payer-funded preventive initiative — we're happy to scope where the real effort and the real ROI sit for your specific setting.
Talk to us about your platform — no commitment, just a conversation.
Frequently Asked Questions
Does AI remote patient monitoring diagnose patients or predict events like heart attacks?
No, and it's important to be precise about this. A responsibly built RPM platform detects concerning trends in a patient's data and escalates them to a clinician for review. It does not diagnose, and it does not predict discrete events. The value is in surfacing a deteriorating pattern early — a blood-pressure trend creeping upward, heart-rate variability declining — so a licensed clinician looks at the right patient sooner and makes the clinical call. Framing it as "predicting heart attacks" both overclaims what the technology does and pushes it toward regulatory territory it's better designed to stay out of.
What devices can feed into an RPM platform?
Common sources include smartwatches and fitness trackers (Apple Watch, Fitbit), connected blood-pressure monitors, continuous glucose monitors, pulse oximeters, and connected scales. The practical constraint isn't which devices exist but how many you support, because each ecosystem has its own API, data format, and quirks that must be normalised into a consistent representation. Supporting one or two device types is far quicker than supporting a broad range, so device coverage is usually where scope and cost expand.
How does the platform avoid overwhelming clinicians with false alarms?
Through per-patient baselines and trend-based detection rather than fixed population thresholds, plus tunable sensitivity and a tiered escalation model. The goal is a high signal-to-noise ratio, because alert fatigue is the single biggest reason monitoring programmes get abandoned — a team that stops trusting the alerts will eventually ignore the one that mattered. Good platforms measure the false-alarm rate as a primary metric and deliberately tune toward fewer, higher-confidence escalations.
Is RPM data covered by HIPAA?
Yes. Continuous physiological data streamed from a patient's home is protected health information and must be handled with full HIPAA rigour: encryption in transit and at rest, access controls, audit logging, and signed Business Associate Agreements across the whole chain — including device platforms and cloud services. Device-sourced data also raises consent and data-ownership questions that need to be addressed explicitly.
Do we need FDA clearance to build an RPM platform?
It depends entirely on what the software does. A platform that surfaces trends for clinician review, keeping a human in every clinical decision, is generally a workflow tool rather than a regulated medical device. But a function that autonomously diagnoses or drives a treatment decision without a clinician in the loop may fall under the FDA's Software as a Medical Device (SaMD) framework and require separate clearance. The safe design keeps the AI assistive and human-reviewed, which is both better clinical practice and cleaner regulatorily. Confirm the specifics for your design during scoping.
Can RPM be reimbursed in the US?
Generally yes — there are established CPT codes for remote patient monitoring covering areas like device setup, supply, and monitoring time, and US providers and payers increasingly fund preventive and chronic-care programmes. However, billing rules, code details, and eligibility change over time and vary by payer, so we'd steer you to current CMS guidance and your billing team rather than quote specifics here. Treat reimbursement as a real but moving target, and model the business case honestly for your own population and payer mix.