Remote Therapeutic Monitoring (RTM) App Development: CPT Codes, FDA Device Status, and Platform Architecture

You’re building a digital MSK coach, a connected-inhaler app, or a CBT homework tracker, and somewhere in the pitch deck there’s a line about Medicare reimbursement under RTM. That line is where most remote therapeutic monitoring app development goes sideways. Teams treat RTM as RPM for therapy and ship a product that bills wrong.

RTM is its own category. It has its own CPT codes, its own set of billers (physical therapists, occupational therapists, speech-language pathologists, and clinical psychologists, all of whom RPM locks out), and an FDA device requirement that quietly decides whether you can bill at all. Miss any of the three and the revenue model doesn’t hold.

The content out there won’t help you: it’s vendor marketing for clinic owners or billing summaries for coders. None of it is an engineering guide for the team building the platform.

So here’s the thesis: the billing engine is the product. Get the device-status question or the dual-clock wrong, and your claims fail audit.

How do you build a remote therapeutic monitoring (RTM) platform?

Build the billing engine as the core: a day-ledger counting qualifying device days, a time-tracker for management minutes, an interactive-communication log, and an audit trail across all three, with the patient app layered on top. To bill the device-supply codes, the app has to clear the FDA’s 201(h) medical-device definition, usually as a Class I, 510(k)-exempt device. The two hardest constraints are that device-status question and the dual-clock problem: device codes bill per rolling 30-day period, management codes per calendar month, and conflating them fails audit.

Key Takeaways:

1. RTM is its own reimbursement category, with its own codes and its own billers. The 98975-98986 set is billable by physical therapists, occupational therapists, speech-language pathologists, and clinical psychologists, all of whom RPM locks out. Unlike RPM, it allows patient self-reported data, which reshapes the whole capture layer.
2. The FDA device-status decision gates the entire product. To bill the device-supply codes, your monitoring app has to clear the FDA’s 201(h) medical-device definition, and a general wellness app can’t. The lowest-risk way to clear it is usually Class I, 510(k)-exempt: register and list, no premarket review.
3. The billing engine is why a practice keeps paying. Every counted day and logged minute exists to defend a claim when an auditor asks. The day-ledger, time-tracker, and audit trail are what that comes down to; the patient-facing app is just the surface.

Table of Contents

1. RTM vs RPM: the data type decides your architecture
2. The RTM CPT codes: each one is a line in your build spec
3. The 2026 code expansion: short-duration codes that pay the full rate
4. The FDA device requirement: why a wellness app can’t bill RTM
5. Who can bill RTM, and why that defines your buyer
6. RTM platform architecture: the billing engine is the product
7. The dual-clock problem: 30-day periods vs calendar months
8. Specialty requirements
9. Audit-proofing: documentation that survives a payer review
10. The RTM platform build checklist
11. How Topflight Apps can help build your RTM platform

RTM vs RPM: the data type decides your architecture

Start with what separates them, because from the outside it isn’t obvious. RPM and RTM both put a patient at home with a device sending data back for a monthly claim. What splits them is the kind of data, and who’s allowed to enter it.

The category error is easy to make: RPM got to market first and gets most of the attention, so reaching for its patterns is the reflex. But RTM and RPM are separate reimbursement categories, and that difference in data type is what decides your architecture.

RTM monitors non-physiologic data: therapy adherence and functional response, whether the patient is doing the exercises and whether the condition is improving. RPM monitors physiologic data captured automatically off a device:

• blood pressure,
• glucose,
• weight,
• pulse oximetry.

And RTM lets the patient self-report or manually key in readings on an FDA-defined device, where RPM demands automatic capture with no human in the loop. That self-reported data allowance is the whole difference, and it’s what your capture layer has to be designed around.

RTM vs RPM comparison

We cover the RPM side in depth in our guide to remote patient monitoring app development, so this post won’t restate those mechanics.

The RTM vs RPM difference cascades from that one line. Different practitioners can bill the codes, a different code family applies, and the capture architecture has to handle manual entry and self-report instead of a clean sensor feed. You also can’t bill RTM and RPM for the same patient in the same period.

The platform has to enforce that rule, tracking who’s billing each patient so a competing claim never goes out. Build RTM on RPM assumptions and the product is mispriced and misarchitected before the first sprint, and no amount of polish on the exercise UI fixes a billing model that was wrong at the foundation.

