The Microplan Assumptions step is designed to streamline the process of defining critical campaign-related hypotheses based on the selected Resource Distribution Strategy and Campaign Type. This step consists of two substeps:

Step 1: Registration and Distribution Process Selection

This screen adapts based on the Resource Distribution Strategy chosen during the Campaign Details step.

1. Mixed Strategy:

For campaigns following the Mixed Strategy, the system prompts users to provide details for both the registration and distribution processes. However, the same method cannot be selected for both.

Prompts:

1. How is the campaign registration process happening?

   • Users are required to select from predefined options such as House-to-House, Fixed, etc.

2. How is the campaign distribution process happening?

   • Users must select a different option from the registration process, tailored to the distribution method (e.g., House-to-House, Fixed, etc.).

This distinction ensures that the two processes are appropriately differentiated and configured.

2. Fixed or House-to-House Strategy:

For these strategies, users are prompted to specify the relationship between registration and distribution processes:

Question:

• Is the registration and distribution process happening together or separately?

  • Options:

    • Together

    • Separately

The response determines how the system pre-configures subsequent assumptions.

Step 2: Assumptions Form

Once the registration and distribution process is selected, users proceed to the Assumptions Form, which dynamically adapts based on campaign-specific parameters.

Configurability of Assumptions Data (Categories and Assumptions)

The form fetches data from the MDMS and includes categories and assumptions customized according to:

• The Campaign Type (e.g., Bednets, SMC)

• The Resource Distribution Strategy (e.g., House-to-House, Fixed)

Example of some dynamic categories of Assumptions:

1. General Assumptions:

   • High-level parameters that apply to the overall campaign.

2. Registration Assumptions:

   • Assumptions specific to how and where registration activities occur.

3. Distribution Assumptions:

   • Parameters defining the methodology and logistics for distributing resources.

4. Commodities Assumptions:

   • Details about distributed items, such as the number of bednets per household.

Features of the Assumptions Form:

1. Input Values:

   • Users must input specific values for each assumption.

   • Validation Rules:

     • Assumption values must:

       • Be numerical and are mandatory. and fall within the range of 0 to 1000.

       • Contain at most two decimal places (e.g., 12.34 is valid, but 12.345 is not).

       • Adhere to a specific format, ensuring they match the pattern of a valid decimal or whole number (e.g., 123.45 or 678).

   • Tooltips:

     • Each category includes input parameters with tooltips that provide detailed information when users hover over the respective field.

2. Manage Assumptions:

   • Users can add new assumptions or delete existing ones based on campaign needs.

   • Initiate Adding an Assumption:

     • Users can click the "Add New Assumption" button from the assumptions management interface.

     • Assumption Details Input:

       • A popup/modal is displayed with the following fields:

         • Choose Assumption: A dropdown or selection box to choose an existing assumption or create a new one.

         • Assumption Name: An input field where users specify the name of the new assumption.

     • Confirmation Options:

       • Cancel: Discards the changes and closes the popup/modal.

       • Add: Saves the new assumption after passing validation checks.

• Deleting Assumption

  • Users can click the "Delete" button from the assumptions management interface.

  • Confirmation Options:

    • No: Discards the changes and closes the popup/modal.

    • Yes: Deletes the assumption.

  • Recovering deleted assumption:

    • Users can click the "Add New Assumption" button from the assumptions management interface and select the deleted assumption from the Choose Assumption dropdown.

Customization and Management:

Each assumption category and its parameters are dynamically tailored based on:

• The selected Campaign Type

• The chosen Resource Distribution Strategy

Here are the articles in the section:

Microplan Details

Boundary Selection

Data Management

Microplan Assumptions

Formula Configuration

The microplan creation process is organised into multiple steps using a stepper for better navigation. The first step in this process is Microplan Details, divided into two sections: Campaign Details and Microplan Details. This document provides an overview of these sections.

1. Campaign Details

The Campaign Details section collects critical information about the campaign to set up the microplan.

Header

• Title: Enter the campaign details Guides users to input required campaign information.

• Description: Please enter the required details to proceed with the microplan setup. Explains the purpose of this section.

Localisation: Both the title and description are fully translatable into multiple languages.

Fields

1. Disease Identified for the Campaign

• Description: Select the disease targeted for the campaign.

• Field Type: Dropdown

• Default Value: Malaria

• Mandatory: Yes

• Usage: Use the dropdown or type to filter options.

Localization: The label is translatable.

2. Type of Campaign

• Description: Specify the type of campaign.

• Field Type: Dropdown

