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, theerrors array in the response typically has the code set to one of the following values:
65: Invalid/Missing Patient Name67: Patient Not Found73: Invalid/Missing Subscriber/Insured Name75: Subscriber/Insured Not Found
- 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 followingAAA 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) and79(Invalid Participant Identification)80(No Response received - Transaction Terminated)
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:
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 missingprovider object:
Payer AAA errors
When a payer rejects your eligibility check, the 271 response contains one or moreAAA 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.
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
subscriber.aaaErrors):
payer, provider, subscriber, and dependents levels are also reported in the top-level errors array in the eligibility check response.
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 thepayer level.
Provider
You may receive the following types of errors at theprovider level.
Subscriber
You may receive the following types of errors at thesubscriber level.
Dependents
You may receive the following errors at thedependents 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: