Building Remote Patient Monitoring Products: CPT Codes 99453/99454/99457, Device Integration, and the Billing Architecture That Actually Works

In February 2023, a remote patient monitoring founder in Atlanta came to us with a product that had been live for eight months. Seed stage, $5.1M raised, building an RPM platform for hypertension management targeting primary care practices in the Southeast. Forty-three enrolled practices. 1,200 active patients. A technically sound device integration with Withings blood pressure monitors and a clean clinical dashboard.

His revenue was $0.

Not because the practices weren’t enrolled. Not because patients weren’t using the devices. Because his billing architecture was wrong in three ways that Medicare does not forgive retroactively.

First: his platform was documenting device setup, CPT 99453, but not capturing the date the patient first transmitted data. Medicare requires that CPT 99453 is billed only after the patient has transmitted data for the first time, not on device delivery or device setup. His system was billing 99453 on device delivery. Every single claim had been denied.

Second: his platform was counting calendar days of device use but not verifying 16 days of data transmission within a 30-day period, the threshold required for CPT 99454. His “days active” metric was counting days the device was powered on, not days a qualifying reading was transmitted. 340 of his 1,200 patients had technically enrolled but never transmitted 16 qualifying days of data in any 30-day window. He had billed 99454 for all of them. Every claim denied.

Third: his clinical monitoring documentation, required for CPT 99457 (20 minutes of interactive communication and care management per calendar month), was stored as free-text notes with no timestamp at the individual interaction level. Medicare auditors require that 99457 documentation show the date, the duration, and the nature of each interaction that contributes to the 20-minute threshold. His notes showed the total time. Not the component interactions.

Eight months of denials. $340,000 in revenue he could not recover retroactively because his documentation did not meet Medicare’s requirements at the time the service was rendered.

The billing architecture for an RPM product is not a feature you add after you validate the clinical model. It is the clinical model. Build it correctly from Day 1 or do not build an RPM product.

Eight Things RPM Founders Get Wrong Before They Build

• Wrong #1: “RPM billing is straightforward, we bill CPT codes for monitoring.”

RPM billing is one of the most operationally complex billing models in digital health. Four CPT codes (99453, 99454, 99457, 99458) with distinct documentation requirements, distinct thresholds, distinct billing frequencies, and distinct coverage policies across Medicare, Medicaid, and commercial payers. Getting one requirement wrong on one code results in denial for that code for that patient for that month, and unlike a missed feature, a denied claim often cannot be corrected retroactively.

• Wrong #2: “We’ll integrate whatever device the practice already uses.”

Device integration is the highest-variance technical challenge in RPM development. Every device manufacturer has a different data transmission protocol, a different API architecture, a different data format, and a different approach to cellular versus Bluetooth versus WiFi connectivity. “We support any device” is not a product feature. It is a engineering commitment that requires a device integration framework, a device certification process, and a device support operation. Scope your device integrations explicitly in discovery.

• Wrong #3: “Days of data transmission is easy to count.”

The CPT 99454 requirement is 16 or more days of data transmission within a 30-day period. “Days of data transmission” has a specific meaning: a day on which at least one qualifying physiological reading was transmitted from the device to the platform. Not a day on which the device was powered on. Not a day on which the patient opened the app. Not a day on which the device connected to Bluetooth. A transmitted reading. Your data model must track transmission events at the reading level, not the session level, not the device ping level, to correctly calculate the 99454 threshold.

• Wrong #4: “The clinical dashboard is the product.”

The clinical dashboard is the UI. The product is the care management workflow that generates billable CPT 99457 and 99458 revenue. A beautiful dashboard that shows a patient’s blood pressure trend over 30 days generates zero revenue if no clinical staff member spends 20 minutes in interactive care management with the patient that month. The workflow that supports clinical staff in delivering and documenting that care management, the task queue, the interaction timer, the documentation template, the attestation workflow, is the revenue-generating layer of the product.

• Wrong #5: “Medicare covers RPM and that’s our payer strategy.”

Medicare covers RPM under specific conditions for specific patient populations. Medicare Advantage plans have their own RPM coverage policies that differ from traditional Medicare. Commercial payers have their own coverage determinations, some have issued positive coverage policies for RPM, many have not, and those that have often require prior authorization. Medicaid RPM coverage varies dramatically by state. Know your payer mix before you architect your billing system.

• Wrong #6: “The device company handles the data transmission.”

Device manufacturers transmit device data, but where it goes, how it is secured, how it is formatted, and how it is stored in your platform is your responsibility, not the manufacturer’s. You are the HIPAA Business Associate for the patient data your platform receives, processes, and stores. The device manufacturer may also be a Business Associate if they have access to identified patient data. Every device integration requires a BAA analysis.

• Wrong #7: “We don’t need clinical staff, the platform monitors automatically.”

CPT 99457 and 99458, which together generate 70-80% of the recurring RPM revenue, require interactive communication between the patient and clinical staff. Not automated alerts. Not app notifications. Interactive communication. A clinical monitoring model that relies on automated alerts without clinical staff follow-through does not generate 99457/99458 revenue. Every RPM product needs a clinical operations layer, either within the practice, outsourced to an RPM clinical management service, or built into the platform as a managed care service.

• Wrong #8: “We can add payer-specific billing rules later.”

Payer-specific billing rules, coverage policies, prior authorization requirements, claim submission formats, modifier requirements, are not a billing module you configure after launch. They are architectural constraints that affect your data model, your documentation requirements, your claim generation logic, and your denial management workflow. Build your billing architecture as a configurable rules engine from Day 1. Adding a new payer should be a configuration update, not a sprint.

What RPM Actually Is, And the Four Product Categories Founders Confuse

Before scoping your build, get precise about which category of RPM product you are building. The regulatory requirements, the device integration needs, the billing architecture, and the clinical workflow are materially different across these four categories.

• Category 1: Chronic Disease RPM (the core market)

Continuous physiological monitoring for patients with chronic conditions, hypertension, diabetes, heart failure, COPD, obesity. The most mature RPM market and the primary target for Medicare RPM billing under CPT 99453/99454/99457/99458.

Devices: blood pressure monitors, pulse oximeters, glucometers, weight scales, spirometers. Clinical workflow: daily readings transmitted, clinical staff review alerts and trends, monthly care management interactions for billing.

This is the category most RPM founders are building. It has the clearest regulatory framework, the most established payer coverage, and the most validated clinical evidence base.

• Category 2: Post-Acute and Transitional Care RPM

Monitoring of patients transitioning from hospital to home, post-surgical, post-cardiac event, post-hospitalization for CHF or COPD exacerbation. Shorter monitoring windows (30–90 days), higher alert thresholds, tighter clinical response protocols. Different billing model, often bundled into hospital discharge billing rather than stand-alone CPT code billing.

The clinical stakes are higher (patients are recently discharged and at elevated readmission risk), the device integration requirements are similar to chronic disease RPM, but the workflow and billing architecture are materially different.

• Category 3: Specialty RPM

Disease-specific monitoring programs, oncology symptom management, maternal-fetal monitoring, post-transplant monitoring, mental health biometric monitoring (HRV, sleep, activity for depression and anxiety management).

May use standard consumer devices (smartwatches, fitness trackers) or medical-grade specialty devices. Billing may follow the standard RPM CPT codes or specialty-specific billing frameworks depending on the clinical use case.

• Category 4: Consumer Health Monitoring (Not RPM)

Consumer wearable data (Apple Watch, Fitbit, Oura) aggregated in a wellness platform without physician order, without clinical staff monitoring, and without CPT code billing. This is not RPM under CMS definitions.

It may be a valuable product, but it is not a Medicare-billable RPM service and should not be positioned as one. The regulatory risk of billing CPT 99454 for consumer wearable data without a physician order and clinical oversight is significant.

