Remote patient monitoring is becoming an important part of how healthcare organizations manage chronic conditions, support patients between appointments, and deliver care beyond traditional clinical settings. But as remote monitoring programs grow, the software behind them must keep pace with changes in medical billing, clinical workflows, and reimbursement requirements.

In 2026, new Current Procedural Terminology (CPT) codes give healthcare providers more flexibility to report certain remote monitoring services delivered over shorter periods and with less monthly treatment management time. These updates affect both Remote Physiologic Monitoring (RPM) and Remote Therapeutic Monitoring (RTM).

For healthcare organizations, digital health startups, and remote monitoring platform developers, the question is no longer simply whether a platform can collect patient data. It is whether the software can track qualifying activity, document clinical work, distinguish monitoring programs, and support accurate billing under the applicable payer rules.

This guide explains the 2026 RPM and RTM CPT code changes, the software capabilities healthcare organizations should prioritize, and how thoughtful Healthcare Software Development can help build a more reliable remote monitoring platform.

What Are the 2026 RPM and RTM CPT Code Changes?

The American Medical Association introduced new remote monitoring codes effective January 1, 2026. The changes address shorter monitoring periods and treatment management services that fall below previously established time thresholds.

Two important changes affect RPM, while three new codes expand reporting options for RTM. Existing codes and their descriptors also require review where applicable.

For developers working on 2026 RPM CPT codes software, this means billing logic should not assume that every patient must meet the same monitoring-duration or treatment-management threshold.

New RPM CPT Codes for 2026

Remote Physiologic Monitoring focuses on collecting physiologic health data through connected medical devices. Common examples include blood pressure monitors, weight scales, pulse oximeters, and glucose-monitoring devices.

The two new RPM codes are:

CPT 99445 — Shorter-duration RPM device supply

This code covers remote physiologic monitoring of qualifying physiologic parameters for 2–15 days within a 30-day period, subject to applicable billing requirements.

Previously, software workflows built around the traditional 16-day monitoring threshold could fail to identify shorter periods that may qualify under the new code.

A capable platform should therefore calculate qualifying transmission days automatically and distinguish the shorter-duration pathway from the existing CPT 99454 pathway.

CPT 99470 — Shorter-duration RPM treatment management

This code covers the first 10 minutes of qualifying RPM treatment management services performed by a physician or other qualified healthcare professional, or clinical staff when permitted, in a calendar month.

It creates a reporting option for qualifying management activity that does not reach the traditional 20-minute threshold associated with CPT 99457.

Remote monitoring software should capture time accurately, distinguish clinical management from administrative work, and maintain supporting documentation.

These codes do not mean that every short monitoring period or brief patient interaction is automatically billable. Eligibility, medical necessity, documentation, and other applicable requirements still matter.

New RTM CPT Codes for 2026

Remote Therapeutic Monitoring focuses on therapy-related information, such as respiratory status, musculoskeletal function, and adherence to a prescribed treatment plan. Depending on the program, information may be collected through connected devices or reported by patients through an appropriate technology-enabled workflow.

The 2026 RTM updates introduce three codes:

CPT 98984 — Shorter-duration respiratory monitoring

This code provides a reporting pathway for qualifying respiratory monitoring over 2–15 days within a 30-day period.

CPT 98985 — Shorter-duration musculoskeletal monitoring

This code provides a reporting pathway for qualifying musculoskeletal monitoring over 2–15 days within a 30-day period.

CPT 98979 — Shorter-duration RTM treatment management

This code covers the first 10 minutes of qualifying RTM treatment management services in a calendar month.

These additions give eligible programs more flexibility when monitoring and management activity falls below traditional thresholds. Software should recognize the appropriate monitoring category, calculate qualifying days, and record management time separately.

The precise code descriptors, applicable edits, and payer requirements should be verified against the current CPT code set and official billing guidance before production deployment.

RPM vs. RTM: What Remote Monitoring Software Must Understand

Although RPM and RTM share some operational similarities, they are not interchangeable. Their underlying data, clinical objectives, and billing requirements differ.

Remote monitoring software should preserve those distinctions from patient enrollment through reporting and claim preparation.

Remote Physiologic Monitoring (RPM)

RPM is generally used to monitor physiologic measurements associated with acute or chronic conditions.

Examples include:

• Blood pressure readings for patients with hypertension.

• Weight measurements for patients at risk of fluid retention.

• Oxygen saturation readings for patients with respiratory conditions.

• Glucose measurements collected through qualifying connected devices.

A suitable RPM platform should support device integration, automatic data transmission, measurement validation, threshold-based alerts, clinical review, and treatment-management documentation.

It should also identify gaps in incoming data and give authorized staff a clear view of each patient's monitoring activity.

Remote Therapeutic Monitoring (RTM)

