Healthcare prior authorizations eats up a lot of our time. While prior authorizations are not needed for all specialties, many of our healthcare providers (orthopedic surgeons, ophthalmology practitioners, dental providers etc) do require a LOT of insurance prior authorizations to be processed.
Much like Amazon Web Services, our goal is to pass on cost savings to our healthcare customers. The more we leverage AWS and combine our healthcare business domain expertise, the more cost savings and healthcare workflow optimizations we discover.
In case you didn’t know, here’s how healthcare prior authorizations work in healthcare:
- A patient is seen for a “reason” or “chief complaint”.
- The patient is diagnosed with “something” by the doctor (provider and doctor are used interchangeably). This diagnosis translates to an ICD code.
- Based on the diagnosis, a certain procedure (can be a surgery as well) needs to be performed by the doctor. This needs to be administered to the patient. This procedure translates to a CPT code.
- Since this procedure might not be the “usual” kind of procedure, the doctor wants to know that they would get paid for performing the procedure / CPT code.
- The doctor’s office (medical practice) needs to submit a prior authorization request to the insurance company of the patient (payer) using specific forms. This submission also includes documentation to establish the medical necessity of the CPT in question.
- Some insurance payers have a website to submit the prior authorization requests. Some payers only accept it via fax.
- Some procedures do not need a prior authorization. Some procedures always require a prior authorization. However, the decision tree of which procedure / CPT needs a prior authorization vs not also changes from time to time and is entirely up to the insurance company / payer. So, it is in the best interests of most medical practices to submit prior authorization requests for everything – to cover all bases.
- Of course, as one can imagine, this increases the load of processing PA requests on both the payer and the provider sides… and the cycle continues..
- The payer responds back with a decision within a couple of days – approved or denied. Sometimes, the payer (understably so, because they too have medical professionals on their own staff) requests further documentation from the doctor’s office.
- If it is denied, the doctor’s office tries to appeal the decision. If the payer wants more documentation, the doctor’s office gathers all the documentation and resends the fax or resubmits the prior authorization application on the website.
- Then, they wait for the requisite number of days or call the payer to get an answer / decision.
- Based on the prior authorization decision of the payer, the next steps are determined. If the prior authorization was denied, then the doctor has a choice to recommend another procedure (or surgery). The doctor might feel that the recommended procedure is the only possible way to address the “most responsible diagnosis” and might still want to proceed with their recommended procedure. In this case, the patient has to decide whether they want to pay out of pocket for this procedure or not.
- Sometimes, based on the delays involved in processing prior authorization requests, the medical office might need to reschedule patient appointments as well – in the best interests of the patient and the provider office.
- This is a laborious process – end to end. On top of this, a member (or members) of the medical billing / revenue cycle management team has to check the fax machine or the website for the payer’s decision. More often than not, this arrives via a fax.
- If there is an approval from the payer side, this usually includes the start and end dates of the prior authorization validity. It also includes a prior authorization number to be used in the associated claim (once the CPT is submitted along with the ICDs in a claim).
- So, the revenue cycle management team has to scan the fax (or the website PDF), attach it to the patient visit record in their EMR/EPM. They also have to add the prior authorization note to the patient visit record so that the medical coders and medical billing staff can use it in their claim submission (and later, if needed, with the payer reps to buttress their claim).
As you can see, this is labor intensive and therefore increases practice management costs significantly.
How can you save money on medical prior authorization requests?
If you are a provider, you cannot do anything on the payer side of things, of course.
You can, however, save time and money you spend on filling/refilling out prior authorizations request forms.
You can also save time and money you spend on monitoring the fax machine, updating your EMR with prior authorization details.
If you spend 15 mins per prior authorization form and process 20 prior authorizations per day – this means that you are spending 15*20 = 300 mins or 5 hrs per day processing prior authorizations alone.
This is where you can save time and therefore money.
Here’s an example of what a prior authorization form looks like. You know very well that you have to open up your EMR or EPM in one browser window, manually copy / paste each field into this prior authorization form (even if you are doing this on the payer’s web portal). Then you have to save this form and fax it (or upload to the payer’s web portal).
That alone takes a good 10-15 mins to complete, per prior authorization request.
Here’s an example of an approved prior authorization form
Sometimes authorization is not required and you get a response back like below
The fax cover sheets are almost always the same.
The format of denials are the same
The format of approvals are the same.
Unless you are using an electronic prior authorization software, you are doing all these things manually.. And wasting time + money.
How Amazon Textract and AWS Step functions can help you
Just like MANY organizations are doing – you could be using robotic process automation (RPA) to automate workflow, back-office processes that are labor-intensive. RPA will allow you to cut down on the labor intensive process of filling out the forms.
RPA is just a software bot.. It takes the repetitive tasks that your practice management staff does and automates those things. Simple.
This way, your practice management HUMANS can oversee the things that software does, ensure quality outcomes and increase their own productivity immensely. This way, you leverage human capital for their “human touch” and not to do “donkey work”.
AWS Step Functions is a serverless function orchestrator and workflow automation tool. It’s pretty amazing what AWS Step functions can orchestrate and automate for you.
The other thing you are going to need is Amazon Textract. Textract is brilliant !
While optical character recognition technology (OCR) has been around for ages, Textract can automatically extract printed text, handwriting, and other data from scanned documents. Keep in mind that this goes beyond simple optical character recognition (OCR) to identify, understand, and extract data from forms and tables. OCR can do many things – but not to the extent that Amazon Textract can.
On top of it – unlike Tesseract servers, Amazon Textract is a fully managed machine learning service that automatically extracts text and data from scanned documents.
Combine the power of AWS Step functions and Amazon Textract – and you can run your practice on steroids. Keep the same number of staff and see your patient volume grow. Repurpose your staff to more patient facing functions.. Therefore improving your practice reputation even more.
If you are using NisosHealthCRM, you wouldn’t have to fill out any of the prior authorization forms at all. You would simply select the patient, and choose the form you want to fax, like this.
If you were running an eligibility check beforehand, you wouldn’t have to do anything but use a form like this.
So, all you have to do with Amazon Textract is to attach it to an AWS S3, let AWS Lambda kick off the extraction of data using Amazon Textract, then notify you via Amazon SNS about the success or failure of the job.
Here’s a wonderful example of this solution with invoices (instead of prior authorization request forms).
Just like in the blog above, the steps are (slightly extended):
- Faxes received are converted into PDFs (almost every fax server can do that these days) and uploaded to an AWS S3 bucket.
- If you are unfortunately unable to get faxes and are still receiving PA responses via postal mail, those are also scanned and uploaded to the same AWS S3 bucket.
- If you are processing prior authorizations via the payer’s web portal, those responses are also available to be saved to your desktop as a PDF. These are also uploaded to the same AWS S3 bucket.
- So, basically, ALL prior authorization payer responses are scanned and loaded into an Amazon Simple Storage Service (S3) bucket.
- As soon as a PA response PDF is uploaded, an Amazon S3 trigger kicks off an AWS Lambda function.
- The only thing that this AWS Lambda function does is to start an asynchronous Amazon Textract job to analyze the text and data of the scanned prior authorization request.
- Once the Amazon Textract job finishes, it publishes a completion notification message with a status of “SUCCEEDED” or “FAILED” to an Amazon Simple Notification Service (SNS) topic.
- In turn, Amazon SNS sends this SUCCEEDED / FAILED message to an Amazon Simple Queue Service (SQS) queue that is subscribed to the SNS topic.
- This message in the SQS queue, in turn, triggers another AWS Lambda function.
- This is not the same AWS Lambda function as in the prior step. This particular AWS Lambda function initiates an AWS Step Functions state machine. The AWS Step function state machine then processes the results of the Amazon Textract job.
- If the Amazon Textract job has completed successfully, the AWS Lambda function will save the document analysis into an Amazon S3 bucket.
- Once the above mentioned AWS Lambda function has loaded the document analysis to the designated Amazon S3 bucket, this triggers another Lambda function to process this.
- This AWS Lambda function then goes ahead and retrieves the text and data of the scanned prior authorization response file to find the response information (refer to the images above).
- Keep in mind that each payer has a different response format for their prior authorization request decisions.
- This AWS Lambda function then writes the response information to an Amazon DynamoDB table. It also writes the status indicating whether the prior authorization request has been processed or not.
- If the prior authorization request processing has been successful, then the PA document needs to be archived. So, we attach another AWS Lambda function to the Amazon DynamoDB table insert operation. If the Amazon DynamoDB item contains the approval / rejection information, this AWS Lambda function is invoked.
- This other Lambda function archives the processed payer response to your prior authorization request into another AWS S3 bucket and gets it out of the way.
- If by chance the payer response was NOT positive, you still have a chance to appeal it (as you should anyway). In this case, the Amazon DynamoDB row does not contain the APPROVED record. For any record that doesn’t contain APPROVED – a message is published to an Amazon SNS topic requesting that the prior authorization response be reviewed by your staff.
- Once your staff reviews the response, the next step is to send an appeal fax / document and wait for the response. Then, the whole process as mentioned above starts over again.