A cardiology practice buys two hundred Bluetooth blood pressure cuffs, hands them out to patients with uncontrolled hypertension, and waits for the reimbursement to show up. Three months later, the billing team is still arguing with the EHR vendor about where the device-transmission logs live, half the patients have stopped syncing their cuffs, and nobody can say with confidence whether the program is breaking even. This is the ordinary lifecycle of a remote patient monitoring (RPM) rollout that skipped the operational planning stage and went straight to procurement.

RPM is not a hard technology problem. Bluetooth-enabled cuffs, scales, pulse oximeters, and glucometers are mature, inexpensive, and easy to ship. The hard problem is the connective tissue: getting device data into the electronic health record in a form clinicians will actually look at, staffing the monitoring function so it does not silently become “one more thing” for an already-stretched care team, and billing it in a way that survives an audit. This guide walks through the current Medicare reimbursement structure, the operational pieces that determine whether an RPM program is financially sustainable, and the questions that come up most often when health systems evaluate whether to build or expand a program.

What Counts as Remote Patient Monitoring, and What Doesn’t?

RPM, in the Medicare billing sense, refers to the collection and clinical interpretation of physiologic data — blood pressure, weight, blood glucose, pulse oximetry, respiratory flow — transmitted from an FDA-registered medical device in the patient’s home to the care team. It is billed under the American Medical Association’s Current Procedural Terminology (CPT) codes administered through Medicare Part B, and its rules are set out in the annual Medicare Physician Fee Schedule (PFS) published by the Centers for Medicare & Medicaid Services (CMS).

RPM is often confused with two adjacent categories that have separate billing codes and separate rules:

  • Remote therapeutic monitoring (RTM) covers non-physiologic data — musculoskeletal status, respiratory therapy adherence, medication adherence — and uses a distinct code family (98975–98981 and newer additions). RTM has looser supervision rules in some settings, which is why physical therapy and behavioral health programs frequently use it instead of RPM.
  • Chronic care management (CCM) and remote monitoring of physiologic parameters can be billed in the same month for the same patient in some circumstances, but CMS has specific rules about which clinical staff time can be counted toward which code, and double-counting the same minutes toward two programs is a common audit finding.

Because code definitions, time thresholds, and payment amounts are revised through CMS rulemaking every year — and have changed materially for 2026 — none of the figures or thresholds below should be treated as fixed. Program leaders should confirm current-year specifics against the CMS Physician Fee Schedule and related guidance before finalizing billing workflows. This article is a technology and operations overview, not billing or legal advice.

What Are the CMS RPM CPT Codes, and What Does Each One Cover?

The core RPM code family, as historically defined by CMS, separates the “getting the technology working” phase from the “clinical staff time spent managing the patient” phase:

CPT 99453 — Initial Setup and Patient Education

Billed once per episode of care, when a new monitoring device is provided to a patient and clinical staff educate the patient (or caregiver) on its use. It is not billable again for the same episode simply because a device is swapped or a reading is missed — it is a one-time setup fee tied to onboarding a patient onto a new monitoring program.

CPT 99454 — Device Supply and Data Transmission

Covers the device(s) and the daily recording and transmission of data over a 30-day period. Historically, CMS required at least 16 days of readings within that 30-day window before 99454 could be billed at all — commonly referred to as the “16-day rule.” That threshold has been a persistent friction point for programs, because a single vacation, hospitalization, or lapse in patient engagement could knock an entire month’s device fee out of billability, and CMS has revisited it repeatedly in rulemaking.

CPT 99457 and 99458 — Treatment Management

99457 covers the first 20 minutes per calendar month of clinical staff, physician, or other qualified health care professional time spent on RPM management activities that include at least one interactive communication with the patient or caregiver. 99458 is the add-on code for each additional 20-minute increment in the same month. These codes are about clinical judgment and interaction time, not just data collection — a nurse reviewing a dashboard without patient contact generally does not satisfy the interactive-communication requirement.

CPT 99091 — Physician or QHP Data Review

An older, narrower code covering at least 30 minutes of physician or qualified health care professional time interpreting device data over a 30-day period, without the interactive-communication requirement built into 99457. It is billed less frequently than 99457/99458 in current practice but remains a valid alternative in certain workflows.

