Find the service build updates below:

HCM v1.6 Release chart

Checklist Configuration

1. Attributes:

• Each checklist consists of multiple attributes, where each attribute represents a specific question or input field.

• Attributes may have associated codes (e.g., SMC1, SMC1.YES.SM1).

1. Points Mapping:

• Each possible response to an attribute (e.g., YES, NO, NOT_SELECTED) is mapped to specific points for different flows.

1. Precedence Questions:

• Some attributes are designated as precedence attributes.

• Precedence attributes determine the priority flow when multiple flows are eligible.

1. Flow Types:

• Common flow types include:

- TO_ADMINISTER

- BENEFICIARY_REFUSED

- BENEFICIARY_REFERRED

Checklist Configuration Process

1. Define the checklist attributes and associate them with codes.

2. Map each possible response of an attribute to flow points.

3. Identify precedence attributes and configure precedence mapping.

4. Define precedence flow logic (e.g., YES maps to TO_ADMINISTER, NO maps to BENEFICIARY_REFUSED).

Example:

1. Processing Inputs

• For each attribute in the checklist:

- Retrieve the user input.

- Generate a unique key (e.g., SMC1_YES) to avoid duplicate processing.

- Check if the input has already been processed to prevent double counting.

2. Update Scores:

• For each response:

- Retrieve the corresponding flow points from the points mapping.

- Update the scores for each flow type by adding the mapped points.

3. Handle Precedence:

• If the attribute is a precedence attribute and an input is provided:

- Record the precedence flow answer.

• Skip precedence attributes if no input is provided.

Final Flow Assignment:

• Calculate the total scores for all flows based on user inputs.

• If there is a tie in scores between flows:

- Check for precedence answers and assign the flow based on the precedence mapping.

- If no precedence answer exists, assign the flow with the highest score.

• If no tie exists, directly assign the flow with the highest score.

In the HCM 1.7 release, we are introducing several technical improvements and functional enhancements, including 3 new key capabilities.

New Capabilities

1. Payments

Overview

Health campaigns involve multiple events spanning different jurisdiction levels, managed by various supervisors and attended by diverse types of campaign staff, such as healthcare workers, frontline workers, supervisors, etc. These events incur logistical costs and necessitate timely payments, including daily allowances for campaign personnel. However, the lack of a dedicated payment module presents several challenges.

Current Challenges

• Manual and fragmented payment processes: Payments are often tracked and processed manually, leading to inefficiencies and errors.

• Delays in payments: Staff compensation is frequently delayed, impacting motivation, engagement, and retention.

• Lack of transparency: The absence of a streamlined payment process results in limited visibility for supervisors and stakeholders regarding payment status.

• High administrative costs: Manual reconciliation and payment processes increase operational overheads.

Key values delivered

• Timely and accurate payments: Automated calculation and disbursement based on attendance ensure prompt compensation to campaign staff.

• Enhanced staff satisfaction: Timely payments encourage greater participation and improve workforce morale.

• Financial inclusion: Digital payments help bring unbanked staff into formal financial systems, contributing to financial equality.

• Cost efficiency: Automated processes reduce administrative expenses and improve resource allocation.

• Alignment with Sustainable Development Goals (SDGs): By digitising financial services responsibly, the module advances digital inclusion and promotes financial equality in health campaign operations.

• Transparency and accountability: Clear payment tracking fosters trust and provides better visibility for supervisors and stakeholders.

• Operational efficiency: Streamlined processes reduce administrative burdens and errors in payment handling.

User manual

Discovery and validations

The discovery of the users, the pain points, and potential solutions were formulated from various discussions with the different stakeholders such as:

• NMCP Mozambique workshop

• NMEP Burundi workshop

• Digital Finance Team, World Health Organisation

Test yourself:

Credentials

Value measurement

• User feedback from the UAT sessions in Burundi, Mozambique (SUS, CSAT).

• Validations and feedback from WHO-DFT.

• Validations and feedback with partners.

- Catholic Relief Services

- Malaria Consortium

- Alliance for Malaria Prevention

Key metrics to monitor

1. Payment Processing Efficiency:

• The time between campaign event completion and payment report submission to financial providers (MMO/Bank).

• The percentage of payments disbursed within the defined timeline. (SLA to be defined by the programme).

1. Data Accuracy and Quality:

• The number of reports requiring edits or corrections after generation.

• The error rates in payment data submitted for processing (Edited reports/Total reports).

