1 of 100

v1.5

Introducing DIGIT Health

Mission

Help countries achieve Health SDGs by building digital public goods that strengthen public health.

What are public health campaigns?

Health risks such as infectious diseases generally cannot be addressed at the individual and health worker levels alone. They require intervention at the policy level. This is where public health campaigns come into the picture.

Public health campaigns are specific, time-bound health services that respond to particular challenges and are provided to a target population by dedicated campaign workers. Such campaigns can influence perceptions, attitudes, and behaviors to achieve the desired goal. They can prevent or respond to disease outbreaks, control or eliminate targeted diseases, or achieve other health objectives. According to the World Health Organisation (WHO), two strains of wild poliovirus have “officially been certified as globally eradicated,” and immunisation campaigns have played a key role in this. Over the years campaigns to fight malaria, AIDS and other diseases have not only improved the lives of millions of people in poor and developing countries and disadvantaged communities, but it has also enabled them to lead more productive lives.

In 2019, 534 campaigns were tracked globally, providing vaccines, drugs, vitamins, and preventative tools for malaria, malnutrition, measles, meningitis, NTDs, polio, tetanus, typhoid, and yellow fever. However, by the end of 2020, an estimated 50% of the public health campaigns were postponed, suspended, or canceled due to the COVID-19 pandemic. This left millions of people and children at risk of vaccine-preventable diseases and malnutrition.

How can DIGIT HCM help?

As health campaigns catch up on missed vaccinations, drugs, and other preventative measures globally, there is an opportunity to reimagine the way countries can plan and implement campaigns through open-source digital platforms.

Today, digital tools are either free but not fit for purpose, or they do the job but cost a fortune due to repetitive work adding to the costs. Data is locked in silos and there is no operability between systems. These tools are also difficult to sustain and scale. These realities made it clear that isolated approaches cannot do the job.

Health campaigns require a holistic digital transformation. That's why DIGIT Health Campaign Management or DIGIT HCM was developed to address these challenges effectively.

DIGIT HCM is a free, fit-for-purpose, open-source, end-to-end health campaign digitisation product. It covers campaign setup, planning, registration, service delivery, inventory management, and real-time data dashboards, enabling faster and cost-effective health campaigns. DIGIT HCM is designed to evolve rapidly and adapt to local needs while addressing systemic challenges.

With DIGIT HCM, all programmes — whether for polio, malaria, or measles — are unified under a single, streamlined interface. This ensures that data flows seamlessly across different modules, improving data quality and accessibility.

The shared data repository within DIGIT HCM guarantees a “single source of truth,” maintaining high data quality. It offers easy integrations, seamlessly operating with open-source products, providing a unified system for health campaign management.

DIGIT HCM is designed with highly configurable, reusable modular building blocks, enabling rapid reconfiguration of the same product for different health campaigns. These modules can also be repurposed to develop new solutions for routine health, primary healthcare, and other areas.

More than just a product, DIGIT HCM is a comprehensive solution designed to streamline health campaigns, enhance coordination, and improve outcomes at every level of the health campaign management system.

Useful Links

Contact Us

Release Notes

HCM v1.5 Release Notes

Release Summary

HCM v1.5 is a product release with upgrades for a new campaign adaptation such as IRS.

Features:

Enhancement of DIGIT HCM for managing a new campaign such as IRS.
Enhancement to provide the ability to link downloaded households to new campaigns.
The product has been enhanced to capture information related to house structure, room details, and the number of pregnant women and children present in the house independent of the campaign type.
Enhanced accuracy for geo coordinates capture in the app.
Enhancement of DSS dashboards for new campaign adaption.
Enhancement to provide the ability to view dashboards for District Supervisors in the mobile application.

Functional Changes

Closed Household: This feature enables data collection on closed households by utilizing the existing registration and delivery package. It allows CDDs (Community Drug Distributors) to revisit households for registry updates efficiently.
Registration and Delivery: Added intermediate screens to enhance registration of households to support new campaigns.
User Action: Full CRUD functionality for project-related actions taken by the field worker that are not tasks related to the beneficiary like:
- Refusal of consent for data collection.
- Scanning of resources that will be reused for multiple deliveries.
- Marking a transit post-non-compliant (polio).
- Marking any incident that doesn't bear relation to the beneficiary.
- Location capture of the field worker app.
Dashboard Updates:
- Mobile Dashboard: Enabled the mobile dashboard for district supervisors and configured the Digit UI DSS Dashboard to support new campaigns (e.g. IRS).
- National Dashboard Enhancements: Introduced support for pie charts and bar charts.
- Map Configurations: Moved map configuration data to S3 assets.
- Chart Configurations: Added and modified chart configurations for both the Mobile and DSS Dashboards (e.g., IRS), including both new and existing charts.
Tech Debts
- Search Query Optimization: Enhanced search queries across the mobile application for improved performance.
- Boundary Localizations: Migrated boundary localizations from the ISAR (JSON) database to an SQL database in the mobile application for better efficiency.

