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 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. 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, the combination of name/gender/DOB alone 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.

For more information, see Understanding Matching.

The Identity service 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
Medicare Benficiary Identifier (MBI) 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 Identity can function without SSNs, you will get better results when you provide specific identifiers. For more information, see Understanding Matching.

The Identity service 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 Identity service 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 Identity service to operate on hashed/blinded data.

While the 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 Identity Secures Data.

No, the matching sensitivity is not adjustable.

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

When testing out Identity, 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 Identity service 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 they are treated as missing fields. For more information on ignored values, see Understanding Matching.

Yes. If you upload multiple records from a single source with matching demographics and different source identifiers, they will be linked. For more information, see Understanding Matching.

Yes. The source system is considered the authority on demographics. For more information, see Understanding Matching.

Security

All demographic fields are irreversibly hashed upon being received by the Identity service. 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.

For more information, see How Identity Secures Data.

The Identity service 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 Identity Secures Data.

General

The Identity service will perform well with parallelized uploads within its concurrency limits. It is recommended that you not exceed 60 concurrent requests.

For more information, see Maximizing Throughput.

Contact Us | Terms of Service | Privacy Policy

© 2024 CareEvolution, LLC