Changelog

Claim edit: Invalid HCPCS Level II code

Stedi now rejects 837P professional and 837I institutional claims that include an invalid HCPCS Level II procedure code.

HCPCS codes

The Healthcare Common Procedure Coding System (HCPCS) is a set of medical procedure codes. HCPCS codes consist of two levels:

• Level I consists of the Current Procedural Terminology (CPT) code set, which is maintained by the American Medical Association (AMA). These codes are used to bill for an individual provider's services, like an office visit or a surgery.

• Level II codes are used to bill for things like medical equipment, ambulance rides, and certain drugs. For example: E0114 (crutches) or A0429 (an emergency ambulance ride).

Level II codes are maintained by the Centers for Medicare & Medicaid Services (CMS), which updates the official list quarterly. That means new HCPCS Level II codes are added and outdated ones are retired over time.

You can submit both Level I and Level II codes as service-line procedure codes on professional and institutional claims. This edit applies to Level II codes.

Procedure code

How the edit works

Payers may reject claims that include an invalid HCPCS Level II code.

When you submit an HCPCS Level II procedure code on a professional or institutional claim, Stedi compares it against the official CMS HCPCS Level II code set. If the code isn't valid or wasn't active during the claim's date of service, this edit rejects the claim before it reaches the payer. This prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

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

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid HCPCS code. The procedure code, F9999, on line 1 is not valid. HCPCS are typically 5 characters, starting with a letter. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, 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>507*[DATE]*U*[AMOUNT]********Invalid HCPCS code. The procedure code, F9999, on line 1 is not valid. HCPCS are typically 5 characters, starting with a letter. Correct and resubmit.~

Related claim edits

Stedi has another edit that checks the procedure code format. See Invalid procedure code format.

Introducing the improved Billing page

Admins on production accounts can now manage all billing tasks from the Billing page in the Stedi portal. The page is available in account settings.

Previously, managing billing meant juggling an external payment portal (surfaced through the Stedi portal) and manual requests. For example, the account balance was only visible through a support link, and Stedi's W-9 was available only by email.

Now, Admins can use the Billing page to:

• Edit billing information, like the billing address and emails.
• Update the credit card on file.
• View and download past invoices.
• Download Stedi's W-9 form.

For accounts on the pay-as-you-go plan, Admins can also:

• See the current account balance.
• Set the auto-recharge amount and the balance that triggers it. Stedi tops up the account balance whenever it drops below the trigger.

Introducing filtered result counts for claims and ERAs in the Stedi portal

You can now see how many claims or ERAs match your filters in the Stedi portal’s claims view. Previously, you could filter these lists but couldn't get a count of the matching records.

You can use the result counts to quickly answer questions about your claims or ERAs. For example:

• How many claims from last week are currently in the Rejected status?

• How many claims have been submitted for a billing provider?

• How many ERAs were received from Aetna in the last month?

Results counts only appear when one or more filters are applied. On the claims list, a resubmitted claim linked to the original record counts as one claim.

For more information, see our claims view and ERA view docs.

Introducing the My Payers view

You can now view every payer you've submitted claims to or received ERAs from through Stedi in the Stedi portal's My Payers view. You can access the view under Claims in the top nav.

Previously, seeing which payers you've worked with meant combing through your claims and ERAs lists separately. Now, you can see every payer you've worked with in a single, filterable list.

Access quick links

In the view, you can hover over any payer row to access quick links:

• View in network: View the payer's details in the Stedi Payer Network.

• Find claims: View all claims submitted to this payer in the claims view.

• Find 835 ERAs: View all ERAs you received from the payer.

• Find enrollments: View all transaction enrollments and enrollment requests with the payer.

Filter payers

You can filter the view's list of payers by:

• Payer name, payer ID, or payer ID alias

• Whether you've submitted an 837 claim to the payer

• Whether you've received an 835 ERA from the payer

Availability and pricing

The My Payers view is available for free on all production accounts.

Claim edit: Duplicate remaining patient liability

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that report a remaining patient liability amount for the same other payer at both the claim level and the service line level.

How the edit works

When a patient has more than one insurance plan, say a child covered by both parents' health insurance, claims go to the primary payer first, then the secondary, and so on. This is called coordination of benefits (COB).

Claims sent to a non-primary payer must report how much the patient still owes after adjudication from previous payers. This amount is called the remaining patient liability.

X12 standards state that a claim can report the remaining patient liability at the claim level (for the whole claim) or the service line level, but not both. Sending both creates ambiguity and potential double counting so requiring at one level forces the single authoritative source.

Claim-level remaining patient liability

Line-level remaining patient liability

If a claim reports both a claim-level and service-line-level remaining patient liability for a previous payer, the payer you submit the claim to may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

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

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid Remaining Patient Liability reporting. For a payer, the remaining patient liability amounts must only be reported at the claim or line-level. This information was submitted at the claim-level and for line(s) 1. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, entity identifier code, and error message:

STC*A7>639>GB*[DATE]*U*[AMOUNT]******A7>247**Invalid Remaining Patient Liability reporting. For a payer, the remaining patient liability amounts must only be reported at the claim or line-level. This information was submitted at the claim-level and for line(s) 1. Correct and resubmit.~

Stedi achieves HITRUST r2 Certification

Stedi's healthcare clearinghouse platform is now r2 certified by HITRUST for cybersecurity and information protection.

HITRUST r2 Certification is the most rigorous of HITRUST's three progressive assessments. It validates that Stedi has strong, risk-based controls in place to protect sensitive data and manage risk effectively. The certification is backed by independent third-party testing and HITRUST's Cyber Threat-Adaptive engine, which keeps controls aligned with evolving standards across NIST, ISO, and OWASP.

