Q&A: Cohere Health’s Matt Parker on Meeting CMS Prior Authorization API Requirements

Health plans are starting to realize that without digitized, structured policies, they cannot effectively automate authorization workflows and can’t meet CMS interoperability requirements or fulfill the goals outlined in AHIP’s 2025 pledge to standardize electronic prior authorization, enhance transparency, and expand real-time response capabilities. 

Matt Parker is chief product officer at Cohere Health, a company that works with more than 660,000 providers and handles over 12 million prior authorization requests annually. Its AI auto-approves up to 90% of requests for millions of health plan members. He recently sat down with Healthcare Innovation to talk about which aspects of the upcoming CMS requirements health plans are finding the most challenging, as well as how his company developed a solution to help eliminate the technical complexity and manual burden of policy digitization.

Healthcare Innovation: This month, we are putting a spotlight on the progress that health plans and providers are making complying with the CMS Interoperability and Prior Authorization Final Rule in order to boost transparency and efficiency. We are also looking at some of the ways AI is impacting the prior auth interactions. I hope to talk to you about what some of the pain points are and how Cohere’s solutions are helping customers overcome them. Please give us a little background about the company. 

Parker: I manage our product management and design teams. I am focused on helping build solutions for our customers to help them improve a couple of areas of work. We started as a utilization management/prior authorization company. Our goal was to bring AI tools, advanced decisioning and automation to help increase the speed with which providers could get a yes from the health plan. 

We had recognized prior auth as a very onerous process and our goal is to make it better and faster and to remove barriers to access to care, and to do that in a way that helps plans meet their needs — applying essentially a clinical policy of coverage in a meaningful, transparent and easy-to-understand way. We built a foundation — we call it a clinical intelligence layer — that allows us to evaluate the clinical state of a particular patient and help provide guidance to providers submitting authorization requests to payers, and helping decisions in other areas to be more effective and more aligned with that clinical policy.

HCI: It sounds like there are two elements. One is helping the payer get the complete information faster to make the decision. But the other part is making the back and forth with the provider more seamless. 

Parker: Yes, absolutely. Our clinical intelligence layer ties in with the interoperability standards, and the policy of transparency and visibility. Our goal is not to create scenarios in which a provider is getting a no from the health plan, but actually to accelerate a yes. One of the big drivers of abrasion is whether or not the plan has the right information necessary to make a decision and do a clinical evaluation, which in many cases, leads to denials of care in other prior auth models. 

We’re actually evaluating the submission as it's coming in, helping identify to the provider: Hey, this particular policy needs evidence of this from this type of test. Please submit the lab report. That feedback loop during submission allows us to get that answer to them quickly, without having to go through a denial and appeals process. We are focused on how we can get to yes right away, remove the administrative burden from the providers, from the payers administering that and getting to an appropriate clinical decision within respect of policy and patient safety and all of those other considerations.

HCI:  Let’s talk about this rule, CMS-0057. The first part, which goes into effect this year, involves public reporting of prior authorization metrics, and then in January 2027 it involves mandated FHIR APIs. I saw that WEDI released a survey about people's top challenges with this broken down by payers versus providers. The payers said their top concerns are digitizing policies, meeting compliance timelines, and delegated third parties facing challenges with different systems. (In a previous WEDI survey conducted a few months ago, determining a cohesive enterprise strategy for interoperability was listed as well). So do those sound about right to you? Is that what you hear from customers?

Parker: 100 percent.  I think that survey result absolutely jibes with what we're hearing from our customers. The delegated vendor issue is important. We do delegated prior auth. We also provide a technology solution. Because of the way the mandate is written, the payer is mandated to provide sort of a single pane of glass, from an API standpoint, which means it really needs to connect to and work with all of their different delegated vendors. And those vendors have to be ready to support that as well.

The policy digitization is the No. 1 concern, I think, for a really good reason.

HCI: So let's talk about that. I understand that Cohere has released a tool called Policy Studio to help with this. The payers often have the policies sitting in static documents such as PDFs, and they need to digitize them to make this work, right? 

Parker: Part of the mandate is that you need to provide in an API format the ability to understand whether prior auth is required, the ability to submit an authorization and the ability to know what needs to be done to get an approval — what are the conditions of evaluation — the policies themselves. So you have this policy that says here are the rules for this particular code or set of codes, and here are the conditions that are going to be evaluated for a particular patient. Well, that needs to be transformed into an API so that you can have a response. 

There's a great FHIR standard for it, and there are elements that are out there, but most of the plans have these on PDFs. These are written in Word documents by clinicians. They're not written to be digitized and translated to APIs. And that's a pretty substantial amount of work we have to do. For example, we've got about 4,000 policies that we manage across our installed base today. Those all started as Word documents that were converted into PDFs and then we digitize those in our applications. 

