Patient Identity Use Cases in Registration and Search (MPI & CR Lookup)


  • Main user: Reception / Registration Clerks. Or, at smaller sites, Nurses or Clinicians who are also providing care. 

User Stories

SummaryUser StoryPriorityNotes
Register a new patient
  • First Registration at Site
  • Search to check for matching/duplicate patients: 
    • Local System Search + MPI Search all at once
    • Ideally seamless one-step process, not multiple. 
Search for an existing patient
  • Subsequent visit at a Site
Send updates a patient identity (X Y Z changed)MEDIUM

Retrieve updates the identity for an existing local patientMEDIUM
De-duplication at local levelAuthorized users should be able to id likely duplicates, review, and either merge or mark resolved. MEDIUM
De-duplication at local level escalated nationallyAuthorized users to run de-dupe processes locally to i.d. matching patients that could be sent back to MPI or CR as potential matches (depends on centralized review and decision making)LOW

De-duplication between local and national level:

Match locally with someone nationally: eg orphaned record never added to our facility; but we find their record from another facility available in the MPI. (distributed decision making)LOW


In RegistrationIn Search
UgEMR v3Screenshot 2024-02-09 at 01.32.42
KeEMR v3

KeEMR v2

DS4_HC_Patient Search-Results-PMRSprompt

Ampath v3

Ampath v2

When an AMD/GD/OP enters patient information (i.e., care code and socio demogs such as name, sex, age, and/or DOB) from a new paper-based patient chart into OpenMRS, and tries to validate
if this patient potentially already exists, OpenMRS will query PIM when there is an active internet connection to check if the patient has been already registered. The query will be made possible by the connection between OpenMRS and PIM.

PIM will run the algorithm to find the duplicates and return a message to OpenMRS about whether any matches have been found. OpenMRS will display information transmitted from PIM whether potential matches have been found.
If no matches are found, the AMD/GD/OP will proceed with building the new patient profile, and new patient data will be sent to PIM.
If there are potential matches
OpenMRS will display a list of potential matches ranking from high to low probability of duplication;
the AMD/GD/OP will adjudicate/flag which matches need further review and verification in OpenMRS;
OpenMRS sends back information to PIM based on the decision. Possible actions:
Continue creating the new patient and flag it as duplicate for an existing record at another facility
Not creating the new patient at this time and flag that this person already exists at another facility

If deciding not to create the new patient, duplication flags will be created and stored in PIM, and users can access previous duplication flags through PIM.

Data Variables Needed

The EMR Needs:
Care code

First and last names


Age or DOB



Cell phone number

Edge Cases:

  • Biometrics (eg fingerprint-based search of an MPI)
  • Date of HIV testing (Source: ITECH-CIV)
  • Date of ART initiation (Source: ITECH-CIV)
  • Date of UPID creation (Source: ITECH-CIV)
  • Date of enrollment in care (Source: ITECH-CIV)
The PIM / MPI / CR system needs:
  • Surnames and first names
  • Sex
  • Age or date of birth