7 Best CMS-0057-F Prior Auth FHIR API Tools 2026

The category decision is how an impacted payer (or a provider connecting to one) will meet CMS-0057-F, not which UM vendor has the nicest nurse portal. The seven tools below are FHIR prior-authorization paths: Da Vinci CRD, DTR, and PAS, plus the operational SLAs that already started. US Tech Automations is not a payer FHIR platform. It is a proposed hold layer after a PAS response exists.

Office-based physicians using EHR: 78%+ according to HIMSS (2024), HIMSS 2024 Health IT Adoption Report. Adoption is high; differentiation is whether prior auth leaves the EHR as FHIR or as a PDF.

Prior-auth SLA: 72 hours / 7 days according to CMS (2024), with those operational provisions generally beginning January 1, 2026. The Prior Authorization API (and the other FHIR APIs in the rule) is due beginning January 1, 2027.

This page is published from the homepage. No vendor paid for inclusion.

TL;DR: Impacted payers must implement Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization FHIR APIs, generally by January 1, 2027. SLAs and denial reasons started January 1, 2026. Da Vinci CRD (is PA required?), DTR (documentation), and PAS (request/response) is the practical IG path CMS encourages. Pick Cohere, Infinitus, Waystar, Availity, Stedi, InterSystems, or Health Samurai based on whether you are a payer building APIs or a provider submitting them.

CMS-0057-F dates that already started

CMS-0057-F is the Interoperability and Prior Authorization final rule. Impacted payers include MA organizations, Medicaid and CHIP FFS, Medicaid managed care, CHIP managed care entities, and QHP issuers on the FFEs. Drugs are generally out of these prior-auth API provisions.

From the CMS fact sheet (Jan 17, 2024):

• Prior Authorization API: implement by January 1, 2027. Must list covered items/services, identify documentation, support request/response, and communicate approve / deny (with reason) / more information.

• Patient Access API: add prior-auth information (excluding drugs) by January 1, 2027; usage metrics to CMS beginning January 1, 2026.

• Provider Access API and Payer-to-Payer API: January 1, 2027.

• Decision timeframes: 72 hours expedited, 7 calendar days standard (excluding QHP issuers on the FFEs for this SLA).

• Specific denial reason regardless of request method: beginning 2026.

• Public prior-auth metrics: first report by March 31, 2026.

• Electronic Prior Authorization measure for MIPS / Promoting Interoperability: clinicians and hospitals attest beginning CY 2027.

HHS also described enforcement discretion for HIPAA X12 278 so a FHIR-only or FHIR+X12 Prior Authorization API can satisfy the rule. That is flexibility, not a reason to skip FHIR.

Adjacent reading: healthcare automation benchmarks, patient follow-up, appointment preparation, and claims inquiry calls.

Da Vinci CRD + DTR + PAS

CMS strongly encourages Da Vinci IGs. CRD, DTR, and PAS: 3 IGs according to HL7 Da Vinci (2026), the practical chain:

• CRD — Coverage Requirements Discovery: is prior auth required?

• DTR — Documentation Templates and Rules: which docs?

• PAS — Prior Authorization Support: request and response.

Recommended IG versions in the fact sheet include Da Vinci CRD STU 2.0.1, DTR STU 2.0.0, and PAS STU 2.0.1, plus FHIR R4.0.1 and US Core STU 3.1.1 as required standards.

Key Takeaways

• SLAs started 1 Jan 2026; APIs are due 1 Jan 2027.

• 72 hours expedited / 7 calendar days standard (with stated exceptions).

• EHR adoption is already high (78%+ office-based); the gap is FHIR PA workflow.

• CRD asks “required?”, DTR asks “which docs?”, PAS carries the request.

• Orchestrate the exception; do not replace the payer API.

How we scored the 7

The 7 FHIR prior-auth tools

Scores from public pages checked 2026-09-06. USTA column is first-party design numbers (1 hold, 1 recipe, 8 gates).

Pricing is quote-led. Example program: 1 payer or 1 specialty group, 4 PA seats, 64 requests/day.

Ask for PAS IG version, SLA clocks, denial-reason fields, and EHR or Patient Access write-back in one quote.

Cohere Health

Best fit: payers (and partners) implementing a FHIR Prior Authorization API, including Cohere Connect as a PAS offering. Limitations: contact vendor; confirm whether Connect is standalone vs bundled UM. Implementation: map CRD/DTR/PAS, SLA clocks, denial reasons. Primary evidence: Cohere Connect public pages. Disqualifier: you only needed a fax OCR.

