Questions and Answers > Understanding the Redox PatientSearch Data Model
Questions and Answers

Understanding the Redox PatientSearch Data Model

When do I need to use the PatientSearch Data Model?

Applications can leverage the PatientSearch Data Model (Not to be confused with Redox Patient Record Locator Service) when they have key patient inputs, such as demographic data or the patient’s Medical Record Number (MRN), and are looking to confirm and receive all of the patient’s information. This can be divided into two main use cases:

  1. Search by identifier: In this case, the user or application may key in a key identifier such as the patient’s MRN and expect to return the full set of patient level demographics.
    1. The response should either be positive (when a patient is found with the MRN and full demographics are returned) or negative (when no patient can be found with the queried MRN).
  2. Search by demographics: In this case, the user or application only have key demographics, such as name, birth date, gender, SSN and expect to return any possible matches from the EHR system.
    1. The response may be one patient, many patients, or no patient.

Can I query for patients across multiple organizations?

Currently with the Redox API, you will need to query each Destination separately. We currently have a Record Locator Service solution in Developer Preview that enables robust demographics queries across the Redox network at scale. If interested, you can sign up here!

If I’m querying with demographic data points as inputs, what is required to identify a patient using Redox’s Data on Demand feature?

Data on Demand queries use “exact” matching. In other words, a search for phone number “(608) 555-1234” will not match a patient with a phone number of “608-555-1234”. Apart from identifiers, strings are matched regardless of case (“mcfly” will match “McFly”). Meeting any one of those sets should allow a query to be performed:

  • Identifiers[]
  • FirstName + LastName + DOB + ZIP
  • FirstName + LastName + DOB + City + State
  • FirstName + LastName + DOB + Phone
  • FirstName + LastName + DOB + Email

If I’m querying with demographic data points as inputs, what is required to identify a patient at a given EHR?

Every EHR will have its own threshold of required demographic inputs in order to correctly identify a given patient. Some smaller systems may just need first name, last name and DOB. Other larger, enterprise systems will need additional data points like zip code, phone number, email, etc. If demographic-based searching is a required part of your workflow, it will be good to discuss this early with your healthcare organization partners to determine what they need in order to respond to the queries.

What if I have a patient’s SSN? Shouldn’t that be sufficient to identify a patient’s record?

Many health systems won’t accept a patient’s SSN as part of a PDQ or XCPD. This is something that will be variable by site that we can talk through with each healthcare organization.

Is a patient’s insurance information always included in the response?

No. Patient insurance information is not typically included on PatientSearch responses.  The PatientAdmin data model is used for insurance information.

When multiple potential matches are found in a demographics-based search, are they always included in the response?

No, not always. When Redox’s Data on Demand feature is used, an error will be returned if there are multiple matches found as this feature supports exact matching.  Generally cloud-based EHRs that have a corresponding API, like Athena, will return potential matches. If we are mapping our PatientSearch Data Model to a PDQ or an XCPD, then potential matches will not be returned.

If there isn’t a match to a PatientSearch query, what can I expect to receive from Redox?

If the EHR doesn’t return a patient, Redox will send you an empty array.

Keep in mind that we’re happy to talk through the above in more detail as we scope your integration project!