Availity

Availity is how an authorization request actually reaches a payer. The trading relationship is yours, and we submit under it, so the payer sees your organisation rather than ours.

#Before you start

• An Availity account for your organisation, with an administrator who can create a developer application.
• A subscription that covers the transactions we send. The default scope is healthcare-hipaa-transactions, which covers both Service Reviews (the authorization itself) and Coverages (the eligibility check that decides whether an authorization is even needed).
• About fifteen minutes.

#Steps

1. Create a developer application in Availity
   In your Availity developer portal, register an application. Availity issues a client id and a client secret for it.
2. Copy the client id and secret
   The secret is shown once by Availity. If you lose it, regenerate it there rather than guessing.
3. Open Settings, then Connections
   Choose Availity and paste the client id and the client secret.
4. Add a customer id only if you were given one
   Some organisation structures require it; most do not. Leave it blank unless Availity told you otherwise.
5. Save
   We request a token with those exact values. If Availity refuses them, nothing is stored and the reason is shown.

#What we ask for

#When it does not work

Availity refused these credentials

The client id or the secret is wrong, or the application was deleted in the Availity portal. Nothing was stored, so simply correct and save again.

Authorizations submit but eligibility does not

Your subscription probably covers Service Reviews but not Coverages. They ride the same product, so this is a subscription question for Availity rather than a settings change here.

It worked and then stopped

Secrets in the Availity portal can be rotated or expired by your own administrator. Re-validate the connection from Settings; if it fails, issue a new secret in Availity and paste it here.

#Connecting is not the same as going live

Saving a valid credential proves the connection works. It does not start sending real transactions to payers. Moving your practice onto the live rail is a separate, deliberate change with its own audit trail, and it happens once you are ready and the trading partner agreement is in place.

1. Connected
   Your credentials are stored and proven. Authorizations are still produced against a simulator, so you can walk the whole workflow without anything reaching a payer.
2. Live
   Your practice is switched to the live clearinghouse. From that point every request carries your own credentials and reaches Availity under your organisation.