Engineering Clean Claims at the Source
Written by Ted Stipanovich
Most revenue cycle problems start long before they show up in denial queues, aging accounts receivable, or long follow-up cycles. The real cause usually happens earlier, when claims are first built and formatted for each payer.
At this point, even small inconsistencies can cause problems. Maybe a field is formatted differently than a payer expects, or a code needs to be translated. A segment might act differently based on payer rules. On their own, these issues are hard to spot, but together they create ongoing problems that take time and money to fix later.
Most organizations attempt to manage this through downstream controls. Edits are added. Scrubbing logic is expanded. Teams are trained to catch more before claims go out. These steps reduce noise, but they do not remove variability. They move the correction point earlier or later in the cycle, without changing how the claim is actually built.
SparkChange does things differently.
We make sure claims are correct from the start, so problems don't turn into extra work later. One way we do this is with our approach to the Claims Rule Development Tool (CRDT).
CRDT is a rules engine embedded directly into the claim pipeline that allows SparkChange to write custom payer logic using Structured Rules Language, a Java-based scripting framework. These are not configuration settings or standard system edits. They are purpose-built rules designed around the specific requirements of individual payers and client workflows.
The goal is simple: claims should be correct before anyone needs to review, fix, or resubmit them.
CRDT works through three main layers.
Derivation rules adjust claim data before it's formatted. This is where payer-specific changes occur, such as converting values to the correct format or remapping codes so claims match what payers expect from the start. These rules remove manual work effort from the billers, allowing them to focus on higher value tasks.
Validation rules check claims before they're sent. If something's missing, the claim is held, and clear feedback is given. If everything is right, the claim goes through without delay. This helps prevent issues that would otherwise show up later as denials.
Placement rules set up the structure of the outbound 837 transaction. They decide how segments are arranged and when certain elements are included or left out, based on what each payer needs. This makes sure claims are correct in both content and structure.
These layers work together as a built-in system that controls how claims are created, checked, and formatted before they go to a payer. This means not only fewer errors, but also fewer chances for errors to happen at all.
The impact of this approach is visible in client results.
At one large health system, SparkChange completed 144 CRDT/BRDTs as part of a broader revenue cycle engagement — resolving 1,784 service requests, 398 incident reports, and 186 escalations — across a SparkChange team that scaled as needed to meet our client’s optimal support needs. The SR backlog dropped 52% (972 to 469), and the IR backlog dropped 46% (441 to 237), with a best month of 637 closes — sustained throughput, not a one-time surge.
In another engagement, CRDT work was central to recovering $16.7M+ in impacted revenue from what started as a 0.5 FTE support contract. Wins included $11.05M from a missing provider charge toggle, $4.25M from a carve-out release, and $639K in radiology missing charge recovery. Twelve CRDT/BRDTs have been completed since contract signature, and the engagement has expanded from support to analytics, automation, and a full partnership. AR data from that same client showed the Edits bucket — the category most directly influenced by CRDT work — trending from $46M in August 2025 to a peak of $54.7M in February 2026, then declining, with the 12-month average settling at $55.4M across 24.14 AR days.
In another large project, CRDT helped reduce accounts receivable by approximately $14.3M and cut AR days by 4.83 during rollout. These results didn't come from hiring more staff or speeding up follow-up. They happened because fewer claims needed fixing later on.
For revenue cycle leaders, this shift changes how operations work.
Cash flow is more predictable because fewer claims are delayed by errors. Clean claim rates go up since claims are right the first time. And teams spend less time reworking accounts after submission.
Not only does this reduce manual effort on the front end before claims are produced, but the downstream benefits matter too. Teams no longer waste time fixing the same payer-specific issues over and over. Instead, they can focus on higher-value tasks, such as resolving complex denials, handling authorizations, and assisting patients with financial questions. The system stops using resources on preventable work and allocates them to tasks that require real judgment.
CRDT also changes how organizations handle payer changes. When requirements change, updates are made once in the rules and instantly apply to all future claims. There's no need to wait for denial trends or for teams to spot patterns. The system adapts right when claims are created.
CRDT is one piece of the puzzle. The main idea is the same across workflows: identify where variability starts, move intelligence earlier in the process, and design systems that produce correct outcomes by default rather than relying on corrections later.
When that shift happens, the revenue cycle stops operating as a correction engine and starts functioning as a controlled system.
That's when the real impact starts to add up.
“Before this approach, organizations often relied on generic system edits that fail to manage payer variability. Our custom CRDT edits replace or enhance those with precision-engineered logic embedded directly into the claim pipeline, ensuring that payer-specific requirements are enforced automatically to reduce the manual work effort.”
