Stedi home page
Docs

Provider network status, authorizations, referrals

You have a few options for determining whether the requesting provider is in- or out-of-network for the patient. The most reliable method is contacting the payer or provider directly.

You can also use the benefit entries in the eligibility response to determine whether prior authorization or a referral is required for requested services.

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 arrayEndpoints
plansReal-Time Eligibility Check JSON
benefitsInformationBatch 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.

Is the provider in- or out-of-network?

Unfortunately, you can't reliably determine whether the requesting provider is in- or out-of-network from a standard eligibility response.

Payers typically don't indicate it explicitly, though there are some exceptions. You also can't use the network indicator for this purpose. It indicates whether the specific benefit type applies to in- versus out-of-network, not the requesting provider.

The most 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.

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:

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 most 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 freeform messages typically arrive in the benefit entry's messages array for the plans shape, or in benefitsInformation[].additionalInformation[].description for the benefitsInformation shape. For example:

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

These messages 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.

In Plan Network Indicator

The X12 EDI 271 eligibility response includes a data element called EB12 (In Plan Network Indicator). Both response shapes surface this element, under different property names.

Counterintuitively, this value doesn't indicate whether the provider is in- or out-of-network for the patient's health plan. It specifies whether the specific benefit type applies to in- versus out-of-network. 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.

Stedi represents this element as the network.indicator property on each benefit entry. The property contains one of the following values:

  • IN_NETWORK
  • OUT_OF_NETWORK
  • IN_AND_OUT_OF_NETWORK - The benefit applies to both in- and out-of-network providers.

Payers sometimes send other values, most commonly U (unknown). Stedi passes these through as-is, so you can receive a network.indicator of U, which means it's unknown whether the benefit applies to in- or out-of-network providers.

The following example shows the patient's out-of-network deductible for the calendar year, which is $7,500. The network.indicator of OUT_OF_NETWORK indicates that the deductible applies to services performed by providers outside the patient's network.

"plans": [
  {
    "benefits": {
      "deductible": [
        {
          "amount": "7500",
          "coverageLevel": "INDIVIDUAL",
          "service": {
            "system": "STC",
            "value": "30",
            "definition": "Health Benefit Plan Coverage"
          },
          "network": { "indicator": "OUT_OF_NETWORK" },
          "timePeriod": "CALENDAR_YEAR"
        }
      ]
    }
  }
]

Is prior authorization required?

Prior authorization (also called pre-authorization or pre-certification) is a requirement that the patient or their provider must get approval before a payer will cover specific services, procedures, medications, or devices. Without it, the payer may deny claims.

For example, some payers require prior authorization for:

  • Elective surgeries, such as joint replacements
  • Advanced imaging, such as MRIs or CT scans
  • Step therapy, where a patient must try lower-cost treatments before the payer approves a higher-cost one

Payers indicate whether prior authorization is required for the service type code in the eligibility check. They sometimes send a value meaning the requirement is unknown, most commonly U. Learn more about unknown prior authorization requirements.

Each benefit entry's priorAuthIndicator property contains one of the following values:

  • REQUIRED indicates that prior authorization is required.
  • NOT_REQUIRED indicates that prior authorization is not required.

Payers sometimes send other values, most commonly U (unknown). Stedi passes these through as-is, so you can receive a priorAuthIndicator of U.

If you don't receive the priorAuthIndicator property in the response, you can assume that prior authorization is not required.

The following example shows that prior authorization is required for anesthesia services.

"plans": [
  {
    "benefits": {
      "coInsurance": [
        {
          "percent": "0.2",
          "coverageLevel": "INDIVIDUAL",
          "service": {
            "system": "STC",
            "value": "7",
            "definition": "Anesthesia"
          },
          "timePeriod": "CALENDAR_YEAR",
          "priorAuthIndicator": "REQUIRED"
        }
      ]
    }
  }
]

Authorization notes

Some payers send additional notes about prior authorization rules in their freeform messages. They sometimes send these notes on a separate entry, typically a coverage status, coverage basis, or benefit description type.

Look for these notes in the benefit entry's messages array. When the payer sends them on a separate entry, that entry appears in the statuses, coverageBasis, or benefitDescription array.

