In How Electronic Prior Authorization Will Work, we discussed at a high level how electronic prior auth will work. In this article we delve into the technical implementation.
Definition of Terms
EMR (Electronic Medical Record) – This is the software application used by doctors to enter information into the patient’s chart.
Patient Chart – A set of data that describes the clinical information about a patient e.g., their name, date of birth, insurance carrier, diagnoses, procedures etc etc.
API (Application Programming Interface) – An API is a way for one system to communicate with another via established rules and protocols.
API Endpoint – An API endpoint is an internet address where the caller can communicate with an API.
FHIR (Fast Healthcare Interoperability Resources) – FHIR is a standard describing data formats and elements (known as “resources”) and an application programming interface (API) for exchanging electronic health records (EHR). The standard was created by the Health Level Seven International (HL7) healthcare standards organization.
CQL (Clinical Quality Language) – CQL is a domain-specific language designed for expressing electronic clinical quality measures (eCQMs) and clinical decision support (CDS) rules within healthcare IT systems. It aims to standardize the way clinical knowledge is represented, making it easier for healthcare providers to measure quality and implement clinical guidelines and protocols consistently.
FHIR Standards
Electronic prior authorization is built on FHIR standards. The implementation guide for Electronic Payer Auth is: Prior Authorization Implementation Guide Home Page – Da Vinci Prior Authorization Support (PAS) FHIR IG v2.0.1.
Sub-processes
There are four sub-processes involved:
- Coverage Requirements Discovery (CRD): CRD IG Home Page – Da Vinci – Coverage Requirements Discovery v2.0.1
- This Coverage Requirements Discovery (CRD) implementation guide defines a workflow to allow payers to provide information about coverage requirements to healthcare providers through their provider systems at the time treatment decisions are being made.
- Clinical Data Exchange (CDex): HL7.FHIR.US.DAVINCI-CDEX\Home – FHIR v4.0.1
- CDex allows payers to request only the minimum necessary portion of the patient record in FHIR.
- Documentation Templates and Coverage Rules (DTR): Documentation Templates and Rules Implementation Guide Home Page – Da Vinci – Documentation Templates and Rules v2.0.1
- The Da Vinci Documentation Templates and Rules (DTR) implementation guide provides a mechanism for payers to express their documentation requirements computably in a way that allows clinicians and other EHR users to navigate and quickly specify the needed information in a context-specific way.
- DTR leverages FHIR Questionnaires combined with embedded CQL logic and associated value sets to retrieve existing information, prompt for additional relevant information, and manage the logic process of determining which questions need to be answered (and what answer choices are relevant).
- Prior Auth (PAS): Prior Authorization Implementation Guide Home Page – Da Vinci Prior Authorization Support (PAS) FHIR IG v2.0.1
- Allows provider systems to send (and payer systems to receive) prior authorization requests using FHIR.
Sequence Diagram
This shows the sequence of calls between the provider and the payor.
Technology Needed in the Process
While there are many ways this process can be implemented, we believe the optimal method involves three pieces:
- An EMR to store the patient record and where the doctor creates a new order. This is also where the result of prior authorization is stored.
- A prior auth client app that integrates with the EMR using SMART on FHIR. This app runs on the same computer as the EMR.
- A prior auth cloud service that does the heavy work of communicating with all the payor APIs, converting data to FHIR and running the CQL engine. These functionalities require a lot of CPU, memory and network bandwidth which is not available on the computers that run EMR software.
The prior auth client app communicates with the prior auth cloud service.
Steps in the Process
This process assumes that a prior auth client app has been installed from the EMR’s app store.
Step 1: Is Prior authorization needed for this order?
The first step in the process is to determine if a prior authorization is required by the payer for the service that the doctor is proposing.
This uses the Coverage Requirements Discovery (CRD) implementation guide.
The prior auth client app uses CDS hooks to be notified when a new order is created in the EMR. CDS hooks is a technology that can be used by third-party software to be notified when certain things happen in the EMR.
Once the doctor creates a new order for a patient in the EMR, the CDS hooks notify the prior auth client app.
The prior auth client app can then read the patient’s payor information from the patient’s chart.
The prior auth client app sends this information and the new order to the prior auth cloud service.
The prior auth client cloud service maintains a list of each payor’s API endpoints so it looks up the API endpoint for this patient’s payor.
The prior auth client cloud service converts the order into FHIR and calls the payor API to see if prior authorization is required for this order under the patient’s insurance coverage.
If prior authorization is not needed, then the prior auth client app just shows a message to the doctor in the EMR so they know they don’t need prior authorization for this order.
If prior authorization is needed, then the prior auth client app moves onto the next step.
Step 2: Send the needed documentation to payor
This step discovers the information required by the payor for this particular prior authorization. Then this information is either extracted from the patient record or the doctor answers some questions. The information is then sent to the payor API.
This follows the Documentation, Templates and Rules (DTR) implementation guide.
The payor API sends back a questionnaire in FHIR Questionnaire format and logic in CQL (Clinical Quality Language) format to the prior auth cloud service.
The prior auth cloud service converts the patient’s record in EMR to FHIR.
The prior auth cloud service includes a CQL engine to run the provided CQL on the patient record (converted to FHIR) to retrieve requested parts of the patient record.
If there are questions that cannot be answered after running CQL on the FHIR patient record then the prior auth client app shows a UI to the doctor where they can answer those questions.
All the questionnaire answers (whether calculated with CQL logic or answered by the doctor) are then sent to the payor API in FHIR QuestionnaireResponse format.
Step 3: Receive an authorization or rejection from the payor
This follows the Prior Auth (PAS) implementation guide.
The payor API takes all the documentation provided in previous step and returns either an authorization, rejection, pending or request for (even) more information.
If there is an authorization or rejection then that information is returned in FHIR ClaimResponse format. The prior auth client app should store this in the patient’s chart in the EMR
If the response is Pending then this means the payor system is still processing the request. The prior auth cloud service must keep checking periodically until one of the non-pending responses is received.
If there is a request for more information, then we go back to previous step to either calculate that information or ask the doctor for that information.
Summary
A combination of an EMR, a prior auth client app and a prior auth cloud service can be used to implement electronic prior auth at the care provider.