Da Vinci DTR Explained: Questionnaires, CQL and Prior Authorization

In brief: Documentation Templates and Rules is the Da Vinci guide that delivers a payer's questionnaire together with CQL logic that pre-fills it from the patient's chart. The payer publishes packages through $questionnaire-package; the client (the EHR, a SMART app or a payer-hosted service) runs the logic, marks which answers came from the chart, and leaves the rest to the clinician. The hard part is not the API but turning medical policies into structured criteria, questionnaires and tested rules.

Documentation Templates and Rules is the guide that makes the prior-authorization form disappear. Once CRD has told the EHR that an order needs documentation, DTR fetches the payer's questionnaire together with the logic to fill it, runs that logic against the patient's chart, and shows the clinician only what remains unanswered. When the work is done properly, a clinician sees a form that is already mostly complete.

It is also the guide that exposes the state of a payer's medical policies. Policies that live in PDFs need structured extraction, clinical review, versioning and validation before they become reliable executable questionnaires and Clinical Quality Language rules. For most plans that work has not been done, which is why WEDI's readiness surveys put policy content among the hardest parts of CMS-0057-F, and why DTR is the piece many delegated-review vendors are furthest behind on.

Our earlier post, Da Vinci DTR: questionnaires, CQL rules and the part everyone under-scopes, covers the scoping view; this one goes deeper on the mechanics. It follows the same structure as the CRD one: the flow, the operations, the pipeline that produces content, the two questionnaire types, the population rules, the three ways a client can run, and how to test. Requirement identifiers such as §spec-6 are the DTR guide's own (version 2.2.0 is current; CMS names 2.1.0 for 2027).

The flow in one picture

1. CRD returned a coverage-information extension saying documentation is needed, with a coverage-assertion id and, optionally, a link to launch DTR.
2. The DTR client, which may be the EHR itself or a SMART app it launches, calls the payer's $questionnaire-package operation with the coverage and the order. The response is a Bundle containing one or more Questionnaires, their CQL libraries, and any value sets the logic depends on.
3. The client runs the CQL against the EHR's FHIR data (via the SMART token) and pre-populates the QuestionnaireResponse.
4. The clinician reviews, completes what could not be populated, and attests.
5. The QuestionnaireResponse is stored in the EHR and attached to the order. If a prior authorization is required, PAS carries it to the payer; if the payer only needs it with the claim, it travels as an attachment.

The guide fixes a single door on the payer side: "Payers SHALL support a single endpoint for all DTR-related operations" (§spec-6). A plan with five delegated vendors still exposes one endpoint and routes internally, the same rule that applies to CRD.

The operations

DTR defines four operations on the payer server.

• $questionnaire-package is the one everyone must support. Input: the Coverage, the order, an optional context Parameters resource. Output: a Bundle of Questionnaire(s), Library(ies) and ValueSet(s). The payer "SHALL" return everything needed to render and populate the form without further calls.
• $next-question drives adaptive questionnaires: the client posts the answers so far, the payer returns the next item or signals completion.
• $log-questionnaire-errors lets the client report a questionnaire that could not be rendered or whose CQL failed, so the payer can fix content. Servers SHALL support it; it is how content quality improves in production.
• $expand on ValueSet is needed when the package references value sets by canonical URL rather than embedding them.

The response Bundle carries a Questionnaire whose items reference CQL expressions through the SDC (Structured Data Capture) extensions: cqf-library on the Questionnaire and initialExpression or candidateExpression on items. The Library resource holds the CQL text and, ideally, the compiled ELM so the client does not need a CQL translator at runtime.

The pipeline that produces content

This is the part Sidharth Ramesh's Medblocks walkthrough covers well and most vendor decks skip. A DTR package is a build artifact. Something has to produce it.

• Policy catalog. Medical policies, criteria and required documentation per procedure code, line of business and product. This is the same catalog CRD's requirement matrix is compiled from. If the utilization-management team keeps policies as PDFs, the first project is turning them into structured criteria with a code, a version, an effective date and an owner.
• Questionnaire authoring. Each criterion becomes an item with a linkId, a type, answer options and the SDC extensions that say how it can be pre-populated. Many teams start in a form builder (the HL7 Foundry bundle ships one) and version the output in git.
• CQL authoring. For each item that can be answered from the chart, a CQL expression: "most recent HbA1c in the last 90 days", "any MRI of the lumbar spine in the last 12 months", "documented failure of two conservative therapies". The guide fixes the language version: "SHALL use CQL 1.5" (§spec-92). Value sets come from VSAC, which needs a license key.
• Compilation and testing. CQL is translated to ELM and run against synthetic patients in a test FHIR server to prove it returns what the author meant. The Inferno DTR kit and the Foundry bundle's DTR reference app both consume the output.
• Publication. Versioned packages behind $questionnaire-package, keyed by the same code and product that CRD used to say documentation is needed. When a policy changes, the package changes, and the old version stays available for in-flight requests.

