Changelog

Claim edit: Missing claim-level referring provider

Stedi now rejects 837P professional and 837I institutional claims that report a referring provider on a service line but not at the claim level.

What is a referring provider?

The referring provider is the provider who directed the patient to the rendering provider – the one who delivered the care on the claim. For example, a primary care provider may refer a patient to a specialist.

When you submit a claim, you can report the referring provider at two levels: the claim level and the service line level.

The claim-level referring provider applies to every service line on the claim.

Claim-level referring provider

The service-line referring provider applies to a single service line.

Service-line referring provider

How the edit works

Per HIPAA standards, a referring provider on a service line acts as an override of the claim-level referring provider for that line. Without a claim-level referring provider, there's nothing to override.

If a claim reports a referring provider on a service line but omits the claim-level referring provider, 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-level Referring Provider. When referring provider information is reported at the line-level, referring provider must also be reported at the claim-level. 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>562>DN*[DATE]*U*[AMOUNT]******A7>562>DN**Missing Claim-level Referring Provider. When referring provider information is reported at the line-level, referring provider must also be reported at the claim-level. Correct and resubmit.~

Claim edit: Missing diagnosis-related group code

Stedi now rejects 837I institutional claims that include diagnosis-related group (DRG) information but no DRG code.

Diagnosis-related group codes

In institutional claims, a diagnosis-related group (DRG) code groups inpatient hospital stays into categories expected to consume similar resources. For example, DRG 470 covers inpatient hip or knee replacements without complications.

Payers use DRG codes to determine fixed reimbursement rates under DRG-based contracts with providers. Medicare inpatient hospital reimbursement is the most common use case, though Medicaid and some commercial plans use different DRG systems.

DRG codes are only required if the provider's payer contract uses DRG reimbursement.

Diagnosis-related group (DRG) code

How the edit works

If you submit claims as raw X12, the DRG code goes in a DRG information segment: an HI segment in Loop 2300 (Claim Information) with DR in HI01-01. When that segment is present, X12 standards require a DRG code in HI01-02.

If you submit a claim that includes a DRG information segment without a DRG code, 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.

Triggering the edit using the JSON API

If you use Stedi's JSON Institutional Claim Submission API endpoint, you can only trigger this edit by submitting a diagnosisRelatedGroupInformation object with an empty drugRelatedGroupCode string.

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 Diagnosis Related Group (DRG) code. When the Diagnosis Related Group Information is present, then the specific DRG code must also be populated. 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>256*[DATE]*U*[AMOUNT]********Missing Diagnosis Related Group (DRG) code. When the Diagnosis Related Group Information is present, then the specific DRG code must also be populated. Correct and resubmit.~

Related claim edits

Stedi has another edit for DRG code format. See Invalid diagnosis-related group code format.

Claim edit: Missing street address

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that are missing a required street address.

How the edit works

X12 standards require a street address for many claim entities. Some entities, like the billing provider, always require a street address. Others, like the service facility, only need a street address when the entity appears on the claim.

If a required street address 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.

The edit checks only that the address line is present. It doesn't validate the format or contents.

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 Street Address. When submitting billing provider information, a valid street address must also be 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>503>85*[DATE]*U*[AMOUNT]********Missing Street Address. When submitting billing provider information, a valid street address must also be provided. Correct and resubmit.~

Related claim edits

Stedi has another edit for addresses that populate line 2 without line 1. See Missing address line 1 when line 2 is present.

This edit only checks that a street address is present, not what it contains. A separate edit rejects PO box addresses for the billing provider. See Invalid billing provider address.

Claim edit: CPT code outside the valid range

Stedi now rejects 837P professional and 837I institutional claims with a numeric procedure code that falls outside the range of valid CPT codes.

CPT codes

Current Procedural Terminology (CPT) codes are medical procedure codes. CPT codes fall into three categories:

• Category I codes bill for an individual provider's services, like an office visit or a surgery. For example, 99213 is the Category I CPT code for a 20- to 29-minute office visit with an established patient.

• Category II codes are optional tracking codes for performance measurement. They end in F, such as 0001F.

• Category III codes are temporary codes for emerging services and technologies. They end in T, such as 0019T.

CPT codes make up Level I of the Healthcare Common Procedure Coding System (HCPCS).

You can submit both CPT codes and other HCPCS codes as service-line procedure codes on professional and institutional claims. This edit applies to Category I CPT codes.

Procedure code

How the edit works

Category I CPT codes are always 5-digit numbers between 00100 and 99699 (inclusive). They're the only purely numeric codes in HCPCS.

Payers may reject claims that include a Category I CPT code outside the valid range, such as 00099 or 99700.

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 Procedure Code. The submitted procedure code, 99700, on service line 1 is not a valid CPT code. CPT codes must be 5-digit numeric values and within the valid CPT range. 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>454**U*********Invalid Procedure Code. The submitted procedure code, 99700, on service line 1 is not a valid CPT code. CPT codes must be 5-digit numeric values and within the valid CPT range. Correct and resubmit.~

Related claim edits

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

Stedi also validates HCPCS Level II codes. See Invalid HCPCS Level II code.

Claim edit: Supervising provider matches the rendering provider

Stedi now rejects 837P professional and 837D dental claims where the supervising provider matches the rendering provider.

Rendering and supervising providers

In professional and dental claims, the rendering provider is the provider who delivered the care. The supervising provider is the provider who oversaw the rendering provider. For example, an attending physician might supervise a resident who delivers the care. Because these are distinct roles, the same provider can't be both – a provider can't supervise themselves.

Rendering provider

Supervising provider

How the edit works

Per X12 standards, claims should only report a supervising provider when it's a different person from the rendering provider. If they're the same person, you should omit the supervising provider from the claim.

If a claim includes a supervising provider with the same NPI, first name, and last name as the rendering provider, 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 Supervising Provider Information. The Supervising Provider indicates the provider who supervises the rendering provider and must be different. The submitted supervising provider matches the rendering provider NPI 1234567893. 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>562>DQ*[DATE]*U*[AMOUNT]******A7>732**Invalid Supervising Provider Information. The Supervising Provider indicates the provider who supervises the rendering provider and must be different. The submitted supervising provider matches the rendering provider NPI 1234567893. Correct and resubmit.~

Resolution tip

When the supervising provider is the same person as the rendering provider, omit the supervising provider and report only the rendering provider.

Introducing parent payer group names in the Stedi Payer Network

Stedi payer records now include the payer's parent payer group name, when applicable. The parent payer group is the corporate or brand group to which the payer belongs.

Previously, payer records only included the parent payer group ID, which is an opaque code like FIVMG. The group name is the human-readable name for that ID. For example, the group name for FIVMG is UnitedHealth Group.

Unlike group IDs, group names can be surfaced in customer-facing applications to indicate a payer belongs to a parent company or brand.

You can view the parent payer group names using Stedi's Payer Network, the Payers API, or the payer list CSV.

Using parent payer groups

Stedi provides parent payer group names as organizational metadata only. The parent payer group has no effect on routing, enrollment, or transaction support.

For example, two payers sharing a parent payer group may support different transaction types or have different enrollment processes. Not all payers have a parent payer group.

View parent payer groups in the Stedi Payer Network

In the Stedi Payer Network, a payer's parent payer group, when applicable, is listed in the Payer pane:

The parent payer group also appears on the payer's Payer page:

View parent payer groups in the Payers API

Payer records returned by Stedi's JSON-based Payers API endpoints now include the parentPayerGroupName property. For example:

{
  "displayName": "UMR",
  "primaryPayerId": "39026",
  ...
  "parentPayerGroupId": "FIVMG",
  "parentPayerGroupName": "UnitedHealth Group"
}

View parent payer groups in payer list CSV downloads

The list payers CSV endpoint and the payer list CSV download on the Stedi Payer Network now include a new ParentPayerGroupName column.

If your application parses the CSV, update it to account for the new column.

Introducing payer programs in the Stedi Payer Network

You can now see which insurance programs a payer participates in, such as Medicare or Medicaid, using the Stedi Payer Network and Payers API.

Stedi payer records now list the insurance programs a payer is known or expected to participate in, based on Stedi's curated sources. If Stedi doesn't know a payer's programs, they aren't listed.

When you submit a professional claim, you can set an insurance type, which tells the payer the kind of health insurance plan being billed. That insurance type usually maps to one of the payer's programs. For Medicare and Medicaid, the mapping is one-to-one.

