The Complete Guide to Remote Patient Monitoring in 2026

Remote patient monitoring (RPM) is the use of connected medical devices to collect a patient’s physiologic data at home, such as blood pressure, weight, blood glucose, or oxygen saturation, and transmit it automatically to a care team that reviews the readings and adjusts treatment between visits. Medicare has paid separately for remote patient monitoring since 2018, and in 2026 it reimburses six CPT codes covering device setup, device supply, and monthly treatment management. RPM is a subset of telehealth, sits alongside remote therapeutic monitoring, and works best for chronic conditions where daily numbers change clinical decisions.

This guide covers how remote patient monitoring works, which devices and conditions it applies to, what the clinical evidence says, how the 2026 CPT codes and Medicare rates are structured, and what a HIPAA compliant RPM architecture looks like when it is built rather than bolted on. It also covers the questions provider organizations and digital health founders ask us at Arkenea, where we have spent 15 years building only healthcare software, including two remote patient monitoring applications for physician led companies: build or buy, what it costs, how long it takes, and how to get device data into the EHR without creating a second inbox for clinicians.

What Is Remote Patient Monitoring?

Remote patient monitoring is a care delivery method in which a patient uses an internet connected medical device to record health data outside a clinical setting, the device transmits that data digitally to the patient’s provider, and the provider uses the data to treat or manage the patient’s condition. The Centers for Medicare & Medicaid Services defines RPM by three components: education and device setup, device supply with data transmission, and treatment management. All three must happen for the service to count as remote patient monitoring under Medicare.

The device must meet the Food and Drug Administration’s definition of a medical device and must upload data digitally on its own. Manual entry by the patient into an app does not qualify for Medicare billing. Medicare covers RPM for both chronic and acute conditions, so a patient recovering from surgery is as eligible as a patient with hypertension, provided the monitoring is medically necessary and the patient consents.

The term remote physiologic monitoring is used interchangeably with remote patient monitoring in the CPT code descriptors. Both refer to the same service. Remote therapeutic monitoring (RTM) is a separate service with its own codes and is covered below.

How Does Remote Patient Monitoring Work?

Remote patient monitoring works as a five stage data pipeline: a connected device captures a reading, the reading is transmitted over cellular or Bluetooth to a secure cloud platform, the platform stores the data and applies threshold rules, clinical staff review flagged readings in a dashboard or inside the EHR, and a clinician intervenes by phone, video, or medication change. Each stage has a software component, and the weakest stage determines whether the program produces outcomes or just data.

Stage 1: Enrollment, consent, and device setup

A physician or qualified health professional identifies an eligible patient, explains the program, and documents consent. The patient receives a device and is taught to use it. CMS pays for this setup once per episode of care under CPT 99453, and starting in 2026 the setup code requires at least 2 days of monitoring data to be billable.

Stage 2: Data capture and transmission

The patient takes readings at home. Cellular connected devices transmit each reading on their own through an embedded modem, while Bluetooth devices pair with a hub or a smartphone app that relays the data. In our experience building RPM applications, the transmission method is the single largest driver of adherence: patients who must open an app, pair a device, and keep a phone charged transmit fewer days per month than patients whose device simply works when they press one button.

Stage 3: Ingestion, storage, and rules

The platform receives readings through a device manufacturer API or a direct gateway, validates them, stores them as protected health information, and evaluates them against patient specific thresholds. A systolic reading above 160 mmHg or a weight gain of more than 3 pounds in 2 days generates an alert. This is also where the software counts transmission days per 30 day period and clinical minutes per calendar month, because those counts determine which CPT code the practice can bill.

Stage 4: Clinical review

Nurses, medical assistants, or pharmacists working under general supervision review alerts and trends. Programs that push device data into the EHR as FHIR Observation resources let clinicians review readings in the chart they already use. Programs that require a separate login produce slower reviews and more missed alerts.

Stage 5: Intervention and documentation

The care team contacts the patient, adjusts medication, reinforces the care plan, or escalates to an office visit. CMS requires at least one live interactive communication with the patient or caregiver each month for the treatment management codes. Every minute of that work is logged, because the 10 minute and 20 minute thresholds decide whether the month bills under CPT 99470 or CPT 99457.

Remote Patient Monitoring vs Telehealth vs Remote Therapeutic Monitoring: What Is the Difference?

Telehealth is the umbrella category for any care delivered over telecommunications technology, telemedicine is the subset covering live clinical encounters such as video visits, remote patient monitoring is the subset covering asynchronous collection of physiologic data from connected devices, and remote therapeutic monitoring is a parallel service that collects non physiologic data such as medication adherence, pain levels, or musculoskeletal function. A video visit captures one moment. Remote patient monitoring captures a trend over weeks.

The distinction matters for billing and for staffing. RPM codes (99453, 99454, 99445, 99457, 99458, 99470) can be billed by physicians and non physician practitioners such as nurse practitioners and physician assistants. RTM codes (98975 through 98981, plus new 2026 codes 98984 through 98986 and 98979) can also be billed by physical therapists, occupational therapists, and other qualified professionals who cannot bill RPM. Many programs run both, since a heart failure patient may need weight monitoring under RPM and medication adherence tracking under RTM.

For a broader treatment of the video visit side, see our guide to telemedicine app development. Both RPM and telemedicine share the same HIPAA, consent, and EHR integration requirements, so organizations often build them on one platform.

Which Conditions and Devices Does RPM Cover?

Remote patient monitoring is used most for hypertension, heart failure, type 2 diabetes, COPD and asthma, post surgical recovery, and high risk pregnancy, and the standard devices are connected blood pressure cuffs, weight scales, blood glucose meters, continuous glucose monitors, pulse oximeters, spirometers, and thermometers. The pattern across every successful use case is the same: a daily number that a clinician would act on if they saw it.

Conditions where RPM changes clinical decisions

• Hypertension: home readings expose white coat and masked hypertension and let clinicians titrate medication over days instead of between quarterly visits.
• Heart failure: daily weight and blood pressure catch fluid retention before it becomes a readmission.
• Type 2 diabetes and prediabetes: connected glucometers and CGMs show how diet, activity, and medication move blood sugar, which is the use case behind our MiPHR engagement described later in this guide.
• COPD and asthma: pulse oximetry and peak flow readings flag declining lung function before a crisis.
• Post surgical and post discharge recovery: short term monitoring for 2 to 15 days, now billable under CPT 99445, supports safe transitions home.
• Obesity and metabolic care: weight tracking feeds dosing decisions in virtual clinics prescribing semaglutide and similar weight management drugs, one of the fastest growing RPM adjacent models.

Device classes and what each requires from the software

Blood pressure cuffs, scales, and pulse oximeters produce a small number of discrete readings per day and are simple to ingest. Continuous glucose monitors and wearable ECG patches produce streams of thousands of data points per day, which changes the storage model, the alerting logic, and the cost of the platform. Any device used for Medicare RPM billing must meet the FDA definition of a medical device, and any device with software and network connectivity now falls under the FDA’s cyber device requirements described in the compliance section below.

Does Remote Patient Monitoring Improve Outcomes? What the Evidence Shows

Remote patient monitoring reduces heart failure hospitalizations and mortality when it is paired with education, self management support, and active clinical follow up, and it produces little measurable benefit when it only transmits readings to a provider without a workflow to act on them. That is the consistent finding across the strongest recent evidence, and it corrects the most common assumption in the market: that deploying devices is the intervention.

A 2025 meta analysis in the European Journal of Heart Failure pooled 41 randomized controlled trials with 16,312 heart failure patients and found that non invasive RPM was associated with a lower risk of first heart failure hospitalization (pooled odds ratio 0.78, 95% CI 0.70 to 0.87) and lower mortality (pooled odds ratio 0.81, 95% CI 0.69 to 0.95) compared with usual care. The same analysis found that programs with a self management module and an education module reduced hospitalizations significantly more than programs without them, and that video calls during monitoring further reduced both heart failure and all cause hospitalizations.

The Peterson Health Technology Institute reached a related conclusion for hypertension in its April 2025 policy brief. Digital hypertension tools that pair connected cuffs with rapid medication adjustment achieve faster blood pressure control than standard care, with patients typically stabilized within three to six months. Tools that only route home readings back to a provider without medication management did not produce clinically significant improvement over usual care.

The same PHTI brief found that over 40% of traditional Medicare beneficiaries receiving remote monitoring for hypertension were monitored for longer than six months, which is beyond the window where the evidence shows benefit. For anyone designing an RPM program or the software behind it, the implication is direct: build the program around a clinical protocol with a defined endpoint, not around indefinite device supply.

How Is Remote Patient Monitoring Reimbursed in 2026? CPT Codes and Medicare Rates

