Healthcare provider master data · worked example
When a golden record chose the wrong name
How a single frequency-based survivorship rule let fourteen repeated errors beat two correct values, and what a defensible master data architecture changes.
This is a worked example from an architecture review conducted during a coaching session, later published as a field note. It is not a client engagement. The provider database, source systems, and people involved are not identified.
Client context
The situation.
While spot-checking golden records generated by a provider MDM pipeline, one record stood out: the provider's legal name was William, and the mastered value read Illium. Nothing had crashed and no matching library had misfired. A single survivorship rule, most frequent value wins, had done exactly what it was designed to do. One high-volume source had reported the wrong name fourteen times; the correct name appeared twice.
Symptoms and risks
- One global survivorship rule applied to every field
- Repeated rows from a single source counted as independent evidence
- A confident, on-schedule pipeline producing the wrong answer quietly
- No stewardship path for conflicts the source could not resolve
Review approach
How the problem was examined.
The work focused on evidence and decision quality before prescribing implementation.
Separated the entity-matching decision from the field-survivorship decision
Traced the legal-name values inside the cluster: fourteen against two
Rejected the obvious code fixes: lower the match threshold, swap the algorithm, hardcode an override
Identified the immediate correction: fix the source and reprocess with lineage intact
Engagement timeline
How the work unfolded.
Phases are listed in the order they happened. Durations appear only where they can be stated without exposing client detail.
- 01
Spot check
Sample mastered records against known-good provider identities instead of trusting the pipeline's success status.
One wrong legal name surfaced that no error log would ever have reported.
- 02
Decision separation
Confirm the cluster was a legitimate match on multiple identifying attributes, then isolate the failure to survivorship rather than matching.
- 03
Immediate correction
A data steward corrects the provider name at its operational origin; the pipeline reprocesses the cluster and produces the correct golden record without a code change.
The incident is closed as a people-and-process fix, not a notebook patch.
- 04
Durable design
Replace the global rule with field-level survivorship stored as governed configuration, add confidence bands that route gray-zone matches to stewardship, and preserve source identity through a cross-reference bridge with SCD Type 2 history.
Every mastered value can be explained, reversed, and traced to the records that produced it.
Findings and recommendations
A sequenced path, not an unbounded backlog.
- Start with deterministic identity anchors such as a validated NPI before applying fuzzy logic
- Treat fuzzy match scores as evidence with high, gray, and low confidence bands, not as verdicts
- Configure survivorship per field: source authority and verification for names, type and recency for addresses, consent and deliverability for contact channels
- Keep a cross-reference bridge from every master ID back to its source records, with effective dates and match method
- Make stewardship part of the operating model, with named owners for merges, splits, overrides, and source corrections
Outcome
What changed.
The immediate fix restored one record. The durable fix removes the mechanism that let repetition masquerade as authority, so the platform stops amplifying whichever error appears most often.
Related service
Explore data strategy consulting
Review the service boundaries, typical deliverables, pricing context, and evidence before deciding whether to schedule.