Remote Patient Monitoring (RPM): Devices, Uses, and Billing

Remote patient monitoring (RPM) is the use of connected medical devices — blood pressure cuffs, glucose meters, pulse oximeters, scales, and others — to collect health data from patients at home and transmit it to a care team that reviews it between visits. Instead of assessing a chronic condition from a single blood pressure reading every three months, a clinician sees dozens of readings a month taken in the patient's real life, and can adjust treatment or intervene before a deterioration becomes an emergency. Medicare has reimbursed RPM under dedicated billing codes since 2019, and it has become one of the fastest-growing corners of telehealth — the modern descendant of the "tele-home health" nursing programs of the 1990s, which proved decades ago that regularly transmitting vital signs from home could substitute for some in-person nursing visits.

This article covers what RPM is, the devices involved, which conditions benefit most, how a program actually runs, the Medicare billing framework at a high level, and where the field is heading.

What RPM is — and what it isn't

RPM is a species of telehealth, but it differs fundamentally from a video visit. A video visit is an episode: it happens at a scheduled time and ends. RPM is a continuous service: data flows daily or near-daily, someone is responsible for watching it, and the "care" is the ongoing loop of measurement, review, and response. In the vocabulary of the field (see the telehealth glossary), RPM is a form of asynchronous or store-and-forward telehealth — the patient and clinician need not interact in real time for the data to do its work.

Three elements define a real RPM program, as opposed to a gadget:

1. A connected device that measures physiologic data — data generated by the body, such as blood pressure, glucose, weight, or oxygen saturation — and transmits it automatically rather than relying on the patient to write numbers down.
2. A monitoring function: a person or team (often nurses, sometimes supported by software) who reviews incoming data against thresholds and flags concerning trends.
3. A response pathway: defined actions when data crosses a line — a phone call, a medication adjustment, an expedited appointment, or an urgent escalation.

Remove any one of these and the value collapses. A cabinet full of unopened blood pressure cuffs is not a program; neither is a dashboard nobody checks.

For Medicare billing purposes, RPM devices must meet the FDA's definition of a medical device, and the data must be automatically collected and transmitted rather than self-reported — a line that separates clinical RPM from general-purpose wellness apps.

The devices

Two design details matter more than the sensor technology. The first is connectivity: the most effective programs for older and rural populations use cellular-enabled devices that transmit automatically over built-in mobile connections — no smartphone, no app pairing, no home broadband required. Bluetooth devices that must sync through a phone app introduce a failure point exactly where digital literacy and connectivity are weakest. The second is simplicity: adherence over months depends on the device being one-button easy, because the clinical value of RPM comes from sustained measurement, not from a sophisticated first week. Both are facets of the broader telehealth usability problem: the population that benefits most from monitoring overlaps heavily with the population most easily defeated by technology.

Consumer wearables occupy an ambiguous middle ground. They generate enormous amounts of data and some — notably watch-based ECG and irregular-rhythm features — have FDA clearance for specific functions, but general fitness tracking does not by itself constitute clinical RPM, and most reimbursed programs are built on dedicated medical devices.

Where RPM works best

RPM earns its keep in conditions with three properties: a measurable signal, a meaningful intervention when the signal moves, and enough event risk that catching deterioration early changes outcomes.

• Hypertension is the highest-volume use case. Home readings are more representative than office readings — they capture real life and sidestep "white coat" elevation — and a stream of home data lets clinicians titrate medications (adjust doses stepwise) in weeks rather than across quarterly visits. Hypertension programs are also operationally simple: one device, one number, well-established thresholds.
• Diabetes pairs naturally with glucometers and increasingly with continuous glucose monitors, supporting insulin adjustment and early identification of patients drifting out of control between A1c checks.
• Heart failure is the classic high-stakes case. Fluid retention — the mechanism behind most heart failure hospitalizations — announces itself as rapid weight gain days before symptoms become severe. A daily scale plus a nurse who calls when weight jumps is one of the oldest and most intuitively compelling monitoring models, often combined with blood pressure and symptom check-ins, and it connects RPM to the larger discipline of telecardiology.
• COPD programs watch oxygen saturation and symptoms to catch exacerbations early, when escalating inhalers or starting steroids at home can head off an admission.
• Post-discharge monitoring is the major short-term use case: 30 to 90 days of monitoring after a hospitalization for heart failure, pneumonia, COVID-19, or surgery, aimed squarely at the readmission window. This is RPM's most direct inheritance from 1990s tele-home health, which was built around exactly this population.