Non-Functional Changes

Pop-ups have been added to various screens to improve geo-coordinate accuracy within the app. These pop-ups will display a message and temporarily freeze the screen, allowing users to capture a person's geo-coordinates without disruption.

Breaking Changes

No breaking changes were made.

Benefits - v1.5

Configurable Project Dashboard: Previously, project dashboard configurations were hardcoded. Now, they are fully configurable based on boundary v2 and project-type codes.
Removal of Hardcoded Context Paths: All hardcoded context paths have been removed throughout the application, improving flexibility and maintainability.
Map Config Data Moved to S3: Due to the large size of the map configuration data, it could not be loaded into MDMS v2. This data has now been moved to S3 assets for better handling and storage.
Search Query Enhancement: Previously, each entity had its own individual search. Now, we have implemented a unified query builder, which has significantly improved the performance of the search functionality.

Migration from v1.4 to v1.5

The HCM v1.5 release does not require any migration from the 1.4 release.

Service Build Updates

Find the service build updates below:

Release Checklist

HCM v1.4 Release Notes

Release Summary

HCM v1.4 is a tech release with only server upgrade to with some additional cleanup.

Features:

Digit core LTS integration
- MDMS v2 integration
- Boundary V2 integration
HCM Admin Console
DIGIT HCM app modules as package extractions

Functional Changes

Missing unique validation on client reference ID added in all offline supported services.
Project types have been moved to project additional details from MDMS.

Non-Functional Changes

UI modules extracted as packages
- Registration and delivery
- Referral reconciliation
- Inventory management
- Attendance management
- DIGIT scanner
- DIGIT showcase
All core services have been upgraded to core 2.9 LTS barring the services modified for offline use cases.
All data models have been restructured with an "is a relationship" from base eGov model and the base eGov search model.
All data models have been moved to the health common library and duplicates removed.
Removed reflection until code in the health common library that is Incompatible with Java 9 and above.

Breaking Changes

All the master data for the DIGIT HCM app are separated by functionality from one single master.
Flyway version upgrade to 9.22.3 for LTS upgrade.
Boundary v2 Integration

Migration from v1.3 to v1.4

The HCM v1.4 release requires migration of the boundary and MDMS data if the server is not a fresh deployment but an existing v1.3 deployment

Boundary v2 migration

If the current environment has boundary data in MDMS v1 please follow the steps mention in the document below to migrate to boundary v2. Boundary migration from v1 to v2 LTS

MDMS v2 migration

If the environment is new the one click installer and data loader will by default load the data required.

If the Environment has pre existing data then the MDMS v2 migration tool should be run using the below document:

MDMS migration from v1 to V2 LTS

Following is the code link:

Code link for the above-mentioned migration utilities

Service Build Updates

Find the service build updates below:

Release Checklist

v1.3 Release Notes

Release Summary

Health Campaign Management v1.3: The Frontline Worker’s App includes two new features that enable frontline teams to perform their tasks efficiently even when offline.

To learn more about the DIGIT Health Platform and the Health Campaign Management (HCM) product, click .

New Feature Additions

Localisation Keys

v1.3 Tech Release Summary

Impacted Services

Project:

Implemented validation for updating the project start date and the end date. Implementing this ensures that any changes made to these critical campaigns adhere to the predefined criteria.
Added the number of sessions field in additional details for the attendance registry, which enhances the system's ability to manage attendance tracking within projects. This field specifically denotes the frequency of attendance-taking sessions for a given project. Each session represents an instance where attendance is recorded, typically within a single day. For instance, if a project requires attendance twice daily (for example, morning and afternoon sessions), the number of sessions field would indicate ‘2’ to reflect this frequency. This information provides crucial context for understanding the attendance requirements and scheduling patterns within the project.

Individual:

