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 array 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.

• If you don't specify either serviceTypeCodes or a procedureCode and productOrServiceIDQualifier, Stedi defaults to using 30 (Plan coverage and general benefits) as the only serviceTypeCodes value.
• 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.
• When checking eligibility for today, omit the dateOfService property 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.

• You must provide the organizationName (if the entity is an organization), or firstName and lastName (if the provider is an individual).
• 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 taxId or ssn.
• Don't include additional properties, such as taxId 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 dependents empty.

• 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 you provide all four of memberId, dateOfBirth, firstName, and lastName, 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.
• 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 patient's healthcare benefits, such as coverage level (individual vs. family), coverage type (deductibles, co-pays, etc.), out of pocket maximums, and more.

Payers typically return at least the following properties: code, coverageLevelCode, serviceTypeCodes, and either benefitAmount or benefitPercent. However, the exact properties returned in this object are up to the payer's discretion.

The payer may send benefits information for service type codes (STCs) you didn't request - this is expected. The STC you send in the request tells the payer the types of benefits information you want, but they aren't required to respond with exactly the same STC(s) in the response. Receiving different STCs than you requested can also mean that the payer is ignoring the STC you sent, which is why we recommend testing payers to determine their support for specific STCs.

Visit Determine patient benefits for more information about benefit types, details about how to interpret the benefitsInformation array, and additional examples.

Information about the patient when they are a dependent. When the patient is a dependent, this array will contain a single object with the patient's information. When the patient is a subscriber, or considered to be a subscriber because they have a unique member ID, their information is returned in the subscriber object, and this array will be empty.

When present, this object will always include the dependent's name for identification, but many payers will also return the date of birth and other identifying information.

When a payer rejects your eligibility check, the response contains one or more AAA errors that specify the reasons for the rejection and any recommended follow-up actions.

Any errors that occur at the payer, provider, subscriber, or dependents levels are also included in this array, allowing you to review all errors in a central location. If there are no AAA errors, this array will be empty.

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.

Contains the dates associated with the subscriber and dependents' (if applicable) insurance plan. This information is used to determine their eligibility for benefits.

• Most fields contain a single date, but some can contain either a single date or a date range. Each field's documentation specifies its format.
• Fields that can contain either a single date or date range include: plan, eligibility, planBegin, admission, and service.
• The provided dates apply to every benefit within the patient's health plan unless specifically noted within a benefitsInformation[].benefitsDateInformation object.
• If the payer sends back date(s) that are different for the subscriber and dependents, Stedi includes only the dates for the dependent in this object and omits the subscriber's date(s). Dependents can have different coverage dates than the subscriber due to qualifying life events, such as starting a new job or passing the age limit for coverage through their parent's plan.
• Most payers return either plan or planBegin and planEnd, but the exact dates returned depend on the payer's discretion and the patient's insurance plan.
• If the date of service is after the earliest ending plan, eligibility, planEnd, eligibilityEnd, policyEffective, or policyExpiration value, the patient likely doesn't have active coverage.

Additional identification for the subscriber's healthcare plan.

Please use benefitsInformation instead.

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.

A unique identifier for the eligibility request. It's used to trace the transaction. Stedi always generates a trace number for internal tracking, and the payer may generate one as well. Stedi returns both its internal trace number and the payer's trace number (if present) in this array.

You can't set your own trace number when submitting eligibility checks through this endpoint.

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.