Health Plan Claims Adjudication Software: Why Does the Pend Queue Grow Faster Than Your Team Can Clear It?

The pend queue is a mirror, and nobody likes the reflection

Every claims operation has a number it does not put on the board. Not the auto adjudication rate, which gets reported upward and gets massaged. The other number: how many claims are sitting in pend right now, how old the oldest one is, and how many of them are pended for a reason that has occurred thousands of times before and will occur thousands of times again.

The mechanics are the same at a 40,000 member provider sponsored plan and at a 400,000 member regional. An 837 comes in. Eligibility resolves, or it does not because the group loaded a retroactive term. Benefit determination runs. Pricing looks up the provider contract, which is a case rate with a stop loss threshold and a carve out for implants, and the configuration only covers the case rate, so the claim pends. An examiner opens it, opens the contract PDF in another window, does arithmetic, types a price and releases it. Eleven minutes. Multiply by the same contract, the same scenario, forty times a week, for two years.

That is not a technology gap in the abstract. It is a specific gap between what your provider contracts say and what your configuration can express, and it is paid for in examiner headcount, interest under state prompt pay rules, provider abrasion and the reprocessing that follows when someone eventually notices the price was wrong in both directions.

Where the platforms genuinely stop

Let us be fair about the incumbents, because a lot of writing in this category is not. Cognizant TriZetto Facets and QNXT are deep, mature systems that run a very large share of American health plans and do things a first build will not do for years. HealthEdge HealthRules Payer has a more expressive rules language than either and was designed later with that in mind. Plexis Healthcare Systems is a sensible lighter option for smaller third party administrators.

Their common limitation is not capability, it is who can change them and how fast. Configuration depth in these platforms lives with a small population of certified specialists, release cycles are measured in quarters, and a novel benefit design or payment model arrives as a services engagement with a statement of work. If your product changes twice a year that is fine. If you are a direct contracting entity, a provider sponsored plan launching bundled episodes, or a TPA serving employers who each want something slightly different, the configuration backlog becomes the constraint on the business. The second limitation is economics: per member per month licensing plus implementation is heavy for a plan under roughly 50,000 lives, which is exactly the size at which new risk bearing entities start.

Problem one: the contract is a document and pricing is a program

Percent of Medicare with a specific year and locality. Per diem by level of care with an outlier threshold and a lesser of billed charges rule. MS-DRG with a transfer policy. Case rates with implant carve outs. Multiple procedure reduction on the second and subsequent surgical line. Withholds, shared savings, quality bonus. Each of those is a small program, and a health plan has hundreds of them.

What a custom build does: treat each contract as versioned, executable, testable pricing logic with effective dates, and build a regression harness around it. Before a contract goes live you run twelve months of that provider's historical claims through the new logic and diff the outcome line by line against what was actually paid. Differences are either an intended change or a bug, and you know which before a single provider is affected. That harness is the single most valuable artifact in the build. It is also the thing that makes changing a contract a two day exercise instead of a two quarter one.

Problem two: pends without root cause are just a backlog

Most operations track pend volume and pend age. Very few can tell you the marginal cost of clearing pend reason 214 and how many of those are caused by three provider contracts and one group's eligibility feed. Without that, the response to a growing queue is more examiners, which is the only response available.

What a custom build does: every pend carries a machine readable reason, the data element that failed, an owner, a resolution path and a measured clear time. That turns the queue into a ranked backlog of engineering and configuration work. In our experience the top five reasons account for the majority of the volume, and two of them are usually fixable in a sprint. The system should also route pends by capability rather than round robin, so institutional outlier pricing goes to the examiners who are fast at it, and it should learn the resolution pattern well enough to propose the answer for review rather than a blank field. That is the honest use of machine learning in claims: suggest and let a human confirm, with the confirmation rate measured.

Problem three: accumulators are where members lose trust

Individual and family deductible with embedded or aggregate logic. Out of pocket maximum. Cross accumulation with the pharmacy benefit manager, which arrives on a file with its own timing. Mid year plan changes, retroactive eligibility terms, and a member who moves between two of your own plans in the same year. An accumulator that is wrong by 300 dollars generates a member complaint, an appeal, a reprocessing job and, if the pattern repeats, a regulatory complaint.

