Introduction

This document outlines a systematic approach to manage and evaluate new ideas for product development coming from the members of the DPAC. It is meant to serve as a guide for product managers to effectively assess and decide whether to implement these ideas into the product.

Process Overview

Step 1: Idea Submission and Documentation

The DPAC members are encouraged to use the Idea submission form to submit new ideas which will be documented in a central repository.

Step 2: Initial Review

All submitted ideas will undergo a preliminary review to check alignment with the overall goal, outcomes, problem addressed and the product’s roadmap. Any idea that does not align with the strategic objectives of the product will be dropped after deliberation with the DPAC.

Step 3: Prioritisation and Feasibility Analysis

The remaining ideas that pass the preliminary review are then prioritised based on their potential to solve a specific problem and deliver impact on the ground.

Agenda

To present the Health Campaign Management product roadmap and identify the pain points currently associated with conducting health campaigns in Africa.

Meeting Attendees

Discussions

Key Discussions in Proceedings

1. Introduction and context setting by Jojo

a. Proposal to conduct this meeting once a quarter, with the next one hopefully in person.

b. SMC and Bednet Campaigns have been conducted so far, with IRS, LF, and Polio campaigns to be conducted in the coming months.

1. Product Roadmap Walkthrough by Abhishek

a. Discussion of existing HCM capabilities as well as planned capabilities to be added over the following months.

1. Attendance Management, presented by Abhishek

a. Liberty outlined the importance of preventing fraud, and stressed the need for an additional method to prove the identity of the person giving attendance, In addition to a simple yes/no, perhaps IDs could be involved in attendance taking as well.

b. Elijah brought up the need for a user creation and access management feature.

• Jojo responded that this feature is coming up in the admin console.

c. Elijah suggested scanning a QR code as proof of ID for taking attendance. This would help in fraud prevention.

• Jojo responded that this could be done for attendance at a solution level.

d. Elijah also suggested using QR codes as a form of identification, instead of usernames and passwords. The printed QR code would provide login credentials. This would solve the need for teams to converge at a central location at the end of the day for attendance-taking.

• Jojo agreed that this is something we need to understand further.

e. Elijah also brought up the need to be able to edit and add records of campaign participants. Currently, the central team has to add the records of the replacements for participants who drop out. Names are misspelled as well.

• Abhishek stated that this is possible and would reach out to Elijah

f. Satish wanted a follow-up meeting on attendance capabilities.

1. Code Scanning, presented by Abhishek

a. Sid stated that a lot of the input is going to be upstream or downstream of the technical system and that it would be useful to understand both sides of it.

• Jojo suggested a follow-up call with Sid to understand this further.

b. Marcy stated that there have been operational issues involved in bale scanning in Liberia, starting with training. A further deep dive is needed to discuss this.

c. Bale scanning conversation to be orchestrated by Nita.

1. Voucher Scanning, presented by Abhishek

a. Marcy stated that control of the vouchers had been lost in Liberia. Vouchers were unused in the field because no one knew who they were meant for. There was little visibility on what had been sent to districts, issued to supervisors, issued to households, and remained to be collected and returned. This needs to be addressed going forward in Liberia and in Burundi.

b. Nita added that sometimes people did not have voucher details and hence were denied bednets.

c. In response to Marcy, Elijah stated that it was an implementation issue in Liberia. There is scope to improve voucher management, for example, tracking all vouchers in the system. This way, vouchers could be shipped and tracked to their respective points of issuance .

d. Elijah brought out the need for guidance on the use of each functionality. The outcome of not following the prescribed SOP needs to be stated at each stage of the product.

e. Jojo mentioned that the SOPs need to be adhered to. For instance, when vouchers are issued, the SOP to collect the vouchers after handing over the bednets needs to be followed, or else there is a likelihood of bednets being delivered against the same voucher more than once.

1. Location Accuracy and GIS Dashboard, presented by Abhishek

a. Jojo called for participants' opinions on what distance they felt constituted a good level of accuracy. Currently, 94% of geo-coordinates are accurate within 20 meters, and almost 80% are within 5-10 meters.

b. Ravi stated that 5-10 meters constituted a great level of accuracy and that there are constraints on the level of accuracy that can be obtained due to structures, trees, etc. Coordinates could be aggregated together on a grid and displayed in dashboards. The value of the programme comes from both spatial and non-spatial data. Furthermore, only clustered data is released since countries have shown resistance to releasing individual-level data.

c. Ravi also spoke of the need to have baseline data like imagery, building footprints, etc., and stated that this should be the future focus. This data would help in time analysis to answer questions such as which areas have a shortage of bednets or what is the optimal coverage for delivery centers.

d. Ravi put forth the need to build a culture with the enumerators on the accuracy of data capture. Accuracy would be better with towers and is often limited to 10-20 meters because there are no towers nearby to triangulate coordinates. Another problem is that when people get into a house and start the survey, the walls obscure the signal.

f. Ravi brought out the value of GIS data both when taking micro-level decisions regarding operations and at a higher level among decision-makers. The value provided would be diminished if the GIS data could not be obtained in a timely manner.

To learn more about the April 2023 session, click on the following link:

Introduction

The purpose of this document is to establish the Digital Product Advisory Committee (DPAC) for DIGIT HCM. The DPAC will be responsible for providing guidance, inputs, insights and recommendations to the design and development of DIGIT HCM and to the product roadmap. This charter outlines the DPAC’s objectives, responsibilities, composition and operating principles.

