Background: Since 2018, there have been numerous calls to enhance the DHIS2 data management system by adding “Username” as a data type that can be used in program rules and on forms. While progress has been made with the availability of this data type and the inclusion of createdby in event reports, etc, it has not yet fulfilled the diverse set of use cases requested. This use case outlines an immediate and critical need we yet again find ourselves in at my place of work.
Current Situation: Our organization operates a tracker program where various users, referred to as connectors, enroll girls into the program. These connectors subsequently transfer the enrolled girls to mentors. The mentors maintain routine engagements with the girls across approximately 10 distinct tracker programs, all initially based on the original enrollment done by the connectors.
The Challenge: Before departing for fieldwork, mentors are required to identify and download a list of girls enrolled by a specific connector using the DHIS2 Android app. Currently, we utilize a free-text field labeled “Group_Name” for this purpose. However, the unstructured nature of this text field results in spelling inconsistencies and other data quality issues. And because mentors and connectors are too many country wide, change both orgunits and roles, it’s not practical to maintain optionsets (tried this route too) where they whould be selecting prepopulated names etc.
What we want to be able to do: Our objective is to create a new field, either a “tracked entity attribute” or a “data element,” with the data type “Username.” This field will be updated or assigned with the value of the connector who registered the girls, using a program rule or by default. We can then concatenate the “created by” username with a month/year date to differentiate successive cohorts of enrolled girls. This approach offers a dynamic yet consistently unique way to manage the girls within the system, even if a connector relocates to a different organizational unit or changes roles.
Since username is inherently unique within the system, this ensures that we can reliably group girls by the connector responsible for their enrollment at any orgunit and over time.
This is just one use case we currently need, but we have had other needs for this field or data type.