Changelog

Claim edit: Invalid NPI format

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain a National Provider Identifier (NPI) with an invalid format.

How the edit works

An NPI is a unique, 10-digit identifier assigned to every healthcare provider in the U.S.

HIPAA-adopted X12 standards require that all NPIs in a claim be 10 digits. If a claim includes an NPI that’s not 10 digits – such as an NPI that’s too short or too long – the payer may reject the claim. This can delay payment for the provider.

This edit – the industry term for an automated validation rule – catches the issue before the claim reaches the payer.

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 NPI. The Billing Provider NPI of 123456789 is invalid. The National Provider Identifier must be valid with 10 digits and no prefixes or dashes. 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>562>85*[DATE]*U*[AMOUNT]******A7>569>85**Invalid NPI. The Billing Provider NPI of 123456789 is invalid. The National Provider Identifier must be valid with 10 digits and no prefixes or dashes. Correct and resubmit.~

Tip: How to handle 15-digit NPIs

Some official NPI documentation references a 15-digit NPI format that includes a 5-digit card issuer prefix. Omit this card issuer prefix when submitting claims.

Introducing branded signup links for Stedi apps

Stedi app developers can now share a co-branded Stedi signup link with their providers.

The link takes providers through a streamlined signup flow that creates an integrated account – a Stedi account that’s linked to your app.

The signup page is branded with your app's name and logo.

Branded signup links for Stedi apps

To get the signup link for your Stedi app, contact us in your Slack or Microsoft Teams channel. You can also email us or use our contact form.

Create a Stedi app

Stedi apps are prebuilt integrations between your system and Stedi. After you publish your app to the Stedi app directory, your providers can install the app from within their Stedi accounts.

To get started, check out our developer docs or contact us.

Claim edit: Invalid NDC format

Stedi now rejects 837P professional and 837I institutional claims that contain a National Drug Code (NDC) with an invalid format.

How the edit works

National Drug Codes (NDCs) are unique identifiers for drugs or biologics regulated by the U.S. Food and Drug Administration (FDA).

A provider can list an NDC in one or more service lines of a claim to get paid for drugs administered during care.

Claim typeJSON API fieldX12 segment
837P professionalserviceLines[].drugIdentification.nationalDrugCodeLIN03 (National Drug Code) of a Loop 2410 (Drug Identification)
837I institutionalserviceLines[].drugIdentification.nationalDrugCodeLIN03 (National Drug Code) of a Loop 2410 (Drug Identification)

Payers use NDCs in claims to determine the correct reimbursement amount for these drugs or to apply drug rebates.

HIPAA-adopted X12 standards require that all NDCs in a claim be 11 digits. If a claim includes an NDC that’s not 11 digits – such as an NDC that’s too short or too long – the payer may reject the claim. This can delay payment for the provider.

This edit – the industry term for an automated validation rule – catches the issue before the claim reaches the payer.

Rejection errors

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

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid National Drug Code (NDC). Service line 1 contains an invalid NDC value: 0002606351. NDCs must be 11-digits without any spaces or hyphens and valid per FDA records. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

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

STC*A7>218*[DATE]*U*[AMOUNT]********Invalid National Drug Code (NDC). Service line 1 contains an invalid NDC value: 0002606351. NDCs must be 11-digits without any spaces or hyphens and valid per FDA records. Correct and resubmit.~

Tip: How to handle 10-digit NDCs

The FDA has previously published 10-digit NDCs. X12 standards still require these NDCs to be 11 digits in claims.

Regardless of length, all NDCs have three segments: a labeler, a product, and a package code. In 11-digit NDCs, these segments must be 5, 4, and 2 digits respectively.

To convert a 10-digit NDC to an 11-digit NDC, add a leading zero to whichever segment is short.

Example 10-digit NDC11-digit version of the NDC
0002-3227-0100002-3227-01
00002-327-0100002-0327-01
00002-3227-100002-3227-01

Claim edit: Invalid Social Security Number

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain an invalid Social Security Number (SSN).

How the edit works

SSNs can only contain 9 digits. If a claim contains an invalid SSN – one longer or shorter than 9 digits – the payer may reject the claim, which can delay payment for the provider.

This edit – the industry term for an automated validation rule – catches invalid SSNs before the claim reaches the payer.

Rejection errors

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

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Social Security Number. The submitted social security number does not meet the required format of 9 digits with no separators. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails the edit using SFTP, 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>148>HK*[DATE]*U*[AMOUNT]********Invalid Social Security Number. The submitted social security number does not meet the required format of 9 digits with no separators. Correct and resubmit.~

Introducing automatic transaction enrollment requests for Highmark payers

Stedi now supports automatic transaction enrollment requests for eligibility checks with the following payers:

These payers require you to complete transaction enrollment for the provider to run eligibility checks.

If Stedi receives an AAA error indicating the provider isn't enrolled with the payer, we now automatically create an enrollment request.

Once the enrollment is live, the provider can successfully run eligibility checks with that payer.

You can track and manage these enrollment requests using Stedi's Enrollments API or the Stedi portal.

For more details, check out our Transaction enrollment docs.

Introducing automatic transaction enrollment requests for MBI lookups with SSN

Stedi now supports automatic transaction enrollment requests for MBI lookups with a Social Security Number (SSN).

What’s an MBI lookup?

A Medicare Beneficiary Identifier (MBI) is a unique ID for a Medicare beneficiary.

You need an MBI to run Medicare eligibility checks.