Previously, you had to pick the right insurance type yourself. Now, when you submit a professional claim using the Stedi portal's CMS-1500 form, we auto-select the insurance type for Medicare and Medicaid payers, based on their programs.

If you submit claims using the API or SFTP, you can look up a payer's programs with the Payers API and set the insurance type yourself.

Auto-select insurance type on the CMS-1500 form

Stedi auto-selects the Box 1: Insurance type value when you submit a professional claim on the Stedi portal's CMS-1500 form to a payer that participates in only Medicare or only Medicaid. For example, selecting a Medicaid payer auto-selects the Medicaid insurance type.

If a payer participates in both Medicare and Medicaid, or in neither, we don't auto-select an insurance type – you choose it.

View payer programs in the Stedi Payer Network

In the Stedi Payer Network, a payer's programs are listed in the Payer pane:

Programs also appear on the payer's Payer page:

View payer programs in the Payers API

Payer records returned by Payers API endpoints now include a programs field. If Stedi hasn't assigned any programs to a payer, this field is an empty array.

For example:

{
  "displayName": "Molina Healthcare California",
  "primaryPayerId": "38333",
  "programs": ["COMMERCIAL", "MEDICARE", "MEDICAID"]
}

Filter by payer programs using the Payers API

You can also filter payers by program using the Search Payers endpoint's programs query parameter. The parameter accepts one or more program values and returns payers that participate in any of them.

For example, the following search returns payers that participate in Medicare or Medicaid:

curl --request GET \
  --url 'https://healthcare.us.stedi.com/2024-04-01/payers/search?programs=MEDICARE&programs=MEDICAID' \
  --header "Authorization: <api_key>"

Introducing new events for transaction enrollment updates and tasks

You can now subscribe to three new transaction enrollment events using event destinations:

• enrollment.updated – Stedi generates this event when an enrollment request changes, such as an update to its status, payer, contacts, provider details, tasks, or documents.

• enrollment.task.completed – Stedi generates this event when a provider completes an enrollment task, such as uploading a document or confirming details.

• enrollment.task.deleted – Stedi generates this event when it deletes an enrollment task that's no longer needed to move the enrollment forward.

You can subscribe to events on the Stedi portal's Event Destinations page.

Stedi sends each event as an HTTP POST request to the URL you configured. If a delivery fails, Stedi automatically retries it for up to 48 hours.

For event schemas, see our event types reference.

Introducing payer ID lookup by member ID card in the Stedi Agent

You can now find a payer ID by uploading a photo of an insurance member ID card to the Stedi Agent.

Eligibility checks fail if you use the wrong payer ID, even if you provide the right patient data. Many member ID cards don't list the payer ID used for eligibility checks and other electronic transactions, so matching a card to the right payer previously required a manual search.

If your workflow starts with a physical or digital insurance card, you can now get the primary payer ID without manually searching Stedi's payer list.

How member ID card payer lookups work

To start a lookup:

1. Open the Stedi Agent.

   

2. Select New chat > Upload member ID card.

   

3. Upload a JPEG or PNG image of the member ID card. You can upload an image up to 5MB in size.

After you upload an image, the agent reads the card and identifies the payer. If it finds a match, it returns the payer ID, a confidence rating, and the transaction types the payer supports.

If the agent can't read the card, try uploading a clearer image. If it can't determine the payer, contact Stedi support.

Availability and pricing

Member ID card payer lookups are available on all production Stedi accounts.

Stedi bills per lookup. For pricing, see our pricing page.

Security

You must have the Operator role or above to use the Stedi Agent. All Stedi Agent chats are visible to anyone with access to your Stedi portal account.

For more information, see our Stedi Agent docs.

Claim edit: Deactivated NPI

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include a provider NPI that's deactivated in the National Plan and Provider Enumeration System (NPPES).

How the edit works

A National Provider Identifier (NPI) is a unique, 10-digit identifier for US healthcare providers. The Centers for Medicare & Medicaid Services (CMS) issues NPIs and tracks their status in the NPPES.

CMS may deactivate an NPI if, for example, a provider dies, an organization disbands, or a fraud or regulatory review warrants it. Deactivated NPIs are not valid for use in a claim.