RTM is designed around therapeutic information and treatment adherence rather than physiologic measurements alone.

Examples include:

• Respiratory therapy monitoring.

• Musculoskeletal recovery and functional activity.

• Patient adherence to prescribed exercises or treatment plans.

• Therapy-related symptoms reported through an application.

RTM software may require structured patient questionnaires, adherence tracking, therapy plans, clinician messaging, and progress reporting.

A platform that supports both RPM and RTM should maintain separate program configurations and code-selection rules. It should not assign a billing code solely because a device transmitted data or a patient opened an application.

7 Software Capabilities Every RPM and RTM Platform Should Support in 2026

The most important software changes are not limited to adding a few CPT codes to a billing dropdown. They involve making the entire monitoring workflow more measurable, auditable, and adaptable.

1. Configurable CPT Code and Billing Rules

Remote monitoring software should maintain a configurable rules engine for applicable RPM and RTM codes.

The engine should account for:

• Monitoring duration within the applicable reporting period.

• Qualifying data-transmission days.

• Treatment-management time within the correct calendar month.

• The distinction between device-supply and treatment-management services.

• Relevant patient eligibility and program requirements.

• Payer-specific policies and applicable claim edits.

For example, a patient may transmit qualifying physiologic readings on 12 days during a 30-day period. The platform should identify the shorter-duration monitoring pathway for review rather than automatically marking the patient as ineligible because the traditional 16-day threshold was not reached.

Likewise, if a clinician records 12 minutes of qualifying treatment-management time, the software should identify the relevant shorter-duration pathway when its requirements are satisfied.

These are workflow examples, not guarantees that a claim is payable.

Development priority: Store code descriptors, effective dates, eligibility conditions, and payer-specific rules as versioned configuration rather than hardcoding them throughout the application.

2. Automatic Monitoring-Day Calculations

Manual counting is error-prone, particularly when healthcare teams manage hundreds or thousands of enrolled patients.

A reliable platform should calculate qualifying transmission days using timestamped device data and the applicable reporting rules.

Important capabilities include:

• Daily monitoring activity summaries.

• Configurable 30-day monitoring windows.

• Duplicate-reading detection.

• Time-zone-aware timestamps.

• Data-gap identification.

• Monitoring-period status and eligibility indicators.

• Alerts when additional documentation or review is needed.

The system must distinguish a successful data transmission from a valid qualifying monitoring day. Repeated readings, incomplete uploads, or records that fail applicable requirements should not automatically count as qualifying activity.

3. Accurate Clinical Time Tracking

Treatment-management codes depend on documented time and qualifying professional work.

Remote monitoring software should help clinicians record their activity without adding unnecessary administrative burden.

Useful features include:

• Start and stop time entries where appropriate.

• Manual time entry with audit history.

• Patient-specific activity logs.

• Documentation of qualifying clinical work.

• Monthly time summaries.

• Duplicate or overlapping time detection.

• Review and approval workflows.

The software should not count every phone call, automated notification, or administrative action as billable treatment-management time.

It should also avoid counting the same work toward multiple services when prohibited by applicable rules. Clinicians and billing teams must be able to review the underlying record before a claim is submitted.

4. Connected Medical Device Integration

Device connectivity remains fundamental to RPM.

A modern platform may integrate with blood pressure monitors, weight scales, pulse oximeters, glucose devices, and other supported technologies.

However, integration is not simply about receiving a number from a device. The platform must preserve the source and context of the data.

Recommended capabilities include:

• Secure device onboarding and pairing.

• Device identity and patient association.

• Automated data ingestion.

• Unit normalization and timestamp validation.

• Handling of delayed or failed transmissions.

• Duplicate and anomalous record detection.

• Device connectivity monitoring.

• Traceable data provenance.

Where Medicare RPM requirements apply, the software should help establish that the device and transmission process meet the relevant requirements. A consumer application or manually entered measurement should not automatically be treated as qualifying RPM device data.

5. Clinical Alerts and Escalation Workflows

Monitoring data becomes valuable when care teams can act on it appropriately.

For example, a patient with hypertension may submit a reading that requires clinical review. The software should route the alert to the appropriate team member, document the review, and preserve any resulting action.

Important features include:

• Clinician-configurable thresholds.

• Alert prioritization.

• Assignment to the responsible care team.

• Escalation for unreviewed alerts.

• Patient communication records.

• Follow-up task management.

• Documentation of clinical decisions.

Alert thresholds should reflect the clinical program and its protocols. Automated alerts must not be presented as a replacement for professional judgment or emergency care.

6. EHR Integration and Interoperability

Remote monitoring platforms rarely operate in isolation. Healthcare organizations often need to exchange data with electronic health record (EHR) systems, practice management platforms, billing systems, and patient engagement tools.

A well-designed integration layer can reduce duplicate entry and make monitoring information available where clinicians already work.

