Medicare Beneficiary Identifier (MBI) lookup

A Medicare Beneficiary Identifier (MBI) is a unique, randomly-generated identifier assigned to individuals enrolled in Medicare. You must include the patient's MBI in every eligibility check you submit to the Centers for Medicare and Medicaid Services (payer ID: CMS).

When patients don't know their MBI, you can use Stedi's eligibility APIs to perform an MBI lookup instead of a standard eligibility check. Stedi returns a complete eligibility response containing the patient's coverage status and their MBI for future reference.

There is an additional cost to perform MBI lookups with Stedi's eligibility check APIs. Visit pricing for details.

Types of MBI lookups

There are two types of MBI lookups you can perform with Stedi. For each, you'll use a payer ID that tells Stedi to perform an MBI lookup for the patient in addition to a standard eligibility check.

Type	What's required	Payer ID
With SSN	first name, last name, date of birth, Social Security Number (SSN)	MBILU
No SSN	first name, last name, date of birth, U.S. state (plus a city on the Raw X12 and SOAP endpoints)	MBILUNOSSN

We recommend running MBI lookups with the patient's SSN whenever possible. When the SSN is present, the MBI lookup has a higher likelihood of successfully returning their MBI. MBI lookups with no SSN are a fallback option when the patient's SSN isn't available.

You don't need to include more patient demographic information than what's required, such as additional address data. It doesn't improve MBI lookup success rates.

Transaction enrollment

Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer.

Unlike standard eligibility checks, MBI lookups always require transaction enrollment. This is because MBI lookups involve sending requests to Stedi payers that tell Stedi to perform the MBI lookup in addition to a standard eligibility check. You must enroll the provider with Stedi's MBI lookup payers to use these services.

To enroll, complete the following steps:

1. Create a provider record with the information required for enrollment. If you already have a record for the provider, you can skip this step. Stedi portal | API endpoint

2. Submit an enrollment request for Real-time eligibility checks. Stedi portal | API endpoint

   Select the payer ID based on the type of MBI lookup you want to perform:

   • With SSN: MBILU (CMS MBI Lookup)
   • No SSN: MBILUNOSSN (CMS MBI Lookup Without SSN)

If you want to perform both types of MBI lookups, you must submit separate enrollment requests for each payer ID.

When MBI lookups with SSN (Payer ID: MBILU) fail because the provider isn't enrolled, Stedi automatically submits the required transaction enrollment request. Learn more

Run MBI lookups

You can run MBI lookups with and without SSN using the following endpoints:

• Real-Time Eligibility Check JSON
• Real-Time Eligibility Check Raw X12
• Real-Time Eligibility Check SOAP
• Batch Eligibility Check

You can also run MBI lookups with and without SSN through the eligibility check form in the Stedi portal and through bulk CSV uploads.

Request

Construct an eligibility check request that includes the required patient demographic data:

• With SSN: first name, last name, date of birth, Social Security Number (SSN)
• No SSN: first name, last name, date of birth, U.S. state. For the Raw X12 and SOAP endpoints, you must also include a city in Loop 2100C N4 (Subscriber City/State/ZIP Code). You can use a dummy city value, such as DUMMY, if needed. If you omit the city value, you receive an X12 validation error.

Identify the lookup type with one of these payer IDs, which tell Stedi to perform an MBI lookup for the patient in addition to a standard eligibility check:

• With SSN: MBILU
• No SSN: MBILUNOSSN

You don't need to include other patient information, such as additional address data. It doesn't improve lookup success rates.

The following sample requests show how to perform an MBI lookup for a patient named Jane Doe.

JSON

The following examples show MBI lookups with and without SSN for the Real-Time Eligibility Check JSON endpoint.

With SSN

curl --request POST \
  --url https://healthcare.us.stedi.com/2026-06-01/eligibility-check \
  --header 'Authorization: <api-key>' \
  --header 'Content-Type: application/json' \
  --data '{
  "payerId": "MBILU",
  "externalPatientId": "UAA111222333",
  "encounter": {
    "services": [
      {
        "value": "30",
        "system": "STC"
      }
    ]
  },
  "provider": {
    "name": {
      "organization": "ACME Health Services"
    },
    "npi": "1999999984"
  },
  "subscriber": {
    "dateOfBirth": "1900-01-01",
    "name": {
      "person": {
        "firstName": "Jane",
        "lastName": "Doe"
      }
    },
    "additionalInformation": {
      "ssn": "123456789"
    }
  }
}'

The following examples show MBI lookups with and without SSN for the Batch Eligibility Check endpoint.

With SSN

curl --request POST \
  --url https://manager.us.stedi.com/2024-04-01/eligibility-manager/batch-eligibility \
  --header 'Authorization: <api-key>' \
  --header 'Content-Type: application/json' \
  --data '{
  "items": [
    {
      "submitterTransactionIdentifier": "ABC123456789",
      "tradingPartnerServiceId": "MBILU",
      "encounter": {
        "serviceTypeCodes": [
          "30"
        ]
      },
      "provider": {
        "organizationName": "ACME Health Services",
        "npi": "1999999984"
      },
      "subscriber": {
        "firstName": "Jane",
        "lastName": "Doe",
        "dateOfBirth": "19000101",
        "ssn": "123456789"
      }
    }
  ]
}'

