BRD-02 — Core Administration Consolidation

Business requirements for moving Cumberland Valley's 420,000 members onto ACME's core administration platform — benefit configuration, claims adjudication, enrollment and eligibility, accumulators and correspondence — and for retiring the platform they leave behind. Issued February 6, 2024. This is the second-largest work package on the program at 17% of the cost baseline, and it is the one with no rollback.

These are requirements for EQUIVALENCE, not for correctness, and that changes what every one of them has to say. Nobody is asking whether ACME's platform adjudicates correctly — it has done so for 1,800,000 members for years. The question is whether it adjudicates a Cumberland Valley claim the same way Cumberland Valley's platform did, and where it does not, whether the difference was intended. The oracle is not a specification. It is the system being retired. ⚠ That means a requirement here is rarely "the system shall calculate X" and almost always "the system shall produce the same outcome as the retiring platform, except in the following documented cases."

1. Business Case and Objectives

2. Regulatory Drivers

3. Current State

Cumberland Valley adjudicates claims on a platform it has run for nineteen years. It works. That sentence is the whole difficulty of this document, because a system that works has no specification that anybody has read recently — it has behavior, accumulated in layers by people solving problems on the days those problems appeared.

The configuration is not small. Benefit plans carry variants for group size, funding arrangement, network tier and effective period, and the combinations multiply. Provider contracts carry pricing methodologies that differ by service category. And beneath both sits the edit library: rules that stop, pend, adjust or route a claim before it pays. Each was added for a reason. The reasons were not always written down.

Nobody in either organization holds a complete picture. The people who know the most are the configuration analysts who maintain it daily, and their knowledge is procedural rather than documentary — they know that a particular edit fires on a particular combination because they have watched it happen, not because a document told them. That knowledge is real, it is accurate, and it exists nowhere the program can read.

⚠ This is why the current state section of this BRD is shorter than it should be, and why that is honest rather than lazy. A full behavioral inventory of the retiring platform is itself a work package (§6), not an input to the requirements. The document states what is known now and names what must be discovered before build, rather than implying a completeness that does not exist.

The claims edit row is the requirement risk on this workstream, and it is not a technical problem. An edit with no documented reason cannot be safely ported or safely dropped. Porting it carries forward a rule nobody can explain, which will eventually pay or deny something in a way nobody can defend. Dropping it removes a control that may exist because of a regulatory finding, a provider dispute, or a fraud pattern from six years ago. Every edit therefore needs a decision from a person, and the only people who can supply the reason are the ones this transaction has made least certain of their futures. That is the connection between §3 and the retention plan, and it is why FR-09 requires the inventory to be completed early rather than during build.

4. Target State and Scope Boundaries

The first exclusion is the one that has to be defended repeatedly, because every stakeholder can see an improvement worth making. Benefit configuration touches thousands of decisions, and while a team is in there anyway the temptation to fix a known inconsistency is constant and reasonable. It is refused for a specific reason: a redesigned benefit cannot be validated by parallel run, because there is nothing to compare it to. ⚠ The moment a plan is improved rather than reproduced, every variance in that plan becomes a judgment call rather than a defect, and the only test this program has stops working.

5. Benefit Configuration

FR-03 is the requirement that decides whether parallel run produces signal or noise, and it has to be satisfied before testing starts rather than during it. Some differences are deliberate: a benefit interpretation being corrected, an ACME edit rule applying that the target never had, a denial code mapping to a more specific reason. If those are not written down in advance, reconciliation returns hundreds of variances, the team triages them by hand under time pressure, and the genuine defects hide among the intended ones. ⚠ The register is also, read plainly, the list of every place the program is knowingly changing a member's outcome — which is why it carries an approver rather than just an author.

6. Claims Adjudication and Edits

Normal requirements testing asks whether a system behaves as specified. That question is unavailable here, because the oracle is not a specification. It is the system being retired. The only thing that can settle a dispute about correct behavior is what the old platform actually does, and the old platform does not explain itself.

