Health Plan Claims Adjudication Software: Buy Facets, QNXT or HealthRules Payer, or Build the Pricing Layer Yourself

When is off the shelf genuinely the right call here?

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 running a very large share of American health plans, and they 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.

Buy, and stop reading here, if this describes you:

• A conventional commercial or Medicaid plan above roughly 150,000 members with standard benefit designs and a stable network contracting model.
• A smaller third party administrator running conventional business where the constraint is budget rather than expressiveness. Plexis is the sensible answer and rebuilding it is poor use of capital.
• Your real pain is configuration turnaround rather than capability. Sometimes the fix is bringing configuration in house and staffing it properly with two people, which costs less than any build on this page.
• Your pend queue is dominated by eligibility and data quality problems rather than by pricing scenarios your configuration cannot represent.
• You have no permanent owner for pricing configuration. An engine without a funded owner drifts, and the drift shows up in provider payments rather than in a status report.

Before funding anything, do the cheapest engineering in the category. Instrument your pends so each one carries a machine readable reason, the failing data element, an owner and a measured clear time, then rank them. In our delivery experience the top five reasons account for most of the volume and two are usually fixable in a single sprint. If the queue collapses, you have saved several hundred thousand dollars. If it does not, you now have the evidence a board needs.

When does a custom build actually pay off?

The platforms' common limitation is not capability, it is who can change them and how fast. Configuration depth lives with a small population of certified specialists, releases run on a quarterly rhythm, and a novel benefit design or payment model arrives as a services engagement with a statement of work attached. 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 an administrator serving employers who each want something slightly different, the configuration backlog becomes the constraint on the business rather than on the technology.

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.

Build when two or more of these are true:

• Your benefit or payment design needs vendor services work every quarter to stay administrable.
• You are under 50,000 lives and licensing scales against you as you grow.
• You are an administrator whose differentiator is doing what other administrators will not.
• Your pend queue is dominated by a handful of pricing scenarios the configuration cannot express, and an examiner clears each one by opening a contract in another window and doing arithmetic.
• You are launching new, in which case the comparison is build cost against implementation cost, which is far closer than most boards assume.

How do they compare on the things that matter in this industry?

Expressing the contract. Percent of Medicare with a year and locality. Per diem by level of care with an outlier threshold and a lesser of billed charges rule. Diagnosis related group with a transfer policy. Case rates with implant carve outs. Multiple procedure reduction. Each of those is a small programme, and a plan has hundreds of them. Ask a vendor for a price and a date on a methodology you have not signed yet, and treat the date as the answer.

Proving a price is right. This is the largest practical difference. A regression harness replays twelve months of a provider's historical claims through new pricing and diffs the outcome line by line against what was actually paid. Differences are either intended or a bug, and you know which before any provider is affected. That turns a contract change from a quarterly project into a two day task, and it is the single most valuable artifact in a build.

Accumulator behaviour. Model member cost share as an event ledger rather than a running total, with reversals as new entries rather than edits. Voids and replacements then unwind deterministically and a resent pharmacy cross accumulation file is idempotent instead of double applying. We have found that failure mode live at more than one plan, and an accumulator wrong by a few hundred dollars becomes a complaint, an appeal and a reprocessing job.

Pends as data. Most operations track volume and age. Very few can name the marginal cost of clearing a specific reason, or which three provider contracts and one group feed cause it. Without that, the only available response to a growing queue is more examiners.

Per member per month economics. Licensing scales with the thing you are trying to grow. Build cost is broadly flat against membership. Model both at the size you expect in five years, not at today's roster.

Getting your data back. Ask what an export of open claims, adjustment history and accumulator balances with audit trail looks like, and ask before you renew rather than after you decide to leave.

What does total cost of ownership look like at your scale?

