The articles in this section include the following:

Table of contents

Background

Target Audience

Assumptions and Validations

Process flow

Solution - Quick Win

Out of scope

Specifications

Design

Background

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

Target Audience

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).

Assumptions and Validations

Role-Action Mapping

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.

Statuses in the Workflow

Process Flow

Solution

Complaints: For mobile users

1. 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)

1. All complaints raised by any system user in the system must first be routed to the helpdesk.

2. Helpdesk user must be able to filter, sort, and search complaints.

3. 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 example, assign to programme managers, supervisors, etc).

4. Helpdesk 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 the complaints

3. Username

Risk/Limitations

Addressed in the out-of-ccope section.

Out of Scope

• 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

Specifications

Design

Find the mockups below:

HCM Home screen

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.

Complaints

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.

File Complaint Workflow

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:

1. Name (must be populated if already available in the user’s profile else must be blank).

2. Contact number (must be populated if already available in the user’s profile else must be blank).

3. 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.

Resolving a complaint (Mobile App View)

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.

Confirmation Screen

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.

Metrics to track: (WIP)

The metrics that will be tracked are as follows:

• Complaints registered.

• Complaints resolved.

Table of Contents

Background

Target Audience

Objectives

Assumptions and Validations

Process flow

Specifications

Design

Background

This document describes the need and scope of adding a referral management module within V2.0, explaining the module’s features, specifications, purpose, and functionality. It also provides a descriptive view of the application along with the specification of each element.

In health campaigns, it is very common that beneficiaries show some symptoms against the dose administered, such as fever, body ache, etc., which are not alarming. But in cases where the dose has an adverse effects on the beneficiary and he/she requires medical assistance, the beneficiary is referred to a healthcare facility for treatment. This module helps to track the referral details for a beneficiary and ensure the authenticity of genuine referrals done within the campaign.

Target Audience

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

Objectives

1. Referral Management:

- Enable actors to collect referral details of beneficiaries before as well as after administering the dose.

- Capture details of the referred facility, referring individual, and reasons for referral.

1. Enhance user experience:

- Simplified forms for capturing referral information.

- Ensure authenticity of data:

- Referral details to track the beneficiary and avoid fraudulent referrals by verifying the collected data.

Assumptions and Validations

Process flow

Specifications

Design

Find the mock-ups below:

Refer Beneficiary (Household Card)

When the user clicks on the ‘Open’ button on the beneficiary card or scans a voucher on the search household screen, the household card is opened, which contains the household details.

Based on campaign type, the deliver intervention button is displayed either on each individual’s card or the entire household. For individual-based campaigns, the button appears only on the individual’s card that was searched or scanned.

The user must click on the “Refer Beneficiary” button in case the beneficiary is suffering from any illness and needs medical treatment before delivering the intervention.

Refer Beneficiary (Adverse Events)

Referral Details

After clicking on “Refer Beneficiary”, the referral details screen appears where the user provides information for referral.

The date and administrative unit fields are auto-populated by the system and are non-editable.

The referred by field automatically captures the team code from the user’s profile but can be edited. The user must select a facility where the beneficiary is being referred to.

Search Facilities

When the user clicks on the search icon in the “Referred to” field, a pop-up screen appears, which contains the list of all the health facilities within the campaign. The user can search for any facility by typing within the search box, and it will display the related search results.

When the user selects any facility, the screen collapses and the value is displayed within the field. The user must click again on the search icon if he/she wants to change the facility.

Reason For Referral

Users must select the reason for referring the beneficiary. Reasons are basically the adverse events observed in a beneficiary and the user can select multiple values from the list. Users can describe the beneficiary's health condition in the referral comments field.

Was the delivery successful

The user must provide the details for whether the delivery was successful or not.

If the user selects ‘No’, an additional field must appear asking for the reason of non-delivery. The dropdown must have the reasons that are configured in the MDMS.