Weaker fits are conditions without a good home-measurable signal, patients unable to use even simple devices without in-home support, and clinical situations where no one would act on the data anyway. The honest screening question for any enrollment is: if this number changes, will we do something different? If not, monitoring is theater.

How an RPM program works operationally

The device is the visible part; the program is the work. A functioning RPM operation has five stages:

1. Identification and enrollment

Programs define eligibility criteria — diagnosis, recent hospitalization, uncontrolled readings, risk scores — and identify candidates from the EHR or at discharge. Enrollment includes obtaining and documenting patient consent (required for billing and good practice), explaining what will be monitored and what the patient should expect, and setting the care plan: which measurements, how often, and what thresholds will trigger contact.

2. Device logistics

Someone must supply, configure, ship or hand over, and explain the device — and later retrieve, refurbish, or replace it. Practices handle this in-house or through RPM vendors that manage fulfillment and technical support. Onboarding is the make-or-break moment for adherence: a patient who takes a successful first reading during setup, with a person on the phone or in the room, is far more likely to still be measuring in month four.

3. Monitoring

Incoming data lands on a dashboard reviewed by monitoring staff — typically nurses or medical assistants working under physician oversight, in-house or at a vendor's monitoring center. Review is usually daily on business days, exception-based: software sorts readings against patient-specific thresholds so humans concentrate on the outliers. Missed transmissions matter as much as abnormal ones; a patient who stops measuring may be hospitalized, discouraged, or dealing with a dead battery, and outreach for non-adherence is part of the job.

4. Escalation and intervention

Every program needs a written escalation ladder: which readings prompt a same-day nurse call, which go to the clinician for a medication change, which trigger "go to the emergency department." Interventions are documented in the EHR so monitoring stays integrated with the rest of the patient's care rather than running as a parallel universe. This is also where RPM generates its billable clinician time — treatment management based on the data, including interactive communication with the patient.

5. Review and graduation

RPM should not be a life sentence by default. Programs periodically reassess: blood pressure controlled for three months may mean graduation or reduced frequency; persistent non-adherence may mean the modality is not working for this patient. Post-discharge programs have natural end dates. Disciplined graduation keeps monitoring capacity pointed at patients who currently benefit.

Standing up this machinery — staffing, workflows, vendor selection, EHR integration — is a program-design exercise of the kind covered in how to start a telemedicine program, and the data pipeline itself must meet the security expectations described in telehealth security and HIPAA.

The Medicare billing framework, at a high level

Medicare pays for RPM through a small family of CPT codes (CPT is the AMA-maintained procedural coding system), each covering a different component of the service. Described functionally and without dollar figures:

Several structural rules shape program design as of early 2026, though practices should verify current requirements with CMS because the details are periodically revised:

• The 16-day concept. The device-supply code has historically required device readings on at least 16 days out of a 30-day period — a threshold meant to ensure the code pays for genuine monitoring rather than a device sitting in a drawer. This requirement (temporarily relaxed during the COVID-19 public health emergency, and a recurring subject of CMS rulemaking, including proposals for codes covering shorter monitoring durations) is the single most important operational number in RPM: programs live or die on keeping patients measuring most days of the month.
• Time must be real and documented. The management codes pay for actual clinical time spent reviewing data, adjusting treatment, and communicating with the patient, with documentation to match.
• Established relationship and medical necessity. RPM is billed for patients under an established plan of care for an acute or chronic condition, ordered by a physician or other qualified practitioner; general wellness tracking is not a covered service.
• One biller per patient per period. Only one practitioner can bill the RPM codes for a patient in a given period, which forces coordination when multiple specialists might monitor the same person.

State Medicaid programs and commercial payers cover RPM with their own, varying rules — the Center for Connected Health Policy tracks state policies — and the reimbursement landscape overall is covered in our guide to telehealth reimbursement.

RTM: the sibling category

Remote therapeutic monitoring (RTM), added to the CPT code set after RPM, mirrors its structure — setup, device supply, and treatment management codes — but covers non-physiologic data: therapy adherence and response, such as medication-taking, respiratory exercise use, or home physical therapy progress, often collected through an app or connected device and permissibly self-reported. Its practical significance is twofold: it extends monitoring beyond vital signs into the "did the patient do the therapy" dimension of care, and its billing rules open remote monitoring to practitioners — physical and occupational therapists prominently among them — who cannot bill the RPM codes. Musculoskeletal rehabilitation, respiratory therapy, and behavioral health adherence are the flagship RTM use cases.

