Changelog

Eligibility and claim status checks now fill in missing provider names

Stedi has made the provider name (first and last name, or organization name) optional in the following endpoints:

• Real-Time Eligibility Check JSON
• Real-Time Eligibility Check JSON (legacy)
• Real-Time Eligibility Check Raw X12
• Real-Time Eligibility Check SOAP
• Batch Eligibility Check JSON
• Real-Time Claim Status JSON
• Real-Time Claim Status Raw X12

If you leave the provider name out, Stedi fills it in from the provider's National Plan and Provider Enumeration System (NPPES) record.

Why the provider name matters

In eligibility and claim status checks, most payers use only the National Provider Identifier (NPI) and ignore the provider name. But Stedi has observed that some payers respond differently based on the provider name. If the name doesn't match the one in their backend system, they can return different benefits and claim status information.

For example, an eligibility check for NPI 1999999984 uses the name ACME Health Services. But some payers have the name ACME Health Services, Inc. in their backend system. Certain payers will return a limited set of benefits. If they include network status, they can even return the incorrect status for a given NPI.

Most payers use NPPES as the source of truth for provider names. As such, we recommend that you omit the provider name and let Stedi fill it in from NPPES. Only include the name if you believe the name in the payer's backend system is different from the name in NPPES. We don't recommend sending placeholder values like PROVIDER.

How it works

When the last name or organization name is missing, Stedi looks up the provider's NPI in NPPES. If the NPI has an active NPPES record, Stedi uses the record's primary name, which depends on the NPI type:

• Individual (Type 1) NPIs – The last name, plus the first name, middle name, and suffix when the record has them.
• Organization (Type 2) NPIs – The organization name.

Stedi also sets the entity type – individual or organization – to match the record. It doesn't use other names on the record, such as a doing business as (DBA) name. If the NPPES name is too long for the payer's transaction, Stedi shortens it. If Stedi can't get a name from NPPES, it uses PROVIDER.

If you include a provider name, Stedi doesn't replace it. This includes placeholders, such as PROVIDER, and names that don't match NPPES. We made this optional instead of replacing names because payers can theoretically use their own name records instead of NPPES. We haven't identified specific payers that do this. But we don't want to negatively affect requests where you chose a non-NPPES name intentionally.

This new functionality doesn't add transaction latency. Stedi performs all NPPES lookups locally in its own copy of the NPPES database. NPPES updates are released weekly. So name changes in NPPES will take up to one week to update in Stedi's copy.

For more information, see Provider name in our docs.

Filter claims by who rejected them in the Stedi portal

You can now filter claims in the Stedi portal's claims view by who rejected them – Stedi or the payer.

Previously, the Status filter had one Rejected option. Now you can expand Rejected and select By Stedi or By payer.

This lets you handle each type of rejection separately. For example, you can combine By payer with the Payer filter to review one payer's rejections. You can also review By Stedi rejections over a date range to find recurring errors.

A Stedi rejection happens before Stedi sends the claim to the payer. A payer rejection happens before adjudication. It can happen even after the payer acknowledges receipt.

For more information, see our filter claims docs.

Claim edit: Multiple prior authorization or referral numbers on a service line

Stedi now rejects 837P professional and 837D dental claims that report more than one prior authorization number or referral number on a service line for the payer you're sending the claim to.

Service line prior authorization and referral numbers

A prior authorization is the payer's approval of a service before the provider performs it. A referral is a provider's recommendation that the patient see another provider. Some plans, such as HMOs, require a referral before they cover a specialist visit. The payer assigns a number to each.

Service line prior authorization number

Service line referral number

How the edit works

Per X12 standards, a prior authorization or referral number without a payer identifier belongs to the payer you're sending the claim to. A service line can have only one of each for that payer.

To report another payer's prior authorization number, such as the primary payer's in a coordination of benefits (COB) claim, include that payer's identifier in otherPayerPrimaryIdentifier (REF-04 with qualifier 2U). In the CMS-1500 API, use otherPayerPrimaryId. The JSON API doesn't support payer identifiers for referral numbers, so report only one per service line.

