Prior Authorization Automation: Building the CMS-Mandated FHIR API with Da Vinci PAS Step by Step

Prior authorization costs US healthcare $31 billion annually in administrative overhead. Physicians spend an average of 13 hours per week on prior auth activities. Patients wait 2-14 days for decisions that could be instant. And starting January 2027, every CMS-regulated payer must support a FHIR-based prior authorization API.

The CMS interoperability mandate (CMS-0057-F) is a forcing function. This isn't a theoretical FHIR exercise — it's a regulatory deadline with real enforcement. Payers must build PAS (Prior Authorization Support) endpoints. Providers need systems that can submit and track authorizations through these APIs. And the Da Vinci PAS Implementation Guide is the technical specification that makes it all work.

This guide is implementation-focused. We walk through the Da Vinci PAS IG structure, the FHIR Claim resource for preauthorization, ClaimResponse parsing for decisions, CRD integration for requirement discovery, testing against the Da Vinci reference implementation, and the real-world challenges you'll face when payers interpret the IG differently. We include FHIR JSON examples throughout.

Da Vinci PAS IG: Structure and Key Concepts

The Da Vinci Prior Authorization Support (PAS) Implementation Guide defines how providers submit prior authorization requests to payers using FHIR. It builds on the FHIR Claim resource and adds extensions specific to prior auth workflows. Key concepts:

• $submit operation: Providers submit prior auth requests by POSTing a FHIR Bundle containing a Claim resource to the payer's Claim/$submit endpoint. This replaces the X12 278 Health Care Services Review transaction.
• Claim resource with use=preauthorization: The FHIR Claim resource is repurposed for prior auth — not claims adjudication. The use field is set to preauthorization and the type to professional or institutional.
• ClaimResponse with decision: The payer returns a ClaimResponse with the authorization decision. The response may be synchronous (immediate decision) or asynchronous (pended for review).
• Bundle-based submission: The request is a FHIR Bundle containing all referenced resources — the Claim, Patient, Coverage, Practitioner, Organization, and any supporting DocumentReference resources.
• PAS-specific extensions: The IG defines extensions for review action, condition code, certification type, and item authorization detail that don't exist in base FHIR.

The FHIR Claim Resource for Prior Authorization

The Claim resource is the core of every PAS submission. Understanding its structure is the first implementation task.

Required Fields

{
  "resourceType": "Claim",
  "id": "prior-auth-mri-lumbar",
  "status": "active",
  "type": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/claim-type",
      "code": "professional"
    }]
  },
  "use": "preauthorization",
  "patient": {
    "reference": "Patient/patient-john-doe"
  },
  "created": "2026-03-15",
  "provider": {
    "reference": "Organization/requesting-provider"
  },
  "insurer": {
    "reference": "Organization/target-payer"
  },
  "priority": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/processpriority",
      "code": "normal"
    }]
  },
  "insurance": [{
    "sequence": 1,
    "focal": true,
    "coverage": {
      "reference": "Coverage/patient-coverage"
    }
  }],
  "diagnosis": [{
    "sequence": 1,
    "diagnosisCodeableConcept": {
      "coding": [{
        "system": "http://hl7.org/fhir/sid/icd-10-cm",
        "code": "M54.5",
        "display": "Low back pain"
      }]
    }
  }],
  "item": [{
    "sequence": 1,
    "productOrService": {
      "coding": [{
        "system": "http://www.ama-assn.org/go/cpt",
        "code": "72148",
        "display": "MRI lumbar spine without contrast"
      }]
    },
    "diagnosisSequence": [1],
    "servicedDate": "2026-03-20",
    "locationCodeableConcept": {
      "coding": [{
        "system": "https://www.cms.gov/Medicare/Coding/place-of-service-codes",
        "code": "11",
        "display": "Office"
      }]
    },
    "quantity": {
      "value": 1
    }
  }]
}

Key Implementation Notes

