Health Plan Core Administration Platforms: What to Build When Facets or QNXT Configuration Cannot Express Your Benefit

The honest starting position: the core is not the thing to rebuild

A COO at a 180,000 member regional plan describes the problem this way. Sales wants a new employer group product live for January. The benefit design has a tiered network with a carve-out for a specific orthopaedic partner and an embedded deductible structure the current configuration cannot express directly. The configuration analysts say twelve weeks, and they mean it, because expressing it will require workarounds across benefit plan, network and pricing configuration, and then a regression test cycle to make sure the workaround has not disturbed six existing groups. Sales heard twelve weeks and started negotiating anyway. Nobody in the room thinks the platform is bad. They think it is slow to bend.

Facets, QNXT, HealthRules Payer and Plexis are large, mature systems that adjudicate claims correctly at volume, carry decades of accumulated edge case handling, and are maintained against a regulatory environment that changes constantly. Rebuilding that is not a software project, it is a decade. Anyone quoting you a custom core administration platform is either misunderstanding what adjudication involves or selling you the first two years of a project they will not finish. We will say that flatly because plans get pitched it regularly.

What is true is that the packaged core covers perhaps 70 percent of what a modern plan needs, and the remaining 30 percent is where your differentiation, your regulatory exposure and your operating cost all live. That 30 percent is a legitimate and well-scoped build. The question is not whether to build, it is where.

Configuration lead time is the constraint that shapes your whole business

When a benefit change takes a quarter, the plan stops proposing benefit changes. Product strategy quietly reshapes itself around what configuration can do quickly, which is the worst possible way to make product decisions. The lead time is not usually the configuration keystrokes, it is everything around them: interpreting the benefit summary document into configuration intent, deciding which of three possible configurations to use, building it, and then testing that it pays correctly across a claim population without breaking anything adjacent.

What a build can genuinely fix here: the interpretation and testing halves, which are the bulk. A benefit intent model sits above the core, expressing a product in the terms your product team uses, cost share by service category, tiering, accumulator behaviour, carve-outs, then generating the target configuration and, more importantly, generating the test cases. Configuration testing today is usually a spreadsheet of scenarios a senior analyst wrote from memory. Automating it changes the economics: build a regression suite of real historical claims per product, replay them against a configuration change in a test environment, and diff the payment outcomes. A change that alters payment on 40 claims you did not intend to touch is visible in an hour rather than in production three weeks later.

Plans that have this report the effect immediately in cycle time, because most of the twelve weeks was never configuration, it was fear of regression. Removing that fear is worth more than any individual feature.

Value-based and delegated arrangements have no home in the core

This is where packaged platforms genuinely run out. A shared savings arrangement with a provider group, a partial capitation with risk corridors and stop-loss, a delegated arrangement where an IPA adjudicates and you reconcile encounters, a bundled payment across an episode with a defined trigger and window: these are contracts whose logic is calculated periodically over populations, not adjudicated per claim.

Core systems model fee-for-service pricing extremely well and capitation adequately. They do not model an attribution methodology, a quality gate that modifies a settlement, a risk corridor with a truing-up period, or the reconciliation of delegated encounter data against expected utilisation. So those arrangements end up in the actuarial team's spreadsheets and in a finance analyst's quarterly settlement workbook, calculated once a quarter, disputed by the provider group, and never visible to the network team until settlement.

What a custom build does: make the contract an executable object. Attribution runs on a defined methodology with a stated cadence, so a provider group can see their attributed panel continuously rather than in arrears. Settlement calculations execute against claims and encounters with every input traceable, so a dispute is resolved by pointing at data rather than by re-running two spreadsheets and comparing. Quality measure inputs feed the calculation from the same pipeline that reports them. And the provider group gets a portal showing their performance against the arrangement during the period, which is the difference between a value-based contract that changes behaviour and one that is just a retrospective payment adjustment.

For delegated arrangements, the build handles the reconciliation the core does not: encounters received against expected volume, completeness by provider, and financial reconciliation against the capitation paid. Plans running delegation without this are trusting a downstream entity's data quality on faith.

The integration estate is the actual system, and it is where projects die

The transaction set is fixed and unforgiving: 834 enrollment in from employer groups and exchanges, 837 claims in, 835 remittance out, 270 and 271 eligibility real time, 820 premium payment, plus the government-specific flows for Medicare Advantage including MMR and MOR reconciliation, and state Medicaid MMIS files that differ per state and change on the state's schedule. Around those sit the pharmacy benefit manager, the dental and vision vendors, the care management platform, the utilisation management vendor, the print and fulfilment house, the broker portal and the general ledger.

In most plans this estate is a mix of point-to-point interfaces built over fifteen years by people who have left, with reconciliation done by exception reports that somebody reads on Tuesdays. Enrollment discrepancy is the classic failure: a member is active in the core, inactive at the PBM, and finds out at a pharmacy counter. The plan discovers it through a complaint.

What a custom build does: an integration layer with the boring properties that matter. Every inbound file is retained as received, with a processing outcome per record rather than per file, so a partial failure is a queue of 12 records and not a rejected batch nobody wants to touch. Enrollment reconciliation runs on a schedule across every downstream system with a defined source of truth, and discrepancies become work items with an owner. Retries, idempotency and replay are designed in, because the question is never whether a downstream system will be unavailable during a nightly run, it is what happens when it is.

The regulatory forcing function here is real. The CMS Interoperability and Prior Authorization final rule extends API obligations for impacted payers including Patient Access, Provider Access, Payer-to-Payer and Prior Authorization APIs on FHIR, with the main compliance dates in January 2027. Your core platform vendor will offer something. Whether it covers your specific data and your prior authorisation workflow, which typically lives in a separate utilisation management system, is a question to answer now rather than in late 2026. Confirm your specific obligations with counsel, but do not wait to find out whether the vendor's answer fits.

The member and provider experience layer is yours, not the vendor's

Members judge a plan by the ID card, the explanation of benefits, the cost estimate before a procedure and the speed of an answer. Providers judge it by eligibility checks, claim status and how fast a prior authorisation moves. None of that is core adjudication, all of it is served from core data, and all of it is where a regional plan can genuinely be better than a national competitor.

Packaged member portals exist and they are serviceable. They are also identical across every plan using them, they lag your product design, and they cannot easily surface things that matter locally, like which of your contracted facilities has capacity this week or what a specific procedure will cost this member given their accumulator position today. Building that layer against your own data is a well-understood project with a clear return, and it does not touch adjudication at all, which makes it the safest place to start.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the surround programme prices as follows. A first release covering one domain properly, most often either the configuration testing and regression harness or the value-based arrangement engine, runs $120,000 to $250,000 over 16 to 24 weeks. A multi-domain programme adding the integration layer with reconciliation, delegated encounter handling, provider and member experience surfaces, and API compliance work runs $350,000 to $900,000 phased across 12 to 24 months.

Cost drivers specific to health plans: the number of lines of business, because Medicare Advantage, Medicaid and commercial each carry separate regulatory calendars and file formats, and a plan running all three is running three programmes. The number of states for Medicaid, since MMIS interfaces are state-specific. Data access to your core platform, which varies enormously, since a plan with a maintained operational data store is in a different position from one where the only route is nightly extracts. And whether any custom logic must write back into the core, which raises the vendor support and testing burden considerably compared with read and surround.

What holds cost down: choosing read-only surrounds first. Configuration testing, value-based settlement, reconciliation reporting and member experience all consume core data without modifying it, which means no vendor support risk and a much shorter path to production.

What to buy and what to build

Buy the core. If you are on Facets, QNXT, HealthRules or Plexis and it adjudicates correctly, keep it. If you are a small TPA or a startup plan under about 30,000 members, buy a core and buy the surrounds too, because at that size your differentiation is not in software.

Replace the core only for a structural reason: your current platform is genuinely end of life, or you are entering a line of business it cannot support. Then run a packaged selection with a specialist integrator and budget for a multi-year programme. That decision is not a custom development question and should not be sold to you as one.

Build the surround when configuration lead time is shaping your product roadmap, when value-based arrangements are settled in spreadsheets your provider partners dispute, when enrollment discrepancies reach members before they reach your reports, or when you have obligations arriving on a fixed regulatory date that your vendor's roadmap does not clearly cover. Provider-sponsored plans hit the value-based case first and hardest, because the arrangement with the parent system is usually the most complex contract they have and the one their core handles worst.

How to choose a developer for work around a core platform

Ask what they will not touch. A developer who is comfortable modifying core configuration or writing into adjudication tables without your platform vendor's blessing is going to cost you support coverage. The right answer starts with read-only surrounds and treats write-back as a deliberate, jointly agreed decision.

Ask how they would build a configuration regression suite from your historical claims. If they understand that replaying real adjudicated claims against a configuration change and diffing payment outcomes is the highest-value thing in the whole programme, they have worked in this sector.

Ask them to describe a partial file failure. The answer should involve per-record processing outcomes, an exception queue with owners, idempotent reprocessing and replay. If they describe file-level success and failure, your operations team will be manually reconciling forever.

Ask specifically about EDI experience by transaction: 834 companion guides differ per employer group and per exchange, 837 institutional and professional are different problems, and MMR and MOR reconciliation is its own discipline. Name the transaction, not the standard. And settle ownership before kickoff: the plan owns the repository, the cloud environment and the data. At Digital Heroes the client owns everything from the first commit, which matters most in a category where you are already dependent on a core vendor and should not create a second dependency.