This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

If you are a founder or product lead scoping a physical-therapy, sports-rehab, post-surgical, or musculoskeletal product, you are building in the one telemedicine vertical where the clinical signal is a movement and the patient is usually exercising alone, at home, without a clinician in the room. That changes three things at once: you need technology that can see or sense motion, you need a safety model for unsupervised exercise, and you need to understand a reimbursement scheme — RTM — that was redesigned for 2026 specifically to pay therapists for this work. This article gives a non-technical product owner the vocabulary to make build-versus-buy decisions, talk to engineers, therapists, and auditors, and avoid the four mistakes that sink these products: weak or unsafe motion feedback, an accidental medical device, an unprotected stream of movement and video data, and a billing model that misses the codes the product was supposed to capture.

What makes rehab different from a video visit

A routine telemedicine call is a conversation with a camera attached; the doctor is mostly listening. A tele-rehabilitation session is the opposite — the picture of the patient moving is the clinical content. A physical therapist watching a patient do a squat is measuring depth, symmetry, knee tracking, and compensation, the same way a dermatologist reads the border of a mole. The movement is the data.

That single trait drives the rest of the build. It pushes a lot of the work out of the live visit and into the patient's living room, because the therapy that actually changes outcomes is the exercise the patient repeats every day between appointments — the home exercise program, or HEP. And it raises a problem video alone cannot solve: when the patient is exercising alone, who tells them their form is wrong, counts the reps, and notices they have stopped doing the program altogether?

Two answers have emerged, and your product will use one or both. The first is synchronous care: a live video visit where the therapist watches and corrects in real time. The quality bar for that video is higher than for a chat-and-talk consult, and we cover how to budget latency and resolution in latency and quality: the clinical "good enough" bar. The second is asynchronous, motion-tracked care: the patient does the program on their own, and software watches the movement and gives feedback, while the therapist reviews the data later. Most modern digital musculoskeletal products combine the two, and the distinction between live and store-and-forward care — which carries different rules and data flows — is laid out in synchronous, asynchronous, and remote patient monitoring.

Table comparing live video rehab, motion-tracked home program, and RTM by timing, data captured, billing path, and main risk Figure 1. Three ways movement-based care reaches the patient. Most products blend the live visit with a motion-tracked home program and wrap an RTM billing program around the data.

How the software actually sees movement

Movement feedback needs the software to know where the body is in space. There are two ways to get that, and the choice shapes cost, accuracy, and the patient's setup burden.

The first is pose estimation — computer vision that finds the body's joints in an ordinary camera image and tracks them frame to frame, with no markers or wearables. Think of it as the software drawing a stick figure on top of the video and watching the stick figure move. Open models such as MediaPipe, OpenPose, and RTMPose do exactly this; we cover how they work in the AI section's pose tracking with OpenPose, MediaPipe, and RTMPose, and this article stays on the clinical and compliance side rather than re-deriving the models.

The accuracy is now good enough to matter clinically. Recent studies of markerless, single-camera pose estimation report joint-angle measurements within roughly five degrees of a gold-standard, marker-based motion-capture lab, with tracking latency under 100 milliseconds — fast enough for live correction. That is the technical reason a phone on a coffee table can now coach a knee rehabilitation exercise. The camera-based digital MSK leader Hinge Health, which went public in 2025, built its program on exactly this: computer-vision motion tracking through the patient's own device camera, with no wearable sensors.

The second approach is inertial motion sensors — small worn devices (the same accelerometer-and-gyroscope chips in a phone) that measure limb motion directly. Sword Health's "Digital Therapist," an FDA-listed system, uses worn motion sensors paired with a tablet. Sensors can be more robust to bad lighting and camera angles and can sense motion the camera cannot see, at the cost of hardware to ship, charge, and support. Camera-only is cheaper and frictionless; sensors are more controlled. Many products offer both.

Whichever you choose, the output is the same kind of thing: a stream of body-position data over time, from which the software derives rep counts, range of motion, and a form score. That stream is the asset the rest of the product is built around — and, as we will see, it is Protected Health Information.

The regulatory tripwire: coach versus assess

This is the most important section in the article, so we will define every term before using it.

Software as a Medical Device (SaMD) is software that performs a medical function on its own. The FDA regulates it. The opposite is a general wellness product — software intended to encourage exercise, general fitness, or a healthy lifestyle, without diagnosing or treating disease. In January 2026 the FDA updated its General Wellness: Policy for Low-Risk Devices guidance, reaffirming that low-risk general wellness products are not regulated as devices — they either fall outside the legal definition of a device or the FDA exercises enforcement discretion. The line between the two is the line between a product you can ship this quarter and one that needs FDA authorization first.