Added the ability to search by user UUID (Universally Unique Identifier) for individual search. This addition expands the search capabilities within the DIGIT-HCM platform, providing users with a more versatile and efficient means of locating specific individuals. A UUID is a unique identifier assigned to each user within the system. This new feature allows users to quickly retrieve information about a particular individual by entering their UUID into the search functionality. By leveraging UUIDs, which ensure each user has a distinct identifier, the search process becomes highly precise and reliable, minimising the risk of ambiguity or confusion, particularly in large datasets.

Referral Management:

Health Facility Referral Feature Update

New Feature: HF Referral

DIGIT-HCM now includes a Health Facility Referral (HF Referral) functionality that enhances the platform’s capability to efficiently manage referrals across health facilities. This addition is aimed at improving coordination and communication, ensuring a smoother referral process.

Stock Registry:

Enhance the inventory flow with the sender ID and the receiver ID added. Including sender and receiver IDs offers flexibility in handling inventory transactions within the DIGIT-HCM platform. Transactions can involve movement between warehouses, from warehouse to staff, from staff to staff, or any combination thereof. This accommodates various scenarios, such as inter-departmental transfers, internal requisitions, or supplier deliveries.

Sender Identification: The sender ID specifies the entity initiating the inventory transaction. This could be a warehouse, indicating that inventory items are being dispatched from a specific storage location. Alternatively, it could represent an individual staff member responsible for authorising the transfer of inventory items.
Receiver Identification: The receiver ID denotes the entity or individual receiving the inventory items. Similar to the sender ID, this could represent either a warehouse where the items are being delivered or an individual staff member who is the designated recipient.

Attendance:

Implemented offline-enabled functionality in the Attendance Module. Implementing this functionality in the attendance module significantly enhances the usability and reliability of the DIGIT-HCM platform, especially in environments where internet connectivity may be intermittent or unavailable.

Master Data Management Service (MDMS) & Configuration Updates

MDMS

Config

Test Cases

HCM Test Cases v1.3

Service Build Updates

Category (Tag)

Services

Docker Artifact ID

Remarks

v1.2 Release Notes

Release Summary

Health Campaign Management v1.2: The frontline worker’s App includes 8 new features that allow the frontline teams to perform their tasks efficiently even when offline.

New Feature Additions

v1.0 Release Notes

Release Summary

The Health Campaign Management V1.0 frontline worker’s app includes four new modules with several features that allow frontline teams to perform their tasks efficiently even when offline. To learn more about the DIGIT Health Platform and the Health Campaign Management (HCM) product, please follow the GitBook link.

Release Highlights

Feature

Description

Bug Fixes (Feedback from the bug bash)

Click here to access the Jira dashboard.

Known Issues

Field 'type' does not exist or this field cannot be viewed by anonymous users.
The field 'assignee' does not exist or this field cannot be viewed by anonymous users.
A value with ID '10141' does not exist for the field 'project'.
Field 'labels' do not exist or this field cannot be viewed by anonymous users.
The field 'priority' does not exist or this field cannot be viewed by anonymous users.
Not able to sort using field 'priority'.

Click here to view the feedback from the UX audit.

Product Roadmap

Find the Product Capability Roadmap below:

To see a detailed version of this roadmap, click here.

HEALTH CAMPAIGN MANAGEMENT

Understanding DIGIT Health Campaign Management (HCM)

The DIGIT Health Campaign Management (HCM) aims to expand capabilities in public health. It covers campaign setup, planning, registration and delivery, inventory management, and real-time data dashboards enabling the establishment of digital public health infrastructure for faster and cost-effective health campaigns. DIGIT HCM is designed to evolve rapidly and adapt to local needs while addressing systematic challenges. It enables decision-makers and programme managers to streamline campaign planning, manage workflows and monitor service delivery in real-time to aid data-driven decision-making.

Why do we need DIGIT HCM?

Health campaigns are a commonly used strategy that helps the routine health system prevent or control diseases by delivering essential healthcare interventions in a time-bound manner.

Health campaign management faces several challenges, which include the inability to fetch accurate population targets or monitor the campaigns in real-time and tune the campaign to the defined population needs. Lack of timely and actionable data is often the primary cause of operational inefficiency. Additional concerns relate to siloed, redundant datasets adding to the implementation costs.

There is a need for a campaign management product that offers:

Single interface for managing all components in a campaign lifecycle
Allows reuse of assets across campaigns
Reduces fragmentation by supporting multiple diseases
Supports data interoperability with other health intervention areas (Eg. disease surveillance systems)
Improves sustainability by providing ownership and control to the government
Uses a modular and standards-based architecture

