Turn messy payer names into valid IDs

The big takeaway: Manually entered payer names are often wrong. Use Stedi's Search Payers endpoint to find the closest matching payer ID. Then verify it's the right payer with an eligibility check.

Healthcare runs on forms. People often fill them out wrong.

One thing we commonly see is the plan name entered as the payer name. A tired nurse sees "UHC Open Access Plus" on an insurance card and enters it as the payer name. But that's actually the plan name. The payer is UnitedHealthcare.

It’s an honest mistake. But if you’re building on top of that data, it can break your workflow.

Clearinghouse transactions – like claims – need a payer ID. It’s like a routing number for the payer. Use the wrong ID, and your claims are likely to be rejected. And that may mean delayed payments for the provider.

When payer names are clean and trustworthy, finding their IDs is easy. You can just use the top result from Stedi’s Search Payers endpoint.

But when the data is dirty, you need a verification workflow. This guide lays out our recommended flow. It’s based on what we’ve seen work with customers.

Step 1. Run a payer search

Use the Search Payers endpoint to search for the payer name:

curl --request GET \
  --url "https://healthcare.us.stedi.com/2024-04-01/payers/search?query=uhc+open+access+plus" \
  --header "Authorization: <api_key>"

Results are sorted by relevance. Store the top result's primaryPayerId as the payer ID:

{
  "items": [
    {
      "payer": {
        "stediId": "KMQTZ",
        "displayName": "UnitedHealthcare",
        "primaryPayerId": "87726",            // Payer ID
        ...
      }
    },
    ...
  ],
  ...
}

The Search Payers endpoint’s search algorithm is greedy. It’ll almost always return something, even for an unmappable payer name like BCBS out of state.

It’s important to verify the patient has coverage with the payer before using the payer ID in a workflow.

Step 2. Verify the payer ID using an eligibility check

Eligibility checks are fast, inexpensive, and easy to automate. This makes them a good choice to verify a patient’s payer.

Run an eligibility check to verify the payer ID. For example, using the Real-Time Eligibility Check JSON endpoint:

curl --request POST \
  --url "https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3" \
  --header "Authorization: <api_key>" \
  --header "Content-Type: application/json" \
  --data '{
  "tradingPartnerServiceId": "87726",            // Payer ID
  "encounter": {
    "serviceTypeCodes": ["30"]
  },
  "provider": {                                  // Provider data
    "organizationName": "ACME Health Services",
    "npi": "2528442009"
  },
  "subscriber": {                                // Patient data
    "memberId": "1234567890",
    "firstName": "Jane",
    "lastName": "Doe",
    "dateOfBirth": "19850101"
  }
}'

The results will tell you if the patient has active coverage with the payer. If so, you can use the payer ID in other workflows for the patient. For tips on interpreting the results, see Active and inactive coverage in the Stedi docs.

If the check returns AAA error 75 (Subscriber/Insured Not Found) or a similar error, it means the payer search likely matched the wrong payer. Move on to step 3.

Step 3. Manually check the rest

Some raw payer names can't be mapped automatically. They need human judgment to pick the right ID.

Many payers use separate payer names and payer IDs for different lines of business, states, or coverage types.

For example, searching "Aetna" returns their main commercial ID first, but they also have separate IDs for each state's Medicaid plan. Without more context, you can't pick the right one.

Other payer name strings can’t be mapped to a valid payer ID at all:

• BCBS out of state (which state?)

• Insurance pending (not a payer)

• Typos that match nothing

Mark these for review or flag them with the provider. Don't guess.

Things to watch out for

Don’t send Medicare Advantage checks to CMS

Medicare Advantage isn't Medicare. It's commercial insurance that Medicare has approved.

Medicare Advantage plans and payers often have “Medicare” in their names. With typos, it’s easy to run a search for these payers that returns the National Centers for Medicare & Medicaid Services (CMS) – the government payer for Medicare – instead of the commercial payer you need.

CMS forbids using its system for Medicare Advantage checks. To avoid doing that, filter anything with "Medicare" in the name. Make sure it’s not a Medicare Advantage check before sending it to CMS.

Blue Cross Blue Shield eligibility responses

Blue Cross Blue Shield (BCBS) isn't one payer. It's a collection of 30+ separate entities. However, a BCBS payer can verify any other BCBS member through the BlueCard network.

For example, if you send an eligibility check to BCBS Texas for a BCBS Alabama member, you'll get benefits back. It may not be obvious that BCBS Alabama is the home payer.

To get the home payer, check the response's benefitsRelatedEntities for an entry with entityIdentifier = "Party Performing Verification". The entityIdentificationValue is the home payer’s ID. Use that payer ID for claims and other workflows.

{
  ...
  "benefitsInformation": [
    {
      "code": "1",
      "serviceTypeCodes": ["30"],
      ...
      "benefitsRelatedEntities": [
        {
          "entityIdentifier": "Party Performing Verification",
          "entityType": "Non-Person Entity",
          "entityName": "Blue Cross Blue Shield of Alabama",
          "entityIdentification": "PI",
          "entityIdentificationValue": "00510BC"
        }
      ]
    },
    ...
  ],
  ...
}

Get help when you need it

We’ve seen the workflow above work about 80% of the time. For the remaining 20%, patterns often emerge.

If there’s a raw payer name string that’s giving you trouble, reach out. Our team can help with payer ID matching.