In 2026 Medicare reimburses remote patient monitoring through six CPT codes: 99453 for setup, 99454 and the new 99445 for device supply, 99457 and 99458 for 20 minute increments of treatment management, and the new 99470 for the first 10 minutes of management. CMS finalized the two new codes in the CY 2026 Physician Fee Schedule final rule issued October 31, 2025, effective January 1, 2026. A standard month of RPM (99454 plus 99457) pays roughly $99 per patient at the national non facility rate before locality adjustment.

Rates are approximate national non facility Medicare amounts compiled by CareTrack from the 2026 relative value units and the $33.40 non qualifying conversion factor. Published estimates for 99454 range from about $47 to $52 depending on the source and rounding. Verify the amount for your locality in the CMS Physician Fee Schedule lookup tool before modeling revenue.

What the new 2026 codes change

Before 2026 a patient who transmitted on 12 days and needed one 15 minute call generated real clinical work and zero revenue, because 99454 required 16 days and 99457 required 20 minutes. CPT 99445 makes 2 to 15 transmission days billable at the same rate as 99454, and CPT 99470 pays for 10 to 19 minutes of management at half the value of 99457. According to the Nixon Law Group’s analysis of the final rule, CMS valued 99470 at 0.31 work RVUs, exactly half of 99457’s 0.61, and adopted CPT’s language that the live interactive communication must contribute to the total time but need not represent all of it.

For software, this means the platform must count transmission days per 30 day period and clinical minutes per calendar month precisely enough to select the correct tier for every patient every month. It also opens tiered program designs: a post discharge cardiac patient can start on daily readings under 99454 and 99457, then step down to weekly readings under 99445 and 99470 instead of being discharged from the program.

Billing rules that generate the most denials

• Only one practitioner can bill RPM management for a given patient in a given calendar month, so a cardiologist and a primary care physician monitoring the same patient must decide who bills before claims go out.
• 99454 is billed once per 30 days regardless of how many devices the patient uses.
• RPM can be billed in the same month as chronic care management (99490 and related codes), transitional care management, and behavioral health integration, but the time counted toward each service must be distinct.
• Rural Health Clinics and Federally Qualified Health Centers report the individual RPM codes rather than a bundled care management code as of 2025.

Why compliance is now a design requirement, not a policy document

The HHS Office of Inspector General reported in September 2024 that about 43% of Medicare enrollees who received remote patient monitoring did not receive all three components of the service, and that Medicare lacks information on who ordered the monitoring and what data is being collected. OIG recommended that CMS require an ordering provider on claims, develop methods to identify what health data is monitored, and identify and monitor companies that bill for RPM. Four of those five recommendations remain open with CMS updates expected in 2027.

The practical reading is that audit exposure for RPM programs is rising, and the defense is an audit trail generated automatically by the software: timestamped device transmissions, logged clinical minutes, documented interactive communication, and a record of the ordering practitioner on every enrollment. A platform that stores readings but leaves time tracking to a spreadsheet will not survive a Medicare Administrative Contractor review.

What Are the Benefits of RPM for Providers and Patients?

The benefits of remote patient monitoring are earlier intervention on deteriorating patients, fewer hospitalizations and readmissions for conditions like heart failure, faster medication titration for hypertension and diabetes, better access to care for rural, elderly, and mobility limited patients, and a recurring per patient revenue stream that funds the care management staff who deliver the clinical work. Each of those benefits depends on the program being run as a clinical protocol rather than a device distribution exercise.

Continuous data instead of point in time snapshots

A clinic visit captures one blood pressure reading under conditions that are not representative of the patient’s daily life. Thirty days of home readings show the pattern, the variability, and the response to a medication change. Clinicians make dosing decisions on trends, and trends are what RPM produces.

Support for value based care contracts

Controlling blood pressure and managing diabetes are core HEDIS measures and Medicare Advantage Star Rating measures. RPM produces the documented readings that satisfy those measures and gives accountable care organizations visibility into their highest risk patients between visits. Under fee for service, RPM generates direct monthly reimbursement; under risk contracts, its value shows up as avoided admissions and quality bonuses.

Patient engagement that is measurable

A patient who takes a reading every morning is participating in their own care in a way that is visible to the care team. The meta analysis evidence above shows that self management and education modules are what convert that participation into fewer hospitalizations. The software should therefore treat patient education content, reminders, and two way messaging as core features rather than extras.

Access for patients who cannot travel

Patients in rural areas, patients with disabilities, and elderly patients with multiple chronic conditions face the highest barriers to frequent office visits and gain the most from monitoring at home. Cellular connected devices that need no smartphone or home internet extend that access to patients who would be excluded by an app first design.

