Search for a patient with demographics

If you want to locate a patient's record in an EHR system but you don't have a patient identifier, you can search for a patient with demographics instead. Typically, you can use this for: 

  • Tying patient records from your system to the patient’s record in the relevant EHR;
  • Filling the gaps in demographics you have for a specific patient by using a few data points to locate a more comprehensive set of data; or
  • Searching for a patient in a large integration network like the Carequality Interoperability Framework.

This API action will quickly become one of your favorites since it’s a great option for quickly locating a specific patient in your connection’s EHR system.

Supported systems

You can use this API action with the Redox FHIR® API.

Your connection's system can return results with their own FHIR® or query-based API.

Using data on demand

It's possible that your connection's system can't support a query-based data exchange, but they may still be willing to provide results with a push-based method.

However, we understand that you may not want to store all that data—maybe you don't need all possible results and just want to query for what you want when you need it. If so, you can use this API action via our data on demand service, which stores the connection's data so that you can query from Redox "on demand." .

Special considerations

We mentioned that this API action is a great option for quickly locating a patient, but that doesn't mean that it works like a Google search or a typical SQL database search. None of the fields automatically populate, nor can you only use one demographic data point. Also, the purpose is to find matches for a specific patient, not a list of potential patients matching a broad set of criteria. In other words, you have to know who you’re looking for. 

You must include the following to search for a patient: 

  • given name 
  • family name
  • birthdate
  • gender (not required with data on demand)

Typically, you must also include at least one of the following, but these requirements differ based on the EHR system you're integrating with: 

  • Social Security number
  • address
  • email address
  • phone number

We recommend using as much demographic information as possible though; otherwise, you may find other patients with the same basic demographic information.

Fields you can't search by

For easy reference, here are some common data points that you can’t use to search for a patient:

  • time range
  • diagnosis
  • insurance member ID
  • other insurance data points (insurance data is for entirely different resources, like Claim)

Matching method

There's a caveat to using as much demographic information as possible, however, which has to do with exact, partial, or fuzzy matching. The method of matching is dependent on (a) your connection and the EHR they use; and (b) whether you use data on demand or RLS. Spoiler alert: it's better to use as much demographic information as possible if the system you're using does partial or fuzzy matching, not exact matching.

Exact matching

Exact matching means that the EHR—or our data on demand service–only returns results that match every field in your request exactly.

For example, let’s say you provide a name, birthdate, gender, and phone number for patient demographics. The EHR locates a patient with the same name, birthdate, and gender, but there’s a different phone number listed. Based on exact matching, no results would be returned.

As you can imagine, this can get dicey if patients have different phone numbers, email addresses, or nicknames throughout different systems. Or, if different systems use nonidentical formats for any of these fields—for example, 555-555-0000 instead of (555) 555-0000 for a phone number—then they still won’t match.

How to get multiple matches with exact matching

Exact matching may still return multiple matches. This can happen if:

  • two patients’ demographic data match (e.g., if a patient has the same name, birthdate, and gender); or
  • one patient has two records in an EHR system due to a data entry error or unmerged records.

Partial matching

Most EHR systems use partial matching, which means that any patients that match one or more demographic data points can be returned. So using our same example from above, if the patient demographics all match except the phone number, the EHR still returns that patient, along with any others that have at least one matching data point. In these cases, you want to include as much demographic information as possible so that you find the most probable patient matches.

Fuzzy matching and transposition

You may find some Enterprise Master Patient Index (EMPI) products that go beyond partial matching by also supporting fuzzy matching and some transposition. Our RLS offering is an EMPI-like solution that does this.

Fuzzy matching means that the EMPI product—or our RLS—still returns probable matches if there's a typo or slight character difference (e.g., if you search "Rorbert Day" then "Robert Day" may be returned). Transposition occurs for month and day or nicknames (e.g., if you search "Bobby Day" then "Robert Day" may be returned).

With RLS, probable matches are scored based on how likely they are to be a match. RLS adds up the confidence score of the parameters, so the confidence score can exceed 100.

Contact us to learn more

Probabilistic matching and multiple results are possible with RLS. Typically, RLS is specific to an integration with Carequality, but it can be used for other integrations as well. Contact us if you're interested in learning more.

Carequality Interoperability Framework

You may qualify to join Carequality if your organization employs staff that provides treatment to patients (e.g., physicians, nurses, coaches, therapists). This would allow you to search for a patient across multiple nationwide organizations without needing to connect to each organization individually. Using our Record Locator Service (RLS), you can search for a patient across multiple Carequality participants with just one search. Contact us if you're interested in learning more or read about digital record retrieval.

Requesting additional patient data

Once you locate a patient, you can use other API actions to gather more detailed patient data. If your connection uses FHIR®, you likely need the resource ID to locate patient data. If you don't have the resource ID, you can search for a patient with demographics to return all known patient identifiers, including the resource ID. Alternatively, you can search with a patient identifier that you already have to request the resource ID. Learn more about searching for a patient with identifier.

Action steps

This API action comprises one step.

Search for a patient with demographics

Search parameters

Parameter
Description
given
The patient's first name.
family
The patient's last name.
birthdate
The patient's date of birth.

Returned results

Depending on the EHR system, you may receive one result per search, a list of results, or no results at all. 

Partial or fuzzy matching
Number of results
Scenario
Notes
One
The most probable match is returned.
The EHR system may return an error if they found potential matches but can only return one result per search. The error prompts you to narrow your search criteria so they can locate the most probable match.
A list of two or more
A list of probable matches are returned.
Some EHR systems provide a score for how closely matched a given result is based on a pre-defined confidence level.
If using the Data Model API, this score can be found in the MatchMetadata[] array.
If using the FHIR® API, this score can be found in the bundle.entry.search.score field. However, these score fields aren't required, so it may not always be populated. When it is, it can give you an idea of which patient result in the list is a more probable match.
No results
No probable matches were found.
If using the Data Model API, the Patient[] array is empty.
If using the FHIR® API, the search response bundle is empty.
Exact matching
Number of results
Scenario
Notes
One
An exact match is returned.
A list of two or more
More than one exact match is found.
This is possible with data on demand for two patients with matching demographics or one patient with duplicate records.
No results
No exact matches are found.
If using the Data Model API, the Patient[] array is empty.
If using the FHIR® API, the search response bundle is empty. If this happens, we recommend the "less is more" philosophy—take out extraneous demographic data and search for the patient with the most critical data points.

Search for a patient with demographics Options

Open dropdown