Electronic prior authorization (PA) is a process that allows care providers (e.g, doctors) to electronically transmit a pre-authorization request for a service to the patient’s insurance carrier and receive an authorization within minutes instead of days or weeks.

If you’re not familiar with it, you can click here to learn about the current PA process in healthcare.

Why Electronic Prior Authorization (PA) is so important

In the current (fax, phone and paper based) PA process, it can take days or weeks to receive prior authorization. As a result, either the patient goes ahead with the procedure not knowing whether it will get paid by the insurance or they have to wait a long time before having the procedure.

In addition, the current process results in high administrative costs to the doctor and high administrative costs to the payer. Patients frequently delay diagnosis and treatment since they are not sure how much they will have to pay.

Electronic Prior Authorization is designed to cut this process from days and weeks to just a few seconds or minutes. All without the involvement of any administrative staff on either side.

This is expected to cut costs for healthcare, enable better, timely care for patients and provide piece of mind to patients.

When are insurance payors required to support electronic prior authorization?

CMS Rule (CMS Interoperability and Prior Authorization Final Rule CMS-0057-F | CMS) requires all payors covered by CMS to provide electronic Prior Authorization APIs by January 1, 2027.

CMS is requiring impacted payers (excluding QHP issuers on the FFEs) to send prior authorization decisions within 72 hours for expedited (i.e., urgent) requests and seven calendar days for standard (i.e., non-urgent) requests. 

While this rule targets only payors covered by CMS, we expect that payors will support this for all their lines of businesses due to the potential for large cost savings in administrative staff.

Main Parts of the Process

There are three main parts of the electronic prior authorization process:

1. Checking if Prior authorization is required by the patient’s payor for this proposed service.
2. Sending the requested information about the patient to the payor to determine whether this service is authorized.
3. Receiving an authorization or rejection and keeping that in the patient record.

Workflow

This is a sample workflow of how this can work in the real world:

1. Jim goes to visit his doctor, Doctor Givens. Jim has insurance coverage from Cigna.
2. Dr. Givens logs into their Electronic Medical Record (EMR) software (e.g., Epic) and brings up Jim’s patient chart.
3. Dr. Givens creates a new order for a procedure e.g., MRI.
4. The doctor sees a message in the EMR that Cigna requires prior authorization for MRI and asks the doctor’s permission to start the process.
5. Dr. Givens tells Jim that he will be submitting the request for prior authorization to Cigna.
6. This UI screen then lists the parts of the patient record that are requested by the payor and will be sent to the payor.
7. In addition, the screen asks a couple of questions requested by the payor that are not answered by the data in the patient record.
8. Dr. Givens provides answers to these questions and chooses to submit for prior authorization.
9. The doctor continues to talk to Jim for a few minutes.
10. The doctor then has a message in the EMR that says that prior authorization was successfully approved based on the information submitted.
11. The doctor informs Jim and finishes writing the order.
12. Jim walks away knowing that his insurance, Cigna, will cover this procedure.

What Technologies Are Needed?

For a provider to be able to use electronic prior auth they will need the following technologies:

1- Electronic Medical Record (EMR)

An EMR is needed to store the patient chart and to create a new order for treatment. While you could have the doctor submit the prior authorization in another tool, it is simplest to have the doctor just create a new order in their EMR.

Good news is that almost all providers already have an EMR such as Epic, Allscripts or Cerner.

2- SMART on FHIR App

SMART on FHIR app is a piece of software that is available in your EMR’s “app store”. Just like apps on your phone, these apps can be installed in your EMR and they enhance the functionality in your EMR.

3- CDS Hooks

CDS Hooks is a technology that allows a third party SMART on FHIR app to monitor what the doctor is doing in the EMR and then bring up UI screens to provide additional functionality to the doctor.

4- Prior authorization API client

This is a new piece of technology that listens to new orders in the EMR, communicates with the payor prior authorization APIs and saves responses into the patient chart.

5- FHIR converter

Electronic Prior Auth standards require that all the patient data sent to payors must be in FHIR format. This software converts the data from the EMR’s clinical record format into FHIR.

6- CQL engine

The request for information from payors will include CQL logic to fill the answers from the patient’s chart in FHIR format. The CQL engine is able to run this CQL and fill the answers. (A CQL Engine reads logic defined in CQL language and runs it on FHIR data to calculate results.)

7- FHIR Questionnaire Processor

Request for information from payors is received in FHIR Questionnaire format. The FHIR Questionnaire processer reads FHIR Questionnaire, calls the CQL engine to fill the answers, shows the doctor a UI to answer the remaining questions and formats the information in FHIR QuestionnaireResponse format to send back to the payor.

What vendors do I need?

While there are a number of technologies necessary to support electronic prior auth, the good news is that some vendors already support many of them.

A provider really only needs two vendors:

1. An EMR vendor that provides the EMR (e.g., Epic, Cerner, Allscripts etc).
2. A prior auth client app vendor that provides:
   • SMART on FHIR App
   • CDS Hooks
   • Prior authorization API client
   • FHIR converter
   • CQL Engine
   • FHIR Questionnaire Processor

With just these two vendors, a provider can use electronic prior authorization.

How Can Care Providers Get Ready?

It is expected that electronic prior auth will cut administrative costs for providers and allow them to provide better care to their patients. CMS has set the deadline of January 1st, 2027 for payors (under the purview of CMS) to support electronic prior authorization.

As mentioned above, providers will need new technology to be able to support this.

One strategy may be to wait for EMR providers to build this functionality. We expect this will be take a long time since the EMRs today lack the core technology pieces above (e.g., FHIR data models, API management and CQL engines). These are complex pieces that are not quick to build. Relying on your EMR provider can create risk that you may not be ready to take advantage of electronic prior authorization in time.

An alternate strategy is to use a third-party vendor that supports electronic prior authorization. These vendors can provide SMART on FHIR apps that integrate with your EMR to seamlessly provide additional functionality without leaving the EMR experience.

You can look for vendors that already have the technology to convert and store data in FHIR, can manage communications with external FHIR APIs and include CQL engines.

Leveraging one of these vendors can provide a great risk mitigation strategy. You can start with integrating a third party SMART-on-FHIR app into your EMR. This can allow you to start to take advantage of the cost savings of electronic prior authorization quickly. If in the future your EMR provider adds this capability you can switch over to that functionality if you prefer.

Learn about the technical details about how to implement electronic prior authorization.