ID Management

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

Patient IDs

Before you can send any data into a health system, you must know the patient ID. Until a universal patient identifier is adopted, we must deal with the fact that each health system uses its own identifier for patients. In fact, some health systems use many more than that. Code your system with the assumption that there will be just one patient ID for you to work with. When you begin integrating with a new health system, always have the discussion early regarding whether this assumption is true, and work from there.

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

Patient Merge

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.