How to read a 271 eligibility response in plain English

Stedi’s Eligibility Check APIs let you get 271 eligibility responses as JSON. That makes them easier to use in code – not easier to understand.

The 271 format is standard. The data inside isn’t. Most fields are optional, and payers use them in different ways. Two payers might return different info for the same patient or put the same info in different places. Luckily, there are consistent ways to extract the data you need.

This guide shows you how to read Stedi’s 271 responses in plain English. You’ll learn how to check if a patient has coverage, what benefits they have, and what they’ll owe. It also includes common mistakes and troubleshooting tips.

This article covers the highlights. For complete details, see Determine patient benefits in our docs or contact us.

Where to find most benefits info

Most of a patient’s benefit info is in the 271 response’s benefitsInformation array.

Each object in the array answers a different question about benefit coverage: Is it active? What’s the co-pay? What's the remaining deductible?

{
  ...
  "benefitsInformation": [
    {
      "code": "1",                        // Active coverage
      "serviceTypeCodes": ["30"],         // General medical
      "timeQualifierCode": "23",          // Calendar year
      "inPlanNetworkIndicatorCode": "Y",  // Applies to in-network services
      "additionalInformation": [
        {
          "description": "Preauthorization required for imaging services."
        }
      ]
    },
    {
      "code": "B",                        // Co-pay
      "serviceTypeCodes": ["88"],         // Pharmacy
      "benefitAmount": "10",              // $10 co-pay
      "inPlanNetworkIndicatorCode": "Y"   // Applies to in-network services
    },
    {
      "code": "C",                        // Deductible
      "serviceTypeCodes": ["30"],         // General medical
      "benefitAmount": "1000",            // $1000 annual deductible
      "timeQualifierCode": "23",          // Calendar year
      "inPlanNetworkIndicatorCode": "N"   // Applies to out-of-network services
    }
  ],
  ...
}

Each benefitsInformation object includes a few key fields. Most of them contain codes:

• code: What the benefit is, like "1" (Active Coverage), "B" (Co-pay), or "C" for (Deductible). Although it's one field, there are two classes of codes: 1-8 for coverage status and A-Y for benefit categories. For more details, see Benefit type codes in the docs.
  
  

• serviceTypeCodes: What kind of care the benefit applies to, like "30" (General Medical) or "88" (Pharmacy). See Service Type Codes in the docs.
  
  Some Service Type Codes (STCs) are broader categories that include other STCs. For example, "MH" (Mental Health) may include "A4" (Psychiatric), "A6" (Psychotherapy), and more. But this varies by payer.
  
  You’ll often see the same serviceTypeCodes in more than one benefitsInformation object. That’s expected. To get the full picture for a service, look at all entries that include its STC.
  
  

• timeQualifierCode: What the benefit amount represents – often the time period it applies to, like "23" (Calendar Year). Sometimes, this indicates whether the amount is a total or remaining portion, like "29" (Remaining Amount). For the full list, see Time Qualifier Codes in the docs.
  
  Use this field to understand how to interpret the dollar amount. For example, whether it’s the total annual deductible or the remaining balance of a maximum.
  
  

• inPlanNetworkIndicatorCode: Whether the benefit applies to in-network or out-of-network care – not whether the provider is in-network. Possible values are "Y" (In-network), "N" (Out-of-network), "W" (Both), and "U" (Unknown). For more details, see In Plan Network Indicator in the docs.
  
  

• additionalInformation.description: Free-text notes from the payer. These often override structured fields. Payers often include important info here that doesn’t fit elsewhere.

Most of these fields have human-readable versions, like codeName for code. Use those for display, not logic. Always use the related code field in your code.

Unless otherwise indicated, the fields referenced in the rest of this guide are in benefitsInformation objects.

Check active coverage

To check if a patient has active coverage, look for two things:

• A benefitsInformation object with code = "1"

• A date range that includes the date of service

Start with the code. This means the patient has coverage for general medical care.

{
  "code": "1",                      // Active coverage
  "serviceTypeCodes": ["30"]        // General medical
}

Next, check the coverage dates. If there’s a benefitsDateInformation field in the same object, use that:

{
  "code": "1",
  "serviceTypeCodes": ["30"],
  "benefitsDateInformation": {
    "service": "20241216-20250114", // Coverage window for this benefit
    "periodStart": "20981216"       // Optional start date (duplicate of above)
  }
}

The benefitsDateInformation dates apply specifically to the benefit in the object. They override the top-level plan dates, so they take precedence.

If that’s missing, use the top-level planDateInformation field:

{
  "planDateInformation": {
    "planBegin": "20250101",       // Plan start date
    "planEnd": "20251231"          // Plan end date
  },
  ...
  "benefitsInformation": [
    {
      "code": "1",                 // Active coverage
      "serviceTypeCodes": ["30"]   // General medical
    }
  ]
}

planDateInformation contains the coverage dates for the patient’s plan.

If the date of service isn’t in the date range, coverage is not active, even if code = "1".

Get patient responsibility

Patient responsibility is what the patient has to pay, usually before or at the time of service. This includes co-pays, co-insurance, or deductibles.

Each cost type uses a different code, and the amount is either a dollar (benefitAmount) or a percent (benefitPercent).

Use inPlanNetworkIndicatorCode to see if the cost applies in-network ("Y") or out-of-network ("N"). If both in- and out-of-network costs exist, you’ll see two benefitsInformation objects with the same code, one for each.

Example: $20 co-pay for in-network mental health

