Payment Integrity Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the scope always start by rebuilding rules that already exist?

The first scoping workshop almost always drifts toward a rule engine that will handle everything: coding relationships, medically unlikely edits, bundling, modifier logic, the lot. It is an understandable instinct, because those are the edits everyone can describe, and a demo of a rule that catches a bilateral modifier is satisfying to watch. It is also the fastest way to spend your budget on work that was already done for you.

Coding relationship content is a maintained body of work, updated quarterly by teams of coders who do nothing else. Cotiviti and Optum maintain it properly. A software team rebuilding it will produce something that looks right in a demo, drifts within two quarters, and quietly stops matching current coding rules while everyone assumes it is fine.

The money in a plan-specific build is in the rules nobody sells you: your medical policy requiring a documented conservative therapy period before a particular imaging study, your carve-out with one health system for implants above an invoice threshold, your state Medicaid rate floor that overrides the standard fee schedule, the network exception granted during a capacity crisis that should have expired eighteen months ago. None of that is in a library, because none of it is standard.

The fix is a scope line written before anyone estimates. Licensed content stays licensed. What you build is the layer holding your policies, your contract terms, your simulation workspace and your governance. If a proposal includes rebuilding coding relationship libraries, it is either padding the number or misunderstanding the domain, and both are worth catching before signature.

What goes wrong with contract data when you actually try to structure it?

Every payment integrity proposal we have reviewed underestimates this line, including our own early ones. The premise of contract-aware editing is that the system knows what you agreed to pay. In practice your contract terms exist as signed PDFs in a repository, a configuration somebody set up in Facets or QNXT years ago, a folder of letters of agreement, a set of single case agreements approved by email, and the memory of two people in network contracting.

The configuration and the contract document disagree more often than anyone expects, and the disagreement is usually invisible because both sides of it produce a payment. A percent-of-Medicare arrangement running on a superseded rate year pays every claim without error. An outlier calculated on a stale cost-to-charge ratio pays. A carve-out that was never configured simply never applies.

What goes wrong in the project is sequencing. Teams schedule contract structuring as a data task in week three, discover in week six that resolving one health system agreement requires a contracting director who is in renewal negotiations, and the whole build slips behind a dependency nobody owns.

The fix is to treat contract structuring as its own workstream with a named business owner, started before engineering, and to scope it deliberately: your top twenty agreements by paid dollars first, not all of them. Then run repricing verification against paid claims before you touch the live claim path. It requires no adjudication intervention, it surfaces configuration drift within days, and in most engagements it finds enough to fund the next phase.

Why do the adjudication and remittance integrations break after launch?

The integration works on day one because it was built against the core system as it stood during the project. Then the vendor ships a release, your platform team applies it during a maintenance window, and the hook your integrity layer calls behaves slightly differently. Or a new line of business goes live on a second instance and nobody told the integrity team it existed.

The second breakage is quieter and worse. Rule identity has to travel out of the edit and into the remittance advice and the provider portal explanation, so that a disputed claim can be traced back to the rule that touched it. That mapping is fragile: remittance code assignments get changed for an unrelated reason, a new claim adjustment reason code is introduced, and suddenly the rule identity on your denials is wrong. Nobody notices, because claims still pay and denials still go out. You find out at the next quarterly review when overturn rate by rule cannot be computed.

The fix is a contract test suite that runs against the core system on a schedule, not only at build time, asserting that the intervention point still behaves as expected and that a known test claim produces a remittance carrying the expected rule identity. Add an alert on the rate of edits with unmapped rule identity, because that number should be zero and any drift from zero is the early warning. Get the core system upgrade calendar from your platform team and put it in the same plan, because integration breakage in this category is almost always scheduled by somebody else.

What happens when the prompt payment clock is not built into the design?

This is the gap that turns a savings programme into a regulatory finding. Prompt payment statutes set a hard clock from receipt of a clean claim, and the clock does not pause because your integrity layer wanted a second look. A prepay design that routes generously to manual review, or that adds latency inside the adjudication path, converts saved dollars into a claims backlog with a statutory deadline attached.

The specific failure sequence is predictable. Rules go live, the pend queue fills faster than the review team can clear it, the queue is worked first in first out because that is what the screen defaults to, and the claims closest to their deadline sit in the middle of the pile. The first anyone knows is an interest payment run or a complaint.

