Changelog

Claim edit: Missing billing provider ID

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that don’t contain one of the following IDs for the billing provider:

• National Provider Identifier (NPI), a unique 10-digit identifier for the provider assigned by the Centers for Medicare & Medicaid Services (CMS)

• Tax identification number (TIN), such as an Employer Identification Number (EIN) or Social Security Number (SSN)

• A secondary identification number, such as a:

  • Payer Identification Number

  • Employer's Identification Number

  • Claim Office Number

  • National Association of Insurance Commissioners (NAIC) Code

The billing provider is the person or organization, such as a clinic or group practice, that will receive payment from the payer.

Rejection errors

If you submit a claim that fails the edit using Stedi’s JSON or X12 Claim Submission API endpoints, you’ll get back an error response in real time. The response includes error details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "A Billing Provider Identification is missing. This is required when the Billing Provider NPI is not present and an identification is necessary to identify the provider. 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*A6>560*[DATE]*85*[AMOUNT]********A Billing Provider Identification is missing. This is required when the Billing Provider NPI is not present and an identification is necessary to identify the provider. Correct and resubmit.~

New claim edits: Invalid subscriber individual relationship codes

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that contain an invalid individual relationship code for the subscriber.

Individual relationship codes

In a healthcare claim, the subscriber is the person who holds the insurance policy. The subscriber is also called the policyholder or primary cardholder.

The subscriber is not always the patient. For example, a dependent, such as a spouse or child, may receive care through an employee’s insurance. In that case, the employee is the subscriber, even though they’re not receiving care.

Claims indicate the relationship between the subscriber and the patient using an individual relationship code in the subscriber’s section. This code tells the payer whether the patient is the subscriber themselves or a dependent covered under the same plan.

How the edits work

In a claim, if the subscriber’s individual relationship code is 18 (Self), it means the subscriber is the patient. In these cases, the claim must not include information for a dependent. Similarly, if a claim does not include a dependent’s information, the subscriber’s individual relationship code must be 18.

If a claim mixes the subscriber’s individual relationship code and dependent information incorrectly, payers may reject the claim. This can delay payment for the provider.

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

Where to find the subscriber’s individual relationship code

• JSON API

  • Professional claims JSON endpoint: claimInformation.otherSubscriberInformation[].individualRelationshipCode

  • Dental claims JSON endpoint: claimInformation.otherSubscriberInformation[].individualRelationshipCode

  • Institutional Claims JSON endpoint: claimInformation.otherSubscriberInformation.individualRelationshipCode

• Raw X12

  • Professional claims: SBR02 (Individual Relationship Code) of Loop 2000B (Subscriber Hierarchical Level)

  • Dental claims: SBR02 (Individual Relationship Code) of Loop 2000B (Subscriber Hierarchical Level)

  • Institutional claims: SBR02 (Individual Relationship Code) of Loop 2000B (Subscriber Hierarchical Level)

• Stedi portal

  • Professional claims using the CMS-1500 form: Box 6 – Patient Relationship to Insured

The subscriber’s individual relationship code must not be 18

If you submit a claim with a dependent’s information and the subscriber’s individual relationship code is set to 18, Stedi’s JSON or X12 Claim Submission API endpoints return an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Subscriber Individual Relationship Code. Subscriber's individual relationship code cannot be '18' (Self) when subscriber is not the patient (as indicated by the dependent 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 include a related claim status category code, claim status code, and error message:

STC*A7:N156*[DATE]*IL*[AMOUNT]********Invalid Subscriber Individual Relationship Code. Subscriber's individual relationship code cannot be '18' (Self) when subscriber is not the patient (as indicated by the dependent loop). Correct and resubmit.~

The subscriber’s individual relationship code must be 18

If you submit a claim without a dependent’s information and the subscriber’s individual relationship code is missing or not set to 18, Stedi’s JSON or X12 Claim Submission API endpoints return an error response in real time. The response includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Subscriber Individual Relationship Code. Subscriber's individual relationship code must be '18' (Self) when subscriber is the patient (as indicated by the absence of dependent information). 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*A6>156*[DATE]*IL*[AMOUNT]********Missing Subscriber Individual Relationship Code. Subscriber's individual relationship code must be '18' (Self) when subscriber is the patient (as indicated by the absence of dependent information). Correct and resubmit.~

Request to join existing accounts

Now, when you sign up for Stedi, we check if your email domain is already tied to an existing account. If it is, you can request to join that account instead of creating a new one.

For example, if you sign up with john.doe@example.com and your company already has a Stedi account for example.com, you’ll see the option to request to join it. This helps avoid duplicate Stedi accounts for the same organization.

Transaction Enrollment API responses now include the originally submitted payer ID

We now return payer.submittedPayerIdOrAlias as an optional field in responses for the following Transaction Enrollment API endpoints:

• Create Enrollment

• Retrieve Enrollment

• List Enrollments

For example, in a Retrieve Enrollment response:

{
  "payer": {
    "name": "UnitedHealthcare",       // Resolved name for the payer
    "stediPayerId": "87726",          // Resolved Stedi payer ID for the payer
    "submittedPayerIdOrAlias": "UHC", // Originally submitted payer ID
  },
  ...
}

You must pass a payer idOrAlias when creating an enrollment using the Create Enrollment endpoint. Previously, responses only returned the stediPayerId, the Stedi payer ID that the submitted payer ID or payer ID alias resolved to.

If you submitted a primary payer ID or another payer ID alias, this made it difficult to reconcile the response with the payer ID you originally provided.

