A technical guide to the Prior Authorization API under CMS-0057-F 

The Prior Authorization API is named in the singular, which is misleading. What CMS requires is a set of capabilities:

• Providers need to check whether prior authorization is required
• See what required documentation you need
• Submit requests electronically and get decisions back

The practical path runs through the Da Vinci burden reduction implementation guides (IGs), each with its own architecture, plus an integration into your utilization management system(s) where most of the work currently happens.

Treating these capabilities as separate projects is the mistake to avoid. They share infrastructure, they have conformance requirements between them, and a sequencing decision made for one affects the others. This blog covers what the rule requires, what each IG asks of the payer’s side, and the decisions that cut across all of them.

Which versions apply 

CMS lists two recommended versions for each of CRD, DTR, and PAS: STU 2.0.1 and 2.1.0. All three 2.0.1 releases carry the same expiry footnote that retired US Core 3.1.1 and Plan-Net 1.1.0 on January 1, 2026. So 2.1.0 is the operative version across all three, alongside US Core 6.1.0 and SMART App Launch 2.0.0.

The continuous builds have since moved on to CRD 2.2.1, DTR 2.2.0, and PAS 2.2.1, but those are working drafts rather than published releases. Value sets and code systems are still shifting between releases.

What CMS-0057-F requires

The Prior Authorization API must:

• Be populated/connected with your list of covered items and services (drugs are excluded throughout)
• Identify the documentation requirements for prior authorization approval
• Support prior authorization requests and responses electronically
• Communicate the outcome: approval (including when or under what circumstances the authorization ends), denial with a specific reason, or a request for more information

The API deadline is January 1, 2027. The operational requirements around it are already in force: since January 1, 2026, decisions must go out within 72 hours for expedited requests and seven calendar days for standard ones, denials must carry a reason regardless of submission channel, and prior authorization metrics must be reported publicly.

CMS recommends (but does not currently mandate) the Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), and Prior Authorization Support (PAS) IGs. They’re the practical route to conformance, and the route the rest of the ecosystem is building toward, so the rest of this guide assumes them.

One structural point to consider. In February 2024, the National Standards Group announced enforcement discretion for the HIPAA X12 278: payers implementing a FHIR-based Prior Authorization API won’t face enforcement action for skipping it. An authorization number returned through FHIR can be used in the X12 837 claim, which is what makes an all-FHIR path viable end to end.

So you have three viable architectures: FHIR-only, FHIR with an X12 conversion layer behind it, or X12-only. Which fits depends on how deeply the 278 is embedded in your UM stack, and it’s a decision to make before you build rather than during.

CRD: answering “Do I need prior auth?” in real time

CRD is a real-time decision support service. When a provider places an order or books an appointment, the EHR fires a CDS Hooks call to your CRD server, and you respond with whether the service is covered, whether prior authorization is required, and whether documentation needs to be gathered.

The trigger points are defined hooks rather than a generic call: ‘order-select’, ‘order-sign’, ‘encounter-start’ and others. The current build recommends support for ‘encounter-start’ and ‘order-select’ and flags that either may become a requirement, so it’s worth building for them now rather than retrofitting.

Two things make this architecturally different from anything else in CMS-0057-F:

• It’s synchronous and fast. The response comes back while the provider is working, and the IG’s suggested metrics use five seconds as a benchmark. If determining “does this code under this plan need prior auth” currently involves a human or an overnight process, that logic must become a service.
• It’s fully automated on the payer’s side. If your system can’t produce guidance without human input, no guidance is returned. There is no “we’ll get back to you” in CRD.

Your build is a CRD server that resolves coverage, evaluates your prior auth and documentation rules against the order context, and, when needed, queries the EHR for additional patient data using a token the EHR provides. That last part is worth designing carefully: the more your server determines automatically, the fewer unnecessary forms you send back to providers.

Two things teams tend to miss:

• You don’t get to pick a US Core version. CRD clients need support for only support one of US Core 3.1.1, 6.1.0, or 7.0.0. Servers must handle all three, because clients transition at different times and may send a mixture. Your serverhas to cope with everyone else’s migration schedule.
• A coverage assertion is a commitment. Payers are expected to stand behind non-expired CRD coverage declarations, except where coverage changed outside their control. Each response reflects the coverage position at the time you sent it, and the identifier in the response is what lets you trace what a decision was based on. If your rules are imprecise, you’ll be held to the imprecise answer.

