CMS-0057 for Developers: Testing Prior Auth APIs

TL;DR

• CMS-0057-F requires Medicare Advantage, Medicaid, CHIP, and QHP issuers on the FFE to implement CRD, DTR, and PAS FHIR workflows by January 1, 2027.
• CMS estimates the rule will save an estimated $15 billion over ten years by cutting manual prior auth burden (CMS final rule).
• The AMA 2024 prior auth survey reports 94% of physicians say prior auth delays care, and 24% report it led to a serious adverse event.
• Testing against realistic CRD cards, DTR CQL, and PAS profile validation is what separates a passing implementation from one that works with real payers.

What CMS-0057 actually requires

The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) mandates that Medicare Advantage, Medicaid, CHIP, and FFE QHP payers implement three FHIR prior auth workflows by January 1, 2027. These are regulatory requirements with enforcement behind them.

The three workflows:

1. Coverage Requirements Discovery (CRD): the EHR sends a CDS Hooks request when a provider orders a service. The payer responds in real time with whether prior auth is needed, what documentation is required, and coverage status.

2. Documentation, Templates, and Rules (DTR): if documentation is needed, DTR serves FHIR Questionnaires that the provider or agent fills. Questionnaires can be pre-populated from the patient's record using CQL expressions.

3. Prior Authorization Support (PAS): the submission. Instead of faxing or navigating a portal, the provider submits a FHIR Bundle containing Claim, supporting documentation, and questionnaire responses. The payer returns approval, denial, or pend.

Together, these replace the current process (phone, fax, portals, days of waiting) with a FHIR exchange that can complete in seconds.

The timeline

• January 1, 2026: Payers must implement the Patient Access API and begin reporting prior auth metrics.
• January 1, 2027: Payers must implement CRD, DTR, and PAS. Providers must be able to use them.
• Ongoing: Payers must respond within 72 hours for urgent cases and 7 days for standard cases, down from an industry average of 14+ days.

As of April 2026, you have 9 months. Payer teams should be deep in implementation. Provider and health tech teams need to be testing now.

"The Prior Authorization Final Rule is a critical step in streamlining prior authorization processes and reducing burden on providers, so they can spend more time on patient care."

-- Chiquita Brooks-LaSure, former CMS Administrator (CMS press release)

What developers actually need to build

For payer-side teams

Three API surfaces:

CRD endpoint. A CDS Hooks service accepting order-sign and order-select hooks. It receives FHIR context (Patient, Coverage, the ordered ServiceRequest or MedicationRequest) and returns CDS Cards indicating auth requirements, documentation needs, and links to DTR questionnaires.

The hard part is not the API. It is the decision logic. CRD must evaluate coverage rules against the patient's plan, the ordered service, and clinical context.

DTR questionnaire service. A FHIR Questionnaire repository that serves adaptive questionnaires with CQL expressions for pre-population. The hard part is CQL evaluation. Your questionnaires need CQL that correctly references FHIR resources to pre-fill diagnosis codes, medications, and observations.

PAS submission endpoint. A FHIR operation ($submit) that accepts a Bundle with Claim (profiled as PAS Request), supporting DocumentReferences, and QuestionnaireResponses. You process the submission and return a ClaimResponse.

The hard part is mapping your existing adjudication logic to PAS FHIR profiles. The Da Vinci PAS IG defines specific profiles. Your rules engine probably speaks X12 278, not FHIR.

For provider-side teams and agent builders

Client side:

1. CDS Hooks client: fire a hook to the payer's CRD endpoint on order create. Parse response cards. Display or act on auth requirements.

2. DTR client: fetch the payer's questionnaire, evaluate CQL against the FHIR record, pre-fill answers, present remaining questions to the clinician or agent, submit the QuestionnaireResponse.

3. PAS client: construct the PAS Bundle, submit via $submit, handle the synchronous response, and handle async updates via polling or subscriptions.

For agent builders, the opportunity is enormous. An agent handling the full CRD-DTR-PAS flow eliminates hours of manual work per authorization. For common failure modes, see how prior authorization agents fail.

Why testing against real payer behavior matters

You can build a technically correct CRD/DTR/PAS implementation that fails against every real payer.

Payer implementations will vary. The Da Vinci IGs provide a standard, but payers implement differently. One CRD response includes detailed documentation requirements in the cards. Another returns a generic "prior auth required" with a link. One DTR questionnaire has 5 questions. Another has 40.

