How we build our claim edits database
Engineering
When a payer rejects a claim, it slows down payment for the provider.
Payer rejections can take days to arrive. Once a rejection arrives, the provider has to correct and resubmit, and the process starts over.
In some cases, it can cause the provider to miss timely filing limits, which means they don't get paid at all.
At Stedi, our goal is to drive payer rejections to zero by “shifting left.”
We've built a library of edits – the industry term for claim validation checks – that run on every claim submitted through Stedi. They mimic the same checks payers use. We grow that library by analyzing every claim rejection we receive.
Closing the loop
At Stedi, we often talk about closed-loop systems. The idea comes from manufacturing, where it's used to ensure products are produced faster, at higher quality, and with fewer errors.
In this model, an error or defect, like a claim rejection, is a signal that your system needs improvement. If you see one, you should:
1. Track down the root cause.
2. Implement a control to address or minimize the root cause (closing the loop).
We apply closed loops to almost everything we do: addressing customer feedback, resolving software bugs, or fixing typos in our docs. When applying closed loops in practice, we’ve found that the first step – tracking down the root cause – is almost always the hardest part.
Eating glass
Tracking down a root cause takes focus and time, often under pressure – like when you’re dealing with frustrated customers who are having an issue. Other times, it involves tedious work, like sorting through thousands of claim rejections to find patterns.
It's easy to deprioritize root cause analysis. The pressure to ship features or help other customers is legitimate. And the short-term cost is real: time spent finding a root cause is time not spent on things that could generate revenue.
But the long-term benefits compound: you stop fixing the same issues over and over, and the quality of the underlying system improves.
At Stedi, we call this "eating glass" – doing the painful, unglamorous work needed to improve the system.
Fingerprinting claim rejections
We built our database of claim edits by applying a closed-loop mechanism.
When a payer rejects a claim, they send back a 277CA claim acknowledgment. It contains claim status category codes, claim status codes, and error messages that describe what went wrong.
We extract those codes and fingerprint each unique rejection pattern. The result is a prioritized list of rejection reasons, ranked by dollar value and volume. High-dollar, high-volume rejections go to the top of our “todo” list.
Starting at the top, our claim edits team works through each pattern to identify the root cause. From there, we build one of two things:
A repair – An automated fix that corrects the issue before the claim reaches the payer. For example, removing hyphens from a phone number. Stedi applies repairs automatically. The submitter doesn't need to do anything.
An edit – A validation check that catches the issue before submission and returns an error with details so you can correct it.
Because they’re driven by real rejections, our edits cover all SNIP Types, including payer-specific SNIP Type 7 edits.
We also build edits on request. If a customer flags a rejection pattern, even if the rejection only fires for one claim out of millions, we'll investigate and ship an edit if it applies. Volume isn't the only trigger.
Example: Invalid submitter ID
In a claim, the submitter ID tells the payer who submitted the claim. Most payers accept standard submitter IDs, like an Employer Identification Number (EIN) or a Tax Identification Number (TIN).
Some payers – particularly Medicare and Medicaid – require a payer-assigned submitter ID on all claims. These IDs have a required format, typically with a specific prefix and length. When the format is wrong, the payer rejects the claim.
At one point, this pattern accounted for ~8% of addressable claim rejections in our clearinghouse. So we shipped an edit that validates the submitter ID format for these payers at claim submission.
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:
If you submit a claim as X12 using SFTP and the claim fails the edit, Stedi will reject the claim with a 277CA claim acknowledgment. The acknowledgment includes a claim status category code, a claim status code, and the error message:
Improving first-pass rates for claims
The goal of Stedi's edits database is to ensure that the payer accepts the claim on first submission, what's called a first-pass acceptance rate.
New Stedi customers typically arrive with first-pass rates around 85% from their existing clearinghouse. Once up and running, customers often see rates of 95% or more, with our highest-volume customers exceeding 99%.
Those rates are just the start. We ship new edits each week to help improve first-pass rates. See our changelog for the latest. You can browse a sampling of those edits at edits.stedi.com.
Get started with Stedi
If you want to see how Stedi’s claim edits work, sign up for our free Basic plan. You’ll get 100 free claim submissions each month.
Signup takes less than two minutes. No credit card is required.
Share
Automate healthcare transactions with developer-friendly APIs that support thousands of payers. Contact us to learn more and speak to the team.
