CMS-0057-F for prior-auth agent companies: what changes January 1, 2027, and how your agent should sign in

The short version

• The rule. CMS-0057-F, the CMS Interoperability and Prior Authorization final rule, was published on February 8, 2024 (89 FR 8758).
• January 1, 2026. Impacted payers had to start answering prior auth requests within 72 hours for urgent requests and 7 calendar days for standard ones.
• January 1, 2027. They must run four FHIR APIs, including a Prior Authorization API that software can call to ask whether an item needs prior auth, gather the documentation and submit the request.
• Your agent's sign-in. If you build an AI agent that does prior auth, that API is the front door, and it will ask how your software signs in. A clinician's borrowed login doesn't answer that well.
• Start now. Register with each payer, use your own keys, and keep a record of which agent acted for whom and why.

This guide covers what the rule requires, what a payer's prior auth API looks like, how outside software gets in, and a checklist for the weeks before January 1.

What CMS-0057-F requires, from whom, and when

The rule applies to these "impacted payers," according to the CMS fact sheet:

• Medicare Advantage organizations
• state Medicaid and CHIP fee-for-service programs
• Medicaid managed care plans and CHIP managed care entities
• issuers of Qualified Health Plans on the Federally-Facilitated Exchanges

Commercial employer plans aren't directly covered.

Requirement	What it means	Date
Prior auth decision times	72 hours for expedited (urgent) requests and 7 calendar days for standard requests. QHP issuers on the FFEs are excluded.	January 1, 2026
Public prior auth metrics	Payers post approval, denial and timing metrics on their websites every year	First report by March 31, 2026
Patient Access API	Adds prior auth information (not drugs) to what patients can already pull	January 1, 2027
Provider Access API	In-network providers with a treatment relationship can pull a patient's data. Payers keep an attribution process, and patients can opt out.	January 1, 2027
Payer-to-Payer API	Data follows the patient when they change plans	January 1, 2027
Prior Authorization API	Software can find out whether prior auth is needed, see the documentation requirements, submit the request and get the decision back, including a reason for any denial	January 1, 2027

Two limits matter for agent builders:

• Drugs are excluded. The prior auth provisions don't apply to drugs, so a pharmacy prior auth agent is outside this API.
• The implementation guides are recommended, not required. CMS "strongly encourages" payers to use the HL7 Da Vinci guides described below. In practice most payers build to them, but check each payer's developer documentation.

What a payer's prior auth API looks like

The Prior Authorization API is usually built from three HL7 Da Vinci implementation guides, which map onto the steps of a prior auth:

1. Coverage Requirements Discovery (CRD). At the moment of ordering, the system asks the payer whether this item or service needs prior auth for this patient, and what documentation it needs.
2. Documentation Templates and Rules (DTR). The payer returns a questionnaire with its rules. Much of it can be filled in automatically from the chart, and a person completes the rest.
3. Prior Authorization Support (PAS). The request is submitted as a FHIR bundle (the Claim/$submit operation), and the payer answers with a decision, a pended status or a request for more information. PAS maps to the X12 278 transaction that clearinghouses already handle.

The guides assume the EHR drives CRD and DTR at the point of care. An agent that does the work for the clinic usually comes in from the side: it reads the chart, fills in the documentation and submits through PAS.

How outside software gets in

Every payer API asks the caller who it is and what it may do before it returns a byte. Three standards answer that question for software that isn't a person in a browser.

SMART Backend Services

SMART Backend Services is the HL7 profile for system-to-system access with no user at the keyboard. It works in four steps:

1. You register a client with the payer ahead of time and give it your public key.
2. Your software signs a short JWT with the matching private key.
3. It trades the JWT for a short-lived access token.
4. It uses that token on the API.

The rule's list of required standards includes SMART App Launch and OpenID Connect, per the CMS fact sheet.

The gap for agents: the token says which client called. It says nothing about which agent within that client was calling, which clinician it acted for, or why.

UDAP (HL7 FAST Security)

The UDAP Security implementation guide adds three things on top:

• Certificates from a trust community. A payer can trust a client because a known authority vouches for it, not because someone emailed a key.
• Dynamic client registration. Software can register itself with a signed statement instead of going through a manual review at every payer.
• The B2B extension. It lets the token request carry the organization, the person making the request and the purpose of use.

That last one is the closest any healthcare standard comes to saying "this software is acting for this person, for this reason." It still has no field for the agent itself.

TEFCA

TEFCA is the national exchange framework. Its Facilitated FHIR Implementation SOP requires FHIR adopters to follow the HL7 UDAP Security guide from January 1, 2026, according to HL7's summary of the requirement. If your agent exchanges data through TEFCA, it needs a UDAP-capable client.

Registration is per payer

Each payer runs its own authorization server and reviews its own clients. An agent company that works with 40 payers and 50 hospitals is looking at roughly 90 separate registrations, each with its own keys and review. UDAP's dynamic registration and trust communities help where payers support them.

Why borrowed logins and shared accounts fail

Agents that call payer and EHR systems usually sign in one of two ways:

• A clinician's login. The log says the doctor did it.
• A shared service account. The log says "the vendor" did it, and nobody can tell which agent or which task.

Both are common. In a survey of 250 US healthcare leaders (Imprivata, run by Vanson Bourne, September 2026), 35% said their agents operate under a clinician's delegated credentials. Another 16% said they use generic or shared service accounts.

Two parts of the HIPAA Security Rule make both setups hard to defend. It requires a unique name or number to identify and track each user's identity, and audit controls that record activity in systems with patient data.

A hospital security review asks the same questions in plainer words:

• Which agent touched which patient?
• Who was it acting for?
• Who approved it?
• Can you show me?

With borrowed or shared credentials, the honest answers are bad ones.

What to do before January 1, 2027

1. List the payers your customers need, and find each one's developer portal, endpoints and registration process. Some are live, some are late, and they don't all register clients the same way.
2. Get your own client registration at each one. Don't route through a clinician's account. Prefer UDAP where the payer supports it, and SMART Backend Services everywhere else.
3. Keep keys out of your agents. Private keys belong in a key management service. Agents should get a short-lived token for one call, not a long-lived secret.
4. Name the agent, the person and the purpose on every call, at least in your own records. Use UDAP's B2B fields where the payer reads them.
5. Put a person in front of risky actions. Submitting a prior auth or an appeal should wait for a staff member's approval, and the record should show who approved.
6. Keep an audit trail you can hand over: agent and version, the clinic and clinician it acted for, purpose, patient (tokenized), action, approver, result and time. Make it append-only.
7. Get a BAA in place with anyone in the path who touches patient data.
8. Plan for late APIs. Keep X12 278 through a clearinghouse as a fallback for payers that aren't ready.

Questions agent builders ask

Does CMS-0057-F apply to my company?

Not directly. It regulates payers. It matters to you because it decides what the payer's front door looks like and when it opens.

Do payers have to use the Da Vinci guides?

No. CMS recommends CRD, DTR and PAS but doesn't require them. Most payers are building to them anyway, so check each payer's documentation.

Can my agent use the clinic's existing payer portal login?

It can work technically, but the payer's log will say a person did what your agent did. That's the first thing a hospital security reviewer will ask about.

What about drug prior authorizations?

They're excluded from the CMS-0057-F prior auth provisions. Drug prior auth still runs through the pharmacy channels and their own standards.

Sources

• CMS, Interoperability and Prior Authorization Final Rule (CMS-0057-F) fact sheet, January 17, 2024.
• Federal Register, 89 FR 8758, February 8, 2024. The rule took effect April 8, 2024.
• CMS, CMS-0057-F overview page.
• HL7 Da Vinci implementation guides: CRD, DTR, PAS.
• HL7, SMART App Launch: Backend Services.
• HL7, UDAP Security for Scalable Registration, Authentication, and Authorization.
• HL7, FAST Security now part of TEFCA and HTI-2 requirements, July 17, 2024.
• 45 CFR § 164.312, HIPAA Security Rule technical safeguards.
• HIT Consultant, Imprivata report on agentic AI in healthcare, September 15, 2026.