Business requirements for resolving 420,000 Cumberland Valley member identities against ACME's 1,800,000, and for the enterprise master patient index that holds the result. Issued January 29, 2024, three weeks after Day 100 and one week after the program re-baseline. This is the largest single work package on the program at 22% of the cost baseline, and it sits on the critical path from end to end.
The requirement that shapes every other requirement in this document: in healthcare the two matching errors are not symmetrical. A false negative leaves a duplicate record — visible, irritating, eventually noticed and merged. A false positive merges two people, which means one member's protected health information sitting under another's identity, claims adjudicating against the wrong history, and a clinician reading a chart that is not their patient's. And unlike a duplicate, nothing in normal operations surfaces it: the member does not know, the system does not flag it, and it is typically found by accident months later. Every threshold, review band and audit requirement below follows from that asymmetry rather than from a preference for caution.
Table of Contents
Part I — Context
Part II — Requirements
- Functional Requirements — Matching
- Functional Requirements — Survivorship
- Functional Requirements — Steward Workflow
- Data Requirements
- Integration Requirements
- Non-Functional Requirements
Part III — Proving It
1. Business Case and Objectives
| Objective | Measure | Baseline | Target |
|---|---|---|---|
| One identity per member across the combined entity | Duplicate rate in the master index | Not measurable — two indexes | Below the accepted threshold at go-live and sustained |
| No member merged with another member | ⚠ Audited false-positive rate | Unmeasured | Zero tolerated in audit; any instance is a Severity 1 |
| No member loses coverage history | Coverage period completeness | Complete in each source | Complete in the union. ⚠ Never an overwrite. |
| Core administration cutover can proceed | Review queue cleared and reconciled | — | Cleared within the migration window |
| Data center exit is not blocked by identity work | Wave 5 gate | — | ⚠ Wave 5 is gated by this work, not by infrastructure |
The second objective is the only one on this program stated as a tolerance of zero, and it is deliberate. Every other measure here has an acceptable band, because every other failure is recoverable — a duplicate is merged, a missing coverage period is restored from source, a late queue costs schedule. A merged pair is not recoverable in the same sense: the PHI has already been disclosed, the claims have already adjudicated, and unpicking two people who have been one record for four months is a manual reconstruction with no authoritative source to reconstruct from.
2. Regulatory Drivers
| Ref | Driver | Requirement it creates |
|---|---|---|
| RG-01 | HIPAA Privacy Rule | A merged pair is an impermissible disclosure of protected health information. ⚠ Discovery starts a breach assessment clock. |
| RG-02 | HIPAA Security Rule | Audit controls over every record-level decision, retained and reviewable |
| RG-03 | State insurance approval condition | ⚠ Member-level data may not be processed or accessed outside the United States. Removes offshore capacity as an option for clerical review. |
| RG-04 | State record retention | Coverage history retained for the statutory period; a merge may not truncate it |
| RG-05 | Prior market conduct finding | Claims timeliness is measured; identity errors that pend claims consume that allowance |
3. Current State
| Aspect | ACME Health | Cumberland Valley Health Plan |
|---|---|---|
| Members | 1,800,000 | 420,000 |
| Identity model | Enterprise index, single member identifier | ⚠ Identifier issued per line of business; a member with two products has two records by design |
| Name capture | Standardized at entry | ⚠ Free text. Nicknames, initials, suffixes and transpositions all present. |
| Address | Validated against postal reference at entry | Not validated. Historical addresses not updated on move. |
| Government identifier | Validated format, checksum | ⚠ Optional field. Mis-keyed values present and not detectable at entry. |
| Date of birth | Mandatory | Mandatory, but transposition errors present |
The row that does most of the damage is the identifier model, not the free-text name. Name variation is a known problem with known techniques — standardization tables, phonetic encoding, edit distance. An identifier issued per line of business is different in kind: it means the target's own data contains intentional duplicates that are correct in the source system and wrong in the target. The program is not only matching across two companies; it is first resolving a population against itself, and the requirement in §5 to run internal resolution before cross-entity matching exists entirely because of this row.
4. Target State Capability
A single enterprise master patient index holding one identity per member for the combined population, with a documented, auditable derivation from both sources.
| Capability | Description |
|---|---|
| Deterministic matching | Exact and rule-based matching on high-confidence identifiers |
| Probabilistic matching | Weighted comparison producing a score, with configurable thresholds |
| Three-outcome model | ⚠ Auto-match, auto-reject, and a clerical review band worked by people — not a binary decision |
| Survivorship | Attribute-level rules determining which source wins for each field |
| Steward workbench | Queue, decision capture, immutable audit trail |
| Cross-reference retention | ⚠ Both source identifiers retained permanently against the enterprise identity |
| Unmerge | ⚠ The ability to reverse a merge, with full history. Rarely used and essential. |
5. Functional Requirements — Matching
| Ref | Priority | Requirement | Detail |
|---|---|---|---|
| FR-01 | Must | Internal resolution before cross-entity matching | ⚠ Target duplicates are resolved within the target population first. Matching two dirty populations against each other compounds the error. |
| FR-02 | Must | Deterministic pass | Exact match on government identifier plus date of birth, or on a shared member identifier. Expected to resolve approximately 65% of records. |
| FR-03 | Must | Name standardization | Nickname and diminutive tables, suffix and prefix handling, phonetic encoding for surname variation |
| FR-04 | Must | Address standardization | Postal reference validation and change-of-address lookup applied to both populations before comparison |
| FR-05 | Must | Blocking | ⚠ Candidate pairs generated by blocking keys. Pairwise comparison of 1,800,000 against 420,000 is not computationally feasible and is not attempted. |
| FR-06 | Must | Probabilistic scoring | Weighted agreement and disagreement per attribute, producing a single comparison score |
| FR-07 | Must | Three configurable thresholds | Auto-match above the upper threshold, auto-reject below the lower, clerical review between them. Approximately 27% expected to auto-match probabilistically and 8% to fall into review. |
| FR-08 | Must | Threshold asymmetry | ⚠ Thresholds are set so that uncertainty resolves toward review, never toward merge |
| FR-09 | Must | Every decision auditable | Score, contributing attributes, rule version and outcome retained per pair — including auto-decisions |
| FR-10 | Should | Rule versioning | A change to rules or thresholds is versioned, and prior decisions identify the version that produced them |
| FR-11 | Should | Re-run capability | Ability to re-score a cohort under revised rules without discarding steward decisions |
FR-07 and FR-08 together are the whole design, and FR-08 is the one that gets argued about. A wider review band means a larger queue, more stewards, more cost and more schedule — every pressure on the program points at narrowing it. The band is wide because narrowing it does not remove the uncertain pairs; it merely decides them automatically, and the automatic decision in the uncertain range is the one that merges two people. ⚠ The review band is not inefficiency to be optimized away. It is where the program has chosen to spend money rather than accept an unrecoverable error, and any proposal to narrow it is a proposal to change that trade.
6. Functional Requirements — Survivorship
| Ref | Priority | Requirement | Detail |
|---|---|---|---|
| FR-12 | Must | Survivorship is per attribute | ⚠ Each field has its own source-of-truth rule. "Newest record wins" applied globally is prohibited. |
| FR-13 | Must | Coverage history is a union | ⚠ Every coverage period from both sources is retained. A merge may never shorten a member's entitlement. |
| FR-14 | Must | Address from most recent claim activity | Not from the most recently updated record — a record touched by a batch process is not evidence of where someone lives |
| FR-15 | Must | Government identifier from enrollment | Enrollment is the attested source. Claims-sourced identifiers are not authoritative. |
| FR-16 | Must | Accumulator balances reconciled, not selected | ⚠ Running totals are computed from the union of claims, never taken from one side |
| FR-17 | Must | Source values retained | Every non-surviving value is retained and viewable. Survivorship selects what is presented, not what is kept. |
FR-12 exists because the intuitive rule is the dangerous one. "Newest record wins" is simple, defensible in a design review, and wrong in a specific and damaging way: the newest record is frequently the one created by the acquisition itself, and it contains the least history. Applied globally it would overwrite coverage periods with a record that has none — producing members who appear never to have been covered, denied claims for services rendered while they were, and an appeals volume that arrives as an operational failure rather than a data one.
7. Functional Requirements — Steward Workflow
| Ref | Priority | Requirement | Detail |
|---|---|---|---|
| FR-18 | Must | Side-by-side comparison | Both candidate records with agreeing and disagreeing attributes highlighted, plus the score and its contributors |
| FR-19 | Must | Three steward outcomes | Match, not a match, ⚠ and refer. A steward who is unsure must not be forced to guess. |
| FR-20 | Must | Reason capture | A structured reason on every decision, not free text alone. ⚠ Reasons are what make the audit meaningful. |
| FR-21 | Must | Immutable audit trail | Steward, timestamp, decision, reason, record version. ⚠ Append-only. |
| FR-22 | Must | Queue prioritization by risk | Active members, dual coverage, high-cost claimants and open care management cases worked first |
| FR-23 | Must | Throughput and aging visible | Queue volume, decisions per steward per day, and age of oldest item reported daily |
| FR-24 | Must | Independent false-positive audit | ⚠ A sample of auto-matched pairs re-reviewed by the Privacy Officer's team — not by the workstream that set the thresholds |
| FR-25 | Should | Second review on high-risk merges | Two stewards required where both records show active claims history |
FR-24 measures the error that produces no symptom, which is why it must sit outside the team that produces it. Every other quality signal on this workstream — queue throughput, duplicate rate, steward productivity — can be improved by matching more aggressively. The false-positive rate is the only measure that gets worse when thresholds are loosened, and it is invisible unless somebody deliberately goes looking. Asking the workstream that owns the thresholds to also report on the harm those thresholds cause puts a team in the position of grading its own decisions. ⚠ Placing the audit with the Privacy Officer is not a comment on anyone's integrity; it is a structural requirement, and it is the requirement most likely to be questioned as duplicated effort.
8. Data Requirements
| Data element | Source | Classification | Handling |
|---|---|---|---|
| Member demographics | Both enrollment systems | PHI | ⚠ Onshore only. Encrypted at rest and in transit. |
| Government identifier | Enrollment | PHI — restricted | Masked in the steward workbench except on explicit reveal, which is logged |
| Coverage history | Both enrollment systems | PHI | Union retained in full |
| Claims history | Both claims platforms | PHI | Used for address recency and accumulator reconciliation |
| Care management episodes | Target platform | ⚠ PHI — clinical | Used only for queue prioritization. Not displayed to stewards. |
| Match decisions and scores | EMPI | Operational, audit | Append-only, retained for the statutory period |
9. Integration Requirements
| Ref | Integration | Direction | Requirement |
|---|---|---|---|
| IR-01 | Enrollment extract, both sources | Inbound | Full initial load, then daily delta through coexistence |
| IR-02 | Claims extract, both sources | Inbound | For address recency and accumulator reconciliation |
| IR-03 | Enterprise identity to core administration | Outbound | ⚠ The surviving platform consumes the enterprise identifier, not a source one |
| IR-04 | Cross-reference service | Bidirectional | Any consumer can resolve a source identifier to the enterprise identity and back |
| IR-05 | Identity events to the integration layer | Outbound | ⚠ A merge or unmerge is published as an event. Consumers holding a source identifier must learn it has changed. |
IR-05 is the requirement that is missed until something downstream breaks. A merge is not a private act inside the index — it changes what other systems should believe. A care management record keyed on the retiring identifier, a pended claim, an open appeal and a member portal session all reference an identity that has just stopped being the right one. Without a published event, every consumer discovers the change independently, at a time of its own choosing, usually when something fails.
10. Non-Functional Requirements
| Ref | Requirement | Target |
|---|---|---|
| NFR-01 | Cross-reference lookup latency | Under 100 ms at the 95th percentile — it sits in the eligibility path |
| NFR-02 | Batch matching throughput | Full population re-scored within a single weekend window |
| NFR-03 | Steward workbench availability | Business hours, Tier 1. ⚠ Queue downtime is queue days lost and they cannot be recovered. |
| NFR-04 | Audit retention | Statutory period, append-only, restorable |
| NFR-05 | Data residency | ⚠ United States only, enforced by platform policy rather than by undertaking |
| NFR-06 | Recovery | Per service tier, with a tested restore before go-live — not a configured backup |
| NFR-07 | Access control | Role-based; steward access is scoped to the queue and logged per record viewed |
11. Testing and Validation
| Test | Owner | Criterion |
|---|---|---|
| Labelled test set | Y. Abegunde | ⚠ Rules validated against a set with known answers, including deliberately hard pairs — not against supplier demonstration data |
| Threshold calibration | S. Wrenfield | False-positive and false-negative rates measured at candidate thresholds before any are set |
| Survivorship verification | I. Duvernay | Attribute by attribute against the specification, including the coverage-history union |
| Steward workflow | T. Vandiver | Stewards reach consistent decisions on a common set. ⚠ Disagreement rate is a measure of the SOP, not of the stewards. |
| Independent audit dry run | L. Braithwaite | The false-positive audit is exercised before go-live, not designed at go-live |
| Volume and performance | P. Ramaswamy | NFR-01 and NFR-02 at full population scale |
12. Acceptance Criteria
- Every Must requirement demonstrated, not asserted.
- Thresholds set from measured false-positive and false-negative rates on a labelled set.
- ⚠ Audited false-positive rate below the accepted threshold, measured by the Privacy Officer's team.
- Coverage history union verified — no member's entitlement shortened by a merge.
- Review queue cleared, with aging reported and no item beyond the agreed maximum age.
- Restore tested, with evidence retained.
- ⚠ Unmerge exercised at least once in a controlled test. A reversal path that has never been used is a hypothesis.
- Identity events consumed successfully by every registered downstream consumer.
13. Constraints, Assumptions and Dependencies
| Type | Item | Consequence |
|---|---|---|
| Constraint | Onshore processing only | ⚠ Queue capacity cannot be scaled offshore. The obvious lever does not exist. |
| Constraint | Steward throughput is human | Capacity scales by adding people, and onboarding runs several weeks |
| Constraint | Migration window | The queue must clear inside it or the core administration cutover moves |
| Assumption | ⚠ Target data quality broadly as represented in diligence | Untested at this date. Profiling is in progress. If the review band is materially wider than assumed, queue duration scales directly with it. |
| Assumption | Steward throughput of 100 records per day at quality | To be validated over the first full month of operations |
| Dependency | EMPI platform delivered and configured | Madison Data Systems, SOW-06 |
| Dependency | Stewards recruited and onboarded | Two Rivers Talent Partners, SOW-04 |
| Dependency | Landing zone accepted | Met January 15, 2024 |
The fourth row is the largest open assumption on the program, and this document is written before it is tested. Every volume in this BRD — the size of the review band, the queue, the steward count, the duration — derives from a data quality profile that could not lawfully be examined before closing. The requirements above do not change if that assumption proves wrong. The arithmetic does. ⚠ The queue is the product of two numbers, and the program controls neither of them at this date: the proportion of pairs that need a human decision, and how fast a human can make one.
14. Traceability
| Requirement | Design artifact | Verified by | Evidence |
|---|---|---|---|
| FR-01 to FR-11 | 23 — Data Migration & EMPI Strategy, 32 — Match Rules Spec | Labelled test set | Measured rates at chosen thresholds |
| FR-12 to FR-17 | 32 — Survivorship Specification | Attribute verification | Per-attribute results, coverage union proof |
| FR-18 to FR-25 | 33 — Data Steward SOPs & SLA | Workflow test, audit dry run | Consistency rate, audit report |
| IR-01 to IR-05 | 25 — Integration Architecture | Interface regression | Control totals, event consumption |
| NFR-01 to NFR-07 | 34 — Cloud Landing Zone, 26 — Quality Plan | Performance and recovery testing | ⚠ Tested restore evidence, not configuration |
15. Sign-Off and Approval
Requirements are baselined on signature. ⚠ Changes after this point are change-controlled against the program's thresholds, not absorbed into delivery.
Business owner
Dr. A. Ravindran
Director, Enterprise Data Management · workstream lead
Date: _______________
Accountable executive
S. Achebe
Chief Information Officer, ACME Health
Date: _______________
Target-side acceptance
C. Bhattacharya
Manager, Member Data, Cumberland Valley · counterpart
Date: _______________
Privacy and compliance
L. Braithwaite
Chief Privacy Officer, ACME Health
Date: _______________
The Privacy Officer signs this document, and that is not a formality on this workstream. The requirement she is accepting is not "handle data carefully" — it is FR-24, which puts her team in the path as the independent auditor of an error the delivery team cannot be asked to grade itself on. ⚠ Signing here commits her function to work it will have to resource and to a finding it may have to raise against a program under schedule pressure. A sign-off that commits the signer to nothing is decoration; this one obliges her to something specific.
Related artifacts: 7 — Due Diligence Findings · 23 — Data Migration & EMPI Strategy · 25 — Integration Architecture · 26 — Quality Plan · 28 — Risk Register · 34 — Cloud Landing Zone · SOW-06 — EMPI Platform · SOW-04 — Data Stewards