Will FHIR standard guides bring relief to prior authorization?
While hurdles and testing remain still lie ahead, hopes for expediting the difficult process are rising, contends standards expert Linda Michaelson.
Prior authorization remains a challenging problem for the healthcare industry, frustrating both provider offices and insurers. Despite attempts to automate it, the process remains highly manual, document heavy and unautomated.
The development of standards to facilitate the process are being fine-tuned and being tested in early pilots. The use of the Fast Healthcare Interoperability Resource (FHIR) standard offers new hope in making the process automatic, says Linda Michaelsen, an HL7 subject matter expert with more than 20 years of experience in clinical and administrative electronic data interchange.
She has worked at UnitedHealth Group over the last 21 years, and now serves as director of healthcare interoperability standards for Optum, a subsidiary that's part of UnitedHealth Group as the holding company. Michaelsen talked to Fred Bazzoli, Editor of Health Data Management, about the challenges that must be surmounted to bring modern technology to bear on the prior authorization process.
Prior authorization has become a focus for efforts to streamline administrative functions that slow care delivery. What are the challenges for providers? Patients? Payers?
There is a transaction in HPAA that was supposed to support prior authorization, the X12 278. It just did not contain enough clinical data to make it possible to approve a prior authorization. And then the X12 community suggested another standard, the 275, which is where you can send an attachment. There was a lot of regulation proposed, but to my knowledge, the 275 never was adopted as being required. And even so, an attachment could include a PDF or non-discrete data.
(Attachments) are frustrating for practitioners not to be able to submit it and be ready to go. And let’s be honest, it’s the office staff or nurse doing this, learning all the payers and the different ways to manage these, which is often through portals. Someone has to log into the portal, upload and fax documents that are linked to entries in the portal. It’s very confusing – in the practitioner’s office, nurse assistants specialize in portals, and they know each portal's workflow and the challenges. Da Vinci’s work is with burden reduction; it allows for three prior authorization guides in that burden reduction suite.
One guide is for coverage requirements discovery (CRD), allows for provider to use CDS Hooks on orders, such as when the provider wants to do a certain procedure.
Then, the payer can respond in a number of ways. The payer can respond with a smart card that indicates that no authorization required. Or it can direct the provider to go to a payer's portal and here’s the link. Or it could respond more intelligently and launch a smart app. Once it launches, we get into the second Da Vinci guide, which is Data Templates and Rules (DTR), which can gather information in FHIR format from the EMR that’s necessary for the prior authorization.
Once it gathers that information, there still may be questions that may not be in the EMR that have to be answered, it will prompt with a questionnaire or structured data capture, where they can get the answer in a structured way from a person sitting at the keyboard. In the ideal scenario, it would use Clinical Quality Language (CQL), which is a logic that is combined with FHIR to make a determination as approved or denied, or it even could be pended, where a medical resource would be required to sign off on it.
The third Da Vinci guide is prior authorization support (PAS), which has the logic to transform the FHIR bundle from the previous two guides to X12 278; then FHIR bundle could go along in the X12 275. Then on the return pass, PAS could return it back from the X12 278 response to a FHIR bundle. That’s the beauty of what DV does.
This seems like a promising approach. What challenges are still standing in the way?
The biggest challenge is the with the component in the middle – the organizations like Interqual and Milliman Care Guidelines, which have the care guidelines. All the folks creating the prior authorization rules, including the payers for their particular clients, have to codify those rules and recreate the logic behind them so that it can work while it collects the data through FHIR and run the logic and give the (prior authorization) answer back to the provider.
The industry is working there. At one of our Da Vinci events, Milliman showed us progress in this back and forth with the provider system, something that would give support for admitting a patient. It’s no different than what is done today – it just has to all be codified. Instead of having that human there pulling up the records and entering the data necessary for the approval.
Prior authorization is obviously a challenge for the provider and it’s frustrating for the patient. Does the process also represent a burden for the payer community that may be more or less invisible as well?
Certainly, if payers are getting faxes of medical charts or even if they’re uploading PDFs, it’s not discrete data, so somebody on their side has to ferret out the data that they need to enter in whatever tool their using to work on the prior authorization. Any time you’re abstracting from documents and putting them into a system, there’s always the possibility of missing things. There’s a lot of back and forth to get the level of detail necessary.
Whereas the way DTR is codified, it looks for all the data that it needs to make the decision at one time from the EMR, and so it prevents having to find the random note or that (a patient’s) blood work was done on a different day than the encounter. So instead of faxing back and forth, you get whatever you need to know for the prior authorization.
So the payer is doing the same work on their side of the portal that the provider is doing on their side. The reason we refer to it as "provider burden" is because the payers implemented the process. It’s done on the behalf of the payers, so there’s typically not much sympathy for them.
Prior authorization burdens everybody involved on both sides; computers are just not as good at replicating this process yet. There are times when humans have to be involved at some point, when a payer medical director will need to get that doctor on the phone and talk. I’m not saying that this will ever totally replace that element, because it never should.
The focus should always be the patient. We all know that there are routine things that are done every day, and the prior authorization process is there to make sure bad actors don’t do bad things. Payers are at risk, too; they don’t want the patient having interventions that will cause them harm. It is really on behalf of both entities.
What have constituted past efforts to automate the prior authorization process? What challenges have these past efforts encountered?
Some people have implemented some aspects of this, but unless a provider can do it for everything, it’s more of a burden. It has to be consistent across payers, because for the provider, it’s hard to remember that, as a hypothetical example, Humana does (automated prior authorization) but United doesn’t. I think we’ve seen a lot of solutions implemented with one-offs around prior authorization – it doesn’t meet the need because then the practice has to understand that I use this for payer A, but for everyone else, I have to go to a portal.
If you think about the Da Vinci effort, it’s a standard that can be implemented across all payers and all EMRs. There’s probably still some work needed around the look and feel of the smart apps. Both sides have opinions on how this should look. What the provider needs is one way to do it across all payers and the EMR. It’s evolving, and not regulated yet, all EMRs and payers are working on it.
Developing a unified solution for everybody, that’s probably the Holy Grail of making life around prior authorization more bearable.
The process of getting the data is not what makes a payer or practitioner shine. It’s about how they do it, the rules that drives their quality around processing it, that makes the difference. There’s no great business benefit in how it’s done now. You have to keep the patient in mind, what’s being done to make the patient healthier. That will drive the market. It isn’t about the nuts and bolts for how you get the data to the payer.
Specifically, when it comes to ANSI transactions, what has worked and what hasn’t worked? It seems like the individual pieces are there to manage these interactions, but do they work in combination?
I don’t think it’s the workflow, but what I’ve heard that it doesn’t support enough of the clinical data. Also, some organizations have highly integrated front and back office systems like Epic and Athena, but if they don’t, clinical data is not always in the front office; the data you need for prior authorization is in your back office, not in your patient administration or practice management system. So if they’re not highly integrated, then anything you’re trying to communicate you have to somehow re-enter to generate the X12 transactions.
What are the current efforts to facilitate the process? In particular, what are efforts being developed within the Da Vinci Project hoping to accomplish?
All three implementation guides have all been published at least once, so that none are awaiting first ballot. Don’t know if they have been implemented in actual production.
What are potential future paths for facilitating the prior authorization process? What would the ultimate solution look like?
Adoption right? You don’t know the problems until you’ve implemented the implementation guides. It will take people implementing them and sharing that their implementation is in production so that the community believes its real. We can do demos until its real, but folks have to know it works – nothing beats that testimonial. In an ideal world, it would be awesome if this would happen with the providers and payers in the room.
Certainly, you have to be able to scale this, but I as far as volume is concerned, it’s not a challenge. It’s kind of the 80-20 rule; practitioners will set up their connections with the 80 percent of the payers they use all the time, and maybe fall back to more manual processes with the 20 percent of payers who don’t use FHIR guides.
What are the potential benefits to the healthcare industry as a whole for coming to consensus on approaches that facilitate prior authorization?
I will be pleasantly surprised if we will be under five years for market penetration. The biggest challenge is the codification of all those rules, thinking about how you do it when you don’t have a person abstracting from a chart.