Functional Specifications

Campaign Type Setup

Name of the field	Description	Mandatory or optional	Input	Validation	Need data from program/state
Campaign type name	Name of the campaign type. For example, LLIN 2022, IRS 2023.	Mandatory	User		Yes
Code	Unique code for the campaign type.	Mandatory	User		Yes
Disease group	Disease(s) targeted by the campaign. For example, malaria, polio.	Mandatory	User		Yes
Beneficiary type	Specify beneficiaries for the campaign. For example, household, individual, structure.	Mandatory	User		Yes
Eligibility criteria	Specify the criteria to determine if beneficiaries are eligible for the campaign. For example, universal campaign, age-based, gender-based, etc.	Mandatory	User		Yes
Task Procedure [ ]	Capture the details regarding the tasks to be carried out as a part of the campaign. For example, details regarding drug administration/resource distribution, that is, 1 bed net for 2 individuals, 1 tablet for individuals under the age of 5, etc.	Mandatory	User		Yes
Delivery mode	The way in which the campaign intervention will be delivered. For example, fixed, mobile, door-to-door.	Mandatory	User		Yes
Campaign product [ ]	When does the campaign start? It is set up by the national programme manager.	Mandatory	User		Yes
Product type	The type of product being used. For example, drug, spray, vaccine, bed net, IEC material.	Mandatory	User		Yes
Product name	Name of the product being used. For example, Ivermectin, Paracetamol, etc.	Mandatory	User		Yes
Product manufacturer	Name of the manufacturer. For example, Merck, Johnson & Johnson, etc.	Mandatory	User		Yes
Product variant	Capture details about the product variants and the SKU's being used. For example, Para 200 mg.			Ensure that the product is created before product variants and that the SKU's are defined. The system must not allow the creation of a product variant without a parent product.	Yes
SKU	The stock keeping unit code of the product. For example, Para 200 mg and Para 250 mg.	Mandatory	User	There must be at least one SKU assigned to a product: For a product with only 1 variant, it will be product "Bed net", with SKU "Bed net".	Yes
Variant	Capture the variant of the products. Products can vary based on shape, size, colour, or other characteristics. For example, Para 200 mg, pack of 5 tablets, Para 250 mg, pack of 10 tablets.	Mandatory	User		Yes
Base unit variant	Capture details if the variant is the base unit used for record-keeping of the product's inventory. It is useful to filter variants applicable for tasks within a project. For example, base unit for bed net is an individual bed net or a base of 50 nets.	Mandatory	User		Yes

Campaign Setup

Name of the field	Description	Mandatory	Input	Validation	Comments	Need data from program/state
Address		Mandatory	User			Yes
Door number	House number or door number.	O	User
Latitude	Latitude of the address.	O	System
Longitude	Longitude	O	System
Location accuracy	Accuracy of the address, latitude and longitude, in metres.	O	System
Type	Type of address: permanent, correspondence, other.	R	User
Address Line 1	Apartment, block, street of the address.	O	User
Address Line 2	Locality, area, zone, ward of the address.	O	User
Landmark	Additional landmark to help locate the address.	O
City	City of the address. This can be represented by the tenant ID itself.	R	User
Pincode	Pin code of the address.	R	User		Indian pin codes will usually be all numbers.
Building name	Name of the building.	O	User
Street	Street name.	O	User
Locality
Start date	Campaign start date.	Mandatory	User			Yes
End date	Campaign end date.	Mandatory	User			Yes
Targets					Targets will be provided after the micro-planning exercise	Yes
Beneficiary type		Mandatory	User			Yes
Baseline	The total number of individuals/ households.	Mandatory	User			Yes
Target number
Department	Project department	Mandatory	User			Yes
Description	Description of the project.	Mandatory	User			Yes
Setup tasks to be carried out as part of the campaign
Tasks
Resources [ ]	Array of resources that are a part of the campaign.
Task resources
Delivery comment	Capture comments regarding the delivery of campaign resources.	Mandatory	User		The final list of reasons to be given by the state/programme during impel	Yes
Status	Status of the task. For example, delivered, not delivered, partial delivery, refused, insufficient, etc.	Mandatory	User		The final list of tasks' status to be given by the state/program during impel.	Yes

Inventory

Name of the field	Description	Mandatory	Input	Data type	Minimum length	Maximum length	Validation	Comments	Need data from program/state
	Stock details