• Default Value: None (user must select a value)

• Mandatory: Yes

• Usage: Select the type from the dropdown.

Localization: The label and options are localizable.

3. Resource Distribution Strategy

• Description: Choose a strategy for distributing resources.

• Field Type: Dropdown

• Default Value: None (user must select a value)

• Mandatory: Yes

• Usage: Select a strategy aligned with campaign goals.

Localization: Fully supports translations for the label and dropdown options.

User Interface

• Dropdown Menu:

  • Accepts text input for filtering options.

  • Includes a dropdown arrow icon for selection.

Validation

• Fields marked with an asterisk (*) are mandatory.

• Users must complete all required fields to proceed.

• Validation rules and error messages are localizable.

2. Microplan Details

The Microplan Details section focuses on naming the microplan for reference and identification in subsequent steps.

Fields

1. Campaign Details Summary

Displays a summary of the campaign information entered:

• Campaign Disease: Malaria

• Campaign Type: SMC Campaign

• Resource Distribution Strategy: House-to-House

2. Name of the Microplan

• Description: Provide a unique name for the microplan.

• Field Type: Text Input

• Mandatory: Yes

Microplan Naming Rules

1. The name must be between 3 and 64 characters in length.

2. Numeric values alone are not allowed.

3. Allowed special characters: -, _, (, ), &.

Naming Regex MDMS: https://unified-qa.digit.org/workbench-ui/employee/workbench/mdms-search-v2?moduleName=hcm-microplanning&masterName=MicroplanNamingRegex

• Provides the regex pattern used to validate microplan names.

Naming Convention Info MDMS: https://unified-qa.digit.org/workbench-ui/employee/workbench/mdms-search-v2?moduleName=hcm-microplanning&masterName=MicroplanNamingConvention

• It contains detailed information about naming conventions and guidelines.

Suggested Name: The system automatically suggests a microplan name based on campaign details. You can use this suggested name or provide a unique name that matches the naming rules.

Example: "Malaria-Bednet Campaign-Fixed Post & House-to-House-29 Nov 24"

Localization: Instructions and validation messages are fully translatable.

API Endpoints and Example Request Payloads

The Boundary Selection step is the second step in the microplan creation process. It allows users to define the geographic areas (boundaries) where the campaign will be conducted. Users must select boundaries at different hierarchical levels to ensure accurate targeting.

Header

• Title: Select the boundaries where you want to run the campaign Provides clear instructions for selecting the geographic regions for the campaign.

• Description: Boundaries are the administrative areas defined that you want to run a campaign in. Start selecting boundaries from the first level so that the boundaries present in the next level are available for selection. Explains the importance of hierarchical boundary selection.

• Localization: Both the title and description can be translated into multiple languages.

Fields

The following fields represent the hierarchical administrative levels for boundary selection. These levels are dynamic and depend on the hierarchy definition configured in the system. An example hierarchy could look like this:

1. Country

   • Description: Select the top-level boundary (e.g., Country) where the campaign will be conducted.

   • Field Type: Dropdown

   • Mandatory: Yes

   • Usage: Selection of this level enables the next level in the hierarchy.

2. Province

   • Description: Select the second-level boundary (e.g., Province) within the chosen country.

   • Field Type: Dropdown

   • Mandatory: Yes

   • Usage: Available only after selecting the country.

3. District

   • Description: Select the third-level boundary (e.g., District) within the chosen province.

   • Field Type: Dropdown

   • Mandatory: Yes

   • Usage: Available only after selecting the province.

4. Administrative Post

   • Description: Select the next boundary level (e.g., Administrative Post) within the chosen district.

   • Field Type: Dropdown

   • Mandatory: Yes

   • Usage: Available only after selecting the district.

5. Locality

   • Description: Select the locality boundary within the chosen administrative post.

   • Field Type: Dropdown

   • Mandatory: Yes

   • Usage: Available only after selecting the administrative post.

6. Village

   • Description: Select the final-level boundary (e.g., Village) within the chosen locality.

   • Field Type: Dropdown

   • Mandatory: Yes

   • Usage: Available only after selecting the locality.

Note: The hierarchy structure (e.g., Country > Province > District > Administrative Post > Locality > Village) is just an example. Actual levels and labels will vary based on the specific administrative hierarchy configured in the system.

Key Points

• The number of levels and their labels (e.g., Country, Province, District) are not fixed and depend on the system's hierarchy definition.

• Users must proceed sequentially, selecting each level to unlock the next.

• Localization: All hierarchy level labels are fully translatable, allowing them to be displayed in different languages as required.

