Medicare paid $536 million for remote patient monitoring in 2024, up 31% on the year before, and nearly one million enrollees received it. In 2019 the same line came to $15 million. Those figures come from an August 2025 data snapshot by the HHS Office of Inspector General, and the snapshot reads like a list of audit targets. It flagged 45 practices that had never seen more than 80% of the patients they billed for, one of them with over 30,000 such patients. In another 52 practices, more than three in four enrollees never had a single month of treatment management billed. Read with remote patient monitoring app development in mind, each flagged pattern points to a check the software never made.
Growth like that pulls in two kinds of buyers: practices that want their own program and healthtech companies that want to sell one. Both usually start remote patient monitoring app development from the device and the dashboard, and the billing rules come last. That order gets expensive. Most of what separates a paid program from a clawback sits in the software: whether it counts transmission days correctly, logs who spent which minutes, and proves the patient was onboarded.
In remote patient monitoring app development, the Medicare billing rules are the product specification, and the screens come after. Our custom healthcare software development team has built these pieces before, and the patterns below come from that work.
Remote patient monitoring app development, defined
The term covers more than a mobile app. An RPM product is a small system with a device on one end, a clinician on the other and a billing record in between. Three groups of people use it, and each has its own reasons to stop.
What does a remote patient monitoring app do?
A remote patient monitoring app collects physiologic readings, such as blood pressure, weight, glucose or blood oxygen, from a connected device in the patient’s home and sends them to a care team automatically. Clinicians review the data, act on readings outside the patient’s targets, and document the time spent, which is what Medicare reimburses.
The word that matters most in that definition is automatically. According to the CMS telehealth and remote monitoring booklet, updated in December 2025, physiologic data must be collected electronically and uploaded automatically, and the device has to meet the FDA's definition of a medical device. A patient typing yesterday's reading into a form does not count, however good the interface is. Everything else in remote patient monitoring software is built around keeping that stream of readings flowing and turning it into care decisions a reviewer can trace.
The three user groups an RPM app serves
The three audiences pull the product in different directions.
- Patients want to take a reading and forget about it. Many are over 65, managing hypertension, heart failure or diabetes, and some have never paired a Bluetooth device. Every extra tap costs you readings.
- Clinical staff – nurses, medical assistants, care coordinators – live in the dashboard. They need a queue ordered by clinical urgency, the patient's history one click away, and a way to log a call without switching systems. A nurse covering 300 patients will judge the product in the first week.
- Practice administrators and billing teams see RPM as a monthly revenue line. They need to know on the 25th which patients will clear the thresholds by month end, and they need claims that match the documentation.
Most remote patient monitoring app development projects are built for the second group and tolerate the other two. That tends to show up as a well-designed dashboard with thin data in it, because patients stopped measuring, and a billing export someone rebuilds in a spreadsheet every month.
Remote patient monitoring against remote therapeutic monitoring
Remote therapeutic monitoring (RTM) is RPM's younger sibling, and the difference decides which codes a product can bill. RPM tracks physiology. RTM tracks how a patient responds to therapy: medication adherence, pain scores, range of motion, breathing exercises.
| Remote patient monitoring (RPM) | Remote therapeutic monitoring (RTM) | |
|---|---|---|
| Data type | Physiologic: blood pressure, weight, glucose, SpO2, heart rate | Non-physiologic: adherence, pain, function, therapy response |
| Collection | Transmitted automatically by the device | Device-based, self-reported data allowed |
| Condition areas | Any acute or chronic condition | Respiratory, musculoskeletal, cognitive behavioral therapy |
| Established patient relationship | Required before billing | Not required |
| Typical billers | Physicians and other practitioners, with clinical staff under general supervision | The same; several codes can also be billed by physical and occupational therapists |
| Device supply codes, 2026 | 99445 (2–15 days), 99454 (16–30 days) | 98984, 98985, 98986 (2–15 days); 98976, 98977, 98978 (16–30 days) |
| Management codes, 2026 | 99470 (first 10 min), 99457 (first 20 min), +99458 | 98979 (first 10 min), 98980 (first 20 min), +98981 |
A patient can receive RPM or RTM in a given month, never both, so a product that supports both needs a rule preventing the overlap. Worth deciding early: if your buyers include physiotherapy groups, RTM support widens the market considerably for a modest amount of extra work.
Remote patient monitoring app architecture
A remote patient monitoring platform looks simple on a whiteboard and gets complicated in production, mostly at the joins. Readings arrive late, twice, or in the wrong unit, devices get swapped between patients, and the EHR accepts some data and quietly drops the rest.
Five layers from device to dashboard
Every remote patient monitoring app development project we have seen, whatever its stack, ends up with five layers.
- The device - a blood pressure cuff, scale, glucometer or pulse oximeter, each with its own firmware, transmission protocol and quirks. Some store readings offline and send them in bulk.
- The gateway - either the patient's phone running your app over Bluetooth Low Energy, or a cellular modem built into the device or a hub that bypasses the phone entirely.
- Ingestion and normalization - the backend receives readings from your app or from a device vendor's cloud, de-duplicates them, converts units, attaches a trustworthy timestamp and maps the device serial number to the right patient. This is where most data quality problems are either caught or born.
- Clinical logic - per-patient thresholds, alert generation, transmission day counters, time logs and the rules that decide which codes a month supports.
- Clinician and billing outputs - the triage dashboard, the patient record, EHR write-back and the monthly claim file.
Layers three and four are where most of the budget in remote patient monitoring app development goes, and where most guides spend the least time. A reading that lands under the wrong patient because a device changed hands is a clinical risk, and it is also a billing error.
Bluetooth devices against cellular devices
The gateway choice shapes the patient experience, your support load and your integration work more than any other decision in the architecture.
| Bluetooth (BLE) via the patient's phone | Cellular, built-in modem or hub | |
|---|---|---|
| Patient setup | Install the app, pair the device, keep the phone nearby | Take it out of the box and use it |
| Patient requirements | A compatible smartphone and some confidence with it | None beyond mobile coverage at home |
| Hardware cost | Lower per device | Higher per device, plus a monthly data plan |
| Reliability of delivery | Depends on the app running; iOS and Android both restrict background sync | High, the device sends on its own schedule |
| Integration work | One integration per device model or SDK, handled inside your app | Usually one API from the device vendor's cloud |
| Who controls the data path | You, end to end | The device vendor's cloud sits in the middle and needs its own BAA |
For an older population, cellular remote patient monitoring devices usually win on readings per patient per month, which is the number your revenue depends on. Bluetooth gives you more control and lower hardware cost, and it suits younger patients or programs where the app does more than relay readings. Plenty of programs end up with both. We covered the phone side, including pairing and background delivery, in our guide to medical device integration in healthcare apps.
Alert rules and the clinical triage queue
A remote patient monitoring platform that pages a nurse for every reading above 140/90 will be ignored within a month. Alert fatigue is the most common way a technically sound product fails clinically, and thresholds and triage rules can prevent most of it.
Thresholds belong to the patient. A clinician should set targets per person when enrolling them, since a systolic of 150 means something different for a stable 82-year-old than for a 45-year-old after a medication change. The system then sorts what comes in by severity: critical readings that need a call the same day, out-of-range readings for the routine queue, and missing data, which is its own category because a patient who stopped measuring is both a clinical and a revenue problem. Repeated readings from the same episode should collapse into one item.
Every action on an alert needs a timestamp, the person's role and the outcome. That record does two jobs at once. It shows a reviewer that someone acted on an out-of-range value, and it becomes part of the time log behind the management codes, so a nurse's triage work gets counted without being typed in twice.
EHR integration over HL7 FHIR
Clinicians do not want a second system, and CMS expects the monitoring to feed into the patient's care, so RPM data has to reach the EHR. HL7 FHIR is the standard route in the US. Readings travel as Observation resources coded with LOINC, the device as a Device resource, and the app can launch inside the EHR through SMART on FHIR so a physician sees the trend without a separate login.
The catch sits in the word write. Federal rules pushed EHR vendors to open FHIR APIs for reading patient data, and write access is far less consistent. Some vendors accept observations through their app marketplace programs, others only take a PDF summary or an HL7 v2 message. Settle what the target EHR accepts before estimating. In remote patient monitoring app development, that single answer can move a timeline by months. Integrations with several EHRs are usually the largest single line in a multi-practice product.
Features that decide whether an RPM program gets paid
Remote patient monitoring software development for a US practice is, in large part, the implementation of a billing rulebook. The features in this section rarely appear in demos. They are the ones an auditor asks about.
The 2026 CPT codes in software terms
The CY2026 Physician Fee Schedule final rule added two RPM codes on 1 January 2026 and lowered both old floors: the 16-day transmission minimum and the 20-minute management minimum. Payments below are national averages and vary by locality.
| Code | What it pays for | 2026 national average | What the software must track |
|---|---|---|---|
| 99453 | Device setup and patient education, once per episode of care | ~$22 | Onboarding record, date, staff member, at least 2 days of readings |
| 99445 (new) | Device supply, 2–15 days of data in 30 days | ~$47–52 | Distinct transmission days per rolling 30-day period |
| 99454 | Device supply, 16–30 days of data in 30 days | same as 99445 | The same counter; the two never bill together |
| 99470 (new) | Management, first 10 minutes in a calendar month | ~$26 | Minutes by role plus one real-time interactive communication |
| 99457 | Management, first 20 minutes in a calendar month | ~$52 | The same; excludes 99470 in that month |
| +99458 | Each additional 20 minutes | ~$41 | Minutes beyond 20, in full 20-minute blocks |
The table hides a detail that breaks naive implementations. Device supply runs on a 30-day period that starts from the patient's first reading, while management time runs on the calendar month. A system with one "month" concept will miscount one of them.
The 2026 changes turned patients who used to be written off into billable ones, but only for software that counts days and minutes precisely enough to tell the tiers apart. A patient with nine days of readings earned nothing for device supply in 2025. In 2026 that patient earns the same device supply rate as one with 25 days.
Day counters, time tracking and the interaction log
These three features carry the revenue, and each has a trap.
The day counter counts distinct days: five measurements on a Tuesday count once. It should also be visible to staff in real time, because a patient sitting at day 14 in week three is exactly the patient a quick reminder call should target.
Time tracking has to record whose minutes they are and what they were spent on. Clinical staff time under general supervision counts toward the management codes, but a timer that stores a bare duration gives an auditor nothing to check. Tie each block of time to an activity: a data review, a call, a care plan change, a message thread. The same logic applies if the patient is also enrolled in chronic care management, which can run alongside RPM as long as no minute counts twice. We covered the separation in our breakdown of chronic care management software.
The interaction log is the evidence for the real-time interactive communication that both 99470 and 99457 require. Log the call with its date, duration, participant and a short note. A two-minute call with a caregiver on the 29th can decide whether an entire month is billable, so the product should warn staff when a patient has minutes but no interaction yet.
Around those three sit the exclusion rules, and they belong in code, where nobody can forget them. Only one practitioner can bill remote monitoring for a patient in a 30-day period, so enrollment should flag a patient already monitored elsewhere. A month carries 99445 or 99454, 99470 or 99457, RPM or RTM, never both halves of a pair. Billing teams also get a lot out of one screen we add to every build: patients close to a threshold on the 25th, sorted by what a single call or reminder would unlock.
Onboarding flows that close the OIG gap
The 2024 OIG evaluation of RPM in Medicare found that 43% of enrollees who received monitoring did not receive all three components: education and setup, device supply and treatment management. About 28% had no claim for education and setup, 23% had no claim for a device, and 12% never received treatment management at all. For 44% of enrollees, Medicare had no record of who ordered the monitoring.
Each of those gaps maps to a missing screen. An onboarding flow built with that report in mind checks four things before the first device ships:
- A prior relationship – the patient had an in-person or telehealth visit with the practice, and the record shows when.
- An order – the ordering clinician and the condition being monitored, recorded as structured data.
- Consent – obtained and stored with the date and method, including that the patient heard about cost sharing.
- Education and setup – who trained the patient, when, and confirmation that the first readings arrived.
The OIG's 2025 snapshot shows why the first item carries weight: practices billing for patients they had never seen are now named as a risk measure. None of this is hard to build. It is missing from most remote patient monitoring app development projects that start from the dashboard.
Patient-side features that keep readings coming
Everything upstream depends on the patient measuring regularly, and adherence drops fast after the first few weeks. In remote patient monitoring app development, the patient app has the narrowest job of all: make a reading effortless and make the patient feel someone is watching.
Reminders should adapt to the patient's actual habits instead of firing at a fixed hour. A simple confirmation after each reading ("received, your nurse will see it") does more for adherence than charts most patients never open. For people who struggle with phones, caregiver access and cellular devices matter more than any app feature. Watch what the notifications say, too. A push message reading "Your blood pressure is high" on a lock screen is protected health information on display, one of the quiet leaks we listed in our piece on HIPAA-compliant app development.
- Large-type, one-action home screen – the reading, the next reminder, nothing else.
- Offline tolerance – readings taken without signal sync later with their original timestamps.
- Two-way messaging – optional, but every message the care team sends is also documented time.
- Language and accessibility settings set during onboarding, so nobody has to hunt for them later.
Remote patient monitoring app development cost and timeline
Remote patient monitoring app development cost depends less on the number of screens than on three variables: how many device types you support, how many EHRs you connect to, and whether the product serves one practice or many.
Cost ranges by scope
These remote patient monitoring app development ranges assume a Poland-based team at $25 to $60 an hour and match the band in our wider guide to healthcare software development cost.
| Scope | What it includes | Cost | Timeline |
|---|---|---|---|
| MVP for one practice | One device type, patient app, clinician dashboard, threshold alerts, day counter and time log, CSV claim export | $80,000–$130,000 | 2-4 weeks |
| Production platform | 3–4 device types over BLE and cellular, triage queue, billing rules engine, one EHR integration | $130,000–$220,000 | 2–7 months |
| Multi-tenant product | Many practices, RPM plus RTM and CCM, several EHR integrations, reporting, role hierarchies | $220,000–$350,000+ | 8–12 months |
Then budget 15% to 20% of the build every year for maintenance. The 2026 fee schedule is a good illustration of why: two new RPM codes and a set of new RTM codes went live on 1 January, and any system with 16 days and 20 minutes written into its logic needed changes to collect on them.
Compliance work that belongs in the estimate
Compliance adds roughly 15% to 25% to remote patient monitoring app development, and it belongs in the architecture from week one. For RPM the list runs as follows:
- HIPAA safeguards – encryption, access control, audit logs, session timeouts.
- Business associate agreements down the whole chain, including every device vendor cloud that relays readings.
- Security testing before launch. Health systems increasingly ask for a penetration test report or SOC 2 during procurement.
- GDPR if any patients are in Europe, which applies alongside HIPAA.
- An FDA assessment of your own software. The FDA treats software that solely transfers, stores, converts or displays device data as a non-device. One that interprets them to drive clinical decisions may be a medical device in its own right, and the answer changes the budget.
Build, white-label or hybrid
White-label remote patient monitoring software can get a practice billing within weeks, for a per-patient monthly fee. For a single practice running a standard hypertension or diabetes program, that is often the sensible choice, and we say so to clients.
A custom remote patient monitoring app development project pays off when the software is the product you sell, when the patient base grows large enough that per-patient fees outrun a build, or when the clinical model does not fit anyone's configuration screen. The hybrid route sits in between: buy device connectivity from an aggregator that already handles dozens of device models, and build the clinical logic, triage and billing layers yourself. You give up some control over the data path and save months of device integration work.
A phased roadmap for the first release
A remote patient monitoring app development project that tries to launch with every device and every integration usually launches late with none of them working well. The sequence that holds up:
- Discovery, 1-2 weeks. Pick the conditions, the codes you will bill, the first device, the target EHR and the compliance scope. Confirm EHR write access now.
- MVP build, 2-4 weeks. One device, onboarding with the four OIG checks, alerts, day counter, time log and interaction log.
- Pilot with 50–100 patients. Watch readings per patient per month and alert volume per nurse. These two numbers tell you more than any feature request.
- Billing and second device. Month-end views, claim export, and the device type your pilot patients asked for.
- EHR integration and scale. Write-back, a second practice or payer, then RTM or CCM if the market calls for it.
We have built each of these layers for healthcare clients, from device sync to the billing logic, and the most useful thing we can offer early is an honest scoping conversation. If you are still comparing partners, our guide on how to choose a software development company lists what to check first. Scope the billing rules and the onboarding flow before the dashboard; they decide whether the program earns anything.
FAQ
Short answers to the questions practices and product teams ask most about remote patient monitoring.
How does remote patient monitoring work?
A clinician enrolls a patient and gives them a connected device, such as a blood pressure cuff or scale. The patient takes readings at home, and the device sends them automatically, over the patient's phone or a built-in cellular connection, to a platform the care team reviews. Staff act on out-of-range values, talk to the patient during the month, and bill Medicare for the device supply and the time spent.
How much does it cost to build a remote patient monitoring app?
Remote patient monitoring app development for a single-practice MVP costs about $80,000 to $130,000 and takes three to four months. A production platform with several devices and an EHR integration runs $130,000 to $220,000, and a multi-tenant product sold to many practices reaches $350,000 or more. The biggest cost drivers are:
- the number of device types and gateways
- EHR integrations, especially write access
- multi-practice features and reporting
Devices are a separate line, bought or leased per patient, and maintenance adds 15% to 20% of the build a year.
Does Medicare cover remote patient monitoring?
Yes. Medicare Part B has covered RPM widely since 2019, and Medicare Advantage plans cover it too. The usual Part B coinsurance applies, which is why patients have to be told about cost sharing when they consent. The patient needs an established relationship with the billing practice, and the device must meet the FDA definition of a medical device.
Who qualifies for remote patient monitoring?
Any Medicare patient with an acute or chronic condition whose clinician decides monitoring is reasonable and necessary can qualify. In the OIG's 2022 data, 94% of Medicare enrollees on RPM had a chronic condition, and more than half were monitored for hypertension. The conditions are:
- an in-person or telehealth visit with the billing practice beforehand
- documented consent
- at least 2 days of transmitted readings in a 30-day period, the 2026 minimum
Commercial payers set their own rules, so check each contract.
Does a remote patient monitoring app need FDA clearance?
The devices usually do, and your software usually does not. Medicare requires the monitoring device to meet the FDA definition of a medical device, and most programs use remote patient monitoring devices – cuffs, scales and meters – that are already cleared. Software that only transfers, stores and displays readings generally sits outside FDA device regulation. If your app interprets data to recommend treatment or runs active patient monitoring alarms, get a regulatory assessment at the start of remote patient monitoring app development.
What is one disadvantage of remote patient monitoring?
Adherence. Programs depend on patients measuring regularly, and many stop after the first few weeks, which weakens both the clinical value and the billing. A related problem sits on the staff side: poorly tuned alerts bury nurses in noise until they stop trusting the queue. Adaptive reminders, cellular devices for less confident patients and per-patient alert thresholds reduce both.
