CMS Prior Authorization API: FHIR Requirements for 2027

Reviewed September 2026. Requirements checked against CMS's FAQ pages and the HL7 Da Vinci guides on 25 September 2026.

The CMS Prior Authorization API is the FHIR interface that CMS-0057-F requires Medicare Advantage, Medicaid, CHIP and federal-exchange plans to run from 1 January 2027, so that a provider's EHR can ask whether a service needs approval, learn what documentation is required, submit the request and receive the decision. It covers items and services, not drugs. The HL7 Da Vinci guides CRD, DTR and PAS are how most payers will build it. For the wider rule (the 2026 decision clocks, public metrics, the other three APIs and who must comply) see our page on CMS-0057-F requirements.

This guide is for engineers and architects at payers and payer technology vendors. It covers what CMS says the API must do, how CRD, DTR and PAS map onto those duties, working FHIR examples taken from an open-source PAS server that passes the Inferno PAS suites, the engineering problems that decide delivery dates, and a readiness checklist.

What the CMS Prior Authorization API must do

The CMS Prior Authorization API must do four things: publish which items and services need prior authorization, identify the documentation each one requires, accept a prior authorization request, and return a decision. CMS's HIPAA FAQ describes it as an API "populated with the payer's list of covered items and services that require prior authorization", that "can identify all documentation required", and that "supports a prior authorization request and response".

The decision itself has three valid shapes, per CMS's Prior Authorization API FAQ: an approval with an end date or circumstance, a denial with a specific reason, or a request for more information. Four limits are worth stating plainly because they are misread often:

• Drugs are out of scope under CMS-0057-F. CMS-0062-P proposes to add them, on FHIR for medical-benefit drugs and NCPDP SCRIPT for pharmacy-benefit drugs, but it is still a proposal.
• Real-time decisions are not required. CMS's FAQ says the rule "did not include a requirement ... to make real-time decisions". The 72-hour and 7-day clocks are the requirement.
• The X12 278 alone does not satisfy it. CMS says the 278 "cannot meet the other requirements", because it cannot publish requirements or documentation rules.
• There is no certification. Payers self-attest and keep evidence that the API works; no vendor can sell a Prior Authorization API that CMS has certified.

CMS-0057-F deadlines and who must comply, in one line

The Prior Authorization API is due on 1 January 2027 for Medicare Advantage organizations and state Medicaid and CHIP fee-for-service programs, for the rating period beginning on or after that date for Medicaid and CHIP managed care, and for the plan year beginning on or after it for exchange QHPs; commercial plans are not covered. The dated status (no deadline has moved as of September 2026), the decision clocks, penalties and oversight, the public metrics and the cost estimates are maintained on the CMS-0057-F deadlines and status page.

How CRD, DTR and PAS deliver the four capabilities

CRD answers "is approval needed and what is required", DTR collects the documentation, and PAS carries the request and the decision. CMS recommends these three HL7 Da Vinci guides rather than requiring them, but they are the only published specification that covers all four capabilities, and certified EHRs are being built to them.

Each guide has its own deep dive: Da Vinci CRD (Coverage Requirements Discovery), Da Vinci DTR and Da Vinci PAS and the X12 278. Which versions to build to (2.2.1, 2.2.0 and 2.2.1 for the payer side, with an older path kept open) is covered on the pillar page.

Technical architecture: building the Prior Authorization API

A Prior Authorization API is a workflow engine behind three FHIR interfaces: a CDS Hooks service, a questionnaire service and a PAS endpoint, all reading the same rules and writing to the same utilization management record. The examples below come from our open-source servers and use synthetic data.

Step 1: Resolve the member and the coverage

Every call carries the patient's Coverage, and the payer must resolve it to a member before it can answer. CRD's request model includes the Coverage through prefetch; PAS carries it in the request Bundle. A CRD server returns a 400 for a Coverage whose payer it does not serve, so routing by payer is part of the design, not an afterthought. Plan for mismatched identifiers from day one: dependents under a subscriber's ID, recycled member numbers, and plan changes mid-episode.

Step 2: Answer the CRD hook

When the clinician signs an order, the EHR calls the payer's CRD service, and the payer returns a coverage-information extension inside a system action. For the primary hooks the guide says the server "SHALL include a Coverage Information system action" even if more information is needed. This is the answer for a hospital bed (HCPCS E0250) that needs prior authorization and clinical documentation:

{
  "url": "http://hl7.org/fhir/us/davinci-crd/StructureDefinition/ext-coverage-information",
  "extension": [
    { "url": "coverage", "valueReference": { "reference": "Coverage/crd221-demo-coverage-complete-prefetch" } },
    { "url": "covered", "valueCode": "covered" },
    { "url": "pa-needed", "valueCode": "auth-needed" },
    { "url": "doc-needed", "valueCode": "clinical" },
    { "url": "doc-purpose", "valueCode": "retain-doc" },
    { "url": "billingCode", "valueCoding": { "system": "https://bluebutton.cms.gov/resources/codesystem/hcpcs", "code": "E0250" } },
    { "url": "reason", "valueCodeableConcept": { "text": "Prior authorization with documentation of medical necessity is required for hospital beds." } },
    { "url": "questionnaire", "valueCanonical": "https://nirmitee.io/fhir/Questionnaire/hospital-bed" },
    { "url": "date", "valueDate": "2026-09-12" },
    { "url": "coverage-assertion-id", "valueString": "5f0c3e9b8f4e4a1c9d2b7a6e1f3c8d90" },
    { "url": "expiry-date", "valueDate": "2026-12-11" }
  ]
}

Step 3: Serve the DTR questionnaire package

If documentation is needed, the EHR or a DTR app calls Questionnaire/$questionnaire-package and receives a Parameters resource holding a Bundle with the Questionnaire, the CQL Library that pre-fills answers from the chart, the ValueSets it uses and a draft QuestionnaireResponse. The guide requires a single payer endpoint for DTR (run by the payer or a delegate), CQL compatible with version 1.5, and questionnaires that populate from US Core and HRex data where possible. Writing those questionnaires from medical policy documents is the long pole of the whole project.

Step 4: Accept the PAS request

The provider posts a PAS request Bundle to Claim/$submit. The first entry is a Claim with use set to preauthorization, and every supporting resource is referenced from Claim.supportingInfo. A trimmed Claim looks like this:

{
  "resourceType": "Claim",
  "status": "active",
  "type": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/claim-type", "code": "professional" }] },
  "use": "preauthorization",
  "patient": { "reference": "Patient/pas-pat-001" },
  "created": "2026-09-12T09:58:00Z",
  "insurer": { "reference": "Organization/pas-org-payer" },
  "provider": { "reference": "Organization/pas-org-provider" },
  "priority": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/processpriority", "code": "normal" }] },
  "insurance": [{ "sequence": 1, "focal": true, "coverage": { "reference": "Coverage/pas-cov-001" } }],
  "item": [{
    "sequence": 1,
    "productOrService": { "coding": [{ "system": "https://bluebutton.cms.gov/resources/codesystem/hcpcs", "code": "E0250" }] },
    "servicedDate": "2026-09-15"
  }]
}

Step 5: Return the ClaimResponse

The response Bundle starts with a ClaimResponse. The decision for each item sits in the reviewAction extension, using X12 306 action codes, so the same answer can travel on the 278 rail. This is the approval item from our PAS server's v2.2.1 example:

{
  "itemSequence": 1,
  "extension": [
    { "url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-itemPreAuthPeriod",
      "valuePeriod": { "start": "2026-09-12", "end": "2026-12-11" } },
    { "url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-administrationReferenceNumber",
      "valueString": "ADMREF-PA-2026-0001-1" }
  ],
  "adjudication": [{
    "extension": [{
      "url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-reviewAction",
      "extension": [
        { "url": "number", "valueString": "AUTH-PA-2026-0001-1" },
        { "url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-reviewActionCode",
          "valueCodeableConcept": { "coding": [{ "system": "https://codesystem.x12.org/005010/306", "code": "A1", "display": "Certified in total" }] } }
      ]
    }],
    "category": { "coding": [{ "system": "http://terminology.hl7.org/CodeSystem/adjudication", "code": "submitted" }] }
  }]
}

Step 6: Finish pended requests by subscription, not polling

When the payer cannot decide inside the synchronous window, it returns a pended response (X12 306 code A4) and sends the final ClaimResponse later through a FHIR subscription. The PAS guide says a subscription-based mechanism "SHALL be used by the client" and that $inquire should not be used while waiting for final results. Subscriptions use the R5 backport on R4, only the rest-hook channel, and one subscription per sending system filtered by its organization identifier:

{
  "resourceType": "Subscription",
  "status": "requested",
  "reason": "Notify the requesting provider organization when a pended prior authorization is finalized",
  "criteria": "http://hl7.org/fhir/us/davinci-pas/SubscriptionTopic/PASSubscriptionTopic",
  "_criteria": { "extension": [{
    "url": "http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-filter-criteria",
    "valueString": "org-identifier=1745023006" }] },
  "channel": {
    "type": "rest-hook",
    "endpoint": "https://provider.example.org/pas/notifications",
    "payload": "application/fhir+json",
    "_payload": { "extension": [{
      "url": "http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-payload-content",
      "valueCode": "full-resource" }] }
  }
}

The X12 278 bridge

