Da Vinci PA adoption inside provider organizations depends on workflow fit. Technical conformance with CMS-0057-F is necessary but not sufficient; provider organizations that find the workflow awkward fall back to legacy PA channels (phone, fax, web portal) regardless of how technically capable the FHIR ePA stack is. Five anti-patterns consistently break adoption in 2026 deployments. For more on TEFCA and CMS interop coverage, these are the failure modes worth knowing.
1. Forcing Standalone SMART Launch When EHR Launch Is Available
The most common anti-pattern. The payer's DTR SMART app is built to launch standalone (from a payer portal link), even when the target EHR supports SMART EHR Launch cleanly. The clinician has to switch context to a separate window, authenticate, find the patient, and complete the form outside the clinical workflow.
Provider adoption of standalone DTR is consistently low. Clinicians who can submit through legacy channels in two minutes prefer those over a standalone DTR that takes five minutes plus context switching. The fix is to support EHR Launch wherever the target EHR allows.
2. Requiring Manual Data Entry for Fields Available in EHR Context
A pattern where the DTR app launches inside the EHR but does not pre-populate available fields. The clinician sees a blank questionnaire and manually re-enters patient demographics, current medications, recent diagnoses, and other data the EHR already has.
This anti-pattern wastes clinician time and undermines the entire premise of EHR-embedded PA. The fix is to wire up FHIR pre-population from the EHR context (Patient, Encounter, MedicationStatement, Condition) so the clinician sees a partially-completed form.
3. Showing All Questions Regardless of Relevance
A pattern where the DTR app displays the full questionnaire (which can be 30 or more questions) without using CQL conditional logic to hide irrelevant questions. The clinician scrolls through dozens of inapplicable questions to find the few that actually apply to the case.
This anti-pattern is especially bad on mobile-EHR clients where scrolling is more friction. The fix is to author CQL rules that drive conditional question rendering based on prior answers, the patient's current state, and the specific PA case.
4. Synchronous-Only Submission With No Save State
A pattern where the DTR app requires the clinician to complete the questionnaire in one session, with no save-and-resume capability. PA forms sometimes need supporting data (a pending lab result, an imaging review not yet completed) that the clinician cannot answer at the moment.
When the form has no save state, the clinician either has to abandon the workflow and restart later (losing all progress) or wait until everything is available and complete in one sitting (which disrupts the clinical flow). The fix is to support partial save, hand-off between clinical staff, and resume across sessions.
5. Burying the PA Decision in a Notification That Does Not Surface in Clinical Workflow
A pattern where the PA decision comes back from the payer (after the UM team reviews it) but the notification is sent to a payer-controlled portal or an email address rather than into the provider's EHR workflow. The clinician does not learn the decision until the next encounter with the patient or until staff manually check the portal.
The CMS-0057-F intent is that PA decisions integrate with the provider workflow. The fix is to use FHIR Subscriptions to notify the EHR of decision changes, with the EHR rendering the notification in a place the clinician naturally encounters (the patient chart, the order status, a task list).
How These Anti-Patterns Compound
The anti-patterns are not independent. A DTR app that uses standalone launch (Anti-Pattern 1) typically also lacks EHR context for pre-population (Anti-Pattern 2). A form without conditional logic (Anti-Pattern 3) combined with no save state (Anti-Pattern 4) produces a workflow that almost no clinician completes. Production deployments need to address the anti-patterns together rather than fixing one at a time.
For positive patterns to use instead, the Best DTR SMART app patterns for provider workflows covers the production-grade designs. For the architectural choice between standalone and EHR launch specifically, the Standalone SMART vs EHR Launch for Da Vinci DTR workflows comparison covers the trade-off.