How to estimate patient responsibility using a 271 eligibility response

“How much will this cost?” It’s the first question many patients ask their provider.

Real-time eligibility checks return the data you need to estimate patient responsibility – co-pays, deductibles, limitations – but they don’t hand you the answer. The response is often nuanced and, in some cases, can seem contradictory.

With a few simple patterns in place, though, you can reliably extract the information needed to build cost estimates you – and your providers – can trust.

This guide shows you how. It walks through the structure of a 271 eligibility response and shares practical tips for using Stedi’s Real-Time Eligibility Check JSON API to estimate patient responsibility. It also gives you tips for improving cost estimates using data from Stedi’s 835 ERA Report API.

Choose the right STC

Eligibility responses organize benefits by Service Type Codes (STCs). STCs group services into broad categories like "office visit" or "surgery."

The STC you send in the eligibility request shapes what you get back in the response. Choose the right one, and you'll get the benefits you need. Choose the wrong one, and you might miss them entirely.

Here’s a reliable approach:

• Use one STC per request. Many payers don’t support multiple STCs. To test payer support for multiple STCs, see Test payer STC support in the Stedi docs.
  
  

• Don't use procedure codes (HCPCS/CPT/CDT) in eligibility requests. While Medicare and some dental payers accept them, most ignore them entirely. Map the procedure codes to STCs first.
  
  

• Only send required patient data in eligibility requests. Payers require that eligibility checks match a single member. Extra data increases the risk of a mismatch. Stick to:

  • Member ID

  • First name

  • Last name

  • Date of birth
    
    

• You may get benefits for more STCs than you request. For example, HIPAA requires medical payers to return benefits for applicable STCs for STC 30 (Health Benefit Plan Coverage).  See General benefit checks in the docs.
  
  

• Missing benefits don't mean missing coverage. Payers aren't required to respond to every STC. Compare the response for your STC to STC 30 for medical or STC 35 for dental. If there's a difference in the response, the STC is likely supported. See Test payer STC support in the docs.

For example, to estimate costs for a level 3 established patient office visit (CPT code 99213), start by mapping the procedure code to the most appropriate STC. In this case, that’s STC 30.

Then, send a real-time eligibility request with a body similar to:

{
    ...
    "encounter": {
      "serviceTypeCodes": ["30"]
    },
    "provider": {
      "organizationName": "ACME Health Services",
      "npi": "1999999984"
    },
    "subscriber": {
      "dateOfBirth": "19900101",
      "firstName": "John",
      "lastName": "Doe",
      "memberId": "123456789"
    }
}

Where to find patient costs in the response

Most of a patient’s benefit information, including patient cost, is in the eligibility response’s benefitsInformation array. For example:

{
  ...
  "benefitsInformation": [
    {
      "code": "B",                        // Co-pay
      "serviceTypeCodes": ["88"],         // Pharmacy
      "benefitAmount": "10",              // $10 co-pay
      "inPlanNetworkIndicatorCode": "Y"   // In-network only
    },
    {
      "code": "C",                         // Deductible
      "coverageLevelCode": "IND",          // Individual coverage
      "serviceTypeCodes": ["30"],          // General medical (used for CPT 99213)
      "timeQualifierCode": "23",           // Calendar year
      "benefitAmount": "1000",             // $1000 deductible
      "inPlanNetworkIndicatorCode": "Y",   // In-network only
    },
    {
      "code": "A",                         // Co-insurance
      "serviceTypeCodes": ["35"],          // Dental Care
      "benefitPercent": "0",               // 0% co-insurance    
      "inPlanNetworkIndicatorCode": "N",   // Out-of-network only
      "compositeMedicalProcedureIdentifier": {
        "productOrServiceIDQualifierCode": "AD", // American Dental Association (ADA)
        "procedureCode": "D0150"                 // Comprehensive oral evaluation
      },
      "benefitsDateInformation": {
        "latestVisitOrConsultation": "20240404" // Last service
      },
      "benefitsServiceDelivery": [           // 1 visit every 6 months
        {
          "quantityQualifierCode": "VS",     // Visits
          "quantity": "1",                   // 1 visit
          "timePeriodQualifierCode": "34",   // Months
          "numOfPeriods": "6"                // Every 6 months
        }
      ]
    }
    ...
  ],
  ...
}