Here is the rule of thumb for movement technology. If your software coaches a general exercise — counts reps, shows a joint angle, encourages the patient to keep going, and leaves the clinical judgment to a human therapist — you are most likely on the non-device, general-wellness side. The moment your software interprets the movement to output a clinical assessment or a treatment decision — "your rotator cuff is impinged," "advance to phase three of your ACL protocol," "this gait indicates a fall risk of X" — and a patient or clinician is expected to act on it without independent review, you have probably built a regulated device.

Decision tree: coaching exercise stays a non-device; interpreting movement into a clinical decision is a regulated FDA device Figure 2. The tripwire for movement tech. "Coach and show" stays in general wellness; "interpret and decide" crosses into device regulation. Most digital-PT motion feedback is deliberately built to stay on the wellness side.

Two FDA ideas sharpen the line. The first is its Clinical Decision Support guidance, finalized September 28, 2022, which leans on automation bias — people's tendency to over-trust a confident machine. Software that hands a clinician a specific directive they cannot independently review looks like a device; software that surfaces information a clinician still interprets can stay a non-device. The second is the intended-use test: the FDA judges your product by what you claim it does, read from your marketing, labeling, and interface. A "form coach" that markets itself as diagnosing injuries has made a device claim no matter how the code works. We unpack this boundary for AI features generally in the compliance and safety layer for clinical AI.

The practical takeaway: decide which side of the line you are on deliberately, at design time, and write your product claims to match. Most successful digital-PT products keep the motion engine as a coach and keep a licensed therapist as the clinical decision-maker — which is also, conveniently, what the reimbursement model rewards.

Reimbursement: the codes built for therapists

For most telemedicine verticals, billing is a downstream detail. For tele-rehabilitation it is a primary design input, because there is a billing scheme built specifically for this work, and getting the product to fit it is much of the business case.

That scheme is Remote Therapeutic Monitoring (RTM). Introduced in the 2022 Medicare Physician Fee Schedule, RTM is a sibling of the older Remote Physiologic Monitoring (RPM) used for blood pressure and glucose. The crucial difference for you: RTM was designed to monitor non-physiologic data — explicitly including "musculoskeletal system status" and "therapy adherence and therapy response" — and, unlike RPM, physical therapists and occupational therapists are eligible to bill it. RTM is, in effect, the code set that lets a therapist get paid for managing a patient's home program between visits. That is why every serious digital-MSK product is built around it.

The original RTM codes form a simple chain. Code 98975 covers the initial setup and patient education, billed once per episode of care. Code 98977 covers supplying the monitoring device or software for the musculoskeletal system, per 30 days. And codes 98980 and 98981 cover the therapist's treatment-management time — the first 20 minutes, and each additional 20 minutes — and require at least one interactive, real-time communication with the patient during the month. "Interactive" can be a video visit, a phone call, or, per CMS, secure messaging that meets the code's criteria.

The catch, until recently, was an all-or-nothing threshold. To bill the device-supply and management codes you needed at least 16 days of data in the 30-day period and at least 20 minutes of management time. A patient who logged 12 days and 14 minutes earned the clinic nothing — a revenue cliff that, in practice, kept many therapy clinics from launching RTM at all.

The 2026 Physician Fee Schedule changed this. The final rule (published in the Federal Register on November 5, 2025, effective January 1, 2026) added shorter-duration RTM codes: 98985 covers musculoskeletal monitoring for just 2 to 15 days in the period, and 98979 covers a 10-minute increment of management time (valued at 0.31 work RVUs, half of the 20-minute code). The threshold to bill something dropped from 16 days and 20 minutes to 2 days and 10 minutes. CMS also designated several of the new codes as "sometimes therapy" services, with the CQ/CO modifiers that apply when a therapy assistant does the work. The structural picture of how reimbursement shapes the product is in reimbursement rules that shape the product, and the RPM contrast is in chronic care management and remote patient monitoring.

RTM code map: setup 98975, device supply 98977 or new 2-15 day 98985, management 98980/98981 or new 10-minute 98979 Figure 3. The RTM code chain and the 2026 additions. The new short-duration codes lower the billing floor from 16 days and 20 minutes to 2 days and 10 minutes — the change that makes partial adherence billable.

