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

Definitions

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

User Stories

Summary	User Story	Priority
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.	HIGH
Search for an existing patient	Subsequent visit at a Site	HIGH
Send updates	...to a patient identity (X Y Z changed)	MEDIUM
Retrieve updates	...to the identity for an existing local patient	MEDIUM
De-duplication at local level	Authorized users should be able to id likely duplicates, review, and either merge or mark resolved.	MEDIUM
De-duplication at local level escalated nationally	Authorized 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 Registration	In Search
UgEMR v3
KeEMR v3
KeEMR v2
Ozone
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
Sex
Age or DOB
UPID
Address
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