Changelog

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.

Claim edit: The MJ unit of measurement code is only valid for anesthesia services

Stedi now rejects 837P professional claims when the MJ (minutes) unit of measurement code is used to incorrectly bill for anesthesia or non-anesthesia services.

In professional claims, the MJ unit of measurement code indicates a service was billed in minutes. While not a HIPAA mandate, it’s standard practice in the healthcare industry to bill for anesthesia services - but no other services – using MJ. Other services are billed using units, encounters, or time-based units – such as 15-minute increments – not raw minutes.

If MJ is used incorrectly, payers may reject the claim, which can lead to payment delays. This edit – the industry’s term for an automated validation rule – catches the issue before it reaches the payer.

When MJ must be used

If you submit a professional claim for anesthesia services that doesn't include the MJ unit of measurement code using Stedi’s 837P professional claim submission APIs or CMS-1500 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": "Invalid Measurement Code for Anesthesia Procedure Code. 01001 is an Anesthesia service which must be reported in minutes (measurement code: MJ). Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails this requirement 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:

STC*A7:N659*[DATE]*U*[AMOUNT]********Invalid Measurement Code for Anesthesia Procedure Code. 01001 is an Anesthesia service which must be reported in minutes (measurement code: MJ). Correct and resubmit.~

When MJ must not be used

If you submit a professional claim for non-anesthesia services that includes the MJ unit of measurement code using Stedi’s 837P professional claim submission APIs or CMS-1500 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": "Invalid Measurement Code for Procedure Code. Measurement Code MJ is not valid for 90837 as it should be only used code for Anesthesia services. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim that fails this requirement 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:

STC*A7>659*[DATE]*U*[AMOUNT]********Invalid Measurement Code for Procedure Code. Measurement Code MJ is not valid for 90837 as it should be only used code for Anesthesia services. Correct and resubmit.~

Introducing operating states for payers

You can now see which U.S. states and territories a payer operates in using the Stedi Payer Network website and the Payers API.

Stedi payer records now list the states or territories where the payer is known or expected to offer coverage, based on Stedi’s curated sources. If Stedi doesn’t know the payer’s operating states, they aren’t included in the record.

You can also filter by operating states when searching for payers.

Filter by operating state in the Stedi Payer Network

When you browse or search payers on the Payer Network, click + Operating States beside Filter by and select one or more states. The results will use AND logic to only show payers that operate in those states.

Each payer now lists its Operating States in the Payer pane. National payers – those who cover all U.S. states display NATIONAL. Regional payers list one or more U.S. state or territory codes, such as CA (California) or WA (Washington).

Operating states are also listed on the Payer page:

Operating states in the Payers API

All Payers API endpoints also now return an operatingStates array, if available, for payer records:

{
  "displayName": "Providence Health Plan",
  "primaryPayerId": "PHP01",
  "operatingStates": [
    "CA",
    "OR",
    "WA"
  ],
  ...
},

Payers that cover all U.S. states contain a single  NATIONAL value in the array:

{
  "displayName": "Cigna",
  "primaryPayerId": "62308",
  "operatingStates": [
    "NATIONAL"
  ],
  ...
}

Filter by operating state using the Payers API

You can also filter payers by operating state using the Search Payers endpoint’s new operatingStates query parameter.

The parameter expects exact matches and can accept multiple values. The endpoint uses AND logic to return the intersection of all filters.

For example, the following query returns only payers that operate in both CA (California) and WA (Washington):

curl --request GET \
  --url "https://healthcare.us.stedi.com/2024-04-01/payers?operatingStates=CA&operatingStates=WA" \
  --header "Authorization: <api_key>"

Claim edit: Limit line item control number to 30 characters

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims when a line item control number exceeds 30 characters.

The line item control number, also called the provider control number, is a provider-assigned identifier for each service line. Payers return this number on service lines in 277CA claim acknowledgments and 835 Electronic Remittance Advice (ERAs). Providers use it to track service lines across claim submissions, acknowledgments, and remittance files.

Line item control numbers are different from patient control numbers, which are used to track a claim as a whole.

HIPAA-adopted standards limit this line item control numbers to a maximum of 30 characters. If the value is too long, 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 one of the following request field values is more than 30 characters:

  • Professional claims JSON endpoint: claimInformation.serviceLines.providerControlNumber

  • Dental claims JSON endpoint: claimInformation.serviceLines.providerControlNumber

  • Institutional claims JSON endpoint: claimInformation.serviceLines.lineItemControlNumber

• Raw X12
  If you’re using raw X12, the edit fails if REF-02 (Line Item Control Number) in any Loop 2400 (Service Line Number) is more than 30 characters.

• Stedi portal
  Professional claims submitted through Stedi's CMS-1500 form can’t fail this edit. You can't enter line item control numbers longer than 30 characters using the form.

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": "Submitted Line Item Control Number, {123456789012345678901234567890123}, is invalid as it exceeds 30 characters. This field must be between 1-30 characters. 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.