Consider supporting:

• Patient and encounter data exchange.

• Relevant clinical observations.

• Care-plan information.

• Clinical notes and management records.

• Device and monitoring status.

• Approved billing and reporting workflows.

• Standards-based integrations using appropriate HL7 FHIR resources and APIs.

Integration scope should be based on the receiving system's capabilities, the data needed for the workflow, and the applicable privacy and security requirements.

Healthcare Software Development teams should also design for failed messages, duplicate events, reconciliation, and auditability. A successful API request does not always mean the receiving EHR has correctly stored or processed the data.

7. Audit-Ready Reporting and Billing Review

A billing dashboard should help staff understand why a patient appears eligible for a particular code and which requirements still need review.

Useful reporting features include:

• Patient-level monitoring summaries.

• Qualifying transmission-day counts.

• Documented treatment-management time.

• Missing-data and documentation alerts.

• Code-rule evaluation results.

• Clinician review and approval status.

• Claim preparation and export.

• Historical audit trails.

Each proposed billing code should be traceable to the relevant monitoring records and clinical documentation.

The platform should flag incomplete records rather than silently treating missing information as proof of compliance. Final coding and claim submission should remain subject to appropriate clinical and billing review.

How to Design a Future-Ready 2026 RPM CPT Codes Software Architecture

Adding the new codes to an existing application may seem straightforward, but a more sustainable approach is to design the platform around configurable monitoring workflows.

A practical architecture includes five connected layers.

1. Device and patient data layer

Collect readings, device events, patient-reported information, and timestamps from supported sources. Validate incoming data before using it for clinical workflows or billing calculations.

2. Monitoring rules engine

Evaluate qualifying monitoring days, reporting windows, program type, and relevant code conditions. Keep RPM and RTM logic separate where their requirements differ.

3. Clinical workflow layer

Manage enrollment, care plans, alerts, clinician reviews, communications, follow-ups, and treatment-management documentation.

4. Billing and compliance layer

Apply versioned code rules, generate review queues, identify missing evidence, and prepare structured billing information for authorized staff.

5. Reporting and integration layer

Connect with EHRs and billing systems, produce operational reports, and maintain traceable records of system decisions.

This structure makes future CPT updates easier to implement and test. It also reduces the risk of billing rules becoming scattered across unrelated application components.

HIPAA, Security, and Patient Data Protection

Remote monitoring software handles sensitive health information, often across multiple devices, organizations, and third-party services.

Security must therefore be part of the initial design rather than a final development task.

Healthcare organizations should evaluate:

• Encryption in transit and at rest.

• Role-based access controls.

• Strong authentication and appropriate session management.

• Audit logging and monitoring.

• Secure API authentication.

• Backup and recovery procedures.

• Vendor and business associate responsibilities.

• Data retention and deletion policies.

• Incident response and security testing.

Where HIPAA applies, the platform's technical safeguards, administrative processes, and business associate arrangements should align with the organization's obligations.

Compliance is not achieved simply by adding encryption or displaying a HIPAA badge. It requires an appropriate combination of technology, documented processes, contractual responsibilities, and ongoing oversight.

Common Remote Monitoring Software Mistakes to Avoid

Even a technically sophisticated platform can create billing and operational problems when its workflows are poorly designed.

Using one threshold for every code

The 2026 changes make it particularly important to distinguish monitoring-duration rules from treatment-management time requirements.

Confusing RPM and RTM

The two programs have different purposes and code families. The software should not apply RPM logic indiscriminately to RTM services.

Counting all incoming data as qualifying activity

The presence of readings does not, by itself, establish that all billing requirements have been met.

Treating automated activity as clinical management

Notifications, background processing, and administrative tasks should not automatically count toward qualifying professional time.

Hardcoding code rules

Hardcoded logic makes updates expensive and increases the risk of inconsistent behavior across modules.

Ignoring payer differences

Medicare requirements, Medicare Administrative Contractor guidance, and commercial payer policies may differ. The application should support appropriate payer-specific configuration.

Overlooking auditability

When a billing decision is challenged, the organization needs to reconstruct the data, rules, documentation, and review steps that supported it.

Avoiding these mistakes requires collaboration between developers, clinicians, compliance specialists, and medical billing professionals.

How Healthcare Organizations Should Prepare for the 2026 Changes

A structured implementation plan can help healthcare organizations update their existing remote monitoring software without disrupting active programs.

Step 1: Audit Existing Billing Logic

Review how the platform currently handles monitoring days, reporting windows, treatment-management time, patient enrollment, and code assignment.

Identify assumptions that rely exclusively on older thresholds.

Step 2: Map the New and Revised Codes

Document the applicable RPM and RTM code families, their effective dates, and the requirements associated with each code.

Verify the details against the current CPT code set and relevant payer guidance.