X12

The following examples show an MBI lookup with SSN for the Raw X12 and SOAP endpoints.

For a no SSN lookup, send MBILUNOSSN in Loop 2100A NM109 (Information Source Primary Identifier), omit the patient's SSN, and include their state and city in Loop 2100C N4 (Subscriber City/State/ZIP Code) instead.

Raw X12

curl --request POST \
  --url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3/raw-x12' \
  --header 'Authorization: <api-key>' \
  --header 'Content-Type: application/json' \
  --data '{
  "x12": "ISA*00*          *00*          *ZZ*AV09311993     *01*030240928      *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*CMS MBI Lookup*****PI*MBILU~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*0~TRN*1*00000000000000000000000000*3117151744~NM1*IL*1*Doe*****MI*123456789~REF*SY*123456789~DMG*D8*19550505~EQ*30~SE*13*0001~GE*1*1~IEA*1*000000001~"
}'

Response

Stedi uses the patient's demographic data, along with their SSN or state, to perform an MBI lookup. If there is a match, Stedi submits an eligibility check to CMS. The response shape is the same for both the SSN and no SSN lookup types.

Stedi returns a complete eligibility response from CMS for the patient, including their MBI. You can find the MBI in the following locations:

• Real-Time JSON: subscriber.memberId
• Raw X12: subscriber.memberId
• Batch: items[].subscriber.memberId
• SOAP: Loop 2100C NM109 (Subscriber Primary Identifier), with NM108 (Identification Code Qualifier) set to MI

Visit Active coverage and benefits for details about how you can use the eligibility response to determine a patient's coverage status and benefits. Although unlikely, false positives are possible, so you're ultimately responsible for matching results to your own records.

The following examples show a CMS eligibility response returned from an MBI lookup. In this scenario, the patient's MBI is 1AA2CC3DD45.

Concurrency limit

MBI lookups you perform using real-time eligibility check endpoints (JSON and Raw X12) share a concurrency pool with other real-time healthcare APIs. For more information, visit Concurrency limits.

MBI lookups you perform using the Batch Eligibility Check endpoint don't count toward your Stedi account concurrency limit.

Mock request

When you submit the following mock MBI lookup request with a test API key, Stedi returns mock benefits data you can use for testing. The mock request works with Stedi's JSON, Raw X12, and SOAP endpoints.

This mock request is for an MBI lookup with SSN.

Mock requests are free for testing purposes and won't incur any charges in your Stedi account.

Request notes:

• MBI lookup supports only service type code 30.
• You can use any organization name and any NPI, as long as it passes check digit validation. To generate a dummy NPI, you can use this free tool.
• You must use the exact patient values shown in the test request. Other birth dates, first names, last names, and Social Security Numbers return errors.

Health Insurance Claim Number (HICN)

Some payers return the patient's MBI in a standard eligibility response, without you performing an MBI lookup. Where it appears depends on the endpoint:

• Real-Time JSON: subscriber.additionalInformation.mbi, or additionalInformation.mbi on an individual benefit
• Raw X12: benefitsInformation[].benefitsAdditionalInformation.hicNumber or planInformation.hicNumber
• Batch: items[].benefitsInformation[].benefitsAdditionalInformation.hicNumber or items[].planInformation.hicNumber
• SOAP: REF (Subscriber Additional Identification) in Loop 2100C or Loop 2110C, with REF01 set to F6

If the value matches the format specified in the Medicare Beneficiary Identifier documentation, the number is likely an MBI. In these cases, you don't need to perform an MBI lookup - you can use this value in a standard eligibility check to CMS.

You're most likely to receive an MBI in eligibility responses from commercial Medicare Advantage plans, but they can also be present in responses from Medicaid plans for dual-eligible patients.

Medicare Advantage plans

A Medicare Advantage plan (also known as Medicare Part C) is a type of health insurance plan offered by private companies that contract with Medicare to provide all of a patient's Part A (hospital insurance) and Part B (medical insurance) benefits.

Medicare Advantage plans have their own unique member ID, which the MBI lookup response doesn't return. However, the MBI lookup response includes the patient's Medicare Advantage plan name when available. Where it appears depends on the endpoint:

• Real-Time JSON: relatedEntities[].name.organization on the relevant benefit
• Raw X12: benefitsInformation[].benefitsRelatedEntities[].entityName
• Batch: items[].benefitsInformation[].benefitsRelatedEntities[].entityName
• SOAP: Loop 2120C NM103 (Benefit Related Entity Last or Organization Name)

Don't submit eligibility checks for Medicare Advantage plans to CMS (HETS) - submit them to the actual Medicare Advantage plan payer instead.

Many Medicare Advantage plans allow you to submit eligibility checks with just the patient's name and date of birth. However, if that approach is unsuccessful and you don't have the patient's member ID, you can use Insurance Discovery to retrieve benefits information with the patient's demographic information instead.

