Remote patient monitoring architecture in 2026: four products
TL;DR
Remote patient monitoring architecture in 2026 is never one application. A program that reaches patients ships four things: a companion app on the patient's phone, a web portal for the clinicians who act on the data, an administrative surface for accounts plus configuration, and a cloud backend that owns the record. Price the phone app and you have priced a quarter of the work.
- Medicare paid more than $500 million for remote patient monitoring in 2024, and about 43 percent of enrollees who received it did not get all three components.
- The CPT 2026 code set added five codes for monitoring over 2 to 15 days and dropped the treatment management threshold from 20 minutes to 10.
- Qualifying day counts and clinician minute counts are backend features. No phone app produces them.
- In our own monitoring requirement records, around 85% named a clinician or administrator web surface next to the patient app.
Why one app is the wrong unit of scope
The request arrives in the singular. We have a device, we need an app. Then the first workshop produces a clinician who wants to see the readings, an administrator who has to create that clinician's account, and a payer question nobody can answer from a phone. That is not indecision. It is the shape of the product, visible late.
The public record says the same thing in money. Medicare payments for remote patient monitoring exceeded $500 million in 2024, according to the HHS Office of Inspector General. An earlier OIG evaluation found that about 43 percent of enrollees who received it did not receive all three components.
Read that as an architecture result. CMS describes the components as education and setup, device supply with data transmission, then treatment and management. The first lives in the patient app, the last wherever a clinician works, and in 43 percent of cases the distance between those two surfaces was wide enough to swallow a component.
The 2026 code change put the portal on the invoice
On September 11, 2025 the AMA published the CPT 2026 code set. Five new codes report remote monitoring over short periods, 2 to 15 days within a 30-day period. Two report treatment management after 10 minutes of service per calendar month, down from the previous 20-minute threshold. CMS then valued the remote monitoring family, new codes 99445 and 99470 included, in the CY 2026 Physician Fee Schedule final rule of November 5, 2025, and now states the device must collect and transmit health data at least 2 days every 30 days.
Count what the software has to produce. Which days carried a transmission, per patient, per calendar month. How many minutes a named clinician spent reviewing that patient, with a start and a stop. Neither number exists in a mobile app. Both are backend aggregates shown to a human in a browser, and a 10-minute threshold is twice as sensitive to a sloppy timer as a 20-minute one. A program that cannot show its own day counts bills on faith.
How we built this breakdown
Three rules, applied to everything below.
- Payment and regulatory facts come from the agency instrument or page, not from a summary of one.
- Engineering examples are work we published as case studies, with the page linked so you can check the claim.
- Where we publish our own numbers, any group with fewer than three data points is not published.
One disclosure. Mercury Development builds device connected and healthcare software, so every engineering example is our own. Detailed public guides exist: Acquaint Softtech publishes a component model with price bands, a single-device MVP at $60,000 to $120,000 plus $50,000 to $120,000 per EHR vendor integration. The components are there. What is missing, in that guide and most others, is the step from role count to price.
The four surfaces at a glance
| Surface | Who signs in | What only it can do | What deferring it costs |
|---|---|---|---|
| Companion app | Patient, caregiver | Pair the device, capture readings, carry consent | Nothing ships; everyone funds this one |
| Clinician portal | Physician, nurse, therapist | Review a panel, set orders, log managed time | The clinical workflow runs on exported spreadsheets |
| Admin surface | Program operator, support staff | Create accounts, assign roles, set thresholds | Engineers run production queries per new clinic |
| Cloud backend | Nobody, which is the problem | Own the record, enforce access, derive counts | Each surface invents its own version of the truth |
Four sign-in paths, one record. That last column is the whole argument.
The companion app is the smallest surface
Patient-facing work is the part buyers can picture, so it gets specified in detail. Pairing, readings, reminders, consent. Real work, and the cheapest row in the table. It is rarely one app either. On Fitbit, where we have been the software partner since 2011, the consumer side alone grew into a desktop application for Windows and Mac that set up the tracker, an Android client, a Windows 8.1 application with Bluetooth 4.0 sync, an Xbox One version of Fitbit Coach, plus a website we built in 44 language versions. One product in the marketing sense, five build targets in the engineering sense. Clinical programs multiply differently: an app for elders and an app for their caregivers are two information models, not one app with a toggle.
When the device itself is regulated, the companion app carries its own classification, covered in our guide to medical device companion app development.
The clinician portal carries the program
The portal is where monitoring becomes care. Someone reviews a panel of patients, decides who needs attention, writes an order, and spends measurable minutes doing it. Two requirements follow, and neither is a dashboard.
Orders have to flow back. When a clinician sets a therapy prescription in the portal, the patient app has to receive it without anyone retyping it, which makes the portal a writer into the device path rather than a reader of it. That alone pulls in conflict rules, acknowledgement, a version history of what was prescribed when. And managed time has to be recorded as evidence: a start, a stop, an actor, a patient, held where an auditor can see it.
The portal also decides your regulatory status more than the phone app does. The FDA's clinical decision support software guidance, issued in January 2026 under docket FDA-2017-D-6569, sets out when a function supporting a clinical decision falls outside the device definition. The agency's guidance on medical device data systems separately treats software intended solely to transfer, store, convert or display medical device data as outside device regulation. Display the reading and you sit on one side of that line. Score it, or rank the panel by predicted risk, and you may be on the other.
A browser gets this work for reasons unrelated to taste. On EyeIC, moving a 510(k) cleared retinal image comparison tool from Windows desktop to a multi-user web application took three months and removed four problems at once, among them an update mechanism with its own test matrix and manual steps for payer submission. The web version carried HIPAA compliant online access plus automated reporting for reimbursement. Reimbursement reporting was a web feature then, for the same reason day counts are a web feature now.
Admin is not a settings screen
Admin gets cut first and missed hardest, because its users are your staff and your staff will cope.
Start with the rules. HIPAA's technical safeguards at 45 CFR 164.312 call for a separate name or number that identifies and tracks each user, mechanisms that record and examine activity in systems holding electronic protected health information, plus procedures verifying that whoever seeks access is who they claim to be. In build terms: an account system, an audit log, an authentication model. None of the three is a preferences page, and none arrives free with a hosted login provider.
Then the operational half, where the hours go. Creating a clinic and its staff. Assigning roles. Limiting which patients a role can see. Setting alert thresholds. Updating educational content without a store release. Reporting across the user base rather than one patient at a time.
We have built that surface at scale in an adjacent field. The claims workflow system we built for a medical billing client has been in production since 2006 and is on its fourth major release, and its administrative application is why it survived: operators add rejection codes and workflows themselves, change processing rules by practice or by carrier, and limit which codes a user class may touch. The published result is 80 percent more claims worked without new staff, plus a 35 percent reduction in the average age of claims, in a system that now processes $395 million in claims for 168 practices and 422 physicians.
Skip admin and the work moves to an engineer with database access, the most expensive and least auditable place to put it.
The backend is the product nobody demos
The backend decides whether a program is one system or three systems wearing a shared logo.
It owns the record: readings with provenance, orders with versions, consent with timestamps, plus the derived counts billing and clinical review both read. It enforces the access rules admin configures, because rules enforced in a client are suggestions. And it absorbs the device layer, meaning ingestion that tolerates a gateway dropping offline and returning with four hours of buffered readings in the wrong order.
Multi-client is the constraint teams underestimate. On Tonal the same product reaches users through an iOS application, an Android application, a watchOS app, plus the Android-based trainer itself: four clients of one service, each with its own release cycle, which is why that interface gets versioned rather than negotiated in a chat. Scale is a staffing fact too. On MiMedia our side reached more than 30 engineers across 4 parallel projects.
If glucose readings are one of the device feeds, the ingestion limits are in our Dexcom API integration guide.
What four surfaces do to the price
Here is the mechanism, in the order it reaches a budget.
Each surface carries its own perimeter of unglamorous work: authentication, authorization, navigation, empty states, error handling, accessibility, localisation, a test matrix. A clinician portal is not a fifth of a patient app because it has fewer screens. It has fewer screens and the same perimeter.
Roles multiply that test matrix rather than adding to it. Every permission boundary is a case per surface, and the interesting cases are negative. What a nurse cannot see. What an operator cannot export. What happens to a clinician's view when a patient withdraws consent.
So a feature list is a poor estimating unit and a role list is a good one. Give a vendor the roles, the surfaces each role signs into, plus the data that has to cross between them, and the estimate stops being a guess about screen counts.
Dollar bands for monitoring builds sit in our guide to remote patient monitoring app development cost and what HIPAA adds to it.
What to defer to V2 and what never defers
Phasing works. Phasing by surface does not. Cut depth inside each surface instead, and keep every role able to finish one job.
Defers well:
- Analytics beyond the counts you must bill and clinically justify.
- The second and third device family. One proven protocol beats three at a demo.
- EHR write-back. Read what you need, price the bidirectional interface separately.
- Self-service clinic onboarding. Supported manual setup is fine at ten clinics.
- Native clinician mobile, while a responsive portal covers the ward round.
Never defers:
- The role model with its permission boundaries. Retrofitting these reworks every surface.
- The audit log, which cannot be reconstructed after the fact.
- Account lifecycle, including what happens when a clinician leaves.
- The derived day counts and minute counts your reimbursement depends on.
- Consent and withdrawal, which touch every surface at once.
- The API contract between app, portal, backend, versioned from release one.
The honest version of V1 is narrow in features and complete in roles.
What our own monitoring records show
Counted by hand across the device linked monitoring programs in our healthcare requirement records, every one described software for more than one human role. Around 85% specified a clinician or administrator web surface alongside the patient application, in writing, before any workshop. Two patterns inside that group are large enough to publish.
- Clinical data review for a professional user, whether physician, nurse or therapist, appears in the majority of records. Staff need to see what the device produced and act on it.
- Role and account administration, meaning who may create users and what each role may touch, appears often enough to count as a default rather than an option.
A third pattern, content and configuration updates without an app store release, had fewer than three data points, so it is not published here.
One more pattern predicts budget trouble. In around 35% of these programs the scope we were first shown was narrower than the product needed, and in the clearest cases the trajectory ran from a single utility application to a web application, then a mobile application over Bluetooth, then a cloud service behind both. That is not a client failing. A device company describes the thing it built, and the surfaces around it appear when somebody asks who signs in.
To compare vendors that scope all four surfaces, start with our ranking of remote patient monitoring app development companies.
Why we build the portal before the second device
Opinion, stated plainly. Given a fixed first budget, we would rather ship one device family with a working clinician portal than three device families with a spreadsheet export.
The reason is where the risk sits. A second protocol is bounded work: you can estimate it badly, learn the truth on a bench, reprice. A missing portal is unbounded, because the clinical workflow does not stop existing when the software omits it. It relocates into email and exported files, and the program accumulates a shadow process the next release has to migrate instead of build.
Two limits. Counting surfaces does not make an estimate correct, it makes it falsifiable, which is a smaller claim and a more useful one. And the model does not apply to a wellness product with no clinical actor. If nobody licensed reads your data, you have a consumer app with a backend, and you should not pay for a portal you will never staff.
Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder. The requirement reviews behind this breakdown, where incoming monitoring programs are read for user roles, device paths and the data that has to cross between surfaces, come from the engineering practice he works in.
Send us your role list and we will scope the surfaces
List the people who will sign in, what each of them has to finish, and what the device sends. We will come back with the surfaces that implies, the parts we would phase behind your first release, and the boundaries we would refuse to defer.