FHIR Prior Authorization APIs: Payer Requirements and Provider Integration Questions
Understand the payer API requirements, separate provider reporting measures, and verify what your payer and EHR partners can support before planning an integration.
CMS-0057-F places API requirements on specified payers and introduces separate provider program measures. It does not establish a universal January 1, 2027 deadline for every practice to build its own API. CMS-0057-F final rule
This guide provides a questionnaire for evaluating an integration. Regulatory and technical source status was checked on October 6, 2026.
1. Separate the payer requirement from the provider's work
CMS-0057-F requires impacted payers to support prior authorization functions for medical items and services, excluding drugs, through an API. Those functions include identifying requirements, exchanging requests and documentation, and communicating responses. API compliance dates generally begin in 2027, with applicability depending on payer type. CMS-0057-F final rule
For the practice, separate two decisions. First, the program reporting owner should establish which electronic prior authorization measure, if any, applies to the organization or its clinicians. Second, the technical and operations owners should determine which payer connections are useful and available.
As of the source check, CMS describes the hospital and critical access hospital measure change as finalized: optional for CY 2027 and mandatory beginning CY 2028. The analogous MIPS timing change appears in the 2027 QPP proposal and should not be treated as finalized. CMS electronic prior authorization overview and 2027 QPP proposed-rule fact sheet
Keep those program questions in the provider operations readiness checklist. The integration questionnaire below establishes what a connection can do. It is not a substitute for a program applicability determination.
2. Name the actors, scope and interface
Draw a short path from the person initiating the request to the payer receiving it. Include the EHR, any connected application or intermediary, and the system where staff will see the response. Assign an owner to each handoff.
Then give the connection a precise scope. Record the payer product, supported service categories, environment, authentication arrangement, interface version and available transactions. A phrase such as "FHIR enabled" leaves too many operational questions unanswered.
FHIR supports adaptation through profiles and extensions, and HL7 notes that healthcare implementations may require local agreements. HL7 FHIR overview. Ask the vendors to identify the implementation guides and versions they use, along with any constraints that matter for your workflow.
CMS's standards FAQ distinguishes required standards from recommended implementation guides. It states that the recommended guides in the final rule's Table H3 are not required by that rule at this time. It also identifies proposed changes under CMS-0062-P. CMS standards and implementation guides FAQ. Do not equate the newest published guide with a universally required production version.
This is a technical scope exercise, not a request for every administrator to implement the standard. The practice needs an answer it can verify and an owner who can explain the implications.
3. Ask four separate capability questions
Use four questions to structure the vendor conversation. They describe business functions, not a claim that every implementation follows an identical sequence.
Can the system discover the applicable requirements? Ask how the response is linked to the member, coverage and requested service. Ask how the interface distinguishes an explicit answer from an unavailable or incomplete result. The staff display should preserve that distinction.
Can it assemble the documentation requested for this case? Identify what information can be drawn from the clinical record, what needs additional input and who reviews the result before submission. Test whether staff can see the source of populated information and correct an error through the approved workflow.
Can it submit the request and preserve evidence of receipt? Ask what event means the local system sent the request, what proves the payer received it, and how the request reference is retained. These are different questions from whether the payer has reached a decision.
Can it return a useful response to the right workflow? Demonstrate how staff see an approval, denial or request for more information, with the relevant details and next action. CMS's required response functions include those outcomes; an API connection should not be described as a guarantee of approval. CMS-0057-F final rule
For the broader operational context, see electronic prior authorization explained. To see how Linear Health handles the handoffs around your prior authorization process, book a demo.
4. Use an integration questionnaire that produces evidence
The following questionnaire is an original operating template. Complete it with the vendors involved and keep their answers alongside the test record.
| Question and data contract to confirm | Supported transaction to demonstrate | Environment and observed result to retain | Accountable owner | Unresolved issue to record |
|---|---|---|---|---|
| Which member, coverage and service identifiers define the request? | Requirements inquiry for the intended payer product | Test environment, identifiers used and actual response | Payer integration lead | Unsupported product, ambiguous match or missing response |
| Which fields and documents are needed, and where does each originate? | Documentation assembly and staff review | Sample case, populated fields and items still requiring input | EHR or application lead | Missing data or unclear source |
| What proves receipt and links the response to the request? | Submission and subsequent retrieval or response handling | Request reference, event times and observed state | Integration lead | Unconfirmed delivery or unmatched response |
| Which response details reach the staff worklist? | Each supported decision or information-request outcome | Exact visible result and required next action | Authorization operations lead | Lost detail or unclear assignment |
| Which record is updated, by whom and with what permission? | Approved writeback or documented manual update | Destination record, test result and audit evidence | EHR owner | Unavailable field or unsuccessful update |
Do not fill the "observed result" column from a sales presentation. A roadmap statement can be valuable, but it belongs in a separate availability record with the date and the person who supplied it.
Review the questionnaire jointly. A connection may satisfy a technical exchange test while leaving the authorization coordinator without a usable work item. Conversely, a well-designed staff screen does not demonstrate that the request reached the intended payer.
5. Test outcomes, delays and unavailable functions
Build a small set of test cases that exercises the agreed scope. Use data approved for the test environment. Include a straightforward supported request, a request requiring more information, an unsupported case and a delivery problem.
For each case, have the team explain the result using the evidence on screen. Can staff identify the request? Can they distinguish an unsuccessful exchange from a payer decision? Can they see who should act next? The purpose is to discover ambiguity before relying on the workflow.
CMS clarifies that a coverage-requirements check is not itself submission of a prior authorization request. It also states that the final rule does not require real-time authorization decisions. CMS prior authorization process FAQ. Those distinctions should remain visible in the test cases.
Ask technical partners whether conformance testing is appropriate. The HealthIT.gov Inferno tools provide separate test kits for Coverage Requirements Discovery, Documentation Templates and Rules and Prior Authorization Support. At the source check, these kits were labelled draft and low maturity. The hosted service prohibits sensitive data and protected health information. Passing a selected kit should therefore be recorded for its specific scope, not presented as proof of a complete production workflow or regulatory compliance.
Where a function is unavailable, document the current payer-supported process, the person responsible and how the result returns to the practice's record. Do not remove an existing channel merely because a future API capability has been announced.
Clinical interpretation and decisions about urgency or appeals need the appropriate clinical or authorized owner. Keep those responsibilities explicit when deciding which administrative steps can be automated.
6. Keep a change register after the pilot
An integration record should survive the first successful transaction. Retain the payer product, vendor release, interface and guide versions, environment, date tested, accepted functions and unresolved issues.
When a vendor changes a function, identify the affected cases and repeat the relevant tests. When a policy source changes, have the responsible program owner assess the requirement before altering the workflow.
Track drug-related developments separately. CMS's April 2026 interoperability and drug prior authorization document remained a proposal at this source check. CMS-0062-P proposed-rule fact sheet. A proposal should not silently expand the scope of a connection documented for non-drug services.
For a wider assessment of staffing, exception ownership and vendor responsibilities, use our prior authorization automation guide. When your questionnaire is complete, book a demo and we will walk through it with you.
Before Linear, I needed five systems just to get a patient from referral to appointment. Now I have one screen. The team is coordinating care instead of chasing it.
Frequently asked questions
What is a FHIR prior authorization API?
What should we ask our EHR vendor?
How do we verify that requests and responses work?
Will an API remove all staff work?
What should we do when a required function is unavailable?
Sources
Sources accessed October 13, 2026. CMS pages describe CMS's own rules, FAQs and program materials; HL7 and HealthIT.gov pages describe the standard and its test kits as published by those organizations.
- HL7: Introducing FHIR, Release 4
- Federal Register: CMS-0057-F final rule
- CMS: Electronic Prior Authorization
- CMS: 2027 QPP Proposed Rule Fact Sheet and Policy Comparison Table
- CMS: Standards and Implementation Guides, FAQs
- CMS: Improving Prior Authorization Processes, FAQs
- HealthIT.gov: Da Vinci Coverage Requirements Discovery Test Kit
- HealthIT.gov: Da Vinci Documentation Templates and Rules Test Kit
- HealthIT.gov: Da Vinci Prior Authorization Support Test Kit
- CMS: 2026 Interoperability Standards and Prior Authorization for Drugs Proposed Rule