The RTM CPT codes: each one is a line in your build spec

Every RTM code is a product requirement. It names what your platform has to capture, log, or prove, so the remote therapeutic monitoring CPT codes are really a build spec that happens to live in a billing manual. Hand them to finance and move on, and you’ll ship a platform that can’t back up its own claims.

Take CPT 98977, the MSK device-supply code. It pays when the patient’s device transmits data on at least 16 of 30 days, so your platform needs a per-patient day-ledger: one that counts qualifying days with their source and flips the code to billable only once the count clears 16.

CPT 98980 covers the first 20 minutes of treatment management in a month, and CPT 98981 stacks each additional 20 on top of it. Both require a practitioner time-tracker that logs minutes against a patient, plus a record of at least one real-time interactive communication, a live call or video visit, inside the billing window. No logged conversation, no claim.

CPT 98975 is the setup code, billable once per episode of care. That word once is the requirement: the platform has to gate setup as a single logged event per episode, so a practice can’t re-bill onboarding every time a patient re-engages.

Four codes, three capabilities. Every other code on the list works the same way: read the rule it encodes, and you’ve read a line of your build spec.

CPT-to-product-requirement matrix

The matrix above carries the full set: ten codes, each with a plain-language descriptor, an approximate 2026 Medicare Physician Fee Schedule rate (re-verify at publish), and the platform capability it forces. Grab it as a build checklist. For the claims plumbing underneath it, see our guide to medical billing software development. The codes’ period and time rules are where the engineering risk piles up, which is what the dual-clock and audit sections get into next.

The 2026 code expansion: short-duration codes that pay the full rate

For CY2026, Medicare added short-duration RTM device codes across all three specialties: CPT 98984 (respiratory), CPT 98985 (MSK), and CPT 98986 (CBT). Each covers a 2-15 day monitoring window, a shorter tier alongside the existing 16-30 day codes. It also added CPT 98979, a management code for the first 10-19 minutes. This is the newest change to the code set, and most competitor pages haven’t caught up with it.

A 2-15 day code pays the full rate of its 16-30 day counterpart. If you’ve seen vendor pages quoting a higher number for the short MSK code, they’re wrong; CMS priced it at parity with the 16-30 day code.

So a patient who transmits 10 days of data and logs 12 minutes of management, a month that used to bill nothing, now bills at full device-supply value. Plenty of therapy patients engage briefly and drop off before hitting 16 days, so the old all-or-nothing cliff was quietly leaving a real slice of billable work on the table. That slice is now revenue you can model.

For the build, that means two new tiers:

• the day-ledger needs to recognize a 2-15 day band alongside the 16-30 one,
• and the time-tracker needs a 10-19 minute band alongside the 20-plus.

RPM picked up parallel codes the same year (99445 for the short device tier, 99470 for the short management tier), so if you’re building a combined RPM and RTM product, both clocks carry both bands.

The FDA device requirement: why a wellness app can’t bill RTM

A general wellness app cannot bill RTM. If the app itself is your device, it has to meet the FDA medical device definition in section 201(h), and the lowest-risk way there is usually Class I, 510(k)-exempt: register and list, no premarket review.

FDA device-status three-tier spectrum

The mistake most builders make is collapsing two separate questions into one.

• Question one is billing eligibility: is your app a 201(h) device at all?
• Question two is the clearance pathway: if it is a device, does it need premarket clearance or not?

They have different answers, and getting them tangled is how teams either over-build (chasing a 510(k) they didn’t need) or under-build (shipping a wellness app they can’t bill on).

The billing line: 201(h) device or general wellness

To bill the device-supply codes, your device has to clear the section 201(h) definition. A general wellness product is not a device, so it cannot satisfy the RTM medical device requirement.

These are opposite sides of one line, and the line just moved. FDA finalized its general wellness policy on January 6, 2026 and broadened what counts as wellness, which makes the safe harbor roomier and more tempting than ever.

The wellness path is attractive for a reason: it keeps you out of the FDA device process, with no registration or listing to file and no quality system to stand up. So teams write their intended-use language to stay firmly in wellness territory, then try to bill RTM and find the two goals are mutually exclusive. The status you engineered your way into is the same one that invalidates your device-supply claims.