RPM and hospital-at-home

Hospital-at-home programs deliver inpatient-level acute care in the patient's residence — daily clinician contact, IV therapies, oxygen — and continuous or near-continuous remote monitoring is their technological backbone. In the U.S., these programs expanded under a CMS waiver (Acute Hospital Care at Home) launched during the pandemic; the waiver's continuation has depended on congressional extension, so its current status — like much post-pandemic telehealth policy — should be verified with CMS rather than assumed. Conceptually, hospital-at-home sits at the intense end of a continuum on which chronic-disease RPM is the ambulatory end: the same architecture of home devices, transmitted data, thresholds, and escalation, scaled up in acuity, staffing, and response speed. Programs at the highest acuity blur into emergency response models, and at the end-of-life end of the spectrum, similar home-monitoring logic supports telehospice care.

Evidence and limitations

The published literature on RPM, much of it indexed in PubMed Central, supports measured optimism rather than triumphalism:

• Hypertension has the most consistent results: home blood pressure monitoring paired with active management — a team that titrates medication in response to readings — has repeatedly been shown to improve blood pressure control versus usual care. Monitoring alone, without the management loop, does much less.
• Heart failure results are genuinely mixed: some trials and programs have shown reduced hospitalizations, while other rigorous trials have found no benefit. The pattern across the literature suggests that program design — who watches, how fast they respond, whether the patient is at high enough risk to have events worth preventing — matters more than the devices.
• Diabetes monitoring supports better glycemic control when tied to active medication management and coaching.
• Post-discharge programs have shown reduced readmissions in some settings, with results again dependent on execution.

The recurring lesson is that RPM is an intervention delivered through devices, not by devices. Its limitations follow directly: it adds cost and staff workload that must be justified by outcomes; adherence decays over time without human attention; and it can widen disparities if programs are only workable for patients with smartphones, broadband, and confidence with technology — which is why device connectivity choices are an equity decision, not a technical one. Selection bias also flatters the field: patients who successfully sustain monitoring differ from those who don't, so glowing observational results deserve the skepticism that applies across telemedicine cost-effectiveness research generally.

Data overload and alert fatigue

RPM's defining operational hazard is drowning in its own data. A panel of 500 monitored patients taking daily readings generates thousands of data points a week; if even a few percent cross naive thresholds, the monitoring team faces a wall of alerts, most of them clinically meaningless. The predictable result is alert fatigue — the well-documented phenomenon in which clinicians exposed to high volumes of low-value alarms begin to tune them all out, including the ones that matter.

Mature programs engineer against this deliberately:

• Patient-specific thresholds instead of one-size-fits-all cutoffs — a reading alarming for one patient is baseline for another.
• Trend- and persistence-based rules (rising over days, multiple consecutive out-of-range readings) rather than firing on every stray value.
• Alert tiering, so a critical value interrupts someone now while a mild drift lands in tomorrow's worklist.
• Regular alert audits: reviewing what fraction of alerts led to any action, and retuning rules when the answer is "almost none."
• Sized monitoring staff, because no threshold design compensates for a panel too large for the team watching it.

The goal is a monitoring signal that stays meaningful — a system in which an alert still reliably means "look at this now."

What's next: AI triage and smarter monitoring

The volume problem is also the opening for RPM's most plausible next phase: artificial intelligence as the first-pass reader of monitoring data. Instead of static thresholds, machine learning models can learn each patient's baseline and flag deviations from their normal; combine multiple streams (weight plus blood pressure plus heart rate plus adherence) into a single deterioration risk estimate; predict which patients are trending toward trouble days ahead rather than alarming at the moment of crossing a line; and rank a monitoring team's worklist so human attention lands on the highest-risk patients first. Some of this is already deployed — notably algorithmic detection in cardiac rhythm monitoring, an area with a growing inventory of FDA-cleared software — and much more is in development.

The near-term reality is best described as promising and unevenly validated. Software that analyzes medical data to guide care can constitute a regulated medical device requiring FDA clearance, model performance can drift or fail across populations, and an algorithm that quietly buries a sick patient at the bottom of a worklist is a new kind of safety risk that programs will need to govern. The sober expectation is not autonomous monitoring but a rebalanced division of labor: software reads everything, humans decide, and the scarce resource — clinical attention — gets spent where models suggest it matters most. Combined with cheaper cellular devices and monitoring codes that continue to evolve, that division of labor is how RPM grows from a chronic-disease niche into standard infrastructure for care between visits.