The goals include:

Increased campaign effectiveness (coverage)
Reduced time to respond to outbreaks
Improved efficiency (lower costs)
Increased transparency and accountability

Watch the video below to find out how DIGIT Health Campaign Management meets the above goals and more:

Reimagine Health Campaigns with DIGIT HCM

Setup campaigns in 3 days
Run hundreds of campaigns simultaneously
Record bednet delivery in 1 minute
Real-time campaign data dashboards
Interoperability with any system
Reusable campaign setup
Data privacy by maintaining control over data from day one

Health - The DPI Approach

DIGIT is certified as a Digital Public Good (DPG) by the Digital Public Goods Alliance (DPGA) - a multi-stakeholder initiative with a mission to accelerate the attainment of sustainable development goals. Click here for more details.

DIGIT HCM is a Digital Public Infrastructure (DPI) that enables countries to transform public health campaigns.

Value Proposition

A digital partner for the frontline workers:

Better user experience for frontline workers leads to better quality data captured in less time, thus facilitating improved efficiency
The ability for frontline workers to access on-demand training, and in-app guided walkthroughs, enabling improved efficiency
Ability to use geospatial tools to analyse and identify missed households. This leads to increased coverage and identification of fraud by frontline workers

Co-pilot for managers and supervisors:

Ability to reuse campaign data for planning and executing other campaigns leading to lower costs and lower turnaround time, leading to better estimation and planning
Provide visibility into stock availability and consumption data to enable supervisors to identify leakages/ wastages and avoid potential stock-outs
Track attendance based on task completion – this provides visibility into incentives due based on attendance, reducing ambiguity in payment amounts
Ability to leverage staff registry and attendance tracking to request and release digital payments to campaign staff

Digital headquarters for national health agencies:

Quick setup and launch
The dashboard provides the ability to view better quality data in near real-time that provides actionable insights
Quick and easy integration with existing platforms and systems such as supply chain, HRMS, LMIS, and DHIS2, facilitating interoperability and coordination at scale

Free & open-source software:

Countries own and evolve digit

HCM PRODUCT SUITE

Functional Specifications

Here are the articles in this section:

Campaign Setup

Name of the field

Description

Mandatory

Input

Validation

Comments

Need data from program/state

Inventory

Name of the field

Description

Mandatory

Input

Data type

Minimum length

Maximum length

Validation

Comments

Need data from program/state

Beneficiary

Name of the field

Description

Mandatory

Input

Data type

Minimum length

Maximum length

Validation

Comments

Need input from program/state

Configurations

REFERENCE IMPLEMENTATIONs

TECHNOLOGY

Resolving Complaints

An illustrative guide to using the Complaints Module (Mobile and Web)

There is a support helpdesk set up by the program which will receive all complaints raised by system users. The support helpdesk is responsible for reviewing all the complaints in the inbox. Depending on the complaint, the helpdesk can either resolve, reject, or assign the complaint to the respective actor Helpdesk users may create complaints on the user’s behalf, which are received over call/WhatsApp messages.

User Roles

User Role

Scope of Action

Role Description

Resolving Complaints

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 appropriate action (mentioned below).

The helpdesk user must be able to do the following :

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

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.

Health Facility Referral

An illustrative guide to using the Health Facility Referral Module

This will enable the health facility supervisors to track referrals made by on-field health workers to different health facilities digitally via the Digit HCM app

Key Features

It captures all the cases of:

Beneficiary being referred.
Referral details of the beneficiary.
Reason for referrals and its diagnosis.
Based on the diagnosis chosen further details if applicable.

User Roles

User Role

Scope of Action

Role Description

Using the Health Facility Referral Management Module

User Persona: This feature will be used by workers working at a given Health Facility (HF) who will be responsible for giving the diagnosis based on the type of symptoms they observe and then do a diagnosis and provide the appropriate drugs.

Steps for Referral Flows:

Step 1:

Login for a HF worker who will see the home screen options based on the role-action mapping and will see the option which says “Beneficiary Referral“. The options available on the home screen for HF workers apart from the Beneficiary Referral option will be defined based on the role-action mapping provided for them.

Step 2:

When the user clicks on the “Beneficiary Referral” button in the previous screen, the user will be taken to the “Search Beneficiary” screen where he/she can search for a given beneficiary by their name or a QR code voucher provided to the beneficiary.

