Understanding the Redox PatientSearch Data Model

When do I need to use the PatientSearch data model?

The PatientSearch data model is a model applications can leverage 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 identifiers and full demographic profile.

What is supported via Data Chateau?

For PatientSearch queries via Data Chateau where Redox is responding to the application’s query based on ADT HL7v2 or similar data that’s pushed from the healthcare organization, identifier-based searching is supported.

What is supported outside of Data Chateau?

If the connecting EHR supports a Patient Demographic Query (PDQ), a Cross Gateway Patient Discovery (XCPD), or an API that Redox can map the PatientSearch model to then demographic-based searching is supported and patient identifiers are not required.

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.

Are potential matches 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 model to a PDQ or an XCPD then potential matches will not be returned.

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