You may want to periodically conduct batch eligibility checks for your entire patient population or a subset of patients, such as those who have active care plans or who have future services scheduled. This approach allows you to proactively reach out to patients when they lose or change coverage, preventing surprises and billing delays.

​
Send batch checks

You can 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.

Asynchronous batch 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.

​
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. However, each batch 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. This value is returned in the response as controlNumber.
tradingPartnerServiceIdYou can find the payer ID in our list of supported payers.
submitterTransactionIdentifierA 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, 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. Eligibility also usually starts and ends on month boundaries.
encounter object, service or procedure codesSpecify 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.

​
Sample request and response

The following example demonstrates how to submit a batch of eligibility checks in the items array, where each item represents an individual eligibility check. Stedi returns a batchId that you can use to retrieve the results of these checks later.

​
Retrieve batch results

After you’ve submitted a batch of eligibility checks, you can use the Poll Batch Eligibility Checks endpoint to retrieve the results.

​
Minimize waste

We recommend the following to optimize batch eligibility checks:

  • Periodically purge or archive records for inactive patients. It’s a waste to perform eligibility checks on patients who have died or who haven’t scheduled an encounter for several years.
  • Remove or deactivate patients that are no longer eligible. The payer indicates ineligibility by setting benefitsInformation.code = “6” (Inactive) in the response.

​
When to follow up

Check for benefitsInformation.code = “5”, which stands for Active - Pending investigation, or a response containing a benefitsDateInformation.premiumPaidToDateEnd before the current date. Some payers may still show active coverage while the subscriber is behind on premium payments.

You may want to conduct additional checks on these patients because they have an elevated risk of losing coverage soon.

Was this page helpful?

Real-time eligibility checksTroubleshooting