Changelog

Claim edit: Invalid drug unit count

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.

Claim edit: Missing accident date

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.

Claim edit: Invalid revenue code

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.

Claim edit: Duplicate payer responsibility level codes

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.

Claim edit: Missing primary payer

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

Upcoming: Standard delimiters in X12 eligibility and real-time claim status responses

In the coming weeks, Stedi will normalize all X12 271 eligibility responses and 277 real-time claim status responses to use a standard set of delimiters.

If you do not parse the raw X12 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 and 277 real-time claim status responses. This can break X12 parsing for some Stedi customers.

**What’s changing
**Stedi will normalize all delimiters returned in X12 271 eligibility responses and X12 277 real-time claim status 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 and X12 277 real-time claim status 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 response

• x12 property of our Poll Batch Eligibility Checks API endpoint response

• X12 Real-time Claim Status API endpoint

• x12 property of our JSON Real-time Claim Status API endpoint response

• Stedi portal

**Next steps
**If you do not parse the raw X12 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.

Claim edit: Invalid billing provider address

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

Claim edit: Invalid primary diagnosis on Medicare chiropractic claims

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

Introducing MBI lookups without an SSN

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.

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.

Claim edit: Invalid tax identification number

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.