Product variant ID	The product variant that is being transferred.	Mandatory	User	String	2	64			No
Quantity	The number, or quantity, or the count of units of the product variant that are being transacted.	Mandatory	User	Integer				Outputs from the micro-plan.	Yes
Reference ID	The reference entity for which the stock transfer is taking place.	Mandatory	User	String					No
Reference ID type	The entity type that the reference ID refers to. For example, 'Project'.	Mandatory	User	String	2	64	String		No
Transaction type	The kind of transaction that is taking place: Received, dispatched.	Mandatory	User	String					No
Transaction reason	The status of the transaction: Received, returned, loss.	Mandatory	User	String					No
Transacting party ID	The ID of the party from/to which the product variant stock is being transferred.	Mandatory	User	String	2	64			No
Transacting party type	The type of entity that the transacting party ID refers to. For example, 'Warehouse'.	Mandatory	User	String	2	64		The list of warehouses/facilities and their type to be provided by the program/state during impel.	No
	Stock reconciliation
Physical count	The count of units of the product variant as a result of a physical count.	Mandatory	User	Integer					No
Calculated count	The count of units of the product variant that is calculated from the stock movements.	Mandatory	User	Integer					No
	Facility details
Facility ID	The ID of the facility where the stock of the product variant is being transferred.	Mandatory	System	String	2	64		List of warehouses/facilities and their type to be provided by the programme/state during impel.	No
Facility name	The administration name of the facility.	Mandatory	User	String	2	2000			Yes
Is it permanent?	Whether the facility is permanent or not.	Mandatory	User	Boolean					Yes
Usage	The purpose of the facility: Storage warehouse, medical facility, sewage treatment plant.	Mandatory	User	Dropdown					Yes
Storage capacity	Physical storage capacity of the facility in cubic metres.	Optional	User	Numeric					Yes
Address		Mandatory	User	String

Boundary Hierarchy

Name of the field	Description	Mandatory	Input	Data type	Minimum length	Maximum length	Need data from program/state
Serial number	Sequence number for the list.
Boundary hierarchy type	The meaningful name to define a group of boundaries defined to perform one function.	Mandatory	MDMS	String	2	256	Yes
Code	Code is used to identify a certain classification of the type of boundary hierarchy.	Mandatory	MDMS	String	2	64	Yes
Description		Mandatory	MDMS	String	2	256	Yes

Beneficiary

Name of the field	Description	Mandatory	Input	Data type	Minimum length	Maximum length	Validation	Comments	Need input from program/state
	Household details
ID	Unique system generated GUID.	Mandatory	System	String	2	64			No
Client reference ID	Unique client generated GUID.	Mandatory	Client generated	String	2	64			No
Household ID	The ID of the household.	Mandatory	User/system	String	2	64			No
Member count	The total number of individuals in a household.	Mandatory	User	Numeric	1	1000		A household can be created only when it has at least 1 individual assigned to the household.
Individual ID	The ID of the individual	Mandatory	User/system	String	2	64
	Individual details
ID	Unique system generated GUID.	Mandatory	System	String	2	64			No
Client reference ID	Unique client generated GUID.	Mandatory	Client generated	String	2	64			No
Name of the individual	Name of the individual being registered as the given name, family name, and other name.	Mandatory	User	String	2	200			No
Head of the household	Capture if the registered individual is also the head of the household.	Mandatory	User	Boolean					No
Type of ID	Capture type of ID.	Mandatory	User	Array				The list of IDs to be given by the programme/state during impel. If no forms of ID are allowed, then a system generated ID is to be selected for the ID type.
Identity number	Capture ID number belonging to the beneficiary.	Mandatory	User	String	2	64	If the individual has no forms of ID, then a unique system generated ID must be assigned.	Validations for specific ID types to be built during impel depending on the list of acceptable IDs.
Date of birth	Date of birth in DD/MM/YYYY format.	Optional	User	String			The DoB cannot be in the future. Error Message: DoB cannot be in the future.
Age	The age of the individual.	Optional	User	Integer			If DoB is not known, allow the user to enter his/her age.
Contact number	The mobile number of the registered individual.	Optional	User	Integer				Any validations on mobile numbers to be built during impel as per country-specific requirements.
Gender	Gender of the registered individual.	Optional	User	String				A product allows three types of genders: male, female and other. Adding/deleting from this list to be done during impel in accordance with country-specific requirements.

Boundary Data Specs