From a US founder call: “I spent six months building what I thought was an RPM platform. When I brought in a healthcare billing consultant before launch, she told me my product was a consumer wellness app, not an RPM platform, because I had not built the physician order workflow or the clinical monitoring documentation.

I had the devices. I had the dashboard. I did not have the clinical structure that makes it billable RPM. I rebuilt the clinical workflow layer in four months. That conversation cost me six months of misdirected development.”, Seed-stage RPM founder, Houston.

The Regulatory Stack for RPM Products in 2026

RPM products operate under a regulatory framework that combines HIPAA, Medicare billing regulations, state telehealth laws, and, for certain device types, FDA medical device regulations. Here is the full stack.

1. HIPAA, The Baseline

All patient physiological data transmitted through an RPM platform is ePHI. The Privacy Rule, Security Rule, and Breach Notification Rule all apply. The device manufacturer is a potential Business Associate, if the manufacturer has access to identified patient data (name, date of birth, readings linked to an individual patient), they need a BAA.

The cellular carrier for cellular-connected devices is generally not a Business Associate (they transmit but do not access the data content) but confirm this with your healthcare attorney for your specific device architecture.

2. CMS RPM Billing Regulations

The Centers for Medicare and Medicaid Services defines RPM eligibility, documentation requirements, and billing rules in the Medicare Physician Fee Schedule. The current framework (confirm current rules with a healthcare billing specialist, CMS updates the Physician Fee Schedule annually):

• RPM services must be ordered by a physician, NPP (nurse practitioner, physician assistant), or other qualified healthcare professional
• The patient must have a chronic condition or acute condition (the acute condition expansion was made permanent post-PHE)
• The device must be a medical-grade device that automatically transmits data, not a consumer wearable without FDA clearance as a medical device
• Consent must be obtained from the patient before RPM services begin (verbal consent acceptable, must be documented)
• The monitoring period is a calendar month (not a rolling 30 days)

3. FDA Medical Device Regulations

Devices used in RPM programs may be subject to FDA regulation as medical devices under 21 CFR Part 820. Blood pressure monitors, pulse oximeters, and glucometers used in clinical RPM programs are typically Class II medical devices that have received FDA 510(k) clearance. Consumer wearables (Apple Watch, Fitbit) may have FDA clearance for specific features (ECG, blood oxygen) but may not qualify as the “medical-grade device” required for Medicare RPM billing, confirm device eligibility with a healthcare billing specialist before committing to a device.

Your software platform is generally not a medical device under FDA definitions if it does not itself perform a diagnostic or therapeutic function, it is a data transmission and display platform. However: if your platform’s alert logic performs clinical decision support that meets the FDA’s SaMD definition (for example, an AI that identifies a patient as likely to experience a cardiac event based on their RPM data), the SaMD classification question applies.

4. State Telehealth and RPM Laws

RPM is generally considered a telehealth service and is subject to state telehealth laws. Most states have enacted telehealth coverage parity laws that include RPM, but coverage parity does not mean reimbursement parity and does not mean all payers in the state cover RPM.

State Medicaid programs have their own RPM coverage determinations. Some states have state-specific RPM regulations beyond CMS rules. Confirm state-specific requirements for your target geography with a healthcare billing specialist.

The Physician Order Requirement: Medicare RPM requires a physician order before monitoring begins. This is not optional and it is not a billing nuance, it is a care delivery requirement. Your platform must have a physician order workflow: the ordering provider creates an order specifying the condition being monitored, the device prescribed, the monitoring parameters, and the monitoring duration. The order is stored in the patient record and referenced in billing documentation.

Compliance trap: The CMS RPM billing rules specify that the device used must be a medical-grade device that automatically transmits data, meaning the patient does not manually enter data into a phone app. A glucometer that requires the patient to open the app and manually log their reading does not qualify for RPM billing under CMS definitions.

A glucometer that automatically transmits readings via Bluetooth to the platform (with no patient data entry required) qualifies. This distinction determines which devices you can support for Medicare RPM billing and must be verified before you scope your device integration list.

The 16-Question RPM Product Readiness Audit

Work through these sixteen questions before your engineering team writes a line of code.

• Which chronic condition(s) is your RPM platform targeting?

Hypertension, diabetes, heart failure, COPD, obesity, atrial fibrillation, chronic kidney disease, or multi-condition? The condition determines the device types, the physiological parameters monitored, the alert thresholds, the clinical workflow, and the clinical evidence base you can cite for payer coverage arguments.

• Which device types will you support at launch?

Blood pressure monitor, pulse oximeter, glucometer, weight scale, spirometer, ECG monitor, continuous glucose monitor (CGM), smartwatch with FDA-cleared features? Scope your device integrations explicitly, “we support any device” is not a scope, it is a roadmap commitment without a timeline.

• Are the devices you plan to support FDA-cleared medical devices that automatically transmit data?

Confirm device eligibility for Medicare RPM billing before committing to a device integration. Consumer wearables without FDA clearance for the specific physiological parameter being monitored may not qualify.

• What is your clinical workflow model?

Practice-based RPM (the practice has clinical staff who manage the monitoring program), outsourced clinical management (you provide clinical staff as a managed service), or hybrid? The clinical workflow model determines your revenue model and your product architecture.

• Who are your target customers, practices, health systems, or direct-to-consumer?

Practice-based RPM (billing through the practice’s provider NPI), health system RPM (billing through the health system’s billing department), or a direct-to-consumer model (patients enroll directly, you bill Medicare directly as an RPM vendor). Each model has different contracting, different billing architecture, and different regulatory requirements.

• Which payers are you targeting, Medicare FFS, Medicare Advantage, Medicaid, or commercial?

Each payer has different RPM coverage policies, different documentation requirements, different claim submission formats, and different reimbursement rates. Know your payer mix before you architect your billing system.

• Have you built the physician order workflow?

Medicare RPM requires a physician order before monitoring begins. Who creates the order? In what format? Where is it stored? How is it referenced in billing documentation?

• Have you designed the 99453 billing trigger?

CPT 99453 (device setup and patient education) is billed once per patient per device. The billing trigger is the date the patient first transmits data, not the date of device delivery, not the date of device setup. Does your system capture and store the first transmission date separately from the enrollment date?

• Have you designed the 99454 threshold calculation?

CPT 99454 (device supply with daily recordings) requires 16 or more days of data transmission within a 30-day calendar month period. Does your system track transmission events at the reading level, the specific date each qualifying reading was transmitted, and calculate the 16-day threshold correctly against the calendar month?

• Have you designed the 99457 documentation workflow?

CPT 99457 (20 minutes of interactive communication and care management) requires documentation of the date, duration, and nature of each interaction that contributes to the 20-minute threshold. Does your system support a timestamped interaction log at the individual interaction level, not just a total-time field?

• Have you designed the 99458 add-on workflow?

CPT 99458 is an add-on code to 99457, billed for each additional 20-minute increment of care management beyond the first. Does your system track cumulative interaction time per patient per calendar month and trigger 99458 billing when the threshold is crossed?

• What is your denial management workflow?

RPM claims will be denied. Denial rates for RPM billing range from 15–35% in the first year of a new program. Does your system capture denial reason codes, route denials to the appropriate correction workflow, and track the appeal and resubmission process?

• What is your patient consent documentation workflow?

CMS requires documented patient consent before RPM services begin. Verbal consent is acceptable but must be documented. Does your system capture consent at enrollment with a timestamp, the name of the staff member who obtained consent, and the consent method (verbal or written)?

• What is your device fleet management model?

For practice-based RPM where you supply devices: how do you track which device is assigned to which patient, when it was shipped, when it was returned, when it needs to be reconditioned, and whether it is functioning correctly? Device fleet management is a supply chain and operations challenge that requires software support.

• What are your alert threshold and escalation protocols?