After selecting the response, the user must click on the ‘Submit’ button, which opens the acknowledgement screen stating that the delivery is successful, and the user can go back to the search household screen.

Table of Contents

Background

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.

Target Audience

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).

Objectives (of this release)

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 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.

1. 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

Risk/Limitations

• Addressed in the out-of-scope section.

Out of scope

• Search and view beneficiaries on the map based on proximity.

• Filter and sort beneficiaries.

• Generate QR codes for registered beneficiaries.

• Edit the user profile.

Specifications

Design

Find the mock-ups below:

HCM Home screen

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.

Hamburger Menu

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.

Edit Profile

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.

Project Selection

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.

Location

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.

Help Button

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.

Search Households

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:

1. No results are displayed.

2. The search results displayed do not match.

Both cases are discussed further. The ‘Back’ button on the top will navigate to the home screen.

Case 1: No match found

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.

Case 2: Results do not match

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.

Household Dropdown (for household-level campaigns)

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.

Household Dropdown (for individual-level campaigns)

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.

Location

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.

Household Details

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.

Individual Details

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:

1. If the user enters the date of birth, the age field is disabled. The system captures the exact date entered.

2. If the user has entered the age, the date of birth field must remain editable (date of birth takes precedence over age).

3. 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).

4. 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.

5. 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).

Confirmation 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.

Acknowledgement Screen

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.

Household Card (for a household-level campaign)

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.

Household Card (for an individual-level campaign)

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.

Delete 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.

Reason for Deletion (household)

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 the 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.

Individual-Level Actions

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.

Edit Individual Details

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).

Delete Individual

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.

Reason for Deletion (Individual)

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.

Sync

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.

Sync Status

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:

1. Retry: If the user wants to retry syncing the data.

2. Close: Clicking on this will navigate the user back to the home screen.

Reports

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.

Call Supervisor

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.

Success Criteria

1. Various actors involved in the process will be able to collect, track, and analyse the data for beneficiaries registered using a bug-free platform.

2. 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.

3. Digital records will result in maximum coverage with fewer chances of households being missed during a certain campaign.

Metrics to Track

The following metrics will be tracked:

1. Households registered.

2. Individuals registered in households.

Table of Contents

Background

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

About

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

Problem

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

• A high volume of user accounts is required initially.

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

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

Impact

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

Target Audience

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

Assumptions and Validations

Role-Action Mapping

1. System administrator

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

- CRUD other system administrator accounts.

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

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

1. Supervisors

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

b. Assign/update/delete role assignments.

c. Assign/update/delete campaign assignments.

1. Helpdesk user

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

b. Assign/update/delete role assignments.

c. Assign/update/delete campaign assignments.

Process Flow

Solution

High-level scope:

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

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

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

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

- Bulk user deactivation will be done after the campaign.

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

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

A campaign can be any collection where:

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

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

• Example:

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

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

User Accounts

There are two types of user accounts that need to be created during a health campaign:

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

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

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

1. 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.

2. The system administrator must have the ability to provide user management permissions to other roles as required (example, supervisors, managers).

3. 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 the system admin).

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

c. Edit user details.

d. Deactivate users.

e. Edit campaign assignment.

1. 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 programme, once created.

1. 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 the LLIN campaign in Mozambique).

1. If the programme wants to track the performance of each frontline worker individually, then the product SOP recommends that each mobile app user should have their 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.

Specifications

Login Credentials (Must have)

Demographic Information

Administrative Information

Campaign Details

User Deactivation

Risk/Limitations

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

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

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

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

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

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

Out of scope

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

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

Design

Find the mock-ups below:

Landing Page

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

User Management Module

Search Page

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

Create New Employee

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

Assign Campaigns

View and Edit Screen

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

Deactivate Employee Screen

Refer to the section on specifications for validations and conditions.

Table of Contents

Background

Target Audience

Objectives (of this release)

Assumptions and Validations

Solution - Quick Win

Out of scope

Design

Background

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

Target Audience

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).