Field name	Description	Mandatory	Input	Data type	Minimum length	Maximum length	Validation	Comments	Need data from program/state
Boundary code	This is a code for the sub-classification for a particular boundary. It should be unique across all boundaries defined.	Mandatory	MDMS	String	2	64			Yes
Boundary name* (In English)	The name of the boundary that is being defined in the English language.	Mandatory	MDMS	String	2	256			Yes
Boundary name* (In local language)	The name of the boundary that is being defined in the local language of the state. For example, Portuguese, Hindi, etc.	Mandatory	MDMS	String	2	256			Yes
Parent boundary code*	This is the boundary code of the parent which identifies to which parent the child belongs to.	Mandatory	MDMS	String	2	64			Yes
Boundary type*	The name of the boundary type, that is, ward, zone, etc.	Mandatory	MDMS	String	2	256			Yes
Hierarchy type code*	The code of the boundary hierarchies for which this particular boundary is defined.	Mandatory	MDMS	String	2	64			Yes
Campaign start date	The date when the campaign starts in the respective boundary.	Mandatory	MDMS	Date					Yes
Campaign end date	The date when the campaign is supposed to end in the respective boundary.	Mandatory	MDMS	Date					Yes
Total households	Total households present in the boundary (as per the micro-plan).	Mandatory	MDMS	Numeric					Yes
Targeted households	Total households targeted for the respective boundary (as per the micro-plan).	Mandatory	MDMS	Numeric					Yes
Total individuals	Total individuals present in the boundary (as per the micro-plan).	Mandatory	MDMS	Numeric					Yes
Targeted individuals	Total individuals targeted in the boundary (as per the micro-plan).	Mandatory	MDMS	Numeric					Yes
Bed nets estimated to be delivered	Total bed nets estimated to be delivered in the boundary (as per the micro-plan).	Mandatory	MDMS	Numeric					Yes

Draft System User Setup

Name of the field	Description	Mandatory	Input	Data type	Minimum length	Maximum length	Validation	Comments	Need data from program/state
Name*	The name of the user who wants access to the system.	Mandatory	User	String	2	2000
Mobile No.*	Mobile number of the user.	Mandatory	User	Numeric	2	15	Length validation- Specific to Impel	Current HRMS specs are designed for Indian phone number formats and would need updates.	Yes
Father/Husband's Name*	Name of the user's husband or father.	Mandatory	User	String	2	2000			Yes
Gender*	Gender of the user being registered.	Mandatory	User	String	2	64			Yes
Date of Birth*	Date of birth of the user being registered.	Mandatory	User	Date	10	10		Date of birth cannot be in the future.	Yes
Email	Email ID of the user being registered.	Optional	User	String	8	64			Yes
Correspondence Address*	Address of the user being registered.	Mandatory	User	String		256			Yes
ULB*	ULB assigned to the user where the user is supposed to perform tasks assigned to her.	Mandatory	User	String		256			Yes
Role*	Role assigned to the user to enable her to carry out her tasks and access required data and services.	Mandatory	User	String		256	Every user must have at least 1 role assignment.		Yes
Employment Type*	The employment types indicate the type of contract which he/she holds with the organisation. This indicates whether he/she is a permanent employee or a contract employee for a short period. Select the relevant employment type: 'Permanent', 'Temporary', “DailyWages” and 'Contract'.	Mandatory	User	String		256			Yes
Current assignment	The current assignment type is to indicate whether the employee is currently assigned to a particular department and designation. A user can be also be assigned multiple assignments to perform his/her function.	Mandatory	User	String		64			Yes
Status*	The status indicates the type of status which he/she holds, whether employed or not within the organisation.	Mandatory	User	String		256			Yes
Hierarchy *	The hierarchy indicates the hierarchy type for the boundary to which he/she is assigned.	Mandatory	User	String		256			Yes
Boundary Type *	The boundary type indicates assigning a city to his/her role within the organisation. A user can be assigned multiple boundary types to perform in different functions. Example: city, zone, block, and locality.	Mandatory	User	String		256			Yes
Boundary *	The boundary indicates assigning a particular city to his/her role wherein they perform the role function of the application for the particular city. A user can be assigned multiple boundaries to perform in a different location. Example: city name, and tenant zone.	Mandatory	User	String		256	User must be assigned to atleast 1 boundary.	Project boundary must take precedence over user boundary assignment.	Yes
Assigned from Date*	The assigned from date indicates the date from which his/her role is assigned to perform the role function assigned.	Mandatory	User	Date		10			Yes
Department*	The department indicates the particular department to which his/her role is assigned to.	Mandatory	User	String		256			Yes
Designation*	The designation indicates a particular designation that is assigned to his/her role.	Mandatory	User	String		256		Not required for HCM.	Yes

Role Action Mapping

Role action mapping has only been completed for registrars, distributors and system administrators to support the development of registration and Delivery flows. Other roles are still in progress.

