The Redox API makes ID management straightforward. Here’s a breakdown of a few different IDs you’ll be using and interacting with while using the Redox API.
Source and Destination IDs
Application developers can sometimes confuse the Source and Destination IDs of the system with whom they’re exchanging data. It’s important to note that these IDs are not the same—incoming messages will have that system’s Source ID, which is different from that same system’s Destination ID (to which outbound messages should be sent).
Before you can push any patient data back into a health system you will need to obtain the correct identifier for the patient in the destination EHR. Connecting applications usually obtain these by consuming an outbound feed from the EHR and storing the relevant patient demographics and identifiers sent through that interface.
It is also not uncommon for EHRs to assign patients multiple identifiers, which may require the connecting application to also store and track multiple identifiers. When you begin integrating with a new health system, always have the discussion early regarding whether this assumption is true, and work from there.
Please note that the ID type for the patient ID may very per health system. For example, the main ID type for a given health system’s MRN may be “Enterprise” at your first site, “Patient ID” at your second, and “EPI” at your third.
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.
Visit IDs and Direct Scheduling
Health systems always appoint visit IDs to any appt that gets scheduled within their system. When an application is direct scheduling using the Available Slots query with a health system, they can send in scheduling appointments using their own external ID and receive an echoed response containing the health system visit ID. Visit IDs are necessary if an application is looking to send in encounter-specific information (such as encounter notes) into the health system
Health systems run tools that analyze their master person index (MPI) and identify potential duplicates. After reviewing the list of duplicates, they perform chart merges for each confirmed duplicate in their system. When this happens, downstream systems need to begin using the new patient identifier to ensure data is filed to the correct place in the EHR.
Merges are communicated on the inbound PatientAdmin data model with the event type of “Patient Merge”. Applications that are receiving an inbound PatientAdmin feed should be aware of this and ensure their code accounts for this type of event.