Changelog

Claim edit: Missing attachment control number

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.

Claim edit: Missing initial treatment date for Medicare chiropractic claims

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 a MAC payer.

• 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.

Claim edit: Missing patient date of birth or gender

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.

Introducing automatic enrollment requests for failed CMS eligibility checks

Note: This feature was previously called "CMS automatic enrollment." For more information on the name change, see this changelog entry.

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.

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.

Introducing SFTP support for multi-claim 837 transactions in X12

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).

Claim edit: COB claims must be balanced

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.

Claim edit: Invalid billing provider ZIP Code

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": "The 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.

Claim edit: Missing member ID

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.

Claim edit: Non-zero adjustment amounts

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.

Claim edit: Total claim charges must equal line-level charges

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.

Claim edit: Zero-charge claims

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).

New claim edits: Missing or invalid Payer Claim Control Number

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.

Claim edit: Invalid phone numbers

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.

Introducing longer retry windows for batch eligibility checks

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.

Introducing NPI and tax ID filters for the List Providers endpoint

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.

Introducing timeframes for transaction enrollments

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.

Claim edit: Invalid ICD-10-CM diagnosis codes

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.

Introducing attachment uploads in the professional claims form

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.

Introducing API endpoints for batch status checks

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.

Introducing ERA PDFs

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.