Search Produces Result: If the user searches for a given beneficiary name and finds a match, he/she can click on the 'Open' button in the card for that beneficiary and view their details.

Search Does Not Produce Result: If the search does not provide any results, the user can click on the “Create New Referral" button to add a new entry under the Referral module.

Step 3:

Once the user creates a new referral or opens an existing one in the previous step, he/she is taken to the Facility Details screen first where he/she needs to enter the details of the health facility they are in to attend the beneficiary. This screen will have the following fields:

Administrative Unit: This field will be auto-filled from the value available from the role-action mapping, and will be non-editable.
Date of Evaluation: This field will be auto-filled with system value and will be non-editable.
Evaluation Facility: This will be a mandatory field for the health facility worker to search and add. It is the ID used for a given health facility.
Name of Health Facility Coordinator: This is a non-mandatory field that will capture the name of the health facility coordinator who is attending the referred beneficiary.
Referred By (CDD Team Code): This is a non-mandatory field that will capture the CDD team code of the field worker who referred the beneficiary.

Once the user has filled all the fields with the relevant information, he/she must click on the 'Next' button.

Step 4:

After the user has clicked on submit, he/she will come to the screen called “Referral Details”. On this screen, the user is supposed to enter details into sections, that is, “Referral Details” and “What is the reason for referral”.

Section 1: Referral Details

In this section, the user must add the details to the following fields:

Select Cycle: This will be a dropdown selector which will have the cycle numbers. This is a mandatory field and cannot be left empty.
Name of the child: The user needs to add the name of the referred beneficiary. This field is mandatory.
Beneficiary ID: This will be added by the user with the beneficiary ID of the referred Beneficiary. This is a mandatory field.
Age in Months: This will be a mandatory field that will capture the age of the beneficiary being referred in months.
Gender: This is a mandatory field with a dropdown having values: Male, Female, Other.

Section 2: Reason for Referral

In this section, the user must capture the data as to why the beneficiary was referred. The field will capture data with the help of the radio button option selector. The options are:

Sick
Fever
Drug side effect in current cycle
Drug side effect in previous cycle

After selecting one of the reasons for referral, the user needs to press 'Next' which will navigate the user to 3 different screens based on what they select in the “Reason for Referral” section.

Step 5:

Based on what the user selects in the previous step in the “Reason for Referral” section, the following 3 flows could be shown to the user:

If “Sick” was chosen as a reason: If the user selects 'Sick' as the reason for eeferral in Step 4, he/she will be taken to “Referral Due to Illness” screen, where he/she will see the following list of questions:
- “Child evaluated to determine cause of illness”: This will be a mandatory question to be answered with 2 options in the form of a radio button: Yes or No.
- Enter Comment for Diagnosis: The answer to this question should be entered by the user in a free text form which will be a mandatory field.
- “Was the Child Treated?”: This question will be answered by the user using a radio button option of 'Yes' or 'No', and it will be a mandatory question
- Name and Dose of the Drug: Provide an open text field that will be mandatory.
- “Was the child admitted / transferred to the hospital due to serious illness?”: This question will have a Yes/No radio button selection for it. This is a mandatory field.

If “Fever” was chosen as a reason: If the user selects 'Fever' as the reason for referral in Step 4, the user will be taken to the “Referral Due to Fever” screen, where he/she will see the following list of questions:
- “Was the child tested for malaria?”: This question will have a Yes/No radio button option. This will be a mandatory field.
- “Result of Malaria Diagnostic Test? “: This will be a mandatory field and based on what the user answers to this question the next set of questions for the user will open up as a nested form.
  - If the user chooses 'Positive' as the answer for “Result of Malaria Diagnostic Test? then he/shewill see the following questions:
    Was the child admitted/transferred to the hospital due to serious illness?: This will be answered with a simple Yes/No radio button and will be a mandatory field.
    Child with positive malaria test treated with anti-malarial?: This will be answered with a simple Yes/No radio button and will be a mandatory field.
    Name and Dose of Anti Malarial: This will be answered with an open text form and will be a mandatory field.
  - If the user chooses “Negative” for “Result of Malaria Diagnostic Test?, then he/she will see the following questions as a nested fForm:
    “Child with negative malaria test received SPAQ in this cycle“: This will be a Yes/No Radio button question, and is a non-mandatory field.