Step 3: Update Data Models and Rules

Ensure the system stores the timestamps, device events, clinical activities, and documentation needed to evaluate the applicable rules.

Create versioned configuration so future updates can be deployed and tested consistently.

Step 4: Test Realistic Patient Scenarios

Include cases involving shorter monitoring periods, incomplete transmissions, overlapping activities, missing documentation, and different payer configurations.

Test both qualifying and nonqualifying cases. The goal is not to maximize code assignment; it is to produce consistent, defensible results.

Step 5: Train Clinical and Billing Teams

Explain how monitoring status, time tracking, documentation alerts, and code-review workflows have changed.

Make sure staff understand that software recommendations do not replace applicable coding rules or professional judgment.

Step 6: Monitor Performance After Deployment

Track data-quality issues, failed integrations, incomplete documentation, rejected claims, and discrepancies between system recommendations and billing reviews.

Use these findings to improve the software and its operational workflows.

How Auspicious Soft Can Help Build Remote Monitoring Software

Healthcare organizations developing a new remote monitoring product or modernizing an existing platform need more than basic application development. They need software that supports clinical workflows, connected devices, secure data exchange, and maintainable billing logic.

Auspicious Soft provides Healthcare Software Development and Software Development Services for organizations building digital healthcare products and business applications.

Depending on the project's scope, a remote monitoring software development engagement may include:

• Custom RPM and RTM platform development.

• Patient and clinician dashboards.

• Connected medical device integration.

• EHR and third-party API integrations.

• Configurable monitoring and billing rules.

• Clinical workflow automation.

• Secure reporting and audit trails.

• Existing healthcare application modernization.

• Ongoing maintenance and support.

For organizations already operating an RPM or RTM platform, modernization may be a practical way to introduce versioned CPT rules, improve device integrations, and reduce manual administrative work without replacing the entire system.

The appropriate solution depends on the organization's clinical workflows, target users, technical environment, payer requirements, and integration needs.

Final Thoughts

The 2026 RPM and RTM CPT code changes highlight the need for remote monitoring platforms to be flexible, accurate, and ready to evolve with healthcare requirements.

For software teams, the priority is to support shorter qualifying monitoring periods, the new treatment-management time thresholds, appropriate code selection, and reliable documentation without sacrificing clinical usability or data security.

Organizations that invest in configurable billing logic, robust device integrations, and audit-ready workflows will be better positioned to adapt to future coding changes.

Auspicious Soft can help healthcare organizations plan and develop software around these needs, from new remote monitoring platforms to targeted improvements in existing systems. The objective is to build technology that supports healthcare teams, improves operational efficiency, and remains maintainable as digital care continues to evolve.

Frequently Asked Questions

1. What are the new RPM CPT codes for 2026?

The two new RPM codes are CPT 99445, for qualifying monitoring over 2–15 days in a 30-day period, and CPT 99470, for the first 10 minutes of qualifying treatment-management services in a calendar month. Applicable coding and payer requirements still apply.

2. What are the new RTM CPT codes for 2026?

The new RTM codes are CPT 98984 for shorter-duration respiratory monitoring, CPT 98985 for shorter-duration musculoskeletal monitoring, and CPT 98979 for the first 10 minutes of qualifying RTM treatment management. Confirm the current code descriptors before implementation.

3. Does the 2026 update eliminate the 16-day RPM requirement?

No. The new shorter-duration code creates an additional pathway for qualifying monitoring over 2–15 days. It does not mean that every existing RPM code can be billed with fewer monitoring days. Software must evaluate the requirements for the specific code being considered.

4. Why does remote monitoring software need automatic CPT tracking?

Automatic tracking can reduce manual counting errors, identify incomplete records, and help clinicians and billing teams review whether documented activity meets applicable code requirements. It should support, not replace, appropriate billing review.

5. Can RPM and RTM be billed together for the same patient?

RPM and RTM have distinct purposes and billing rules. Medicare guidance generally does not permit billing both for the same patient during the same period. Organizations should verify the current requirements and applicable payer policies before configuring concurrent programs.

6. What should healthcare providers look for in RPM software in 2026?

Prioritize configurable CPT rules, automated monitoring-day calculations, accurate time tracking, device integrations, clinical alerts, EHR connectivity, secure data handling, and audit-ready billing reports.

7. Does RPM software need to be HIPAA-compliant?

When HIPAA applies, the software and the organizations using it must meet their relevant privacy, security, and contractual obligations. Appropriate access controls, encryption, audit logging, vendor oversight, and documented operational safeguards are important parts of that work.

8. Should an existing RPM platform be rebuilt for the 2026 CPT changes?

Not necessarily. Many platforms can accommodate the changes through a carefully planned update to their billing rules, data models, and reporting workflows. A larger modernization project may be appropriate if the existing architecture cannot support these changes reliably.