Enrollment & Claims Platform Modernization

1 · Purpose, scope and what this plan owns G-01

The RTM records G-01 as an open gap: nine transition requirements name conversion behaviour that was specified in the FSD and the Test Strategy but owned by no single maintained document. A conversion whose rules live only inside a test plan is a conversion whose rules change silently when the test plan is revised. This plan is that single owning document. It states the rules once, names an owner for each, and makes the sign-off a gate.

Out of scope, by design. TR-008/009 (training, process documentation) belong to the Training Plan; TR-010 (hypercare) and the cutover runbook belong to the Cutover Plan; TR-011 (legacy read-only retention) and TR-012 (member notification) are named there too. This plan stops at the moment converted data is accepted into production; what happens to the people and the process at that moment is the Cutover and Training plans' work.

2 · What is being converted Data scope

Four data domains move, and they do not move independently — a claim references a member, a member holds a policy, a policy names a provider network. The conversion sequence respects those dependencies: reference data first, then the entities that depend on it, then transactional history last. Loading claims before the members and providers they reference would produce orphaned transactions that reconcile to nothing — so the sequence is a correctness control, not merely an efficiency choice.

Claims history dominates the risk. It is the largest domain by record count, the oldest (so the most likely to carry data-quality debt accumulated over years of legacy operation), and the domain where the duplicate-record problem I-001 surfaced. It is also the domain whose conversion time drives whether TR-006's outage window is met. For all three reasons the plan sequences claims conversion last and rehearses it hardest — the dry runs in §5 exist primarily to de-risk this domain, because the other three are comparatively small and clean.

3 · The conversion pipeline TR-001–003

Every record travels the same five stages. The design principle is that a record can leave the pipeline in exactly two ways — converted-and-reconciled, or quarantined-and-owned. There is no third path in which a record simply disappears, because a record that silently fails to convert is a member whose claims will not adjudicate, discovered weeks later by that member.

4 · De-duplication — auditable and reversible TR-002 · I-001

TR-002 is deceptively demanding: duplicate member records must be resolved by documented rule, and every merge must be auditable and reversible. Reversibility is the hard part. A merge that cannot be undone is a decision made permanent before it has been proven right, and member-record merges are exactly the decisions most likely to be wrong — two people with the same name and date of birth are not the same member, and a merge that assumes they are creates a privacy incident, not a data-quality improvement.

• Rule-based, not judgement-based at scale. Merges are proposed by documented matching rules (identifiers, demographics, coverage overlap). The rule that proposed each merge is recorded against it, so a wrong merge is traced to a wrong rule and the rule is corrected once, for all records it touched.
• Every merge is journaled. The pre-merge state of both records is retained. "Reversible" means the original two records can be reconstructed exactly — not approximately — from the journal.
• Ambiguous matches are quarantined, not merged. Where the rule is not confident, the record goes to the TR-003 quarantine for a named data owner to adjudicate. The pipeline never guesses on identity.

5 · The three dry runs TR-004 · D-002

TR-004 requires the conversion to be rehearsed at full volume before it is run for real. This program does that three times, and the third rehearsal is pre-funded on purpose. The Test & Quality Strategy and decision D-002 pre-approved up to $150,000 of contingency for a third dry-run cycle before anyone knew whether it would be needed — because on a mandatory replacement with a fixed open-enrollment go-live, the time to discover that historical claims data is dirtier than expected is the second dry run, not the production cutover.

6 · Parallel run — the independent check TR-005

Reconciliation proves the data moved correctly. It does not prove the new platform processes it correctly. TR-005 closes that gap: legacy and new platforms are run in parallel on representative transactions, and every variance is explained before cutover. This is owned by the QA / Test Lead (R. Whitfield), not the Conversion Lead, on purpose — the party that performed the conversion should not also be the sole party certifying that its output behaves correctly.

• Representative, not exhaustive. The parallel set is chosen to exercise the cases most likely to diverge: claims spanning a benefit change (date-of-service adjudication, FS-005), claims that draw down a converted accumulator (FS-008), and commission calculations touching the I-004 divergence.
• Every variance is explained, not just counted. A variance is either a legacy defect the new platform correctly does not reproduce, or a new-platform defect — and the two have opposite dispositions. An unexplained variance is a blocking finding.
• Legacy behaviour is the reference where spec and code disagree. Per I-004, where the legacy calculation and the written spec diverge, the FSD names the authoritative resolution; the parallel run confirms the new platform implements that resolution, not the legacy accident.

7 · The outage window and the point of no return TR-006 · TR-007

Production conversion runs inside a bounded outage window during the cutover weekend. Two requirements govern it, and they are in tension: TR-006 says the conversion must complete within the window; TR-007 says a tested rollback must exist up to a defined point of no return. The tension is deliberate — the point of no return is the moment those two requirements hand off to each other.

8 · Roles and sign-off authority Governance

9 · Traceability — this plan against the RTM G-01 closed

The RTM records TR-001 through TR-010 as transition requirements and flagged G-01 because seven of them had no owning plan. With this document, they do:

TR-008 and TR-009 are owned by the Training Plan; TR-010, TR-011 and TR-012 by the Cutover Plan. Together the three plans close the RTM's transition-requirement gaps G-01, G-02 and G-03 without overlap and without a requirement falling between them.