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:

• API Key: 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, Stedi will use the current date (default) to retrieve benefits information from the payer.

{
  "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.

​

Patient information

You don’t need to supply information for every possible field within the subscriber and dependents objects. Instead, you should only include the information required for your use case.

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.

​

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 will reject additional requests with a 429 HTTP code until one of your previous requests is completed.

​

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.