Remote monitoring proposals almost always start in the wrong place.

The RealityThe cost is the person watching the data

⚠️

The Problem

The model counts devices and ignores people.

A per-device cost, an enrolment target, and no line for the clinician who reviews readings or the person who calls a patient whose device stopped transmitting.

🔧

The Solution

Model the staffing first, then the hardware.

Work out who watches the data, how long each patient takes per month, and what happens to an abnormal reading. Then price the devices.

✅

The Resolution

A programme that survives month three.

Enrolment sized to the review capacity that exists, escalation defined before the first alert, and a business case that holds when volume grows.

Data collection days: the rule has changed

Start here, because a great deal of published material is now wrong and it is the kind of wrong that propagates.

CMS’s Telehealth and Remote Monitoring MLN booklet, published December 2025, states that you must collect data for “2–15 or 16+ days out of 30 days, depending on the code descriptor,” and that this does not apply to the treatment management codes 98980, 98981, 99457 and 99458.

The flat sixteen-day requirement that many practices and a good deal of guidance still describe no longer applies across the board. We are deliberately not listing specific code numbers for the shorter-duration tier here, because we could not verify them to the standard this site holds — and a wrong code in print is worse than an absent one. Confirm the current descriptors against the fee schedule before building anything that depends on them.

Device supply is a different act from treatment management

The billing structure separates supplying and setting up a device from the clinical work of managing the patient, and the distinction shapes the staffing model more than it shapes the revenue.

Setup and patient education happen once. Supplying the device and its data transmission is a recurring monthly matter tied to the data actually being collected. Treatment management is time a clinician spends interacting with the patient about the data, and the booklet is explicit that the data-collection day requirement does not apply to those management codes.

Read that as an operational instruction. The device side is logistics; the management side is clinical time, and they are performed by different people with different costs. A model that treats the programme as one undifferentiated service will misprice both.

The staffing model is the whole business case

AHRQ’s patient safety network puts the operational reality plainly. Its perspective on remote patient monitoring, published March 2023, notes that appropriate staff are needed to train patients and provide technical support, monitor data, or respond to abnormal values, and that there is a risk of clinical misdiagnosis or failure to identify when patients need attention.

That is an editorial perspective rather than peer-reviewed research, and it was written in a different reimbursement environment, so treat the framing rather than the economics as the takeaway. The framing is right: three distinct staff functions, not one.

Model them separately. Onboarding and technical support, which is high at enrolment and falls away. Daily or weekly data review, which scales linearly with census and never falls away. And escalation, which is unpredictable and has to be covered by someone with clinical authority. Practices that staff only the middle one discover the first at go-live and the third at the worst possible moment.

Enrolment volume and the point where it breaks

The single most useful number in a remote monitoring business case is how many patients one reviewer can carry, and almost nobody measures it before committing.

Measure it. Run twenty patients for a month, time the review, time the exceptions, and count how many readings triggered a call. You will get a per-patient-per-month figure specific to your population, your device and your threshold settings, which is worth more than any vendor benchmark because the thresholds are yours.

Then set enrolment to that capacity rather than to a revenue target. The failure mode we see is a programme that grows past its review capacity, at which point the data is being collected and not read — which carries the clinical risk without the clinical benefit, and is a worse position than not running the programme.

The payment side moves annually

Any model built on this year’s rates needs a note saying so. The CY 2026 Physician Fee Schedule final rule, published 5 November 2025 at 90 FR 49266 and effective 1 January 2026, is the current authority, and it contains valuation sections for both remote physiologic and remote therapeutic monitoring.

One structural change worth knowing: CY 2026 has two conversion factors rather than one — $32.7365 for qualifying alternative payment model participants and $32.5765 for others. A model quoting a single conversion factor is describing a world that no longer exists.

None of which is a reason to wait. It is a reason to build the model so the rate assumptions sit in one place and can be changed annually without rebuilding everything around them. That is the same discipline we apply to remote monitoring programmes generally, and it is what stops a business case going stale in January.

What to decide before you buy anything

• Who reads the data, and when. By name and by schedule, not by role in the abstract.
• What happens to an abnormal reading out of hours. Written down before enrolment one.
• How many patients one reviewer carries. Measured on your own twenty, not benchmarked.
• Where the rate assumptions live in the model. One place, changed annually.

Qventive provides remote patient monitoring program cost services to practices across New Jersey, and the engagement usually starts by measuring the review time rather than by comparing devices. The work sits inside our EHR services because the data has to land in the chart to be useful.

Because device data crosses from a manufacturer’s platform into your record, the flow belongs in your HIPAA risk analysis, and the escalation path is usually worth rebuilding alongside the wider clinical workflow rather than bolted onto it.

Monitoring programmes: common questions