New Medicare RTM reimbursement gave PAVE a market opening, earned through two non-negotiables: physician approval and auditable billing status.
On this page
In 2026, expanded Remote Therapeutic Monitoring reimbursement created a timely opportunity for healthtech teams. It also created a demanding product problem.
Remote Therapeutic Monitoring, or RTM, allows eligible practitioners to monitor how patients respond to prescribed therapy outside the clinic. For PAVE, the opportunity was to turn that reimbursement pathway into a product physicians could use with confidence: a clinical portal for care teams and a simple mobile experience for patients completing rehabilitation exercises at home.
The difficult part was not displaying activity data. It was building a system that could support clinical oversight, document the actions behind a claim, and reduce the chance of billing mistakes.
The product had to earn trust before it could earn adoption
RTM billing depends on specific evidence. Patient activity, monitoring periods, practitioner review time, and direct patient interaction may all affect whether a service qualifies under the applicable code and payer rules.
That changes the standard for the software. A missed event is not merely an inconvenient product bug. It can create billing and audit exposure for the practice relying on the record.
PAVE therefore needed to answer three questions from the beginning:
- Can a physician quickly see which patients need attention?
- Can the platform preserve a reliable record of how billing status was reached?
- Can AI assist clinical work without bypassing the clinician responsible for it?
What PAVE needed to make work
We designed PAVE as two connected products.
The provider portal gives physicians a prioritized work queue and a five-tier billing-status classification. Instead of opening one patient record after another, a physician can view the compliance position of the patient panel from one screen and focus attention where it is needed.
The patient app was designed for adults aged 60 to 85. That shaped practical decisions throughout the experience. Magic-link access replaces another password to remember. The daily check-in is designed to take less than two minutes. The interface reduces choices and keeps the next action clear.
PAVE also includes Dr. Brain, an AI-assisted planning engine built using Claude. When a patient is enrolled, it prepares a personalized rehabilitation plan and a rationale document that references the clinical evidence used to support the recommendation.
Two decisions carried most of the risk
Many features made the platform useful. Two architectural decisions made it defensible.
1. Physician approval cannot be skipped
An AI-generated plan never goes directly to the patient. The treating physician must first review and approve it, and the product has no alternate path around that step.
This is more than a workflow policy or a checkbox. It is a system constraint. Even when a clinical team is busy, the software cannot silently turn an AI suggestion into a patient instruction.
That distinction matters whenever software handles protected health information and contributes to patient-specific clinical decisions. AI can prepare and organize. The accountable clinician remains in control.
2. Billing status cannot be manually manufactured
PAVE calculates billing status from patient activity recorded by the platform. Events are server-timestamped and preserved as part of the system record. A physician cannot manually move a patient into a billable state.
This protects the practice from a subtle but serious risk: turning a judgment call, data-entry mistake, or rushed action into unsupported billing evidence.
The benefit is simple to explain. The platform does not merely display whether a patient appears billable. It preserves the activity trail used to reach that status.
What we can measure before launch
PAVE has not yet launched to real patients, so there are no responsible adoption or clinical-outcome claims to make. Pre-launch evidence should be reported for what it is: evidence that the product is being prepared carefully, not proof that it has succeeded in the market.
Across the first two build milestones, the team created 403 structured test cases:
- 150 for the platform foundation and authentication layer
- 253 for the billing engine and core provider portal
Testing is concentrated on the areas where failure would matter most, including access controls, tenant isolation, privacy safeguards, and RTM qualification logic.
The foundational architecture, authentication layer, and design system are complete. Both the provider and patient experiences are live in staging as part of a 16-week, six-milestone delivery plan.
The project team also reviewed the agreements and data-handling obligations for every vendor expected to touch protected health information during the foundational build. That work belongs at the beginning of a healthcare product, not at the end of a launch checklist.
The real deliverable is confidence
PAVE is not a growth story yet. It is a product-engineering story about preparing for the scrutiny that growth will bring.
For healthtech founders, that is the useful lesson. When reimbursement rules create a market opportunity, speed still matters. But the fastest path is not the one with the fewest controls. It is the one that identifies the decisions carrying the most clinical and billing risk, then makes the safe action the default behaviour of the product.
For PAVE, that meant two non-negotiables: no AI-generated plan reaches a patient without physician approval, and no billing status can be created without the underlying patient activity.
The next Case Note should be written when physicians and patients are on the other side of these pre-launch numbers. Until then, the honest result is this: a working platform in staging, a defined evidence trail, and an architecture designed to help physicians trust what the software tells them.
Building a healthcare product that clinicians can trust?
We help healthtech teams turn complex clinical, compliance and billing requirements into secure, practical software, with responsible AI and human oversight built into the product from the start.
[Talk to Our Healthtech Product Team →]
Frequently asked questions
What is Remote Therapeutic Monitoring (RTM), and why did it create a product opportunity?
RTM is a Medicare reimbursement pathway that lets eligible practitioners monitor how patients respond to prescribed therapy outside the clinic. When RTM reimbursement expanded in 2026, it opened the door for healthtech teams to build monitoring tools, but only if the software could also support the clinical oversight and billing evidence the reimbursement rules require.
Why can't billing status in PAVE be set manually?
Because a manually set status could turn a judgment call, data-entry mistake, or rushed action into unsupported billing evidence. PAVE calculates billing status only from server-timestamped patient activity recorded by the platform, preserving the underlying activity trail rather than just displaying a status.
How does PAVE keep a physician in control of AI-generated treatment plans?
An AI-generated rehabilitation plan from Dr. Brain, PAVE's planning engine built on Claude, never reaches a patient directly. The treating physician must review and approve it first, and the product has no alternate path that bypasses that step.
Who is the patient app designed for, and how does that shape its design?
The patient app is designed for adults aged 60 to 85 completing rehabilitation exercises at home. That shaped decisions like magic-link access instead of a password, a daily check-in designed to take under two minutes, and an interface that reduces choices and keeps the next action clear.
Has PAVE launched to real patients yet?
Not yet. Both the provider and patient experiences are currently live in staging as part of a 16-week, six-milestone delivery plan, so the evidence available so far reflects careful preparation rather than market or clinical outcomes.
What kind of testing has gone into PAVE before launch?
Across the first two build milestones, the team created 403 structured test cases: 150 for the platform foundation and authentication layer, and 253 for the billing engine and core provider portal, concentrated on access controls, tenant isolation, privacy safeguards, and RTM qualification logic.
About the author:
Ahana Roy
Content Marketing Manager
A writer at heart and a marketer by choice, Ahana heads content and social media at SDTC Digital, bringing an instinct for language and a sharp eye for what moves people. Working across the blog and social channels every day, she sees firsthand which stories earn attention and which get lost in the feed.
.png)
.png)
.png)
