Prior Authorization Workflow

Prior authorization is one of the most disruptive friction points in US healthcare — a manual fax-and-phone process that delays care, consumes clinician time, and generates denials that could have been avoided with better information upfront. CMS-0057-F (Interoperability and Prior Authorization Final Rule, 2024) mandates that affected payers implement electronic prior authorization using FHIR. The technical mechanism is a three-IG Da Vinci stack: CRD, DTR, and PAS.

This page covers the end-to-end workflow: what each step does, what each party must implement, and where the common failures occur. For the regulatory obligations, see CMS Interoperability Rules. For the Claim resource structure used in PAS, see Claim.

The problem this solves

The traditional prior auth process: a clinician orders a service, a staff member identifies it may need PA, faxes a form to the payer, calls to confirm receipt, waits days or weeks for a fax response, appeals if denied. The order-to-authorization cycle averages 2–3 business days under best conditions. Real-world delays often exceed a week.

The Da Vinci PA stack attacks this in sequence: check coverage requirements before ordering (CRD), gather required documentation at the point of care (DTR), and submit and receive PA decisions within the EHR workflow (PAS). Each step can independently reduce friction; all three together eliminate most fax-based PA.

The three-IG stack

IG	What it does	Who implements it	When it runs
CRD (Coverage Requirements Discovery)	Real-time payer guidance embedded in EHR workflow	Payer (server), EHR (client)	As clinician is ordering
DTR (Documentation Templates and Rules)	Gathers required documentation using payer-defined Questionnaires, pre-populated from EHR data	Payer (Questionnaire publisher), EHR or SMART app (form renderer)	After CRD identifies PA requirement
PAS (Prior Authorization Support)	Submits the PA request and receives a real-time or pended decision	Payer (server), EHR or intermediary (client)	After documentation is gathered

The IGs are designed to chain: CRD tells you whether PA is needed and what documentation is required, DTR collects that documentation, PAS submits the request with the documentation attached. A payer can implement all three or some subset; a provider system needs to support whichever IGs their payer partners implement.

Step 1: CRD — Coverage Requirements Discovery

What CRD does

CRD embeds payer guidance directly into the EHR ordering workflow using CDS Hooks — a standard for real-time clinical decision support. When a clinician creates a medication order, referral, or lab order, the EHR sends a hook invocation to the payer’s CRD server. The payer returns cards with coverage guidance before the order is signed.

CRD answers three questions in real time:

Is this service covered at all?
Does it require prior authorization?
If so, what documentation is required?

CDS Hooks integration

CRD uses these hooks:

Hook	When it fires
`order-select`	Clinician selects a medication, device, or service
`order-sign`	Clinician is about to sign/finalize the order
`encounter-start`	Patient encounter begins
`appointment-book`	Appointment is being scheduled
`order-dispatch`	Order is being sent to a performer

The EHR sends patient context (Patient, Coverage, Encounter), the order in progress (MedicationRequest, ServiceRequest, etc.), and relevant clinical context. The CRD server returns CDS Hooks cards with guidance.

CRD response types

CRD cards can tell the EHR:

Coverage information — is this service covered under the patient’s plan
Prior authorization required — PA is needed; here is the requirements URL
Prior authorization not required — proceed without PA
Documentation required — attach specific clinical documentation with the claim
DTR launch — launch the DTR app/workflow to collect required documentation
Alternatives suggested — covered alternatives to an uncovered service

What payers must implement (CRD server)

A CDS Hooks discovery endpoint listing supported hooks
Hook handlers for the relevant order and appointment hooks
Logic to determine PA requirements based on the patient’s specific coverage
Card construction returning structured guidance with systemActions where appropriate

What EHRs/provider systems must implement (CRD client)

CDS Hooks client capable of calling external hook services
Rendering CDS Hooks cards within the ordering workflow
Handling systemActions that auto-populate order fields
Surfacing the DTR launch option when CRD returns it

Step 2: DTR — Documentation Templates and Rules

What DTR does

When CRD identifies that PA is required and documentation must be gathered, DTR provides the mechanism to collect it. The payer publishes a Questionnaire (FHIR Questionnaire resource) defining what information is needed. DTR either launches a SMART app that renders the Questionnaire or integrates the Questionnaire directly into the EHR’s native UI. Crucially, DTR pre-populates the Questionnaire with data already in the EHR — retrieving it via CQL (Clinical Quality Language) queries — so clinicians only fill in what the EHR doesn’t already have.