The following example shows a coverageBasis entry containing additional information about prior authorization requirements for imaging services.

"plans": [
  {
    "benefits": {
      "coverageBasis": [
        {
          "coverageLevel": "INDIVIDUAL",
          "network": { "indicator": "IN_AND_OUT_OF_NETWORK" },
          "messages": ["PRECERTIFICATION REQUIRED FOR PET SCANS, CT/CTA SCANS, MRI/MRA SCANS."]
        }
      ]
    }
  }
]

Handling U (unknown)

Both response shapes surface U, in priorAuthIndicator for the plans shape and in authOrCertIndicator for the benefitsInformation shape. Handle it the same way in both.

When either property is U (unknown), it means the payer can't determine in real time whether prior authorization is required for the service. The payer may require additional details, like diagnosis or place of service, that you can't provide using an eligibility check.

In these cases, do the following:

  • Check the payer's freeform messages for any clarification on prior authorization requirements. These arrive in the benefit entry's messages array for the plans shape, or in benefitsInformation[].additionalInformation[].description for the benefitsInformation shape. Also check other benefit entries, which sometimes contain additional information.
  • Call the payer or use the payer's provider portal to see if you can get more information. You can use an AI voice agent or screen scraper to do this programmatically.
  • Use a third-party prior authorization platform. Stedi's Platform Partner directory includes trusted vendors that can help you get prior authorization details that aren't available through an eligibility check.
  • If your payer has implemented the HL7 Da Vinci Coverage Requirements Discovery (CRD) FHIR API, you can query it to determine whether a specific service requires prior authorization. For example, here's the link to Aetna's Prior Authorization APIs.

Gold carding

Some payers offer "gold carding" programs that let certain providers skip prior authorization requirements. In some cases, gold carding is required by state law.

Unfortunately, you can't reliably get a provider's gold card status from an eligibility response. If you think a provider may qualify, check directly with the payer or provider.

Prior authorization status

Payers typically don't indicate whether the requesting provider has obtained prior authorization for services that require it. Instead, they indicate whether prior authorization is required for a specific service type code (STC) or procedure code.

If you need to check the status of an existing prior authorization, contact the payer directly or use their provider portal if they have one.

Is a referral required?

A referral is a written or electronic authorization from a primary care provider (PCP) to see a specialist or receive certain services. Some health plans won't cover specialty care without a referral.

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 a payer includes this information, you can find it in their freeform messages: the benefit entry's messages array for the plans shape, or benefitsInformation[].additionalInformation[].description for the benefitsInformation shape. You're more likely to receive referral information for members with HMO plans.

Primary care provider (PCP)

A PCP is the main healthcare provider responsible for managing a patient's care and coordinating referrals to specialists. Some payers include the patient's PCP information in eligibility responses, but this is payer-dependent and not guaranteed.

When a payer returns PCP information, it appears on a benefit entry.

  • The entry appears in the plans[].benefits.primaryCareProvider array.
  • The PCP's details appear in a relatedEntities object with type set to PRIMARY_CARE_PROVIDER.
  • If the PCP is an individual, name.person contains their firstName and lastName. If the PCP is an organization, name.organization contains the organization name.

The following example shows that the patient's assigned PCP is an organization called Acme Physician Group.

"plans": [
  {
    "benefits": {
      "primaryCareProvider": [
        {
          "coverageLevel": "INDIVIDUAL",
          "service": {
            "system": "STC",
            "value": "30",
            "definition": "Health Benefit Plan Coverage"
          },
          "relatedEntities": [
            {
              "type": "PRIMARY_CARE_PROVIDER",
              "name": { "organization": "Acme Physician Group" }
            }
          ]
        }
      ]
    }
  }
]
Plan details
Patient responsibility

On this page

Response shapesIs the provider in- or out-of-network?Payer FHIR APIsAdditional network status detailsSelective inclusion of benefitsFreeform messagesIn Plan Network IndicatorIs prior authorization required?Authorization notesHandling U (unknown)Gold cardingPrior authorization statusIs a referral required?Primary care provider (PCP)