Background & Context

Digital technologies generally, and digital public goods (DPGs) in particular, provide an opportunity for governments, private sector organisations and civil society organisations to collaborate to address public health outcomes by creating a country’s digital public health infrastructure. These digital technologies manifest as digital products or solutions that are used as part of programs by governments and civil society organisations aimed at specific interventions. Public health is one such area where digital public infrastructure (DPI) using DPGs is being built across countries. Within the larger public health space, public health campaigns are one such intervention, that are aimed towards the control, prevention, and eradication of disease at the population scale by setting up digital public infrastructure.

Working with partners and supported by our donors, Bill & Melinda Gates Foundation (BMGF), Nandan Nilekani Philanthropies, and the Global Fund (Supply Chain team), eGov Foundation, is designing and developing a digital health campaign management product on the DIGIT Health platform. For the first implementation of this product, eGov Foundation has partnered with the National Malaria Control Programme (NMCP) under the Ministry of Health of the Government of Mozambique. The first exemplar using DIGIT HCM was done for a bednet campaign in Mozambique in August 2023 in Tété province. Following this, DIGIT HCM will be used for managing and operationalising an SMC campaign in the Nampula province of Mozambique, starting January 2024. The next country adopting DIGIT HCM for their health campaigns is Liberia, where DIGIT HCM will be used for a bednet campaign in March 2024. The same product is intended to be used for campaigns across multiple diseases and we hope to work with other partners to help us evolve the roadmap for this product.

As in many other spaces, the health campaign management space is fragmented with multiple products and solutions. Oftentimes, these products and solutions have overlapping capabilities, are not interoperable or are difficult to deploy in a changed context. This adds the burden of creating a new solution for each campaign, straining the already limited resources which can be put to better use. Designing and developing DIGIT HCM as a global DPG that forms a part of the digital public health infrastructure of a country can help mitigate many of these issues. DIGIT HCM is being designed and developed as a DPG and made freely available to all as open-source software under the MIT license. ().

Objectives of the Digital Product Advisory Committee

There are many organisations and individuals with deep knowledge and expertise in the public health space in general, and in public health campaign management, in particular. We endeavor to leverage this collective knowledge and expertise as we evolve the product. We do this by arriving at a shared understanding of the challenges faced by various actors in delivering public health campaigns, prioritising the most pressing issues keeping an eye on what’s going to be used first, building into the product the capabilities that are needed by most and enabling interoperability with other products and solutions catering to very specific use cases.

The objectives of the Digital Product Advisory Committee then, are to:

1. Get strategic alignment on the most pressing problems in health campaign management across the different types of campaigns.

2. Provide inputs that will inform the product roadmap.

3. Provide domain knowledge.

4. Share experience on the variations in campaigns in different countries and how the product can factor in those variations.

5. Share best practices, learnings and failures, and the root causes of these problems.

What does the Digital Product Advisory Committee do?

Here’s a view of what the Digital Product Advisory Committee (DPAC) is expected to do -

The following are a few of the things the Digital Product Advisory Committee will not do:

As the name suggests, the Digital Product Advisory Committee is an advisory body and as such, it is not a decision-making body. Its role is to share relevant experience from different geographies, share learnings from other campaigns and countries, help understand the problems in campaigns and challenges faced by different actors, etc. It will provide inputs and strategic direction that can be taken up for consideration on the roadmap but is not responsible for the roadmap itself.

Members of the Digital Product Advisory Committee

The advisory committee will meet once a quarter.

Proposed Principles

1. Understand the problem and reimagine futures with the ecosystem:

• Understand the problems of different actors, and their problems.

• Refer to existing research, consult experts, involve stakeholders, and engage with end-users to develop an understanding of the problem space.

• Develop and articulate a point of view.

• Validate and refine this understanding through dialogue and discussion.

• Reimagine futures.

1. Prioritise solving pivotal problems:

• Keep the focus on pivotal problems, enabling services and not pointing solutions

1. Prioritise design and development of what will be used:

• Design and development effort is scarce and hence should be prioritised towards capabilities that will be used, that is, in a specific implementation.

1. Co-create with actors:

• Design and co-create along with users and ecosystem actors

1. Design and plan for scale from the beginning:

• Build in flexibility, modularity, and simplicity from the start.

• Identify and design for scale levers.

1. Follow a holistic design approach:

• Holistic design incorporates functional, visual, process, tech, and business models. and policy considerations.

• Design for people and the needs of different types of people.

• Think in terms of affordances (UI/UX, channels, language, etc.) and not just the technical capabilities of the system.

• Design for change.

1. Reuse and evolve:

• Leverage the work done by others and evolve that.

• Everything does not need to be reinvented.

1. Follow an ecosystem-first approach:

• What can be done by the ecosystem, should be done by the ecosystem.

• Plan for enabling and co-creating with the ecosystem.

• Put out artefacts that will enable others to reuse and evolve what’s already been done.

1. Define success from the beneficiary’s perspective

• Define what success looks like from the perspective of those who we are solving for.

• Solve for beneficiaries, with citizens being the first among them.

• Plan to track, measure, and iterate from the beginning.

For more details, click on the following links:

• November 2023

• August 2024

To learn more about the April 2023 session, click on the following link:

Here are the articles in this section: