Changelog

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain duplicate line item control numbers.

How the edit works

In a claim, a service line represents billing for one specific service, procedure, or supply – for example, an office visit or a dental filling. Each service line represents a separate billable event.

A line item control number is a provider-assigned identifier for a specific service line.

Within a claim, each service line must have a unique line item control number. Payers and providers use line item control numbers to track service lines across claim submissions, claim acknowledgments, and Electronic Remittance Advice (ERAs).

Payers may reject claims with duplicate line item control numbers, which can cause payment delays.

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

Where to find line item control numbers

• JSON API

  • Professional claims JSON endpoint: claimInformation.serviceLines.providerControlNumber

  • Dental claims JSON endpoint: claimInformation.serviceLines.providerControlNumber

  • Institutional claims JSON endpoint: claimInformation.serviceLines.lineItemControlNumber
    
    

• Raw X12
  REF-02 (Line Item Control Number) of Loop 2400 (Service Line Number)
  
  

• Stedi portal
  You can’t specify line item control numbers using the Stedi portal’s CMS-1500 professional claim form. Claims submitted through the form can’t fail this edit.

Rejection errors

If you submit a claim that fails the edit using Stedi’s claim submission APIs, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": Invalid Line-Item Control Numbers. Each line-item control number must be unique within the claim. Control numbers, 12345, 67890, have been used more than once. 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:N584*[DATE]*U*[AMOUNT]********Invalid Line-Item Control Numbers. Each line-item control number must be unique within the claim. Control numbers, 12345, 67890, have been used more than once. Correct and resubmit

You can now see which U.S. states and territories a payer operates in using the Stedi Payer Network website and the Payers API.

Stedi payer records now list the states or territories where the payer is known or expected to offer coverage, based on Stedi’s curated sources. If Stedi doesn’t know the payer’s operating states, they aren’t included in the record.

You can also filter by operating states when searching for payers.

Filter by operating state in the Stedi Payer Network

When you browse or search payers on the Payer Network, click + Operating States beside Filter by and select one or more states. The results will use AND logic to only show payers that operate in those states.

Each payer now lists its Operating States in the Payer pane. National payers – those who cover all U.S. states display NATIONAL. Regional payers list one or more U.S. state or territory codes, such as CA (California) or WA (Washington).

Operating states are also listed on the Payer page:

Operating states in the Payers API

All Payers API endpoints also now return an operatingStates array, if available, for payer records:

{
  "displayName": "Providence Health Plan",
  "primaryPayerId": "PHP01",
  "operatingStates": [
    "CA",
    "OR",
    "WA"
  ],
  ...
},

Payers that cover all U.S. states contain a single  NATIONAL value in the array:

{
  "displayName": "Cigna",
  "primaryPayerId": "62308",
  "operatingStates": [
    "NATIONAL"
  ],
  ...
}

Filter by operating state using the Payers API

You can also filter payers by operating state using the Search Payers endpoint’s new operatingStates query parameter.

The parameter expects exact matches and can accept multiple values. The endpoint uses AND logic to return the intersection of all filters.

For example, the following query returns only payers that operate in both CA (California) and WA (Washington):

curl --request GET \
  --url "https://healthcare.us.stedi.com/2024-04-01/payers?operatingStates=CA&operatingStates=WA" \
  --header "Authorization: <api_key>"

Stedi now rejects 837P professional claims when the MJ (minutes) unit of measurement code is used to incorrectly bill for anesthesia or non-anesthesia services.

In professional claims, the MJ unit of measurement code indicates a service was billed in minutes. While not a HIPAA mandate, it’s standard practice in the healthcare industry to bill for anesthesia services - but no other services – using MJ. Other services are billed using units, encounters, or time-based units – such as 15-minute increments – not raw minutes.

If MJ is used incorrectly, payers may reject the claim, which can lead to payment delays. This edit – the industry’s term for an automated validation rule – catches the issue before it reaches the payer.

When MJ must be used

If you submit a professional claim for anesthesia services that doesn't include the MJ unit of measurement code using Stedi’s 837P professional claim submission APIs or CMS-1500 professional claim form, you’ll get back an error message in real time. If you’re using the JSON API endpoint, the response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": Invalid Measurement Code for Anesthesia Procedure Code. 01001 is an Anesthesia service which must be reported in minutes (measurement code: MJ). Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

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

STC*A7:N659*[DATE]*U*[AMOUNT]********Invalid Measurement Code for Anesthesia Procedure Code. 01001 is an Anesthesia service which must be reported in minutes (measurement code: MJ). Correct and resubmit

When MJ must not be used

If you submit a professional claim for non-anesthesia services that includes the MJ unit of measurement code using Stedi’s 837P professional claim submission APIs or CMS-1500 professional claim form, you’ll get back an error message in real time. If you’re using the JSON API endpoint, the response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": Invalid Measurement Code for Procedure Code. Measurement Code MJ is not valid for 90837 as it should be only used code for Anesthesia services. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

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

STC*A7:N659*[DATE]*U*[AMOUNT]********Invalid Measurement Code for Procedure Code. Measurement Code MJ is not valid for 90837 as it should be only used code for Anesthesia services. Correct and resubmit

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims when a line item control number exceeds 30 characters.

The line item control number, also called the provider control number, is a provider-assigned identifier for each service line. Payers return this number on service lines in 277CA claim acknowledgments and 835 Electronic Remittance Advice (ERAs). Providers use it to track service lines across claim submissions, acknowledgments, and remittance files.

Line item control numbers are different from patient control numbers, which are used to track a claim as a whole.

HIPAA-adopted standards limit this line item control numbers to a maximum of 30 characters. If the value is too long, the payer may reject the claim, which can cause payment delays.

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

When this edit applies

A claim will fail this edit when:

• JSON API
  If you’re using one of Stedi’s JSON claim submission API endpoints, the edit fails if one of the following request field values is more than 30 characters:
  
  

  • Professional claims JSON endpoint: claimInformation.serviceLines.providerControlNumber

  • Dental claims JSON endpoint: claimInformation.serviceLines.providerControlNumber

  • Institutional claims JSON endpoint: claimInformation.serviceLines.lineItemControlNumber

• Raw X12
  If you’re using raw X12, the edit fails if REF-02 (Line Item Control Number) in any Loop 2400 (Service Line Number) is more than 30 characters.
  
  

• Stedi portal
  You can’t specify line item control numbers using the Stedi portal’s CMS-1500 claim form. As a result, you can’t fail this edit using the form.

Rejection errors

If you submit a claim that fails the edit using Stedi’s claim submission APIs, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": Submitted Line Item Control Number, {123456789012345678901234567890123}, is invalid as it exceeds 30 characters. This field must be between 1-30 characters. 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

You can now upload batch eligibility CSV files containing up to 10,000 checks – 10x the previous 1,000-check limit for CSV.

If you need to run more checks, you can upload and run multiple files at the same time.

For details, check out our Batch eligibility CSV upload docs.

You can now programmatically retrieve PDF versions of your 835 Electronic Remittance Advice (ERAs) using Stedi’s new ERA PDF API endpoint. The {transactionId} path parameter is the ERA's transaction ID.

By default, the endpoint returns the PDF as a base64-encoded string. To get the unencoded PDF data, include the Accept: application/pdf request header. To view the PDF, save the PDF data to a file with a .pdf extension.

curl -X GET \
  "https://healthcare.us.stedi.com/2024-04-01/electronic-remittance-advice/{transactionId}/pdf" \
  -H "Authorization: <api_key>" \
  -H "Accept: application/pdf" \
  > era.pdf

The PDFs are the same as the ones you can download from the Stedi portal:

For more, check out our announcement blog or the API reference.

Horizon Blue
Cross Blue Shield of New Jersey (Payer ID: 22099) 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.

You can now upload documents required for transaction enrollment requests directly in the Stedi portal. Only PDF documents are supported.

What is transaction enrollment?

Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer.

For 835 Electronic Remittance Advice (ERAs), enrollment is always required. A payer only sends ERAs to the clearinghouse the provider has enrolled with, and a provider can only enroll with the payer through one clearinghouse at a time.

Stedi offers fully-managed, API-based transaction enrollment. You can use Stedi’s enrollment API to programmatically submit and track enrollments for providers. You can also use the Stedi portal, which supports bulk CSV imports.

When possible, we handle all enrollment paperwork on your behalf. When we can’t, we let you know what’s needed next.

Upload required enrollment documents

Enrollment requirements vary by payer. Some payers require additional documents, such as:

• A signed form

• A practice W9

• A voided check

Previously, Stedi emailed you to request these documents and asked you to email them back to us.

With this update, we’ll still email you when an enrollment requires action. But, now, you can upload completed documents by clicking Upload new document in the Documents section of the enrollment’s details page in the Stedi portal.

The new upload functionality is available for all Stedi plans, including our free Basic plan.

For more information, see our documentation.

You can now get a payer’s website URL using the Stedi Payer Network and the Payers API.

Stedi payer records now list the payer’s website URL, when provided.

View payer URLs in the Stedi Payer Network
Each payer now includes a Visit payer website link, when available in the payer’s record, in the Payer pane:

The Payer page also includes the link:

Retrieve payer URLs using the Payers API
All Payers API endpoints also now return the urls.website response property, if available, for payer records.

{
    "displayName": "Blue Cross Blue Shield of Texas",
    "primaryPayerId": "84980",
    ...
    "urls": {
      "website": "https://www.bcbstx.com"
    }
  }
}

You can now correct and resubmit 837P professional claims using the Stedi portal’s CMS-1500 form.

Previously, if you submitted a claim using Stedi’s CMS-1500 form and later needed to fix it, you had two options:

• Re-enter all the data into the form by hand.

• Use the portal’s Edit and resubmit feature to change the raw X12.

Now, you can revise the previous claim directly in Stedi’s CMS-1500 form. Stedi loads the data from the original claim into the form for you.

For more details, see our announcement blog.

You can now download unbranded ERA PDFs without a Stedi logo in the Stedi portal.

Stedi generates a PDF version of each Electronic Remittance Advice (ERA) you receive. Previously, all ERA PDFs included “Powered by Stedi” in the page footer. Now, you have the option to download ERA PDFs without this footer.

To download an unbranded ERA PDF:

1. Go to the Transactions page.

2. Click the ERA transaction you want to download.

3. On the Overview tab, click Fetch artifact. Then click … and select Download 835 ERA PDF without Stedi logo.

Stedi now rejects 837I institutional claims that are missing a required admission source code.

In an institutional claim, the admission source code tells you where the patient came from, such as the emergency room (ER), a doctor’s referral, or another facility.

Most institutional claims require this code. Without it, the payer can’t adjudicate the claim. The one exception is non-patient lab services, where no patient is present.

If the code is missing when required, the payer may reject the claim, which can cause payment delays.

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

When this edit applies
An institutional claim will fail this edit in the following cases:

• JSON API
  If you’re using Stedi’s JSON institutional claim submission API endpoint, the edit fails if:

  • The admissionSourceCode field is missing or empty.
    AND

  • The placeOfServiceCode field does not contain 14 (Non-Patient Laboratory).
    
    

• Raw X12
  If you’re using raw X12, the edit fails if:

  • CL1-02 (Admission Source Code) of Loop 2300 (Claim Information) is missing or empty.
    AND

  • C023-01 (Facility Type Code) of Loop 2300 is NOT 14 (Non-Patient Laboratory).

Rejection errors
If you submit a claim that fails the edit using Stedi’s institutional claim submission API endpoints, you’ll get back an error message in real time. If you’re using the JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Missing admission source code. This code is required on all institutional claims with the exception of non-patient laboratory claims (Type of Bill 014x). 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Stedi app developers can now configure their apps to automatically add one or more support users – called members – to accounts that install their app. 

App developers can use the support users to provide support or help with implementation.

This new feature is optional. The support user has the Developer role.

What is a Stedi app?
A Stedi app is a prebuilt integration between Stedi and a third-party platform. 

Stedi accounts on the Basic plan can install Stedi apps to quickly connect their account to a third-party Revenue Cycle Management (RCM) system, Practice Management System (PMS), Electronic Health Record (EHR) platform, or other Stedi Platform Partners. 

For example, a practice or provider on Stedi’s free Basic plan can install a Stedi app to connect their Stedi account to their EHR.

As an app developer, you can choose to offer your app for free on the Basic plan or require a paid upgrade.

Get started with Stedi apps
To discuss publishing or configuring a Stedi app, contact us. You can also check out Publish your app in our developer docs.

To install a Stedi app, log in the Stedi portal and go to the Apps page. You can also check out our related docs.

Priority Health (Payer ID: PRHTH) 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.

Highmark Western and Northeastern New York (Payer ID: 55204) 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.

Healthcare payer Quartz (Payer ID: 39180) 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.

Highmark Blue Cross Blue Shield of Western New York (Payer ID: 100948) 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.

Blue Cross Blue Shield of Kansas City (Payer ID: 47171) 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.

Blue Cross Blue Shield of Kansas (Payer ID: 47163) 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.

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain an invalid date of birth.

In a claim, you must provide a date of birth for the patient. If the subscriber is a different person, you must also provide the date of birth for the subscriber – the person who carries the insurance policy.

Payers use dates of birth to distinguish between members with similar names. If you provide an invalid date of birth for the patient or subscriber, the payer may reject the claim, which can cause payment delays.

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

When this edit applies
A claim will fail this edit when the patient or subscriber’s provided date of birth:

• Occurs after the claim’s transaction date. – the date the claim is submitted. Providers always submit claims after care is provided. Logically, the date of birth can’t occur after the date the claim is submitted.
  
  If you’re using Stedi’s JSON claim submission APIs or professional claim form, this is the date you submit the claim to Stedi.  In X12 claims, this date is in segment BHT-04 (Transaction Set Creation Date).
  
  OR
  
  

• Indicates an age of 150 years or older

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The subscriber date of birth, 18001231, is invalid. The date of birth cannot be later than the transaction date and must reflect a reasonable subscriber age. 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Dentaquest - Individual (Payer ID: CX014) 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.

Stedi now rejects 837P professional and 837I institutional claims that bill for a drug or biologic without a valid unit count.

In professional and institutional claims, you bill for drugs or biologics by adding information about the drug to a service line, specifying what drug was administered and how much.

The line’s unit of measurement code – such as F2 (International Unit) or GR (Gram) – shows how the drug was measured. The line’s unit count reports the quantity administered in that measure.

Payers use the measurement code and unit count to verify dosage and pricing. Without a valid unit count, they can’t confirm the billed amount and may reject the claim, which can delay payment.

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

When this edit applies
A professional or institutional claim will fail this edit in the following cases:

• JSON API
  If you’re using one of Stedi’s JSON claim submission API endpoints, the edit fails if:

  • A service line contains a drugIdentification.measurementUnitCode value.
    AND

  • The service line’s drugIdentification.nationalDrugUnitCount field is less than or equal to ”0”.

• Raw X12
  If you’re using raw X12, the edit fails if:

  • Loop 2410 (Drug Identification) is present
    AND

  • The CTP-05 (Composite Unit of Measure) of Loop 2410 contains a value.
    AND

  • The CTP-04 (National Drug Unit Count)  of Loop 2410  is less than or equal to 0.

• Stedi portal
  If you’re using the Stedi portal’s professional claim form, the edit fails if:

  • Box 24 – Service Lines contains a service line with a Unit/Basis of measurement value and a Quantity less than or equal to zero.

    

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid drug unit count. When reporting a drug unit qualifier, the drug count must be greater than zero (0.0). 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Stedi now rejects 837P professional and 837D dental claims that relate to an auto or other accident but don’t include an accident date.

When you submit a professional or dental claim, you can indicate that the patient’s condition is related to an accident using a related causes code. Valid codes are AA (Auto accident), EM (Employment), and OA (Other accident).

If you provide a related causes code of AA or OA, payers also require an accident date – the date the injury occurred. Payers use this date to determine liability, coordinate benefits with other payers, and correctly adjudicate the claim.

If you don’t include the accident date in these cases, the payer may reject the claim, which can delay payment.

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

When this edit applies
A professional or dental claim will fail this edit in the following cases:

• JSON API
  If you’re using one of Stedi’s JSON claim submission API endpoints, the edit fails if:

  • The claimInformation.relatedCausesCode array contains AA (Auto accident) or OA (Other accident).
    AND

  • The claimInformation.claimDateInformation.accidentDate field is empty or missing.

• Raw X12
  If you’re using raw X12, the edit fails if:

  • The CLM11-1 (Related Causes Code)  or CLM11-2 (Related Causes Code) of Loop 2300 (Claim Information) contains AA (Auto accident) or OA (Other accident).
    AND

  • The DTP-03 (Accident Date) of Loop 2300 is empty or missing.

• Stedi portal
  If you’re using the Stedi portal’s professional claim form, the edit fails if:

  • The Auto accident? or Other? field of Box 11 – Is patient's condition related to is Yes.

  • Box 15 – Other Date does not contain a Date with a Qualifier of 439 (Accident)

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The Accident Date is missing. This date is required when the claim is marked as accident-related, Auto Accident, in Related Causes Code. 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Stedi now rejects 837I institutional claims that contain an invalid service line revenue code.

Revenue codes are standardized, 4-digit codes that hospitals and other care facilities use to identify the type of room, service, or supply billed on a service line. Example revenue codes include:

• 0450 – Emergency Room

• 0360 – Operating Room Services

• 0300 – Laboratory

Revenue codes are different from procedure codes, such as CPT or HCPCS codes. A procedure code describes what kind of care was delivered. A revenue code describes the type of facility associated with the charge.

Revenue codes are maintained by the National Uniform Billing Committee (NUBC). They are always 4 digits and start with a 0, 1, 2, or 3.

Revenue codes often drive how payers price and reimburse institutional claims. If a claim includes an invalid revenue code, the payers may reject the claim, which can delay payment.

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

When this edit applies
An institutional claim fails this edit if a service line revenue code:

• Is not exactly 4 digits

• Does not start with a 0, 1, 2, or 3

If you're using Stedi’s JSON institutional claim submission endpoint, you provide the revenue code in the serviceLineRevenueCode field for the service line.

In raw X12, you provide the revenue code for a service line in SV2-01 (Service Line Revenue Code) of Loop 2400 (Service Line Number).

Rejection errors
If you submit an institutional claim that fails the edit using Stedi’s institutional claim submission API endpoints, you’ll get back an error message in real time. If you’re using the JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The Revenue Code value does not match the required format. Revenue codes must be 4 digits and have a valid leading digit of 0, 1, 2, or 3. Please review and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit an institutional claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include duplicate payer responsibility level codes.

Payer responsibility level codes, also called payment responsibility sequence number codes, indicate which payer is supposed to pay first, second, and so on. For example, a code of P indicates the primary payer. A code of S indicates the secondary payer.

The process of determining this order is known as coordination of benefits (COB). Payers use this information to process secondary and tertiary claims correctly.

If a claim lists more than one payer at the same responsibility level – for example, two primary payers – the payer may reject the claim, which can cause payment delays.

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

When this edit applies
A claim will fail this edit when:

• JSON API
  If you’re using one of Stedi’s JSON claim submission API endpoints, the edit fails if the subscriber.paymentResponsibilityLevelCode field and/or any claimInformation.otherSubscriberInformation.paymentResponsibilityLevelCode fields contain a duplicate value.

• Raw X12
  If you’re using raw X12, the edit fails if Loop 2000B (Subscriber Hierarchical Level) and/or Loop 2320 (Other Subscriber Information) contain a duplicate SBR-01 (Payer Responsibility Sequence Number Code) value.

• Stedi portal
  You can’t fail this edit using the Stedi portal’s professional claim submission form. Currently, the form only supports claims to a single primary payer. Secondary and tertiary claims aren't supported.

This edit does not fail if a claim lists multiple payers with a responsibility level code of U (Unknown). A code of U doesn’t indicate a specific payment order, so duplicates are allowed.

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid payer responsibility submitted. Duplicate payer responsibility codes were detected: [P, S, S]. Payer responsibility values within a claim must be unique. 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that don’t include a primary payer.

Every claim must include exactly one primary payer. For primary claims, this payer determines routing. For secondary and tertiary claims, payers use this information to determine coordination of benefits (COB) and adjudicate the claim correctly. If it’s missing, the payer may reject the claim, which can cause payment delays.

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

When this edit applies
A claim will fail this edit when:

• JSON API
  If you’re using one of Stedi’s JSON claim submission API endpoints, the edit fails if neither the subscriber.paymentResponsibilityLevelCode nor any claimInformation.otherSubscriberInformation.paymentResponsibilityLevelCode fields contains a value of P (Primary) in the request.

• Raw X12
  If you’re using raw X12, the edit fails if neither Loop 2000B (Subscriber Hierarchical Level)) nor Loop 2320 (Other Subscriber Information) contains an SBR-01 (Payer Responsibility Sequence Number Code) value of P (Primary).

• Stedi portal
  You can’t fail this edit using the Stedi portal’s professional claim submission form. Currently, the form only supports claims to a single primary payer. Secondary and tertiary claims aren't supported.

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The Primary Payer information is missing. A primary payer must be indicated in either the Subscriber or Other Subscriber loops of the claim. 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Resolution tips
For secondary and tertiary claims, include a single primary payer in other subscriber information:

• JSON API
  If you’re using one of Stedi’s JSON claim submission API endpoints, you can provide this information in a claimInformation.otherSubscriberInformation object with a paymentResponsibilityLevelCode of P (Primary) in the request.

• Raw X12
  If you’re using raw X12, you can provide this information in Loop 2320 (Other Subscriber Information) with an SBR-01 value of P (Primary).

In the coming weeks, Stedi will normalize all X12 271 eligibility responses to use a standard set of delimiters.

If you do not parse the raw X12 271 and only parse Stedi's JSON response, this change will not impact you.

What are X12 delimiters?
In X12, delimiters are characters that separate the parts of a transaction set. Each transaction set has four types of delimiters:

• Element Separator – Separates fields

• Repetition Separator – Separates repeat values

• Component Element Separator – Separates sub-elements

• Segment Terminator – Ends each segment

These delimiters are defined in the ISA segment and can vary across transaction sets.

How it works today
Stedi currently passes through whatever X12 delimiters the payer sends.

However, some payers use unsafe characters, such as carriage returns, as delimiters in their 271 eligibility responses. This can break X12 parsing for some Stedi customers.

What’s changing
Stedi will normalize all delimiters returned in X12 271 eligibility responses to the following characters:

• Element Separator: * 

• Repetition Separator: ^

• Component Element Separator: >

• Segment Terminator: ~

If any of the above delimiters appear in a data element value – meaning the delimiter isn’t used to delimit content but is used as content – we will replace it as follows:

For example:

O*CONNOR → O|CONNOR
CODE^01 → CODE|01
O`CONNOR → O'CONNOR
MSG~HELLO → MSG|HELLO

What’s impacted
This change will affect all X12 271 eligibility responses returned by Stedi, including those returned by the:

• X12 Eligibility API endpoint

• SOAP Eligibility API endpoint

• x12 property of our JSON Eligibility API endpoint

• x12 field of our Poll Batch Eligibility Checks endpoint

• Stedi portal

Next steps
If you do not parse the raw X12 271 and only parse Stedi's JSON response, this will not impact you. Most Stedi customers won’t need to make any changes for this update. 

However, if your X12 parser assumes fixed delimiters instead of reading them from the ISA segment, you should confirm that your parser will continue to work after the update.

If you need time to update your parsing logic or have questions, contact us using your dedicated support channel or our contact form by December 22, 2025.

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that list a non-physical address for the billing provider. Non-physical addresses include Post Office (PO) Boxes, lockboxes, private mailboxes (PMBs), and similar mailbox-only addresses.

For claims, HIPAA requires that the provider’s billing address be a physical practice location where care is delivered. If you’re using Stedi’s JSON claim submission API endpoints, this address is in the request’s billing.address field. In X12, the address is in N3 (Billing Provider Address)  of Loop 2010AA (Billing Provider Name).

Payers may reject claims when the billing provider address is not a real street address, which can cause payment delays.

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

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Billing Provider address. The billing provider address must be a street address. Post Office Box or Lock Box addresses are to be sent in the Pay-To Address (2010AB Loop). 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Resolution tips
If the billing provider receives mail at a PO Box, lockbox, or other non-physical address, you can provide a “pay-to” address in the claim.

If you’re using Stedi’s JSON claim submission API endpoints, you can specify the pay-to address in the request’s payToAddress field or, for institutional claims, the billingPayToAddressName field. In X12, you can specify the pay-to address in N3 (Pay-to Address) of Loop 2010AB (Pay-to Address Name).

Stedi now rejects 837P professional claims that are billed to Medicare Part B for chiropractic services when the primary diagnosis doesn’t indicate subluxation – a partial dislocation of a spinal joint.

Medicare requires the primary diagnosis on a chiropractic claim to indicate subluxation. In ICD-10-CM, this is represented by the M99.0x family of diagnosis codes: M99.00-M99.05.

Medicare Part B claims submitted with a non-subluxation primary diagnosis may be rejected by the Medicare Administrative Contractor (MAC) payer, which can cause delays.

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

When this edit applies
A claim will fail this edit when all of the following are true:

• The claim is billed to Medicare Part B.

  • In raw X12, this is indicated by a value of MB (Medicare Part B) in SBR09 (Claim Filing Indicator Code) of Loop 2000B (Subscriber Information).

  • In the JSON professional claims submission endpoint, this is indicated by a Claim Filing Indicator Code of MB (Medicare Part B).

  • In the professional claim form, this is indicated in Box 1 – Insurance type by a value of Medicare.
    
    

• The claim includes a service line with one of the following Chiropractic Manipulative Treatment (CMT) procedure codes: 98940, 98941, or 98942.
  
  

• The claim’s primary diagnosis code is not within the M99.00-M99.05 range (inclusive).

  • In raw X12, the primary diagnosis is the first diagnosis code in HI (Health Care Diagnosis Code) of Loop 2300 (Claim Information).

  • In the JSON professional claims submission endpoint, the primary diagnosis is in the diagnosisCode field of the first object in the claimInformation.healthCareCodeInformation array.
    Note: Do not include decimal points in the diagnosis code.

  • In the professional claim form, the primary diagnosis is the first diagnosis code in Field A of Box 21 – Diagnosis or nature of illness or injury.

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Chiropractic claims submitted to Medicare must have a primary diagnosis that lists the precise level of subluxation. 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

You can now look up a patient’s Medicare Beneficiary Identifier (MBI) without a Social Security Number (SSN) using Stedi's Eligibility APIs or the Stedi portal.

Note: CSV batch eligibility requests do not support MBI lookups without SSN.

Two types of MBI lookups
With this update, you can now perform an MBI lookup in two ways. Each uses a different payer ID:

Note: When running an MBI lookup without SSN using our raw X12 or SOAP eligibility endpoints, you must include a city, in addition to a U.S. state, in Loop 2100C N4. You can use a dummy city value, such as DUMMY, if needed. If you omit the city value, you'll receive an X12 validation error.

Transaction enrollment
Before running an MBI lookup without an SSN, enroll the provider for eligibility checks with the MBILUNOSSN payer ID using the Transaction Enrollment API or the Stedi portal. Enrollments for the MBILUNOSSN payer typically take 1-3 business days to complete.

You’ll get an email once the enrollment is live. You can also check enrollment status using the List Enrollments or Retrieve Enrollment API endpoints.

Run an MBI lookup without an SSN
After the enrollment is live, send an eligibility check to MBILUNOSSN. Include:

• The provider’s NPI

• The patient’s first name

• The patient’s last name

• The patient’s date of birth

• The patient’s U.S. state

• The patient's city (if using the raw X12 or SOAP eligibility endpoints)

For example, using Stedi’s JSON Eligibility API:

curl --request POST \
  --url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3 \
  --header 'Authorization: <api-key>' \
  --header 'Content-Type: application/json' \
  --data '{
  "tradingPartnerServiceId": "MBILUNOSSN",
  "externalPatientId": "UAA111222333",
  "encounter": {
    "serviceTypeCodes": [
      "30"
    ]
  },
  "provider": {
    "organizationName": "ACME Health Services",
    "npi": "1999999984"
  },
  "subscriber": {
    "dateOfBirth": "19000101",
    "firstName": "Jane",
    "lastName": "Doe",
    "address": {
      "state": "NY"
    }
  }
}'

The response includes the MBI as the subscriber’s member ID. For example:

{
  "subscriber": {
    "memberId": "1AA2CC3DD45",
    "firstName": "JANE",
    "lastName": "DOE",
    ...
    "address": {
      "state": "NY",
      ...
    }
  },
  ...
}

For more details, see our announcement blog.

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that indicate an attachment was or will be sent by mail, electronically, email, fax, or file transfer – but don’t include an attachment control number.

Some payers require supporting documents, such as X-rays or treatment plans, before approving claims for certain services. Depending on the payer, you can send attachments in several ways, including by mail or electronically using a 275 claim attachment transaction through Stedi.

When a claim indicates that an attachment was or will be sent by mail, electronically, email, fax, or file transfer, you must include an attachment control number. The payer uses this value to match the attachment to the claim.

Payers may reject claims missing this number, which can cause delays.

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

This edit only applies when the claim indicates that an attachment was or will be sent. If the claim does not reference an attachment, this edit does not run.

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Attachment control number is required when attachment is sent by mail, electronically, email, fax, or file transfer",
      "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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain an invalid tax identification number (TIN) for the billing provider.

When you submit a claim, you must include the billing provider’s TIN – either a Social Security Number (SSN) or Employer Identification Number (EIN). The TIN must be a 9-digit number with no spaces or separators.

Payers reject claims that contain an invalid TIN for the billing provider, which can cause delays.

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

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The billing provider tax id (TIN), 1234567890, is invalid. The TIN must be a string of exactly 9 numbers 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

You can now submit multiple claims in a single 837 transaction set using X12 over SFTP. 837P professional, 837D dental, and 837I institutional claims are supported.

Some billing platforms create a single 837 transaction set (one ST/SE segment) that includes multiple claims from different billing providers or patients. The transaction set may include claims for different payers. To deliver the claims to the correct payer, the X12 must be split into separate 837 transactions.

Stedi automatically splits 837 transaction sets containing multiple claims at the Billing Provider (2000A), Subscriber (2000B), and Claim Information (2300) loops. Behind the scenes, Stedi creates separate 837 transactions for each claim and routes them to the payer independently. Multiple claims going to the same payer will also be split to maintain the same behavior across all 837 transactions.

For example, if your 837 transaction set has two billing providers (two 2000A loops), each with three subscribers (three 2000B loops), and two claims per subscriber (two 2300 loops), Stedi submits 12 separate claim transactions.

Pricing
Stedi charges for each split claim transaction. For example, if a transaction set would result in 12 claim transactions, you're billed for 12 claim submissions. For rates, see our pricing page or contact us.

Claim acknowledgments and ERAs
The Stedi portal’s Transactions page will only display one 837 transaction, representing the original X12 file, and you’ll receive a single 999 acknowledgment. However, 277CA claim acknowledgments – from Stedi and the payer – and 835 Electronic Remittance Advices (ERAs) will reference the split 837 claims. Stedi will also run claim edits on the split 837 claims to catch rejections early.

If you submit a batch X12 claim to the Stedi Test Payer (Payer ID: STEDITEST), each transaction receives its own mock 835 Electronic Remittance Advice (ERA). 

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that are missing the patient’s date of birth or gender.

Payers use the patient’s date of birth and gender to match the claim to the correct patient record. If either field is missing, the payer will reject the claim, which can cause delays.

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

Patient vs. subscriber vs. dependent
In a health insurance claim, there are three distinct roles:

• The subscriber is the person who holds the insurance policy. They’re also called the insured, the primary policyholder, or the primary cardholder.
  
  

• A dependent is someone covered under the subscriber’s plan, such as a spouse or child.
  
  

• The patient can be either the subscriber or a dependent, depending on who received care.

For example, if a child receives dental care, the child is the patient even though the parent is the subscriber.

Claims must include the patient’s date of birth and gender – not just the subscriber’s – so the payer can identify the correct person.

How the edit works
A claim can include information for both the subscriber and the dependent, if applicable. You only include the dependent’s information if the dependent is the one who received care and the dependent doesn’t have their own member ID.

As part of the edit, Stedi checks the patient’s information to ensure the claim includes the patient's date of birth and gender:

• If the subscriber is the patient: The edit requires the subscriber’s date of birth and gender.
  
  

• If the dependent is the patient: The edit requires the dependent’s date of birth and gender and ignores the subscriber's date of birth and gender.

If the patient’s date of birth or gender is missing, Stedi rejects the claim so you can correct and resubmit it before it reaches the payer.

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes an error in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The patient's date of birth and gender are both missing. 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Stedi now rejects 837P professional claims that are billed to Medicare Part B for chiropractic services when the initial treatment date is missing.

Medicare requires chiropractic claims to include the initial treatment date. CMS defines this as the first date the chiropractor provided active treatment for the current episode. If that date is missing, the Medicare Administrative Contractor (MAC) payer will reject the claim, causing delays.

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

When this edit applies
A claim will fail this edit when all of the following are true:

• The claim is billed to Medicare Part B.

  • In raw X12, this is indicated by a value of MB (Medicare Part B) in SBR09 (Claim Filing Indicator Code) of Loop 2000B (Subscriber Information).

  • In the JSON professional claims submission endpoint, this is indicated by a Claim Filing Indicator Code of MB (Medicare Part B).

  • In the professional claim form, this is indicated in Box 1 – Insurance type by a value of Medicare.
    
    

• The claim includes a service line with one of the following Chiropractic Manipulative Treatment (CMT) procedure codes: 98940, 98941, or 98942.
  
  

• The claim is missing the initial treatment date.

  • In raw X12, this is indicated by a date with qualifier 454 (Initial Treatment) in DTP01 (Date - Initial Treatment Date) of Loop 2300 (Claim Information).

  • In the JSON professional claims submission endpoint, you can provide this in the initialTreatmentDate field.

  • In the professional claim form, enter the date in Box 15 – Other date with a Qualifier of 454 (Initial Treatment). 

Rejection errors
If you submit a claim that fails the edit using Stedi’s professional claims submission API endpoints or professional claim form, you’ll get back an error message in real time. If you’re using the JSON API endpoint, the response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "An initial treatment date is required when the chiropractic service, 98940, is submitted to Medicare. 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

The Centers for Medicare and Medicaid Services (CMS) requires that providers complete transaction enrollment to run eligibility checks through Stedi or other clearinghouses.

When an eligibility check to CMS fails with AAA error 41 – meaning the provider isn’t enrolled with CMS for eligibility transactions – Stedi now automatically submits the required transaction enrollment request. CMS usually processes these enrollments within 24-48 hours.

With this change, Stedi customers no longer need to track down and submit missing enrollments when a Medicare eligibility check fails. Stedi now handles that work for you. This reduces your operational overhead and helps ensure future Medicare checks will succeed.

For more information, see the related announcement blog.

Stedi now rejects 837I institutional claims that include an invalid billing provider ZIP code.

Institutional claims must include a full nine-digit ZIP code – called a ZIP+4 – with no spaces or hyphens for the billing provider. For example: 100031502. If you don’t know the full ZIP+4, you can look it up using the USPS ZIP Code Lookup tool.

If you submit institutional claims through Stedi’s institutional claim submission JSON API endpoint, this ZIP code is provided in the providers.address.postalCode field.

Payers reject claims that are missing a full ZIP+4 or that contain an invalid code, which can cause delays.

This edit – the industry’s term for an automated validation rule – prevents these claims from reaching the payer.

Rejection errors
If you submit a claim that fails the edit using Stedi’s institutional claim submission API, you’ll get back an error message in real time. If you’re using the JSON API endpoint, the response includes an error in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Billing provider zip code, 11113527 is invalid. Zip codes must be a nine-digit number with no spaces or hyphens. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit an institutional claim that fails the edit using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Stedi now rejects 837P professional and 837D dental claims that are missing the subscriber’s member ID when the subscriber is a person.

Payers use the subscriber’s member ID to identify the patient and verify eligibility. It’s typically printed on the subscriber’s insurance card. If it’s missing, the payer will reject the claim, which delays processing.

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

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes an error in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The subscriber identification is missing. When the subscriber is a person, then the subscriber identifier (commonly member id) is required. 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Resolution tip
Add the subscriber’s member ID and resubmit the claim. If you’re using Stedi’s JSON API endpoints, provide this value in the subscriber.memberID field.

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims when an adjustment amount is zero.

In healthcare claims, an adjustment represents an amount that was written off, applied as patient responsibility, or previously paid by another payer. Adjustments can be applied at both the claim level and the service line level.

Payers expect adjustments in a claim to reflect a real dollar amount. A zero amount isn’t valid and will cause the claim to be rejected downstream, which can cause delays.

This new edit – an industry term for an automated validation rule – catches the issue before it reaches the payer. The edit ensures that no claim-level or line-level adjustment in a claim equals zero. If so, the claim fails the edit.

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Claim Adjustments at the Line-level (Segment CAS) contain one or more zero values. Segment CAS-03 represents the monetary amount for each adjustment, which must be greater than zero (0.00). 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Resolution tip
Add the initial treatment date and resubmit the claim.

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims when the Payer Claim Control Number (PCCN) is missing when required – or included when it shouldn’t be.

A PCCN is the claim number the payer assigns after they receive and process a claim. It’s the payer’s unique ID for that claim.

You only include a PCCN when you’re replacing or voiding a previous claim. In those cases, payers use it to link the new claim to the original.

If a PCCN is included on a new claim – or missing when you’re replacing or voiding a previous claim – the payer may reject the claim. These edits catch those issues before your claim reaches the payer.

When the PCCN must be included
A claim’s Claim Frequency Code indicates whether it replaces or voids a previous claim. A PCCN is required if the frequency code is:

• 7 – Replacement of Prior Claim

• 8 – Void/Cancel of Prior Claim

• G – Common Working File (NCH) generated adjustment claim

• I – Miscellaneous adjustment claim

• X – Void/Cancel a Prior Abbreviated Encounter Submission

• Y –  Replacement of prior abbreviated encounter submission

If the PCCN is missing when one of these codes is used, Stedi rejects the claim using a new edit – an industry term for an automated validation rule.

If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The Payer Claim Control Number is missing. This is required when submitting a replacement or void claim (Frequency code 7, 8, G, I, X, Y). 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

When the PCCN must be excluded
If the Claim Frequency Code is not one of the codes above, you should not include a PCCN. If one is present, Stedi rejects the claim using a new edit.

If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The Payer Claim Control Number should not be reported on this claim. This should only be used when submitting a replacement or void claim (Frequency code 7, 8, G, I, X, Y). 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims when the total claim charge amount is zero and the claim is marked as chargeable.

Most commercial payers do not accept zero-dollar claims. Some scenarios – such as capitated arrangements or encounter submissions – allow them, but standard chargeable claims must have a charge amount greater than $0. Otherwise, the payer will reject the claim, causing delays.

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 APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "For Chargeable (CH) claims, the total claim charge amount $0.00 must be greater than zero ($0.00) dollars. 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Resolution tip
If the claim was intended for reporting and the total charge should be $0, change the claim’s Claim Identifier to Reporting. If you’re using a JSON claim submission API endpoint, you can do this by changing the top-level claimIdentifier request body property to RP (Reporting).

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims when the total charge amount doesn’t equal the sum of the claim's service line charges.

Payers require these amounts to balance. If they don’t, the payer will reject the claim, which can cause delays. This edit – the industry’s term for an automated validation rule – catches the issue before it reaches the payer.

As part of the edit, we total up the line-level charges and compare them to the claim-level charge. A small rounding tolerance (±$0.01) is allowed. Anything outside that range fails the edit.

The edit applies to all claims, including Coordination of Benefits (COB) claims.

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Total claim charge amount ($110.20) does not equal the sum of all service line charge amounts ($109.20) for this claim. 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Resolution tips
Double-check that the claim-level charge and the sum of the line-level charges match. Most issues come from:

• Rounding or formatting errors. For example, using $100.005 instead of $100.00.

• Adding, removing, or editing service lines without updating the total.

Stedi now rejects secondary and tertiary 837P professional, 837D dental, and 837I institutional claims if the claim’s Coordination of Benefits (COB) amounts don’t balance.

When you submit a secondary or tertiary claim, you must include the payments and adjustments, like patient responsibility or disallowed amounts, from previous payers. These amounts must add up cleanly:

Total charges = All payments + All adjustments

This process is called Coordination of Benefits (COB) balancing.

If the numbers don’t match, the payer may reject the claim to avoid overpayment. This edit  – the industry term for an automated validation rule – catches the issue before it reaches the payer.

For more on COB balancing, see our How to balance COB claims guide.

Rejection errors
If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Coordination of Benefits (COB) balancing failed. The total charged amount of $140.00 does not equal the sum of the paid amount of $80.00 and all adjustment amounts of $35.00. 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

Resolution tip
Double-check the payment and adjustment details from the previous payer’s Electric Remittance Advice (ERA), Explanation of Payment (EOP), or Explanation of Benefits (EOB). For help walking through the math, see How to balance COB claims.

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain an invalid phone number.

Stedi already fixes common formatting issues for phone numbers in claims. These fixes include:

• Removing non-alphanumeric characters, such as spaces, parentheses, or hyphens.

• Converting vanity letters, such as those in 1-800-MEDICARE, to numbers

• Removing leading country codes, such as 1 from 11-digit numbers.

Sometimes, phone numbers still don’t meet phone number validation requirements even after all fixes have been made. Invalid phone numbers will ultimately be rejected by payers, which delays the ultimate adjudication of the claim.

Stedi has introduced a new edit – the industry term for an automated validation rule – to ensure all telephone numbers in a claim are exactly 10 digits after all fixes.

If you submit a claim that fails the edit using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
   {
      "code": "33",
      "description": "Billing provider phone number is in an invalid format. The expected format is 10 numeric digits (0123456789); no country code, punctuation, or extension. 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 contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

You can now change how long Stedi retries failed checks in a batch using the new maxRetryHours property of the Batch Eligibility Check API endpoint.

You can set any integer between 8 and 24 hours (inclusive). If you don’t specify a value, the default remains 8 hours.

For example:

curl --request POST \
  --url https://manager.us.stedi.com/2024-04-01/eligibility-manager/batch-eligibility \
  --header 'Authorization: <api-key>' \
  --header 'Content-Type: application/json' \
  --data '{
  "items": [
    ...
  ],
  maxRetryHours: 24  // Retry failed checks for up to 24 hours
}'

Note: You can only set a customer retry window for batch eligibility checks submitted using the Batch Eligibility Check API endpoint.

For more details, see our announcement blog.

You can now filter provider records in the List Providers API endpoint by NPI and Tax ID using the providerNpis and providerTaxIds query parameters.

Both parameters expect exact matches and accept multiple values. They can be combined with other filters. The endpoint uses AND logic to return the intersection of all filters.

Example
The following request returns up to 50 provider records whose name contains Dental and whose NPI matches either 1234567890 or 0987654321 and whose tax ID matches either 111223333 or 444556666.

curl --request GET \
  --header "Authorization: <api_key>" \
  --url "https://enrollments.us.stedi.com/2024-09-01/providers" \
  --data-urlencode "filter=Dental" \
  --data-urlencode "providerNpis=1234567890" \
  --data-urlencode "providerNpis=0987654321" \
  --data-urlencode "providerTaxIds=111223333" \
  --data-urlencode "providerTaxIds=444556666" \
  --data-urlencode "pageSize=50"

The List Providers endpoint is used to filter provider records used in transaction enrollment requests. For more information, see the transaction enrollment docs.

You can now see how long – minutes, hours, days, or weeks – it takes for an enrollment to go from submission to live with a payer in the Stedi Payer Network or the Payers API.

Payer Network
In the Stedi Payer Network, enrollment timeframes are shown in the Payer pane, in the Activation Timeframe field for the transaction type:

Activation Timeframe fields are also listed on the Payer page:

A value of Instant means the enrollment typically goes live within minutes of submission. Other values, like Hours or Days, indicate how long the process usually takes.

Payers API
In Payers API responses, each payer object lists enrollment details, if any, for each transaction type under transactionEnrollmentProcesses. The timeframe field shows the expected enrollment timeline for the transaction type.

{
  "payer": {    "displayName": "Blue Cross Blue Shield of Michigan",
    "primaryPayerId": "00710",
    "enrollment": {
      "ptanRequired": false,
      "transactionEnrollmentProcesses": {
        "claimPayment": {                  // This payer requires enrollment for ERAs.
          "timeframe": "INSTANT",          // ERA enrollment typically takes minutes.
          "type": "ONE_CLICK"
        }
      }
    },
    ...
  }
}

For more details, see our announcement blog.

Stedi now rejects 837P professional claims and 837I institutional claims with an invalid diagnosis code.

In healthcare claims, diagnosis codes describe what’s wrong with the patient. HIPAA requires that professional and institutional claims only use valid, billable ICD-10-CM codes as diagnosis codes.

What the edits check
Stedi has introduced new edits – the healthcare industry’s term for automated validation rules – to help ensure claims include valid diagnosis codes.

The new edits reject a professional or institutional claim when any diagnosis code is:

• Not a valid ICD‑10‑CM code.
  For example, if the code is misspelled or doesn’t exist in the official ICD-10-CM code list.
  
  

• A non-billable ICD‑10‑CM code.
  Some ICD-10-CM codes are categories. They cover a broad diagnostic grouping rather than a specific condition. For example, E11 (Type 2 diabetes mellitus) is a category header.
  
  By themselves, category headers aren’t considered billable codes. They’re not specific enough to describe the exact condition or encounter being billed.
  
  A billable ICD-10-CM code must include both a category and a subcategory, such as E11.9 (Type 2 diabetes mellitus without complications).
  
  

• Not valid for the claim’s dates of service.
  Updates to the ICD-10-CM code set are published each year. If a claim uses a code that wasn’t valid on the dates of service, Stedi now rejects it.
  
  For example, Z11.52 (“Encounter for screening for COVID-19”) became effective on October 1, 2021. A claim with a date of service before that date would be rejected because the code wasn’t valid at the time.

If you submit a claim that fails the edits using Stedi’s claim submission APIs or professional claim form, you’ll get back an error message in real time. If you’re using a JSON API endpoint, the response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "The ICD-10 code E11 submitted does not meet the level of specificity needed. The Diagnosis code is a header and not valid for HIPAA transactions. Please resubmit with a more specific ICD-10.",
      "followupAction": "Please Correct and Resubmit"
    }
  ],
  ...
}

If you submit a claim that fails the edits using SFTP, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will contain a related claim status category code, claim status code, and error message. You can use the error message to correct and resubmit the claim.

You can now upload claim attachments using the professional claims submission form in the Stedi portal.

For claim-level attachments, use Box 19 – Supplemental claim information.

For line-level attachments, use Box 24 – Service lines supplemental information.

You can upload JPG, PDF, PNG, or TIFF files as attachments. To upload an attachment, you must set the Transmission code to EL (EDI).

You must also choose the appropriate Report type for the attachment. For example, if you’re uploading a medical record, you’d select a Report type of M1 – Medical Record Attachment. See Attachment Report Type Codes for a full list.

Note: You can’t add attachments to claims that were already submitted through the portal. To include attachments for those claims, resubmit them with the attachments.

Previously, you could only upload attachments using Stedi’s Create Claim Attachment JSON API endpoint.

For more details, see our announcement blog.

You can now download a PDF version of your 835 Electronic Remittance Advice (ERAs) from the Stedi portal.

Each PDF use a layout similar to the CMS Standard Paper Remit (SPR), Medicare’s official paper form for remittance.

For more details, see our announcement blog.

Batch eligibility checks let you run up to 10,000 checks asynchronously using a single request. You can check the progress of those batches with two new API endpoints:

• Retrieve Batch Check Status – Shows the overall status of a batch, including counts for completed and in-progress checks.

• Retrieve Batch Check Statuses – Shows the status of each individual check in a batch.

For more details, see our announcement blog.

You now get back a realistic mock 835 Electronic Remittance Advice (ERA) for claims submitted to Stedi’s test payer.

The mock ERAs mirror the type of electronic remittance you’d receive from payers in production. Each ERA contains the same information as if the test claim were paid in full.

For details, check out our announcement blog.

You can now tell which payers support vision coverage using the Stedi Payer Network or the Payers API.

For more details, see our announcement blog.

You can now submit claims as X12 EDI in the Stedi portal. Professional, dental, and institutional claims are supported. Previously, you could only submit claims as X12 using our X12 Claims API or SFTP.

For more information, see our announcement blog.

Required fields are marked with a red asterisk. For example, in the form, the insured's First and Last name is required.

We’ve redesigned the benefits table for eligibility responses in the Stedi portal to make it faster and easier to read a patient’s benefits.

Benefits are now grouped by health plan. Each plan begins with its general limitations, followed by benefit details. The benefit details are organized by the Service Type Codes (STCs) and procedure codes from the payer’s response.

If present, benefits for STC 30 (Health Benefit Plan Coverage) and STC 35 (Dental Care) – the baseline STCs for medical and dental care – appear first.

The table displays information from the benefitsInformation objects in Stedi’s JSON Eligibility API responses.

Filter benefits

You can filter the table to quickly find benefits for a specific service, procedure, or coverage type – like a deductible or limitation. You can also filter by overage level and whether the benefit applies to in-network or out-of-network services.

For example, you can filter the table to only show individual deductibles for STC 3 (Consultation).

The table displays information from the benefitsInformation objects in Stedi’s JSON Eligibility API responses.

For more information, see our announcement blog.

The Batch Eligibility Check API endpoint now supports up to 10,000 eligibility checks in a single request. Previously, the limit was 1,000 checks per request.

For more information, see our announcement blog.

The Stedi Payer Network now displays logos for select payers.

The Payer Network is Stedi's online payer list. The site lets you browse and search Stedi's supported payers for payer IDs, supported transaction types, and transaction enrollment requirements.

Logos make it easier to confirm you’ve found the right payer while browsing or searching.

The payer’s logo also appears on its detail page.

Logos in the Payers API
Stedi’s Payers API now returns the URL for a payer’s logo, when available. You can use the URLs to fetch payer logos for use in your own applications and interfaces.

The logo URL appears in the payer.avatarUrl field of the API response. The field is available for the Search Payer, List Payer, and Retrieve Payer endpoints.

Example:

{
"payer": {
  "displayName": "Cigna",
  "primaryPayerId": "62308",
  "avatarUrl": "https://prod-payer-avatars.payers.us.stedi.com/HGJLR/avatar.png?v=1761841671464",
  ...
}

We’ve redesigned the professional claim form in the Stedi portal to make it faster and easier to manually submit 837P professional claims.

The new layout mirrors the CMS-1500 (NUCC) Health Insurance Claim Form, the standard paper form for professional claims in the healthcare industry. If you’ve filled out a CMS-1500 before, the new form will look familiar.

To access the form, sign in to your Stedi account and go to https://portal.stedi.com/app/healthcare/claims/create. You can also open the form from the Stedi portal by going to Claims> Submit claim.

For more details, see our announcement blog.

You can now get free production access to Stedi with the Basic plan.

The Basic plan is our new starter plan for customers who just need to manually process production transactions, such as claims and eligibility checks, in the Stedi portal. It’s great for providers and small practices who are processing a small number of transactions each month.

The Basic plan also allows customers to test API integrations using test API keys. Once they’re finished testing, these customers can upgrade to a Developer plan to send production transactions using real API keys.

For details, see the announcement blog.

We’ve expanded the Stedi Agent with two new conversational features:

• Payer Finder: Ask questions about payers using conversational AI

• Chats: A dedicated page for all your Stedi Agent conversations

You can use these tools to get answers to payer questions faster and easier.

For more information, see the announcement blog.

We’re replacing the SUBMITTED transaction enrollment status with two new statuses that show who needs to act next:

• STEDI_ACTION_REQUIRED – Stedi needs to take action.

• PROVIDER_ACTION_REQUIRED – You or the provider need to take action.

The SUBMITTED status is now deprecated. Any existing requests will keep the SUBMITTED status and use the previous status workflow until they're live, canceled, or rejected.

We've also clarified the PROVISIONING status to mean only thing: the request has been submitted to the payer.

These changes make it easier to see which requests need your attention. You can filter by the PROVIDER_ACTION_REQUIRED status in the Stedi portal or List Enrollments endpoint to see which requests require action by you or your provider. For example, using the endpoint:

https://enrollments.us.stedi.com/2024-09-01/enrollments?status=PROVIDER_ACTION_REQUIRED

How enrollment statuses work now

Requests submitted through the Stedi portal or a bulk CSV now start in the STEDI_ACTION_REQUIRED status. If you’re using the Create Enrollment endpoint, you can set the status to STEDI_ACTION_REQUIRED to start processing the enrollment.

You can now submit 837I institutional claims as X12 EDI using the Institutional Claims X12 API endpoint.

Most Stedi customers submit 837I claims using our JSON-based Institutional Claims endpoint. JSON is familiar and easy to work with. You can build an integration faster.

But if you already work with X12, converting to JSON wastes time. The new endpoint accepts X12 directly. 

Previously, X12 submissions of 837I claims required SFTP. With SFTP, you have to wait for files to get errors or validation. With the API, you get instant responses. Development is faster, and debugging is easier.

For complete details, check out the Institutional Claims (837I) Raw X12 API reference.

Stedi integrated accounts and Stedi apps are now available. Together, this new set of capabilities allows end customers of Stedi’s Platform Partners to have Stedi accounts of their own.

Integrated accounts drastically reduce the amount of clearinghouse functionality that partners need to build themselves.

Integrated accounts
Integrated accounts are simplified Stedi accounts that are designed to be friendly to non-technical users. The more complex developer-focused functionality – such as configuring API access and webhooks, and viewing raw JSON payloads – has been removed.

Stedi apps
Integrated accounts can install Stedi apps, which are Stedi’s pre-built integrations to a growing list of third-party RCM, PMS, EHR, and other platforms.

Stedi apps allow providers to quickly connect their Stedi account to these external systems using preconfigured SFTP credentials and API keys.

They can also grant Stedi portal access for external support and implementation teams to assist with setup and ongoing support.

Learn more
See our announcement blog.

You can now correct and resubmit claims directly from the transaction detail page of any claim in the Stedi portal. 

We’ve also made other UI improvements that make the portal’s Claims section simpler and faster to use. Here’s what’s new:

• Streamlined list views and filters on the Transactions and Files pages help you find what you need, fast.

• Cleaner detail pages for transactions and files put the most important information front and center.

For more information, see our announcement blog.

You can now run 276/277 real-time claim status checks in the Stedi portal.

You can submit a claim status check using the Stedi portal’s new Create claim status check page. You can access the page by clicking Claims > New claim status in the portal’s nav.

Previously, you could only run these checks using Stedi’s Real-Time Claim Status API.

For more information, check out the announcement blog.

You can now download documents for a transaction enrollment request directly from its details page in the Stedi portal. This includes documents signed by Stedi on your behalf if you use delegated signature authority.

For more information, see our documentation.

You can now use the Stedi Agent in sandbox accounts and test mode.

In sandbox accounts and test mode, you run predefined mock eligibility requests that return realistic responses. The Stedi Agent is the Stedi portal’s built-in AI assistant. It helps you recover failed eligibility checks.

Previously, you could only use the Stedi Agent for failed eligibility checks in production. Now, you can try the agent out in sandbox accounts and test mode using a predefined mock check.

For more information, check out the announcement blog.

You can now filter results more precisely in the List Enrollments and List Providers API endpoints.

We’ve also updated the Enrollments page and Providers page in the Stedi portal to surface these filters.

List Enrollments endpoint

We’ve added new query parameters to the List Enrollments endpoint. You can use the parameters to filter by:

• Partial term: filter lets you search across multiple fields at once.
  
  

• Status: Filter by one or more enrollment statuses—such as DRAFT, SUBMITTED, PROVISIONING, LIVE, CANCELED, or REJECTED.
  
  

• Provider details: Filter by NPI (providerNpis), tax ID (providerTaxIds), or name (providerNames).
  
  

• Payer: Filter by payer IDs (payerIds).
  
  

• Source: Limit results by how the enrollment was created: API, UI, or IMPORT.
  
  

• Transaction type: Filter by transaction types, like eligibilityCheck, claimStatus, or claimSubmission.
  
  

• Date: Filter enrollments by when they were created (createdFrom, createdTo) or when their status last changed (statusUpdatedFrom, statusUpdatedTo).
  
  

• Import ID: If an enrollment was created through CSV import, filter by the returned importId.

Several of these query parameters accept arrays. You can include an array parameter more than once in the URL to filter by multiple values.

List Providers endpoint

The List Providers endpoint now accepts a filter parameter for searching by provider name, NPI, or tax ID. Filtering is case-insensitive and supports partial matches.

Updated filters in the Stedi portal

Alongside API improvements, we’ve updated the Stedi portal to surface these new filters on the Enrollments page and Providers page.

On the Enrollments page:

On the Providers page:

Now available in Stedi's Eligibility Manager, the Stedi Agent brings AI-powered automation to healthcare clearinghouse workflows, beginning with eligibility check recovery.

Use the Stedi Agent to recover failed eligibility checks. If a check fails with a known recoverable error, a Resolve with Stedi Agent option appears next to the related search. The agent runs in Debug view, where you can watch it work – step by step, in real time.

For more information, see our announcement blog.

Stedi now enriches most Blue Cross Blue Shield (BCBS) eligibility responses by automatically including the member’s home payer name and primary payer ID whenever possible.

This info appears in a related benefitsInformation.benefitsRelatedEntities entry in our JSON eligibility responses and in a 2120C or 2120D loop in X12 responses.

For more information, see our announcement blog.

Stedi is now e1 certified by the HITRUST for foundational cybersecurity.

HITRUST e1 Certification demonstrates that Stedi’s healthcare clearinghouse platform is focused on the most critical controls to demonstrate that essential cybersecurity hygiene is in place. The e1 assessment is one of three progressive HITRUST assessments that leverage the HITRUST Framework (HITRUST CSF) to prescribe cyber threat adaptive controls that are appropriate for each assurance type.

You can now run real-time eligibility checks using our CAQH CORE–compliant SOAP API endpoint.

Most Stedi customers use our JSON API for real-time eligibility. But if you're already using CAQH CORE SOAP, this new endpoint is the fastest way to start running eligibility checks with Stedi.

The endpoint supports CAQH CORE Connectivity Rule vC2.2.0. We plan to support CAQH CORE Connectivity Rule vC4.0.0 as industry adoption increases.

For complete details, see our documentation.

Today, Stedi announces the release of its Model Context Protocol (MCP) server.

The MCP server gives AI agents plug-and-play access to Stedi’s Real-Time Eligibility and Search Payers API endpoints, along with built-in guidance for common errors. You can connect your agents without having to write integration code or copy documentation.

For more information, see the announcement blog and our documentation.

You can now use the Retrieve Payer API endpoint to get a single payer record by its Stedi payer ID:

curl --request GET \
  --url https://healthcare.us.stedi.com/2024-04-01/payer/{stediId} \
  --header 'Authorization: <api-key>'

The endpoint returns the same payer information as our existing JSON-based Payer API endpoints: payer ID, name, payer ID aliases, transaction support, enrollment requirements, and more. Just for a single payer.

For more information, see the Stedi docs and the announcement blog.

You can now use the Stedi Platform Partners directory to find RCM, EHR, and practice management systems that use Stedi.

Many healthcare companies are looking for modern RCM solutions – and can’t or don’t want to build one themselves. The directory helps you find solutions that are powered by Stedi’s API-first clearinghouse rails.

For more information, see the announcement blog.

You can now authorize Stedi to sign enrollment forms for you using delegated signature authority, eliminating over 90% of your team’s enrollment paperwork.

Delegated signature authority is available to all Stedi customers. To get started, reach out to Stedi support.

For more details, see the blog.

You can now see whether a payer supports medical or dental transactions using the Payers API and Stedi Payer Network.

Every payer in the network now includes a coverageTypes field in responses from Payers API endpoints. For example, in JSON responses:

{
  "items": [
    {
      "displayName": "Blue Cross Blue Shield of North Carolina",
      "primaryPayerId": "BCSNC",
      ...
      "coverageTypes": ["dental"]
      ...
    }
  ]
}

If you’re using the Search Payers API endpoint, you can also filter by coverage type. Example:

GET /payers/search?query=blue+cross&coverageTypes=dental

For more details, see the blog.

You can now run batch 270/271 eligibility checks by uploading a CSV file in the Stedi portal.

Use the new Eligibility check batches page to run batch checks using a bulk CSV:

• Submit up to 1,000 checks per file.

• Run multiple files at the same time.

• Pull results from any batch using the Poll Batch Eligibility Checks API.

Track all batches – CSV or API – in real time, in one place.

For more details, see the blog.

You can now use the List Payers CSV API to get a full list of Stedi’s supported payers in CSV format:

curl --request GET \
  --url https://healthcare.us.stedi.com/2024-04-01/payers/csv \
  --header 'Authorization: <api-key>'

The CSV includes the same data as the Stedi Payer Network UI and other JSON-based Payer APIs:

• Payer IDs

• Transaction support flags

• Transaction enrollment requirements, and more.

For complete details, see the List Payers CSV API docs.

When the status of a transaction enrollment request changes, Stedi now sends you an automated email.

No setup is needed. These email notifications replace our previous manual notification process.

If an enrollment requires action on your part, we’ll continue to reach out to you via Slack or email with next steps.

For more information, check out our related blog.

CAQH CORE has officially certified Stedi for real-time eligibility checks.

This certification confirms that our 270/271 transactions meet CORE’s strict standards for:

• What data a 271 response must include

• Standardized error messaging

• System uptime and performance under real-world conditions

For more details, see our CORE certification blog.

You can now submit transaction enrollments to select payers in a single step.

Just submit an enrollment request using Stedi’s Enrollments API, UI, or a bulk CSV import. We do the rest.

One-click enrollment is available for 850+ payers. Check the Stedi Payer Network or Payer APIs to see which payers are supported.

To learn more, see our full blog.

Stedi now has a direct connection to Zelis, a multi-payer provider platform.

Many payers use Zelis as their primary way of delivering 835 Electronic Remittance Advice (ERA) files through clearinghouses to providers.

To receive ERAs from Zelis, providers must set up an account in the Zelis portal. This involves selecting a clearinghouse from a prepopulated list. Previously, providers using Stedi had to select an intermediary clearinghouse in order to receive ERAs.

With Stedi’s new direct Zelis connection, you can now choose Stedi from the list of integrated clearinghouses. Once set up, you’ll automatically receive ERAs from all Zelis-connected payers directly through Stedi.

To submit new enrollment requests, use the Enrollments API, UI, or a bulk CSV import. For Zelis-connected payers, we’ll instruct you to select Stedi as the clearinghouse in Zelis when needed.

If you previously submitted a Stedi enrollment for a Zelis-connected payer, you can log into Zelis and select Stedi as the clearinghouse to transition to Stedi’s direct Zelis connection without any interruption or downtime.

For details, see the blog.

Stedi has partnered with Anatomy, a modern healthcare lockbox and document conversion service, to help you turn paper explanations of benefits (EOBs) into standard 835 Electronic Remittance Advice (ERA) transactions.

Previously, providers receiving paper EOBs had to scan and manually enter payment data, slowing down posting and introducing errors. You can now use Anatomy to handle paper EOBs using your existing digital workflow.

Anatomy accepts paper or PDF EOBs and converts them into 835s. Anatomy then securely sends the 835s to Stedi on your behalf. In Stedi, you can enroll to receive 835s from Anatomy just like you would if they were a payer. You get the ERAs using the 835 ERA Report API or the from-stedi directory of your Stedi SFTP connection. You can use webhooks to get notified when new ERAs are available.

Anatomy is now listed as a supported payer in the Stedi Payer Network. For more details, see the blog.

You can now use the Search Payers API to programmatically search the Stedi Payer Network.

The API lets you search by the payer’s name, payer ID, or payer ID alias. The search supports fuzzy matching, so it returns close matches even if the provided payer name isn’t exact. You can further filter the results by supported transaction types, like dental claims (837D) or eligibility checks (270/271).

The following request searches for the “Blue Cross” payer name and filters for payers that support eligibility checks and real-time claim status.

curl --request GET \
  --url https://healthcare.us.stedi.com/2024-04-01/payers/search?query=Blue%20Cross&eligibilityCheck=SUPPORTED&claimStatus=SUPPORTED \
  --header 'Authorization: <api-key>'

Visit the Search Payers API docs for complete details.

We’ve also updated the Stedi Payer Network UI to use the new API. You now get consistent search results across the UI and API.

You can now include claim attachments in API-based 837P professional and 837D dental claim submissions.

For more information, see the announcement blog.

You can now request up to 200 results per page when using the pageSize query parameter in the Poll Batch Eligibility Checks API. The previous limit was 10.

With the higher limit, you can retrieve larger sets of eligibility results with fewer API requests.

GET /2025-04-25/healthcare/eligibility/poll-batch?batchId=abc123&pageSize=200

Visit our batch refresh checks docs for complete details about batch eligibility checks.

The Batch Eligibility Check (270/271) API now supports up to 1,000 eligibility checks per batch. Previously, batches were limited to 500 checks each.

The Batch Eligibility Check (270/271) API lets you submit multiple eligibility checks in a single request, which Stedi processes asynchronously. You can use batch checks to run periodic patient eligibility refreshes before appointments, preventing surprises and billing delays.

Visit our batch refresh checks docs for complete details about batch eligibility checks.

The 277 Claim Acknowledgment (277CA) indicates whether a claim was accepted or rejected and (if relevant) the reasons for rejection. You may receive multiple separate 277CAs for each claim you submit to Stedi. Typically, this includes:

• 277CAs from Stedi reflecting whether the claim was sent to the payer or rejected due to validation issues.

• A 277CA from the payer indicating whether the claim was accepted or rejected.

The 277CA Report API now returns additional properties in the transactions.payers array that allow you to quickly determine whether the 277CA was sent by Stedi or the payer. The organizationName property contains the sender's name (such as STEDI INC, or CIGNA), and the entityIdentifierCodeValue property contains either Clearinghouse or Payer.

"payers": [
  {
     "entityIdentifierCode": "AY",
     "entityIdentifierCodeValue": "Clearinghouse",
     "etin": "117151744",
     "organizationName": "STEDI INC"
  }
]

We also added this information to the top of the 277CA details view in the Stedi portal for easy access. 

Visit our claim responses docs for complete details about interpreting and retrieving 277CAs.

Eligibility checks verify a patient's coverage with a specific payer. But what if you don't know the patient's insurance details or you're not sure whether they have coverage at all? Now, you can run an insurance discovery check to find a patient's active coverage using only their demographic data.

You may need to run an insurance discovery check when a patient provides outdated insurance details, doesn’t have their insurance card, or can’t provide insurance details in an urgent care situation. You may also want to use insurance discovery checks to simplify patient onboarding.  

Here's how insurance discovery checks work:

1. Submit a request to the Insurance Discovery API with as much patient demographic information as possible to increase the chances of finding matching coverage. You'll also include information like the provider's NPI and the date of service, similar to an eligibility check.

2. Stedi uses the demographic information you provide to determine if the patient has active coverage with one or more payers. This process involves submitting real-time eligibility checks to supported payers to find a match. 

3. When the insurance discovery check is complete, Stedi returns an array of potential active coverages along with subscriber details and complete benefits information.

There is no cost for limited insurance discovery checks while the API is in beta. If you are interested in pricing when the product is generally available, please contact us.

Visit our Insurance Discovery docs for complete instructions, example requests and responses, and more.

The 835 ERA Report API retrieves 835 Electronic Remittance Advice (ERA) transactions from Stedi in developer-friendly JSON. The ERA data now contains full Claim Adjustment Reason Code (CARC) and Remittance Advice Remark Code (RARC) descriptions, making it easier to interpret the payer’s response. 

CARC codes describe why a claim or service line was paid differently than it was billed. Now, adjustments objects for both the claim and specific service lines contain an adjustmentReason property with the full code description. The following example shows the adjustmentReason1 property within the transactions.detailInfo.paymentInfo.serviceLines.serviceAdjustments object.

"serviceAdjustments": [
  {
    "adjustmentAmount1": "21",
    "adjustmentReasonCode1": "131",
    "adjustmentReason1": "Claim specific negotiated discount."
    "claimAdjustmentGroupCode": "CO",
    "claimAdjustmentGroupCodeValue": "Contractual Obligation"
  }
]

RARC codes provide additional explanations for adjustments or convey information about remittance processing. Now, transactions.detailInfo.paymentInfo.claimAdjustments.serviceLines.healthCareCheckRemarkCodes objects contain an additional remark property with the full code description. 

"healthCareCheckRemarkCodes": [
  {
    "codeListQualifierCode": "HE",
    "codeListQualifierCodeValue": "Claim Payment Remark Codes",
    "remarkCode": "M30",
    "remark": "Missing pathology report."
  }
]

This new endpoint allows you to use a Stedi business identifier (the claim’s correlation ID) to retrieve the CMS-1500 PDF for submitted 837 professional claims.

1. Call the endpoint with the business identifier as a query parameter for the claim form PDFs you want to retrieve. The business identifier should be the claim’s correlation ID. You can find this value in the claimReference.correlationId property in the synchronous responses from the Professional Claims and Professional Claims Raw X12 endpoints.

2. Stedi returns an array of PDFs for all claims with the specified business identifier value. The PDFs are returned as a base64 encoded string. 

3. Decode the base64 string and save it to a file with a .pdf extension.

Visit the CMS-1500 PDF: Business Identifier API docs for complete details.

Test mode provides a separate test environment where you can simulate transactions in your Stedi account without PHI/PII and without sending any data to payers. 

In test mode, you can submit mock real-time eligibility checks and Stedi sends back a realistic benefits response so you know what kinds of data to expect in production. You can send mock requests for a variety of well-known payers, including:

• Aetna

• Cigna

• UnitedHealthcare

• National Centers for Medicare & Medicaid Services (CMS)

• Many more - Visit Eligibility mock requests for a complete list

After you submit a mock eligibility check, you can review all of the request and response details in Eligibility Manager. This includes a user-friendly benefits view designed to help you quickly understand the patient’s active coverage and payment responsibilities.

To access test mode in your account, toggle Test mode to ON. Visit the test mode docs for more details.

You can use Stedi’s fully-managed SFTP server to submit claims to payers and retrieve claim responses. Stedi SFTP is a great option if you have an existing system that generates X12 EDI files and you want to send them through the Stedi clearinghouse without an API integration.

Here’s how SFTP claims processing works:

1. Create both test and production SFTP users through the Healthcare page in Account settings. Test users can only send claims to Stedi’s test clearinghouse, which helps ensure you never accidentally send test claims to payers while you’re getting up and running.

2. Connect to Stedi's server and drop compliant X12 EDI claim files into the to-stedi directory. 

3. Stedi automatically validates the claim data. If there are no errors, Stedi routes your claims to the test or production clearinghouse.

4. Stedi places claim responses - 277 Claim Acknowledgments and 835 Electronic Remittance Advice (ERAs) - into the from-stedi directory in X12 EDI format. 

5. You retrieve claim responses from the SFTP server at your preferred cadence.

You can also configure Stedi webhooks to send claim processing events to your endpoint. This allows you to monitor for processing issues, confirm successful claim submissions, and get notified when new payer responses are available.

Visit the SFTP claim submission docs for complete details.

Developers and operations teams can now submit transaction enrollments to payers using bulk CSV import functionality. This allows you to submit hundreds of enrollment requests to Stedi in minutes. 

Here’s how it works:

1. Go to the Bulk imports page and click New bulk import.

2. Download the CSV template with the required fields. The upload page contains detailed formatting instructions. 

3. Complete and upload the CSV file containing enrollment information—one row equals one enrollment request for a specific transaction to a payer. 

4. Stedi checks the file for errors and notifies you of any issues. You can fix the errors and re-upload the file as many times as needed. 

5. Once you execute the import, Stedi automatically creates provider records and enrollment requests. 

6. When the import is complete, you can download a report that shows the status of each row in the CSV file to ensure all your enrollment requests were submitted successfully. You can also track the status of each new enrollment request through the Enrollments page.

7. The Stedi team will contact you with any additional information required for the enrollment and will let you know when it is live.

Visit the Stedi Payer Network to find out if a payer requires enrollment for a particular transaction type.

A Medicare Beneficiary Identifier (MBI) is a unique, randomly-generated identifier assigned to individuals enrolled in Medicare. You must include the patient’s MBI in every eligibility check you submit to the Centers for Medicare and Medicaid Services (payer ID: CMS). When patients don’t know their MBI, you can use Stedi's eligibility check APIs to perform an MBI lookup using their Social Security Number (SSN) instead.

To perform an MBI lookup:

1. Construct an eligibility check request with the patient’s first name, last name, date of birth, and Social Security Number (SSN).

2. Set the tradingPartnerServiceId to MBILU. This is a special payer ID that tells Stedi to perform an MBI lookup for the patient in addition to a standard eligibility check.

3. Stedi returns a complete benefits response from CMS with the patient's MBI in the subscriber object for future reference.

Visit our Medicare Beneficiary Identifier (MBI) lookup docs for complete details.

The view for 277CA Claim Status transactions includes the following improvements:

• Key claim details, including the patient account number and the claim value, are at the top for easy access.

• Claim Status codes are displayed with clear descriptions, and processing issues are flagged to help you quickly catch errors and understand what went wrong.

• Related transactions, including the original claim, are identified and linked.

• The transaction’s raw input and output are available for review and download. 

To check out the updated view, click any 277CA Claim Status transaction listed on the Stedi Transactions page.

You can now submit coordination of benefits (COB) checks through the Coordination of Benefits Check API for any of Stedi’s supported COB payers.

• You submit COB checks programmatically in developer-friendly JSON. The information required is similar to a standard eligibility check – the patient's first name, last name, DOB, and either member ID or SSN.

• Stedi synchronously returns summary information about each of the patient’s active health plans and whether there is coverage overlap. When there is coverage overlap, Stedi returns the responsibility sequence number for each payer (such as primary or secondary, if that can be determined).

Visit the Coordination of Benefits Check API documentation for full details, test requests and responses, and more.

You can now create test API Keys for development and integration testing. 

Test API keys allow you to conduct integration testing on specific Stedi APIs without sending data to partners or processing PHI or PII. You can generate production and test API keys from the API Keys page in your Stedi account.

At launch, test API keys support hitting the Real-Time Eligibility Check API with the mock requests we have available. We will add support for other APIs in the near future. All mock requests sent with a test API key are free for testing purposes and won’t incur charges in your Stedi account.

When a patient is covered by more than one health plan, you need to know which plan is primarily responsible for paying claims (coordination of benefits). You can now submit coordination of benefits (COB) checks in the Stedi UI to determine:

• If a patient is covered by more than one health plan

• Whether coverage overlap requires coordination of benefits

• Each payer’s responsibility for payment (primacy) in coordination of benefits scenarios

For each COB check, Stedi searches a national database of eligibility data from state and commercial payers. This database has 245+ million patient coverage records from 45+ health plans, ASOs, TPAs, and others, including participation from the vast majority of national commercial health plans. Data is updated weekly to ensure accuracy.

The response includes information about the patient’s active health plans, whether coordination of benefits is required, and the responsibility sequence number for each payer if available (such as primary or secondary).

To help reduce claim denials, we recommend coordination of benefits checks for all new patients with coverage through one of Stedi’s supported COB payers. Visit the Payer Network for a complete list.

Developers and operations teams can now submit enrollments one at a time or in batches through Stedi’s user-friendly Enrollments dashboard or modern Transaction Enrollment API. 

Both submission methods follow the same streamlined process:

1. Add provider: You add a new provider record with the information required for enrollment, including the provider's name, tax ID, NPI, and contact information.

2. Submit transaction enrollment request: You submit requests to enroll the provider with required payers, one for each transaction type. For example, you’d submit three separate requests to enroll a provider for 837P (professional) claims, 270 real-time eligibility checks, and 835 ERAs (claim payments). You can save requests in DRAFT status until you're ready to submit them to Stedi. Once you submit an enrollment request, its status is set to SUBMITTED, and it enters Stedi’s queue for processing.

3. Provisioning: Stedi begins the enrollment process with the payer and sets the enrollment status to PROVISIONING. Our team leaves clear instructions about what to do next, if required, and provides hands-on help as needed with additional steps.

4. Enrollment is Live: Once the enrollment is approved, the enrollment status is set to LIVE, and the provider can start exchanging the enrolled transactions with the payer.

You can find out if a payer requires enrollment for a particular transaction type in the Stedi Payer Network.

You can use Stedi’s new Dental Claims API to send 837D (dental) claims through the Stedi Clearinghouse:

• Dental Claims: Submit your claim in user-friendly JSON. Stedi translates your request to the X12 EDI 837D format and sends it to the payer.

• Dental Claims Raw X12: Submit your claim in X12 EDI format. This is ideal if you have an existing system that generates X12 EDI files and you want to send them through Stedi’s API.

Both endpoints return a response from Stedi in JSON format containing information about the claim you submitted and whether the submission was successful. Later, the payer will respond with Claim Acknowledgments (277CA) and the ERA (835), which you can retrieve using Stedi’s APIs.

Visit the Stedi Payer Network to find every supported payer for dental claims.

You can now use Stedi’s Batch Eligibility Check API to submit multiple eligibility checks in a single request for Stedi to process asynchronously.

You can submit up to 500 individual eligibility checks within a single batch, and you can submit as many batches as you need to process. After you’ve submitted a batch of eligibility checks, you can use the Poll Batch Eligibility Checks endpoint to retrieve the results.

We recommend using this new API to perform batches of eligibility checks, such as during periodic refreshes for a patient population or when running weekly eligibility checks for upcoming appointments. Asynchronous batch checks don’t count toward your Stedi account concurrency budget, allowing you to stage thousands of batch checks while continuing to send real-time eligibility checks in parallel.

You can use the new Institutional Claims API to send 837I institutional claims through the Stedi clearinghouse.

• Call the endpoint with a JSON payload.

• Stedi translates your request to the X12 EDI 837I format and sends it to the payer.

• The endpoint returns a response from Stedi in JSON format containing information about the claim you submitted and whether the submission was successful.

• Later, the payer will respond with Claim Acknowledgments (277CA) and the ERA (835), which you can retrieve using Stedi’s APIs.

You can now submit five new mock requests for dental benefits to the Eligibility Check endpoint, and Stedi returns mock eligibility responses you can use for testing. To send a mock request, you need a Stedi API key for authentication, and you must set the stedi-test header to true.

Try it now for Ameritas, Anthem Blue Cross Blue Shield of CA, Cigna, Metlife, and UnitedHealthcare.

Use the new List Payers API to programmatically retrieve information about thousands of supported payers in our Payer Network. 

The following Blue Cross Blue Shield of North Carolina response example shows that real-time eligibility checks, real-time claim status requests, and professional claims are supported for this payer. The response also indicates that payer enrollment is required for 835 ERAs (claim remittances).

{
  "stediId": "UPICO",
  "displayName": "Blue Cross Blue Shield of North Carolina",
  "primaryPayerId": "BCSNC",
  "aliases": [
    "1411",
    "560894904",
    "61473",
    "7472",
    "7814",
    "BCBS-NC",
    "BCSNC",
    "NCBCBS",
    "NCPNHP"
   ],
   "names": [
     "Blue Cross Blue Shield North Carolina"
   ],
   "transactionSupport": {
     "eligibilityCheck": "SUPPORTED",
     "claimStatus": "SUPPORTED",
     "claimSubmission": "SUPPORTED",
     "claimPayment": "ENROLLMENT_REQUIRED"
   }
}

We adapted the National Uniform Claim Committee (NUCC) 1500 Claim Form into a user-friendly digital form you can use to submit claims manually. 

Our in-app form validates provider NPIs and other key information to reduce errors and payer rejections. You can also review a live preview of the autogenerated JSON payload for our Professional Claims API to understand how the form relates to the request structure.

To submit a manual claim, visit the Create manual claim page in the Stedi app.

You can now use the CMS-1500 Claim Form PDF API to programmatically retrieve auto-generated claim forms for submitted 837 professional claims. All you need is an API Key for authentication and Stedi’s transaction ID for the processed claim. 

curl --request GET \
  --url https://healthcare.us.stedi.com/2024-04-01/export/{transactionId}/1500/pdf \
  --header 'Authorization: <api-key>'

You can use the API to make auto-generated claim form PDFs available for download within an EHR, practice management, or revenue cycle system. You can also automate retrieving them for internal use, such as record-keeping, mailing and faxing claims to payers, or reviewing claim information in a familiar format.

Stedi can now automatically generate and deliver negative TA1s for inbound transactions. TA1 Interchange Acknowledgments indicate receipt of an interchange and identify any errors in the interchange’s envelope (ISA and IEA) information.

Stedi can generate two types of negative TA1s:

• Accepted with errors: TA1s with code E in TA104 indicate that the interchange was accepted with errors. Stedi proceeds with processing the transaction and creates a record in the Stedi app

• Rejected because of errors: TA1s with code R in TA104 indicate that the interchange was rejected and that Stedi won’t continue processing the transaction.

You can enable automatic TA1s in each partnership’s Acknowledgments settings. Visit the Acknowledgments documentation for complete details. 

You can use the new List Payers API to programmatically retrieve information about every supported payer in our Payer Network. The response includes:

• The payer’s name, payer ID, payer ID aliases, and alternative names.

• Whether the following transactions are supported: real-time eligibility checks, professional claims, real-time claim status requests, and ERAs (claim payments).

• Whether payer enrollment is required for each transaction type.

Stedi can now automatically generate positive TA1s for inbound transactions and deliver them to your trading partners. 

TA1 Interchange Acknowledgments indicate receipt of an interchange and identify any errors in the interchange’s envelope (`ISA` and `IEA`) information. Positive TA1s contain code `A` in the `TA104` element to indicate you received the interchange successfully, and it contains no errors.

Enable automatic TA1s for each partnership in the Acknowledgments settings. You can send TA1s for every inbound file or only when your trading partner requests them. Visit the Acknowledgments documentation for complete details. 

The transaction details page has the following improvements:

• For 837P (professional) claims, Stedi automatically puts key details, including subscriber information and the claim value, at the top for easy access. You can also instantly download a PDF of the autogenerated 1500 Claim Form. 

• Transactions with a common business identifier are clearly identified and linked, so you can easily move between related transactions.

• The transaction’s raw input and output are available for review and download. 

• Multiple other UX updates to make the transaction’s data easier to understand and digest.

You can review this information by clicking any transaction on the Transactions page in the Stedi app.

You can now use the following APIs to retrieve payer responses in JSON format:

• Get 277 Report: Retrieve processed 277 Claim Acknowledgments

• Get 835 Report: Retrieve processed 835 Electronic Remittance Advice (ERA) transactions

You can either poll or listen for event-driven webhooks to discover new payer responses. Then, you can call the Report APIs to retrieve the processed responses from Stedi. For convenience, Stedi returns 277s and 835s in the same JSON format as the Change Healthcare (CHC) Convert Reports APIs.

For every claim you submit through our Professional Claims APIs, Stedi now automatically generates a complete 1500 Claim Form. You can download these PDF claim forms from the transaction detail page for that claim in the Stedi app.

This feature is useful when you need to export claim forms for record-keeping purposes, physically mail a claim to a payer, or review specific claim information in a familiar format. 

You can now review a mapping’s version history, compare older versions with the current, and instantly roll back to any published version. This functionality helps you better understand the updates made in each version and debug issues in production mappings.

To review a mapping’s version history, go to the mapping, open the Actions menu, and select Version history. You can choose to publish an older version or compare it with the current version in production. Comparing highlights every difference between the old and current versions to show you what has been added or deleted.

The following APIs are now available for customers who want to send raw X12 EDI to payers. These APIs are ideal for companies that generate X12 EDI internally and want to use Stedi to validate and deliver these transactions to payers.

• Eligibility Check Raw X12: Send raw X12 EDI 270 Eligibility Benefit Inquiry transactions and receive the payer’s raw X12 EDI 271 Eligibility, Coverage, or Benefit Information in the response - all in real time.

• Professional Claims Raw X12: Send raw X12 EDI 837P (professional) Health Care Claims to payers.

• Claim Status Raw X12: Send raw X12 EDI 276 Claim Status requests and receive the payer’s raw X12 EDI 277 Status Request Response - all in real time.

You can now send eligibility checks to more than 200 dental payers through Stedi’s growing Payer Network. New dental payers include Guardian, Delta Dental, UHC Dental, Anthem Blue Cross Blue Shield, Pacificare Dental & Vision Plan, Aetna Dental, Cigna Dental, and more.

Search the Payer Network to instantly find the payer ID for any payer and use it to start sending real-time eligibility checks through Stedi’s Eligibility Check API.

We redesigned the Stedi Payer Network to make it more comprehensive and user friendly. Improvements include:

• Enhanced searching and filtering capabilities so you can instantly find the payers you need for your use case.

• Alternative payer names to help you identify payers using the name most familiar to your organization. For example, “Eaton Benefits Ohio” is an alternative associated with “Cigna”—searching for either name returns the same payer within the database. 

• UX improvements, including clearly showing all of the transaction types supported for each payer as well as the payer ID and any payer ID aliases.

The Mappings UI now autosaves your changes and stages them for publishing. When you’re ready, you can promote changes to production by clicking Publish changes. You can also discard changes to revert back to the previously published version.

You can now submit mock requests to the Eligibility Check endpoint, and Stedi returns mock eligibility responses you can use for testing. To send a mock request, you need a Stedi API key for authentication, and you must set the stedi-test header to true.

Try it for Cigna.

The List Transactions and Poll Transactions APIs now return business identifiers for each transaction.

Business identifiers are values you can use to correlate a transaction with related transactions or other data in your business system. For example, Stedi automatically marks the purchase order number (PRF01) as a business identifier for 850 Purchase Orders. 

The following example shows a truncated API response containing the new businessIdentifiers object.

You can now set custom filenames for generated EDI files within outbound transaction settings.

By default, Stedi autogenerates a unique name for outbound files using a UUID. To specify a custom filename, open Advanced settings in the outbound transaction setting and enter a JSONata expression into the Filename expression field. 

You can use & (Concatenation) or $millis in the expression to generate a unique name based on the processing timestamp. For example, the expression “EDI850-” & $millis() results in filenames like EDI850-5182341242.

You can now lock mappings in your account to prevent accidental changes or deletions. Any user in your Stedi account can lock a mapping, but only an account admin can unlock it. 

You can lock the entire mapping or just the mapping definition. When you lock the mapping definition only, you can add or edit lookup tables, but you cannot edit the mapping source schema, target schema, or mapping expressions. 

To lock a mapping, open it, click the ...(ellipses) menu next to its name, and select Lock settings.

We released the following EDI platform features:

You can now lock guides in your account to prevent accidental changes or deletions. Any user in your Stedi account can lock a guide, but only an account admin can unlock them. To lock a guide, go to the Actions menu and select Lock.

When configuring an outbound test file, you can now review the EDI that Stedi will generate from your JSON test data. To generate an outbound test file, go to the Files page, open the Create file menu, and select Test outbound.

The new Map Transaction Output endpoint applies a Stedi mapping to a previously processed inbound transaction and returns the fully mapped output.

You can use the endpoint to retrieve processed transaction data asynchronously and ingest it into your business system. This approach can be helpful when the mapped output is too large for Stedi to deliver through a Destination webhook.

Introducing the Stedi Payer Network - a comprehensive list of every payer Stedi supports for eligibility checks, claim submission, and claim status checks. You can search by the payer’s name or payer ID alias to retrieve their payer ID, learn which Stedi APIs are supported, and determine whether or not the payer requires provider enrollment.

The Eligibility Check API now returns detailed AAA error messages that specify why the payer rejected the transaction and any recommended follow-up actions. Stedi includes this information in the aaaErrors object in the response JSON.

The following example shows an error at the subscriber level:

Visit our eligibility check troubleshooting docs for a complete list of all possible error types and resolution steps.

Our Professional Claims API now automatically replaces non-Latin characters with their Latin equivalents. 

Claim submissions with non-conforming characters are a common cause of 999 rejections from the payer. The new autocorrect feature will help reduce these types of errors and the (often significant) time and manual work it takes to fix them.

When you perform a manual eligibility check through the Stedi app, you can now review a more user-friendly 271 Eligibility, Coverage, or Benefit Information response organized by coverage type and level. Click a row to review more details about the benefit type, including the Service Type Code (STC) and the raw JSON response data. 

Submitting a manual eligibility check can be useful for testing and when you need to do a one-time eligibility check. Learn more about eligibility checks in our docs.

Stedi’s Claim Status endpoint directly replaces the Change Healthcare (CHC) Claim Status API. You can use it to check the status of an existing claim.

• Call Stedi’s endpoint with a JSON payload in the CHC 276 Claim Status format.

• Stedi automatically maps CHC payer IDs to our IDs.

• Stedi translates the JSON to the X12 EDI 276 format and delivers it to the payer or peer clearinghouse.

• The endpoint returns a synchronous 277 response in the CHC Claim Status response JSON format.

Visit the Claim Status API docs for more information. 

From the Eligibility menu in the Stedi app, you can now perform the following actions:

Submit manual eligibility checks and review the full 271 JSON response. This feature is useful for testing and for operations teams who need to do one-off checks.

Review errors for every eligibility check you send through the Stedi API and the app. You can filter by payer or timeframe (last hour, last day, or last week) and view details about each error code.

The Stedi app now displays Destination webhook delivery attempts to help with testing and debugging. This page includes metadata about the delivery attempt, including the destination, the time of the attempted delivery, and detailed logs about each delivery stage. 

To review delivery attempts, click a processed file or transaction, click any event to view its details page, and then go to the Destination attempts tab.

Stedi can now validate and translate inbound EDI files containing multiple interchanges. The interchanges in the file must have the same partnership and direction (matching sender and receiver IDs). 

Learn more about inbound file processing.

You can now require all users to enable Multi-Factor Authentication (MFA) before accessing your Stedi account. To enforce MFA for all users:

1. Click the account name.

2. Select Account settings and toggle MFA to ON.

The next time each user logs into the account, Stedi prompts them to set up their MFA token. Once you enable MFA for a Stedi account, it cannot be disabled.

The following improvements make it easier to build and update Stedi mappings.

You can now view more context about Stedi guide segments and elements when you hover over them, allowing you to understand which part of the guide you are mapping more easily. This is especially helpful for large guides, including many X12 HIPAA guides, that repeat the same loop or segment in multiple locations. 

You can now search within a mapping’s source or target fields for a specific text string and jump to each matching value. For example, you might search for the name of a specific segment or element.

Connections and Destination webhooks now apply an automatic filter that displays the last hour of logs by default. You can remove or adjust this time filter as needed. 

It’s now easier to build custom healthcare guides that conform to X12 HIPAA specifications. When creating a new guide, set the X12 Release to 5010 HIPAA. Stedi automatically preloads every HIPAA transaction set from the Stedi Network for you to choose as a base for customization. 

Stedi guides are machine-readable versions of the EDI requirements trading partners typically provide as PDF, CSV, or Word documents. You can use Stedi’s guide builder to customize any X12 HIPAA transaction for your EDI integration. Then, you can make your guides public to share them with trading partners as user-friendly, interactive web pages.

The Generate EDI API now supports idempotent requests. 

When you send a request to the Generate EDI API, you can include an idempotency key to prevent sending duplicate data to your trading partners. In the event of network errors or other intermittent failures, you can safely retry requests with the same idempotency key as many times as necessary within 24 hours after making the first request. Learn more.

We made the following improvements to the Stedi app:

Execution metadata: You can now view file execution metadata, which includes the X12 Interchange and Functional Group values, along with other processing information. To view a file’s execution metadata, go to the Files page, click the file you want to view, and select Raw Metadata in the Results tab.

Event retries: You can now retrigger individual events from both the transaction details page and the file details page. 

AS2 certificate validation: Stedi now gives you immediate feedback about errors in your local and partner signing and encryption certificates. For example, you will now receive an error when your certificate is improperly formatted, when a certificate doesn’t validate against a certificate chain, when a public and private key pair don’t match, and more.

You can now find the following X12 HIPAA guides in the Stedi Network:

• Application Advice (X186A1)

• Health Care Services Review Information - Acknowledgment (X216)

• Health Care Services Review Information - Notification (X216)

• Patient Information (X210)

• Health Insurance Exchange Related Payments (X306)

The Stedi Network is a free and open catalog of Stedi guides for hundreds of popular trading partners. You can import any X12 HIPAA guide into your account for free and use it in your EDI integration. 

Request guides: If you don’t see your partner’s guides in the Stedi Network, submit a request, and we’ll build the guides you need for free in 1-2 business days.

We updated the authorization scheme in our API to better align with OpenAPI specifications.

The Authorization header no longer requires the Key prefix. Instead, you should now provide API keys directly (Authorization ${STEDI_API_KEY}). This change aligns with the OpenAPI standard and allows for out-of-the-box compatibility with OpenAPI tools and services.

Previously, our APIs required API keys to be passed with a Key prefix (Authorization: Key ${STEDI_API_KEY}), which required manual setup to work with OpenAPI. We will continue to support the previous format for backward compatibility, but we encourage you to adopt the new format to leverage the benefits of OpenAPI compliance.

You can now read and write EDI for X12 release 008050, the latest version approved in December 2023 and released in February 2024. Stedi now supports every release from 002001 (released in 1987) to present.

The 008050 release is supported throughout the entire Stedi platform. You can review every 008050 transaction set in EDI Reference, create PDF and machine-readable 008050 Stedi guides for your trading partners and EDI integrations, and process live 008050 transactions instantly.

Stedi Destinations now pre-fills the grant_type header for OAuth 2.0.

When you create or edit a Stedi Destination with OAuth 2.0 configured, the Header parameter grant_type is now pre-populated with client_credentials. This is the most common grant type used when the client is acting on its own behalf. You can change this value in the Advanced menu if you need to use a different grant type.

This change helps ensure that your OAuth 2.0 connections are set up correctly and securely, without extra manual configuration.

For more details on the OAuth 2.0 protocol, visit RFC 6749 section 4.4, which outlines the protocol for the client credentials grant.

You can now set a custom Interchange Version Control Number Code (ISA-12) for generated EDI files. 

When you call the Generate EDI API, the outbound transaction setting ID you provide dictates which Stedi Guide will be used for validation and translation. By default, Stedi sets ISA-12 to be the X12 release number of the associated guide. However, some trading partners may require that you specify a different release for the transaction and the ISA envelope – for example, you might send a transaction from X12 release 003020 inside an ISA envelope with an Interchange Version Control Number Code of 00401.

Visit the Generate EDI docs for complete details about ISA and GS overrides.

You can now use Stedi to read and write any transaction set from all releases in the 1980s-era X12 Version 2:

• 002001 | Release year: 1987

• 002002 | Release year: 1988

• 002003 | Release year: 1988

• 002040 | Release year: 1989

With this update, Stedi now has complete coverage of all transaction sets across all releases from X12 002001 to X12 008040.

Stedi also now supports custom GS-08 Industry Identifier Codes for all X12 releases when reading and writing EDI.

Industry Identifier Codes are the 1-6 characters appended to the end of a release in the GS-08 element – for example, 005010UCS and 004010VICS or 005010X279A1 in the X12 HIPAA standard. You can now define your own custom identifier for any transaction set as needed. Custom identifiers are helpful when trading with automotive OEMs such as Ford (which uses 002002FORD) and Chrysler (which uses 002040CHRY).

We consolidated the top navigation bar to make the Stedi app easier to use and understand. 

The top navigation is now organized into three sections:

• Files: Review, sort, filter, and inspect every file flowing through Stedi. This page was previously called File executions.

• Transactions: Review, sort, filter, and inspect every EDI transaction flowing through Stedi. 

• Setup: Access all the tools and configurations required to onboard and manage trading partners. This menu includes Trading partners, Guides, Destinations, EDI settings, and Mappings (if applicable). 

We also consolidated documentation and resources into a single menu and co-located key account admin pages, such as Account settings, under the account selection menu.

Stedi stores metadata about each successful file execution, such as the processing timestamp and X12 Interchange and Functional Group values. You can now retrieve this metadata through the following methods:

• The file.processed.v2 event includes a metadata artifact with a document download URL you can use to fetch the execution metadata.

• The Get Execution Metadata API returns a document download URL you can use to fetch the execution metadata. 

You can now retrigger events for successfully processed files. This feature makes it easier to test your end-to-end integration – for example, triggering webhooks – without continually reprocessing the same files.

To retry an event:

1. Go to the Files page.

2. Click the name of the processed file.

3. Go to the Events tab.

4. Click the ellipses (...) next to an event and select Retry.

The HIPAA 999 Implementation Acknowledgment is now available in the Stedi Network’s collection of X12 HIPAA guides. 

The Stedi Network is a free and open catalog of Stedi guides for hundreds of popular trading partners. Stedi guides are a machine-readable format for EDI requirements that Stedi uses to automatically validate, translate, and generate EDI according to trading partner’s requirements.

You can import the 999 into your account for free and add it to transaction settings for your EDI integration. 

Request guides: If you don’t see your partner’s guides in the Stedi Network, submit a request, and we’ll build the guides you need for free in 1-2 business days.

To make debugging easier, you can now set the log level for each Destination webhook. Destination webhooks allow you to send transaction data and events from Stedi to any external API. 

You can edit the webhook to switch between the following log levels at any time:

• OFF - no logs

• ERROR - errors only

• INFO - errors and select execution steps, such as successful deliveries

• TRACE - all execution steps

To review a webhook’s logs, click its name and then go to the Logs tab.

When building a Stedi mapping for reading EDI, you can now switch between the sample files attached to the source guide. Sample files typically represent the use cases when you could receive that transaction set from your trading partner. For example, the X12 HIPAA 834 Benefit Enrollment and Maintenance guide includes samples for adding subscriber coverage, canceling a dependent, changing subscriber information, and more.

As you switch between samples, Mappings dynamically updates the source JSON shape and the expected mapping results, so you can ensure your mapping works for each use case. 

The Mappings module is a powerful JSON-to-JSON transformation engine that helps you transform Guide JSON into and out of the shape you need for your business system. You can use Stedi’s visual mapper to build mappings for both inbound and outbound transactions.

You can now import your trading partner’s EDI guides directly from the Stedi Network when creating transaction settings. The Stedi Network has pre-built guides for hundreds of popular trading partners that you can use in your integration for free.

Stedi guides are a machine-readable version of the EDI requirements – sometimes called implementation guides – that your partner would typically provide as PDF, CSV, or Word documents. When you add a guide to a transaction setting, Stedi validates and translates (inbound files) or generates (outbound files) EDI according to the guide’s requirements. 

Request guides: If you don’t see your partner’s guides in the Stedi Network, submit a request and we’ll build the guides you need for free in 1-2 business days.

You can now configure transaction.processed.v2 event bindings to trigger a Destination webhook based on the following new filters:

• Connection: Inbound files from a specific connection. This option is useful when there are multiple connections within the same partnership. For example, you may set up a separate SFTP connection for test files and route them to a test endpoint.

• Mode: The transaction contains a specific value in the ISA-15 element, which is used in X12 to distinguish between test and production files. This option is useful when you want to send test and production data to separate endpoints.

Destination webhooks allow you to automatically send data and events from Stedi to any external API. You can configure one or more event bindings that conditionally trigger each webhook. The new Connection and Mode filters are available under the Advanced menu.

You can now programmatically retrieve the generated EDI files that Stedi has delivered to your trading partner.

Stedi emits a file.delivered.v2 event every time a file is successfully delivered to a connection for an outbound transaction set. These events now include an output URL in an event.detail.artifacts object. You can use this URL to fetch the generated EDI file, including its envelope information.

You can now configure Remote FTP and FTPS connections in the Stedi app. 

For each partnership configuration in your Stedi account, you can set up one or more connection protocols to exchange files. When connecting to your partner’s remote server, you can choose between the FTP, FTPS, and SFTP protocols.

You can now use Mappings to automatically transform file.processed.v2 events into a custom JSON shape. You can then attach the mapping to a Destination webhook to automatically forward transformed event data to your API.

For every successful file execution, Stedi emits a file.processed.v2 event that includes information about when Stedi processed the file, the associated partnership configuration, the file size, and more.

Visit the Events documentation for complete details.

Stedi Mappings is our powerful JSON-to-JSON transformation engine. We recently made the following major improvements to the visual mapping tool:

• The visual mapper now shows warnings when the expected mapping output does not match the target JSON Schema. These warnings highlight issues such as invalid value types and missing properties to help you more easily create a complete, accurate mapping.

• We added a quickstart workflow that makes it easier to create new mappings. You can choose a quickstart for reading EDI (mapping transactions from Stedi to a custom shape for your API), writing EDI (mapping JSON from your system to the shape required for Stedi’s Generate API), and ingesting Stedi events (for example, mapping `file.failed.v2` events to a custom shape).

• To help you keep mappings up-to-date, we added clearer notifications when a connected Stedi guide has changed (for example, it has new segments or elements) and provided instructions for pulling those changes into your mapping.

You can now view detailed logs for each Destination webhook and filter them by a specific date range. The logs provide details about how the webhook is functioning, such as when each webhook is triggered and the response from the configured endpoint, which can help you troubleshoot issues. 

Destination webhooks allow you to send transaction data and events from Stedi to any external API. To view the logs for a destination, click its name to go to its details page, and then navigate to the Logs tab.

You can now set a custom filename for autogenerated acknowledgments to comply with your trading partner’s requirements.

Stedi can automatically generate a 997 Functional Acknowledgment or a 999 Implementation Acknowledgment for each inbound transaction and deliver it to a specified connection.

To set a custom filename, navigate to the partnership, turn on the Acknowledgments functionality, and enter a JSONata expression into the Filename expression field. For example, the expression "EDI997_" & $millis()would produce filenames that start with EDI997 and then contain a timestamp, such as EDI997-5182341242.edi.

You can now specify a regex expression for Stedi to use when retrieving files from a Remote SFTP/FTPS connection. When polling the remote server, Stedi only processes files that match the filter pattern.

For example, your trading partner may place files for multiple different entities on the remote server, with different prefixes for each entity. In this case, you could write a regex expression that matches only files with a given prefix.

You can specify a Filter pattern for the remote poller in the connection’s Inbound settings.

You can now use Stedi mappings to automatically transform file.failed.v2 events into a custom shape before sending them to external APIs.

Stedi emits file.failed.v2 events when it cannot parse an inbound EDI file, or it cannot deliver an outbound EDI file to the configured connection. You may want to automatically send these events to an external platform like Slack or Jira, so your team can receive alerts and monitor issue resolution.

You can now create a Stedi mapping to transform the file.failed.v2 event JSON into the shape your external systems can receive and ingest. Then, you can attach the mapping to a Destination webhook to automatically forward the transformed event data to your API.

You can now attach files to any Stedi guide and choose whether the attachments are public or private (only available to members of your Stedi account). 

Stedi guides are a machine-readable representation of the EDI specifications that your trading partners provide to you or that you provide to your trading partners. Attachments provide additional information about the guide. 

For example, you may want to add private attachments that help your team debug issues in your EDI pipeline, such as the original PDF specifications or a changelog. For a public guide, you may want to attach an appendix with a supplementary code list or a diagram that helps your partners understand the messaging flow.

To add attachments to a guide in your account, navigate to its Overview page, scroll to the Attachments section, and click Attach file.

You can now use OAuth 2.0 with Destination webhooks. 

Destination webhooks allow you to send transaction data and events from Stedi to any external API. To configure a destination webhook, you first create an auth configuration that defines how to authenticate with a set of URL endpoints. 

The OAuth 2.0 configuration includes setting the Authorization endpoint and parameters, the HTTP method, a client ID, and a client secret. You can create a new OAuth 2.0 configuration from the Event Destinations page.

Your trading partner may send you TA1 Interchange Acknowledgments in response to outbound EDI files.

Stedi now automatically processes inbound TA1s and displays the data in the File executions and Transactions pages for inspection.

You can also set the acknowledgmentRequestedCode outbound EDI files to request interchange acknowledgments from your trading partner. Visit the Generate EDI docs for details.

TA1s indicate receipt of an interchange and identify any errors in the interchange's envelope (ISA and IEA) information.

Stedi accounts on the Enterprise plan can now set an automatic data removal time frame in Stedi.

Artifacts refer to the transaction and file execution payloads from files Stedi has processed. They contain the actual input/output transaction data in EDI, JSON, or another format. You may want Stedi to remove artifacts after a certain time frame - for example, to comply with your company's PII/PHI retention policies.

Once you set a retention period, Stedi deletes artifacts after the retention window has passed. This affects both existing and future data in your account.

For example, if you set a retention period of 30 days and process a file today, Stedi will delete the artifact after 30 total days have elapsed. Stedi will also delete any artifact created more than 30 days prior. For more details on how artifact retention works, please visit the docs.You can set an automatic data removal time frame from the Settings page.

You can now generate and send inbound test files to simulate receiving a file from your trading partner. This is useful for testing your downstream integration, since the inbound file will trigger configured destination webhooks.

To generate an inbound test file:

1. Go to the File executions page or navigate into a partnership and click Test inbound.

2. Select a partnership and an Inbound transaction setting.

3. Autogenerate the test file from a sample EDI file in the guide or paste your own test data into the editor.

4. Click Ingest file.

Stedi immediately processes the generated file and triggers any configured webhooks. You can review the results on the File Executions and Transactions pages.

Stedi provides fully-managed AS2 connections that take care of the intricacies of AS2 and scale automatically to meet your demand. We recently made the following improvements:

• We added extensive conditional validation to reduce common configuration errors.

• You can now view and filter provisioning logs for each AS2 connection. These logs detail each step to create or update the connection, such as provisioning the certificates, making it easier to diagnose errors. To view provisioning logs, go to the partnership associated with the connection, and then click the connection to view its details page.

• When creating or updating an AS2 connection, Stedi now clearly indicates when there are previously uploaded encryption and signing certificates and provides the option to update them. Previously, adding or updating certificates was a separate workflow.

Stedi accounts on the Enterprise plan can now use fragments to split large transaction payloads from Stedi into smaller, more manageable chunks for downstream processing.

Large EDI files are often the result of transaction sets containing many repeated loops or segments. For example, a company may receive an 837 Health Care Claim file containing many insurance claims, or a retailer may receive an 846 Inventory Inquiry/Advice file containing millions of SKUs. To avoid overloading downstream systems, you can enable fragments on the repeated EDI segment.

Once enabled, Stedi splits the transaction payload into chunks based on that segment.For example, you might enable fragments on the LIN loop (list of inventory items) in an 846 Inventory Inquiry/Advice. For each processed 846, Stedi will emit fragment.processed.v2 events that each contain a chunk of LIN loop iterations.

You can create destination webhooks to automatically send fragment data to your downstream systems, or you can use the API to request the fragments for each processed transaction.

Stedi's guide builder now shows warnings when an ID element does not specify the set of allowed codes. You can see which fields are missing ID codes and specify the allowed values from the provided list or supply your custom codes.

Code warnings are available to help improve the quality of your guides, and you can ignore them without affecting Stedi's ability to use the guide for EDI processing. Warnings only appear for ID fields where the X12 specification includes the allowed code values. For example, they will not appear for State or Province codes.

Why element codes are important

ID element codes are a powerful component of the X12 EDI specification to provide additional information about data fields and reference well-known values. For example, you can use ID codes to specify the currency code of a monetary value, the meaning of a date value, or the reason for a shipment delay.

Many elements offer 1,000 or more possible codes, but most trading partners only expect to use just one or a few of these values. If a guide does not indicate which codes are accepted, trading partners often have to engage in costly follow-up with EDI departments or conduct multiple rounds of testing as they discover more code values in use.

The new warnings in Stedi's guide builder help ensure you and your trading partners work with the most accurate EDI specifications on the market.

Pre-built guides: Instead of building guides from scratch, you can find hundreds of free guides for popular trading partners in the Stedi Network.

You can now add a mapping to destination webhooks to automatically transform transactions before delivering them to external APIs.Stedi parses EDI files into Guide JSON, which reflects the structure of an EDI transaction in a modern format. You can use a mapping to transform Guide JSON into the shape required by your internal systems and business applications. Mappings provide a visual interface for building JSON-to-JSON transformations and are available in the Cloud and Enterprise plans.

To add a mapping to a destination webhook:

1. Use the mappings editor to create a transformation for the transaction.processed.v2 event. Visit the mappings documentation for instructions.

2. Select the mapping in the Mapping menu when creating a transaction.processed.v2 event binding. Visit the webhooks documentation for complete instructions.

You can now create partnerships faster by importing guides from the Stedi Network.

Partnerships contain transaction settings that define the EDI transaction sets you plan to exchange with that trading partner. For each transaction setting, you specify the EDI guide Stedi should use to validate data. The Stedi Network has pre-built guides for hundreds of popular trading partners that you can use in your integrations.

To import a partnership from the Stedi Network, go to the Trading partners page, click Create partnership, and choose Import from network. Visit the partnerships documentation for step-by-step instructions.

If you can't find your partner or guide in the network, you can submit a request, and we'll build it for you for free within 1-2 business days.

Stedi accounts on the Enterprise pricing plan can now use role-based access control (RBAC) to ensure only authorized users can access and modify account resources.

Admins can assign account members to one of four roles:

• Admin: These users can access and modify all resources within a Stedi account. This includes adding and removing members, assigning member roles, adding billing information, switching between pricing plans, configuring Partnerships, generating EDI files, and configuring resources like Mappings and Functions.

• Developer: These users can access and configure all resources, such as Partnerships, Mappings, and Functions.

• Operator: These users can access and configure Partnerships, Guides, and Mappings. They can interact with developer resources like Functions, but cannot modify them. For example, they can invoke existing Stedi functions, but cannot change them or add new functions.

• Read-only: These users can view account resources, but cannot modify them. For example, they can review processed transactions in Stedi's interface but cannot call the Generate EDI API or edit partnership details.

To change a member's role, go to Settings > Members in your account. Click the pencil icon for a member, choose a Role from the list, and click Update role.

You can now enable automatic 999 Implementation Acknowledgments for any Stedi partnership.

When you enable 999 acknowledgments for a partnership, Stedi automatically generates a 999 acknowledgment per functionality group of every valid inbound EDI file and delivers the 999s to your trading partner using the specified connection.

You will only use 999 acknowledgments in response to healthcare transactions. It's likely you should use 999s if you receive these transaction sets:

• 270

• 271

• 276

• 277

• 278

• 820

• 834

• 835

• 837

Each generated acknowledgment includes ISA and GS envelopes, complete with auto-incremented control numbers. Visit the partnerships documentation for more details.

The EDI Inspector in Stedi guides can now autogenerate an envelope for any sample EDI file.

If the EDI test file in the editor does not contain an envelope, the EDI Inspector displays a Generate envelope button that you can use to instantly create a generic envelope for the transaction set. You can then edit the envelope with information for you and your trading partner.Stedi guides are a machine-readable format for EDI specifications that Stedi uses to translate inbound EDI files and generate outbound EDI files according to your and your trading partners' requirements. You can use the EDI Inspector in each guide to validate EDI test files according to the guide's specifications. You can start from sample files attached to the guide or add your own test file into the editor.Check out the Stedi Network, which includes Stedi guides for hundreds of popular trading partners. You can import any guide into your Stedi account to use in your EDI integrations.

You can now set the maximum number of concurrent executions for any Stedi function to avoid overloading downstream services and ensure that the function can scale up as needed.

Concurrency refers to the number of in-flight requests your function is handling at the same time. With the new concurrency controls, you can set the maximum number of executions that a given function can execute simultaneously. Generally, you would set this to a number that your downstream system can comfortably support.

In addition to limiting the number of concurrent requests, concurrency controls help ensure that you always have available capacity for a given function within your Stedi account. All functions within a Stedi account share an overall concurrency limit that can be raised upon request. When you set a concurrency limit for a specific function, you reserve a part of the overall account "budget" for that function. This approach ensures that you can scale up to the reserved level, even if other functions are experiencing a high load.

To use this feature, go to the Functions UI, click the function you want to edit, and set the Max concurrent executions.

We are excited to announce that our EDI Inspector can now validate EDIFACT EDI files. All EDIFACT releases D96A and later are supported.

The EDI Inspector instantly recognizes any X12 or EDIFACT EDI file and validates its content against the corresponding EDI standard. You can view the transaction data on an easy-to-read UI, and identify and fix errors, such as incorrect codes and formats, missing or misplaced segments, and more.

EDIFACT integration preview: Soon, you'll be able to configure an EDIFACT integration on Stedi to exchange EDIFACT files with your partners. Contact us to get added to the preview launch.

You can now configure your Remote FTP connections to use a static source IP address when exchanging EDI files with your trading partners.

Enabling a Static IP address ensures that your Remote FTP connections always use the same source IP address when communicating with the remote server. This may be required if one or more of your trading partners need to add your IP address to an allowlist to enable access.

You can enable a static IP address for your Remote FTP connections from the Core settings UI.

You can now generate and send test files to your trading partner from your browser.

To send a test EDI file from within a partnership, you can open the menu next to any outbound transaction setting and click Send EDI. You can also access this feature from the File Executions page.Stedi can autogenerate the input transaction payload (JSON) from any sample EDI file in the guide. You can modify this payload or paste your data into the editor. You can send the file from the browser or get the (HTTP) Generate API syntax for that payload. If you send the file, Stedi delivers the outbound test file to the connection, and you can review the results on the File Executions and Transactions pages.

Learn more about configuring new trading partners in our documentation.

You can now configure Destination webhooks to send data from Stedi to third-party services without writing any custom code.You can use destinations to send processed transaction data to your internal systems and business applications for further processing. You can also configure webhooks for other Stedi events, such as file processing failures. You can use this approach to trigger alerts in systems like Slack, PagerDuty, or Zendesk for further review.

Stedi can send webhooks to:

• Custom applications using Basic, OAuth, or API Key authorization

• Cloud functions, including AWS Lambda, Google Cloud Functions, and Azure Functions

• iPaaS platforms, such as Zapier, Workato, or Tray.io

• ERPs like NetSuite, SAP, or Oracle.

You can now use Stedi's fully-managed AS2 connections

 to exchange EDI documents with your trading partners.The UI helps you quickly set up and test an AS2 connection for a trading partner. When you enable inbound messages, Stedi automatically processes EDI files received through the connection. When you generate EDI for a partnership

 using the API, Stedi uses the AS2 connection assigned to the transaction to deliver the document to the trading partner. You can review the delivery status of all your sent EDI files on the file executions page.