Here is the arithmetic that shows why the 2026 change matters, using approximate national Medicare amounts you must confirm for your payers and year. Suppose a clinic enrolls a post-surgical knee patient and the patient logs movement data on 12 days and the therapist spends 14 minutes managing the program that month. Under the old rules, 12 days is below the 16-day floor and 14 minutes is below the 20-minute floor, so the billable amount is: device supply \$0 + management \$0 = \$0. Under the 2026 rules, the same engagement bills code 98985 (2–15 days, roughly \$40–50) plus code 98979 (10-minute management, roughly \$25), for about \$65–75 captured on a patient who previously generated nothing. Multiply that by a panel of a few hundred patients with imperfect adherence and the new codes are the difference between a viable program and a write-off. Reimbursement rules are jurisdictional and change yearly — treat every dollar figure here as a planning estimate and confirm current values and state coverage before you model revenue.

One more product consequence: the entire RTM revenue stream depends on the patient actually using the program. Adherence is not a "nice to have" — it is the billable event. Roughly half of patients in traditional physical therapy do not complete their home exercise program, and the central promise of a good tele-rehab product is moving that number. Streaks, reminders, progress visualizations, and therapist nudges are not engagement gimmicks here; they are revenue and outcomes infrastructure.

Safety: the patient is exercising alone

Tele-rehabilitation has a risk that a chat-based or image-based product does not: a patient performing physical movement, unsupervised, possibly after surgery or with a balance impairment, can fall or re-injure themselves. The product owns part of that safety responsibility, and a thoughtful build addresses it explicitly rather than hoping nothing goes wrong.

Three safeguards belong in the design. First, an environment and readiness check before unsupervised exercise — enough space, stable footing, a chair or wall for balance where the exercise needs it, and screening questions for symptoms that should stop the session. Second, contraindication and escalation logic — pain or symptom inputs that pause the program and route the patient to their therapist or to urgent care, never a system that cheerfully counts reps through a patient reporting chest pain. Third, clinician oversight by design — the therapist sees adherence and red-flag data and can intervene, which is both a safety control and, not coincidentally, the RTM management activity you are billing for. None of this is exotic; it is the difference between a fitness app and a clinical product.

Common mistake: the wellness app that quietly became a medical device

The failure we see most in this space is scope creep across the FDA line. A team ships a clean motion-coaching app that counts reps and shows joint angles — solidly a general wellness product. Then a well-meaning product cycle adds a feature that scores the patient's injury risk, or auto-advances them through a clinical protocol, or tells them their gait suggests a specific diagnosis. Each addition feels like a small improvement; together they turn a non-device into an unauthorized medical device, discovered only when a regulator, an investor's diligence, or an enterprise health-system buyer asks for the FDA paperwork that does not exist. The fix is cheap at design time and ruinous afterward: decide the device line up front, write product claims that match, and put any feature that interprets movement into a clinical decision through a deliberate regulatory review before it ships.

Where the movement data lives, and why it is PHI

Because so much of this care happens between visits, your architecture is a data pipeline: capture motion, send it, store it, let a therapist review it, and write the result into the record. Every hop carries Protected Health Information (PHI) — any health data tied to an identifiable person — and rehab data is unusually identifying. The video shows the patient's face and home. The motion stream is a biometric pattern. The therapy data reveals a diagnosis and a body. A "movement log" is not anonymous telemetry; it is a medical record.

Data-flow in a HIPAA boundary: camera or sensors, motion engine, therapist dashboard, EHR/RTM record, encrypted BAA hops Figure 4. The tele-rehab pipeline as a compliance boundary. Every component that can see the video or the motion stream needs a signed BAA, and every hop crossing the boundary is encrypted.

Three rules govern this pipeline, all tracing to the HIPAA Security and Privacy Rules. First, encryption: under 45 CFR 164.312(a)(2)(iv), encrypting electronic PHI is an "addressable" specification — which sounds optional but is not; for a video and motion stream there is no defensible reason to skip it, so encrypt in transit and at rest. The mechanics are in encryption in transit, at rest, and end-to-end. Second, the Business Associate Agreement (BAA) — the signed contract that lets an outside vendor handle patient data, the equivalent of the promise a contractor signs before getting a building key. Every component that can see the data needs one: the cloud store, the pose-estimation or motion-analysis vendor, the video platform, the EHR you write into. Encryption and a BAA are separate requirements; encrypted-but-un-BAA'd is still a violation. The foundation is in HIPAA for telemedicine product teams. Third, consent and recording — patients should understand that sessions and movement data are captured and stored, especially when a camera is recording inside their home; the consent and retention model is covered in patient consent, recording, and data retention.

