Changelog

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 and 837D dental claims with an invalid Place of Service (POS) code.

A Place of Service (POS) code tells the payer where the patient received care, such as a doctor’s office, a hospital, or the patient’s home.

POS codes are always two digits with no spaces. See Place of Service Code Set on CMS.gov for a list of valid POS codes and their descriptions.

Payers reject claims that contain invalid POS codes, such as a code that contains one digit without a leading zero. These rejections can cause delays. This edit – the industry’s term for an automated validation rule – prevents those claims from ever 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 place of service code, 1, is invalid. The code must be exactly 2 digits without any spaces. 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 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.