Eligibility checks verify a patient’s coverage with a specific payer. But what if you don’t know the patient’s insurance details or you’re not sure whether they have coverage at all? In these situations, you can use an insurance discovery check to search for a patient’s active coverage using only their demographic data. You may need to perform an insurance discovery check when:
  • You don’t know the payer, such as when a patient doesn’t have their insurance card or can’t provide insurance details in an urgent care situation.
  • One or more eligibility checks failed with an AAA 75 (Subscriber Not Found) or similar error.
  • The patient’s information is incomplete or outdated, such as when the patient can’t provide their member ID.
We recommend using insurance discovery checks as a backup when eligibility checks fail or aren’t possible. Because of their limitations, you shouldn’t rely on them as your primary method for verifying patient coverage.

​
Limitations

Insurance discovery checks have the following limitations:
  • Match rates vary: Insurance discovery checks aren’t guaranteed to return a patient’s active health plans 100% of the time - especially when the request doesn’t include key demographic information like the patient’s address or Social Security Number (SSN). Even with strong input data, insurance discovery match rates typically range from 30–70%.
  • Dental use cases aren’t supported: Insurance discovery checks only reliably identify active medical coverage. Some payers may return dental coverage (service type code 35) in their response, but insurance discovery checks won’t return results for dental-only payers even if the patient has coverage. Don’t use insurance discovery for dental use cases.
  • No retroactive or future coverage: Insurance discovery checks can only return active coverage for the date of service range provided. For example, if a patient recently switched insurance plans and coverage for the previous plan has ended, the insurance discovery check will only return their new, active plan.
  • No payer primacy: Insurance discovery checks can’t determine payer primacy. You must run a coordination of benefits (COB) check to determine whether the patient has active coverage with additional payers and which payer is responsible for paying claims (primacy).
  • Slower response time: Insurance discovery checks are slower than real-time eligibility checks and can take up to 120 seconds to return results. This is because Stedi performs an average of 13-16 real-time eligibility checks per insurance discovery check.

​
How insurance discovery checks work

1

Submit insurance discovery check.

Call the Insurance Discovery Check endpoint or submit through the Create insurance discovery check form in the Stedi portal.You should provide as much patient demographic information as possible to increase the chances of finding matching coverage. You’ll also include information like the provider’s NPI and the date of service, similar to an eligibility check.
2

Stedi searches for active coverage.

The insurance discovery process involves demographic lookups to enrich partial patient details, comparisons across third-party data sources to determine member IDs, and submitting real-time eligibility checks to payers to detect coverage.Stedi choose the most probable payers based on the patient’s demographic details, resulting in 13-16 real-time eligibility checks. Once all checks are complete, Stedi compiles the results into the response.
3

Receive results.

Stedi returns an array of potential active coverages along with subscriber details and benefits information. You should always review the results to ensure the returned subscriber information matches the demographic information for the patient.If there’s a match, you can use the benefits information to determine the patient’s eligibility for services. You generally shouldn’t need to perform a follow-up eligibility check since the insurance discovery response includes the same benefits information.

​
Enrollment requirements

Before you can perform insurance discovery checks, you must complete transaction enrollment for Payer ID: DISCOVERY.

​
Medicaid Provider ID

A Medicaid Provider ID is a unique identification number assigned to a healthcare provider when they enroll with a state Medicaid program. It’s different than a provider’s National Provider Identifier (NPI), which is assigned by the federal government. If a provider works in multiple states, they’ll have different Medicaid IDs for each state. Medicaid Provider IDs aren’t required for transaction enrollment with Stedi, but they can enhance insurance discovery check results for certain payers. To add Medicaid Provider IDs to transaction enrollment requests, please email enrollments@stedi.com with a CSV file containing the NPI and Medicaid ID(s) for each provider. Many state Medicaid agencies have a provider lookup tool you can use to find a provider’s Medicaid Provider ID. For example, for providers who practice in Texas, you can use the Texas Medicaid & Healthcare Partnership Provider lookup tool to search for enrolled providers. You can also call the state Medicaid agency to request a provider’s ID.

​
Required patient information

You should provide as much patient demographic information as possible when submitting insurance discovery checks. The more information you provide, the more likely Stedi is to find matching coverage.

​
Minimum required

At a minimum, you must provide the patient’s:
  • First name
  • Last name
  • Date of birth (DOB)
