Remote Patient Monitoring: An Educational Overview

What remote patient monitoring is

CMS says remote patient monitoring allows a person to collect their own health data using a connected medical device that automatically transmits the data to the provider 1. CMS breaks the service into three practical components:

Quick answer: what is remote patient monitoring? Remote patient monitoring, or RPM, is the use of connected medical devices to collect physiologic data such as blood pressure, weight, glucose, SpO2, or heart rate outside the clinic and transmit it to a care team for review and management.

Authoritative sources

• CMS care management services
• AMA RPM CPT overview
• FDA digital health center

1. Education and setup
2. Device supply and data transmission
3. Treatment and management

That structure is useful because it mirrors how real programs operate. Someone has to onboard the person. A device has to capture and transmit data. A clinician has to review the data and use it to manage care.

What counts as RPM data

RPM is for physiologic data. Think blood pressure, weight, pulse oximetry, glucose, or similar vital-sign style measurements.

That physiologic requirement is why RPM is often a fit for conditions such as:

• hypertension,
• heart failure,
• diabetes,
• COPD and other respiratory conditions,
• post-acute recovery when physiologic trending matters.

The data cannot just be manually typed into a portal. CMS says the person must use an internet-connected device that meets the FDA definition of a medical device and digitally uploads data 1.

That is the line many teams miss when they try to label every remote care workflow as RPM.

Who is eligible for RPM under Medicare

CMS states that Medicare broadly covers RPM for chronic and acute conditions, which is an important update from older industry explanations that treated RPM as chronic-care only 1. To qualify, the person must:

• have a chronic or acute condition that requires monitoring,
• use an internet-connected device,
• and that device must meet the FDA definition of a medical device and digitally upload data 1.

Common RPM devices

The most common device categories are straightforward:

• connected blood pressure cuffs,
• digital weight scales,
• glucometers and CGM-related physiologic tools,
• pulse oximeters,
• other connected physiologic monitors.

CMS uses blood pressure cuffs, weight scales, and pulse oximeters as examples on its own RPM page 1.

How RPM works in real care delivery

A functioning RPM program usually looks like this:

1. Selecting people for monitoring

Identify people with a real monitoring need, not just people who are easy to enroll.

2. Consent and onboarding

Document consent, educate the person, and make sure the device is configured correctly.

3. Device deployment

Ship or hand off the connected device, then verify the person can actually transmit readings.

4. Data review workflow

Create thresholds, alert rules, staffing coverage, and escalation pathways.

5. Treatment management

Use the data to make decisions. If no one is going to act on the information, the program will quickly turn into a data landfill.

CMS’s example is hypertension management: the person uses a connected cuff, readings transmit automatically, and the provider reviews the data and adjusts treatment if needed 1. That is still the cleanest mental model.

The most important RPM compliance rule: qualifying device requirements

This is where many commercial claims break apart.

CMS says the person must use a connected device that:

• meets the FDA definition of a medical device, and
• digitally uploads data 1.

That means an RPM program is not just a dashboard with symptom check-ins, chatbot messages, or manually entered numbers. Those tools can still be useful, but by themselves they do not turn a workflow into Medicare RPM.

What RPM is not

RPM is not the same thing as telehealth visits, secure messaging, care management, or an app with self-reported check-ins. Those services can sit around an RPM program and make it more effective, but CMS’s RPM definition is anchored to physiologic data from a qualifying connected device 1.

A workflow that mainly captures symptoms, therapy adherence, or treatment response should not be called RPM without checking the applicable program requirements.

RPM vs. RTM: different monitoring frameworks

This is the fork in the road.

RPM is built around physiologic data from FDA-defined connected devices. RTM, by contrast, is designed around treatment-response and therapy-related monitoring workflows, and CMS has continued expanding its RTM treatment and therapy framework in recent rulemaking 23.

If your program revolves around:

• medication or therapy adherence,
• symptom-response tracking,
• rehabilitation or musculoskeletal workflows,
• respiratory therapy engagement,
• software-guided treatment response,

then you should not assume the workflow qualifies for RPM. RTM has its own requirements; failing to meet RPM’s device requirements does not establish RTM eligibility.

Program design mistakes that sink RPM initiatives

Mistake 1: starting with hardware instead of care pathways

A box of connected devices is not a care model.

Mistake 2: enrolling people who do not need active monitoring

Low-acuity enrollment can make dashboards look busy while generating almost no clinically meaningful interventions.

Mistake 3: treating alerts as clinical management

An alert is not an intervention. Someone still has to review, interpret, and act.

Mistake 4: confusing remote monitoring with remote messaging

Symptom surveys and engagement tools matter, but they do not automatically satisfy RPM rules.

Where RPM works best

RPM is strongest when there is a measurable physiologic signal that can change treatment decisions on a meaningful timeline.

Examples include:

• titrating antihypertensives from home blood pressure trends,
• monitoring weight and symptoms in heart failure pathways,
• following pulse oximetry or respiratory status in selected pulmonary populations,
• supporting post-discharge monitoring where deteriorating physiology needs quick detection.

The literature on wearable and remote sensing also shows why device validation matters. Knight et al. highlighted inconsistent accuracy reporting and a shortage of large real-world validation studies of wearable PPG sensors 4. That should make buyers more disciplined, not less.

What administrators and product teams should ask vendors

Before signing an RPM contract, ask:

• Does the device meet the FDA definition of a medical device?
• Is data transmission automatic, or does it rely on the person entering readings manually?
• How is consistent device use supported and documented?
• Who reviews alerts and abnormal values?
• What is the documented clinical intervention workflow?
• Which outcomes improved in a population similar to ours?

If the answers are vague, the program is probably not mature.

The RPM metrics that actually matter

A serious RPM program should track more than enrollment volume. The metrics that matter are:

• activation rate after device delivery,
• percentage of people transmitting readings as required by the monitoring protocol,
• median time from abnormal reading to staff review,
• rate of treatment changes driven by monitored data,
• emergency department visits, readmissions, or escalation events in the monitored population,
• staff time per active person per month.

Those numbers tell you whether RPM is functioning as care delivery or just as device distribution.

References

1. Centers for Medicare & Medicaid Services. Remote Patient Monitoring. March 4, 2026 Source

2. Centers for Medicare & Medicaid Services. Calendar Year (CY) 2024 Medicare Physician Fee Schedule Final Rule. November 2, 2023 Source

3. Centers for Medicare & Medicaid Services. Therapy Services. Updated 2026, including RTM-related code list changes Source

4. Knight S, et al. The Accuracy of Wearable Photoplethysmography Sensors for Telehealth Monitoring: A Scoping Review. Telemed J E Health. 2023;29(6):813-828. PMID: 36288566 Source