DTR (Documentation Templates and Rules)

One-sentence definition: DTR (Documentation Templates and Rules) is a Da Vinci FHIR Implementation Guide that provides the mechanism for collecting prior authorization documentation at the point of care, using payer-published FHIR Questionnaires that are automatically pre-populated with clinical data from the provider’s EHR system so that clinicians complete only what the record does not already contain.

Full Definition

Prior authorization documentation is one of the most time-consuming parts of the PA process. Staff manually transfer information — diagnoses, lab results, treatment history — from the patient chart into payer-specific forms. The data already exists in the EHR; the burden is the re-entry. DTR eliminates most of that re-entry by automating the data retrieval.

DTR is the second component in the three-IG Da Vinci prior authorization stack, published by HL7. It defines how payers publish structured documentation requirements as FHIR Questionnaire resources, and how provider systems use those Questionnaires to collect clinical information within the EHR workflow. The payer’s Questionnaire includes CQL (Clinical Quality Language) expressions that specify exactly how to retrieve each answer from the provider’s FHIR server — a question about a patient’s most recent HbA1c, for example, maps to a specific FHIR query. The DTR client executes those queries against the EHR, pre-populates the form, and presents only the unanswered items to the clinician.

The term “DTR” refers both to the IG specification and, informally, to the documentation collection step or the application that performs it. A “DTR app” or “DTR workflow” describes the form-rendering process that sits between CRD’s identification of a PA requirement and PAS’s submission of the PA request. When a payer has “implemented DTR,” it has published Questionnaires with CQL pre-population expressions and either provides a SMART on FHIR app to render them or supports native EHR rendering.

The output of DTR is a completed QuestionnaireResponse — a FHIR resource capturing the structured answers. That QuestionnaireResponse travels as supporting documentation attached to the PAS Claim submission in the final step.

For how DTR works technically — Questionnaire structure, CQL pre-population, SMART vs native deployment, and the QuestionnaireResponse handoff to PAS — see Prior Authorization Workflow.

Context and Usage

Where This Term Appears

• Da Vinci IG documentation and HL7 project materials
• EHR vendor product documentation for prior authorization workflows
• Payer developer portals listing Questionnaire endpoints
• Clinical informatics discussions about reducing PA documentation burden
• CMS-0057-F implementation planning (DTR is best practice but not individually mandated)

Common Usage Examples

In conversation: “We launched the DTR app for the rheumatology PA — it pulled the diagnosis, joint count, and prior biologics history automatically. The doc only had to answer two questions.”

In technical contexts: “The payer’s DTR Questionnaire uses CQL to query for the most recent ESR result. If nothing is found, the field stays blank for manual entry.”

In documentation: “After CRD returns a PA-required card, the EHR should surface the DTR launch button so the clinician can initiate documentation collection before the order is signed.”

Relationship to Other Terms

DTR is the middle component of the three-IG Da Vinci PA stack:

• CRD — Coverage Requirements Discovery; the upstream step that identifies a PA requirement and signals that DTR should be launched; CRD tells the EHR which Questionnaire to load
• PAS — Prior Authorization Support; the downstream submission step; the QuestionnaireResponse produced by DTR is attached to the PAS Claim as supporting documentation
• Questionnaire / QuestionnaireResponse — the FHIR resources at the core of DTR; the Questionnaire is the payer’s form definition, the QuestionnaireResponse is the completed form
• SMART on FHIR — one of two deployment models for DTR; a SMART app launched within the EHR renders the payer’s Questionnaire
• CQL (Clinical Quality Language) — the expression language used in DTR Questionnaires to specify EHR data retrieval for pre-population

Common Misconceptions

“DTR is mandated by CMS-0057-F.” CMS-0057-F mandates the PA submission and decision workflow (PAS). DTR is part of the Da Vinci best-practice stack and strongly recommended, but not individually required by the rule.

“DTR replaces the need for clinical documentation.” DTR collects existing documentation; it does not generate clinical content. If the EHR does not contain the data the Questionnaire requires, the clinician must still provide it manually. DTR eliminates re-entry of data that already exists — it cannot substitute for documentation that hasn’t been created.

“DTR only works as a SMART app.” The IG supports two deployment models: a SMART on FHIR app launched in the EHR’s embedded browser, and native rendering where the EHR renders the Questionnaire directly using SDC (Structured Data Capture) specifications. Both are valid DTR implementations.

---

Last reviewed: February 16, 2026 Definition authority: HL7 International Content status: Canonical reference