However, match rates will be very low with only this basic information. The reason is that the patient information provided must resolve to a single member to return results. Unless the name is extremely uncommon, a name + DOB is likely to match multiple members and result in no matches. In addition to the patient’s name and DOB, we strongly recommend providing as much of the following additional information as possible. For example, with a full or partial SSN and an address or ZIP code, match rates range from 30-70%.
  • Current address or previous addresses - especially the patient’s ZIP code, as this helps narrow down the list of probable payers. ZIP code search isn’t an exact match, so even the first 3-4 digits of the patient’s current zip code can help improve the results. If the patient’s current address isn’t available, you can try a full or partial zip code from one of the patient’s previous addresses or even one in close proximity.
  • Social Security Number (SSN) - The patient’s full SSN is preferred, but even the last 4 digits of the SSN can help narrow down matching coverage.
  • Phone number
  • Gender

​
Manual submission

You can submit insurance discovery checks through the Create insurance discovery check form in the Stedi portal.
Unlike eligibility checks, Stedi doesn’t display historical insurance discovery checks in the UI for review.

​
API submission

You can submit an insurance discovery check using the Insurance Discovery Check endpoint.

​
Request

The following example shows the payload for an insurance discovery check. 
{
  "provider": {
    "npi": "1999999984"
  },
  "encounter": {
    "beginningDateOfService": "20250326",
    "endDateOfService": "20250328"
  },
  "subscriber": {
    "dateOfBirth": "20010925",
    "firstName": "Jane",
    "lastName": "Doe",
    "address": {
      "address1": "1 MAIN ST",
      "address2": "UNIT 1",
      "city": "ANYTOWN",
      "state": "MO",
      "postalCode": "12341"
    }
  }
}

​
Response

Stedi’s synchronous response to the Insurance Discovery Check endpoint can take up to 120 seconds to return, though it’s often faster. The synchronous response can have one of two status values:
  • COMPLETE - Stedi has completed the insurance discovery check for the patient. If Stedi finds coverage for the patient, the items array will contain the results. If Stedi doesn’t find any coverage for the patient, the items array will be empty.
  • PENDING - Stedi is still processing the insurance discovery check for the patient. You can use the discoveryId in the response to retrieve the results asynchronously.
The following example response shows a PENDING insurance discovery check. In this case, you would use the discoveryId to retrieve the results asynchronously.
Insurance discovery check in progress
{
  "discoveryId": "12345678-abcd-4321-efgh-987654321abc",
  "meta": {
    "applicationMode": "production",
    "traceId": "1-abcdef12-123456789abcdef123456789"
  },
  "status": "PENDING",
  "items": []
}
The following example response shows a COMPLETE insurance discovery check. Stedi found one instance of potential matching coverage for the patient, Jane Doe. Insurance discovery checks only return active coverage for the date of service range provided, so any old plans with expired coverage aren’t included in the results. Information about the potential match is available in the items array.
  • The payer is Aetna.
  • The patient in the request, Jane, is a dependent on the Aetna plan because her demographic information appears in the dependent object in the response.
  • The confidence.level is marked as REVIEW_NEEDED, because the dependent’s last name is slightly different from the patient’s last name in the insurance discovery request. However, all of the other demographic details in the dependent object - first name, date of birth, address - match the patient from the request. The two-part last name, Smith Doe, appears to be the complete version of the last name in the request, Doe. Based on this information, we can confirm that this is active coverage for the patient.
  • The benefitsInformation object (truncated to keep this example concise) contains the patient’s benefits details. For example, the patient has active medical coverage under their health plan for the service dates in the request. Visit Determine patient benefits to learn more about interpreting the benefits information in the insurance discovery check response.
  • Payer names and IDs aren’t normalized, so you’ll need to handle matching these results to Stedi’s Payer Network or your own internal payer list.