Objectives (of this release)

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. 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.

1. 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.

Assumptions and Validations

Role-Action Mapping

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.

Solution

1. Context: Supervisors are required to perform random or scheduled inspections and record observations of the inspection activity in the supervision checklists.

2. The number of checklists and the number of questions in the checklist will be based on the programme’s requirements.

3. 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 programme's 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. Localisation 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).

1. 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.

2. 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 programme 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.

1. 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.

2. The latitude/longitude coordinates must be captured at the backend and linked to the checklist submission.

3. Users must be able to save a checklist as a draft (good to have).

4. 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.

1. Dashboard requirements:

a. Indicators to track the aggregates of all checklists filled:

i. Filter based on administrative area.

1. 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.

Risk/Limitations

Addressed in the out of scope section.

Out of scope

• Deleting a filled checklist on UI.

• Editing a checklist on UI.

Design

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.

View My Checklists

Filling a Checklist

Confirmation Screen

Acknowledgement Screen

Table of Contents

Background

Target Audience

Objectives (of this release)

Assumptions and Validations

Process flow

Specifications

Design

Background

This document describes the need and scope of proximity based search included within V2.0, explaining the module’s features, specifications, purpose, and functionality. It also provides the descriptive view of the application along with the specification of each element.

Proximity-based search is a feature implemented in HCM to enhance user experiences and provide relevant results based on last recorded location. It leverages location data to enable the field team to identify a nearby household.

Proximity-based search is designed to address the need for location-specific information and improve the user’s convenience by presenting results that are geographically relevant.

Target Audience

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.

Objectives (of this release)

1. Improve accessibility:

- By enabling actors to easily find nearby households and deliver bed nets accordingly.

1. Enhance user experience:

- Proximity-based search offers a seamless and intuitive way to find the nearby households based on the latitude, longitude, saved by the application.

1. Enhance offline functionality:

- Aims to address scenarios where internet connectivity may be limited or unavailable.

Assumptions and Validations

Process flow

Specifications

Design

Find the mock-ups below:

HCM Home Screen

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 zero registrations. The action buttons related to the beneficiary 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 a walkthrough of the elements on that screen.

On the top right, the administrative area assigned to the user is displayed which is based on the level of hierarchy.

The hamburger button on the top left corner covers some other actions mentioned further.

Search Households

During implementation, there must be an option to configure the default view of the search households screen. There are two views:

1. Show results only after searching (current v1 state).

2. Display results (list of households) based on LIFO (last registered households displayed first).

For #2:

The Search Household screen displays the number of households registered along with the number of bed nets delivered in that administrative area. It also displays a comprehensive list of beneficiaries who have been registered within the system. The list is sorted in descending order, with the most recently registered beneficiary appearing at the top, allowing for easy access to the latest beneficiary information. This feature ensures that users can quickly identify and review the most recent additions to the beneficiary database, enabling efficient tracking and management of beneficiary records.

The “Search Near Me” checkbox will allow users to conveniently view the list of beneficiaries who are in close proximity to the user’s last recorded latitude/longitude coordinates.

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. The ‘Back’ button on the top will navigate to the home screen.

Search Near Me

The "Search Near Me" checkbox enables users to find beneficiaries in close proximity to their latitude/longitude location (search radius must be configurable).

1. When the checkbox is enabled, users can access a list of beneficiaries located near their current GPS coordinates - latitude and longitude coordinates - allowing them to identify nearby households.

2. When sorting the list by proximity, prioritise showing the households that have not been visited yet. If two households are at the same distance, display the visited households afterwards. This ensures efficient organisation and visibility of household visits based on the status.

3. When the "Search Near Me" box is unchecked, the list of beneficiaries should revert back to its original state, displaying the initial list of beneficiaries. This allows users to easily reset the search and view all beneficiaries without proximity filtering.

4. The distance must be displayed dynamically, that is, if the distance is less than 1 km, display it in metres, and for distances above 1 km, display it in kilometres.

Table of Contents

Background

Target Audience

Objectives (of this release)

Assumptions and Validations

Out of Scope

Specifications

Design

Success Criteria

Metrics to Track

Background

This document describes the need and scope of a digital platform for health campaigns, explaining the product’s features, specifications, purpose, and functionality. It also provides 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.

Target Audience

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)

1. 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.

1. Enable the 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.

Assumptions and Validations

Risk/Limitations

Addressed in the out-of-scope section.

Out of scope

• 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.

Specifications

Design

Find the mock-ups below:

HCM Home screen

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.

Hamburger Menu

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.

Edit Profile

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.

Project Selection

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.

Location

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.

Help Button

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.

Search Households

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:

1. No results are displayed.

2. 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:

1. The list of households will appear as a search result. The user can then open the household card and proceed with service delivery.

2. 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 beneficiary registration PRD).

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.

Household Card (For an individual-level campaign)

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.

Deliver Intervention

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.

Confirmation screen

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.

Acknowledgement 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.

Delete Service Delivery Details

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.

Sync

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.

Sync Status

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:

1. Retry: If the user wants to retry syncing the data.

2. Close: Clicking on this will navigate the user back to the home screen.

Reports

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.

Call Supervisor

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.

Success Criteria

• 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.

Metrics to track

The following metrics will be tracked:

• Households delivered.

• Households not delivered.

• Households rejected.

• Team progress.

Table of Contents

Background

Target Audience

Objectives (of this release)

Assumptions and Validations

Process flow

Specifications

Design

Background

This document describes the need and scope of including the 2D code scanning feature within V2.0, explaining the module’s features, specifications, purpose, and functionality. It also provides the descriptive view of the application along with the specification of each element.

Target Audience

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.

Objectives (of this release)

1. Improve accessibility:

- By enabling actors to execute the registration and delivery process efficiently through the use of scanners.

1. Enhance User Experience:

- Code scanning capability provides better user experience by auto populating the data, thus reducing the time and effort.

1. Prevent duplication of records and monitor resources:

- Linking beneficiaries to their respective codes and reusing it while registering a new beneficiary or distributing resources.

- Monitoring the quantity of stock distributed by scanning the code available on the stock.

Assumptions and Validations

Process flow

High level requirements

1. The HCM flutter mobile application must support an in-app 1D and 2D code scanner launched within the application to scan codes. The following use cases have been identified for implementation in various contexts.

2. QR code scanning: Use case to scan registration or delivery vouchers to be used to redeem benefits (bed nets) by households.

   1. Registration vouchers are provided to beneficiaries during household registration/ individual registration and act as a temporary ID for the campaign.

   2. FLW teams can scan these vouchers to retrieve beneficiary data to provide a benefit or use for longitudinal tracking in a multi-round campaign.

3. Bar codes and 2D Data matrix: Use case for supply chain (Global fund traceNet project) to track the individual bed net that is distributed to the household.

   1. Bar code or data matrix on the nets are linked to the delivery record created against the household to track which net was distributed (coupled with GPS and timestamp, this data verifies that the exact net was delivered to which beneficiary, when and where).

4. The application must support scanning from live camera input and from existing images from gallery.

5. The bar code module must support features like flashlight control (in case of low light settings).

6. In case the code is not scannable, an option to skip or manually enter the barcode must be supported.

7. Haptic feedback must be provided, either in the form of vibration or sound, upon successful scan for user’s understanding (Good to have).

8. Toast message upon successful scan must be displayed.

