For years, remote patient monitoring had an all or nothing structure. A patient transmitted data on at least sixteen days in a thirty day period or the device supply code could not be billed. Fifteen days of readings paid the same as none.
That changed on 1 January 2026. The CY 2026 Medicare Physician Fee Schedule final rule introduced new codes for shorter duration monitoring. A device supply code now exists for two to fifteen days of transmission in a thirty day period, alongside the existing sixteen to thirty day code. Treatment management gained a ten minute option alongside the existing twenty minute one. The same restructuring was applied to remote therapeutic monitoring.
One detail matters more than the rest. CMS valued the new shorter duration device supply code at the same rate as the sixteen day version. The revenue cliff did not get gentler. It moved.
That sounds like a billing story. It is not. Every threshold in that paragraph is a number a software system has to produce, defend, and evidence. Below is what a remote patient monitoring system has to be able to prove, written as requirements.
One caveat first. This is engineering guidance, not coding or billing advice. Code selection and compliance decisions belong with a certified coder and a compliance lead. What follows is what the system has to be capable of so those people can do their jobs.
R1. Count transmission days correctly, and defensibly
The requirement. For any patient and any thirty day period, the system must return the number of distinct days on which qualifying device data was transmitted, and be able to show which days those were.
Why it is harder than it sounds. A day is not a row in a table. Devices transmit late, buffer readings offline and upload several at once, duplicate on retry, and record timestamps in their own timezone. A naive count of records produces a number that looks right and will not survive an audit.
The specific decisions that have to be made deliberately are which timezone defines a day, whether a buffered upload counts on the day of reading or the day of receipt, and how duplicates are collapsed. None of those have an obvious answer, all of them change the count, and the count is what determines which code applies.
That is an ingestion and data modelling problem, which puts it in backend development and cloud engineering rather than in a billing module.
R2. Hold threshold state, and enforce mutual exclusivity
The requirement. The system must know, at any point in a cycle, which thresholds a patient has crossed, and must prevent the two device supply tiers being claimed for the same patient in the same calendar month.
The new codes are not additive. A practice bills either the shorter duration code or the sixteen to thirty day code for a given patient in a given month, not both. A system that surfaces both as eligible has created a compliance risk rather than an opportunity.
The design implication. Threshold status is state, not a report. It has to be queryable mid cycle, because the whole point of the change is that a patient who will not reach sixteen days is now worth continuing to monitor rather than writing off. If your system only reveals the answer after the month closes, it has removed the operational value of the change.
R3. Capture clinical time in a form that survives review
The requirement. Time spent on treatment management must be attributable to a named qualified professional, tied to a specific patient and month, and recorded close to when it occurred.
With a ten minute tier now sitting alongside the twenty minute one, the precision of this measurement matters more than it used to. The difference between nine minutes and eleven is now the difference between billing and not billing, where previously everything under twenty was equally unbillable.
What good looks like. Time captured as a by-product of the work rather than typed into a box afterwards. Every minute a clinician spends recording that they spent minutes is a minute lost and an entry that is harder to defend. Reconstructed time is the weakest evidence in any review and the easiest thing for a system to avoid producing.
R4. Produce an audit trail nobody had to assemble
The requirement. For any claim, the system must be able to reproduce the evidence behind it: the automated transmissions, their timestamps, the clinical interactions, and who performed them.
This is the requirement most often discovered late, because it is invisible while everything is going well. The relevant question is not whether the data exists somewhere. It is whether one query returns the complete evidence for one claim, or whether someone has to assemble it from three systems and a spreadsheet.
The test. Pick a claim from four months ago at random. How long does it take to produce its full supporting evidence? If the answer is measured in hours, the audit trail exists in theory only.
R5. Tie monitoring to a documented clinical reason
The requirement. Each monitored patient must be linked to the condition the monitoring supports, and that linkage must live in the record rather than in someone's memory.
CMS was explicit in its commentary that remote monitoring must be medically necessary for the diagnosis or treatment of illness or injury in order to be billed. Lower thresholds expand who can be monitored profitably. They do not change who should be monitored.
Why this belongs in the software. A programme that enrols patients because the economics now work at two days of transmission, without a documented clinical rationale per patient, has built a volume problem with an audit attached. The system should make the clinical linkage a condition of enrolment rather than a field someone can skip. That means reaching into the clinical record properly, which is a custom EMR and EHR development and integration question.
What the change actually means for programme design
Two consequences follow, and they pull in different directions.
Short duration monitoring became viable. Post surgical recovery, medication titration, and acute episodes where four weeks of intensive monitoring was never the clinical need are now billable propositions. That is a genuine expansion, and it is the one CMS described as reflecting clinical reality rather than an arbitrary threshold.
Adherence stopped being all or nothing. Previously a patient who transmitted on ten days produced nothing. The programme absorbed the device cost and the staff time with no offset. That cliff was the single biggest reason RPM programmes underperformed their business case, and it has been softened considerably.
The counterweight is that the compliance surface grew. More codes, mutual exclusivity rules, and two time tiers mean more ways to bill something you cannot substantiate. The systems that benefit are the ones that can answer R1 through R5 without a person reconstructing anything.
The failure mode
It is worth naming plainly, because it is where these programmes go wrong.
The risk is not under-billing. It is billing confidently on numbers the system produced without anyone examining how it produced them. A day count with an undocumented timezone rule, clinical minutes entered retrospectively, and an audit trail spread across three systems will all produce claims that pass submission and fail review.
The useful discipline is to treat every billable threshold as a measurement with a defined method, the same way you would treat a clinical metric. Write down how a day is counted. Write down how a minute is captured. Those two documents are worth more at audit than any feature in the product.
For programmes operating at scale, the same measurements are also the operational dashboard, since transmission adherence by cohort tells you which patients are drifting before the month closes. That sits with healthcare data analytics platform work rather than with the monitoring tool itself.
Where Woltrio fits
Woltrio builds the ingestion, integration, and evidence layers underneath remote monitoring programmes rather than selling devices or a monitoring platform.
In practice the engagements are R1 and R4: device data pipelines that count days in a defined and defensible way, and an evidence model where a claim's supporting record is a query rather than a reconstruction project. Both are unglamorous and both determine whether the programme survives review.
Where a health system or device company is still establishing whether the model works for its patient population, a scoped MVP instrumented against transmission adherence answers that faster than a full build. The wider capability set sits under services.
Start with a scoped discovery from Woltrio.