What is remote patient monitoring?

Medicare pays for remote patient monitoring in three parts, and CMS names them in this order: education and setup, device supply, then treatment and management. A program that does the first two and neglects the third collects data nobody bills against. That is the common failure, and it is an operational failure rather than a clinical one.

Who qualifies

CMS states two conditions. The patient must have a chronic or acute condition that requires monitoring, and must use an internet-connected device that meets the FDA's definition of a medical device, uploads data digitally, and "collects and transmits health data at least 2 days every 30 days."

Note what is absent from that list. There is no minimum number of chronic conditions, unlike CCM's two. RPM covers acute conditions as well as chronic ones, so a post-surgical patient on a blood pressure cuff for six weeks is in scope. The patient consents before the program starts, and one practitioner bills per patient per 30-day period.

The 2-day rule and the 16-day rule are both real

This trips up more programs than any other detail, because the two numbers come from different places.

CMS's own RPM page sets the eligibility floor at 2 days of data every 30. The code descriptors then split the device-supply month in two: 99454 pays for 16 to 30 days of readings, and 99445, new for 2026, pays the same national amount for 2 to 15 days. Before 2026, a patient who transmitted 12 days simply produced no billable device month.

The data-day requirement does not reach the treatment-management codes. 99457 and 99458 pay for the practitioner's time and the interactive communication, not for the readings.

RPM or RTM: the question that decides your whole program

The distinction is the type of data, not the type of device, and getting it wrong invalidates the claim.

A sleep practice monitoring PAP adherence is running RTM, not RPM, because usage hours describe therapy adherence rather than a physiologic measurement. Practices bill this wrong often enough that it is worth stating plainly. The pair that carries a PAP programme is 98976 for the device month and 98980 for the review time, with 98984 covering the patient whose machine reported fewer than sixteen days.

RPM and RTM cannot both be billed for the same patient. Choose per patient, on the data you are actually acting on.

Full thresholds, frequencies and 2026 national payment amounts are on the CCM, PCM, APCM, RPM and RTM code guide.

What a month actually looks like

The billable month has a shape, and every element has to be evidenced rather than asserted.

1. Consent, once, with a date. Recorded before the first reading, along with the patient's cost share.
2. Device supplied and the patient taught to use it. 99453 pays once per episode of care, and it pays for the teaching as much as the shipping.
3. Readings arrive on their own. Patient-keyed numbers in a portal are not RPM. The device transmits.
4. Somebody watches the data. Out-of-range readings need a rule that routes them to a person on the same day, not at month end.
5. At least one real-time interactive communication. 99457 requires it. A text thread does not satisfy it.
6. Time logged as it is spent. Twenty minutes of practitioner or clinical staff time, recorded when it happens.

Where programs stall

The device stops transmitting and nobody notices until billing. A patient whose cuff went flat on the ninth of the month is discovered on the first of the next one. By then the month is gone, or it drops to the lower-paying 2-to-15-day code when someone could have called on day ten.

Data arrives that nobody reviews. Readings accumulate, no clinician touches them, and the practice bills a device month it can defend while skipping the management codes that carry most of the value.

The interactive communication gets missed. Everything else is in place and the month fails on one phone call.

Time is reconstructed at month end. An auditor asking for the evidence behind twenty minutes will not accept a number typed into a box in the last week of the month.

Nobody owns enrollment. RPM programs shrink quietly. Patients drop off, the roster is never refilled, and the program that justified the device contract is running at a third of the volume it was sized for.

What to ask a vendor

• Does the device transmit on its own, and what happens on the day it stops?
• Who watches out-of-range readings, and how fast?
• Is time logged as it is spent, or entered afterwards?
• Where does the monthly note land: in my chart as a note, or in your portal?
• Who submits the claim, and who holds the evidence behind it?
• If a patient reports 12 days rather than 16, does your system know to bill 99445?

Where Caesar Health fits

Caesar is not an RPM vendor and does not supply devices. It is a clinic operating system: agents that run the practice's operations on top of the EMR already in use.

For remote monitoring that means the agents take the logistics around the readings. Enrollment outreach through your consent pathways, the chase when a device goes quiet, the monthly check-in written back into the EMR, escalation on your tiers, drafts routed to your care team, and a billing gate that holds each patient until every element clears and a person sets Ready for Billing.

Being exact about the current state, because it matters more than the pitch: the outreach, consent capture, review queue, program state machine and billing gates are live. Device telemetry adapters for blood pressure, weight, glucose and PAP adherence are in build. Device logistics, meaning assign, ship and return, are on the roadmap and not built. RTM today runs on device-platform exports rather than direct connections.

An AI agent's minutes are not clinical staff time under Medicare's rules, and we say so on every page. The agent does the work that was never billable. Your staff spend their twenty minutes on the review and the conversation that need a clinician.

See chronic care management software for the component-by-component status.