Overview

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. Insurance discovery checks support both medical and dental use cases.

We recommend using insurance discovery checks as a backup when eligibility checks fail or aren't possible. Don't rely on them as your primary method for verifying patient coverage.

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:

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).

How insurance discovery works

1

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.

2

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.

3

Receive results.

Stedi returns an array of coverages along with subscriber details and benefits information. A response can include multiple coverages, and each one can be active or inactive, depending on what the payer supplied.

Review each coverage to confirm it's for your patient and active on your date of service. Visit Determine which matches to use for details.

• When a coverage passes these checks, you can use its 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.
• When more than one coverage is active for your patient, visit Handle multiple active coverages to determine the billing order.
• 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.

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.
• Limited request types: Insurance discovery checks can only request basic Health Benefit Plan Coverage (service type code 30) or Dental Benefit Plan Coverage (service type code 35). If you need specific benefits that aren't returned in the response, send a subsequent eligibility check for that service type or procedure code.
• Payers may return additional coverage types: You may receive more coverage types than you requested. For example, when you request dental coverage (service type code 35), payers may return medical coverage (service type code 30) or other coverage types in addition to dental. Some national payers return all coverage they have on file, including inactive coverage. Stedi doesn't filter these results - you receive whatever the payer returns. Review benefitsInformation.serviceTypeCodes to identify the relevant coverage for your use case.
• 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).
• API response time: The p50 latency is ~3.5 seconds and the p90 latency is ~13 seconds, and Stedi returns a response within 120 seconds. Checks that don't complete synchronously return HTTP 202 with a PENDING state, and you can retrieve the final results asynchronously.