Health Plan Claims Adjudication Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does scoping every line of business at once sink the build?

The scope failure that ends these projects is deciding to replace the core in one motion, across commercial, Medicare Advantage and Medicaid, with historical conversion included. It reads as decisive to a board and it turns a bounded problem into an unbounded one, because each line carries its own benefit structures, its own pricing methodologies and, for government lines, encounter data submission obligations that are a project in their own right.

Claims work is worse than most domains for this, because the pieces are not independent. Coordination of benefits, capitation and value based settlement all sit on top of fee for service pricing, so a team building everything at once is building the upper storeys while the foundation is still moving. Nothing can be proved correct until a great deal is finished, which is when a schedule stops being knowable.

The fix is to take one line of business, ideally your largest conventional one, and build it end to end: intake of the professional and institutional claim transactions, eligibility and benefit determination, contract pricing with a regression harness, accumulators, pend workflow and remittance output. Prove it in shadow against production traffic, cut it over, then add the next line. That sequence gives you a working engine early and gives every later line a proven spine to attach to. Anyone proposing all lines in one release has not run a parallel period.

What goes wrong when you convert historical claims and accumulators?

Claims history is the easy half, and it is still not easy. The hard half is accumulators. A member's deductible and out of pocket position is a running total in the legacy system, derived from years of applications, reversals and adjustments that were sometimes edits rather than entries. Import the total and you import whatever drift it accumulated, with no way to explain any individual figure to a member who disputes it.

The situation worsens where a member has moved between plans mid-year, where a family accumulator combines embedded and aggregate logic, or where the pharmacy benefit administrator sends a cross-accumulation file on its own timing. Those are precisely the members who complain, so those are the totals you least want to import blindly.

The fix is to convert accumulators as an event ledger rather than a number. Rebuild the position from the underlying claim applications wherever the source data supports it, so every figure traces to a claim, a timestamp and a reason, and reversals appear as new entries rather than edits. Where a rebuild is impossible, import an opening balance as one explicit entry labelled as converted, so a dispute investigation can see where reconstructed history begins. Then reconcile a sample of members against the legacy system by hand before go-live, choosing the awkward ones deliberately: mid-year plan changes, retroactive terminations, families near their out of pocket maximum.

Why do the intake, enrolment and reference data feeds break after launch?

Every feed into a claims engine fails eventually, and the ones that hurt fail quietly. Enrolment is the classic: a group loads a retroactive termination, membership changes underneath claims that were already adjudicated, and the engine has no signal that anything unusual happened. The pharmacy accumulator file is the second: it gets resent after a transmission problem and, if the load is not idempotent, applies twice and pushes a whole population past its out of pocket maximum.

Reference data is the quiet one. Fee schedules and code sets refresh on their own calendars, and a build that treats a schedule as a table someone imports occasionally will keep pricing against a stale version for months. Nothing errors. The claims simply price wrong, consistently, and the discovery event is a provider dispute.

The fix is threefold. Make every inbound file idempotent by construction, keyed so a resend is a no-op rather than a second application, and log the file identity so you can prove which load produced which entry. Effective-date your reference data rather than replacing it, so a claim adjudicates against the schedule that applied on its date of service and a retroactive refresh triggers an explicit reprocessing decision. And monitor expectations rather than errors: alert when a daily enrolment file does not arrive, when its record count falls outside its normal band, or when the proportion of claims pending for eligibility reasons moves sharply.

What happens when the regulatory and appeals surface is not covered?

Builds tend to model adjudication correctly and treat everything that happens around it as later work. That leaves three gaps that all cost money. The first is prompt pay: state rules attach interest to claims not paid within a defined period, so a pend queue is not only a labour cost, it is an accruing liability, and a system that cannot tell you which pended claims are approaching their clock cannot help you prioritise.

The second is the appeals record. When a provider or a member challenges an outcome, you have to reproduce why the claim adjudicated as it did on the date it did, which means the contract version, the benefit configuration, the accumulator position and the edits applied all have to be reconstructible. A system storing only final numbers cannot do this, so the reconstruction happens by hand under a deadline.

The third applies to government lines: encounter data submission is its own obligation with its own formats, timelines and rejection handling, and treating it as a reporting job at the end is how plans end up with rejected encounters they cannot resubmit in time.

The fix is to make the audit position part of the data model rather than a log. Every adjudication should record the versions of everything it used, so replaying a claim as of a past date is a query. Attach a prompt pay clock to each claim on receipt and surface it in the pend worklist, so the queue is ranked by liability rather than by age alone. And if government lines are in your roadmap at all, scope encounter submission as a first-class workstream in the phase that introduces them.

Should you build custom or configure what you already own?

If you are a conventional commercial or Medicaid plan above roughly one hundred and fifty thousand members with standard benefit designs and a stable network contracting model, buy. The established platforms are proven at your scale and do things a first build will not do for years, and an implementation, however painful, is cheaper and lower risk than building the same capability. Saying so costs us work and it is still the right advice.

Configuration also deserves a genuine attempt before anyone talks about replacement. A great deal of the pain attributed to a platform is really configuration turnaround: the depth lives with a small population of specialists, release cycles are measured in quarters, and a novel design arrives as a services engagement. Sometimes the correct answer is to bring configuration in house and staff it properly rather than replacing the engine underneath it, and that costs a fraction of a build.

Build when two or more of these hold. Your benefit or payment design cannot be expressed without vendor services work every quarter, which is the normal condition for direct contracting entities and bundled payment models. You are under fifty thousand lives and per member licensing is eating your administrative budget. You administer for employers who each want something slightly different and doing what others will not is your actual differentiator. 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 closer than most people assume.

How do hidden costs get into the quote?

The parallel operating period is the biggest omission, and it is not a testing task. Shadow adjudication means running the new engine against production claim traffic alongside the legacy system for months, producing a nightly comparison of allowed amount, member liability and pend disposition, and investigating every difference until each is explained and intended. That is real cost in both engineering and operations time, commonly a few months per line of business, and a quote showing it as a testing phase understates the project badly.

The rest of the pattern: the count of distinct pricing methodologies in your network, because each is genuine engineering rather than configuration; coordination of benefits, which is deceptively hard once order of benefits rules are handled properly; the number of upstream feeds, each with its own timing and failure modes; encounter submission for government lines; and value based arrangements, where attribution and settlement logic is usually more complex than the pricing it sits on.

The fix is to make the vendor name counts before naming a price: lines of business in scope, distinct pricing methodologies, clearinghouses, enrolment sources, whether pharmacy cross-accumulation is in scope, and how long the parallel period runs per line. A proposal that does not reference those numbers will return as change orders.

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

The single most valuable artefact in a claims build is the regression harness, and the teams that succeed build it first. Before any contract goes live, replay twelve months of that provider's historical claims through the new pricing logic and compare the outcome line by line against what was actually paid. Every difference is either an intended change or a bug, and you know which before a single provider is affected. That harness is also what turns a contract change from a quarterly project into a two day task.

Ask a candidate 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 a replacement claim affects accumulators, they have not built one of these and you will fund their education.

Insist that pends carry structure rather than volume. Every pended claim should record a machine-readable reason, the data element that failed, an owner, a resolution path and a measured clear time, which converts the queue from a staffing problem into a ranked backlog of fixable work. In practice a small number of reasons account for most of the volume, which a count of pends by age will never show.

Finally, put ownership in writing before kickoff: the repository, the infrastructure accounts and the unrestricted right to bring in another firm. A claims engine is the machine that pays your provider network, and renting the ability to change it is how organisations end up locked in for a decade.