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

​
Benefit type codes

The following is a complete list of codes that can be returned in the benefitsInformation.code property.
  • 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
  • B - Co-Payment
  • C - Deductible
  • CB - Coverage Basis
  • D - Benefit Description
  • E - Exclusions
  • F - Limitations
  • G - Out of Pocket (Stop Loss)
  • H - Unlimited
  • I - Non-Covered
  • J - 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

​
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.

​
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-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.

​
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. If you think a patient has a Medicare Advantage plan, you should send an additional eligibility check to the Centers for Medicare and Medicaid Services (CMS) to confirm. If you don’t have the patient’s MBI (required for CMS eligibility checks), you can use MBI lookup to send eligibility checks to CMS with the patient’s Social Security Number instead.

​
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