# Search for a patient with identifier

You can use this API action to retrieve a patient's record from an EHR system with a specific identifier. 

> **Search with a patient's identifier or demographics? **
>
> You can locate a patient’s record in an EHR system with either an identifier or with demographics. So how do you know which to use and when?
>
> Using the <u>patient identifier</u>:
>
> - saves time since you only populate one field instead of a handful of demographics fields; and
> - likely locates the correct patient since identifiers are typically more unique than patient demographics.
>
> 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.
>
> On the flip side, using the <u>patient demographics</u>:
>
> - allows you as an outsider (stay gold, Ponyboy) to search a system that you don’t have access to; and
> - locates the patient identifier if you don't have one already.
>
> So 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. [Learn more about searching with patient demographics](/fhir-api-actions/patients/search-for-a-patient-by-demographics).

## Use cases

This API action may be a good fit for your organization if you perform any of these use cases:

- Tie patient records from your system to the patient’s record in the relevant EHR system.
- Locate other patient identifiers used in different systems. 
- Start a search for a patient’s demographics, insurance, general clinical data, test results, prescribed medications, or vaccination history.

## 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**
>
> Your connection's system may not 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_ the 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 <u>data on demand</u> service, which stores the connection's data so that you can query from Redox "on demand." [Learn about data on demand](/basics/data-exchange-with-redox/data-on-demand).

## Things you need to know

<details>
<summary>Not your typical Google search</summary>

While this API action is great for easily locating a patient, it doesn't work like a Google search or a SQL database search. The purpose is to find matches for a _specific_ patient, not a list of potential patients. In other words, you have to know who you’re looking for.

</details>

<details>
<summary>System and identifier types</summary>

A patient ID is a unique value that represents a patient record. That value is only meaningful in a certain context, though, whether that be a particular system or namespace. In FHIR, `system` defines the context for the ID. We recommend using `system` when querying with the patient ID whenever possible.

> **Identifier type tips**
>
> If you’re receiving an HL7 feed with patient data, you’ll receive a patient ID and identifier type. The identifier type may help derive the `system` to use when querying with FHIR.
>
> If you’re querying a data on demand instance, you should always include both the identifier’s `value` and `system` when searching for patients.

Ultimately, EHR systems have different requirements for patient searches. Typically, patients have a unique identifier within the EHR system, as well as alternative identifiers used for specific purposes. For example, if the identifier is 123 with a type of MRN, then you may know it’s for System A, which uses MRNs to track patient records. On the other hand, you may have an identifier of 123 with a type of MR, which should be used for System B since they use MRs to track patient records. So the same identifier value may not necessarily mean it has the same identifier type in every system.

You can potentially search for a patient with any of these common identifier types: 

- EHR-specific identifiers
- medical record number (MRN)
- medical record ID (MR)
- driver’s license (DL)
- passport number (PPN)
- Social Security number (SSN)
  - not recommended
- organization ID (OID)
  - Within Redox, an OID typically refers to an identifier used for <u>Network Onramps</u> when searching clinical networks (e.g., Carequality).

</details>

<details>
<summary>FHIR resource IDs</summary>

FHIR uses a resource ID for the patient identifier type. If your connection uses FHIR, you’ll likely need the resource ID to locate patient data.

If you don’t have the resource ID, you can use the patient identifier you already have to find the resource ID. Or you can search for a patient with demographics to locate the resource ID. [Learn about searching for a patient with demographics](/fhir-api-actions/patients/search-for-a-patient-by-demographics).

</details>

<details>
<summary>EHR-specific IDs </summary>

The important thing about searching for a patient with an identifier is that you must search with the identifier types that are relevant to the EHR that you’re searching. That may sound obvious, but you can’t search for a patient by their driver’s license number if the EHR uses MRNs instead. You must use the ID and ID type as specified by the EHR.

Typically, the EHR provides at least one patient identifier that you can later search with. So, however you receive the patient identifier from the EHR is how you should send it in requests to the EHR. In some cases, you may need to ask the EHR what static identifier type they use. Or, you may receive the patient identifier when you send requests for other data, like requests related to scheduling or orders for that patient.

</details>

> **What's next? **
>
> Does this API action seem like a good fit for your unique workflow? Let your Technical Account Manager know! To start development, download the resource schema noted in the related action step. Then decide which data elements you need.
>
> If you’re new to Redox, [use the Quickstart guide](/quickstart-for-redox) to dive in. If you’re not engaged with our sales team yet, [talk to a Redoxer](https://redoxengine.com/forms/contact-us/) to get started.