For most of the past decade, the remote monitoring market was stuck in a particular kind of purgatory. The technology worked. The clinical evidence was accumulating. Health systems were interested. And then the reimbursement question came up, and the room went quiet. Most remote monitoring programs were running on grant funding, risk contracts, or hospital goodwill — not on a durable, scalable revenue model. That started changing in 2019, and by 2022-2023, the pieces were in place for something that looks like a real market.
The change came from CMS. A series of CPT code updates and Physician Fee Schedule changes created a reimbursement framework for Remote Physiologic Monitoring (RPM) that, when properly implemented, generates meaningful per-patient revenue. It's not easy to access — the documentation requirements are real and the billing complexity is non-trivial — but for the first time, there's a fee-for-service pathway that doesn't require a special contract with a progressive payor.
The core RPM code set
Four CPT codes form the backbone of RPM billing under Medicare:
| CPT Code | What It Covers | 2024 Medicare Rate (approx.) |
|---|---|---|
| 99453 | Initial setup and patient education (one-time) | ~$19 |
| 99454 | Device supply and daily transmission (per 30-day period) | ~$64 |
| 99457 | First 20 minutes of treatment management per month | ~$51 |
| 99458 | Each additional 20 minutes of treatment management per month | ~$41 |
At full billing — 99453 (once), 99454, 99457, and 99458 combined — a single patient generates roughly $156/month in Medicare reimbursement in addition to the setup fee. Across a patient population of 1,000 enrolled patients, that's approximately $1.9M annually before any commercial payor contribution. These aren't huge numbers per patient, but they're real, recurring, and scalable in a way that grant funding isn't.
The documentation requirement problem
The codes exist. Billing them correctly is another matter entirely. The RPM codes require documented evidence of: the device being supplied to the patient, data transmission occurring on at least 16 days per 30-day period (for 99454), and clinical staff time being spent reviewing data and managing treatment (for 99457/99458). That last requirement — documented staff time — is where most practices and health systems fall down.
Documenting 20 minutes of clinical time in a compliant way requires a system that tracks time against specific patients during monitoring review activities. Most EHRs don't do this natively in a way that generates clean CPT documentation. Most remote monitoring platforms don't either, at least not out of the box. The companies in our portfolio that have cracked the billing side have either built the documentation workflow directly into their software or have a revenue cycle operations team that handles it as a service alongside the technology.
This creates a meaningful competitive advantage. RPM billing compliance is actually a barrier to entry that looks administrative but is operationally hard. The companies that have solved it — that can credibly say "we handle end-to-end RPM billing on behalf of the practice and your net revenue per enrolled patient is $X" — are selling a complete solution, not just a monitoring device. That's a very different sales conversation.
Who can bill: the supervision rules
One thing that often gets lost in early-stage digital health pitches: RPM billing requires a physician (or qualified non-physician practitioner) to supervise the monitoring. The clinical staff performing the 20-minute review for 99457/99458 must be operating under the supervision of a physician. This means the billing entity needs to be a physician practice or health system, not the technology company directly.
This has significant implications for go-to-market. Remote monitoring companies that sell directly to patients and try to bill Medicare themselves face serious compliance and legal challenges. The sustainable model is selling to or partnering with physician practices and health systems, who then bill for the monitoring services and pay a platform fee or share revenue with the technology company.
We've seen several interesting models emerge: practice-embedded RPM programs where the health system bills and pays a per-patient platform fee; independent RPM companies that employ their own clinical staff and operate as the billing entity (typically requiring a physician group structure); and payor-sponsored programs where a Medicare Advantage plan funds the monitoring outside the fee-for-service framework. All three work in different contexts.
What this means for the market now
The RPM billing framework is established enough that it's no longer a "this is coming" story. There are companies generating $20M+ ARR on RPM billing-enabled revenue models today. The market validation is there.
What's still uncertain is the long-term rate trend. CMS has reduced RPM rates in some fee schedule cycles, and the value-based care shift creates pressure toward bundled payments that could reduce the fee-for-service RPM revenue opportunity over time. Companies building entirely on fee-for-service RPM billing without a clear path to value-based or risk contracts are building on a somewhat uncertain foundation.
The companies that look most durable to us are the ones that are using RPM billing as the initial revenue model to establish clinical data and relationships, with a clear roadmap toward payor partnerships and outcomes-based contracting as the primary revenue model. That's the transition we're investing in — the companies positioned to ride the RPM wave now while building toward the higher-margin, higher-durability model on the other side.
