Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Background
Target Audience
Objectives (of this release)
Assumptions and Validations
Out of Scope
Specifications
Design
Success Criteria
Metrics to Track
This document describes the need and scope of a digital platform for health campaigns, explaining the product’s features, specifications, purpose, and functionality for beneficiary registration. It also provides a descriptive view of the application along with the specification of each element within the flow.
The 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 Platform (HCM).
To enable actors with a digital system to manage and implement health campaign activities.
a. Facilitate FLWs, supervisors, district officers, and other actors to collect and analyse data accurately, along with monitoring registration tasks. Regular progress checks can also be performed at any time and a comparative analysis can be derived at the district levels for different teams in terms of beneficiaries registered.
To increase the adoption of the HCM platform for multiple health campaigns by providing flexibility in the UI and UX as well as product specifications.
a. Emphasis on adopting digital systems by collaborating with several healthcare initiative bodies.
b. Provide scope for future changes and improvements in the upcoming versions of the application.
Assumptions and Validations
Customer persona
The actors using the application are not digitally literate and need training before they can use the application independently.
Device and services
The actors have a smartphone and there should be internet connectivity to enable syncing of data from the mobile application to the server for populating the dashboards.
The actors using the mobile application must sync at least once daily.
Logging into the application needs internet connectivity.
Identifiers for individuals
The type of identifiers and their validations must be configured during implementation. If there is no ID collected during registration, the system will generate a unique ID while persisting the record into the registry.
Registration of households and individuals
A household can be created only if there is at least one individual associated with the household.
Only one member within the household can be marked as the household’s head, which is the first member being registered.
A user will be able to register a new household only after attempting a search (the register button will be disabled until the search is completed).
Peer-to-peer sync
For v1.0, the product will not support peer-to-peer sync, either by directly syncing phones or routing traffic through the server.
Location picker
The user must select at least the highest boundary to proceed with registration and delivery.
Date of birth
The system captures only the date at the backend, irrespective of whether the user enters the date of birth or age.
For date of birth, the system captures the exact date, and for age (eg 23), the date must be 01-01-2000.
The reason why the system captures only the date is that in health campaigns, the approximate age can be used for providing interventions. The exact age is required in periodic campaigns, where an individual’s dosage depends upon his age, gender, height, weight, and other factors. Another reason for capturing the date is that it is easier to update the age for future use cases.
The date of birth must be validated to restrict the users from entering a future date value.
Additional fields
All the non-mandatory fields must be taken care of during implementation. This must be done across all the flows.
Addressed in the out-of-scope section.
Search and view beneficiaries on the map based on proximity.
Filter and sort beneficiaries.
Generate QR codes for registered beneficiaries.
Edit the user profile.
Location picker
Dropdown
Select at least the highest boundary.
Y
The area boundary assigned to a specific user.
Search for a household
String
Search by the household head.
Y
After 2 characters, it will start showing related search results.
Administrative area
String
NA
Y
The administrative boundary of the household. Auto-populated by the system and it is non-editable.
Address line 1
Alphanumeric
Min. length: 2. Max. length: 64.
N
Household address.
Address line 2
Alphanumeric
Min. length: 2. Max. length: 64.
N
Additional information of the address.
Landmark
String
Min. length: 2. Max. length: 64.
N
Additional landmark to help locate the household.
Postal code
String
Min. length: 2. Max. length: 64.
N
Postal code of the house.
Lat
Numeric
Min. value: -90. Max. value: 90.
N
Latitude of the household. It is fetched by the system.
Long
Numeric
Min. value: -180 Max. value: 180.
N
Longgitude of the household. It is fetched by the system.
Date of registration
Date
Cannot be in the future.
N
The date when a new beneficiary is registered. It is fetched by the system and it is non-editable.
Number of members living in the household
Numeric:
Increment/decrement
Min. member: 1 Max. members: 1,000.
Y
The number of members living in a particular household. It is defaulted to 1.
Name of the individual
String
Min. length: 2 Max. length: 200.
Y
The name of the individual belonging to a particular household. It is captured from the search bar and is editable. The first name will be head of the household by default.
ID type
Dropdown
NA
Y
The ID type of the individual.
ID number
Alphanumeric
10-digit ID number.
Y
The ID number of the individual. If the individual does not have an ID, a system-generated ID will be provided.
Date of birth
Date
Cannot be in the future.
Y
The date of birth of the individual.
Age
Numeric
Min. length: 1. Max. length: 64.
Y
The age of the individual. The individual needs to provide either her/his age or date of birth. The date of birth takes precedence over age. If the date of birth is entered, the user must not be able to enter age.
Gender
Dropdown
NA
N
Gender of the individual.
Mobile number
Numeric
Length: 10 digits.
N
Mobile number of the individual if they have a mobile phone.
Reasoon for deletion
Select from the options
NA
Y
Select the reason for deleting the household/individual.
Find the mock-ups below:
After logging into the application, the user lands on this screen which displays the daily performance (number of households registered). The progress bar must reset daily at 00:00 hours and start from 0 registrations.
The action buttons related to the beneficiary are present, which include:
Beneficiaries
Sync Data
Call Supervisor
File Complaint
At the bottom, there is a card that shows how many records are unsynced for the user’s convenience to sync data. If all the records are synced, then the card must say “All records are synced”. The help button is on every screen of the application, clicking on which a user can get a walkthrough of the elements on that screen.
On the top right, the administrative area assigned to the user is displayed, which will be based on the level of hierarchy. The hamburger button on the top left corner covers some other actions mentioned further.
After clicking on the hamburger button, a list of actions appears on the user screen. The top displays the user name and contact number, followed by other options such as the home button, language select, edit profile, projects, and logout. The ‘Edit Profile’ option is not in scope for V1, it needs to be taken in V1.1
If the user clicks on the hamburger button again, it collapses the hamburger menu. The button is available on all screens of the application.
The user can edit his/her name, and phone number, and select the gender. After updating the details, the user needs to click on the save button which opens a prompt stating “saved successfully”.
If the user does not want to make any changes, he/she can click on the back button, which will take them back to the hamburger menu. Not in scope for V1.0, needs to be taken in V1.1.
When a user clicks on the projects option in the hamburger menu, it navigates them to the project selection screen, from where the user can select another project to work on.
Though the automatic sync is triggered by the login action, after selecting another project, the system must now sync the data for the new project, and the same flow must be followed.
For a user assigned multiple boundaries, after logging in, the boundary selection overlay must appear. This forces the user to select a boundary, only after which the user will be able to view the home screen. The user can then change the boundary whenever required from the location picker placed on the top right.
It has dropdown fields to select the boundary, which depends on the hierarchy level of the user. For example, in the case of an FLW, the boundary selection starts from the administrative post. The values in the dropdown are linked to the higher hierarchy and the user cannot select a boundary if the previous field is left blank.
The dropdown must only consist of the boundaries that are assigned to the user, not all the boundaries under a particular hierarchy. For example, if the user is assigned localities 1, 2, and 3, and there are 5 localities in all under admin post 1, then the dropdown must have only 1, 2, and 3 localities.
At least the highest boundary must be selected to enable the select button, which navigates the user to the home screen. For multiple projects, sync needs to download the data only for the selected project.
If the user clicks on the help button, it will give a walkthrough of the entire screen, including the role of each button placed with two buttons:
Skip: If the user wants to skip the walkthrough at any point.
Next: It will proceed to the next action aligned.
The text box appears at the bottom of the button.
When a user clicks on the ‘Beneficiaries’ button, they will be navigated to this screen. It displays the number of households registered along with the number of bednets delivered in that administrative area.
The register button is primarily disabled to ensure that the user performs the search action.
The search bar allows the user to search by the household head’s name and the system provides the search results. The minimum string length to show results is 2 characters and the order of the results will be the last record displayed first. Two cases can be generated:
No results are displayed.
The search results displayed do not match.
Both cases are discussed further. The ‘Back’ button on the top will navigate to the home screen.
If a user is searching for a household and there are no households registered by that name, it will display: “Match not found! Register New Household button to add details”. The register button is enabled to proceed with the household registration. When the user clicks on the “Register New Household” button, it takes them to the “Household Location” screen.
If the user searches for a household by the name Jose, for example, all the household cards by the name Jose will be displayed. The cards will provide details such as the household name, members in the household, service delivery status, administrative area, and a dropdown arrow at the centre.
The open button at the right corner of each card is for the user’s understanding to open the household card. The search results displayed must be 10 at a time followed by pagination for the next 10 results.
At the end of the search results, a query message is displayed stating “Match not found” and the register button is enabled. If the results do not match, the user can click on the register button for household registration. The back button will take them to the home screen.
After the user searches for a household, the search results are displayed with a dropdown arrow. The dropdown has a significant circular area of touch response for the user. When the user clicks on the dropdown, it will expand and display the tabular data of all the members in that particular household. The table is scrollable, both vertically as well as horizontally, but the card dimension of the dropdown must remain fixed to show 5 members.
The table must not display the household head icon ‘H’, as shown on the individual level screen. This will help the user to verify whether it is their household or not. In the beneficiary column, only the first 14 characters will be displayed.
Since there are no separate fields for first name and last name, the cell will count 14 characters, counting space as 1 character. If it is the same household, the user can click on the ‘Open’ button on the card, which will open the household card. The ‘Back’ button will take the user to the home screen.
In this case, a column for delivery status is added to the table. The format for the delivery status must be the same for every screen wherever the status needs to be displayed. The format is check mark+status. The household-level delivery status is omitted in this case.
Household registration begins from this screen. The user needs to provide the location details of the household. The administrative area field must be auto-captured from the boundary selected, which is mandatory, denoted by * and is non-editable. If the user wants to change the area, he/she can click on the location picker on the top, which opens the boundary selection screen.
The system must fetch the lat/long coordinates of the household. If it is unable to detect the coordinates, it will be left blank in the dashboard to avoid errors.
The back button takes the user to the “List of Households” screen. The ‘Next’ button at the bottom takes them to the “Household Details” screen.
The “Date of Registration” is auto-populated by the system, and is non-editable. The user provides the details on the total number of members in a particular household with the help of the increment/decrement buttons on both sides. The field must default to one and validation must be applied, where at least one member should be there in a household for registration.
After providing the numbers, the user clicks on the ‘Next’ button at the bottom of the screen, which will navigate them to the ‘Individual Details’ screen.
In the name field, the system fetches the name from the search action performed on the beneficiaries screen, which is editable. The first individual will be the head of the household by default, denoted by a checkbox below the field. The checkbox must be non-editable as the users are trained in such a way that the first member registered should always be the household head.
The name, ID type, and ID number fields are kept mandatory for data collection. The ID type is a dropdown field where the individual must provide the type of ID they hold if any. The ID types must be configured in the MDMS.
If the individual does not hold any ID, an option for ‘System generated ID’ must be there, which will inform the system to generate an ID for that individual. In “ID Number”, the user needs to enter the individual’s ID number. If the user selects a system-generated ID, then this field must be disabled. The system must capture the ID number when the device is online and sync can take place.
The “Date of birth” is a calendar input field, where the individual’s birth date is entered. If the individual does not know his/her date of birth, there is an option to enter the age. The system captures only the date of birth at the backend, which is described in the two cases below:
If the user enters the date of birth, the age field is disabled. The system captures the exact date entered.
If the user has entered the age, the date of birth field must remain editable (date of birth takes precedence over age).
If age has been entered, the date captured by the system must be the first day of January and the year must be the difference between the current year and age. For example, if the user has entered the age 23, then the date captured must be 01-01-2000 (as of 2023).
During the edit flow, the application user must not see the system-derived date. This means that while creating the record, the user had input age and the system calculated the date of birth as 01-01-XXXX, but during the edit flow, only the data entered by the user while creating the record must be visible to the user.
If the user has entered age (Eg. 23) in the current year, the system must derive the date as 01-01-2000. After a year, during the edit flow, the age displayed must be 24 (incremented by 1 year).
The date of birth field must be validated where the value cannot be in the future, and if a user has entered a future date, then an error message must appear stating the date cannot be in the future. Gender is a dropdown field to select the individual’s gender. The user needs to enter the mobile number of the individual if they have a mobile phone.
At the bottom, there is a ‘Submit’ button, clicking on which the user can register the beneficiary into the system. For every submit action, the system validates the information entered. If the user enters incomplete or incorrect data, clicking on the submit button will show an error message above it, along with the validated message below the field (as shown in the adjacent screen).
When the user clicks on the ‘Submit’ button, a popup appears asking for confirmation. If the user wants to edit any detail, they can click on the ‘Cancel’ button, which will take the user back to the previous screen. If the user clicks on ‘Submit’, the household is registered and the household card is opened.
Once the user clicks on the submit button, the acknowledgement screen appears providing the information that the data has been recorded successfully. When the user clicks on “Back to Search”, he/she must be navigated to the search household screen.
After registering the household, the user can search for the household and open the card. The household name is displayed as household only, to avoid the risk of names that may be longer. There is also an ‘Edit Household’ button for editing household details, which navigates the user to the household location screen.
The service delivery status is present below the household’s name followed by the administrative area and the number of members. There are cards for each member, starting from the household head. The card consists of the member's name, gender, age, and the ‘Edit’ button for individual-level actions. Age will be denoted in years for this version, as for household-level campaigns, age is not a considerable parameter for providing interventions.
For adding new members to the household, there is the ‘Add Member’ button below the member cards, which navigates the user to the ‘Individual Details’ screen. At the bottom, the ‘Deliver Intervention’ button navigates the user to the update delivery screen.
If the intervention is delivered to that household, the second screen will appear. The deliver intervention button must be replaced by the ‘Update Delivery Details’ button in case more interventions are needed to be delivered. The back button on top takes the user to the list of households screen.
If the campaign is at an individual level, the household card appears in a similar format with some changes. The ‘Deliver Intervention’ button is present at the bottom of every member’s card. If the intervention is delivered to a member, it will display ‘Delivered’ below their details on the card and the button will be replaced with ‘Update Delivery Details’. If the intervention is not delivered, it will display “Not Delivered”. The ‘Deliver Intervention’ button in this case navigates the user to the update delivery screen. The back button navigates the user to the search households screen.
Household-Level Actions When the user clicks on the “Edit Household” button, the actions appear on the screen.
Edit Household: The user is navigated to the household location screen followed by household details. In this screen, the ‘Next’ button is now replaced by the ‘Save’ button.
Delete Household: If the user wants to delete the entire household.
After a user clicks on the “Delete Household”’ button, an overlay appears with a message asking whether he/she wants to delete that beneficiary. It has two buttons: Delete: This will delete the beneficiary from the system records. Cancel: if the user does not want to delete the beneficiary, clicking on this button will collapse the overlay.
If a user selects the delete option, it will bring them to this screen, where he/she must select the reason for deleting a particular household. The screen will be the same as that of individual deletion, only the reasons will vary. The reasons may include the household having relocated, the household does not exist, etc. The reasons must be configured in the MDMS.
When a user clicks on the ‘Edit’ button on an individual’s card, an overlay screen appears with the following actions:
Assign as household head: If the user wants to change the head of household, they can select this option and that member will be assigned as household head. The option must be disabled for the household head.
Edit individual details: If the user wants to edit the member’s details. It will navigate them to the individual details screen and the same flow is to be followed.
Delete individual: This option allows the user to delete a particular member. A user must not be able to delete the household head and hence the delete individual button must be disabled if the beneficiary is marked as the head of the household. If the user wants to delete the beneficiary marked as a household head, the user must assign another member in the household as the head and then delete the beneficiary.
When a user clicks on edit individual details, he/she navigates to the individual details screen where he/she can edit the previously entered data. For edit flow, all the fields must be editable at the front end.
For the date of birth and age fields, the date of birth must always be given precedence over age. If the user has entered the date of birth while creating an individual, only that field must be editable, and the age field must be disabled. If the user has entered age, then the age entered must be visible, and the date of birth field must be blank, but editable. If the user wants to enter the exact date of birth, then he/she must be able to enter the value, in which case the age field is disabled (as in create flow).
Clicking on the delete button opens a popup that asks whether the user wants to delete that member. If the user clicks on the delete button, it will proceed further to delete the member. If the user clicks on cancel, it will take him/her back to the household card.
If the member is the household head, a popup should appear stating that deletion cannot happen unless some other member is assigned the household head. If there is only one member in a household, a popup should appear stating that there should be at least one member for creating a household. The user needs to either add another member or delete the entire household.
If the user selects the delete option, it will bring him/her to this screen, where he/she needs to select the reason for deleting a member. The reasons must be configured in the MDMS.
Before going into the field, the user needs to log into the application every day, which will initiate an automatic sync process (mentioned in the user login PRD). For manual sync, there is a ‘Sync Data’ button on the home screen, which allows the user to sync data according to his/her convenience. At the bottom of the screen, there is a card that shows the message “Data unsynced” along with the number of records unsynced.
When the user clicks on the ‘Sync’ button, the sync action starts along with an overlay showing “Sync in Progress” over the home page. The user cannot perform any other action until the sync is complete or there is some error.
Once the data is synced, it will show a popup, stating “Data Synced” along with a ‘Close’ button at the bottom. When the user clicks on close, it navigates him/her to the home screen.
If the data is not synced due to any error, it will show a popup stating “Sync Failed” with two buttons below it:
Retry: If the user wants to retry syncing the data.
Close: Clicking on this will navigate the user back to the home screen.
The reports dashboard provides a tabular and visualised representation of user performance. The reports are not in V1.0 for mobile applications, except for the stock reconciliation. They are generated based on the offline data present in the local device, associated with the user’s login.
If a user selects the ‘Data’ option, it will provide a data-wise report of the campaign. The bar graph shows the day-to-day comparison of registered beneficiaries along with a threshold of the daily target for registration. Below the graph, the table is added which displays the households registered as well as bednets distributed.
In the leaderboard section, the overall number of households registered will be displayed in the form of a milestone. Below that, all the individual users’ performance will be listed separately. The leaderboard option will not be available at the registrar level (field level) but at the field supervisor level.
If the user is facing any challenge and requires an immediate solution, he/she can click on the call supervisor button on the home screen, which will redirect them to their phone’s dial pad with the supervisor’s number auto-filled. By clicking on the ‘Call’ button, the user can contact the supervisor for immediate assistance.
Various actors involved in the process will be able to collect, track, and analyse the data for beneficiaries registered using a bug-free platform.
The supervisors, district officers, and program managers will be able to monitor team performance, which will help them understand the problems and challenges faced by the teams.
Digital records will result in maximum coverage with fewer chances of households being missed during a certain campaign.
The following metrics will be tracked:
Households registered.
Individuals registered in households.
Background
Target Audience
Objectives (of this release)
Assumptions and Validations
Process flow
Design
Success Criteria
This document describes the need and scope of a digital platform for health campaigns, explaining the product’s features, specifications, purpose, and functionality.
The module focuses on the design and features of the user interface of HCM for beneficiary registration and service delivery. It provides a detailed description of the elements and the process flow of the application along with a wireframe model for easier comprehension. The module aims to reduce the risks of data redundancy., besides providing better service delivery tracking and visibility into the services provided for maximum area coverage, and in the quickest time possible.
This document is intended for the engineering and platform (tech teams), product management, and implementation teams to agree on requirements for the Health Campaign Management (HCM) Platform.
1. To enable actors with a digital system to manage and implement health campaign activities.
a. Facilitate FLWs, supervisors, district officers, and other actors to collect and analyse data accurately, along with monitoring the tasks from registration to service delivery. Regular progress checks can be performed at any time and a comparative analysis can be derived at the district levels for different teams.
b. Facilitate better diagnostics with improved access to healthcare interventions for the general public.
2. To increase the adoption of the HCM platform for multiple health campaigns by providing flexibility in the UI and UX, as well as product specifications.
a. Emphasis on adopting digital systems by collaborating with several healthcare initiatives.
b. Provide scope for future changes and improvements in the application.
Specifications
Find the mockups below:
After successful login, a user lands on the home screen of inventory management which consists of the following actions and elements:
Manage Stock
Stock Reconciliation
View Reports
Sync Data
Call Supervisor
File Complaint
There is a location picker on the top right that displays the assigned boundary for the user. The help button provides a walkthrough of the screen to the user. The hamburger button on the top left consists of a few quick actions. The location picker, help button, and hamburger buttons are available on every screen for a user’s convenience.
After clicking on the hamburger button, a list of actions appears on the user screen. On top, it displays the user name and contact number, followed by other options such as the home button, language select, edit profile, projects, and logout. The “Edit Profile” option is not in scope for V1; it needs to be taken in V1.1 If the user clicks on the hamburger button again, it collapses the hamburger menu. The button is available on all screens of the application.
This screen consists of different types of transactions that take place for the inventory. These include:
Stock Receipt
Stock Issued
Stock Returned
Stock Damaged
Stock Loss
Every transaction has a separate card with an arrow button, an icon, and a brief description below the title. Clicking on the arrow button will navigate the user to the warehouse details screen. The back button is located below the hamburger button, which takes the user to the previous screen (In this case, it is the home screen).
If the user is not assigned any warehouse, then an error popup must appear over the warehouse details screen, asking the user to contact the system administrator to assign a warehouse. The user must be able to close the popup and change the administrative area on the warehouse details screen to check if he/she is assigned any warehouse in any other boundary. This must force the screen to load again and check for the warehouse.
When the user clicks on record stock receipt, the warehouse details screen will appear. The latitude/longitude captures the Geo-location of the warehouse which can be fetched with the help of the location icon within the field. It is a mandatory field denoted by *. The warehouse name/ID is a dropdown field which contains the list of warehouses assigned to the project for a particular user. If there is only one warehouse, the field must be auto-populated by the system.
The date of receipt field captures the date of transaction which can be fetched with the help of a calendar icon placed inside the box. The field must be validated, where the date cannot be in the future. If the user puts a future value, it must show an error message stating “date cannot be in future”. The user must select the administrative unit from the dropdown of the administrative unit field. The next button navigates the user to the stock receipt details screen.
The user must provide details of the stock received. The select product field has a dropdown that consists of all the products under a campaign. The user can select from the list the desired product that he has received. The type of transaction is provided to specify whether the stock is being received, issued, or returned.
In the ‘received from’ section, the user needs to select from the dropdown the warehouse from which the stock is being received. The dropdown must contain the list of all the warehouses that are part of the campaign, that is, the list must be of the warehouse assigned to the root project. The list is taken from the facility registry and must be the same for all the transactions. The quantity received field collects the information for how much quantity of stock is being received.
For a pack of a certain number of nets, there is a packing slip attached to the packet which indicates the number of nets within that pack. The user needs to mention the value in the number of nets field.
The total number of packing slips must be mentioned in the following field. The user can add any comments/remarks in the additional comments field. The following - select product, type of transaction, received from, and quantity received fields - are mandatory for this screen. When the user has entered all the details, he must click on the submit button which leads to the confirmation screen whether the record has been created successfully or there are some errors.
When the user clicks on the submit button, he/she lands on this page with the confirmation message “Record created Successfully”. Users can go back to the home screen by clicking on the “Back To Home” button. This screen must appear for every other transaction (issued, returned, damaged, lost, reconciliation).
When the user clicks on record stock issued, the warehouse details screen will appear. The screen is similar to the stock receipt one. The only difference is that instead of the date of receipt, the field is the date of issue. The next button navigates the user to the stock issued details screen.
The user needs to provide details for the stock issued. The select product field acts the same as that for stock receipt. In the destination field, the user needs to select the warehouse where the stock is being sent. The quantity sent field collects the information on how much quantity of stock is being sent. When the user has entered all the details, he must click on the submit button which leads to the confirmation screen whether the record has been created successfully or there are some errors.
When the user clicks on stock returned, the warehouse details screen appears. The fields are similar to that for stock receipt; only the date of receipt label is changed to the date of return. The next button navigates the user to the stock returned details screen.
The user needs to provide details for the stock returned. The “Select product” field acts the same as that for stock receipt. In the “Returned from” field, the user needs to select the warehouse from where the stock has been returned. The “Quantity returned” field collects the information for how much quantity of stock has been returned. When the user has entered all the details, he/she must click on the submit button which leads to the confirmation screen that confirms whether the record has been created successfully or there are some errors.
For the damaged stock, the user must provide the details asked on the screen.
The user needs to provide the details for the damaged stock. There can be two cases for the damaged stock:
If the stock is damaged during transit, then the user must select the warehouse name from where the stock was received.
If the stock is damaged during storage, then the user must select N/A from the dropdown.
The user needs to provide the details for the lost stock.
The user must provide the details for the stock loss.
Stock Reconciliation
When the user clicks on the stock reconciliation button on the home screen, they are navigated to this screen where they need to verify whether the physical count and calculated stock values are the same or not. In the select product field, the user needs to select a product from the dropdown. There are warehouse name and administrative area fields as well, all of which are mandatory. The following details are there:
Date of Reconciliation
Received Stock
Issued Stock
Returned Stock
Damaged Stock
Stock Lost
Stock on Hand- The stock on hand is calculated as incoming stock minus outgoing stock. There is a hint icon for how the stock on hand is calculated. The received and returned stocks will be considered incoming stocks. The issued, damaged and lost stocks will be considered outgoing stocks.
The date of reconciliation is system-generated and non-editable. Other values are calculated based on the data recorded in stock receipts, stock issued, and the stock returned screens. In the manual stock count, the user needs to enter the value for manually counted inventory. If the stock on hand does not match the physical count, then the latter must take precedence, provided the user has submitted the form with a proper reason. In the comments field, the user can add remarks and comments.
When a user clicks on the view reports button on the home screen, he/she is navigated to this page where he/she has the provision to view the following reports:
Stock Received
Stock Issued
Stock Returned
Stock Reconciliation
Users can click on the arrow button placed next to every transaction to open the respective report. The back button will navigate them back to the home screen.
When the user clicks on the “Stock Received” button, the report for stock received appears which provides a tabular representation of the data. The table is scrollable, both vertically and horizontally, to cater to multiple values and columns. The date column is kept frozen and other columns are scrollable. The first column is for the date of the receipt, followed by units received in the second column, and received from (warehouse name) in the third column. The “Back To Home” button is placed at the bottom of the screen which navigates the user back to the home screen.
For the stock reconciliation report, the table consists of the date in the first column and other columns. The “Back To Home” button will navigate users to the home screen.
Various actors involved in the process will be able to collect, track, and analyse the data for beneficiaries registered as well as services delivered to them using a bug-free platform.
The supervisors, district officers, and program managers will be able to monitor the team’s performance which will help them understand the problems and challenges faced by the teams.
This will facilitate the warehouse managers to optimise the inventory management of interventions which will further improve the supply chain and prevent surplus or deficit of stock. This includes stock receipts, issues, returns, and lateral movements of the stock.
Digital records will result in maximum coverage with fewer chances of households being missed during a certain campaign.
Background
Target Audience
Objectives (of this release)
Assumptions and Validations
Solution - Quick Win
Out of scope
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 requirements for the Health Campaign Management Platform (HCM).
To enable actors with a digital system to manage and implement health campaign activities.
a. Facilitate FLWs, supervisors, district officers, and other actors to collect and analyze data accurately, along with monitoring the tasks from registration to service delivery. Also, regular progress checks can be performed at any time and a comparative analysis can be derived at the district levels for different teams.
b. Facilitate better diagnostics with improved access to healthcare interventions for the general public.
To enable more and more adoption of the HCM platform for multiple health campaigns by providing flexibility in the UI and UX as well as product specifications.
a. Emphasis on adopting digital systems by collaborating with several healthcare initiative bodies.
b. Provide scope for future changes and improvements in the application.
System Administrator:
a. Create, search, edit and delete checklists.
b. Assign checklists to projects.
c. Edit/delete filled checklists.
Supervisors:
a. View assigned checklists.
b. Fill assigned checklists.
Field Supervisor:
a. View assigned checklists.
b. Fill assigned checklists.
Context: Supervisors are required to perform random or scheduled inspections and record observations of the inspection activity in the supervision checklists.
The number of checklists and the number of questions in the checklist will be based on the program’s requirements.
The system administrator must have the ability to create supervision checklists.
a. Checklists are forms with questions.
b. Current scope:
i. Ability to create/edit a questionnaire with yes/no responses: Questions and alert messages must be configurable as per the program requirements.
ii. Ability to insert validations/conditions on the questions present in the checklist. The use case to consider for v1: If the user selects “No” as a response to a particular question, the user must be able to see an information tip on the checklist displaying the corrective action to be taken and must also be able to enter a justification behind selecting ‘No.’
iii. Marking a question as mandatory or optional (Validations are applicable on all questions irrespective of whether the question is mandatory or not).
iv. Localization support is required as checklists would be required in the local language:
v. Support for the following question types required:
a. Yes/No answers
b. Short answer type
c. Long answer type
d. Multiple answers type
e. Checkbox answer type
f. Date answer type
g. Time answer type
h. Lat/Long coordinates– Must have for v1
i. Media - Good to have
vi. The system admin must be able to view all filled-in checklists and be able to edit or delete the submitted checklists (via backend, No UI).
Ability to assign checklists to particular roles: Not all checklists may be required by all supervisors. For example, a provincial supervisor may be responsible for inspecting X while a district supervisor may be responsible for performing X and Y.
a. One checklist can be mapped to multiple roles b. Users must be able to view and fill the checklists that are assigned to their assigned roles.
Users must be able to view all previously submitted checklists:
a. Good to have: Inform users if the checklist submission is due.
b. Good to have: A user must be able to view whether a particular checklist was filled or not, when it was filled, how many times it was filled (as per the program SOP, users are required to fill the checklists x number of times during the campaign).
c. The same checklist may be filled out multiple times during the campaign.
The date of checklist submission must be tracked and the frequency of each checklist submission (linked to the user) must be recorded for reporting purposes.
The latitude/longitude coordinates must be captured at the backend and linked to the checklist submission.
Users must be able to save a checklist as a draft (good to have).
Users must be able to view and fill checklists even when offline and sync the filled checklists once internet connectivity is available.
a. Sync down and Sync up support required.
Dashboard requirements:
a. Indicators to track the aggregates of all checklists filled:
i. Filter based on administrative area.
Reports:
a. Users must be able to view a report on the response trend for each question within a checklist.
b. Indicators to track the aggregates of each checklists filled:
i. Filter based on role.
Addressed in the out of scope section.
Out of scope
Deleting a filled checklist on UI.
Editing a checklist on UI.
Find the mock-ups below:
HCM Homescreen
After logging into the application, the user lands on this screen which displays daily performance (number of households registered). The progress bar must reset daily at 00:00 hours and start from 0 registrations. The action buttons related to the beneficiary are present which include:
Beneficiaries
View Reports
Sync Data
Call Supervisor
File Complaint
At the bottom, there is a card that shows how many records are unsynced for the user’s convenience to sync data. If all the records are synced, then the card must say, “All records are synced.”
The help button is on every screen of the application, and by clicking on it a user can get the walkthrough of the elements on that screen.
On the top right, the administrative area assigned to the user is displayed which will be based on the level of hierarchy. The hamburger button on the top left corner covers some other actions mentioned further.
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
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.
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.
Background
Target Audience
Objectives (of this release)
Assumptions and Validations
Out of Scope
Specifications
Design
Success Criteria
Metrics to Track
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 an overview of the application.
The module aims to reduce the risks of data redundancy, provide better service delivery tracking and visibility of the services provided for maximum area coverage in the quickest time possible. It focuses on the design and features of the user interface of the Health Campaign Management (HCM) Platform for service delivery to households or individuals. The document also describes the elements and the process flow of the application along with a wireframe model for easy comprehension.
The document is intended for the engineering and platform (tech teams), product management, and implementation teams to agree on the requirements for the platform.
Objectives (of this release)
Enabling actors with a digital system to manage and implement health campaign activities.
Facilitate FLWs, supervisors, district officers, and other actors to collect and analyse data accurately, along with monitoring the tasks from registration to service delivery. Regular progress checks can be performed at any time and a comparative analysis can be derived at the district levels for different teams.
Facilitate better diagnostics with improved access to healthcare interventions for the general public.
Enabling adoption of the HCM platform for multiple health campaigns by providing flexibility in the UI and UX as well as product specifications.
Emphasis on adopting digital systems by collaborating with several healthcare bodies.
Provide scope for future changes and improvements in the application.
Addressed in the out-of-scope section.
Search and view beneficiaries on the map based on proximity.
Filter and sort beneficiaries.
Generate QR codes for registered beneficiaries.
View payments due for services delivered.
Find the mock ups below:
After logging into the application, the user lands on this screen which displays daily performance (the number of households registered). The progress bar must reset daily at 00:00 hours and start from 0 registration. The action buttons related to the beneficiary are present, which include:
Beneficiaries
View Reports
Sync Data
Call Supervisor
File Complaint
At the bottom, there is a card that shows how many records are unsynced for the user’s convenience to sync data. If all the records are synced, then the card must say, “All records are synced”.
The help button is on every screen of the application. By clicking on this button, a user can get a walkthrough of the elements on that screen. On the top right, the administrative area assigned to the user is displayed which will be based on the level of hierarchy. The hamburger button on the top left corner covers other actions.
After clicking on the hamburger button, a list of actions appears on the user screen. On top, it displays the user name and contact number, followed by other options such as the home button, language select, edit profile, projects, and logout. The “Edit Profile” option is not in scope for V1, it needs to be taken in V1.1.
If the user clicks on the hamburger button again, it collapses the hamburger menu. The button is available on all screens of the application.
The user can edit his/her name, phone number, and select the gender. After updating the details, the user needs to click on the save button which opens a prompt stating “saved successfully”.
If the user does not want to make any changes, he/she can click on the back button which will take him/her back to the hamburger menu. This is not in scope for V1.0; it needs to be taken up in V1.1.
When a user clicks on the projects option in the hamburger menu, it navigates them to the project selection screen from where the user can select another project to work on.
Though the automatic sync is triggered by the login action, after selecting another project, the system must now sync the data for the new project, and the same flow must be followed.
For a user assigned multiple boundaries, after logging in, the boundary selection overlay must appear. This forces the user to select a boundary only after which the user can view the home screen. The user can then change the boundary whenever required from the location picker placed at the top right. It has dropdown fields to select the boundary, which depends upon the hierarchy level of the user. For an FLW, the boundary selection starts from the administrative post. The values in the dropdown are linked to the higher hierarchy and the user cannot select a boundary if the previous field is left blank.
The dropdown must only consist of the boundaries which are assigned to the user, not all the boundaries under a particular hierarchy. For example, if the user is assigned localities 1, 2, and 3, and there are a total of 5 localities under admin post 1, then the dropdown must have only 1, 2, and 3 localities. The highest boundary must at least be selected to enable the select button which navigates the user to the home screen. For multiple projects, the sync needs to download the data only for the selected project.
If the user clicks on the help button, it will give a walkthrough of the entire screen, including the role of each button placed with two buttons:
Skip: If the user wants to skip the walkthrough at any point.
Next: It will proceed to the next action aligned.
The text box appears at the bottom of the button.
When a user clicks on the ‘Beneficiaries’ button, he/she will be navigated to this screen. It displays the number of households registered along with the number of bednets delivered in that administrative area. The register button is primarily disabled to ensure that the user performs the search action.
The search bar allows the user to search by the household head’s name, and the system provides the search results. The minimum string length to show results is 2 characters and the order of the results will be the last record displayed first.
Two cases can be generated:
No results are displayed.
The search results displayed do not match.
Both cases are discussed further. The ‘Back’ button on the top will navigate to the home screen.
When the user searches for a household, there can be two outcomes:
The list of households will appear as a search result. The user can then open the household card and proceed with service delivery.
Household Card (For a household-level campaign)
After registering the household, a user can search for the household and open the card. The household name is displayed as household to avoid the risk of names that may be longer. There is an “Edit Household” button for editing the household details which navigates the user to the household location screen. Below the household’s name, the service delivery status is present followed by the administrative area and the number of members.
There are cards for each member, starting from the household head. The card consists of the member's name, gender, age, and the ‘Edit’ button for individual-level actions. Age will be denoted in years for this version. This is because, for household-level campaigns, age is not a considerable parameter to provide interventions.
For adding new members to the household, there is an “Add Member” button below the member cards, which navigates the user to the “Individual Details” screen. At the bottom, the “Deliver Intervention” button navigates the user to the update delivery screen.
If the intervention is delivered to that household, a second screen will appear. The deliver intervention button must be replaced by the ‘Update Delivery Details’ button if more interventions are needed to be delivered. The back button at the top takes the user to the list of households screen.
In the case of an individual-level campaign, the household card appears in a similar format with some changes. The “Deliver Intervention” button is present at the bottom of every member’s card. If the intervention is delivered to a member, it will display ‘delivered’ below their details on the card, and the button will be replaced with “Update Delivery Details”. If the intervention is not delivered, it will display “not delivered”.
The deliver intervention button on the individual cards navigates the user to the update delivery screen. The back button navigates the user to the search households screen.
The summary of the household is displayed for preview on this screen. At the top, the “Date of Registration” is displayed, followed by the household head’s details, and the number of members in that household.
The “Number of Resources For Delivery” must be automatically calculated by the system based on the value entered in the number of household members, including the household head. For the LLIN campaign, the auto-calculation formula to calculate the number of bednets is in the ratio 1:1.8, that is, 1 bednet for 1.8 members with a maximum cap of 3 bednets per household. For example, if the member count is 7, the calculated value must be 3. The “Resource delivered” field consists of all the possible resources that can be delivered in a particular project. If there is only one resource to be delivered, then the field must be auto-filled by the system.
In the “Quantity distributed” field, the user can decide how many bednets need to be delivered to that household against the value generated by the system. The auto-calculation of the quantity must be hard-coded and can be made configurable in later versions. The user can increase or decrease the count through the ‘+’ or ‘-’ buttons, respectively. The field is mandatory and must be defaulted to 1, but can be reduced to 0 to cater to situations where the household receives no intervention due to stock-out.
The user can add a delivery comment if the service is not delivered due to some reason or situation, in the “Delivery Comment” field, which is a dropdown field with a list of possible reasons. The reasons must be configured in the MDMS. After reviewing the details, the user can click on the submit button which will save details of the household in the system. The confirmation screen appears after the details are validated.
After submitting the details, a pop-up window appears, asking the user to review the details before submitting.
If the user clicks on the ‘Submit’ button, the data will be submitted and the next screen will appear.
If the user clicks on the ‘Cancel’ button, the popup will close and the user will be taken back to the “Deliver Intervention’ screen.
When the user clicks on submit, this screen appears, confirming to the user that his/her data has been recorded successfully. Below the message, there is a “Back to Search” button which navigates the user to the search households screen for household-level campaigns. The search bar must be blank and previous results must not be displayed. For individual-level campaigns, the user will land on the household card screen.
The front end must not have the capability to delete any delivery details to avoid any misuse of this function. The backend must be able to delete any delivery record if needed.
Before going into the field, the user needs to log into the application daily, which will initiate an automatic sync process mentioned in the user login PRD. For manual sync, there is a “Sync Data” button on the home screen which allows the user to sync data according to their convenience. At the bottom of the screen, there is a card that shows the message “Data Unsynced” along with the number of records unsynced.
When the user clicks on the ‘Sync’ button, the sync action starts along with an overlay showing “Sync in Progress” over the home page. The user cannot perform any other action until the sync is complete or there is some error.
Once the data is synced, a pop-up comes up stating “Data Synced” along with a ‘Close’ button. When the user clicks on this button, it navigates them to the home screen.
If the data did not sync, a popup comes up, stating “Sync Failed” with two buttons below it:
Retry: If the user wants to retry syncing the data.
Close: Clicking on this will navigate the user back to the home screen.
The reports dashboard provides a tabular and visualised representation of user performance. They are generated based on the offline data present in the local device, associated with the user’s login. If a user selects the ‘Data’ option, it will provide a data-wise report of the campaign.
The bar graph shows the day-to-day comparison of registered beneficiaries along with a threshold of the daily target for registration. The table, which is added below the graph, displays the households registered as well as bednets distributed.
In the ‘Leaderboard’ section, the overall number of households registered will be displayed in the form of a milestone. Below that, all the individual users’ performance will be listed separately. The leaderboard option will not be available at the registrar level (field level) but at the field supervisor level.
If the user is facing any challenge and requires immediate solutions, they can click on the “Call Supervisor” button on the home screen. It will redirect them to their phone’s dial pad with the supervisor’s number auto-filled. By clicking on the ‘Call’ button, the user can contact the supervisor for immediate assistance.
Various actors involved in the process will be able to collect, track, and analyse data for the services delivered to them using a bug-free platform.
The supervisors, district officers, and program managers will be able to monitor the team’s performance which will help them understand the problems and challenges faced by the teams.
Digital records will result in maximum coverage with fewer chances of households being missed during a certain campaign.
The following metrics will be tracked:
Households delivered.
Households not delivered.
Households rejected.
Team progress.
The articles in this section include the following:
No results appear. In this case, the user needs to register the household first, so that he/she can deliver the intervention. (Note: Refer to the PRD).
Customer persona
Device and services
Contact numbers
Product details
Multiple product details cannot be captured within the same form in any transaction. A user needs to fill separate forms for each product.
Dropdown fields
If the dropdown consists of only one value, then the field must be auto-populated. In the warehouse details screen, there is a search field that must contain only those values which are assigned to the project.
In the received stock details screen, the list must contain all the warehouses along with ‘N/A’ value.
Additional/Non-mandatory fields
All the additional and non-mandatory fields across all the flows must be taken care of during implementation.
Latitude/ Longitude
Numeric
NA
Y
The geographical coordinates of the house/household. It is captured by the system at the backend.
Warehouse name/ID
Search text
NA
Y
The warehouse name/ID where the transaction is taking place. The search field must contain the values assigned to the project.
Date of receipt
Date
Cannot be in the future
Y
The date when a receipt was created. It is system-generated and non-editable.
Administrative unit
String
NA
Y
The area boundary assigned to a specific user. It is captured from the location picker and is non-editable.
Select product
Dropdown
NA
Y
This describes the type of resources needed.
Received from
Search text
NA
Y
The warehouse name from where the stock is received. The list must consist of all the warehouses, irrespective of the boundary and the distribution team value on top. This applies to every transaction.
Waybill number
Numeric
NA
N
The unique packing slip number.
Number of nets indicated on the waybill
Numeric
NA
N
The total number of bed net counts indicated on the waybill.
Quantity received
Numeric
NA
Y
The total number of bed nets received.
Type of transport
Dropdown
NA
N
The type of transport which is used for delivery.
Comments
String
NA
N
Additional comments for the transaction.
Vehicle number
String
NA
N
Vehicle number
Date of issue
Date
Cannot be in the future
Y
The date when the stock is being issued. It is system-generated and non-editable.Search text
Destination
Search text
NA
Y
The warehouse name where the stock is being sent.
Quantity sent
Numeric
NA
Y
The total number of bed nets sent.
Return date
Date
Cannot be in the future
Y
The date when the stock is being returned. It is system-generated and non-editable.
Returned from
Search text
NA
Y
The warehouse from where the stock is being returned.
Quantity returned
Numeric
NA
Y
The date of filing the damage. It is auto-captured by the system.
Damage date
Date
Cannot be in the future
Y
The date of filing the damage. It is auto-captured by the system.
Damaged during
Dropdown
NA
Y
Select from the dropdown when the stock was damaged.
Received from
Search text
NA
Y
The warehouse from where the stock was received. If the stock is damaged in the same warehouse (storage), then select ‘NA’.
Quantity damaged
Numeric
NA
Y
The quantity of stock that has been damaged.
Loss date
Date
Cannot be in the future
Y
The date of filing the loss. It is auto-captured by the system.
Lost during
Dropdown
NA
Y
Select from the dropdown when the stock was lost.
Received from
Search text
NA
Y
The warehouse from where the stock was received. If the stock is lost in the same warehouse (storage), then select ‘NA’.
Quantity lost
Numeric
NA
Y
The count of stock lost.
Warehouse
Dropdown
NA
Y
Select the warehouse for reconciliation.
Select product
Dropdown
NA
Y
Select the product for reconciliation.
Manual stock count
Numeric
NA
Y
Manual count of the stock.
Comments
String
NA
N
If needed, comments can be manually added.
Filling a checklist
Assumed that supervisors will record the checklist during or after they have performed the inspection.
There is no requirement to backdate a checklist or make changes to responses after a checklist has been submitted.
All checklists will be completed in one go and there is no requirement to submit an incomplete checklist as a draft.
Creating checklists
Questions types supported would be:
- Yes/No answers
- Short answer type
- Long answer type
- Multiple answers type
- Checkbox answer type
- Date answer type
- Time answer type
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.
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
Customer persona
The actors using the application are not digitally literate and need training before they can use the application independently.
Device and services
The actors have a smartphone and there should be internet connectivity to enable syncing of data from the mobile application to the server for populating the dashboards.
The actors using the mobile application must sync at least once daily.
Logging into the application needs internet connectivity.
Deliver intervention
The user will be able to add delivery details only after registering a household.
The option to deliver an intervention must be provided either to the household (in case of a household-based campaign) or to an individual (for an individual-based campaign) and must be configured during system setup.
Peer-to-peer sync
For v1.0, the product will not support peer-to-peer sync, either by directly syncing phones or routing traffic through the server.
Location picker
The user must select at least the highest boundary to proceed with the registration and delivery.
Additional fields
All the non-mandatory fields must be taken care of during implementation. This must be done across all the flows.
Dropdown
If the field contains only one value, then it must be auto-populated by the system.
Location picker
Dropdown
Select at least the highest boundary.
Y
The area boundary assigned to a specific user.
Search for a household
String
Search by the household head.
Y
After two characters, it will start showing related search results.
Resource delivered
Dropdown
NA
Y
Resource to be delivered in the campaign.
Quantity distributed
Numeric; increment/ decrement
NA
Y
Quantity of the resources distributed. It is defaulted to 1, but can be reduced to 0.
Delivery comment
Dropdown
NA
N
Select any comment/reason from the dropdown.
System administrator
Define campaign type (project type).
Create campaign(s) (projects).
Create products.
Create product variants.
Assign product variants as campaign resources.
Create roles and map to actions.
Create users: Map to role and boundary (boundary mapping to be confirmed).
Define boundaries.
Map users to campaigns.
Define MDMS configurations (including project type).
Create localisation.
Registrar
Frontline worker (FLW) who is responsible for registering households. The registrar also shares awareness messages (SBCC).
Create new household.
Create new individual.
Map individuals to households.
Assign household/individual as a beneficiary of a campaign.
Read, update and delete for all actions mentioned above.
View offline reports.
Distributor
Frontline worker (FLW) who is responsible for registering households and updating service delivery details against registered households. The registrar also shares awareness messages (SBCC).
Create new household.
Create new individual.
Map individuals to households.
Assign household/individual as a beneficiary of a campaign.
Update service delivery against the beneficiary (household/ individual).
Read, update and delete for all actions mentioned above.
View offline reports.
Field supervisor
Responsible to monitoring the field teams. This user is also responsible for training the FLW teams, monitoring the field team's progress during campaign execution, managing stocks at the community warehouse, and performing random inspections during campaign execution.
National supervisor
Supervisors are responsible for overseeing the campaign operations, conduct random and scheduled inspections, fill supervision checklists, support field supervisors to tackle operational issues under their jurisdictions, and train users on campaign SOP and digital tools.
Provincial supervisor
Supervisors are responsible for overseeing the campaign operations, conduct random and scheduled inspections, fill supervision checklists, support field supervisors to tackle operational issues under their jurisdictions, and train users on campaign SOP and digital tools.
District supervisor
Supervisors are responsible for overseeing the campaign operations, conduct random and scheduled inspections, fill supervision checklists, support field supervisors to tackle operational issues under their jurisdictions, and train users on campaign SOP and digital tools.
Warehouse manager
Record stock transactions: Create receipt, issues, returns.
View stock reconciliation (system calculated).
Submit reconciliation form.
View offline reports for inventory reconciliation.
Program manager
These users consume the data collected and shared by the FLW, and take decisions based on the data present. These users must have access to the dashboard with the default view of the data belonging to their jurisdiction and a level below. For example, a provincial manager must be able to view the aggregated data from the entire province as well as the data for individual districts by logging into the system.
Employee
Already present in HRMS.
Background
Target Audience
Assumptions and Validations
Process flow
Solution - Quick Win
Out of scope
Specifications
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 teams), product management, and implementation teams to agree on requirements for the Health Campaign Management Platform (HCM).
Logging complaints
Not all complaints will be logged using the complaints module. Users may prefer raising complaints on WhatsApp groups/calls, and may not be registered in the system.
Complaints are most likely to be logged by users on behalf of other users (Most common use case: Supervisors raising complaints on behalf of users
Resolving complaints
There is a support helpdesk set up by the program which will receive all complaints raised by system users.
The support helpdesk must be responsible for reviewing all the complaints in the inbox
Depending on the complaint, the helpdesk can either resolve, reject or assign the complaint to the respective actor
Helpdesk users may create complaints on the user’s behalf, which are received over call/WhatsApp messages.
Registrar: Create, view, update and cancel complaints.
Field Supervisor:
a. Create, view, update, and cancel complaints.
b. Resolve complaints, re-assign complaints back to the helpdesk, and reject complaints.
Supervisor:
a. Create, view, update, and cancel complaints.
b. Resolve complaints, re-assign complaints back to the helpdesk, and reject complaints.
Helpdesk user:
a. Create, view, update, and cancel complaints.
b. Resolve complaints, assign complaints, and reject complaints.
Submitted (TBD depending on design approach)
Status when a complaint is submitted but hasn’t been received by the helpdesk (to support offline use case).
Pending Assignment
Pending Assignment
Status when the complaint has been received by the helpdesk (in the event of a completely online system), the pending assignment must be the first status in the workflow.
Resolved, Rejected, Assigned
Resolved
Status when the complaint has been addressed and closed successfully.
NA
Rejected
Status when the complaint is found to be invalid and rejected.
NA
Assigned To < >
Status when the complaint is assigned by the helpdesk to other roles in the workflow.
Resolved, Rejected. The possible status will depend on the workflow configured during implementation.
Cancelled
Status, when the user decided to delete the complaint, created.
NA
Creating a new complaint:
Any campaign staff (with access to the complaints module) must be able to create a complaint using the mobile app for themselves or on behalf of other users.
Users can only create complaints for users in the same boundary hierarchy.
2. Viewing “My Complaints”:
Users must be able to view the complaints created by themselves in the mobile app and the web portal.
Users must be able to filter, sort, and search complaints.
Helpdesk View: (Web app and mobile responsive app)
All complaints raised by any system user in the system must first be routed to the helpdesk.
Helpdesk user must be able to filter, sort, and search complaints.
The helpdesk user must review all complaints received in the helpdesk’s inbox and perform one of the following actions:
Resolve: For complaints that can be resolved by the L1 support helpdesk, the helpdesk user must be able to view the details mentioned in the complaints, mark them as “Resolved” and add resolution details.
Reject: If the helpdesk user determines a complaint to be false, irrelevant, or invalid, the user must be able to mark the complaint as “Rejected” and give proper justification for rejecting the complaint.
Assign: For complaints that cannot be resolved by the L1 support helpdesk, the helpdesk user must be able to select the appropriate role and assign the complaint. Once the helpdesk user assigns a complaint, the status must be shown as “Assigned."
a. Workflow to be set up during implementation.
b. The core product would offer the following workflow: Create→ Submitted to L1 Helpdesk→ Assign to L2 support.
c. The workflow must be configurable to support additions of more workflow states: (For eg. Assign to: Program Managers, Supervisors, etc).
4. Help desk users must be able to create new complaints. The new complaint created must be visible in the helpdesk user’s inbox to take action on (Use case: Helpdesk user receives a complaint over call and creates a complaint in the system for tracking on the user’s behalf).
5. Report Generation: (Good to have for v1 since already covered in the dashboard)
a. Helpdesk performance report: Report generated on the following parameters:
1. Time range
2. Status of complaints
3. User name
Addressed in the Out of Scope section.
Re-opening of complaints
Auto-escalation of complaints
Auto-routing of complaints
Sharing feedback on complaint resolution
Notification to users on status change
SLA tracking
Complaint type
Dropdown
Only one complaint type must be selected.
Y
Values to be configured.
If type is “Other”: Display text box to enter type.
Date of complaint
Date
System fetches the current date.
Y
Must be non-editable (no action required by user).
Administrative area
String dropdown
Y
For mobile view: Admin area must be populated based on value set in the location picker For Web view: Select from list of assigned projects/ boundaries.
Complaint raised for
Boolean
Y
Options available: Self and other.
Complainant’s name
String
If “self”: Name must be populated as entered in the user’s profile.
Y
If “Name” is blank in the user’s profile, the text field must be empty.
Complainant’s contact number
Numeric
If “self”: Number must be populated as entered in the user’s profile.
Y
If “Number” is blank in the user’s profile, the text field must be empty.
Supervisor’s name
String
N
Supervisor’s contact number
Numeric
N
Complaint description
String
Max limit of description: TBD
Y
Upload photo
Media
Max size of media: TBD
N
Complaint number
String
Y
Unique ID generated by the system.
Reason for rejection
Dropdown
Y
Must be configurable during impel.
Assign to
Dropdown
Mandatory if action taken to assign.
C(Y)
Must be configurable during impel depending on the workflow. Default value: Assign to L2.
Find the mockups below:
After logging into the application, the user lands on this screen which displays daily performance (number of households registered). The progress bar must reset daily at 00:00 hours and start from 0 registrations. The action buttons related to the beneficiary are present, which include:
Beneficiaries
View reports
Sync data
Call supervisor
Complaints
At the bottom, there is a card that shows how many records are unsynced for the user’s convenience to sync data. The help button is on every screen of the application. By clicking on it, a user can get the walkthrough of the elements on that screen.
On the top right, the administrative area assigned to the user is displayed, which will be based on the level of hierarchy. The hamburger button on the top left corner covers some other actions mentioned further.
When the user clicks on the complaints, she is navigated to the “My Complaints” screen, which consists of two actions:
File a complaint (primary action): Clicking on this must open the complaint type screen.
View previously logged complaints.
Complaint Type
When the user clicks on file a complaint, the complaint type screen appears. The user must select the type of complaint from the list, which must be configurable (to be configured during implementation as per program requirements).
There is a ‘Next’ button at the bottom of the screen, clicking on which, the user is navigated to the complaint details screen.
Complaint Details
Once the user has selected the type of complaint and clicked on ‘Next’, this screen appears, where they need to provide the complaint details.
The date field is auto-captured by the system, which must be non-editable.
The administrative area is also auto-captured but it is editable. It is editable in case the user is creating the complaint on someone’s behalf. The dropdown displays a list of boundaries that are assigned to the user.
The user needs to select whether she is raising a complaint for herself or on behalf of another user.
If the user wants to raise a complaint for herself, then she must provide the following details:
Name (must be populated if already available in the user’s profile else must be blank).
Contact number (must be populated if already available in the user’s profile else must be blank).
Supervisor’s name and contact number.
If the complaint is raised on behalf of another user, then her details must be captured in the above fields. The user has the option to upload images describing the issue along with a text-based description. If the user wants to change the type of complaint, they can click on the ‘Back’ button and return to the previous screen.
After filling in all the details, the user needs to click on the ‘Submit’ button to file the complaint.
Confirmation Screen
When the user clicks on the submit button after providing all the complaint details, the confirmation screen appears, which provides information on whether the complaint has been submitted or not.
If the complaint has been submitted, then it must show the message to sync the data for generating the complaint number. There must be a back to home button below the message. When the user clicks on it, she must be navigated to the home screen.
If the complaint has not been submitted, then there must be two buttons available; Retry and Back to Home.
Helpdesk
The L1 support helpdesk must be the first point in the complaint management workflow. All complaints created must be first routed to the helpdesk, after which the helpdesk may take an appropriate action (mentioned below).
The helpdesk user must be able to do the following :
View List of complaints in the inbox
File a new complaint
Open a complaint from the inbox and
View complaints status
Resolve a complaint
Reject a complaint
Assign to other roles
The inbox view for other workflow states must be similar and must be able to view complaints assigned to their respective inbox. The user must also have the option to assign the complaint back to the L1 support helpdesk by selecting the value in the “Assign To” field. The users must be able to view complaints that have been assigned to their role. For example, the L1 helpdesk user must not be able to view complaints assigned to the L2 helpdesk and vice versa.
Filters The user can apply filters in multiple parameters as follows:
Complaint Type: The user can select the complaint type from the dropdown
Administrative Area: The area of complaint.
Status: Refer to the list of statuses detailed above.
A button to clean all filters must be available at the bottom of the page. An “Apply Filter” button must be available to set the filters and route the user to the inbox and display the filtered complaints.
Search By
A user must be able to search for one or more complaints by using the following search parameters (must support passing multiple search parameters):
Complaint Number
Mobile Number
Administrative Area
After providing the appropriate search parameters, the user must click on the “Search” button located at the bottom of the screen and must be routed to the inbox which displays the search-appropriate search results.
Complaint Summary
A summary screen must be displayed when the user clicks on the ‘Open’ button located on the complaints card.
Actions
The “Take Action” button at the bottom of the screen must open a pop-up displaying all possible actions that the user can take. The actions available to address the complaint are as follows:
Resolve Complaint
Assign to P2
Reject Complaint
Close
The close button collapses the overlay and takes the user back to the complaints summary screen.
Assign Complaint
If the user wants to assign any project to P2, she must click on the assign button which opens this screen. The date of assigning the complaint is user input which can be filled in with the help of the calendar icon within the field.
In the "assigned to" field, the user needs to select the person to whom she wants to assign that complaint. There is an additional comments field in which the user can provide any remarks if she wants. The user can attach any supporting documents such as photos, documents, etc.
At the bottom, there is a cancel button which takes the user back to the complaint summary screen, and an assign button which assigns the complaint to the selected person.
Confirmation Screen
Landing Page (Common page)
Helpdesk (Desktop View)
When the user clicks on complaints on the home screen, then this screen must appear. On the top left, there is an option to file a new complaint, view reports. Besides, there are search fields for different parameters, such as complaint number and mobile number, and the search button to execute the search action. There is a clear search button below the search one if the user wants to clear the search parameters.
Below the new complaint and reports buttons, there are filters available to apply over the results. The filter parameters are the same as that for the mobile view.
The complaints are displayed in a horizontal format with the same values for mobile view. The user can click on the entire area of a particular complaint.
At the bottom, there are forward, backward, first page, and last page arrow buttons along with the page number information as displayed on the screen.
Complaint Details
When the user clicks on a complaint, the details screen appears which provides the entire information of that complaint. The summary includes the same information mentioned in the card along with the additional comments/remarks, and photos provided by the complainant.
There is a "Take Action" button at the bottom. When the user clicks on it, the actions appear above the button as displayed on the screen. The actions include resolve complaint, assign to P2, and reject complaint. If the user clicks on any blank area on the screen, the actions collapse.
Resolve Complaint
If the complaint has been resolved, then the user must click on the "Resolve Complaint" button which opens this screen. There is an "Additional Comments" field in which the user can provide any remarks if he wants. At the bottom, there is a submit button that updates the complaint status as resolved.
Reject Complaint
If the user has rejected any complaint, then she needs to select the reason for rejection from the dropdown. There is an additional comments field in which the user can provide any remarks if he wants. At the bottom, there is a submit button that updates the complaint status as rejected.
Assign to P2
If the user wants to assign any project to P2, she must click on the assign button which opens this screen. The date of assigning the complaint is user input which can be filled in with the help of the calendar icon within the field.
In the assigned to field, the user needs to select the person to whom she wants to assign that complaint.
There is an additional comments field in which the user can provide any remarks if he wants. The user can attach any supporting documents such as photos, documents, etc.
At the bottom, there is a cancel button which takes the user back to the complaints screen, and an assign button which assigns the complaint to the selected person.
New Complaint
When the user clicks on the “New Complaint” button on the complaints screen, then this screen appears. The details captured are the same as that entered by the complainant. When the details are entered, the user needs to click on the submit button which opens the confirmation window over the same screen. If the user clicks on the cancel button, then she is navigated back to the complaints screen
Confirmation Screen
When the user clicks on the submit button, the system confirms whether the complaint has been submitted successfully or not. There is a back to home button placed on both screens, clicking on which will navigate the user to the home screen of the helpdesk.
The metrics that will be tracked are as follows:
Complaints registered.
Complaints resolved.
Background
Target Audience
Objectives (of this release)
Assumptions and Validations
Process Flow
Out of scope
Specifications
Design
Success Criteria
Metrics to track
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.
The module focuses on the design and features of the user interface of HCM for beneficiary registration and service delivery. It provides a detailed description of the elements and the process flow of the application along with a wireframe model for easier comprehension. The module also aims to reduce the risks of data redundancy, provide better service delivery tracking, and visibility of the services provided for maximum coverage in the quickest time possible
The document is intended for the engineering and platform (tech teams), product management, and implementation teams to agree on requirements for the Health Campaign Management (HCM) Platform.
1. To enable actors with a digital system to manage and implement health campaign activities.
a. Facilitate FLWs, supervisors, district officers, and other actors to collect and analyse data accurately, along with monitoring the tasks from registration to service delivery. Regular progress checks can be performed at any time and a comparative analysis can be derived at the district levels for different teams.
b. Facilitate better diagnostics with improved access to healthcare interventions for the general public.
2. To enhance the adoption of the HCM platform for multiple health campaigns by providing flexibility in the UI and UX, and product specifications.
a. Emphasis on adopting digital systems by collaborating with healthcare bodies.
b. Provide scope for future changes and improvements in the application.
Customer persona
The actors using the application are not digitally literate and need training before being able to use the application independently.
Device and services
The actors have a smartphone and there should be internet connectivity to enable syncing of data from the mobile. application to the server for populating the dashboards.
The actors using the mobile application must sync at least once daily.
Logging into the application needs internet connectivity
Peer-to-peer sync
For v1.0, the product will not support peer-to-peer sync, either by directly syncing phones or routing traffic through the server.
User login
The system-generated user ID and password must be provided to the user for login.
The user needs to login daily before going to the field and log out after coming back from the field.
Addressed in the out of scope section.
Password reset for the users.
User capability of resetting the password if they forget it.
User capability of creating own user ID for login.
Specifications
Language
Choose from the given options
Need to select one language
Y
Select the language for the application.
User ID
String
NA
Y
The unique system-generated ID.
Password
Alphanumeric
NA
Y
The unique system-generated password
New password
Alphanumeric
NA
Y
After the first login, a user needs to create a new password (V1.1).
Confirm password
Alphanumeric
NA
Y
Confirm the new password (V1.1).
Project
Choose from the given options
Need to select one language
Y
This is the project selection page for users assigned multiple projects.
Find the mock-ups below:
When the user opens the application, it asks them to first select the language. The selected language is highlighted in orange color. Once the user selects a language, he/she must click on the ‘Continue’ button which opens the login page.
The user will be provided a unique system-generated ID and password manually for first-time login. After logging in, the user is taken to the password reset page where they need to enter a new password of their choice. The password reset is not in scope for V1.0. If a user enters an incorrect username, it should show an error message below the field saying “username does not match”. For an incorrect password, it should show the message “incorrect password” below the password field.
If an existing user does not remember his/her password, they must click on “Forgot Password”. This will open a popup asking the user to contact the administrator. The ‘OK’ button will collapse the popup.
After the user logs in for the first time, a screen appears where he/she needs to create a new password. There are two fields, “Enter new password” and “Confirm password”, with the eye button present in both.
After entering and reviewing the new password, the user clicks on the submit button which opens a screen with the message “New password created successfully” along with a “Back to Login” button below the text. Clicking on this button will take the user back to the login page. The password reset flow is not in scope for V1.0.
If the user is assigned to multiple projects, they need to select a particular project on this page by clicking on the arrow in front of each project name. Once the user has selected a project, it will open the application’s home page. After selecting a project, the system must download the data for the selected project only. For single-project users, the sync action takes place directly after the login action. There can be multiple cases for projects assigned to a user:
If the user is assigned 0 projects, an overlay must appear saying “Please contact the system administrator for a project” after logging in, and the user must log out of the application.
If the user is assigned multiple projects as mentioned above.
If the user has been assigned a project but later the project has been unassigned. In this case, if the user logs in and selects that project, an error message must appear stating “the project is not assigned to you, please select another project”. When the user clicks on the ‘OK’ button, he/she must be navigated to the updated project selection screen which must not display the unassigned project.
After every login action, the system will automatically sync the data with the system. Since the user will log in only at the start of the day and before going into the field, there must be stable internet connectivity for the device to perform this process. A “Sync in Progress” window will appear on the screen and the user cannot perform any other action until the process is complete.
The overlay will appear over the previous screen. For users assigned to multiple projects, the overlay appears over the project selection screen when the user selects one project from the list. For single-project users, the overlay must appear over the login page.
Once the data is synced, it will show a popup that the data is successfully synced, with a ‘Close’ button at the bottom. When the user clicks on this button, it will navigate him/her to the homepage. These overlays also appear over the previous screens.
If the data is not synced due to an error, it will show a popup stating “Sync Failed” with two buttons below it:
Retry: If the user wants to retry syncing the data. This will open the sync in progress window.
Close: Clicking on this will navigate the user back to the login page and he/she is required to log in again.
Various actors involved in the process will be able to collect, track, and analyse the data for beneficiaries registered as well as services delivered to them using a bug-free platform.
The supervisors, district officers, and program managers will be able to monitor the team’s performance which will help them understand the problems and challenges faced.
Enable warehouse managers to optimise the inventory management of interventions which will further improve the supply chain and prevent surplus or deficit of stock. This includes stock receipts, issues, returns, and lateral movements of the stock.
Digital records will result in maximum coverage with less chances of households being missed during a campaign.
The following metrics that will be tracked:
Number of logins by a user.
User ID and password of the users.
Number of password reset requests.
If the complaint has been assigned successfully, then the following screen must appear.
A landing page must be available to the user to access all available modules.
Confirmation Screen
If the complaint has been assigned successfully, then the following screen must appear. If the complaint could not be assigned, then the text must say, “Complaint Not Assigned.”