Infinitus

Best fit: provider organizations chasing prior auth status across payers that are not yet API-complete. Limitations: contact vendor; voice/digital chase is not a substitute for a payer’s 2027 API. Implementation: census of payers still on phone, then a hold when PAS is available. Primary evidence: Infinitus public pages. Disqualifier: you are the payer building the API (see the Infinitus vs Cohere comparison).

Waystar

Best fit: health systems already in Waystar RCM that need PA in the same revenue-cycle stack. Limitations: contact vendor; confirm Da Vinci PAS vs portal. Implementation: map eligible payers, SLA dashboard. Primary evidence: Waystar public pages. Disqualifier: you needed a greenfield FHIR server.

Availity

Best fit: providers and payers already on Availity who need network connectivity, including prior-auth transactions. Limitations: contact vendor; confirm FHIR PAS vs X12 278. Implementation: enrollment, transaction testing, SLA reporting. Primary evidence: Availity public pages. Disqualifier: you needed a standalone FHIR platform.

Stedi

Best fit: teams translating X12 and FHIR and who want a modern clearinghouse. Limitations: contact vendor; confirm CMS-0057-F Prior Authorization API coverage. Implementation: map 278 vs PAS, test pairs. Primary evidence: Stedi public pages. Disqualifier: you needed a UM clinical engine.

InterSystems

Best fit: payers and HIEs building on InterSystems FHIR (IRIS for Health) with CMS-0057-F Q&A already published by the vendor. Limitations: contact vendor; you still own IG conformance. Implementation: FHIR server, SMART, bulk, then PAS. Primary evidence: InterSystems CMS-0057-F Q&A. Disqualifier: you needed a turnkey UM product.

Health Samurai

Best fit: engineering teams building on Aidbox / FHIR platform components. Limitations: contact vendor; not a complete UM department. Implementation: US Core, SMART, PAS resources. Primary evidence: Health Samurai public pages. Disqualifier: you needed a nurse-staffed UM vendor.

Worked queue: 64 auths, 72 hours, 7 days

A payer ops team processing 64 prior-auth requests a day with a 72-hour expedited SLA and a 7-calendar-day standard SLA can treat a FHIR ClaimResponse.outcome as the event that a PAS decision exists and must hit the clock. The 64, 72, and 7 figures are a worked scenario; ClaimResponse.outcome is a real FHIR R4 element. A proposed US Tech Automations path could watch that outcome, pause for a clinician on “error” or missing denial reason, and only then post to Patient Access. Prerequisites: PAS API, unique claim ID, clock, and a human who will catch a missing reason. Configurable capability, not a live payer result. The agentic workflow path is the allowlisted route for that hold.

Zapier plus Make plus n8n can connect a FHIR subscription to Slack and a ticket system and can keep run histories, retries, error branches, and audit evidence when configured. The operator still owns observability, idempotency, escalation, access controls, retention, and PHI. A proposed US Tech Automations design would require the clinical hold before any member-visible denial and write the decision back to the prior-auth record.

Patient Access metrics and MIPS attestation

The 2026 work is not “build FHIR later.” SLAs and denial reasons already apply. Patient Access API usage metrics go to CMS beginning January 1, 2026. The first public prior-auth metrics post is due March 31, 2026. If your PAS project plan starts in Q4 2026, you are late for the operational provisions even if you still have calendar time for the 2027 API.

MIPS eligible clinicians and hospitals get an Electronic Prior Authorization attestation measure beginning CY 2027 (clinicians: 2027 performance / 2029 payment; hospitals: 2027 EHR reporting period). It is yes/no or an exclusion, not a numerator/denominator. Providers who cannot find a payer API will claim exclusions. Payers who cannot expose PAS will hear about it from those providers. Census your top volume payers now: API-ready, 278-only, phone-only.

Drugs stay out of these PA API and SLA provisions. Do not tell a specialty pharmacy that CMS-0057-F “solved PA.” Keep a separate drug path.

PHI belongs in a BAA. Zapier plus Make plus n8n can move tickets, but a prior-auth payload is not a generic webhook. If you cannot sign a BAA and name a clinician for member-visible denials, you should not orchestrate this workflow. The hold described above is a clinical hold, not a marketing automation.

