Changelog

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

Claim type	JSON API field	X12 element
837P professional	`serviceLines[].professionalService.procedureCode`	`SV1-01-02` (Procedure Code) of Loop `2400` (Service Line)
837I institutional	`serviceLines[].institutionalService.procedureCode`	`SV2-02-02` (Procedure Code) of Loop `2400` (Service Line)

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

Claim type	JSON API field	X12 element
837P professional	`rendering.npi`	`NM1-09` (Identification Code) of Loop `2310B` (Rendering Provider Name)
837D dental	`rendering.npi`	`NM1-09` (Identification Code) of Loop `2310B` (Rendering Provider Name)

Supervising provider

Claim type	JSON API field	X12 element
837P professional	`supervising.npi`	`NM1-09` (Identification Code) of Loop `2310D` (Supervising Provider Name)
837D dental	`supervising.npi`	`NM1-09` (Identification Code) of Loop `2310E` (Supervising Provider Name)

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"
    }
  ]
}

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:

Open the Stedi Agent.
Select New chat > Upload member ID card.
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"
    }
  ]
}

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

Claim type	JSON API field	X12 element
837D dental	`claimInformation.claimDateInformation.serviceDate`	`DTP*472` (Service Date) of Loop `2300` (Claim Information)

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

Claim type	JSON API field	X12 element
837D dental	`claimInformation.predeterminationOfBenefits`	`CLM-19` (Predetermination of Benefits Code) of Loop `2300` (Claim Information)

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"
    }
  ]
}

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"
    }
  ]
}

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.