How to avoid eligibility check errors

Insurance verification is the first step in the revenue cycle – and the first place it can break.

When an eligibility check fails or returns bad data, everything downstream falls apart. Claims get denied. Patients get surprise bills. Providers wait to get paid. Staff waste hours on the phone verifying coverage or fixing claims.

Bad eligibility checks set providers up to fail.

But there’s good news: If you’re using Stedi’s Eligibility Check APIs, most eligibility check errors are avoidable. This guide shows how to prevent them – and how to use Stedi to build a faster, more reliable eligibility workflow.

Only send the required patient data

Payers return AAA errors when they can’t match an eligibility request to a subscriber. It may seem counterintuitive, but this often happens because the request includes too much patient data.

Payers require that each check match a single patient. Extra data increases the risk of mismatches. Even a small typo in a non-required field can cause a failed match.

For the best results, only send:

• Member ID

• First name

• Last name

• Date of birth

If you’re verifying the subscriber, put this info in the subscriber object.

{
  ...
  "subscriber": {
    "memberId": "123456789",
    "firstName": "Jane",
    "lastName": "Doe",
    "dateOfBirth": "19000101"
  }
}

If you’re verifying a dependent, the format depends on the payer. If the dependent has their own member ID, try this:

• Put the dependent’s info in the subscriber object.

• Leave out the dependents array.

If the dependent doesn’t have their own member ID:

• Put the subscriber’s info in the subscriber object.

• Put the dependent’s info in an object in the dependents array.

Don’t send SSNs, addresses, or phone numbers in eligibility checks. They often cause mismatches. For medical checks, if you don’t know the insurer, or the payer requires a member ID and you don’t have it, start with an insurance discovery check.

If your eligibility checks still fail, try a name variation. For example, “Nicholas” might work where “Nick” doesn’t. Use Stedi’s Eligibility Manager to test variations and retry requests directly from the UI.

When you get a successful response from the payer, update your records with the returned member ID, name, and date of birth. This improves your chances of a successful response on the next eligibility check, whether it’s for a future visit or a batch refresh.

Use insurance discovery when patient data is missing

If you don’t know the insurer or the payer requires a member ID and you don’t have it, start with an insurance discovery check.

Discovery checks use demographic data, like name and date of birth, to search payers for active coverage. If they find a match, they’ll return a response with the payer and member ID.

While helpful, discovery checks aren’t guaranteed to match. Match rates vary. They’re also slower than eligibility checks. But when you can’t send a clean eligibility check, discovery is your best fallback.

Discovery checks might not return all of a patient’s active insurance plans. If the patient could have multiple payers, follow up with a coordination of benefits (COB) check after the eligibility check. A COB check can find other coverage and figure out the primary payer.

Check eligibility before checking COB

COB checks are more sensitive than eligibility checks. Even small mismatches, like using a nickname instead of a legal name, can cause them to fail.

To reduce errors, run an eligibility check first. Then use the member ID from the eligibility response in your COB request. You’ll get cleaner results and fewer failures.

If you don’t have a member ID, start with an insurance discovery check first. Then follow up with an eligibility check and COB check – in that order.

Keep coverage data fresh with batch refreshes

Insurance changes often. Patients switch plans. Cached coverage data goes stale fast.

Always re-check eligibility before a visit. Between visits, use Stedi’s Batch Eligibility Check API to run weekly or monthly refreshes. Batch checks return full coverage breakdowns, just like real-time checks. They can catch insurance issues before they cause problems.

Batch eligibility checks are asynchronous. They don’t count toward your Stedi account’s concurrency limit. You can run thousands of batch eligibility checks and still send real-time checks at the same time.

Include an MBI for Medicare eligibility checks

Every Medicare eligibility check requires a Medicare Beneficiary Identifier (MBI) for the patient. If it’s missing or wrong, the check will fail.

If the patient doesn’t know their MBI, run an MBI lookup using the same Real-Time Eligibility Check API. You’ll need to:

1. Set the tradingPartnerServiceId to MBILU (MBI Lookup).

2. Include the following in the request:

   • subscriber.firstName

   • subscriber.lastName

   • subscriber.dateOfBirth

   • subscriber.ssn

For example:

curl --request POST \
  --url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3 \
  --header 'Authorization: <api-key>' \
  --header 'Content-Type: application/json' \
  --data '{
  "controlNumber": "123456789",
  "tradingPartnerServiceId": "MBILU",
  "externalPatientId": "UAA111222333",
  "encounter": {
    "serviceTypeCodes": [
      "30"
    ]
  },
  "provider": {
    "organizationName": "ACME Health Services",
    "npi": "1999999984"
  },
  "subscriber": {
    "dateOfBirth": "19000101",
    "firstName": "Jane",
    "lastName": "Doe",
    "ssn": "123456789"
  }
}'

Stedi will return the patient’s full coverage details and their MBI. You can then use the MBI as the member ID for eligibility checks.

MBI lookups require setup with Stedi and incur additional costs. Contact us for details.

Test each STC one at a time

Service Type Codes (STCs) tell the payer what kind of benefits info you’re requesting. You can include them in the encounter.serviceTypeCodes array:

"encounter": {
  "serviceTypeCodes": ["30"]
}

You can send multiple STCs in one request, but support varies by payer:

• Some only respond to the first STC.

• Some ignore your STCs and always return a default response for STC 30 (Health Benefit Plan Coverage).

• Some don’t support multiple STCs in a single request.

To figure out what works, test each payer individually:

1. Send a request with just STC 30 for general medical benefits or 35 for general dental benefits.

2. Send one with a specific STC you care about, like 88 for pharmacy benefits.

3. Try a request with multiple STCs.

Compare the responses. If they change based on the STC or the number of STCs, the payer likely supports them. If not, they may be ignoring or only partially supporting STCs.

Success depends on the payer’s implementation. Partial support and fallback behavior are common.

Avoid timeouts with request hedging

Payer responses can be slow. Payers can take up to 60 seconds to respond to eligibility requests. To handle this, Stedi keeps real-time eligibility requests open for up to 120 seconds. Internally, Stedi may retry a request to the payer multiple times during that window.

Don’t cancel and retry your own requests during this window. It can create duplicates, increase your concurrency usage, and further slow things down.

If a check feels stuck, use request hedging instead. Wait 30 seconds, then send a second request without canceling the first. Use whichever response returns first. It’s a simple way to avoid timeouts.

Debug errors with Eligibility Manager

Sometimes, eligibility errors are unavoidable. Payers go down, data is missing, or coverage has changed. Stedi’s Eligibility Manager shows exactly why a check failed so you can fix it instead of guessing.

Each check is grouped under a unique Eligibility Search ID. Retries stay in the same thread, giving you a full audit trail.

Use Eligibility Manager to:

• Filter by error code, payer, or status. For example, you can find all checks that failed with a specific AAA code (like 75 for Subscriber Not Found). Or see issues by a specific payer.

• View raw request and response data.

• Edit and retry failed checks directly from the UI.

• Compare retries to see what changed between failures and successes.

If you’re running eligibility at scale, this tool can save you hours of guessing and debugging.

Eligibility workflows that don’t break

Stedi gives you modern APIs and tools to build accurate, reliable eligibility workflows. When errors do happen, you get help fast. Our average support response time is under 8 minutes.

Want to see how it works? Contact us to set up a proof of concept.