The Questionnaire/QuestionnaireResponse pattern

{
  "resourceType": "Questionnaire",
  "id": "oncology-chemo-pa",
  "url": "https://payer.example.org/fhir/Questionnaire/oncology-chemo-pa",
  "title": "Oncology Chemotherapy PA Requirements",
  "item": [
    {
      "linkId": "diagnosis",
      "text": "Primary diagnosis",
      "type": "open-choice",
      "answerValueSet": "http://hl7.org/fhir/ValueSet/icd-10",
      "required": true
    },
    {
      "linkId": "prior-treatment",
      "text": "Has the patient received prior chemotherapy?",
      "type": "boolean",
      "required": true
    }
  ]
}

The completed form is a QuestionnaireResponse that travels with the PAS Claim submission in Step 3.

CQL pre-population

Payer Questionnaires include CQL expressions that tell DTR how to fetch answers from the EHR’s FHIR server. For example: a question about the patient’s most recent HbA1c can be answered automatically by querying Observation?patient=X&code=4548-4&_sort=-date&_count=1. Clinicians only see fields that couldn’t be pre-populated — dramatically reducing documentation burden.

Two deployment models

SMART app: DTR launches a SMART on FHIR application that renders the Questionnaire. The app runs in the EHR’s embedded browser. The app queries the EHR for pre-population data and writes the completed QuestionnaireResponse back.

Native: The EHR renders the Questionnaire in its own UI using the DTR IG’s SDC (Structured Data Capture) rendering specifications. More integrated but more complex to implement.

What payers must implement (DTR)

Publish Questionnaires with CQL pre-population expressions via a public endpoint
Optionally: a SMART on FHIR app for form rendering
QuestionnaireResponse storage/retrieval for in-progress forms

What EHRs must implement (DTR)

SMART app launch capability, or native Questionnaire rendering
CQL execution engine for pre-population
QuestionnaireResponse storage linked to the active order

Step 3: PAS — Prior Authorization Support

What PAS does

PAS is the actual submission: a FHIR Claim resource with use: preauthorization is submitted to the payer’s PAS endpoint. The payer returns a ClaimResponse (synchronously or asynchronously) with the PA decision. The entire exchange happens within the EHR, replacing the fax workflow.

The Claim submission

{
  "resourceType": "Claim",
  "id": "pa-request-example",
  "meta": {
    "profile": ["http://hl7.org/fhir/us/davinci-pas/StructureDefinition/profile-claim"]
  },
  "status": "active",
  "use": "preauthorization",
  "patient": { "reference": "Patient/123" },
  "created": "2025-01-15",
  "insurer": { "reference": "Organization/payer-acme" },
  "provider": { "reference": "Practitioner/dr-jones" },
  "priority": { "coding": [{ "code": "normal" }] },
  "insurance": [
    {
      "sequence": 1,
      "focal": true,
      "coverage": { "reference": "Coverage/member-456" }
    }
  ],
  "item": [
    {
      "sequence": 1,
      "productOrService": {
        "coding": [{ "system": "http://www.ama-assn.org/go/cpt", "code": "96413" }]
      },
      "servicedDate": "2025-02-01",
      "quantity": { "value": 1 }
    }
  ]
}

The Claim includes references to the QuestionnaireResponse from DTR as a supportingInfo entry, attaching the collected documentation to the submission.

Synchronous vs pended responses

CMS-0057-F mandates specific decision timeframes:

Request type	Required decision timeframe
Urgent	72 hours
Standard (non-urgent)	7 calendar days

PAS supports two response patterns:

Synchronous — the ClaimResponse comes back in the HTTP response to the Claim POST. Most appropriate for straightforward requests that the payer can approve or deny based on rules alone.

Pended (asynchronous) — the ClaimResponse immediately returns outcome: queued. The payer processes the request and delivers a final decision via a subscription notification or polling. The provider system must track pended requests and surface the decision when it arrives.

The ClaimResponse decision

{
  "resourceType": "ClaimResponse",
  "status": "active",
  "use": "preauthorization",
  "outcome": "complete",
  "item": [
    {
      "itemSequence": 1,
      "adjudication": [
        {
          "category": {
            "coding": [{ "code": "submitted" }]
          }
        }
      ],
      "extension": [
        {
          "url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-reviewAction",
          "extension": [
            { "url": "number", "valueString": "AUTH-20250115-001" },
            { "url": "code", "valueCodeableConcept": {
              "coding": [{ "code": "A1", "display": "Approved" }]
            }}
          ]
        }
      ]
    }
  ]
}