1. User Engagement and Experience:

• CSAT score from proximity supervisors and payment approvers.

1. Operational and Cost Efficiency:

• Reduction in administrative costs due to digitisation of payment processes.

• The time saved per payment processing cycle compared to manual methods (Compare between As is vs To be).

1. Adoption Rates:

• The number of campaigns adopting the payments module.

1. Financial Inclusion:

• The number of users with mobile money accounts onboarded.

• The number of people paid out in cash vs mobile money vs bank.

Implementation considerations

1. Non-campaign events, such as training sessions, must be created as separate projects. This means that users will need to log out and select the appropriate project to mark attendance for each event.

For example, the following events require attendance tracking:

• Training of health facility supervisors at the district level

• Training of frontline workers at the district level

• Household registration (first half of the campaign)

• Household registration (second half of the campaign)

• Household distribution (first half of the campaign)

• Household distribution (second half of the campaign)

Since these events occur sequentially rather than simultaneously, the supervisor's application will contain six separate projects for attendance marking, along with an additional project for routine campaign activities such as checklists, complaint logging, and supervision. As a result, the project created for campaign activities cannot be used for attendance tracking, and a dedicated project will need to be created specifically for that purpose.

1. The indicators for monitoring the payment-related activities need to be incorporated in the dashboard depending on the programme requirements. Currently, the following indicators are considered.

• Number of attendance registers at the national level created, approved, payment report generated - Number chart.

• Number of attendance registers at provincial level created, approved, payment report generated - Number chart.

• Number of attendance registers at district level created, approved, payment report generated - Number chart.

• Attendance registers created vs approved - by district side-by-side bar chart with drill-down.

1. Ensure all actors involved in training, registration, and distribution follow the prerequisites outlined in the attached guidelines. (Part of the guidelines attached above).

a. Before the campaign or related event starts:

• Ensure all workers, including supervisors as per the microplan, are created in the system.

• Complete all worker validations.

• Confirm that all attendance registers are created and assigned to the appropriate attendance markers and proximity supervisors.

• If payment reports need to be generated mid-event, create two separate registers for the event: one for the first half and another for the second half.

• For different wage amounts across specific boundaries for the same role, create separate roles with the appropriate wage amounts and assign workers accordingly.

• Verify that all attendance markers and proximity supervisors can log in and view their assigned attendance registers.

b. During the campaign or related event:

• Mark attendance diligently for each register daily using the HCM application.

• Perform routine syncs to ensure no unsynced records remain, particularly upon event completion.

c. After the campaign starts or ends:

• Ensure no registers are pending approval by proximity supervisors.

• Verify the accuracy of the worker and register details before generating the payment report

• Confirm that payment registers are created for all boundary levels and individual boundaries (For example: districts, province, country).

Baseline data for report generation performance testing

Known bugs/Issues

None

2. Community Living Facilities (CLF)

Overview

In health campaigns, HCM has primarily supported house-to-house delivery, where the distribution was tied to a specific household or individual. For fixed post mode, HCM has done only household-based campaigns where enumeration was done house-to-house and distribution was done at a fixed post. Even in individual-based campaigns, the beneficiaries were usually part of a household with a limited number of members, with the largest households we’ve encountered being up to 30 members.

During the discussions for the polio campaign in Nigeria, there was a need to administer vaccines in fixed locations like schools, community centers, or in transit settings. In these scenarios, delivery agents are mobile, administering vaccines on the go, such as along roadsides or under trees.

There is now a growing demand for addressing similar alternative delivery modes in other health campaigns. For example, in Nigeria's Schistosomiasis campaign, medicines had to be delivered to children residing in Madrassas (residential schools), where they are permanent residents. Other similar use cases could include:

• Nursing homes and long-term care facilities

• Orphanages

• Military camps

• Police camps

• Retirement homes

• Religious Community living facilities with permanent residents

• Refugee camps

• Jails

• Schools (Residential and Non-residential)

• Bus stands / railway stations

As these use cases expand, HCM needs to adapt to cater to these modes of delivery as well and also ensure the HCM Console enables the same.

Key values delivered

As a campaign manager, I can configure different modes of delivery (fixed locations or transit points) in HCM, so that I can ensure efficient and adaptable health interventions across diverse settings like schools, refugee camps, or transit locations.

As a field worker, I can easily administer vaccines or medicines on the go using HCM, so that I can reach beneficiaries efficiently in non-household environments, such as roadsides, schools, or community centers.

