A practice administrator forwarded us a vendor proposal last week for a prior authorization platform. The pitch leaned on one sentence: "Payers are required to support electronic prior authorization APIs by January 2027, and our platform is ready." The price was a per-provider monthly fee plus a per-transaction charge. The administrator wanted to know whether the 2027 deadline meant the software would make authorizations automatic.
It will not, and it is worth being precise about why, because the deadline is real and the technology behind it is a genuine improvement. The problem is the gap between what the rule requires of payers and what a practice will experience, and that gap is where vendor claims live.
Key takeaways
- CMS-0057-F requires Medicare Advantage, Medicaid, CHIP and federal marketplace plans to offer FHIR prior authorization APIs by January 1, 2027; employer plans and traditional Medicare are not covered.
- The APIs only help if your EHR or a platform calls them at the point of ordering, so your EHR vendor's 2027 roadmap matters more than any payer's.
- The APIs remove phone calls and portal hunting; they do not remove clinical review, documentation or denials.
- Buy on the payer connectivity list and the EHR integration method, not on the deadline.
- For most independent practices in 2026, a disciplined log and per-service documentation templates come first; a platform is a later decision.
What the rule requires, and of whom
CMS-0057-F requires impacted payers to implement three APIs by January 1, 2027, built on the HL7 FHIR standard. The Prior Authorization API must let a provider's system find out whether a service requires authorization, what documentation the payer needs, submit the request, and receive the decision and status electronically. The Provider Access API gives a provider access to the payer's claims, encounter and clinical data for attributed patients. The Payer-to-Payer API moves a patient's data between plans when they switch. The decision timeframes and denial reason requirements that started January 1, 2026 apply to the same payers.
The impacted payers are Medicare Advantage organizations, Medicaid and CHIP fee-for-service and managed care, and qualified health plans on the federal marketplaces. Not employer-sponsored commercial plans. Not traditional Medicare. Not plans on state-based marketplaces. For a practice whose payer mix is mostly commercial employer coverage, the 2027 deadline binds a minority of authorizations. Some commercial payers will build the same APIs voluntarily, and the June 2025 insurer pledge included a commitment to standardized electronic prior authorization by 2027, but a pledge is not a deadline.
The other half of the connection is your EHR
An API on the payer's side is only useful if something on your side calls it. The workflow the standards describe (the Da Vinci coverage requirements discovery, documentation templates and rules, and prior authorization support implementation guides) is meant to run inside the EHR at the point of ordering: the physician orders an MRI, the system asks the payer whether authorization is needed, pulls the documentation requirements, pre-fills what it can from the chart, and submits. That requires your EHR vendor to build and certify the connection. Some large EHRs are building it. Many smaller ones have announced nothing. Ask your EHR vendor directly what it will support by January 2027 and get the answer in writing.
A third-party authorization platform can sit between the EHR and the payers and call the APIs itself. That is a legitimate architecture. But it means the platform needs access to your clinical data to populate requests, and how it gets that access (a real integration or a staff member copying and pasting) is the question that decides whether it saves time.
Some history explains our caution. An electronic prior authorization transaction has existed since the HIPAA transaction standards were adopted: the X12 278 request and response. It has been mandated for payers for two decades and almost nobody uses it, because most payers implemented it as a bare acknowledgment with no way to attach documentation and no meaningful status, and most practice systems never built a screen for it. The FHIR APIs in CMS-0057-F are a better design, particularly because they carry documentation requirements and attachments, and the rule enforces them on the payer side with real deadlines. But the lesson of the 278 is that a mandated transaction does not become a working workflow until both ends build for it and someone pays for the integration. Assume that will take longer than January 2027 for many payers, and longer still for the ones the rule does not touch.
What a platform actually costs
Read the proposal with a calculator. A per-provider monthly fee plus a per-transaction charge is the common structure, and the second number is the one that grows. A practice with eight providers submitting 350 authorizations a month at an illustrative $4 per transaction is paying $1,400 a month in transaction fees before the per-provider fee, or roughly $17,000 a year. If the platform is really doing portal automation for your top payers and fax for the rest, the practice has bought a tracking database with a robot that breaks whenever a portal changes. If it is submitting through real electronic transactions to the payers that generate most of your requests, and pulling the documentation from the EHR without a staff member re-keying it, the same money may be replacing most of a full-time coordinator's hold time. The pricing is the same in both cases; the value is not, and only the connectivity list tells you which one you are buying.
What the APIs will and will not change
| Question | What changes in 2027 | What does not |
|---|---|---|
| Does this service need authorization? | Answerable electronically from impacted payers at order time | Commercial employer plans may still require a portal lookup |
| What documentation is needed? | Payer returns requirements electronically | The clinician still has to have documented it |
| Submitting the request | Electronic submission with structured data and attachments | Incomplete requests still pend; the clock still starts on completeness |
| Getting the decision | Status and decision returned to the system | Medical necessity review is still a human or a payer algorithm making a judgment |
| Denials | Specific reason required since 2026 | The appeal is still written by your staff |
The honest summary is that the APIs remove the phone calls and the portal hunting. They do not remove the clinical review, the documentation burden or the denials. A vendor who says otherwise is selling.
Questions to ask a vendor
- Which payers are connected today through a real electronic transaction (the X12 278 or a FHIR API), which through portal automation, and which by fax? Ask for the list with your top ten payers marked.
- How does the platform get clinical data from our EHR? Name the integration method. If the answer is that staff upload documents, it is a tracking tool, not an automation tool.
- What happens when a payer changes its portal? Portal automation breaks; ask how often and who fixes it.
- What is the pricing when authorization volume rises? Per-transaction fees look small until they are not.
- Can we export our complete authorization history, including submission timestamps and decision dates, if we leave? That log is your evidence for payer compliance with the 2026 timeframes.
- Does the platform report turnaround by payer against the regulatory standards? If not, you will build that spreadsheet yourself.
- Which of our payers will the platform reach through the 2027 APIs, and what happens for the rest?
What we recommend
For most independent practices in 2026, the right investment is a disciplined tracking process (a log with submission timestamps, due dates and outcomes, and documentation templates per service) rather than a platform. Get that working first; it costs almost nothing and it is what the platforms automate. Then, when your EHR vendor confirms what it will support in 2027, evaluate whether a platform adds enough on top of the EHR's native connection to earn its fee. Practices with very high authorization volume, such as imaging, infusion or surgical specialties, may justify a platform sooner. Even then, the payer connectivity list is the thing to buy on, not the deadline.
Our denial management team runs authorization tracking for practices using exactly the log described above, and our technology team reviews vendor proposals for practices that want a second opinion before signing. The Revelrex EHR training environment is where we teach new staff the authorization workflow before they touch a live system.
Questions we hear
Will the 2027 APIs let us see whether an authorization is needed before the patient leaves the exam room?
For impacted payers, yes, if your EHR implements the coverage requirements discovery step at order entry. That is the most useful piece of the whole rule for a practice, and it is the piece most dependent on your EHR vendor. Ask them about it specifically.
Is there a MIPS incentive for electronic prior authorization?
The rule added an electronic prior authorization measure to the MIPS promoting interoperability category, beginning with the 2027 performance year. It is an attestation-style measure and its weight is modest, so it is a reason to be ready, not a reason to buy software in 2026.
Our EHR vendor says it will be "ready for CMS-0057-F". What does that mean?
Ask three questions in writing. Will the EHR query payers for authorization requirements at order entry, and for which payers at go-live? Will it submit the request with attachments from inside the chart, or hand the user a link to a portal? And is the capability included in the current license or sold as a module? "Ready" has meant all three of those things in vendor answers we have read, and the difference between them is whether your staff's work changes at all in 2027.
What to do this month
- Build or clean up the authorization log with submission timestamps, due dates, decision dates and outcomes, and start the monthly turnaround report by payer.
- Write documentation templates for the ten services you request most often, using each payer's medical policy as the checklist.
- Ask your EHR vendor, in writing, what prior authorization functions it will support by January 2027 and for which payers.
- If a vendor proposal is on the table, send them the seven questions above and score the answers before any demo.
- Rank your payers by authorization volume and mark which are covered by the 2027 deadline and which are not; that list is your negotiating position with any platform.
