The Documentation Templates and Rules (DTR) component of Da Vinci ePA renders the payer-specific questionnaire inside the provider EHR as a SMART app. The provider does not leave their workflow; the DTR app launches in context, runs the CQL rules to determine which questions actually need answers, collects documentation, and returns a completed Bundle ready for PAS submission. Five patterns have emerged as the production-grade approaches in 2026. For the CMS-0057-F provider toolkit on this site, these are the field-tested designs.
1. EHR-Launch With Pre-Population From Context
The most effective production pattern. The DTR app launches via SMART EHR Launch, receives Patient and Encounter context, and pre-populates the questionnaire from EHR data. The clinician sees a partly-completed form rather than a blank slate, and only completes the fields the CQL rules cannot derive automatically.
Pre-population reduces clinician time substantially. A typical PA form that would take 10 to 15 minutes to fill manually completes in 2 to 3 minutes when pre-population catches 60 to 80 percent of the data from EHR resources.
2. CQL-Driven Conditional Question Rendering
A pattern where the DTR app does not render all questions at once but instead uses CQL rules to determine which questions apply given the current answers. A "patient takes medication X" answer triggers a follow-up question; a "patient does not take medication X" answer skips the follow-up.
This pattern reduces the visible form to what actually matters for the specific PA case. The implementation complexity is in the CQL authoring; payer clinical teams need to author the conditional logic, often with FHIR-specific tooling.
3. Staged Save With Resume
A pattern where the DTR app saves partial progress and lets the clinician resume later. PA forms sometimes need data the clinician cannot answer in the moment (lab result pending, imaging review needed). The staged-save pattern lets the clinician complete what they can, hand off the rest to clinical staff, and resume later without re-entering data.
The implementation requires the DTR app to maintain state across sessions and the EHR to support relaunch with the saved context. Both are achievable but require deliberate design.
4. Inline Attachment Capture From EHR
A pattern where the DTR app needs supporting documentation (imaging report, lab values, clinical note) and can pull it directly from the EHR via the FHIR API rather than requiring the clinician to manually attach files. The clinician approves the attachment but does not have to find and upload it.
This pattern works well for PA cases where the documentation requirements are predictable. The implementation depends on the EHR exposing the supporting resources through the FHIR API; not all EHR configurations support this cleanly.
5. Two-Way Validation Before Submission
A pattern where the DTR app validates the completed Bundle against the payer's rule set before submitting to PAS. The clinician sees inline indication that the submission will pass clinical-necessity criteria before they actually submit. If the rules indicate a likely denial, the clinician can adjust documentation or escalate before formal submission.
This pattern significantly improves first-pass approval rates and reduces denial-then-appeal cycles. The trade-off is that the validation logic has to run client-side in the SMART app, which adds complexity.
How Production Teams Combine These Patterns
The teams that ship production DTR SMART apps in 2026 typically combine all five patterns. EHR Launch with pre-population is the foundation. CQL-driven conditional rendering keeps the form concise. Staged save handles real-world workflow interruptions. Inline attachment capture reduces clinician burden. Two-way validation improves approval rates.
The patterns build on each other. Implementations that skip the foundational pre-population produce DTR apps that fail clinical adoption regardless of the other features.
What to Avoid
The most common anti-patterns in DTR SMART app design are: standalone launch when EHR launch is possible (forces the clinician to leave their workflow), blank forms when pre-population is possible (wastes clinician time), all-questions-at-once when CQL conditional rendering is possible (overwhelms the clinician), and synchronous-only operation when staged save is needed (loses partial progress).
For the broader question of Standalone SMART versus EHR Launch as the architectural choice, the Standalone SMART vs EHR Launch for Da Vinci DTR comparison covers the trade-offs. For the broader catalog of EHR workflow patterns that derail Da Vinci PA adoption, the 5 EHR workflow anti-patterns that break Da Vinci PA adoption covers the failure modes.