2026 Changes Worth Flagging

CMS finalized changes affecting RPM and RTM billing for calendar year 2026, including lower time and data-day thresholds intended to make monitoring billable for shorter engagement periods — for example, provisions allowing device-supply billing when data is collected for as few as two to fifteen days in a 30-day period (via a new lower-threshold code, alongside the existing 16-day code rather than replacing its threshold), and shorter treatment-management time increments in addition to the existing 20-minute blocks. New and revised codes have accompanied these changes. Because this rulemaking cycle is active and payment amounts adjust annually through the Physician Fee Schedule, program leaders should verify current thresholds, code numbers, and payment rates directly against CMS.gov and current-year Medicare Learning Network guidance rather than relying on any single article, including this one.

Medicare’s RPM coverage has historically required an established patient relationship — generally meaning the billing practitioner or another clinician of the same specialty in the same group practice has furnished a professional service to the patient within a defined look-back period. This is a meaningful operational constraint: RPM has generally not been available as a stand-alone intake mechanism for patients with no prior relationship to the practice, which shapes how health systems design enrollment (typically, a discharge or an office visit triggers the RPM referral, rather than direct-to-patient marketing).

Coverage extends to both chronic and acute conditions where remote physiologic data would reasonably inform clinical management — hypertension, heart failure, diabetes, COPD, and post-surgical monitoring are common use cases — but the device and the condition need a documented clinical rationale in the medical record.

Patient consent is required before or at the time RPM services begin. CMS has permitted verbal consent, documented in the chart, rather than requiring a separately signed form, and consent can be obtained by auxiliary clinical staff under general supervision rather than only by the billing practitioner. Programs should still document consent carefully: what data is collected, how it’s transmitted, who reviews it, and how the patient can opt out. This is as much a compliance safeguard as a regulatory checkbox, since consent documentation is a routine audit target.

How Does Device Data Actually Get Into the EHR?

This is where most RPM programs succeed or fail operationally. Three integration patterns are common:

Direct HL7/FHIR Integration

Device or platform vendors push structured data (typically via HL7v2 interfaces or FHIR APIs) directly into the EHR as discrete, flowsheet-ready values. This is the most clinically usable pattern — readings appear alongside other vitals, trend automatically, and can trigger EHR-native alerts — but it requires interface-build effort and often a fee from both the EHR vendor and the RPM platform vendor.

Embedded Dashboard / SMART on FHIR Launch

The RPM platform runs as a separate application that launches from within the EHR session (via a SMART on FHIR context), giving clinicians a single sign-on view of the monitoring dashboard without full data-level integration. This is faster to stand up than a full interface build but leaves monitoring data outside the native EHR record unless a summary note is manually or automatically pushed back in.

Standalone Portal With Manual Documentation

The RPM vendor’s portal is entirely separate from the EHR, and clinical staff manually chart summary findings and billed time into the EHR after reviewing the portal. This is the slowest and most error-prone pattern, common among smaller practices or early-stage pilots, and it is also the pattern most likely to generate audit-defensibility problems because the “audit trail” linking device data to billed time lives in two disconnected systems.

Health IT leaders evaluating RPM vendors should ask specifically about interface standards supported (HL7v2, FHIR R4), where the audit trail for billed time and data-day counts lives, and whether that trail is exportable in the event of a payer audit — not just whether the vendor “integrates with Epic” or “integrates with Cerner,” which vendors describe inconsistently.

What Staffing Model Actually Works?

The most consequential design decision in an RPM program is who monitors the dashboard and manages patient outreach — because that decision determines both clinical quality and program economics.

Centralized RPM Nursing Team

Many health systems route physiologic data to a centralized team of RPM-dedicated registered nurses or medical assistants, working from standardized clinical protocols and escalation pathways (a blood pressure above a defined threshold triggers an outreach call; a persistently missing data stream triggers a re-engagement call). This model can let a smaller number of staff manage a much larger monitored population than a traditional one-to-one phone-based chronic disease management model, because the dashboard surfaces exceptions rather than requiring staff to review every reading for every patient.

Embedded Practice Staff