What a custom build does: model the accumulator as an event ledger rather than a running total. Every application of a member cost share is an entry with its source claim, timestamp and reason. Reversals are new entries, not edits. When a claim is voided or replaced, the accumulator unwinds deterministically instead of drifting. This design also makes the pharmacy cross accumulation file idempotent, so a resend does not double apply, which is a failure mode we have found live at more than one plan.

Problem four: migration is the project, not a phase of it

Nobody replaces a claims engine on a weekend. The credible pattern is shadow adjudication: the new engine consumes production 837 traffic in parallel with the legacy system for months, adjudicates every claim, and produces a nightly diff of allowed amount, member liability and pend disposition against what production actually did. You do not cut over a line of business until that diff is clean and every remaining difference is explained and intended.

That is slow and it is the only approach that does not damage providers. Budget for it explicitly. Plans that treat migration as a testing task rather than a parallel operating period are the plans that end up sending an apology letter to their entire network.

What it costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, this is the honest shape. A first release covering 837 professional and institutional intake, eligibility and benefit determination, contract pricing with the regression harness, accumulators, pend workflow and 835 generation, for one line of business, runs $150,000 to $350,000 across 5 to 8 months. A full core, meaning all lines of business, coordination of benefits, subrogation, capitation and value based arrangements, provider and member portals, and conversion of historical claims and accumulators, runs $600,000 to $2,000,000 or more over 18 to 30 months.

What drives it up: the number of distinct pricing methodologies in your network, because each is real engineering. Government lines, since Medicare Advantage and Medicaid carry encounter data submission obligations that are a project of their own. Value based arrangements, where the attribution and settlement logic is usually more complex than the fee for service pricing it sits on top of. Coordination of benefits, which is deceptively hard once you handle order of benefits rules properly. And the number of upstream feeds: enrolment, pharmacy accumulators, authorisations, provider data, each with its own timing and failure modes.

When we would tell you to buy

Buy if you are a conventional commercial or Medicaid plan above roughly 150,000 members with standard benefit designs and a stable network contracting model. The platforms exist, they are proven at your scale, and an implementation, however painful, is cheaper and less risky than building the same thing. We say this to prospects regularly and we mean it.

Buy also if the real pain is configuration turnaround rather than capability. Sometimes the answer is bringing configuration in house and staffing it properly rather than replacing the engine underneath it.

Build when two or more of these are true. Your benefit or payment design cannot be expressed in the platform without services work every quarter, which is the situation for most direct contracting and bundled payment models. You are under 50,000 lives and per member per month licensing is eating your administrative budget. You are a TPA whose differentiator is doing what other administrators will not. Your pend queue is dominated by a handful of pricing scenarios your configuration cannot represent. Or you are launching new and would be implementing a platform anyway, in which case the comparison is build cost against implementation cost, which is much closer than people assume.

How to choose a developer for claims adjudication software

Ask them to draw the model before anything is signed: claim, claim line, member, coverage period, benefit plan, accumulator entry, provider, contract version, fee schedule, edit, pend, adjustment. If they do not immediately ask how you handle a replacement claim and its effect on accumulators, they have not built one of these.

Ask how they will prove the engine is right. The only acceptable answer is regression against historical adjudicated claims with a line level diff, run continuously, not a test plan.

Ask what they have actually integrated. An 837 from a specific clearinghouse, an 834 from a specific enrolment source, a pharmacy accumulator file, an authorisation feed, a Medicare fee schedule refresh. Naming the transaction set is the minimum bar. Anyone who talks about health data integration without naming a transaction set has not done it.

Ask who owns the code and get it in writing before kickoff. You should hold the repository, the infrastructure accounts and the unrestricted right to hire another firm. At Digital Heroes the client owns it from the first commit. A claims engine is the machine that pays your providers, and renting the ability to change it is how plans end up trapped for a decade.