Enrollment & Claims Platform Modernization

01 Document Control & Purpose

This document is the baselined statement of what the business needs from the Enrollment & Claims Platform Modernization program. Every downstream artifact — the functional specification, the test strategy, the vendor statements of work — traces back to a requirement identified here, and a change to any of them that does not trace to a change here is a change nobody agreed to.

Requirements are baselined at the Nov 3, 2026 milestone. After that date the Change Control Board is the only authority that can alter them, and the reason is not procedural fussiness: the vendor statements of work are priced against this document, so a requirement that moves after baseline moves money.

This BRD states requirements in business terms and is deliberately design-agnostic: it defines what must be true of the solution and why, not how the vendor's platform will achieve it. Configuration and technical design decisions belong to the Solution Architect and the vendor, traced back to the requirements below.

02 Executive Summary

Two sentences are worth stating before anything else, because everything below follows from them. First, this program exists because the incumbent platform version reaches vendor end-of-support — not because a business case identified an opportunity. Second, the platform is the system of record for enrollment and claims, so the migration cannot be staged behind a feature flag or rolled out to a pilot population.

Together those produce an unusual risk profile. The program carries very little product risk — the target version is proven and already runs elsewhere — and very high transition risk. Almost everything that can go wrong goes wrong in conversion, in the interfaces, or on the night of cutover, which is why the transition requirements in §13 are treated with the same seriousness as the functional ones in §11.

The organization's enrollment and claims platform has reached the end of its vendor-supported life. The vendor has announced end-of-support, and the platform cannot be extended past that date. This is therefore a mandatory replacement, not a discretionary modernization — a distinction that shapes every requirement and prioritization decision in this document.

The program delivers a vendor-delivered core platform upgrade, conversion of member, policy, provider/producer and historical claims data, and re-establishment of six downstream integrations. Go-Live is targeted for August 24, 2027, ahead of the following open-enrollment period.

03 Business Context & Drivers

The single fact that shapes this program is that the incumbent platform version passes vendor end-of-support. The deadline is external. It was not chosen by the program, it cannot be negotiated with the sponsor, and it does not move because the program is late.

That inverts the usual relationship between scope and schedule. On a discretionary program, pressure on the date is relieved by reducing scope. Here the largest element of scope — running a supported version — is the reason for the deadline, so it cannot be reduced to protect the date. What can flex is everything arranged around it, which is why the requirements below are prioritized by MoSCoW rather than presented as a flat list.

The consequence for Compliance and Internal Audit is stated plainly in the table: an unsupported system of record for regulated healthcare data has no forward path for security patching or regulatory updates. That is not a risk to be managed to an acceptable level. It is a condition the organization cannot be in.

There is a second-order effect worth naming. Because the date is fixed and the largest scope item is fixed, the only remaining variable is quality of execution — which means the program's contingency is not in schedule or scope but in how early problems are found. Every decision below that looks like caution is really an attempt to move discovery earlier: the conversion rehearsals, the parallel run, the requirement that the claims-edit inventory be completed before build rather than during it.

04 Business Objectives & Success Measures

Each objective below carries a measure and a milestone, because an objective without a measure cannot be failed and therefore cannot be delivered. The measures are deliberately unflattering: they are the ones the program can be held to at Go-Live on Aug 24, 2027 and at closeout on Nov 2, 2027, rather than the ones easiest to report green.

⚠ Note what the objectives do not claim. None of them promises improved adjudication accuracy, faster claims processing or reduced operating cost. The program is a platform upgrade, and improvements that happen to arrive with it are not what it was funded to deliver. Claiming them here would create requirements nobody committed to build.

The measures also decide what “done” means for the program as a whole. Closeout on Nov 2, 2027 is not the day the last defect is fixed; it is the day the objectives below can be evidenced. Anything outstanding at that point is transferred to run rather than held open, which is why the hypercare exit criteria in §13 matter more than they appear to.

05 Scope

Scope is stated in both directions, and the exclusions do more work than the inclusions. On a forced upgrade the pressure to absorb adjacent work is highest exactly when the deadline is closest: every deferred improvement in the organization has a sponsor who can argue it would be cheaper to do now, while the system is open.

⚠ That argument is usually true and still has to be refused. Each addition extends the one path that cannot slip, and a program that arrives late to a supported version has failed at the only thing it could not fail at. Work excluded here is not judged unworthy — it is judged separable.

The six downstream integrations are in scope because they are not separable: an interface that is not re-established is a business function that stops on the day of cutover.

One exclusion deserves naming because it will be revisited. Benefit redesign is out of scope: products are reproduced, not improved. Several are known to be configured in ways nobody would choose today, and the temptation to correct them during a migration that touches every product is considerable. Correcting them here would mean members' benefits changing as a side effect of an IT program, with no separate decision and no separate communication.

Functional decomposition

In scope

• Core platform version upgrade (vendor-delivered) and configuration to current business rules.
• Conversion of member, policy, provider/producer and historical claims data from the legacy platform.
• Six downstream integrations: Billing, Underwriting, Claims Administration, Commission Management, Data Warehouse/Reporting, Payment Processing.
• Operational and regulatory reporting continuity.
• User training, process documentation, cutover execution and legacy decommissioning planning.