What reading values trigger an alert? What does the alert do, notify the patient, notify the clinical staff, or both? What is the escalation protocol when a patient does not respond to an alert? Who is responsible for the clinical response to a critical alert (a blood pressure reading indicating hypertensive crisis, a blood glucose reading indicating hypoglycemia)?

• What is your data retention policy for device readings?

Device readings are ePHI. HIPAA minimum retention: 6 years. Medicare audit requirements may require retention of billing documentation for 7 years (the Medicare audit lookback period). Build your retention policy around the longer of the two requirements.

CPT Code Architecture, The Billing Foundation Every RPM Product Must Get Right

This is the section most RPM products get wrong. Not because the CPT codes are complex, they are not, once you understand them.

But because implementing them correctly requires your data model, your documentation workflow, your clinical workflow, and your claim generation logic to all be built around the specific requirements of each code. Here is the full picture.

• CPT 99453, Initial Setup and Patient Education

What it covers: Remote monitoring of physiological parameter(s); initial; set-up and patient education on use of equipment.

Reimbursement (2026 Medicare national average): approximately $19–$21

Billing frequency: Once per patient per device type per episode of care. Not once per enrollment. Not once per year. Once per device type per episode of care, if a patient is discharged from an RPM program and re-enrolled more than 30 days later, 99453 is billable again.

Documentation required:

• Physician order for RPM
• Date patient received the device
• Date patient first transmitted data (the billing trigger, not device delivery date)
• Documentation that patient education on device use was provided

The most common billing error: Billing 99453 on the date of device delivery or device setup, before the patient has transmitted any data. The correct trigger is the date of first data transmission.

Your system must capture first transmission date separately from enrollment date and enrollment date separately from device delivery date. Three different dates, three different fields, three different billing implications.

What we’d cut: If your MVP launches with a single device type, 99453 implementation is straightforward, one billing event per patient, triggered by first transmission. Complexity increases when you support multiple device types per patient (a hypertension + diabetes patient using both a blood pressure monitor and a glucometer can bill 99453 for each device separately).

• CPT 99454, Device Supply and Daily Recordings

What it covers: Remote monitoring of physiological parameter(s); device supply with daily recording(s) or programmed alert(s) transmission, each 30 days.

Reimbursement (2026 Medicare national average): approximately $47–$52

Billing frequency: Once per 30-day calendar month period, per device type, when the threshold is met.

The threshold: 16 or more days of data transmission within the 30-day calendar month.

Documentation required:

• Physician order for RPM
• Evidence of 16 or more days of data transmission within the calendar month
• The transmission log at the reading level, the specific dates on which qualifying readings were transmitted

The most common billing error: Counting device connection days, app-open days, or Bluetooth pairing days rather than qualifying reading transmission days. The threshold is transmission of a physiological reading, not device activity. Your data model must store each transmitted reading with its transmission date, device ID, patient ID, and reading value. The 16-day calculation is performed against this reading-level dataset, not against a device activity log.

The calendar month nuance: CMS defines the 30-day period as a calendar month, not a rolling 30-day window from enrollment. A patient enrolled on January 15th has their first 99454 billing period for the month of January. If they transmit readings on 16 days in January, 99454 is billable for January. The next 99454 billing period is February, regardless of whether they have completed 30 days since enrollment.

Multi-device billing: A patient using a blood pressure monitor and a glucometer can bill 99454 for each device separately if each device meets the 16-day transmission threshold. Your billing engine must track threshold calculations by device type, not just by patient.

• CPT 99457, Remote Physiological Monitoring Treatment Management

What it covers: Remote physiological monitoring treatment management services, clinical staff/physician/other qualified health care professional time in a calendar month requiring interactive communication with the patient/caregiver during the month; first 20 minutes.

Reimbursement (2026 Medicare national average): approximately $48–$52

Billing frequency: Once per calendar month when the 20-minute threshold is met.

The threshold: 20 or more minutes of clinical staff time in interactive communication with the patient or caregiver in a calendar month. Interactive communication means real-time communication, phone call, video call, or secure messaging that includes a response within the session. Automated alerts do not count. Reviewing device data without patient interaction does not count.

Documentation required:

• The date of each interaction
• The duration of each interaction (in minutes)
• The nature of each interaction (what was discussed, what clinical action was taken)
• The name and credentials of the clinical staff member who conducted the interaction
• The total accumulated interactive communication time for the calendar month
• Attestation by the supervising physician or NPP

The most common billing error: Documenting total interaction time without documenting individual interactions. A note that says “20 minutes of care management this month” does not meet Medicare documentation requirements. The documentation must show individual interactions: “January 8: 8 minutes phone call, discussed blood pressure readings, advised medication compliance. January 15: 7 minutes phone call, discussed dietary sodium reduction. January 22: 6 minutes phone call, reviewed week’s readings, no changes to plan.” That is 21 minutes, documented correctly at the interaction level.

Who can perform 99457: Clinical staff (medical assistant, nurse, LPN, RN) under the supervision of the billing physician or NPP, or the physician or NPP directly. The supervision requirement, general supervision, means the physician or NPP does not need to be present for each interaction but must review and attest to the service.

The interaction timer: Your clinical workflow must include an embedded interaction timer that starts when a clinical staff member opens a patient’s chart and initiates contact, runs during the interaction, and stops when the interaction ends. The timer records the start time, end time, and duration. This timer record is the source of the documentation that supports 99457 billing.

• CPT 99458, Remote Physiological Monitoring Treatment Management, Add-On

What it covers: Remote physiological monitoring treatment management services; additional 20 minutes. Add-on code to 99457.

Reimbursement (2026 Medicare national average): approximately $38–$42 per additional 20-minute increment

Billing frequency: Once per additional 20-minute increment per calendar month. A patient with 45 minutes of interactive communication in a month bills 99457 (first 20 minutes) + one unit of 99458 (next 20 minutes). The remaining 5 minutes do not trigger another 99458.

Documentation required: Same as 99457, individual interaction documentation with date, duration, nature, and clinical staff name.

The architecture implication: Your billing engine must calculate cumulative interactive communication time per patient per calendar month in real time, trigger 99457 billing when 20 minutes is crossed, and trigger 99458 billing for each additional 20-minute increment. The clinical staff must be able to see where a patient stands in their monthly communication time during each interaction, “This patient has 12 minutes of documented interaction time this month. This call is 8 minutes, which will meet the 99457 threshold.”

• CPT 99091, Collection and Interpretation

What it covers: Collection and interpretation of physiological data digitally stored and/or transmitted by the patient and/or caregiver to the physician or other qualified health care professional, qualified by education, training, licensure/regulation (when applicable) requiring a minimum of 30 minutes of time.

When it applies: 99091 cannot be billed in the same calendar month as 99457. It is used for RPM programs where physician time in data review and interpretation is the primary billable activity, rather than clinical staff care management. For most practice-based RPM programs, 99457/99458 generates more revenue than 99091 and is the preferred billing code. Know which code applies to your clinical workflow model.

The billing engine architecture:

Your RPM platform’s billing engine must:

1. Track enrollment date, device delivery date, and first transmission date separately per patient per device type
2. Calculate 99453 eligibility: first transmission date received and patient education documented
3. Track daily transmission events at the reading level per patient per device type per calendar month
4. Calculate 99454 eligibility: 16+ qualifying transmission days in the calendar month
5. Track interactive communication time at the individual interaction level per patient per calendar month
6. Calculate 99457 eligibility: 20+ minutes of interactive communication in the calendar month
7. Calculate 99458 eligibility: each additional 20-minute increment above the first 20 minutes
8. Generate claim data in the correct format for each eligible code
9. Track claim submission status, payment, and denial reason codes
10. Route denied claims to the denial management workflow
11. Apply payer-specific billing rules (Medicare FFS vs. Medicare Advantage vs. commercial payer)

This is a purpose-built billing engine, not a general billing module you configure. Every RPM product must have it. Every RPM product that lacks it has unclaimed revenue and compliance exposure.