Most payers will run the FHIR API in front of utilization management systems and delegated vendors that still speak X12, so a FHIR-to-278 translation layer is part of the build even though HHS will not enforce the 278 on an all-FHIR API. The enforcement discretion, the loop-by-loop mapping and where round trips fail are covered in the CMS-0057-F pillar and the PAS guide linked above.

The real engineering challenges

The FHIR interfaces are the smaller part of a Prior Authorization API; the schedule is decided by policy content, delegated vendors, EHR variance, security and the clocks. These are where teams get stuck.

1. Rules that live in documents

CRD can only answer instantly if "does this need approval" is data, and DTR can only pre-fill if the criteria are structured. Most payers keep medical policies and clinical guidelines as PDFs, and prior authorization lists are often maintained separately by line of business. Turning them into computable rules and reviewed questionnaires is continuous work, not a one-time migration, and it needs clinical reviewers as well as engineers.

2. Delegated review vendors

Many plans delegate whole categories (imaging, genetic testing, home health, behavioral health) to review vendors. The plan's API must still answer for them, which means routing each request, getting decisions back inside the clock, and keeping one audit trail. The delegated entity problem is usually the longest lead-time item because it involves contracts, not code.

3. EHR variance

Providers reach the API through their EHR, and EHRs differ in which hooks they fire, how they populate prefetch and how closely they follow the guide version. Epic describes its February 2026 prior authorization APIs as "constructed around the Da Vinci 2.1 FHIR IG, though it does not follow it exactly". From 1 October 2026, certified EHRs move to the 2.2 guides. Expect to test against each major EHR and to run more than one guide version.

4. SMART on FHIR and Backend Services authorization

System-to-system calls use SMART Backend Services (client credentials with signed JWT assertions), and a DTR app launched from the EHR uses the SMART App Launch flow. Getting scopes, key rotation and per-EHR registration right is slow, and every payer's registration process becomes a provider's onboarding cost.

5. Performance under the regulatory clocks

The 72-hour expedited window means the API must stay available and the review pipeline must move within hours. A queue that waits behind a nightly batch job will miss the clock. Most payers need event-driven intake, triage on arrival and a visible clock per request.

FHIR API requirements for 2027: readiness checklist

A payer is ready for 1 January 2027 when every row below has a tested implementation and evidence to show for it. The Prior Authorization API rows are the ones this page covers; the others are linked from the pillar.

Open-source reference servers

Nirmitee publishes open-source CRD, DTR and PAS payer servers, written in Go and .NET, that are tested with ONC's Inferno test kits. They pass every test in the Inferno PAS server suites (84 of 84 for v2.2.1, 68 of 68 for v2.0.1) and the CRD server suites (136 and 86 passes, no failures), and pass the DTR payer server suites apart from two Inferno test-kit issues (one open, one fixed upstream and awaiting deployment).

The code and the session links are public: davinci-crd-server, davinci-dtr-server and davinci-pas-server. Inferno results are the conformance evidence a payer keeps on file. Our CMS-0057-F testing guide shows how to build the same evidence for your own endpoints.

Where Nirmitee fits

Nirmitee builds CMS-0057-F-aligned prior authorization APIs using the HL7 Da Vinci CRD, DTR and PAS guides, tested with ONC's Inferno test kits. The work covers the FHIR services, SMART and Backend Services authorization, the X12 278 bridge, the questionnaire content pipeline that DTR depends on, and the integration with utilization management systems and delegated vendors.

We have passed the Inferno ONC g10 suite on our own FHIR server and run the Da Vinci suites above in public, so every result can be checked before an engagement starts.

Key takeaways

• The CMS Prior Authorization API must list what needs approval, identify documentation, accept requests and return decisions, for items and services, by 1 January 2027.
• CRD, DTR and PAS are recommended, not required, but the X12 278 alone cannot meet the requirement, so the guides are the practical specification.
• Real-time decisions are not required; the 72-hour and 7-day clocks are, and they have applied since 1 January 2026.
• Pended requests finish by subscription, not polling.
• Policy digitization, delegated vendors and EHR variance decide the schedule more than the FHIR code does.

Need help building the Prior Authorization API? Our healthcare interoperability team delivers the FHIR, CDS Hooks and PAS services and the X12 bridge, and our healthcare AI agents practice automates the review work behind them. Talk to our team.

Sources

• CMS Prior Authorization API FAQ (modified 21 September 2026)
• CMS HIPAA transaction enforcement discretion FAQ (modified 21 September 2026)
• CMS-0057-F final rule, 89 FR 8758
• HL7 Da Vinci CRD 2.2.1, DTR 2.2.0 and PAS 2.2.1
• ONC Inferno test kits
• FY 2027 IPPS/LTCH final rule, FR doc 2026-15833