This page focuses on the processes used to ensure data quality across the OpenSRP systems.

Unique Person Identification

Unique Person Identification is a process by which individuals interacting with the health system are able to be uniquely identified, relevant information is able to be accessed in the client's health record and that information informs the care provided to the individual. Successful unique person identification practices lead to a unified longitudinal health record for an individual regardless of the location where care is provided. Unique person identification processes focus on ensuring that the person receiving care is appropriately matched to the record in the health system. This often takes the form of asking a series of questions of the individual (something they know), reviewing an officially recognized identity card or care booklet (something they have) or using biometric scans such as fingerprint, palm vein readers or iris scans (something they are).

OpenSRP has a number of built-in features that support the unique identification of people directly from the Android client:

• Assignment of a globally unique identifier on the tablet when offline
  • The OpenSRP Android client stores a unique person identifier on each person that's registered in the system. This identifier travels with the client's record, is guaranteed to be globally unique across OpenSRP and OpenMRS and is linked to each clinical encounter. 
• QR Code scanning
  • Some OpenSRP implementations utilize a QR code scanner to quickly search for clients on their device. At each client registration, a QR code sticker is placed in the client's health book and it's scanned on each subsequent visit. This improves the time it takes to search for and identify a client who is about to receive care.
• Device-level Demographic Search
  • This feature allows the frontline health worker to query all clients on their tablet by basic demographic information including name, date of birth, gender, etc.
  • No internet connection is required to perform this search.
• Advanced Search for out of area clients (internet required)
  • The advanced search feature allows a frontline health worker to search the entire OpenSRP database for a client by demographic information. This global search requires the internet because it actively searches the entire OpenSRP database for the client. A list of clients is returned and the frontline worker is able to add the client's record to their Android device.

Description of the Event and Client Data Model

It's important to understand the OpenSRP data model when having a conversation about data quality. OpenSRP has standardized on an Event and Client data model that stores each encounter that takes place as an event and each person as a client in the system. In the background, we create tables on the Android client and OpenSRP server that form a digital representation of the client. Each implementation has a unique process for generating tables on the Android client to improve the in-app performance. Generally speaking, though we maintain a client table on the Android client and on the OpenSRP server that keeps the core characteristics of each registered client updated. So, if an "update registration" form is completed on the Android client, the local client table gets updated with the most up-to-date information and that "update registration" event is forwarded to the OpenSRP server where a similar process takes place. Furthermore, the event is forwarded to the OpenMRS server where the patient/person information is updated.

Identification and Deduplication of Clients

The OpenSRP server contains a data repository of all clients in the system with the focus on providing a single record for each client. The aforementioned Android client features aim to reduce the number of duplicates that are entered in the system, but we recognize that duplicates are inevitable and are developing strategies to identify and merge patients who are recognized as duplicates. The OpenSRP server does not currently include a user interface or process for identifying duplicates and modifying their records. Currently, implementers run custom queries against the database to identify duplicates and manually edit each document to merge clients and events in the OpenSRP database.

OpenMRS' Registration module acts as a Master Person Index with the capabilities to identify and merge patient records in the OpenMRS system. The OpenMRS "Merge Patients" user interface allows implementers to choose matching properties and a list of possible matches are presented to the user. They are then required to review each record side-by-side. If the two records appear to be duplicated, the user chooses which record to keep and which record to archive. Once approved, the system moves the demographic information to the retained record and reassigns all encounters and observations to the retained record. All information on the discarded record is archived in the OpenMRS database. These changes, however, are not reflected in the OpenSRP server and require complex manual adjustments in order to be reflected in the Android client.

Sample Processes for Identifying and Deduplicating Clients

Each implementation utilizes different mechanisms for identifying duplicates in the system. This section documents processes used by each implementation.

Zambia (ZEIR)

The ZEIR implementation of OpenSRP relies on an ETL process to extract the information from the CouchDB and load it into a postgreSQL client table. This client table is searched to identify clients who have the following:

• Demographic searchesSame Name, DOB and Gender
• Duplicate ZEIR Ids (There should be no duplicates in the system)
• Duplicate m_zeir_id (Mother Zeir IDs)
• Clients with null ZEIR Id and null m_zeir_id (There should be none in the system)

Additionally, the BlueCode team is testing the OpenMRS merge patients user interface to identify duplicates in the system so they can be adjusted in both OpenMRS and OpenSRP Servers.

Bangladesh

(Sohel Sarder can you contribute to this section?)

Indonesia

Indonesia implementation of OpenSRP is based on data sharing platform, each of OpenSRP App( Nutritionist, Vaccination and Midwifes App) Share the basic client record  as well as the important data that needed by other workers (not all data is shared) on their working area (Based on Village), this feature created issue on duplication when the Apps doesn't connect to internet (since the others App can't get the latest data and others workers assume that the patient hasn't been recorded). To identify the clients who have duplicates data, Indonesian team created separated automated data cleaning that will review the data based on:

• Name, Husband Name, DOB, and Village Name
• National ID Number, Verhoeff Id Number
• Workers ID (Ranked up by : 1. Midwifes, 2. Nutritionist, 3. vaccination)

This data will be analyze and will be rank up based on the latest updated version of the patient visit record, later this data will be reviewed with the health workers and Indonesian science team before decided to take out the out of date data then merged the event data from duplicated data.