The reason this matters commercially: the pipeline is the durable asset. CRD and PAS endpoints are engineering; the policy catalog and its questionnaires are what the plan will keep maintaining for years, and CMS-0062-P's proposal to bring drug prior authorization onto the same rails from October 2027 would add a second body of content whose size depends on the plan's formulary policies.

Standard versus adaptive questionnaires

A standard questionnaire is delivered whole. The client renders every item, runs the CQL, and the clinician completes the rest. It is simple, works offline once fetched, and is what most payers ship first.

An adaptive questionnaire is delivered one question at a time through $next-question. The payer decides the next item from the answers so far, which lets it stop as soon as a decision is reachable and keeps its full decision tree private. It costs a round trip per question and needs the client to hold state.

The guide does not let clients pick one: DTR clients "SHALL support both standard and adaptive questionnaires" (§spec-16). Payers may use either. In practice adaptive forms are rare today; they matter where the plan's rules are proprietary or where a short path to "approved" exists for most patients.

Population rules: what "pre-filled" is allowed to mean

A pre-populated form is only useful if the clinician can trust it. The guide's population rules are precise about what the client must do and must show.

• The client "SHALL" execute the CQL and populate answers where the expression returns a value (§spec-54), and "SHALL" mark answers that were populated automatically so they are distinguishable from manual entries (§spec-55). The origin.source extension records whether an answer came from the chart, from the user, or from a previous response.
• Where the CQL returns nothing, the item is left for the clinician; the client "SHALL NOT" invent a value.
• The clinician "SHALL" be able to edit any pre-populated answer (§spec-62), and the edit is recorded as manual.
• Where an answer came from a specific resource, the client "SHOULD" keep the reference so the payer can see provenance (§spec-66).
• The client "SHALL" persist the QuestionnaireResponse in the EHR, in-progress or completed, so work is not lost between sessions (§spec-78), and "SHALL" attach the completed response to the order (§spec-87).
• Timing matters here too: the guide expects the package fetch and initial population in about five seconds, and one second for $next-question at the ninetieth percentile (§spec-38).

Two rules apply to the payer side of the same exchange. A payer "SHALL NOT" require a preferential DTR app, meaning it cannot insist a provider use its own app rather than the EHR's built-in client (§spec-1). And the payer "SHALL" accept a QuestionnaireResponse populated by any conformant client (§spec-41, §spec-42, §spec-45), which is the interoperability guarantee.

Chart evidence and clinician-entered answers need distinguishable origins. Missing evidence remains unresolved until reviewed; a dated order alone does not prove completed treatment.

Three shapes a DTR client can take

The client side of DTR is where EHR strategy decides what a payer will see.

1. Native in the EHR. The EHR renders the Questionnaire, runs the CQL with its own engine, and stores the response. Epic's February 2026 release and Oracle Health's roadmap both go this way. The payer's job is to publish good packages; the payer has no app to build.
2. A SMART app launched from the CRD card. The EHR passes a launch token; the app fetches the package, populates it from the EHR's FHIR API, and writes the response back. This is the HL7 Foundry reference DTR app and what many provider-side vendors build. The payer may host it, but under §spec-1 cannot require it.
3. A payer-hosted DTR running under the plan's own FHIR facade. The plan's DTR service receives the order and coverage, runs the CQL against data the plan already holds plus what it fetches through the EHR with the launch token, and returns a mostly complete response. This is the pattern we build for plans with delegated vendors: one questionnaire endpoint, one CQL engine, vendors supply content in a shared format.

Whichever shape the provider chooses, the payer must produce packages that work in all three. That means CQL that only depends on US Core profiles the EHR actually serves, value sets that expand, and questionnaires that render in a generic SDC renderer.

How to test DTR before you meet a real EHR

1. The HL7 Foundry Burden Reduction bundle. Runs the payer reference server with sample questionnaires, the reference DTR app, and the CDS-Library of CQL. It needs a VSAC key. Change a sample questionnaire, watch it populate against the test EHR's patients.
2. The Inferno DTR test kit. Its server suites (2.0.1 and 2.2.0 at the time of writing) exercise $questionnaire-package, $next-question and error logging for the requirements the kit documents. Self-host with the same setup.sh and run.sh pattern as the CRD kit.
3. The Acentra Health sandbox. Exposes $questionnaire-package only, at present, on synthetic data, so use it to prove your package fetch and population flow, not the adaptive path.
4. Epic on FHIR "CMS Prior Auth" template apps. At the time of writing the DTR-side template listed the scopes a SMART DTR client needs in Epic's sandbox: Questionnaire and QuestionnaireResponse read, search and create, the clinical resources the CQL reads, and launch context. A registered client is the prerequisite; a runnable native DTR launch still depends on sandbox configuration and, for production, Epic's review.
5. A CQL test harness. Run each library against a synthetic cohort and assert the expected answers. This is the test the kits do not give you, and it is the one that catches "the expression compiled but returns null on every real patient" before a clinician does.