Each benefitsInformation object includes a few key fields related to patient costs:

• serviceTypeCodes - The services this benefit applies to.
  
  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.
  
  

• code - What the benefit is. For patient costs, the relevant codes are:

  • A – Co-insurance: Percentage the patient pays for the benefit.

  • B – Co-pay: Fixed dollar amount the patient pays for the benefit.

  • C – Deductible: Total amount the patient must pay before benefits begin.

  • F – Limitations (Maximums): Maximum benefit amount. Typically used for dental and vision plans.

  • G – Out of Pocket (Stop Loss): Maximum amount a patient can pay per year. Once reached, the plan pays 100% of covered services.

  • J – Cost Containment: Total amount the patient must pay before benefits begin, similar to a deductible. Typically used for Medicaid benefits.

  • Y – Spend Down: Total amount the patient must pay before they can receive benefits. Typically used for Medicaid benefits.
    
    

• benefitAmount or benefitPercent - The dollar or percentage value of the patient costs. benefitPercent is used for co-insurance (code = A). All other patient cost types use `benefitAmount`.
  
  

• timeQualifierCode - What the benefit amount represents. It’s often the time period it applies to. For example, if an entry has code = G (Out-of-pocket maximum) and timeQualifierCode = 29 (Remaining Amount), then benefitAmount contains the remaining out-of-pocket maximum.

For the full list of time qualifier codes, see Time Qualifier Codes in the docs.

• coverageLevelCode - Code indicating the level of coverage for the patient. For example, IND (Individual) or FAM (Family).
  
  

• 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. For patient costs, these notes often contain limitations and qualifications, as well as carve-outs that don’t align neatly to a full STC. For example for co-pays (code = B), this may contain VISIT OFFICE PCP,TELEHEALTH PRIMARY CARE, which indicates when the co-pay applies.

Service history fields
Some benefits have frequency limits. For example, “one visit every 6 months” or “two cleanings per year.” Others depend on when the patient last received the service.

To estimate patient cost for these types of benefits, look for:

• benefitsDateInformation – Shows when a service (like a cleaning or exam) was last performed.
  
  

• benefitsServiceDelivery – Indicates how often a service is allowed, such as once every 6 months or twice per year. Many payers don’t populate this field and instead return this information as free text in additionalInformation.description.

These fields show up in responses for dental, vision, and Medicaid. They also apply to some medical services, like annual wellness visits or therapy sessions.

If the patient has already reached the allowed frequency, the next visit may not be covered. In that case, they may owe the full amount.

Some plans, especially dental, apply shared frequency limits across a group of procedures. For example, a plan might allow one X-ray series per year, regardless of the procedure code used later in the claim. If a claim has already been paid for one of the codes in the group, subsequent claims for others may be denied.

Handling multiple benefit entries

The same STC often has different patient costs for different scenarios. When you see multiple benefit entries for the same STC, check these fields to understand which cost applies when:

• coverageLevelCode - Coverage level, such as individual or family

• inPlanNetworkIndicatorCode - In-network vs. out-of-network rates

• additionalInformation.description - Specific limitations and exceptions.

These fields are easy to miss, but without them, entries with the same STC and benefits code can look contradictory when they’re actually describing different conditions.

Example: Multiple deductibles for the same STC
In the following example, both benefitsInformation entries apply to general medical coverage (STC 30), but the inPlanNetworkIndicatorCode differentiates them: the in-network deductible is $1000. The out-of-network deductible is $2500.