• type vs use: Both must be set. type is "professional" or "institutional" (matching the service setting). use is always "preauthorization" for PAS requests.
• diagnosis and item linkage: Each item references diagnoses by diagnosisSequence. The payer uses this to evaluate medical necessity — the diagnosis must support the requested service.
• productOrService coding: Use CPT for professional services, HCPCS for durable medical equipment, and ICD-10-PCS for inpatient procedures. The code system must be explicit in the system field.
• insurance reference: Points to a Coverage resource in the submission Bundle. The Coverage contains the payer plan ID, subscriber ID, and group number.

Supporting Information and Attachments

Many prior auth requests require supporting clinical documentation. The PAS IG uses Claim.supportingInfo to reference DocumentReference resources containing clinical notes, lab results, imaging reports, or questionnaire responses.

"supportingInfo": [
  {
    "sequence": 1,
    "category": {
      "coding": [{
        "system": "http://hl7.org/us/davinci-pas/CodeSystem/PASSupportingInfoType",
        "code": "patientEvent"
      }]
    },
    "timingPeriod": {
      "start": "2026-01-15",
      "end": "2026-03-15"
    }
  },
  {
    "sequence": 2,
    "category": {
      "coding": [{
        "system": "http://hl7.org/us/davinci-pas/CodeSystem/PASSupportingInfoType",
        "code": "additionalInformation"
      }]
    },
    "valueReference": {
      "reference": "DocumentReference/clinical-notes-mri-justification"
    }
  }
]

The DocumentReference resource contains the actual clinical document — either as an inline base64-encoded attachment or as a URL to a document repository. Payer preferences vary: some accept PDF attachments, others require C-CDA documents, and some accept both. This is one of the most frustrating implementation variables.

The $submit Operation

PAS requests are submitted as FHIR Bundles using the $submit operation on the Claim endpoint. The Bundle must be type collection and must include all referenced resources:

POST /Claim/$submit HTTP/1.1
Host: payer-pas-endpoint.example.com
Content-Type: application/fhir+json
Authorization: Bearer {access_token}

{
  "resourceType": "Bundle",
  "type": "collection",
  "entry": [
    {
      "resource": { /* Claim resource */ }
    },
    {
      "resource": { /* Patient resource */ }
    },
    {
      "resource": { /* Coverage resource */ }
    },
    {
      "resource": { /* Practitioner resource */ }
    },
    {
      "resource": { /* Organization (provider) */ }
    },
    {
      "resource": { /* Organization (payer) */ }
    },
    {
      "resource": { /* DocumentReference (clinical notes) */ }
    }
  ]
}

The payer returns a Bundle containing a ClaimResponse. If the decision is immediate, the response comes synchronously. If the payer needs time to review (which happens for approximately 40% of prior auths), the response indicates "pended" and the provider must poll for updates or subscribe to notifications.

ClaimResponse: Parsing the Decision

The ClaimResponse is where the payer's decision lives. Parsing it correctly is critical — the structure is more complex than it appears.

Approved Response

{
  "resourceType": "ClaimResponse",
  "status": "active",
  "type": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/claim-type",
      "code": "professional"
    }]
  },
  "use": "preauthorization",
  "patient": { "reference": "Patient/patient-john-doe" },
  "created": "2026-03-15T10:30:00Z",
  "insurer": { "reference": "Organization/target-payer" },
  "outcome": "complete",
  "disposition": "Approved",
  "preAuthRef": "AUTH-2026-MRI-78923",
  "preAuthPeriod": {
    "start": "2026-03-15",
    "end": "2026-06-13"
  },
  "item": [{
    "itemSequence": 1,
    "adjudication": [{
      "category": {
        "coding": [{
          "system": "http://terminology.hl7.org/CodeSystem/adjudication",
          "code": "submitted"
        }]
      },
      "reason": {
        "coding": [{
          "system": "http://hl7.org/us/davinci-pas/CodeSystem/PASInformationChangeMode",
          "code": "A1",
          "display": "Certified in total"
        }]
      }
    }]
  }]
}

Pended Response

When the payer needs additional time, the outcome is queued and the response includes extensions indicating what additional information is needed:

