Match-Ready Examples: Patient, Supplier, and B2C Synthetic Datasets

A Match-Ready Sample is a synthetic dataset shaped like a specific real-world domain, carrying the field correlations and duplicate patterns that domain's match rules must handle, without containing any real person's or organization's data. This entry shows what that looks like across three domains. It does not cover how to request one for your own domain (see the Match-Ready Sample offer) or how match rules get scored against it once you have one (see the precision, recall, and F1 explainer).

Every Match-Ready Sample comes out of the same Match Rule Truth Engine: pick a domain, and the engine generates records with realistic field correlations plus a labeled set of duplicate pairs tagged to a Master ID and Duplicate Type, the same answer-key mechanism used across this site's other labeled samples.

Domain shape is the part generic test data skips. Two datasets can both carry names, addresses, and identifiers and still exercise entirely different rule behavior, because the way those fields correlate and the way duplicates arise differ by domain. A supplier record and a patient record fail in different places. A Match-Ready Sample is built so that the failures it can surface are the ones that domain's match rules actually meet in production.

Every value printed on this page is fabricated for illustration. Identifiers carry a visible prefix (MRN-, TAX-), email domains follow the example.com convention already used across this site's labeled samples, and every entity and person name is invented for the example rather than taken from any real record. This disclosure governs the delivered datasets on the same basis.

Synthetic data notice. Every dataset and truth key in this sample is synthetically generated. It contains no real personal data and no real PII.

A patient Match-Ready Sample carries fields shaped like admission records: a facility-style medical record number (for example, MRN-000482), patient name, date of birth, and address, generated entirely from scratch. This disclosure applies to every field in this example: no real patient, no real facility, and no real medical record number appears anywhere in a Match-Ready Sample.

An illustrative duplicate scenario: two admission rows for the same fictional patient, "Priya Natarajan" on one row and "P. Natarajan" on the other, sharing a date of birth, with a one-digit street-address variant. Both rows are tagged to the same Master ID with a Duplicate Type of nickname/alias, giving the truth set a documented answer key for the match rules being tested.

That pair stresses a rule keyed on name plus date of birth. The date of birth agrees exactly, the name is abbreviated rather than misspelled, and the street address differs by a single digit. A rule that requires exact name equality misses the pair entirely. A rule that leans on address alone catches pairs it should be keeping apart. The labeled answer key is what tells you which of the two happened.

A supplier Match-Ready Sample carries B2B fields: legal entity name, a tax-ID-shaped identifier (for example, TAX-illustrative-8841), remit-to address, and a contact name and email. This disclosure applies: every entity, address, and identifier is fabricated, with no real company name or tax ID anywhere in the set.

An illustrative duplicate scenario: "Meridian Fabrication LLC" and "Meridian Fab (a division of Meridian Holdings)" are the same fictional supplier entered under two source-system names, sharing a remit-to address and contact email. Both rows are tagged to the same Master ID with a Duplicate Type of subsidiary/DBA drift.

That pair stresses a rule keyed on entity name. The two legal names share one token and diverge everywhere else, while the remit-to address and the contact email agree exactly. A rule weighted toward name similarity misses it. A rule that reads remit-to address as corroborating evidence finds it. The labeled answer key is what separates those two outcomes on this pair.

A B2C customer Match-Ready Sample carries consumer fields: name, email, phone, and address, generated as a fresh set distinct from the MDM customer example already on the MDM test data guide. This disclosure applies: every name, email, and address is fabricated, using example.com-style email domains and fictional street addresses.

An illustrative duplicate scenario: "Alexandra Kim" signs up once as "Alexandra Kim" and once as "Alex Kim," with a matching phone number and a one-character typo in the street address. Both rows are tagged to the same Master ID with a Duplicate Type of nickname/typo, so B2C match rules have known ground truth to score against.

That pair stresses nickname handling and typo tolerance at the same time. An edit-distance check on its own does not connect Alexandra to Alex, because the two strings are far apart by character count. A rule keyed on address alone is thrown by the single-character variant. The phone number is the one field that agrees exactly, which makes this pair a test of whether the rule weights a corroborating field at all.

These three domains are examples, not the limit. Request a Match-Ready Sample for whatever domain you name, free, with no call required. Ask for patient, supplier, B2C, or another domain, and the request produces a labeled set built the same way as the examples above.