If a claim includes a provider NPI that the NPPES has deactivated, 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 describes the NPI as inactive and includes details in the errors array:

{
  "errors": [
    {
      "code": "33",
      "description": "Provider NPI is inactive. The NPI submitted, 1255328415, is inactive according to the National Plan and Provider Enumeration System (NPPES). An active NPI is required for claim submission. 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>562>85*[DATE]*U*[AMOUNT]********Provider NPI is inactive. The NPI submitted, 1255328415, is inactive according to the National Plan and Provider Enumeration System (NPPES). An active NPI is required for claim submission. Correct and resubmit.~

Related claim edits

Stedi has another edit that checks the NPI format. See Invalid NPI format.

Claim edit: Missing service date on dental claims

Stedi now rejects 837D dental claims that are missing a claim-level service date, unless the claim is for a predetermination of benefits.

How the edit works

Most dental claims report services a provider has already performed. The claim-level service date tells the payer when those services took place.

Service date

X12 standards require dental claims to include a claim-level service date unless the claim is for a predetermination of benefits. A date on an individual service line doesn't satisfy the requirement.

A predetermination of benefits claim works differently. It asks what a payer would cover before service occurs, so there's no service date to report.

Predetermination of benefits

If a dental claim isn't for a predetermination of benefits and has no claim-level service date, 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 Date. The claim-level date of service is required unless the claim is a predetermination of benefits (CLM19 = PB). 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>187*[DATE]*U*[AMOUNT]********Missing Service Date. The claim-level date of service is required unless the claim is a predetermination of benefits (CLM19 = PB). Correct and resubmit.~

Introducing in-app notifications and notification preferences

You can now receive in-app notifications in the Stedi portal for the following:

• Enrollment status changes – When a transaction enrollment request changes status to PROVISIONING, PROVIDER_ACTION_REQUIRED, LIVE, or REJECTED.

• Delivery failures for event destinations – When event deliveries to an event destination repeatedly fail.

• Account invitations and requests – When you're invited to a Stedi account, when someone requests to join your account, and when Stedi approves your account upgrade.

Previously, Stedi only sent these notifications through email. Now, you can see them when you log in to your Stedi account.

A bell icon in the navigation bar shows your unread count and opens a dropdown where you can review notifications.

Each in-app notification includes a link to the related resource, such as the updated enrollment request. You can mark notifications as read or unread and archive them – individually or in bulk.

Notification preferences

You can now manage delivery preferences for each notification type from the new Notifications page in Settings.

For example, you can choose to receive only email notifications for enrollment status changes. All notifications are enabled by default.

Your notification preferences apply across all Stedi accounts you can access. They're tied to your signed-in user, not to a specific Stedi account.

For more information, see our notifications docs.

Claim edit: Taxonomy code not in the NUCC code set

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims that include a provider taxonomy code that isn't in the NUCC Health Care Provider Taxonomy code set.

How the edit works

A taxonomy code identifies a provider's classification and specialization, such as cardiology or orthodontics.

The National Uniform Claim Committee (NUCC) maintains and publishes valid taxonomy codes in the Health Care Provider Taxonomy code set. Stedi checks the taxonomy code for every provider on the claim, including billing, rendering, attending, referring, and assistant surgeon providers, at both the claim and line level.

If a claim includes a taxonomy code that isn't in the NUCC code set, 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 Taxonomy Code. The submitted taxonomy code, ABC123456X, for Billing Provider is not valid per NUCC. 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>145>85*[DATE]*U*[AMOUNT]********Invalid Taxonomy Code. The submitted taxonomy code, ABC123456X, for Billing Provider is not valid per NUCC. Correct and resubmit.~

Related claim edits

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

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

If the procedure code isn't a valid HCPCS Level II code:

{
  "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 the procedure code exists but wasn't effective for the claim's date of service:

{
  "errors": [
    {
      "code": "33",
      "description": "Invalid HCPCS Level II code. The procedure code, J2400, on line 1 is not effective for the date of service. 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.

If the procedure code isn't a valid HCPCS Level II code:

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

If the procedure code exists but wasn't effective for the claim's date of service:

STC*A7>796*[DATE]*U*[AMOUNT]********Invalid HCPCS Level II code. The procedure code, J2400, on line 1 is not effective for the date of service. 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.