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.

Some payers require enrollment before you can start sending them eligibility checks.

​
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:

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:

InformationDescription
controlNumberAn integer used to identify the transaction. It does not need to be globally unique.
tradingPartnerServiceIdYou can find the payer ID in our list of supported payers.
provider object, nameYou must include the provider’s name - either the firstName and lastName of a specific provider within a practice or the organizationName.
provider object, identifierYou must include an identifier. Most often this is the National Provider Identifier (NPI). The NPI is a unique, 10-digit identification number assigned to healthcare providers according to HIPAA standards.
subscriber and/or dependents objectsAt a minimum, our API requires that you supply at least one of these fields in the request: memberId, dateOfBirth, or lastName. However, each payer has different requirements, so you should supply the fields necessary for each payer to identify the subscriber in their system. When all four of memberId, dateOfBirth, firstName, and lastName are provided, payers are required to return a response if the member is in their database. Some payers may be able to search with less information, but this varies by payer. We recommend always including the patient’s member ID when possible. Learn more about patient information.
encounter object, service datesYou can specify either a single dateOfService or a beginningDateOfService and endDateOfService. The payer defaults to using the current date in their timezone if you don’t include one. We recommend submitting dates up to 12 months in the past or up to the end of the current month. Dates outside of these ranges are likely to be rejected by many payers, since they may have archived older data and they cannot guarantee eligibility for future months.
encounter object, service or procedure codesSpecify serviceTypeCodes and/or a procedureCode and productOrServiceIDQualifier to request specific types of benefits information. We don’t know which payers support multiple service type codes, so we recommend including no more than one in each request. If you do not include any of these fields, Stedi defaults to using 30 (Plan coverage and general benefits) as the only serviceTypeCodes value. Learn more about checking eligibility for specific services.

Don’t include the following characters in your request data: ~, *, : and ^. They are reserved for delimiters in the resulting X12 EDI transaction, and X12 doesn’t support using escape sequences to represent delimiters or special characters. Stedi returns a 400 error if you include these restricted characters in your request.

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

Asynchronous batch eligibility checks don’t count toward your Stedi account concurrency budget. This allows you to stage thousands of batch checks while continuing to send real-time eligibility checks in parallel.

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.

You can also use Stedi’s Batch Eligibility Check API to submit up to 500 eligibility checks in a single request. Stedi processes these eligibility checks asynchronously, implementing best practices to avoid payer throttling.

Was this page helpful?

OverviewBatch refresh checks