What Does HIPAA Compliance Look Like in a Remote Patient Monitoring System?

A HIPAA compliant remote patient monitoring system encrypts protected health information at rest and in transit, authenticates every user with multifactor authentication, logs every access to patient data, isolates the device ingestion layer from the clinical application layer, runs on infrastructure covered by a Business Associate Agreement, and can prove all of that through a risk analysis and audit trail. Every one of those controls is an architecture decision made in the first month of a project, not a policy written before launch.

The HIPAA Security Rule notice of proposed rulemaking published by HHS in December 2024 sets the direction even though the current Security Rule remains in effect while the proposal is finalized. It would remove the distinction between required and addressable specifications, mandate encryption of ePHI at rest and in transit, mandate multifactor authentication, require network segmentation, require vulnerability scanning every six months and penetration testing every twelve months, require a technology asset inventory and network map showing how ePHI moves, and require the ability to restore critical systems within 72 hours. We build to those requirements now on every RPM project because retrofitting them onto a live system is far more expensive than designing for them.

Controls that are specific to RPM data flows

• Device to cloud transport over TLS 1.2 or higher, with device identity verified by certificate rather than a shared API key.
• Separation of the ingestion service, which receives raw device payloads, from the clinical application, so a compromised device cannot reach the patient database.
• Field level encryption for identifiers and AES 256 encryption for data stores, with keys managed in a hardware backed key management service.
• Immutable audit logs recording who viewed which reading and when, retained for at least six years to match the HIPAA documentation retention period.
• Business Associate Agreements with the cloud provider, the device manufacturer if it stores data, the eFax or messaging vendor, and any offshore development partner that touches ePHI.
• Role based access so a medical assistant reviewing alerts cannot export a population level data set.

FDA cybersecurity requirements for connected devices

Any RPM device that contains software and can connect to the internet is a cyber device under section 524B of the Federal Food, Drug, and Cosmetic Act, which took effect in March 2023. Manufacturers must submit a cybersecurity plan, provide a software bill of materials, and maintain postmarket vulnerability management. The FDA’s final premarket cybersecurity guidance issued June 27, 2025 details what those submissions must contain. If you are building the device as well as the platform, or if your platform software itself is regulated as software as a medical device, these requirements apply to your development process, and our medical device software development guide covers IEC 62304 and the related quality system obligations.

For the full set of administrative, physical, and technical safeguards, our HIPAA Security Rule checklist and HIPAA compliance guide walk through each one. Hosting choices that keep you on the right side of the Security Rule are covered in our review of HIPAA compliant hosting providers.

How Do You Integrate Remote Patient Monitoring Data With an EHR?

Remote patient monitoring data reaches the EHR through HL7 FHIR R4 APIs, writing each device reading as a FHIR Observation resource linked to a Patient resource and a Device resource, with alerts surfaced through the EHR’s own inbox or task list rather than a separate portal. Certified EHRs must expose FHIR R4 APIs under federal information blocking rules, which makes reading patient demographics and writing observations far more standardized than it was five years ago. Older interfaces use HL7 v2 ORU messages for results, and some health systems still require them.

Integration is where RPM budgets most often go wrong. Reading data from an EHR is well supported; writing device observations back and triggering clinician workflow is vendor specific and requires app registration, security review, and testing in the health system’s sandbox. Each EHR vendor integration adds two to four months and a separate cost line, which we detail in our guides to FHIR integration, Epic EHR integration, and medical device integration.

Integration decisions to make before writing code

• Whether alerts land in the EHR inbox, a standalone dashboard, or both, because clinicians will not reliably check a second system.
• Whether the platform writes every reading to the chart or only summaries and out of range values, because writing 288 CGM readings a day to a chart is noise.
• Which system is the source of truth for the patient’s active medication list when the care team titrates a dose based on RPM data.
• How billing time is captured so that 99457 and 99470 minutes flow to the practice management system without manual re entry.

Should You Build or Buy an RPM Platform?

Buy a remote patient monitoring platform if your organization is a practice or health system running a standard hypertension, heart failure, or diabetes program under Medicare RPM codes and your differentiation is clinical, not technical. Build a custom platform if RPM is the product you sell, if your clinical protocol or device mix is unusual, if you need to own the patient data and the roadmap, or if vendor per patient per month fees will exceed the cost of ownership at your projected scale. Most organizations that come to Arkenea with a build request fall into the second group.

The case for buying

