Enrol

During an enrolment, a frontline worker will collect a beneficiary's biometrics. Simprints then generates a biometrics template and links that to a Globally Unique Identifier (GUID). The GUID is a random alphanumeric string that links the template in Simprints to the ODK record. The GUID is shared with the ODK form and stored along with other demographic information collected through the ODK form.

The steps below references this example form for enrolment (link).

Before starting to build your enrolment form, do check you have the reference form and the correct columns in your form:

Step 1: Open your XML registration form and have the sample form provided as reference (link).

Step 2: Check that these columns are present in your XML form. If not, add them:

• • type

  • name

  • label

  • intent

  • appearance

  • calculation

As part of the Simprints integration, you will need to collect information about the user (User ID) and module (Module ID). Please click here for more information on user ID and module ID.

Step 3: Add questions to collect information about the user and module (refer to rows 12-13 in the sample form)

Add questions to collect basic demographic information from a beneficiary as required for your project.

Step 4: In your XML form, add three rows for three calculate questions and the following names in the 'name' column (Refer to rows 15-17 in the sample form):

• user_id

• module_id

• project_id

In the calculation column:

• user_id: link this to the user filling out the form (if there’s a user question earlier in the form, if not input a string “user”)

• module_id: link this to the module related question earlier in the form (e.g. question on district), if not input a string “module”

• project_id: input the project credentials provided by the Simprints project manager. This is an alphanumeric string in quotation marks: “xxxxxx”

Step 10: End the Simprints enrolment question group with the following questions (refer to rows 23-24 in sample form)

• note: enrolnote

• end group

In the label column:

• enrolnote: Once fingerprints have been collected, please swipe to the next screen*

Data from completed enrolment forms will need to be formatted and stored for the successful identification of a beneficiary. Data can be stored in a CSV file.

Store enrolment data as a CSV file (in the identification and verification forms, the file is saved as "sampledatareg"). The file must include columns on Simprints GUID and a secondary identifier from the ODK enrolment form (e.g. age, name, study ID). The title of the columns need to correlate to the labels used on the enrolment form.

If you are using SurveyCTO, there's another option of storing enrolment data as a dataset on the SurveyCTO web platform. Refer to SurveyCTO documentation on how to do this here

The difference during Enrolment+ is Simprints checks for a suspicious or potential duplicate in the system. Think of it like any registration process when opening a new account online with a bank. If you try to enrol the same person twice it will flag it in the system. Here are the biggest differences.

Step 1: If we see a potential duplicate, rather than enrolling the biometrics we send back the potential duplicate results for the frontline worker to adjudicate. Therefore we need to add the following rows in the registrationgrp:

• type: text ; name: odk-guids ; label: GUIDs:

• type: text ; name: odk-confidences ; label: Confidences:

• type: text ; name: odk-match-confidence-flags ; label: Match confidence flags:

• type: text ; name: odk-highest-match-confidence-flag ; label: Highest match confidence flag:

• type: text ; name: odk-tiers ; label: Tiers:

The odk-match-confidence-flags is returned with each result, depending on how we determine our thresholds on confidence. So along with a pure confidence score, it will be accompanied with a flag NONE, LOW, MEDIUM, HIGH. This doesn't occur in any of the logic, but it may be useful metadata to have a hold of.

The odk-highest-match-confidence-flag is returned with one value for the entire results list. It represents the Confidence Flag of the top result. This is used to determine logic throughout the flow.

Step 2: Next we have to add the identification rows in case results come back with a potential duplicate. This corresponds to rows 28-42 in the spreadsheet below. This operation will only run if the condition in the relevance column in row 28 is met, which is ${odk-guids} != ""

Step 3: Rows 44-49 are also identical to what you would find in an identification flow. If one of the results is in fact corresponding to the person in front of you, these rows will allow you to select that correct beneficiary so that you do not enrol the beneficiary a second time and then return that result to simprints using the com.simprints.simodkadapter.CONFIRM_IDENTITY(projectId=${project_id}, sessionId=${odk-session-id}, selectedGuid=${selected_id}) intent.

Step 4: Rows 51-54 we have a group called flag_duplicate. This only displays if the frontline worker decides to try to enrol a beneficiary when we send back a Medium or High confidence potential duplicate.

Step 5: In the next group called registrationgrp_1 you have an opportunity to enrol the beneficiary (in the case in the documentation we provide, we have relevance that restricts a beneficiary from being enrolled if a HIGH confidence flag is present. Here is the callout in the 'INTENT' column.

com.simprints.simodkadapter.REGISTER_LAST_BIOMETRICS(projectId=${project_id}, sessionId=${odk-session-id}, userId=${user_id},moduleId=${module_id})

Step 6: The next group we have in this form is to add personal details only if you have registered biometrics. In this case we added name and age.

Step 7: We have configured different notes the display at the end of this form depending on the endpoint of the workflow. This can be configured however you like but we provide examples in Rows 66-72.