Using Stedi insurance discovery in an EHR

Almost every healthcare billing transaction requires the patient's insurance information.

But few people know their insurance member ID by heart. Patients often forget their cards, switch plans, or don't know who covers them.

When the provider can't get that insurance information, the entire billing flow, and sometimes even care, grinds to a stop.

As a fallback, Stedi's insurance discovery check can restart it. Discovery finds the patient's coverage from demographics that the patient is likely to know, such as their name and date of birth.

This guide shows how EHR teams integrate Stedi insurance discovery into their billing workflows.

What is insurance discovery?

An insurance discovery check, also called a coverage discovery check, searches for a patient's active coverage using only their demographic data, like name, date of birth, address, and (optionally) SSN.

If the check returns active coverage, the response contains the same data as an eligibility check.

You'll get the patient's coverage status, eligibility dates, and cost-sharing details (like co-pays and deductibles). The response also includes the payer ID and member ID, which can be used later to submit a claim to the patient's payer.

When should an EHR use insurance discovery?

Insurance discovery is a fallback for eligibility checks. You use discovery checks when an eligibility check isn't possible or returns no active coverage. Some common cases include:

• The payer isn't known.

• The member ID is missing or incorrect.

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

• The patient gave conflicting or incomplete information.

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.

Patient intake

Patient intake is when a provider captures a patient's information ahead of a visit. It can include things like scheduling, pre-registration, registration, and check-in.

Providers commonly run eligibility checks during intake to answer two questions:

• Will the patient's insurance cover this visit?

• If yes, what payment should I collect from the patient before the visit?

This prevents two problems: claim denials that could leave the provider unpaid, and surprise bills for the patient.

When you can't get a clean eligibility check, insurance discovery can sometimes fill the gap.

Before claim submission

Claims require the patient's member ID and accurate demographic data, like name and address.

Providers often verify a patient's insurance before submitting a claim to confirm the patient's information is current.

It can also be useful if the patient's insurance information wasn't captured (or was inaccurately captured) during intake.

In these cases, insurance discovery checks act as a fallback when eligibility checks don't return what you need.

Revenue recovery

Revenue recovery is what a provider does to collect on past care that wasn’t paid for. It can include following up with patients on past-due balances, appealing denials, and managing write-offs.

A common reason for unpaid care is missed coverage. For example, the patient may have been insured at the time of service, but the provider didn't capture the right payer or member ID.

An insurance discovery check surfaces that coverage retroactively, turning an aging self-pay balance or denied claim into a billable one.

How do I embed Stedi insurance discovery in my EHR?

EHRs typically embed revenue cycle workflows, like claim submission and eligibility checks, directly in the product UI so providers don't have to leave.

The Insurance Discovery API is well-documented and easy to integrate with. Its responses use the same shape as Stedi's JSON Eligibility API. Many EHRs can integrate and onboard their first provider in under a day.

Tip: Give Claude Code, Cursor, or your preferred coding agent Stedi's docs and OpenAPI spec to scaffold the integration quickly. See How to use Stedi with a coding agent for more tips.

Step 1. Enroll providers with the DISCOVERY payer ID

Transaction enrollment is strongly recommended but not required for insurance discovery. Enrollment lets Stedi run MBI lookups as part of the discovery check, meaning you’ll get better results. The same enrollment covers both real-time and batch use.

To enroll a provider for insurance discovery, submit a transaction enrollment request for eligibility checks with the special DISCOVERY payer ID. You can submit enrollment requests through the Enrollments API, the Stedi portal, or a bulk CSV. Most enrollment requests go live within hours.

Step 2. Build the request

To run an insurance discovery check, make a POST to the Insurance Discovery Check endpoint with the patient's demographic information.

The minimum required fields are first name, last name, and date of birth. Match rates with only the required fields tend to be low. For better results, also include:

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

• Gender

• Full address or ZIP Code (current or previous)

An example Insurance Discovery Check API request body:

{
  "provider": {
    "npi": "1999999984"
  },
  "subscriber": {
    "firstName": "Jane",
    "lastName": "Doe",
    "dateOfBirth": "20010925",
    "ssn": "123456789",
    "gender": "F",
    "address": {
      "address1": "1 MAIN ST",
      "city": "ANYTOWN",
      "state": "MO",
      "postalCode": "12341"
    }
  },
  "encounter": {
    "beginningDateOfService": "20250326",
    "endDateOfService": "20250328"
  }
}

{
  "provider": {
    "npi": "1999999984"
  },
  "subscriber": {
    "firstName": "Jane",
    "lastName": "Doe",
    "dateOfBirth": "20010925",
    "ssn": "123456789",
    "gender": "F",
    "address": {
      "address1": "1 MAIN ST",
      "city": "ANYTOWN",
      "state": "MO",
      "postalCode": "12341"
    }
  },
  "encounter": {
    "beginningDateOfService": "20250326",
    "endDateOfService": "20250328"
  }
}