Error handling is where agents fail. What happens when the CRD endpoint is down? When DTR CQL cannot be evaluated against the patient's record? When PAS returns a pend and the payer never updates?

Data shapes matter. The PAS Claim profile requires specific extensions and slices not in base FHIR. CoverageEligibilityRequest needs the correct plan identifiers. QuestionnaireResponse must reference the exact canonical URL. Off-by-one profile conformance errors cause silent failures.

Testing against a HAPI server that accepts anything tells you nothing, as we discuss in the FHIR sandbox problem. Testing against a server that enforces PAS profiles, serves realistic DTR questionnaires, and returns CRD responses matching real payer behavior tells you whether your code works.

How sandbox environments help meet the deadline

With 9 months left, you do not have time for a 6-month EHR integration cycle followed by 3 months of debugging. You need to test full CRD-DTR-PAS workflows now.

A purpose-built sandbox for CMS-0057 provides:

• CRD endpoints returning realistic card payloads based on service type and coverage. Some require auth. Some do not. Some require documentation.
• DTR questionnaires matching real payer complexity. Short forms for routine services, long forms for complex procedures, with CQL pre-population.
• PAS endpoints validating against PAS IG profiles and returning realistic responses: approvals, denials with reason codes, pends with polling URLs.
• Synthetic patients with the coverage, conditions, and clinical history needed to exercise each pathway.

This lets you test the full workflow in days, not months.

A concrete testing checklist

CRD:

• Handles order-sign and order-select hook types
• Correctly parses CDS Cards with multiple suggestions
• Handles payer endpoint timeouts (CRD has a 5-second response expectation)
• Processes "no prior auth needed" responses correctly

DTR:

• Retrieves and renders adaptive questionnaires
• Evaluates CQL expressions against the patient's FHIR record
• Handles missing data gracefully (CQL returns null for absent resources)
• Submits QuestionnaireResponses with correct references

PAS:

• Constructs Bundles conformant to PAS IG profiles
• Handles all three response types: approved, denied, pend
• Implements polling for pended requests
• Processes ClaimResponse reason codes and communicates them clearly

End-to-end:

• Full CRD to DTR to PAS flow completes for at least 10 service types
• Agent handles the "no prior auth needed" path without submitting unnecessarily
• Agent recovers from failures at each step without losing state (see our four-layer testing framework)

Key Takeaways

• CMS-0057-F is a regulatory requirement with a January 1, 2027 deadline for CRD, DTR, and PAS.
• CMS projects $15B in ten-year savings from reduced prior auth burden.
• The hard engineering is not the FHIR plumbing. It is coverage decision logic for CRD, CQL evaluation for DTR, and mapping X12 278 adjudication to PAS profiles.
• Testing against a permissive HAPI server gives false confidence. Use a sandbox that enforces PAS profiles.
• Build against synthetic patients that exercise each decision pathway: auth-required, no-auth, missing-docs, and pended.
• With 9 months left, prioritize end-to-end CRD to DTR to PAS runs over unit tests of each layer.
• Error handling (timeouts, null CQL, indefinite pends) is where most real implementations break.

FAQ

Who exactly must comply with CMS-0057?

Medicare Advantage plans, state Medicaid FFS programs, Medicaid managed care plans, CHIP FFS and managed care, and QHP issuers on the Federally Facilitated Exchanges. Commercial non-FFE payers are not required but many are implementing for alignment.

What happens if a payer misses the January 2027 deadline?

CMS has enforcement authority. Consequences include CMP assessments and compliance actions. Payers in Medicare Advantage face additional program integrity scrutiny.

Can I test DTR without building full CQL evaluation?

You can start with questionnaires that have no CQL pre-population to validate the request-response plumbing, but real CQL is where most implementation bugs live. You need a sandbox with CQL-aware questionnaires to test meaningfully.

How does CMS-0057 interact with the existing X12 278 prior auth transaction?

Payers may continue to support X12 278 alongside FHIR PAS. Providers can choose. Over time, FHIR is expected to dominate for new implementations, but legacy X12 support persists, especially for non-CMS-regulated payers.

Getting started

If you are building prior auth workflows and need realistic CRD, DTR, and PAS endpoints to test against, book a demo.