A practice enrolls 200 patients in remote monitoring, ships the devices, and closes the month. A third of those patients transmitted for nine days and then stopped, because a device fell off a nightstand or a phone updated and killed a pairing, and nobody noticed until the period had already closed. Until this year those patients were worth nothing. In 2026 they are worth something, which is a genuine improvement and also the beginning of a harder problem, because the difference between nine days and sixteen is now the difference between two codes rather than between a code and a zero.
That is the defining characteristic of remote monitoring as a business: the billing rule is a product requirement, and it is a real-time one. A day of missing data is not a reporting problem you fix at month end. It is revenue that no longer exists. Any software that treats adherence as a report rather than as a live operational signal will lose a predictable fraction of its revenue every single month, and the practice will blame the staff.
On 1 January 2026 the shape of what is billable changed, and with it which products are worth building. Under the CY2026 Medicare Physician Fee Schedule final rule, CPT 99445 pays for RPM device supply when between 2 and 15 days of data are transmitted in a 30-day period. The old device-supply code required a 16-day minimum. That single threshold was the reason most short-duration monitoring programs were not businesses, and it is gone.
This is a builder's read of that, written for the person who has to run the program rather than the person writing the claim.
Before anything else: nothing here is billing, coding, legal or regulatory advice. Code numbers, thresholds and payment amounts must be confirmed against the current CMS physician fee schedule, your Medicare Administrative Contractor's guidance, your payer contracts, and your own billing and compliance advisors. Payment figures below are national averages and vary by locality and by year. This area changes annually and mid-year sub-regulatory guidance moves it further. We build software to the boundary your compliance people define; we do not define it.
What remote monitoring actually pays for
The single most useful thing an operator can understand is that remote monitoring is not one service. It is a small stack of separately-billed components, and each one has its own conditions. Get the mental model right and the software requirements fall out of it.
1. Setup and patient education. A one-time service for enrolling the patient and teaching them to use the equipment. Billed once per episode rather than monthly.
2. Device supply and data transmission. The recurring component tied to the patient actually having the device and it actually transmitting. This is where the day-count condition lives, and where 2026 changed. The long-standing threshold was 16 days of readings in 30. CPT 99445 now covers a period in which 2 to 15 days of data are transmitted, at a national average of roughly $47. It is still the component most often lost, and it is still lost silently — the difference is that losing it now costs you a smaller code rather than the whole month.
3. Treatment management time. Clinical time spent reviewing data, contacting the patient, and adjusting care, accumulated across a period. The long-standing structure has been a first increment of time with add-on codes for further increments. CPT 99470 covers the first 10 minutes of clinical staff, physician or qualified health professional time in a calendar month, at a national average of roughly $26, and it requires at least one real-time interactive communication with the patient or caregiver. That last condition is the one that is a software requirement rather than a workflow note: a chart review is not an interactive communication, and if you cannot evidence the conversation you cannot bill the code.
Note the period language, because it is not consistent between the two. The device-supply condition is expressed against a 30-day period; the treatment-management condition is expressed against a calendar month. Those are different objects in a data model and you cannot use one period table for both. Confirm the applicable period definition for every code you intend to bill before you design the schema.
And the sibling family: remote therapeutic monitoring (RTM). RPM covers physiologic data — blood pressure, weight, glucose, oxygen saturation. RTM covers non-physiologic data such as musculoskeletal and respiratory system status and therapy adherence and response, and it has historically permitted self-reported data in a way RPM does not. For anyone building in physical therapy, pulmonary rehab, behavioral health or medication adherence, RTM rather than RPM is frequently the relevant family, and confusing the two is one of the more expensive mistakes in this space.
What changed for 2026, and why it matters commercially
Effective 1 January 2026, the CY2026 physician fee schedule final rule made shorter-duration monitoring billable. CPT 99445 covers a device-supply window of 2 to 15 days rather than a 16-day floor. CPT 99470 covers a first increment of 10 minutes of management time rather than the previous longer minimum. CMS finalized corresponding shorter-duration flexibility for remote therapeutic monitoring as well, so the same structural change applies to the RTM family.
The operator's read of that is more important than the code numbers, and it is this: program shapes that previously could not be billed now can be.
Under a 16-day floor, remote monitoring was structurally a chronic-disease product. You needed patients who would wear or use a device for more than half of every month, every month, indefinitely. That constrained the market to hypertension, heart failure, diabetes and COPD, and it meant a patient who engaged for ten good days generated nothing at all. Ten days was not a partial success under the old rule. It was a zero.
A 2-day floor opens up:
- Post-operative and post-discharge monitoring, where the clinically interesting period is one to three weeks and then the patient is fine.
- Medication titration, where you need dense data for a short window while a dose is adjusted, then far less.
- Pre-operative optimization, a bounded window before a scheduled procedure.
- Short behavioral and therapy programs under RTM, where adherence data matters for a defined course rather than forever.
- Episodic flare management for conditions that are stable most of the year.
- Patients who engage partially. Previously an all-or-nothing cliff at day 16. Now two qualifying days puts a patient inside a billable band instead of outside one.
That last one is not a niche case. In real programs, a meaningful share of enrolled patients are partial adherers, and under an all-or-nothing threshold every one of them was pure cost. Changing that changes unit economics for the whole book, not just for new program types.
The commercial consequence for a builder: the addressable buyer expands from chronic-care management organizations to surgical practices, orthopedics, physical therapy, specialty clinics and post-acute providers — buyers who previously looked at remote monitoring, did the arithmetic, and passed. Some of them are looking again right now, and most of them do not yet have a vendor.
The questions that decide whether you can bill at all
Before any software gets built, an operator needs written answers to these. Your billing and compliance advisors own them; your product has to implement them.
- Does the device meet the regulatory definition of a medical device, and does it transmit automatically? For RPM, the data must be collected and transmitted by the device rather than typed in by the patient. This is the point at which a lot of consumer-wearable business plans fail: a general-purpose fitness tracker is generally not the same thing as a monitoring device for billing purposes, whatever its data quality. Confirm before you architect around it.
- Who is the billing practitioner, and can more than one bill for the same patient in the same period? Historically the answer to the second question has been no, which makes patient-level exclusivity a data-integrity requirement, not a nicety.
- What supervision does the clinical staff time require, and does your staffing model satisfy it?
- Was consent obtained, documented, and is it retrievable?
- Has the interactive communication requirement been met and evidenced for the management-time component?
- Which period does everything count against? Not one answer. The 2026 device-supply condition is written against a 30-day period and the 10-minute management increment against a calendar month. These are not the same object, the difference determines your entire data model, and getting it from your billing advisor per code family is cheaper than discovering it in an export.
- What documentation would you produce in an audit, per patient, per period, without a developer running a query?
If an operator cannot answer those, the correct next step is not a build. It is a conversation with a billing advisor, and then a $1,500 planning sprint that turns those answers into a scope.
Now the engineering: what a billable RPM product must do
Everything below follows from the rules above. This is the part that separates a remote monitoring product from a health dashboard, and it is almost entirely unglamorous.
Adherence day counting as a first-class, auditable field
Not a report. A live computed value per patient per period, visible to staff, with a written definition of what counts as a qualifying day and evidence attached to each one.
One structural change worth building for deliberately: the counter is no longer a pass/fail test against a single threshold. With a 2-to-15-day band sitting below the 16-day one, the same count now has to place the patient in a band, and the band determines which code the period exports as. Products that modelled adherence as a boolean will need that boolean replaced with a banded value everywhere it appears — in the work queue, in the projection, in the billing export and in the audit record. Do that before you have a year of production data shaped the old way.
The details that decide whether the count is correct:
- Whose day is it? A reading transmitted at 11:40 p.m. in the patient's timezone arrives in your system after midnight UTC. If your day counter uses server time, patients in western timezones lose days. This is the same class of bug that breaks fitness streaks, except here it costs money.
- One reading or several? Define it, write it down, and make the definition visible in the audit record. Multiple readings on one day are still one day.
- Rolling window or calendar month? Build the period model explicitly rather than assuming, because the reporting, the alerting and the billing export all inherit it.
- Late-arriving data. Devices buffer. A cellular device out of coverage for three days will dump its backlog when it reconnects, and those readings belong to the days they were taken, not the day they arrived. Recompute the count when backfill lands, and log that you did.
The mid-period intervention loop, which is the actual product
If a patient is off pace on day nine, someone has to know on day nine. That means:
- A projected end-of-period adherence figure, not just a current count.
- A staff work queue sorted by recoverability, and now by marginal value: a patient sitting at one qualifying day is a different intervention from a patient sitting at fourteen. The first is about to fall out of billability entirely; the second is one day from the higher band. Rank by which contact moves the most money, not by who is furthest behind.
- The same queue has to flag patients with a qualifying day count but no interactive communication logged, since that is a separate way to lose the management code.
- Escalation rules: automated reminder, then SMS, then a call, then a device check, then disenrollment.
- A device-health signal distinct from patient non-adherence. "Not transmitting" and "not using it" require different interventions, and telling them apart is a technical problem: last-seen timestamps, battery level, connectivity state, pairing status.
This single loop is worth more to a program's revenue than any dashboard, and it is the feature most commonly missing from products built by teams who have not run a program.
A time ledger, not a time field
Management-time codes require accumulated clinical time, and "our nurse says she spent about 25 minutes" is not evidence.
What a defensible time ledger looks like: entries attributable to a named staff member and a named patient, with start and stop times, an activity type, a link to the clinical action taken, an immutable audit trail, and an association with a specific billing period. It should be capturable in the flow of work — a timer that starts when a chart opens — because a system that requires staff to remember to log time will be under-reported, which means unbilled revenue, or over-reported, which is much worse than unbilled revenue.
The interactive-communication requirement needs its own evidenced record, and under CPT 99470 it is not optional — at least one real-time interactive communication with the patient or caregiver has to have happened in the month for the code to be billable. Model it as a first-class object rather than a checkbox on a note: who initiated it, who the other party was and whether they were the patient or a caregiver, the channel, the start timestamp, the duration, and a link to the clinical action it produced. Then surface an unmet-communication flag in the same work queue as the day count, because it fails in exactly the same way — quietly, and only discoverable after the month has closed.
Device supply, which is a logistics business hiding inside a software business
Nobody warns founders about this. A remote monitoring program is a hardware fleet:
- Cellular versus Bluetooth. Cellular devices cost more per unit and carry a data plan, and they work — no phone, no pairing, no app, no patient troubleshooting. Bluetooth devices are cheaper and fail through the patient's phone: OS updates, battery optimization killing the background connection, a new handset. For an older Medicare population, cellular is usually the cheaper option once support cost is counted honestly. Consumer-wearable and phone-based approaches inherit every problem described in our wearable integrations work, plus a billing-eligibility question on top.
- Inventory, shipping, returns and losses. Devices go out, some come back, some do not. Serial-number tracking, assignment history and a replacement workflow are day-one requirements, not phase two.
- Vendor data ingestion. Each device manufacturer has its own API, its own webhook behavior, its own idea of units and its own outage schedule. Normalize on ingest, keep the raw payload, and instrument the gap between "device took a reading" and "our system has it".
Getting data into the EHR, which is where these projects die
Clinicians will not use a second system. If readings and time entries do not land in the chart, adoption fails regardless of how good the app is.
Plan for FHIR-based integration where it is available and HL7 interfaces where it is not, plus the unglamorous reality that every health system's integration queue has its own timeline and its own gatekeeper. Budget calendar time for this, not just engineering time. It is the most common reason a technically finished product does not go live for another two quarters. Our telehealth and clinical software work is mostly this class of problem.
The audit pack
For every patient-period, one exportable bundle: consent record and version, device assignment and serial, every qualifying day with its underlying readings, the day-count band and the code it produced, the time ledger with staff attribution, the interactive communication record with its timestamp and counterparty, and the clinical notes generated. Assembled automatically. If producing that requires an engineer, you do not have a compliance feature, you have a liability.
The audit question a banded threshold creates is specific and you should be able to answer it on demand: why did this period bill as 2-to-15 days rather than 16 or more, and what evidence supports each day counted? If the answer lives in a nightly job with no retained inputs, you cannot answer it a year later.
Alerts, thresholds and who is awake
A blood pressure reading of 210/130 arrives at 2 a.m. What happens?
That is a clinical governance question with a software implementation, and it is the same class of problem as crisis escalation in behavioral health: thresholds set by a named clinician, escalation executed deterministically in code, coverage that matches what the patient was told, alarms on failed handoffs, and logs that a reviewer reads. Alert fatigue is the failure mode — a system that fires on everything trains staff to dismiss everything, and the one that mattered goes with it.
Build or buy
The honest answer differs by who is asking.
If you are a clinic or a practice group: buy. Established remote monitoring platforms have already solved device logistics, ingestion, adherence tracking and billing exports, and they will get you running in weeks. A custom build for a single practice almost never returns its cost. Spend the money on the staff who deliver the service, because staff minutes are your binding constraint, not software.
If you are a startup selling remote monitoring to providers: build, because the platform is your product — but build the boring parts first. The adherence engine, the time ledger, the audit pack and the device fleet management are the product. The patient app is not, and it is the part most teams build first.
If you are a device manufacturer: partner. Your advantage is the device and the data; the billing workflow layer is a different company's core competence, and buying your way to an integration is faster than becoming a software vendor.
If you are a health system: your existing EHR vendor probably has a module. Evaluate it honestly before commissioning anything, because integration is the expensive part and they start with it solved.
The economics an operator should model
Do this arithmetic with your own numbers before you build anything.
Revenue per enrolled patient per period is a function of which components you can bill, the fee schedule, and your geographic adjustment. As an order-of-magnitude starting point, the 2026 national averages are roughly $47 for the 2-to-15-day device supply code and roughly $26 for the first 10 minutes of management time. Those are national averages: they move with locality adjustment, they change every year, and commercial payers are a separate negotiation entirely. Model with the numbers your MAC and your payer contracts give you, not with the numbers in this paragraph and not with the numbers in a vendor's deck.
The banded structure also means revenue per patient is now a distribution rather than a binary. Model it that way — what share of your enrolled patients land at zero qualifying days, in the 2-to-15 band, and at 16 or more — because the middle bucket used to be worth nothing and is now the bucket your intervention loop is fighting for.
Cost per enrolled patient per period is device amortization plus connectivity, plus clinical staff minutes, plus platform cost, plus support and shipping.
The binding constraint is staff minutes. Which is the single most important design insight in this category: the job of the software is to reduce the clinical minutes required per patient per period, not to add features. Every screen that makes a nurse review data faster is worth more than every screen that makes the patient app prettier. Work queues sorted by clinical priority, one-click documentation, pre-drafted outreach, and data views that surface the exception rather than the record — that is where the margin is.
Then apply the enrollment funnel honestly. Not every eligible patient consents, not every consenting patient activates the device, and not every activated patient hits threshold. Model the drop-off at each step, because a program that pencils out at 100% adherence and loses money at realistic adherence is a program that loses money.
What this costs to build
- MVP Planning Sprint — $1,500, 5 days, credited toward the build. In this category it is where the billing rules become a data model.
- Healthtech MVP Blueprint — $1,999, 7 days. Adds the sensitive-data and claims inventory and the specialist decision points, which is what you want when PHI and billing rules are both in scope.
- Prototype on synthetic data — from $3,500. No PHI, no BAA, enough to test the staff work queue with actual nurses. Do this before building the patient app.
- MVP build — from $12,000. A bounded version one.
- Full custom build — from $25,000. Where a real multi-tenant platform with EHR integration starts.
- App maintenance — from $1,000/mo, and in this category it is not optional: fee schedules change annually and device vendors change APIs whenever they like.
Full list on the pricing page. Device hardware, connectivity, EHR interface fees and any clinical staffing sit outside those numbers.
To be exact about the boundary: Zee Palm builds HIPAA-aware, compliance-conscious systems and maps sensitive-data, claims and clinical boundaries during planning. We do not issue certifications or legal sign-off, we do not determine whether a product is a regulated medical device, and we do not give billing or coding advice. Our trust page says the same in the same words, and the engineering side of PHI handling is covered in how to build a HIPAA-compliant app.
If you are evaluating whether a program is viable before committing to software, that is exactly what the planning sprint is for. If you already have the billing answers and need the build scoped, send us the program design — and if you are earlier than that, the health-tech startups page explains how we work from the beginning.
Frequently asked questions
What changed with RPM codes for 2026?
Effective 1 January 2026 under the CY2026 Medicare Physician Fee Schedule final rule, CPT 99445 pays for RPM device supply when between 2 and 15 days of data are transmitted in a 30-day period, replacing the old 16-day minimum as the only option, and CPT 99470 covers the first 10 minutes of management time in a calendar month. CMS finalized corresponding shorter-duration flexibility for RTM. Confirm the codes and their applicability against the current fee schedule, your MAC and your payer contracts.
What is CPT 99445?
The 2026 RPM device supply and data transmission code for a period in which between 2 and 15 days of data are transmitted, at a national average of roughly $47. It is the code that makes short-duration monitoring viable, because the previous device-supply code required at least 16 days of data in 30. National averages vary by locality and by year, so verify against the current schedule before you build a revenue model on it.
What is CPT 99470?
The 2026 RPM treatment management code covering the first 10 minutes of clinical staff, physician or qualified health professional time in a calendar month, at a national average of roughly $26. It requires at least one real-time interactive communication with the patient or caregiver during the month, which is a documentation requirement your software has to satisfy — a chart review does not count and an undocumented phone call is not evidence.
Why does that make more RPM programs viable?
Because a 16-day floor made remote monitoring structurally a chronic-disease product, and patients who engaged for ten days generated nothing. A 2-day floor makes post-operative, post-discharge, medication-titration, pre-operative and short behavioral therapy programs billable, and it changes the economics of partial adherers across an entire book of patients rather than only for new program types.
Can we use Apple Watch or Fitbit data for RPM billing?
Generally not for RPM, which requires data collected and transmitted by a device meeting the regulatory definition of a medical device rather than self-reported or general-consumer fitness data. RTM has different rules around self-reported data. Get the determination from your compliance advisor before you architect a product around consumer wearables — it is the assumption that most often breaks a business plan late.
What is the difference between RPM and RTM?
RPM covers physiologic data such as blood pressure, weight, glucose and oxygen saturation. RTM covers non-physiologic data including musculoskeletal and respiratory status and therapy adherence and response, and has historically allowed self-reported data. Physical therapy, pulmonary rehab, behavioral health and medication adherence products usually belong under RTM.
What does RPM software actually have to do that a health app does not?
Count qualifying transmission days in the patient's local timezone as a live, auditable value and resolve that count to a billing band rather than a pass/fail; alert staff mid-period while a shortfall is still recoverable; maintain a defensible time ledger attributable to named staff and billing periods; evidence interactive communication; manage a physical device fleet including returns and replacements; write into the EHR; and produce a per-patient audit pack automatically.
Should we build or buy remote monitoring software?
Clinics should buy — established platforms have solved device logistics and billing exports, and the money is better spent on the staff delivering the service. Startups selling to providers should build, starting with the adherence engine, time ledger and audit pack rather than the patient app. Device manufacturers should partner. Health systems should evaluate their EHR vendor's module first.
How much does it cost to build an RPM platform?
A bounded version one starts at $12,000 and a full multi-tenant platform with EHR integration starts at $25,000, with a $1,500 planning sprint or $1,999 blueprint first to turn the billing rules into a data model. Maintenance from $1,000 a month is genuinely required here, because fee schedules change annually and device vendor APIs change without warning.