Interpret benefit response

After you send a successful eligibility check, the payer sends back an X12 271 Eligibility Benefit Response containing the patient’s benefits information, including coverage status, co-pays, and deductibles.

Stedi transforms the 271 response from the original X12 EDI into JSON, making it easier to read, understand, and ingest into your system.

​

Active and inactive coverage

You can quickly determine whether a patient has active coverage from the benefitsInformation object within the response. The following sample excerpt from a payer response shows a member with active coverage. The benefitsInformation.name property is set to Active Coverage and benefitsInformation.code is set to 1:

  "benefitsInformation": [
    {
      "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"
      }
    }
  ]

The following example excerpt from a payer response shows a member with inactive coverage. The benefitsInformation.name property is set to Inactive and benefitsInformation.code is set to 6:

"benefitsInformation": [
  {
    "code": "6",
    "name": "Inactive",
    "serviceTypeCodes": [
      "30"
    ],
    "serviceTypes": [
      "Health Benefit Plan Coverage"
    ],
    "inPlanNetworkIndicatorCode": "W",
    "inPlanNetworkIndicator": "Not Applicable"
  },
  {
    "code": "X",
    "name": "Health Care Facility",
    "inPlanNetworkIndicatorCode": "W",
    "inPlanNetworkIndicator": "Not Applicable",
    "benefitsRelatedEntity": {
      "entityIdentifier": "Provider",
      "entityType": "Non-Person Entity",
      "entityName": "MEDICAL PROVIDER",
      "entityIdentification": "XX",
      "entityIdentificationValue": "0001112223"
    }
  }
]

​

Coverage period

The planDateInformation object contains dates related to the patient’s coverage under their health plan. These dates apply to every every benefit within the patient’s health plan unless specifically noted within a benefitsInformation.benefitsDateInformation object. Most commercial payers only return information for the current calendar year.

If the payer sends back date(s) that are different for the subscriber and dependents, Stedi includes only the dates for the dependent in this object and omits the subscriber’s date(s). 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.

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

​

Benefits information

Each object in the benefitsInformation array contains details about the patient’s coverage under their health plan. The benefitsInformation.code property indicates the type of benefit, and the name property provides a description.

The following example shows a patient’s co-payment for psychiatric, psychotherapy, and social work in-office visits. This copayment is 20 dollars for providers considered in-network, as indicated by the Y in the inPlanNetworkIndicatorCode property:

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

​

Eligibility and 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.

​

Identify 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:

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

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.

​

In- and out-of-network coverage (network status)

The standard eligibility check benefits response isn’t a reliable way to determine whether a provider is in- or out-of-network for the patient. This is because payers typically don’t explicitly include information indicating whether the requesting provider is in- or out-of-network (though there are some exceptions).

The only reliable way to determine network status is to check directly with the payer or the provider. Note that payers may have different networks for different health plans, such as employer-sponsored plans versus Medicare Advantage, and these networks may have different contact paths.

​

Plan Network Indicator

The X12 EDI 271 eligibility response includes a data element called EB12 (In Plan Network Indicator). Stedi represents this field as the benefitsInformation.inPlanNetworkIndicatorCode property in the eligibility benefits response.

This value specifies whether the specific benefit type applies to in- vs. out-of-network. It doesn’t indicate whether the provider is in- or -out-of-network for the patient’s health plan. Most payers include information about both the patient’s in- and out-of-network coverage and benefits in the response, regardless of the requesting provider’s network status.

Payers can send the following inPlanNetworkIndicatorCode values:

• Y - Yes
• N - No
• W - Not Applicable | This indicates that the benefit applies to both in and out-of-network providers.
• U - Unknown | This indicates that it is unknown whether the benefits apply to in- or out-of-network providers.

The example benefitsInformation object below shows the patient’s out-of-network deductible for the calendar year, which is $7,500 dollars. The inPlanNetworkIndicatorCode is N, indicating that the deductible is applicable to services performed by providers outside the patient’s network.

{
  "code": "C",
  "name": "Deductible",
  "coverageLevelCode": "IND",
  "coverageLevel": "Individual",
  "serviceTypeCodes": ["30"],
  "serviceTypes": ["Health Benefit Plan Coverage"],
  "timeQualifierCode": "23",
  "timeQualifier": "Calendar Year",
  "benefitAmount": "7500",
  "inPlanNetworkIndicatorCode": "N",
  "inPlanNetworkIndicator": "No"
}

​

Payer FHIR APIs

Some payers have implemented the HL7 Da Vinci PDEX Plan Net (FHIR) API, which allows you to query directly for provider network status. Here are links to these APIs for a few large, commercial payers:

• Aetna
• Cigna
• Humana
• UnitedHealthcare

This is not an exhaustive list, and we provide these links for convenience and reference only. Stedi can’t give any additional support on how to use third-party APIs.

​

Additional network status details