9. App must audit and log all the scanned barcodes and sync this data along with the HCM transaction created (possible changes to the API in case of use case #b above).

10. The scanned code must be associated with the HCM app transaction calling the bar code function. For example:

    1. For registration voucher, the code scanned must be linked to the individual/household head as their temporary ID.

    2. For resource delivery verification, the scanned code must be linked to the service delivery transaction.

11. Upon scanning a code, on the search household screen, the application must use the code scanned to search and retrieve details of beneficiaries.

12. The scanner must enable batch scanning.

    1. Ability to assign multiple codes to one transaction.

    2. Use case: If the distributor needs to deliver 3 bed nets to a household, the scanner must be able so scan 3 bar codes or data matrixes and link to the delivery transaction.

    3. Scanner must be able to identify duplicate scans- If the user scans multiple items and repeats one, then the scanner must show a message that the item is already scanned.

    4. Scanner must take the “quantity distributed” for resources from the delivery intervention screen and allow the user to scan only x number of resources.- Validation.

13. Support landscape and portrait orientations.

14. The application must provide feedback or error messages if barcode scanning fails due to low lighting or camera issues.

Specifications

Design

Find the mock-ups below:

HCM Home Screen

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 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 it, 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 is based on the level of hierarchy. The hamburger button on the top left corner covers some other actions mentioned further.

Search Beneficiary Screen

On this screen, a user can search for a registered beneficiary or register a new one. There are multiple options included to search for a beneficiary: search by name, proximity, and scan a code. The metrics card shows the data for beneficiaries registered and the number of resources delivered, depending on the type of campaign.

Scan Code (Search Beneficiary)

Clicking on the scan button on the search household screen opens a scanner that allows a user to scan the voucher code provided to the beneficiary during registration. The user can also enter the code manually by clicking on the “Enter Beneficiary Code” button, if the device is unable to scan.

Based on the campaign type, the beneficiary card is opened with a set of actions for the scanned beneficiary. The user can close the scanner if needed by clicking on the close button.

Scan Code (Linking Beneficiary)

While creating a beneficiary, the user can link the beneficiary to the voucher card provided during registration by clicking on the “Link Voucher to Individual” button. If the scanner is not able to scan the code, the user can also enter the details manually. Screens for the scanner are same as that for search beneficiary.

On successful scanning, the toast message appears over the individual details screen and the voucher code is displayed. In case the scanned code does not match with the one mentioned in the voucher, the user can click on the edit button and rescan or re-enter the code. The previously scanned value must be overwritten by the latest one (No multiple scanning to be done).

Age Field

The age field must be displayed in months and years on the following screens: beneficiary table on search household screen, beneficiary details screen, and household card, for children below 1 year. On the individual details screen, the age field must have separate fields to capture in years and months. There must be a validation to restrict the user from entering months less than 12. It must show an error message (similar to that for years).

Scan Code (Track Delivery Resource)

While delivering any resource to the beneficiary, the user must scan the code provided on the packaging of the resource. The scanner must be able to identify duplicate scans and must not scan the same voucher multiple times. The user can perform multiple scans at a time, but the number must not exceed the value provided by the user in the “Quantity Distributed” field.

The scanner screen has an expandable card that provides the list of resources scanned. The card displays the count of resources scanned along with the identification number for each scanned resource. If one is unable to scan, the user can enter the codes manually, but after every code, he/she must click on the enter beneficiary code again and repeat the process. The user can remove any resource by the help of the delete button provided against each resource. Once scanned, the user must click on the submit button which brings him back to the deliver intervention screen. The toast message for successful scan is displayed on the screen.

Table of Contents

Background

Target Audience

Objectives (of this release)

Assumptions and Validations

Process flow

Specifications

Design

Background

This document describes the need and scope of adding forms to track adverse events after a dose is administered to a beneficiary within V2.0, explaining the module’s features, specifications, purpose, and functionality. It also provides the descriptive view of the application along with the specification of each element.

While administering the dose to a beneficiary (usually children), there can be instances when the beneficiary shows some symptoms against the dose provided. These adverse events need to be recorded and monitored as it helps to take precautionary measures for further doses as well as in future campaigns for that beneficiary. It is helpful for cases when a beneficiary's situation becomes critical and he/she needs to be referred to a healthcare facility. This is also crucial for resource tracking because in certain campaigns, the beneficiary can be re-administered the dose even after he vomits out the medicine.

Target Audience

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.

Objectives (of this release)

1. Recording adverse events.

2. Enabling actors to record and track the adverse events observed in a beneficiary after administration of the dose.

3. Monitoring the data to plan and decide for upcoming doses during the campaign.

Assumptions and Validations

Process flow

Specifications

Design

Find the mock-ups below:

Deliver Intervention

The user needs to provide the delivery details for the resources delivered to the beneficiary. The screen is configurable depending upon the campaign type and the auto-calculated resources and quantity are displayed and populated in the fields. The user can edit the fields if required to change the resource administered.

Adverse Events

When the user clicks ‘Next’ on the deliver intervention screen, it opens a pop-up that asks: “Did you observe any adverse events?” If the user selects ‘No’, the adverse events screen is skipped, and he/she is directly navigated to the next screen in the flow. If the user selects ‘Yes’, it opens the adverse events form to capture the details. On top the summary of delivered resources is displayed in a tabular form. The list of symptoms must be configurable to include more values if required. It is possible that the beneficiary shows multiple symptoms, thus the user must be able to select multiple values from the list.

If the dose is readministered, then the user must select ‘yes’ and provide the number of times it has been readministered.

The “Refer Beneficiary” button navigates the user to the refer beneficiary flow, in case the beneficiary is critical and requires medical assistance. The ‘Next’ button takes the user to the next screen in the flow.

Table of Contents

Background

Target Audience

Objectives (of this release)

Assumptions and Validations

Process flow

Specifications

Design

Background

This document describes the need and scope of adding a module for tracking resources till the last mile delivery within V2.0, explaining the module’s features, specifications, purpose, and functionality. It also provides the descriptive view of the application along with the specification of each element.

In health campaigns, it is crucial to keep track of the resources delivered to prevent stock mis-handlings and for maximising the coverage. The form helps to track the resource till the last mile delivery, that is, it captures the stock till it reaches the distributor, and the distributor can record the quantity of stock received along with other stock transactions.

Target Audience

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).

