Remote Patient Monitoring App Development: What to Build and What It Costs in 2026

A hypertensive patient seen every three months produces four blood pressure readings a year. The same patient on a connected cuff produces around a thousand. That gap is the entire case for remote patient monitoring, and it is why RPM has moved from pilot projects to line items in health system budgets.

The CDC reports that six in ten US adults live with a chronic condition and four in ten have two or more. That is the addressable population, and it is not shrinking.

But most guides to remote patient monitoring app development spend their length on Bluetooth pairing and dashboard design, then stop. They skip the part that decides whether the product makes money: the reimbursement rules. In January 2026 those rules changed, and the change rewrites the specification.

What an RPM platform actually contains

Strip away the marketing and every production RPM system has the same five layers.

Teams new to this space almost always start at layer one, because device integration feels like the hard technical problem. It is a solved one. Cellular-enabled cuffs, glucometers, scales and pulse oximeters mostly ship with documented APIs.

Layer four is where projects actually fail. The clinical layer has to log time, track engagement thresholds and produce an audit trail. Get it wrong and the platform works perfectly while generating nothing your customer can bill.

The 2026 billing codes changed the product spec

CMS finalised two new RPM codes in the 2026 Medicare Physician Fee Schedule, and they matter more than a rate table update.

Before 2026, RPM had hard floors. A patient who transmitted readings on ten days instead of sixteen triggered nothing. A nurse who spent seventeen minutes on a patient instead of twenty billed nothing. That work was real, and it was free.

CPT 99445 now covers device supply for two to fifteen days of data, paid at the same rate as the sixteen-day code. CPT 99470 covers ten to nineteen minutes of management time. Neither replaces the existing codes; both sit alongside them.

That is the commercial story. The patient who half-engages went from worthless to roughly $78 a month. For a programme with a thousand patients and a realistic level of partial engagement, that is meaningful recurring revenue that did not exist last year.

Every billing threshold is a feature requirement

This is the part that separates teams who have built RPM before from teams learning on your budget.

Look at the day-counting rule. The code requires a number of unique days on which data was transmitted. If your data model counts readings, a patient who takes three readings on Monday looks like three days of compliance. Every claim built on that number is wrong, and you will not find out until a payer audit.

Time tracking has the same trap. The management codes require at least one real-time interactive communication with the patient or caregiver in the calendar month. If a nurse phones a patient and the system does not capture that the call happened, who made it and when, the time is unbillable regardless of whether the care was delivered.

Then there is the calendar boundary. Device supply codes work on a rolling 30-day period. Management time codes work on the calendar month. Those are different windows, and a platform that applies one rule to both will misfile claims consistently.

Compliance: what actually applies to you

Healthcare compliance is often presented as one undifferentiated wall. It is not. Different rules attach to different products.

The FDA line is the one that causes the most expensive surprises. A dashboard that shows a clinician a blood pressure trend is generally not a regulated device. A model that flags deterioration risk and recommends an intervention often is. That distinction changes timeline and budget substantially, so settle it before you write code, not after.

What RPM app development costs

Cost tracks the number of systems you touch far more than the number of screens you design.

A few things worth pulling out of that breakdown.

• Device integrations scale linearly. Three device types is a reasonable starting point. Each additional one is real work, not configuration.
• EHR write-back is the longest pole. Technical effort is moderate; getting through Epic or Cerner's integration process is what consumes the calendar.
• The billing engine costs more than people expect. Around $22k in this example, and it is the component that makes the rest of the product commercially viable.
• An FDA-regulated build sits well above this. If you are in SaMD territory, treat the figure above as a floor and plan for regulatory work on top.

Timelines run roughly four to six months for a single-condition pilot, and eight to fourteen months for a multi-condition platform with EHR integration.

Cellular or Bluetooth? The choice affects your revenue

This looks like a hardware procurement decision. It is really a billing decision, and it is worth deciding early.

Bluetooth devices pair to the patient's phone and sync through your app. They cost less per unit and give you a richer app experience, because the patient opens the app to see their own data. The problem is that every reading depends on the patient having the app installed, logged in, and open near the device with Bluetooth switched on.

Cellular devices transmit directly over a built-in modem. No phone, no pairing, no app. The patient takes a reading and it arrives. Unit and data costs are higher, and you lose the app-based engagement loop.

Now connect that to the code set. Device supply reimbursement depends on the number of unique days a patient transmits data. Cellular hardware removes most of the failure points between the reading and your server, which directly protects the metric your revenue depends on. For elderly or less tech-confident populations, the higher unit cost is usually recovered through better transmission-day compliance.

The practical answer for most programmes is a mix: cellular for the primary vital being monitored, Bluetooth or manual entry for secondary data. Whichever you choose, build the ingestion layer so it accepts both from the start. Swapping a device vendor after launch is common, and a platform hardwired to one connectivity model turns that into a rebuild.

Where RPM builds go wrong

• Building the billing engine last. It is treated as back-office plumbing and scheduled after launch. It is the revenue engine and belongs in the first release.
• Designing for the engaged patient. Real adherence is patchy. The 2026 codes exist precisely because partial engagement is normal, so design for it rather than treating it as failure.
• Alert fatigue. A dashboard that flags everything gets ignored within a fortnight. Thresholds need clinical input, not sensible-looking defaults.
• Treating HIPAA as a hosting checkbox. A compliant cloud provider is a starting point, not compliance. Access controls, audit logs and BAAs are your responsibility.
• Ignoring the patient's phone. Your users skew older. Large text, minimal steps, and a path that works when someone forgets their password are product requirements, not polish.

Building an RPM platform with Duple IT Solutions

Duple IT Solutions builds custom healthcare software for clients across the US, UK, Canada and Australia, covering mobile apps, API and EHR integration, and HIPAA-aligned cloud infrastructure.

For RPM specifically, we start with the reimbursement model rather than the feature list. Which codes you intend to bill determines what the software must count, log and prove, and that determines the architecture. Doing it in the other order is how teams end up rebuilding the data model a year in.

Talk to us about your RPM build →

Frequently Asked Questions