The inversion runs deeper than it first appears. On a build program a defect is a deviation from the specification, and the specification is the authority. Here a deviation from the retiring platform is a defect even when the retiring platform is wrong — because members, providers and regulators have been living with that behavior, accumulators have been built on it, and prior claims were paid under it. Reproducing a known error is a pass. Improving on it without a decision is a defect. That is not a comfortable rule and it is the correct one.

It also means the program cannot ask whether the new system is right, only whether it does what the old one did — including the parts nobody can explain. Where an edit's rationale is unknown, the requirement is not to justify it but to reproduce it, and to record that the rationale is unknown so a later decision to remove it is taken deliberately rather than by accident.

The edit inventory is where this concentrates, and it is not a technical problem. An edit with no documented reason can be neither safely ported nor safely dropped. Porting it carries forward a rule nobody can defend, which will eventually be questioned by someone who cannot be answered. Dropping it changes adjudication in a way that surfaces as claims paying differently — sometimes months later, in aggregate, as a trend nobody can trace back to a decision.

⚠⚠ And the only people who can supply the missing reasons are the ones least certain of their futures. The configuration analysts who know why an edit exists are Cumberland Valley staff, working through an integration that will not need all of them. Retention covers sixteen roles for exactly this reason, but retention buys time rather than goodwill: the program is asking people to write down the knowledge that currently makes them difficult to replace. That asymmetry is real, it is not solvable by process, and the honest response is to sequence the discovery early — while the people are still present — rather than to assume it will be available when convenient.

7. Enrollment, Eligibility and Effective Dating

FR-18 is the quiet one, and it is where migrations most often go wrong without anyone noticing for weeks. A claim for a service rendered in March must adjudicate against the benefit, provider contract and eligibility that were in force in March — not against today's configuration. A platform loaded with only current-state configuration will process a backdated claim confidently and incorrectly, and the error appears as a small allowed-amount difference on an old claim rather than as a failure. ⚠ The requirement is not "support effective dating"; it is that the migrated configuration carries its own history back far enough to cover the claims still arriving.

8. Accumulators and Coordination of Benefits

Accumulators are the entity that punishes a naive migration, because they are cumulative and therefore never fail gracefully. Almost everything else in a claims system is evaluated fresh: a benefit lookup is either right or wrong on that claim. An accumulator carries every prior claim inside it, so a small error at migration does not produce a small error once — it produces a wrong member liability on every subsequent claim until somebody notices. ⚠ And the member who notices is the one being asked to pay a deductible they have already met, which arrives as a complaint, an appeal, and a regulatory data point rather than as a defect report.

9. In-Flight Work at Cutover

A cutover is an instant on a plan and a period in reality. The plan shows a date on which adjudication moves. What actually exists at that moment is a population of work part-finished: claims received but not adjudicated, claims adjudicated but not paid, appeals open, pended items awaiting information from a provider who has not replied, and adjustments in flight against payments already issued.

None of these can be left where they are, because the platform holding them is being switched off. None can be moved naively either, because each carries state that only means something in the system that created it — a pend reason code, a partially applied accumulator, an adjustment that references an original claim by an identifier the new platform does not use.

The requirements in this section therefore specify a disposition for each category rather than a migration for all of them. Some categories are drained before cutover by stopping intake early. Some are carried across with their state translated and reconciled item by item. Some are deliberately re-worked from the source transaction rather than migrated, because reconstructing the outcome is cheaper and more auditable than translating the intermediate state.

⚠ The category that causes the most trouble is the smallest one. Items pended awaiting external information have no completion date the program controls — they wait on a provider. A cutover plan that assumes the pended queue can be drained is assuming behavior from parties with no obligation to the program's schedule, which is why FR-31 requires the pended population to be reported weekly from the start of the cutover window rather than counted once at the end.

The requirements nobody writes until the first cutover teaches them to. At the moment of transition, work is part-finished in the retiring system.

This section exists because a cutover is an instant on a plan and a period in reality. Claims are mid-adjudication, an appeal is at day nineteen of a thirty-day clock, a payment file is half-built, and a provider submitted something four minutes ago. None of that is visible in a migration plan drawn as a line between two boxes, and all of it has to be decided before the weekend rather than during it. ⚠ FR-27 in particular is a legal requirement wearing operational clothing: an appeal that restarts because the system changed is a compliance failure regardless of how it is explained.

