# Active coverage, eligibility dates, plan details
Source: https://www.stedi.com/docs/healthcare/eligibility-active-coverage-benefits

***

title: "Active coverage, eligibility dates, plan details"
sidebarTitle: "Active coverage, eligibility dates, plan details"
----------------------------------------------------------------

After you send a successful eligibility or insurance discovery check, the payer sends back an X12 271 eligibility response containing the patient’s benefits information. Stedi transforms the 271 response from the original X12 EDI into JSON, making it easier to read, understand, and ingest into your system.

You can find the full benefits response shape in the [Real-Time Eligibility Check](/healthcare/api-reference/post-healthcare-eligibility) and [Insurance Discovery Check](/healthcare/api-reference/post-insurance-discovery) API references. This documentation describes how to use the eligibility response to determine the patient's active coverage, plan details, and specific benefits.

<Tip>
  New to eligibility? Check out these blogs:

  * [How to read a 271 eligibility response in plain English](https://www.stedi.com/blog/how-to-read-a-271-eligibility-response-in-plain-english)
  * [What you can (and can't) reliably get from a 271 eligibility response](https://www.stedi.com/blog/what-you-can-reliably-get-from-a-271-eligibility-response)
  * [How to deal with gaps in eligibility responses](https://www.stedi.com/blog/how-to-deal-with-gaps-in-eligibility-responses)
</Tip>

## Does the patient have coverage for the requested service?

You need two key pieces of information to determine whether the patient's health plan covers the requested service. The patient has coverage when:

1. The date of service is within the [eligibility period](#when-is-the-patient-eligible-for-benefits) for their health plan.
2. They have [active coverage](#active-and-inactive-coverage) for the applicable [service type code](#service-type-codes).

Once you know that the patient has coverage, you can determine [patient responsibility](/healthcare/eligibility-patient-responsibility-benefits), or how much the patient will pay for the service. For example, you can determine the patient's co-payment, deductible, and out-of-pocket maximum.

## When is the patient eligible for benefits?

The `planDateInformation` object contains dates related to the patient's coverage under their health plan. Most commercial payers only return information for the current calendar year.

You can use these dates to determine the patient's eligibility for benefits.

* The dates in `planDateInformation` apply to every benefit within the patient's health plan unless specifically overridden within a `benefitsInformation.benefitsDateInformation` object. Visit [Benefit-specific eligibility dates](#benefit-specific-eligibility-dates) for more details.
* The patient likely doesn't have active coverage if the date of service is after the earliest ending `plan`, `eligibility` `planEnd`, `eligibilityEnd`, `policyEffective`, or `policyExpiration` value.

The following example shows part of the benefits response for a health plan that began on January 1, 2024 and ended on December 31, 2024. The patient was eligible for benefits under that health plan starting on January 2, 2024.

{/* schema:PlanDateInformation:unwrap */}

```json
"planDateInformation":
  {
    "planBegin": "20240101",
    "planEnd": "20241231",
    "eligibilityBegin": "20240102"
  }
```

### Plan dates for dependents

Dependents can have different coverage dates than the subscriber due to qualifying life events, such as starting a new job or passing the age limit for coverage through their parent's plan.

When the patient is a dependent, and the payer sends back date(s) that are different for the subscriber and dependent, Stedi includes only the dates for the dependent and omits the subscriber's date(s).

## What are the patient's benefits?

The vast majority of the information you need to determine a patient's benefits under their health plan is contained in the `benefitsInformation` array. Each object in this array contains information about a specific benefit type, such as co-payments, deductibles, and exclusions.

The `benefitsInformation.code` property indicates the type of benefits information described in the `benefitsInformation` object. Sometimes, the code simply indicates that the patient has active coverage for the `serviceTypes` listed. For example, the following excerpt shows a member with active coverage for service type code `30` (Health Benefit Plan Coverage).

{/* schema:BenefitsInformation */}

```json
{
  "code": "1",
  "name": "Active Coverage",
  "serviceTypeCodes": ["30"],
  "serviceTypes": ["Health Benefit Plan Coverage"],
  "planCoverage": "Open Access Plus",
  "additionalInformation": [
    {
      "description": "Complete Care Management"
    }
  ]
}
```

In other array entries, the code indicates that the `benefitsInformation` object contains details about specific benefits, such as co-payments, deductibles, and exclusions.

The following example shows a patient's co-payment for psychiatric, psychotherapy, and social work in-office visits.

* The copayment is $20 for providers considered in-network, as indicated by the `Y` in the `inPlanNetworkIndicatorCode` property.
* Note that the `inPlanNetworkIndicatorCode` doesn't tell you whether the provider that requested the eligibility check is in-network for the health plan, so you shouldn't assume a $20 copay for that provider until you can verify that they are in-network. Visit [Provider network status, authorizations, referrals](/healthcare/eligibility-network-status-authorization-referrals) for more details about verifying a provider's network status.

{/* schema:BenefitsInformation */}

```json
{
  "code": "B",
  "name": "Co-Payment",
  "coverageLevelCode": "IND",
  "coverageLevel": "Individual",
  "serviceTypeCodes": ["A4", "A6", "22"],
  "serviceTypes": ["Psychiatric", "Psychotherapy", "Social Work"],
  "timeQualifierCode": "27",
  "timeQualifier": "Visit",
  "benefitAmount": "20",
  "authOrCertIndicator": "N",
  "inPlanNetworkIndicatorCode": "Y",
  "inPlanNetworkIndicator": "Yes",
  "eligibilityAdditionalInformation": {
    "codeListQualifierCode": "ZZ",
    "industryCode": "Office"
  },
  "eligibilityAdditionalInformationList": [
    {
      "codeListQualifierCode": "ZZ",
      "industryCode": "Office"
    }
  ]
}
```

### Active and inactive coverage

You can quickly determine whether a patient has active coverage for specific service types when the `benefitsInformation.code` is set to values `1` - `5`. The following example shows a member with active coverage for service type code `30` (Health Benefit Plan Coverage).

{/* schema:BenefitsInformation */}

```json
{
  "code": "1",
  "name": "Active Coverage",
  "serviceTypeCodes": ["30"],
  "serviceTypes": ["Health Benefit Plan Coverage"],
  "insuranceTypeCode": "C1",
  "insuranceType": "Commercial",
  "planCoverage": "Gold Plan HMO",
  "authOrCertIndicator": "Y",
  "inPlanNetworkIndicatorCode": "W",
  "inPlanNetworkIndicator": "Not Applicable",
  "benefitsRelatedEntity": {
    "entityIdentifier": "Payer",
    "entityType": "Non-Person Entity",
    "entityName": "UNITEDHEALTHCARE",
    "entityIdentification": "PI",
    "entityIdentificationValue": "87726"
  }
}
```

Likewise, you can quickly determine when a patient has inactive coverage for a service type when the `benefitsInformation.code` is set to values `6` - `8`. The following example shows a member with inactive coverage for service type code `30` (Health Plan Benefit Coverage).

{/* schema:BenefitsInformation */}

```json
{
  "code": "6",
  "name": "Inactive",
  "serviceTypeCodes": ["30"],
  "serviceTypes": ["Health Benefit Plan Coverage"],
  "inPlanNetworkIndicatorCode": "W",
  "inPlanNetworkIndicator": "Not Applicable"
}
```

You can also assume the patient has active coverage for a service type when benefits information for that service type is included in the response, even if there is no explicit `benefitsInformation` object with `code` = `1` - `5`. For example, if the response contains a `benefitsInformation` object with `code` = `B` (Co-Payment) for service type code `30`, you can assume the patient has active coverage for that service type.

### Benefit type codes

The benefit type code indicates the type of benefit described in the `benefitsInformation` object, such as co-payments, deductibles, and exclusions. The benefit type code is different from the service type code, which indicates the type of service covered by the benefit. Payers may send multiple `benefitsInformation` objects for the same service type code with different benefit type codes to communicate different aspects of the benefits.

The following is a complete list of codes that can be returned in the `benefitsInformation.code` property.

<Accordion title="Benefit type code list">
  * `1` - Active Coverage
  * `2` - Active - Full Risk Capitation
  * `3` - Active - Services Capitated
  * `4` - Active - Services Capitated to Primary Care Physician
  * `5` - Active - Pending Investigation
  * `6` - Inactive
  * `7` - Inactive - Pending Eligibility Update
  * `8` - Inactive - Pending Investigation
  * `A` - [Co-Insurance](/healthcare/eligibility-patient-responsibility-benefits#co-insurance)
  * `B` - [Co-Payment](/healthcare/eligibility-patient-responsibility-benefits#co-payment)
  * `C` - [Deductible](/healthcare/eligibility-patient-responsibility-benefits#deductible)
  * `CB` - Coverage Basis
  * `D` - Benefit Description
  * `E` - Exclusions
  * `F` - Limitations
  * `G` - [Out of Pocket (Stop Loss)](/healthcare/eligibility-patient-responsibility-benefits#out-of-pocket-stop-loss)
  * `H` - Unlimited
  * `I` - Non-Covered
  * `J` - [Cost Containment](/healthcare/eligibility-patient-responsibility-benefits#cost-containment)
  * `K` - Reserve
  * `L` - Primary Care Provider
  * `M` - Pre-existing Condition
  * `MC` - Managed Care Coordinator
  * `N` - Services Restricted to Following Provider
  * `O` - Not Deemed a Medical Necessity
  * `P` - Benefit Disclaimer
  * `Q` - Second Surgical Opinion Required
  * `R` - Other or Additional Payor
  * `S` - Prior Year(s) History
  * `T` - Card(s) Reported Lost/Stolen | Typically used by Medicaid to indicate to a provider that the person who has presented the ID card is using a stolen ID card.
  * `U` - Contact Following Entity for Eligibility or Benefit Information
  * `V` - Cannot Process
  * `W` - Other Source of Data
  * `X` - Health Care Facility
  * `Y` - [Spend Down](/healthcare/eligibility-patient-responsibility-benefits#spend-down)
</Accordion>

#### Code `V` - Cannot Process

These are the most common reasons a payer may return a `benefitsInformation.code` of `V`:

* **Request errors:** The payer didn't actually return any benefits information because of errors in the request - listed in the `errors` object. You should ignore the stub benefits data in the `benefitsInformation` object, correct the errors, and resubmit the eligibility check.
* **Wrong submission method:** The payer doesn't support automated X12 EDI eligibility checks for the service type code you provided and requires that you obtain benefits information through a different channel, such as by phone or online portal. The `benefitsInformation.additionalInformation.description` typically contains an explanation. The payer may also include contact information in `payer.contactInformation`.
* **Unable to interpret:** The payer located the member but couldn't make sense of the request. For example, a dental payer can't return benefits information for a vision service type code.
* **Alternate service type code:** The payer has grouped the service type code you submitted into a different one. In this case, the payer typically returns a `benefitsInformation` entry with `code` = `V` immediately followed by an entry with an active code and `benefitsInformation.serviceTypeCodes` set to the preferred service type code.

### Service type codes

The `benefitsInformation.serviceTypeCodes` property contains the service type codes (STCs) that apply to the benefit.

You should review the [STC list](/healthcare/eligibility-stc-procedure-codes#full-stc-list) to determine which STCs are relevant to the benefits you're interested in and check for all of them in the response. This is helpful because the payer may return relevant benefits under a different STC than the one you submitted. For example, mental health benefits are typically returned with STC `MH` (Mental Health), but some payers may use other STCs, such as `BH` (Behavioral Health), `A4` (Psychiatric) or `SA` (Substance Abuse) for related services.

You should also check all `benefitsInformation` objects with relevant `serviceTypeCodes` values because the same STC is typically repeated across multiple `benefitsInformation` objects in the response.

* Each object communicates a different aspect of benefits, such as coverage status, co-pays, or deductibles.
* Payers also use multiple objects to describe different subsets of services within an STC. For example, the `MH` STC might have one entry for standard therapy and another that notes coverage for other treatments. Descriptions typically appear in entries with code: `"1" (Active Coverage)` or code: `"D" (Benefit Description)`, but they can appear in other entries as well.

**Example**

The following three `benefitsInformation` objects all have the same `serviceTypeCodes` value of `CF`, which corresponds to `Mental Health Provider - Outpatient`. However, the `code` property is different for each object, indicating that they describe different aspects of the benefits:

* The first object has `code` = `1`, indicating that the patient has active coverage for outpatient mental health services.
* The second object has `code` = `C`, indicating that the patient has a $1000 deductible for outpatient mental health services.
* The third object has `code` = `D`, indicating that the patient has a benefit description that qualifies the coverage for outpatient mental health services.

{/* schema:BenefitsInformation:unwrapArray */}

```json
"benefitsInformation": [
  {
    "code": "1",
    "name": "Active Coverage",
    "serviceTypeCodes": ["CF"],
    "serviceTypes": [
      "Mental Health Provider - Outpatient"
    ],
    "timeQualifierCode": "23",
    "timeQualifier": "Calendar Year",
    "inPlanNetworkIndicatorCode": "Y",
    "inPlanNetworkIndicator": "Yes",
    "additionalInformation": [
      {
        "description": "INCLUSIONS SPEECH/PHYSICAL/OCCUPATIONAL THERAPY; APPLIED BEHAVIOR ANALYSIS (ABA)"
      }
    ]
  },
  {
    "code": "C",
    "name": "Deductible",
    "serviceTypeCodes": ["CF"],
    "serviceTypes": [
      "Mental Health Provider - Outpatient"
    ],
    "benefitAmount": "1000",
    "timeQualifierCode": "23",
    "timeQualifier": "Calendar Year",
    "inPlanNetworkIndicatorCode": "Y",
    "inPlanNetworkIndicator": "Yes"
  },
  {
    "code": "D",
    "name": "Benefit Description",
    "serviceTypeCodes": ["CF"],
    "serviceTypes": [
      "Mental Health Provider - Outpatient"
    ],
    "additionalInformation": [
      {
        "description": "EXCLUSIONS: DEVELOPMENTAL TESTING, EDUCATIONAL THERAPY"
      }
    ]
  }
]
```

### Benefit-specific eligibility dates

When present, the `benefitsInformation.benefitsDateInformation` object contains dates that determine the patient's eligibility for a specific type of benefits. You should use these dates to determine the patient's eligibility for that specific benefit type instead of the dates in the `planDateInformation` object.

Payers send benefit-specific dates when certain benefits within a plan have different activation rules or waiting periods than the overall plan coverage. This can happen in a variety of scenarios, including:

* Employers may offer plans with benefits that activate based on employment duration or role. For example, Medical coverage may start on your hire date, but life insurance or disability coverage begins after 90 days.
* Some plans require a delay before certain benefits start, even though your general plan is active. For example, dental insurance may have a 6-month waiting period for major services (like crowns), but basic services (like cleanings) are covered immediately.
* Some government programs like Medicare split coverage (Part A, B, D, etc.), each with its own effective date.
* You may switch plans during open enrollment, and new benefits might have different effective dates.

### Carveout benefits

A carveout is when the primary payer for a plan lets another entity handle certain benefits. Carveout administrators often specialize in benefits for a particular service, such as mental health services or pharmacy benefits. For example, many Blue Cross Blue Shield (BCBS) plans carve out mental (behavioral) health benefits to Magellan, a mental health payer.

Carveouts are part of a single health plan, so they're different from secondary or tertiary insurance coverage. A patient can have carveout benefits for their primary plan and still have secondary insurance coverage through other payers.

Most payers omit carveout benefits from eligibility responses, but many include the carveout administrator's information.

#### Carveout administrator information

Don't rely on `benefitsRelatedEntities.entityIdentifier` to identify carveout administrators because the value can vary between payers.

Instead, look for a `benefitsInformation` object that has:

* `code` = `U` (Contact Following Entity for Eligibility or Benefit Information) or `code` = `1` (Active coverage).
* `serviceTypeCodes` with [related STCs](#service-type-codes).
* a `benefitsRelatedEntities` object containing contact information. If present, `benefitsRelatedEntities.entityIdentificationValue` contains the patient's member ID for the carveout administrator.

You should also examine `benefitsInformation` objects with `code` = `D` (Benefit Description). The `additionalInformation.description` property may contain relevant details.

The following example shows a benefits response for a patient whose mental health benefits (`serviceTypeCodes` = `MH`) are handled by a third-party administrator called Acme Health Payer. The `description` property in the second object indicates that these benefits are managed separately.

{/* schema:BenefitsInformation:unwrapArray */}

```json
"benefitsInformation": [
  {
    "code": "U",
    "serviceTypeCodes": [
      "MH"
    ],
    "benefitsRelatedEntities": [
      {
        "entityIdentifier": "Third-Party Administrator",
        "entityType": "Non-Person Entity",
        "entityName": "Acme Health Payer",
        "entityIdentificationValue": "123456789",
        "contactInformation": {
          "contacts": [
            {
              "communicationMode": "Telephone",
              "communicationNumber": "1234567890"
            }
          ]
        }
      }
    ]
  },
  {
    "code": "D",
    "serviceTypeCodes": ["MH"],
    "additionalInformation": [
      {
        "description": "BEHAVIORAL HEALTH MANAGED SEPARATELY"
      }
    ]
  }
]
```

#### Get carveout benefits details

When payers return carveout administrator information, you can:

1. Get the carveout administrator's payer ID from the [Payer Network](https://www.stedi.com/healthcare/network) or [Search Payers](/healthcare/api-reference/get-search-payers) endpoint.
2. Get the patient's member ID for the carveout administrator. It's in the `benefitsRelatedEntities.entityIdentificationValue` property, if present.
3. Send a second eligibility check to the carveout administrator.

If you use the right STC, many carveout admins will return the missing carveout benefits. The STC may differ from the one you sent to the primary payer. Visit [STCs and procedure codes](/healthcare/eligibility-stc-procedure-codes) for tips on choosing the right STC.

If the primary payer doesn't return the carveout administrator's details, you can try checking the patient's member ID card. The back of the card often lists the carveout administrator's name and contact information. You can also try calling the primary payer and checking their website or portal.

### Pharmacy benefits

Some payers include benefits for STC `88` (Pharmacy) in eligibility responses, but these benefit entries usually only indicate that pharmacy coverage exists with `code` = `1` (Active coverage). They often don't include specific benefit details.

The following example shows a `benefitsInformation` object indicating that the patient has active pharmacy benefits.

{/* schema:BenefitsInformation */}

```json
{
  "planCoverage": "Advantage Pharmacy",
  "serviceTypes": ["Pharmacy"],
  "serviceTypeCodes": ["88"],
  "code": "1",
  "name": "Active Coverage"
}
```

However, some payers do return specific pharmacy benefit details, such as co-payments and out-of-pocket maximums. The following example shows a patient's [out of pocket (stop loss)](/healthcare/eligibility-patient-responsibility-benefits#out-of-pocket-stop-loss) benefit per calendar year for pharmacy services. This is the maximum amount the patient will pay for covered pharmacy services in a year. The payer includes a note that the patient's co-payments count toward this out-of-pocket maximum.

{/* schema:BenefitsInformation */}

```json
{
  "code": "G",
  "name": "Out of Pocket (Stop Loss)",
  "coverageLevelCode": "FAM",
  "coverageLevel": "Family",
  "serviceTypeCodes": ["88"],
  "serviceTypes": ["Pharmacy"],
  "benefitAmount": "6000",
  "inPlanNetworkIndicatorCode": "Y",
  "inPlanNetworkIndicator": "Yes",
  "timeQualifierCode": "23",
  "timeQualifier": "Calendar Year",
  "additionalInformation": [
    {
      "description": "Copay does apply to member's out-of-pocket maximum"
    }
  ]
}
```

#### Pharmacy Benefits Manager

Pharmacy benefits are often handled by a Pharmacy Benefits Manager (PBM), a company separate from the payer.

Information for the plan's PBM is often (but not always) returned in a `benefitsRelatedEntities` object. Don't rely solely on the `benefitsRelatedEntities.entityIdentifier` field to identify PBMs because the value can vary between payers. Review the `entityName` and `contactInformation` to confirm that the entity is a PBM.

The following example shows a benefits response indicating that the patient's pharmacy benefits are managed by a third-party administrator called Acme Pharmacy Services.

{/* schema:BenefitsInformation */}

```json
{
  "code": "U",
  "name": "Contact Following Entity for Eligibility or Benefit Information",
  "serviceTypeCodes": ["88"],
  "serviceTypes": ["Pharmacy"],
  "benefitsRelatedEntities": [
    {
      "entityIdentifier": "Third-Party Administrator",
      "entityType": "Non-Person Entity",
      "entityName": "Acme Pharmacy Services",
      "contactInformation": {
        "contacts": [
          {
            "communicationMode": "Telephone",
            "communicationNumber": "1234567890"
          }
        ]
      }
    }
  ]
}
```

#### RxBINs and RxPCNs

Pharmacy Bank Identification Numbers (RxBINs) and Processor Control Numbers (RxPCNs) tell pharmacies where to send claims. RxBINs and RxPCNs are often on the member's insurance card.

Payers don't typically include these codes in eligibility responses.

### Crossover coverage

Crossover coverage is the process where a primary insurance payer (usually Medicare) automatically forwards claims and related information to a secondary payer (typically Medicaid or a supplemental private insurer) after processing. When there's crossover coverage, you won't need to manually resubmit claims to the secondary payer - it happens automatically.

When the patient has crossover coverage, the eligibility response may contain information about crossover carriers, such as their names and identifiers, in the `benefitsInformation.benefitsRelatedEntities` array. However, you **shouldn't** automatically assume the responding payer will automatically forward crossover claims to those payers.

To determine whether a claim has been sent to a crossover carrier, you must review the 835 ERA. Visit [crossover claims](/healthcare/receive-claim-responses#crossover-claims) for more details.

## What are the patient's plan details?

The following details about the patient's health plan are sometimes included in the eligibility response. Not all payers return this information, and behavior can vary by payer.

### Plan name

The only standard property that contains a health plan product or program name is `benefitsInformation.planCoverage`.

Payers are only required to provide a plan name when returning Service Type Code (STC) `30`, but the plan name itself isn't tied to any specific STC. The `benefitsInformation` array can contain many entries for multiple plans, such as medical, dental, and vision.

For example, a payer might send back multiple `benefitsInformation` objects with STC `30`. Each one can have a different `planCoverage` value. You might see `"PPO DENTAL"` in one and `"PREFERRED PROVIDER OPTION MEDICAL"` in another. This just means the member has multiple plans – a dental plan and a medical plan. Each plan gets its own set of objects.

In the following example, the plan name is `Open Access Plus`:

{/* schema:BenefitsInformation */}

```json
{
  "code": "1",
  "name": "Active Coverage",
  "serviceTypeCodes": ["30"],
  "serviceTypes": ["Health Benefit Plan Coverage"],
  "planCoverage": "Open Access Plus",
  "additionalInformation": [
    {
      "description": "Complete Care Management"
    }
  ]
}
```

You may also be able to identify the plan name through the following properties, but they're not as reliable as `planCoverage.` Payers aren't required to return information for these properties, so behavior can vary by payer or even by plan.

* Some properties may contain a name for the group (often named for the employer if they sponsor the plan), insurance policy, or network. These properties are: `groupDescription`, `planDescription`, and `planNetworkIdDescription`. These properties may be included in the `subscriber`, `dependents`, or `benefitsInformation.benefitsAdditionalInformation` objects, depending on where the payer places this information in the benefit response.
* Some payers may send something like a plan name in `planInformation.planDescription` or as unstructured text in `benefitsInformation.additionalInformation.description`.

#### BCBS home plan

Many Blue Cross Blue Shield (BCBS) payers are part of the BlueCard Program, which makes it easier to run eligibility checks for patients receiving care outside their home state. With BlueCard, you can send eligibility checks to any participating BCBS payer, and BlueCard routes them to the patient's home plan for benefits verification.

For example, if you send a request to BCBS Florida for a patient covered by BCBS Alabama, the response will include benefits information from the patient's home plan BCBS Alabama.

Stedi enriches the eligibility response with information about the patient's home plan when the eligibility check includes the member's first name, last name, birthdate, and full member ID (including the 3-character BCBS alpha prefix).

In JSON responses, Stedi returns information about the patient's home plan in a `benefitsInformation[].benefitsRelatedEntities` entry. The relevant object's `entityIdentifier` property is set to `Party Performing Verification`.

{/* schema:BenefitsInformation */}

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

In X12 EDI responses, Stedi returns this information in `Loop 2120C` (Subscriber Benefit Related Entity) or `Loop 2120D` (Dependent Benefit Related Entity), depending on whether the patient is the subscriber or a dependent. The `NM1-01` composite is set to `VER` (Party Performing Verification).

```
LS*2120~
NM1*VER*2*Blue Cross Blue Shield of Alabama*****PI*00510BC~
LE*2120~
```

BCBS enrichment isn't supported when:

* The patient's member ID doesn't contain the 3-character alpha prefix.
* The patient has stand-alone vision and pharmacy cards issued through an intermediary model.
* The patient's plan is a stand-alone dental product.
* The patient is part of a Federal Employee Program (FEP). In this case, the patient has `R` before their member ID.

### Plan number

A plan number is the payer's unique ID for a plan. Not all payers return the patient's plan number. When returned, it can appear in multiple places, including outside the `benefitsInformation` object. Check the following properties in order:

* [`subscriber.planNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.subscriber.planNumber)
* [`benefitsInformation.benefitsAdditionalInformation.planNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.benefitsInformation.benefitsAdditionalInformation.planNumber)
* [`planInformation.planNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.planInformation.planNumber)

### Group number

A group number is the payer's code for the employer or other party that purchased the plan. Employees on a group plan typically share the same group number, though there are exceptions. Some employers use different group numbers for different employee categories, like union members and management.

Not all payers return the patient's group number. When returned, it can appear in multiple places, including outside the `benefitsInformation` object. Check the following properties in order:

* [`subscriber.groupNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.subscriber.groupNumber)
* [`benefitsInformation.benefitsAdditionalInformation.groupNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.benefitsInformation.benefitsAdditionalInformation.groupNumber)
* [`planInformation.groupNumber`](/healthcare/api-reference/post-healthcare-eligibility#response.planInformation.groupNumber)

### Medicare Advantage plans

A Medicare Advantage plan (also known as Medicare Part C) is a type of health plan offered by private insurance companies approved by Medicare. It provides all the benefits of standard Medicare (Parts A and B) and often includes additional services such as prescription drug coverage, vision, dental, and hearing care. Medicare Advantage plans also include an annual out-of-pocket spending limit, offering financial protection beyond what standard Medicare provides.

Here's how to identify Medicare Advantage plans in eligibility responses from commercial payers and CMS.

#### Commercial payers

A response from a commercial payer likely contains a Medicare Advantage plan when it has any of the following properties:

* `benefitsInformation.insuranceTypeCode` = `MA` or `MB` which correspond to `benefitsInformation.insuranceType` = `Medicare Part A` and `Medicare Part B`, respectively.
* `planInformation.hicNumber` and/or `benefitsInformation.benefitsAdditionalInformation.hicNumber`. These properties contain the Medicare Beneficiary Identifier (MBI), so if either of these are present, then it's almost certainly a Medicare Advantage plan.

Behavior varies by payer, so these properties may not always be included, even if the patient has a Medicare Advantage plan.

#### CMS

A response from CMS likely contains a Medicare Advantage plan when it has the following properties:

* `benefitsInformation.code` = `U` (which corresponds to `benefitsInformation.name` = `Contact Following Entity for Eligibility or Benefit Information`) combined with `serviceTypeCodes` = `30`.
* `benefitsInformation.additionalInformation.description` - CMS provides what they call the MA Bill Option Code in this property.

The MA Bill Option code may be one of two sets of values, depending on whether the Medicare beneficiary is locked in. When a Medicare beneficiary is locked in, they can only make changes to their coverage during specific times of the year, unless they qualify for a Special Enrollment Period (SEP).

In the following code sets, the Fiscal Intermediary is what CMS refers to as a MAC.

**Medicare Beneficiary locked in to Medicare Advantage (MA)**

* `A`: Fiscal Intermediary should process all claims
* `B`: MA should process only in-plan Part A claims and in-area Part B claims
* `C`: MA should process all claims

**Medicare Beneficiary NOT locked in to Medicare Advantage (MA)**

* `1`: Fiscal Intermediary should process all claims
* `2`: MA should process only in-plan Part A claims and in-area Part B claims