SMART App Launch defines two launch patterns. Standalone Launch starts the app outside any EHR context, typically from a web link. The user authenticates, picks a patient, and the app runs. EHR Launch starts the app from within the EHR, with the EHR providing Patient, Encounter, and other context. For Da Vinci DTR workflows, both patterns are technically conformant. The choice has substantial consequences for clinician adoption and the experience of completing a PA inside the provider workflow. This comparison lays out the trade-offs for the inter-payer transfer reference on this site.
What Each Launch Pattern Actually Does
Standalone Launch is essentially a web-app pattern. The user navigates to the DTR app URL (often from a CRD card with a launch link, or directly from a bookmark). The app prompts for authentication, the user logs in with payer-issued credentials, the app prompts the user to identify the patient, and the user then completes the questionnaire. The app runs in its own browser tab or window separate from the EHR.
EHR Launch starts the app inside the EHR. The EHR provides authentication tokens via SMART OAuth, passes Patient and Encounter context, and embeds the app in an EHR-controlled view. The clinician sees the DTR form without leaving the patient chart and the app already knows which patient is being treated.
Where EHR Launch Wins
EHR Launch wins on clinician experience. The clinician does not authenticate separately, does not pick the patient (the EHR already knows), does not switch context to a separate window, and sees the DTR form as part of the clinical workflow. Pre-population from EHR context works because the context is already provided.
EHR Launch also wins on adoption. Workflow integration that respects the clinician's existing pattern gets used. Workflow integration that requires context-switching gets bypassed in favor of legacy submission channels (phone, fax) regardless of how technically capable the DTR app is.
Where Standalone Launch Wins
Standalone Launch wins in narrow circumstances. Care management staff who handle PAs outside the clinician's direct workflow can use a standalone DTR app. Specialty providers whose EHR does not support SMART EHR Launch (or supports it poorly) can use standalone as a fallback. Initial pilot rollouts before the EHR-specific work is complete can use standalone for testing.
Standalone Launch is also the only path when the workflow originator is not in an EHR. For example, an automated batch submission tool processing accumulated PA requests overnight does not have an EHR launch context; it operates standalone.
The Adoption Gap That Matters Operationally
The data from production DTR deployments in 2025 and early 2026 shows a wide adoption gap. EHR-launched DTR apps see provider completion rates of 60 to 85 percent (depending on workflow design and EHR-specific quirks). Standalone-launched DTR apps see completion rates of 20 to 40 percent for clinician-facing cases, with the rest falling back to legacy submission.
The gap is not about technical quality. It is about whether the workflow asks the clinician to do additional work (find the standalone link, authenticate, pick the patient) or fits into work the clinician is already doing.
When Standalone is Actually the Right Choice
For care-management workflows (not clinician-facing), standalone is sometimes the right pattern. The care management team is processing PAs as their primary work; the standalone DTR app is the right tool for that work. They do not need EHR launch context because they are not embedded in EHR workflow.
For batch-style PA processing where multiple submissions are completed in sequence outside any single clinical encounter, standalone fits the work pattern better than EHR Launch (which would require launching from a specific patient context for each PA).
The Hybrid Pattern That Works Best in Production
Most production DTR deployments support both launch patterns. EHR Launch handles the clinician-facing case where it is supported by the target EHR. Standalone Launch handles care-management workflow, EHR-without-SMART-support fallback, and edge cases. The DTR app code is mostly shared; the difference is in the launch sequence.
For the broader catalog of DTR SMART app design patterns that work well in production, the Best DTR SMART app patterns for provider workflows covers the field-tested designs. For the broader workflow anti-patterns to avoid, the 5 EHR workflow anti-patterns that break Da Vinci PA adoption covers the failure modes.