Eligibility checks

You can send real-time eligibility checks to payers by:

• Performing manual eligibility checks in the Stedi app.
• Calling one of Stedi’s APIs to send eligibility checks programmatically.

Stedi returns the payer’s synchronous benefits response in real time, which contains information about the patient’s coverage, including covered services, deductibles, and copays.

​

Use the Stedi App

Manual eligibility checks can be useful for testing and for situations when you need to do a one-time eligibility check.

Go to the Create manual eligibility check page in the Stedi app to submit manual eligibility checks and review the full JSON response. You can also sort and filter a more user-friendly response organized by coverage type and level.

​

Use the API

Call one of the following endpoints to send 270 eligibility checks to payers:

• Eligibility Check to send requests in JSON
• Eligibility Check Raw X12 to send requests in X12 EDI

Stedi automatically applies various repairs to help your requests meet X12 HIPAA specifications, resulting in fewer payer rejections.

​

Headers

You must include the following Stedi-specific headers in your API request:

• Authorization: Generate an API key to use for authentication.
• Content-Type: Set to application/json.

curl --request POST \
  --url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3 \
  --header 'Authorization: <api-key>' \
  --header 'Content-Type: application/json' \

​

Body

The information you provide to the payer in an eligibility check can vary, depending on the circumstances. You can review a list of all possible request fields in the Eligibility Check endpoint documentation.

However, each eligibility check must include the following information in the request body:

The following example shows the bare minimum request body for an eligibility check. Because the dateOfService is not specified, the payer will use the current date in their timezone (default) to retrieve benefits information.

{
  "controlNumber": "123456789",
  "tradingPartnerServiceId": "AHS",
  "encounter": {
    "serviceTypeCodes": ["78"]
  },
  "provider": {
    "organizationName": "ACME Health Services",
    "npi": "1234567891"
  },
  "subscriber": {
    "dateOfBirth": "19000101",
    "firstName": "Jane",
    "lastName": "Doe",
    "memberId": "1234567890"
  }
}

​

Sample request and response

The following request and response examples show a basic eligibility check for a patient named Jane Doe. The request uses the MH service type code to check for mental health benefits. It also includes the patientId, which is a unique identifer Stedi uses to identify and correlate historical eligibility checks for the same individual.

​

Patient information

All payers are required to be able to search for patients using the following “bare minimum” subsets of information. They will return benefits information as long as they can find a unique match for the patient within their system.

For a subscriber:

• Member ID, first name, last name, date of birth
• Member ID, last name, date of birth
• Member ID, first name, last name

For a dependent:

• Subscriber member ID (in the subscriber object), first name, last name, date of birth
• Subscriber member ID, last name, date of birth
• Subscriber member ID, first name, last name

Of course, not all of this patient information is always available. For example, a patient may forget their ID card. In these instances, some payers may still be able to search with even less information, such as the patient’s first name, last name, and date of birth. Contact us if you have questions about alternative search options for a particular payer.

​

Dependents

The patient qualifies as a dependent for eligibility checks when:

1. The patient is listed as a dependent on the subscriber’s insurance plan.
2. The payer cannot uniquely identify the patient through information outside the subscriber’s policy.

For example, if the dependent has their own member ID number in the payer’s database, you must identify them in the subscriber object instead.

​

Checking eligibility for specific services

You can request specific types of benefits information from the payer by including either a procedureCode and productOrServiceIDQualifier or a serviceTypeCodes value in the encounter object. This approach can help you determine whether a patient’s insurance covers particular medical or dental services.

However, not all payers support procedure codes, and it can be hard to map some procedure codes to the right service type code. For example, if a provider offers medical nutrition therapy and bills using CPT code 97802, should they use service type code 1 - Medical Care, 3 - Consultation, MH - Mental Health, or another option?

We recommend the following tips when checking eligibility for specific services:

• Send a test eligibility check with a encounter.procedureCode and encounter.productOrServiceIDQualifier to payers you frequently bill. Most payers don’t support procedure codes, but some do - particularly dental payers and the Centers for Medicare and Medicaid Services. Payers typically return a generic service type code 30 (Plan coverage and general benefits) response when they don’t support the procedure code you provided.
• For dental payers that don’t support specific CDT codes, you can use Table 6 in the American Dental Association’s Technical Report No. 1102 to map CDT codes to service type codes. You can either purchase a copy of the report or contact Stedi support for recommendations about specific mappings.
• Ask a medical coder with AAPC certification for guidance. Their familiarity with billable codes will help them make good recommendations about service type code mappings.
• Maintain an internal document that contains the mappings for codes and health plans most heavily used in your practice.

​

Service Type Codes

You can include the following service type codes in the encounter object to request specific benefits information from the payer. Not all payers support all service type codes, however all payers are required to return benefits information for 30(Plan coverage and general benefits).

Note that the word physician in service type codes refers to any healthcare provider, including physician assistants, nurse practitioners, and other types of healthcare professionals.

​

Send mock requests

When you submit specific mock requests to the Eligibility Check endpoint, Stedi returns mock benefits data from the specified payer you can use for testing. You need a Stedi API key for authentication, and you must set the stedi-test header to true.

Visit Send mock requests for a complete list of mock requests you can send.

​

API concurrency limit

Requests to payers typically time out at 1 minute, though Stedi can keep connections open longer than that if needed.

Our real-time eligibility check endpoint has rate limiting on a per-account basis. This limit is based on concurrent requests, not requests per second. The default rate limit is 5 concurrent requests; if you need a higher limit, reach out to Support.

Insurance payers may take up to 60 seconds to respond to a request, so your transactions per second (and thus your concurrency limit) will vary based on the payer response time. If you reach the maximum concurrency limit, Stedi rejects additional requests with a 429 HTTP code until one of your previous requests is completed. Rejected requests have the following error message:

{
  "message": "The request can't be submitted because the sender's submission has been throttled: CUSTOMER_LIMIT",
  "code": "TOO_MANY_REQUESTS",
  "eligibilitySearchId": "019249c7-e176-76b0-a46a-3aef1a519bc4"
}

​

Avoid payer throttling

Payers expect to receive requests at a “human scale”, such as a member entering insurance information into a website or presenting their insurance card at a doctor’s office. They may throttle high volumes of requests for the same provider (NPI ID) at once. This throttling can occur even when you are within Stedi’s concurrency limit.

Real-time requests during normal operations are unlikely to experience throttling. However, we recommend spacing out requests during testing and periodic “refresh” checks, such as verifying active insurance. Avoid hitting payers with the same NPI ID more than 1-2 times every 15 seconds.