Changelog

Claim edit: Field values longer than maximum length

Stedi now rejects 837P professional, 837D dental, and 837I institutional claims with a field value that's longer than the maximum length allowed by X12 standards.

How the edit works

X12 standards set a maximum length for every text field in a claim. For example, the field for the subscriber's first name has a maximum length of 35 characters. The field for the billing provider's name has a maximum length of 60.

If a claim contains a field value that's longer than the maximum length of that field, 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 string length. A Subscriber First Name (2010BA/NM1-04) cannot exceed 35 characters. The submitted value contains 40 characters. 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>481*[DATE]*U*[AMOUNT]********Invalid string length. A Subscriber First Name (2010BA/NM1-04) cannot exceed 35 characters. The submitted value contains 40 characters. Correct and resubmit.~

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.