Out of scope

• New product lines, benefit designs or business capabilities not present in the legacy platform.
• Re-engineering of downstream systems themselves beyond their interfaces.
• Ongoing run-state production support beyond the vendor warranty period.
• Member- or provider-facing portal redesign.

06 Stakeholders

The stakeholder list matters more on this program than on most, because the requirements are not derivable from a specification. Much of what the platform must do exists only as accumulated configuration and operating practice, and the people below are where that knowledge lives.

Two dependencies are worth naming. F. Jones owns the baselined requirements as the configuration basis, so a gap here is a gap the vendor cannot fill from the outside. T. McCormick owns conversion and reconciliation, which is the work that determines whether the requirements below were met in fact or only in test.

The list is also a retention map, and that is uncomfortable to write down. Several of the people whose knowledge is load-bearing here are the ones whose roles change most when the legacy platform is decommissioned. A requirements process that depends on their cooperation while the program removes the system they are expert in has an obligation to say so, and to capture what they know early rather than assume availability throughout.

07 Current State & Future State

The current-state column is not documentation of a designed system. It is a description of what two decades of production have left behind: benefit configuration copied and edited rather than derived, historical claims with known duplication, and interfaces built point-to-point as each downstream system arrived.

⚠ This is why the oracle is the retiring system rather than a specification. For most of the surface the requirement is not "the system shall calculate X" but "the system shall produce what the current system produces" — including behavior nobody can now explain. Reproducing it faithfully is the requirement; improving it without a decision is a defect, because a member's benefit changing silently is indistinguishable from the system being broken.

The future-state column is therefore narrower than it looks. It commits to a supported version, converted and reconciled data, and re-established integrations. It does not commit to better outcomes, and the distinction is the difference between a program that can be finished and one that cannot.

The practical consequence for this document is that its requirements are written in an unusual voice. Where a greenfield BRD says what the system shall do, most of §11 says what the system shall continue to do — and the evidence for each is a behavior observed on the retiring platform rather than a policy anyone can produce. That is uncomfortable to sign and it is the honest description of the situation.

It also sets the acceptance standard. “Same as before” sounds like a low bar until it is tested: proving sameness across two decades of accumulated configuration is harder than proving conformance to a specification, because a specification is finite and accumulated behavior is not.

08 Requirements Elicitation Approach

The technique mix below is chosen for what each surfaces reliably, and the weighting toward document analysis and observation is deliberate. On a system whose behavior is the requirement, interviews alone produce what people believe the system does, which is a description of the parts they touch and the parts they remember being surprised by.

⚠ Observation is included because the gap between described and actual process is where undocumented requirements live. A workaround performed daily for years is not reported as a requirement by the person performing it — it has stopped being visible to them — but its absence after cutover is experienced immediately.

Requirements were elicited using a combination of techniques recognized by both the PMBOK® Guide and the BABOK Guide, chosen for what each surfaces reliably:

09 Business Requirements BR

Business requirements state what the organization needs, independent of any solution. They are the layer that survives a change of vendor, and each one below is written so that it could be satisfied by a different platform than the one selected.

Eight is a small number deliberately. A business requirement that decomposes into another business requirement is a solution requirement wearing the wrong label, and a list that runs to forty entries has usually collected design decisions on the way. Everything more specific sits in §11 and §12, traceable back to one of these eight.

Each is written to survive the question a sponsor eventually asks: what happens if we do not do this? For a genuine business requirement the answer is a consequence to the organization — a regulatory exposure, a function that stops, a cost that recurs. Where the honest answer is that something is less convenient, the entry belongs in §10 or §11 rather than here.

Why the change is being made and how success will be assessed — the highest-level statement of need, from which all other requirements derive.

10 Stakeholder Requirements SR

Stakeholder requirements state what a particular group needs in order to do its work, and they are the layer where competing needs become visible rather than being resolved silently in design. Seven are listed, each attributed to a named stakeholder group rather than to “the business”.

Attribution matters when a trade-off has to be made. A requirement owned by everyone is defended by nobody, and the ones most likely to be quietly dropped under schedule pressure are exactly those whose owner is not in the room when the decision is taken.

Needs of specific stakeholder groups that the solution must satisfy in order to meet the business requirements above.

11 Solution Requirements — Functional FR

Functional requirements are where the reproduce-rather-than-improve rule bites hardest. Twenty are listed, and most describe behavior the current system already has — which makes them easy to under-specify, because everyone in the room already knows what the system does.

⚠ Each is therefore written to be testable against the retiring platform rather than against an opinion. Where current behavior is known to be wrong, the requirement still describes the current behavior and the correction is raised separately as a change. That is the only way the program can answer the question it will actually be asked after cutover: did anything change that we did not decide to change?

Capabilities the solution must provide. Stated as business behavior, not platform configuration.

Core platform & administration

Integrations — six downstream systems