{
  "resourceType": "ClaimResponse",
  "outcome": "queued",
  "disposition": "Pended — additional clinical documentation required",
  "extension": [{
    "url": "http://hl7.org/us/davinci-pas/StructureDefinition/extension-reviewAction",
    "valueCodeableConcept": {
      "coding": [{
        "system": "https://codesystem.x12.org/005010/306",
        "code": "A4",
        "display": "Pending"
      }]
    }
  }],
  "item": [{
    "itemSequence": 1,
    "adjudication": [{
      "category": {
        "coding": [{
          "code": "submitted"
        }]
      },
      "reason": {
        "coding": [{
          "code": "A4",
          "display": "Pending"
        }]
      }
    }]
  }]
}

For pended authorizations, implement a polling mechanism. Use the $inquire operation to check status:

POST /Claim/$inquire HTTP/1.1
Content-Type: application/fhir+json

{
  "resourceType": "Bundle",
  "type": "collection",
  "entry": [{
    "resource": {
      "resourceType": "Claim",
      "use": "preauthorization",
      "identifier": [{
        "value": "original-claim-id"
      }],
      "provider": { "reference": "Organization/requesting-provider" },
      "insurer": { "reference": "Organization/target-payer" }
    }
  }]
}

CRD Integration: Knowing What Payers Require

The Da Vinci Coverage Requirements Discovery (CRD) IG solves a critical problem: how does the provider know what the payer requires for a given service before submitting the PAS request? Without CRD, providers guess — and guessing leads to incomplete submissions, denials, and rework.

How CRD Works

CRD uses the CDS Hooks specification. When a provider enters an order in the EHR, a CDS Hook fires (typically order-select or order-sign) and sends the order context to the payer's CRD endpoint. The payer responds with:

• Whether prior auth is required for this service/diagnosis/payer combination
• What supporting documentation is needed (clinical notes, imaging, lab results)
• A link to a Questionnaire resource if the payer uses DTR (Documentation Templates and Rules) for structured data collection
• An estimate of expected turnaround time

// CDS Hooks request for CRD (order-select hook)
{
  "hookInstance": "d1577c69-dfbe-44ad-ba6d-3e05e953b2ea",
  "hook": "order-select",
  "context": {
    "userId": "Practitioner/dr-smith",
    "patientId": "Patient/patient-john-doe",
    "draftOrders": {
      "resourceType": "Bundle",
      "entry": [{
        "resource": {
          "resourceType": "ServiceRequest",
          "code": {
            "coding": [{
              "system": "http://www.ama-assn.org/go/cpt",
              "code": "72148",
              "display": "MRI lumbar spine w/o contrast"
            }]
          },
          "reasonCode": [{
            "coding": [{
              "system": "http://hl7.org/fhir/sid/icd-10-cm",
              "code": "M54.5"
            }]
          }]
        }
      }]
    }
  },
  "prefetch": {
    "patient": { /* Patient resource */ },
    "coverage": { /* Coverage resource */ }
  }
}

CRD Response: Cards and System Actions

The payer CRD endpoint returns CDS Hooks cards that the EHR displays to the provider:

{
  "cards": [{
    "uuid": "auth-required-mri-lumbar",
    "summary": "Prior authorization required for MRI Lumbar Spine",
    "detail": "This service requires prior authorization for the patient's plan. Please submit clinical documentation including recent physical exam notes and conservative treatment history.",
    "indicator": "warning",
    "source": { "label": "Payer CRD Service" },
    "suggestions": [{
      "label": "Launch Prior Auth Request",
      "actions": [{
        "type": "create",
        "description": "Pre-populated PAS Claim",
        "resource": { /* Pre-filled Claim resource */ }
      }]
    }],
    "links": [{
      "label": "Complete Documentation Questionnaire",
      "url": "https://payer.example.com/dtr/questionnaire/mri-lumbar",
      "type": "smart"
    }]
  }]
}

The power of CRD + PAS together: CRD tells you what's needed, PAS is how you submit it. When integrated, the provider sees at order entry whether auth is required, what documentation to include, and can launch the PAS submission directly from the EHR workflow — rather than discovering the requirement after the fact through a denied claim.

Real-World Implementation Challenges

The Da Vinci PAS IG is well-specified on paper. In practice, implementation teams face significant challenges that the IG doesn't fully address.

Challenge 1: Payer Variability