The clearance line: exempt or 510(k)/De Novo

Meeting the 201(h) definition doesn’t automatically drag you into premarket review. A data-supply app that just feeds readings to a clinician is often a Class I medical device, 510(k)-exempt: General Controls only, which means FDA registration and listing and nothing more, no premarket submission.

The line moves once the app does more than supply data. An app that delivers a therapeutic intervention or makes an autonomous recommendation is Class II software as a medical device (SaMD), and that needs 510(k) or De Novo clearance. Most digital therapeutics land here.

Propeller Health’s connected-inhaler platform holds 8+ FDA 510(k) clearances, which is what a real Class II RTM device looks like.

Which side of that line you land on is partly a design decision. An app that surfaces data for the clinician to act on can often stay Class I and exempt; the moment it makes the call itself, you’re in Class II with a clearance timeline. Scope the autonomy deliberately, because that decision sets your regulatory cost as much as your feature set.

One more trap sits in the January 2026 CDS guidance, which broadened the Non-Device CDS exemption. Non-Device CDS is, by definition, not a device, so leaning on that exemption to skip clearance also strips the device status your RTM claims need. If the app is your intended billable device, the exemption works against you.

The full 510(k) and De Novo walkthrough is its own topic; we’ve mapped it in our guide to health AI FDA clearance.

Who can bill RTM, and why that defines your buyer

The list of who can bill RTM is your customer list. That single fact reroutes your whole go-to-market.

RTM codes are general medicine codes, which is why the biller list is so wide. Four practitioner types can all bill them:

• physical therapist
• occupational therapist
• speech-language pathologist
• clinical psychologist

So can physicians, NPs, PAs, and clinical nurse specialists.

RPM, built on E/M codes, shuts the therapists out. So your buyer is a therapy or behavioral-health practice. That’s a different customer than RPM’s physician groups, and it changes your sales motion and your onboarding.

That lockout is the opening. Because RPM can’t reach these practitioners, RTM is the only remote-monitoring reimbursement a therapy practice can bill, which makes it an easier sell than one more RPM pitch.

The billing mechanics follow from that. Therapists furnish RTM under a plan of care and append a GP, GO, or GN therapy modifier by discipline. Therapy assistants change the math: bring a PTA or OTA into the work and the de minimis 10% standard kicks in, which puts a CQ or CO modifier on the management and setup codes (98975, 98979, 98980, 98981).

Three of the codes also carry a sometimes therapy designation, so whether a given claim rides therapy rules or general medicine rules depends on the code and who furnished it. All of that modifier logic has to be encoded in the platform.

Run the per-patient math, and the model gets concrete.

• A fully-engaged MSK patient runs about $136 a month once you bill the device code (98977) and both management codes (98980 plus its add-on 98981), or roughly $158 in month one after adding setup (98975).
• A short-engagement patient on the new short-duration codes (98985 plus 98979) brings in about $66 a month, revenue that didn’t exist before 2026.

These are approximate national averages; re-verify against the fee schedule at publish.

Then there are the attribution rules, which are pure platform logic. Only one practitioner can bill RTM for a given patient in a 30-day period, and the first claim submitted is the one that gets paid, so the platform has to arbitrate before a second claim goes out.

RTM and RPM can never run concurrently for the same patient, but RTM does stack with care-management programs like CCM, PCM, and BHI when each is independently met. Those are the RTM billing requirements your platform enforces in code.

For the chronic-conditions context where a lot of this stacking happens, see our guide to chronic disease management app development.

RTM platform architecture: the billing engine is the product

Most teams build the patient app first, then bolt billing on at the end. The defensible order is the reverse.

In remote therapeutic monitoring software, the exercise videos are how the patient experiences the platform, but the billing engine underneath is what the practice pays to keep.

The architecture is three layers: data capture, a billing engine, and the clinical workflow that pushes into the EHR. The billing engine is the integrity core, the pieces that decide whether a claim is valid:

• the day-ledger
• the time-tracker
• the interactive-communication log
• the code-eligibility rules

An audit trail runs through all three, because proving a claim means tracing it from captured data to submitted code.

RTM platform architecture diagram