User Interface

• Dropdown Menu:

  • Hierarchical: The options in each dropdown depend on the selection made in the previous level.

  • Filtering: Text input is supported to filter options.

• Validation: Ensures selections are made sequentially and that no level is skipped.

• Localization: Error messages and validation prompts are fully translatable.

Validation Rules

• All fields marked with an asterisk (*) are mandatory.

• Users cannot proceed without completing the selection at each level.

• If boundaries are not selected down to the last level, or if any selected boundary does not have its child boundary selected, a proper error message is displayed.

Boundary Selection Overview Card

The Boundary Selection Overview Card displays details of the number of selected levels at each dynamically configured boundary level (e.g., Country, Province, District, etc.). It provides a quick summary of the selections made at each level, offering users an efficient way to track the progress of the boundary selection process.

API Endpoints and Example Request Payloads

It looks like the second update was missed. Here's the table with both updates correctly included:

The Data Management step includes two substeps: Population Upload and Facility Upload, enabling users to upload essential data for the microplan.

Population Upload

Description: This substep allows users to upload population data for the campaign.

• Download Template: Download the template for population data.

• Boundary Dependency: The boundaries appearing in the population template are dependent on the boundaries selected in the previous Boundary Selection screen. Tabs in the template will correspond to the districts selected in that screen.

• File Upload: Drag and drop or browse to upload the filled Excel file.

Guidelines:

• Mandatory Fields: The Total Population and Target Population columns are mandatory and must be provided as whole numbers.

• Latitude & Longitude: These fields must be in Degree Decimal or Degree Minute Seconds format.

Facility Upload

Description: This substep allows users to upload facility or point-of-service information.

• Download Template: Download the template for facility data.

• Boundary Codes: The facility template will include boundary codes for the villages selected in the previous Boundary Selection screen in a single Boundary Code sheet.

• File Upload: Drag and drop or browse to upload the filled Excel file.

Guidelines:

• All fields are mandatory except for Latitude and Longitude.

• Latitude & Longitude must be in Degree Decimal or Degree Minute Seconds format.

Error Handling

Validation Process: After the file is uploaded, the system will validate the data. If any errors are found, the system will populate an Error column in the sheet, showing the errors next to the corresponding rows.

Error Preview: Clicking the View Error button will show a preview of the uploaded Excel file, highlighting the errors in the Error column next to the corresponding row.

Re-upload Process: Once the errors are corrected, users can download the validated file, make the necessary changes, and re-upload the file.

Proceeding with Valid Data: Processing will only proceed if a valid sheet with no errors is uploaded. If the sheet is valid, the system will continue to the next step.

Boundary Selection Screen Navigation Warning:

• Warning: If the user navigates back to the Boundary Selection screen, the current uploaded templates for Population and Facility will be discarded. A warning message will appear on the UI to inform the user before they proceed.

Generation and Validation from MDMS Schema

• Generation: From this schema, fields are converted into columns in the respective upload templates.

• Validation: Validation is performed based on the schema, ensuring that the data adheres to the defined structure.

• Additionally, custom validations are applied to ensure data integrity.

Localization & User Interface

• Localization: All labels, instructions, and error messages are translatable into multiple languages.

• File Upload: The interface supports drag-and-drop or browse-to-upload file options.

• Validation: Validation ensures all required fields are completed and data is properly formatted. Processing will proceed only if a valid sheet with no errors is uploaded.

Here is the updated table with the adjustments:

The Formula Configuration Screen allows users to configure resource estimation formulas based on assumptions and campaign strategies. Users can also choose whether the formula should be displayed on the Estimation Dashboard (Population Inbox Screen). Additionally, new formulas can be added as needed.

Key Features

1. MDMS Integration for Autofilled Configurations

   • These configurations are tailored using specific keys that define the campaign type, distribution strategies, and processes.

2. Add Formula

   • To create a new formula, click Add Formula.

   • Define the Formula Name, Inputs, and select the appropriate Operator.

   • After creating the formula, users can choose whether to display it on the Estimation Dashboard.
3. Delete Formula

   • To remove a formula, click Delete next to the relevant formula.

   • If the formula is used in the campaign, the system will prompt the user to either reuse the deleted formula or define a new one.

4. Show on Estimation Dashboard

   • If the user wants the formula to appear on the Estimation Dashboard, check the Show on Estimation Dashboard box.

   • Unchecking the box will keep the formula available for calculations but will exclude it from the dashboard view.

Example Formula Configurations

