A remote patient monitoring program lives or dies on one thing: whether someone actually reviews the data every day. The U.S. remote patient monitoring market is on track to reach $17.2 billion in 2026, according to Coherent Market Insights.
Most of that growth is going into vital sign devices and real-time alerting rather than one-off pilots.
Before a health system signs a vendor contract or opens a development budget, the harder question is whether remote patient monitoring software should be bought off the shelf or built to match how the practice actually works.
Both routes can bill the same Medicare codes. They ask for very different things upfront.
What remote patient monitoring software actually has to do
Strip away the marketing and the job is narrow. The platform has to pull readings from connected devices, compare them against thresholds a clinician set, flag anything out of range, and log the minutes staff spend reviewing the data.
That log is what turns into a claim.
- Ingest data from connected blood pressure cuffs, glucose meters, pulse oximeters, and scales
- Apply per-patient or per-condition thresholds and surface the readings that need a human look
- Track and timestamp clinical review time for billing
- Get the results somewhere the care team already looks, rather than a separate login nobody opens
Miss any one of those and the program stalls, no matter how polished the dashboard looks.
Why health systems are racing to launch these programs now
Coherent Market Insights' analysis of the U.S. market puts remote patient monitoring at $17.2 billion in 2026, growing to $49.5 billion by 2033.
Devices make up the largest single share of that spend. Real-time monitoring, rather than periodic check-ins, now leads the market too, because it lets a care team act on a bad reading the same day instead of waiting for the next visit.
Two demand drivers sit underneath the growth. The same report counts 78 to 80 million Americans aged 65 and older by 2040. It also notes that three in four American adults already live with at least one chronic condition.
Neither trend reverses on its own. That's part of why home healthcare is the fastest-growing setting in the same report: patients would rather be monitored at home than make repeat trips to a clinic.
How Medicare reimbursement shapes the build-vs-buy math
Reimbursement is what makes RPM software worth building or buying in the first place. Coherent Market Insights names CMS billing codes 99453, 99454, and 99457, covering setup, device supply, and monthly treatment management, as a direct driver of provider adoption. They create recurring revenue rather than a one-time grant.
That revenue got easier to earn this year. Starting January 1, 2026, CMS lowered the bar for both halves of RPM billing, according to an analysis from law firm McDonald Hopkins.
Providers can now bill after collecting data for just 2 to 15 days in a 30-day period, instead of the old 16-day minimum. The monthly treatment management requirement dropped too, to less than half its old minimum.
The changes trace back to CPT codes the American Medical Association's editorial panel approved in September 2024. CMS still requires that the monitoring be medically necessary, not just technically billable.
A vendor platform typically has this billing logic built in and updated on the vendor's schedule. Building it yourself means watching the CPT codebook every year and updating the time-tracking rules before the next fee schedule takes effect.
When buying an established platform is the smarter move
Buying wins when the workflow you need is common. If patients on the program are mostly on standard vital sign monitoring with standard thresholds, a vendor has already built that, tested it against CMS's billing rules, and can get a cohort live in weeks rather than months.
Buying also moves the compliance burden. When a code changes or a device manufacturer updates its firmware, that's the vendor's problem to solve, not something your own engineering team has to catch.
The tradeoff is fit. You're working inside whatever thresholds, integrations, and reporting the vendor decided to support, and asking for something outside that scope usually means waiting for their roadmap.
When building your own is worth the investment
Photo by DΛVΞ GΛRCIΛ on Pexels
Building makes sense once the program outgrows what a generic platform does well: alerting rules tied to a specific discharge protocol, thresholds that vary by condition in ways a vendor's configuration screen doesn't support, or a need to write RPM data straight into fields your own systems already use.
At that point, a vendor platform stops saving time and starts working against the program. Faster response to a flagged reading is often the whole point, and our case study on what response times actually show looks at that tradeoff in more detail.
We've built patient-facing healthcare software end to end before. When we built OptimalMD's digital product, we designed and built the website, the members portal, and the mobile app from the ground up, through to launch.
That's the kind of ownership a custom RPM build asks for. Every screen, every data rule, and every integration is yours to shape rather than configure around, which is the same reasoning behind our apps and SaaS work more broadly.
The commitment is real. A custom build means owning the FHIR or HL7 mapping into your EHR, the device integrations, the alert logic, and the billing time log, indefinitely, not just at launch.
If your development partner disappears after go-live, that ongoing ownership becomes a staffing problem fast.
What FDA and HIPAA require either way
Neither path gets you out of federal rules. Most of the physical devices feeding an RPM program, blood pressure cuffs, glucose meters, scales, and pulse oximeters, fall into the FDA's Class II category, according to Tenovi's breakdown of FDA device classes.
Class II requires a 510(k) submission proving the device is substantially equivalent to one already cleared.
| FDA class | Share of medical devices | What's required | RPM relevance |
|---|---|---|---|
| Class II | 43% | 510(k) clearance, showing equivalence to a cleared device | Where most RPM devices sit: BP cuffs, glucose meters, scales, pulse oximeters |
| Class III | 10% | Full premarket approval with clinical study data | Life-sustaining implants like pacemakers, not typical RPM hardware |
Patient vitals moving through the software are protected health information under HIPAA regardless of who built the platform.
Buying a vendor's software doesn't transfer that obligation away from the practice, and building your own doesn't add a new one. Either way, the encryption, access controls, and audit logging have to hold up.
Frequently asked questions
What happens if a patient doesn't hit a full month of monitoring days?
Under the CMS rule that took effect January 1, 2026, that no longer means zero reimbursement, since providers can now bill under a lower tier covering 2 to 15 days of data in a 30-day period instead of needing the previous 16-day minimum.
Can patients use devices they already own?
Usually not without checking first. Most vendor platforms and payer rules work from an approved device list so the data source stays verifiable for billing, so confirm supported hardware before assuming a patient's own scale or cuff will connect.
Do RPM devices need FDA clearance separately from the software?
The devices generally do. Most fall into the FDA's Class II category and need 510(k) clearance, whether the software collecting their data was bought or built in-house.
Does a custom-built platform have to follow the same Medicare billing rules as a vendor platform?
Yes. CMS sets the CPT codes and thresholds regardless of who wrote the software. Building your own just means your team, not a vendor's, is responsible for keeping the time-logging and threshold logic current whenever CMS revises the codebook.
Cover photo by Gustavo Fring on Pexels