Objectives (of this release)

1. Tracking stock till the last mile

2. Capture stock details till the end user to keep a track of the transactions that take place

3. Enable actors to record the stock transactions during a campaign

4. Ensure the safety of stock

5. Keep a track of the stock count and verify from both ends (received versus issued) to prevent the misuse of stocks

Assumptions and Validations

Process flow

Specifications

Design

Find the mock-ups below:

HCM Home Screen

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

• Manage Stock

On 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 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.

Manage Stock

This includes all the stock transactions that can be captured by the distributor.

Transaction Details

The transaction details are captured on this screen. The date and administrative unit fields are auto captured by the system and are non-editable. The team code/identifier is captured from the user profile and it must be editable.

Received Stock Details

The stock related details are captured on this screen. “Select product” is a dropdown field that includes the resource that has been received. “Received from” is a search-based dropdown field, clicking on which navigates the user to the search facility screen that includes the facilities along with ‘Supervisor’ as the value. If the user selects ‘Supervisor’ then he/she must enter the supervisor’s name. The user must enter the quantity received, and if any additional comments are needed, they can be added.

Acknowledgement Screen

Once the user clicks on ‘Submit’, the confirmation pop-up appears. If the user clicks on the ‘Submit’ button, the acknowledgement screen appears and ‘Cancel’ takes the user back to the previous screen.

Transaction Details (Stock Consumed)

Consumed Stock Details

This screen includes all the fields except for the facility field.

Transaction Details (Stock Returned)

Returned Stock Details

Table of Contents

Background

Target Audience

Objectives (of this release)

Assumptions and Validations

Process flow

Specifications

Design

Background

This document describes the need and scope of adding multi-round delivery capability within V2.0, explaining the module’s features, specifications, purpose, and functionality. It also provides a descriptive view of the application along with the specification of each element.

