What you can (and can’t) reliably get from a 271 eligibility response

Eligibility checks return results in 1-5 seconds and cost pennies. And Stedi’s JSON Eligibility API makes the responses easy to use in code.

But the data inside an eligibility response can vary a lot between payers. For example, one payer may return the provider’s network status as free text. But most leave it out entirely.

Stedi passes back any eligibility data the payer returns – nothing is omitted. But it can be hard to know what data you can expect across payers.

This guide covers what payers typically include in eligibility responses, what they leave out, and where to find what's there.

The cheat sheet

This table shows what data you can expect in an eligibility response. It covers data we most commonly get asked about.

The sections below contain related explanations and examples. The examples use Stedi's JSON eligibility responses, and, except where noted, contain benefitsInformation objects. These objects contain most of the benefits information for a patient.

For tips on interpreting eligibility responses, check out Determine patient benefits in our docs.

Coverage

✅ Active coverage and coverage dates

To check if a patient has active coverage for a service, look for a benefitsInformation object with:

• code = 1 (Active coverage) for the related Service Type Code (STC)

• A coverage date range that includes the date of service.

For the coverage date range, first check if there’s a benefitsDateInformation field in the same object. If so, use that. It applies specifically to the service and overrides any top-level plan dates.

{
  ...
  "benefitsInformation": [
    {
      "code": "1",                      // Active coverage
      "serviceTypeCodes": ["30"],       // General medical
      "benefitsDateInformation": {
        "service": "20241216-20250114", // Coverage date range for this benefit
        "periodStart": "20981216"       // Optional start date (duplicate of above)
      }
    }
  ]
}

If benefitsDateInformation is missing, use the top-level planDateInformation field. It contains the coverage dates for the patient’s plan.

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

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

✅ Coverage level

The coverageLevelCode field tells you who is covered by a benefit, such as an individual, family, children, etc.

{
  "code": "B",
  "serviceTypeCodes": ["CF"],  // Mental health outpatient
  "coverageLevelCode": "IND",  // Individual coverage
  ...
}

If coverageLevelCode is missing, assume the benefitsInformation object applies to individual coverage.

✅ Plan name

The planCoverage field is the only consistently returned field that contains the plan name:

{
  "code": "1",
  "serviceTypeCodes": ["30"],
  "planCoverage": "Open Access Plus",  // Plan name
  ...
}

The returned plan name may not exactly match the name the payer uses on member insurance cards or their documentation.

A patient can have multiple plans with a payer, like medical, dental, or vision. When they do, each plan may return separate benefitsInformation objects with its own planCoverage value.

✅ Member ID

Most payers require a member ID in the eligibility request to return results. But some allow you to run checks using only a first name, last name, and date of birth. In those cases, you can get back the member ID from the response.

The patient’s member ID can appear in multiple places, including outside the benefitsInformation object. Check the following fields in order:

• subscriber.memberId

• benefitsInformation.benefitsAdditionalInformation.memberId

• planInformation.memberId

The following example includes the group number in subscriber.memberId:

{
  "subscriber": {
    "firstName": "JANE",
    "lastName": "DOE",
    "memberId": "123456789",  // Member ID
    ...
  },
  ...
}

⚠️ Plan number

A plan number is the payer’s unique ID for a plan.

Not all payers return the patient’s plan number. When returned, it can appear in multiple places, including outside the benefitsInformation object. Check the following fields in order:

• subscriber.planNumber

• benefitsInformation.benefitsAdditionalInformation.planNumber

• planInformation.planNumber

The following example includes the group number in subscriber.planNumber:

{
  "subscriber": {
    "firstName": "JANE",
    "lastName": "DOE",
    "planNumber": "123456789",  // Plan number
    ...
  },
  ...
}

⚠️ Group number

A group number is the payer’s code for the employer or other party that purchased the plan. Employees on a group plan typically share the same group number, though there are exceptions. Some employers use different group numbers for different employee categories, like union members and management.

Not all payers return the patient’s group number. When returned, it can appear in multiple places, including outside the benefitsInformation object. Check the following fields in order:

• subscriber.groupNumber

• benefitsInformation.benefitsAdditionalInformation.groupNumber

• planInformation.groupNumber