// In-network deductible
{
  "code": "C",                             // Deductible
  "coverageLevelCode": "IND",              // Individual coverage
  "serviceTypeCodes": ["30"],              // General medical
  "timeQualifierCode": "23",               // Calendar year
  "benefitAmount": "1000",                 // **$1000 deductible**
  "inPlanNetworkIndicatorCode": "Y",       // **In-network only**
}
// Out-of-network deductible
{
  "code": "C",                             // Deductible
  "coverageLevelCode": "IND",              // Individual coverage
  "serviceTypeCodes": ["30"],              // General medical
  "timeQualifierCode": "23",               // Calendar year
  "benefitAmount": "2500",                 // **$2500 deductible**
  "inPlanNetworkIndicatorCode": "N",       // **Out-of-network only**
}

Improve cost estimates with 835 ERAs

Eligibility responses return benefits at the service type level. But what payers actually pay shows up in the 835 ERA, broken down by procedure code.

You can retrieve ERAs as JSON using Stedi’s 835 ERA Report API endpoint. For example, the previous eligibility check above may correspond to a visit with the following ERA:

{
 ...
 "transactions": [
   {
     ...
     "detailInfo": [
       {
         "paymentInfo": [
           {
             "claimPaymentInfo": {
               "claimPaymentAmount": "500",           // What payer paid provider
               "patientResponsibilityAmount": "300",  // What patient owes
               "totalClaimChargeAmount": "800",       // Original charge
               "patientControlNumber": "1112223333"   // Your tracking number
             },
             "patientName": {
               "firstName": "JOHN",
               "lastName": "DOE",
               "memberId": "123456789"
             },
             "serviceLines": [
               {
                 "serviceAdjustments": [
                   {
                     "adjustmentAmount1": "300",         // Amount adjusted
                     "adjustmentReasonCode1": "1",       // Deductible
                     "claimAdjustmentGroupCode": "PR"    // Patient responsibility
                   }
                 ],
                 "servicePaymentInformation": {
                   "adjudicatedProcedureCode": "99213",   // CPT code
                   "lineItemChargeAmount": "800",         // Charged amount
                   "lineItemProviderPaymentAmount": "500" // Paid to provider
                 }
               }
             ]
           }
         ]
       }
     ],
     "financialInformation": {
       "totalActualProviderPaymentAmount": "1100"   // Total payment for all claims
     },
     ...
   }
 ]
}

To identify patient responsibility in an ERA, look for serviceLines entries with serviceAdjustments.claimAdjustmentGroupCode = PR (Patient responsibility). These adjustments are the amounts the patient is expected to pay. The adjustmentReasonCode tells you why. For example, Claim Adjustment Reason Codes (CARCs) are:

• 1 – Deductible

• 2 – Coinsurance

• 3 – Copay

• 119 – Benefit max reached for the period

For a full list, see the X12 Claim Adjustment Reason Codes list.

CARCs often align with benefitsInformation.code values in eligibility responses. For example, adjustmentReasonCode = 1 (Deductible) in the ERA corresponds to code = C (Deductible) in the eligibility response. By comparing both sources, you can refine your estimates over time.

Building a cost estimation engine
Several Stedi customers combine 271 eligibility checks with 835 ERAs to refine their patient cost estimates over time. The most reliable setups use a simple feedback loop:

1. Estimate patient costs using eligibility responses and historical data from prior claims (see step 5).

2. Submit claims and collect ERAs.

3. Extract payment patterns by CPT code, payer, and plan.

4. Compare actual payments to your original estimates.

5. Update your logic for patient cost estimates based on actual payments.

ERAs don’t give you market-wide benchmarks – only what happened with your own claims. For common procedures with high-volume payers, that’s often enough to make confident estimates.

Real-time support for real-time eligibility

Even clean eligibility requests sometimes return unclear responses. When that happens, our support team can help make sense of it. Our average support response time is under 10 minutes.

It’s one reason teams trust Stedi to stay in the loop while they scale.

To see how it works, start a free trial.