For most digital therapeutics (DTx) companies, the phrase “DTx reimbursement: using RWE to satisfy CMS in 90 days” sounds like an unrealistic goal—especially when the evidence generation team is used to planning twelve-month studies before seeing a single coverage decision. But the reality in 2026 is that CMS no longer gives full weight to retrospective claims analyses alone, nor does it wait patiently for a manufacturer to design a costly prospective trial. The winners are the companies that treat real-world evidence (RWE) as a living data pipeline, not a one-time research project. This article lays out a pragmatic, day-by-day approach to collecting post-market data that positions your DTx product for faster coverage verdicts—without blowing your budget or burning out your clinical staff.
Why CMS Changed the RWE Game for Digital Therapeutics
CMS has gradually moved from asking “does it work?” to asking “does it work for our beneficiaries in our settings, at a cost we can justify?” That shift matters because traditional randomized controlled trials (RCTs) rarely answer the second question. For DTx, where the intervention is software, the user is the patient, and the treatment variable is engagement, RCT evidence feels less convincing to coverage reviewers than ever.
Recent CMS guidance around Medicare Advantage and the Transitional Coverage for Emerging Technologies pathway has pushed manufacturers to blend clinical trial data with real-world evidence from claims, electronic health records (EHRs), and patient-generated health data. The problem is that many DTx teams interpret this as “do more research.” The smarter response is to standardize the data you already collect—from onboarding surveys, in-app engagement logs, PHQ-9 or GAD-7 scores, and pharmacy/medical claims—into a clean, query-ready dataset before you ever approach CMS.
The 90-Day RWE Sprint: Build Around Existing Data, Not New Studies
A 90-day timeline doesn’t mean you can run an RCT. It means you can assemble an evidence package that CMS reviewers respect. The key is to stop thinking like a clinical trial sponsor and start thinking like a health informaticist. Your goal is to answer three coverage questions: (1) Is this DTx safely used in real-world populations? (2) Does it measurably improve outcomes compared to standard care or a chosen benchmark cohort? (3) Does it reduce total cost of care or offset downstream utilization?
Here is a pragmatic week-by-week playbook that has worked for DTx manufacturers submitting to CMS in the last two years.
Step 1: Align Outcomes with CMS’s Coverage Language
Before touching a single database, go through the CMS National Coverage Determination (NCD) Manual and relevant Local Coverage Determination (LCD) policies for your therapeutic area. Identify the exact outcome language CMS uses—readmission, medication adherence, depression remission, pain interference, or work productivity. Then map every outcome your product already collects to that language. If there is a gap, don’t design a new trial immediately. Instead, look for alternative data sources you can license or partner on, such as state all-payer claims databases or qualified clinical data registries.
Step 2: Use Claims and EHR Data From Day One
Your 90-day clock starts when you create an extract, transform, and load (ETL) process that pulls in de-identified claims and EHR data for a defined cohort of patients who have used your DTx product. That means working with a health data partner or using CMS’s Virtual Research Data Center (VRDC). The goal is to build a secure, HIPAA-compliant dataset that links each patient’s app activation date to their medical and pharmacy claims, lab results, and visit history. You want to show seamless engagement with Medicare fee-for-service and Medicare Advantage beneficiaries, not just a non-representative commercial sample.
Step 3: Create a Control Arm From Analytics, Not Randomization
In 90 days, you won’t have time to randomize. But CMS will accept well-constructed comparator cohorts if you can demonstrate robust propensity score matching. Use patients who meet the same clinical criteria for your DTx but either used a different digital app, received usual care, or had a delayed start. Document your matching variables transparently: age, sex, comorbidities, socioeconomic score, baseline severity, and prior utilization. This is not a subversion of science; it is the practical definition of real-world evidence. CMS wants to see that your product’s effect is not due to self-selection bias, and matching can often get you 80% of the way there.
Avoiding the “RWE Dump” Trap: How to Package Data for CMS Reviewers
Too many DTx submissions fail because the manufacturer sends CMS a 300-page RWE appendix with unmatched cohorts and confusing endpoint definitions. CMS reviewers are not reading your study to learn; they are scanning for three things: completeness, transparency, and relevance. Package your RWE in a structured format that mirrors the way CMS evaluates evidence:
- A one-page executive summary with your primary outcome and effect size.
- A clearly labeled table that maps each CMS coverage criterion to the data source and endpoint used.
- A sensitivity analysis showing the result changes only slightly when you exclude patients with less than two weeks of app engagement.
- A description of any missing data and how you handled it—CMS is more forgiving of missing data than of hidden data.
Use standardized vocabularies like SNOMED-CT for diagnoses, RxNorm for medications, and LOINC for lab tests. Add FHIR-formatted endpoints if your EHR partner can supply them. CMS’s data teams increasingly expect interoperability standards, and showing that your RWE pipeline is FHIR-native signals that you are ready for post-market surveillance under the HTI-2 final rule.
Three RWE Mistakes That Derail DTx Reimbursement Timelines
Even with a tight 90-day sprint, certain mistakes can force a reset. Watch for these common pitfalls.
First, measuring engagement instead of outcomes. CMS does not care if users opened the app thirty times. They care if depression scores dropped, A1c levels improved, or hospitalizations fell. Engagement is a proxy variable, not the outcome. If your RWE package leans heavily on “sessions completed,” you will get a coverage denial.
Second, comparing your DTx to a perfect, non-existent standard. If your control arm is a cohort of patients with zero digital health use, you are creating an unrealistic counterfactual. The right comparator is usual care—what actually happens in the Medicare population, including generic wellness apps, in-person therapy, and medication changes.
Third, ignoring the coding and payment angle. RWE does not exist in a vacuum. The reason CMS asks for post-market evidence is often to assign a HCPCS Level II code, set a payment rate, or refine a benefit category. If your DTx is being evaluated under a temporary code, your RWE must include cost data—total allowed amounts, utilization rates, and any offset reductions in other services. That requires early coordination with your billing and market access teams, not a late-stage data handoff.
Measuring What Matters: The DTx-Specific RWE Metrics That Win CMS Over
Generic RWE frameworks for drugs and devices don’t fully capture the behavior-based nature of a digital therapeutic. To accelerate coverage decisions, include metrics that show how your software actually changes patient behavior in ways that drive hard outcomes.
One high-value metric is the “digital responder rate”—the proportion of patients who meet a clinically meaningful within-patient improvement threshold after a defined number of days in the program. Another is the “time-to-first clinical event” reduction for chronic disease DTx, such as days-to-hypertensive-crisis or days-to-depression-relapse. A third is the “care shift” metric: the percentage of patients who transition from emergency department visits to primary care visits after using your product. CMS loves seeing evidence that a digital intervention nudges patients toward more appropriate, lower-cost care settings.
Also consider analyzing race, ethnicity, and rural status in your subgroup analyses. CMS has explicitly stated that it expects evidence to show whether a technology reduces health disparities. A 90-day RWE package that includes a well-powered subgroup analysis for dual-eligible beneficiaries will stand out from competitors who only show average effects.
What a 90-Day RWE Timeline Looks Like in Practice
Let’s be concrete. On days 1–15, you sign data use agreements, map endpoints to CMS language, and extract a de-identified claims/EHR dataset. On days 16–40, you build propensity-matched cohorts and run baseline balance checks. On days 41–60, you run outcome analyses, including sensitivity tests and subgroup stratifications. On days 61–75, you prepare the evidence submission, create visualizations, and format the appendices. On days 76–90, you submit pre-payment to CMS’s technical contractor and hold a technical call to walk through your methods. That is an intense schedule, but it is feasible when you have engaged an informatics partner early and you are not trying to shoehorn a full RCT into a 90-day window.
The DTx companies that get reimbursement in 2026 will not be the ones with the highest clinical trial budgets. They will be the ones that treat RWE as a continuous signal from the field—and know how to package that signal into a concise, compelling narrative for CMS. Start your 90-day clock today, and make your evidence pipeline the strategic advantage it was always meant to be.
