Insurance discovery checks

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.

Insurance discovery checks return an array of coverages along with subscriber details and benefits information. These coverages may be active or inactive, and there may be multiple of each type. If an insurance discovery check returns active coverage for the patient, you don't need to perform a follow-up eligibility check. The results include the same benefits information you'd get from running an eligibility check with the payer.

Use cases

If you have all the patient's demographic details (first name, last name, date of birth, member ID) and know the payer, running a standard eligibility check with that payer is always the most cost-effective and reliable path. Insurance discovery is the best option if running a standard eligibility check isn't possible.

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.
The coverage on file is no longer active, such as when a member changes employers or loses coverage.

The most common workflows for eligibility checks and insurance discovery are patient intake and claims submission. You can also use insurance discovery checks during revenue recovery. The following flowchart shows how insurance discovery works as part of these workflows:

Insurance discovery workflow

For patients who are likely covered by Medicare, such as those 65 or older, an MBI lookup is a targeted alternative to an insurance discovery check. An MBI lookup returns the patient's Medicare Beneficiary Identifier (MBI) and, if found, the patient's complete eligibility response from Medicare. You can run MBI lookups using only the patient's demographic information and (optionally) Social Security Number (SSN).

Usage notes

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 state or Social Security Number (SSN). Although unlikely, false positives are possible, so you're ultimately responsible for matching results to your own records.
Dental and vision use cases aren't supported: Insurance discovery checks only reliably identify active medical coverage. Some payers may return dental coverage (service type code 35) or vision coverage (service type code AL) in their response, but insurance discovery checks won't return results for dental-only or vision-only payers even if the patient has coverage. Don't use insurance discovery for dental or vision use cases.
Coverage is relative to service dates: Insurance discovery checks can only return active coverage for the service dates in the request. For example: A patient starts a new job, and coverage with their new employer starts through Cigna in March 2026. Previously, they had active coverage through UnitedHealthcare (UHC). If you submit an insurance discovery check for a date of service in February 2026, and it succeeds, Stedi returns active coverage for UHC and no coverage for Cigna.
No payer primacy: Insurance discovery checks can't determine payer primacy. You must either run a coordination of benefits (COB) check or use your own internal logic to determine whether the patient has active coverage with additional payers and which payer is responsible for paying claims (primacy).
Response time: The p50 latency is ~3.5 seconds and the p90 latency is ~13 seconds. If the discovery check has not completed after 120 seconds, it returns a PENDING state, and you can retrieve the final results asynchronously.

How insurance discovery works

Submit insurance discovery check.

Call the Insurance Discovery Check endpoint or submit through the Create insurance discovery check form in the Stedi portal.

Provide as much patient demographic information as possible, such as first name, last name, DOB, state, and SSN, 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.

Stedi searches for active coverage.

Stedi uses the supplied information - alongside its proprietary logic - to find coverage. This process usually takes between 3.5s and 13s.

Receive results.

Stedi returns an array of coverages along with subscriber details and benefits information. Always review the results to ensure that the returned subscriber information matches the patient's demographic information. These coverages could be active or inactive, depending on what the payer supplied.

If there's a match, you can use the benefits information to determine the patient's eligibility for services. Since the coverage result comes directly from the payer's 271 response, you don't need to perform a follow-up eligibility check, as the insurance discovery response includes all the necessary benefits information.
If you need to change the date of service or service type code (STC), run a standard eligibility check with the exact demographic information the insurance discovery check returned.

Run insurance discovery checks

You can run insurance discovery checks manually through the Stedi portal or programmatically through Stedi's API.

Transaction enrollment

Transaction enrollment isn't required for insurance discovery, but we do strongly recommend it. Enrollment lets Stedi run MBI lookups as part of the discovery check in addition to checks to other large payers that require enrollment, improving your results.

To enroll, submit an enrollment request for the Stedi insurance discovery payer (payer ID: DISCOVERY):

Create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step. Stedi portal | API endpoint
Submit an enrollment request for Real-time eligibility checks. Use DISCOVERY as the payer ID (Stedi Insurance Discovery). Stedi portal | API endpoint

Medicaid Provider ID

A Medicaid Provider ID is a unique identification number that state Medicaid programs assign to healthcare providers when they enroll. It's different than a provider's National Provider Identifier (NPI), which the federal government assigns. 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, 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, providers practicing in Texas 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

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)

State from the current address or previous addresses. This ensures that Stedi's insurance discovery logic finds localized, relevant payers. Without the state, Stedi can only determine coverage from the large, national payers.
Social Security Number (SSN). The patient's full SSN is best, but even the last 4 digits of the SSN can help narrow down matching coverage.

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 an insurance discovery check for a patient named Jane Doe.

curl --request POST \
  --url "https://healthcare.us.stedi.com/2024-04-01/insurance-discovery/check/v1" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
      "provider": {
        "npi": "1999999984"
      },
      "encounter": {
        "beginningDateOfService": "20250326",
        "endDateOfService": "20250328"
      },
      "subscriber": {
        "dateOfBirth": "20010925",
        "firstName": "Jane",
        "lastName": "Doe",
        "ssn": "123456789",
        "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, though it's often faster (typically 3.5-12 seconds).

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 contains the results. If Stedi doesn't find any coverage for the patient, the items array is 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 use the discoveryId to retrieve the results asynchronously.

{
  "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 provided date-of-service range, so old plans with expired coverage aren't in the results.

Information about the potential match is available in the items array.

The payer is Aetna. Payer names and IDs aren't normalized, so you may need to handle matching these results to Stedi's Payer Network or your own internal payer list.
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 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, you 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.

{
  "coveragesFound": 1,
  "discoveryId": "12345678-abcd-4321-efgh-987654321abc",
  "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"
}

Concurrency limit

Visit Concurrency limits for more information.

Recommended API clients

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 can only expect to retrieve checks submitted within the last 24 hours. After 24 hours, the results may no longer be available.

Verify the match

Always verify that the returned subscriber or dependent information matches the demographic information you submitted for the patient. Pay special attention to:

Name matching - The patient's name must match, though slight variations (like hyphenated last names) may appear.
Date of birth - Must match exactly.
Address - Must match or be a previous address.

If the information matches, you can use the benefits details to understand the patient's coverage. You don't need to run a follow-up eligibility check since the insurance discovery response includes the same benefits information.

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 state or SSN, was missing from the request. 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 demographics in the request don't match the patient's legal name or date of birth.
The payer that the patient has doesn't support real-time eligibility checks, which makes it impossible for Stedi to determine coverage.
The patient has coverage with a payer that supports eligibility checks, but Stedi's insurance discovery system couldn't find the payer.

We're always looking for feedback. If you know the patient has coverage and determined the payer through other means, reach out to Stedi's support team for further investigation.

Insurance discovery checks

On this page