- Call this endpoint with a JSON payload. The required information can vary depending on the circumstances, but we recommend starting with a basic eligibility request.
- Stedi translates your request to the X12 270 EDI format and sends it to the payer.
- The endpoint returns a synchronous response from the payer in both JSON and raw X12 EDI format. The response contains the patient’s eligibility and benefits information. Note that our documentation lists all enums officially allowed in the eligibility response. Some payers return non-compliant values, which Stedi passes through as is.
Authorizations
A Stedi API Key for authentication.
Headers
Please create a test API key to submit requests in test mode.
Body
An integer used to identify the transaction. This is a requirement for the X12 EDI 270 transaction that Stedi will generate and send to the payer. It doesn't need to be globally unique - you can use the same number for every request.
9The 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, orlastName. 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, andlastName, 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.
This is the payer ID. Visit the Payer Network for a complete list. You can send requests using the primary payer ID, the Stedi payer ID, or any alias listed in the payer record.
1 - 80An object containing 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 ID (npi).
Details about the eligibility or benefit information you are requesting for the patient.
- If you don't specify either
serviceTypeCodesor aprocedureCodeandproductOrServiceIDQualifier, Stedi defaults to using30(Plan coverage and general benefits) as the onlyserviceTypeCodesvalue. - You can specify either a single
dateOfServiceor abeginningDateOfServiceandendDateOfService. The payer defaults to using the current date in their timezone if you don't include one. - When checking eligibility for today, omit the
dateOfServiceproperty 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.
A unique identifier for the patient that Stedi uses to identify and correlate historical eligibility checks for the same individual. We recommend including this value in all requests.
36The password that the provider uses to log in to the payer's portal. This is not commonly used.
1 - 50The username that the provider uses to log in to the payer's portal. This is not commonly used.
1 - 50This property is only relevant for asynchronous batch eligibility checks.
The payer's name, such as Cigna or Aetna.
1 - 80Use the corresponding properties in the provider object instead.
This shape is deprecated.
A dependent for which you want to retrieve benefits information.
- You can only submit one dependent per eligibility check.
- An individual qualifies as a dependent for eligibility checks 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
subscriberobject 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.
1 elementResponse
EligibilityCheck 200 response
Metadata about the response. Stedi uses this data for tracking and troubleshooting.
An identifier for the payer's response.
Deprecated; do not use.
An ID for the payer you identified in the original eligibility check request. This value may differ from the tradingPartnerServiceId you submitted in the original request because it reflects the payer's internal concept of their ID, not necessarily the ID Stedi uses to route requests to this payer.
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 the payer may assign to the transaction. Note that Stedi doesn't support setting a subscriber trace number in the eligibility check request because there is no need to include a trace number for real-time queries.
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.
Additional identification for the subscriber's healthcare plan.
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, andservice. - The provided dates apply to every benefit within the patient's health plan unless specifically noted within a
benefitsInformation.benefitsDateInformationobject. - 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
planorplanBeginandplanEnd, 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, orpolicyExpirationvalue, the patient likely doesn't have active coverage.
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.
Warnings indicate non-fatal issues with your eligibility check or a non-standard response from the payer.
Errors Stedi encountered when generating or sending the final X12 EDI transaction to the payer. These can include validation errors and payer unavailable errors that prevent delivery.
The transaction set acknowledgment code provided in in the X12 EDI 999 response.
The implementation transaction set error code provided in IK502 of the 999 transaction.
Typically this property contains the raw X12 EDI 271 Eligibility Benefit Response from the payer.
In some circumstances, this property may contain a 999 Implementation Acknowledgment instead of a 271. A 999 indicates validation errors in the X12 EDI transaction, such as improper formatting or missing or invalid values.
If the 999 is returned in this property, many of the other response properties will be empty, as they are mapped to information in the 271.
Please use benefitsInformation instead.
This shape is deprecated.
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.
Information about the subscriber or dependents' 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.
Visit Payer benefit response for more information about benefit types, details about how to interpret the response, and additional examples.