If a service line reports more than one, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "description": "Invalid Prior Authorization Number. Only one prior authorization number for the destination payer is allowed per service line. Other payers' numbers need a payer identifier (2U). Line 1 reports 2 without one. Correct and resubmit."
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Prior Authorization Number. Only one prior authorization number for the destination payer is allowed per service line. Other payers' numbers need a payer identifier (2U). Line 1 reports 2 without one. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Referral Number. Only one referral number for the destination payer is allowed per service line. For other payers' numbers, include the payer identifier (2U). Line 1 reports 2 without one. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A7>252>HK**U*******A8>247**Invalid Prior Authorization Number. Only one prior authorization number for the destination payer is allowed per service line. Other payers' numbers need a payer identifier (2U). Line 1 reports 2 without one. Correct and resubmit.~

STC*A7>761>HK**U*******A8>247**Invalid Referral Number. Only one referral number for the destination payer is allowed per service line. For other payers' numbers, include the payer identifier (2U). Line 1 reports 2 without one. Correct and resubmit.~

Related claim edits

Stedi has other edits for service line prior authorization and referral numbers. See Prior authorization number matches the referral number and Service-line referral number without a claim-level referral number.

Introducing the Billing member role

You can now assign the Billing role to members of your Stedi account.

Previously, a member needed the Admin role to manage billing. That role also gives access to transactions, which contain protected health information (PHI).

Now, finance and billing staff can manage billing without access to PHI.

Billing members can:

• View and pay invoices
• Replace the payment method
• Edit billing details and billing email addresses
• Add prepaid credits with a manual top-up
• Get billing and payment notifications

Billing members can't change the pricing plan. They also can't access transactions, API keys, members, or other settings.

Each member has one role, so a member who needs billing access and access to other resources needs the Admin role. An account can have up to 5 billing members, including pending invitations.

Admins can assign the Billing role from the Members page in your account settings.

For more information, see our member roles docs.

Eligibility PDFs are now available within milliseconds

Stedi's eligibility PDFs are now typically available within milliseconds after an eligibility check completes. A small number of PDFs take slightly more than one second.

Previously, a PDF became available 4-20 seconds after the check, requiring users to add a delay before attempting to retrieve the PDF.

You can now call the Retrieve Eligibility PDF API endpoint as soon as you get the eligibility check response. The endpoint returns an HTTP 404 error until the PDF is available.

The endpoint and the PDFs are unchanged. You don't need to update your integration.

Introducing real-time validation in Stedi's CMS-1500 form

Stedi's CMS-1500 form now checks your claim for errors as you fill it out, including errors that would fail Stedi's claim edits.

Previously, the form checked the claim only when you clicked Submit claim. If the claim failed a claim edit, Stedi still created the claim and then rejected it with a 277CA claim acknowledgment.

Now, Stedi shows errors when you leave each box. It doesn't submit the claim until you fix every error. When you resubmit a claim using the form, Stedi shows its existing errors, including failed claim edits, as soon as the form opens.

Real-time validation also works when you use the CMS-1500 form in test mode.

For more details, see our announcement blog.

Claim edit: Invalid remark code in COB claims

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that report an invalid remark code from a previous payer.

Remark codes in COB claims

When a patient has more than one insurance plan, say a child covered by both parents' health insurance, claims go to the primary payer first, then the secondary, and so on. This is called coordination of benefits (COB).

Claims sent to non-primary payers can include the Remittance Advice Remark Codes (RARCs) from a previous payer's explanation of benefits (EOB) or Electronic Remittance Advice (ERA). A remark code gives more detail about why that payer adjusted the claim's payment.

Outpatient adjudication remark codes

Inpatient adjudication remark codes

How the edit works

