- Call this endpoint with payload in 270 X12 EDI format. Note that the request must include
BHT03(Submitter Transaction Identifier) and the Payer ID inLoop 2100A NM109. We recommend reviewing the requirements for a basic eligibility request. - Stedi validates the EDI and sends the eligibility check 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.
Body
Response
EligibilityRawX12Check 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.