Remote patient monitoring software is shaped by billing requirements more than by clinical ones, and building it without starting from the CPT codes produces a product that cannot be reimbursed. The codes govern specific, countable things: how many days of readings a device transmitted in a period, how many minutes of clinical staff time were spent reviewing and acting on that data, and whether an interactive communication with the patient took place. Each of those has to be captured as structured, auditable data rather than inferred later — device transmission days need timestamps tied to a specific patient and device, and clinical time needs to be logged as it happens, by whom, against what. Teams that design the clinical experience first and add billing capture afterwards routinely discover that the data needed to justify a claim was never recorded in a form an auditor would accept.
RPM Is a Reimbursement Program First
Remote patient monitoring is a reimbursement program first, and a generic “what is RPM” explainer misses that. Design the software around the billing codes from day one, not as an afterthought layered onto a clinically-designed product.
What the CPT Codes Actually Require
RPM billing codes are revised annually; this list reflects CMS’s CY 2026 final rule (CMS-1832-F, 90 FR 49266). CMS’s 2026 final rule covers these six RPM CPT codes, each with its own specific, countable requirement:
| Code | What it covers | What must be captured |
|---|---|---|
| 99453 | Initial device setup and patient education | Set-up and patient education on use of the equipment; CPT’s 2026 edits changed its requirements, so confirm them in the CPT codebook |
| 99454 | Device supply, 16-30 days of data in a 30-day period | Per-device transmission-day count, timestamped |
| 99445 (new for 2026) | Device supply, 2-15 days of data in a 30-day period | Same transmission-day tracking, lower threshold |
| 99457 | First 20 minutes of monthly management time | Real-time, two-way interactive communication, logged |
| 99458 | Additional 20-minute increments | Same interactive-communication logging |
| 99470 (new for 2026) | First 10 minutes of clinical management time | Time logged as it happens, by whom |
Two new codes for 2026 — 99445 and 99470 — expand the granularity CMS now reimburses at, which means software built against the older, coarser code set is already behind. Every one of these codes requires structured, timestamped, auditable data — not a number a biller reconstructs from memory or a loosely-kept spreadsheet at the end of the month.
CMS also says the device-supply codes are not additive: 99445 (2-15 days) and 99454 (16-30 days) are not a base and add-on pair, so a practitioner bills only one of them for the number of days of data transmitted in a 30-day period. The same holds for the first-10-minute code (99470) and the first-20-minute code (99457): they are not additive, and the practitioner chooses the code that fits the time spent that calendar month. Software needs to pick the right code from the captured data, not stack them.
Device Data Ingestion
Whether readings arrive via cellular, Bluetooth-to-phone relay, or manual patient entry, the software has to count transmission days accurately per device, per patient, because 99454 and 99445 hinge on exactly that count crossing a specific threshold. Gaps in transmission have real billing consequences — a patient who doesn’t take readings for the required number of days in a period means that period simply isn’t billable under those codes, and the software should surface that gap to staff before it becomes a denied or unbilled claim, not after.
Capturing Clinical Time
This is the most common build mistake, and it’s worth naming directly: clinical time for 99457, 99458 and 99470 has to be logged as it happens — who performed the review or communication, against which patient, for how long — not reconstructed at month-end from memory or a general activity log. Software that treats time capture as a nice-to-have reporting feature rather than a first-class, real-time data requirement produces exactly the kind of undocumented claim that fails an audit.
Patient Engagement and Interactive Communication
The requirement teams under-build: 99457, 99458 and 99470 require a live, interactive communication with the patient or caregiver — not an asynchronous message, not a portal notification the patient reads later. The software has to support and log a genuine live interaction (CMS notes the interactive communication counts toward the total time but does not have to make up all of it), and distinguishing that from a passive check-in is a real product requirement, not a minor detail.
Getting RPM Data Into the EHR
RPM readings and clinical notes need to reach the patient’s actual chart, not live in a separate silo — the same write-back governance question I cover in Epic write-back integration and the parallel-record risk I raise in telehealth EHR integration. RPM data that never reaches the chart creates the same clinical continuity problem a non-integrated telehealth platform does.
Where RPM Programs Fail
Honest treatment of the operational reality beyond the software itself: enrollment friction, adherence decay over time as patient engagement fades, and device logistics — getting hardware to patients, replacing failed units, managing returns — are where real RPM programs struggle, independent of how well the billing capture is built. Software can support these operational realities with good workflow design, but it can’t solve them outright.
Next Steps
If you’re building RPM software, start from the current CPT codes and their exact capture requirements, not from the clinical workflow alone — that sequencing is what actually determines whether the program gets reimbursed. Talk to our team if you’re scoping an RPM build or integrating monitoring data into an existing EHR.