Physical Therapist Access: Enabling Remote Recovery Collaboration

What I Found

Patient disengagement was tied to plan freshness, not motivation.

A consistent pattern emerged: engagement dropped as recovery plans stopped evolving. Programmes became repetitive. Without PT input, exercises stopped reflecting where patients actually were in their recovery. Patients were not disengaging out of lack of motivation. The plan had stopped being relevant.

With no direct access to Physical Therapists, I adapted the research approach: structured conversations with surgeons and clinicians, triangulated with competitive analysis of comparable platforms and a stakeholder workshop in Florida. The pattern held consistently across every input.

Business Context

Introducing PT access was a deliberate commercial decision, not just a feature addition.

OrthoLogIQ's model depended on practices renewing and expanding platform usage. Enabling PT involvement created a pathway for PTs as contracted customers, increased platform stickiness across the care ecosystem, and addressed a direct commercial risk: patients who disengaged from MotionSense stopped generating the monitoring data that gave the platform its clinical value to surgeons. Sustained patient engagement was inseparable from the business model.

What I Did

Starting with the hardest model, on purpose.

The team's instinct was to start with in house PTs, lower complexity, faster to ship. I pushed to prioritise external PTs first. Solving the hardest access model early meant we would build permissions architecture that could handle all future PT types without rebuilding.

A patient-initiated consent model.

I chose a patient invited access model to preserve clinician oversight and reduce regulatory exposure. Patients invite their own PT through the MotionSense app. PTs only access patients who have explicitly granted permission, not the fastest path, but the right foundation.

Resolving a permissions conflict before any UI.

I surfaced a critical issue: Engineering's initial permissions model would have duplicated access logic across both platforms. I ran scenario mapping sessions, redirected the approach, and resolved this before the UI phase began.

Mapping the system, not just the screens.

Before wireframing anything, I mapped the full cross platform workflow with Engineering: invitation flows, onboarding, backend access rules, NPI validation, approval workflows, invitation expiry, and data visibility boundaries.

Edge cases & access state handling.

With the core flows mapped, I worked through every access state and failure mode before any high fidelity work began. This meant defining exactly what the system should show (and do) when a PT invitation expired, when a patient revoked access, when a PT had not yet registered, or when the 120-day post surgery access window closed.

Mapping these edge cases early prevented them becoming engineering surprises mid-sprint. It also ensured the UI communicated access status clearly to patients at every point , not just the happy path.

Catching an unaddressed onboarding gap.

During invitation flow mapping, I spotted the whole team had assumed patients would brief their own PT on how to use the platforms. External PTs would arrive with no context. I challenged this and designed a dedicated landing experience.

Design System Management.

PT Access was designed within the OIQ Design System. New components introduced for this feature, PT toggle states, access status indicators, and invitation flow UI, were documented with full states, variants and interaction specs in Figma. This gave Engineering a clear, consistent reference through to build, and ensured the new PT-facing patterns integrated cleanly with existing platform components.

Maintaining Information Hierarchy.

Adding PT contact details into the patient block risked overcrowding the section and pushing critical recovery data out of view. I reorganised the layout into four clearly labelled groups, Patient Details, Case Details, MotionSense Details, and Other Details, so clinically important information stayed visible and PT context sat cleanly alongside it.

How I Designed

From access model selection to a privacy first invitation architecture.

With external PTs selected as the primary user group, the design challenge shifted from who to enable to how to enable them safely. I mapped each PT model against access control complexity, permissions risk, and clinical oversight requirements. This surfaced the constraints that would define the MVP: patient-initiated invitations, restricted data visibility, and time bound access.

Invitation flows, onboarding requirements, backend access rules, NPI validation, approval workflows, and invitation expiry were all mapped before high fidelity work began. New design system components, PT toggle states, access status indicators, invitation flow UI, were documented with full states and variants in Figma, giving Engineering a clear reference through to build.

Final Designs

Some selected screens from the delivered UI.

The following screens show the key moments in the PT Access flow as shipped, the patient invitation experience in MotionSense, the PT onboarding landing page, and the reorganised patient details block in OrthoLogIQ.

Outcomes

The first time external PTs could access either platform.

Before this project, there was no mechanism for therapist collaboration once patients left the clinic. Patients whose exercise plans were updated by PTs were 54% more likely to remain active 30 days post surgery. The permissions and onboarding architecture became the foundation for future PT-facing features and billing workflows. When CMS reimbursement changes in 2024 shifted adoption patterns from individual PTs to PT organisations, the access model proved flexible enough to accommodate organisation-level onboarding. The feature also reduced clinician administrative load by distributing routine recovery plan updates to PTs, freeing surgeons to focus on higher-complexity cases rather than routine recovery management.

What Shifted

From clinician only platform to a connected recovery ecosystem.

Before this project, recovery collaboration stopped the moment a patient left the clinic. PT Access changed that, for the first time, therapists could support patients remotely, update plans as recovery evolved, and stay connected to outcomes without being part of the surgical practice. The permissions and onboarding architecture became the foundation for future PT-facing features and billing workflows. This was not a standalone feature. It was infrastructure. When CMS reimbursement changes shifted adoption patterns in 2024, the access model proved flexible enough to accommodate organisation level onboarding without rebuilding.

What I Learned

Limited access to end users means every assumption carries more weight.

Not being able to speak directly to Physical Therapists required more rigour in how I stress-tested assumptions, through competitive analysis, stakeholder triangulation, and the Florida workshop. I'd introduce lighter-touch PT conversations earlier in the process, even informally, rather than waiting for a formal research phase that did not materialise.