Send eligibility checks with Stedi
Learn to send elligibility checks using Stedi’s real-time EDI connections. Our API provides a direct replacement for the Change Healthcare (CHC) Check Eligibility API.
Submit 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. - Response Type: Controls the shape of the response payload. Set to
change-betato return a payload matching the CHC 271 format.
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' \
--header 'Stedi-Response-Type: change-beta' \
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 | This is a 9-digit, unsigned numeric value that that identifies the transaction to you and the payer. You can autogenerate the control number in any way that makes sense for your business, but it should be unique for each eligibility check you send. The control number is included in the payer’s 271 response as the reassociationKey, allowing you to link the request and response for tracking and troubleshooting. |
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, and we will automatically map them to our payer IDs. |
provider object | You must include at least the provider’s name - either the firstName and lastName of a specific provider within a practice or the organizationName - and the provider’s NPI (npi). The NPI is a unique, 10-digit identification number assigned to healthcare providers according to HIPAA standards. Ask your provider for their NPI if you don’t have it. |
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. Learn more |
encounter object | This object contains information about the medical services provided and the type of benefits information you are requesting from the payer. If you don’t include it, Stedi defaults to using the current date as the dateOfService and 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"
}
}
Service dates and type codes
The encounter object defines the beginning and end dates of the service and the service type codes for which you want to receive benefits information. For example, you might specify MH for mental health services or 30 for general benefits.
You can define the encounter as a single date (dateOfService) or as a range of dates (beginningDateOfService and endDateOfService).
We don’t know which payers support multiple service type codes. However, we recommend including no more than one service type code in each request.
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.
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.
Supported payers
Review our list of supported payers for eligibility.
Provider 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.
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?