Changelog

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.