The following example includes the group number in subscriber.groupNumber:

{
  "subscriber": {
    "firstName": "JANE",
    "lastName": "DOE",
    "groupNumber": "123456789",  // Group number
    ...
  },
  ...
}

⚠️ Secondary or tertiary payers

If the patient is covered under multiple insurance plans, the payer may or may not return the payers for other plans in their response.

Look for a benefitsInformation object with code = R (Other or Additional Payor). The additional payer(s) will be listed in the benefitsRelatedEntities object array:

{
  "code": "R",
  "serviceTypeCodes": ["30"],
  ...
  "benefitsRelatedEntities": [  // Contains info about other payers
    {
      "entityIdentifier": "Secondary Payer",
      "entityType": "Non-Person Entity",
      "entityName": "CIGNA",
	...
    }
  ]
}

The object’s entityIdentifier may indicate whether the other payer is primary, secondary, or tertiary, but it’s not reliable. To check the billing order, run a Coordination of Benefits (COB) check.

❌ Provider network status

Most payers don’t include the provider’s network status in the eligibility response.

The most reliable way to check a provider’s network status is to contact the payer or provider directly. For more tips, see provider network status in the Stedi docs.

Patient responsibility

✅ Deductible

A deductible is the amount a patient must pay out-of-pocket for a service before the payer starts covering costs. For example, with a $1,000 annual deductible, the patient must pay for the first $1,000 before coverage kicks in.

To find the patient’s deductible for a service, check for a benefitsInformation object with code = C (Deductible) for the related STC:

• If the object has a timeQualifierCode of 23 (Calendar Year), the object’s benefitAmount is the annual deductible.
  
  

• If the object has a timeQualifierCode of 29 (Remaining), the object’s benefitAmount is the amount remaining to meet the deductible.

{
  "code": "C",	               // Deductible
  "serviceTypeCodes": ["30"],  // General medical
  "timeQualifierCode": "23",   // Calendar year
  "benefitAmount": "1000",     // $1,000 annual deductible
  ...
},
{
  "code": "C",	               // Deductible
  "serviceTypeCodes": ["30"],
  "timeQualifierCode": "29",   // Remaining
  "benefitAmount": "500",      // $500 remaining to meet the deductible
  ...
}

If you see multiple deductibles for the same STC, check the other fields in the benefitsInformation objects for differences. See How to handle duplicate benefits in 271 eligibility responses for tips.

✅ Co-insurance

Co-insurance is the percentage of costs the patient is responsible for paying for a service. For example, with 20% co-insurance, the patient pays 20% of the cost, and the payer covers the remaining 80%.

To get a patient’s coinsurance, check for a benefitsInformation object with code = A (Co-insurance) for the related STC. The benefitPercent is the co-insurance percentage.

{
  "code": "A",                         // Co-insurance
  "serviceTypeCodes": ["35"],          // Dental Care
  "benefitPercent": "0",               // 0% co-insurance    
  ...
}

If you see multiple co-insurance amounts for the same STC, check the other fields in the benefitsInformation objects for differences. See How to handle duplicate benefits in 271 eligibility responses for tips.

Note: Co-insurance and co-pays are typically mutually exclusive. Plans tend to have one or the other for a benefit. It’s rare to see both.

✅ Co-pay

A co-pay is a fixed dollar amount the patient pays for a service, regardless of whether they’ve met the deductible. For example, a $25 co-pay for each physician office visit.

To get the patient’s co-pay, look for code = B (Co-payment) for the related STC. The benefitAmount is the co-pay amount.

{
  "code": "B",                        // Co-pay
  "serviceTypeCodes": ["86"],         // Emergency Services
  "benefitAmount": "30",              // $30 co-pay
  ...
}

If you see multiple co-pays for the same STC, check the other fields in the benefitsInformation objects for differences. See How to handle duplicate benefits in 271 eligibility responses for tips.

Note: Co-insurance and co-pays are typically mutually exclusive. Plans tend to have one or the other for a benefit. It’s rare to see both.

✅ Out-of-pocket maximum

An out-of-pocket maximum is the total amount a patient will pay for a service in a plan year. Look for benefitsInformation objects for the related STC with code = G (Out of Pocket):

