How DTR fixes the documentation bottleneck in prior authorization

When prior authorization stalls, documentation is often to blame. Even if coverage rules are clear, requests bounce back because paperwork is incomplete, the wrong form is used, or supporting evidence is missing. This back-and-forth frustrates providers, delays care, and drives up administrative costs for payers. 

That’s where Documentation Templates and Rules (DTR) comes in. Developed under the HL7 Da Vinci project, DTR is a FHIR Implementation Guide that guides providers through the exact information required for a PA request right inside their EHR workflow. 

It’s the second piece of the electronic prior authorization (ePA) loop, sitting between Coverage Requirements Discovery (CRD) and Prior Authorization Support (PAS). Together, these three capabilities create an end-to-end process that replaces fax, phone, and portals with real-time digital workflows. 

Why DTR is essential

Coverage Requirements Discovery (CRD) can tell providers whether prior authorization is required and flag that supporting documentation will be needed. But it doesn’t specify how. 

DTR takes it a step further by translating those requirements into structured, payer-specific templates which are often prepopulated with existing EHR data. It then prompts providers for anything missing. The result is a complete, standardized request that gets it “right the first time” and reduces rework, resubmissions, and delays. 

How DTR works

When a provider initiates an order, DTR automatically launches within the EHR (or another clinical system). Instead of guessing what to include, the provider is presented with a structured, payer template that guides them through exactly what’s required. 

DTR uses FHIR Questionnaires (essentially “smart forms”) with embedded logic to: 

• Prefill data already available in the provider’s EHR (e.g., demographics, lab values, prior diagnoses).
• Prompt for additional details that the payer requires, such as recent test results or clinical notes. 
• Validate completeness so all required fields are filled before the request is submitted. 

Responses can be captured either through a SMART on FHIR application or functionality embedded directly in the EHR, so providers don’t have to leave their workflow. 

For example: if a physician orders an MRI, DTR can instantly generate a smart form with payer requirements. This automatically pulls prior imaging results and diagnoses from the EHR, while only prompting the physician for missing details. The result is a request that moves smoothly to a decision without delays. 

What payers should prepare to deliver

For DTR to work, payers must configure their systems to share documentation requirements in a structured, machine-readable way. 

That includes: 

• Documentation rules: Define clinical, administrative, and patient-level requirements.
• Structured templates: Share rules and forms as FHIR resources that SMART on FHIR apps can consume.
• Pre-population mapping: Allow provider systems to auto-fill as much data as possible (demographics, labs, encounter details, etc.).
• Consistency across CRD and PAS: Make sure what DTR requires matches what PAS will ultimately accept. 

By configuring rules in DTR, payers ensure requests arrive complete, cutting down on costly back-and-forth and improving trust with providers. 

Enabling DTR from the provider side   

The success of DTR depends on making it feel effortless within the provider’s workflow. That usually means running inside the EHR, either as a SMART on FHIR app or built-in functionality.  

To make that happen, providers (and their vendors) should ensure the system can: 

• Launch DTR directly from the EHR so providers don’t leave their workflow or juggle multiple logins.
• Prefetch and auto-populate existing data (like demographics, problems, labs, or meds) to prefill forms and minimize manual entry.
• Map local data to payer requirements so the provider’s existing data can flow into the payer’s templates.
• Present payer templates directly within the workflow and check that all required fields are captured before submission. 

Pre-populating fields not only saves clinicians time but also boosts adoption rates and ensures a smoother prior authorization process for providers and payers alike. 

Suggested DTR metrics to measure success 

The DTR Implementation Guide also includes a set of suggested metrics that organizations can use to evaluate how well their implementation is working. These aren’t required today, but they provide a useful overview on adoption and efficiency. 

Suggested metrics include:

• Launch mode: Percentage initiated via CRD, standalone in the EHR, or CDex launch.
• Questionnaire type: Percentage of standard questionnaires vs. adaptive forms.
• Auto-population: Percentage of fields prefilled from the EHR vs. manually entered.
• Review rates: Percentage reviewed prior to completion.
• Duration: Average time to complete.

Tracking these kinds of indicators helps both payers and providers identify friction points, improve workflows, and prepare for the possibility that future regulation may formalize metric reporting. 

The bottom line

Incomplete documentation is one of the biggest bottlenecks in prior authorization. DTR solves that problem by turning requirements into structured, guided workflows.

For payers, it means fewer denials, less manual review, and faster turnaround. For providers, it means less frustration and reduced administrative burden. And for patients, it means timely access to care. 

In short: If CRD provides clarity at the start, DTR ensures completeness at the critical middle step. For payers, getting DTR right means smoother workflows, lower costs, and stronger provider relationships. And of course, it ensures payers have the foundation to meet upcoming CMS-0057-F compliance deadlines.