POST /eligibility-check

A dependent for which you want to retrieve benefits information.

• You can only submit one dependent per eligibility check.
• Only include the patient's information here when they are listed as a dependent on the subscriber's insurance plan AND the payer cannot uniquely identify them through information outside the subscriber's policy. For example, if the dependent has their own member ID number, you should identify them in the subscriber object instead. This includes member IDs that differ only by a suffix, such as 01, because the patient can still be uniquely identified.
• Most Medicaid plans don't support dependents, with a few exceptions. Sending this information to payers that don't support dependents will either cause an error, or the payer may ignore the information and return results for the subscriber instead.
• Each payer has different requirements, so you should supply the fields necessary for each payer to identify the dependent in their system. However, we strongly recommend including the dependent's date of birth in the request when available because many payers return errors without it.
• Enter the patient's name exactly as written on their insurance card, if available, including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces. Visit patient names for all best practices to avoid unnecessary failures.

Details about the eligibility or benefit information you are requesting for the patient.

• You can optionally include service type codes (STCs) or procedure codes to request benefits for specific services.
• You can specify either a single service date or a date range using dates.service. The payer defaults to using the current date in their timezone if you don't include one.
• When checking eligibility for today, omit the service date to ensure consistent behavior across payers.
• We recommend submitting dates up to 12 months in the past or up to the end of the current month. Payers aren't required to support dates outside these ranges. However, some payers such as the Centers for Medicare and Medicaid Services (CMS) do support requests for dates further in the future - especially the next calendar month. Check the payer's documentation to determine their specific behavior.

Information about the entity requesting the eligibility check. This may be an individual practitioner, a medical group, a hospital, or another type of healthcare provider.

• Provide the provider's name as either a person (with name.person) or an organization (with name.organization). If you leave it out, Stedi uses the name on the NPPES record for the provider's npi, or PROVIDER when there is no record.
• You must also provide an identifier - this is typically the provider's National Provider Identifier (npi). If the provider doesn't have an NPI, you can supply an alternative, such as their tin or ssn.
• Don't include additional properties, such as tin or address, unless they are specifically required or suggested by the payer.

The primary policyholder for the insurance plan or a dependent with a unique member ID. If a dependent has a unique member ID, include their information here and leave dependent empty.

• At a minimum, our API requires that you supply at least one of these fields in the request: memberId, dateOfBirth, or name.person.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 you provide all four of memberId, dateOfBirth, name.person.firstName, and name.person.lastName, payers must 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.
• Enter the patient's name exactly as written on their insurance card, if available, including any special or punctuation characters such as apostrophes, hyphens (dashes), or spaces. Visit patient names for all best practices to avoid unnecessary failures.

Information about the dependent from the eligibility check request. Note that the payer may return the dependent in the subscriber object instead. When present, this object will always include the dependent's name for identification, but many payers also include the date of birth and other identifying information. Some payers truncate names to fit their own technical limits, so the payer may not return the dependent's full legal name.

AAA rejection errors from the payer. AAA errors specify the reasons for the rejection and any recommended follow-up actions.

Metadata about the response. Stedi uses this data for tracking and troubleshooting.

Information about the payer providing the benefits information. The response will always include the payer's business name and an identifier, such as the payer's tax ID. Most payers also include contact information.

The patient's insurance plans, grouped by plan name. Each plan contains the benefits that apply to the patient.

Information about the entity that submitted the original eligibility check request. This may be an individual practitioner, a medical group, a hospital, or another type of healthcare provider. This object will always include at least one identifier, such as the provider's NPI, tax ID, or EIN.

Information about the primary policyholder for the insurance plan listed in the original eligibility check request. The response will always include either the subscriber's name or member ID for identification, but most payers will also return the subscriber's date of birth and other identifying information. Some payers truncate names to fit their own technical limits, so the payer may not return the subscriber's full legal name.

Issues with your eligibility request that could affect the results, or information about the response. For example, warnings can help explain why the request was rejected.