RTM CPT Codes for Spine Practices: 98975, 98977, 98980, and 98981 Explained

By the SpineOS team · Updated July 7, 2026 · 8 min read

Remote therapeutic monitoring (RTM) lets a spine practice bill for monitoring work it is often already doing — reviewing post-op pain trends, walking activity, and exercise adherence between visits. Four CPT codes do most of that work: 98975 (setup), 98977 (data supply, with the 16-of-30-day rule), and 98980/98981 (management time). This page explains each code's requirements, the 16-day rule, what documentation survives an audit, and the question surgical practices ask first: what happens during the 90-day global period.

RTM vs. RPM in one paragraph

RTM is remote monitoring of non-physiologic data: therapy adherence, therapy response, pain scores, and functional status — the things a recovering fusion patient reports or a monitoring platform records about how treatment is going. Remote physiologic monitoring (RPM) is the older sibling that covers physiologic data — blood pressure, glucose, weight, pulse oximetry. A spine practice tracking daily pain 0–10, walking minutes, exercise-program adherence, and patient-reported wound status after surgery is squarely in RTM territory, and 98977 is specifically defined for monitoring the musculoskeletal system. If you are capturing vital signs from a connected cuff or scale, that is RPM and a different code family entirely — the two are commonly confused, and billing the wrong family is an easy way to generate denials.

The four RTM codes spine practices use

The documentation that survives an audit

Across all four codes, auditors look for the same four things. If your program can produce these on demand, you are in good shape:

• The platform or device used — what the patient was set up on, and when (this is also your 98975 documentation).
• Transmission-day counts — which calendar days had data, so the 16-of-30 threshold for 98977 is provable rather than asserted.
• Time logs for 98980/98981 — dates, minutes, who did the work, and the interactive communication for the month.
• The care actions taken — what the data changed: a medication adjustment, a program modification, reassurance after a review, an escalation. Time with no recorded action is the classic audit failure.

The 16-day rule

98977 requires data transmission on at least 16 distinct days out of the 30-day period. Distinct calendar days are what count, not data points: a patient who submits a morning pain score, an afternoon walking entry, and an evening note has logged one day, not three. A patient who checks in 15 days out of 30 does not meet the threshold, and the code should not be billed for that period.

Two practical consequences follow. First, the 16-day rule makes patient adherence a billing input — a program patients find tedious quietly falls below threshold. The easier the daily check-in, the more months clear 16 days. Second, you need the day-count before billing, per patient, per period — bookkeeping that goes wrong fast in a spreadsheet. Your platform should show distinct transmission days against the threshold, not just a pile of data.

The 90-day global period question

This is the spine-specific issue that generic RTM articles skip, and it matters because most fusions carry a 90-day global period — precisely the window when monitoring is most valuable.

The general rule: the practitioner who received the global surgical payment typically cannot separately bill RTM treatment-management time (98980/98981) during the 90-day global period, because routine post-operative management is already included in the global payment. Billing management time for reviewing your own post-op patient's data inside the global window is double-billing the same work.

But the rule is about who holds the global payment, not about RTM itself:

• A different practitioner can bill. If a physical therapist (or another practitioner who did not receive the global payment) runs the monitoring program, their RTM management time is generally separately billable even during the surgeon's global period.
• Monitoring beyond the global period is billable. Once the 90 days end, the surgeon's own RTM management time is no longer bundled — and many spine patients benefit from monitoring well past day 90.
• Commercial payers vary. Some follow Medicare's global-period logic, some do not, and some have their own RTM policies entirely. Verify with each payer before assuming either answer.

How the setup and supply codes (98975/98977) interact with the global period is payer-specific as well — confirm the treatment of every code in the family with your MAC rather than extrapolating from the management-time rule.

What a post-op spine RTM program looks like in practice

The mechanics are simpler than the code descriptions suggest. A workable program has three parts:

1. A data source patients actually use. In a SpineOS-based program, the patient side is EasySpine — a free iPhone app (currently in early-access beta via TestFlight) plus a web portal. The daily check-in asks one question at a time: pain 0–10, walking (auto-filled from Apple Health, so the patient doesn't count anything), and wound status. Each completed check-in is a transmission day; because the check-in takes under a minute, the 16-day threshold becomes a byproduct of normal recovery tracking rather than a nagging project. Validated outcome surveys like the Oswestry Disability Index run through the same stream, adding functional-status data alongside the daily entries.

2. Someone reviewing the data and acting on it. This is where 98980/98981 time comes from — a clinician or staff member reviewing trends, contacting patients (there's your interactive communication), and adjusting the plan. Given the global-period rule above, many spine practices structure this so a PT or other non-global practitioner runs the management side during the first 90 days.

3. A monthly documentation report. At the end of the period, SpineOS assembles the month's RTM documentation: the distinct data-day count versus the 16-day threshold and a per-code met/not-met status. It's the audit-facing paper trail — transmission days, thresholds, and status — generated from the data rather than reconstructed from memory. The same patient-generated data stream also feeds the conservative-care documentation that prior-authorization packets depend on, so one program serves two documentation problems.

To be precise about the boundary: SpineOS produces documentation support. It does not submit claims, assign codes to encounters, or tell you what is billable for a given payer — those are decisions for your practice and its billing team.

Frequently asked questions