Some payers do provide additional information about whether the requesting provider is in- or out-of-network. They may do this through either selective inclusion of benefits in the response or through freeform messages.

​

Selective inclusion of benefits

A small subset of payers selectively include portions of the eligibility response according to the provider’s network status. For example, some payers only return out-of-network benefits if the requesting provider is out-of-network. Likewise, if the provider is in-network, they only provide in-network benefits.

One example is Blue Cross and Blue Shield of New Mexico (BCBSNM). Their 270/271 Transaction Standard Companion Guide states in section 5.3:

“When local transactions are submitted, BCBSNM uses the provider type and/or provider specialty along with the providers contracting network status to determine the applicable benefits.”

Stedi doesn’t have a complete list of payers that selectively include or exclude benefits based on the provider’s network status. The only reliable way to determine network status is to reach out to the provider or payer directly.

​

Freeform messages

While uncommon, some payers communicate information about the requesting provider’s network status using freeform messages. For example, Cigna’s 270/271 Companion Guide states:

“When the requestor’s network participation status can be determined, Cigna will send a Message on the EB1*30 Row that indicates either the Health Care Professional (or facility) is in or out of the customer’s medical network.”

In Stedi’s eligibility response, these types of freeform messages are typically included in the benefitsInformation.additionalInformation.description property. For example:

• PROVIDER IS OUT NETWORK FOR MEMBER
• BENEFITS RETURNED BASED ON NON-AFFILIATED PROVIDER STATUS

This description property may also contain information about network tier levels, since some plans have more complex benefit structures with reduced patient responsibility for higher-tier providers.

These freeform messages are not standardized across payers and may even differ across plans for the same payer. Again, the most reliable way to determine network status is to reach out to the provider or payer directly.

​

Prior authorization

Payers use the benefitsInformation.authOrCertIndicator property to indicate whether prior authorization is required for the service type code in the eligibility check. It can have the following values:

• Y indicates that prior authorization is required.
• N indicates that prior authorization is not required.
• U indicates that the payer is unable to confirm whether or not prior authorization is required.

If you don’t receive the benefitsInformation.authOrCertIndicator property in the response, you can assume that prior authorization is not required. Some payers may send additional notes about prior authorization rules in the benefitsInformation.additionalInformation.description property.

​

Referral required

Payers aren’t required to provide information about whether referrals are required for benefits, and we can’t provide a definitive list of payers who do. When this information is included, you can find it in the benefitsInformation.additionalInformation.description property. You’re more likely to receive referral information for members with HMO plans.

​

Patient responsibility

Some benefits require the patient to pay a portion of the cost of care, also known as patient responsibility.

​

Service type codes

Not all service type codes (STCs) require payers to return patient responsibility information. For example, health plans are required to support inquiries for the following STCs, but aren’t required to return patient responsibility information for them.

• 1 - Medical Care
• 30 - Health Plan Benefit Coverage
• 35 - Dental Care
• 88 - Pharmacy
• AL - Vision (Optometry)
• MH - Mental Health

However, health plans regulated under HIPAA must return any applicable patient co-insurance, co-payment, or deductible amounts for the following service type codes.

• 33 - Chiropractic
• 47 - Hospital
• 48 - Hospital Inpatient
• 50 - Hospital Outpatient
• 86 - Emergency Services
• 98 - Professional (Physician) Visit – Office
• UC - Urgent Care

These lists don’t necessarily extend to dental or vision plans. Some payers may support returning patient responsibility information for additional STCs.

​

Benefit types

The following types of benefits indicate patient financial responsibility. Note that payers may respond with zero in the benefitAmount or benefitPercent properties when the patient has no responsibility.

If a particular benefit category is not applicable to a plan, the payer will often send nothing for that category rather than explicitly sending a zero benefit. For example, if a health plan has 20% co-insurance for STC 98 but no co-payment, then typically none of the benefitsInformation array entries for that STC will have benefitsInformation.code = B (Co-Payment).

​

Co-Insurance

Co-Insurance is indicated by benefitsInformation.code = A and always includes a value for the benefitsInformation.benefitPercent property.

Co-insurance represents the percentage of a benefit patients are responsible for covering themselves. For example, if a patient has met their annual deductible and their co-insurance is 20 percent, they would pay 20 dollars for a treatment that costs 100 dollars. The amount of co-insurance can differ depending on whether a provider is in-network with the health plan.

​

Co-Payment

Co-Payment is indicated by benefitsInformation.code = B and always includes a value for the benefitsInformation.benefitAmount property.

Co-Payment represents a fixed dollar amount a patient must pay for a benefit. For example, a patient may have a 10 dollar co-payment for a physician office visit. The amount of co-payment can differ depending on whether the provider is considered in-network with the health plan.

​

Cost Containment

Cost Containment is indicated by benefitsInformation.code = J and always includes a value for the benefitsInformation.benefitAmount property.

