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:
There are two ways to locate a patient in an EHR system: with demographics or with an identifier. So how do you know which to use and when?
Using the patient demographics:
This back-door alternative is fantastic if you have the patient's info, minus the appropriate identifier. We can still help you find the right patient with a little extra time.
On the flip side, using the patient identifier:
The catch is that you have to already have a patient identifier, like the MRN, on hand. If you do, we definitely recommend this option. We also recommend validating you found the right patient (because you don't ever make typos, right?) by confirming the returned patient's demographics match your patient. Once confirmed, you can start retrieving the patient's relevant clinical data.
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.
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." Learn more about data on demand.
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:
Typically, you must also include at least one of the following, but these requirements differ based on the EHR system you're integrating with:
We recommend using as much demographic information as possible though; otherwise, you may find other patients with the same basic demographic information.
For easy reference, here are some common data points that you can’t use to search for a patient:
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 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.
Exact matching may still return multiple matches. This can happen if:
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.
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.
Probabilistic matching and multiple results are possible with record locator service. Typically, record locator service 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.
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. |
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. |
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.
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.
Does this API action seem like a good fit for your unique workflow? If so, let your Redox rep know! You can begin development by downloading the relevant resource schema (which is noted in the relevant action step below), and deciding which data elements you need. Then head over to our Quickstart guide to dive right in.
If you're not engaged with our sales team yet, talk to a Redoxer to get started.
This table has notes about how to use parameters for this API action specifically, but it's not exhaustive. Refer to the resource schema for more details.
Query parameter | Required | Notes |
|---|---|---|
given | Y | When searching by demographics, you must include the patient's given name (typically first name)—along with any other demographics you want to include—for the search to be successful. |
family | Y | When searching by demographics, you must include the patient's family name (typically last name)—along with any other demographics you want to include—for the search to be successful. |
birthdate | Y | When searching by demographics, you must include the patient's date of birth—along with any other demographics you want to include—for the search to be successful. |
Depending on the EHR system, you may receive one result per search, a list of results, or no results at all.
If you're operating in Canada, you must tweak the Redox hostname slightly. All you need to do is add a ca in that URL like this: https://api.ca.redoxengine.com.
curl ---location --request POST 'https://api.redoxengine.com/fhir/R4/redox-fhir-sandbox/Development/Patient/_search' \--header 'Content-Type: application/x-www-form-urlencoded' \--header 'Authorization: Bearer $API_TOKEN' \--data-urlencode 'given=Keva' \--data-urlencode 'family=Green' \--data-urlencode 'birthdate=1995-08-26'
{"id": "fc7b832c-2a3b-4b17-80e7-2dbc81109f8f","type": "searchset","entry": [{"search": {"mode": "match","score": 1},"resource": {"id": "81c2f5eb-f99f-40c4-b504-59483e6148d7","meta": {"lastUpdated": "2020-10-29T20:06:13.429Z"},"name": [{"use": "official","given": ["Keva"],"family": "Green"}],"active": true,"gender": "female","address": [{"use": "home","city": "Hillsboro","line": ["932 Stehr Vista"],"state": "OR","postalCode": "97123"}],"birthDate": "1995-08-26","extension": [{"url": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-race","extension": [{"url": "text","valueString": "White"}]},{"url": "http://hl7.org/fhir/us/core/StructureDefinition/us-core-ethnicity","extension": [{"url": "ombCategory","valueCoding": {"code": "2186-5","system": "urn:oid:2.16.840.1.113883.6.238","display": "Non Hispanic or Latino"}},{"url": "text","valueString": "Not hispanic or latino"}]}],"identifier": [{"value": "kyHGADnvX3xbkU4V9ayaqh","system": "urn:redox:redox-fhir-sandbox:MR"}],"resourceType": "Patient","deceasedDateTime": null}}],"total": 1,"resourceType": "Bundle"}