Each payer interprets the PAS IG differently. Required fields, supported code systems, attachment format requirements, and response timing all vary. One payer may require clinical notes as PDF DocumentReferences; another requires C-CDA; a third accepts both but has a 5MB size limit. Your implementation must handle this variability. The solution: build a payer registry that stores payer-specific configuration — required fields, accepted formats, endpoint URLs, and known quirks — and use it to customize each submission.

Challenge 2: Attachment Handling

Clinical documentation attachments are the most common point of failure. Issues include: size limits (some payers cap at 5MB per attachment), format requirements (PDF vs C-CDA vs plain text), encoding requirements (base64 vs URL reference), and the clinical question of which documents to include. Too few documents leads to denial for insufficient information. Too many leads to processing delays and reviewer fatigue. Build logic that selects relevant documents based on the service type and diagnosis, informed by CRD responses when available.

Challenge 3: Asynchronous Decision Flow

Approximately 40% of prior authorizations are pended for review. Your system must handle asynchronous workflows: submit the request, receive a pended response, track the pending authorization, poll for updates (or process subscription notifications), and update the EHR when the decision arrives. This requires a persistent tracking system — a database of pending authorizations with scheduled polling jobs or FHIR Subscription listeners.

Challenge 4: X12 278 Fallback

Not all payers will support PAS by the January 2027 deadline. Commercial payers that aren't CMS-regulated have no mandate. Your system needs a fallback path to X12 278 for these payers. The architecture should abstract the submission layer so the EHR workflow is the same regardless of whether the backend uses PAS (FHIR) or 278 (X12) — the facade pattern applies here too.

Challenge 5: Testing Without Standardized Sandboxes

