I've watched enough BlazePose demos to know the moment they always end. The skeleton overlay tracks the person's body. The joint angles update in real time. The presenter says something like "and this all runs on device." The room is impressed. Then the demo stops — because what comes next, the thing that would tell you whether the movement was right and what to do about it, is the part nobody has shipped as a product.
That gap is why I started building AI Biomechanics for PT Platforms & Corporate Wellness.
The Meeting That Clarified the Real Build
My first conversation with a PT clinic director about exercise verification software didn't go where I expected. I walked in thinking the question was model accuracy — whether our pose estimation could hit the joint angle thresholds the clinical literature specifies. She stopped me about ten minutes in.
What she needed wasn't more accurate keypoints. She needed a system that could tell her, for a 62-year-old patient eight weeks post-ACL reconstruction, whether a squat at 78 degrees of knee flexion was acceptable progress or a warning sign. That judgment depends on whether the patient was at 60 degrees two weeks ago, whether they're showing valgus deviation, whether their descent tempo suggests compensatory movement. BlazePose returns 33 keypoints per frame. It doesn't return any of that.
The intelligence layer she needed — exercise-specific, population-aware, configurable per patient per protocol — is what she'd assumed existed somewhere as software you could buy. When I told her it didn't, that the companies who had solved it (Hinge Health, Sword Health post-Kaia acquisition) had locked it inside their own care models, she looked at me like I'd said something unexpectedly expensive.
Hinge Health is projecting $732M in 2026 revenue. Their TrueMotion computer vision achieves published outcomes — 56% fewer spinal fusions, 73% fewer knee replacements in their patient population. But TrueMotion lives inside Hinge Health's care delivery. You cannot embed it in your PT platform. Sword acquired Kaia Health in January 2026 for $285M, combining Kaia's Motion Coach computer vision with Sword's M-band wearable. The most clinically validated digital MSK capability now belongs to two companies with no interest in selling it to competitors.
What RTM Billing Actually Requires
I didn't fully understand the RTM billing documentation standard until I was deep into the build with a PT platform that was trying to capture the CMS 2026 expansion. The new CPT codes — 98985 and 98979 — lowered the RTM threshold from 16 monitoring days to as few as 2 days, and from 20 management minutes to 10. More patients were newly billable. But the documentation requirement was unchanged: device-gathered data, timestamps, quality metrics, protocol mapping to specific CPT line items, and a demonstrated connection to treatment decisions.
The platform we were working with had been tracking exercise via patient self-report. That doesn't qualify. The leap wasn't just "add a camera" — it was building the pipeline from camera to RTM-compliant output. Pose estimation extracts keypoints. The exercise intelligence layer applies biomechanical thresholds, identifies deviations, classifies rep quality, and maps the structured output to the CPT documentation format. None of those intermediate steps were off the shelf.
The adherence problem is the context that made this gap visible to me: only 35% of PT patients fully adhere to home exercise programs (Physiopedia/Sprypt, 2025). Clinicians can't distinguish the 65% who didn't exercise from the ones who exercised incorrectly, and self-report doesn't tell them either way. The 2026 RTM expansion gives platforms more billable patient-days. But billing still requires device-gathered data with quality metrics — not a form the patient filled out. Limber Health runs the billing workflow efficiently. MedBridge and Force Therapeutics handle EHR integration and patient engagement. None of them solve the upstream problem of where the verified exercise data comes from. That's the gap each of them depends on being solved by someone else.
The RTM billing expansion lowered the threshold for how long you have to monitor. It didn't change what monitoring actually requires.
The Corporate Wellness Conversation That Changed My Architecture Thinking
The conversation I keep returning to happened with a corporate wellness director at a mid-market company. She'd run multiple wellness programs over the years. All of them had the same shape: high engagement at launch, drop-off within six weeks, and whatever exercise tracking she used got gamed — Fitbit-shaking, watch-on-a-fan, self-logged workouts that never happened.
What reframed the technical problem for me was the constraint she put on the replacement: she needed verification that her employees would actually consent to use. The way she put it was that if the system felt like surveillance, she'd lose the employees before she ever got the compliance data she needed to justify the program.
That constraint — privacy-first architecture as an adoption requirement, not a legal afterthought — is what pushed me toward on-device inference. NPU-accelerated processing on the phone (CoreML on iOS, NNAPI on Android) produces aggregate compliance data without any video frames or raw keypoint coordinates leaving the device. The employee's movement data never hits a server. The employer receives rep counts, quality scores, and protocol completion percentages. The biometric data never transmits.
The BIPA exposure added a legal dimension to the conversation she and I had about trust: Illinois saw 107 new BIPA class action lawsuits in 2025 alone, and the Seventh Circuit capped per-person damages in April 2026, but the legal theory for treating gait and movement data as biometric data under BIPA and GDPR Article 9 is well-established. Over 50% of employees express reluctance to share health data with their employer (ROI/VOI measurement studies). On-device processing eliminates the liability exposure at the source — and gives the employees something concrete to point to when their company's privacy skeptics ask where the camera footage goes.
The Accuracy Question I Stopped Leading With
Early on, I spent a lot of time explaining the MAE numbers — mean absolute error for knee flexion angles from monocular cameras runs 9–22 degrees depending on lighting, body habitus, and what the person is wearing (Nature Scientific Reports, 2025). I thought that was the credibility question. It turns out it wasn't.
The buyers didn't want to know whether our angle measurements were clinically accurate in the abstract. They wanted to know whether the measurements were accurate enough for their specific use case. A PT director managing post-ACL patients with 90-degree flexion targets needs to know whether her verification system can reliably distinguish "reached target" from "fell short." A corporate wellness director tracking whether employees completed their prescribed sets doesn't need clinical-grade joint angle measurement at all — she needs fraud-resistant rep counting and protocol verification.
The architecture that made both use cases work wasn't a more accurate model. It was population-adaptive threshold configuration: separate threshold tables for different patient populations (post-surgical vs. arthritic vs. wellness), configurable per exercise per protocol, adjustable by the clinician rather than hard-coded by the system. MSA-TCN, the current state-of-the-art temporal convolutional architecture for human activity recognition, hits 98.7% accuracy at 0.08 MB and 1.8ms inference on a mid-range smartphone (IEEE, 2025) — the latency and size characteristics make on-device deployment practical. But accuracy on a benchmark dataset is only the starting point. The clinical usefulness comes from the threshold layer that sits above it.
The MAE range from monocular cameras isn't the problem to solve — it's the given to design around. The question I stopped asking was "how do we improve accuracy" and started asking "how do we make this accuracy range clinically meaningful for each specific population."
What the Build Actually Taught Me
I spend more time thinking about the pipeline from pose estimation to RTM documentation than I do about the pose estimation model itself. The model is a solved problem, or close enough. The pipeline — exercise definition, threshold calibration per population, biomechanical rule engine, RTM output formatting, EHR integration hooks — is where the actual engineering complexity lives.
The B2B SDK landscape (Kemtai's WebGPU browser-based computer vision, QuickPose's iOS SDK for fitness developers) stops at the real-time feedback layer for general fitness. Neither configures clinical thresholds per patient population or produces RTM-compliant output. The billing workflow platforms (Limber Health with patent-pending risk stratification, MedBridge serving 3,500+ healthcare organizations, Force Therapeutics' surgical recovery pathways) handle everything downstream of the exercise data. What nobody has built is the pipeline that connects camera to clinical documentation.
The FDA's January 2026 guidance reduced oversight for general wellness products — exercise monitoring positioned for wellness use can avoid SaMD classification. PT platforms with RTM billing needs operate differently; they accept that classification trade-off for the billing revenue. The architecture is the same either way; what differs is the claims layer and the compliance framing. That's actually a feature for platforms building in both markets: one verification engine, two positioning paths.
I don't know whether the next generation of agentic health AI — autonomous monitoring that adjusts protocols based on real-time performance data, the direction that BCG and ARPA-H's ADVOCATE program are both pointing toward — will be built by the PT platforms that currently lack the verification layer, or by the incumbents who have it locked in their care models and haven't opened it up. What I do know is that the platforms making architecture decisions right now are choosing whether to build this layer into their own product or to depend on it existing somewhere they can access. The first choice is harder. The second choice depends on something that doesn't exist yet.
The architecture we built for AI Biomechanics for PT Platforms & Corporate Wellness was designed to be the thing in the middle. Whether that ends up being the right approach is something the market will answer. But the gap between free pose estimation and verified exercise documentation is real, and I haven't seen a product that fills it from the outside.