EB Index 2026: Across 14 Revenue Patient Monitoring products we have shipped since 2020, platforms with a correctly implemented billing engine captured an average of 94% of eligible CPT code revenue in their first year. Platforms without a correctly implemented billing engine, relying on manual billing workflows or repurposed general billing modules, captured an average of 61% of eligible revenue. The billing engine is not a cost center. It is the revenue engine.

Red flag: Any RPM development agency that does not discuss CPT code documentation requirements in the first week of discovery does not understand RPM billing. The CPT codes are the product. The documentation requirements are the product specification. An agency that treats billing as a post-build configuration is not equipped to build an RPM product.

Device Integration, The Technical Layer Most Agencies Underestimate

Device integration is where RPM builds go wrong most often, not in the clinical workflow, not in the billing engine, but in the device layer. Here is the full picture of what device integration actually involves.

• The device integration landscape:

Every device manufacturer has a proprietary data transmission architecture. There is no universal RPM device API. Here is the reality for the most common device categories:

Blood pressure monitors: Withings: REST API with OAuth 2.0 authentication. Well-documented. The most developer-friendly blood pressure monitor integration in the market. BAA available under Withings for Health Institutions program.

Omron: Omron Connect API. Less developer-friendly than Withings. Cellular-connected models transmit directly without phone pairing, better for patient adherence with elderly populations. BAA negotiation required.

iHealth: iHealth API. Cloud-based data storage with API access. BAA available.

A&D Medical: Cellular-connected devices (no phone required) with proprietary data transmission to A&D’s cloud. API access to A&D’s cloud data. BAA negotiation required.

Glucometers: Dexcom (CGM): Dexcom API for continuous glucose monitoring data. Well-documented. One of the cleanest device APIs in the RPM market. BAA available.

Abbott FreeStyle Libre (CGM): Abbott’s LibreView API for CGM data. Less developer-friendly than Dexcom. BAA negotiation required.

Accu-Chek: Roche’s HealthAPI for traditional glucometer data. Variable documentation quality.

One Drop: API access available. Cloud-connected glucometer with good API documentation.

Pulse oximeters: Masimo: Medical-grade pulse oximetry with API access. High accuracy. Strong clinical credibility. More expensive than consumer pulse oximeters. BAA available.

Nonin: Bluetooth-connected pulse oximeters with SDK for data capture. Medical-grade. Used in clinical RPM programs.

Weight scales: Withings: Same API infrastructure as Withings blood pressure monitors. Clean integration.

iHealth: Same API infrastructure as iHealth blood pressure monitors.

Fitbit (for weight): Fitbit API available but consumer-grade, may not qualify for Medicare RPM billing as a medical-grade device. Verify device eligibility before integration.

• The integration architecture decision:

Cellular-connected devices (no phone required): The device transmits data directly via cellular network to the manufacturer’s cloud, which then transmits to your platform via API webhook. Patient adherence is higher, there is no Bluetooth pairing step, no app installation, no phone dependency. Better for elderly patient populations with low digital literacy. Higher device cost (cellular module adds $20–$50 to device cost). Our recommendation for Medicare-target RPM programs with elderly patient populations.

Bluetooth-connected devices (phone required): The device pairs with the patient’s smartphone via Bluetooth. The mobile app transmits data to the manufacturer’s cloud or directly to your platform. Lower device cost. Higher patient adherence friction, Bluetooth pairing issues are the most common source of patient support requests in RPM programs. Better for tech-comfortable patient populations.

The device integration framework:

Building individual point-to-point integrations with each device manufacturer is a maintenance nightmare, every API version change requires a platform update, every new device type requires a new integration build. Build a device integration framework instead:

• A standardized internal data model for physiological readings: reading value, unit of measure, device type, device ID, patient ID, transmission timestamp, reading timestamp (the time the reading was taken on the device, which may differ from the transmission timestamp)
• Device-specific adapter layer: one adapter per device manufacturer that translates the manufacturer’s proprietary data format into the standardized internal model
• API polling and webhook handling per manufacturer
• Device status monitoring: is the device transmitting? When was the last reading? Is the battery low?
• Reading validation: is the reading within physiologically plausible range? Out-of-range readings may indicate device malfunction rather than a clinical event

This framework allows you to add new device types by building a new adapter, not by rebuilding the platform. Every device you support in the future is an adapter, not a rebuild.

The BAA analysis for device integrations:

Every device manufacturer whose API your platform calls, and who therefore has access to patient-identified reading data through the API relationship, is a potential Business Associate. For manufacturer-cloud-to-your-platform data flows: the manufacturer’s cloud stores patient-identified reading data and transmits it to you. The manufacturer is a Business Associate. You need a BAA with them before real patient data flows through their API.

BAA availability varies by manufacturer:

• Withings: BAA available under Withings for Health Institutions program
• Dexcom: BAA available for clinical partners
• Masimo: BAA available for clinical partners
• Most consumer-grade manufacturers: BAA not available or requires enterprise negotiation

This is not a detail. It is a pre-integration requirement. Before you start building the integration, confirm BAA availability with the manufacturer. If they won’t sign a BAA, find an alternative device.

Device fleet management:

For practice-based RPM programs where you supply devices to patients, device fleet management is an operational and software challenge:

• Inventory management: how many devices are in stock, in-transit, assigned to patients, returned, and being reconditioned?
• Device-to-patient assignment: which device (by serial number) is assigned to which patient?
• Shipping and return logistics: integration with shipping provider APIs (UPS, FedEx) for device dispatch and return label generation
• Device reconditioning: when a device is returned, is it functional? Does it need to be reconditioned before reassignment?
• Device monitoring: is each assigned device transmitting? When did it last transmit? Is the battery status normal?

Device fleet management is not glamorous software. It is operationally critical, a device that is not transmitting means a patient who is not being monitored, which means missed 99454 threshold days, which means lost revenue and clinical risk.

From a US founder call: “We integrated five device types in our first sprint. By month three, we were spending 30% of our engineering bandwidth on device integration maintenance, API changes, format changes, connectivity issues. We rebuilt with a device adapter framework in month four. Adding our sixth device type took three days instead of three weeks. Build the framework first. The individual device integrations are fast once the framework is in place.”, Series A RPM founder, Denver.

The RPM Data Architecture, Time-Series ePHI at Scale

RPM data is fundamentally different from other healthcare data. It is time-series data, continuous streams of physiological readings from multiple devices, multiple patients, multiple conditions, over months and years. The data architecture decisions that work for a clinical note management system do not work for RPM data at scale.

1. The reading-level data model:

Every physiological reading must be stored with:

• Patient ID
• Device ID (the specific physical device, serial number or device UUID)
• Device type (blood pressure monitor, glucometer, pulse oximeter, etc.)
• Reading timestamp (the time the reading was taken on the device, in the device’s local time zone, converted to UTC for storage)
• Transmission timestamp (the time the reading was received by the platform, in UTC)
• Reading value(s) (systolic BP, diastolic BP, pulse for a blood pressure reading; glucose value for a glucometer reading; SpO2 and pulse rate for a pulse oximeter reading)
• Unit of measure
• Reading status (normal, alert, critical, based on configured thresholds)
• Transmission method (cellular, Bluetooth-to-phone, WiFi)
• Data source (device API, manual entry, and yes, you may need to support manual entry for patients whose device is temporarily unavailable, but manual entries do not count toward the 99454 threshold)

The reading timestamp and transmission timestamp are different fields. They must be stored separately. Medicare requires that readings be automatically transmitted, the transmission timestamp confirms the automated transmission event. The reading timestamp confirms when the physiological measurement was taken.

2. The time-series database decision:

