How to use insurance discovery

Eligibility checks are intended for ideal circumstances: the patient has their current insurance card handy, or they know their member ID and are certain of the correct payer. For those situations, Stedi offers a Real-Time Eligibility Check API. But that’s not always reality.

In the real world, patients forget their cards, switch plans, or don’t know who covers them at all.

It’s important to get a successful eligibility response from the patient’s current payer. Without one, patients get surprise bills, staff waste time chasing payment, and providers lose money on denied claims.

But payers can only return results when an eligibility check matches a single patient. While certain payers can match on name and date of birth alone, most need a member ID. If the patient doesn’t have it, the check fails, and the provider is stuck.

When you only have partial details, Stedi’s Insurance Discovery API can help.

With an insurance discovery check, you don’t need to know the member ID or payer. Just send the patient’s known demographic details such as name, birthdate, state or ZIP, and SSN, if available. We enrich these details with third-party data sources and search potentially relevant payers for active coverage, then return what we find.

It’s not guaranteed – match rates vary. But when eligibility checks fail, insurance discovery gives you a way forward. This guide shows how to use it and how to get the best results.

When to use insurance discovery

If you know the payer up front, we recommend that you attempt one or more eligibility checks before running an insurance discovery check (if you know the payer name but not the payer ID, you can use our Payer Search API to find it). If you don’t know the payer or if you’re unable to get a successful eligibility response, insurance discovery is the next step. Some common cases include:

• The payer isn’t known.

• The member ID is missing or incorrect.

• Attempted eligibility checks failed with an AAA 75 (Subscriber not found) or other similar error.

• The patient gave conflicting or incomplete info.

Discovery checks are a great fallback when a standard eligibility check is impossible or unsuccessful. Since a successful discovery check ultimately returns the full details from a successful eligibility check, they are a direct replacement for eligibility checks. The main tradeoffs are:

• They’re slower, since Stedi performs an average of 13-16 real-time eligibility checks per discovery check.

• They’re less reliable than sending an eligibility check with full patient details to a known payer, since it isn’t possible for every discovery check to perform searches against every payer.

• They’re more expensive, since multiple third-party data and eligibility lookups are performed.

Note: Discovery checks don’t support dental payers. If your use case is dental-only, discovery won’t return results – even if the patient is insured. It's best used for medical coverage.

How to set up insurance discovery

To run discovery checks for a provider, you first need to complete transaction enrollment for their NPI with the DISCOVERY payer ID.

This is a one-time step for each provider. You can submit enrollment requests using the Enrollments API, the Stedi portal, or a bulk CSV.

Enrollment is typically approved within 24 hours. When it’s live, you’ll get an email notification. You can also check enrollment status in real time using the API or Stedi portal. After that, you can use the approved NPI in insurance discovery requests.

If you make an insurance discovery check with an unenrolled provider NPI, you’ll get an error response.

What to include in discovery checks

With eligibility checks, too much data can cause a payer to reject a request that otherwise would have been successful . The opposite is true for insurance discovery checks: the more patient data you include, the better your chances of getting a match.

If you only send the patient’s name and date of birth, success rates will be very low. The reason is that ultimately, Stedi and the payers need to be able to resolve to a single member. Unless the name is extremely uncommon, a name + date of birth is likely to match multiple members and result in a rejection. The same is true for sending a common name + date of birth + ZIP code – for example, John Smith with any date of birth in a New York ZIP code will have dozens of matches, and will therefore result in a failure.

With a full or partial SSN and an address or ZIP code, hit rates range from 30-70%.

For the best results, include at least the following patient info in Insurance Discovery Check API requests:

• First name (required)

• Last name (required)

• Date of birth (required)

• Full or partial SSN (even the last 4 digits can help)

• Gender

• Full address or ZIP code (current or previous)

An example request body with patient info in the subscriber object:

{
  "provider": {
    "npi": "1999999984"
  },
  "subscriber": {
    "firstName": "John",
    "lastName": "Smith",
    "middleName": "Robert",
    "dateOfBirth": "19800101",
    "ssn": "123456789",
    "gender": "M",
    "address": {
      "address1": "123 Main St",
      "city": "Springfield",
      "state": "IL",
      "postalCode": "62701"
    }
  },
  "encounter": {
    "beginningDateOfService": "20240326",
    "endDateOfService": "20240326"
  }
}

