A request goes out. The payer asks for one more document. That response lands somewhere the person who submitted the request is not watching.
The electronic exchange worked. The patient's care is still waiting.
This is an illustrative situation, not a customer story. It explains why we think practices should ask two separate questions about prior authorization: can the software exchange the information, and can the team see who needs to do something next?
In brief
New payer connections matter. But a connection does not assign the next task, gather missing information or tell the patient what happens next. Before evaluating an electronic prior authorization tool, follow one request through the entire workflow, including the moment a payer asks for more information.
What changes in 2027, and what already changed
CMS's Interoperability and Prior Authorization final rule, CMS 0057 F, sets requirements for specified payer groups. These include Medicare Advantage organizations, state Medicaid and CHIP programs and managed care plans, and qualified health plan issuers on the federal exchanges. It is not a requirement covering every insurer or every authorization.
The rule has two different timelines. Certain operational requirements generally began January 1, 2026. The API requirements generally begin January 1, 2027, with exact compliance dates varying by payer type. Treating these as one deadline makes a vendor conversation less useful.
Under the rule, a payer's Prior Authorization API must identify covered items and services and their documentation requirements, and support requests and responses. A response can be an approval, a denial with a specific reason, or a request for more information. An approval must communicate when, or under what circumstances, the authorization ends.
This rule excludes drug prior authorizations. A practice should not assume that a connection built for medical items and services also handles a medication request. Ask about each workflow separately.
For the covered operational provisions, impacted payers other than qualified health plan issuers on the federal exchanges must send decisions within 72 hours for expedited requests and seven calendar days for standard requests. A required response window is not a promise that every request will be approved, nor proof that a particular payer connection is available in your software today.
CMS also requires specific reasons for denials under the rule beginning in 2026, regardless of how the request was sent. That makes the response more useful. Someone still needs to read it and decide the next step.
Start with the response, not the submit button
When evaluating a tool, it is tempting to begin with how quickly a request can be sent. We would start with a harder question: show us what happens when the request comes back incomplete.
Use a synthetic case. Ask the vendor to demonstrate a payer response requesting a missing document. Then follow it through the practice's work queue.
Can the team identify the request and patient without reconstructing the history? Is the missing document named? Does a person own the next task? Is there a due date or another clear way to see how long it has been waiting? Can another team member take over without starting again?
These are workflow questions, not claims that regulation requires a particular interface. They matter even when the response arrives by portal or fax rather than an API.
A denial needs a different path. The team should see the payer's stated reason and the original request together. Clinical decisions about changing treatment, supplying more evidence or pursuing an appeal belong with the responsible clinician and team. Software should make that work visible, not quietly treat the denial as the end of the story.
A small handoff checklist
| Point in the request | What the team should be able to see |
|---|---|
| Before submission | Which workflow and payer are supported, and which documents are required |
| After submission | Confirmation that the request was received and who watches for a response |
| More information requested | What is missing, who supplies it and when the next review happens |
| Approved | The authorization details and any stated expiry or end condition |
| Denied | The specific reason and the person responsible for deciding the next step |
This checklist is a proposed evaluation method. It is not a description of every feature currently available in Thyra.
What we would measure in a focused pilot
Count requests that need another touch after submission. Check how long those requests sit before someone acts. Record when a teammate has to hunt through a separate portal or message chain to understand the status.
Also keep payer response time separate from the time your practice takes to act on that response. A tool cannot make those two delays interchangeable. Measuring them separately shows where a change actually helps.
At Thyra, our view is that clinical software should help the team finish the work, not merely move it to another screen. That is a design principle, not a claim that every payer connection is ready. Confirm the payer, request type, supported actions and review responsibilities before any pilot.
Questions practices ask
Does electronic submission remove the need for follow up?
No. A request may still need more information or a clinical decision. Define who owns the next step and where they see it.
Does the 2027 API requirement include drug prior authorization?
CMS 0057 F excludes drugs. Do not use this rule as evidence that your medication workflow is supported. Check the applicable requirements and your vendor's actual coverage separately.
What should we ask an EHR vendor now?
Ask which payers and request types are supported in your software version, what it costs, and how responses become visible work for your team. Ask for a demonstration of an incomplete request, not only a successful submission.
The useful test is simple: when the response comes back, does someone know what to do next?
Sources
CMS Interoperability and Prior Authorization final rule fact sheet
MGMA readiness warning, Physicians Practice, October 1, 2026
Policy details checked October 8, 2026. Verify applicable payer requirements for your practice and workflow.