Each remark code must be a valid RARC and active on the date the previous payer adjudicated the claim. If it isn't, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Claim Payment Remark Code (RARC). Other payer 60054, payer responsibility P, reported code(s) ZZ99 that are not in the X12 remittance advice remark code list. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Expired Claim Payment Remark Code (RARC). Other payer 60054, payer responsibility P, reported code(s) M33 (2004-07-31) that expired before the 2024-03-15 adjudication. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Claim Payment Remark Code (RARC) Not Yet Effective. Other payer 60054, payer responsibility P, reported code(s) N905 (2025-03-01) that took effect after the 2024-03-15 adjudication. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A7>634>GB*[DATE]*U*[AMOUNT]********Invalid Claim Payment Remark Code (RARC). Other payer 60054, payer responsibility P, reported code(s) ZZ99 that are not in the X12 remittance advice remark code list. Correct and resubmit.~

STC*A7>634>GB*[DATE]*U*[AMOUNT]********Expired Claim Payment Remark Code (RARC). Other payer 60054, payer responsibility P, reported code(s) M33 (2004-07-31) that expired before the 2024-03-15 adjudication. Correct and resubmit.~

STC*A7>634>GB*[DATE]*U*[AMOUNT]********Claim Payment Remark Code (RARC) Not Yet Effective. Other payer 60054, payer responsibility P, reported code(s) N905 (2025-03-01) that took effect after the 2024-03-15 adjudication. Correct and resubmit.~

Related claim edits

Stedi has another edit for COB claims without the previous payer's adjudication date. See Missing other payer adjudication date in COB claims.

Claim edit: Attachment control number for an attachment available on request

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include an attachment control number for an attachment that's only available on request.

Attachment transmission codes and control numbers

A claim can reference attachments, such as X-rays or treatment plans. The attachment transmission code says how the provider sends each attachment to the payer. The AA (Available on Request at Provider Site) code means the provider doesn't send it. The payer must ask for it.

Attachment transmission code

The attachment control number lets the payer match an attachment to the claim.

Attachment control number

How the edit works

An attachment that's only available on request has nothing for the payer to match. X12 HIPAA standards say to leave out the attachment control number in this case. If the claim includes one, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Attachment Control Number. When the attachment transmission code is 'AA' (Available on Request at Provider Site) the attachment control number must not be submitted. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A7>489*[DATE]*U*[AMOUNT]******A7>732**Invalid Attachment Control Number. When the attachment transmission code is 'AA' (Available on Request at Provider Site) the attachment control number must not be submitted. Correct and resubmit.~

Related claim edits

Stedi has another edit for attachments the provider sends without an attachment control number. See Missing attachment control number.

Claim edit: Missing ambulance transport information

Stedi now rejects 837P professional claims for ambulance services that don't include ambulance transport information.

Place of service and ambulance transport information

A place of service code of 41 (Ambulance – Land) or 42 (Ambulance – Air or Water) marks an ambulance claim.

Place of service code

An ambulance procedure code identifies the service, but not the details of the transport. Ambulance transport information gives the reason for the transport and the distance. Payers use these details to evaluate coverage, medical necessity, and payment.

Ambulance transport information

How the edit works

X12 standards require ambulance claims to include ambulance transport information at the claim level. Ambulance transport information on a service line doesn't replace it. If an ambulance claim omits the claim-level information, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "description": "Missing Ambulance Transport Information. When a claim indicates ambulance services (POS 41, 42), the ambulance transport information segment (CR1) is required. Correct and resubmit."
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Ambulance Transport Information. When a claim indicates ambulance services (POS 41, 42), the ambulance transport information segment (CR1) is required. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A6>428*[DATE]*U*[AMOUNT]********Missing Ambulance Transport Information. When a claim indicates ambulance services (POS 41, 42), the ambulance transport information segment (CR1) is required. Correct and resubmit.~

Claim edit: Missing CLIA number for a lab test

Stedi now rejects 837P professional claims that bill a lab test without a Clinical Laboratory Improvement Amendments (CLIA) number.

Lab tests and CLIA numbers

A CLIA number identifies a lab that's certified to test human specimens. Payers require the number on claims that bill lab tests.

A service line reports the lab test as a procedure code.

Procedure code

You can report the CLIA number at the claim level or on individual service lines.

Claim-level CLIA number

Line-level CLIA number