Targeted users

Frontline workers who are responsible for registering and delivering interventions to community living groups.

Discovery and validations

The problem discovery and solution were done through discussions with the Burundi NMEP program team and also during the field visit to Kano, Nigeria as part of the discovery for the polio campaign.

Test yourself:

Link to download APK:

Credentials

Value measurement

• User feedback from the UAT sessions in Burundi, Nigeria (SUS, CSAT).

Key metrics to monitor

1. Adoption & Usage

• The number of health campaigns utilising non-household-based delivery.

• The percentage of the total health campaigns that use non-household-based delivery.

• The average number of beneficiaries served per CLF.

1. Efficiency & Reach

• The percentage of the total beneficiaries covered through non-household-based campaigns.

• The average time taken per beneficiary in non-household-based campaigns vs. household-based campaigns.

• The number of beneficiaries reached per field worker per day in different delivery modes.

1. Operational Effectiveness

• The percentage of campaigns successfully configured with fixed post and transit delivery modes.

• The percentage of frontline workers successfully using HCM for non-household-based delivery.

1. Impact on Health Outcomes

• The percentage increase in service delivery due to non-household-based campaigns.

• The percentage of targeted vulnerable populations (for example, refugees, children in schools) reached.

1. User Experience & System Performance

• SUS (System Usability Scale) and CSAT (customer Satisfaction) scores from field workers using HCM for non-household-based campaigns.

• The percentage of frontline workers who report ease of use in administering interventions in non-household settings.

Implementation considerations

• The distribution logic — determining the number of interventions based on CLF type — needs to be configured as per implementation requirements. For example, schools may distribute one bednet per child, while refugee camps may allocate one bednet for every two people.

• If household registration within a CLF (For example, households within refugee camps) is required, it is not currently supported in the product and will require code adjustments. The Burundi Bednet Campaign 2025 can serve as a reference for such modifications.

• Additionally, KPIs and charts specific to CLFs must be customised based on the requirements of different implementations.

Known bugs/Issues

None

3. Eligibility Checklist

Overview

For campaigns like SMC, NTD, or Polio, where medication is administered and specific considerations arise — such as referring a beneficiary, marking side effects, or identifying ineligibility — the decision-making process currently rests with frontline workers in HCM. They assess the child and determine the appropriate flow within the application. However, this approach heavily depends on the efficiency, knowledge, and capacity of frontline workers, making it prone to inconsistencies.

As a pilot, a checklist-based approach was implemented at the solution level for the SMC campaign in Kebbi State, Nigeria. This approach was well received by both the implementation partner and the program, as it reduced the effort required from frontline workers. Based on this success, the feature has now been incorporated into the product offering for SMC, NTD, and similar campaigns.

Key values delivered

For frontline workers, the administration and referrals for beneficiaries become faster, allowing for greater coverage of beneficiaries. This approach reduces inconsistencies stemming from varying capabilities and knowledge among workers, ensuring that all beneficiaries receive the appropriate intervention or service based on their health conditions, thereby promoting standardisation.

Targeted users

Frontline workers who are administering medicines for campaigns such as SMC, NTS, and polio.

Discovery and validations

• Discussions with Malaria Control Programme of Kebbi State, Nigeria.

• Discussions with Malaria Consortium.

Test yourself

Link to download apk:

Credentials

Value measurement

Through field study for upcoming campaigns in SMC and NTD campaigns in Nigeria and Mozambique, we intend to observe the following:

1. Efficiency of administration and referrals: Measure the reduction in time taken by frontline workers to administer medicines and refer beneficiaries, as compared to the previous process without the checklist approach. To compare against past campaign data (baseline).

2. Coverage of beneficiaries: Track the number of beneficiaries covered per frontline worker before and after implementing the checklist approach to gauge the increase in coverage. To compare against past campaign data (baseline).

3. Stakeholder satisfaction: Collect feedback from implementation partners (like the Malaria Consortium) and frontline workers regarding the ease of use and effectiveness of the checklist-based approach.

Key metrics to monitor

1. Time per beneficiary: The average time taken by a frontline worker to complete the administration and referral process.

2. Beneficiaries covered per worker: The number of beneficiaries attended to by each frontline worker within a given time frame (for example, per day/campaign).

3. SUS, CSAT scores: Regularly gather insights from supervisors overseeing the implementation of the checklist, evaluating both worker performance and the overall success of the checklist-based approach.