Now, submittedPayerIdOrAlias returns the payer ID or payer ID alias you submitted in the original Create Enrollment request.

Introducing eligibility check IDs

Stedi now generates and returns a universally unique ID (UUID) for every eligibility check.

The check ID is returned in the id field of the following API responses:

• JSON Real-Time Eligibility Check

• X12 Real-Time Eligibility Check

• Retrieve Batch Check Statuses

• Poll Batch Checks

The check ID is a string that always starts with ec_. For example:

{
  "id": "ec_550e8400-e29b-41d4-a716-446655440000", // Unique check ID, generated by Stedi
  "eligibilitySearchId": "01922a35-a177-7171-b868-cd4974dd54df",
  "benefitsInformation": [
    ...
  ],
  ...
}

For SOAP Real-Time Eligibility Check API responses, the check ID is returned in the stedi-id HTTP response header:

stedi-id: ec_550e8400-e29b-41d4-a716-446655440000

The check ID gives you a stable handle for a single eligibility check. You can use it to:

• Track eligibility checks for debugging and troubleshooting in your application

• Search for specific checks in the Stedi portal

• Construct deep links to eligibility checks in the Stedi portal

• Share a reference to a specific eligibility check with Stedi support

For more information, check out our announcement blog.

The 837I Institutional Claims JSON API now supports claim attachments

You can now include unsolicited claim attachments when submitting 837I institutional claims through Stedi’s Institutional Claims JSON API endpoint.

Previously, you could only submit attachments for institutional claims using our X12 API endpoint or SFTP.

For instructions and more information, see our Claim Attachment docs.

Claim edit: Invalid diagnosis pointers

Stedi now rejects 837P professional and 837D dental claims with invalid diagnosis pointers.

How the edit works

In a claim, a diagnosis code describes what’s wrong with the patient, such as tooth decay or lower back pain. A claim can include multiple diagnosis codes, listed and indexed in order of importance. The primary diagnosis code is in position 1, the next is in position 2, and so on.

A service line is a single row on a claim that bills for one specific service, procedure, or supply – such as an office visit or a dental filling.

Each service line can include a diagnosis code pointer. This pointer tells the payer why the service was provided by linking it to a specific diagnosis code. For example, this office visit (service) was provided because of lower back pain (diagnosis). Payers use this information to determine the medical necessity or clinical rationale for the service.

The diagnosis code pointer refers to the index position of a diagnosis code on the claim. For example:

• If a service line uses diagnosis pointer 2, the claim must include a diagnosis code in position 2.

• If a service line uses diagnosis pointer 3, the claim must include a diagnosis code in position 3.

Payers may reject claims that include a diagnosis pointer that refers to a diagnosis code position that isn’t present on the claim. These rejections can delay payment for the provider.

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

Where to find diagnosis codes and pointers

• JSON API

  • Professional claims JSON endpoint: 

    • Diagnosis codes: healthCareCodeInformation

    • Diagnosis pointers: serviceLines[].professionalService.compositeDiagnosisCodePointers

  • Dental claims JSON endpoint:

    • Diagnosis codes: healthCareCodeInformation

    • Diagnosis pointers: serviceLines[].dentalService.compositeDiagnosisCodePointers
      

• Raw X12

  • Professional claims:

    • Diagnosis codes: HI (Health Care Diagnosis Code) in Loop 2300 (Claim Information)

    • Diagnosis pointers: SV1-07 (Composite Diagnosis Code Pointer) in Loop 2400 (Service Line)

  • Dental claims:

    • Diagnosis codes: HI (Health Care Diagnosis Code) in Loop 2300 (Claim Information)

    • Diagnosis pointers: SV3-11 (Composite Diagnosis Code Pointer) in Loop 2400 (Service Line)

• Stedi portal

  • Professional claims using the CMS-1500 form:

    • Diagnosis codes: Box 21 – Diagnosis or nature of illness or injury

    • Diagnosis pointers: Box 24e – Diagnosis codes

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 Diagnosis Pointer(s) of 2, 3, 4 on line 0 is/are invalid. The diagnosis pointer must point to an existing diagnosis code on 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 include a related claim status category code, claim status code, and error message:

STC*A7>477*[DATE]*U*[AMOUNT]********The Diagnosis Pointer(s) of 2, 3, 4 on line 0 is/are invalid. The diagnosis pointer must point to an existing diagnosis code on the claim. Correct and resubmit.~

Claim edit: Line item control numbers must be unique

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
  **Professional claims submitted through Stedi's CMS-1500 form can’t fail this edit. The form requires manually entered control numbers to be unique.

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>584*[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.~

Include submitter's fax number using Stedi’s CMS-1500 form

You can now include the submitter’s fax number when submitting an 837P professional claim using Stedi’s CMS-1500 form.

The submitter is the person or organization who creates and submits the claim. When submitting a claim, you must include at least one of the following for the submitter:

• Email address

• Phone number

• Fax number

Payers may use this information to contact the submitter about issues with the claim. Previously, the form only accepted the submitter’s email address and/or phone number.

Introducing status filters for batch eligibility checks in the Stedi portal

You can now filter eligibility checks within a batch by status in the Stedi portal.

Batch eligibility checks let you run multiple eligibility checks asynchronously using a single request. The checks run in a dedicated pipeline, separate from real-time checks, and Stedi handles retries for you.

You can submit batch eligibility checks through our API or by uploading a bulk CSV in the Stedi portal.

The portal’s Eligibility check batches page shows all your batch checks.

You can click a batch name to view its details, including the status – such as Started or Pending – of each check.

With this change, you can now filter the list based on its status.