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 find a patient’s active coverage using only their demographic data.

You may need to perform an insurance discovery check when a patient provides outdated insurance details, doesn’t have their insurance card, or can’t provide insurance details in an urgent care situation. You may also want to use insurance discovery checks to simplify patient onboarding by reducing the amount of information new patients must provide to schedule an appointment.

Once you identify active coverage through an insurance discovery check, we recommend performing 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).

​

How insurance discovery checks work

Here’s how insurance discovery checks work:

1. Call the Insurance Discovery Check endpoint with 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 determines if the patient has active coverage with one or more payers. This 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.
3. 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 for each active health plan matches the demographic information for the patient. Once you confirm matching coverage, 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 as a standard eligibility check.

​

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

At a minimum, you must provide the patient’s first name, last name, and date of birth (DOB) in each insurance discovery check.

However, the more demographic information you provide, the more likely Stedi is to find matching coverage with a high confidence level. Generally, the more common the patient’s name, the more important it is to include more demographic information. Regardless, we strongly recommend providing as much of the following additional patient information as possible:

• Current address - especially the patient’s ZIP code, as this helps narrow down the list of probable payers.
• Previous addresses
• Social Security Number (SSN)
• 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 portal 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": {
    "organizationName": "THE DOCTORS OFFICE",
    "npi": "1999999984"
  },
  "encounter": {
    "beginningDateOfService": "20250326",
    "endDateOfService": "20250328"

  },
  "controlNumber": "123456789",
  "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.

{
  "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. The information 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.

{
  "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": "2025-01-01",
        "eligibilityBegin": "2025-01-01",
        "service": "2025-03-27"
      },
      "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 to preserve space
        {
          "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"
}

​

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.

​

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.