Changelog

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

Claim edit: Duplicate occurrence span codes in institutional claims

Stedi now rejects 837I institutional claims that include the same occurrence span code more than once within a single occurrence span group.

How the edit works

In institutional claims, occurrence spans are a range of dates for a significant event in a patient's care. Occurrence span codes tell the payer what each span of dates represents. These codes can affect how much a payer will approve or pay for a claim.

For example, occurrence span code 70 reports the qualifying inpatient stay dates that establish eligibility for a skilled nursing facility claim. Code 74 reports a noncovered level of care or leave of absence. Occurrence span codes are defined by the National Uniform Billing Committee (NUBC).

A claim can contain up to two groups of occurrence span codes. Each group can contain up to 12 codes.

Occurrence span code

The NUBC states that each occurrence span code must be unique within a single group. If a claim includes the same occurrence span code more than once within a single group, 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": "Invalid Occurrence Span Code(s). If submitting multiple occurrence span codes, each code must be unique. The submitted occurrence span code(s) are submitted more than once, 70. 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>721*[DATE]*U*[AMOUNT]******A7>732**Invalid Occurrence Span Code(s). If submitting multiple occurrence span codes, each code must be unique. The submitted occurrence span code(s) are submitted more than once, 70. Correct and resubmit.~

Related claim edits

Stedi has another edit for duplicate occurrence codes. Occurrence codes report a single event on a specific date. Occurrence span codes report a condition that applied over a range of dates. See Duplicate occurrence codes in institutional claims.

Claim edit: Insurance type code not allowed for the primary payer

Stedi now rejects 837P professional and 837D dental claims that include an insurance type code for the primary payer.

What is an insurance type code?

Insurance type codes are only required in coordination of benefits (COB) scenarios where Medicare – or a Medicare Administrative Contractor (MAC) – is not the primary payer.

In COB scenarios, the patient is covered by insurance from more than one payer. The primary payer pays first, then the secondary payer, and so on. Payer responsibility level codes, also called payment responsibility sequence number codes, indicate this order. A code of P indicates the primary payer.

An insurance type code indicates why Medicare is not the primary payer on a claim. For example, code 12 means the patient has an employer group health plan that pays before Medicare.

Claims should only include an insurance type code when providing information about the non-primary payer, such as the secondary or tertiary payer. You can provide an insurance type code in two places, depending on whether it's for the payer you're sending the claim to or one of the patient's other payers:

Insurance type code for the payer you’re sending the claim to

Insurance type codes for the patient’s other payers

How the edit works

A claim shouldn’t include an insurance type code for the primary payer. If it does, 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": "Invalid insurance type code usage. When the payer is primary for the subscriber, an insurance type code is not allowed. 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>578>HK*[DATE]*U*[AMOUNT]******A8>742**Invalid insurance type code usage. When the payer is primary for the subscriber, an insurance type code is not allowed. Correct and resubmit.~