How to read discovery responses

Discovery checks usually return a synchronous response within 60-120 seconds. If the result isn’t available by then, you can poll for it using the discoveryId and the Insurance Discovery Check Results endpoint. Most checks don’t require polling.

If the discovery check finds active coverage, you’ll get:

• Payer name and ID

• Member ID

• Group number and plan details

{
  "discoveryId": "12345678-abcd-4321-efgh-987654321abc",
  "status": "COMPLETE",
  "items": [
    {
      "payer": {
        "name": "EXAMPLE INSURANCE CO"
      },
      "subscriber": {
        "memberId": "987654321000",
        "firstName": "John",
        "lastName": "Doe"
      },
      "planInformation": {
        "planNumber": "123456-EXMPL9876",
        "groupNumber": "123456-78",
        "groupDescription": "Individual On-Exchange"
      },
      "benefitsInformation": [
        {
          "code": "1",
          "name": "Active Coverage",
          "serviceTypeCodes": ["30"],
          "serviceTypes": ["Health Benefit Plan Coverage"],
          "planCoverage": "Gold Plan",
          "inPlanNetworkIndicator": "Yes"
        }
      ]
    }
  ]
}

In many cases, the response also includes full benefits data with the same benefitsInformation objects you’d get from a 271 eligibility response. But not always.

If the benefits data is included, you can use it directly. If the data seems incomplete, we recommend running a follow-up 270/271 eligibility check using the returned first name, last name, and member ID to the determined payer, especially if you’re automating downstream logic.

Discovery checks will return multiple payers if multiple coverages are found, but it isn’t guaranteed that they’ll find all of a patient’s plans. If you think the patient may have multiple plans, run a Coordination of Benefits (COB) check after the eligibility check to find other coverage and determine which payer is primary.

How to fix zero matches

A "coveragesFound": 0 result doesn’t always mean the patient is uninsured. It just means the discovery check couldn’t find a match.

{
  "coveragesFound": 0,
  "discoveryId": "0197a79a-ed75-77c3-af58-8ece597ea0be",
  "items": [],
  "meta": {
    "applicationMode": "production",
    "traceId": "1-685c0f14-1b559a954f0bd0127110d161"
  },
  "status": "COMPLETE"
}

Common reasons for no match results include:

• Recommended fields, like SSN or ZIP code, were missing from the request. Remember that only including name, date of birth, and ZIP code is extremely unlikely to find a single match unless the provided name is extremely uncommon in the provided ZIP code.
  
  

• The patient’s info doesn’t exactly match what the payer has on file. For example, the patient isn’t using their legal name, or their address has changed.
  
  

• The payer doesn’t support real-time eligibility checks, which makes it impossible for Stedi to determine coverage.
  
  

• The patient is covered under a different name, spelling, or demographic variation.

If you think the patient has coverage, try again with corrections or more data. Even small changes like using a partial SSN or legal name can make a difference.

But keep in mind: Even clean, complete input won’t always return a match. Matches aren’t guaranteed.

Since Stedi supports 1,250+ payers for real-time eligibility, it isn’t feasible to check every patient against every payer. Stedi chooses the most probable payers based on the provided demographic details – if the patient has improbable coverage (for example, if the patient has always lived in New York City but has coverage through a small regional payer in the northwest due to their employer’s location), the request is unlikely to find a match.

Limitations

Insurance discovery is a useful tool when used as a fallback. But it has limitations:

• Hit rates vary. Just sending a name, date of birth, and ZIP code will almost always result in no matches. Including SSN (even last 4), full address, and gender significantly improves results. With strong input data, match rates typically range from 30–70%.

• It only returns active coverage for the date of service in the request. It can’t return retroactive or future coverage – only what’s active on the date you specify.

• It doesn’t determine payer primacy. If you get multiple results, use a COB check to figure out which plan is primary.
  
  

• It doesn’t support dental use cases. If your use case is dental-only, discovery won’t return results – even if the patient is insured.

In most cases, you shouldn’t use insurance discovery for your primary workflow. Use it only when eligibility checks fail or aren’t possible.

Get started with insurance discovery

Stedi gives you modern APIs and tools to build accurate, reliable eligibility workflows. But when you can’t get a clean eligibility check, insurance discovery can fill the gap.

If you’re ready to get started, reach out to us for a demo or free trial. We’d love to help you get set up.