Business requirements for the capabilities this program deliberately did not consolidate — care management preserved on the target's platform, utilization management taken best-of-both, and member services coexisting to Day 100 before absorption. Issued February 27, 2024. Scoped this way rather than by function because these three share a problem the absorption workstreams do not have.
A preserved capability has no project team, no budget line and no deadline, and that is exactly why it needs requirements. Every other workstream on this program is protected by having something to deliver: a date, a gate, a status report where a slip is visible. Preservation looks like doing nothing, so it attracts no attention, no resourcing and no reporting — and it degrades quietly while the organization watches the migrations. ⚠ Eighteen months later the capability the transaction was partly undertaken to acquire has lost its people, missed two vendor upgrades and drifted into the acquirer's operating model by default. Every requirement below is a requirement against neglect rather than against a build.
Table of Contents
Part I — Context
Part II — Requirements
- Care Management — Preserve
- Utilization Management — Best-of-Both
- Member Services — Coexist to Day 100
- Provider Network Analysis
- Non-Functional Requirements
Part III — Proving It
1. Business Case and Objectives
| Objective | Measure | Target |
|---|---|---|
| The acquired clinical capability still performs | ⚠ Readmission and chronic-condition engagement rates | At or above pre-transaction performance, measured quarterly |
| Best-of-both is actually both | Retained components from each side | Target's clinical criteria plus ACME's workflow and portal integration |
| Member service continuity through Day 100 | Member-visible service disruption | None attributable to the coexistence |
| A decision point that is actually taken | ⚠ Day 100 CRM decision | Decided on the date, with evidence — not deferred by default |
| Network analysis enabled | Combined-population provider analysis | Available to support rationalization |
2. Scope — Three Dispositions
| Ref | Capability | Disposition | What that means here |
|---|---|---|---|
| AD-07 | Care management platform | Preserve | ⚠ The target's platform survives; ACME's is retired. The acquirer's system loses. |
| AD-08 | Utilization management | Best-of-both | Target's clinical criteria configuration on ACME's authorization workflow and provider portal |
| AD-12 | Member portal and mobile | Coexist | ⚠ Sequenced after ID card reissue — members are not asked to change portal and card in the same period |
AD-07 is the row that has to survive being questioned, because it is the one where the acquirer's system is the one retired. That is uncomfortable in a way the other twenty-one rows are not: it requires ACME to accept that on this capability the smaller company was better, and it will be re-litigated by people with tenure and conviction. The requirement that protects it is FR-01 — the performance measure is stated, baselined and reported, so the decision rests on evidence that continues to exist rather than on the memory of a meeting in June.
3. Why Not Consolidate
| Capability | Consolidation would save | Why it was rejected |
|---|---|---|
| Care management | One platform, one team | ⚠ The clinical program is part of what was bought. Migrating members mid-episode and retraining care managers on a weaker toolset destroys the outcome the valuation assumed. |
| Utilization management | Simplicity | Each side is genuinely better at a different half. Taking one whole would give up real capability on the other. |
| Member portal, immediately | Earlier retirement | ⚠ Would ask members to change portal and ID card in the same period. Service-desk volume, not saving. |
The general rule these three share, and the one worth stating when a consolidation looks obviously cheaper: consolidation savings are real and the capability loss is usually invisible until later. A platform retirement shows up in next year's budget; a care management program that quietly stops performing shows up two years out as a medical cost trend nobody can attribute. The discipline is not "preserve when in doubt" — it is to require a measure. If the preserved capability cannot be shown to be better on a number, it should be consolidated. That is why FR-01 exists and why AD-08 splits rather than preserving wholesale.
4. Care Management — Preserve
| Ref | Priority | Requirement | Detail |
|---|---|---|---|
| FR-01 | Must | Performance baselined and reported | ⚠ Readmission and chronic-condition engagement rates baselined pre-close and reported quarterly. Preservation is justified by a number or it is reversed. |
| FR-02 | Must | No member migrated mid-episode | ⚠ An open care management episode completes on the platform that opened it |
| FR-03 | Must | ACME members onboarded, not target members moved | The platform is preserved and extended. ACME's population migrates to it. |
| FR-04 | Must | Care manager team retained | ⚠ The platform without the people is not the capability. Retention coverage for the clinical leads is a requirement of this BRD, not only an HR matter. |
| FR-05 | Must | Named owner and budget line post-program | ⚠ A preserved system with no owner and no budget degrades by default. Both named before program close. |
| FR-06 | Must | Vendor support and version currency maintained | ⚠ A preserved platform must not fall out of supported versions while attention is elsewhere |
| FR-07 | Must | Member feed from the surviving core platform | IF-09. Enrollment, coverage and claims context for the combined population |
| FR-08 | Should | Clinical protocols documented | What makes the program work is written down rather than held by the team that runs it |
FR-04, FR-05 and FR-06 are the requirements that make "preserve" a decision rather than an omission, and none of them is technical. A preserved platform fails in three ordinary ways: its people leave, because retention attention follows the systems being migrated; nobody owns it, because the program that decided to keep it ends and hands it to no one; and it falls out of vendor support, because upgrades are deferred while the organization is busy elsewhere. ⚠ Each is individually reasonable in the moment and together they retire the platform anyway — just slowly, without a decision, and without anyone able to point at when it happened.
5. Utilization Management — Best-of-Both
| Ref | Priority | Requirement | Detail |
|---|---|---|---|
| FR-09 | Must | Target's clinical criteria configuration retained | Criteria sets, review pathways and escalation rules |
| FR-10 | Must | ACME's authorization workflow retained | Intake, routing, turnaround management and provider portal integration |
| FR-11 | Must | The seam is specified, not discovered | ⚠ Exactly where criteria hand off to workflow, defined and documented. Best-of-both fails at the join, not at either half. |
| FR-12 | Must | Turnaround times preserved | Regulatory decision timeframes met throughout. ⚠ A slower authorization is a member access problem. |
| FR-13 | Must | Authorization status available to both platforms | IF-08. A claim adjudicating on either side can see the authorization |
| FR-14 | Should | Single provider-facing experience | ⚠ A provider should not need to know which entity a member came from |
FR-11 exists because best-of-both is the disposition that sounds best in a steering meeting and is hardest to deliver. Taking the strong half of each system is genuinely the right answer here — and it creates a join that neither vendor designed, neither team owns, and no runbook covers. Every failure in a best-of-both arrangement happens at the seam: a criteria change that the workflow does not know about, a status the workflow shows that the criteria engine does not recognize, a turnaround clock that starts in one and stops in the other. ⚠ Specifying the seam before build is the difference between a deliberate hybrid and two systems loosely stapled together.
6. Member Services — Coexist to Day 100
| Ref | Priority | Requirement | Detail |
|---|---|---|---|
| FR-15 | Must | Both service platforms operate to Day 100 | No member-visible change to how they contact their plan in the first hundred days |
| FR-16 | Must | Agents can serve either population | ⚠ Read access across both, so a member reaching the wrong number is helped rather than transferred |
| FR-17 | Must | The Day 100 decision has evidence and a decider | ⚠ Absorb or extend, decided on the date by a named owner against stated criteria. Deferral is a decision and is recorded as one. |
| FR-18 | Must | Portal migration sequenced after ID card reissue | ⚠ Members are not asked to change portal and card in the same period |
| FR-19 | Must | Contact history migrates with the member | An agent sees prior contacts regardless of which platform recorded them |
| FR-20 | Should | Single knowledge base | Agents work from one source, even while two systems run |
FR-17 is written this way because a coexistence decision point almost never gets taken; it gets passed. Day 100 arrives while the program is mid-migration, the decision is not urgent because both systems work, and the honest answer — "we have not looked at it" — is embarrassing enough that the item quietly moves to the next review. Two years later the organization is still running two member service platforms, and nobody can name the meeting where that was chosen. ⚠ Requiring the decision to be recorded including when the decision is to extend is what stops coexistence becoming permanent by omission.
7. Provider Network Analysis
| Ref | Priority | Requirement | Detail |
|---|---|---|---|
| FR-21 | Must | Combined-population provider analysis | Cost, utilization and quality across both books on conformed definitions |
| FR-22 | Must | Overlap identified | Providers contracted with both entities, with both rate structures visible |
| FR-23 | Must | Renewal-dated action | ⚠ Rate alignment happens at contract renewal. A renewal date is a constraint, not a target. |
| FR-24 | Must | Network adequacy maintained | ⚠ Regulatory adequacy tested before any termination. Rationalization may not create a gap. |
| FR-25 | Should | Provider-facing change minimized | A provider experiences one change, not one per system |
FR-23 is why network synergy re-profiles rather than fails, and it is a useful thing to be able to say precisely. Rate alignment cannot be accelerated: a contract renews when it renews, and approaching a provider early to reopen terms is a negotiation conducted from a weak position. So a delay here is a timing loss rather than a value loss — the synergy lands in a later period at the same annual run-rate. ⚠ That distinction matters when reporting: a workstream reporting behind plan on cumulative capture while its run-rate commitment is intact is in a very different position from one that has lost the value, and conflating the two produces the wrong intervention.
8. Non-Functional Requirements
| Ref | Requirement | Target |
|---|---|---|
| NFR-01 | Care management availability | Tier 1. ⚠ Clinical staff work in it during business hours; an outage is deferred care. |
| NFR-02 | Authorization turnaround | Within regulatory decision timeframes, measured end to end across the seam |
| NFR-03 | Member service response | Existing service levels maintained through coexistence |
| NFR-04 | Clinical data handling | ⚠ Care management data is clinical PHI. Access restricted beyond standard member data. |
| NFR-05 | Preserved platform currency | ⚠ Within vendor-supported versions at all times. Tracked, not assumed. |
9. Testing and Validation
| Test | Owner | Criterion |
|---|---|---|
| Clinical outcome baseline | Dr. P. Nwachukwu | ⚠ Baseline established before ACME members onboard, or there is nothing to compare against |
| Episode continuity | Dr. M. Ellsworth | No open episode interrupted by any migration event |
| Seam testing | B. Nkemdirim | ⚠ Criteria change propagates to workflow; turnaround clock is continuous across the join |
| Cross-population service | C. Hollifield | An agent on either platform can serve a member from either population |
| Network adequacy | A. Boudreaux | Adequacy modeled before any termination decision |
| Support currency | G. Whitmire | Preserved platform version confirmed supported at each quarterly review |
10. Acceptance Criteria
- Every Must requirement demonstrated.
- ⚠ Clinical performance baseline established pre-onboarding and first quarterly comparison reported.
- No care management episode interrupted by a migration event.
- ⚠ Named owner and budget line for the preserved platform, confirmed before program close.
- Utilization management seam documented and tested end to end.
- ⚠ Day 100 member services decision recorded with evidence and a named decider — including if the decision is to extend.
- Network adequacy verified before any provider termination.
- Preserved platform confirmed within vendor-supported versions.
11. Constraints, Assumptions and Dependencies
| Type | Item | Consequence |
|---|---|---|
| Constraint | Provider contract renewal dates | ⚠ Externally paced. Rate alignment cannot be accelerated. |
| Constraint | Regulatory network adequacy | Limits what can be rationalized regardless of economics |
| Constraint | Authorization turnaround timeframes | Statutory. The seam may not add latency that breaches them. |
| Assumption | Care management team is retained | ⚠ Retention-covered, all Cumberland Valley. If the clinical leads leave, the preserved capability is a platform without a program. |
| Assumption | Measured clinical advantage persists | Tested quarterly. ⚠ If it does not, the preserve decision is reversed rather than defended. |
| Dependency | Enterprise member identifier | Member feed and cross-population service both need it — BRD-01 |
| Dependency | IF-08 and IF-09 | Authorization status and care management feed — BRD-03 |
| Dependency | Conformed provider dimension | Network analysis needs it — BRD-04 |
12. Traceability
| Requirement | Design artifact | Verified by | Evidence |
|---|---|---|---|
| FR-01 to FR-08 | 20 — Application Disposition Matrix (AD-07) | Clinical outcome baseline | ⚠ Quarterly performance against pre-close baseline |
| FR-09 to FR-14 | 20 — Disposition Matrix (AD-08) | Seam testing | Propagation and turnaround-clock continuity |
| FR-15 to FR-20 | 20 — Disposition Matrix (AD-12); 36 — Day 100 Plan | Cross-population service test | ⚠ Recorded Day 100 decision with decider |
| FR-21 to FR-25 | 37 — Network Rationalization | Adequacy modeling | Adequacy result before termination |
| NFR-01 to NFR-05 | 26 — Quality Plan | Availability and currency review | Quarterly version confirmation |
13. Sign-Off and Approval
Business owner
Dr. M. Ellsworth
Chief Medical Officer, ACME · workstream lead
Date: _______________
Accountable executive
R. Villanueva
Chief Operating Officer, ACME Health
Date: _______________
Preserved capability owner
Dr. P. Nwachukwu
VP Care Management, Cumberland Valley · owns FR-01
Date: _______________
Member experience
T. Ruffalo
VP Member Experience, ACME · owns the Day 100 decision
Date: _______________
The third signature is the one that makes this document work, and it is being asked of the person with the least reason to trust it. Dr. Nwachukwu runs the capability ACME chose to keep, at the company ACME acquired, and is signing a requirement that measures her program quarterly against a baseline she sets — knowing that if the advantage does not persist, the decision reverses and her platform is consolidated after all. That is a fair bargain and it should be stated as one: the program is committing to preserve the capability on evidence, and she is committing to produce the evidence. ⚠ A preserve decision without that exchange is a favor, and favors do not survive a change of sponsor.
Related artifacts: BRD-01 · BRD-03 · BRD-04 · 20 — Application Disposition Matrix · 2 — Deal Summary · 13 — Synergy Realization Plan · 26 — Quality Plan