Prior authorization in the real world: Takeaways from Epic ahead of looming API deadline

The healthcare industry is slowly but surely moving away from the old, fragmented and manual way of handling prior authorization toward a modernized electronic system.

CMS-regulated payers, such as Medicare Advantage, Medicaid and marketplace insurers, are now confronting a Jan. 1 deadline to implement the three prior authorization application programming interfaces — sets of rules that enable computer programs to communicate directly with one another —  under a federal interoperability rule that was finalized in 2024.

The federal government hopes the reforms will make prior authorizations faster and more efficient. The cost-control policies, which require patients and their doctors to get approval from insurers before a service is provided, have been maligned by providers and other stakeholders for delaying patient care.

Reforming the process is a priority for the Trump administration, which has stood up multiple initiatives to improve the process through technology — and health tech companies will play a big role in making those reforms happen.

Epic, which accounts for roughly 42% of the acute care EHR market, was one of several major electronic health record companies that pledged last year to help reform prior authorization and get payers ready for the Jan. 1 deadline. By using Epic’s technology, doctors and health plans can comply with the new requirements.

Epic also plays a unique role in the implementation of the technology. Its sheer size means it has connectivity to thousands of physicians, and enabling real-time electronic prior authorizations could let it expand its footprint in the payer space.

Modernizing the antiquated process is the goal, according to Ryan Bohochik, vice president of value-based care at Epic.

“There's an old eye-rolling joke that people like to reference, which is that the healthcare industry is the last thing keeping the fax industry running. There’s just all these ways that people have to exchange information that feel outdated,” Bohochik said. “And I think everybody realizes there's got to be a better way to do it.”

Bohochik is a member of the Da Vinci Project, an industry-led initiative formed by standards organization HL7 in 2018 to promote standards that dictate the transfer of healthcare data.

The group developed the open-source blueprint for the three APIs that payers will soon have to adopt. The APIs let providers check whether a medical service requires prior authorization, pull clinical documentation requirements using data from a patient’s EHR, and enable providers to submit the request and payers to respond electronically.

Now, Epic is taking that blueprint and building the APIs directly into its software.

Bohochik sat down with Healthcare Dive to discuss the upcoming deadline and how far along Epic’s partners and customers are in meeting it, as well as what he would do differently if he was developing these standards today in the age of AI.

Editor’s note: This interview has been edited for clarity and brevity.

HEALTHCARE DIVE: I understand Epic has been working with a lot of payers across the industry on rolling out prior authorization APIs. From your point of view, how far along are they in implementing this tech ahead of the deadline?

RYAN BOHOCHIK: It is a spectrum. So a lot of the large national payers are either ready or in testing with us and with other EHRs. UnitedHealthcare is live with health systems. Some smaller health plans that also use Epic technology, like Network Health based in Wisconsin, are supporting all three of the APIs.

But some of the smaller regional health plans are still working through it and getting to a place where they can support this. It's a lot of work for them to say: “Here's all the policies we used to use. They used to live in a binder on our website. We have to digitize all of them.”

We decided we were going to focus on what we control from the Epic side, which is to make sure everybody who uses our technology has these resources available. The ability to do the electronic API-based prior auth process was in our February release. We wanted to give people some runway, so it wasn't just the day before the requirements went live. 

What are some of the lessons you’ve learned so far from rolling out the APIs in a real-world setting? Has there been anything unexpected that came up in the process?

Everybody was designing away in a lab and now that we've come together, you’re seeing that there's still work to be done. And I think that's always a good reminder. You could put out a new standard and we could say, “Here's a great electronic way to do something.” But when you actually have people start doing it in practice, you find real-world considerations you have to work through, but that's what we're doing now.

For example, one of the three new APIs is called [Coverage Requirements Discovery]. Basically, it lets you electronically ask an insurance company: Does this require prior authorization? When CRD was first designed, the focus was on doing this at the point of care. If a physician is with a patient and places an order, the system should ask the insurance company right then whether prior auth is necessary.

In theory, that's great — you talk to your doctor, he says you need an X-ray, and ideally the system tells you in real time whether that requires prior auth from your insurance company.

In reality, there's probably a lot of data that you and your physician don't yet know that would impact some insurance considerations. There might be certain things you talk about [with your doctor], and then in the process of scheduling, now we're rechecking with the insurance company to work through those things.

You don't want to put the burden on the physician to collect all of that information, but in reality, those are all data points that the insurance company needs to know to tell you if prior auth is necessary.

These are all solvable problems, but again, it comes down to when you design something in a lab versus when you get it out there. You find that people's interpretations were maybe a little bit different.

What has the physician and front desk staff experience been like with these changes, from what you’ve heard?

With some of our early adopters, we've seen outcomes like fewer canceled appointments, because somebody will be on the books, but then they’d find that they didn't get pre-approval from the insurance company, so they have to move the [appointment] to a different time. 

That's obviously a really good thing for patients if you get them in for care faster. 

But what we've seen so far is that it's fewer touches, certainly, to get an authorization request through. So reduction in administrative overhead for the people that support physicians.

It’s hard to talk about any developments in health tech without talking about artificial intelligence. How do you see AI playing a role in streamlining the prior authorization process in the future?

It’s a huge opportunity. When we started this work in 2018, it was before the commercial-grade AI chatbots came out. The way that we designed it then, we probably wouldn't do now.

I think [AI] has the opportunity to significantly reduce the effort that it takes to do this work. We're working with a state Blue Cross Blue Shield group that was using AI to basically summarize authorizations, and they had some pretty significant time savings. They said it's 15 minutes less per case, which may not seem like a lot, but just means they get through things more quickly and then you get the response back as the patient and as the physician.

The thing that you also see happening is, there’s admittedly a little bit of apprehension around AI in this process because, depending on your perspective, some people immediately jump to: “Well, how are people going to use AI to do something that I don't like?” You'll hear from some groups, and even some folks in government, that want to jump to regulating AI out of this process or at least potentially minimizing how it can be used. But I think there's good, thoughtful ways that it can be employed for really good outcomes.

Let’s zoom out on prior authorization more broadly. It’s a known source of administrative burden for providers, and you alluded to the fact that it can cause some tension. 

It's not that [doctors] necessarily are anti-prior auth, it's anti-administrative work and the back-and-forth, and the things that delay patient care and lead to frustration. That seems to be the thing that everybody can coalesce around. 

And with these new APIs, I do think that this is not the endpoint. It'll be great, it's going to make huge improvements, but it's not like these APIs will go live and then we'll say, “Now nobody is frustrated with prior auth anymore and we've solved all problems.”

It now creates this infrastructure where we can do more to further improve it, like some of this further use of AI and the additional automation opportunities that are there. It's like you're building these bridges to share information, which can then help expedite the process and people can do things more efficiently. And it's a really good step to further improve what traditionally has been pretty painful.