Availity Integration: Switch from REST to SOAP APIs Save 60% on Insurance Eligibility Verification

60% Reduction in Medical Insurance Verification Costs with SOAP APIs

Availity, a leading healthcare clearinghouse, enables real-time patient insurance eligibility and coverage verification across multiple insurance providers. Through Availity integration capabilities, patients can confirm their insurance eligibility status and coverage details from payers. They expose their APIs, which can be called to retrieve the required information.

Our client had a web application that used Availity’s REST APIs to check insurance coverage, but the cost was too high. Technosoft switched from REST to SOAP-based APIs to enhance the insurance eligibility verification process for the web application serving patients, providers, and clinics in partnership, resulting in lower costs for the client.

The Challenge

The client’s web application, used by patients, providers, and partner clinics, was generating high costs when verifying insurance coverage. The application checked if a patient’s insurance plan covered specific medical services, such as surgeries, check-ups, or lab tests, by sending patient parameters like name and date of birth to Availity via REST APIs. Although Availity provided the necessary information, their REST APIs were expensive, leading us to seek a cost-effective solution that could integrate seamlessly with the existing infrastructure. The primary challenge was the high costs associated with Availity’s current REST APIs resulting in increased monthly and yearly bills for the client.

Transition to SOAP-based Integration

In response to the high costs associated with Availity’s current REST APIs, the decision was made to replace them with SOAP (Simple Object Access Protocol) APIs. Availity’s SOAP integration provided a cost-effective alternative, replacing the REST APIs from the existing implementation.

Integration Process

The integration process began with registering with Availity, leveraging their sandbox environment for testing. Unlike REST APIs, SOAP uses XML-based messaging and requires specific libraries for creating and parsing these messages. Our team utilized the node-soap library in our Node.js technology stack to handle SOAP messaging, ensuring seamless communication between systems. With the necessary tools in place, we began testing in the Availity sandbox, sending SOAP messages and processing responses to refine our integration.

Registering with Availity

• Signed up on Availity’s website
• Filled in the required fields with company and business-specific information
• Submitted the registration request and waited for approval
• Received sandbox credentials upon approval
• Requested SOAP service activation, as it is not enabled by default

Payer-Based Soap Eligibility

After setting up our account, we followed these steps to enable payer-based SOAP eligibility:

Step 1: Identify Payers Supporting SOAP

We identified which payers supported SOAP and which did not. Availity provided a list of payers with a column indicating whether SOAP was enabled for each.

Step 2: Check SOAP Enablement

We checked the list to see if SOAP was enabled for each payer. Some payers had SOAP enabled by default, while others required enrollment.

Step 3: Enroll in Required Payer

We enrolled in the required payer to enable SOAP. This involved clicking on the “Enrollment Required” link, which redirected us to the payer that required enrollment. After completing the necessary contracts and steps, SOAP was enabled for those pairs.

Step 4: Request Eligibility Verification

Finally, we requested eligibility verification only for the pairs that had SOAP enabled. We made sure to request eligibility verification only for the payer that supported SOAP, to avoid any errors or issues.

By following these steps, we successfully enabled payer-based SOAP eligibility and completed our integration with Availity’s system.

Transition to Production Environment

Once we had access to the account, enabled SOAP, and created the required payload, we utilized the sandbox environment to test our integration. The sandbox environment had certain capabilities and limitations.

Sandbox Capabilities

• Verified the structure of our SOAP payload
• Checked for required fields, authentication, and password verification

Sandbox Limitations

• Did not support actual eligibility verification

After validating our setup in the sandbox, we transitioned to the production environment to perform actual eligibility verification. We submitted our payload and received the accurate eligibility verification results in the production environment. We followed Availity’s B2B services documentation, which provided the exact format of SOAP messages required. By adhering to this format and leveraging the sandbox environment for preliminary testing, we ensured a successful transition to production, resulting in a 60% cost reduction.