Established RPM vendors supply devices, logistics, connectivity, a clinical dashboard, billing code assignment, and in many cases the monitoring staff. A practice can enroll its first patients in weeks. The tradeoffs are per patient monthly fees that scale with the program, limited control over workflow and integrations, data that lives in the vendor’s system, and a roadmap set by the vendor’s largest customers rather than by you.

The case for building

Digital health companies whose business is the RPM program itself, specialty groups with protocols that off the shelf dashboards cannot express, and organizations combining RPM with telemedicine, care coordination, or a consumer facing app usually need a custom platform. Building costs more up front and takes longer, but it produces an asset the company owns, integrations shaped to its EHR and device fleet, and unit economics that improve with scale rather than scaling with fees.

The hybrid most of our clients choose

The pattern that works most often is to buy the commodity layers and build the differentiating ones. Device fulfillment, cellular connectivity, and raw ingestion are commodities available through device manufacturer APIs. The clinical logic, the patient experience, the EHR workflow, the billing engine, and the analytics are where the value is, and that is what gets built. This keeps the build scope to what matters and avoids spending engineering budget on hardware logistics.

How Much Does It Cost to Build Remote Patient Monitoring Software, and How Long Does It Take?

Based on Arkenea’s project history, a remote patient monitoring platform with device integration, a patient mobile app, a clinical dashboard, alerting, and RPM billing logic costs $150,000 to $300,000 and takes 5 to 8 months to reach a production ready first release, and an enterprise platform with FHIR based EHR integration, multi tenant support, CGM class data streams, and analytics runs $350,000 to $700,000 over 9 to 14 months. These are US market figures for a HIPAA compliant build with a dedicated healthcare team, and they exclude hardware and cellular data plans.

What moves the number

• Device mix: discrete reading devices are inexpensive to integrate; continuous streams from CGMs or ECG patches add data engineering and alerting complexity.
• EHR integration: each vendor integration adds roughly two to four months and a separate cost line, with Epic and Oracle Health at the higher end because of their app review processes.
• Billing engine: automated day counting, minute tracking, and code selection across the 2026 tiers is a meaningful module, not a report.
• Regulatory scope: if the software itself is classified as software as a medical device, IEC 62304 documentation and FDA premarket cybersecurity content add time and cost.
• Platforms: a native iOS and Android patient app plus a web clinician application costs more than a single web application, but adherence favors native apps for patients.

Our full breakdown of healthcare software pricing, including how staffing model and location affect the range, is in our guide to the cost of developing medical software. Vendor quotes below $100,000 for a HIPAA compliant RPM platform almost always exclude EHR integration, billing logic, or the security controls described above, and those items surface as change orders later.

How Do You Launch an RPM Program in Six Steps?

Launching a remote patient monitoring program means choosing one or two conditions where daily data changes decisions, defining a clinical protocol with thresholds and an endpoint, selecting devices by adherence rather than feature count, assigning who reviews data and who contacts patients, mapping every workflow activity to the CPT code it supports, and measuring enrollment, transmission days, and outcomes from the first month. Programs that skip the protocol step end up with data nobody acts on, which is the failure mode the outcomes evidence warns about.

1. Define the population and the protocol: pick hypertension or heart failure first, write the thresholds that trigger a call, and set the expected duration, such as 90 days of titration followed by step down monitoring.
2. Plan reimbursement before enrollment: confirm Medicare and commercial payer coverage, model revenue at the 2026 rates, and decide how copays will be communicated to patients.
3. Choose devices by adherence: cellular devices for patients without smartphones or reliable internet, Bluetooth devices for patients who will use an app, and never a device that requires manual entry for billed readings.
4. Assign clinical roles and supervision: name who reviews alerts daily, who makes the monthly interactive contact, and which practitioner holds the NPI on claims.
5. Build or configure the software so that transmission days, clinical minutes, interactive communication, and the ordering provider are captured automatically and mapped to 99453, 99454 or 99445, and 99457 or 99470.
6. Measure from month one: enrollment, percentage of patients reaching 16 transmission days, blood pressure control rate, readmissions, and revenue per patient, and use the numbers to expand or adjust.

A dedicated healthcare software development company that has built RPM applications before will already know the HIPAA, FDA, and CMS requirements above and will scope the build around them from the start. That knowledge is the difference between a platform that passes its first payer audit and one that needs to be rebuilt.

What Arkenea Has Learned Building RPM Applications