How the edit works

The Centers for Medicare & Medicaid Services (CMS) lists lab test procedure codes in the Clinical Laboratory Fee Schedule (CLFS). Stedi checks each service line's procedure code against the CLFS for the line's service date.

If a line bills a lab test and has no CLIA number at either level, the payer may reject the claim. CLIA-waived tests still need a CLIA number.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "description": "Missing CLIA Number. A Laboratory Test was billed on line 1, 87811, which requires a Clinical Laboratory Improvement Amendment (CLIA) number. This can be included at the claim or line-level. Correct and resubmit."
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Missing CLIA Number. A Laboratory Test was billed on line 1, 87811, which requires a Clinical Laboratory Improvement Amendment (CLIA) number. This can be included at the claim or line-level. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A6>544**U*********Missing CLIA Number. A Laboratory Test was billed on line 1, 87811, which requires a Clinical Laboratory Improvement Amendment (CLIA) number. This can be included at the claim or line-level. Correct and resubmit.~

Related claim edits

Stedi has another edit for CLIA numbers in an invalid format. See Invalid CLIA number format.

Claim edit: Accident date after the service date

Stedi now rejects 837P professional and 837D dental claims where the accident date is after a service date.

Accident and service dates

The accident date is the date the injury occurred. You report it when a claim relates to an accident.

Accident date

The service date is the date the provider performed the service. You report it on each service line.

Service date

In dental claims, the service-line service date is optional. When a service line omits it, the claim-level service date in claimInformation.claimDateInformation.serviceDate (DTP-03 of Loop 2300) applies.

How the edit works

An accident date ties the claim's services to that accident. A service before the accident can't result from it. If the accident date is after a service date, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "description": "Invalid Accident Date. The accident date must be on or before the service date. The submitted accident date, 20240305, is after the service date, 20240301 on line 1. Correct and resubmit."
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Accident Date. The accident date must be on or before the service date. The submitted accident date, 20240305, is after the service date, 20240301 on line 1. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A7>727*[DATE]*U*[AMOUNT]******A8>187**Invalid Accident Date. The accident date must be on or before the service date. The submitted accident date, 20240305, is after the service date, 20240301 on line 1. Correct and resubmit.~

Related claim edits

Stedi has another edit for accident-related claims without an accident date. See Missing accident date.

Claim edit: Mismatched DME procedure code on a service line

Stedi now rejects 837P professional claims with a service line where the durable medical equipment (DME) procedure code doesn't match the line's procedure code.

How the edit works

DME is equipment a patient uses at home over time, such as a wheelchair or an oxygen concentrator.

A service line can report a procedure code in two places:

• SV1-01-02 (Procedure Code) of Loop 2400 (Service Line Number) – the code for the billed service
• SV5-01-02 (Procedure Code) of Loop 2400 (Service Line Number) – the code for the DME

X12 standards require the two codes to match. If they differ, the payer may reject the claim.

The JSON Professional Claims endpoint doesn't accept a separate DME procedure code. The edit applies only to claims you submit as raw X12 or through SFTP.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Durable Medical Equipment procedure code. The DME procedure code must match the service procedure code on the same line. Line 1 reports DME code 99901 against procedure code 80369. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A7>454**U*******A8>490**Invalid Durable Medical Equipment procedure code. The DME procedure code must match the service procedure code on the same line. Line 1 reports DME code 99901 against procedure code 80369. Correct and resubmit.~

Claim edit: Missing DME certification revision date

Stedi now rejects 837P professional claims that renew or revise a durable medical equipment (DME) certification without a certification revision date.

DME certifications and revision dates

A DME certification is the provider's statement that a piece of equipment, such as a wheelchair, is medically necessary. The certification type code tells the payer whether the certification is I (Initial), R (Renewal), or S (Revised).

Certification type code

The certification revision date tells the payer when a change to the patient's certified DME needs took effect. This helps the payer confirm medical necessity.

Certification revision date

How the edit works

