Active coverage and benefits
This page describes how to use the eligibility response to determine the patient's active coverage, eligibility dates, and specific benefits.
Response shapes
Stedi returns one of two response shapes, depending on the endpoint you called. Both contain the same benefits information, organized differently. You can identify them by the top-level array that organizes the patient's benefits information - either plans or benefitsInformation.
| Top-level array | Endpoints |
|---|---|
plans | Real-Time Eligibility Check JSON |
benefitsInformation | Batch Eligibility Check, Insurance Discovery, Real-Time Eligibility Check Raw X12, Real-Time Eligibility Check JSON - Legacy |
Every section on this page covers both response shapes, labeled plans and benefitsInformation. Select the label that matches the endpoint you called, and the page applies your selection to every section.
Does the patient have coverage for the requested service?
You need two key pieces of information to determine whether the patient's health plan covers the requested service. The patient has coverage when:
- The date of service is within the eligibility period for their health plan. When the benefit you're checking has its own benefit-specific dates, use those dates instead.
- They have active coverage for the applicable service type code.
The subscriber.dates object contains the eligibility period for the patient's health plan. Each entry in plans[].benefits.statuses reports coverage status for the service named in its service object.
In the following example:
- The
subscriber.dates.planobject shows that the patient's coverage with their health plan runs from January 1 through December 31, 2024. - The
plans[].benefits.statusesentry reportsACTIVE_COVERAGEfor service type code35(Dental Care). - That entry includes its own
dates.benefit, which begins July 1. The patient has dental coverage from July 1, not from January 1 when their health plan coverage begins. Use the benefit's dates to determine eligibility for dental services.
{
"id": "ec_550e8400-e29b-41d4-a716-446655440000",
"payer": {
"type": "PAYER",
"name": { "organization": "HUMANA" }
},
"x12": "...",
"subscriber": {
"dates": {
"plan": { "start": "2024-01-01", "end": "2024-12-31" }
}
},
"plans": [
{
"benefits": {
"statuses": [
{
"status": "ACTIVE_COVERAGE",
"coverageLevel": "INDIVIDUAL",
"service": {
"system": "STC",
"value": "35",
"definition": "Dental Care"
},
"dates": {
"benefit": { "start": "2024-07-01", "end": "2024-12-31" }
}
}
]
}
}
]
}When is the patient eligible for benefits?
The payer returns dates that determine when the patient is eligible for benefits under their health plan. Most commercial payers only return information for the current calendar year.
The patient likely doesn't have active coverage if the date of service falls after the earliest ending date. These dates apply to every benefit within the patient's health plan unless a specific benefit has its own dates.
The subscriber.dates object contains the coverage dates, or dependent.dates when the patient is a dependent. Check plan, eligibility, and policy.
The following example shows a health plan that began on January 1, 2024 and ended on December 31, 2024. The patient has been eligible for benefits since January 1, 2023.
"subscriber": {
"dates": {
"plan": { "start": "2024-01-01", "end": "2024-12-31" },
"eligibility": { "start": "2023-01-01" }
}
}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.
The subscriber and the dependent each have their own dates object, so Stedi maps them independently. When the patient is a dependent, check dependent.dates for their coverage dates.
Benefit-specific eligibility dates
When a benefit has its own dates, use those dates to determine the patient's eligibility for that benefit type instead of the plan-level coverage dates.
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 the patient's hire date, but life insurance or disability coverage begins after 90 days.
- Some plans require a delay before certain benefits start, even though the patient's general plan is active. For example, dental insurance may have a 6-month waiting period for major services (like crowns), but covers basic services (like cleanings) immediately.
- Some government programs like Medicare split coverage (Part A, Part B, and Part D), each with its own effective date.
- Patients may switch plans during open enrollment, and new benefits can have different effective dates.
Every benefit type can include its own dates object, such as plans[].benefits.deductible[].dates. Check benefit for the dates that apply to that benefit.
The following example shows a dental deductible that applies from July 1, 2024 through the end of the year, even though the patient's plan began earlier.
"plans": [
{
"benefits": {
"deductible": [
{
"amount": "1000",
"coverageLevel": "INDIVIDUAL",
"service": {
"system": "STC",
"value": "35",
"definition": "Dental Care"
},
"dates": {
"benefit": { "start": "2024-07-01", "end": "2024-12-31" }
}
}
]
}
}
]What are the patient's benefits?
A response usually contains many benefit entries for one or more of the patient's health plans. To understand the patient's benefits, look for three things in the response:
- Coverage status: Whether the patient has active or inactive coverage for a service.
- Benefit types: Which benefit types the response includes, such as co-payments, deductibles, and exclusions.
- Service type codes: Which service type code applies to each benefit type.
Active and inactive coverage
A response doesn't always include an explicit coverage status for every service. When the response includes any benefit for a service, you can assume the patient has active coverage for that service. For example, when the response includes a co-payment for service type code 30, you can assume active coverage for that service type.
When the payer does report coverage status, a patient can have active coverage for some services and inactive coverage for others.
Check the plans[].benefits.statuses array. Each entry's status property reports coverage for the service in that entry's service object. Values beginning with ACTIVE indicate active coverage, and values beginning with INACTIVE indicate inactive coverage.
The following example shows active coverage for service type code 30 (Health Benefit Plan Coverage).
"plans": [
{
"benefits": {
"statuses": [
{
"status": "ACTIVE_COVERAGE",
"coverageLevel": "INDIVIDUAL",
"service": {
"system": "STC",
"value": "30",
"definition": "Health Benefit Plan Coverage"
},
"planCoverageDescription": "Open Access Plus"
}
]
}
}
]The following example shows inactive coverage for the same service type.
"plans": [
{
"benefits": {
"statuses": [
{
"status": "INACTIVE",
"coverageLevel": "INDIVIDUAL",
"network": { "indicator": "IN_AND_OUT_OF_NETWORK" },
"service": {
"system": "STC",
"value": "30",
"definition": "Health Benefit Plan Coverage"
}
}
]
}
}
]Benefit types
A response can include many entries across several benefit types, such as co-payments, deductibles, and exclusions. How you find the benefit types you care about depends on the response shape.
A benefit's network indicator reports whether that benefit applies to in-network or out-of-network providers. It doesn't tell you whether the provider who requested the eligibility check is in-network for the health plan, so don't assume an in-network cost applies to that provider until you verify their network status. Visit Provider network status, authorizations, referrals for more details.
The plans[].benefits object contains the benefits, where each kind of benefit is its own named array. The statuses array reports whether the patient has coverage, and the remaining arrays describe specific benefits.
The following example shows a member with active coverage for service type code 30 (Health Benefit Plan Coverage), along with a co-payment for hospital room and board. The co-payment is $2,000 for providers considered in-network, as indicated by IN_NETWORK in the network.indicator property.
"plans": [
{
"benefits": {
"statuses": [
{
"status": "ACTIVE_COVERAGE",
"coverageLevel": "EMPLOYEE_ONLY",
"planCoverageDescription": "Humana Gold Plan",
"service": {
"system": "STC",
"value": "30",
"definition": "Health Benefit Plan Coverage"
},
"network": { "indicator": "IN_AND_OUT_OF_NETWORK" }
}
],
"coPayment": [
{
"amount": "2000",
"coverageLevel": "INDIVIDUAL",
"service": {
"system": "STC",
"value": "49",
"definition": "Hospital - Room and Board"
},
"network": { "indicator": "IN_NETWORK" },
"timePeriod": "ADMISSION",
"messages": ["INPATIENT HOSPITAL ROOM AND BOARD"]
}
]
}
}
]Benefit type codes
Benefit type codes apply only to the benefitsInformation shape. The plans shape has no equivalent code, because each benefit type is its own named array.
The benefit type code identifies the benefit type. It's different from the service type code, which identifies the service a benefit covers. Payers may send multiple entries for the same service type code with different benefit type codes, to communicate different aspects of the benefits.
The following is a complete list of codes that can be returned in the benefitsInformation[].code property.
Cannot process
A payer sometimes reports that it couldn't process part of your request. This doesn't mean the patient has no coverage for the service. It means the payer couldn't answer the question you asked, so you need to determine why before you rely on the response.
These are the most common reasons:
- Request errors: The payer didn't return any benefits information because of errors in the request, which appear in the
errorsarray. Ignore the stub benefit data, 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 payer typically explains this in a freeform message, and sometimes includes contact information.
- 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 both a cannot-process entry and an entry reporting coverage for the code it prefers.
Look for entries in the plans[].benefits.cannotProcess array.
- The entry's
messagesarray contains the payer's explanation. payer.contactscontains contact information when the payer sends it.- For an alternate service type code, the payer typically returns a cannot-process entry immediately followed by an active coverage entry containing the preferred code. Stedi groups entries by type, so the preferred code appears in
plans[].benefits.statuses[].service.value.
Service type codes
Service type codes (STCs) identify the services a benefit covers.
Review the service type code (STC) list to determine which STCs are relevant to the benefits you're interested in and check for all of them in the response. This is helpful because the payer may return relevant benefits under a different STC than the one you submitted. For example, mental health benefits are typically returned with STC MH (Mental Health), but some payers may use other STCs, such as A4 (Psychiatric), CF (Mental Health Provider - Outpatient), or AI (Substance Abuse) for related services.
Each benefit includes one service object. Its system property identifies the code system, value the code, and definition the code's name. Stedi populates definition for service type codes, but not for procedure codes such as CDT, CPT, and HCPCS, so you need your own lookup for those. When a benefit applies to several services, Stedi returns a separate entry for each.
The following entries all apply to service type code CF (Mental Health Provider - Outpatient), but each appears in a different benefit array, describing a different aspect of the benefits:
- The
statusesentry reports that the patient has active coverage for outpatient mental health services. - The
deductibleentry reports a $1,000 deductible for those services. - The
benefitDescriptionentry qualifies the coverage.
"plans": [
{
"benefits": {
"statuses": [
{
"status": "ACTIVE_COVERAGE",
"coverageLevel": "INDIVIDUAL",
"service": {
"system": "STC",
"value": "CF",
"definition": "Mental Health Provider - Outpatient"
},
"network": { "indicator": "IN_NETWORK" },
"messages": [
"INCLUSIONS SPEECH/PHYSICAL/OCCUPATIONAL THERAPY; APPLIED BEHAVIOR ANALYSIS (ABA)"
]
}
],
"deductible": [
{
"amount": "1000",
"coverageLevel": "INDIVIDUAL",
"service": {
"system": "STC",
"value": "CF",
"definition": "Mental Health Provider - Outpatient"
},
"network": { "indicator": "IN_NETWORK" },
"timePeriod": "CALENDAR_YEAR"
}
],
"benefitDescription": [
{
"coverageLevel": "INDIVIDUAL",
"service": {
"system": "STC",
"value": "CF",
"definition": "Mental Health Provider - Outpatient"
},
"messages": ["EXCLUSIONS: DEVELOPMENTAL TESTING, EDUCATIONAL THERAPY"]
}
]
}
}
]Carveout benefits
A carveout is when the primary payer for a plan lets another entity handle certain benefits. Carveout administrators often specialize in benefits for a particular service, such as mental health services or pharmacy benefits. For example, many Blue Cross Blue Shield (BCBS) plans carve out mental (behavioral) health benefits to Magellan, a mental health payer.
Carveouts are part of a single health plan, so they're different from secondary or tertiary insurance coverage. A patient can have carveout benefits for their primary plan and still have secondary insurance coverage through other payers.
Most payers omit carveout benefits from eligibility responses, but many include the carveout administrator's information.
Carveout administrator information
Don't rely on relatedEntities[].type to identify carveout administrators, because the value can vary between payers.
Instead, look for entries in the plans[].benefits.contactFollowingEntityForInformation or plans[].benefits.statuses array that have:
- A
serviceobject containing a related service type code. - A
relatedEntitiesobject containing the administrator's name and contact information. - A
memberIdon that object, which contains the patient's member ID for the carveout administrator when the payer sends one.
We recommend also examining plans[].benefits.benefitDescription entries. Their messages array sometimes contains relevant details.
The following example shows a third-party administrator called Acme Health Payer handling a patient's mental health benefits (service type code MH). The messages array in the benefitDescription entry indicates that the administrator manages these benefits separately.
"plans": [
{
"benefits": {
"contactFollowingEntityForInformation": [
{
"coverageLevel": "INDIVIDUAL",
"service": {
"system": "STC",
"value": "MH",
"definition": "Mental Health"
},
"relatedEntities": [
{
"type": "THIRD_PARTY_ADMINISTRATOR",
"name": { "organization": "Acme Health Payer" },
"memberId": "123456789",
"contacts": [
{
"phoneNumbers": ["1234567890"]
}
]
}
]
}
],
"benefitDescription": [
{
"coverageLevel": "INDIVIDUAL",
"service": {
"system": "STC",
"value": "MH",
"definition": "Mental Health"
},
"messages": ["BEHAVIORAL HEALTH MANAGED SEPARATELY"]
}
]
}
}
]Get carveout benefits details
When payers return carveout administrator information, you can:
- Get the carveout administrator's payer ID from the Payer Network or Search Payers endpoint.
- Get the patient's member ID for the carveout administrator, if the payer returned one. In the
plansshape, it's inrelatedEntities[].memberId. In thebenefitsInformationshape, it's inbenefitsRelatedEntities[].entityIdentificationValue. - Send a second eligibility check to the carveout administrator.
If you use the right STC, many carveout admins will return the missing carveout benefits. The STC may differ from the one you sent to the primary payer. Visit STCs and procedure codes for tips on choosing the right STC.
If the primary payer doesn't return the carveout administrator's details, you can try checking the patient's member ID card. The back of the card often lists the carveout administrator's name and contact information. You can also try calling the primary payer and checking their website or portal.
Pharmacy benefits
Some payers include benefits for STC 88 (Pharmacy) in eligibility responses, but these entries usually only indicate that pharmacy coverage exists. They often don't include specific benefit details.
These entries usually appear in the statuses array with a status of ACTIVE_COVERAGE. The following example shows a statuses entry indicating that the patient has active pharmacy benefits.
"plans": [
{
"benefits": {
"statuses": [
{
"status": "ACTIVE_COVERAGE",
"coverageLevel": "INDIVIDUAL",
"planCoverageDescription": "Advantage Pharmacy",
"service": {
"system": "STC",
"value": "88",
"definition": "Pharmacy"
}
}
]
}
}
]However, some payers do return specific pharmacy benefit details, such as co-payments and out-of-pocket maximums. The following examples show a patient's out of pocket (stop loss) benefit per calendar year for pharmacy services. This is the maximum amount the patient pays for covered pharmacy services in a year. The payer includes a note that the patient's co-payments count toward this out-of-pocket maximum.
"plans": [
{
"benefits": {
"outOfPocket": [
{
"amount": "6000",
"coverageLevel": "FAMILY",
"service": {
"system": "STC",
"value": "88",
"definition": "Pharmacy"
},
"network": { "indicator": "IN_NETWORK" },
"timePeriod": "CALENDAR_YEAR",
"messages": ["Copay does apply to member's out-of-pocket maximum"]
}
]
}
}
]Pharmacy Benefits Manager
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 relatedEntities object. Don't rely solely on relatedEntities[].type to identify PBMs, because the value can vary between payers. Review the object's name and contacts properties to confirm that the entity is a PBM.
The following example shows a relatedEntities object indicating that a third-party administrator called Acme Pharmacy Services manages the patient's pharmacy benefits.
"plans": [
{
"benefits": {
"contactFollowingEntityForInformation": [
{
"coverageLevel": "INDIVIDUAL",
"service": {
"system": "STC",
"value": "88",
"definition": "Pharmacy"
},
"relatedEntities": [
{
"type": "THIRD_PARTY_ADMINISTRATOR",
"name": { "organization": "Acme Pharmacy Services" },
"contacts": [
{
"phoneNumbers": ["1234567890"]
}
]
}
]
}
]
}
}
]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 the member's insurance card.
Payers don't typically include these codes in eligibility responses. When the payer sends one, both response shapes return the requesting provider's processor number in provider.pharmacyProcessorNumber. The plans shape can also return a processor number for another entity, such as the PBM, in relatedEntities[].pharmacyProcessorNumber on any benefit entry.
Crossover coverage
Crossover coverage is the process where a primary insurance payer (usually Medicare) automatically forwards claims and related information to a secondary payer (typically Medicaid or a supplemental private insurer) after processing. When there's crossover coverage, you won't need to manually resubmit claims to the secondary payer - it happens automatically.
When the patient has crossover coverage, the eligibility response may contain information about crossover carriers, such as their names and identifiers. However, don't automatically assume the responding payer forwards crossover claims to those payers.
Crossover carriers appear in a benefit's relatedEntities array. Check relatedEntities[].type for values such as PRIMARY_PAYER, SECONDARY_PAYER, or ORIGIN_CARRIER.
The following example shows a patient with secondary coverage through a payer called Acme Secondary Health Plan.
"plans": [
{
"benefits": {
"statuses": [
{
"status": "ACTIVE_COVERAGE",
"coverageLevel": "INDIVIDUAL",
"service": {
"system": "STC",
"value": "30",
"definition": "Health Benefit Plan Coverage"
},
"relatedEntities": [
{
"type": "SECONDARY_PAYER",
"name": { "organization": "Acme Secondary Health Plan" },
"address": {
"addressLine1": "1 Acme Way",
"city": "Anytown",
"state": "CA",
"postalCode": "12345"
},
"contacts": [
{
"phoneNumbers": ["1234567890"]
}
]
}
]
}
]
}
}
]To determine whether a claim went to a crossover carrier, review the 835 Electronic Remittance Advice (ERA). Visit crossover claims for more details.