Reporting & compliance

12 Solution Requirements — Non-Functional NFR

Non-functional requirements are where a platform upgrade is most often under-specified, because the current system's performance is familiar rather than measured. “As fast as it is now” is not a requirement — nobody has recorded what now is, and the number will be argued about after cutover, when it is too late to design for.

⚠ The availability and recovery requirements are the ones that will be tested by events rather than by testers. They are stated against the operational reality of a health plan: a member cannot be told eligibility is unavailable because a batch overran, and a provider cannot be told a claim was lost in transit between two systems the plan chose to connect.

13 Transition Requirements TR

Transition requirements carry more weight on this program than functional ones, and they are usually the first thing dropped when a schedule tightens. They describe the work of moving between two supported states — conversion, reconciliation, cutover, hypercare and decommission — none of which appears in the platform's feature list, and all of which determines whether Go-Live on Aug 24, 2027 is a success.

Twelve are listed, and they are the requirements most likely to be met partially. A conversion that moves 99% of historical claims is not 99% successful; the missing 1% is a member whose history is wrong, discovered one claim at a time over the following year.

Hypercare is included here rather than treated as an afterthought because it is where the program learns what conversion actually did. The requirements specify an exit based on evidence — defect rates, reconciliation results, users operating unaided — rather than on the calendar, since a hypercare period that ends on a date rather than on a condition simply relabels open problems as run problems.

14 Prioritization Method

MoSCoW is used because the external deadline forces a genuine ordering. On a program whose date can move, prioritization is advisory; here it is the mechanism by which the program arrives on a supported version with the most valuable subset of everything else.

⚠ The classification is only honest if Must is expensive to claim. A requirement is Must only where its absence at Go-Live means the plan cannot enroll a member, cannot adjudicate a claim, or cannot meet a regulatory obligation. Everything else — however desirable, however loudly requested — is Should or below, and the discipline is what makes the list usable when the schedule tightens.

The method is also a forecast of the conversation the program will have in spring 2027. By then the date will be immovable and the remaining work will exceed the remaining time — that is the normal condition of a deadline-driven program, not a sign of failure. What determines the outcome is whether the prioritization was done honestly a year earlier, when nothing was at stake, or is being done under pressure by whoever is loudest in the room.

The Won't category is written down deliberately. On a mandatory replacement, the same enhancement requests resurface repeatedly; recording the decision and its date is what stops the scope boundary being renegotiated informally.

15 Assumptions, Constraints & Dependencies

The distinction below is load-bearing. An assumption is something believed true that has not been proven, and its failure is a risk the program carries. A constraint is a fact the program cannot change and must design around. A dependency is work owned by someone else on which delivery rests.

Conflating them produces a plan that looks robust and is not: an assumption recorded as a constraint stops being monitored, and a dependency recorded as an assumption has no owner to chase. Each entry below is classified accordingly, and the dependencies carry names rather than teams.

The constraints are the entries worth reading twice. Two of them — the end-of-support date and the regulatory obligations the platform carries — are not merely fixed but external, meaning no authority inside this program or this organization can vary them. A plan that treats an external constraint as negotiable will discover otherwise at the point it matters most.

16 Traceability

Traceability is what makes this document auditable rather than merely written. Every solution requirement traces to a stakeholder or business requirement, and every business requirement traces to a driver in §03 — so a requirement with no trace is either unnecessary, or evidence that a driver was never written down.

⚠ The trace runs forward too. A test case with no requirement behind it tests something nobody asked for, and a requirement with no test is a commitment nobody will check. Both directions are verified before the baseline is declared.

Every requirement traces forward to the artifacts that implement and verify it. Traceability is maintained by the Lead Business Analyst and reviewed at each phase gate.

17 Risks to Requirements Integrity

This section is about risks to the requirements, not to the program. The distinction is easy to lose and worth holding: the program risk register tracks what could stop delivery, while this tracks what could make the delivered thing wrong even though delivery succeeded.

⚠ The largest of these is knowledge loss. Requirements reconstructed from a system rather than a specification depend on the people who operate it, and those people are the ones for whom an upgrade is most unsettling. A requirement that was never captured does not appear anywhere as a gap — it appears after cutover as a member or provider experiencing something the plan did not intend.

The second risk is subtler and harder to mitigate: requirements that are correct at baseline and quietly stop being correct. Regulatory change, a vendor product decision, or a business process that shifts between Nov 3, 2026 and Go-Live can each invalidate a requirement without anyone noticing, because nothing prompts a re-read of a document that has already been approved. The mitigation is a scheduled re-validation at each phase gate rather than reliance on someone raising it.

18 Approval

Approval baselines this document at the Nov 3, 2026 milestone. From that point the requirements below are the agreed statement of need, the vendor statements of work are priced against them, and change runs through the Change Control Board.

⚠ Signing here is not agreement that the requirements are complete — on a system whose behavior is its own specification, completeness cannot be demonstrated. It is agreement that they are the best available statement of need, and that anything discovered later will be handled as a change rather than treated as an omission somebody should have caught.