Roles	Description	Actions	Comments
System administrator		1. Define the campaign type (project type). 2. Create campaign(s) (projects). 3. Create products. 4. Create product variants. 5. Assign product variants as campaign resources. 6. Create, search, update, and deactivate user accounts. 7. CRUD other system administrator accounts. 8. Create, assign, update, delete role assignments. 9. Create, assign, update, delete campaign assignments. 10. Define MDMS configurations (including the project type). 11. Create localisation. 12. Create, search, edit, and delete checklists. 13. Assign checklists to projects. 14. Edit/delete filled checklists. 15. Boundary setup.
Registrar	Frontline worker (FLW) who is responsible for registering households. The registrar also shares awareness messages (SBCC).	1. Create a new household. 2. Create a new individual. 3. Map individuals to households 4. Assign household/individual as a beneficiary of a campaign. 5. Read, update, and delete for all actions mentioned above. 6. View offline reports. 7. Create, view complaints.
Distributor	Frontline worker (FLW) who is responsible for registering households and updating the service delivery details against the registered households. The registrar also shares awareness messages (SBCC).	1. Create a new household. 2. Create a new individual. 3. Map individuals to households. 4. Assign a household/individual as the beneficiary of a campaign. 5. Update service delivery against the beneficiary (household/ individual). 6. Read, update, and delete for all actions mentioned above. 7. View offline reports. 8. Create, and view complaints.
Field supervisor	Responsible for monitoring the field teams. This user is also responsible for training the FLW teams, monitoring the field team's progress during campaign execution, managing stocks at the community warehouse, and performing random inspections during campaign execution	1. View assigned checklists. 2. Fill assigned checklists.
National supervisor	Supervisors are responsible for overseeing the campaign operations, conduct random and scheduled inspections, fill supervision checklists, support field supervisors to tackle operational issues under their jurisdictions, and train users on campaign SOP and digital tools	1. View assigned checklists. 2. Fill out assigned checklists. 3. View completed checklists. 4. Create, search, update and deactivate user accounts (except system admin). 5. Assign, or update, or delete role assignments. 6. Assign, or update, or delete campaign assignments. 7. View the national-level dashboard page. 8. Select and view the dashboard for each province. 9. View indicators and visualisations district-wise for each province. 10. Drill down charts to view the metrics upto the lowest boundary level (village). 11. Filter dashboard indicators by the date range. 12. Share dashboard pages/visualisations by email/Whatsapp. 13. Download dashboard pages/visualisations as PDF/JPG. 14. View the offline excel reports at specified intervals. 15. View the checklists completion rate for the country across all levels of supervisors (national, province, district, and field).
Provincial supervisor	Supervisors are responsible for overseeing the campaign operations, conduct random and scheduled inspections, fill supervision checklists, support field supervisors to tackle operational issues under their jurisdictions, and train users on campaign SOP and digital tools	1. View assigned checklists. 2. Fill out assigned checklists. 3. View completed checklists. 4. Create, search, update, and deactivate user accounts (except for the system admin). 5. Assign, or update, or delete role assignments. 6. Assign, or update, or delete campaign assignments. 7. View the province-level dashboard page. 8. View indicators and visualisations district-wise for the province. 9. Drill down charts to view the metrics upto the lowest boundary level (village). 10. Filter dashboard indicators by the date range. 11. Share dashboard pages/visualisations by email/WhatsApp. 12. Download dashboard pages/visualisations as PDF/JPG. 13. View the offline excel reports at specified intervals. 14. View the checklists completion rate for the assigned province across all levels of supervisors (national, province, district, and field).
District Supervisor	Supervisors are responsible for overseeing the campaign operations, conduct random and scheduled inspections, fill supervision checklists, support field supervisors to tackle operational issues under their jurisdictions, and train users on campaign SOP and digital tools.	1. View assigned checklists. 2. Fill out assigned checklists. 3. View completed checklists. 3. Create, search, update, and deactivate user accounts (except for the system admin). 4. Assign/update/delete role assignments. 5. Assign/update/delete campaign assignments. 6. View the district-level dashboard page. 8. View indicators and visualisations, administrative post-wise, for the district. 9. Drill down charts to view the metrics upto the lowest boundary level (village). 10. Filter dashboard indicators by the date range. 11. Share dashboard pages/visualisations by email/WhatsApp. 12. Download dashboard pages/visualisations as PDF/JPG. 13. View offline excel reports at specified intervals. 14. View the checklists completion rate for the assigned district across all levels of supervisors (national, province, district, and field).
Warehouse manager		1. Record stock transactions: Create receipt, issues, and returns. 2. View stock reconciliation (system calculated). 3. Submit reconciliation form. 4. View offline reports for inventory reconciliation.
Program manager	This user consumes the data collected and shared by the FLW and takes decisions based on the data present. This users must have access to all dashboards with the default view of the data belonging to their jurisdiction and a level below. For example, a provincial manager must be able to view the aggregated data from the entire province as well as the data for individual districts after logging into the system.
Help desk user	Supports an executive to resolve, route complaints raised during the campaign. This user also helps in user management requests.	1. Create, view complaints. 2. Resolve complaints, assign complaints, and reject complaints. 3. Create, search, update, and deactivate user accounts (except for the system admin). 4. Assign/update/delete role assignments. 5. Assign/update/delete campaign assignments.