User Management

Table of Contents

Background

Target Audience

Assumptions and Validations

Process Flow

Solution

Out of Scope

Specifications

Design

Background

This document describes the need and scope of a digital platform for health campaigns, explaining the product’s features, specifications, purpose, and functionality. It also provides a descriptive view of the application along with the specification of each element.

About

The ability for supervisors/managers to create and manage users and team assignments for their respective boundaries through the user interface.

Problem

The current process for managing users is operationally heavy for the following reasons:

• A high volume of user accounts is required initially.

• The programme does not have the capacity to use backend APIs, and hence would rely on implementation partners (CHAI or eGov). This acts as a blocker because the final list of users and teams is finalised 3 days before the campaign starts.

• Multiple changes are requested throughout the campaign (high churn rate for contractual workers).

Impact

Delay in creating and sharing new user credentials or changing project assignments impacts campaign operations (and ultimately coverage) as users have to wait on the field to receive their credentials and start working. This also creates a dependency on the implementation partner to support each campaign and does not empower the programme to take ownership (the solution is not sustainable).

Target Audience

This document is intended for the engineering and platform (tech teams), product management, and implementation teams to agree on the requirements for the Health Campaign Management (HCM) Platform.

Assumptions and Validations

Theme	Assumption
User account creation	Assumed that the programme will collect user demographic details during user onboarding and link them to the user profiles. If demographic details are not collected and linked to user accounts, then the creation of a staff registry will not provide the data that is fit for reuse. Users can exist in the system even without a campaign assigned.
Bulk operations	Assumed that the frequency of bulk account creation and deactivation is low and will happen before and after the campaign (UI to perform bulk user management is good to have).
UI for user management	A UI for user management will enable decentralised user management, and the programme will train district-level users to perform user management actions to reduce the load on the central system admin.
Mapping of user accounts to administrative areas	With a UI that decentralises user management, it is assumed that users will be created and mapped to more granular levels in the boundary hierarchy. Mapping user accounts at a higher boundary level will hamper the generation of reports for team performance.
User management	UI for user management will require an internet connection (no support for offline user management). User management functionality to be accessed using responsive web apps (support desktop and mobile views).
Password reset	If the users do not have email IDs linked to their accounts, then a common recovery email must be linked to each account which will be used for password recovery. - In this case, only the system administrator or any user who has access to the recovery email must be able to reset passwords via an email OTP-based authentication.

Role-Action Mapping

1. System administrator

a. Create, search, update and deactivate user accounts.

- CRUD other system administrator accounts.

b. Create, assign, update, delete role assignments.

c. Create, assign, update, delete campaign assignments.

2. Supervisors

a. Create, search, update and deactivate user accounts (except system admin).

b. Assign/update/delete role assignments.

c. Assign/update/delete campaign assignments.

3. Helpdesk user

a. Create, search, update and deactivate user accounts (except system admin).

b. Assign/update/delete role assignments.

c. Assign/update/delete campaign assignments.

Process Flow

Solution

High-level scope:

• Along with APIs, provide a user interface (UI) to empower district managers/supervisors to own and manage user account creations/updates for their respective campaigns.

• Both bulk user management (template-based upload) and individual user management functionalities would be required on the UI.

- Bulk user creation will be done at the beginning of the campaign.

- Individual user creates/updates/deletes will most likely be done before and during the campaign.

- Bulk user deactivation will be done after the campaign.

• The programme would need the flexibility to move actors from one campaign to another for operational reasons. Hence, to change campaign assignments, a UI component would be required so that user management can be decentralised.

Note: A project (aka campaign) is defined as follows in the HCM system:

A campaign can be any collection where:

• Either service delivery takes place (that is, the lowest level in the administrative hierarchy),

• Or any boundary, which is a parent of the boundaries where the service delivery takes place but needs to report on metrics by aggregating metrics from all the child boundaries.

• Example:

a. Either the campaigns can be set up as a parent-child relationship (tree structure), that is, national (only reporting)-province(s) (only reporting)-district(s)-only reporting–villages (service delivery and reporting). (Must be of the same campaign type);

b. Or it can be set up only at the village level: where village A, and village B are two separate campaigns (can be of the same campaign type or different).

User Accounts

Two types of user accounts need to be created during a health campaign:

1. Mobile app users’ accounts: Frontline workers (mostly contractual) who will log in on the phones and submit data to their assigned project. These users must also be able to view mobile reports to track their progress or the progress of their teams.

2. Web app user accounts: Supervisors, system administrators, helpdesk users (most likely permanent employees of the health system, but some can also be contractual), who are mostly responsible for viewing online dashboards and reports to monitor campaign progress and view data submitted by the frontline workers (mobile app users).

a. However, some supervisors may also be responsible for data collection and may act as both data collection agents as well as data reviewers.

3. The system administration must be able to create all user roles and assign actions to each role as mentioned in the role-action mapping section.

4. The system administrator must be able to provide user management permissions to other roles as required (for example, supervisors, and managers).

5. Any user, who has permission to manage/create users in the system, must also be able to perform the following actions:

a. Create users (except the system admin).

b. Search for existing users - Search parameters: Name, username, etc.

c. Edit user details.

d. Deactivate users.

e. Edit campaign assignment.

