Frequently Asked Questions

Matching

We recommend you submit all available demographics when using the Add/Update Record operation. Many records do not contain complete demographics, so the more information you can provide to the BMPI about a patient, the better it will be at finding and linking that patient’s records.

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. 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, and certain communal addresses (rehab centers, skilled nursing, homeless shelters, etc.) can create ambiguity.
  • First/Last/Gender/DOB
  • Government/Insurance IDs (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/Insurance IDs (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.

For more information, see Understanding Matching.

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

Notes:

  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.

For more information, see Understanding Matching.

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. For more information, see Understanding Matching.

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. Even accounting for data errors and fraud, they are one of the best identifiers for patient matching. While the BMPI can function without SSNs, you will get better results when you provide specific identifiers. For more information, see Understanding Matching.

The BMPI stores all information, including SSNs, using a highly secure, irreversible hashing mechanism.

We advise using internal, non-business identifiers that have no meaning outside of the source system. These are typically primary keys from the source system’s internal database. See Identifying Records for details.

CareEvolution takes privacy concerns very seriously, which is why our system is implemented such that it only stores and utilizes irreversible, highly-secure keyed hashes of the original data.

While exchanging “minimal” identifiers for privacy reasons is well-intentioned, it can easily backfire. If you don’t give the BMPI enough to work with, the results will have reduced specificity and sensitivity, leading to more missed matches.

Typically, degraded performance in the automated matching algorithm would be mitigated with a manual review process. This process is often expensive, time-consuming, and prone to human error. It also requires significantly more human access to plain text, unhashed PII/PHI. This can ultimately result in less privacy compared to allowing the BMPI to operate on hashed/blinded data.

While the BMPI matching algorithm can function effectively with some data limitations (see Understanding Matching for details), our recommendation is to always send all available demographics for the best performance.

For more information on privacy, see How the BMPI Secures Data.

No, the matching sensitivity is not adjustable.

The BMPI utilizes a combination of strategies to determine similarity between record pairs. For more information, see Understanding Matching.

When testing out the BMPI, it is common to use fake/synthetic test patients rather than real PHI/PII. However, these test patients may sometimes contain common placeholder values that the BMPI intentionally ignores. Placeholders such as an SSN of “123-45-6789” or a DOB of “1/1/1900” are often found in real records when data is not available, so the BMPI treats them as missing fields. For more information on ignored values, see Understanding Matching.


Security

All demographic fields are irreversibly hashed upon being received by the BMPI. This secures all identifying information by making it irretrievable in subsequent operations.

Those seeking even more security can use Privacy-Preserving (Blinded) Mode to hash demographics with a local hashing service before they are even sent to the BMPI.

For more information, see How the BMPI Secures Data.

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.