Understanding Matching

The matching logic is a complex set of algorithms that have been developed and refined by CareEvolution over the past 15+ years. These algorithms have been validated to ensure appropriate sensitivity and specificity against production data in a variety of settings.


To determine whether two given records are a match, the BMPI performs several steps:

  1. Account for common variations in demographics.
  2. Perform an irreversible hash on the demographics.
  3. Perform a weighted comparison of demographic fields to establish whether the records are a match.

These steps are discussed in the following sections.

The BMPI is designed to minimize false positives (where two records are erroneously linked when they truly represent different individuals) by only linking records when there is high confidence of a match. This is because false positives are generally considered to have a greater impact than false negatives (where two records from the same individual are not linked). For clinicians, dealing with incomplete data is the norm; dealing with wrong data is more likely to lead to adverse clinical outcomes.

Standardizing and Variations

The BMPI performs some pre-processing of demographic fields to account for common variations among input sources. This includes:

  1. Transforming data to a common format. For example, normalizing case and using standard formats. For example: “John” and “JOHN” would be normalized to “john”; “888-555-1234” and “(888)555-1234” would both be normalized to “8885551234”.
  2. Determining common variations, such as nicknames, typographical errors, and transpositions. For example: “Abby” for “Abigail”; a birthday of May 1st erroneously entered as 2001-01-05; a SSN that’s off by 1 digit.

The BMPI will also ignore certain known invalid values and placeholders, treating them as missing fields. See Ignored Values for details.


Before storing a record, the BMPI performs an irreversible hash operation on the demographic data. The BMPI only stores and performs match operations with the hashed values, not the original values. This is the “blinded” nature of the BMPI.

The CareEvolution BMPI uses only FIPS compliant hash functions (HMAC/SHA256), with a unique client-specific key to ensure privacy and guard against brute force or dictionary attacks. For more information, see How the BMPI Secures Data.

For example, consider the first names of several records. Although hashed values are actually alphanumeric (e.g., “9f86d081884c…”), emoji are used in these examples for clarity.

  Record A Record B Record C
Original Value Daniel Gio Dan
Known Variants Dan, Danny Daniel, Danny
Hashed Value 🍎 🍇 🍑
Hashed Variants 🍑, 🍐 🍎, 🍐

The BMPI never stores the original values or variants, only the hashed ones. Yet even with the hashed values, the BMPI can determine that Person A and C potentially have matching first names (A’s original value and C’s variant are both 🍎), while Person B has no values in common with either A or C. The BMPI will consider every available field in this manner before reaching its final conclusion about whether two persons are a match.

Demographic Weighting and Match Confidence

When determining if two records are a match, the BMPI will compare the hashed values of every available demographic field. For each field individually, it will consider:

  • How similar the values are.
  • The field’s relative importance (or “weight”) in determining a match (e.g., name is more important than phone number).

Then the BMPI will look at the overall status of all the fields combined to reach a final conclusion as to whether the records match.

The matching algorithm uses a combination of deterministic matching (the weighting system) and probabilistic matching (the statistical analysis of the overall confidence) to determine the final match status.

Match Similarity

When the BMPI compares two demographic fields, it determines how closely each one matches. This gives a similarity status, which is one of:

Similarity Status Example
Exact Match Both records have a middle name of “Abigail.”
Approximate Match One record has a middle name of “Abby” and the other has “Abigail.”
Data Missing One record has a middle name of “A” and the other has no middle name.
Disagreement One record has a middle name of “A” and the other has a middle name of “T.”

Match Weight

The individual match status results are then combined into an overall score. When doing so, some demographics are weighted more heavily than others.

Demographic Weight
Government Identifier (SSN, Medicaid ID) High
First and Last Name, Date of Birth, Gender, Health Card ID, Address Medium
Middle Name, Email Low

Agreement or disagreement in high-weighted fields is more indicative of a match than agreement or disagreement in low-weighted fields.

The BMPI takes into account several factors when weighting demographics:

  • Specificity - Many people can share the same name or birthdate (or even both), but government IDs like SSN or Medicaid ID are intended to uniquely identify an individual. This is not a guarantee, of course. Government IDs can be incorrect due to dummy/placeholder SSNs, typographic errors, fraud, cases where a spouse or parent’s SSN was mistakenly added to a record for insurance reasons, etc. Nonetheless, records with the same SSN are likely to be from the same individual, while records with different SSNs are likely to be different people.
  • Reliability - Middle names are not as reliable as first/last name, due to common recording errors or cultural naming variations.
  • Stability - Some demographics are anticipated to change repeatedly over a person’s lifetime. Address and phone number can change often, and are commonly shared among different individuals (such as families or even homeless shelters). Even names can change due to marriage or legal name changes.

