What are claim edits and repairs?

Submitting clean claims – ones that reach the payer without errors – can have a real impact on a provider’s cash flow.

If a claim contains an error – even a harmless one like a misformatted phone number – the payer may reject it, which can delay the provider’s payment.

Worse, payers often send rejections days after a claim is submitted. Sometimes that delay can bump up against timely filing deadlines the provider has to follow.

In other cases, the payer may deny or negatively adjust the claim. That means lost revenue or extra work to appeal or rebill it.

Avoiding errors is the best way to prevent these issues. Stedi’s claim edits and repairs act as a first line of defense. They catch – and, where possible, fix – errors before the claim reaches the payer.

What’s an edit?

A claim edit – often just called an edit – is an automated rule that validates part of a claim.

Each edit checks that a specific requirement for the claim is met. For example, an edit might confirm that a phone number contains exactly 10 digits. Another edit may check that the claim contains all required fields if the claim’s related to an accident.

If a claim fails an edit, the submitter must fix the issue and resubmit the claim before it can be processed.

Together, edits help ensure each claim is complete, accurate, HIPAA compliant, and follows payer-specific rules.

SNIP types

Edits are often categorized using the Strategic National Implementation Process (SNIP) framework. The framework was created by the Workgroup for Electronic Data Interchange (WEDI), which sets guidelines (but not standards) for how EDI should be implemented in healthcare.

In this framework, each SNIP type – or level – checks a different aspect of a claim’s correctness. It covers everything from basic formatting to HIPAA compliance and payer-specific rules.

SNIP Type 1: EDI Standard Integrity Testing
Checks that the claim uses valid EDI syntax. Edits of this type don’t check for things specific to HIPAA. Instead, they check for things like:

• Are the EDI segments in the right order?

• Do fields meant for numbers contain numbers?

SNIP Type 2: HIPAA Implementation Guide Requirement Testing
Checks that the claim uses HIPAA-compliant X12 syntax. Examples:

• Invalid phone numbers

• Invalid date of birth

• Invalid billing provider address

• Missing primary payer

SNIP Type 3: HIPAA Balance Testing
Checks that the billing amounts in the claim add up correctly. Examples:

• Non-zero adjustment amounts

• COB claims must be balanced

• Total claim charges must equal line-level charges

SNIP Type 4: HIPAA Inter-Segment Situation Testing
Checks that fields are present or missing based on the presence of other fields. Examples:

• Missing accident date

• Missing admission source code

SNIP Type 5: HIPAA External Code Set Testing
Checks that fields that use official HIPAA-adopted code sets only contain valid values. Example: 

• Invalid ICD-10-CM diagnosis codes

SNIP Type 6: Product Type/Type of Service Testing
Checks that the claim is valid and in the right format for the type of healthcare service listed. These edits catch mismatches between the procedure code being billed and the type of claim or service category. They check for things like:

• Using a CDT dental code in an 837P professional claim.

• Billing a surgery CPT code under a diagnostic service type.

• Including a revenue code, which is used only in 837I institutional claims, in an 837P professional claim.

SNIP Type 7: Trading Partner-Specific Testing
Checks the claim against rules in HIPAA guides that apply only to government payers like Medicare and Medicaid. Examples:

• Invalid primary diagnosis on Medicare chiropractic claims

• Missing initial treatment date for Medicare chiropractic claims

NCCI edits

There’s no standardized universal library of claim edits. However, a large number of industry-standard edits come from the National Correct Coding Initiative (NCCI). 

NCCI edits were originally developed by the Centers for Medicare & Medicaid Services (CMS) for Medicare, but many non-Medicare payers have adopted them or use them as a baseline.

Most NCCI edits address how procedure codes relate to one another, including:

• Procedure codes that should not be billed together

• Mutually exclusive procedures

• Unit-of-service limits (MUEs)

For example, if a comprehensive surgical procedure already includes wound cleaning, you can’t bill a second code just for the wound cleaning. It’s already part of the comprehensive surgical procedure code.

SNIP Types for NCCI edits
Because they relate to procedures, most NCCI PTP edits fall under SNIP Type 6. However, some – like those related to MUEs may fall under SNIP Type 6 or Type 4. It depends on how the edit is implemented.

