CHT, an electronic medical record system, basically consists of an instance server (with an access through web UI), and an Android app that provides access to the server similarly to a web UI.
Simprints ID, a biometric ID system, basically matches a person's (patient's) biometrics, such as face image or fingerprint depending on instance settings, with a unique ID string linked to the patient. Access to a Simprints instance is done through an Android app https://github.com/Simprints/Android-Simprints-ID/releases, by using credentials typically given in the form of a QR code.
CHT Android app https://github.com/medic/cht-android/releases (get an "unbranded" APK appropriate for your mobile platform) can launch Simprints ID Android app through Android's intent system. If the CHT instance credentials allow setting up so called App forms, this can be configures through the Web UI. If you don't have access for such a CHT server instance, you can run your own development-oriented instance on Docker: clone https://github.com/medic/cht-core, and follow https://docs.communityhealthtoolkit.org/building/local-setup/. You'll be able to log in into your local instance via a link looking for example like https://192-168-1-1.local-ip.medicmobile.org:10444.
If you go to /admin/#/forms in your instance (in the previous example: https://192-168-1-1.local-ip.medicmobile.org:10444/admin/#/forms), there you can select and upload a pair of an XML and a JSON form documents for integration with each biometric flow of Simprints ID.
Note: make sure to substitute
SIMPRINTS_PROJECT_IDin each form's XML file with the correct project ID string that corresponds to the Simprints project access QR code.
There are 3 main biometric flows:
| Flow | Enrollment | Verification | Identification |
|---|---|---|---|
| What it does | Takes new patient's biometrics and returns GUID to attach to medical record | Checks if existing patients' biometrics match the initially enrolled ones by a given GUID | Determines which (if any) previously GUIDs match with the patient's biometrics - a "biometric search" |
| Where in CHT it appears | Patient's profile "+" menu item (when not enrolled yet) | Patient's profile "+" menu item (when already enrolled) | Reports tab "+" menu item |
| What's the result | Simprints biometric ID (GUID) is attached to patient's record | A verification report in Reports | An identification report in Reports |
| Form XML | form_biometric_enroll.xml | form_biometric_verify.xml | form_biometric_identify.xml |
| Form metadata JSON | form_biometric_enroll.meta.json | form_biometric_verify.meta.json | form_biometric_identify.meta.json |
More info on Simprints ID integration, if needed: https://simprints.gitbook.io/docs/development/simprints-for-developers/integrating-with-simprints
Note: if you edit the XML forms, make sure to keep the
nodeset="/data/simprints_launcher/android-app-inputs/versionCode" type="int" calculate="20250102"/>intent extra. It signals Simprints ID to return its result intent payload data in JSON format, needed for CHT to be able to extract the result data.
When all forms are imported, in the CHT Android app, the biometrics-related items will appear as shown below.
The verification and identification results are reports that contain the outcome of biometric operation, patient's info, and session info of Simprints ID - therefore, a proof of each verification and identification, stored in the CHT data system.
Note: the blue-themed screen is Simprints ID app, the rest of the screens are CHT. The Simprints-related form action in CHT is highlighted in green just for illustrative purpose.
Note 2: if you need to remove a form, you can go to
/_utils/#/database/medic/_all_docs. The forms will beform:simprints:person:biometric_enroll,form:simprints:person:biometric_verify, andform:simprints:utility:biometric_identify.
Note 3: To auto-populate a contact from an identified Simprints GUID, a potential way might be a JS-based extension library, which may require CLI access on the server instance rather than the web UI. The forms alone might have too constrained capabilities to do that, but double-checking is a good idea if identification UX improvement is needed.