What to do when insurance discovery returns multiple coverages

You ran an insurance discovery check and got multiple coverages back.

Now you have to figure out which one to use.

An eligibility check confirms active coverage and plan benefit details when you already know insurer and subscriber information. An insurance discovery check finds a patient's active coverage using only demographics, so you can use it when you don't know additional subscriber details.

Before a visit, you're looking for the patient's current coverage. When recovering revenue from unpaid claims, you're looking for the coverage they had on a past date of service.

This guide covers what happens after the check runs: why a response can include several coverages, how to identify the one to use, and what to do when more than one is active.

For running checks and getting the best match rates, see How to use insurance discovery.

Why does a check return more than one coverage?

A discovery check returns an items array. Each item is one possible coverage, with the payer, the person it belongs to, and a benefitsInformation array describing the plan.

{
  "coveragesFound": 1,
  "items": [
    {
      "payer": {
        "name": "Aetna",
        "payorIdentification": "100003"
      },
      "subscriber": {
        "memberId": "J9606211996",
        "firstName": "JOHN",
        "lastName": "DOE"
      },
      "benefitsInformation": [
        {
          "code": "1",  // Active coverage
          "planCoverage": "Aetna Choice POS II"
        }
      ]
      // ...
    }
  ]
}

More than one item doesn't mean the patient has more than one active plan. There are a few different reasons why a response comes back long:

Some national payers return every plan they have on file, including inactive coverage.
Payers also return coverage types you didn't ask for, so a check scoped to one service type code can come back with benefits for others.
Since discovery matches on demographics, some items won't be your patient at all.

Which coverage should I use?

Confirm the coverage is active for your date of service

Check the code on each benefitsInformation object. Codes 1-5 mean active coverage, while codes 6-8 mean inactive.

If the code comes back as 5, 7, or 8, the payer is telling you the record is under investigation or awaiting an update. Make sure to verify those with the payer before you bill.

Then check the dates in planDateInformation, which carries the plan, eligibility, and policy date ranges. If your date of service is after the earliest end date, the patient likely wasn't covered.

If the payer reports the plan as inactive, it means that plan has ended, not that the patient is uninsured – they may be covered under a different one.

For an appeal or a write-off, use the end date in that same planDateInformation object.

For more, see Active coverage, eligibility dates, plan details in our docs.

Verify the patient match

Compare each item against the demographics you submitted:

Name – Allow for variations like a hyphenated or two-part last name.
Date of birth – Must be an exact match.
Address – Must be a current or previous address.
When the patient is a dependent, their details reside in the dependent object and the policyholder's in subscriber. The two last names won't always match.
Check anything else you collected at intake, like gender, ZIP code, or state.

Note that the confidence score won't tell you which of two coverages to use. It currently returns the same value on every result. Derive your own confidence from the comparison above.

For more, see Verify the match in our docs.

Do I need a follow-up eligibility check?

It depends on your use case. Each item in the discovery check response already carries the same benefitsInformation objects an eligibility response would, so if you're looking to confirm active coverage or high-level benefit information like deductible and out-of-pocket amounts, you won't need to run anything else.

You should run a follow-up check only if you need to change the date of service or the service type code (STC). A discovery check defaults to STC 30 (Health Benefit Plan Coverage), so specialty benefits need their own eligibility check. For example, if you are looking for specific psychotherapy visit benefits, you'll want to send a subsequent eligibility check with a mental health service type code.

Send it with the exact demographic details the discovery check returned.

Which payer pays first?

If two of the items are active and both belong to your patient, you need the billing order before you can submit anything.

If a claim has already been denied for coordination of benefits (COB), you don't need the billing order. You need to know who the other payer is, and whether you already have their member ID.

If you know the other payer

You can bill without determining primacy first:

Send an eligibility check to the other plan to confirm active coverage.
Resubmit the claim to that plan as the primary and wait for adjudication.
Bill the original payer with a secondary claim built from the Electronic Remittance Advice (ERA).

Use the payment and adjustment amounts exactly as the ERA reports them. See How to balance COB claims.

Note that this workflow assumes there are two plans involved. If there's a third plan, confirm the full picture with the patient or the payers.

If you don't know the other payer

Primacy follows the NAIC Coordination of Benefits Model Regulation, which every US state has adopted. The rules are public and deterministic. But Stedi can't apply them for you, since the information they need isn't in an eligibility response.

You can run a COB check instead. This check determines primacy across a member's known coverage, and needs a successful eligibility check with active coverage first.

In a COB response, entityIdentifier contains the answer: Primary Payer, Secondary Payer, or Tertiary Payer. A value of Payer means Stedi found no COB instance or couldn't determine primacy. The same field appears in eligibility responses, where it's only an indication. Set the billing order from a COB response, not from an eligibility one.

Finding the other payer in the discovery response

Original Medicare isn't part of the COB data set, though many Medicare Advantage plans are. For a patient on Original Medicare, the discovery response can still tell you who the other payer is.

Other payers show up in the benefitsRelatedEntities array of a benefitsInformation object with code = R (Other or Additional Payor). A Medicare item will often list the supplemental plan, and vice versa.

Send an eligibility check to each plan you find there. That confirms the coverage and gives you the member ID you'll need to bill.

If benefitsRelatedEntities is empty, run another discovery check with any new details to find plans you don't have on file.

For more on recovering revenue from denied and unbilled claims, see Using Stedi insurance discovery for revenue recovery.

What if the check returns nothing?

If you get a coveragesFound: 0 result, it doesn't always mean that the patient is uninsured. It just means the check couldn't find a match.

If you run a check using name, date of birth, and ZIP code alone, it'll almost always miss. Stedi and the payer need to resolve to a single member, and having a common name in a large ZIP can lead to numerous matches.

To increase your likelihood of finding a match, add gender, a full address, and a Social Security Number (SSN) if you have one – even the last four digits help. The state matters the most, since without it, Stedi can only check large, national payers.

For the full input guidance, see How to use insurance discovery.

Get started with Stedi

You can run insurance discovery checks using Stedi's Insurance Discovery Check API or the Create insurance discovery check form in the Stedi portal.

To get started, sign up for a free sandbox account. It takes less than two minutes. No credit card is required.

When you're ready, upgrade to production on our pay-as-you-go plan. There are no monthly minimums or setup fees. You only pay for the transactions you use.

Twitter LinkedIn