HCI: So are there people on the health plan side who wake up in the middle of the night and wonder how they are going to convert all these policy documents into APIs?

Parker: The medical policy functions are somewhat separated from the technical functions. I think that's part of the burden. As the IT folks are trying to figure out how to actually meet the mandates, they're realizing they have this problem to solve. We are trying to give the users managing policies the ability to manage that in a way that allows for a faster and more automated translation into digitization, without forcing them to work outside of normal human language, right? I think that's a big part of it. You can't ask a bunch of medical policy people to start thinking like a robot.

HCI: I read that Policy Studio converts the PDFs into structured formats with workflow management and automatic version tracking. Where does AI come into that?

Parker: Because most of these documents are stored in sort of flat PDF formats, we've actually built a bunch of proprietary algorithms that will take those documents, knowing what needs to be done to turn these into digital entities that can be used in clinical decision-making. It's not just an OCR problem, right? It actually is converting it and helping structure the document such that you can make decisions based off of it.

 If you think about the typical prior auth scenario: request comes in, there's a patient who needs a particular procedure, and we have clinical documentation, labs, and all the other material. The policy says under these certain circumstances, this is when you can do what you want. Whatever prior auth decision-making application you have, whether you're going to automate the decision or you're going to have a nurse review it, you want to surface the evidence required by the policy in a way that you can go back and find that, either in the submission from the authorization request or in the clinical documents attached. For example, in our APIs, you just need to send us the the raw documentation. We're not asking providers to go and do onerous questionnaires. Just upload the clinical patient records. We evaluate that, we find the evidence in there, and then we match it against the policies and guidelines. So what our AI is doing is actually evaluating the document to identify indications, what lab work, what tests, etc., need to be done, so that we can then match that against the source material.

HCI: Does Cohere also work with folks on the provider side?

Parker: We don't sell to providers. We provide a technology and a service-based solution to our health plan customers, but providers are users. We focus really heavily on their experience. Part of what motivated us to start in the first place was prior auth. We have to support providers, because they are the ones submitting the requests and are required by contract with their plans to make sure that they're meeting policies when they make these referrals. And our payers care about provider experience. They care about abrasion. They don't want to get in the way of care. They don't want to create patient risk by having necessary care delayed, so we focus a lot on the provider experience, trying to make it a simple process. 

We meet providers where they are, so whether they're using the portal, whether we're doing our EHR integrations, the goal is quick answers, rapid feedback on what is needed to make the evaluation from the case.

HCI: Do you think this CMS rule is pretty ambitious as far as the timeline and lighting a fire under people to do something about this as far as the interoperability aspect?

Parker: The interoperability mandates have been around for quite some time. I think the industry has wanted to do this for a long time. The first round of mandates were in effect six or seven years ago, with patient access APIs, right? So there has been time to plan for this. 

Part of why I think we at Cohere were fairly far ahead is we're only a 6-year-old company, and we were founded after the mandates were written, and a lot of our core architecture uses some of the FHIR standards as they were being developed, and we have been an active participant in the Da Vinci Project for a long time. So, these aren't new things that have crept up. There are other priorities. Maybe not everyone was focusing on them with the right urgency at the time, but they were there.

What I would say is this CMS process and the AHIP 2025 pledge — these are all industry and regulatory frameworks that are largely around the idea of making prior auth less burdensome for patients, providers and plans, and I think it’s the right focus. It doesn't need to be onerous. We have auto-approval commitments from payers, the timeliness response. We do have EHR connectivity working today using some of these APIs. So I think the industry is close to being ready for it, and it will make a difference and make these administrative and clinical checks that prior auth provides fast, effective and efficient without creating barriers to patient care, which I think everybody wants.

HCI: I saw your name on the HL7 Da Vinci Project steering committee. Is work that Da Vinci's done with the implementation guides helpful in this work?

Parker: Absolutely, the implementation guides are really the manifestation of the standards. Whatever technology solutions a payer puts in place to meet the needs here are based on implementation guides like what Da Vinci's put together. It is a FHIR standard that elaborates for each of these APIs how they are supposed to work. What should the input be? What should the outputs look like? And providing the structured documentation for being able to meet the mandate.

HCI: Anything else you want to mention?

Parker: By January 2027 there's going to be a standard APIs available across payers for any provider who wants to write to those APIs. But on the provider side, the EHR vendors are going to have to do work to enable this. Epic has a pretty extensive roadmap for native FHIR support that should be rolling out this year. I know that athena and Meditech have applications that are available. But if you're not on one of the big EHR applications, and they haven't done much FHIR development, you’re not going to be able to take advantage of these APIs. So there is still work to be done on the provider side to make use of these APIs.