Health Plan Core Administration Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does replacing the core keep getting proposed?

Because the symptom is felt by everyone and the cause is visible to almost nobody. Sales wants a product live for January. Configuration says twelve weeks. Product strategy quietly reshapes itself around what configuration can do quickly, which is the worst way to make product decisions. In the room, the platform is the thing everyone can point at.

What is actually happening is that most of the twelve weeks is not configuration keystrokes. It is interpreting the benefit summary into configuration intent, choosing between three possible ways to express it, and then proving the change did not disturb six existing groups. That last part is the bulk, and it is fear of regression rather than difficulty of configuration.

Replacement does not touch that. A new platform arrives with new configuration, new conventions and a fresh absence of regression tooling, and the twelve weeks becomes fourteen while the team learns.

The scoping discipline that works is to define the programme as the surround and to say out loud, in the first steering meeting, that adjudication is out of scope permanently rather than for now. Then pick one domain and finish it. Usually that is the configuration regression harness, because it attacks the constraint everyone is actually feeling, or the value based settlement engine, because it removes a quarterly dispute with your largest provider partner. A first release covering one domain properly runs $120,000 to $250,000 over 16 to 24 weeks in our delivery experience. A genuine core replacement is a different species of programme and it should be a packaged platform selection with a specialist integrator, not a custom development project.

What goes wrong when you try to get data out of the core?

Every surround build depends on reading core data reliably, and the position plans start from varies enormously. A plan with a maintained operational data store is in a completely different situation from one whose only route is a nightly extract job somebody wrote in 2014.

Three problems recur. The first is latency mismatch. A configuration regression harness replaying historical claims can live happily on nightly data. A provider portal showing claim status cannot, and discovering that distinction after design is an expensive rework. Decide per feature what staleness is acceptable before anything is built.

The second is semantic drift between the extract and the platform. The extract was built for a reporting need years ago, someone filtered out a claim status that seemed irrelevant, and now your settlement calculation is quietly missing adjustments. This is not a technical failure, it is an undocumented business rule embedded in a job nobody owns.

The third is history. Value based settlement, attribution and regression testing all need multiple years, and older periods often sit in an archive with a different schema after a platform upgrade.

The fixes are unglamorous. Profile the extract against the platform on a sample before design, not after, and treat every difference as a finding rather than noise. Write down the acceptable staleness per feature. Get your platform vendor into the conversation early about supported data access paths, because the supported route is slower to agree and far cheaper to live with than one you invented. And scope historical loading as its own work package with its own budget line, since it is frequently the largest single item.

Why do the transaction feeds and vendor interfaces break after launch?

The integration estate is the actual system, and in most plans it is a mix of point to point interfaces built over fifteen years by people who have left. A surround build that touches it inherits all of that.

The classic failure is file level thinking. A nightly 834 arrives, one hundred records fail validation, and the whole file is rejected because the interface treats a file as the unit of success. Nobody wants to open a rejected batch, so it sits, and enrollment drifts between the core and the pharmacy benefit manager until a member finds out at a pharmacy counter.

The second is that companion guides differ per employer group and per exchange, so an 834 that works for one source breaks quietly for another. The third is that downstream systems go offline during your nightly window, which is a certainty rather than a risk.

The fixes are the boring properties that matter. Retain every inbound file exactly as received. Record a processing outcome per record rather than per file, so a partial failure is a queue of twelve records with an owner rather than a batch nobody touches. Make reprocessing idempotent so a replay cannot double apply. Run enrollment reconciliation on a schedule across every downstream system with a defined source of truth per data element, and turn discrepancies into work items rather than into an exception report someone reads on Tuesdays. Ask any prospective developer to describe a partial file failure. If they answer in terms of file success and failure, your operations team will reconcile manually forever.

What happens when the API obligations are not covered in time?

