Documentation Templates and Rules

DTR makes documentation requirements computable

The current DTR implementation guide describes a mechanism for payers to express documentation needs so clinical systems can retrieve existing information, ask for missing data, and adapt questions based on available answers.

The goal is context-specific data capture. A static PDF can list requirements; DTR adds structured forms and executable logic that software can process.

Questionnaires define the form

DTR uses FHIR Questionnaire resources to describe questions, types, groups, answer choices, and display behavior. A patient-specific QuestionnaireResponse holds resulting answers.

These resources carry data and structure. They do not establish that an answer is clinically accurate, authored by the right person, current for the service date, or sufficient under payer policy.

CQL can drive logic and prepopulation

Clinical Quality Language, or CQL, and associated value sets can help determine which questions apply and retrieve candidate data from the EHR. Prepopulation can reduce duplicate entry.

Every populated value needs provenance, source time, patient and encounter context, and a review state. Copying a prior answer into a new request without confirmation can turn efficiency into documentation error.

Native and SMART app paths are possible

An EHR can implement DTR functionality directly or use a SMART on FHIR app. The chosen path affects launch context, authorization, user identity, data access, storage, audit evidence, and failure handling.

Document the supported DTR version, dependencies, payer endpoints, app registration, scopes, token flow, timeout behavior, and where QuestionnaireResponses are stored.

CRD, DTR, and PAS remain separate

Coverage Requirements Discovery can indicate that documentation is needed and offer a DTR path. DTR gathers the structured information. Prior Authorization Support carries an authorization request and response.

DTR can also operate independently in supported workflows. Completion of a questionnaire does not prove that PAS submission occurred or that a payer accepted, adjudicated, or approved anything.

Current publication and CMS requirements differ

The HL7 U.S. guide index lists DTR 2.2.0 as a 2026 publication based on FHIR R4. Its standard status is trial use.

CMS-0057-F requires specified impacted payers to implement Prior Authorization API functionality for medical items and services excluding drugs, generally beginning January 1, 2027. The CMS fact sheet recommends DTR 2.0.0, CRD 2.0.1, and PAS 2.0.1 while separately naming required standards. The rule does not prove that a payer supports DTR 2.2.0 or any DTR endpoint today.

A fictional ABA documentation flow

A payer-specific assessment request needs recent measures, service history, and a clinical rationale. CRD returns a DTR launch. The app retrieves a questionnaire, proposes four values from the EHR, and asks six additional questions.

The qualified clinician confirms two proposed clinical values, corrects one, rejects one as stale, answers the clinical questions, and signs according to the payer route. Operations verifies member, product, authorization period, and submission evidence.

Report prepopulation acceptance 2 of 4, correction 1 of 4, rejection 1 of 4, and required-question completion 6 of 6. These measures describe form handling, not authorization quality or payment.

Clinical authorship cannot be automated away

Software may retrieve data, evaluate computable rules, flag conflicts, and prepare a response. Only an appropriately qualified and authorized person may make or attest clinical findings, goals, dosage, risk, and rationale.

Keep original clinical records and provenance. Do not silently write payer-oriented answers back into the clinical record or alter a note to make a rule pass.

Privacy and security controls follow the data

Map every FHIR read, app launch, payer request, questionnaire package, response, storage location, and downstream disclosure. Apply the correct legal and contractual route, role-based access, least privilege, transport security, audit logging, retention, incident response, and vendor controls.

CQL and questionnaire packages are executable or computable content. Validate trusted publishers, versions, signatures or integrity checks where supported, dependencies, terminology, and safe execution boundaries.

Test the form as a clinical and technical artifact

Create locked cases for complete, partial, stale, conflicting, unavailable, inapplicable, repeated, and corrected data. Include accessibility, language, timeout, payer-version, code-system, and unsupported-question scenarios.

Measure required questions rendered, answer types validated, proposed values confirmed, provenance retained, rules executed, exceptions resolved, and responses delivered. Use a due-case denominator so skipped or failed forms remain visible.

Version every questionnaire package and test case together. Preserve prior packages while older requests, corrections, and appeals remain open.

Before promotion, require signoff from the clinical content owner, payer-operations owner, privacy and security owners, and the technical release owner for their respective domains. Record the exact package hash, terminology versions, test results, approvers, activation time, rollback package, and open limitations in one release record.