Active coverage

After you send a successful eligibility or insurance discovery check, the payer sends back an X12 271 Eligibility Benefit 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 benefits response to determine the patient’s active coverage, plan details, and specific benefits.

​

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": "Mutually Defined",
    "industryCode": "Office"
  },
  "eligibilityAdditionalInformationList": [
    {
      "codeListQualifierCode": "Mutually Defined",
      "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. However, payers are only required to provide this information for service type code (STC) 30. They may provide it for other STCs, but they don’t have to.

The benefitsInformation array can contain many entries for multiple plans, such as medical, dental, and vision. You may want to filter benefitsInformation objects for certain STCs before checking for the plan name.

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.