Understanding the Redox PatientAdmin Data Model

When do I need to use the PatientAdmin Data Model?

The PatientAdmin Data Model is the most common feed used across Redox customers and is something we would recommend you require if you persist patient data in your application. Over 90% of our installs use PatientAdmin in some form.

This is the primary method for you to stay in sync with the health care organization regarding the patient’s documented demographics, insurance information, and the health system’s patient identifier (usually called a medical record number or MRN). PatientAdmin is the only webhook-based feed that communicates changes to this type of patient information, usually through a push notification generated from health system’s ADT HL7v2 interface. PatientSearch details an alternative query based approach to retrieve patient information.

The information offered in PatientAdmin is quite varied, but can be broken into two main categories:

  • Patient level information – This is information that is about the patient that persists over time, such as their name, address, gender, DOB, email address, or Primary Care Provider, and is not tied to a particular hospital encounter.
  • Visit level information – Information pertaining to the patient’s visit, such as the current location (bed, room, department), referring provider, admitting provider, care team or discharge date/time.

What is a PatientMerge event?

A PatientMerge event occurs when the health system identifies duplicate patients in their EHR system and merges their charts together.  This usually is an uncommon event that occurs a few times per month at a health system, but it’s critical for you to know the correct patient identifier and to help you identify if you have duplicate patients from the health system in your application.  

If you persist patient information in your application, we strongly recommend that you plan to receive PatientMerge events from the health system.  Most Redox application partners develop to accept the PatientMerge event and leverage a notification process such as an email or page to either someone on their team or someone at the health system with access to the application to manually review duplicate patients identified for merge.  If duplicates exist that need to be merged, application often manually handle the process of merging the records on the backend.

If I can get VisitUpdate information from PatientAdmin, why do I need a Scheduling feed?

The biggest pieces of scheduling related content that you can’t get on a PatientAdmin feed is the appointment status and appointment type. Additionally, if your application is looking to receive information about the visit at scheduling, a Scheduling feed is your best bet to receive messages prior to patient arrival.

Will the IDType for the patient identifier always be MR?

Redox sample messages use MR as the value for Patient.Identifiers.IDType in the PatientAdmin Data Model. However, once implementing, the healthcare system assign this value.  Some EHRs and health systems have different names for their IDTypes and require applications to send back those same IDType values for any updates pushed into the EHR.

But, I only have to worry about the main identifier, right?

Not always – some health systems will have multiple identifiers that are used for different reasons so you should plan to be able to handle multiple identifiers in the Patient.Identifiers array in the PatientAdmin Data Model.

Doesn’t the patient information change a lot?

Yes, given the large amount of data elements, EHRs often trigger your application may receive large volumes of messages via the PatientAdmin Data Model.