HIPAA standards require a certification revision date when the certification type code is R or S. If a service line omits the date, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Certification Revision/Recertification Date. The certification on line 1 is a renewal (type R) or revision (type S), but the required certification revision/recertification date is missing. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A6>335**U*********Missing Certification Revision/Recertification Date. The certification on line 1 is a renewal (type R) or revision (type S), but the required certification revision/recertification date is missing. Correct and resubmit.~

Introducing global search in the Stedi portal

You can now find records and open pages from one search field in the Stedi portal.

Previously, the find-by-ID search only opened a record from its exact ID. To find records by other values, like an NPI, you filtered each list page. Now, one search checks those filters across your list pages at once.

To open the search, press Cmd+K on Mac or Ctrl+K on Windows. You can also click the search field under the account menu in the sidebar.

You can type a page name to go to that page. For example, new check opens the form for a new eligibility check. You can also paste a record ID to search for that record.

To search records, type a value like a provider's NPI. The search shows how many records match in each product your account can use, such as claims, ERAs, or eligibility checks. Each result opens the list page with that filter applied.

You can search these records:

• Eligibility checks – Member ID or provider NPI
• Eligibility searches – Provider NPI
• Claims – Patient Control Number (PCN), patient name, member ID, or billing provider NPI or tax ID
• ERAs – Trace number, PCN, or payee name, NPI, or tax ID
• Payments – ACH trace number, reassociation trace number, or check number
• Enrollments – Enrollment ID, provider NPI or tax ID, payer name or ID, or user email
• Transactions – Words in the content or control numbers (transaction or functional group)

Most searches need the whole value, like a full NPI or member ID. Eligibility check and eligibility search results only cover the last month. To find older results, adjust the date filter on the list page.

For more information about each list page's filters, see our claims view and eligibility views docs.

Introducing the redesigned insurance discovery detail page

Insurance discovery checks you submit in the Stedi portal now show their results on a redesigned detail page.

Previously, the detail page listed coverages in the order they were discovered and showed benefits as a static list.

Now, the page uses the same structure as the redesigned eligibility check view. The redesign includes:

• Coverage status – A banner at the top of each coverage shows its number and status.
• Filterable benefits table – Each coverage uses the benefits table and filters from eligibility checks, so you can narrow the list to the benefits you need.
• Active coverage first – The page opens on the first active coverage, when there is one.
• Coverage navigation – A dropdown in the header switches between coverages when the check finds more than one.

For more details, see our announcement blog.

Claim edit: Invalid claim frequency code

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims with a claim frequency code that isn't valid for the claim type.

Claim frequency codes

The claim frequency code tells the payer whether a claim is an original claim, a replacement, a void, or another type of submission.

Claim frequency code

The valid codes depend on the claim type:

• 837P professional and 837D dental claims – 1 (Original), 7 (Replacement of Prior Claim), or 8 (Void/Cancel of Prior Claim).
• 837I institutional claims – A National Uniform Billing Committee (NUBC) frequency code, such as 1 (Admit thru Discharge Claim), 7 (Replacement), or 8 (Void).

How the edit works

If a claim uses a code outside this set, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Claim Frequency Code. The submitted frequency code, 6, is not a recognized claim frequency code for this claim type. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A7>535*[DATE]*U*[AMOUNT]********Invalid Claim Frequency Code. The submitted frequency code, 6, is not a recognized claim frequency code for this claim type. Correct and resubmit.~

Related claim edits

Stedi has another edit for claim frequency codes that conflict with the patient status code. See Invalid claim frequency code and patient status code combination.

Claim edit: Missing billing provider taxonomy code in dental claims

Stedi now rejects 837D dental claims that are missing a billing provider taxonomy code when no rendering provider or assistant surgeon is reported.

How the edit works

A taxonomy code identifies a provider's type and specialty, such as general dentistry or orthodontics.

A dental claim can name a rendering provider or an assistant surgeon for the whole claim or for individual service lines. If the claim names neither at any level, the billing provider is the one who rendered the service. In that case, X12 standards require the claim to include the billing provider's taxonomy code.

Billing provider taxonomy code

