You are building the payer side. How do you configure benefits so a plan change does not need a code release?

The engine is small, the configuration is the product

A payer's adjudication logic is stable: identify the member, confirm coverage on the date of service, establish network status, test the benefit, apply edits, price, split the allowed amount between plan and member liability. What changes constantly is the configuration behind each of those steps — plans, benefit categories, limits, cost-share structures, network tiers, exclusions, authorisation requirements, provider contracts and fee schedules — because every renewal cycle, every new employer group and every contract negotiation rewrites some of it.

So the architecture is an engine that contains no plan knowledge at all, reading a configuration model that is versioned data. The engine's job is to resolve the applicable configuration and apply it deterministically. If a new plan design requires an engine change, the model was under-specified; if every plan design requires an engine change, you have hard-coded the business into the software and each renewal season becomes a release programme.

Effective dating is the decision everything else depends on

A claim adjudicates against the configuration in force on the date of service, which may be many months before the claim arrives and years before you next need to reproduce the decision. Every configuration object therefore carries an effective period, and the engine resolves by date rather than by currency.

The critical corollary is that a configuration version is immutable once it has been used. Correcting a plan does not update rows; it creates a new version with its own effective period, and the old version remains, forever, because it is the only explanation of the decisions made under it. The failure mode is a mutable table with an updated_at column: the moment somebody fixes a copayment amount in place, every claim adjudicated under the old value becomes unexplainable, reprocessing that claim produces a different answer with no record of why, and an audit or an appeal has no artefact to point at.

That makes the configuration store answer two distinct questions, and it needs both. What is in force for date of service D — used at adjudication. And what did we believe on date D about the configuration for date of service E — used when you have to explain why a claim paid the way it did before somebody discovered the configuration was wrong. Bitemporal storage sounds like over-engineering until the first mass correction, at which point it is the difference between a reconciled adjustment run and an argument.

Store the resolved configuration version identifiers on the claim decision itself, alongside the reason codes. It costs almost nothing and it converts "why did this pay 80 per cent" from an investigation into a lookup.

Accumulators are the hard part

Everything above treats a claim as an independent function of its inputs. Accumulators break that, and they are where payer systems actually get difficult.

A deductible, an out-of-pocket maximum, a visit or session count, and a lifetime limit are stateful and shared. They are consumed in order, they may be shared across a family as well as tracked per member, they may differ between in-network and out-of-network spending, and they reset on a plan year boundary that is not necessarily the calendar year. The consequence is that a claim's member liability is a function of every claim that came before it, so a retrospective change to an earlier claim invalidates the cost-share on every later one.

Model accumulators as a ledger rather than a balance: each claim line that consumes accumulated amounts writes a dated contribution referencing the line that caused it, and the accumulated position is the sum of contributions up to a point. This is the same reasoning that makes a financial ledger provable, applied to benefit state. Reversing a claim reverses its contributions, later positions recompute from the remaining contributions, and the sequence is auditable. A single mutable deductible_met column cannot be reversed, cannot be explained, and drifts irrecoverably the first time a reprocessing run fails halfway.

Ordering then has to be explicit. Claims do not arrive in service-date order, so you need a defined rule for the sequence in which contributions apply — service date, then received date, then a deterministic tiebreak — and reprocessing has to re-apply the sequence rather than patching the affected claim in isolation. And it has to be idempotent, because a reprocessing run will be interrupted and restarted, and a run that double-applies contributions produces member liability figures that are wrong in the direction most likely to generate complaints.

Adjustments replace, they do not edit

A claim decision is a communicated determination: a remittance went to the provider, an explanation of benefits went to the member, money moved, and both parties may have relied on it. It is not a mutable record.

So a correction is a new decision that supersedes the previous one, linked to it, with the original preserved in full including the configuration versions it used. The financial effect is expressed as the delta between the two — a further payment, a takeback, a change in member responsibility — and a new remittance is issued explaining it. This is the payer-side equivalent of a compensating ledger entry, and the reason is the same: the artefacts you already sent must remain reproducible.

Mass adjustment is the same mechanism at volume, and it needs its own tooling rather than a script written under pressure. The parts that matter are a selection query that is reviewable before it runs, a dry run reporting the financial delta and the count of affected members and providers before anything is committed, sequencing that respects accumulator ordering, and resumability. It also needs a communication plan, because the same run generates provider takebacks and member liability changes, and in many markets a payer-caused delay carries prompt-payment or interest consequences whose shape varies by jurisdiction.

Releasing configuration safely

Removing the code release does not remove the risk; it relocates it to a place with weaker tooling. A benefit configuration change can misprice a whole employer group as effectively as a bug, and it typically ships with less review.

The control that works is a replay harness. Take a corpus of historical claims, adjudicate them against the current configuration and against the candidate configuration, and diff the outcomes line by line: allowed amount, plan liability, member liability, reason codes, accumulator contributions. A change intended to affect one benefit for one plan should show differences only there, and any difference outside the expected blast radius is a defect found before release rather than a recovery project after it. The diff is also the evidence for the approval, which means the review conversation is about a concrete money delta rather than about a description of intent.

Around that sits ordinary change control, adapted rather than abandoned. Configuration lives in version control or in a store with equivalent history and attribution. Changes promote through environments. Approvals are recorded. And the authoring interface is deliberately constrained — structured editors and validation over a general expression language — because configuration that has become a programming language without a type checker, a test framework or a debugger is the worst of both worlds, and it is where "no code release needed" quietly turns into untested code written by people who were never given the tools to test it.

Effective-dated immutable configuration plus accumulators held as reversible contributions is what makes a payer system correctable. Without both, reprocessing a claim from eighteen months ago cannot reproduce the original decision, which means you can neither defend it nor safely change it.