Healthcare HIPAA Transactions

The APIs included in Availity's HIPAA Transactions product allow your application to exchange HIPAA-compliant X12N transactions. The Availity Partner OAuth2 Provider 1.0.0 API is described in the Authentication section.

Availity Payer List 1.0.4

This API allows you to query the list of available payers and transactions based on your Availity contract.

Configurations 1.0.0

Availity's Configurations API can help save weeks of development time by providing details for each payer Availity supports, as well as the required fields for a specific payer, required field combinations, validation patterns that can be used by your frontend applications, code/values for populating selection groups, and more.

If you've ever tried to support access to multiple health plans in your application, you know how difficult this can be. Although standards such as ASC X12N transactions and HL7 exist, many health plans support these standards at different levels. Traditionally, this would leave the burden on the developer to figure out how to normalize this information across the range of health plans the application must support. Instead, by using the Configurations resource to build your application, you can ensure you always have the most current data and validation requirements for each health plan.

Coverages 1.0.0

Supporting the ASC X12N 270 and 271 transactions (Healthcare Eligibility Benefit Inquiry and Response), this API allows you to find and manage a member's coverage information.

Service Reviews 2.0.0

Find, create, and manage authorizations to perform a healthcare service or refer a patient to another provider with this API, which enables the ASC X12N 278 transaction (Health Care Services Review – Request for Review and Response).

Claim Statuses 1.0.0

This API enables the standard ASC X12N 276 and 277 transactions (Health Care Claim Status Request and Response), which allow you to find, create, and manage claim status information.

Care Cost Estimator – Professional and Care Cost Estimator – Institutional

A care cost estimator (CCE), also known as a predetermination, is a claim request for payment that a healthcare provider submits to a health plan before it has provided a service or items to a member. Claim predeterminations allow patients to learn early whether a particular healthcare service is covered by their health plan. Your application can use the Professional or Institutional Care Cost Estimator API to submit a claim predetermination and to find and manage previous claim predetermination requests.

Availity offers two Care Cost Estimator APIs: Professional (for physicians, suppliers, and other non-institutional providers) and Institutional (for hospitals, skilled nursing facilities, and other institutions).

Add-On API products

Enhanced Claim Status (claim-status 1.0.0 )

Enhanced Claim Status supports both the HIPAA 276/277 transaction as well as several proprietary requests to gather additional claim status information. With Enhanced Claim Status, health plans can add additional summary and detail search options and customize the X12N 277 response with additional information fields, including remark codes and descriptions, amount fields (deductible, discount, copay, co-insurance, patient responsibility), group number, line of business, provider type (rendering, billing), and many more.

Service Reviews Add-On APIs

Availity offers two add-on APIs that work in conjunction with the Service Reviews API to enhance the ASC X12N 278 transaction:

Eligibility & Benefits Value-Add APIs

Availity offers two APIs that add functionality to the eligibility and benefits (ASC X12 270/271) transaction:

Input validation and sanitization

Availity has implemented whitelist rules for data validation that are carefully designed to provide protection even against future vulnerabilities introduced by browser changes. If you send a request to an API that contains characters that we've determined to be unsafe, you'll receive an HTTP 400 response with an inbound injection error message. You must fix the data and resubmit your request. The best way to avoid receiving this error is to ensure that you use proper input validation and sanitization on your side before calling an API.

Response resource encoding

Different encoders exist for each given context; i.e., an HTML body string encode isn't the same as a JavaScript string encode. This is where problems can arise, as XSS attacks also vary from context to context. If encoding isn't done properly for the context in which you're displaying the data, an attack can slip through.

Availity does not provide response resource encoding for an API by default. To take advantage of encoding, you must opt in by sending an X-Response-Encoding-Context request header with one of the following values:

Availity recommends that you use the appropriate response encoding context if you will be displaying API resources directly in your application.

Encoding examples

Below is an example request to the Configurations API showing a partial resource returned using the HTML encoding context. The providerNpi.errorMessage object appears because the message contents that contain () characters are escaped for use in HTML.

curl -X "GET" "https://api.availity.com/availity/v1/configurations?type=270&payerId=700" -H "Authorization: Bearer abc12345" -H "X-Response-Encoding-Context : HTML"
configurations[0].providerNpi.errorMessage = "Enter a valid National Provider Identifier (NPI) containing 10 numeric digits and beginning with a 1, 2, 3, or 4."

Pagination

When a collection resource contains a large number of resource instances, all of them may not be included in a single response. Instead, pagination breaks up the results into one or more pages of data. You can request additional pages as separate requests. Here's an example of a collection resource partial response:

{
  "totalCount": 19,
  "count": 5,
  "offset": 0,
  "limit": 5,
  "links": {
    "last": {
      "href": "https://api.availity.com/availity/v1/coverages?limit=5&offset=14"
    },
    "next": {
      "href": "https://api.availity.com/availity/v1/coverages?limit=5&offset=5"
    },
    "self": {
      "href": "https://api.availity.com/availity/v1/coverages?limit=5"
    }
  },
  "coverages": [
    {
      "customerId": "1194",
      "batchId": "14029438773180168889579000001660",
      "controlNumber": "1-1020",
      "status": "Communication Error",
      "statusCode": "14",
      "createdDate": "2017-07-16T18:38:12.000+0000",
      "updatedDate": "2017-07-16T18:38:12.000+0000",
      "expirationDate": "2017-07-16T19:07:23.000+0000",
      "asOfDate": "2017-02-03T05:00:00.000+0000"
    },
    {
        ...
    }
  ]
}

Query parameters

Availity APIs use cursor-based pagination with two optional query parameters:

Link relations

Availity Client Services

For questions, assistance, and support, log in to Availity Essentials and submit an online support ticket (24/7) by navigating to Help & Training > Availity Support on Availity Essentials. Or contact an Availity Client Services representative at 800-282-4548 (800-AVAILITY).

Days of operation: Monday through Friday

Getting started

Why do I need to create an app?

An app, or application, is the link between your organization and Availity's authentication system and API subscription plans.

When you create an application, you receive both a client ID and client secret. (Make note of both items, but especially the client secret, as this is the only time you will see it.) You must supply the client ID and client secret when you call our OAuth 2 authentication API. An authentication (bearer) token will then be returned to you which is valid for 5 minutes. Use that token to make subsequent calls to our API endpoints. See the Authentication section of the Availity API Guide for more information.

What are Availity's API subscriptions, and how do I use them?

To use Availity's APIs, you must subscribe to a plan from your App. There are generally two types of subscriptions: Demo and Standard.

The Demo plan is the best starting point because it allows users to test and establish connectivity with our API endpoints, understand the flow of API calls, and generally get acquainted with our system. Availity automatically approves subscriptions to the Demo plan, which provides access to a sandbox environment and canned responses for each of the API endpoints. It does not allow for end-to-end testing or testing with any live data.

Once you have explored the Demo system, you can work with your Trading Partner Manager to set up your contract and upgrade your organization to the Standard Plan. The Standard plan gives full access to the REST APIs and data. See Getting Started for more information.

Why am I getting a 429 response code to all my API requests?

Both subscription types have two different transaction limits – a maximum allowed per second and a maximum allowed per day – as follows:

• Demo: limited to 5 transactions per second and 500 per day
• Standard: limited to 100 transactions per second/100,000 per day

A 429 response code indicates that you have exceeded one of these transaction limits. If you have exceeded the per-second limit, you can resume sending transactions after one second. If you have exceeded the per-day limit, you will be able to resume sending transactions at midnight UTC.

Availity does not have the capability to override these limits manually on an as-needed basis. If you consistently exceed your transaction limits on the Standard plan, please contact your Availity Trading Partner Manager to discuss a solution.

What happens if I forget or lose my client secret?

Your application client secret is stored as an encrypted value, and Availity cannot retrieve the unencrypted version to tell you the value. However, you can reset the client secret for your app, which will update the stored value and return the new value to you:

1. Click Apps in the main menu, and then click the application in question.
2. Click the Reset link in the Client Secret section.
3. Make a note of the new client secret displayed at the top of the page. Use this new value to authenticate going forward.

Enhanced Claim Status

What is the Sender Number/SenderID required by Florida Blue?

Some users have reported receiving the following error message when requesting Enhanced Claim Status information from the payer Florida Blue:

A sender number is needed for this function. Please obtain a check
 or EFT number from a Florida Blue payment within the past 90 days and contact
 Availity Client Services at 1-800-282-4548 for assistance.

You can request a Florida Blue Sender Number/SenderID through Availity. Call Availity Client Services (ACS) at 1-800-282-4548 and supply the following information:

• Organization type
• Organization name
• Organization physical address
• Tax ID (Ensure that this ID is associated with the Florida Blue Provider ID)
• Best contact phone number
• Name of the Availity user requesting the Sender ID
• Email
• Availity Customer ID
• Florida Blue Provider ID
• Florida Blue check number
• Check amount
• Check date
• Pay-to address  

Payer approval typically occurs within 24-48 hours. Once approved, the SenderID will appear in View Identifiers/Organization Identifiers on the Availity Essentials portal for you to capture and use in transactions.

I'm working with the Configurations API for Enhanced Claim Status and the response indicates that the payer does not support the HIPAA_276 or the VALUE_ADD_277 subtypes. How can I request Enhanced Claim Status data from this payer?

If the payer supports the MEMBER_ID option, follow these steps for best practice:

1. Run an Enhanced Claim Status Summary call.

   This a proprietary call that does not use the 276/277 transaction, but returns high-level claim information as well as multiple claims.

2. Next, run an Enhanced Claim Status Detail call with the claim number returned in the MEMBER_ID summary response from Step 1.

   This a proprietary call that does not use the 276/277 transaction, but returns detailed claim information for a single claim. See the Enhanced Claim Status reference documentation for more information.