HETS Rules of Behavior

You must abide by the HIPAA Eligibility Transaction System (HETS) Rules of Behavior when you use MBI lookup. HETS is intended to support original Medicare fee-for-service (FFS) activities, such as preparing and submitting FFS claims.

If you have no intention of submitting claims to Medicare, using MBI lookup to identify whether a patient is enrolled in a Medicare Advantage plan is likely outside the scope of permitted HETS use. You should consult your own legal counsel to determine what's permissible for your specific situation.

Stedi can't make this determination on your behalf or provide consultation about what may or may not be permitted.

Outdated MBI error

Stedi's MBI lookup may rarely retrieve an outdated MBI for a patient. The Centers for Medicare and Medicaid Services (CMS) may rotate an MBI for a member for various reasons at any time, such as to help protect against identity theft.

In these cases, the response contains an AAA error with code 72 (Invalid/Missing Subscriber/Insured ID) and the outdated MBI.

The following examples show only the AAA error and the outdated MBI.

JSON

The Real-Time Eligibility Check JSON endpoint returns the error in the top-level errors array. The outdated MBI is in subscriber.memberId. Errors from Loop 2100C (Subscriber Name) have location set to SUBSCRIBER.

{
  "errors": [
    {
      "code": "72",
      "description": "Invalid/Missing Subscriber/Insured ID",
      "followupAction": "Please Correct and Resubmit",
      "location": "SUBSCRIBER",
      "possibleResolutions": "The subscriber's member ID is either missing or invalid.\n\u2022 Check the `subscriber.memberId`.\n\u2022 Ensure the member ID doesn't include the [Card Issuer Identifier](https://www.stedi.com/docs/healthcare/eligibility-troubleshooting#card-issuer-identifier-80840).\n\u2022 If you can't locate the correct member ID, try running an [insurance discovery check](https://www.stedi.com/docs/healthcare/insurance-discovery) to retrieve the patient's benefits information instead."
    }
  ],
  "subscriber": {
    "memberId": "1AA2CC3DD45"
  }
}

Recommended retry strategy

Implementing the right retry strategy for eligibility check failures saves a lot of time and money.

At a minimum, we strongly recommend automatically retrying every request that fails due to payer connectivity issues. Automatic retries resolve a significant portion of these types of failures without manual intervention. Visit Retry strategy for details.

CMS traceability requirements

All parties involved in HETS eligibility transactions must comply with the HETS Rules of Behavior. Compliance is also required under our terms. Review the Rules of Behavior before sending eligibility checks to CMS.

Starting November 8, 2025, the Centers for Medicare & Medicaid Services (CMS) requires submitters to include the entire chain of network hops for every eligibility request sent to CMS's eligibility system, HETS.

Specifically, requests must include an X-Forwarded-For HTTP header containing the network IP addresses from the point of origin through receipt by the HETS system. CMS expects X-Forwarded-For to list each IP, comma-separated, starting with the originating system and continuing through every intermediary.

To comply with this requirement:

• You must collect all IP addresses for upstream requests and pass them in the standard X-Forwarded-For header when calling Stedi's API. If you are yourself an intermediary – for example, an RCM, EHR, or PMS system – you'll need to coordinate with your providers and any third-party organizations to ensure they include the Network IP details as part of the X-Forwarded-For header. This enables CMS to receive a complete list of all IPs, including the original initiator of the request (typically, the provider).
• Stedi records the IP address you use when you call our API, as well as all the IP addresses listed in the X-Forwarded-For header. We include these IP addresses in the list submitted to CMS.

You only need to include the X-Forwarded-For header in eligibility requests when there are upstream IP addresses.

The following examples illustrate when and how to include the header:

Scenario	X-Forwarded-For required?	Result
A provider (IP 2.2.2.2) connects directly to Stedi without intermediaries.	No.	CMS ultimately receives X-Forwarded-For: 2.2.2.2
A provider (IP 2.2.2.2) routes through an RCM platform's transactional system (IP 3.3.3.3) that calls Stedi's API using a separate integration backend (IP 4.4.4.4).	Yes. The RCM platform sets X-Forwarded-For: 2.2.2.2, 3.3.3.3. Stedi records the IP address of the API caller (4.4.4.4 ) and sends it to CMS.	CMS ultimately receives X-Forwarded-For: 2.2.2.2, 3.3.3.3, 4.4.4.4.
A provider network (IP 2.2.2.2) passes through an office firewall (IP 4.4.4.4) and then an RCM platform (IP 3.3.3.3), which calls Stedi's API.	Yes. The RCM platform sets X-Forwarded-For: 2.2.2.2, 4.4.4.4. Stedi records the IP address of the API caller (3.3.3.3) and sends it to CMS.	CMS ultimately receives X-Forwarded-For: 2.2.2.2, 4.4.4.4, 3.3.3.3.

U.S. IP address requirement

Stedi blocks eligibility requests to CMS when any IP address in the chain – the originating IP address or any in the X-Forwarded-For header – is located outside the United States.