{
  "code": "B",                        // Co-payment
  "serviceTypeCodes": ["MH"],         // Mental health
  "benefitAmount": "20",              // $20 per visit
  "inPlanNetworkIndicatorCode": "Y"   // Applies only to in-network services
}

Example: $1,000 annual deductible with $500 left

{
  "code": "C",                      // Deductible
  "serviceTypeCodes": ["30"],       // General medical
  "timeQualifierCode": "23",        // Calendar year total
  "benefitAmount": "1000",          // $1,000 total
  "inPlanNetworkIndicatorCode": "Y"
},
{
  "code": "C",
  "serviceTypeCodes": ["30"],
  "timeQualifierCode": "29",        // Remaining
  "benefitAmount": "500",           // $500 left to meet deductible
  "inPlanNetworkIndicatorCode": "Y"
}

Check prior authorization requirements

Some services need prior authorization, also called preauthorization. That means the payer must approve the service before they’ll cover it.

Check authOrCertIndicator:

If authOrCertIndicator is missing, it means prior auth isn’t required or the payer didn’t return that info. In practice, most payers set this field to "Y" if prior auth is required for at least some services.

Also check additionalInformation.description. Payers often add notes about prior authorization there.

{
  "additionalInformation": [
    {
      "description": "Preauthorization required for all imaging services performed out-of-network."
    }
  ]
}

If the free text says prior auth (may also be called “preauthorization”) is needed, trust it – even if authOrCertIndicator says otherwise.

Check if benefits apply to in-network providers

The field inPlanNetworkIndicatorCode only tells you whether a benefit applies to in-network care. It doesn’t tell you if the provider is in-network. Example:

{
  "code": "B",                        // Co-payment
  "serviceTypeCodes": ["88"],         // Pharmacy
  "benefitAmount": "10",
  "inPlanNetworkIndicatorCode": "Y"   // Co-pay applies to in-network services
}

This means: If the provider is in-network and the co-pay is $10. It doesn’t say whether the provider actually is in-network.

To check if a provider is in-network:

You can’t tell if a provider is in-network just from the 271. Your best option is to call the payer or provider directly.

Some payers include network status for the provider as free text in additionalInformation.description. However, it’s not standardized and may not be reliable. It's best to confirm via phone. Example:

{
  "description": "Provider is out-of-network for member."
}

Check for a Medicare Advantage plan

A 271 response won’t always say “Medicare Advantage” directly – but you can often infer it.

From a commercial payer:

It’s likely a Medicare Advantage plan if either of the following are true:

• insuranceTypeCode = MA (Medicare Part A) or MB (Medicare Part B).

• A hicNumber is populated in benefitsAdditionalInformation or planInformation. This is the patient’s Medicare Beneficiary Identifier (MBI).

Example: Medicare Advantage indicators

{
  "code": "1",
  "serviceTypeCodes": ["30"],
  "insuranceTypeCode": "MA",
  "benefitsAdditionalInformation": {
    "hicNumber": "123456789A"
  }
}

From a CMS response:

Look for code = "U" and serviceTypeCodes = ["30"]. Then check for a message in benefitsInformation.additionalInformation.description that includes MA Bill Option Code: in the free text:

{
  "additionalInformation": [
    {
      "description": "MA Bill Option Code: B"
    }
  ]
}

The bill option code tells you how claims are handled. If you see B, C, or 2, it’s likely a Medicare Advantage plan.

Benefit overrides and free-text messages

Not everything is in a structured field. Some of the most important rules only show up in additionalInformation.description as free text.

This free text can include:

• Prior auth or referral rules

• Network status hints

• Legal notices (like NSA or BBPA)

• Plan limitations or quirks

This field contains overrides. If it contradicts a structured value, like authOrCertIndicator or code, trust the text.

We recommend you surface this text to end users or flag it for review. Ignoring it means missing critical info.

Example: Prior auth rule not shown in authOrCertIndicator:

{
  "code": "B",
  "serviceTypeCodes": ["MH"],
  "benefitAmount": "20",
  "inPlanNetworkIndicatorCode": "Y",
  "additionalInformation": [
    {
      "description": "Preauthorization required for mental health visits after 6 sessions."
    }
  ]
}

Example: Coverage excluded even though code = "1":

{
  "code": "1",
  "serviceTypeCodes": ["30"],
  "additionalInformation": [
    {
      "description": "Coverage excluded due to missing referral."
    }
  ]
}

Common errors and troubleshooting

Eligibility responses aren’t always clean. Payers sometimes return missing data, conflicts, or errors.

Here’s how to handle common problems:

No code = "1" for active coverage

That doesn’t necessarily mean coverage is inactive. Check for:

• code = "6" (Inactive)

• code = "V" (Cannot Process)

• code = "U" (Contact Following Entity for Eligibility or Benefit Information)

Some payers send code = "V" or code = "U" first but still include code = "1" later. If you see a valid code = "1", use it.

Top-level errors

If the response includes a populated top-level errors array, the whole response is invalid. Even if it includes benefitsInformation. Use Stedi’s Eligibility Manager to debug and try the request again.

Unclear results? Retry with STC 30

If the response is confusing, resend the eligibility check using STC 30 for medical or STC 35 for dental.

These STCS are the most widely supported and usually give the clearest data.

Fast, expert support for eligibility

Stedi’s Eligibility Check APIs let you build fast, reliable eligibility checks. Even with the best tools, you’ll sometimes hit errors or unclear responses.

When that happens, we can help – fast. Our average support time is under 8 minutes.

Want to see how good support can be? Get in touch.