Background
Target Audience
Assumptions and Validations
Process Flow
Solution
Out of Scope
Specifications
Design
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.
This document is intended for the engineering and platform (tech team), product management, and implementation teams to agree on the requirements for the Health Campaign Management Platform (HCM).
The ability for supervisors/managers to create and manage users and team assignments for their respective boundaries through the user interface.
The current process for managing users is operationally heavy for the following reasons:
A high volume of user accounts is required initially.
The program does not have the capacity to use backend API’s, and hence would rely on implementation partners (CHAI or eGov). This acts as a blocker as 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).
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 program to take ownership (the solution is not sustainable).
Assumptions and Validations
User account creation
Assumed that the program 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 program 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 no 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.
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.
Supervisors
a. Create, search, update and deactivate user accounts (except system admin).
b. Assign/update/delete role assignments.
c. Assign/update/delete campaign assignments.
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.
High-level scope:
Along with APIs, provide a 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 create/updates/deletes will most likely be done before and during the campaign.
- Bulk user deactivation will be done after the campaign.
The program 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 setup 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 can be set up only at the village level: where village A, village B are two separate campaigns (can be of the same campaign type or different).
There are two types of user accounts that need to be created during a health campaign:
Mobile app users’ accounts: Frontline workers (mostly contractual) who will log in on the phones and submit data into their assigned project. These users must also be able to view mobile reports to track their progress or the progress of their teams.
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.
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.
The system administrator must have the ability to provide user management permissions to other roles as required (example, supervisors, managers).
Any user, who has the permission to manage/create users in the system, must also be able to perform the following actions:
a. Create users (except system admin).
b. Search for existing users - Search parameters: Name, username, etc.
c. Edit user details.
d. Deactivate users.
e. Edit campaign assignment.
The system administrator must be able to create a new user by only specifying the username (credential used to login to the system) and setting the password with an ability to add other demographic information later.
a. The system user must be able to share the list of usernames and passwords with the program, once created.
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 program can decide to create their 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 individual person has submitted the data during analysis (current approach following in LLIN campaign in Mozambique).
i. If the program wants to track the performance of each frontline worker individually, then the product SOP recommends that each mobile app user should have their own username even if they are sharing a device. Since the system will provide reports on the performance/productivity of your mobile app users, If there are multiple mobile users 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.
Username
String
Must be unique and non-editable once set.
Y
The format for creating user names must be configurable.
Password
String
Y
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
String
Y
Add a common email for all users to support OTP-based authorisation-recovery email.
Correspondence address
String
Y
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 programs, etc.
Status
Boolean
Y
To specify if the user is active or deactivated in the system.
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
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
Due to the existing system design, the system cannot support the following use cases:
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.
Scope for future versions: Linking of role attributes to project assignments <Needs further discussion>
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.
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.
UI for performing bulk user management actions: CRUD (Will be supported via backend APIs).
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).
Find the mock-ups below:
A landing page must be available to the user to access all available modules.
A user must be able to search for an existing employee using search parameters (name, mobile number, username).
Users must be able to create new users by providing the following details. Refer to the section on specifications.
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.
Refer to the section on specifications for validations and conditions.