CRD can also answer pre-emptively: if the rules are satisfied, the response can carry an authorization number on the spot, and nobody has to submit a separate request.

DTR: turning documentation requirements into something computable

When CRD flags that documentation is needed, DTR is how the provider gathers it. Your payer service exposes FHIR Questionnaires with embedded Clinical Quality Language (CQL). The provider’s DTR app, either SMART on FHIR or native EHR functionality, retrieves the questionnaire package, runs the CQL against the EHR to pre-populate whatever answers already exist, and prompts the user only for what’s missing.

The payer-side effort here is less about FHIR and more about content:

• Your documentation rules, which today probably live in policy PDFs and reviewer knowledge, must be expressed as structured questionnaires with executable logic. That’s a clinical content authoring effort with its own lifecycle, versioning, and ownership questions.
• Pre-population is the point. A questionnaire with no CQL is a fax form with better transport. The value for providers rests on how much of the form fills itself from EHR data.
• Adaptive forms, where your service determines each question from the answers so far, are powerful and considerably more complex to host. A reasonable path is starting with static pre-populated questionnaires and moving to adaptive where the rules justify it.

One conformance point worth knowing before you design the forms: DTR requires your service to accept any questionnaire response that’s valid against the profile you published. You can’t define a form loosely and then reject what comes back.

PAS: the request itself

PAS carries the prior authorization request and response. The provider system assembles a FHIR Bundle around a Claim resource, including the completed questionnaire response from DTR as supporting information, and submits it. Your side responds with an approval, a denial with a reason, a pended status, or a request for more information.

The implementation questions that matter most:

• The X12 decision from earlier lands here. PAS was designed so the FHIR request can be converted to an X12 278 and back. Under enforcement discretion, you can skip the conversion entirely. Either way, PAS is where the choice becomes concrete.
• Not every decision is instant. PAS supports pended requests, so you need a way to deliver the final decision later, whether by polling or subscription. The clock keeps running either way, so it still has to land inside the 72-hour and seven-day windows.
• The decision doesn’t stop at PAS. Every outcome also has to appear in the Patient Access API within one business day, and in Provider Access and Payer-to-Payer. One decision event, four places it must show up.

Four IGs, one system 

CMS recommends three IGs, but the Da Vinci burden reduction set is four. CDex is the one that completes the workflow: when PAS returns a request for more information, CDex is how you ask, handing the provider a questionnaire to complete through DTR. If your architecture stops at three, the pended path has a gap in it.

Three reasons to plan these together rather than in sequence:

• CRD and DTR share the rules. The logic CRD uses to say “documentation is required” and the questionnaires DTR serves come from the same underlying policy content. Build one rules repository with two consumers, not two encodings of the same policy that drift apart.
• What DTR collects, PAS must accept. This isn’t just good practice, it follows from the DTR conformance point above. If a provider completes the questionnaire your service defined and the resulting PAS submission still comes back needing more information, you’ve built conformant APIs and a broken workflow. Consistency across the IGs needs testing in its own right.
• The UM integration is the most time-consuming piece of work. All four connect to your utilization management system: CRD needs its rules, DTR needs its documentation requirements, PAS needs its adjudication and status events, CDex needs a way to raise a request. If that system is batch-oriented or X12-native, the integration will outweigh the FHIR work, so plan it first rather than partway through the build.

On sequencing, CRD first is the defensible order. It’s the entry point of the workflow, it delivers value to providers on its own, and it forces you to structure your rules content, which DTR then reuses.

What comes next

This is the last of the five APIs in this series, and the one where the compliance build and the business case converge. The same infrastructure that satisfies the rule is what shortens decision times, cuts manual review, and produces the metrics you’re now required to publish.

Worth tracking alongside it: CMS-0062-P, the proposed 2026 rule, would make the recommended IGs required and bring drugs into scope for prior authorization. It’s a proposal, so nothing changes yet, though the IGs themselves already note the expectation that future versions become mandatory. The direction is that those recommendations will become requirements.

If you’re mapping where your CMS-0057-F implementation currently stands, the CMS-0057-F Readiness Checklist covers the Prior Authorization API requirements alongside the other four APIs.

If you’re building on Firely Server, it provides the FHIR foundation for CRD, DTR, and PAS workflows. Get in touch if you want to talk through your situation.