If “Drug side effect in current/previous cycle” was chosen as a reason: If the user selects “Drug side effect in current/previous cycle” as the reason for referral in Step 4, he/she will be taken to the“Referral due to adverse drug reaction” screen, where he/she will see the following list of questions:
- Child evaluated for adverse reaction for SP and AQ?: This will be a simple Yes/No radio button in the form and it will not be a mandatory field.
- The National Pharmacovigilance has been filled out?: This will be a simple Yes/No radio button in the form, and it will not be a mandatory field.
- Was the child admitted/transferred to the hospital due to serious illness?: This will be a simple Yes/No radio button in the form, and it will not be a mandatory field.

Once all the questions in one of these flows are answered, a pop-up frame asking for confirmation will be shown for submission as shown below:

Once the user clicks on submit, he/she will see the ”Data Recorded Successfully” screen, and the option to navigate to the home screen.

LLIN Overview

Overview

The National Malaria Control Program (NMCP) transitioned to a digital system for their bed net distribution campaign in 2022/2023, moving away from their previous paper-based method. However, the team faced numerous issues with the new tool, such as synchronisation errors, data quality issues, inadequate visualization and analysis of geolocation data, and ineffective bednet tracking during the campaign.

To address these challenges, NMCP partnered with eGov to develop DIGIT HCM, a Digital public infrastructure. This collaborative effort resulted in the creation of an open-source digital public infrastructure (DPI) with interoperability and scalability. Customised as Salama (implying health in Swahili), the aim was to mitigate the above challenges and support multiple campaigns efficiently.

Salama and LLIN

Salama was rolled out as part of the Long Lasting Insecticidal Nets (LLIN) campaign for the periodic distribution of bednets in the Tete and Gaza provinces.

The main players involved in the campaigns in Tete and Gaza are listed below:

National Malaria Control Program, Mozambique: Provided overall strategic direction for the campaign, part of the Ministry of Health (MISAU).
DIS (Information System Directorate): Provided support during the requirements discussion and the implementation of the campaigns, part of MISAU.
DTIC (Information Technology and Communication Directorate): Technical team that was trained and helped manage technical training and issues during the campaign, part of MISAU.
World Vision: Implementation Partner for the BedNet campaign in Tete and Gaza.
Bill and Melinda Gates Foundation: Funder of the DIGIT HCM platform.
The Global Fund: Funds campaign implementation across Africa.

The other partners include PNCM, World Vision, the Foundation for Community Development (FDC), Food for The Hungry Association (FHA), Aid for Develop.

Besides the different players mentioned above, a core group called Nucleo Duro, consisting of members from all groups was formed to lead all decision-making aspects of campaign implementation and digitisation.

Lessons learned from the Tete implementation spurred enhancements in Gaza, and underscored the flexibility of Salama. NMCP successfully conducted campaigns with reduced eGov assistance and effectively addressed many campaign-related issues. During the campaign, NMCP noted that the platform was user-friendly for registrars, and the dashboard's clear presentation negated the need to work on different formats in M&E meetings. Notable improvements in the Gaza campaign encompassed enhanced real-time syncing efficiency, prompt access to team performance reports, and a significant decrease in incomplete records.

Key Takeaways from Salama Implementation

The NMCP highlighted the points listed below as things that went well while implementing DIGIT HCM (SALAMA):

Automatic synchronisation in areas with internet connectivity: The Salama application has enabled automatic synchronisation in intervals of 5 minutes, which resulted in near real-time data synchronisation in areas with internet connectivity. This was observed during the campaign in Gaza.
Ability to check teams' progress against daily targets: In the application, there is a progress bar that each team can use to verify their progress when compared to the target. This feature was appreciated by NMCP as it gave the local monitors the ability to check the targets and motivate the teams to achieve at least the daily target.
Automatic collection of GPS data on each Household registered: The collection of GPS coordinates for a household is done in the background of the application. Whenever a household is registered, the registrar does not have to click any button to initiate the capture of geo coordinates. This made the user experience for registrators better and was in turn well received by NMCP.
Dashboard was flexible, interactive, and user-friendly: The dashboard was used in the daily review meetings as the main monitoring and evaluation tool and saved time as it was not necessary to develop a PowerPoint presentation for those meetings.
Automatic calculation of the bednets to be delivered: The application was able to recommend the number of bednets to be delivered to a household based on the number of members, which removed the cognitive effort of the registrar to calculate these numbers by themselves.
Indication of duplications at the end of the day: The custom reports generated at the end of the day indicated duplications of registration and delivery, It further provided details of duplicate households created by the same registrar and the ones duplicated by different registrars.
Application easy to learn: During the training, it was noticed that it took less time for the trainees to understand the application and flows. Thus, the training was more practical and focused on simulation-based learning rather than on training the users on how to use the applications.

