Burden Reduction – What Could Possibly Go Wrong?

The healthcare industry is waiting with bated breath for CMS to release their Burden Reduction regulation for comment. Standards-based methods for Performing Prior Authorizations will help make the process more efficient but what could go wrong?

Prior Authorization is an administrative process used by Health Plans to review proposed treatments for members. 

Each Health Plan has different: 

– Rules for the treatments requiring Prior Authorization. 

– Requirements for the supporting information to be submitted. 

– Medical Guidelines for reaching a decision.

– Methods for a Provider to determine the need for a Prior Authorization and to submit the supporting information.

This variety creates a heavy burden upon Providers and often involves a lot of copying and pasting between systems.

Standards Can Help Reduce Confusion

For the past couple of years the HL7 Da Vinci project has been developing a standardized process for handling Prior Authorizations to address CMS’ Burden Reduction objective. Three Implementation Guides have been created that address the steps in the Prior Authorization process:

• Coverage Requirements Discovery (CRD)
• Documents Templates and Rules (DTR)
• Prior Authorization Support (PAS)

The steps can be summarized as:

• CRD: Is a Prior Authorization required
• DTR: What Information do I need to provide
• PAS: Send all the information to make a decision and return the result.

The Implementation Guides define the data that is to be exchanged and the methods of performing that exchange. It still leaves room for innovation.

The Prior Authorization process requires implementation of solutions at both the Provider and Payer.

So what could possibly go wrong?

Payers have invested in Provider portals to enable providers to submit requests for Prior Authorization. 

When CMS introduces Burden Reduction regulations they are expected to require the use of the HL7 Da Vinci Implementation Guides.

There are two important steps in the Prior Authorization process where we could see challenges in the implementation:

1. Connecting Providers with Payers.
2. Collecting data from the EMR to submit with a Prior Authorization.

1. Connecting Providers with Payers

In order for the new Prior Authorization processes to work as intended Providers will need to be able to discover the API Endpoints where each Payer will expose their Prior Authorization Services.

Once a Provider has discovered those Endpoints they will need a process to be able to register with the Payer. This will enable them to exchange Prior Authorization information. For this to happen there needs to be a way for Payers and Providers to be able to trust each other.  This process needs to be able to handle thousands of Provider Organizations connecting with hundreds of Payers.

As an industry we need to encourage the use of standardized methods for registration. If Payers choose to differentiate themselves in the way they handle registration, the checks they perform, the information they require it will only create additional effort for all parties involved.

The Industry also needs a register of API endpoints to enable Providers to discover Payer APIs. The standardized Prior Authorization processes that will operate in a provider setting need to be able to lookup a Payer to find where to send Prior Authorization requests.

2. Collecting data from the EMR

When a Prior Authorization is required the payer will send an electronic form, a questionnaire, back to the provider. This will contain code that can query the provider’s EMR to extract required information. The provider may need to add additional information that can’t be extracted automatically from the EMR before the Prior Authorization is submitted. This step will require an application that the provider can use to complete the submission.  The risk here is that each payer will produce their own application for performing this step. 

If each payer produces their own application then all we will have accomplished is to move a part of the payer’s Provider Portal into the EMR. Providers will still be faced with 20 different ways to submit a prior authorization. The only advantage is that they will be doing it inside the EMR.

Avoiding A Continuation of Confusion

To avoid perpetuating the current confusing situation for Providers, we need to act as a community and establish:

• A machine-readable Directory of Payer and Provider API endpoints for registration and use of the Prior Authorization capabilities.
• A simple way for Payers and Providers to confirm a trusted relationship.
• A common process for registering a provider organization to a Payer’s Prior Authorization service API.
• Enable the SMART-on-FHIR App that processes the Prior Authorization questionnaire to work with any Payer’s Questionnaire and able to route to any Payer Prior Authorization API endpoint.

Preparing for FHIR-based Prior Authorization

At Onyx, we have been busy building the tooling to support FHIR-based Prior Authorization. The Onyx:OS platform offers Payers full support for the CDS Services and CDS Hooks that they need to respond to Prior Authorization requests from Providers.

The Onyx:OS Hooks framework enables rapid customization to tailor a Payer’s response to a Prior Authorization query. Customization options include: 

• The list of medication or treatment codes that require a Prior Authorization.
• The list of Providers that do not need to perform a Prior Authorization for certain procedures
• Integration with Member and Coverage data to determine whether a Prior Authorization is required for a member.

In a subsequent blog post we can address the challenges faced in translating Medical Guidelines for Prior Authorization in standardized structured data questionnaires that can accomplish automated querying of a provider EMR.

For a briefing on Electronic Prior Authorization please contact us at www.onyxhealth.io