For a denied request, the ClaimResponse must include a processNote with the reason for denial — this is a CMS-0057-F specific requirement. Free-text denial reasons are not sufficient; structured reason codes are required.

preAuthRef propagation

When PA is approved, the preAuthRef from the ClaimResponse must be included in the subsequent Claim for billing. The flow: PAS ClaimResponse returns preAuthRef: AUTH-20250115-001 → that value goes into Claim.insurance.preAuthRef on the billing claim → the payer’s adjudication system validates PA was obtained.

X12 278 relationship

Most payer backends still process PA requests as X12 278 transactions. In practice, PAS intermediaries (clearinghouses and FHIR facades) translate FHIR Claim ↔ X12 278 at the network edge. A provider system submitting FHIR PAS may be talking to a FHIR endpoint that translates to X12 on the payer side — this is explicitly supported by the PAS IG.

The important implication: PA decisions that originated in X12 workflows may not carry all the structured data the FHIR model expects. Intermediaries often fill gaps with text in processNote. Don’t assume a response from an intermediary-fronted payer is semantically equivalent to a native FHIR PAS response.

CMS-0057-F compliance obligations

Which payers are covered

Medicare Advantage organizations, state Medicaid FFS programs, CHIP, and QHP issuers on the Exchanges.

January 1, 2026 deadline

All covered payers must:

Implement an electronic PA API using FHIR (PAS-compliant or equivalent)
Return PA decisions within the mandated timeframes (72h urgent / 7 days standard)
Include structured denial reasons in all denied responses
Track and report PA metrics (approval rate, average decision time, denial reasons)

The PA API does not strictly require CRD and DTR — CMS-0057-F mandates the PA submission and decision workflow (PAS). CRD and DTR are part of the Da Vinci stack and best practice for reducing documentation burden, but are not individually mandated.

What the rule does not mandate

CRD implementation (recommended but not required)
DTR implementation (recommended but not required)
A specific FHIR IG (must meet the functional requirements; PAS is the designated standard but alternatives are possible under the rule)

Implementation considerations

Provider system readiness checklist

CDS Hooks client for CRD integration
SMART app launch for DTR (or native Questionnaire rendering + CQL)
PAS Claim submission with QuestionnaireResponse attachment
Pended request tracking and notification surface
preAuthRef capture and propagation to billing claims
PA status visible within order and encounter workflow

Payer system readiness checklist

CRD server with hook handlers for relevant order types
Questionnaire library with CQL pre-population expressions
PAS endpoint accepting Claim with use: preauthorization
Synchronous decision for rules-based approvals; pended workflow for complex cases
Structured denial reasons in ClaimResponse processNote
72h/7-day SLA enforcement and monitoring

The intermediary question

Many payers and providers will implement the Da Vinci PA stack through clearinghouse intermediaries rather than building native FHIR endpoints. This is practical but introduces latency and semantic translation risk. When evaluating intermediary options, confirm: FHIR → X12 translation fidelity, structured denial reason support, and pended workflow handling.

Common mistakes

Implementing PAS without CRD, so PA requirements aren’t surfaced until after the order is complete
Returning denial ClaimResponses without structured reason codes (violates CMS-0057-F)
Not propagating preAuthRef to the billing Claim, causing downstream adjudication failures
Treating all PAS submissions as synchronous — pended responses need active tracking
Missing the distinction between preauthorization and predetermination on the Claim.use field

Prior Authorization Workflow

Prior Authorization Workflow

The problem this solves

The three-IG stack

Step 1: CRD — Coverage Requirements Discovery

What CRD does

CDS Hooks integration

CRD response types

What payers must implement (CRD server)

What EHRs/provider systems must implement (CRD client)

Step 2: DTR — Documentation Templates and Rules

What DTR does

The Questionnaire/QuestionnaireResponse pattern

CQL pre-population

Two deployment models

What payers must implement (DTR)

What EHRs must implement (DTR)

Step 3: PAS — Prior Authorization Support

What PAS does

The Claim submission

Synchronous vs pended responses

The ClaimResponse decision

preAuthRef propagation

X12 278 relationship

CMS-0057-F compliance obligations

Which payers are covered

January 1, 2026 deadline

What the rule does not mandate

Implementation considerations

Provider system readiness checklist

Payer system readiness checklist

The intermediary question

Common mistakes

See also