These bands come from Digital Heroes delivery experience rather than a price list. A first release for one line of business, covering the 837 claim intake, eligibility and coverage periods, benefit determination, contract pricing with the regression harness, accumulators, pend workflow and 835 remittance output, runs $150,000 to $350,000 across 5 to 8 months. A genuine core replacement across all lines, adding coordination of benefits, subrogation, capitation and value based arrangements, portals and historical conversion, runs $600,000 to $2,000,000 or more over 18 to 30 months.

Membership is a weak driver. The engine that adjudicates 40,000 members adjudicates 400,000. Contract diversity, line of business count and upstream feed count are what you pay for.

A provider sponsored plan with roughly 60,000 commercial members and six distinct pricing methodologies lands at about $333,000 of build. That is not the number that gets you live. Add the shadow adjudication parallel operating period at $58,000 and twelve percent contingency, because at least one contract will price differently in production than anyone believed, and the committed figure is around $438,000 across ten months.

Running cost is 18 to 25 percent of build, so $79,000 to $110,000 a year. Then the lines that get missed: $15,000 to $40,000 for fee schedule refreshes, since published schedules change on a calendar you do not control and each refresh needs regression before it goes live. $20,000 to $50,000 for routine contract changes, plus $15,000 to $45,000 for each genuinely new methodology your contracting team agrees to. $10,000 to $30,000 for transaction set and clearinghouse companion guide changes. $25,000 to $60,000 for hosting and protected health information controls with evidence they work. $15,000 to $35,000 for independent testing, because a machine that pays your network deserves someone outside the build trying to break it.

Amortised over five years that is roughly $88,000 a year of build plus support. Against it, count the examiners clearing recurring pends, the prompt pay interest you paid last year, the reprocessing that followed pricing corrections in both directions, and whatever your contracting team gave up because a payment model could not be administered.

What does the hybrid look like, and when is it the honest answer?

For most plans this is the answer, and running a new engine alongside the platform rather than instead of it is the normal shape, not a compromise.

Keep Facets, QNXT, HealthRules Payer or Plexis for the lines of business you are not touching. Every line you defer removes both engineering and a parallel operating period, and the platform keeps doing what it is genuinely good at. Then take one line, usually commercial or a single Medicaid product, and prove the engine there.

A narrower hybrid is often better still. Leave adjudication where it is and build only the pricing layer: contracts as versioned executable logic with effective dates, the regression harness around them, and pend instrumentation feeding a ranked backlog. That is a fraction of the first release band, it attacks the exact gap between what your contracts say and what your configuration can express, and it produces the evidence for or against a larger build using your own claims rather than a vendor demonstration.

Whatever shape you choose, budget shadow adjudication explicitly. The new engine consumes production claim traffic in parallel for months, producing a nightly diff of allowed amount, member liability and pend disposition against what production actually paid. Nothing cuts over until every remaining difference is explained and intended. Plans that treat migration as a testing task rather than a parallel operating period are the plans that end up writing to their whole network.

Which should you choose, by operator size and stage?

Above 150,000 members, conventional designs. Buy. Facets, QNXT or HealthRules Payer, and accept the implementation. We tell prospects this regularly and we mean it. Spend your engineering budget on the pend instrumentation and the analytics the platform will not give you.

50,000 to 150,000 members, conventional designs. Buy, then negotiate with evidence. Ask for a five year total at projected membership plus the services rate card, and ask what a new methodology costs and how long from signature to production. If the date is a quarter and your contracting team needs a month, build the pricing layer beside the platform.

Under 50,000 lives, or launching new. Build the first release for one line, $150,000 to $350,000, plus the parallel period. At this size the comparison is against implementation cost rather than against a working system, and it is much closer than boards assume.

Administrators and direct contracting entities of any size. Build, because your product is the thing the platforms cannot express. Start with pricing and the harness, then extend outward as each novel arrangement proves itself commercially.

One rule holds across all four. Build the regression harness before the pricing, not after. It looks like overhead, and teams that skip it pay for it in reprocessing inside the first year.

When you are ready to turn this into a specification, Digital Heroes builds and runs its own products, so the people choosing your architecture live with those decisions on their own revenue. You can take that specification to any other firm on your shortlist.