10. Correspondence and EDI

11. Non-Functional Requirements

12. Testing and Validation

Because the oracle is the retiring platform, the primary test is a parallel run: the same claims adjudicated by both systems, outputs compared line by line. This is the only method that can answer the question the program actually has, and it constrains everything around it.

It constrains the schedule, because a parallel run cannot start until the new configuration is complete enough to produce comparable output, and cannot end until enough volume has passed through to exercise the rare combinations. Rare is where the risk sits: a benefit variant that appears in one per cent of claims still appears thousands of times a year, and it is exactly the case nobody configured carefully because nobody remembered it.

It also constrains what counts as a pass. A difference is not automatically a defect — it may be a known correction, a timing artifact, or a case where the retiring platform itself behaves inconsistently. So every difference is triaged into one of three dispositions: reproduce the old behavior, accept the new behavior with a recorded decision, or investigate. The third category is the one that consumes time, and the requirement is that it be worked to zero rather than aged out.

⚠ The tempting shortcut is to sample. Comparing a representative subset is cheaper and answers a different question — it establishes that the common paths work, which was never in doubt. The value of a parallel run is concentrated in the cases nobody thought to sample, so FR-44 specifies full-population comparison for a defined window rather than a statistically representative sample.

Testing cannot cover one thing, and §14 records it: behavior that the retiring platform produces only under conditions that have not occurred during the comparison window. Some edits fire seasonally, some on plan-year boundaries, some only when a specific coordination-of-benefits scenario arises. A parallel run proves equivalence over the period it ran, not over the configuration space, and the gap between those two is the residual risk this workstream carries into production.

13. Acceptance Criteria

1. Every Must requirement demonstrated.
2. ⚠ Parallel run reconciled to zero variance on adjudication outcome, allowed amount and member liability — every remaining difference matched to an approved entry in the expected-difference register.
3. Accumulator balances agree to the cent.
4. Claims edit inventory complete, every edit decided, every undocumented edit escalated and resolved.
5. Every trading partner re-registered and test-exchanged.
6. In-flight rehearsal completed with pended claims, open appeals and a payment cycle.
7. ⚠ No open Severity 1 or Severity 2 defect.
8. Retiring platform decommissioning date agreed and its archive retrievable.

14. Constraints, Assumptions and Dependencies

Two constraints on this workstream are inherited rather than chosen, and both narrow what the requirements can ask for.

The first is that the retiring platform must keep running, correctly, until the moment it stops. It cannot be frozen for the convenience of the migration, because it is adjudicating live claims for real members throughout. Every discovery activity, every parallel run, every extract competes with production work on a system whose operators are the same people the program needs for its own analysis.

The second is that benefit redesign is refused (§5). It is refused not because redesign is a bad idea but because a redesigned benefit cannot be validated by parallel run — there is nothing to compare it against. Allowing redesign during migration would remove the only available test of the entire workstream. Improvements are recorded and deferred to a post-cutover release with a named owner, which is a real cost: the organization spends a year unable to make changes it can see the value of.

⚠ What this document does not claim. The requirement set is written from what is known about the retiring platform's behavior today, and §6 records that the behavioral inventory is incomplete by construction. If discovery finds materially more configuration than assumed, the schedule moves — scope cannot, because equivalence is not a partial standard. Ninety per cent equivalence is not ninety per cent of a working claims system.

15. Traceability

16. Sign-Off and Approval

The target-side signature is the one that carries real weight here, and it is uncomfortable to ask for. R. Lattimore is being asked to confirm that ACME's configuration reproduces her platform's behavior — which requires her to say what that behavior actually is, including where it differs from what the documentation claims. She is also the person whose function this consolidation reduces. ⚠ The signature is not a formality: without it, the program has configured a platform against its own reading of someone else's system, and discovers the gap during parallel run rather than before it.

Related artifacts: BRD-01 — Identity Resolution · 20 — Application Disposition Matrix · 25 — Integration Architecture · 26 — Quality Plan · 11 — Master Schedule · SOW-03 — EDI Assurance · 28 — Risk Register