{
  "provider": {
    "npi": "1999999984"
  },
  "subscriber": {
    "firstName": "Jane",
    "lastName": "Doe",
    "dateOfBirth": "20010925",
    "ssn": "123456789",
    "gender": "F",
    "address": {
      "address1": "1 MAIN ST",
      "city": "ANYTOWN",
      "state": "MO",
      "postalCode": "12341"
    }
  },
  "encounter": {
    "beginningDateOfService": "20250326",
    "endDateOfService": "20250328"
  }
}

{
  "provider": {
    "npi": "1999999984"
  },
  "subscriber": {
    "firstName": "Jane",
    "lastName": "Doe",
    "dateOfBirth": "20010925",
    "ssn": "123456789",
    "gender": "F",
    "address": {
      "address1": "1 MAIN ST",
      "city": "ANYTOWN",
      "state": "MO",
      "postalCode": "12341"
    }
  },
  "encounter": {
    "beginningDateOfService": "20250326",
    "endDateOfService": "20250328"
  }
}

{
  "provider": {
    "npi": "1999999984"
  },
  "subscriber": {
    "firstName": "Jane",
    "lastName": "Doe",
    "dateOfBirth": "20010925",
    "ssn": "123456789",
    "gender": "F",
    "address": {
      "address1": "1 MAIN ST",
      "city": "ANYTOWN",
      "state": "MO",
      "postalCode": "12341"
    }
  },
  "encounter": {
    "beginningDateOfService": "20250326",
    "endDateOfService": "20250328"
  }
}

Step 3. Handle the response

In most cases, Insurance Discovery Check API requests return a synchronous response within 120 seconds (often faster). For example:

{
  "status": "COMPLETE",
  "coveragesFound": 1,
  "discoveryId": "12345678-abcd-4321-efgh-987654321abc",
  "items": [
    {
      "payer": {
        "name": "Aetna",
        "payorIdentification": "100003"
      },
      "subscriber": {
        "memberId": "J9606211996",
        "firstName": "JOHN",
        "lastName": "DOE"
      },
      "dependent": {
        "firstName": "JANE",
        "lastName": "DOE",
        "dateOfBirth": "20010925",
        "relationToSubscriber": "Child"
      },
      "benefitsInformation": [
        {
          "code": "1",  // Active coverage
          "serviceTypes": ["Health Benefit Plan Coverage"],
          "planCoverage": "Aetna Choice POS II"
        }
      ],
      "confidence": {
        "level": "REVIEW_NEEDED",
        "reason": "This record was identified as a low confidence match due to a last name mismatch."
      }
    }
  ]
}

{
  "status": "COMPLETE",
  "coveragesFound": 1,
  "discoveryId": "12345678-abcd-4321-efgh-987654321abc",
  "items": [
    {
      "payer": {
        "name": "Aetna",
        "payorIdentification": "100003"
      },
      "subscriber": {
        "memberId": "J9606211996",
        "firstName": "JOHN",
        "lastName": "DOE"
      },
      "dependent": {
        "firstName": "JANE",
        "lastName": "DOE",
        "dateOfBirth": "20010925",
        "relationToSubscriber": "Child"
      },
      "benefitsInformation": [
        {
          "code": "1",  // Active coverage
          "serviceTypes": ["Health Benefit Plan Coverage"],
          "planCoverage": "Aetna Choice POS II"
        }
      ],
      "confidence": {
        "level": "REVIEW_NEEDED",
        "reason": "This record was identified as a low confidence match due to a last name mismatch."
      }
    }
  ]
}

{
  "status": "COMPLETE",
  "coveragesFound": 1,
  "discoveryId": "12345678-abcd-4321-efgh-987654321abc",
  "items": [
    {
      "payer": {
        "name": "Aetna",
        "payorIdentification": "100003"
      },
      "subscriber": {
        "memberId": "J9606211996",
        "firstName": "JOHN",
        "lastName": "DOE"
      },
      "dependent": {
        "firstName": "JANE",
        "lastName": "DOE",
        "dateOfBirth": "20010925",
        "relationToSubscriber": "Child"
      },
      "benefitsInformation": [
        {
          "code": "1",  // Active coverage
          "serviceTypes": ["Health Benefit Plan Coverage"],
          "planCoverage": "Aetna Choice POS II"
        }
      ],
      "confidence": {
        "level": "REVIEW_NEEDED",
        "reason": "This record was identified as a low confidence match due to a last name mismatch."
      }
    }
  ]
}

