Stedi home page

Active coverage

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 and Insurance Discovery Check API references. This documentation describes how to use the eligibility response to determine the patient's active coverage, plan details, and specific benefits.

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 for their health plan.
  2. They have active coverage for the applicable service type code.

Once you know that the patient has coverage, you can determine patient responsibility, 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 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.

"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).

{
  "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 for more details about verifying a provider's network status.
{
  "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 1 (Active Coverage). The following example shows a member with active coverage for service type code 30 (Health Benefit Plan Coverage).

{
  "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 6 (Inactive). The following example shows a member with inactive coverage for service type code 30 (Health Plan Benefit Coverage).

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

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.

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 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.
"items": [
  {
    "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.

What's the 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:

{
  "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.

"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"
      }
    ]
  },
    ...
]

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.

Does the patient have 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 for more details.

Does the patient have a Medicare Advantage plan?

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.

Commercial payer responses

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 responses

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
Insurance discovery checks
Provider network status, authorizations, referrals