6. The system administrator must be able to create a new user by only specifying the username (credential used to log in to the system) and setting the password with the ability to add other demographic information later.

a. The system user must be able to share the list of usernames and passwords with the programme, once created.

7. Once created during user creation, the username must not be changed. Users creating user accounts must NOT be able to change usernames once created. Product recommendations on choosing a username (these are only recommendations and the programme can decide to create its own username format):

a. First name: This is for people to remember. But if there are multiple users with the same name, then use serials (user, user2) or add a second initial.

b. Phone number: This is a unique number and easy for most people to remember (existing DIGIT functionality).

c. First-last name: This may be longer and more complex but more likely to be unique for each user.

d. Administrative area name: This approach may be adopted if there is a high turnover as multiple users may use the same username. However, the system will not be able to tell which person has submitted the data during analysis (current approach following the LLIN campaign in Mozambique).

1. If the programme wants to track the performance of each frontline worker individually, then the product SOP recommends that each mobile app user should have their username even if they are sharing a device. Since the system will provide reports on the performance/productivity of your mobile app users, if multiple mobile users are sharing a username, then the performance reports will reflect the team performance and not necessarily individual performance, provided the username to individual mapping is maintained outside the system.

e. Regarding the use of special characters: It is recommended that only commonly-known special characters like period (.) be used in the username to make it easy to remember.

f. Regarding the use of capital case: It is recommended to use either all lowercase or all uppercase characters to make it easy for the users to remember and enter the login credentials (lowercase preferred).

g. Regarding the setting of passwords: It is highly recommended that passwords for system administrators, training applications and production applications be kept distinct to avoid confusion.

h. It is also recommended to keep passwords simple so that mobile app users do not forget the password and hence, do not face a barrier in using the app.

Specifications

Login Credentials (Must have)

Field	Data type	Data Validation	Required	Comments
Username	String	Must be unique and non-editable once set.	Y	The format for creating user names must be configurable.
Password	String		Y

Demographic Information

Field	Data type	Required	Comments
First name	String	Y	Must be editable.
Last name	String	Y	Must be editable.
Mobile number	Numeric	N	Must be editable.
Father/husband's name	String	N
Gender	Dropdown	N	Values: Male, female, others.
Date of birth	Date	N
Email	String	Y	Add a common email for all users to support OTP-based authorisation-recovery email.
Correspondence address	String	Y

Administrative Information

Field	Data type	Required	Comments
Role	MDMS	Y	Users must have the ability to assign multiple ones.
Employment type	Dropdown	Y	Values: Permanent, temporary, daily wage, contractual (defined during impel in MDMS).
Date of employment	Date	N
Designation	String	N
Department	Dropdown	Y	Users must be assigned to a department during onboarding. For example, NMCP, polio programmes, etc.
Status	Boolean	Y	To specify if the user is active or deactivated in the system.

Campaign Details

Field	Data type	Data validation	Required	Comments
Campaign name	Dropdown		Y	Users must have the ability to assign multiple campaigns. Users can exist in the system without being assigned to a campaign.
Administrative area	Boolean	Must be able to select multiple ones.	C(Y)	(Mandatory if a campaign is assigned). To specify if the user is currently assigned to one or many administrative areas.
Assigned from date	Date	Project start and end dates must take precedence over these dates.	N
Assigned till date	Date	Project start and end dates must take precedence over these dates.	N

User Deactivation

Field	Data type	Data validation	Required	Comments
Reason for deactivation	Dropdown		Y	The list of reasons must be configurable during impel.
Date of deactivation	Date	Auto-populate from the system date, but it must be editable.	Y
Order number	String		N
Upload documents	Media		N
Remarks	String		N

Risk/Limitations

Due to the existing system design, the system cannot support the following use cases:

1. If a user has role R1 in the LLIN campaign, access to boundaries 1 and 2, and has a different role R2 in the IRS campaign with access to the same boundary (1 and 2). This is due to the HRMS limitation that a role is a common attribute assigned to the user and will remain constant across all campaign assignments.

2. Scope for future versions: Linking of role attributes to project assignments <Needs further discussion>

3. Workaround: During user creation, assign both R1 and R2 roles to the user along with IRS and LLIN campaign assignments.

i. Cons: Users will be able to perform actions associated with both roles in both campaigns assigned.

4. However, this is an edge case and needs to be resolved in future versions of the product. No risk is anticipated for the v1 and v1.1 rollout in Mozambique.

Out of scope

1. UI for performing bulk user management actions: CRUD (Will be supported via backend APIs).

2. Collecting additional user details such as payment, education, skills, language, and previous work experience (to be picked up in v2 for supporting training, staffing, attendance, and payment use cases in the future).

Design

Find the mock-ups below:

Landing Page

A landing page must be available to the user to access all available modules.

User Management Module

Search Page

A user must be able to search for an existing employee using search parameters (name, mobile number, username).

Create New Employee

Users must be able to create new users by providing the following details. Refer to the section on specifications.

Assign Campaigns

View and Edit Screen

Allow users to reset the password. Allow users to edit existing information or add information to an existing employee. Refer to the section on specifications for validations and conditions.

Deactivate Employee Screen

Refer to the section on specifications for validations and conditions.