Throughout the campaign, numerous training sessions were conducted to enhance the capacity of NMCP in managing and utilising Salama, with additional capacity-building activities scheduled for post-campaign implementation. Key recommendations include linking credentials to performance, enhancing microplan estimates, improving warehouse manager training, addressing bed net scanning issues, and shifting the focus to monitoring and correcting supervision results.

In summary, the successful digitalization of Tete and Gaza using Salama facilitated accomplishing essential campaign objectives. While recognising areas for improvement, the standardised data format enabled thorough analysis across campaigns, ensuring ongoing enhancement in effectiveness and efficiency.

Health Campaign System High Level Design

Health Campaign - High Level Design

The high level design is divided into:

Master data
Registries/entities
Reusable DIGIT services
Form engine support
Multi-tenancy
Android offline first app
Web app - Campaign planning + dashboard
External integration - DHIS2

Base Health Campaign on DIGIT Core 2.8.

Master Data

Master data categorised on the complexity required to maintain them from the technical perspective.

Simple Masters
1. Roles
2. Additional field schemas for different entities
3. Project task configurations
4. Project type
5. Role-actions
6. Actions
Hierarchical Masters
1. Administrative boundary and hierarchy
Inter-Linking Masters
1. Field app config
2. Service registry

Services/Registries

Individual Registry

New service.
As users are registered to campaigns, populate the individual registry with basic information about them.
This registry is the first step towards the long term plans in DIGIT to move non users of the system away from the User service. However, due to the current dependency on User service for authN and authZ among other things, this registry will be a wrapper over the User service.

Household Registry

New service.
Collection of Individuals living together (potentially receiving shared campaign intervention).

Facility Registry

New service.
Needed to model storage Warehouses through which stock moves.

Product Registry

New service.
Needed to model the resources that are distributed as part of projects both as part of stock movement and actual distribution to beneficiaries.

Project Service

New service.
Models how services and benefits are typically distributed to citizens by governments.
Contains multiple endpoints within the service to map other entities such as beneficiaries, staff, facilities, resources to the projects.

Stock Service

New service.
Track inflow and outflow of stock resources.

Reusable DIGIT Services

Many of the DIGIT-Core services can be reused without any changes. Some of them could be extended and enhanced to support the required features.

DIGIT Services reused as-is

digit-mdms-service
Digit-location / boundary service
digit-access-control
Zuul API Gateway
digit-idgen
digit-persister
digit-indexer
digit-localization
DSS
Signed Audit

DIGIT Services reused with enhancements

No existing services being enhanced.

Workflow

The Health Campaign system does not make heavy use of workflows. Most flows in v1 are single actor and end after a single step (i.e. submitting collected data).

High-Level Design Diagram

ER Diagram

Form Engine Support

Form engine support was pushing out timelines and has been dropped from v1 scope.

Multi-Tenancy

The proposal is to have a single installation to support multiple countries and multiple health campaigns within these countries. Different campaigns will need to share registries.

Leveraging multi tenancy support in DIGIT for this.

Android App

Offline First

Android app is proposed to be modelled on mGramSeva app and will be built in Flutter.

This app will be used in areas with limited or no internet connectivity and hence will need to work while offline. Users will sync the data collected offline when they are in an area with network connectivity.

SQLite will be used to model structured data and ISAR will be used for unstructured data.

Form Renderer

Out of scope for v1.

Offline Dashboards

The field workers will need to see dashboards based on the data stored in the offline database. Library - TBD

Web App

Campaign Planning App

Out-of-scope for v1.

Dashboards App

The app will have some custom screens to capture information around the campaign plan.

DSS dashboards are planned to be leveraged for reporting dashboards.

External Integration

DHIS2

This will be added to implementation scope.

Field App Architecture

The high-level design of the HCM Framework is divided into three main parts, the details of which are available below.

Tech Stack/Core Dependencies

Flutter: Framework to build multi-platform apps

SQLite: SQL offline db

ISAR: NoSQL offline db

Dio: HTTP Client

Codebase

https://github.com/egovernments/health-campaign-field-worker-app

Design