The second version of this gap is the dependency stall. Your integrity service calls something slow, the call blocks, and claims stop moving. An integrity layer that holds the claim flow is far worse than paying a claim you would have edited, because the blast radius is every claim rather than one.

The fix has three parts, and all three belong in the design rather than in operations. Classify every rule by execution path, so deterministic checks run synchronously inside a stated latency budget and anything needing clinical review or document retrieval goes asynchronous with a pend reason. Prioritise the pend queue by expected value and days remaining on the clock rather than arrival order. And define fail-open behaviour explicitly, with alerting, so a slow dependency degrades the programme instead of stopping the plan.

Should you build custom or configure what you already own?

For a meaningful number of plans reading this, the honest answer is configure and buy, and we would rather say so than sell you a project.

Below roughly 1 million claim lines a year, do not build. The fixed cost of running an integrity engine does not amortise at that volume, and a contingency vendor is genuinely the efficient answer. Use Cotiviti or Optum and keep your capital for something that scales with your membership.

If your gap is purely pricing accuracy against reference-based schedules, look hard at HealthEdge Source before commissioning anything. That is the problem it was built for, it does it well, and buying seventy percent of what you need with an integration project on top usually beats building all of it.

Before you build anything, exhaust your core system. Facets, QNXT and HealthRules all carry configuration capability that plans routinely underuse, often because the person who knew it left. A configuration review by someone who genuinely knows your platform is a few weeks of work and occasionally closes half the gap. Do that first, because a build proposal written against an unexamined configuration baseline is estimating work that may not exist.

The build case begins when two of these are true: your contingency fees exceed a build budget annually, your own policies take a quarter or more to reach adjudication, you cannot independently reproduce your vendors' savings claims, or your network team and your finance team are having a recurring argument about post-pay abrasion. That last one is the real trigger more often than the others, and it is legitimate, because the fix is structural rather than diplomatic.

How do hidden costs get into the quote?

The quote is usually honest about engineering and silent about everything engineering depends on. Watch for these.

• Contract structuring. Turning PDFs, configurations and tribal knowledge into versioned rate rules is a real workstream with a business owner, and it is the single most underestimated item on every proposal we have seen in this category.
• Second and third core instances. A plan running Medicare Advantage, Medicaid and commercial across different platforms is buying two or three integration efforts, not one. Ask which instances are in scope by name.
• Historical claim extracts for simulation. Rule simulation needs a representative claim population with member, provider and contract context attached. Assembling and refreshing that dataset is infrastructure work that quietly lands on your data warehouse team.
• Clinical review workflow. If any rule needs a nurse or coder to look at a chart, you have added document retrieval, clinician screens and a service level. That is a phase, not a feature.
• The parallel run. Running new rules in shadow mode against live claims for a full cycle before they affect payment is the correct approach and it is real cost, in compute and in analyst time reviewing what the shadow found.
• Dispute integration. If rule identity has to reach your appeals system, that is a second integration into a system usually owned by a different team with a different release calendar.

What separates a build that works from one that fails here?

Four things, and none of them are technology choices.

The first is simulation before activation. An analyst must be able to write a rule, run it against last quarter's claims, see the hit count, the dollar impact and a sample of affected claims with their providers, and then decide whether it goes prepay, post-pay or nowhere. Builds without that step ship rules on faith, and the first bad rule teaches network relations to distrust the whole programme.

The second is closing the dispute loop. Every edit that reduces payment must carry its rule identity into the remittance, the provider explanation and the dispute record, so overturn rate by rule becomes a standing report. A rule with a high overturn rate is not saving money, it is generating work and abrasion before paying anyway, and you cannot find those rules without the loop.

The third is that an analyst can suspend a rule without a software release. If retiring a bad rule requires an engineer and a deployment, the plan will keep running it for a fortnight while the sprint completes, and every one of those days is provider goodwill.

The fourth is ownership. You should own the repository, the cloud environment, the rules you author and every historical edit decision, in writing before kickoff. At Digital Heroes the client owns all of it from the first commit. In a category where the logic has historically belonged to vendors, that ownership is most of the point of building at all.