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 benefitsInformation objects in the eligibility response to determine whether prior authorization or a referral is required for requested services.

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

Unfortunately, you can't reliably answer this question from a standard eligibility response.

Payers typically don't explicitly indicate whether the requesting provider is in- or out-of-network for the patient (though there are some exceptions). You also can't use the inPlanNetworkIndicatorCode property for this purpose. The inPlanNetworkIndictorCode 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 types of freeform messages are typically included in the benefitsInformation.additionalInformation.description property. For example:

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

This description property 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). Stedi represents this field as the benefitsInformation.inPlanNetworkIndicatorCode property in the eligibility benefits response.

Counterintuitively, this value doesn't indicate whether the provider is in- or -out-of-network for the patient's health plan.

Instead, the InPlanNetworkIndicatorCode specifies whether the specific benefit type applies to in- vs. 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.

Payers can send the following inPlanNetworkIndicatorCode values:

Y - Yes
N - No
W - Not Applicable | This indicates that the benefit applies to both in and out-of-network providers.
U - Unknown | This indicates that it is unknown whether the benefits apply to in- or out-of-network providers.

The example benefitsInformation object below shows the patient's out-of-network deductible for the calendar year, which is $7,500 dollars. The inPlanNetworkIndicatorCode is N, indicating that the deductible is applicable to services performed by providers outside the patient's network.

{
  "code": "C",
  "name": "Deductible",
  "coverageLevelCode": "IND",
  "coverageLevel": "Individual",
  "serviceTypeCodes": ["30"],
  "serviceTypes": ["Health Benefit Plan Coverage"],
  "timeQualifierCode": "23",
  "timeQualifier": "Calendar Year",
  "benefitAmount": "7500",
  "inPlanNetworkIndicatorCode": "N",
  "inPlanNetworkIndicator": "No"
}

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 a higher-cost one is approved

Payers use the benefitsInformation.authOrCertIndicator property to indicate whether prior authorization is required for the service type code in the eligibility check. It can have the following values:

Y indicates that prior authorization is required.
N indicates that prior authorization is not required.
U indicates that the payer is unable to confirm whether or not prior authorization is required.

The following example benefitsInformation object shows that prior authorization is required for anesthesia services:

{
  "code": "A",
  "name": "Co-Insurance",
  "coverageLevelCode": "IND",
  "coverageLevel": "Individual",
  "serviceTypeCodes": ["7"],
  "serviceTypes": ["Anesthesia"],
  "timeQualifierCode": "23",
  "timeQualifier": "Calendar Year",
  "benefitPercent": ".20",
  "authOrCertIndicator": "Y"
}

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

Authorization notes

Some payers may send additional notes about prior authorization rules in the benefitsInformation.additionalInformation.description property. Payers may also send these notes in a separate benefitsInformation object, typically with a code of 1 (Active coverage), CB (Coverage Benefit), or D (Benefit Description).

The following example shows a separate benefitsInformation object containing additional information about prior authorization requirements for imaging services:

{
  "code": "CB",
  "name": "Coverage Basis",
  "coverageLevelCode": "IND",
  "coverageLevel": "Individual",
  "inPlanNetworkIndicatorCode": "W",
  "inPlanNetworkIndicator": "Not Applicable",
  "additionalInformation": [
    {
      "description": "PRECERTIFICATION REQUIRED FOR PET SCANS, CT/CTA SCANS, MRI/MRA SCANS."
    }
  ]
}

Handling `U` (unknown)

When the authOrCertIndicator 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 additionalInformation.description property for any clarification on prior authorization requirements. Also check for separate benefitsInformation objects that may contain description properties with 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.

Is a referral required?

A referral is a written or electronic authorization from a primary care physician (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 this information is included, you can find it in the benefitsInformation.additionalInformation.description property. You're more likely to receive referral information for members with HMO plans.

Provider network status, authorizations, referrals

On this page