Eligibility troubleshooting

A list of potential errors and possible resolutions when submitting 270/271 eligibility checks.

​

Payer unable to find patient

Sometimes, a payer can’t return benefits information for a patient even when the patient exists in their system. This problem can occur for a couple reasons.

​

Multiple matching records

Payers can have multiple records of patients with the same name and date of birth. The payer cannot return benefits information unless they are able to identify a unique match within their system.

To avoid this issue, we recommend:

• Include all of the demographic information available for a patient.
• Include the patient’s member ID, if available.

​

Information discrepancies

There can be discrepancies between the information the provider has collected from the patient and the record the payer has in their system. These discrepancies can lead to issues returning a patient, even though a match exists. Some examples include differences in spelling the patient’s name, using a nickname instead of the full name (“Nick” vs. “Nicolas”), and accidentally transposing numbers in the date of birth.

If a request fails to return the expected member in the response, we recommend progressively sending additional eligibility check requests with fewer patient identity and demographic data elements, or different combinations of those. This allows you to identify and handle cases where there are data errors or discrepancies between payer and provider data.

​

Name mismatches

If the payer fails to find a matching plan member due to a name mismatch, the errors array in the response typically has the code set to one of the following values:

• 65: Invalid/Missing Patient Name
• 67: Patient Not Found
• 73: Invalid/Missing Subscriber/Insured Name
• 75: Subscriber/Insured Not Found

These error codes are set by the payer, not by Stedi, so it’s possible that other error codes could be returned.

Resolving the error may require trying different name variations until the check is successful.

• Replace any nickname or shortened name with the full legal name, for example “Robert” instead of “Bob”.
• Replace any non-English or accented characters (letters with diacritical marks) such as “Ñ” or “é” with the closest equivalent within the character restrictions. Stedi automatically replaces most such characters with the usual closest equivalent but this might not match the payer’s record. For example, the character “Đ” could be transliterated to “D” or “J” depending on the romanization system used.
• For compound names try using only one or the other part. You can also try try removing the separator, or changing the separator from hyphen to space, or vice versa. Some payers may ignore special or separator characters when performing name searches.
• If the patient has recently changed their name, for example due to marriage, then the name stated by the patient or printed on their ID card might not match the payer’s record. Try both the current and previous name.

​

Retry strategy

Implementing the right retry strategy for eligibility check failures saves a lot of time and money.

At a minimum, we strongly recommend automatically retrying every request that fails due to payer connectivity issues. Automatic retries resolve a significant portion of these types of failures without manual intervention.

​

Payer connectivity issues

We recommend implementing automatic retries for all of the following AAA error cases. These scenarios indicate temporary payer downtime, throttling, or intermittent connectivity issues:

• 42 (Unable to Respond at Current Time)
• 42 (Unable to Respond at Current Time) and 79 (Invalid Participant Identification)
• 80 (No Response received - Transaction Terminated)

Our recommended retry strategy depends on your eligibility check workflow.

​

Real-time eligibility checks

For real-time eligibility checks that require a response within a few minutes, we recommend:

• Wait 15 seconds before the first retry.
• Then, retry every 15 seconds for up to 2 minutes. The recommended retry window is based on what’s acceptable in real-time human workflows. For example, a patient checking in for an appointment at their doctor’s office.
• Don’t hit the payer with the same NPI ID more than once every 15 seconds. This time between requests helps you avoid payer throttling.
• If the request is still unsuccessful, fail gracefully and escalate as needed.

​

Scheduled eligibility checks

You may want to run scheduled or background eligibility checks to perform periodic refreshes for a patient population or when checking eligibility for upcoming appointments.

If you’re using the Batch Eligibility Check endpoint (recommended), Stedi automatically retries checks that fail due to payer connectivity issues for up to 8 hours.

If you’re submitting real-time checks that can tolerate longer wait times, we recommend:

• Wait 1 minute to perform the first retry.
• Then, exponentially increase the wait between subsequent retries to up to 30 minutes between attempts.
• We recommend retrying for at least 8 hours, but the retry window should be based on your business workflows.

​

Other common error cases

You should also consider the following common error cases when implementing retries:

​

Errors

You may encounter the following types of errors when submitting eligibility requests.

​

Stedi payer errors

Stedi returns errors when it encounters issues with the payer ID you provided.

