Da Vinci CRD, DTR and PAS: how the prior authorization guides fit together

The short answer

The HL7 Da Vinci prior authorization guides split one process into three steps. CRD (Coverage Requirements Discovery) lets a payer tell the provider, inside the EHR at the moment of ordering, whether prior authorization or documentation is needed. DTR (Documentation Templates and Rules) turns the payer’s documentation rules into forms that fill themselves from the EHR for a person to review and complete. PAS (Prior Authorization Support) submits the request as a FHIR Bundle and returns the decision, or a pended status that’s resolved later. CMS strongly encourages all three for the prior authorization API that impacted payers must provide from 1 January 2027.¹

Why three guides

CMS’s fact sheet for CMS-0057-F says the API must identify whether prior authorization is needed and what documentation is required, support the request and response, and return an approval, a denial with a specific reason, or a request for more information. It names Da Vinci CRD STU 2.0.1, DTR STU 2.0.0 and PAS STU 2.0.1 as the guides CMS strongly encourages.¹

Those map neatly onto the three guides. Newer versions have since been published: the current versions are CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1.³⁴² Check which version your trading partners support; this post uses the versions CMS named.

CRD: what does this payer need?

CRD defines a workflow for payers to provide coverage requirements to providers through their own systems at the time treatment decisions are made.³ It’s built on CDS Hooks: the EHR calls the payer’s CRD service when a user does something, and the service answers with cards. CRD covers the appointment-book, encounter-start, encounter-discharge, order-dispatch, order-select and order-sign hooks.³

In practice: a clinician signs an order for an MRI; the order-sign hook calls the payer; the payer answers that prior authorization is required and offers a link to launch DTR. The guide supports both PHI-specific and non-PHI mechanisms, depending on what the payer is allowed to see.³

DTR: gather the documentation

DTR uses FHIR Questionnaires with embedded CQL logic and value sets to retrieve existing information from the EHR, prompt for what’s missing, and decide which questions need answering.⁴ The design aim is extracting existing EHR information “for review/confirmation”, so the person filling the form checks what was pulled in rather than re-keying it.⁴

The forms can be rendered in a SMART on FHIR app or inside the EHR itself. The guide defines four kinds of system: a DTR Payer Service that serves questionnaires, a DTR SMART Client, a Full DTR EHR that fills forms natively, and a Light DTR EHR that relies on a SMART app; the payer side supports Questionnaire Package, ValueSet Expand and Next Question operations.⁴ The result is a QuestionnaireResponse that travels with the request.

PAS: submit and track

PAS submits the request. The provider system POSTs a Bundle to [base]/Claim/$submit; the first entry is a Claim, FHIR’s resource for prior authorization requests.² The receiving system may convert the Bundle into an X12N 278, the transaction HIPAA designates for prior authorization, and convert the 278 response back into a FHIR Bundle.² Under a CMS-granted exception, implementers can instead send the PAS bundles intact without X12 translation.²

The detail that matters most for anyone automating: if the payer can’t decide in time, items come back pended. The client can then use a subscription to hear about updates, or Claim/$inquire to ask for the final result.² A response arrived; a decision may not have.

One request, end to end

1. Clinician signs an order. The EHR fires order-sign to the payer’s CRD service.³
2. CRD returns a card: prior auth required; launch DTR.
3. DTR loads the payer’s questionnaire; CQL fills answers from the EHR; staff review, correct and complete them.⁴
4. The EHR builds a PAS Bundle with the Claim and the QuestionnaireResponse and calls Claim/$submit.²
5. The payer answers: approved, denied with a reason, or pended.¹²
6. If pended, the provider system waits on a subscription or polls $inquire.²

Where automation needs checks

AI is being used on both sides of this flow. Each step has one failure to design against:

The pended row is the easiest to get wrong. An agent that sees a successful HTTP response and a ClaimResponse may summarise it as “approved” when the item is pended. Our open draft spec’s examples include exactly this case: a synthetic Da Vinci PAS submission where the agent reports payer approval but the read-back shows the request pended.⁶ The spec page shows how the claim and the observed state sit side by side in one record.

For Bundles generally, read each entry’s status in the response, not just the overall reply; the R4 rules for batch and transaction responses are summarised in our transaction vs batch post.⁵

Questions people ask

Do I need all three guides?

CMS strongly encourages all three for the payer API, not mandates each one.¹ Many providers will meet PAS first, then CRD and DTR as payers offer them.

Does PAS replace the X12 278?

PAS is designed to map to the 278 through an intermediary, and the X12 mapping is published by X12.² Under the CMS exception, bundles can be exchanged intact.²

Where does AI fit safely?

Pre-filling DTR answers for a person to confirm, and tracking pended requests, are natural fits. Deciding or explaining denials needs a person and a traceable criterion; our CMS-0057-F post covers the denial-reason rule.

For payers and their vendors, our insurer page explains how agent actions in this flow can be recorded and checked. To try approvals and read-backs on a real database in your browser, open the playground; to grade what an agent can reach on your own machine, run npx deedglass scan (the grade, explained).

Written with AI assistance and checked against our claims register.