HL7 DTR makes clinical documentation a versioned workflow

DTR turns a document request into a governed questionnaire

The direct answer in the HL7 Da Vinci Documentation Templates and Rules guide is that payer-required clinical documentation can be represented as a versioned, computable workflow rather than a free-form attachment chase. The guide uses FHIR Questionnaires as the structured collection surface and can associate logic and terminology artifacts with those questions. That gives implementers a shared way to identify what was asked, what answer was supplied, what source supported it, and which version of the requirement governed the encounter.

This distinction matters in prior authorization because a list of required documents does not tell a clinician which data elements are needed for a particular service, patient, plan, and policy context. DTR is designed to obtain the relevant documentation requirements and support the completion of those requirements in the clinical workflow. A maintained record should therefore connect the questionnaire, payer and plan context, order or service, patient, author, answers, supporting data, and status without treating every piece of EHR data as an authorized response.

Prepopulation reduces re-entry but does not remove review

DTR can use data available in the EHR to prepopulate answers. It can also apply logic that changes which questions appear as earlier answers become available. Those capabilities can reduce duplicate entry and focus attention, but they introduce an evidence obligation: the workflow should preserve the source, time, patient context, terminology, transformation, and rule version behind each populated value. A field that looks complete can still be stale, mismatched, or outside the intent of the question.

A credible implementation gives the user a way to inspect, confirm, correct, supplement, or decline an answer according to policy and clinical responsibility. It should distinguish a value retrieved from the record from a value entered or attested during the workflow. Missing information and conflicting evidence must remain visible. Automation that converts absence into a default answer, or silently overwrites a user-reviewed value after a refresh, can make the form faster while making the resulting submission less defensible.

The workflow boundary runs from CRD through DTR to PAS

Within the Da Vinci prior-authorization architecture, Coverage Requirements Discovery can surface that authorization or documentation may be needed, DTR supports capture of the requested clinical information, and Prior Authorization Support addresses the submission exchange. The boundaries are deliberate. Discovering a requirement is not the same as assembling evidence; completing a questionnaire is not the same as transmitting a valid request; and a technically accepted transaction is not a favorable utilization decision.

That separation gives buyers a useful trace. For one representative order, the system should show the CRD response that initiated the documentation path, the exact DTR package and questionnaire selected, each answer and provenance, user review, completion status, the information passed toward PAS, the submitted transaction, and the payer response. When a policy or questionnaire changes, the historical case should retain the version actually used instead of re-rendering old evidence under a new rule.

What an implementation demonstration should prove

A production-oriented test should include a fully populated case, a case with missing data, a conflicting clinical value, a changed questionnaire, an unavailable payer endpoint, and a user correction. Reviewers should inspect SMART launch or embedded-workflow context where applicable, authorization and consent boundaries, terminology resolution, CQL execution assumptions, error handling, performance, audit events, exports, and the handoff into submission. The goal is not a polished form; it is a reconstructable chain from requirement version to submitted evidence.

The implementation guide defines exchange expectations, not clinical truth or payer operations. Its publication does not establish that a named payer exposes the required artifacts, that a product conforms, that an EHR contains sufficient data, that a policy was modeled correctly, or that a request will be approved. Payers, providers, implementers, clinicians, coding and utilization teams, privacy and security owners, and qualified standards specialists still own decisions within their respective boundaries.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Prior Auth Monitor will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.