Changelog

Medicaid Texas is now one-click enrollment

Medicaid Texas – CHIP (Payer ID: 10186) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

About one-click enrollment

Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollment for ERAs.

Transaction enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

With one-click transaction enrollment, you only need to submit an enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer supports one-click enrollment using the Stedi Payer Network or the Payer APIs.

UnitedHealthcare Community Plan is now one-click enrollment

Healthcare payer UnitedHealthcare Community Plan (Payer ID: 04567) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

About one-click enrollment

Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollment for ERAs.

Transaction enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

With one-click transaction enrollment, you only need to submit an enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer supports one-click enrollment using the Stedi Payer Network or the Payer APIs.

UPMC Health Plan is now one-click enrollment

Healthcare payer UPMC Health Plan (Payer ID: 23281) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

About one-click enrollment

Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollment for ERAs.

Transaction enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

With one-click transaction enrollment, you only need to submit an enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer supports one-click enrollment using the Stedi Payer Network or the Payer APIs.

Claim edit: Duplicate diagnosis codes

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain duplicate diagnosis codes.

How the edit works

A claim’s diagnosis codes describe what’s wrong with the patient. For example, in 837P professional or 837I institutional claims, M54.50 is the ICD-10-CM diagnosis code for “Low back pain, unspecified."

A claim can include multiple diagnosis codes, listed in order of importance. The primary diagnosis code is in position 1, the next is in position 2, and so on. All codes after position 1 make up the secondary diagnosis list.

Each diagnosis code on the claim must be unique. You can’t submit the same code twice.

Submitting the same diagnosis code more than once does not provide additional clinical information to the payer. It may lead to confusion during processing or review.

Diagnosis codes for 837P professional and 837D dental claims

For 837P professional and 837D dental claims, all diagnosis codes appear in the same array field. The first entry is the primary diagnosis. Subsequent entries are secondary diagnoses.

Diagnosis codes for 837I institutional claims

For 837I institutional claims, the primary and secondary diagnosis codes are in separate fields.

If a diagnosis code appears more than once in a claim, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which are slower and delay payment for the provider.

Rejection errors

This edit has two conditions, each producing a different error.

The primary diagnosis code appears in the secondary diagnosis list

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": "Duplicate Diagnosis Code. The primary diagnosis code, F329, must be unique and cannot also be reported in the secondary diagnosis list. 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, and error message.

STC*A7>254*[DATE]*U*[AMOUNT]********Duplicate Diagnosis Code. The primary diagnosis code, F329, must be unique and cannot also be reported in the secondary diagnosis list. Correct and resubmit.~

The same diagnosis code appears more than once among secondary diagnoses

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": "Duplicate Diagnosis Code. Diagnosis code(s) F329 are incorrectly duplicated. Diagnosis codes must be unique within the claim. 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, and error message.

STC*A7>255*[DATE]*U*[AMOUNT]********Duplicate Diagnosis Code. Diagnosis code(s) F329 are incorrectly duplicated. Diagnosis codes must be unique within the claim. Correct and resubmit.~

Tip: Update your diagnosis pointers

If you remove a duplicate diagnosis code in an 837P professional or 837D dental claim, update any diagnosis pointers on the claim's service lines to avoid mismatched pointers.

Diagnosis pointers link each service line of a claim to a diagnosis code. Diagnosis pointers are positional. Each pointer refers to the index position of a diagnosis code on the claim. For example:

• If a service line uses diagnosis pointer 2, it refers to the diagnosis code in position 2.

• If a service line uses diagnosis pointer 3, it refers to the diagnosis code in position 3.

Removing a code can shift the positions of remaining codes. This would make existing pointers incorrect and can result in payer rejections.

Diagnosis pointers

Claim edit: Missing insurance type code when Medicare is a non-primary payer

Stedi now rejects 837P professional and 837D dental claims where Medicare appears as a non-primary payer and the insurance type code is missing.

How the edit works

In coordination of benefits (COB) scenarios, a claim may list multiple payers. For example, a patient may have a commercial payer as their primary payer and Medicare as their secondary payer. You indicate whether a payer is primary, secondary, tertiary, and so on using a payment responsibility sequence number code, also called a payment responsibility level code.

Payment responsibility level

Any non-primary payers on a claim must have a claim filing indicator. The indicator tells you what type of payer or plan it is. For example, CI is for a commercial insurance company.

Claim filing indicator

If Medicare is a non-primary payer on the claim, the claim filing indicator must be MA (Medicare Part A) or MB (Medicare Part B). In these cases, an insurance type code is also required.

The insurance type code indicates why Medicare isn't the primary payer. For example, code 12 means the patient has an employer group health plan.

Insurance type code

If the insurance type 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 are slower 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": "Missing Insurance Type Code. This field is required when the claim filing indicator identifies Medicare and Medicare is not the primary payer. It is missing for the other subscriber (payer 06302, indicator MB). 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*A6>590>GB*[DATE]*U*[AMOUNT]******A8>480>GB**Missing Insurance Type Code. This field is required when the claim filing indicator identifies Medicare and Medicare is not the primary payer. It is missing for the other subscriber (payer 06302, indicator MB). Correct and resubmit.~

