
Setup
1
Create Credentials
Create a client ID and client secret in the Sohar dashboard.
Create credentials for the sandbox environment to get started quickly without the need for actual patient data.
2
Configure Webhooks
Configure a webhook endpoint to listen for events. If you are using the sandbox environment, subscribe your endpoint to the
sandbox.verification.updated
event. If you are using the production environment, subscribe to the verification.updated
event.Workflow
The diagram below outlines the workflow we will build to take your patient through the intake flow and handle the response from Sohar.
1
Collect patient data
2
Call the Create Verification API
3
Handle webhook events and call the Get Verification API
4
Use the Sohar response to handle routing logic
Collect Patient Data
Create an interface to capture the following information at minimum:- First Name
- Last Name
- Date of Birth
- State (2-letter code, e.g. CA)
- Payer ID
- Member ID
Create a Verification
Pass the information collected in the previous step to the Create Verification API. You will also need to specify theplaceOfServiceCode
and specialtyCode
. In this example we are interested in benefits information for a telehealth consultation (place of service code 10
) with a psychotherapist (specialty code PSY
).
Handle Webhook Events
Once the Verification request is complete, the response will be posted to all subscribed webhook endpoints. This is an example of theverification.updated
and sandbox.verification.updated
webhook payloads:
You can store the Sohar response in your system for data analytics purposes, or load it into external systems such as your EHR.
Patient Routing
Depending on the response you receive from Sohar, it might make sense to route the patient to different flows. The flows detailed below are most commonly used when integrating with Sohar.
Schedule Consultation
This is the ideal outcome. The status iscomplete.eligible
, indicating that the request is complete, the patient has active coverage and they are eligible for the requested service. The patient can proceed through the intake funnel - often the next step is to schedule their initial consultation.
Request Alternative Insurance
The statuscomplete.ineligible
indicates that the request is complete but the patient either doesn’t have active coverage or they are not eligible for the requested service. Perhaps their coverage has lapsed or they are using an outdated member ID. In this instance it might make sense to ask the patient if they have alternative insurance information.
If the patient is able to provide alternative information, this information can be submitted to the Create Verification API.
Review Intake Data
A member error status indicates that there was something wrong with the information submitted by the patient. This could either be anerror.member.id
status, an error.member.name
status or an error.member.dob
status. Ask the patient to review the information they submitted, and if they are able to correct any mistakes then the updated information can be submitted to the Create Verification API.
Manual Workflow
There are two types of payer error status that can be returned.error.payer
indicates that the payer has been unavailable for at least 24 hours - it is unlikely that you will see this status returned during patient intake. error.payer.npi
indicates that the payer doesn’t recognise the NPI that Sohar included in the request. Here is some information about how to manage providers in your account in order to avoid this response. We typically see customers implement manual workflows to handle this status or any other unexpected response. This might involve contacting the patient to clarify the information they submitted.