Understanding the Redox PatientSearch Data Model

When do I need to use the PatientSearch Data Model?

 Applications can leverage the PatientSearch Data Model 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.

What is supported via Data Chateau?

Only identifier-based searching is supported for PatientSearch queries via Data Chateau. Redox will respond to the application’s query with information stored from ADT HL7v2 messages or similar event-driven data that’s pushed from the healthcare organization.

What is supported outside of Data Chateau?

Both identifier-based searching and demographic-based searching is supported if the connecting EHR supports a Patient Demographic Query (PDQ), a Cross Gateway Patient Discovery (XCPD), QRY^A19 HL7v2 message or an API that Redox can map the PatientSearch Data Model. 

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 HCO.

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

No. Patient insurance information will be returned for PatientSearch queries leveraging Data Chateau where Redox has previously received insurance information for a patient via an ADT HL7v2 or similar feed from the connecting healthcare organization.

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

No, not always. 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!