Get the order wrong and it shows up later. A patient app with billing bolted on can’t reconstruct why a claim was valid, because the data provenance and the timing were never first-class. Build the ledger as the foundation and the UX on top, and every claim carries its own evidence.

AllHeartz is the proof this ships: a computer-vision RTM app we built that motion-tracks a patient’s exercises for remote rehab, running on exactly this spine. We won’t retell the AI layer here; it has its own home in our guide to AI in remote patient monitoring.

The clinical workflow layer is where EHR integration stops being a checkbox. Propeller’s respiratory platform is ordered and managed inside the EHR like any medication, which cut enrollment time roughly 75 to 80% at one health system.

On the therapy side, that means integrating over FHIR with the systems these practices already run:

• WebPT,
• Net Health,
• Prompt EMR.

And every integration point that touches PHI needs a business associate agreement (BAA).

We’ve mapped the deeper EHR-integration mechanics in our guide to how to integrate with Epic EHR.

Cost is a real line item too. APTA’s private-practice group has pushed CMS to update RTM’s practice-expense inputs, because the current rates undercount what these platforms cost to run: the subscription infrastructure, plus real data-storage and cybersecurity overhead.

The dual-clock problem: 30-day periods vs calendar months

The dual-clock problem is the single most common RTM billing-logic bug, and it’s easy to miss. Device-supply codes run on a rolling 30-day period that starts on the first day of data; treatment-management codes run on the calendar month. The two clocks don’t line up.

Most platforms pick one clock, usually the monthly one because it’s simpler, and run everything off it. That’s the bug.

Take a device window that opens in mid-March. It doesn’t close until mid-April, so the device code often can’t be billed in the March calendar month, even though the interactive communication and management minutes logged in March are billable then. Key both codes to the calendar month and you bill the device code a window early, which over-bills and fails audit.

The fix is one line of product logic: track two independent clocks per patient, the rolling 30-day device period and the calendar month, and gate each code against its own. The 16 days of data trigger sits on the device clock; the interactive communication sits on the management clock.

Specialty requirements: the capture layer changes per specialty, the billing engine doesn’t

The RTM codes span three specialties, and most teams build for exactly one. The billing engine stays the same across all of them; the capture layer is what changes.

Start with MSK, the largest RTM segment and the digital MSK category that put remote therapy on the map. In musculoskeletal RTM, the platform reads musculoskeletal system status from how the patient moves, turning a phone camera into a motion sensor through:

• pose estimation
• computer vision
• motion tracking

Together they score each rep and follow the home exercise program (HEP) session by session to measure exercise adherence.

The hard part is the vision model: getting it accurate enough across the body types and camera setups real patients bring. This is the space Hinge Health, Sword Health, MedBridge, Limber Health, and Physitrack compete in, alongside our own AllHeartz, and it bills under CPT 98977 and 98985.

Respiratory changes the sensor entirely. Instead of a camera, you integrate a connected inhaler or wearable sensors that log every actuation with a timestamp, reading respiratory system status from usage patterns and technique.

The build challenge moves from vision to hardware: you’re either partnering with an inhaler-sensor maker or building your own device integration, and the data has to be reliable enough to defend a claim. Propeller Health (ResMed), Teva’s Digihaler, Adherium’s Hailie, and Amiko Respiro are the reference points here, and it bills under CPT 98976 and 98984.

The wearable side has its own build considerations, which we cover in our guide to wearable app development.

CBT has no sensor at all. The device data is ePRO, patient-reported outcomes such as:

• mood scores
• PHQ-9 results
• homework completion

These stand in as the monitored signal for cognitive behavioral therapy under CPT 98978 and 98986.

There’s no hardware to integrate, so the build problem is engagement and instrument validity: getting patients to complete validated questionnaires often enough, and reliably enough, to support a claim. A clinical psychologist bills these codes, and 98978 is carrier-priced, so there’s no national rate to model against yet.

The full behavioral-health build runs well beyond RTM; we cover it in our guide to behavioral health platform development.

Across all three, the billing engine is identical, the same one from the architecture section. You build it once, and the capture layer once per specialty you take on. The capture layer is where your product competes, but the billing engine is the part that decides whether you get paid, and you can’t ship one without the other.

Audit-proofing: documentation that survives a payer review