Overall Match Decision

Once the BMPI has established the similarity and weight of each individual field, it looks at the entire record as a whole to determine whether the two records match.

Imagine the two records as a mosaic, with the size of each block representing the weight of the field and the color representing its hashed value. The BMPI considers the overall similarity of the images. Note that the block sizes are merely illustrative, and should not be considered an actual representation of BMPI weights.

Some things to notice:

  • The record on the left has more fields to work with, giving it more opportunities to match with the record on the right.
  • All fields are considered. Address gives important corroboration to help conclude that these are indeed the same person.
  • It is not necessary for the images to match exactly, but rather the overall similarity (based on probability analysis) that determines whether two records match.

For more information about how different combinations of demographics may perform, see Demographic Combinations.


The following examples illustrate how the BMPI considers the above factors in determining a match.

Match Example 1

Consider two records:

First Name Last Name Gender SSN
John Smith Male 123-45-6789
Mary Johnson Female 123-45-6789
Disagreement Disagreement Disagreement Exact Match

This would not be considered a match. The disagreement in several medium-weight fields (first and last name, gender) overrides the exactly matching SSN.

Match Example 2

Consider a pair of records:

First Name Middle Name Last Name Date of Birth Medicaid ID
Mary Jane Johnson 12/1/1956 123456
Mary Jane Smith 12/1/1956 123456
Exact Match Exact Match Disagreement Exact Match Exact Match

This would be considered a match. The high-weight Medicaid ID, coupled with the agreement in other medium-weight fields (first and middle name, gender, and date of birth), is enough to overcome the disagreement in last name (possibly due to marriage).

Match Example 3

Consider this record pair:

First Name Last Name Date of Birth SSN Health Card ID
John Smith 12/1/1956 123-45-6789 A1234
Jon Smith 12/1/1956 Not Provided A1234
Approximate Match Exact Match Exact Match No Disagreement Exact Match

This would be considered a match. Notice that the absence of a SSN in the second record is not considered a disagreement. The preponderance of exact matches across medium-weight fields is enough to constitute a match even without the SSN.

Match Example 4

Consider this record pair:

First Name Last Name Date of Birth Gender Address
John Smith Male 12/1/1956 123 Main Street, Anytown MI, 12345
John Smith Male 12/1/1956 123 Main Street, Anytown MI, 12345
Exact Match Exact Match Exact Match Exact Match Exact Match

This would be considered a match even though no high-weight identifiers are provided. Name, date of birth, and gender are insufficient for a match on their own, but exact matches among multiple fields can provide enough corroboration to make a match.

Invalid/Ignored Values

The BMPI will ignore certain values that are commonly entered into records as placeholders when real information is not available. For example:

  • SSNs like 123-45-6789 or 111-11-1111. Also invalid SSNs, such as those beginning with 000 or 999.
  • MRNs that are all a single digit (like 1111 or 2222222222).
  • DOBs like 1/1/1900.
  • First names like “Baby” or “Baby Boy.”
  • Phone numbers like (111)111-1111.

This is not an all-inclusive list, merely examples.

Values like these are not effective for linking records. They are unlikely to match other records from the same individual, and may provide erroneous matching weight towards records with similar placeholders from different individuals. As such, the BMPI will simply ignore these values and treat them as if the field were missing.

Name/DOB/Gender Matching

One specific case deserves special mention in the matching algorithm: The BMPI does not consider name, date of birth, and gender sufficient for a match. While it may seem unlikely for two individuals to share exactly the same first and last name, date of birth, and gender, it actually happens with some frequency in large population sets.

For example, in Perspectives on Patient Matching: Approaches, Findings, and Challenges the authors report:

“The Social Security Administration’s death master file contains more than 20,000 distinct males named “William Smith,” 5 of whom were born on January 20, 1920 (Social Security Administration, 2001). If name, gender, and date of birth are the only matching criteria used, these individuals may be falsely linked.”

Another report prepared for the for the Office of the National Coordinator for Health Information Technology found that:

“Many regions experience a high number of individuals who share the exact name and birthdate, leading to the need for additional identifying attributes to be used when matching patient records.”

Additional factors that can cause shared name/date of birth/gender include:

  • Naming trends (such as the prevalence of individuals born on 12/25 named “Noelle” or “Holly”, or the popularity of certain names each year).
  • Family members with similar demographics (e.g., twins with similar names).
  • Cultural factors (such as certain names being extremely common in some healthcare populations).

For these reasons, you must always supplement name/DOB/gender with at least one other field that specifically identifies the individual.

Non-specific fields like zip code or city are insufficient supplements to name/DOB/gender. The distribution of names is highly influenced by cultural factors, and is neither uniform nor random. An ethnic neighborhood in a big city may have several individuals with the same name, some of whom may even share a birthday.

Linking Within the Same Source (Duplicate Records)

If the BMPI receives two different records from the same source with matching demographics, it will link them.

In an ideal world, each source system would maintain only one record for a given individual. In reality, incomplete data and poor matching algorithms within EMR systems make duplicate records a pervasive problem.

Overwriting Records

The BMPI considers the source system to be the authority for its own records. Every time you upload data for a given source system/identifier, the BMPI will completely replace the existing record with the new data, then re-evaluate the validity of any existing record links. The response will include information about any updated matches.

This is true even if the new data is very different from the original. For example, CommunityClinic record A12345 may have originally been uploaded as “John Smith, male, born 1/1/1952” and then updated to “Jane Jones, female, born 2/2/1980”. The BMPI will overwrite John’s data with Jane’s, and records previously linked to John’s will no longer match the updated record (though they may still match each other).

Demographic Combinations

Below are some common combinations of demographics and their expected matching sensitivity.

Identifiers Sensitivity Notes
  • First Name
  • Last Name
  • Gender
  • Date of Birth
While it may seem unlikely for two individuals to share exactly the same first and last name, date of birth, and gender, it actually happens with some frequency. This data alone is insufficient for a match. For more information, see Name/Gender/DOB Matching.
  • First/Last/Gender/DOB
  • A non-specific identifier (e.g., City or Zip Code)
As in the previous case, name/gender/DOB is not sufficient for a match. The addition of a non-specific identifier doesn't help. For more information, see Name/Gender/DOB Matching.
  • First/Last/Gender/DOB
  • MRN
MRNs can be useful in certain intra-hospital situations, but their matching value is limited because they are generally not common across systems.
  • First/Last/Gender/DOB
  • Complete Street Address (Street/City/State/Zip)
  • Phone Number (Home or Cell)
This combination will give decent results, but can have sensitivity issues when people move or change telephone numbers. It can also be sensitive to name changes due to marriage. Certain communal addresses (rehab centers, skilled nursing, homeless shelters, etc.) can create ambiguity.
  • First/Last/Gender/DOB
  • Government or Insurance ID (SSN/Health Card/Medicaid)
This combination gives good results, though insurance identifiers can change and Medicaid ID is not always available.
  • First/Last/Gender/DOB
  • Government or Insurance ID (SSN/Health Card/Medicaid)
  • Complete Street Address (Street/City/State/Zip)
  • Phone Number (Home or Cell)
This combination gives excellent results. Providing additional fields will improve results further, compensating for any gaps in individual records.

Identifier Match Weights

The BMPI takes into account many factors when weighting demographics. The table below summarizes the identifiers based on:

  • Specificity - How likely it is that no two individuals share the same identifier.
  • Availability - How likely is it that this identifier is available in any given source record.
  • Stability - How likely is it that the value will be the same across multiple sources and records for the same individual.
  • Weight - The overall weight of this field in the matching algorithm.
Identifier Specificity Availability Stability Weight
SSN High Medium High
SSN (last 4 digits only) Medium High High
Medicaid ID High Low High
Health Card ID High Medium Medium
First Name Low High High [1]
Last Name Low High Medium [1]
Date of Birth Low High High [1]
Street Medium High Medium [2]
City Low High Medium [2]
State Low High Medium [2]
Zip Low High Medium [2]
Gender Low High High
Home Phone Medium Medium Medium
Cell Phone High Medium Medium
Race Low Medium High
Middle Name Low Medium Medium
Maiden Name Low Low Medium
Email Medium Low Medium
MRN High High Low


  1. First name, last name, and date of birth are not very specific on their own, and are not sufficient for a match. However, together they are a core part of the match algorithm.
  2. Individual components of the address do not have a high match weight on their own, but as a group they are useful.