What CMS’s Proposed 2027 RPM Staffing Rules Could Mean for Your Program

I’ve watched CMS tighten RPM rules three times since the codes launched, and this is the first one that isn’t about the device or the data. It’s about who’s allowed to be on the other end of it.

If a large share of your RPM panel is run through a contracted monitoring vendor today, this is worth fifteen minutes of your attention before November.

What CMS Is Actually Proposing

CMS filed this as part of the CY2027 Medicare Physician Fee Schedule proposed rule, published in the Federal Register on July 16, 2026, as CMS-1848-P (document 2026-14327). The core change: the clinical staff who furnish RPM and RTM treatment management services would need to be employees of the billing practice. A contracted third-party monitoring company, the kind a lot of multi-site programs lease staff from today, would no longer qualify for that piece of the service.

The comment period closed September 14, 2026. CMS typically finalizes the Physician Fee Schedule rule around November 1 each year, with changes taking effect January 1 of the following year, so the realistic timeline here is a final rule around November 1, 2026, effective January 1, 2027, assuming CMS finalizes this provision as proposed, which isn’t guaranteed yet.

If you’re already running RPM through our billing breakdown’s code set (99453, 99454, 99457, 99458), this is the provision to track, because it changes who can furnish the service underneath those codes, not the codes themselves.

Why CMS Says It’s Doing This

CMS didn’t pull this out of nowhere. It’s leaning on its own Office of Inspector General’s findings about how RPM has actually been delivered.

A 2024 OIG report examined 2022 RPM claims and found that 43% of enrollees missed at least one required service component, most commonly the 16-day transmission threshold or the monthly interactive communication requirement. A 2025 OIG follow-up tracked the spending side: RPM payments rose 31% in a single year, from $408 million in 2023 to $536 million in 2024.

Taken together, CMS’s framing is that the program grew fast while a meaningful share of billed services didn’t fully meet the requirements behind them, and third-party staffing arrangements are harder for the billing practice to directly supervise than an employee sitting down the hall.

That’s CMS’s rationale, not a verdict on any specific vendor’s work. But it’s worth taking seriously, because it explains why the fix CMS reached for is an employment test rather than a documentation test. Documentation rules are easy to write around. An employment relationship is harder to fake on an audit. Becker’s Hospital Review covered this same rationale in detail shortly after the rule was filed, pulling CMS’s fragmentation concern and both OIG reports into one summary.

What This Doesn’t Touch

No. The rule doesn’t ban RPM or RTM software, devices, or vendors generally. It restricts who can be paid for furnishing the clinical monitoring service itself. Your device vendor, your software platform, your data connectivity: none of that is affected. What changes is whether the person reviewing transmissions and making the required monthly contact can be a contractor, or has to be your employee.

That distinction matters because a few headlines covering this have shortened it to “CMS bans third-party RPM,” which overstates it. If you’re deciding whether to build or keep buying the underlying remote monitoring platform itself, that’s a separate decision from this one, and this rule doesn’t force your hand on it either way.

Who Actually Carries This

The programs most exposed are the ones leaning on contracted monitoring staff to cover a panel their own team doesn’t have headcount for, and that’s disproportionately rural and multi-site primary care and specialty groups, where hiring a dedicated RPM nurse for every location isn’t realistic today.

ccnhealth’s transition playbook for this exact rule cites a staffing-ratio planning benchmark of roughly one monitor per 200 patients as the number programs should plan around when bringing monitoring in-house. That’s a useful anchor regardless of where you land on timeline, because it’s the number that determines whether “just hire employed staff” is a one-person job or a five-person job.

Fig 3: RPM Staffing Risk Across Practice TypesThe ccnhealth staffing-ratio figure above is independently confirmed and carries the weight this section needs without that gap.

The Bill Moving on a Different Track

Don’t let the other CMS story confuse you. H.R. 3108, the Rural Patient Monitoring Access Act, passed the House Ways and Means Committee 39-0 on July 16, 2026, the same week CMS-1848-P was proposed, which is probably why the two get mixed up. H.R. 3108 sets a reimbursement floor for RPM and ends a negative rural payment adjustment. It does not touch the staffing-employment question at all. If this bill becomes law, it changes what you get paid. It doesn’t change who’s allowed to do the monitoring.

What “Employed” Actually Requires

Here’s the practical reading, without the legal hedging. The clinical staff furnishing the RPM/RTM treatment management service would need to be W-2, payroll employees of the billing practice. Remote employment appears to qualify: there’s no on-site requirement in the proposal, so an employed nurse working from home still counts. Two other provisions travel with this one: a mandatory initiating visit before RPM begins, and RTM limited to established patients only.

CMS is also considering a restructuring of the G-code bundling for these services, but that piece is still open for comment and less settled than the staffing provision itself.

The Real Question: Can Your Employed Team Carry the Panel

This is where most of the coverage on this rule stops short, and where it actually gets useful. The rule doesn’t ask whether you can hire someone. It asks whether an employed team, at a realistic headcount, can carry the monitoring load your patient panel generates. That’s a capacity question, not a hiring question, and the two have different answers.

Go back to that roughly one-monitor-per-200-patients planning ratio. If that number holds, a 1,000-patient RPM panel needs five employed monitors doing nothing but review and outreach, full time, to stay inside CMS’s own service requirements, the same requirements the 2024 OIG report found 43% of enrollees weren’t fully getting. Hiring to that ratio with manual chart review is expensive and slow to staff. The ratio only gets survivable if something does first-pass triage before a human ever opens a chart.

That’s the mechanism behind RPMCheck AI: voice-based daily check-ins on vitals and symptoms, with real-time flagging of high-risk patients, so an employed nurse’s day starts with the patients who actually need attention rather than a flat list to work through in order. In practice, this has moved daily check-in completion up 38%, which is the difference between a monitor covering 200 patients and a monitor covering considerably fewer before burning out on alert fatigue.

I’ve seen the staffing-capacity version of this play out directly, on an elderly-care RPM platform Mindbowser built that reached 90% patient engagement with CPT-code billing capture built into the workflow. The documentation CMS is now asking every program to tighten up on was already structured into how the monitoring happened, not bolted on afterward.

If you’re weighing whether to build that triage layer yourself or configure an existing one, ConnectHealth is built for exactly this: the monitoring workflow, alerting, and EHR write-back are already there, and what actually gets configured per practice is the alert-threshold rules, the EHR write-back mapping, and the audit trail that the mandatory initiating visit now requires you to keep. Renting a generic platform gets you running fast but tuned to someone else’s median patient.

Building the whole thing yourself means owning the concurrency and audit logic from scratch. Configuring a pre-built use case is where most practices land, because the hard part, the triage and documentation discipline, is already solved, and what’s left is genuinely yours to set.

The Same Decision, Different Department

If this sounds familiar, it should. RCM teams have been asking the exact same build-or-configure-or-buy question about their own staffing and tooling for years, for the same underlying reason: a compliance requirement creates a capacity problem, and the fix is rarely just “hire more people.” The departments are different. The decision tree is the same one.