Design Considerations for Field App

Needs to work in low/no network coverage areas.
Needs to have a high level of configurability.
Needs to work on Android.
Users of the app have low-tech literacy.

Design Features

Sync

Since the app is expected to be configurable, there is a need to receive these configurations from the server. Data already on the server might also need to be retrieved by the app.

Since the app is expected to work while users are offline, there is the need to send data that has been collected while the user has been offline to the server.

These functionalities are collectively called sync. The retrieval of configuration and data is referred to as sync down while sending data collected using the app is called sync up. Login and sync can only be done while the user is online.

When a user logs in, a sync down is performed to fetch the required configuration and data for the field app to run. After collecting data using the app, the user can perform a sync which will perform a sync-up (to send all data collected) followed by a sync-down (to retrieve any fresh configuration). Syncing of data down is not required for the initial implementation and can be turned off.

Configurability

Configurations for the field app are managed as master data in the MDMS service. These configurations are used to manage various aspects of how the app functions. The important ones are:

If the app has to run in an offline first mode or an online mode.
The backend interfaces for the app include localisation, MDMS, and various services. This also includes the URLs for the various services and endpoints so that a fresh app build is not required if there is a new version of an API.
How long the client can use each configuration that has been previously fetched before requesting data from the server (to optimise the time taken for sync).
Values/options that need to be displayed in various fields in the app.
Additional fields are to be captured for any of the entities, if any.
Supported languages.

Op Log

Any action to create or update the data performed by the field user while the app is configured to run in the offline first mode is written to an op log. When the user performs a sync, the sync-up action reads from this op log to send the data to the server.

Permission (role-action)-Based Access and Sync

Sync is optimised to fetch configuration relevant to the logged-in user so that only the configuration/data for the actions, permissible to the user within the projects that they are assigned to, are fetched.

Network Manager

The network manager component in the app acts as an interface between the rest of the app and the backend. As a result, the other components in the app do not have to change their behaviour based on whether the app is online or offline and rely on the network manager to handle this complexity. This implies that the network manager makes an API call directly if the app is offline or saves to the local database and the op log if the device is offline, whereas the other components just make a call to the network manager to read/write data.

Down Sync of Beneficiaries

The down sync of beneficiaries feature is designed to optimise data synchronisation between the local device and the server, specifically focusing on the beneficiary records. This process helps prevent duplicate record creation by different users within the same boundary.

The down sync initiates by sending a request to the server, providing the boundary code along with offset and limit parameters. The server validates the provided parameters and responds with the total count of beneficiary records within the specified boundary.

Based on the total count received, the down sync retrieves beneficiary records from the server in batches. The batch size is dynamically adjusted according to the device's internet speed to optimise the data transfer.

The response from the server, containing beneficiary records, is written to the local entities tables on the device. This ensures that the local database stays updated with the most recent beneficiary information.

Key Features

Utilises offset and limit parameters for efficient pagination of data retrieval from the server.
Adapts the batch size based on the internet speed to enhance the overall synchronisation performance.
Essential for avoiding the creation of duplicate beneficiary records by different users within the same boundary.

Use Case

The down-sync of beneficiaries is particularly crucial in scenarios where multiple users operate within the same geographical boundary. It ensures that each user has access to the latest beneficiary data while minimising redundant record creation.

Multi-Round Campaign

The multi-round campaign streamlines beneficiary registration and delivery processes, ensuring efficient tracking of eligibility and delivery statuses across multiple cycles.

The system fetches the projectType configuration from MDMS for the selected project.

Eligibility checks are dynamically performed based on the retrieved projectType configuration.

The minimum and maximum age criteria are evaluated to determine the beneficiary's eligibility for the current cycle.
Recorded side-effects for the beneficiary in the current cycle.
There is no cycle defined in the MDMS configuration for the selected project on the current date.

Status Tracking

Not Eligible:

The minimum and maximum age criteria are evaluated to determine the beneficiary's eligibility for the current cycle.
Recorded side effects for the beneficiary in the current cycle.
There is no cycle defined in the MDMS configuration for the selected project on the current date.

Beneficiary Refused: Indicates that the beneficiary refused to accept the delivery in the current cycle.
Beneficiary Referred: Indicates that the beneficiary was referred to a health facility during the current cycle.
Visited: Indicates that a delivery was successfully made for the beneficiary in the current cycle.
Not Visited: Indicates that no delivery was made for the beneficiary in the current cycle.