Two of our remote patient monitoring engagements illustrate the decisions above: TeleMedHome, a HIPAA compliant chronic care RPM application for a physician led company, and MiPHR, a diabetes risk reduction and health management platform that connects to consumer health devices and sends monthly reports to providers. Both taught us that the patient facing design and the provider communication path decide adoption more than any single feature.

TeleMedHome: reducing readmissions through coordinated monitoring

The physician led company behind TeleMedHome was seeing high rates of hospital admissions, morbidity, and early mortality among chronic disease patients, and attributed much of it to the absence of a platform connecting patients, family caregivers, and providers. Arkenea built an iOS application with remote monitoring for high risk chronic patients, medication and appointment reminders, HIPAA compliant exchange of text, images, and video, shared care plan progress tracking across patients, family members, and clinicians, and instant video calling. The design principle was a clutter free interface so that elderly patients and their caregivers could stay engaged without training, which is the adherence lesson the outcomes evidence supports.

MiPHR: consumer device data that reaches the provider

MiPHR is a mobile health management application focused on diabetes risk reduction. Arkenea integrated it with the USDA food database and QR code scanning for calorie tracking, with leading consumer smart devices for automatic synchronization of health parameters, and with eFax so that detailed monthly and summary reports reach the patient’s healthcare provider automatically. It also uses face ID and fingerprint lock on the device. The eFax decision is the instructive one: the providers receiving the reports did not have a FHIR endpoint available, so the integration met them where they were rather than waiting for an interface that did not exist.

What we would tell a founder starting an RPM build today

Decide the billing model and the EHR path before the first sprint, because both shape the data model. Design for the patient who has no smartphone and the caregiver who does. Treat the audit trail as a feature with its own acceptance criteria. And scope the first release to one condition and one device class, because the evidence and the reimbursement rules both reward programs that do one thing well and then step patients down.

Frequently Asked Questions About Remote Patient Monitoring

What is remote patient monitoring in simple terms?

Remote patient monitoring is a service in which patients use connected medical devices at home to record data such as blood pressure, weight, or blood glucose, the devices send the readings automatically to the care team, and clinicians review the data and intervene early when something looks wrong, all between regular office visits.

Who is eligible for remote patient monitoring under Medicare?

Any Medicare Part B patient with a chronic or acute condition that requires monitoring is eligible, provided a practitioner determines it is medically necessary, the patient consents, and the device meets the FDA definition of a medical device and transmits data digitally on at least 2 days in a 30 day period.

What is the difference between RPM and RTM?

Remote patient monitoring collects physiologic data such as blood pressure, weight, glucose, and oxygen saturation and is billed by physicians and non physician practitioners. Remote therapeutic monitoring collects non physiologic data such as medication adherence, pain, and musculoskeletal function, and can also be billed by physical and occupational therapists.

Can remote patient monitoring be billed with chronic care management?

Yes. RPM and chronic care management can be billed for the same patient in the same calendar month, and the same applies to transitional care management and behavioral health integration, as long as the clinical time counted toward each service is separate and each service’s own requirements are documented independently.

Do patients need a smartphone or home internet for remote patient monitoring?

Not if the program uses cellular connected devices, which transmit readings through an embedded modem without an app, Bluetooth pairing, or home internet. Bluetooth devices do require a smartphone or a hub. Programs serving elderly or rural populations usually see higher transmission day counts with cellular devices.

How long should a patient stay on remote patient monitoring?

It depends on the condition and the protocol, but the evidence for hypertension shows control is typically reached within three to six months of active medication management. Programs should define an endpoint or a step down to lower intensity monitoring under CPT 99445 rather than keeping patients on indefinite device supply.

Is remote patient monitoring software a medical device?

Sometimes. Software that only stores and displays readings is generally not regulated, while software that analyzes data to drive a diagnosis or treatment decision may qualify as software as a medical device and fall under FDA premarket requirements. The classification depends on intended use, so settle it with regulatory counsel before development starts.

How much does remote patient monitoring reimburse per patient per month?

At approximate 2026 national Medicare rates, a standard month billing 99454 and 99457 pays about $99 per patient, an engaged month adding one 99458 pays about $141, and a low touch month billing 99445 and 99470 pays about $73. Actual amounts vary by locality and payer.

If you are planning a remote patient monitoring platform, whether a first release for a new digital health company or an EHR integrated system for a health system, Arkenea’s remote patient monitoring software development team can scope the build, the compliance architecture, and the integration path with you before you commit budget. Book a consultation and bring your clinical protocol; the software follows from it.