• If the object has a timeQualifierCode of 23 (Calendar Year) or no timeQualifierCode, the object’s benefitAmount is the annual out-of-pocket maximum.
  
  

• If the object has a timeQualifierCode of 29 (Remaining), the object’s benefitAmount is the amount remaining to meet the out-of-pocket maximum.

{
  "code": "G",	               // Out-of-pocket maximum
  "serviceTypeCodes": ["30"],  // General medical
  "benefitAmount": "4000",     // $4,000 annual out-of-pocket maximum
  ...
},
{
  "code": "G",	               // Out-of-pocket maximum
  "serviceTypeCodes": ["30"],
  "timeQualifierCode": "29",   // Remaining
  "benefitAmount": "3543.13",  // $3,543.13 remaining to meet the out-of-pocket maximum
  ...
}

⚠️/❌ Lifetime maximum

A lifetime maximum is the total amount a payer will pay for a certain benefit over the member's entire coverage lifetime. They’re common for dental and vision plans but rare in medical plans. For example, a dental plan may have a $2,000 lifetime maximum for orthodontics.

Look for benefitsInformation objects with code = F (Limitations) for the related STC:

• If the object has a timeQualifierCode of 32 (Lifetime, the object’s benefitAmount is the lifetime maximum.
  
  

• If the object has a timeQualifierCode of 33 (Lifetime Remaining), the object’s benefitAmount is the amount remaining to meet the lifetime maximum.

{
  "code": "F",                 // Limitations
  "serviceTypeCodes": ["38"],  // Orthodontics
  "timeQualifierCode": "32",   // Lifetime
  "benefitAmount": "2500",     // $2,500 lifetime maximum
  ...
},
{
  "code": "F",		           // Limitations
  "serviceTypeCodes": ["38"],
  "timeQualifierCode": "33",   // Lifetime Remaining
  "benefitAmount": "1020.15",  // $1,020.15 remaining to meet the lifetime maximum
  ...
}

Service-level details

✅ Prior authorization requirements

In some cases, a payer has to approve a service or procedure before it’s covered. That approval is called prior authorization.

To see if a service requires prior authorization, look for the authOrCertIndicator field in benefitsInformation objects for the related STC:

{
  "code": "C",
  "serviceTypeCodes": ["BC"],  // Day Care (Psychiatric)
  "authOrCertIndicator": "Y",  // Prior authorization is required.
  ...
}

If there’s no authOrCertIndicator field in the response, you can assume prior authorization isn’t required.

⚠️ Coverage details for specific procedure codes

Most medical payers don’t return information about specific procedure codes – like Current Procedural Terminology (CPT) or Healthcare Common Procedure Coding System (HCPCS) codes – in their eligibility responses.

Most dental payers do. It’s not uncommon to see Current Dental Terminology (CDT) codes in a dental eligibility response, but it’s not guaranteed.

If returned, procedure code-level information can be in multiple spots. First, check the compositeMedicalProcedureIdentifier object:

{
  "serviceTypeCodes": ["35"],
  "compositeMedicalProcedureIdentifier": {
    "productOrServiceIDQualifierCode": "AD",  // CDT codes
    "procedureCode": "D0120"  // Periodic Oral Evaluation - established patient
  },
  ...
}

Next, check for free-text notes in additionalInformation.description:

{
  "serviceTypeCodes": ["35"],
  "additionalInformation": [
    {
      "description": "Benefit applies to D0150 - Comprehensive oral evaluation"
    }
  ],
  ...
}

If the payer doesn’t return procedure code-level information in these fields, map your procedure code to the closest STC. See STCs and procedure codes for tips.

⚠️/❌ Age limits

Age limits restrict coverage based on the patient's age. They’re common for dependents on dental and medical plans.

Dental payers will sometimes return age limits in benefitsInformation objects. The limit is indicated in the quantityQualifierCode and benefitQuantity fields:

{
  "code": "A",                      // Co-insurance
  "quantityQualifierCode": "S7",    // Age, High Value (max age)
  "benefitQuantity": "22",          // Max covered age is 22 (age limit)
  ...  
}

Most medical payers omit age limits from their eligibility responses.

To get information about age limits, you can contact the payer directly. For programmatic access, you can try an AI voice agent. See Using Stedi for AI voice agent workflows.

⚠️/❌ Frequency limits

Frequency limits control how often a service is covered within a certain time period. They’re common for dental plans but rare for medical plans. For example, your dental plan may only cover 1 cleaning every 6 months.

Some payers include frequency limits in the benefitsServiceDelivery object. There may also be related notes in the additionalInformation.description field:

{
  "code": "A",                                // Co-insurance
  ...  
  "benefitsServiceDelivery": [                // 1 visit every 6 months (freq. limit)
    {
      "quantityQualifierCode": "VS",          // Visits
      "quantity": "2",                        // 2 visits
      "timePeriodQualifierCode": "23",        // Calendar year
      "numOfPeriods": "1",                    // 1 year
    }
  ],
  "additionalInformation": [
    { 
      "description": " SEPARATED BY 6 MONTHS" // Visits must be separated by 6 months
    }
  ],
}

⚠️ Service history

Service history shows what care a patient has already received. It’s important to check a patient’s service history for services with frequency limits, like dental cleanings. Otherwise, the care may not be covered.

Payers don’t typically include a full service history in their eligibility responses. But you can sometimes get the last date of service in benefitsDateInformation.latestVisitOrConsultation:

{
  "code": "A",                              // Co-insurance
  "serviceTypeCodes": ["35"],               // Dental Care
  ...
  "benefitsDateInformation": {
    "latestVisitOrConsultation": "20240404" // Last service
  }
}

⚠️ Missing tooth clause and waiting period

In dental insurance, a missing tooth clause details what services are covered for teeth lost before coverage started. A waiting period is the time you must wait after coverage starts before certain services are covered. 

No dental payer reliably returns missing tooth clause or waiting period details in their eligibility responses. However, some payers do mention them in related limitations.

For the limitations, look for benefitsInformation objects that contain code = F (Limitations) and a related free-text note in additionalInformation.description. For example:

{
  "code": "F",    // Limitations
  ...
  "additionalInformation": [
    {
      "description": "Waiting Period does not apply."
    }
  ],
},
{
  "code": "F",
  ...
  "additionalInformation": [
    {
      "description": "Missing Tooth Exclusion does not apply."
    }
  ]
}

If you need more details, your best bet is to contact the payer directly or use the payer's portal.

For programmatic access, you can try an AI voice agent or portal scraping. See Using Stedi for AI voice agent workflows and How to scale dental payer portal scraping with eligibility checks.

❌ RxBINs and RxPCNs

Pharmacy Bank Identification Numbers (RxBINs) and Processor Control Numbers (RxPCNs) tell pharmacies where to send claims. RxBINs and RxPCNs are often on members’ insurance cards.

Payers don't typically include these codes in eligibility responses.

Active coverage for pharmacy benefits
Some payers include benefits for STC 88 (Pharmacy) in eligibility responses. But these benefit entries usually only indicate that pharmacy coverage exists with code = 1 (Active coverage). They don’t include specific benefit details. For example:

{
  "code": "1",			         // Active coverage
  "serviceTypeCodes": ["88"],    // Pharmacy benefits
  ...
}

Pharmacy Benefits Manager information
Pharmacy benefits are often handled by a Pharmacy Benefits Manager (PBM), a company separate from the payer.

Information for the plan’s PBM is often (but not always) returned in a benefitsRelatedEntities object. For example:

{
  "code": "U",  // Contact Following Entity for Eligibility or Benefit Information
  "serviceTypeCodes": ["88"],  // Pharmacy services
  ...
  "benefitsRelatedEntities": [
  {
    "entityIdentifier": "Third-Party Administrator",
    "entityType": "Non-Person Entity",
    "entityName": "Acme Pharmacy Services",
    "contactInformation": {
      "contacts": [
        {
          "communicationMode": "Telephone",
          "communicationNumber": "1234567890"
        }
      ]
    }
  },
  ...
}

Tip: Don’t rely on the benefitsRelatedEntities.entityIdentifier field to identify PBMs. The value can vary between payers.

Get help from eligibility experts

Every payer is different. If you’re running into edge cases not covered here, reach out. We can help you figure out what’s going on and how to build around it.