If you don’t have the patient’s MBI, you can get it using an MBI lookup with the patient’s demographic details and, optionally, their SSN.

What’s changing

To run MBI lookups with an SSN, you must complete transaction enrollment for the provider with the MBILU payer.

If Stedi receives an AAA error indicating the provider isn't enrolled with the payer, we now automatically create an enrollment request.

You can track and manage these enrollment requests using Stedi's Enrollments API or the Stedi portal.

Note: Automatic enrollment requests are not yet supported for the MBILUNOSSN (MBI lookup without SSN) payer.

For more details, check out our Transaction enrollment docs.

Introducing idempotency keys for Stedi’s Claim Submission API

Stedi’s Claim Submission API now supports an Idempotency-Key request header. The header is available for the following endpoints:

  • 837P Professional Claims – JSON and X12

  • 837D Dental Claims – JSON and X12

  • 837I Institutional Claims – JSON and X12

We strongly recommend including an idempotency key with every claim submission request.

Idempotency keys let you safely retry a failed request. If a claim submission fails mid-flight due to a network error or timeout, resend it with the same key to avoid creating a duplicate claim. You can reuse the same key for up to 24 hours after the original request.

For more details, see our API reference.

Introducing warnings for unsupported SFTP transactions

The Stedi portal’s Transactions page now displays a warning when unsupported X12 transactions are submitted or received over SFTP.

If you use Stedi’s healthcare clearinghouse, your Stedi SFTP connection supports the following transactions:

Supported outbound

Supported inbound

Unsupported SFTP transactions

Other X12 transactions aren’t supported over SFTP, including:

  • 270/271 Eligibility checks

  • 276/277 Real-time claim status checks

To run these transactions, use the Stedi portal or the respective APIs:

Previously, unsupported transactions appeared on the Transactions page without any indication that they weren’t delivered. Now, a warning indicates they weren’t processed or sent to the payer.

CMS now requires attestation for Medicare eligibility checks

To run Medicare eligibility checks with CMS, providers must complete an attestation by May 11, 2026.

Without attestation, CMS will reject Medicare eligibility requests for the provider starting on or after May 11, 2026.

What's changing

The Centers for Medicare and Medicaid Services (CMS) now requires providers to attest that clearinghouses – like Stedi – are allowed to run Medicare eligibility checks on their behalf. CMS also refers to this attestation as HETS EDI Enrollment.

This applies to all CMS trading partners, not just Stedi.

Stedi is updating new and existing CMS eligibility enrollments to include a required attestation step.

To avoid disruption to Medicare eligibility checks, attestation must be completed by May 11, 2026.

Important: The requirement doesn’t apply to:

  • Medicare Advantage, also called Medicare Part C

  • Medicare Part D

Existing enrollments

On February 17, 2026, Stedi moved any existing CMS eligibility check enrollments without an attestation to an enrollment status of PROVIDER_ACTION_REQUIRED. These enrollments now include a task with instructions to complete attestation.

Stedi also sent a notification email to the address in the enrollment's userEmail field (called Person for Stedi to contact in the Stedi portal). The email includes a link to the enrollment.

After the provider completes attestation and you mark the related enrollment task as complete, Stedi will move the CMS enrollment to the LIVE status.

How to find affected enrollments

To view these enrollments in the Stedi portal, filter for a Status of Provider Action Required and Transaction of Real-time eligibility checks (270/271) on the Enrollments page:

Enrollment filters

You can also retrieve the enrollments using the following query parameters for the List Enrollments API endpoint:

curl --request GET \
  --url "https://enrollments.us.stedi.com/2024-09-01/enrollments?status=PROVIDER_ACTION_REQUIRED&transactions=eligibilityCheck" \
  --header "Authorization: <api_key>"

New enrollments

Starting February 16, 2026, new CMS eligibility check enrollments will require attestation. The process works as follows:

  1. When you submit a CMS eligibility check enrollment request, Stedi moves the enrollment to the PROVIDER_ACTION_REQUIRED status and adds an enrollment task to complete attestation.

  2. After the provider completes attestation and you mark the related enrollment task as complete, Stedi moves the enrollment to the LIVE status.

    Note: Once attestation is complete, you can run CMS eligibility checks immediately, even if the enrollment status is not yet LIVE.

Automatic enrollment requests for CMS

If a CMS eligibility check returns AAA error 41 (Authorization/Access Restrictions), indicating the provider is not enrolled for eligibility checks with CMS, Stedi automatically submits a CMS eligibility enrollment request for that provider.

Starting February 16, 2026, these automatic enrollment requests will follow the process for new CMS eligibility enrollments described above and require provider attestation. Previously, Stedi completed these enrollments without requiring provider action.

This feature was previously called “automatic enrollment.” We're now calling it “automatic enrollment requests.”

How to complete attestation

Attestation must be completed for each billing National Provider Identifier (NPI) enrolled with CMS for eligibility checks. There is no bulk attestation across NPIs.

Stedi can't complete this step on the provider’s behalf.

Stedi provides a task and instructions for completing the CMS attestation in:

You can also view the instructions in our Transaction Enrollments Hub.

How long does attestation take?

Attestation takes approximately 5-15 minutes to complete per NPI.

Timing

CMS has stated they'll enforce attestation requirements on May 11, 2026.

When enforcement begins, CMS will return AAA error 41 (Authorization/Access Restrictions) for Medicare eligibility checks with an NPI that has not completed attestation.

Until then, Medicare eligibility checks will continue to work as normal.

Support

If you have questions or concerns, contact us using your dedicated support channel or our contact form.