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.
Response shapes
Stedi returns one of two response shapes, depending on the endpoint you called. Both contain the same benefits information, organized differently. You can identify them by the top-level array that organizes the patient's benefits information - either plans or benefitsInformation.
| Top-level array | Endpoints |
|---|---|
plans | Real-Time Eligibility Check JSON |
benefitsInformation | Batch Eligibility Check, Insurance Discovery, Real-Time Eligibility Check Raw X12, Real-Time Eligibility Check JSON - Legacy |
Every section on this page covers both response shapes, labeled plans and benefitsInformation. Select the label that matches the endpoint you called, and the page applies your selection to every section.
Plan name
Payers are only required to provide a plan name when returning Service Type Code (STC) 30, though the name itself isn't tied to any particular STC. The name they send may not match the name the payer uses in official plan documents or marketing material.
A patient can also have more than one plan, such as separate medical, dental, and vision plans. Each plan has its own name, and the response reports each one separately.
A payer sends a plan name with each benefit entry, and Stedi derives plans[].name from those names. The value is present when the names agree, and absent when the payer's data is missing, ambiguous, or contradictory.
When plans[].name is absent, check each benefit's planCoverageDescription. Stedi omits that property when it repeats the plan name, so it appears only when the payer's description for that benefit differs.
"plans": [
{
"name": "Open Access Plus",
"benefits": {
"statuses": [
{
"status": "ACTIVE_COVERAGE",
"coverageLevel": "INDIVIDUAL",
"service": {
"system": "STC",
"value": "30",
"definition": "Health Benefit Plan Coverage"
},
"messages": ["Complete Care Management"]
}
]
}
}
]You may also be able to identify a name through subscriber.additionalInformation, where plan.name, group.name, and planNetwork.name contain the plan, group, and network names when the payer sends them. These are less reliable than plans[].name.
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 includes 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).
Stedi returns the home plan in a benefit's relatedEntities array. The object's type property is set to PARTY_PERFORMING_VERIFICATION.
"plans": [
{
"benefits": {
"statuses": [
{
"status": "ACTIVE_COVERAGE",
"coverageLevel": "INDIVIDUAL",
"service": {
"system": "STC",
"value": "30",
"definition": "Health Benefit Plan Coverage"
},
"relatedEntities": [
{
"type": "PARTY_PERFORMING_VERIFICATION",
"name": { "organization": "Blue Cross Blue Shield of Alabama" },
"payerId": "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
Rbefore 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.
Check subscriber.additionalInformation.plan, or dependent.additionalInformation.plan when the patient is a dependent. The object's number property contains the plan number, and name contains the plan description, if available.
Individual benefit entries can also carry their own plan details in their additionalInformation.plan object. Stedi keeps these separate from the subscriber and dependent objects, because entries within a plan can report different plan numbers and descriptions.
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.
Check subscriber.additionalInformation.group, or dependent.additionalInformation.group when the patient is a dependent. The object's number property contains the group number, and name contains the group description, if available.
Individual benefit entries can also carry their own group details in their additionalInformation.group object. Stedi keeps these separate from the subscriber and dependent objects, because entries within a plan can report different group numbers and descriptions.
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 the Centers for Medicare and Medicaid Services (CMS).
Commercial payers
A response from a commercial payer likely contains a Medicare Advantage plan when it reports a Medicare Part A or Part B insurance type, or when it includes a Medicare Beneficiary Identifier (MBI). The MBI is the stronger signal: when the payer sends one, the plan is almost certainly Medicare Advantage.
Look for either of the following:
- A benefit entry with an
insuranceTypeofMEDICARE_PART_AorMEDICARE_PART_B. - An
mbiproperty insubscriber.additionalInformationordependent.additionalInformation, which contains the MBI.
The following example shows a coverage status entry with a Medicare Part A insurance type.
"plans": [
{
"benefits": {
"statuses": [
{
"status": "ACTIVE_COVERAGE",
"coverageLevel": "INDIVIDUAL",
"insuranceType": "MEDICARE_PART_A",
"service": {
"system": "STC",
"value": "30",
"definition": "Health Benefit Plan Coverage"
}
}
]
}
}
]The following example shows the patient's MBI.
"subscriber": {
"additionalInformation": {
"mbi": "1A22BB3CC44"
}
}Behavior varies by payer, so payers don't always include these properties, even when the patient has a Medicare Advantage plan.
CMS
A response from CMS likely contains a Medicare Advantage plan when it includes what CMS calls the MA Bill Option Code. CMS sends this code in a freeform message on a benefit entry for service type code 30.
The MA Bill Option Code is 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 Medicare Administrative Contractor (MAC).
Medicare Beneficiary locked in to Medicare Advantage (MA)
A: Fiscal Intermediary should process all claimsB: MA should process only in-plan Part A claims and in-area Part B claimsC: MA should process all claims
Medicare Beneficiary NOT locked in to Medicare Advantage (MA)
1: Fiscal Intermediary should process all claims2: MA should process only in-plan Part A claims and in-area Part B claims
When CMS identifies a Medicare Advantage plan, the same benefit entry contains the plan's name, address, and contact details. Use them to reach the plan directly about claims or prior authorization.
To find the MA Bill Option Code, look for:
- A
plans[].benefits.contactFollowingEntityForInformationentry whoseserviceobject contains service type code30. - A
messagesvalue on that entry, which contains the MA Bill Option Code.
The relatedEntities array contains the Medicare Advantage plan as a PRIMARY_PAYER entity.
{
"coverageLevel": "INDIVIDUAL",
"service": {
"system": "STC",
"value": "30",
"definition": "Health Benefit Plan Coverage"
},
"messages": ["MA Bill Option Code - A"],
"relatedEntities": [
{
"type": "PRIMARY_PAYER",
"name": { "organization": "UHC OF CALIFORNIA" },
"address": {
"addressLine1": "202 Main St",
"city": "Sacramento",
"state": "CA",
"postalCode": "94203"
},
"contacts": [
{
"phoneNumbers": ["8006446644"],
"urls": ["UHC.com/Medicare"]
}
]
}
]
}