If the billing provider taxonomy code is missing, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Billing Provider taxonomy code. This code is required when no rendering provider or assistant surgeon is reported. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A6>145>85**U*[AMOUNT]******A6>732~

Related claim edits

Stedi has other edits that check the taxonomy code when it's present. See:

• Invalid taxonomy code
• Taxonomy code not in the NUCC code set

Claim edit: Prior authorization number matches the referral number

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that report the same value for the prior authorization number and the referral number.

Prior authorizations and referrals

A prior authorization is the payer's approval of a service before the provider performs it. The payer assigns a number to each approval. You can report the prior authorization number at the claim level or on a service line.

Prior authorization number

Service line prior authorization number

A referral is a provider's recommendation that the patient can see another provider – for example, a primary care provider who sends the patient to a specialist. Some plans, such as HMOs, require a referral before they cover a specialist visit. Each referral has its own number.

Referral number

Service line referral number

How the edit works

A prior authorization and a referral are different approvals, so their numbers shouldn't match. If you submit a claim with the same value in both fields, the payer may reject the claim.

The edit compares the numbers at the claim level and on each service line. When a service line reports only one of the numbers, the edit compares it to the other number at the claim level. The comparison ignores letter case.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

How you get the error depends on how you submit the claim.

{
  "errors": [
    {
      "description": "Invalid Prior Authorization number. The prior authorization number, PA20261009, cannot be the same value as the referral number. Correct and resubmit."
    }
  ]
}

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Prior Authorization number. The prior authorization number, PA20261009, cannot be the same value as the referral number. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

STC*A8>761>QC*[DATE]*U*[AMOUNT]******A8>252>QC**Invalid Prior Authorization number. The prior authorization number, [PRIOR AUTHORIZATION NUMBER], cannot be the same value as the referral number. Correct and resubmit.~

Related claim edits

Stedi has another edit for service line referral numbers. See Service-line referral number without a claim-level referral number.

Claim edit: Service-line referral number without a claim-level referral number

Stedi now rejects 837P professional claims that report a referral number on a service line but not at the claim level.

Claim-level and service-line referral numbers

A referral number is the number a payer assigns when it approves a referral to another provider. For example, a payer may require a referral before a patient sees a specialist.

You can report the referral number at two levels. The claim-level referral number applies to every service line on the claim.

Claim-level referral number

A service-line referral number applies to a single service line.

Service-line referral number

How the edit works

Per HIPAA standards, the claim-level referral number applies to every service line. You can also report a referral number on a service line when it differs from the claim-level number. Without a claim-level referral number, there's nothing for the line to differ from.

If a claim reports a referral number on a service line but omits the claim-level referral number, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

If you submit a claim using Stedi's Claim Submission API endpoints and the claim fails the edit, you'll get back an error response in real time. The response includes details in the errors array.

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Line-Level Referral Number. The service-line referral number on line 1, REF789012, should not be submitted when a claim-level referral number is not present. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, entity identifier code, and error message.

STC*A7>247*[DATE]*U*[AMOUNT]******A7>761>QC**Invalid Line-Level Referral Number. The service-line referral number on line 1, REF789012, should not be submitted when a claim-level referral number is not present. Correct and resubmit.~

Related claim edits

Stedi has another edit for a referring provider on a service line without one at the claim level. See Missing claim-level referring provider.

Introducing the redesigned eligibility check view

You can now review an eligibility check's result, summary, and benefits on one page in the Stedi portal's checks view.

Previously, each check had separate Overview and Benefits tabs. Plan details and benefit-related entities were on the Overview tab, apart from the benefits they applied to.

Now, the benefits table is part of the Overview tab. The redesign includes:

• Status banner and summary – A banner at the top of the page shows the check's result, above a summary of the check's details.
• Plan details – Plan names, group numbers, plan numbers, and plan dates appear in the benefits table.
• Coverage statuses – Each status has its own Statuses row in the benefits table.
• Related entities column – Benefit-related entities have their own column in the benefits table.
• Benefits filters – The benefits table has 15 filters, up from 7.

For more details, see our announcement blog.