Patient matching does not fail only because an algorithm chose the wrong score. It fails because identity data is captured inconsistently, identifiers are misunderstood, thresholds ignore clinical risk, merge events do not propagate, ambiguous cases have no safe review workflow, and teams cannot see when records silently diverge.
The hardest question in healthcare interoperability is often not “Can we exchange this record?” It is “Are we certain this record belongs to the right person?”
A healthcare application receives a Patient resource from an EHR. The name, date of birth, mobile number, and address resemble an existing user in the application. The software links the records and continues the workflow.
That looks like a small data problem. It is not.
If the records belong to different people, the application may expose the wrong medical history, attach a device reading to the wrong chart, send a message to the wrong family, submit an incorrect claim, or generate clinical guidance from another person’s data. If the software refuses a legitimate match, clinicians may see an incomplete history, duplicate tests, miss prior results, or create another patient record.
Patient matching is therefore not a search convenience. It is part of the clinical safety, privacy, interoperability, and data-governance architecture.
01. What Patient Matching Actually Means
Patient matching is the process of determining whether two or more records refer to the same real person and linking them with sufficient confidence for the intended healthcare workflow.
The Office of the National Coordinator for Health Information Technology describes patient matching as identifying and linking a patient’s data within and across health systems to create a more complete view of the person’s healthcare record.
Matching is not the same as searching
A patient search returns possible records. A matching process makes or recommends an identity decision. Search can tolerate a broad result set because a user may inspect it. Automated linking needs a much higher standard because the result affects data ownership, access, workflow, and downstream systems.
Matching is not the same as authentication
Authentication asks whether a user controls an account or credential. Patient matching asks which clinical or administrative records belong to that person. A patient can authenticate successfully and still be linked to the wrong EHR record if the identity-resolution workflow is weak.
Matching is not the same as having a patient ID
An identifier is unique only within its assigning domain. Medical record number 12345 in Hospital A is unrelated to 12345 in Hospital B. Even inside one health system, migrations, acquisitions, legacy applications, clinics, laboratories, and billing platforms may maintain different identifiers for the same person. This is the same domain-ownership problem we walk through in our EHR integration services work — connecting Epic, Cerner, Athena, and other systems means treating every identifier as scoped to its source, never as globally unique.
The architecture principle
Never store a patient identifier without its assigning authority or source system. The pair—identifier plus domain—is what makes the identifier meaningful.
02. Why Patient Matching Fails in Real Healthcare Systems
Most failed matching programs focus on algorithm selection before fixing the system that produces identity data. Better scoring cannot fully compensate for poor capture, unclear identifiers, inappropriate thresholds, weak workflows, and missing governance.
1. Demographic data changes
Addresses, phone numbers, email addresses, names, marital status, and insurance details change. A person may use a legal name in one system and a preferred, former, abbreviated, or transliterated name in another. Children become adults. Family members share phone numbers and addresses. Temporary accommodation, homelessness, migration, and seasonal residence further reduce stability.
2. Data is entered differently
One registration desk records “Apartment 4B”; another stores “Apt #4-B.” A middle name becomes an initial. A compound surname is split incorrectly. Day and month may be reversed. Country codes disappear from phone numbers. Unicode characters are transliterated differently. These are not rare edge cases in multi-regional products.
3. Missing data is treated as disagreement
An empty phone number is not evidence that two records belong to different people. It is missing evidence. Matching engines that do not distinguish missing, invalid, default, and conflicting values produce unreliable scores.
4. Shared demographics create false confidence
Twins may share date of birth, address, surname, parent phone number, and care organization. Family members can share phones, emails, addresses, and insurance. Common names can create many plausible candidates. Exact agreement does not always mean unique identity.
5. Registration pressure creates duplicates
Emergency care, unavailable documentation, language barriers, downtime, unconscious patients, newborn registration, and urgent referrals may require temporary or partial identity records. If the reconciliation workflow is weak, those provisional records become permanent duplicates.
6. System migrations create identity debt
Legacy identifiers may be reformatted, source domains may be lost, and duplicate records may be imported without historical relationships. A migration can make previously manageable identity defects enterprise-wide.
7. Thresholds are chosen for convenience
A team may lower the threshold to reduce manual review or raise it to reduce false positives. Neither choice is safe without considering the workflow. Matching a newsletter profile is not equivalent to attaching medication or laboratory data.
8. Merge events do not propagate
The EHR merges Patient B into Patient A, but the RPM platform, data warehouse, billing system, and patient app still reference B. New data continues to arrive under both identities. The organization believes the duplicate was fixed while the distributed architecture recreates it.
9. Human review is poorly designed
Reviewers see two records but not why the algorithm considered them similar, which fields are authoritative, or what downstream impact a merge will have. Under time pressure, the queue becomes a series of guesses.
10. Teams optimize a test dataset instead of production risk
Matching performs well on a clean sample but fails for newborns, multilingual names, incomplete referrals, corrections, family accounts, historical records, or specific facilities. Overall accuracy hides weak performance in high-risk cohorts.
The architecture principle
Never store a patient identifier without its assigning authority or source system. The pair—identifier plus domain—is what makes the identifier meaningful.
03. Design the Identity Model Before the Algorithm
A strong patient-matching architecture begins by separating four concepts that are often collapsed into one database row.
Person
The real human being whose identity the organization is trying to resolve across systems and time.
Patient record
A healthcare-system representation of that person within a specific organization, EHR, practice, payer, registry, or application.
Identifier
A value assigned by a known authority, such as an MRN, payer member ID, national identifier, portal ID, or application user ID.
Identity relationship
The governed assertion that a source patient record or identifier represents a particular enterprise person.
This distinction supports one person with many identifiers, one source record with historical identifiers, merges and unmerges, temporary records, and identity corrections without rewriting every clinical transaction.
Use immutable internal keys
Names, MRNs, phone numbers, and even source Patient resource IDs can change or be superseded. Internal relationships should use stable surrogate keys. External identifiers remain attributes with source, type, status, validity, and history.
Preserve provenance
For each identity attribute, store where it came from, when it was observed, whether it was verified, whether it is current, and whether it was supplied by the patient, a registrar, an external system, or an identity provider. Two identical values with different provenance may deserve different confidence.
Represent aliases and history
Do not overwrite every prior name, address, telephone, or identifier. Historical values help future matching and investigation. They should be marked with use and effective dates rather than treated as equally current.
| Data element | Design considerations | Common mistake |
|---|---|---|
| Name | Legal, preferred, former, alias, prefix/suffix, script, transliteration, effective period | One full-name string overwritten on every update |
| Date of birth | Precision, estimated dates, transposition, invalid defaults, source verification | Treating every populated date as equally reliable |
| Address | Structured components, standardization, geocoding, prior addresses, household sharing | Comparing raw lines as exact strings |
| Phone | Country code, normalization, shared family numbers, reassignment, verification status | Using phone as a globally unique identifier |
| Case normalization, shared accounts, changes, verification, proxy access | Equating an email account with one patient | |
| MRN | Assigning organization, facility, system, status, merge history | Storing the number without its domain |
04. Deterministic, Probabilistic, and Referential Matching
No single technique fits every healthcare workflow. Mature architectures normally combine strong identifiers, deterministic rules, probabilistic scoring, external evidence, and human review.
Deterministic matching
Deterministic logic applies explicit rules. Examples include an exact active MRN within the same assigning organization, a verified national identifier, or a rule requiring exact date of birth plus normalized legal name plus verified phone.
Deterministic rules are explainable and useful when identifiers are strong. They become brittle when demographic variation is expected. Adding more rules can create an unmanageable rule hierarchy with unexpected interactions.
Probabilistic matching
Probabilistic matching weighs agreements and disagreements across fields. A rare surname agreement may carry more evidence than a common surname. A one-character name difference may be acceptable, while a different birth year may strongly reduce confidence. The engine produces a score or likelihood used with operational thresholds.
The important design question is not only how the score is calculated. It is what the system does with it.
Referential matching
Referential matching uses additional identity data from trusted external or enterprise sources to strengthen resolution. It can improve matching where local records are incomplete, but introduces privacy, contractual, coverage, regional, and dependency considerations.
Biometric and credential-assisted identity
Biometrics, digital credentials, verified identity accounts, and in-person document checks can provide stronger evidence in suitable workflows. They do not eliminate the need to connect that verified person to existing clinical records safely.
| Approach | Strengths | Limitations | Best use |
|---|---|---|---|
| Exact identifier | Fast and high confidence within a governed domain | Identifiers can be missing, merged, mistyped, or used outside their domain | Known source-system lookup |
| Deterministic rules | Explainable and easy to audit | Brittle across variation and missing fields | High-confidence auto-link rules |
| Probabilistic scoring | Handles variation and multiple weak signals | Requires tuning, labeled data, monitoring, and explanation | Candidate ranking and tiered decisions |
| Referential data | Adds evidence beyond local records | Coverage, privacy, cost, and external dependency | Cross-organizational identity resolution |
| Human review | Can consider context and uncertainty | Slow, costly, inconsistent, and error-prone without good tools | Ambiguous and high-impact cases |
The safest matching engine is usually a decision system: automatic match, automatic non-match, or review—not a single yes/no threshold.
05. A Safer Patient Matching Pipeline
Matching should be designed as a staged pipeline. Each stage has a specific purpose and measurable output.
Step 1: Validate incoming data
Identify impossible dates, placeholder values, duplicated fields, invalid phone formats, truncated names, unknown assigning authorities, and fields that violate the source contract. Do not silently normalize obviously corrupted values into plausible identity evidence.
Step 2: Normalize without destroying the original
Create normalized representations for comparison while preserving source values. Typical transformations include Unicode normalization, case folding, whitespace handling, punctuation removal, phone formatting, address standardization, common nickname mapping, and transliteration.
Normalization must be locale-aware. Removing meaningful particles, changing name order, or applying English-centric phonetics can reduce accuracy for international populations.
Step 3: Generate candidates
Do not compare every record with every other record. Blocking or candidate-generation rules narrow the search using selected signals such as date-of-birth ranges, name keys, phone fragments, postal geography, or source identifiers. Candidate generation must prioritize recall; a record excluded here can never be matched later.
Step 4: Calculate features
Features may include exact agreement, edit distance, phonetic similarity, token overlap, date transposition, address component agreement, phone suffix match, identifier agreement, rarity, field reliability, and temporal consistency.
Step 5: Score and classify
Use calibrated thresholds to divide candidates into high-confidence match, uncertain review, and non-match. Thresholds should vary by workflow where risk differs. A read-only record suggestion may use a different threshold from an automatic clinical merge.
Step 6: Apply constraints
Business and clinical constraints can override a high score. Two active patients with different verified national identifiers should not be automatically combined. Twins may require additional evidence. Records marked as identity-theft victims, restricted patients, or uncertain newborn identities may need special workflows.
Step 7: Record the decision
Persist candidate score, feature evidence, algorithm version, thresholds, rule outcomes, reviewer, timestamps, and final decision. A match that cannot be explained or reproduced is difficult to audit and unsafe to retune.
Step 8: Propagate and reconcile
After a link or merge decision, notify dependent systems, update identifier crosswalks, redirect stale references, monitor acknowledgements, and reconcile failures. Identity resolution is incomplete until the distributed ecosystem reaches a consistent state.
06. EMPI Architecture: More Than a Master Table
An enterprise master patient index, or EMPI, connects patient records and identifiers from multiple systems to an enterprise identity. It is an identity service and governance capability—not merely a table with one “golden” patient row.
Source systems
EHRs and practice systems
Labs, imaging, payer, HIE
Patient apps and devices
Identity resolution
Validation and normalization
Candidate generation and scoring
Rules, thresholds and review
EMPI and governance
Enterprise person and identifier crosswalk
Merge, unmerge and history
Audit, stewardship and metrics
Consumers
Clinical and operational workflows
Integration and interoperability
Analytics and longitudinal records
Source identifier registry
The EMPI must retain each source identifier with its assigning authority, source record, status, and history. It should know that several identifiers resolve to one enterprise person without forcing source applications to adopt the same identifier immediately.
Enterprise person identity
The enterprise identifier is an internal correlation key. It should not be presented as proof of identity outside its governance domain. It may link records while each source EHR remains authoritative for its local patient record.
Identity graph and relationships
A graph representation can model active links, aliases, superseded identifiers, duplicate candidates, household relationships, guarantors, related persons, and merge history. It also supports investigation without losing the original source structure.
Stewardship queue
Ambiguous records should enter a work queue with evidence, source context, risk, and downstream impact. Reviewers need structured actions: match, no match, defer, request more evidence, split, merge, or escalate.
Event publishing
Identity changes should produce reliable events. Consumers need to know whether a record was linked, unlinked, merged, corrected, or superseded, and which identifiers remain valid. Event consumers must be idempotent because delivery may repeat.
Do not centralize more data than necessary
An EMPI needs identity attributes and evidence, not every clinical observation. Minimize PHI, separate access roles, and keep clinical data in appropriate systems. This same data minimization discipline is central to building GDPR and HIPAA compliant AI healthcare software.
07. Patient Matching With FHIR
FHIR provides useful building blocks for representing and exchanging identity information, including Patient, Person, RelatedPerson, identifiers, names, contact points, addresses, links, and matching operations.
The Patient resource represents a record in a care context
A FHIR Patient is generally the person as represented for a healthcare organization or service. Two Patient resources can refer to the same human. Treating every Patient resource ID as an enterprise person ID creates identity fragmentation.
Identifier systems matter
A FHIR identifier should include a system URI or other clear namespace. The value alone is insufficient. Use identifier use, type, period, and assigner where relevant. Do not collapse all MRNs into one unqualified field.
Patient.link communicates record relationships
The Patient resource can express links to another Patient or RelatedPerson with relationship types such as replaced-by, replaces, refer, or see-also. Implementations must define how these links affect searches, writes, historical references, and user display.
The $match operation standardizes the request, not the algorithm
The FHIR Patient $match operation allows a client to submit patient demographics and receive possible matches with confidence information. The server still needs local identity data, matching logic, thresholds, policy, and governance. A standards-based operation does not guarantee equal matching performance between organizations, and two vendors' "FHIR-compliant" servers can still disagree, a gap we've written about in FHIR integration challenges.
FHIR merge support is evolving
FHIR R5 includes a Patient $merge operation as a trial-use capability. Production systems should verify version and vendor support rather than assuming the operation is available. Many environments still communicate merges through vendor-specific events, HL7 ADT messages, or internal identity services.
FHIR implementation rule
Keep a stable internal identity model and map FHIR resources to it. Do not let one vendor’s Patient profile become the core identity schema for the entire product.
08. Merge and Unmerge Are Distributed Transactions
A patient merge is often treated as a database operation: choose the surviving record and move data. In an integrated healthcare ecosystem, it is a distributed identity change that can affect dozens of systems and years of references.
Choose a surviving identity deliberately
The surviving record may be selected using completeness, active status, authoritative source, existing clinical activity, or organization policy. “Newest wins” and “oldest wins” are rarely adequate universal rules.
Preserve the losing identifiers
A merged identifier should not disappear. Historical messages, documents, claims, devices, and external partners may continue referencing it. Maintain redirect and equivalence relationships so the organization can resolve old references.
Propagate the change
Publish a merge event containing source identity, target identity, effective time, authority, and version. Track consumer acknowledgements and retry failures. Some downstream systems may support merges; others may require a local crosswalk or manual correction.
Prevent stale writes
After the merge, an offline device, delayed interface message, or cached application may submit data under the losing ID. The receiving layer should resolve the old ID to the survivor or reject the transaction visibly—not recreate the duplicate.
Design unmerge before the first merge
Incorrect merges happen. An unmerge is not simply reversing a foreign key. Data created after the merge may need attribution to the correct patient. The system must preserve enough history to investigate which encounters, documents, results, tasks, and communications belonged to each person. This audit trail requirement mirrors what we detail in HIPAA by Design, immutable history isn't just a data-quality safeguard, it's what a real OCR investigation or enterprise security review will expect to see.
| Merge control | Why it matters |
|---|---|
| Pre-merge impact preview | Shows identifiers, records, active encounters, linked accounts, devices, and downstream systems affected. |
| Dual authorization for high-risk cases | Reduces accidental merges where clinical impact is significant. |
| Immutable audit history | Supports investigation, compliance, and safe correction. |
| Merge event and acknowledgement tracking | Prevents silent divergence across connected systems. |
| Historical identifier resolution | Allows old messages and references to reach the surviving identity. |
| Controlled unmerge workflow | Provides a path to correct false merges and reassign affected data. |
09. Design Human Review as a Safety Workflow
Human review is often treated as the fallback when the algorithm is uncertain. In reality, it is a specialized identity-stewardship workflow that needs its own product design.
Show evidence, not only scores
A reviewer should see agreements, conflicts, missing values, source and verification status, historical data, active records, and why the engine produced the candidate, the kind of explainability gap we flagged in 10 FHIR integration architecture mistakes.
Prioritize by risk
A possible duplicate with no clinical activity is different from a proposed merge involving active medication orders, restricted records, or two portal accounts. Queue priority should consider clinical and privacy impact, not only match confidence.
Limit unnecessary exposure
Reviewers need enough context to make a decision, but not unrestricted access to every clinical detail. Apply least privilege and audit every identity investigation.
Capture structured decisions
Record match, non-match, defer, corrected demographics, suspected fraud, twin, temporary identity, or insufficient evidence. These outcomes improve future rules and allow error analysis. Free-text notes alone are difficult to use operationally.
Measure reviewer consistency
Use adjudicated samples, inter-reviewer agreement, reversal rates, queue age, and escalation patterns. If trained reviewers disagree frequently, the policy or evidence may be inadequate.
10. How to Test Patient Matching Safely
Matching requires a labeled dataset that represents the real population and workflows. A random clean sample is not enough.
Build a representative evaluation set
- Common and rare names
- Twins and same-household family members
- Name changes, aliases, initials, and transliteration
- Address changes and incomplete addresses
- Shared and reassigned phone numbers
- Missing, default, and invalid demographic values
- Newborn, emergency, temporary, and unknown patients
- Cross-facility and cross-EHR records
- Historical duplicates and confirmed false merges
- Regional, language, and cultural naming patterns
Measure more than overall accuracy
Precision
Of records classified as matches, how many are truly the same person?
Recall
Of all true matches, how many did the system identify?
Review rate
How much of the workload is routed to humans at the chosen thresholds?
False merge rate
How often are different people incorrectly combined?
Duplicate creation rate
How frequently are new records created despite an existing identity?
Reversal rate
How often are match or merge decisions later corrected?
Evaluate cohorts separately
A model may perform well overall and poorly for a language group, facility, age band, or workflow. Report results by meaningful cohort and field-availability pattern. Fairness in identity matching includes ensuring one population is not systematically harder to link or more likely to be falsely combined.
Use shadow mode before automation
Run the new engine alongside existing workflows without automatically changing identity. Compare candidates and decisions, investigate disagreements, and calibrate thresholds before enabling auto-link or merge actions.
Version everything
Store normalization version, feature definitions, scoring model, rules, thresholds, and configuration. When behavior changes, teams must be able to explain why the same pair produced a different decision.
11. Production Monitoring and Identity Data Quality
Patient matching accuracy changes over time. New facilities, registration practices, populations, EHR upgrades, phone formats, and data sources can alter performance without a code defect.
Operational metrics
- New duplicate rate by source, facility, registrar, and workflow
- Automatic match, automatic non-match, and review distribution
- Queue age and unresolved high-risk candidates
- False merge and unmerge frequency
- Percentage of records missing key demographic fields
- Invalid or placeholder values by source
- Merge event delivery and acknowledgement failures
- Stale identifiers used after merge
- Match confidence distribution drift
- Downstream records not reconciled to the enterprise identity
Make data quality actionable
A dashboard that reports poor phone completeness is not enough. Route recurring issues to the source workflow. If one facility creates duplicates because registrars skip search, change the registration UX and policy. If an external partner sends unknown identifier domains, fix the interface contract.
Monitor for identity-related security events
Repeated attempts to alter demographics, unusual account-link requests, high-volume searches, suspicious proxy relationships, and unexpected merges can indicate fraud or misuse. Identity operations should feed security monitoring.
Architecture reality
The matching algorithm may be owned by engineering, but matching quality is produced by registration, interfaces, governance, clinical operations, security, and data stewardship together.
12. A Practical Implementation Roadmap
Phase 1: Identity and workflow discovery
Inventory patient identifiers, assigning authorities, source systems, registration workflows, known duplicate problems, merge processes, patient access workflows, and downstream consumers. Define the decisions the matching service will make.
Phase 2: Data profiling
Measure completeness, validity, uniqueness, format variation, field stability, and correlation by source and population. Find placeholder values and source-specific defects before designing normalization or weights.
Phase 3: Identity model and governance
Define enterprise person, source patient record, identifier, alias, match relationship, merge history, authority, stewardship roles, and escalation policy. Agree on acceptable automation by workflow.
Phase 4: Candidate and scoring prototype
Implement normalization, blocking, feature calculation, rules, probabilistic scoring, and explainability using representative labeled data. Compare several threshold strategies rather than optimizing one accuracy number.
Phase 5: Stewardship and correction workflows
Build review, merge, unmerge, identity correction, restricted-case handling, audit, and approval processes. Include impact previews and downstream reconciliation.
Phase 6: Integration
Connect EHRs, patient applications, device platforms, warehouses, and interoperability services. Publish identity events, retain source identifiers, and handle stale references.
Phase 7: Shadow and limited rollout
Run in observation mode, validate decisions with stewards, then enable low-risk automatic matches. Expand by source and workflow only when metrics remain acceptable.
Phase 8: Continuous improvement
Monitor drift, investigate errors, improve source capture, retune thresholds, and update policies. Matching is an operating capability, not a one-time implementation.
13. Architecture Checklist for HealthTech Teams
Before connecting a patient application, RPM platform, AI workflow, referral product, or analytics system to an EHR, answer these questions:
- What does “same patient” mean for this workflow?
- Which system issues each identifier, and is the assigning authority stored?
- Do we model a person separately from source patient records?
- Which attributes are verified, historical, shared, or provisional?
- How are values normalized without losing the source?
- How are candidates generated, and what true matches could be excluded?
- What rules or scores permit automatic linking?
- Which cases must always go to review?
- What is the cost of a false positive in this exact workflow?
- How do we prevent the same duplicate from being recreated?
- How are merge, unmerge, and correction events propagated?
- Can old identifiers still resolve after a merge?
- What does the reviewer see, and what actions are available?
- How will performance be measured by population and data source?
- Who owns identity quality after launch?
If the answer to patient identity is “we compare name and date of birth,” the integration architecture is not ready.
14. Peerbits Perspective: Treat Identity as Core Infrastructure
Patient identity affects almost every healthcare product workflow: EHR integration, portals, remote patient monitoring, referral intake, clinical AI, care management, analytics, claims, and longitudinal records. It should be designed as shared infrastructure with explicit governance rather than recreated independently inside each feature.
Peerbits helps healthcare and HealthTech teams analyze identity workflows, design EHR and FHIR integration architecture, build canonical identity services, implement EMPI and patient crosswalk patterns, develop stewardship workflows, and add production monitoring around distributed healthcare data, the same engineering discipline behind our custom healthcare software development practice.
Our approach begins with the workflow and risk: what data will be linked, what action follows the match, which systems must agree, what happens when evidence is uncertain, and how an incorrect decision can be corrected safely.
Planning patient identity or EHR integration architecture?
We can assess your patient identifiers, source systems, matching workflow, FHIR and HL7 interfaces, merge process, and downstream synchronization risks before they become production data-quality problems.
Explore EHR Integration ServicesFrequently asked questions
Patient matching determines whether records from one or more healthcare systems refer to the same real person, then links those records with a confidence and governance model appropriate to the workflow.
Common causes include inconsistent registration, spelling and transliteration differences, missing demographics, changed addresses and phones, emergency and newborn workflows, weak search behavior, system migrations, and failures to propagate merges.
Deterministic matching uses explicit exact or rule-based conditions. Probabilistic matching weighs agreements, disagreements, rarity, and field reliability to estimate whether records represent the same person.
An enterprise master patient index links patient records and identifiers from multiple systems to an enterprise person identity while retaining source domains, relationship history, merge governance, and stewardship workflows.
FHIR standardizes useful resources and operations, including Patient, Person, identifiers, links, and Patient $match. It does not replace data quality, algorithms, thresholds, local policy, or review workflows.
An MRN is normally unique only within the assigning organization or system. Store the MRN together with its assigning authority. The same number can exist in another organization and represent a different person.
Both cause harm, but false positives may combine clinical data from different people. For high-impact workflows, systems generally require stricter automatic-match thresholds and human review of ambiguous cases.
Preserve all identifiers and history, choose a surviving identity deliberately, publish merge events, track downstream acknowledgement, redirect stale references, audit the decision, and maintain a controlled unmerge process.
Use representative labeled records and measure precision, recall, false match and missed match rates, review volume, duplicate creation, merge reversals, and performance across facilities, languages, age groups, and data-quality patterns.
No. Products should reuse an enterprise or platform identity capability where possible. Reimplementing independent matching rules in each application creates conflicting identity decisions and makes merges harder to propagate.