Less than a year ago, Stedi earned HITRUST e1 Certification for foundational cybersecurity. Moving from e1 to r2 in under a year reflects how seriously Stedi prioritizes security.

For customers, r2 certification means independent assurance that Stedi meets rigorous data protection standards. That builds trust faster with new customers and makes it easier to work with organizations that have strict security and compliance requirements.

"The HITRUST r2 Certification is an important benchmark for cyber-aware organizations such as Stedi," said Ryan Patrick, EVP of TPRM Customer Solutions at HITRUST. "Earning HITRUST Certification reflects not only the effective implementation of security controls, but also the organization's commitment to maintaining operational maturity across its cybersecurity program. We congratulate Stedi on this significant achievement."

Claim edit: Missing line item charge amount

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that have a service line missing a charge amount.

How the edit works

In a claim, a service line represents billing for a specific procedure, such as an office visit or X-ray. Each service line must include a line item charge – the amount billed for the related procedure.

Line item charge amount

Payers add up a claim's line charges to confirm they match the claim's total. They also use each line's charge when determining how much to pay for a specific procedure.

If a service line in a claim is missing its charge amount, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

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

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Service-line Charge Amount. Each service line must include a charge amount. Line 1 is missing a charge. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, 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>583*[DATE]*U*[AMOUNT]********Missing Service-line Charge Amount. Each service line must include a charge amount. Line 1 is missing a charge. Correct and resubmit.~

Related claim edits

Stedi has another edit for claims missing the total claim charge amount. See Claim edit: Missing total claim charge amount.

Introducing the official Stedi app for ChatGPT

Stedi’s ChatGPT app is now available in OpenAI’s ChatGPT app store. It’s the first approved app that allows healthcare providers to run patient insurance eligibility checks from within their business’s ChatGPT account.

For example, once connected, you can ask ChatGPT to:

/stedi Check Jane Doe's coverage before I schedule her appointment.
She's on Aetna, member ID AETNA12345, born April 4, 2004.
Provider is Stedi, NPI 1999999984.

The app only takes a few clicks to set up and requires no configuration or custom integration. To access it, you’ll need the ChatGPT Enterprise plan; the app isn't available on ChatGPT plans for individuals (Free/Go/Plus/Pro).

To learn more, see our announcement blog.

Introducing the eligibility checks view

You can now track individual eligibility check attempts in the new checks view of the Stedi portal's Eligibility page.

Previously, the Stedi portal’s Eligibility page grouped all related retries of the same eligibility check into a single record, called an eligibility search. To view individual check attempts, you had to click into the search record.

Now, the Eligibility page has two views, which you can toggle between:

• Checks – Lists every eligibility check attempt as its own row. When you retry a check, the retry appears as a separate row alongside the original. Now the default view.

• Searches – Groups all retries of the same check into a single record, called an eligibility search.

The checks view lets you reference the result of any single attempt and spot failure patterns. For example, you can filter by payer to see whether every check in the last hour failed, which can signal a payer outage.

Eligibility checks in the checks view are sorted by processed date, newest first. You can filter by processed date, result, member ID, payer, provider NPI, error code, and search ID.

Search statuses now reflect the prevailing check

In the searches view, a single eligibility search can contain several checks with different results. To determine the status of a search, Stedi has to pick which check’s result represents the search as a whole.

Previously, each search showed the status from the most recent check. For example, a search whose latest check failed had a Failed status, even if an earlier attempt returned active coverage.

Now, each eligibility search shows the status and data from the check with the highest-priority status, called the prevailing check. Stedi ranks statuses in the following order: Active → Inactive → Investigate → Failed. If two checks have the same status, the more recent check wins.

The prevailing check’s data applies to all search-level data, not just status. Patient information, payer details, Service Type Codes (STCs), and error metadata now come from the prevailing check.

For example, a search with a failed check, then an active check, then a second failed check now shows as Active. The active check is the prevailing result, even though it isn't the most recent.

For more information, see our Eligibility views docs.

Claim edit: Missing other payer adjudication date in COB claims

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that list a previous payer but are missing that payer's adjudication date.

How the edit works

When a patient has more than one insurance plan, say a child covered by both parents' health insurance, claims go to the primary payer first, then the secondary, and so on. This is called coordination of benefits (COB).

Claims sent to non-primary payers must report each previous payer's payments and adjustments. These claims must also include the date on which each previous payer adjudicated – or determined how to pay – the claim. This information helps the payer establish the sequence of benefits as well as timely filing determinations.

You can provide the adjudication date for either the entire claim or each service line.

Claim-level adjudication date

Service line adjudication date

If you don't specify a previous adjudication date in a COB claim, the payer may reject the claim.

This edit catches the issue before the claim reaches the payer. It prevents payer rejections, which take longer to resolve and delay payment for the provider.

Rejection errors

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

{
  "errors": [
    {
      "code": "33",
      "description": "Missing Claim Check or Remittance Date. This date is required when the identified other payer, [other payer name], has previously adjudicated the claim and the line check or remittance date is not provided. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

If you submit a claim using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment will include a related claim status category code, claim status code, entity identifier code, and error message:

STC*A6>516>PR*[DATE]*U*[AMOUNT]********Missing Claim Check or Remittance Date. This date is required when the identified other payer, [other payer name], has previously adjudicated the claim and the line check or remittance date is not provided. Correct and resubmit.~