Unlike SMART on FHIR (which has standardized sandbox environments), PAS testing infrastructure is fragmented. Each payer provides their own sandbox (or doesn't). The Da Vinci reference implementation provides basic testing but doesn't cover payer-specific behaviors. Your testing strategy should include: (1) unit tests with fixture Bundles, (2) integration tests against the Da Vinci RI, (3) payer-specific sandbox testing, and (4) end-to-end testing with your EHR in a non-production environment.

Implementation Architecture

The recommended architecture places PAS middleware between your EHR and payer endpoints. The middleware handles the complexity so the EHR sees a clean, consistent API.

Key Middleware Components

• FHIR Client: Handles HTTP communication with payer PAS endpoints, including OAuth2 token management (payers require client credentials flow for backend access)
• Claim Builder: Assembles the FHIR Claim resource from EHR order data, mapping internal codes to standard code systems (CPT, ICD-10-CM, HCPCS)
• CRD Integration: Receives CDS Hooks from the EHR, forwards to payer CRD endpoints, and feeds requirement information back to the Claim Builder
• Attachment Manager: Retrieves clinical documents from the EHR document repository, converts formats as needed, and assembles DocumentReference resources
• Status Tracker: Maintains a database of submitted and pended authorizations, runs polling jobs, and pushes status updates to the EHR
• Payer Registry: Configuration store for payer-specific PAS endpoint URLs, required fields, attachment preferences, and known implementation quirks

Testing with the Da Vinci Reference Implementation

The Da Vinci project provides a reference implementation (RI) for PAS that you can run locally for development and testing. It validates your Claim submissions against the PAS profiles and returns mock ClaimResponse decisions.

# Run the Da Vinci PAS reference implementation
docker pull hl7davinci/prior-auth:latest
docker run -d -p 9015:9015 hl7davinci/prior-auth:latest

# Test submission
curl -X POST http://localhost:9015/Claim/\$submit \
  -H "Content-Type: application/fhir+json" \
  -d @pas-bundle.json

# Check response
curl http://localhost:9015/ClaimResponse?patient=Patient/patient-john-doe

Limitations of the RI: it returns canned responses (always approved or always pended depending on configuration), doesn't simulate real payer logic, and may lag behind the latest IG version. Use it for structure validation and workflow testing, not for business logic validation. For real payer behavior testing, you need each payer's sandbox.

The CMS Mandate Timeline

The key dates every implementation team must know:

• January 2024: CMS-0057-F Final Rule published
• January 2025: Payer reporting requirements begin (tracking prior auth metrics)
• January 2026: Payer API implementation deadline (systems must be built)
• January 2027: Full enforcement — all CMS-regulated payers (Medicare Advantage, Medicaid, CHIP, Exchange plans) must support PAS API

For providers, there's no hard mandate to use the PAS API — but the competitive advantage is clear. Providers who automate prior auth through PAS will: (1) reduce auth turnaround from days to hours (or minutes for auto-approved requests), (2) eliminate phone/fax submission workflows, (3) reduce denial rates by submitting complete, requirement-informed requests via CRD, and (4) free up staff from the 13 hours/week per physician currently spent on prior auth activities.

Building interoperable healthcare systems is complex. Our Healthcare Interoperability Solutions team has deep experience shipping production integrations. We also offer specialized Agentic AI for Healthcare services. Talk to our team to get started.

Frequently Asked Questions

How is Da Vinci PAS different from X12 278?

X12 278 is the legacy electronic prior auth transaction — flat file format, batch processing, limited attachment support, and no mechanism for requirement discovery. PAS replaces 278 with FHIR: REST API access, structured clinical data via FHIR resources, real-time submission and response, rich attachment support via DocumentReference, and integration with CRD for requirement discovery. PAS is designed for automation; 278 was designed for human-mediated electronic submission.

Do we need to support both PAS and X12 278?

Yes, for the foreseeable future. The CMS mandate only applies to CMS-regulated payers. Commercial payers without CMS contracts have no mandate to support PAS. Some smaller Medicaid MCOs may be slow to implement. Your architecture must support both PAS (FHIR) and 278 (X12) submission paths, with the payer registry determining which path to use for each payer.

What about DTR (Documentation Templates and Rules)?

DTR is the third piece of the Da Vinci prior auth stack: CRD discovers requirements, DTR collects structured documentation (via FHIR Questionnaire/QuestionnaireResponse), and PAS submits the request. DTR is optional but powerful — it replaces free-text clinical justification with structured data that payers can process automatically. If a payer's CRD response includes a DTR questionnaire link, completing it increases the likelihood of auto-approval.

Can AI agents automate the PAS workflow?

Partially today, more so in 2-3 years. AI agents can already: (1) monitor orders for auth requirements via CRD, (2) assemble clinical documentation from EHR data, (3) populate Claim resources automatically, and (4) submit via PAS API. The gap: clinical judgment for complex cases where the diagnosis justification requires reasoning about the patient's complete clinical history. This is exactly the kind of task that multi-agent healthcare systems are being designed to handle.

What FHIR profiles does PAS use?

The PAS IG defines profiles on: Claim (PASClaim), ClaimResponse (PASClaimResponse), Bundle (PASRequestBundle, PASResponseBundle), Coverage, Patient, Practitioner, Organization, and several supporting resources. These profiles add required extensions, constrain cardinality, and bind value sets specific to prior authorization. Your FHIR validation should check against PAS profiles, not just base FHIR R4 profiles — a valid FHIR Claim may not be a valid PAS Claim.

Conclusion

Da Vinci PAS is the technical foundation for ending the prior authorization nightmare. The FHIR-based approach replaces phone calls, fax machines, and web portals with structured API transactions that can be automated, tracked, and optimized. Combined with CRD for requirement discovery and DTR for structured documentation, the complete Da Vinci stack makes touchless prior authorization feasible for straightforward requests.

The implementation isn't trivial — payer variability, attachment handling, and asynchronous workflows all add complexity. But the architecture pattern is clear: build middleware that abstracts payer differences, integrate CRD into the EHR ordering workflow, and implement PAS submission with robust status tracking.

Providers who build this infrastructure now will be ready when payer PAS endpoints go live at scale in 2027. Those who wait will face the same scramble that accompanied every previous CMS interoperability deadline — except this time, the technology is mature, the spec is published, and the reference implementations are available. The only variable is execution.

Building a prior auth automation platform? At Nirmitee, we implement Da Vinci PAS, CRD, and DTR integrations for health systems and health tech companies. We can assess your current prior auth workflow and deliver a working PAS prototype connected to your EHR in 6-8 weeks. Start building.