InterSystems and Firely both publish CMS-0057-F explainers; use them as engineering notes, not as a substitute for the fact sheet dates. Firely CMS-0057-F note year: 2026 according to Firely (2026). InterSystems CMS-0057-F Q&A year: 2026 according to InterSystems (2026). Health Samurai and Stedi are platform/translation picks. Waystar and Availity are incumbent RCM/network picks. Cohere and Infinitus split payer API vs provider chase — use a two-product comparison if you have already narrowed to those two.

Name the clinician who owns member-visible denials. Name the engineer who owns IG versions. If either seat is empty, you are buying a slide. If both seats are full and PAS already returns reasons inside SLA, you do not need a third workflow layer. The remaining case is ClaimResponse without a reason, or a clock with no owner.

X12 278 enforcement discretion is flexibility to use FHIR-only or FHIR plus 278, not permission to skip a Prior Authorization API. Stedi-class translation helps if you still have 278 trading partners. It does not replace CRD/DTR/PAS. Availity and Waystar help if you already live in those networks. They still have to show SLA clocks and denial reasons.

Patient Access prior-auth data (excluding drugs) is a 2027 API item and a 2026 metrics item. Do not build PAS in a closet the member app cannot see. Provider Access and Payer-to-Payer are the other two APIs on the same date. A PAS-only project that ignores those two will be reopened in 2027.

Opt-out (Provider Access) and opt-in (Payer-to-Payer) are patient-permission designs in the fact sheet. Put them in the same program as PAS or you will ship an API that counsel has not read. Attribution of patients to in-network providers is also in that Provider Access package — without it, the API has no one to share with.

Who this is for

This shortlist is for impacted payers building CMS-0057-F APIs and for provider IT that must submit electronic prior auth. Stack: EHR or payer core plus FHIR plus UM. Pain: SLAs already on; APIs not.

Red flags: a cash-pay clinic with no prior auth; a payer whose PAS API already meets 2027 IGs with a clinical review; a buyer who will not handle PHI in a BAA.

When NOT to use US Tech Automations

Skip the hold layer when Cohere, InterSystems, or your core already returns PAS decisions with denial reasons and SLA clocks, when you will not connect FHIR subscriptions, or when no clinician will own member-visible denials. The FHIR API is the control. A workflow layer only routes exceptions.

Required standards listed in the fact sheet: 6 on the same CMS fact sheet already cited (USCDI, FHIR R4.0.1, US Core STU 3.1.1, SMART App Launch 1.0.0, Bulk Data 1.0.0, OpenID Connect Core 1.0). That is the floor, not a vendor score.

The final rule also lives at Federal Register 89 FR 8758 according to the Federal Register (2024). Use the fact sheet for dates; use the Register when counsel asks for the citation.

Patient Access metrics start: 1 Jan 2026 on the CMS fact sheet, with the first public prior-auth metrics due by March 31, 2026. Those are operational dates, not API due dates.

Frequently asked questions

When is the Prior Authorization API due?

Beginning January 1, 2027, per the CMS-0057-F fact sheet already cited. SLAs and denial reasons generally began January 1, 2026. Metrics are due by March 31, 2026.

What is Da Vinci PAS vs CRD vs DTR?

CRD asks whether prior auth is required. DTR asks which documentation. PAS carries the request and response. CMS encourages those IGs for the Prior Authorization API.

When should a payer skip a workflow layer?

Skip US Tech Automations when the PAS API already meets SLAs and denial reasons with a clinical review, when you will not connect FHIR, or when no clinician will own member-visible denials. Zapier plus Make plus n8n are enough if your team will own logs, retries, access control, and PHI.

Does this apply to drugs?

The CMS fact sheet repeatedly excludes prior authorization for drugs from these API and SLA provisions. Confirm your drug PA stack separately.

Which of the 7 for a greenfield payer API?

Cohere Connect, InterSystems, or Health Samurai are the usual platform shortlist. Waystar and Availity fit incumbents. Infinitus fits provider chase while payers catch up. Stedi fits translation.

What is the MIPS electronic prior auth measure?

An attestation (yes/no) beginning with the CY 2027 performance period for MIPS eligible clinicians, and the 2027 EHR reporting period for hospitals and CAHs, to request at least one PA electronically via a Prior Authorization API using CEHRT (excluding drugs), or claim an exclusion.

Meet the 2026 SLA, then the 2027 API

Pick a PAS path. Calendar 72 hours / 7 days. Map CRD, DTR, PAS. If you still need a clinical hold between ClaimResponse and member-visible denial, review plan options.