DTR Questionnaires: The Content Investment Nobody Budgeted

When CMS-0057-F budgets were drawn up, DTR usually appeared as one line item among the API builds: stand up the endpoints, pass the connectathon, done. That framing gets the engineering roughly right and the economics completely wrong. DTR's server-side API surface is bounded and well specified. What is neither bounded nor well specified in anyone's budget is the payload: a library of machine- executable clinical questionnaires, with prepopulation logic, covering every item and service on your prior authorization list — authored, tested against real EHR data, versioned, and maintained for as long as your medical policies keep changing. That is a content operation, and most payers have never run one.

What DTR actually requires — from the IG, not the pitch deck

Documentation Templates and Rules exists to answer the question CRD raises: once the order workflow learns that a service needs prior authorization and more documentation, what documentation, and can most of it be gathered without a human retyping the chart? The current DTR implementation guide is concrete about the machinery.

The payer serves a questionnaire package. The $questionnaire-package operation returns one or more collection Bundles, each containing a FHIR Questionnaire, a QuestionnaireResponse shell, plus every Library and ValueSet the questionnaire depends on. Libraries must include CQL in both source and compiled (ELM) form; small value sets must ship pre-expanded. Nothing in that operation is exotic engineering — it is a well-behaved packaging endpoint over content you have to have.

The provider side executes your logic. DTR functionality runs either as a SMART on FHIR app or natively inside the EHR; the IG assigns both form factors the same duties. The app renders the questionnaire and executes the payer-supplied CQL against EHR data to prepopulate answers — the IG is blunt that any supplied CQL SHALL be used as the basis for prepopulation, and that CQL and FHIR Questionnaires are required even for native-EHR implementations. Prepopulated answers get tagged with an origin extension (auto-client or auto-server), so a reviewer can always distinguish machine-filled answers from human ones.

Two questionnaire styles, one content burden. The IG profiles both standard questionnaires — where branching logic ships inside the questionnaire as CQL and executes in the app — and adaptive questionnaires, where the app calls the payer's $next-question operation and your server decides what to ask next. Apps and full EHRs must support both. Adaptive forms move logic from shipped CQL to payer-hosted software, which changes where the code runs but not the underlying obligation: someone still has to encode, per service, what questions establish medical necessity and which EHR data can answer them.

Prepopulation only reaches standardized data. DTR services cannot depend on resources beyond US Core, HRex, and the IG's own profiles. Whatever your medical policy asks for that lives outside those profiles — the failed conservative therapy documented only in a note, the imaging finding in a PDF — will not prepopulate, and your questionnaire design has to decide whether to ask a human or drop the question.

Why the hard cost is content, not code

Now do the multiplication. CMS-0057-F requires your Prior Authorization API to identify all documentation required for approval of any item or service requiring prior authorization. Take your PA list — for a mid-size plan, often hundreds of distinct services once you decompose categories to codes — and for each one, someone must:

• translate the medical policy's documentation requirements into discrete, answerable questions with coded answer options;
• decide which questions are prepopulatable and write CQL that finds the evidence in US Core-shaped EHR data — conditions coded which ways, observations under which LOINC codes, date windows that match the policy's intent;
• test that logic against the messy reality of multiple EHRs' data, where the ejection fraction might be an Observation, a note, or absent;
• and get clinical sign-off that the questionnaire faithfully implements the policy, because every question is now an assertion about what your plan requires.

That skill set — part informaticist, part UM policy analyst, part CQL developer — is scarce, and the work is not one-time. Policies change on clinical evidence cycles; codes change annually; US Core versions advance. A questionnaire library is software with a clinical editorial board, and it needs a standing team, not a project.

The dry irony: the thing everyone budgeted (the API) is the thing vendors can genuinely sell you, while the thing nobody budgeted (the content) is the thing most vendors quietly leave as "customer responsibility — clinical content configuration." Read those statements of work carefully.

Versioning and governance: the part that bites in year two

A questionnaire answered in March must be interpretable in September — by an appeal reviewer, an auditor, or a court. That forces version discipline most content teams have to learn the hard way:

• Immutable versions. A published questionnaire version never changes; edits create a new version with an effective date. The QuestionnaireResponse you received binds to the version it answered, and your storage and rendering must keep old versions resolvable for as long as retention rules require.
• Synchronized releases. A policy change typically touches the CRD rule ("documentation required"), the questionnaire, its CQL, and reviewer guidance. Releasing those out of sync produces the worst provider experience in the program: a questionnaire that asks for things the policy no longer requires, or a reviewer pending a request for an answer the form never collected. Treat policy-to-production as one release train with a changelog.
• An ownership map. For every questionnaire: which medical policy it implements, who owns that policy, when it was last reviewed, and what its prepopulation hit rate is in production. That last number is your content-quality metric — a questionnaire whose CQL prepopulates almost nothing is transferring burden back to providers while claiming to reduce it.

Sequencing with CRD and PAS

DTR sits between CRD and PAS in the Da Vinci flow, and its content dependency shapes sensible sequencing. CRD needs rules content (which services need auth, what documentation topics apply); DTR needs the deep content (the questionnaires themselves); PAS mostly needs plumbing — profiled Claim/ClaimResponse exchange that maps onto the 278 rail you already run. A pragmatic build order starts CRD and PAS engineering early while the content team ramps on questionnaires for the top-volume, highest-abrasion services first — imaging, DME, planned inpatient — and expands coverage service by service. Shipping DTR "wide" with shallow, non-prepopulating questionnaires for everything is worse than shipping it narrow and real: providers learn fast whether your forms actually save them work, and first impressions of the FHIR stack persist. The QuestionnaireResponses you collect also become PAS payload — structured evidence attached to the request — so every well-built questionnaire pays off twice, once at documentation time and again at review time, where structured answers enable the straight-through processing rates the whole program is ultimately chasing.

The budget conversation to have now

If your 2027 plan funds DTR as an API line item, reopen it. The recurring cost center is a clinical content team — informatics authoring, CQL development, EHR-data testing, clinical review — sized to your PA list and your policy-change velocity. The payers that fund that team get prepopulation rates that actually reduce provider burden and reviews that arrive decision-ready. The payers that don't will technically have a conformant DTR endpoint serving questionnaires nobody can stand — and will have spent real money to automate the experience of being handed a blank form.

Verify operation names, conformance statements, and questionnaire profiles against the current published HL7 Da Vinci DTR implementation guide, and API requirements against the CMS-0057-F rule text — the IG versions in scope for 2027 conformance are still moving.