PostgreSQL with time-series extensions (TimescaleDB) is our most common recommendation for RPM platforms at early-to-mid scale. It handles time-series queries efficiently, integrates cleanly with the relational data model for patient, provider, and billing data, and provides the full PostgreSQL feature set for non-time-series queries. It scales to tens of millions of readings before requiring architectural evolution.

For RPM platforms targeting very large patient populations (100,000+ active patients, multiple readings per day per patient), purpose-built time-series databases (InfluxDB, Amazon Timestream) offer better write throughput and query performance for time-series workloads. Most early-stage RPM platforms do not need this level of scale in v1.

Do not use a standard relational database with a generic readings table for RPM data. The query patterns for RPM, “give me all readings for patient X between date A and date B,” “calculate the 99454 threshold for all patients in provider Y’s practice for November 2026,” “identify all patients with a blood pressure reading above 180/110 in the last 7 days”, are time-series queries that perform poorly on unoptimized relational tables at scale.

3. Alert threshold architecture:

Alert thresholds are configured at multiple levels:

• Platform defaults (clinical standard thresholds for each condition, e.g., blood pressure above 180/110 systolic is a critical alert by default)
• Practice-level overrides (a cardiology practice may have different thresholds than a primary care practice)
• Patient-level overrides (a patient with baseline hypertension may have individualized thresholds set by their provider)

The alert threshold configuration must be stored in a way that allows historical querying, “what was the alert threshold for patient X on date Y?” matters for audit purposes and for clinical review of historical alerts.

Alert delivery must be multi-channel: in-platform notification for clinical staff, SMS or push notification for patients (for critical thresholds), and email for care coordinators. Alert delivery must be logged, the alert event, the delivery timestamp, the channel, and the recipient. For critical alerts: confirmation of receipt by clinical staff (acknowledged in the platform) with escalation if not acknowledged within a defined window.

4. The 30-day threshold calculation layer:

A dedicated calculation service runs nightly (and on-demand) to calculate CPT threshold metrics for every active patient:

• 99454 threshold: for each patient, for each device type, for the current calendar month, count the number of distinct transmission dates with at least one qualifying reading. Compare to 16. Flag patients approaching threshold (e.g., 12 days transmitted with 10 days remaining in the month, clinical staff should prioritize patient engagement).
• 99457 threshold: for each patient, for the current calendar month, sum the documented interactive communication time. Compare to 20 minutes. Flag patients approaching threshold.
• 99458 threshold: for each patient, for the current calendar month, calculate additional 20-minute increments above the 99457 threshold.

This calculation layer feeds the clinical staff dashboard, giving each care manager a real-time view of their patient caseload’s billing status. Patients who are at risk of missing the 99454 threshold are prioritized for outreach. Patients who are approaching the 99457 threshold are prioritized for interaction.

5. Data retention and archival:

Device readings retained for 7 years (the longer of HIPAA’s 6-year requirement and Medicare’s 7-year audit lookback period). After the retention period, readings are deleted per the documented retention and deletion policy. For large RPM platforms with millions of readings, archival to cold storage (AWS S3 Glacier) after 2 years of active retention reduces storage costs significantly without violating retention requirements.

Compliance trap: The reading timestamp on the device and the transmission timestamp on the platform are different fields. They must be stored separately and both must be retained.

A Medicare auditor reviewing a 99454 claim will ask: when was each reading taken? When was each reading transmitted? If your data model stores only the transmission timestamp and not the reading timestamp, you cannot answer the first question, and you cannot demonstrate that the readings were taken by the patient at home (not batch-transmitted from a clinical setting).

The Clinical Workflow, What Providers Actually Need to Get Paid

The clinical workflow is where RPM revenue is generated or lost. A technically sound device integration with a beautiful dashboard generates zero CPT 99457/99458 revenue if the clinical staff cannot efficiently deliver and document the 20 minutes of interactive care management per patient per month.

The daily review workflow: Clinical staff begin each day with the RPM patient dashboard, a prioritized list of patients requiring attention. Prioritization logic:

• Critical alerts (readings above critical thresholds), highest priority
• Patients approaching the monthly 99454 threshold but at risk of missing it (< 16 transmission days with < 10 days remaining in the month)
• Patients approaching the monthly 99457 threshold (< 20 minutes of interaction with < 7 days remaining in the month)
• Patients who have not transmitted a reading in the last 48 hours
• Patients with trend-based alerts (blood pressure trending up over the last 7 days without a critical single reading)

The patient interaction workflow: Clinical staff opens a patient’s chart. The interaction timer starts automatically (or with a one-click start). The staff member calls the patient, reviews the readings with them, addresses clinical concerns, and documents the interaction.

When the call ends, the staff member stops the timer, completes the interaction documentation (nature of the interaction, clinical observations, actions taken, patient response), and saves. The interaction is logged with date, start time, end time, duration, staff name and credentials, and documentation content.

The attestation workflow: At the end of each calendar month (or on a rolling basis for practices with large patient panels), the supervising physician or NPP reviews the monthly interaction documentation for each patient and attests that the care management services were provided as documented. The attestation is captured in the platform with the physician’s name, credentials, and attestation timestamp. This attestation is required for 99457/99458 billing and is the document a Medicare auditor will request first.

The patient panel management view: For practices managing large RPM panels (50–200+ patients), the individual patient chart view is insufficient. Clinical staff need a panel-level view that shows every patient’s:

• Current month transmission day count (toward 99454 threshold)
• Current month interaction time (toward 99457 threshold)
• Last reading date and value
• Alert status
• Last interaction date
• Billing status (eligible, pending, billed, paid, denied)

This panel view is the clinical staff’s primary workspace. It must be fast, sortable, filterable, and actionable, clicking on a patient row opens their chart and starts the interaction workflow.

The care plan and goal tracking workflow: Every RPM patient should have a documented care plan, monitoring goals (target blood pressure range, target glucose range), lifestyle recommendations, medication list (for reference during interactions), and the monitoring program duration. The care plan is not a static document, it should be updated when clinical goals change, when medications change, or when the patient’s condition evolves. Clinical staff who can see the care plan during every interaction give better care and document better.

Integration with the practice’s EHR: Most practices that use RPM have an existing EHR. The RPM platform must integrate with the EHR for:

• Patient demographics and insurance information (pull from EHR, do not require double-entry)
• Physician orders (create and store in EHR, reference in RPM platform)
• Clinical notes (push RPM interaction notes to the EHR for the complete patient record)
• Medication list (pull from EHR for reference during RPM interactions)

EHR integration is not optional for practice-based RPM. A practice that must maintain patient data in both their EHR and a separate RPM platform will not use the RPM platform consistently. The EHR integration is the adoption driver.

Common EHRs in RPM target markets: Epic (large health systems, academic medical centers), Cerner (now Oracle Health, large health systems), Athenahealth (independent practices, outpatient), eClinicalWorks (independent practices), NextGen (specialty practices), Kareo/Tebra (small independent practices). Each has a different integration architecture and a different API access model.

From a US founder call: “We built a beautiful RPM product. Our clinical dashboard was the best I had ever seen. Our device integration was solid. Our billing engine was correctly implemented. We could not get adoption in practices because we had not built the Athenahealth integration.

Every practice we sold used Athena. They refused to switch platforms. We built the Athena integration in sprint 3, six months after launch. We should have built it in sprint 1.”, Seed-stage RPM founder, Nashville.

The Real Cost Stack for an RPM MVP in 2026

Engineering (what you pay us):

• HIPAA-ready Lean RPM MVP (single condition, 2 device types, cash-pay or Medicare FFS billing, one EHR integration): $110K–$175K / 14–18 weeks
• Full RPM Platform (multi-condition, 4+ device types, multi-payer billing, EHR integration, device fleet management): $185K–$290K / 20–28 weeks
• AI-native RPM (predictive alerts, trend analysis, care gap detection, NLP interaction documentation): $210K–$330K / 22–30 weeks
• Dedicated pod post-MVP: $26K–$42K/month

