By Tracy Delgado, CSPO, RHIA, Sr. Product Manager, Payment Integrity

A head of payment integrity pulls the annual vendor performance report, and something nags at her. A frequency-limit edit her team flagged as a top recovery driver last year shows up again this year, same code, same pattern, same providers. Not because the providers changed their behavior. Because the fix was never a fix. It was a finding, and findings get rediscovered, and rediscovery gets billed as a contingency fee, every single year. 

That’s the arrangement most payers have lived inside for years without naming it. A payment integrity vendor identifies billing errors using inputs it doesn’t own, including public reference sources like CMS and AMA code sets, plus the payer’s own claims history, provider contracts, and medical reimbursement policy. None of them belong to the vendor. The resulting logic does anyway, priced as a percentage of everything it finds, for as long as the contract runs. In many contingency arrangements, what the payer buys is the finding, not ownership of the logic behind it

Three consequences follow, and most payment integrity leaders will recognize them immediately. The same errors get paid repeatedly, because the fix is a finding, not a concept the payer keeps. The logic can’t be inspected, so when a provider or a regulator asks why a claim was denied, the reasoning sits in someone else’s system, not yours. And leaving means starting over, because years of tuning and institutional knowledge stay with the vendor the moment the contract ends. That last one, more than any performance metric, can make changing vendors difficult because years of tuning and institutional knowledge may leave with the vendor.

The arrangement is coming under pressure, and payers are noticing

Contingency pricing has an uncomfortable property: the better it works, the more it costs, indefinitely. Self-funded employers are starting to question fees charged on errors found in their own plan’s data. Code sets change faster than most vendor release calendars can keep up with. Retroactive recoveries strain provider relationships that took years to build. The issue isn’t necessarily performance. It’s whether the ownership structure still fits the environment. The evaluation question has changed. It’s no longer which vendor finds more. It’s who owns the logic when the contract ends, and what leaving would cost you.

A different premise: you author the content

Abacus Insights and CoverSelf together offer a different model, built on a simple reversal: the payer authors and owns the content. The same concepts a vendor applies to your claims today get rebuilt as explicit, readable logic in CREOL, a purpose-built configuration language your own team can inspect, version, and edit, without filing a vendor ticket and waiting for a release window. 

You don’t start from a blank page. CoverSelf ships a pre-built library covering the same ground incumbent edit libraries do, with updates that keep pace with guideline changes. From there, your team customizes native content where it fits and authors new concepts where it doesn’t, with CoverSelf’s built-in AI assistant generating the configuration from a plain-English description of the policy. The learning curve becomes reviewing logic instead of writing it, which changes who on your team can own this. That shift, from licensing edit logic to authoring it, is what insourcing claims editing means in practice. 

Pre-claim, prepay, and postpay all run on the same configuration, and that’s not a small detail. Not every finding can move upstream. Retrospective, cross-claim, and history-dependent concepts depend on claims history that doesn’t exist yet at adjudication, and no configuration changes that. The deterministic findings can move: frequency limits, duplicates, bundling, and unbundling. That’s where prepay leakage concentrates. A duplicate your team catches in postpay this quarter becomes a prepay prevention next quarter, at the click of a button rather than a vendor project. That loop is what changes the economics over time: recovery volume falls on those concepts because the errors stop getting paid in the first place, not because your team got better at chasing them after the fact.

What ownership changes on the ground

• Defensibility. Every denial traces to a readable concept with a version history, something you can put in front of a provider, an auditor, or a regulator without a call to the vendor first. 

• Speed. A change becomes a live concept when your team decides it should, not when a release calendar allows it. Table-driven configuration keeps the annual code refresh a data update instead of a rewrite. 

• Continuity. The concept library, its tuning, and the institutional knowledge behind it accumulate in your system. Changing vendors down the line no longer means starting over from zero. 

None of this requires ripping out what you already have. CoverSelf is deployed inside Abacus’ HITRUST-boundary platform, connected through a single bidirectional claims feed with no data egress. Your existing claims platform, workflows, and vendor relationships stay exactly where they are. Most teams start with a second pass alongside their current vendor, small enough to be reversible, judged entirely on their own claims, expanded on their own calendar. There’s no forced migration and no switch to justify before you’ve seen a single result. Payment integrity insourcing can start as a second pass rather than a replacement.

Why this only works with a real data foundation underneath it

Owned editing logic is only as defensible as the data feeding it. A concept that says a service was already billed this month, or that a diagnosis doesn’t support a procedure, is only as trustworthy as the claims, clinical documentation, and authorization history behind it. What separates a defensible concept from a merely plausible one is provider behavior visible across full episodes of care, not reconstructed claim by claim. 

The division of labor is deliberate. Abacus provides the unified, payer-grade data foundation, connecting claims, clinical, provider, authorization, and contract data into a single governed layer that supports analytics, AI, and operational workflows. CoverSelf provides the editing content itself: the CREOL logic, the authoring workspace, and the AI assistant your team uses to write and maintain it. Abacus builds the ground CoverSelf’s logic runs on; CoverSelf builds the logic your team owns.

Questions worth asking before your next renewal

• If we left this vendor tomorrow, what would we lose, and could we rebuild it faster than we built it the first time? 

• Can our own team explain, in plain language, why a specific claim was denied? 

• Are we still paying a contingency fee on an error we’ve already found and reported once before? 

• Is our editing logic connected to the same governed data foundation that powers the rest of our payment integrity program, or is it running on its own island?

If any of those questions are uncomfortable to answer, ownership is worth a closer look. The full comparison is in the white paper where you can see why ownership, governance, and data usability are becoming foundational requirements for modern payment integrity programs.

Frequently Asked Questions

What does insourcing claims editing actually mean for a health plan?

It means the payer authors and owns the edit logic instead of licensing findings from a vendor. The concepts a vendor applies to your claims get rebuilt as explicit, readable rules your own team can inspect, version, and change without filing a vendor ticket. Plans usually start from a pre-built content library rather than a blank page, then customize it and author new concepts where their own policy differs. What changes is ownership: the logic and the tuning stay with the plan.

Why do payment integrity contingency fees keep recurring on the same errors?

Because a contingency fee pays for a finding, not a fix. When the logic that identified the error lives in the vendor’s system, the plan never keeps the concept, so the same billing pattern is rediscovered and billed again the following year. Contingency pricing also scales with what it finds, which means the better it works, the more it costs, indefinitely. Keeping the concept is what breaks the loop.

How much claims editing can a payer realistically insource?

Not all of it, and the split follows the data rather than the ambition. Deterministic concepts such as frequency limits, duplicate detection, and bundling and unbundling can be authored in house and moved upstream to prepay. Retrospective, cross-claim, and history-dependent concepts depend on claims history that does not exist yet at adjudication, so they stay postpay. ZS estimates that in a fully mature state, insourcing potential can reach up to 40 percent of vendor fees.

Do we have to replace our current payment integrity vendor to start?

No. Most plans begin with a second pass alongside the incumbent, judged on their own claims and expanded on their own calendar. The existing claims platform, workflows, and vendor relationships stay where they are, and the deployment runs inside the payer’s governed data environment with no data egress. That makes the first step small and reversible instead of a migration.

Can an insourced edit be defended to a provider or a regulator?

Yes, provided the logic is readable and versioned. When a denial traces to an explicit concept with a change history, your team can explain the reasoning without asking a vendor to produce it first. Defensibility also depends on the data underneath: claims, clinical documentation, authorization, and contract data connected across full episodes of care rather than reconstructed claim by claim. A concept is only as trustworthy as the record it runs on.