Building claim edits against external data sets

Healthcare billing is full of standardized data sets:

• ICD-10-CM diagnosis codes
• Procedure codes
• Provider taxonomies
• National Provider Identifiers (NPIs)
• Claim modifier codes, and more

Each set can be huge. There are more than 74,000 ICD-10-CM diagnosis codes – and over 8 million NPIs in the national registry.

A claim can include dozens of these codes across different data sets. For a payer to accept the claim, every one has to be right.

We've written before about what claim edits are and how we build them.

Our ultimate goal is to raise first-pass acceptance rates – how often payers accept a claim on first submission. A large part of that work is validating the different codes that can show up in claims.

This post covers that work: the edits we've shipped, the problems we hit, and how we solved them.

Why it's hard to build against external data sets

Each data set has a canonical source – typically the organization that maintains it – and each publishes updates on its own schedule. For example:

These schedules are only the baseline. Publishers also ship off-cycle updates when a code can't wait for the next cycle. For example, CMS added ICD-10-CM codes for COVID-19 in 2020 and 2021, ahead of the usual October release. It does the same with HCPCS Level II codes, issuing new drug codes off-cycle as drugs reach the market.

Miss an update, or fall behind, and your copy of the data set goes stale. A stale data set fails two ways.

Take HCPCS Level II codes, which CMS updates every quarter: some codes are retired and new ones added. If our edits miss the retired codes, we pass a claim the payer later rejects. That ultimately delays payment for the provider.

If our edits don't include the new codes, we reject claims the payer would have accepted – a false positive.

Just keeping our data sets current isn't enough. We also need to know which codes were valid when. A claim's date of service can be months in the past, and each code has to be valid for that date, not for today.

Take a claim with HCPCS Level II codes and a date of service in March 2024. We'd need to check them against the HCPCS codes that were valid in March 2024, not the most current version.

Keeping the data sets current

To solve both problems, we built a system that:

• Regularly checks each source for new releases
• Translates each one into a common format
• Stores every version with the dates it was in effect

Each claim submitted through Stedi is then checked against the version of each data set that applied on its date of service.

So an edit rejects a code that exists in the current set but wasn't valid then, and accepts one that was valid then even if it's since been retired.

Edits we've shipped so far

Since building this system, we've shipped edits that check claims against an external data set:

• Invalid ICD-10-CM diagnosis codes – Checks that every diagnosis code in the claim is a valid, billable ICD-10-CM code that was effective for the date of service.

• Invalid HCPCS Level II code – Checks that every HCPCS Level II procedure code in the claim is real and currently effective. Covers 1.7% of the claim rejections we see.

• CPT code outside the valid range – Checks that every Category I CPT procedure code in the claim falls in the valid 00100-99699 range.

• Invalid taxonomy code – Checks that every taxonomy code in the claim is in the NUCC's taxonomy list. Covers another 2.8% of claim rejections. The edit runs on every provider on the claim, at both the claim and line level.

• Deactivated NPI – Checks that no provider NPI in the claim has been deactivated in NPPES.

What's next

The edits above are just the start. We're actively working on edits for more external data sets, and we ship new edits every week.

See our changelog for the latest, and browse a sampling of our edits at edits.stedi.com.