Introducing 999 acknowledgment settings for SFTP users

If you use Stedi’s SFTP server, you’ll now receive negative 999 Implementation Acknowledgments from Stedi for claims with invalid X12 syntax or implementation guide errors.

You can also opt in to receive positive 999 acknowledgments, which are returned for claims with valid X12 syntax.

You’ll receive 999 acknowledgments in the from-stedi directory for claims submitted through SFTP, the Claim Submission API, or the Stedi portal. The acknowledgments arrive within minutes of submission.

What is a 999 acknowledgment?

A 999 Implementation Acknowledgment is a standard X12 transaction set. It confirms whether a submitted functional group and its transaction sets use valid X12 syntax. It is not used for application-level validation.

Negative 999 acknowledgments

A negative 999 acknowledgment means Stedi rejected at least one transaction in the X12 file due to a structural error, such as a malformed segment or a missing required element. Rejected transactions are not further processed by Stedi or forwarded to the payer.

The AK9 (Functional Group Response) segment summarizes the result for the functional group. AK9-01 (Functional Group Acknowledge Code) is set to R if all transactions were rejected, or P if the group was partially accepted:

AK9*P*3*3*1~    ← Partially accepted: 3 transactions submitted, 3 received, 1 accepted (2 rejected)

For each rejected transaction, IK5-01 (Transaction Set Acknowledgment Code) is set to R. The IK3 (Error Identification) and IK4 (Implementation Data Element Note) segments identify where the error occurred. For example:

AK2*837*0002~      ← Responding to transaction 0002
IK3*CLM*22**8~     ← CLM segment at position 22 has element errors
IK4*2*782*1~       ← Element 2 is missing a mandatory value
IK5*R*5~           ← Transaction rejected

If you receive a negative 999, you must correct the errors and resubmit the claim.

Positive 999 acknowledgments

A positive 999 acknowledgment confirms that all transactions in a functional group were accepted for further processing. IK5-01 returns A (Accepted), and AK9 returns A (Accepted). For example:

AK2*837*0001~
IK5*A~           ← Transaction accepted
AK9*A*1*1*1~     ← All accepted: 1 transaction submitted, 1 received, 1 accepted

Interpreting 999 acknowledgments

For more tips on interpreting 999 acknowledgments, see our SFTP docs.

How to update your 999 acknowledgment settings

You can opt in to receive positive 999 acknowledgments using the Stedi portal:

1. Go to the SFTP setup page in your account settings.

2. Under 999 settings, select All 999s to receive 999 acknowledgments for every transaction. Leave the default to receive negative acknowledgments.

For more information, see our SFTP docs.

El Paso First Health Plans Premier Plan Star Medicaid HMO is now one-click enrollment

Healthcare payer El Paso First Health Plans Premier Plan Star Medicaid HMO (Payer ID: EPF02) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

About one-click enrollment

Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollment for ERAs.

Transaction enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

With one-click transaction enrollment, you only need to submit an enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer supports one-click enrollment using the Stedi Payer Network or the Payer APIs.

Claim edit: Invalid name for a non-person entity

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include a first name, middle name, or suffix for a non-person entity.

How the edit works

In a claim, each entity – such as the submitter or billing provider – is marked as either a person or a non-person. Non-person entities include hospitals, billing organizations, and similar groups.

In X12, the entity type is set using the NM1-02 qualifier: 1 for a person, 2 for a non-person entity.

For non-person entities, you should only provide an organization name. The organization name goes where the last name would for an individual. In X12, this is the NM1-03 element.

If a claim includes a non-person entity with a first name, middle name, or suffix, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which are slower 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 Name Elements. When the Billing Provider entity is not a person, as identified by the entity type qualifier 2, then the following name elements should not be submitted: [first name, middle name, suffix]. 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>505>85*[DATE]*U*[AMOUNT]*******Invalid Name Elements. When the Billing Provider entity is not a person, as identified by the entity type qualifier 2, then the following name elements should not be submitted: [first name, middle name, suffix]. Correct and resubmit.~

Independence Blue Cross is now one-click enrollment

Independence Blue Cross (Payer ID: 54704) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

What is transaction enrollment?

Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollments for ERAs.

You can submit and track enrollments using Stedi's transaction enrollment API, the Stedi portal, or a bulk CSV.

One-click enrollment

Enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

If a payer supports one-click enrollment, you only need to submit the enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer requires enrollment – and supports one-click enrollment – for ERAs and other transaction types using the Stedi Payer Network or the Payer APIs.

For details, see our transaction enrollment docs.

Inland Empire Health Plan is now one-click enrollment

Inland Empire Health Plan (Payer ID: IEHP1) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

What is transaction enrollment?

Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollments for ERAs.

You can submit and track enrollments using Stedi's transaction enrollment API, the Stedi portal, or a bulk CSV.

One-click enrollment

Enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

