We're going to go out on a limb and guess that if you're interested in healthcare data exchange, you'll want to locate patient records. With Redox Nexus, you have some options for finding patients in EHR systems.
When you query an EHR system directly to search for a patient, the returned results are typically based on partial matching. This means that any patients that match one or more demographic data points can be returned.
Let’s say you search for a patient with demographics. You provide a name, birthdate, gender, and phone number for the patient. The EHR system locates a patient with the same name, birthdate, and gender, but there’s a different phone number listed. Based on partial matching, the EHR system still returns the record, along with any other records 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.
When you query data on demand to search for a patient, the returned results are based on exact matching. This means that all fields must match your search criteria exactly.
So let’s go back to that example of searching with a patient's demographics, which include a name, birthdate, gender, and phone number. The EHR system 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.
Depending on your configuration, you could receive these kinds of results with 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. |
When you use record locator service to search for a patient, the returned results are based on fuzzy matching and some transposition. This goes beyond partial matching and works a bit more like an Enterprise Master Patient Index (EMPI) product.
In this scenario, a patient demographics search returns probable matches even if there's a typo or slight character difference. For example, 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).
These types of probable matches are scored based on how likely they are to be a match. Record locator service adds up the confidence score of the parameters, so the confidence score can exceed 100.
Depending on your configuration and your connections' capabilities, you could receive these kinds of results with fuzzy matching:
Number of results | Scenario | Notes |
|---|---|---|
One | The most probable match is returned. | The EHR system may return an error if they find 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 is 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, you can find this score in the MatchMetadata[] array. If using the FHIR® API, you can find this score 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. |
Now, you might be thinking any of these search options sound great, so how to choose between them? Here's some guidance for finding the best fit for your organization:
You may prefer data on demand if:
- You only need to search one EHR system at a time.
- You're searching with patient IDs or data that you know has been inputted correctly.
- You want a lightweight alternative to record locator service.
You may prefer record locator service, though, if:
- You want to search across multiple connections at a time.
- You're relying on demographics for patient searches. If so, fuzzy matching comes in handy, especially if you know the inputted data might be prone to human error.
What if you can't choose? Good news, you can use both, depending on your organization's needs and unique workflows. Talk to a Redoxer to find out what works best for you.