Patient Identity Use Cases in Registration and Search (MPI & CR Lookup)
- Grace Potma
Definitions
Main user: Reception / Registration Clerks. Or, at smaller sites, Nurses or Clinicians who are also providing care.
User Stories
Summary | User Story | Priority | Notes |
|---|---|---|---|
Register a new patient |
| HIGH | |
Search for an existing patient |
| 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: |
|---|
|
|
|