Cybersecurity: 24/7/365

Your practice has someone whose week is mostly prior authorization. She logs into four payer portals, retypes clinical data that already exists in the chart, waits on hold, and chases authorization status for requests submitted eight days ago.
None of that work is clinical. Very little of it requires judgement. Almost all of it exists because the payer's system and your electronic health record have never spoken to each other.
Prior authorization is the administrative burden physicians complain about most, and the complaint is well documented. The American Medical Association runs an annual physician survey on it, and the findings are consistent year to year: the volume is high, the staff time is substantial, and physicians report that the resulting delay in care harms patient outcomes.
The AMA survey is worth reading before you buy anything. Tools that genuinely reduce administrative work address the specific failures it names — repeat submissions, requests that stall without explanation, and treatment abandoned while an approval sits unanswered. Those are workflow problems, not clinical ones.
The patient experience side rarely appears in the business case and probably should. A patient who waits three weeks for an approval, calls twice, and gives up is a patient outcome and a retention problem at once.
That is finally changing across healthcare, and not because vendors got clever. Federal rules are forcing it.
The CMS Interoperability and Prior Authorization final rule sets deadlines that reshape the prior authorization process for a large share of your payer mix.
From January 1, 2026, impacted payers must:
By January 1, 2027, those same payers must stand up a FHIR-based Prior Authorization API, alongside Patient Access, Provider Access, and Payer-to-Payer APIs.
Read the scope carefully, because this is where practices get the wrong idea. Impacted payers are Medicare Advantage organisations, state Medicaid and CHIP fee-for-service programmes, Medicaid and CHIP managed care plans, and qualified health plan issuers on the federal exchanges. Commercial and employer-sponsored plans are not covered.
So a practice with a heavy Medicare Advantage and Medicaid mix will feel a real difference. A practice living on commercial contracts will keep dealing with payer portals for the foreseeable future.
Prior authorization automation is not one product. It is four separable pieces, and most practices benefit from the first two long before the clever ones. Each piece removes a different part of the prior authorization workload.
1. Know when an authorization is required. The most expensive failure is discovering at check-in that a procedure needed prior authorization. Automated eligibility and authorization requirements checking runs against the payer at scheduling and flags it while there is still time, which avoids a delay nobody planned for.
2. Assemble the authorization request from the chart. Pulling diagnosis codes, procedure codes, and supporting clinical data out of the EHR removes the retyping and, more importantly, the transcription errors. An incomplete prior authorization request is a leading cause of avoidable delay — payers reject on a missing field and the clock restarts.
3. Submit electronically. Electronic prior authorization through a clearinghouse or a direct payer connection replaces the portal login and the fax. Where a payer supports it, this is where turnaround improves most.
4. Track status automatically. Polling for authorization status and surfacing changes in the workflow removes the follow-up calls, which is usually the single largest time sink. Automated prior authorization is mostly this: the same authorization processes your staff already run, without the waiting.
Pieces three and four depend on payer connectivity, which is exactly what the 2027 API deadline creates. The underlying plumbing is the same interface work covered in our healthcare API integration guide, and the standard behind it is the one described in FHIR versus HL7.
Partly, and the boundary matters more than the capability.
What AI-powered tooling does well here is document work. It can read the chart and draft the medical necessity narrative, identify which supporting documents a specific payer wants for a specific procedure, flag a request likely to be denied as incomplete before you submit it, and read an unstructured denial letter to extract the actual reason.
That last one is quietly valuable. Denial letters are written to be difficult, and an AI tool that reliably tells you which of four things went wrong shortens the appeal considerably.
What AI should not do is decide medical necessity. The clinical judgement that a patient needs a procedure is the physician's, and an AI-driven recommendation that shapes what gets requested is a patient care decision wearing an administrative costume.
There is an irony worth noting. Payers adopted AI for authorization review faster than practices did, and the resulting denial patterns have drawn litigation and regulatory attention. The same principle applies on both sides: automation can prepare and route a decision, but a human being should own it. Human review is not a courtesy here, it is the control that keeps the system defensible.
Anything you deploy that reads charts is handling protected health information, so it needs a business associate agreement and a place on your approved list — see our AI policy guide for the evaluation to run first.
Several categories exist, and they are not interchangeable.
Two questions cut through most sales conversations. Which of my payers do you have live electronic connections with, by name? And what happens with the payers you do not support — does my staff still log into portals for those?
Most practices end up with a hybrid for years, with one workflow for connected payers and another for the rest. Automation covers the payers that support it, and manual work covers the others. Price the tool against the share of your volume it can actually reach, not against your total authorization count.
The API requirement lands on payers, not on you. But the benefit only reaches your practice if your systems can consume it.
Ask your EHR vendor a direct question this year: what is your roadmap for the CMS Prior Authorization API, and will it be included or charged separately? Get the answer in writing. A vendor with no plan is telling you something about the next three years.
In the meantime, measure your baseline. Count authorizations per week, average turnaround, denial rates, and staff hours spent. Without those numbers you cannot tell whether a purchase helped, and every vendor will happily supply their own figures instead.
Then fix the cheap things. Standing authorization requirements per payer in a shared reference, submission checklists that prevent an incomplete authorization request, and a single owner for authorization status follow-up all reduce the administrative burden before any software arrives. You can automate a good process; automating a broken one just produces faster confusion. Denial prevention on the front end is the same discipline that drives our guidance on reducing claim denials.
Prior authorization is not going away. What is changing is that a meaningful slice of it — the government-sponsored plans — now has enforceable timelines that cap how long a decision can be delayed, plus a mandated technical path for real-time exchange.
Healthcare practices that know their baseline and have an EHR vendor with an API roadmap will convert that into recovered staff time and faster approval turnaround. Practices that wait to be told will find the deadline passed and the portals still open on someone's second monitor.
Ready to take the next step? Explore our healthcare IT services, book a free consultation, or compare our plans.