Smaller practices sometimes fold RPM review into the existing care team’s daily workflow rather than building a dedicated function. This avoids new hiring but risks the monitoring function being deprioritized during high-volume clinical days, which shows up downstream as missed data-day thresholds and unbilled or under-billed months.

Outsourced Monitoring Services

Third-party RPM monitoring companies handle day-to-day dashboard review and first-line patient outreach, escalating to the practice’s own clinicians only for clinically significant findings. This reduces internal staffing burden and can improve consistency, but it introduces a vendor-management relationship that needs clear escalation SLAs and clear contractual ownership of the documentation used to support billing.

Whichever model is chosen, using the most expensive clinical staff — attending physicians, in particular — for routine day-to-day dashboard review is generally a poor use of both their time and the program’s margin. RPM management time (99457/99458) can generally be furnished by clinical staff under general supervision, which is precisely the design point that makes a nurse- or MA-led model viable.

What Does the Program Economics Actually Look Like?

RPM reimbursement rates are modest per patient per month and are adjusted annually through the Physician Fee Schedule, so program economics depend far more on scale, staffing efficiency, and patient retention than on any single code’s payment amount. A few structural factors matter more than the headline dollar figures:

  • Enrollment volume and retention. A handful of enrolled patients rarely covers the fixed costs of a monitoring program (device inventory, platform licensing, staff training). Programs generally need a meaningful, sustained patient panel to make the staffing model economical, and patient attrition — people who stop syncing devices after a few weeks — directly erodes billable months.
  • Device logistics. Shipping, provisioning, troubleshooting, and eventually retrieving devices is an operational cost center that is easy to underestimate. Cellular-connected devices reduce patient setup friction (no app pairing, no home Wi-Fi dependency) but typically cost more per unit and may carry ongoing connectivity fees.
  • Documentation defensibility. Payment recovered through billing that cannot survive an audit is not real revenue. Programs should be able to produce, for any billed month, the device transmission log showing the data-day count and a time log showing the clinical staff minutes and the nature of the interactive communication.
  • Payer mix. Medicare Part B coverage and payment rules are the most extensively documented, but Medicare Advantage plans and commercial payers vary in whether and how they cover RPM, and state Medicaid programs vary further still. A program built purely around Medicare fee-for-service rules may need separate workflows for other payers.

Because payment rates change annually and because commercial and Medicaid coverage varies by payer and state, any specific dollar-per-patient-per-month projection should be treated as a planning estimate to be validated against current contracts and the current-year Physician Fee Schedule, not a fixed number.

Frequently Asked Questions

What is the 16-day rule in remote patient monitoring billing?

The 16-day rule refers to CMS’s historical requirement that a patient transmit at least 16 days of physiologic data within a 30-day period before CPT 99454 (device supply) can be billed for that period. CMS has revisited this threshold in recent rulemaking, including proposals for shorter data-collection windows, so practices should confirm the current-year requirement against CMS guidance before billing.

Can remote patient monitoring and chronic care management be billed together?

In some circumstances, yes, but CMS restricts double-counting the same clinical staff minutes toward both RPM treatment-management codes and CCM codes in the same month. Programs need separate, auditable time logs for each service category, and coding decisions should be reviewed with compliance or billing counsel familiar with current CMS rules.

No. CMS has permitted verbal consent for RPM services as long as it is documented in the patient’s medical record before or at the time services begin. Many health systems still use a written consent process internally for clarity and audit support, but a signed form is not a strict CMS requirement.

What devices qualify for remote patient monitoring reimbursement?

Devices must meet the FDA’s definition of a medical device and be capable of automatically transmitting physiologic data — common examples include Bluetooth or cellular blood pressure cuffs, weight scales, pulse oximeters, and glucometers. Consumer wellness devices that are not FDA-registered as medical devices generally do not satisfy CMS’s device requirements for RPM billing.

How much does a remote patient monitoring program cost to run?

Costs vary widely based on device type, patient panel size, staffing model, and EHR integration approach, and no single figure applies broadly. Fixed costs include device inventory and platform licensing; variable costs include staff time, patient onboarding, and device logistics. Programs should model costs against their own payer mix rather than relying on published reimbursement averages alone.