For certain campaigns, especially at the individual levels, the doses are administered in multiple rounds which are referred to as ‘cycles’. Each cycle has multiple doses within them. In such campaigns, the doses are administered by following either of the two strategies: DOT 1 and DOT n, where DOT means Direct Observation of Treatment. In DOT 1 strategy, the distributor provides the first dose of the first cycle, and the remaining doses are given to the caretaker/mother to be given accordingly. The process is repeated for the next cycles. In DOT n, the distributor himself/herself provides each dose to the beneficiary. Thus, the application must be capable of capturing data for multi-round campaigns.

Target Audience

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.

Objectives

1. Support multi-round delivery:

- Enable actors to capture delivery details for multi round campaigns.

- Able to capture details for both types of DOT strategies.

1. Enhance user experience:

- Auto-populate the number of cycles and doses being administered to the beneficiary for the user’s convenience.

- Provide the auto-calculated resource and quantity to be administered for each dose.

- Enable actors to deliver multiple resources based on the campaign.

1. Record past delivery:

- Enable actors to record past delivery details (for DOT 1-based campaigns).

Assumptions and Validations

Process Flow

Specifications

Design

Find the mock-ups below:

Household Card

When the user clicks the ‘Open’ button on the beneficiary card in the search household screen or scans a voucher, the household card is opened, which contains the household details.

Based on the campaign type, the “Deliver Intervention” button is displayed either on each individual’s card or the entire household. For individual based campaigns, the button appears only on the individual’s card that was searched or scanned.

Beneficiary Details

Clicking on the “Deliver Intervention” button opens this screen which has the beneficiary data as well as delivery data if he/she has received any intervention earlier. The user can record past delivery data (if DOT 1 strategy is followed) or simply click on the ‘Next’ button to record current delivery details.

Health Information (PHI Details)

For certain campaigns, the resources delivered are calculated based on the beneficiary’s height, weight, age, or other parameters. This screen captures details of the beneficiary along with a checklist that has health-related questionnaires: Whether the beneficiary is sick and undergoing any treatment, or if he/she is suffering from disease(s).

The form must be configurable to support multiple question types and add questions, if needed. For questions that require specific details, a text field appears when the user selects ‘Yes’. The dropdown list for comorbidities must allow multiple selection.

Deliver Intervention

The user needs to provide the delivery details for the resources delivered to the beneficiary. The screen is configurable depending on the campaign type, and the auto-calculated resources and quantity are displayed and populated in the fields. `The user can edit the fields if he/she needs to change the resource administered.

The “Date of Administration” is non-editable if the user records current delivery details. For past delivery data, the field must be editable with a restriction on the earliest date that can be captured (cannot select the date less than that of previous dose, and if additional time interval is added).

Scan QR Code

Click here to know more.

Adverse Events

When a user clicks on the ‘Next’ button on the “Deliver Intervention” screen, a pop-up appears to check if the user observed any adverse events in the beneficiary. Click here to know more.

Was the delivery successful?

The user must provide the details for whether the delivery was successful or not. If the user selects ‘No’, an additional field must appear asking for the reason of non-delivery.

The dropdown must have the reasons that are configured in the MDMS. After selecting the response, the user must click on the ‘Submit’ button, which opens the acknowledgement screen stating that the delivery was successful. The user can go back to the search household screen or record the next dose, if required.

Table of Contents

Background

Target Audience

Objectives (of this release)

Assumptions and Validations

Process flow

Design

Success Criteria

Background

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.

Target Audience

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.

Objectives (of this release)

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.

Assumptions and Validations

Process flow

Specifications

Design

Find the mockups below:

Home Screen

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.

Hamburger Button

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.

Manage Stocks

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).

Error Popup

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.

Warehouse Details (Stock Receipt)

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.

Received Stock Details

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.

Confirmation Screen

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).

Warehouse Details (Stock Issued)

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.

Issued Stock Details

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.

Warehouse Details (Stock Returned)

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.