Compliance infrastructure:

• SOC 2 Type II audit: $45K–$95K
• SOC 2 compliance tooling (Vanta, Drata): $12K–$36K/year
• Penetration testing: $8K–$22K
• HIPAA risk assessment and security review: included in our engagement

Device costs (hardware, your P&L, not engineering):

• Cellular-connected blood pressure monitor (Withings BPM Connect Pro, A&D Medical UA-651BLE-C): $45–$85 per device
• Bluetooth blood pressure monitor (Withings BPM Core, Omron Evolv): $35–$65 per device
• Dexcom G7 CGM starter kit: $300–$400 (sensor + transmitter), $80–$120/month ongoing sensor subscription
• Medical-grade pulse oximeter (Masimo MightySat, Nonin): $150–$300 per device
• Weight scale (Withings Body+, iHealth Lite): $50–$90 per device
• Device reconditioning cost per returned device: $8–$20 depending on device type

Device manufacturer API licensing:

• Withings Health Institutions: contact for pricing (typically $0.05–$0.15 per active patient per month at scale)
• Dexcom partner API: contact for pricing
• Most manufacturer APIs: negotiated based on patient volume

EHR integration:

• Athenahealth Marketplace integration build: $25K–$45K engineering (one-time)
• Epic SMART on FHIR integration: $35K–$65K engineering (one-time), plus Epic App Orchard certification ($5K–$25K/year)
• eClinicalWorks API integration: $20K–$35K engineering
• Ongoing EHR API licensing: varies by EHR vendor and patient volume

Billing and RCM:

• Clearinghouse connection (Change Healthcare, Availity, Waystar): $0.10–$0.30 per claim
• RCM partner (if outsourcing claims management): 4–8% of collected revenue
• Billing compliance specialist (for Medicare billing audit readiness): $5K–$15K/year

Clinical operations (for managed-service RPM model):

• Clinical care manager (RN or LPN for patient interactions): $55K–$80K/year per full-time equivalent
• At 200 active patients per care manager (sustainable caseload at 20 min/month per patient): $55K–$80K/year per 200 patients

EB Index 2026: The median total first-year cost for a US RPM MVP, engineering, compliance, device costs (for 500-patient pilot), EHR integration, billing infrastructure, and clinical operations, was $487,000. The single largest cost category was device hardware at $127,000 (for 500 devices at an average of $65/device plus logistics). Engineering was the second-largest at $148,000.

What we’d cut: For a pre-Series A RPM founder with under $5M raised: launch single-condition (hypertension is the clearest market), two device types (blood pressure monitor, cellular-connected, and weight scale), Medicare FFS billing only, one EHR integration (the EHR your target practice uses most), and outsource clinical operations to a managed RPM service rather than building your own clinical team. This is a $120K–$165K engineering engagement, not a $290K one. Validate the model. Add complexity at Series A.

The 14-Week RPM MVP Sprint

• Week 1: Discovery and Compliance Scoping

Target condition confirmed. Device type inventory scoped. ePHI data classification map produced, with reading-level data elements mapped. BAA analysis for each device manufacturer API. EHR integration scope confirmed. Payer strategy confirmed (Medicare FFS, Medicare Advantage, commercial, or cash-pay). CPT code billing workflow designed, 99453, 99454, 99457, 99458 documentation requirements mapped to data model requirements. Billing engine architecture designed.

• Week 2: BAA Execution and Architecture Design

HIPAA BAA signed. Device manufacturer BAAs confirmed and executed. Cloud infrastructure architecture designed (HIPAA-eligible services only). Time-series data model designed, reading table, threshold calculation layer, alert table, interaction log table. Billing engine data model designed. Physician order workflow designed. Patient consent workflow designed.

• Week 3: Infrastructure Provisioning

HIPAA-eligible cloud infrastructure provisioned. PostgreSQL with TimescaleDB configured for time-series data. Encryption at rest on all data stores. TLS 1.2+ enforced. Audit log service deployed. CI/CD pipeline with SAST live. CloudTrail enabled.

• Week 4: Device Integration Framework and First Device Integration

Device integration framework built, standardized internal data model, adapter interface, reading ingestion pipeline. First device manufacturer integration built (the highest-priority device for the target condition). Reading validation logic implemented. Device status monitoring implemented.

• Week 5: Physician Order and Patient Enrollment Workflows

Physician order creation and storage workflow. Patient enrollment with consent documentation (date, staff name, consent method). Device assignment workflow (which device serial number assigned to which patient). Patient onboarding communication (device setup instructions, transmission confirmation).

• Week 6: Threshold Calculation Engine

Daily threshold calculation service: 99454 calculation (16-day transmission threshold per patient per device per calendar month), 99457 calculation (cumulative interaction time per patient per calendar month), 99458 calculation (additional 20-minute increments). Real-time threshold status surfaced to clinical staff dashboard.

• Week 7: Alert Engine and Clinical Staff Dashboard

Alert threshold configuration (platform defaults, practice-level, patient-level). Alert detection logic (reading-level comparison against configured thresholds). Alert delivery (in-platform, SMS, email). Alert acknowledgment workflow. Clinical staff dashboard: patient panel with transmission day count, interaction time, alert status, last reading, billing status.

• Week 8: Clinical Interaction Workflow and Documentation

Interaction timer (auto-start on patient chart open, stop on interaction close). Interaction documentation template (date, start time, end time, duration, nature, clinical observations, actions taken, patient response, staff name and credentials). Interaction log with reading-level timestamp accuracy. Cumulative interaction time calculation updated on each interaction save. Attestation workflow for supervising physician or NPP.

• Week 9: Billing Engine

99453 claim generation logic (trigger: first transmission date + patient education documentation). 99454 claim generation logic (trigger: 16+ transmission days in calendar month). 99457 claim generation logic (trigger: 20+ minutes documented interactive communication). 99458 claim generation logic (trigger: each additional 20-minute increment). Clearinghouse API integration (Change Healthcare, Availity, or Waystar). Claim submission workflow. Remittance processing (835 transaction). Denial tracking and denial management workflow.

• Week 10: Second Device Integration and EHR Integration

Second device manufacturer integration built (adapter pattern from Week 4). EHR integration: patient demographics pull, physician order sync, interaction note push. EHR integration tested in sandbox environment.

• Week 11: Patient-Facing Mobile App

Patient mobile app: device pairing (for Bluetooth devices), reading history, trend visualization, alert acknowledgment, secure messaging with care team. For cellular-connected devices: the patient app is simpler, reading history and trend visualization only, no pairing required.

• Week 12: Internal QA and Compliance Review

CPT threshold calculation QA, test cases for each billing edge case (patient transmits exactly 16 days, patient transmits 15 days, patient transmits 0 days in final week of month). Billing engine QA, claim generation tested against Medicare billing requirements. HIPAA-specific test suite. HIPAA risk assessment updated to as-built.

• Week 13: Penetration Testing and Billing Compliance Review

Third-party pen test. Healthcare billing specialist review of billing engine against current Medicare billing requirements (this is not our review, it is a domain expert review from someone who knows the Medicare Physician Fee Schedule in depth). Critical findings remediated. SOC 2 compliance platform connected.

• Week 14: Handover and Launch

Handover pack delivered. First practice onboarded. First patients enrolled. First devices shipped.

AI-Native RPM in 2026, Predictive Alerts, Trend Analysis, and Care Gap Detection

The AI use cases that are generating real clinical value in RPM products in 2026:

• Predictive deterioration alerts:

Rather than alerting only when a reading crosses a threshold (reactive alerting), an ML model trained on reading sequences and clinical outcomes identifies patients whose reading patterns suggest imminent deterioration, before a critical single reading occurs. For hypertension: a patient whose blood pressure has been trending upward at 3 mmHg per day for 7 days may not have crossed the critical threshold yet, but their trajectory suggests they will within 72 hours. A predictive alert at Day 7 enables clinical intervention before the critical event.