4. Training and support effectiveness: Track the number of training sessions provided to frontline workers and the success rate of those workers incorrectly using the checklist.

Implementation considerations

• If a program or implementation prefers not to use a checklist-based approach and instead allows frontline workers to make decisions independently, the checklist should be configured for removal

• The logic and navigation flow may vary based on each country's health protocols and must be configured accordingly. Currently, the referral and delivery processes follow the logic outlined in the following document:

Known bugs/Issues

• Currently, ineligibility is determined solely based on age, height, and weight as per campaign requirements. Checklist-based ineligibility is not yet supported but will be addressed and released as a patch in an upcoming update.

• Marking side effects is not included in the checklist-based approach and should be recorded independently by the frontline worker.

Tech doc link

Enhancements

1. Microplanning

Overview

The enhancements focus on improving the estimation dashboard, refining microplan estimation reports, optimising facility data handling, and incorporating mixed distribution strategies. These changes aim to enhance usability, data accuracy, and flexibility in microplanning workflows.

Key values delivered

• Improved usability: Facility and accessibility filters enable better data segmentation.

• Data accuracy & flexibility: Editable estimate sheets and facility capacity adjustments improve data handling.

• Strategic decision-making: Mixed distribution strategy consideration allows for adaptable service delivery.

Targeted users

Health campaign managers & planners: Managing facility-level microplanning.

Discovery and validations:

• User feedback: Identified usability pain points in dashboard filtering and report editing.

• Stakeholder input: Validated mixed distribution strategy feasibility for service delivery.

Test yourself

Value measurement

User feedback: Identified usability pain points in dashboard filtering and report editing.

Key metrics to monitor:

N/A

Implementation considerations:

N/A

Known Issue

Configuration of microplan assumptions according to the village’s/settlement’s accessibility or security in the estimation dashboard will not be available.

2. HCM Console Patch

Overview

This version will see HCM Console being enabled with co-delivery as a campaign type where the users can create a multi-round, multi-delivery campaign with different delivery rules using various attributes like age, weight, height, gender, type of structure and number of individuals per bednets. The user can add any resources to be delivered based on their needs.

This release will also show how the Console handles user and facility mapping to boundaries through UI. The user now does not have to manually copy and paste boundary code in mapping facilities and users to boundaries.

Key values delivered

Capability to run co-delivery campaigns using the Console.

Targeted users

System admins and programme managers

Discovery and validations

Validations are done with CHAI, AMP, and CRS

Test yourself

Credentials

Key metrics to monitor

The total time to set up a campaign.

The number of campaigns set up by the users.

Implementation considerations:

N/A

Known bugs/Issues

N/A

Technical Improvements

1. HCM Product

• Show proper message for project error.

• Loader in language selection and fix code display during language change.

• Custom template for the white screen issue.

• PGR's new component changes.

• DSS new component changes.

• Extract peer-to-peer as a different module.

• Integration testing.

• Change facility selection to the latest component.

• Unit test cases for missing modules.

• HRM new component changes.

• Integration Testing Flutter.

2. Microplanning

• Download Microplan sheet frontend changes: Keep the download button disabled until the sheet's status is updated and it’s ready to download.

• Implement UI configuration in plan and pop inbox.

• POC: Throttle/Debounce create and update calls throughout the Microplan UI to avoid duplicate API calls in UI.

• Plan configuration APIs.

• Plan service - DB indexes.

• Boundary screen optimisation.

• Assumption values can be decimal values, so they should also accept numbers between 0 and 1.

• Update data table to ui-components' data table in Microplan UI.

• Design UI configuration for plan and pop inbox.

• If the user "Download estimations" immediately after validating the estimations, we won't get the sheet in format or localised way.

• Search and count query logic separation.

• Census Service -

  • Modify the search plan method to match the implementation in the plan service

  • APIs

  • Add method descriptor for bulk update

3. HCM Console

• Checklist Configuration: The console allows configuring checklists only in the user-selected language during the flow. It does not support configuring checklists in other languages, even if the server provides support for multiple languages.

• Assessment Checklist Configuration: Assessment checklists cannot be configured in the Console.

• Boundary Management: Boundary management is restricted to a single language.

• User Management: The same user cannot be assigned to multiple campaigns.

• Data Updates: Updating facility or user data during the update flow is not supported.

• Fetch Data From Microplan: Currently, users can fetch data from one selected microplan.