{
  "status": "COMPLETE",
  "coveragesFound": 1,
  "discoveryId": "12345678-abcd-4321-efgh-987654321abc",
  "items": [
    {
      "payer": {
        "name": "Aetna",
        "payorIdentification": "100003"
      },
      "subscriber": {
        "memberId": "J9606211996",
        "firstName": "JOHN",
        "lastName": "DOE"
      },
      "dependent": {
        "firstName": "JANE",
        "lastName": "DOE",
        "dateOfBirth": "20010925",
        "relationToSubscriber": "Child"
      },
      "benefitsInformation": [
        {
          "code": "1",  // Active coverage
          "serviceTypes": ["Health Benefit Plan Coverage"],
          "planCoverage": "Aetna Choice POS II"
        }
      ],
      "confidence": {
        "level": "REVIEW_NEEDED",
        "reason": "This record was identified as a low confidence match due to a last name mismatch."
      }
    }
  ]
}

{
  "status": "COMPLETE",
  "coveragesFound": 1,
  "discoveryId": "12345678-abcd-4321-efgh-987654321abc",
  "items": [
    {
      "payer": {
        "name": "Aetna",
        "payorIdentification": "100003"
      },
      "subscriber": {
        "memberId": "J9606211996",
        "firstName": "JOHN",
        "lastName": "DOE"
      },
      "dependent": {
        "firstName": "JANE",
        "lastName": "DOE",
        "dateOfBirth": "20010925",
        "relationToSubscriber": "Child"
      },
      "benefitsInformation": [
        {
          "code": "1",  // Active coverage
          "serviceTypes": ["Health Benefit Plan Coverage"],
          "planCoverage": "Aetna Choice POS II"
        }
      ],
      "confidence": {
        "level": "REVIEW_NEEDED",
        "reason": "This record was identified as a low confidence match due to a last name mismatch."
      }
    }
  ]
}

Some tips for interpreting the response:

• Treat each item in the items array as a candidate for insurance coverage, not confirmed. Use each item's confidence object to flag low-quality matches, like last-name mismatches, to review before billing.

• benefitsInformation objects contain most of the benefits information for a patient. These objects follow the same structure as those in our JSON eligibility responses.

Asynchronous responses

Synchronous Insurance Discovery Check API responses can have one of two status values:

• COMPLETE – The discovery check finished.

• PENDING – The discovery check is still running.

Most checks are completed on the first call with a COMPLETE status. If the status is PENDING, poll the Insurance Discovery Check Results endpoint with the returned discoveryId. For example:

curl --request GET \
  --url "https://healthcare.us.stedi.com/2024-04-01/insurance-discovery/check/v1/{discoveryId}" \
  --header "Authorization: <api_key>"

curl --request GET \
  --url "https://healthcare.us.stedi.com/2024-04-01/insurance-discovery/check/v1/{discoveryId}" \
  --header "Authorization: <api_key>"

curl --request GET \
  --url "https://healthcare.us.stedi.com/2024-04-01/insurance-discovery/check/v1/{discoveryId}" \
  --header "Authorization: <api_key>"

curl --request GET \
  --url "https://healthcare.us.stedi.com/2024-04-01/insurance-discovery/check/v1/{discoveryId}" \
  --header "Authorization: <api_key>"

curl --request GET \
  --url "https://healthcare.us.stedi.com/2024-04-01/insurance-discovery/check/v1/{discoveryId}" \
  --header "Authorization: <api_key>"

Async results use the same shape as synchronous Insurance Discovery Check endpoint responses. Async results are available for 24 hours after submission.

What are the limitations of insurance discovery checks?

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

• Slower than eligibility checks – up to 120 seconds. Most eligibility checks return results in 1-3 seconds.

• Not guaranteed to return results, even with strong demographic input.

• No dental support. Dental-only payers won't return results, even if the patient has coverage.

• No payer primacy. If discovery returns multiple coverages, follow up with a Coordination of Benefits (COB) check to determine which payer is primary.

Can providers use the Stedi portal to run insurance discovery checks?

When a discovery scenario falls outside the EHR's UI, providers can submit one-off checks using the Create insurance discovery check form in the Stedi portal.

This is useful for EHR developers using Stedi's integrated account model, where providers have their own Stedi accounts. EHRs can give their providers the option to run insurance discovery checks without having to integrate and build a dedicated UI.

Get started with insurance discovery

Stedi provides developer-friendly APIs that EHRs and practice management systems can embed directly. You get eligibility checks, insurance discovery, claims submission, and ERA processing across thousands of payers.

If you're ready to get started, reach out to us for a demo or free trial. We'll help you build an integration plan that fits your EHR.