CRD, DTR and PAS Explained: How Da Vinci Prior Authorization Fits CMS-0057-F

The big picture

CMS-0057-F requires impacted payers (except QHP issuers on the FFEs for certain timeframe provisions) to stand up a FHIR-based Prior Authorization API. CMS strongly recommends implementing it with the HL7 Da Vinci "Burden Reduction" suite: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), and Prior Authorization Support (PAS). Each answers a different provider question, and together they move prior authorization out of the fax machine and into the EHR.

What CRD does

Coverage Requirements Discovery answers the first question a provider has: does this item or service even need prior authorization for this patient and plan, and what documentation applies? CRD is built on CDS Hooks — the payer registers a service that the EHR calls at natural decision points (for example, order-select or order-sign). The payer returns "cards" indicating whether PA is required and, critically, whether a DTR questionnaire is available.

What DTR does

Documentation Templates and Rules handles the paperwork. The payer publishes FHIR Questionnaire resources (and CQL rules) that describe exactly what clinical documentation a given authorization needs. A DTR app or embedded EHR component runs the questionnaire, auto-populating answers from the EHR's FHIR data wherever possible, and produces a QuestionnaireResponse. The goal is to eliminate the "please fax these ten pages" round-trips by defining the requirements as computable rules.

What PAS does

Prior Authorization Support is the submission and decision channel. PAS wraps the prior authorization request — represented in FHIR as a Claim with use = preauthorization plus the supporting QuestionnaireResponse and clinical bundle — and returns a ClaimResponse carrying the decision (approved, denied with a specific reason, or pended). PAS is the IG that most directly satisfies the "submit a PA request electronically and get a decision" requirement of the rule.

How they work together

The chain is intentionally ordered: CRD tells the provider a PA is needed and points to a DTR questionnaire; DTR assembles the documentation; PAS submits the completed package. A payer can implement them incrementally, but the provider experience is best when all three are present.

Where the payer API boundary sits

Everything to the left of the FHIR endpoint is the provider/EHR ecosystem; everything to the right is yours. The payer is responsible for: hosting the CRD CDS Hooks service, publishing DTR questionnaires and rules, exposing the PAS endpoint, and — behind that boundary — routing the request into the utilization management and core administration systems that actually make and record the decision. The FHIR API is a contract, not the decision engine.

Interaction with utilization management & core administration

When a PAS request arrives, the interoperability layer must translate the FHIR Claim into whatever your authorization workflow expects, invoke the UM/authorization engine, and translate the outcome back into a FHIR ClaimResponse. In many payer environments that backend is an established core administration platform such as QNXT, Facets, or HealthEdge, or a custom system. These products were not originally designed around Da Vinci FHIR profiles, so an adapter/integration layer is generally necessary to bridge the FHIR request to the platform's native authorization APIs or data model. Do not assume any of these products natively speaks CRD/DTR/PAS unless its own documentation says so; treat the mapping as an onboarding and integration task. The companion guide CMS-0057-F with QNXT works through one such integration in detail.

Where X12 278 still appears

Prior authorization has a long-standing HIPAA transaction — the X12 278 request/response. FHIR does not erase it. The PAS implementation guide is explicitly designed to interoperate with X12 278: in many deployments the FHIR PAS request is transformed into a 278 for the payer's existing transaction infrastructure (or a clearinghouse), and the 278 response is mapped back to a FHIR ClaimResponse. This is why PAS is often described as a "FHIR-to-X12 bridge." Expect X12 278 to remain part of the plumbing behind the FHIR boundary for the foreseeable future, especially where trading-partner agreements and clearinghouses are already built around it.

Common implementation mistakes

• Treating PAS as the whole solution. Without CRD and DTR, providers still don't know when PA is required or what to attach — the burden reduction the rule targets doesn't materialize.
• Hand-authoring DTR questionnaires without governance. Questionnaires and CQL rules must track your medical policy; stale rules produce wrong documentation asks.
• Exposing the core system directly. Binding FHIR resources straight to a core admin schema creates brittle, non-conformant payloads. Map through an interoperability layer.
• Ignoring the X12 278 bridge. Building PAS in isolation from existing 278 infrastructure duplicates work and risks decision inconsistencies.
• Forgetting the process rules. The 72-hour/7-day timeframes and specific-denial-reason requirements apply regardless of channel — they are not satisfied just by shipping an API.

Payer implementation checklist

• Host a CRD CDS Hooks service covering the items/services that require PA.
• Publish DTR Questionnaire resources and CQL rules aligned to current medical policy.
• Expose a PAS endpoint accepting Claim (use=preauthorization) and returning ClaimResponse.
• Map PAS requests/decisions to and from X12 278 where your infrastructure requires it.
• Build the adapter from the interoperability layer to your UM/authorization engine and core administration platform.
• Return specific denial reasons and meet the 72-hour (urgent) / 7-day (standard) timeframes.
• Emit the public PA metrics the rule requires, and capture data for CMS reporting.
• Conformance-test against the Da Vinci PAS/CRD/DTR profiles before onboarding trading partners.