Prior authorization is a crucial process in healthcare that involves approving medical treatments or procedures before they are performed. This process is necessary to ensure that patients receive appropriate care and that healthcare providers follow correct procedures. However, prior authorization can be a complex and time-consuming process with a lot of paperwork and communication between healthcare providers, insurance companies, and patients.
The prior authorization process for the electronic health record (EHR) consists of five steps:
- Determine if prior authorization is required.
- Collect the information necessary to support the prior authorization request.
- Submit the prior authorization request.
- Monitoring of the prior authorization request for resolution.
- If necessary, supplement the prior authorization request with any additional information required (and continue to Step 4).
Da Vinci’s load reduction The project has reorganized these steps for prior authorization into three interrelated implementation guides that focus on reducing physician and payer burden:
- Coverage Requirements Discovery (CRD) – This provides decision support for providers as they request diagnoses, specify treatments, make referrals, schedule appointments, etc.
- Documentation Templates and Rules (DTR) – This allows providers to download questionnaires and smart rules, such as Clinical Quality Language (CQL), and provides a SMART FIR application or EHR application that runs questionnaires and rules to collect information relevant to a performed or planned service. Running the questionnaires and rules can also be done through an application that is part of the provider’s EHR.
- Prior Authorization Support (PAS) – This allows provider systems to send (and payment systems receive) pre-authorization requests using FHIR, while still meeting regulatory mandates to use X12 278, when necessary, to transport pre-authorization, potentially Simplifies processing for either (or both) exchange partners. ).
In this post, we focus on the CRD implementation guide for determining prior authorization requirements and explain how CDS (Clinical Decision Support) Hooks uses AWS HealthLake to determine whether prior authorization is required or not.
Solution Overview
CRD is a protocol within the electronic prior authorization workflow that facilitates calls between EHRs and payers using CDS services. When used, it provides information about coverage requirements to providers as they make decisions about patient care. This allows provider staff to make more informed decisions and meet their patients’ insurance coverage requirements. Interaction between providers and payers is seamless using CDS Hooks.
CDS Hooks is a Health Level Seven International (HL7) specification. CDS Hooks provide a way to incorporate additional functionality in near real-time within a clinician’s workflow of an EHR. With CDS Hooks, eligibility practices such as prior authorization can be appropriately streamlined, along with other precertification requirements such as physician network participation. This feature helps providers make informed decisions by providing them with information about their patients’ condition, treatment options, and forms that need to be completed to facilitate their care. Strategic use of CDS Hooks allows physicians to quickly develop more patient-centered care plans and assist in the prior authorization process by revealing critical clinical and administrative requirements. For more information on CDS hooks and their specifications, see CDS Hooks website.
The following diagram illustrates how the CRD workflow is automated using HealthLake.
The workflow steps are as follows:
- A provider staff member logs into the EHR system to open the patient’s record.
- The EHR system validates the user’s credentials and invokes the patient view link to retrieve information about the patient’s status.
- Amazon API Gateway invokes the Patient View Hooks AWS Lambda function.
- The Lambda function validates and retrieves the patient ID from the request and obtains the patient status information from HealthLake.
- After reviewing the patient’s condition, the user invokes the order selection link to retrieve information about the coverage requirements for the respective medication.
- API Gateway invokes the Coverage Requirements Bindings Lambda function.
- The Lambda function retrieves claims information for the patient, executes CQL rules based on the submitted medication and the claims information retrieved from HealthLake, and determines whether prior authorization is required.
The solution is available in the Determine coverage requirement discovery using CDS Hooks with AWS HealthLake GitHub repository.
Previous requirements
This publication assumes familiarity with the following services:
Deploy your application using the AWS SAM CLI
You can deploy the template using the AWS Management Console or the AWS SAM CLI. To use the CLI, complete the following steps:
- Install the AWS SAM CLI.
- Download the sample code from the AWS Examples repository to your local system:
git clone https://github.com/aws-samples/aws-crd-hooks-with-awshealthlake-api
cd aws-crd-hooks-with-awshealthlake-api/
- Create the application using AWS SAM:
sam build
- Deploy the app using the guided process:
sam deploy --guided
# Replace MY_VALUE with proper resource names
Configuring SAM deploy
======================
Looking for config file (samconfig.toml) : Not found
Setting default arguments for 'sam deploy'
=========================================
Stack Name (sam-app): aws-cds-hooks-with-healthlake
AWS Region (us-east-1): us-east-2
#Shows you resources changes to be deployed and require a 'Y' to initiate deploy
Confirm changes before deploy (y/N):
#SAM needs permission to be able to create roles to connect to the resources in your template
Allow SAM CLI IAM role creation (Y/n):
#Preserves the state of previously provisioned resources when an operation fails
Disable rollback (y/N):
cdsDemoServicesFunction has no authentication. Is this okay? (y/N): y
cqlQueryFunction has no authentication. Is this okay? (y/N): y
cqlQueryOrderFunction has no authentication. Is this okay? (y/N): y
Save arguments to configuration file (Y/n): y
SAM configuration file (samconfig.toml):
SAM configuration environment (default):
Deployment may take 30 minutes or more while AWS creates a HealthLake data store and related resources in your AWS account. AWS SAM may time out and return you to its command line. This timeout prevents AWS SAM from showing you cloud progress, but it does not stop cloud deployment. If you see a timeout, go to the AWS CloudFormation console and check the CloudFormation stack deployment status. Integrate CDS Hooks with your clinical workflow when the CloudFormation stack implementation is complete.
Determine coverage requirements for prior authorization
The solution has two hooks, patient view and order selection, to determine whether or not prior authorization is required based on the payer’s prior authorization rules. CQL is used to evaluate prior authorization rules.
CDS Hooks can be integrated with EHRs that support CDS Hooks. Alternatively, if you do not have EHR available for testing, you can use the publicly available testing environment as described in the GitHub repository. Please note that the CDS Hooks sandbox is used for testing purposes only.
Once hooks are integrated with the EHR, when a user navigates to the clinical workflow, the patient view hook runs for the configured patient. Please note that the clinical workflow patient ID must exist in HealthLake. The cards returned by the API indicate that the patient has a sinus infection health condition and the doctor may need to order a prescription.
You can navigate to the RX view tab to request a prescription. Acting as a doctor, choose the appropriate medicine and enter other details as shown in the screenshot below.
The order pick hook is returned with the pre-authorization eligibility card.
The next step is to submit prior authorization through the SMART app or other mechanisms available to the provider.
Clean
If you no longer need the AWS resources you created by running this example, you can remove them by deleting the CloudFormation stack you deployed:
sam delete --stack-name <<your-stack-name>>
Conclusion
In this post, we show how HealthLake with CDS Hooks can help reduce provider burden and improve member experience by determining coverage requirements for prior authorization as part of the clinical prescription ordering workflow. CDS Hooks along with HealthLake can assist providers in ordering diagnoses, specifying treatments, making referrals, and scheduling appointments.
If you are interested in implementing coverage requirements discovery on AWS using this solution or would like more information about implementing preauthorization on AWS, you can contact a AWS representative.
About the authors
Manish Patel, a global partner solutions architect supporting healthcare and life sciences on AWS. He has more than 20 years of experience building solutions for Medicare, Medicaid, payer, provider and life sciences clients. He drives commercialization strategies together with partners to accelerate the development of solutions in areas such as electronic health records, medical imaging, multi-model data solutions and generative artificial intelligence. He is passionate about using technology to transform the healthcare industry and achieve better patient care outcomes.
Shravan Vurputoor He is a Senior Solutions Architect at AWS. As a trusted customer advocate, he helps organizations understand best practices around advanced cloud-based architectures and advises on strategies to help drive successful business outcomes across a broad set of enterprise customers through his passion for educating , train, design and build the cloud. solutions.