Cost Containment refers to rules that a health plan may have in place to control the cost of care. It’s typically included in the benefit response when the patient has Medicaid coverage and represents the total amount the patient will have to pay out of their own pocket before their benefits begin.

​

Deductible

Deductible is indicated by benefitsInformation.code = C and always includes a value for the benefitsInformation.benefitAmount property.

A deductible represents the total amount the patient will have to pay out of their own pocket before their benefits begin. For example, if a patient’s deductible is 1000 dollars, they will have to pay 1000 dollars for covered services before the health plan will start to pay. Then, the patient will typically pay part of the cost of services (such as co-payments) until they reach their out-of-pocket maximum.

Though behavior can vary by payer, the deductible benefitsInformation object is often included twice in the response for a given coverage level + service type + network status. One iteration contains a timeQualifier like Calendar Year, which indicates that the benefitAmount value is the patient’s total annual deductible. In the second instance, the timeQualifier is often Remaining, which indicates that the benefitAmount value is the patient’s remaining deductible amount (annual deductible minus what they’ve already spent for the calendar year).

The following example shows that this patient’s annual deductible is 1000 dollars, and they have 500 dollars remaining to meet that deductible:

{
  "code": "C",
  "name": "Deductible",
  "coverageLevelCode": "IND",
  "coverageLevel": "Individual",
  "serviceTypeCodes": [
    "30"
  ],
  "serviceTypes": [
    "Health Benefit Plan Coverage"
  ],
  "planCoverage": "GOLDLITE",
  "timeQualifierCode": "29",
  "timeQualifier": "Remaining",
  "benefitAmount": "500",
  "inPlanNetworkIndicatorCode": "Y",
  "inPlanNetworkIndicator": "Yes",
  "benefitsDateInformation": {
    "benefit": "20240101-20241231"
  }
},
{
  "code": "C",
  "name": "Deductible",
  "coverageLevelCode": "IND",
  "coverageLevel": "Individual",
  "serviceTypeCodes": [
    "30"
  ],
  "serviceTypes": [
    "Health Benefit Plan Coverage"
  ],
  "planCoverage": "GOLDLITE",
  "timeQualifierCode": "23",
  "timeQualifier": "Calendar Year",
  "benefitAmount": "1000",
  "inPlanNetworkIndicatorCode": "Y",
  "inPlanNetworkIndicator": "Yes",
  "benefitsDateInformation": {
    "benefit": "20240101-20241231"
  }
}

​

Limitations

Limitations are indicated by benefitsInformation.code = F. Dental and vision plans often use this benefit type to specify an annual maximum benefit amount.

The Affordable Care Act prevents most commercial health plans from imposing limits on annual or lifetime benefit amounts. However, this generally doesn’t apply to government health plans and and some commercial health plans may be exempt. So we recommend checking for limitations for all plan types: medical, dental, and vision.

When present, limitations might include a value for the benefitsInformation.benefitAmount property that indicates the maximum benefit amount allocated to the patient. The description property is also often (but not always) set to a value like “ANNUAL MAXIMUM”.

The following example shows a sample response from a dental payer. The patient has an annual maximum benefit for dental care of 2500 dollars.

{
  "timeQualifier": "Calendar Year",
  "inPlanNetworkIndicator": "Yes",
  "TimeQualifierCode": "23",
  "benefitAmount": "2500",
  "code": "F",
  "coverageLevel": "Individual",
  "inPlanNetworkIndicatorCode": "Y",
  "serviceTypeCodes": [
    "35"
  ],
  "additionalInformation": [
    {
    "description": "ANNUAL MAXIMUM"
    }
  ],
  "serviceTypes": [
    "Dental Care"
  ],
  "name": "Limitations",
  "coverageLevelCode": "IND"
}

​

Out of Pocket (Stop Loss)

Out of Pocket (Stop Loss) is indicated by benefitsInformation.code = G and always includes a value for the benefitsInformation.benefitAmount property.

Out of Pocket (Stop Loss) represents the maximum amount a patient can pay per year. Once the patient reaches this limit, the health plan will pay 100 percent of the allowed amount for covered services unless some other coverage limitation (code F Limitations) applies. For example, if a health plan has a limit of 12 covered mental health visits per year, the patient may still be responsible for covering 100 percent of visits beyond that limit even if they have met their out-of-pocket maximum.

Most health plans are required to set an out-of-pocket maximum, but health plans with provider networks are allowed to have unlimited patient responsibility for out-of-network care. If there is no benefitsInformation object in the response that has benefitsInformation.code = G, the payer is indicating that the out-of-pocket maximum is unlimited.

​

Spend Down

Spend Down is indicated by benefitsInformation.code = Y and always includes a value for the benefitsInformation.benefitAmount property.

Spend Down is a process that allows individuals with high medical expenses to qualify for Medicaid even if their income is above the Medicaid income limit. The Spend Down benefitAmount represents the total amount the patient will have to pay out of their own pocket before they can receive Medicaid benefits.