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."
Table of Contents
Part I — Context
Part II — Requirements
- Benefit Configuration
- Claims Adjudication and Edits
- Enrollment, Eligibility and Effective Dating
- Accumulators and Coordination of Benefits
- In-Flight Work at Cutover
- Correspondence and EDI
- Non-Functional Requirements
Part III — Proving It
1. Business Case and Objectives
| Objective | Measure | Baseline | Target |
|---|---|---|---|
| One core administration platform | Platforms in production | Two | One. The retiring platform decommissioned and dated. |
| No member's claim decided differently by accident | ⚠ Parallel run variance on outcome and amount | — | Zero unexplained variance |
| Claims timeliness maintained | Days to adjudication | Current performance | ⚠ Within regulatory limits — not merely "same as before" |
| No provider loses a submission channel | Trading partner readiness | — | Every partner re-registered and test-exchanged before their channel moves |
| Enables the TSA exit | Core platform support service | Provided by the seller | Exited. ⚠ This work is what makes that possible. |
2. Regulatory Drivers
| Ref | Driver | Requirement it creates |
|---|---|---|
| RG-01 | Prior market conduct finding | ⚠ Claims timeliness is measured and reported. A cutover that pends claims consumes an allowance the plan has already been examined on. |
| RG-02 | Prompt payment statutes | Interest accrues on late payment. A backlog is a financial liability, not only an operational one. |
| RG-03 | Appeals and grievance rules | ⚠ Statutory clocks continue across the cutover. A case does not restart because the system changed. |
| RG-04 | Explanation of benefits content | Member-facing content is regulated. A formatting change is a filed change. |
| RG-05 | Coverage continuity | No lapse in demonstrable coverage at any point in the migration |
3. Current State
| Aspect | ACME — surviving | Cumberland Valley — retiring |
|---|---|---|
| Members administered | 1,800,000 | 420,000 |
| Benefit plan definitions | Templated, inherited hierarchy | ⚠ Largely flat. Plans copied and edited rather than derived, so near-identical plans differ in undocumented ways. |
| Claims edits | Version-controlled, documented | ⚠ Accreted over years. Several have no documented owner or original reason. |
| Denial and adjustment codes | Standard code set plus extensions | Local code set. Mapping required, not assumed. |
| Effective dating | Full retroactive re-adjudication | Retroactivity supported but applied inconsistently |
| Accumulators | Real-time | Batch, updated nightly |
| Configuration knowledge | Documented | ⚠ Concentrated in a small number of long-tenured staff. Retention-covered. |
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
| In scope | Explicitly out of scope |
|---|---|
| Benefit plan configuration for all target products | ⚠ Benefit redesign. Products are reproduced, not improved, in this program. |
| Claims edit inventory, decision and porting | New edits not present in either platform |
| Enrollment, eligibility and group structure | Sales, quoting and underwriting systems |
| Accumulators and coordination of benefits | Care management — ⚠ preserved on the target platform, see BRD-05 |
| Correspondence and EDI | Provider network rationalization |
| Decommissioning of the retiring platform | Historical archive retrieval — covered by the migration wave plan |
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
| Ref | Priority | Requirement | Detail |
|---|---|---|---|
| FR-01 | Must | Reproduce adjudication outcomes | Each target plan configured so that a claim adjudicates to the same outcome, allowed amount and member liability as on the retiring platform |
| FR-02 | Must | Plan-by-plan configuration register | Every target product mapped to its ACME configuration, with the person who verified it named |
| FR-03 | Must | Expected-difference register | ⚠ Every intended behavioral difference documented before parallel run, with the reason and an approver |
| FR-04 | Must | Near-identical plans reconciled | Where the target has plans that appear identical, the differences are identified and either preserved deliberately or collapsed with approval |
| FR-05 | Must | Provider contracts and fee schedules loaded | Reimbursement terms reproduced. ⚠ A pricing difference is a contract breach, not a configuration defect. |
| FR-06 | Must | Configuration peer review | No plan goes to parallel run on one person's word |
| FR-07 | Should | Configuration derived from templates | Where the ACME hierarchy allows, so future changes propagate rather than being edited plan by plan |
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
| Ref | Priority | Requirement | Detail |
|---|---|---|---|
| FR-08 | Must | Adjudication outcome equivalence | Pay, deny or pend decisions identical for the same claim. ⚠ There is no third category between "same" and "defect" — only the expected-difference register. |
| FR-09 | Must | Claims edit inventory with a decision per edit | ⚠ Every edit on the retiring platform classified port, drop, or replace, each with a named decider and a stated reason. Completed before configuration build, not during it. |
| FR-10 | Must | Undocumented edits escalated | An edit with no discoverable reason is escalated to the Chief Medical Officer and Compliance rather than defaulted either way |
| FR-11 | Must | Denial and adjustment code mapping | Local codes mapped to the surviving code set. ⚠ The mapping is a deliverable and is itself tested. |
| FR-12 | Must | Pricing equivalence | Allowed amount identical to the cent. Rounding behavior verified explicitly. |
| FR-13 | Must | Timeliness preserved | Adjudication cycle time within regulatory limits throughout, including the cutover period |
| FR-14 | Should | Auto-adjudication rate maintained | ⚠ A drop pushes volume to manual review, which becomes a staffing problem presenting as a systems one |
7. Enrollment, Eligibility and Effective Dating
| Ref | Priority | Requirement | Detail |
|---|---|---|---|
| FR-15 | Must | Group and eligibility structure reproduced | Employer groups, subgroups, classes and rate structures |
| FR-16 | Must | Coverage history complete | ⚠ Every period retained. A member's demonstrable coverage may not shorten. Consumes the identity resolution output. |
| FR-17 | Must | Retroactive terminations and reinstatements | ⚠ Retroactivity behaves as on the retiring platform, including re-adjudication of affected claims |
| FR-18 | Must | Effective dating on all entities | Benefits, providers, groups and members all carry effective dates and are adjudicated as at service date, not as at today |
| FR-19 | Must | 834 processing per trading partner | Full-file and change-file semantics preserved per partner. ⚠ These are not interchangeable. |
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
| Ref | Priority | Requirement | Detail |
|---|---|---|---|
| FR-20 | Must | Accumulator balances reconcile exactly | Deductible, out-of-pocket and visit limits agree to the cent at cutover. ⚠ Zero variance. |
| FR-21 | Must | Accumulators computed, not copied | ⚠ Recomputed from the union of claims and reconciled to the source balance — a copied balance carries any error forward invisibly |
| FR-22 | Must | Mid-year cutover handled | Plan-year-to-date balances continue without reset. ⚠ A reset is a member paying a deductible twice. |
| FR-23 | Must | Family and individual accumulation | Both tiers reproduced, including cross-application rules |
| FR-24 | Must | Coordination of benefits | Primacy determination, order of benefits and secondary calculation reproduced |
| FR-25 | Must | COB information retained | Other-coverage records migrate with the member. ⚠ Losing them makes the plan primary by default and overpays. |
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
The requirements nobody writes until the first cutover teaches them to. At the moment of transition, work is part-finished in the retiring system.
| Ref | Priority | Requirement | Detail |
|---|---|---|---|
| FR-26 | Must | Pended claims disposition | Every pended claim either resolved before cutover or migrated with its pend reason and age intact. ⚠ The regulatory clock does not reset. |
| FR-27 | Must | Open appeals complete where they started | ⚠ A case completes in the system that opened it, with its evidence and correspondence. Statutory timeframes continue across the boundary. |
| FR-28 | Must | In-flight payment cycles | A payment run initiated before cutover completes before cutover. ⚠ No payment cycle spans the boundary. |
| FR-29 | Must | Adjustments and recoveries in progress | Migrate with their linkage to the original claim |
| FR-30 | Must | Submission freeze and drain | Defined quiet window; submissions received during it queue and process after, with receipt dates preserved |
| FR-31 | Must | Post-cutover claims to the surviving platform only | ⚠ Including claims for services rendered before the cutover date |
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
| Ref | Priority | Requirement | Detail |
|---|---|---|---|
| FR-32 | Must | Explanation of benefits content preserved | Regulated content reproduced. ⚠ A change is a filed change, not a design choice. |
| FR-33 | Must | Trading partner re-registration | Each partner re-registered and test-exchanged before their channel moves |
| FR-34 | Must | Payer identifier transition | Old and new identifiers both accepted through a defined window |
| FR-35 | Must | Business-level acknowledgment | ⚠ Every EDI interface carries a control total. A syntactic acknowledgment is not acceptance. |
| FR-36 | Must | 835 reconciles to payment issued | Across both paying platforms during coexistence |
11. Non-Functional Requirements
| Ref | Requirement | Target |
|---|---|---|
| NFR-01 | Adjudication throughput | Combined daily volume within the existing processing window, with headroom |
| NFR-02 | Eligibility response | ⚠ Real-time at the point of care. Latency here is a member turned away at a pharmacy counter. |
| NFR-03 | Availability | Tier 0. Recovery objectives per the Quality Plan, restore tested. |
| NFR-04 | Auditability | Every adjudication reproducible with the configuration version that produced it |
| NFR-05 | Cutover window | ⚠ One weekend. No rollback after the payment cycle resumes. |
12. Testing and Validation
| Test | Owner | Criterion |
|---|---|---|
| Parallel run | B. Nkemdirim | ⚠ Same claims through both platforms. Reconciliation is the assertion; completing the run is not. |
| Risk-based sampling | S. Coventry | Deliberately not representative — weighted to dual coverage, active accumulators, COB, high-cost claimants, retro terminations |
| Accumulator reconciliation | T. Calloway | Balance-by-balance to the cent |
| Effective dating regression | M. Prideaux | Backdated claims against historical configuration |
| In-flight rehearsal | R. Villanueva | ⚠ Pended claims, open appeals and a part-built payment run exercised in a dress rehearsal |
| EDI assurance | Gallatin EDI Assurance | Per SOW-03, business-level control totals |
13. Acceptance Criteria
- Every Must requirement demonstrated.
- ⚠ 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.
- Accumulator balances agree to the cent.
- Claims edit inventory complete, every edit decided, every undocumented edit escalated and resolved.
- Every trading partner re-registered and test-exchanged.
- In-flight rehearsal completed with pended claims, open appeals and a payment cycle.
- ⚠ No open Severity 1 or Severity 2 defect.
- Retiring platform decommissioning date agreed and its archive retrievable.
14. Constraints, Assumptions and Dependencies
| Type | Item | Consequence |
|---|---|---|
| Constraint | No rollback after cutover | ⚠ Claims that have adjudicated cannot be un-adjudicated. The mitigation is a longer parallel run and willingness to say no, not a better rollback plan. |
| Constraint | Parallel run duration is set by claim cycle | Must span a full month-end and payment cycle. Not compressible by effort. |
| Constraint | Trading partners move at their own pace | Externally governed. See the master schedule's externally paced dependencies. |
| Assumption | Target configuration knowledge remains available | ⚠ Held by retention-covered staff. If it leaves before the edit inventory is complete, FR-10 escalations increase sharply. |
| Dependency | Identity resolution complete | ⚠ Members must exist correctly before they can be administered. BRD-01 gates this work entirely. |
| Dependency | Integration layer operating | Accumulator and eligibility synchronization during coexistence — BRD-03 |
| Dependency | EDI assurance | Gallatin, SOW-03 |
15. Traceability
| Requirement | Design artifact | Verified by | Evidence |
|---|---|---|---|
| FR-01 to FR-07 | 20 — Application Disposition Matrix | Parallel run | Zero variance plus the expected-difference register |
| FR-08 to FR-14 | Configuration specification | Parallel run, risk-based sampling | Reconciliation report by claim type |
| FR-15 to FR-19 | BRD-01, 23 — EMPI Strategy | Effective dating regression | Backdated claim results |
| FR-20 to FR-25 | 25 — Integration Architecture | Accumulator reconciliation | Balance-by-balance agreement |
| FR-26 to FR-31 | 29 — Cutover Runbook | In-flight rehearsal | Rehearsal report |
| FR-32 to FR-36 | SOW-03 | EDI assurance | Control totals, partner readiness register |
| NFR-01 to NFR-05 | 26 — Quality Plan | Performance and recovery testing | ⚠ Tested restore evidence |
16. Sign-Off and Approval
Business owner
W. Ferriday
VP Claims Operations, ACME · workstream lead
Date: _______________
Accountable executive
R. Villanueva
Chief Operating Officer, ACME Health
Date: _______________
Target-side acceptance
R. Lattimore
VP Claims, Cumberland Valley · counterpart
Date: _______________
Compliance
J. Ferrandino
Compliance Director, Cumberland Valley
Date: _______________
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