Insurance discovery check completed
{
  "coveragesFound": 1,
  "discoveryId": "e856b480-0b41-11f0-aee6-fc0434004bca",
  "items": [
    {
      "provider": {
        "providerName": "THE DOCTORS OFFICE",
        "entityType": "Non-Person Entity",
        "npi": "1999999984"
      },
      "subscriber": {
        "memberId": "J9606211996",
        "firstName": "JOHN",
        "lastName": "DOE",
        "groupNumber": "012345607890008",
        "groupDescription": "SAMPLE HEALTH GROUP",
        "insuredIndicator": "Y"
      },
      "dependent": {
        "firstName": "JANE",
        "lastName": "SMITH DOE",
        "gender": "F",
        "dateOfBirth": "20010925",
        "planNumber": "0123654",
        "relationToSubscriber": "Child",
        "relationToSubscriberCode": "19",
        "address": {
          "address1": "1 MAIN ST",
          "address2": "UNIT 1",
          "city": "ANYTOWN",
          "state": "MO",
          "postalCode": "12341"
        }
      },
      "payer": {
        "entityIdentifier": "Payer",
        "entityType": "Non-Person Entity",
        "lastName": "Aetna",
        "name": "Aetna",
        "payorIdentification": "100003"
      },
      "planInformation": {
        "planNumber": "0123654"
      },
      "planDateInformation": {
        "planBegin": "20250101",
        "eligibilityBegin": "20250101",
        "service": "20250327"
      },
      "benefitsInformation": [
        {
           "code": "1",
           "name": "Active Coverage",
           "coverageLevelCode": "FAM",
           "coverageLevel": "Family",
           "serviceTypeCodes": [
               "30"
           ],
           "serviceTypes": [
               "Health Benefit Plan Coverage"
           ],
           "insuranceTypeCode": "PS",
           "insuranceType": "Point of Service (POS)",
           "planCoverage": "Aetna Choice POS II",
           "inPlanNetworkIndicatorCode": "W",
           "inPlanNetworkIndicator": "Not Applicable"
        },
        // truncated for brevity
        {
          "code": "W",
          "name": "Other Source of Data",
          "benefitsRelatedEntities": [
            {
              "entityIdentifier": "Payer",
              "entityType": "Non-Person Entity",
              "entityName": "AETNA",
              "address": {
                "address1": "PO BOX 981106",
                "city": "EL PASO",
                "state": "TX",
                "postalCode": "79998"
              }
            }
          ]
        }
      ],
      "confidence": {
        "level": "REVIEW_NEEDED",
        "reason": "This record was identified as a low confidence match due to a last name mismatch."
      }

    }
  ],
  "meta": {
    "applicationMode": "production",
    "traceId": "1-67e5a730-75011daa6caebf3c6595bf7c"
  },
  "status": "COMPLETE"
}
You may want to use an API client to make testing and debugging easier. We don’t recommend using Postman for requests containing Protected Health Information (PHI) because Postman defaults to storing request history - including full request payloads - on its cloud servers. You can’t turn this feature off without impractical workarounds. Visit API clients for a list of recommended clients you can use instead.

​
Retrieve results asynchronously

If the synchronous insurance discovery response indicates that the search is still PENDING, you can use the discoveryId to retrieve the complete results asynchronously from the Insurance Discovery Check Results endpoint. You can begin polling immediately after receiving the PENDING status response from the synchronous endpoint. Like the synchronous endpoint, the Insurance Discovery Check Results endpoint can take up to 120 seconds to return a response. It’s unlikely for the insurance discovery process to take more than a few minutes, so it’s rare to have to poll the asynchronous endpoint more than once. However, if you receive a PENDING status, you can poll the endpoint immediately again, and continue this polling process until the status changes to COMPLETE. Note that you should only expect to retrieve checks submitted within the last 24 hours. After 24 hours, the results may no longer be available.

​
No matches

Insurance discovery checks can return zero matches for a patient even when they have active coverage. 
{
  "coveragesFound": 0,
  "discoveryId": "0197a79a-ed75-77c3-af58-8ece597ea0be",
  "items": [],
  "meta": {
    "applicationMode": "production",
    "traceId": "1-685c0f14-1b559a954f0bd0127110d161"
  },
  "status": "COMPLETE"
}
Common reasons for zero matches include:
  • Recommended demographic data, like SSN or ZIP code, was missing from the request. You should provide as much patient demographic information as possible to increase the chances of finding matching coverage.
  • The patient’s data 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.

​
Coordination of benefits (COB) checks

Insurance discovery checks aren’t guaranteed to return all of a patient’s active health plans, so a follow-up COB check can help you determine whether the patient has active coverage with additional payers and which payer is responsible for paying claims (primacy). Once you receive the results of an insurance discovery check, we recommend performing COB checks for the patient using one of their active commercial plans.