What is configuration drift in pharmacy benefits?

Configuration drift is the gradual divergence between a health plan's intended benefit design and the way its pharmacy benefit manager's (PBM's) adjudication system actually processes claims. The benefit the plan designed and the benefit the system is running start out aligned, or close to it, and separate over time as formularies update, clinical programs launch, pricing files refresh, contracts get amended, and plan year builds carry assumptions forward. Each change is an opportunity for the system's configuration to fall out of step with the plan's intent, and the divergence accumulates quietly because aggregate reporting rarely shows it.

Drift is one of the most consistent sources of pharmacy overspend Rivera sees across its client base, and it is also one of the least visible to traditional oversight. This article covers where drift comes from, what it looks like at the claim level, and why detecting it requires a different cadence than the tools most plans have in place.

Where configuration drift comes from

A PBM's adjudication system is a layered environment. Rule engines, clinical edits, pricing files, override codes, eligibility feeds, and plan-level customizations all interact on every claim. The plan's benefit design has to be translated into that environment, and the translation is never a one-time event.

Drift typically enters through a handful of recurring channels.

Plan year builds. Each new plan year requires the PBM to rebuild or roll forward the plan's configuration. Benefit changes negotiated for January do not always translate cleanly into adjudication logic, and elements carried forward from the prior year can conflict with new terms.

Mid-year changes. Formulary updates, new clinical programs, contract amendments, and regulatory changes all require configuration updates during the plan year. Accumulators, prior authorization rules, step edits, network constructs, and member cost-sharing logic are all places where an update can land incompletely or interact unexpectedly with rules already in place.

System-level changes. PBMs patch and update their platforms continuously. Pricing files refresh. A change made for one client or one line of business can affect adjudication behavior for others. None of this is visible to the plan, and none of it requires anyone to have made an obvious mistake.

The important point is that drift does not require bad faith. Pharmacy benefit administration involves an enormous volume of interacting rules, and that volume creates real surface area for implementation gaps. The relevant question for a health plan is whether it has a mechanism to verify that the benefit running in production still matches the benefit it designed.

What drift looks like at the claim level

Configuration drift rarely announces itself in aggregate reporting, because total spend can look reasonable while individual claim categories quietly diverge from design. In Rivera's experience monitoring claims for health plans across all lines of business, drift tends to surface in patterns like these:

• A lesser-of pricing rule exists in the contract and the build, but a misclassification causes it to skip a subset of drugs or pharmacy types, so those claims pay above the lowest applicable price.

• A prior authorization requirement is active in the system but gets bypassed on certain claims because of how override codes interact with clinical edits.

• A formulary update moves a drug to a new tier, but the member cost-share logic for that tier does not propagate to every affected adjudication rule, so copays are collected against the old design.

• Coordination of benefits logic handles standard secondary payers correctly but misses edge cases with non-standard processing, creating leakage that never appears in summary reporting.

• An accumulator resets or applies incorrectly after a mid-year benefit change, affecting every claim for every impacted member until someone identifies the pattern.

Individually, many of these look small. Because they apply systematically to every claim in an affected category, the aggregate impact compounds for as long as the misconfiguration persists.

Why traditional oversight misses drift

The oversight tools most plans rely on were built for a world where benefit and contract change happened in discrete bursts. Implementation reviews check the build at the start of the plan year. Annual audits review a sample of claims after the year closes. Scorecards and dashboards summarize performance at a level of aggregation where claim-level divergence disappears.

Drift defeats all three of those tools at once. A build review cannot catch a misconfiguration introduced in April. A sample-based audit can miss a drifted category entirely if the affected claims fall outside the sample frame, and even when an audit does catch it, findings arrive months after the plan year closes, which means an error introduced early in the year can persist for 12 to 24 months before it is corrected. Rivera's payer research found that detection gap to be the norm rather than the exception.

None of this reflects a lack of diligence by health plan pharmacy teams. Those teams are actively overseeing PBM performance with the tools available to them. The limitation is scale: no team can manually test whether every adjudication rule still matches design across millions of claims, and the tools built for periodic review were never designed to.

How health plans detect configuration drift

Detecting drift requires evaluating claims continuously against the full set of rules that should govern adjudication, which is the discipline pharmacy payment integrity exists to provide. In practice, that means reviewing 100% of claims, not a sample, on an ongoing cadence, with proprietary algorithms encoded from the plan's own benefit design, contract terms, and regulatory requirements.

Rivera's approach works retrospectively, on post-adjudication claim files, typically received weekly or biweekly. Every claim is evaluated against the plan's specific logic, and when adjudication diverges from design, the pattern is identified, validated, quantified, and documented while it is still current. That timing matters twice: the plan can pursue correction before the error compounds across a full year of claims, and the root cause can be fixed so the same drift does not recur.

Continuous detection also addresses the reality that corrections do not always hold. A rule fixed in the second quarter can break again in the fourth after an unrelated system change. Monitoring that runs continuously catches the recurrence, whereas a point-in-time review confirms a fix once and then goes dark.

Frequently asked questions

What causes configuration drift in pharmacy benefits?

Configuration drift is caused by the accumulation of changes to a plan's benefit environment: new plan year builds, mid-year formulary updates, contract amendments, clinical program launches, pricing file refreshes, and PBM system updates. Each change requires the PBM's adjudication configuration to be updated, and incomplete or conflicting updates cause the system's behavior to diverge from the plan's intended design.

Is configuration drift a contract violation?

Usually not. A PBM can meet every explicit guarantee in its contract while its adjudication system processes claims in ways that diverge from the plan's benefit design. Drift is an operational gap between intent and execution, which is why contract variance reviews alone do not surface it. Systemic integrity monitoring evaluates claims against the full benefit design, not just the written contract terms.

How quickly does configuration drift appear after a benefit change?

Drift can appear immediately after any configuration event. New plan year builds and mid-year changes are the most common entry points, which means a plan that was adjudicating accurately in January may not be by March. Because drift is tied to change events rather than the calendar, it can be introduced at any point in the year.

How is configuration drift different from a plan design error?

A plan design error is a mistake in the initial setup: the benefit was built incorrectly from the start. Configuration drift is divergence that develops after a correct build, as subsequent changes cause the system to fall out of alignment with design. Both produce the same result at the claim level, which is adjudication that does not match intent, and both are detected the same way, by continuously comparing claims against the plan's design.

Can a health plan monitor for configuration drift internally?

Health plan pharmacy teams already review claims and challenge discrepancies with the tools they have, but drift detection requires testing every claim against the full set of design, contract, and regulatory rules on an ongoing basis. That is an infrastructure problem rather than an effort problem. Independent continuous claims monitoring provides the scale that manual review and periodic audits cannot.