Send eligibility checks with Stedi
Learn to send eligibility checks using Stedi’s real-time EDI connections. Our API provides a direct replacement for the Change Healthcare (CHC) Check Eligibility API.
Supported payers
Review our list of supported payers for eligibility.
Payer enrollment
You can begin sending eligibility checks for many payers immediately. However, there is a subset of payers that require enrollment before they will accept eligibilility checks. This typically involves submitting information about the provider that will send eligibility checks to the payer, including the provider’s name, tax ID, NPI, billing address, and contact information.
The list of supported payers specifies which payers require enrollment. Submit payers to our enrollment form, and we can help you complete the enrollment process for them as needed.
Manual eligibility checks
Go to the Create manual eligibility check page in the Stedi app to submit manual eligibility checks and review the full 271 JSON response. This can be useful for testing and for situations when you need to do a one-time eligibility check.
Call the Eligibility Check API
Call the Eligibility Check API to send 270 eligibility checks to payers. Requests to payers typically time out at 1 minute, though Stedi’s API can keep connections open longer than that if needed.
Some payers require enrollment before you can start sending them eligibility checks.
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.
Required information
Each eligibility check must include at least the following information in the request body:
| Information | Description |
|---|---|
controlNumber | A 9-digit, unsigned numeric value that that identifies the transaction. It does not need to be unique. This value is returned in the response as controlNumber. |
tradingPartnerServiceId | You can find the payer ID in our list of supported payers. You can also use the same payer IDs you used for CHC eligibility checks. |
provider object, name | You must include the provider’s name - either the firstName and lastName of a specific provider within a practice or the organizationName. |
provider object, identifier | You 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 dependent objects | You must include enough information for the payer to identify the patient in their system. Every payer can return benefits information when you provide the patient’s first name, last name, date of birth, and member ID. We recommend always including the member ID in requests when possible. Learn more |
encounter object, service dates | You can specify either a single dateOfService or a beginningDateOfService and endDateOfService. Stedi defaults to using the current date 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 codes | Specify either serviceTypeCodes 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. |
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"
}
}
Automatic repairs
Stedi automatically applies various repairs to help your requests meet X12 HIPAA specifications, resulting in fewer payer rejections.
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
subscriberobject), 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:
- The patient is listed as a dependent on the subscriber’s insurance plan.
- 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
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.
Insurance payers may take up to 60 seconds to respond to a request. 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.
Was this page helpful?