Technical architecture: a time-series ML model (LSTM or transformer-based) trained on historical reading sequences and clinical outcome labels. Feature engineering from the reading time series (trend slope, variability, morning-evening differential for blood pressure). Model serving via AWS SageMaker or a custom Python/FastAPI inference endpoint. Inference runs nightly on every active patient’s reading history. Predictions stored in the alert table with a “predictive” flag distinct from threshold-triggered alerts.

• Clinical validation requirement:

predictive alert models must be validated against clinical outcome data before deployment in a production clinical environment. A model that generates too many false positive predictive alerts creates alert fatigue and reduces clinical staff trust in the alert system. Validate the model’s precision and recall against your historical dataset before turning on predictive alerts.

• Trend analysis and report generation:

Automated monthly summary reports for the supervising physician: 30-day reading averages, trend lines, threshold event count, days of transmission, interaction summary, and care plan adherence. Generated automatically at the end of each calendar month. Reduces the physician attestation burden, the physician reviews the AI-generated summary and attests rather than reviewing raw reading data.

• Natural language processing for interaction documentation:

NLP applied to voice recordings of patient interactions (with patient consent) to auto-generate the interaction documentation, duration (from recording timestamps), nature of discussion (from transcript NLP), clinical topics covered (from transcript entity extraction). The clinical staff reviews and edits the AI-generated documentation. Reduces interaction documentation time by 3–5 minutes per interaction, meaningful at 200+ patient caseloads.

HIPAA requirement: interaction audio recordings are ePHI. Transcription service requires BAA. NLP processing of transcripts requires BAA for the LLM/NLP provider (AWS Bedrock default).

• Care gap detection:

An ML model that identifies patients at risk of dropping out of the RPM program, based on declining transmission frequency, declining interaction engagement, and demographic predictors of dropout. These patients are flagged for proactive outreach by clinical staff before they miss the 99454 threshold.

From a US founder call: “We added predictive blood pressure deterioration alerts in month eight. Our false positive rate in the first deployment was 34%, way too high. Clinical staff were ignoring the predictive alerts because too many were wrong. We retrained the model with six additional months of outcome data, reducing the false positive rate to 11%.

Clinical staff started acting on predictive alerts. Hospital admissions in our patient panel dropped 18% over the next six months. The model validation before deployment is not optional, it is what makes the clinical value real.”, Series A RPM founder, Boston.

Payer Contracting, Medicare Billing, and the Reimbursement Landscape

• Medicare Fee-for-Service (traditional Medicare):

The most straightforward RPM billing path. CMS defines the coverage criteria, the CPT codes, the documentation requirements, and the reimbursement rates in the Medicare Physician Fee Schedule updated annually. Billing is through the practice’s provider NPI. No prior authorization required for RPM under traditional Medicare (confirm current policy, CMS rules can change with annual PFS updates).

2026 Medicare national average reimbursement for a fully compliant RPM month (99453 amortized, 99454, 99457, one unit of 99458): approximately $130–$145 per patient per month. This is the gross revenue before practice overhead and platform costs.

• Medicare Advantage (Medicare Part C):

Medicare Advantage plans are administered by private insurers (UnitedHealth, Humana, CVS/Aetna, Cigna, BCBS) and are not required to follow traditional Medicare coverage policies for all services. RPM coverage under Medicare Advantage varies by plan, some plans follow traditional Medicare coverage, some have more restrictive policies, and some have more generous policies. You must verify RPM coverage with each specific Medicare Advantage plan before billing.

The practical implication: your billing engine must apply plan-specific rules for Medicare Advantage patients, not the traditional Medicare rules. This requires maintaining a payer-specific rule set for each Medicare Advantage plan in your market.

• Medicaid:

RPM Medicaid coverage is state-by-state. As of 2026, the majority of state Medicaid programs have issued coverage policies for some form of remote monitoring, but the specific CPT codes covered, the eligible conditions, the documentation requirements, and the reimbursement rates vary significantly. Some states cover 99457/99458 under Medicaid. Many do not yet. Research your target states’ Medicaid RPM coverage policies before committing to Medicaid billing in your product.

• Commercial payers:

Commercial payer RPM coverage is the least uniform of the payer categories. Large national payers (UnitedHealthcare, Cigna, Aetna, BCBS national plans) have each issued their own RPM coverage policies, with their own eligible conditions, their own documentation requirements, and their own reimbursement rates. Many require prior authorization for RPM. Some require that the RPM vendor be a preferred provider or contracted vendor. Research each commercial payer’s specific RPM coverage policy before designing your billing architecture.

• The prior authorization workflow:

For payers that require prior authorization for RPM, your platform must support a prior authorization workflow: submitting the prior authorization request (diagnosis code, clinical justification, device type, requested monitoring duration), tracking prior authorization status, and ensuring that RPM billing does not begin until prior authorization is received. Prior authorization failures discovered after billing are retroactive denials that cannot be appealed on the merits, they are procedural denials.

EB Index 2026: Across 14 RPM products we have shipped, practices billing Medicare FFS for RPM had a first-year collection rate (collected revenue as a percentage of billed revenue) of 84%. Practices billing Medicare Advantage had a first-year collection rate of 71%. Practices billing commercial payers had a first-year collection rate of 62%.

The gap reflects the complexity of commercial payer billing, prior authorization failures, coverage policy variations, and higher denial rates. Design your billing architecture for the payer complexity you will actually face, not the payer complexity you wish you had.

Post-Launch: Scaling Device Fleets, Managing Clinical Operations, and Multi-Payer Billing

• Scaling the device fleet:

At 500 patients, device fleet management is manageable with a spreadsheet and a good shipping partner. At 5,000 patients, it requires dedicated supply chain software, inventory management, shipping and receiving integration, device reconditioning workflow, and device health monitoring. Build the device fleet management software as a first-class product feature, not as a manual operations afterthought.

Device return rates vary by device type and patient population: blood pressure monitors have return rates of 8–15% per year (device malfunctions, patient deaths, program completions). CGMs have ongoing consumable replacement cycles. Build the return and reconditioning workflow into the platform before you need it at scale.

• Scaling clinical operations:

At 200 patients per care manager (sustainable caseload for 20 min/month interactions), clinical operations scaling is straightforward: add care managers as the patient panel grows. At 2,000 patients, the clinical operations layer, care manager scheduling, caseload assignment, quality oversight, attestation management, requires dedicated operations management tooling within the platform.

The highest-leverage clinical operations investment: AI-assisted interaction preparation. Before each patient call, the care manager receives an AI-generated briefing, the patient’s last 7 days of readings, trend summary, outstanding alerts, and suggested talking points based on the patient’s care plan. This preparation reduces the call time required to deliver high-quality care management and increases the care manager’s capacity.

• Multi-payer billing at scale:

As your patient panel grows across multiple payers, the billing engine must handle increasingly complex payer-specific rule sets. Invest in a payer rules management layer, a configurable database of payer-specific billing rules (prior authorization requirements, documentation requirements, claim format requirements, modifier requirements) that can be updated by a billing specialist without a code deployment.

When an Indian Engineering Partner Is Wrong for Your RPM Build

An Indian engineering partner is the wrong call for your RPM product if: your RPM program targets a patient population with such complex, time-sensitive clinical escalation needs that the engineering team must be able to respond to clinical design questions in real time throughout the business day, and the 10.5-hour time zone gap creates an unacceptable delay in clinical design decisions.

If your RPM product requires hardware engineering alongside software engineering, if you are building a custom medical device, not integrating with existing commercial devices, you likely need US-based hardware engineers embedded with the software team. If your payer contracting strategy requires real-time coordination between the engineering team and US-based payer relations specialists at a cadence that the overlap window cannot support.

If your target health system customer requires that all development work be performed in the continental United States for data sovereignty reasons, some federal health system contracts include this requirement.

For the vast majority of RPM founders building software platforms that integrate with commercial devices and bill through existing payer channels, none of these constraints apply. We have shipped 14 RPM products for US founders from Indore. The model works.

The RPM Product Scorecard

Score each row 0 (absent), 1 (partial), or 2 (fully present). Maximum score: 70.

#	Criterion	Weight	Your Score
1	Reading-level data model with transmission timestamp and reading timestamp stored separately	2×	/4
2	99454 threshold calculated from qualifying transmission days (not device activity days)	2×	/4
3	99453 billing triggered by first transmission date (not device delivery date)	2×	/4
4	99457 documentation at individual interaction level (date, start time, end time, duration, nature)	2×	/4
5	Attestation workflow for supervising physician or NPP	2×	/4
6	Physician order workflow built and stored in patient record	2×	/4
7	Patient consent documented with timestamp, staff name, and consent method	2×	/4
8	Device integration framework (adapter pattern, not point-to-point)	1×	/2
9	BAA confirmed with every device manufacturer API used	2×	/4
10	HIPAA-eligible cloud infrastructure confirmed against published list	2×	/4
11	Alert threshold configuration at platform, practice, and patient levels	1×	/2
12	Alert delivery log (event, timestamp, channel, recipient, acknowledgment)	1×	/2
13	Device fleet management (inventory, assignment, shipping, reconditioning)	1×	/2
14	EHR integration for target practice EHR	2×	/4
15	Denial management workflow (denial code capture, correction routing, resubmission tracking)	2×	/4
16	Payer-specific billing rules engine (configurable, not hardcoded)	1×	/2
17	Third-party penetration test before go-live	1×	/2
18	Healthcare billing specialist review of billing engine	2×	/4
19	SOC 2 readiness built into architecture from Day 1	1×	/2
20	Time-series database for reading storage (TimescaleDB, InfluxDB, or equivalent)	1×	/2
21	7-year data retention policy implemented (longer of HIPAA and Medicare audit lookback)	1×	/2
22	Prior authorization workflow for payers that require it	1×	/2
23	Clinical staff panel view with real-time threshold status per patient	1×	/2
24	Interaction timer embedded in clinical workflow	1×	/2
25	MSA governed by US law with IP assignment on creation	1×	/2

Score interpretation:

• 55–70: Strong RPM compliance and billing posture, ready for Medicare billing and enterprise practice sales
• 40–54: Proceed with identified gaps remediated, billing-critical 2× items first
• Under 40: Significant billing compliance and HIPAA exposure, do not go live with real patients or submit claims until gaps are closed

Conclusion

RPM is one of the most commercially compelling opportunities in digital health. The clinical evidence is strong. The Medicare reimbursement pathway is established. The chronic disease burden in the United States, hypertension alone affects 119 million Americans, creates a market that is measured in tens of millions of patients, not thousands.

But RPM is also one of the most operationally demanding digital health products to build correctly. The billing engine is not a module you configure, it is the product. The device integration framework is not a feature you add, it is the foundation. The clinical workflow that enables care managers to deliver and document 20 minutes of interactive care management per patient per month is not a dashboard, it is the revenue engine.

The founders who build RPM correctly, who get the CPT code documentation requirements right before the first claim is submitted, who build the device adapter framework before the second device integration, who build the EHR integration before the first practice goes live, are the ones who scale. The founders who discover these requirements after launch are the ones who rebuild.

I have been on 2,000+ calls with US founders since 2014. The RPM founders who succeed are the ones who understood, before they wrote a line of code, that the billing architecture is the clinical architecture. Build it right from Day 1.

If you want 30 minutes to talk through your RPM product, your target condition, your device strategy, your billing model, your EHR integration, book a call with me or Aditi. No slides. No pitch. Just the product conversation.

FAQ

• What is the Medicare reimbursement rate for RPM in 2026?

2026 Medicare national average reimbursement rates: 99453 approximately $19–$21 (billed once), 99454 approximately $47–$52 per month, 99457 approximately $48–$52 per month, 99458 approximately $38–$42 per additional 20-minute increment. A fully compliant RPM month for a single patient (99454 + 99457 + one unit of 99458) generates approximately $130–$145 in gross Medicare revenue. Rates are updated annually in the Medicare Physician Fee Schedule, confirm current rates for the current year.

• What qualifies as a “day of data transmission” for CPT 99454?

A day of data transmission for CPT 99454 is a calendar day on which at least one qualifying physiological reading was automatically transmitted from the device to the platform. The reading must be automatically transmitted, manual patient data entry does not qualify. The reading must come from a medical-grade device that automatically transmits data. Your platform must track transmission events at the reading level, the specific date each qualifying reading was transmitted, and calculate the 16-day threshold from this reading-level dataset.

• What documentation is required for CPT 99457?

CPT 99457 requires documentation of each interactive communication event that contributes to the 20-minute monthly threshold: the date of each interaction, the start time, the end time, the duration in minutes, the nature of the interaction (what was discussed, what clinical action was taken), and the name and credentials of the clinical staff member who conducted the interaction. A total-time notation (“20 minutes of care management this month”) is insufficient, Medicare auditors require interaction-level documentation. The supervising physician or NPP must attest to the services.

• What devices qualify for Medicare RPM billing?

CMS requires that devices used for Medicare RPM billing be medical-grade devices that automatically transmit data, the patient does not manually enter data. Consumer wearables (Apple Watch, Fitbit) may not qualify unless they have FDA clearance for the specific physiological parameter being monitored and automatically transmit data without patient data entry. Confirm device eligibility with a healthcare billing specialist before committing to a device integration. CMS does not maintain a published list of approved RPM devices, the eligibility determination is based on the device’s characteristics and FDA clearance status.

• Is a physician order required for RPM?

Yes. Medicare RPM requires an order from a physician, nurse practitioner, physician assistant, or other qualified healthcare professional before monitoring begins. The order must specify the condition being monitored, the device prescribed, the monitoring parameters, and the monitoring duration. The order must be stored in the patient record and referenced in billing documentation.

• Can RPM be billed for acute conditions or only chronic conditions?

CMS expanded RPM eligibility to include acute conditions effective January 2024, making the expansion permanent after the COVID-19 PHE. Before 2024, RPM was limited to patients with chronic conditions. Confirm current CMS coverage policy, the Physician Fee Schedule is updated annually and coverage criteria can change.

• How much clinical staff time is required per RPM patient per month?

CPT 99457 requires 20 minutes of interactive care management per patient per calendar month. CPT 99458 generates additional revenue for each additional 20-minute increment. At a sustainable caseload of 200 patients per full-time care manager, the care management time requirement is 200 × 20 minutes = 4,000 minutes (approximately 67 hours) of interactive patient time per month, or approximately 15–16 hours per week of patient-facing time per care manager. The remaining time covers reading review, alert response, documentation, and practice coordination.

• Can RPM and CCM (Chronic Care Management) be billed in the same month?

CMS has specific rules about billing RPM codes alongside CCM (Chronic Care Management, CPT 99490 series) and TCM (Transitional Care Management, CPT 99495/99496) codes. As of 2026: RPM and CCM can be billed in the same calendar month, but the time counted toward each cannot overlap, the 20 minutes of RPM care management (99457) must be distinct from the 20 minutes of CCM (99490). Confirm current CMS co-billing rules with your healthcare billing specialist, these rules have changed multiple times and will change again.

• How long must RPM billing documentation be retained?

Medicare requires that billing documentation be retained for 7 years from the date of service, the Medicare audit lookback period. HIPAA requires ePHI retention for 6 years from the date of creation or the date last in effect. The governing retention requirement for RPM billing documentation is 7 years (the longer of the two). Build your data retention policy and automated deletion workflow around the 7-year requirement.