What Is Remote Patient Monitoring (RPM)?
Remote patient monitoring lets a care team see how a patient is doing between visits, using data that comes straight from a connected medical device rather than a phone call or a handwritten log. Here's how it actually works, in plain language.
The short definition
Remote patient monitoring (RPM) is a clinical service built around one idea: instead of waiting for the next office visit to find out how a patient's blood pressure, weight, or glucose has been trending, the care team gets a steady stream of data from a device the patient uses at home. A nurse or clinician reviews that data, watches for patterns or red flags, and reaches out when something needs attention — often well before the next scheduled appointment.
RPM is formally recognized by the Centers for Medicare & Medicaid Services (CMS) and by many commercial payers as a billable clinical service, not just a convenience feature. That matters, because it means RPM has defined rules about what counts, who can order it, and what has to be documented — which is different from a practice informally asking a patient to "keep track of your numbers."
How the data actually flows
At a high level, an RPM program moves data through four stops:
- The device. The patient uses an FDA-cleared or FDA-registered monitoring device — a continuous glucose monitor (CGM), a connected blood pressure cuff, a smart scale, or a pulse oximeter, for example. The device captures a physiologic measurement automatically, without the patient having to type it in.
- Transmission. The device (often paired with a phone app or a built-in cellular connection) sends that reading to a secure cloud platform. This step is what separates RPM from a paper log — the data has to move electronically and automatically, not be phoned in or written down after the fact.
- Aggregation and review. A monitoring platform — like the kind Endobits builds for clinical teams — organizes the incoming data into trends, flags, and summaries so a clinician or trained staff member can review it efficiently instead of scanning raw numbers.
- Clinical action. Based on what the data shows, the care team may adjust a treatment plan, schedule a visit sooner than planned, or simply document that the patient is stable. That review and any resulting outreach is itself part of the billable service, not just the data collection.
The point of this pipeline is to catch meaningful change early — a glucose pattern drifting out of range, a blood pressure trend climbing over several weeks — while it's still something a care team can respond to proactively.
Who orders and enrolls a patient
RPM isn't something a patient signs up for on their own. A physician or other qualified healthcare provider has to order it as part of a documented plan of care, tied to a specific condition being monitored — for example, monitoring glucose patterns in a patient with type 2 diabetes, or tracking blood pressure in a patient with hypertension.
Once ordered, the patient goes through an enrollment step that typically includes:
- Explaining what the service involves and getting the patient's informed consent
- Setting up or confirming the connected device
- Establishing how often data needs to be transmitted for the service to qualify as active
Day-to-day tasks — reviewing incoming data, logging time spent, and reaching out to patients — are frequently carried out by clinical staff (such as a nurse or medical assistant) operating under the ordering provider's general supervision, rather than the physician personally reviewing every data point.
RPM vs. telehealth vs. a patient-reported log
These three get confused constantly, and the differences matter both clinically and for billing.
| Service | What it is | Data source |
|---|---|---|
| Telehealth | A live video or audio visit that stands in for an in-person appointment, at one point in time. | Whatever the patient reports during the call, plus any records already on file. |
| RPM | An ongoing service — not a single visit — where device data streams in continuously and staff review it between visits. | Device-generated, automatically transmitted readings. |
| Patient-reported log | A patient manually writing down or typing in their own numbers, with no device automatically capturing or transmitting the data. | Self-reported, not device-verified. |
A telehealth visit can happen with or without RPM in place. RPM can (and often does) run continuously in the background between telehealth or in-person visits — the two services are complementary, not competing. The key distinction with a patient-reported log is that RPM specifically requires device-generated data; a spreadsheet or paper diary the patient fills in by hand doesn't meet that bar, even if the numbers themselves are accurate.
Why RPM is reimbursable
CMS created specific billing codes for remote physiologic monitoring because the service represents real clinical work: supplying or supporting a monitoring device, setting up the connection, and — most significantly — the time clinical staff spend reviewing data and managing the patient's care based on it. Many commercial payers have adopted similar coverage, though the specifics (which codes, which time thresholds, which conditions qualify) vary by plan and change over time.
In general terms, reimbursement is built around a few components: getting the patient enrolled and set up on a qualifying device, ensuring a minimum amount of device data is transmitted in a given period, and clinical staff time spent reviewing that data and communicating with the patient. Because these are distinct, separately defined components, accurate documentation of each one is what makes a claim defensible — not just the fact that a device was handed to a patient.
This is also why RPM sits differently from telehealth in a payer's eyes: telehealth reimburses a discrete encounter, while RPM reimburses a monitoring service delivered over a defined time period, which is why the underlying data trail — device readings, timestamps, staff time logs — carries so much weight.
What a good RPM setup looks like in practice
For a monitoring program to run smoothly and hold up under review, it generally needs:
- A device appropriate to the condition being monitored, cleared or registered with the FDA for that use
- Reliable, mostly automatic data transmission so patients aren't relied upon to manually sync or upload
- A dashboard or platform that turns raw readings into something a clinician can act on quickly, rather than a wall of numbers
- A documented order, consent, and care plan tying the monitoring to a specific clinical purpose
- A workflow for staff to log their review and outreach time consistently
Endobits' role in this picture is the third item — organizing CGM and other device data into decision-support views that make ongoing review practical for a busy practice, rather than being an EHR, a billing system, or a substitute for clinical judgment.
See how RPM fits into a primary care workflow
Explore how Endobits helps primary care and internal medicine teams turn CGM data into an actionable RPM program.
For clinical GPsRelated: Remote patient monitoring: the complete guide · Billing CGM as RPM · All resources