The CMS Interoperability and Prior Authorization final rule extends application programming interface obligations for impacted payers, including Patient Access, Provider Access, Payer to Payer and Prior Authorization interfaces built on FHIR, with the main compliance dates in January 2027. Confirm your specific obligations with counsel, because the applicability rules matter more than the headline.

The failure mode is not ignorance of the deadline. Every plan knows the date. The failure is assuming the core platform vendor's offering covers it and discovering in late 2026 that it covers the parts that live in the core. Prior authorisation typically does not live in the core. It lives in a separate utilisation management system, sometimes with a delegated vendor, and the data the rule concerns has to be assembled across both.

The second failure is treating this as a compliance project rather than a data project. Standing up FHIR endpoints is well understood work. Producing complete, accurate, correctly attributed clinical and claims data behind them, from an estate that currently reconciles by exception report, is the part that takes time.

The fix is to run a gap assessment now rather than a build. Map each obligation to the system that actually holds the data, get a written answer from your core vendor about exactly which obligations their offering satisfies for your configuration, and identify the gaps while there is still room to fill them. Plans that do this in early 2026 have options. Plans that do it in late 2026 have one option and it is expensive.

Should you build custom or configure what you already own?

Keep the core. If you run Facets, QNXT, HealthRules Payer or Plexis and it adjudicates correctly, that is the right decision and it stays the right decision. If you are a small third party administrator or a startup plan under roughly 30,000 members, buy the core and buy the surrounds too, because at that size your differentiation is in service and network rather than software.

Before commissioning anything, ask your platform vendor three specific questions in writing. Can we stand up a test environment with production like claim volume for regression testing, and what does it cost. Which of our CMS interoperability obligations does your offering satisfy for our configuration and lines of business. And what is the supported path for reading configuration and claims data at the latency we need. Sometimes the answers are better than the operations team assumes, because the capability exists and nobody switched it on or nobody budgeted the environment.

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 on a fixed 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 health system is usually the most complex contract they have and the one their core handles worst.

How do hidden costs get into the quote?

• Lines of business, not member count. Medicare Advantage, Medicaid and commercial each carry separate regulatory calendars and file formats. A plan running all three is running three programmes.
• States, for Medicaid. Management information system interfaces are state specific and change on the state's schedule, not yours.
• Test environments. Regression testing needs an environment with realistic volume. Some vendors provide one, some charge, and the answer changes the schedule.
• Write back. Anything that modifies core configuration or adjudication data raises vendor support and testing burden considerably compared with read and surround, and it can cost you support coverage. Price it as a separate decision.
• Historical data loading. Attribution, settlement and regression all need years. Older periods behind a platform upgrade may need schema translation.
• Running cost. Roughly 15 to 20 percent of build cost per year, weighted toward regulatory change rather than infrastructure, because the calendar does not stop.

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

The successful programmes start read only and stay read only for as long as possible. Configuration testing, settlement calculation, reconciliation reporting and member and provider experience surfaces all consume core data without modifying it, which means no vendor support risk and a far shorter path to production. Treat any write back as a deliberate decision made jointly with your platform vendor, in writing, rather than as a technical detail an engineer resolves.

The second marker is that the regression harness replays real adjudicated claims rather than synthetic scenarios. Real claims carry the edge cases your configuration analysts have been quietly working around for years. Diffing payment outcomes on a configuration change and finding forty claims you did not intend to touch is the moment the twelve week cycle starts collapsing, and it is the single highest value thing in the whole programme.

The third is that value based arrangements become continuous rather than retrospective. If a provider group only sees their attributed panel and their performance at settlement, the contract is a payment adjustment rather than something that changes behaviour. Continuous visibility is what makes the arrangement work clinically, and it also removes the quarterly dispute, because both sides are looking at the same data throughout.

The fourth is that reconciliation has owners. Discrepancies become work items with names attached, not an exception report, because reports get read when someone has time.

The fifth is ownership. The plan owns the repository, the cloud environment and the data, from the first commit and in writing. This matters most in a category where you are already dependent on a core vendor and should not create a second dependency on top of it.