Changelog

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.

Batch eligibility CSVs now support up to 10,000 checks

You can now upload batch eligibility CSV files containing up to 10,000 checks – 10x the previous 1,000-check limit for CSV.

If you need to run more checks, you can upload and run multiple files at the same time.

For details, check out our Batch eligibility CSV upload docs.

Horizon Blue
Cross Blue Shield of New Jersey is now one-click enrollment

Horizon Blue
Cross Blue Shield of New Jersey (Payer ID: 22099) now supports one-click transaction enrollment for Electronic Remittance Advice (ERAs).

What is transaction enrollment?
Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer. Payers always require transaction enrollments for ERAs.

You can submit and track enrollments using Stedi's transaction enrollment API, the Stedi portal, or a bulk CSV.

One-click enrollment
Enrollment requirements vary by payer. Some payers may require the submitter to sign PDFs or complete tasks in the payer's portal.

If a payer supports one-click enrollment, you only need to submit the enrollment request. There are no follow-up steps. Stedi handles everything else.

You can check whether a payer requires enrollment – and supports one-click enrollment – for ERAs and other transaction types using the Stedi Payer Network or the Payer APIs.

For details, see our transaction enrollment docs.

Introducing the ERA PDF API endpoint

You can now programmatically retrieve PDF versions of your 835 Electronic Remittance Advice (ERAs) using Stedi’s new ERA PDF API endpoint. The {transactionId} path parameter is the ERA's transaction ID.

By default, the endpoint returns the PDF as a base64-encoded string. To get the unencoded PDF data, include the Accept: application/pdf request header. To view the PDF, save the PDF data to a file with a .pdf extension.

curl -X GET \
  "https://healthcare.us.stedi.com/2024-04-01/electronic-remittance-advice/{transactionId}/pdf" \
  -H "Authorization: <api_key>" \
  -H "Accept: application/pdf" \
  > era.pdf

The PDFs are the same as the ones you can download from the Stedi portal:

For more, check out our announcement blog or the API reference.

Introducing enrollment document uploads

You can now upload documents required for transaction enrollment requests directly in the Stedi portal. Only PDF documents are supported.

What is transaction enrollment?

Transaction enrollment is the process of registering a provider to exchange specific healthcare transactions with a payer.

For 835 Electronic Remittance Advice (ERAs), enrollment is always required. A payer only sends ERAs to the clearinghouse the provider has enrolled with, and a provider can only enroll with the payer through one clearinghouse at a time.

Stedi offers fully-managed, API-based transaction enrollment. You can use Stedi’s enrollment API to programmatically submit and track enrollments for providers. You can also use the Stedi portal, which supports bulk CSV imports.

When possible, we handle all enrollment paperwork on your behalf. When we can’t, we let you know what’s needed next.

Upload required enrollment documents

Enrollment requirements vary by payer. Some payers require additional documents, such as:

• A signed form

• A practice W-9

• A voided check

Previously, Stedi emailed you to request these documents and asked you to email them back to us.

With this update, we’ll still email you when an enrollment requires action. But, now, you can upload completed documents by clicking Upload new document in the Documents section of the enrollment’s details page in the Stedi portal.

For more information, see our documentation.

Get payer website URLs in the Stedi Payer Network and Payers API

You can now get a payer’s website URL using the Stedi Payer Network and the Payers API.

Stedi payer records now list the payer’s website URL, when provided.

**View payer URLs in the Stedi Payer Network
**Each payer now includes a Visit payer website link, when available in the payer’s record, in the Payer pane:

The Payer page also includes the link:

**Retrieve payer URLs using the Payers API
**All Payers API endpoints also now return the urls.website response property, if available, for payer records.

{
    "displayName": "Blue Cross Blue Shield of Texas",
    "primaryPayerId": "84980",
    ...
    "urls": {
      "website": "https://www.bcbstx.com"
    }
  }
}

Download ERA PDFs without a Stedi logo

You can now download unbranded ERA PDFs without a Stedi logo in the Stedi portal.

Stedi generates a PDF version of each Electronic Remittance Advice (ERA) you receive. Previously, all ERA PDFs included “Powered by Stedi” in the page footer. Now, you have the option to download ERA PDFs without this footer.

To download an unbranded ERA PDF:

1. Go to the Transactions page.

2. Click the ERA transaction you want to download.

3. On the Overview tab, click Fetch artifact. Then click … and select Download 835 ERA PDF without Stedi logo.

Resubmit professional claims using Stedi's CMS-1500 form

You can now correct and resubmit 837P professional claims using the Stedi portal’s CMS-1500 form.

Previously, if you submitted a claim using Stedi’s CMS-1500 form and later needed to fix it, you had two options:

• Re-enter all the data into the form by hand.

• Use the portal’s Edit and resubmit feature to change the raw X12.

Now, you can revise the previous claim directly in Stedi’s CMS-1500 form. Stedi loads the data from the original claim into the form for you.

For more details, see our announcement blog.