Who runs edits?

Claims are checked against edits throughout the claim lifecycle, and different parties run different categories of edits.

Provider-specific edits
Provider or revenue cycle management (RCM) systems often run provider-specific edits based on internal workflows.

For example, a hospital system might verify that the billing provider’s phone number matches one of its approved numbers.

These edits are optional – it depends on the submitter’s setup. And they’re typically not related to HIPAA compliance or payer-specific rules. Instead, they help the provider ensure their claims follow their own internal operational guidelines.

Clearinghouse edits
Clearinghouses, such as Stedi, can also run edits on claims before they reach the payer. 

Clearinghouse edits typically mirror payer edits and serve two purposes:

• Catching errors early to prevent provider payment delays. Fixing issues upstream means the provider doesn’t wait days for a payer rejection.
  
  

• Filtering out non-compliant claims before they reach the payer. This protects payers from processing invalid claims and keeps payer systems running smoothly.

Payer edits
Payers run edits at two stages:

• Front-end edits
  Payers run these edits during validation – before the claim enters adjudication. If a claim fails a front-end edit, the payer rejects it, sending a 277CA claim acknowledgment back to the provider through the clearinghouse used to submit the claim.
  
  Because they also happen before adjudication, people will sometimes refer to clearinghouse and provider-specific edits as “front-end” edits as well.
  
  

• Back-end edits
  Payers run these edits as part of adjudication. If a claim fails a back-end edit, the payer may deny or adjust the claim rather than reject it.

For more on validation and adjudication, see our The difference between claim rejections and denials blog post.

How Stedi runs edits

As a clearinghouse, Stedi runs claims through clearinghouse edits that mirror the ones payers perform.

Unlike most clearinghouses, Stedi’s edits are designed to fail quickly and return clear, actionable error messages.

If you submit a claim using our API or the Stedi portal, you receive errors in real time. If you submit using SFTP, you’ll receive the rejection as a 277CA claim acknowledgment within minutes.

As an example, the following JSON API error is from an edit that checks the format of each claim’s billing provider phone number:

{
  "errors": [
    {
      "code": "33",
      "description": "Billing provider phone number is in an invalid format. The expected format is 10 numeric digits (0123456789); no country code, punctuation, or extension. Correct and resubmit.",
      "followupAction": "Please Correct and Resubmit"
    }
  ]
}

Stedi’s edit database
Stedi has a growing library of claim edits, including edits for specific payers. We’re adding new ones each week. It’s our goal to eventually cover all non-provider-specific edits that can be deterministically applied to claims.

You can see an up-to-date database of our current edits at https://edits.stedi.com/. Use our edit request form to ask for new edits or updates to existing ones.

What’s a repair?

Edits are great for catching errors in claims, but they don’t fix them. A failed edit only points out what’s wrong. The submitter still needs to revise and resubmit the claim.

A repair goes one step further — it automatically corrects certain types of issues. The submitter doesn’t need to make any changes or resubmit.

The scope of repairs
Because repairs modify the claim, they’re intentionally narrow in scope. They only fix problems with a known, deterministic solution – like formatting issues or structurally invalid data.

For example, if a phone number contains dashes or spaces, a repair might remove them so the claim passes validation.

Repairs aren’t used to change substantive or clinical content. For example, a repair won’t change a CPT code in a claim to reflect a different procedure. That requires a resubmission.

Who runs repairs?
Repairs happen before the claim reaches the payer. They’re only performed by a clearinghouse, like Stedi, or a provider-side system, such as an RCM tool. 

Generally, payers don’t make repairs or otherwise change submitted claim data. Instead, payers will accept, deny, or reject the claim.

How Stedi runs repairs

Stedi applies repairs before edits fail, fixing formatting issues so the submitter doesn’t need to. Because there’s no resubmission, providers can get paid even faster.

Like edits, we have a growing library of claim repairs, including repairs for specific payers.

Get started with Stedi

You can submit test claims to see how Stedi’s edits and repairs work yourself.

To get started, sign up for our Basic plan and submit some test claims. It’s free and includes 100 claim submissions each month.

Signup takes less than two minutes, and no credit card is required.