Changelog

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

Claim edit: Invalid paid amount

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that report a negative or non-numeric other payer paid amount on a service line.

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 for each service line.

Service line paid amount

A service line's paid amounts must be non-negative numbers. If they aren't, 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 Other Payer Paid Amount. The service line other payer paid amount must be a valid number greater than or equal to zero. The submitted value on line 1 is invalid, -150.00. 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>643>PR*[DATE]*U*[AMOUNT]******A8>710**Invalid Other Payer Paid Amount. The service line other payer paid amount must be a valid number greater than or equal to zero. The submitted value on line 1 is invalid, -150.00. Correct and resubmit.~

Claim edit: Missing last name

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include a person entity with no last name.

How the edit works

In a claim, each entity, such as the billing provider or subscriber, is identified as either a person or a non-person using an entity type qualifier.

When an entity is a person, both a first name and last name are required. In X12, this is the entity’s NM1-03 element. If a person’s last name is missing, 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.

How entity type qualifiers are specified

If you use Stedi's JSON Claim Submission API endpoints, Stedi sometimes infers the entity type qualifier. For example, if you provide a firstName and lastName for the billing provider in a JSON 837P Professional Claims API request, the entity is treated as a person.

If you use X12, you set the entity type qualifier in NM1-02 (Entity Type Qualifier). 1 indicates a person and 2 indicates a non-person entity, such as a hospital or billing organization.

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 Last Name. Last name is required when Billing Provider is reported as a person by the entity type qualifier 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*A6>504>85*[DATE]*U*[AMOUNT]********Missing Last Name. Last name is required when Billing Provider is reported as a person by the entity type qualifier 1. Correct and resubmit.~

Related claim edits

Stedi has a companion edit for missing first names. See Claim edit: Missing first name.

Claim edit: Payer responsibility level codes must be in order

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that skip a level in the payer responsibility sequence.

What are payer responsibility level codes?

In coordination of benefits (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.

COB claims must include information about all previous payers. Payer responsibility level codes, also called payment responsibility sequence number codes, indicate each payer’s payment order: P (primary), S (secondary), T (tertiary), then A through H for the fourth through eleventh payers.

Payer responsibility level code for the payer you’re sending the claim to

Payer responsibility level codes for the patient’s other payers

How the edit works

If a claim reports a secondary or later payer, it must also report every prior payer level before it in the order. Otherwise, the payer may reject the claim.

For example, the payer may reject a claim that reports a tertiary payer without a secondary payer.

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.

Note: A responsibility level code of U (Unknown) won’t trigger this edit. A code of U doesn’t indicate a specific payment order.

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 Payer Responsibility Sequence. Any payer responsibility level above primary must follow the prior levels in order. The submitted payer responsibility values are out of order, P, T. 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>742*[DATE]*U*[AMOUNT]******A7>732**Invalid Payer Responsibility Sequence. Any payer responsibility level above primary must follow the prior levels in order. The submitted payer responsibility values are out of order, P, T. Correct and resubmit.~

Related claim edits

Stedi has another edit for duplicate payer responsibility level codes. See Duplicate payer responsibility level codes.

Stedi also rejects claims that don't report a primary payer. See Missing primary payer.