A worked example (synthetic): the lumbar MRI questionnaire

Take the imaging questionnaire from the CRD example. This is a synthetic case with an invented policy. The policy for lumbar MRI without red-flag symptoms requires six weeks of conservative therapy, documented neurological findings or a red flag, and no lumbar MRI in the last twelve months. The package contains one Questionnaire with nine items and one Library with three CQL definitions.

• ConservativeTherapyDocumented looks for documented conservative treatment: Procedures or MedicationRequests in physical-therapy or NSAID value sets, together with their start and end dates or a documented outcome. For this synthetic patient it finds a physiotherapy referral dated in June but no completion record or outcome note. The expression returns the referral as evidence, and the item is flagged "needs clinician confirmation" rather than answered: a dated referral does not prove that six weeks of therapy happened or failed, and the absence of a record is not evidence that treatment did not occur.
• RecentLumbarMRI looks for any ImagingStudy or Procedure coded lumbar MRI in the last 365 days. It finds none in this record, so the item is populated as "none found in this chart" with the query recorded as its source, and the clinician can correct it if imaging happened elsewhere.
• NeurologicFindings looks for any Condition or Observation in the radiculopathy value set in the last ninety days, and returns the radiculopathy diagnosis recorded that day, which populates the item with its source resource referenced.

Five of the nine items pre-populate with chart provenance, one is flagged for confirmation, and three are left for the clinician: pain severity on a scale, whether red-flag symptoms are present, and a free-text clinical summary. The clinician confirms the therapy duration, answers the rest and attests; the response is attached to the order, and PAS carries it. Whether the payer approves depends on its adjudication rules and, where needed, a reviewer. Using the same policy identifier in CRD, DTR and adjudication lets a plan auto-adjudicate where its rules permit, but nothing in DTR guarantees approval.

The same package, unchanged, has to work when Epic renders it natively, when the reference SMART app renders it, and when the plan's own DTR service populates it. That is the interoperability test, and it is why the CQL uses only US Core profiles and VSAC value sets.

Content governance

The questionnaire pipeline needs owners. In the programs that have worked, three roles are named from the start.

• A policy owner in utilization management signs off that the questionnaire and its criteria match the written policy, and re-signs when the policy changes.
• A content engineer writes and tests the CQL, keeps the value sets current with VSAC releases, and runs the synthetic cohort before every publication.
• A release manager versions packages, keeps old versions available for in-flight requests, and reads the $log-questionnaire-errors feed weekly.

Plans with delegated vendors add a fourth: a content format the vendors deliver in, so the plan's pipeline accepts their questionnaires the same way it accepts its own. Without that, every vendor ships a different form and the single endpoint becomes a thin wrapper over chaos.

This illustrative content-release process moves from structured policy through authoring and testing to clinical review and versioned publication. Each numbered stage has a distinct purpose.

If your medical policies are still documents, the first useful step is an inventory: which policies, which codes, which criteria can be answered from chart data. We run that inventory and build the questionnaire and CQL pipeline behind it. See our CMS-0057-F interoperability suite and FHIR integration services pages, or talk to our team.

Explore the CMS-0057-F series

• CMS-0057-F Explained: Requirements and 2027 API Deadlines
• Da Vinci CRD Explained: Coverage Requirements Discovery
• Da Vinci DTR Explained: Questionnaires, CQL and Prior Authorization (this article)
• Da Vinci PAS Explained: FHIR Prior Authorization and X12 278
• CMS-0057-F Payer Architecture for Delegated Vendors
• CMS-0057-F API Testing: Inferno, Sandboxes and Evidence

Sources

• HL7 Da Vinci DTR 2.2.0 (current) and 2.1.0
• DTR $questionnaire-package operation
• HL7 Structured Data Capture 3.0
• Clinical Quality Language 1.5
• CMS Prior Authorization API FAQs
• CMS-0062-P proposed rule, Federal Register 2026-07205 (14 April 2026)
• Epic on FHIR developer documentation
• Acentra Health FHIR sandbox
• Inferno test kits
• HL7 Foundry
• Burden Reduction reference implementations (HL7 Confluence)
• HL7-DaVinci GitHub: br-payer, br-provider, test-ehr, crd-request-generator, dtr, CDS-Library
• WEDI survey, March 2026
• Medblocks, CMS-0057-F Explained (Sidharth Ramesh, YouTube)