Stop Using Remote Patient Monitoring - It Contravenes Medicare
— 6 min read
Medicare’s proposed ban on third-party remote monitoring vendors would stop many home-based health services from being reimbursed, limiting patient access to continuous care. The change comes as CMS looks to tighten physician involvement, but the ripple effects could be far broader than policymakers anticipate.
Stat-led hook: In July 2026, CMS announced a proposal that would affect over 1,000 remote-monitoring firms that currently bill Medicare for RPM services, according to the latest industry briefings.
Medical Disclaimer: This article is for informational purposes only and does not constitute medical advice. Always consult a qualified healthcare professional before making health decisions.
Understanding Medicare’s RPM Rules
When I first heard the term “RPM” I thought it meant “revolutions per minute,” like in a car engine. In health care, RPM stands for Remote Patient Monitoring, a set of services that let clinicians track a patient’s vital signs, symptoms, or device data from home. Medicare has been paying for RPM since 2018, but only if a physician - or a qualified health professional acting under the physician’s direction - directly oversees the data.
- Remote Patient Monitoring (RPM): Technology that collects health data (blood pressure, glucose, weight, etc.) at a patient’s residence and transmits it to a health-care provider.
- Third-party vendor: A company that supplies the devices, software, and sometimes staff to manage the data, without being a traditional health-care provider.
- Physician-directed: Medicare requires a physician to review and act on the data at least once every 30 days.
- CMS (Centers for Medicare & Medicaid Services): The federal agency that sets payment rules for Medicare and Medicaid.
In my experience working with a home-health agency, the RPM workflow looks like this:
- Patient receives a Bluetooth-enabled blood pressure cuff.
- Device automatically uploads readings to a secure cloud.
- A vendor’s care team screens the data for alerts.
- The physician reviews flagged trends and writes a care plan.
- Medicare reimburses the vendor for the service, provided the physician’s signature is attached.
Why does this matter? Because the reimbursement stream has enabled small startups to bring affordable monitoring to seniors with chronic conditions - something that would be unaffordable for most independent physicians.
Key Takeaways
- Medicare’s RPM rule hinges on physician oversight.
- The 2027 proposal targets third-party vendors.
- Many seniors rely on RPM for chronic-disease management.
- Alternative compliance paths exist but cost more.
- Stopping vendors could shrink home-care market.
What the Proposed Ban Actually Means
When I first read the CMS draft, the headline “CMS Proposes to Restrict Outsourced Remote Monitoring Services” felt like a bombshell. The proposal would bar vendors that are not directly employed by a Medicare-participating provider from billing RPM codes. In plain language, a company that supplies a smartwatch and runs the data center could no longer get paid for its services unless a physician’s office hires the company as a subcontractor.
Critics argue the change is needed to curb “phantom billing,” where vendors bill for services that never reach a patient. However, the data from CMS Proposes to Restrict Outsourced Remote Monitoring Services Under Medicare outlines the specific language, emphasizing “closer physician involvement” and “lower device reimbursement.” The proposal also hints at new documentation requirements that could increase administrative burden for both physicians and vendors.
From a contrarian perspective, the ban might be solving a problem that isn’t as widespread as regulators think. In my work with a rural clinic, we never saw phantom billing because our vendor provided transparent audit logs. Instead, the biggest challenge was ensuring that physicians had enough time to review data without burning out.
Moreover, the ban could unintentionally push patients toward less-integrated solutions. If a vendor can’t bill, they may discontinue service, forcing patients to buy expensive, consumer-grade devices that lack clinical validation. That’s a step backward for health equity.
The Real Impact on Patients and Providers
Imagine a 78-year-old with heart failure living alone. She uses a Bluetooth scale that alerts her nurse when she gains more than two pounds - a sign of fluid buildup. The vendor’s platform sends the reading to the clinic, the physician reviews it, and Medicare reimburses the vendor for the RPM encounter. Under the proposed ban, the vendor would lose that reimbursement unless the clinic hires them as an employee. The clinic would either absorb the cost or, more likely, drop the service altogether.
In my experience, the loss of vendor-driven RPM leads to three concrete outcomes:
- Reduced monitoring frequency: Clinics may limit RPM to once a month to save on staffing.
- Higher out-of-pocket costs: Patients may have to purchase devices themselves, often at retail prices that exceed Medicare’s rates.
- Increased hospital readmissions: Without timely alerts, conditions can worsen, leading to costly admissions.
CMS’s own language acknowledges that tighter physician involvement could improve clinical decision-making, but it does not address the capacity gap. A 2026 industry survey (referenced in CMS proposes RPM reimbursement updates, requests information on reimbursing for SaaS) shows that 68% of vendors say they would need to raise fees by at least 30% to cover the extra physician overhead. Those higher costs would inevitably be passed to patients or shrink the service pool.
Physicians also face a hidden cost: the time spent documenting physician oversight for each RPM encounter. If a doctor must sign off on 10-15 patient streams daily, the administrative load can become overwhelming, leading to documentation fatigue and potential errors.
Alternative Paths: How the Industry Can Adapt
Rather than an outright ban, there are several middle-ground strategies that could preserve the benefits of RPM while addressing CMS’s concerns about oversight and fraud.
| Strategy | Pros | Cons |
|---|---|---|
| Physician-vendor partnership contracts | Keeps vendor expertise; spreads compliance cost. | Requires legal work; may limit vendor choice. |
| Hybrid SaaS-billing model | Allows vendors to bill under a “software as a service” code. | New CPT codes not yet approved. |
| Enhanced audit-trail technology | Provides transparency, satisfies CMS. | Initial implementation cost. |
In my consulting work, I’ve seen the first option work best for midsized home-health agencies. By signing a joint-venture agreement, the physician’s practice can claim the RPM codes while the vendor supplies the technology and staff. The arrangement satisfies CMS’s physician-directed rule without forcing the practice to hire a full-time monitoring team.
The second option - leveraging emerging SaaS-specific billing codes - has promise but hinges on CMS finalizing those codes. If approved, vendors could bill directly for software usage, separating device costs from clinical oversight. This would keep the financial flow intact while still ensuring a physician’s signature on each encounter.
Finally, investing in audit-trail technology can pre-empt fraud concerns. A blockchain-based ledger, for instance, can timestamp every data upload and physician review, creating an immutable record that auditors can verify instantly. While the upfront cost can be steep, the long-term savings from reduced audit penalties could outweigh the expense.
Common Mistakes When Interpreting the Ban
Warning: It’s easy to jump to conclusions. Below are the three most frequent misunderstandings I encounter:
- Assuming all RPM will disappear. The ban targets only third-party vendors not attached to a Medicare provider. Physician-owned programs can continue.
- Thinking the rule applies retroactively. The proposal is for the 2027 Physician Fee Schedule; services delivered before the effective date remain reimbursable.
- Believing higher physician involvement automatically improves outcomes. Studies show that without adequate staffing, added oversight can delay alerts, negating any clinical benefit.
By keeping these pitfalls in mind, stakeholders can craft smarter responses rather than reacting out of fear.
Glossary
- RPM (Remote Patient Monitoring): Clinical service that collects patient health data at home and transmits it to a provider.
- CMS (Centers for Medicare & Medicaid Services): Federal agency overseeing Medicare reimbursement rules.
- Third-party vendor: Non-provider company that supplies RPM devices or software.
- Physician-directed: Requirement that a physician review and sign off on RPM data.
- SaaS (Software as a Service): Cloud-based software model where users pay subscription fees.
FAQ
Q: Will the ban stop all remote monitoring for Medicare patients?
A: No. The proposal only blocks third-party vendors that are not directly employed by a Medicare-participating provider. Physician-run programs can continue to bill RPM codes.
Q: How will the change affect device costs for patients?
A: If vendors lose Medicare reimbursement, many will pass the cost to patients, raising out-of-pocket expenses. Some may drop low-margin devices altogether, limiting options for seniors on fixed incomes.
Q: Can providers still use third-party technology under a different billing model?
A: Yes, if they enter a partnership where the provider bills for the service while the vendor supplies the technology. Emerging SaaS-specific codes could also allow vendors to bill directly once CMS finalizes them.
Q: What evidence exists that “phantom billing” is a widespread problem?
A: CMS has not published concrete numbers on phantom RPM billing. Industry surveys suggest the issue is relatively isolated, especially among vendors that provide transparent audit logs.
Q: What should a small practice do now to prepare?
A: Start reviewing existing vendor contracts, assess internal staffing capacity for RPM oversight, and explore partnership models that keep vendor expertise while meeting the new physician-directed requirement.