If a payer supports one-click enrollment, you only need to submit the enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer requires enrollment – and supports one-click enrollment – for ERAs and other transaction types using the Stedi Payer Network or the Payer APIs.

For details, see our transaction enrollment docs.

Sun Life is now one-click enrollment

Sun Life (Payer ID: 70408) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

What is transaction enrollment?

Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollments for ERAs.

You can submit and track enrollments using Stedi's transaction enrollment API, the Stedi portal, or a bulk CSV.

One-click enrollment

Enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

If a payer supports one-click enrollment, you only need to submit the enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer requires enrollment – and supports one-click enrollment – for ERAs and other transaction types using the Stedi Payer Network or the Payer APIs.

For details, see our transaction enrollment docs.

Claim edit: Invalid submitter ID

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims when the submitter ID doesn't match the payer's required format.

How the edit works

In a claim, the submitter ID tells the payer who submitted the claim.

This submitter isn't necessarily the provider who rendered care or is being paid for the claim. It could be a billing service or other vendor acting on the provider's behalf.

Payer-assigned submitter IDs

Most payers accept standard submitter IDs, such as an Employer Identification Number (EIN) or other Tax Identification Number (TIN).

Some payers, including some Medicare Administrative Contractors (MACs) and state Medicaid programs, require submitters to use a specific payer-assigned submitter ID instead.

Payer-assigned submitter IDs are issued during transaction enrollment and tend to follow payer-specific formats. For example, a required prefix followed by a fixed number of digits.

If you submit a claim to one of these payers and don’t use a payer-assigned submitter ID, 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.

The exact error message varies by payer and includes guidance on how to fix the submitter ID. For example:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Submitter Identifier. This payer requires a specific-assigned identifier that begins with AZ followed by 5 or 6 numbers. The submitted value 921545753 does not follow this format and must be confirmed with the payer. 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, and error message.

STC*A7>478*[DATE]*U*[AMOUNT]******A7>733>41**Invalid Submitter Identifier. This payer requires a specific-assigned identifier that begins with AZ followed by 5 or 6 numbers. The submitted value 921545753 does not follow this format and must be confirmed with the payer. Correct and resubmit.~

Claim edit: Invalid claim frequency code and patient status code combination

Stedi now rejects 837I institutional claims that contain a conflicting claim frequency code and patient status code combination.

How the edit works

In an institutional claim, the claim frequency code tells the payer whether a claim is an original claim, a correction, or part of an ongoing stay.

Claim frequency code

The claim’s patient status code describes the patient's condition at the end of the claim’s billed period. It tells the payer whether the patient was discharged, transferred, or still admitted.

Patient status code

The claim frequency code and patient status code must be compatible. For example, if a claim uses a claim frequency code of 1 (Admit thru Discharge Claim) – meaning the patient’s stay is finished – the patient status code shouldn’t be 30 (Still a Patient), which means the patient is still in the facility.

If the claim frequency code and patient status code are conflicting, the payer may reject the claim. That rejection can delay payment to 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 combination of claim frequency and patient status. The submitted patient status code 30 indicates the patient is still admitted, which conflicts with the claim frequency code 1 indicating a final bill. 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>535>QC*[DATE]*U*[AMOUNT]********Invalid combination of claim frequency and patient status. The submitted patient status code 30 indicates the patient is still admitted, which conflicts with the claim frequency code 1 indicating a final bill. Correct and resubmit.~

Claim edit: Invalid future dates

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain dates later than the claim’s transaction date.

How the edit works

Each claim includes a transaction date – the date the claim was submitted.

Providers always submit claims after care is provided. That means other dates in the claim, such as dates of service, statement periods, and accident dates, should always occur on or before the transaction date. Future dates indicate a data entry error.

If a claim contains a future date, the payer may reject the claim, which 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.

Dates covered by this edit

This edit validates date fields at the claim and service line level, including but not limited to:

• Dates of service

• Accident dates

• Initial treatment dates

• Prescription dates

• Last seen dates

• Discharge dates

This edit does not apply to dates of birth. Stedi validates those separately with the invalid date of birth edit.

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": "The submitted date(s) are invalid. The following dates cannot be later than the transaction date of 20260312: Service (20270101). 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, and error message.

STC*A8>510*[DATE]*U*[AMOUNT]******A7>727**The submitted date(s) are invalid. The following dates cannot be later than the transaction date of 20260312: Service (20270101). Correct and resubmit.~

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.

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

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.

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.

Introducing eligibility check PDFs

You can now download a PDF version of your eligibility checks using the Stedi portal or our new Retrieve Eligibility PDF API endpoint.

Eligibility check PDFs are designed to be easy to read, print, and upload to other systems. Their layout mirrors the Stedi portal's eligibility benefits table.

Download a sample PDF.

For details, see our announcement blog.

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:

• Highmark of Pennsylvania (Payer ID: 54771)

• Highmark Senior Health Company (Payer ID: 15460)

• Highmark Blue Cross Blue Shield of Delaware (Payer ID: 030)

• Highmark Blue Cross Blue Shield of West Virginia (Payer ID: 54828)

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.