1. Total Number of Bednets per Boundary Formula: Total Number of Bednets = Target Population / Number of Persons per Bednet

   • Dependency: Relies on assumptions like Target Population and Number of Persons per Bednet.

   • Action: The user can choose to show this formula on the Estimation Dashboard by selecting the Show on Estimation Dashboard checkbox.

2. Total Number of Bales per Boundary Formula: Total Number of Bales = Total Number of Bednets / Number of Bednets per Bale

   • Dependency: Relies on Total Number of Bednets and Number of Bednets per Bale assumptions.

   • Action: The user can delete this formula or add it to the Estimation Dashboard as needed.

The different roles involved in the various parts of the microplan are:

1. National Microplan Estimation Approver

2. National Facility Catchment Assigner

3. National Population Data Approver

4. Microplan Estimation Approver

5. Facility Catchment Assigner

6. Population Data Approver

Each role has its own user list (uploaded through User Management Bulk Upload), and the available jurisdictions is based on the boundaries selected in the Boundary Selection screen.

Note:

Each role will have its own screen. Here, we use the National Microplan Estimation Approver role as an example for assigning and unassigning users.

National microplan estimation approver

This screen is for assigning National microplan estimation approver to the current microplan.

Once the system administrator clicks on the ‘Assign National Microplan Estimation Approvers’ button, he/she will be prompted a pop-up to assign the users with ‘National Microplan Estimation Approver’ role to the ongoing microplan.

Here, the system admin will be able to assign/unassign a user to the ongoing microplan.

Search, Assign, Unassign Implementation

Search The search request is made via /health-hrms/employees/_search, using roles as query parameters (e.g., roles: ROOT_PLAN_ESTIMATION_APPROVER). This returns all registered users with the specified role. When the page loads, a request to /plan-service/employee/_search retrieves all users currently assigned to the current microplan.

Assign Upon clicking the assign button, the userServiceUuid from the search response (/health-hrms/employees/_search) is used as the payload, along with the jurisdiction and role. For the National Microplan Estimation Approver role, the jurisdiction is pre-selected as the national level by default.

For other roles, the jurisdiction is automatically pre-selected based on the boundaries set in the Boundary Selection screen. This information is then sent to /plan-service/employee/_create to assign the user to the current microplan.

Unassign Clicking the unassign button sets the active attribute of PlanEmployeeAssignment to false via /plan-service/employee/_create, updating the microplan accordingly.

API Flow:

The process for assigning users to each role is the same: open the roles screen and assign registered users within the appropriate jurisdiction.

Note:

Assigning users to national roles is mandatory

User Roles

• Actors: System Administrator / Program Manager

• Administrative Boundaries: National / Country level

Summary Screen Modules

The summary screen consists of the following modules:

1. Microplan Details Displays the core information about the microplan, such as the campaign name, disease, and resource distribution strategy. The user can review the details and make necessary edits.

2. Campaign Boundary Shows the geographical administrative boundaries, including the country, province, district, administrative post, locality, and village levels. Users can review and edit the boundary data for each geographical level.

3. Data Management Displays data templates for population and facilities. Users can download the templates or edit the uploaded files.

4. Microplan Assumptions Shows the assumptions used in the microplan setup. Users can review and adjust these assumptions as necessary.

5. Formula Configuration Displays the configured formulas used in the microplan. Users can modify the formulas if required.

6. Data Validation Ensures that the data entered meets all the required criteria and can be validated before proceeding with the microplan.

7. User Access Management Displays the users and their roles in the microplan setup. Users can manage who has access to the microplan.

Tab Filtering Implementation

Based on the tab, the respective section of setup microplan is shown.

Its implemented by using ViewComposer and passing in the pages as cards in a array called Cards.

Data for the Pages

The data displayed on the pages is retrieved from the sessionData, which is created whenever the user inputs data during the microplan setup process. As the user progresses through the setup, each section of the form they complete is captured and stored as formData.

Key Functionalities

Edit Data

• Description: Each section of the summary screen can be edited by clicking the Edit button. This will redirect the user to the corresponding section in the microplan setup for further configuration.

• Implementation: The system sets the key value for the selected section and redirects the user to the relevant page based on that key.

Download Files

• Description: The user can download files (e.g., population and facility data templates) by clicking the Download button where applicable.

• Implementation: This functionality is described in the Data Management page, where users can access and download the uploaded templates and files.

Finalize:

Once satisfied with the configuration, the user clicks Complete Setup to finalize the microplan.

When the Complete Setup button is clicked, the /plan-service/config/_update is triggered, with 'workflow:initiate' sent as the payload.