Implementation Planning¶

This chapter provides considerations and guidance on planning for the use of DHIS2 as a digital platform to support data-driven health campaigns capable of providing real-time insights to campaign managers, programmes and local health departments. Implementation strategies should be tailored to each country context and should consider the characteristics and types of health campaigns that will be implemented in the country

Data collection planning¶

Guiding questions for planning modalities of data collection & reporting¶

Most health campaigns used mixed modes of data collection, including paper-based and electronic reporting tools. Offline data capture is often a key requirement in low-resource settings and has major implications on planning the design of an integrated health campaign data platform that functions as needed in your country setting. Below are some guiding questions as you begin planning your digital campaign monitoring system:

● Who will collect data, for different activities and different levels at different points of the campaign?

● What is the digital literacy of these users? Are users already familiar with DHIS2 or other electronic tools?

● What data collection tools & forms are required for each component of the campaign (e.g. household enumeration, (paper based reporting tools, tally sheets, mobile devices)

● Are paper-based tools and electronic reporting forms in DHIS2 aligned? If there are changes made in DHIS2, how will the paper-based tools be updated & distributed?

● Who is responsible for validating the data and reporting official numbers upwards (at the operational planning level, district level, national level)?

● What is the minimum data needed for real-time monitoring during the campaign? Have data collection points been mapped to monitoring indicators and dashboard outputs?

● What is the ideal frequency for monitoring? Define concrete needs and specific indicators for real-time monitoring: is this conducted daily? Hourly? Is it feasible for data collection?

Real-time vs secondary data entry¶

In general, implementers can expect that data collected in real time on mobile devices or web can be synced to the server in near real-time as long as there is connectivity. In offline settings, implementers need to consider when users will have access to internet to sync data.

It’s important for campaign planners to define precisely what is needed for “real-time” analysis for system designers and implementers to develop responsive but realistic solutions. All data collected during the campaign is typically not needed nor feasible for monitoring minute-by-minute. Prioritizing the key monitoring metrics and the frequency they are needed at the onset of the planning process helps to ensure the system is designed to allow users to sync data for active monitoring throughout the campaign (such as daily targets, campaign worker performance, etc) within the constraints of your operating environment and implementation budget.

Tracker and individual level implementations: planners should consider the amount of time needed for users to enter individual level data into the mobile app and balance the utility of that data for real-time monitoring functions. In addition, planners should minimize the duplication of reporting to maximize efficiency – such as avoiding requirements for users to enter data into Excel and also into DHIS2.

Secondary data entry: For many campaigns, populating key indicators on a daily basis is sufficient for real-time monitoring during the campaign implementation. These indicators can easily be populated through basic aggregated reporting, which can be particularly useful in settings where paper-based tools and tally sheets are still being used for primary data collection and entered into DHIS2 as aggregate datasets.

For more information, see the Tracker implementation guide chapter:

• Real-time vs secondary data entry

Web-based & mobile reporting¶

DHIS2 natively supports multiple modes of electronic data collection & transmission. Note that this list does not consider non-DHIS2 applications and tools, which are mentioned separately in the section Planning for Interoperability.

● Web-based data collection: using the core DHIS2 Data Entry and Capture apps or custom applications developed on top of the platform

● Mobile data collection: using the native DHIS2 Android Capture application or custom mobile applications developed using the DHIS2 Android SDK

● SMS and USSD: this type of reporting is supported when an appropriate gateway is configured using the DHIS2 SMS configuration app

In evaluating and selecting appropriate reporting modes for different types of users throughout the campaign lifecycle, we suggest to consider:

● Internet access and mobile coverage

● Fixed vs mobile service delivery points

● Availability of existing devices, laptops and hardware that can be repurposed/made available for use during campaign activities

● Digital literacy of the users

For additional guidance, please see:

● Web vs Mobile implementations

Aggregate vs individual data collection¶

Most DHIS2 deployments have components of both aggregate and individual (tracker) data which work together as part of a comprehensive campaign information system. Even when Tracker is used for individual level data collection, the aggregate data model is nearly always used in tandem for components such as target setting, population estimates and other denominators essential for planning and monitoring. While the majority of health programmes typically prefer to capture all individual data electronically, it is rarely feasible or cost-effective to do so without making substantial trade-offs (such as shifting campaign budget allocation from other aspects). There is no one-size-fits-all solution for all countries, but rather this decision requires discussion and consensus among stakeholders about limitations within the implementation context, trade-offs and priorities.

Hybrid approaches & aggregate data for real-time monitoring¶

Many countries have successfully implemented successful real-time campaign monitoring systems using only aggregated data during the campaign deployment (Uganda measles/polio, Bangladesh). Daily reporting on a minimum set of aggregate data can be effective and cost-efficient for delivering real-time insights to campaign planners during the deployment phase, reallocating resources for the next day, checking on logistics and staff levels, etc. When real-time Tracker data entry is not feasible, these data are often not “usable” for real-time monitoring due to data entry backlogs or inability to sync data. Some campaign planners may prioritize having access to a complete set of minimum core metrics at least daily, rather than facing gaps in visibility for administrative areas that are not able to keep up with individual reporting.

If real-time data entry is not feasible, DHIS2 Tracker can be implemented alongside an aggregate real-time monitoring solution if there is a strong motivation for maintaining these records electronically beyond the campaign implementation period. For example, some countries may not be able to monitor an immunization campaign with Tracker in real-time but still wish to capture the data necessary to update a child’s electronic immunization registry (EIR) post-campaign.

We encourage implementers to consider hybrid approaches that prioritize the availability of data when it is needed; while providing granularity through Tracker/individual data where feasible and most important. provided there are sufficient resources for secondary data entry. This hybrid approach allows for detailed individual-level tracking while ensuring that key summary indicators remain available for immediate decision-making.

Assessing readiness for Tracker and individual level data¶

The decision about whether to configure and use DHIS2 for individual data collection (e.g. by using the Tracker data model) for various aspects of campaign data collection has many considerations. We recommend revisiting, updating or conducting (if never completed) the DHIS2 Maturity Profile with the MOH to understand readiness for Tracker and if there are gaps that can be strengthened by using DHIS2 as part of integrated health campaign digital infrastructure.

● Availability of robust infrastructure, reliable hosting arrangements and qualified human resources dedicated to server monitoring & management. Note that cloud vs on-premise hosting alone is not sufficient to make this determination; there are many factors to consider within the hosting arrangements and division of responsibilities for hardware (physical servers) vs. monitoring and administration.

● Availability of network connectivity at the point of electronic data collection

● Feasibility and cost of training end users and data entry staff

We also recommend the following resources:

• Tracker Implementation Guide

• DHIS2 Maturity Profile

• Virtual Training: Tracker Readiness Assessment & Country Experience Sharing

• Virtual Training: Tracker Planning & the DHIS2 Maturity Model

Mobile deployments¶

Implementing DHIS2 for health campaign data often entails the use of mobile devices and special considerations for offline settings. The DHIS2 Android Capture app is the native DHIS2 application supported for this function. Implementations may also use mixed reporting methods that incorporate SMS or even USSD reporting in low-connectivity settings for key real-time monitoring data.

When planning to incorporate mobile devices into your health campaign data system, consider the following:

● Device provisioning: Will users use their own devices (bring-your-own-device)? Will the project procure devices specifically for this campaign? How will assets be tracked and managed?

● Compatibility: Are all devices compatible with the necessary Android OS for compatibility with the DHIS2 Android app version and DHIS2 version to be used during the campaign? Ensuring that all necessary mobile devices are available and pre-configured with the DHIS2 application.

● SIM Cards and data bundles: often required to provide to users for syncing data. Implementation plans should include adequate budget for the cost of data bundles and a plan for distribution and replenishment throughout the campaign.

● SMS costs: SMS often incurs costs that should be budgeted as part of the campaign plan. Some countries have successfully negotiated agreements with mobile carriers to reduce or provide these services free of charge for government-authorized use of SMS for reporting.

● Device security: Implementing authentication mechanisms, remote locking, and data encryption to prevent unauthorized access.

● Battery life and charging solutions: Deploying power banks or solar chargers in low-resource settings and hard-to-reach areas. These can be planned along with the operational units of the campaign.

● User training: what types of user training required may also depend on the devices used and the users’ existing familiarity with these devices and the DHIS2 Android application.

● Server performance implications: Defining a synchronization strategy and ensuring the server hardware and bandwidth specifications can handle large peaks based on testing before the campaign. Large-scale campaign implementations often see a peak period of time where users sync their offline data with the server (such as at the end of the day). Using server monitoring tools throughout the campaign will help admins to identify and address bottlenecks; server logs can also be highly useful for admins troubleshooting syncing errors.

DHIS2 Android Capture App¶

If you are planning to use the DHIS2 Android Capture app in your implementation, we recommend to visit and review:

● DHIS2 Android Mobile Implementation Guide

Special considerations for Android & campaign use cases¶

Testing your configuration for Android

It can be difficult to simulate real-world performance on a new configuration when real users and data have not been entered. One benefit of an integrated campaign design is that the country can learn from each campaign experience and implement common strategies for testing & optimizing the DHIS2 configuration for Android deployment. Key considerations for testing that often impact users and performance on the hardware include the following. Time-checking these steps during testing can also inform expectations about how much time campaign workers will spend on reporting; and scheduling appropriate time for data syncing, device preparation, etc.

● Loading org units

● Executing program rules and validation rules

● Loading large option sets

● Loading TEIs that need to be stored and accessed offline from the device

Mobile device specifications

We recommend that you review the DHIS2 Android mobile device specifications for the most up-to-date guidance on minimum and recommended specifications for procuring Android devices**.**

The amount of RAM available on devices has a direct impact on performance, especially when many tracked entity instances (TEIs), events, or large option sets are stored offline. For large-scale mobile Tracker implementations – especially those in offline settings – we recommend to plan and budget for sufficient RAM (more than 2GB). It is always important to test your configuration against devices to understand realistic performance in your setting; however, the amount of RAM you may need for expected performance can be impacted by:

● Number of records expected to be stored offline on the device;

● Number of org units assigned to a given user;

● Program rules and validation logic

● Very large option sets

In addition to RAM, also consider:

● Battery capacity and charging options in field conditions

● Android version compatibility with your DHIS2 app and server

● Storage space, particularly when media files (photos, attachments) are collected

● GPS module performance, especially if location accuracy is important

Field Insights: It is not uncommon for DHIS2 Android Capture implementations for health campaigns to require storage of 1,000-10,000 or more TEIs on their device while working offline; or have hundreds of organisation units assigned to one user (such as a mobile campaign worker who travels between many distribution sites). When implementing Tracker, implementers and planners benefit from estimating the number of org unit assignments, campaign workers, users, expected TEIs and events as early on in the campaign planning process as possible to provide the optimal DHIS2 and device conditions for the intended scale.

Submitting Data via SMS & USSD¶

DHIS2 supports the configuration of an SMS gateway, which can be configured and used to support SMS reporting from handheld devices in low-connectivity settings.

DHIS2 also supports structured data entry captured on Android devices to sync with the DHIS2 server via SMS the ; however,messages must follow a specific syntax to be correctly interpreted and integrated into the system. To simplify this process, the DHIS2 Android App can also act as an intermediary, automatically formatting and sending SMS messages without requiring users to manually structure them. However, to enable SMS transmission, the SMS gateway must be correctly configured.

This configuration is managed via the Android Settings Web App (ASWA), where administrators can enable SMS mode, set encryption preferences, and determine fallback behavior. You can find the configuration details in the Android Settings App Guide.

From the user’s perspective, SMS-based syncing behaves differently from standard mobile data synchronization. Once configured, the app allows users to send records via SMS, and view the sync status through the app interface. The full description of how this works can be found in the Android User Guide.

When using SMS reporting at scale, be sure to test message size and delivery speed with the chosen mobile operator, as limits on character count or gateway latency may affect performance. When relying on SMS data reporting from handheld devices (e.g. not using the DHIS2 Android app/non-smart phones), implementers and campaign managers should consider the feasibility of data collection points, including data quality and estimated time spent reporting for these users.

Note that sending data via SMS often incurs costs that should be budgeted as part of the campaign plan. Some countries have successfully negotiated agreements with mobile carriers to reduce or provide these services free of charge for government-authorized use of SMS for reporting.

The following guidance documents can further support integrating SMS reporting or data transmission in your implementation:

● Configuring an SMS gateway with DHIS2

● Guide to SMS configuration in the DHIS2 Android Settings web app (required for DHIS2 Android Capture to work with SMS transmission)

● How SMS sync works in Android from the user perspective

Mobile Device Management (MDM) & APK Distribution¶

Although the use of a Mobile Device Management (MDM) system is not mandatory, it is strongly encouraged and should be considered during budgeting for any mobile deployment. An MDM can significantly enhance device control, security, and user experience. An MDM enables centralized management of all devices used in the campaign, allowing administrators to ensure that each device is running the correct version of the DHIS2 App and other required software, while enforcing organization-wide security policies. It can also ensure specific device settings are forced on (such as geolocation services), limit and/or monitor the use of data, and distribute files such as SOPs, training videos, or other job aids for offline access directly from the device.

These benefits are particularly pronounced in campaign use cases:

● Deploying large numbers of devices: MDM simplifies the setup and software update processes for applications and configurations.

● Devices are geographically dispersed or difficult to retrieve: MDMs enable pushing remote software updates or security measures remotely.

In cases where a full MDM solution is not feasible or needed, DHIS2 also provides the APK Distribution Web App—a lightweight, campaign-friendly alternative for securely distributing the DHIS2 Android App. This tool allows implementers to centralize specific APK versions on Android devices without relying on the Google Play Store. It supports installation via secure HTTPS links or local networks, making it ideal for disconnected settings or countries where Play Store access is restricted. It also ensures DHIS2 app version updates are not automatically triggered by the Google Play Store, keeping only fully tested versions deployed on devices to ensure no bugs are inadvertently introduced.

Please see the additional resources:

• Implementing an MDM
• DHIS2 APK Distribution Web App

User Acceptance Testing (UAT)¶

Conducting a User Acceptance Test (UAT) with a small yet representative sample of end users is highly recommended before full-scale user training. This process helps ensure the configuration is optimized for usability, efficiency, and user experience. A well-executed UAT minimizes usability challenges, streamlines workflows, and improves overall system adoption.

Pre-UAT Preparation¶

Prior to conducting the UAT, implementers, testers, and designers should:

● Map each end-user workflow to understand how users will interact with the system.

● Internally test the configuration to identify and resolve basic usability issues before engaging end users.

● Ensure system stability by addressing any configuration inconsistencies, accessibility concerns, and performance issues.

Key Components of the UAT¶

During the UAT, the following activities should be considered:

Observation-Based Testing

• Observe users as they walk through each step of their assigned workflows.

• Identify potential usability barriers and areas for system improvement.

Performance and Efficiency Evaluation

• Record the time taken to complete tasks within the workflow.
• Identify unnecessary steps, bottlenecks, or inefficiencies that slow down data entry.
• Note any errors encountered and assess their impact on usability.

Structured Documentation and Feedback Collection

• Test workflows with a diverse sample of users from each user group (e.g., data collectors, supervisors, administrators).
• Document any recurring patterns, feedback, and challenges faced by different user groups.
• Collect qualitative feedback on overall system usability, clarity of instructions, and workflow logic.

Iterative Re-Testing and Optimization

• Refine the system configuration based on UAT findings.

• Conduct re-testing with the same or new users to validate improvements.

• Ensure all major usability concerns are resolved before proceeding with broader user training and deployment.

Post-UAT Considerations¶

A well-structured UAT process plays a critical role in ensuring that the system is intuitive, efficient, and ready for large-scale implementation, reducing post-deployment issues and increasing user confidence.

• Develop UAT summary reports to document findings, recommended changes, and system optimizations.
• Use insights from the UAT to enhance training materials and onboarding sessions.
• Ensure final workflows align with end-user needs while maintaining data security and compliance.

Infrastructure, hosting & security¶

Planning for volume, scale and performance¶

Do I need a separate DHIS2 instance for campaigns?

For large-scale, high-volume health campaigns, it is generally recommended that a dedicated DHIS2 instance separate from the stable HMIS (if in use in a given country) is used for health campaigns. Each country should analyze possible architecture for leveraging DHIS2 (and other systems) as part of an integrated health campaign digitalization approach. The benefits of having a separate DHIS2 instance for health campaign operations include:

● Greater flexibility in adjusting the org unit hierarchies for the lowest levels, such as distribution points and sub district operational units

● Managing volume and performance: campaign instances are often at higher risk of poor performance during peak data synchronization periods; a dedicated DHIS2 instance and adequate infrastructure can mitigate disruption to routine HMIS reporting

● User management & access: campaigns often require user management at scale, often with users that are not typically part of the routine public health information system

The principles of integrated system design can be applied to integrated health campaign platforms such as DHIS2 in a similar manner to the HMIS functioning as an integrated routine health facility data system. An integrated digital campaign platform would be designed to accommodate campaign interventions across different types of health programs, allowing for the sharing and reuse of data (particularly “expensive” datasets such as household mapping/enumeration at the community level).

Key data and indicators such as campaign coverage rates can be integrated back into the HMIS post-campaign for triangulation and analysis with other routine health data. This approach helps preserve the stability of routine HMIS operations, preventing disruptions in routine reporting—especially in contexts where national HMIS instances are hosted on-site with limited infrastructure, often relying on a single server.

Hosting & server monitoring¶

Cloud-based vs on-premise

Cloud-based hosting has several distinct advantages for campaign implementations given the possibilities to rapidly scale up to additional machines, adjust resources, etc etc to be be responsive and handle high volumes typically seen during times of peak reporting or data synchronization (for example: when all campaign teams are expected to sync the data they collected offline at the end of the day). as it enhances performance and scalability by distributing workloads across multiple physical or virtual servers.

Where cloud-based hosting is not permissible under national policies, on-premise solutions can be implemented if a strong server admin team and adequate physical infrastructure are available. This is often challenging for Ministries of Health and government partners in low-resource settings.

Server administration & performance monitoring

To ensure system stability and responsiveness, server monitoring tools should be implemented. These tools allow administrators to track performance metrics in real-time, identify bottlenecks, and make necessary adjustments throughout the campaign.

For guidance on server hosting, administration, and monitoring, please refer to:

● DHIS2 hosting guide

● DHIS2 server monitoring: using Prometheus and Grafana

For large-scale campaign implementations – especially those using DHIS2 Tracker for individual data collection – we also recommend:

● DHIS2 Performance at Scale: Implementation & server admin guide

Guiding Questions for Infrastructure Planning¶

Implementation planners should work with server admin specialists early on in the campaign planning process to assess the needs for server hosting to handle the volume and unique characteristics of the country’s deployment; as well as to ensure that server monitoring tools are in place and human resources are allocated to this function. The following are typical guiding questions that can be used to provide key information about your implementation to those responsible for server administration & backend performance monitoring:

Data Model

● Aggregate, Tracker (including event programs) or hybrid?

If Tracker is Used:

● How many Tracked Entities are expected?

● How many Tracked Entity Attributes will each entity have?

● How many enrollments and events are expected?

● How many enrollments and events will each user need stored offline (if using mobile devices)

Organizational Unit Structure

● How many organizational units (OUs) will be included?

● How are OUs distributed in the hierarchy? (Well-balanced or concentrated in certain areas?)

● How many hierarchical levels will be used?

● Will data entry occur at multiple levels or only at the lowest level?

● Will some OUs be significantly more active than others, or is activity evenly distributed?

User Management & Performance

● How many concurrent users are expected?

● What is the distribution of users based on their function or role?

○ How many users are configured for aggregate data entry vs. tracker data entry?

○ How many users will have access only to dashboards and analytics apps?

● Do all users have access to all OUs, or are there restrictions? If restricted, what are the criteria?

Data Volume & Processing

● How many data values are expected?

● What is the expected volume of data for tracker vs. aggregate reporting?

Insights from the field: The Bangladesh measles mass campaign needed to support and maintain a total of 403,765 microplan-related OUs, daily vaccination data, and a total of 16,000 user IDs. With such scale, the campaign provided DHIS2 core developers access to a restricted set of anonymized data in DHIS2 to support performance and stress testing against large databases. The result of such assessments translated into significant improvement in the memory usage of API and performance fixes on tracker (in combination with OUs and user access) as a secondary cascade impact of the primary tests on aggregate*

Data Privacy & Security¶

Properly structuring user access and permissions is fundamental for both campaign workflow efficiency and data protection. Campaigns often involve multiple stakeholders who may have access to digitized data, increasing the risk of unauthorized data sharing. This concern is particularly critical when using DHIS2 Tracker, where individual-level data is recorded. However, data security protocols must also be in place for both aggregate and individual data.

Key security considerations include:

● Role-based data access: Restrict access to sensitive data based on user roles.

● Data encryption: Ensure secure storage and transmission of data.

● Audit logs: Monitor user activity to detect and prevent unauthorized access.

● Secure authentication: Implement strong authentication protocols to prevent account misuse.

For a more comprehensive approach to security, refer to the DHIS2 guidelines on security considerations, which provide context-specific advice and best practices for ensuring data security and user management within DHIS2.

Planning for Interoperability Requirements¶

Data collection using non-DHIS2 mobile applications such as ODK and KoboToolbox is also feasible, but successful implementation requires a strong technical team to manage interoperability and has the mandate and access required to test, fix and assure data exchange between systems. Establishing robust metadata governance is essential for maintaining data consistency and compatibility across platforms. Ongoing maintenance and metadata management in both DHIS2 and external tools is necessary to ensure that any changes to one application does not disrupt the flow of information established through the interoperability solution; and that changes are coordinated and tested across both systems/tools before deployed in either or both. This means that if other mobile data collection tools are used and being administered by implementing partners or other non-MOH organizations, there need to be clear roles and responsibilities for each tool to coordinate the data integration with the national DHIS2 system. This process is not only technical, but requires people with the right skills, mandates, and access rights; and processes for establishing and maintaining the interoperability solution.

For more information, please refer to:

● General information about extensibility and interoperability with DHIS2: https://dhis2.org/features/extend/

● DHIS2 and Integration concepts

● DHIS2 Web API documentation

● DHIS2 Android SDK: a freely available resource for developers to extend and customize Android applications that sync natively with DHIS2

End User Support & Help Desks¶

A well-structured HelpDesk is critical for ensuring smooth operations during campaign implementation. Key components include:

● Support structure: Establishing tiered support levels (e.g., field-level support, national support desk, technical teams).

● Issue tracking: Implementing ticketing systems for monitoring technical issues and ensuring timely resolution.

● Communication channels: Providing dedicated phone lines, messaging platforms, and email support to assist users.

● User guidance materials: Developing FAQs, user manuals, and troubleshooting guides tailored to campaign needs.

● Monitoring and evaluation: Continuously assessing HelpDesk effectiveness and making improvements based on feedback and issue trends.

By addressing mobile device management and HelpDesk operationalization, DHIS2 implementers can enhance data quality, improve user experience, and ensure seamless campaign execution.