Every counted day and logged minute in the build exists for one moment: an auditor asking you to prove the claim.

The audit risk is real and rising

RPM payments hit $536 million in 2024, up 31% in a single year. An OIG review found 43% of enrollees were missing at least one required component of the service, and a dedicated audit of Medicare Part B remote monitoring is now underway, with findings expected in 2026.

Those figures are for RPM, but RTM won’t be spared. It runs on the same code architecture, so the same concerns apply, and that’s the enforcement backdrop every RTM platform is built against.

The direction is one-way. Remote monitoring went from niche to a billion-dollar category in a few years, and enforcement follows the money. Every quarter, the bar for what a payer will accept without question goes up, and the platform is what has to clear it.

The failures are concrete:

• MAC claim denials for missing 16-day data,
• DOJ subpoenas,
• providers self-disclosing overbilling to get ahead of it.

Auditors check four things, and your ledger has to produce the proof

Auditors converge on a short list: practitioner orders, medical necessity, days-of-data, and time. Miss any one and you’re looking at a claim denial.

The two that sink most builds are the day count and the time log: without 16 days of transmitted data, the device code isn’t billable, and without documented interactive minutes, the management code isn’t either. A platform that captures the time and the readings accurately, and documents both clearly, is what holds a claim up in a payer audit.

The documentation requirements are specific, and the ledger has to produce all of it on demand, everything behind a defensible superbill:

• device or platform name and description
• transmission-day count
• time log: date, staff, activity, minutes
• logged interactive communication
• setup education record
• active plan of care with modifier

The time tracking is where claims most often fail: no logged minutes, no billable management. A ledger that produces this whole set on demand is the moat.

This is where “the billing engine is the product” stops being a slogan. Patients see the exercise videos, but the practice renews because its claims survive a payer review. A practice on a thin platform is the one facing clawbacks two years later.

That ledger carries the same HIPAA obligations as everything else touching PHI, which we cover in HIPAA compliant software development.

The RTM platform build checklist

This is RTM app development reduced to what has to exist for claims to survive a review. It’s grouped by the layer each requirement lives in, so a team can scope against billing defensibility from day one, before the first denial forces the issue.

Capture layer (changes per specialty)

• FDA 201(h) device status settled, since a wellness app can’t bill
• specialty-appropriate capture: pose estimation and computer vision, an inhaler sensor, or ePRO
• patient self-report supported, with source provenance on every reading

Billing engine (the same across all three)

• per-patient day-ledger covering both duration tiers, 2-15 and 16-30 days, with provenance
• practitioner time-tracker covering both time tiers, 10-19 and 20-plus minutes
• a logged real-time interactive communication in every billing period
• two independent clocks per patient: the rolling 30-day device period and the calendar month
• mutual-exclusivity and one-practitioner-per-patient attribution rules
• modifier logic: GP/GO/GN by discipline, CQ/CO when a therapy assistant is involved

EHR and workflow

• FHIR integration
• order and enroll inside the EHR
• results written back to the chart

Compliance and audit

• a full audit trail spanning every layer
• the documentation set produced on demand
• medical-necessity and plan-of-care records

That’s the whole build. The checklist is the audit defense in build form.

How Topflight Apps can help build your RTM platform

If you’re like most teams we talk to, the plan is to build the patient app first, the exercise videos and the motion tracking that demo well, and wire up billing later. That’s the path that ends in claims failing audit two years in, once the volume is real and the ledger can’t reconstruct why any of it was billable. By then the fix means re-architecting the core with live patients on the platform, which is the expensive way to learn this.

We build the other way around. Topflight Apps engineers the audit-defensible core first:

• the day-ledger
• the time-tracker
• the audit trail

Those three are what make RTM claims survive review. The patient experience is the layer on top.

That comes from 10-plus years of HIPAA-bounded healthcare builds and the EHR integrations that usually eat the timeline.

Most teams pitching RTM builds have read the codes; few have shipped a platform that survived a payer review. We have. AllHeartz is that platform: our remote-rehab RTM build, with the patient app riding on top of the audit-defensible core.

If you’re going to build an RTM platform that still pays out after the auditors arrive, that’s the exact engineering problem we solve, and we’ve got the receipts. When you’re ready to scope it, our guide to healthcare app development cost is where to start.