Getting Started with OAuth 2.0

OAuth 2.0 is an industry-standard protocol for authorization that allows users to grant limited access to their resources on one website to another website without sharing their credentials. It provides a secure and standardized way for applications to authenticate and authorize users.

Registering application

Before you can start using OAuth 2.0, you need to register your application with VerifyTreatment. Please send your registration request to [email protected] to obtain your client credentials, including a client ID and client secret.

Obtain an Authorization Grant

OAuth 2.0 supports multiple authorization flows, each designed for different use cases. VerifyTreatment limits 3rd party access to following flows:

1. Authorization Code Flow: This flow is suitable for server-side applications that can securely store client secrets. It involves exchanging an authorization code for an access token.
2. Client Credentials Flow: This flow is used by applications that need to access resources on behalf of themselves rather than a specific user. It involves directly exchanging client credentials for an access token.

Authorization Code Flow

The authorization code flow is a "three-legged OAuth" configuration. It involves three parties: the user (resource owner), the client (application), and the server (VerifyTreatment). Initially, the user obtains an authorization grant, which is then exchanged for an access token by the client.

Step 1: Authorization Request

The client initiates the flow by directing the user to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied).

Step 2: User Authorizes Access

When the user clicks the link, they must first log in to VerifyTreatment, then will be prompted to authorize or deny the client's request to access data. If the user clicks authorize, VerifyTreatment redirects the user-agent to the client's redirection endpoint provided earlier. The redirection URI includes an authorization code and the client's local state.

Approved request:

Denied request:

Step 3: Exchange the Authorization Grant for an Access Token

Once you have obtained the authorization grant, you need to exchange it for an access token. The exact process depends on the chosen flow.

Authorization Code Flow:

Client Credentials Flow:

Accessing Protected Resources

Refresh Access Token

VOBs

Create / Search benefits

You can create a new VOB by sending a POST request to the /vobs endpoint. The facility and payer_id fields are required to complete the configuration request.

List All VOBs

View Vob

Update VOB

Delete VOB

Re-Verify VOB

History

Subscriber Relations

Exporting Data

Export single vob as PDF

Export all vobs

Requires access to VerifyTreatment export subscription

Importing Data

Import batch data

You can import / update batch data by sumbitting a CSV file

Batch Eligibility

Automatically re-verify vobs

VerifyTreatment provides two options for batch eligibility verification: Auto VOB Monitoring and Run Now.

Auto VOB Monitoring method re-verifies each VOB record when the "Client Type" field is set to "client," according to the specified schedule and settings.

Run Now method enables the user to generate a one-time batch eligibility report.

Please note that the VerifyTreatment Automate Subscription is require to access this feature.

{
  "vob_status": "VOB_STATUS", // optional defaults to client
  "vob_coverage": "COVERAGE_STATUS", // optional
  "tag": "OPTIONAL_VOB_TAG", // optional
  "vob_last_update": "LAST_UPDATED_DATE (YYYY-MM-DD)", // optional
}

Payers

Configuration API

Each insurance company requires a unique combination of patient/provider details. For example, some insurance companies may require less information than others.

The configuration API allows you to look up all the required fields for a specific payer.

Tip: Sometimes the insurance company may allow you to submit requests using only the patient's first name, last name, and date of birth. However, you may still receive a "Patient Not Found" error message, even if you have verified the information. In these cases, you will still need to submit the request using the Member ID

Facilities