The following error resulted from an unrecognized payer ID:

{
  "controlNumber": "123456789",
  "tradingPartnerServiceId": "TEST2",
  "errors": [
    {
      "code": "79",
      "description": "Invalid Participant Identification",
      "followupAction": "Please Correct and Resubmit",
      "location": "2100A",
      "possibleResolutions": "Payer TEST2 is not configured. Please check our published payer list or contact Stedi support to resolve."
    }
  ],
  "status": "ERROR"
}

​

Validation errors

Stedi validates the structure of your eligibility request and will not submit your request to the payer if it is missing required fields or if the data is not formatted correctly. The following Stedi validation error resulted from a missing provider object:

{
  "controlNumber": "123456789",
  "tradingPartnerServiceId": "CIGNA",
  "errors": [
    {
      "code": "33",
      "description": "Input Errors",
      "followupAction": "Please Correct and Resubmit",
      "possibleResolutions": "Missing required field: provider"
    }
  ],
  "status": "ERROR"
}

​

Payer AAA errors

When a payer rejects your eligibility check, the 271 response contains one or more AAA Request Validation segments that specify the reasons for the rejection and any recommended follow-up actions. Stedi includes this information in the aaaErrors object in the response JSON.

Common causes for AAA errors include:

• Missing or incorrect information for the subscriber, dependent, provider, or payer. In this case, you should correct any errors before resubmitting.
• Issues with payer enrollment. Many of these issues require that the provider contact the payer directly to resolve, due to PHI/HIPAA guidelines.
• The payer’s system is down or experiencing issues. In this case, the payer may not have actually validated the data in your request. If you receive these types of errors, you should wait a few minutes and resend the request again.

Each error contains a followupAction:

• Please Correct and Resubmit
• Resubmission Not Allowed | Note that this code doesn’t mean you should never resubmit the request. Intermediary clearinghouses may send this code when they have temporarily lost connection to the payer, so this code indicates that you should wait at least a few minutes before retrying instead of retrying immediately.
• Resubmission Allowed
• Do Not Resubmit; Inquiry Initiated to a Third Party | This code is uncommon
• Please Resubmit Original Transaction
• Please Wait 30 Days and Resubmit | This code is uncommon
• Please Wait 10 Days and Resubmit | This code is uncommon
• Do not resubmit; We Will Hold Your Request and Respond Again Shortly | This code is uncommon

AAA errors can be present at multiple different levels in the response, depending on the type. The following example shows an error at the subscriber level (subscriber.aaaErrors):

    "subscriber": {
        "memberId": "123456789",
        "firstName": "JANE",
        "lastName": "DOE",
        "entityIdentifier": "Insured or Subscriber",
        "entityType": "Person",
        "dateOfBirth": "190001103",
        "aaaErrors": [
            {
                "field": "AAA",
                "code": "75",
                "description": "Subscriber/Insured Not Found",
                "followupAction": "Please Correct and Resubmit",
                "location": "Loop 2100C",
                "possibleResolutions": "- Subscriber was not found."
            }
        ]
    }

Visit Eligibility mock requests to retrieve more examples of common AAA errors in eligibility responses.

​

Payer

You may receive the following types of errors at the payer level.

​

Provider

You may receive the following types of errors at the provider level.

​

Subscriber

You may receive the following types of errors at the subscriber level.

​

Dependents

You may receive the following errors at the dependents level.

​

Card Issuer Identifier (80840)

All health plans use (80840) as the first five digits of the Card Issuer Identifier.

This is a placeholder value used for standards compliance only, and you shouldn’t pass it in an electronic eligibility check. However, many providers and OCR systems accidentally pass (80840) in other eligibility check fields. For example, they may try to pass this value as a subscriber or dependent ID, causing an AAA rejection from the payer.

To prevent these types of mistakes, Stedi automatically suppresses any string containing (80840) in the following fields:

If the payer’s eligibility response returns an AAA error, Stedi returns the following warning:

The field {FIELD} contains the string "(80840)", which is a known
placeholder prefix for a field that should not be provided in {FIELD}.
We have omitted that value in the request, and the request failed.
Please locate the correct value for {FIELD} and resubmit.

To correct this error, read the documentation for the corresponding field, locate the correct value, and resubmit the eligibility check.