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.
Will the IDType for the patient identifier always be MR or MRN?
Redox sample messages use MR as the value for Patient.Identifiers.IDType, but this is a value that is defined by the health system. MR should not be assumed or hardcoded as the expected ID type.
Some EHRs and health systems have different names for their IDTypes and require those same IDType values be sent back for any updates that you need to push into the EHR.
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.
What events do I need to support?
We recommend being tolerant to as many events as possible, even if your application does not take action in response to or need to know about the event itself. For example, your application may have an interest in keeping patients’ demographics up to date, but does not need to know that a patient was admitted to the hospital–something that would likely trigger an Arrival event. Although your application may not need to know about the admission itself, the most up-to-date demographic, contact, or coverage information may be in the message triggered by that event. If your application handles the demographic updates similarly to a PatientUpdate, you will have the most up-to-date information and you will be prepared to integrate at a wide variety of organizations.
Should I only create new patients upon receiving the NewPatient event?
The NewPatient event, when used, is triggered when the organization creates a new patient in their EHR/registration system, not necessarily when it is new to your application. The first message you receive for a patient will most likely be some other event. We recommend that your application be able to deal with new patients coming across on any event.