There is also a licensing rule that shapes the product directly. A therapist must generally be licensed in the state where the patient is physically located during the session. The Physical Therapy Licensure Compact eases this: as of 2026 roughly three dozen states plus the District of Columbia participate, letting a therapist with a compact privilege practice across member states without a separate license in each. Your scheduling and matching logic has to know where the patient is and route them to a therapist licensed there — a constraint, not an afterthought.

Where Fora Soft fits in

Fora Soft has built real-time video, streaming, and AI-enabled media products since 2005, including telemedicine platforms and computer-vision systems, and tele-rehabilitation sits exactly where that experience concentrates: low-latency video for live correction, a motion pipeline built on pose estimation or sensor data, and the compliance boundary around both. The requirement comes first — diagnostic-quality movement capture inside a HIPAA boundary, with a clear line between coaching exercise and making a clinical decision — and the capability follows: a camera or sensor motion engine, BAA-covered storage and analysis, an adherence model that feeds the RTM billing path, and AI features wired so that a regulated-device decision is made on purpose, not by accident. We build the pipeline; the clinical judgment and any FDA pathway stay with you and your clinical and regulatory advisors.

What to read next

Call to action

References

  1. CMS, "Medicare and Medicaid Programs; CY 2026 Payment Policies Under the Physician Fee Schedule" — Final Rule, Federal Register 90 FR (doc 2025-19787), published 2025-11-05, effective 2026-01-01; new short-duration RTM codes and 10-minute management code. Tier 1. https://www.federalregister.gov/documents/2025/11/05/2025-19787/medicare-and-medicaid-programs-cy-2026-payment-policies-under-the-physician-fee-schedule-and-other
  2. eCFR, 45 CFR 164.312 — HIPAA Security Rule technical safeguards; (a)(2)(iv) encryption/decryption (addressable). Tier 1. https://www.ecfr.gov/current/title-45/section-164.312
  3. eCFR, 45 CFR 160.103 — definitions of Protected Health Information and Business Associate. Tier 1. https://www.ecfr.gov/current/title-45/section-160.103
  4. U.S. FDA, "General Wellness: Policy for Low-Risk Devices" — guidance reissued January 2026; low-risk general wellness products are non-devices or receive enforcement discretion. Tier 1/2. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-wellness-policy-low-risk-devices
  5. U.S. FDA, "Clinical Decision Support Software" — Final Guidance, issued 2022-09-28 (automation bias; device vs non-device CDS criteria). Tier 2. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software
  6. American Physical Therapy Association (APTA), "Practice Advisory: Remote Therapeutic Monitoring Codes Under Medicare" — RTM codes 98975–98981, PT/OT eligibility, musculoskeletal status and therapy adherence. Tier 2/5. https://www.apta.org/contentassets/95321a10e951408db650e2f19b96699f/apta-practice-advisory-rtm-codes032023.pdf
  7. Physical Therapy Licensure Compact (FSBPT / ptcompact.org) — compact privilege; member-state count (~36 + DC as of 2026); patient-location licensing. Tier 2. https://ptcompact.org/
  8. Scientific Reports / PMC, "A real time action scoring system for movement analysis and feedback in physical therapy using human pose estimation," 2025 — markerless single-camera pose feedback; sub-100 ms latency. Tier 5. https://pmc.ncbi.nlm.nih.gov/articles/PMC12749503/
  9. Heliyon (ScienceDirect), "Exercise quantification from single camera view markerless 3D pose estimation," 2024 — joint angles within ~5° of marker-based gold standard. Tier 5. https://www.sciencedirect.com/science/article/pii/S2405844024036272
  10. Nixon Law Group, "CMS Finalizes 2026 Remote Monitoring Reimbursement Updates" — RTM codes 98979/98984/98985/98986, 'sometimes therapy' designation, RVU values. Tier 5 (analysis of the Final Rule; ref 1 governs). https://www.nixonlawgroup.com/resources/cms-finalizes-2026-remote-monitoring-reimbursement-updates-what-changed-for-rpm-and-rtm
  11. Hinge Health — camera-based computer-vision motion tracking (no wearable sensors); NYSE listing 2025. Tier 4. https://www.hingehealth.com/
  12. Sword Health — FDA-listed worn inertial motion-sensor "Digital Therapist." Tier 4. https://swordhealth.com/

Where sources disagreed, the official rule governed: the CFR text and the CY 2026 Final Rule (refs 1–5) override any vendor or law-firm paraphrase (refs 6, 10, 11, 12). RTM code numbers and thresholds were taken from the Final Rule and APTA, not from vendor blogs.