Batch Eligibility Check
This endpoint allows you to submit multiple eligibility checks in a single request for Stedi to process asynchronously. You can submit up to 500 individual eligibility checks within a single batch, and you can submit as many batches as you need to process. To perform synchronous eligibility checks, use the Real-Time Eligibility Check endpoint.
We recommend using this endpoint to perform batches of eligibility checks, such as during periodic refreshes for a patient population or when running weekly eligibility checks for upcoming appointments.
- Call this endpoint with a JSON payload containing one or more eligibility checks.
- The endpoint returns a synchronous response containing a
batchIdthat you can use to retrieve the results of these checks later, using the Poll Batch Eligibility Checks endpoint. - Stedi translates each eligibility check included in the request to the X12 270 EDI format and sends it to the appropriate payer.
Eligibility checks you submit through this asynchronous endpoint don’t count toward your Stedi account concurrency budget. This allows you to stage thousands of requests through this endpoint while continuing to send real-time eligibility checks in parallel.
Basic batch eligibility check
The content of your eligibility request depends on your use case and the payer’s requirements. However, a basic batch eligibility check includes the following information in the request body:
| Information | Description |
|---|---|
controlNumber | An integer used to identify the transaction. It does not need to be globally unique. This value is returned in the response as controlNumber. |
tradingPartnerServiceId | You can find the payer ID in our list of supported payers. |
submitterTransactionIdentifier | A unique identifier for the eligibility check within the batch. Stedi returns this identifier in the response for the Poll Batch Eligibility Checks endpoint so you can correlate benefit responses with the original eligibility check. |
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 dependents objects | At 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 dates | You 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. Eligibility also usually starts and ends on month boundaries. |
encounter object, service or procedure codes | Specify serviceTypeCodes and/or a procedureCode and productOrServiceIDQualifier to request specific types of benefits information. Medical providers should set items.encounter.serviceTypeCodes to a single value of 30 - Health Benefit Plan Coverage, and dental providers should set it to 35 - Dental Care. Stedi supports all service type codes, but some payers may not support other values. Don’t include multiple service type codes because many payers will either return an error or ignore additional codes entirely. If you do not include any of these fields, Stedi defaults to using 30 (Plan coverage and general benefits) as the only serviceTypeCodes value. |
Character restrictions and replacement
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.
Stedi automatically replaces backticks (`), also known as backquotes or grave accents, with a single quote (') in subscriber and dependents first and last names. This autocorrection prevents errors when submitting your request to payers and intermediary clearinghouses. Stedi returns a message in the response’s warnings array when it makes this replacement.
Conditional requirements
Note that objects marked as required are required for all requests, while others are conditionally required depending on the circumstances. When you include a conditionally required object, you must include all of its required properties.
For example, you must always include the provider object in your request, but you only need to include the informationReceiverName object when you need to include additional information about the provider making the request, such as their specific location.
Authorizations
A Stedi API Key for authentication.
Body
Each entry in this array represents a single eligibility check. You can submit up to 500 eligibility checks in a single request. Warning: If any of the individual checks contain invalid data, Stedi rejects the entire batch and returns errors to help you correct the issues.
Response
An identifier for this batch of eligibility checks. You can use this identifier to retrieve the results of this batch using the Poll Batch Eligibility Checks endpoint.
The date and time that the batch of eligibility checks was submitted to Stedi for processing.
Was this page helpful?