What Does Remote Therapeutic Monitoring (RTM) Software Actually Need to Do?

I sat in on a rural orthopedic practice’s RTM rollout call last spring, the kind of meeting where a vendor walks a clinical director through a platform demo and everyone nods. Twenty minutes in, the director asked one question the demo never covered: what happens to the sixty patients already enrolled in RPM if we add RTM for the same panel. Nobody on the call had an answer. That question, not the feature list, is what actually decides whether an RTM program survives past its pilot quarter.

What Counts as Remote Therapeutic Monitoring, and Why It’s Not RPM

Remote Therapeutic Monitoring (RTM) is a distinct billing category CMS created under the 2022 Physician Fee Schedule to reimburse monitoring of non-physiologic patient data: musculoskeletal status, respiratory function, and therapy adherence, meaning the exercises a patient actually completes at home, their reported pain levels, and their functional progress over time. Remote Patient Monitoring (RPM) covers physiologic data instead, blood pressure, glucose, weight, oxygen saturation, billed under a separate code family.

The practical distinction that matters most: RTM is asynchronous. The patient records data on their own schedule, using a device or software solution that meets the FDA’s definition of Software as a Medical Device (SaMD), and the care team reviews it later, unlike a live telehealth visit. And RTM opened billing eligibility to physical therapists and occupational therapists directly, not just physicians, which is the specific reason orthopedic and pulmonology practices adopted it faster than most primary care clinics did.

Practices running both programs for overlapping patients, the exact scenario from that rollout call, need software that keeps the two data types, the two provider-eligibility rules, and the two billing windows separate without a person cross-referencing spreadsheets to catch the overlap. See Mindbowser’s automated remote patient monitoring guide for the physiologic-monitoring side of this distinction.

Getting a Patient From Prescribed to Transmitting Data

The first place RTM programs lose patients is setup, and it is also the least discussed part of any RTM buyer’s guide. A therapist prescribes a home exercise program with a connected device or app. The patient needs the device provisioned, the app installed, and the first data transmission confirmed, all before CPT 98975’s initial-setup billing applies. A patient who never completes onboarding generates zero billable months and zero clinical data, and in a manual workflow, nobody notices a stalled onboarding until someone runs a monthly report, usually weeks after the window to fix it easily has passed.

The fix is not more patient education. It is a workflow that flags an incomplete setup within days, not at month-end, so staff can follow up while the patient still remembers why they agreed to the program.

What Happens Between Visits Is the Entire Point

RTM’s clinical value sits almost entirely between visits. A patient does home exercises, reports pain levels, or logs respiratory symptoms on days the practice never sees them in person, and that data is the reason RTM exists as a program at all. Handled well, this is a continuous view of recovery. Handled as a checkbox, it is a compliance requirement nobody reads.

This is the same category of problem Mindbowser has solved before in an adjacent context: MedAdhere AI runs ongoing monitoring and escalation for medication adherence, driving a 26% adherence improvement and a 12% drop in emergency visits tied to missed care in production deployments. RTM’s adherence monitoring is a different data type, exercise completion and pain reporting rather than medication doses, so it is not a drop-in reuse of that same accelerator, but the underlying pattern, watch continuously and escalate on real deviation rather than wait for the next scheduled check-in, is proven. Nobody wrote a search-engine query for “adherence monitoring software” that shows real volume today. That does not make the workflow optional. It makes it the part of the program a buyer’s guide skips and a real deployment cannot.

Not Every Alert Deserves a Phone Call

A patient who misses one exercise session is not an emergency. A patient whose reported pain score climbs for three consecutive check-ins probably is. RTM software that treats every missed data point identically produces one of two failure modes: staff drowning in alerts they learn to ignore, or staff missing the one alert that mattered because it looked the same as forty routine ones.

Alert triage is a workflow-design problem before it is a technology problem: which threshold crossings need same-day outreach, which ones can wait for the next scheduled check-in, and which patterns across several data points matter more than any single reading. This is where artificial intelligence earns its place in an RTM program, not as a marketing claim but as the specific job of surfacing the signal inside a stream of routine data. It is custom logic built around a specific practice’s clinical protocols and risk tolerance, not a packaged product, though it draws on the same triage discipline that makes MedAdhere AI’s medication-adherence escalation work in a different program.

The Billing Rules That Actually Trip Practices Up

Beyond the basic CPT structure, three rules cause most of the RTM billing errors I have seen practices walk into. First, and more specific than most guides state it: the mutual exclusivity runs by condition type, not as one blanket rule. CPT 98984 (short-window respiratory) and 98976 (long-window respiratory) are mutually exclusive, bill one or the other per patient per month. CPT 98985 (short-window musculoskeletal) and 98977 (long-window musculoskeletal) are mutually exclusive the same way. A practice chooses the window based on the patient’s actual data-transmission pattern that month, not by picking whichever code pays more. These are new device-supply codes created by the CY2026 Medicare Physician Fee Schedule Final Rule, effective January 1, 2026. Second, a practice cannot bill both the 10-minute treatment management code (98979) and the 20-minute code (98980) for the same patient in the same calendar month, only one management code applies regardless of how much time was actually spent. Third, at least one interactive communication with the patient per calendar month is required before billing any of the treatment management codes, a documentation requirement that gets missed when the clinical work happens but nobody logs the specific interaction.

None of these are exotic edge cases. They are the rules a practice hits in month two or three, after the pilot cohort looks clean and the real patient volume starts revealing the documentation gaps a small pilot never surfaces.

Twelve RTM Platforms Compare Features. None of Them Compare Workflows.

Search “best RTM software” and the results are buyer’s guides ranking platforms like Physitrack, MedBridge, Wibbi, and Limber Health against RTM-native billing tools like CCN Health, SaRA Health, and KangarooHealth, alongside broader care-management platforms including Prevounce, HealthArc, CoachCare, ThoroughCare, and CareSimple that added RTM to an existing product. Every one of these lists compares feature checklists: does it support device X, does it integrate with EHR Y, what does it cost per patient.

None of them start from the workflow this page just walked through: onboarding that gets flagged before it stalls, adherence monitoring that runs continuously, alert triage that separates signal from noise, and billing logic current with the window-selection and monthly-communication rules that actually cause denials. A rented platform built for every customer at once tends to be generic at exactly the points where a specific practice’s patient mix and provider types need something else. Mindbowser builds RTM software into the practice’s existing systems, reflecting how that specific practice runs, not a shared configuration built for the median customer across fifteen competing platforms.

Not every part of this needs custom engineering. Patient-facing exercise content, the actual library of prescribed movements and instructional video, is a licensing decision a practice makes with its clinical team, not a software build, and no accelerator or platform replaces the clinical judgment of which exercises belong in a given protocol. Software’s job is the workflow around that content, not the content itself.

Where RTM Fits Alongside a Practice’s Other Medicare Programs

RTM rarely runs alone, which is the exact question that stalled the rollout call I mentioned at the start. A patient in RTM for post-surgical rehab may also qualify for Transitional Care Management (TCM) in the weeks after discharge, or Advanced Primary Care Management (APCM) for ongoing chronic-condition coordination. See Mindbowser’s APCM guide for how tier-based billing works alongside program-specific codes like RTM’s. Software that treats each program as an isolated silo misses the revenue and the clinical picture available when a practice runs several of these programs correctly for the same patient, and it is also the reason that rollout call ended without an answer: the platform on the table had never been asked to think about more than one program at a time.