DHIS 2 Tracker Implementation

Guide

Applicable to 2.34 version

DHIS 2 Documentation team

August 2020
DHIS 2 Tracker Implementation Guide Applicable to 2.34 version

Copyright © 2006-2020 DHIS 2 Documentation team

August 2020

Revision History
2.34@0f1af22 2020-08-07 13:52:40 +0200

Warranty: THIS DOCUMENT IS PROVIDED BY THE AUTHORS ‘’AS IS’’ AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT
SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS MANUAL AND PRODUCTS MENTIONED HEREIN, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

License: Permission is granted to copy, distribute and/or modify this document under the terms
of the GNU Free Documentation License, Version 1.3 or any later version published by the Free
Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the source of this documentation, and is available here online:
http://www.gnu.org/licenses/fdl.html

2
Table of Contents Applicable to 2.34 version

Table of Contents
1 Target audience
2 Introduction
2.1 What can Tracker be used for?
2.2 Example Tracker Use Cases
2.2.1 Pre-configured Tracker Packages
2.2.2 Botswana: Nutrition and Immunization Program
2.2.3 Ghana: HIV/ART and other eTracker modules
2.2.4 Palestine: Maternal and Child Health eRegistry
2.2.5 Zimbabwe: National Malaria Control Program
3 Is My Project Ready For Tracker?
3.1 Readiness questions and key considerations
3.2 General considerations
3.2.1 Institutional buy-in and support
3.2.2 Funding
3.2.3 Legislation and policies
3.2.4 Capacity and competence
3.2.5 Infrastructure
3.2.6 Security Considerations
4 Building your Tracker Program(s)
4.1 Determining Scale
4.2 Design and configuration process
4.3 Determining your M&E Framework
4.4 Real-time vs secondary data entry
4.5 Mobile vs Web
4.6 Human Resources and IT Support
4.6.1 IT support unit
4.7 Hosting
4.8 Training and Rollout
4.9 Relating Tracker to your Aggregate Data System

3
1 Target audience Applicable to 2.34 version

1 Target audience
The target audience for this guide are those who are wondering if DHIS2 Tracker is the right fit
for their needs, and for those working with planning, budgeting, or managing a Tracker
implementation. This includes prospective system owners, project managers, decision makers,
and donors, as well as those responsible for configuration, training and support. The guidance in
this document was derived from a number of existing use cases, which are referenced
throughout. It should be referred to in conjunction with the rest of the documentation found at
docs.dhis2.org.

Recommended changes and improvements to this guide can be made by following the process
described in the DHIS2 github.

4
2 Introduction Applicable to 2.34 version

2 Introduction
Tracker is the app within the DHIS2 platform that enables the capture and use of individual,
longitudinal data. The functionality of Tracker covers a wide spectrum of needs, from monitoring
the quality and availability of water wells, to collecting student attendance in a classroom, to
capturing patient data in a shared health record. For the purposes of this guide, many of the
examples will come from health systems, although Tracker is widely used also for education
systems, environmental systems, logistics, and more.

Many countries and programs are making use of increased network availability and the
widespread presence of mobile devices and other hardware to push information systems closer
to the level where primary data are generated. Individual-level data adds granularity and nuance
to information systems, providing opportunities for ad hoc analysis, shifting indicators over time,
and improving data quality. Beyond its usefulness for reporting and analysis, individual-level data
can also be used to eliminate reporting redundancies, empower lower level staff with better
decision-making tools, and place the client at the center of the information system. In short,
individual-level data is the smallest data unit, and as such can be repurposed in many ways to
satisfy the various competing needs in national information systems.

The purpose of this guide is to help determine if Tracker is the right fit for a potential use case,
and provide practical guidance to help plan for successful implementations. The use of Tracker at
a large scale introduces additional factors that should be planned for beyond what may already
be in place for an existing aggregate DHIS2 instance. The opportunities and potential benefits
from information systems increase as a system goes from aggregate data → tracked anonymous
data → data from identifiable individuals → real-time patient data at the point of care. Those
planning for a Tracker implementation should recognize that the challenges increase along with
the benefits.

This implementation guide will provide recommendations to help you:

• determine if Tracker will address your needs

• evaluate the readiness of your setting for the introduction of individual-level data
collection
• understand how implementing Tracker differs from DHIS2 aggregate
• appreciate the concerns specific to individual-level data systems, including privacy and
security
• review lessons learned and best practices derived from real-world use cases
• plan for the introduction of your Tracker program(s) at at the desired scale
• set in place the infrastructure that will maintain a Tracker program over time

The guide is broken into two basic sections:

• Is My Project Ready For Tracker? describes five important contextual factors that should be
well understood for your setting before proceeding with planning a Tracker
implementation

◦ Institutional buy-in and support

◦ Funding
◦ Legislation and policies
◦ Capacity and competence
◦ Infrastructure

• Building your Tracker Program(s) provides specific guidance and recommendations for
nine different aspects of a Tracker implementation

◦ Determining scale

5
2 Introduction 2.1 What can Tracker be used for?

◦ Design and configuration process

◦ Determining your M&E framework
◦ Real-time vs. secondary data entry
◦ Mobile vs web
◦ Building supporting HR infrastructure
◦ Hosting
◦ Training and rollout
◦ Relating Tracker to your aggregate system

Links of specific planning tools are provided throughout the document, and in the appendix.

2.1 What can Tracker be used for?

As with the rest of the DHIS2 platform, Tracker has a generic data model that allows it to be
configured by the user for many different purposes. At its most basic, Tracker allows the user to
define a particular kind of thing (person, commodity, lab sample, catchment area, etc.) that they
want to follow over time (a tracked entity), define the data that they want to collect about this
entity (data elements), place the data elements in a specific order and with any accompanying
conditions or logic (program, program rules), and determine the analytics that should be
produced (program indicators, event reports, data visualizations, etc.)

An example of a simple Tracker program could be a program for collecting malaria case
information at the point of care. The tracked entity would be a person, defined by attributes such
as first name, last name, date of birth, or village. The program would contain data elements such
as symptoms, test used and result, treatment provided, etc. These data elements might have pre-
configured options for possible responses, such as possible tests available, or logic helping to
ensure data quality, such as possible minimum and maximum values for a given data element.
The data collected would be visible to the clinical user as a part of the malaria patient’s shared
health record, but could also be used to generate monthly reports required by the national
malaria control program, provide decision support to the clinician, generate SMS reminders to
the patient to promote adherence to treatment, or populate a clinic-facing dashboard containing
key performance indicators. For all these purposes, the data were collected only once – during
the patient visit – but were reused many times for different needs.

DHIS2 also supports the collection of individual data without longitudinal tracking, using the
Capture and Event apps. Non-longitudinal tracking will be referred to throughout this
documentation as well, and follows most of the same data model as tracker, with the exception
of defining a tracked entity, which is not a required part of non-longitudinal tracking. An example
of such an event program could be the reporting of the same malaria data from individuals as in
the previous (tracked entity) program, but without linking these data to a specific patient. As
such, the data would not become a part of a shared health record (or perhaps not used to
generate SMS message reminders to the patient, or other features that rely on tracking an entity
over time) but the various other uses of the data could still be utilized.

As can be seen from the examples above, Tracker and the collection of individual data are quite
different from traditional aggregate reporting for Health Management Information Systems
(HMIS). Only one of the potential uses described above are satisfied by aggregate data collection
– that of monthly reporting – whereas the patient-, clinician-, and facility-facing uses only become
possible through the collection of individual data.

Even with regards to routine reporting, the collection of individual data introduces opportunities
for improved data interpretation and analysis, and – crucially – for action to be taken. For
example, an aggregate report might show that overall immunization coverage is 80%, but lacks
detail as to whether the remaining 20% reflects errors in reporting, unintentional exclusion of
certain individuals (geographic or groups), or other factors. The aggregate numbers also do not
allow for the specific identification of non-vaccinated children that could be followed up with

6
2 Introduction 2.2 Example Tracker Use Cases

through a targeted outreach program. The aggregate numbers in this example address a basic
need of ministries of health to report national progress on a global indicator, but not the needs
of immunization program managers or providers to take specific actions to improve coverage.

One inherent benefit to using Tracker as your individual level system is its alignment with the
existing aggregate DHIS2 system, which is already used in most lower- and middle-income
countries for their HMIS. Unlike a standalone Electronic Medical Record (EMR) or other
application, Tracker encourages the collection of structured data that can natively aggregate
upwards and be fed into the national HMIS, thus replacing secondary data entry and aggregation
with primary source data.

As a core component of the DHIS2 platform, Tracker is updated twice annually along with the rest
of the DHIS2 software. The driving inputs for improvements to Tracker come from real-country
implementations, and are aligned with global recommendations, notably the WHO Guidelines on
Digital Interventions for Health Systems Strengthening. Of the ten recommended interventions,
Tracker has specific functionality to support the following:

• Birth notification
• Death notification
• Stock notification and commodity management
• Targeted client communication
• Health worker decision support
• Digital tracking of client’s health status and services combined with decision support
• Digital tracking combined with decision support and targeted client communication
• Digital provision of training and educational content for health workers

Taking full advantage of such features requires that the data collected are systematic and
uniform. In health care, primary and public health services that are strongly driven by fixed
guidelines and workflows are particularly suited for Tracker programs. For example in Antenatal
Care (ANC), most countries have guidelines with algorithms for screening and patient
management in response to test findings that can be incorporated in Tracker to follow a routine
clinical workflow, supporting both the care provider and the reporting needs. In more complex
areas of health care, with less documented and well-defined decision algorithms (such as in a
referral hospital, for example) Tracker may be best used for simple data collection, allowing the
clinician to determine the best use of the data for patient triage, and allowing the standardized
data elements to be used for additional reporting or other purposes.

2.2 Example Tracker Use Cases

Throughout this guide, we will refer to example use cases to give real-world examples of planning
principles, decision points, software and data utilization, common hurdles and issues, and
lessons learned at different stages of the Tracker planning and implementation process. A short
introductory summary of these individual use cases is provided here. Greater detail for some of
the use cases can be found on www.dhis2.org.

2.2.1 Pre-configured Tracker Packages

Under the WHO’s Analysis and use of Health Facility Data toolkit, pre-configured Tracker
programs have been created to cover a series of health topics. These packages are intended as
the starting point for country programs, allowing for further configuration to match local context,
while retaining global standards for indicators and practice. They can be added to existing DHIS2
systems, either together or individually. These packages can be accessed at the link above, as
well as at who.dhis2.org. The current pre-configured packages cover the following topics:

• Adverse Events for Immunization

• Birth, Stillbirth and Death Notification for CRVS
• Cause of Death (including ICD-10 codes from the start-up mortality list)

7
2 Introduction 2.2.2 Botswana: Nutrition and Immunization Program

• Malaria Breeding Site Investigation

• Malaria Diagnosis, Treatment, Case and Household Investigation
• Malaria Foci Investigation
• Mass Immunization Campaigns
• Routine Immunization Registry
• TB Case Surveillance

Additional packages that are still under development can be accessed at https://who.dhis2.org/
documentation/work_in_progress.html.

2.2.2 Botswana: Nutrition and Immunization Program

Botswana has created a combined nutrition and immunization program providing key services to
young children receiving nutrition assistance, while ensuring that the children are hitting their
growth indicators and receiving the full set of vaccines. Working with the Botswana team, the
Tracker platform was enhanced to produce standardized z-scores providing quick assessment of
weight-for-height, weight-for-age, and height-for-age.

2.2.3 Ghana: HIV/ART and other eTracker modules

Since 2012, Ghana Health Services has led a pioneering program in reporting patient-level data
through DHIS2 Tracker programs (“eTrackers”). As of 2019, they were using 8 different eTracker
modules. A prime example is their HIV/ART eTracker, which tracks individual patients through
testing and treatment and makes it easier for health personnel to identify and follow up with
defaulters, while also supporting the reporting flow for aggregate HIV data, which has been
ongoing in Ghana since 2006.

2.2.4 Palestine: Maternal and Child Health eRegistry

Every woman in Palestine is assigned a primary health care clinic, and if that clinic does not
provide the services she needs, she is asked to visit a higher-level clinic. This referral system
requires an eRegistry that controls access to clinical patient files, supports the continuity of care
across different healthcare sites, allows for data entry from several different points, and provides
analytics to help drive decisions under Palestine’s antenatal care guidelines. Our collaboration
with Palestine started in 2014. The development and implementation of the maternal and child
health (MCH) eRegistry included an iterative approach and dynamic dialogue between the
developers, policymakers, public health officials and health care providers. This implementation
features extensive use of automated SMS messages to communicate with patients, as well as
quality improvement dashboards to measure performance of clinics and support the delivery of
quality care.

2.2.5 Zimbabwe: National Malaria Control Program

The DHIS2 Android Tracker implementation in Zimbabwe started in 2014 as a collaborative

project between the National Malaria Control Program (NMCP) and the University of Oslo, and
has since been scaled to cover nearly half of the country’s 60+ districts. This implementation
features offline data collection, detailed location data, and near real-time data collection and
analysis, and is an example of working with multiple stakeholders at a global level to develop a
program with potential for expansion across geographic regions and disease areas.

8
3 Is My Project Ready For Tracker? 3.1 Readiness questions and key considerations

3 Is My Project Ready For Tracker?

3.1 Readiness questions and key considerations

This section is intended to describe some of the key landscape conditions that should be well
understood before proceeding with a Tracker implementation. Due to the fact that many of the
countries where Tracker is being introduced are already using DHIS2 for the national HMIS or
other aggregate purposes, it is important to highlight some of the key differences between DHIS2
Tracker and Aggregate systems, in order to plan appropriately for the changes that may need to
be made around implementation and administration.

Tracker programs often expand the reach of the information system, extending it to users that
were not previously using an electronic information system of any kind. Inherently, individual
data requires additional considerations around data privacy and security. These two factors
mean that Tracker implementations typically require:

• larger scale training efforts among cadres of workers that might also have high turnover
rates;
• increased emphasis on user acceptance and mapping to existing work practices;
• additional hardware for data capture, including the management of that hardware over
time;
• reliable network coverage and/or strategies to address intermittent connectivity;
• increased awareness of, and capacity for, privacy and security;
• greater capacity for IT support that can solve solve problems for a much larger user basis;
distributed across a larger geography.

These and other recommendations will be discussed in greater detail in the sections below. The
following series of questions can be helpful when initially assessing readiness for a new Tracker
implementation. In particular, if your use case involves the collection of personally identifiable
data (health-related or otherwise) you should review and reflect on the following questions
before you begin.

• Is there political and institutional will to undertake implementation of point-of-service

individual-level large-scale data collection?

• Is it feasible to provide a system for actual point-of-care data collection, without creating
additional documentation burden for the care providers?

• What is the added value and meaningful use of patient-level data in this context? What are
the specific questions that only this data can answer?

• How will the data be used to make substantive decisions, by care providers, managers, and
policymakers?

• Are there laws, regulations in place for the collection, storage and use of individual-level
and personally identifiable data? Alternatively, are there mechanisms for ensuring that
such laws will be in place in the near future?

• Is there sufficient and sustained funding, resources and human capacity for design,
implementation (computer and internet), training, maintenance, data management and
monitoring of the system?

• Is there a way to uniquely identify clients in the health system setting?

• How are identifiable patient records currently collected and distributed on paper?

9
3 Is My Project Ready For Tracker? 3.2 General considerations

Are there clinical guidelines/clinical interventions or at least some form of guidance for
• clinical practice? Are there a list of reporting items in the HMIS and their detailed
definitions?

• How are facility-level and patient-level data currently collected, managed, and shared
within the health system?

References:

1. mERA checklist: https://www.bmj.com/content/352/bmj.i1174

2. Principles of Digital Development
3. Public Health Informatics – a developing country perspective: https://global.oup.com/
academic/product/public-health-informatics-9780198758778?cc=ps&lang=en&

3.2 General considerations

3.2.1 Institutional buy-in and support

Ensure there is institutional buy-in and support from the outset of your project to create long
term commitment. A tracker project ties closely work practice and data management and will
take time, attention and resources. It will alter work practices at the ground level for the positive
if done well and negatively if done poorly. Hence it is crucial that the project has solid support
from key stakeholders such as program managers, IT units, heads of department, etc. From the
outset, a diverse working group of the key stakeholders and users should be involved with
designing the objectives and scope of the system, and this working group will be empowered to
make decisions such as replacing some levels of paper reporting, or adapting supervision
processes to respond to new key performance indicators made possible by the capture and
analysis of individual level data.

Identify the division/department within the health organization of interest (such as Ministry of
Health, public health institute, etc) with sustainable growth potential for housing a long-term core
administrative development team. Engage relevant departments that should be involved, such as
those working with data collection and management and IT, as well as health policy makers and
implementers who can provide input on the workflows of health workers. Obtain agreement that
the working group is not meant to dissolve at the end of scale-up, but rather should transform to
the long term administrators and system managers.

Before committing to a large scale Tracker project, consider the funding landscape for the large
and long term investments required for sustainability, particularly with device procurement,
ongoing network costs, and training, both at the outset of the project, and routine training over
time for new users. Are the goals and resource allocations from the funding mechanisms aligned
with the group responsible for implementing tracker? Will the introduction of Tracker replace
costs in other areas, such as printing reporting forms, that can be reprogrammed once the
system is adopted and running well?

Consider how tracker could affect and potentially bring improvements to all levels, not just the
end users. For example, a Tracker program that matches the clinical workflow for antiretroviral
treatment could be designed to bring benefits to the person on treatment, through appointment
reminders and a shared clinical record between ART sites. It could bring benefits to the care
provider by automating some aspect of their reporting and providing decision support. It could
add benefits to the supervisor by providing concrete information about performance and
challenges based on data; and could bring benefits to program managers by adding not only real
time data, but also introducing new types of indicators, such as those based on timeliness or
quality, due to the opportunities presented by individual level data.

Designing for these outcomes not only greatly enhances the value of the system, it helps to
ensure user uptake and satisfaction, and can bring significant improvements in the provision of

10
3 Is My Project Ready For Tracker? 3.2.2 Funding

healthcare. These kinds of features can also help secure donor buy-in and cross-donor financing,
as the system can satisfy multiple objectives.

References:

• Principles of Donor Alignment for Digital Health

• Principles for Digital Development

3.2.2 Funding

Ensure sustainable funding for development, implementation, training and continued support to
last throughout the life cycle of the tracker projects. A tracker implementation requires funding in
the following phases:

• Requirements gathering and development

• Training of the core IT team, administrative staff and program managers, particularly if
they are only familiar with aggregate reporting
• Purchase and replacement of devices and backup solutions (alternative devices and paper)
• Roll out/scaling
• End user training, including per diem and workers salaries
• Connectivity (internet) and SMS costs, tracker may require investments in the
infrastructure to sustain it in the field
• IT support at the end-user level
• Hosting
• Continued evaluation and maintenance of the tracker program
• Refresher training(s)

Experience from existing tracker implementations points to the initiation and rollout of Tracker
projects to be the most resource intensive phase. A complex Tracker program modelling clinical
workflows and replacing paper reporting can take a year to design and obtain proper buy-in and
support. National trainings of thousands of users are resource intensive. Providing new
hardware, such as Android devices or laptops, requires significant investment. Hiring and training
additional staff in the IT unit to manage a large increase in users requires increased budgets.

As time passes the largest costs are related to refresher training and ongoing user support. To
ensure a sustainable tracker implementation it is crucial that funding is secured not only through
to scale-up, but also for covering routine costs in the future. Typically projects fail to be
sustainable when insufficient funds are allocated for a sufficiently staffed IT team and/or ongoing
maintenance and refresher training.

The costs associated with introducing individual systems can be somewhat offset by improved
processes; reductions in budgets for printing and transporting paper forms; improved adherence
to guidelines and referral mechanisms; etc. That said, digitizing current work processes is a long
term investment and plans should be made from the beginning to see such projects as a change
in routine practice, requiring ongoing support.

References:

• Learning Package – Training (http://eregistries.org/wp-content/uploads/2017/11/05-

training.pdf)
• Registries for Evaluating Patient Outcomes: A User’s Guide [Internet]. 3rd edition. https://
www.ncbi.nlm.nih.gov/books/NBK208631/

3.2.3 Legislation and policies

Before deploying Tracker, it is important to review relevant privacy and data management
legislation and policies at the local, national and international level. Collecting individual data is
categorically different from aggregate data and requires more attention to privacy and security.

11
3 Is My Project Ready For Tracker? 3.2.3 Legislation and policies

In the absence of clear national policies, data security and confidentiality guidelines - both
technical and administrative - must be developed and agreed upon. The proper practices that
must be clear and documented range from data access, to hosting requirements, to user
practice.

Many types of individual health data have the potential for serious consequences if privacy is not
protected. For example, in countries where it is illegal or culturally unacceptable to be an unwed
pregnant woman, a breach of this information could lead to harm for the individual and family. If
the client is not confident that his or her data will be properly protected, they may not be open
with their care provider about their health concerns, lowering quality of treatment. Personally
identifiable data can be mined for political purposes, or for identifying individuals in
systematically marginalized groups.

There are several specific areas that should be reviewed during the planning phase of a Tracker
implementation. As covered in the eRegistries Situation Analysis Tool, there are five areas to
focus on:

1. understanding the legal landscape

2. existing governance surrounding health registries
3. guidance, legislation and current practices associated with data collection and storage
4. oversight and reporting requirements
5. potential and existing ethical and social implications

Policies can be drastically different between countries, and it is extremely important to assess
these locally at the outset of each Tracker project. It is also critical to obtain local support for
privacy policies. Experience has shown that even a well-crafted legal document developed
externally, without local buy-in, can be shelved and not in use because the local organization(s)
were not involved in its development and it was not translated to the local language. A Tracker
implementation should consider the end user in all aspects – including legislation and policies.

Individual level data has significant value for future research and analysis, long after it is
collected. A 2018 IMIA Yearbook of Medical Informatics article, it shows that the number of health
record access requests is growing. To help ensure proper data management of sensitive data for
the future, one should consider establishing procedures for data sharing agreements, if they are
not already locally stipulated. This will help to maintain a systematic and fair approach to
requests for information and their use – whether from a research organization, donor or other
interested party. In situations where there is no or limited guidance, it is recommended to
address the concerns outlined in the eRegistries Governance Toolkit and receive appropriate
governmental buy-in for routine policies regarding data sharing and access.

Proper project planning will include time and resources for identifying essential policies,
procedures and protocols for privacy and security. The eRegistries Governance Toolkit provides
practical guidance on how to move forward through these steps. A thorough review with local
stakeholders of what data will be collected and how it could be misused can help to drive the
process forward. It is also important to identify a timeframe to revisit your privacy plan as
policies change over time. Keeping informed of these changes will help you to better plan when
navigating development, implementation and maintenance of Tracker.

Specific details about the Tracker software privacy features and guidance for proper
configuration can be found in the DHIS2 user and implementation guides.

References:

• Governance guidance toolkit

• Situation Analysis Toolkit
• Frost MJ, Tran JB, Khatun F, Friberg IK, Rodriguez, DC: What Does It Take to Be an Effective
National Steward of Digital Health Integration for Health Systems Strengthening in Low-

12
3 Is My Project Ready For Tracker? 3.2.4 Capacity and competence

and Middle-Income Countries? Global Health: Science and Practice 2018, Vol 6, Supplement
1
• Myhre SL, Kaye J, Bygrave LA, Aanestad M, Ghanem B, Mechael P, Frøen JF: eRegistries:
governance for electronic maternal and child health registries. BMC pregnancy and
childbirth 2016, 16(1):279
• Kloss L, Brodnik, M, Rinsehart-Thompson, L: Access and Disclosure of Personal Health
Information: A Challenging Privacy Landscape in 2016-2018. IMIA Yearbook of Medical
Informatics 2018, 60-66
• The 2012 WHO and the International Telecommunication Union (ITU) National eHealth
Strategy Toolkit http://apps.who.int/iris/handle/10665/75211
• The 2015 Roadmap for Health Measurement and Accountability https://www.who.int/hrh/
documents/roadmap4health-measurement_accountability.pdf?ua=1Foundations

3.2.4 Capacity and competence

Given the increased reach of Tracker, both in terms of users and IT support, it is important to
assess and ensure sufficient capacity and relevant competence to plan, design, develop, support
and use the tracker program. It is possible that there are areas in the country where Tracker is
suitable, and other areas where it is not, based on the capacity of the intended users and their
access to appropriate hardware and network. In many cases it is beneficial to roll out Tracker in
phases, rather than attempt to introduce it as a routine system in areas or with users that are not
prepared. An assessment should be conducted before developing the rollout plan, to guide the
scale-up and reach of the system based on appropriateness.

The key stakeholder working group described in the section on Institutional buy-in and support
should be engaged early on to assess what cadre of users the system will be aimed at, determine
which department will be responsible for long-term support, who will be tasked with providing
training, both initially and over time, etc.

Additional training may be required for the IT unit, increasing their capacity to properly manage
personally identifiable data, or provide support for any new hardware provided.

The tools and dashboards configured in Tracker should be designed with the intended users in
order to ensure that they are appropriate and accepted.

Trainings for users may require not only specific curricula for the system, but also general
training on the use,maintenance and troubleshooting of hardware and network access. Simple
job aids and access to first-tier IT support should be developed and established in order to
increase the number user needs that can be handled outside of the central level team.

References and Resources:

• Myhre SL, Kaye J, Bygrave LA, Aanestad M, Ghanem B, Mechael P, Frøen JF: eRegistries:
governance for electronic maternal and child health registries. BMC pregnancy and
childbirth 2016, 16(1):279
• Software Development learning package
• Governance guidance toolkit
• Principles of Digital Development

3.2.5 Infrastructure

It is important to ensure appropriate and sufficient infrastructure, which may be different for
Tracker than for other existing digital systems. There are three groups of necessary
infrastructure:

Electricity and network In areas where the network is stable, using Tracker through the browser
of a laptop or desktop computer is appropriate. Data from the browser client are sent instantly to

13
3 Is My Project Ready For Tracker? 3.2.6 Security Considerations

the server, with no local storage outside of the browser cache. This ensures data fidelity and
leverages the power of server-side computation. In areas of intermittent or low-connectivity, the
DHIS2 Android app is required to make use of Tracker, as it creates a local copy of the database
and allows the user to continue working without a direct connection to the central server.
Android-based projects bring additional requirements with regards to access to electricity for
charging; SMS and data costs; etc. Review the DHIS2 Android App Implementation Guidelines for
more information.

Servers and hosting With the increase in numbers of users, the existing hosting solution for
DHIS2 aggregate may not be adequate, and Android-based implementations bring even more
strain on server resources. Whereas with monthly based reporting systems it is at times
acceptable to expect low performing hosting options, Tracker programs that support daily work
processes or clinical workflows require constant uptime and responsive IT support if problems
arise. It is especially vital to establish a routine backup of Tracker data to a separate site, so that
loss of critical data in the primary server can be quickly addressed. Conduct an evaluation of the
current hosting approaches, including both hardware and available human resources, to develop
an approach for your Tracker implementation. It is recommended that Tracker programs
containing personally identifiable data be hosted in a separate environment from the aggregate
system, in order to ensure greater security. Although many countries currently host local
installations of DHIS2, it is worth considering a cloud-based hosting option for Tracker programs,
where industry-standard hardware and technical support can be assured over time.

Hardware for end users Given the wide scale adoption of digital health projects, it is possible that
the existing hardware available to targeted users is sufficient for a new tracker implementation.
An assessment should be conducted to review the availability of computers and Android devices,
and determine where additional hardware may be necessary. Long-term agreements for
maintenance and replacement of hardware should be established in order to ensure the
sustainability of the Tracker system past the life of the originally purchased hardware.

3.2.6 Security Considerations

Security is primarily about people. The people who are the subjects of data collected, the people
who use the data, the people who are responsible for implementing technical measures and the
people whose responsibility it is to manage the security of the particular tracker project.

It is not sufficient to assume that technical implementers will have made a best effort to make
the system as secure as possible (though in general we hope that they will). In order to meet any
level of regulatory compliance and avoid legal hazard it is usually necessary to be able to
demonstrate that reasonable steps have been taken to secure the system. At a minimum this
implies that:

1. There is a role defined in the organisation whose responsibility it is to be concerned with

security related issues. This might be a chief security officer, a data protection officer or
some other designation. The important thing is that there is an individual whose job it is to
be concerned about, and to be accountable for addressing, security considerations. Ideally
this is not a technical role, but one closer to senior management.
2. There should be some documented security plan around the tracker program. This is
sometimes referred to as security posture. It should indicate the principles that are
important to the organisation, the processes which are in place to identify, monitor and
mitigate risk on an ongoing basis and various other artefacts and processes such as
acceptable use policy (for employees), Non-Disclosure Agreements (for contracters), access
policy, backup and disaster recovery plans, minimum standards for software deployment
and configuration etc.

In some organisations the role of security officer is already established and well defined. In many
others it is an evolving need which manifests itself in an environment characterised by the

14
3 Is My Project Ready For Tracker? 3.2.6 Security Considerations

absence of strong regulation, weak IT institutional and management structures and lack of
appropriate training. There are existing standards and methodologies which can be useful in
shaping such a role, such as the ISO27000 series (including useful free online material and
templates). It is not an item frequently seen on funding and budget proposals, but security
management training might well be one of the more important items to consider and budget for.

A non-exhaustive list of high priority tasks to consider: 1. Make sure the software setup is
technically strong, documented and preferably automated. How to do that is a bit opinionated
and their are different ideas of best practice. For system administrators, attending server
academy is a good way of meeting peers and exchanging ideas. Also interact with the server
admin community via the community of practice. There is also telegram group of system
administrators (to join, email Lamin - [email protected] ). 2. make sure you have a team
(at least 2) of sysadmins that are responsible for the daily maintenance of the system. Depending
on a single “technical” person is one of the biggest identified risks in many implementations. 3. As
outlined above, somebody MUST be responsible for security. That role should: - report directly to
management (not just a geeky thing) - manage overall risk (the risk register is your friend) - make
sure that sysadmins are doing their job - be aware of local law, constraints and SOPs regarding
data handling and privacy. In their absence, or where they are inadequate, develop and maintain
good practice guidelines locally. 4. make sure there is a backup plan, including off site, which is
regularly tested. Straightforward unrecoverable data loss has been the single most common
security problem countries have faced, 5. make sure that systems get audited regularly (this can
be “official” from auditor general, or peer-to-peer within our community). This is the best way for
management to ensure that sysadmins are doing their job (above)

15
4 Building your Tracker Program(s) 4.1 Determining Scale

4 Building your Tracker Program(s)

The purpose of this section is to give a high level overview of the considerations that will lead to
success in your Tracker implementation, grouped by topic and with links to specific tools.

This section will cover:

1. Scale
2. Design and Configuration
3. Real-time vs. Secondary Data Entry
4. Mobile vs. Web
5. Establishing a Core Team
6. Hosting
7. Training
8. Roll-out

4.1 Determining Scale

Because Tracker is aimed at the lowest levels of a system, Tracker systems can mean dramatically
increasing the number of users, devices technical and organisational support requirements.
Countries often have limited personnel that are qualified to do deployments and there are costs
associated with the work.

Scale can refer to several dimensions; programmatic scale, functional scale or geographic scale to
mention a few.

Scaling geographically can thus take time and resources. There are different strategies to
geographical scale i.e. cover one region completely or start “small” in several regions at the same
time and scale at a slightly slower pace in parallel.

When you start scaling things will happen faster; more people will work on it and need support.
Hence, make sure that the team is rigged to handle an increased volume and speed by taking
into consideration the following:

Finalize and pilot the tracker before scaling it

Gather evidence and demonstrate impact before attempting to scale. Consider reduced
investment in features that do not demonstrate impact, or resource-intensive features that have
limited impact. You should have a final design/configuration which is user tested and piloted and
produces the targeted results in terms of information management and the wanted reports
BEFORE you scale. When you start scaling, it is not the time for experimenting. In other words,
test your design and set up with 100 rather than 5000 users.

Governance
Ensure there are solid governance processes and a clear distribution of responsibilities before
you attempt to scale. Make sure you audit this process to ensure the governance process is
followed. Proper governance is also key to ensure the flexibility and adaptability of your tracker
project, for example routines for adding new option sets or new clinics. Who makes these
decisions and how do you document them and how do you communicate them to the users?

Cost/financial considerations
Consider your funding model, including revenue-generation options, social business models, the
cost per user and financial paths to sustaining the initiative. Scaling leads to increased
operational costs in terms of support, devices and connectivity.

Scaling up infrastructure
With increased scale you have to handle more connections that in turn requires increased
resources in memory, processing power, storage and connectivity.

16
4 Building your Tracker Program(s) 4.2 Design and configuration process

Part of the scaling process makes sure you have a sound plan for speedy recovery because more
people depend on the system.

Revise the process from the pilot

Scaling up can often not be done with the exact same tool and approach as is done in a pilot,
particularly when it comes to the level of human resources and expertise needed in training and
support to attain the level of use achieved in a pilot. Consequently, review your tool and
implementation approach and consider what aspects can be redesigned and simplified to
achieve your core goal

References:

• Principles of Digital Development

Tools:

• Readiness Assessment

4.2 Design and configuration process

Involve users closely in design and configuration of your Tracker program to ensure that it
improves and supports their work. In order to develop a Tracker program one needs to define
what data to enter, define a workflow and define program rules. All of these definition decisions
should be made in close collaboration with users, since they directly relate to – and can affect –
how they do their work.

We recommend that you start the design process by asking the following questions to start
discussions:

1. What is the purpose of the data you collect? How do you intend to use the data?
2. Who will benefit from the Tracker implementation?
3. How will the users entering data benefit from the Tracker implementation?
4. Do you currently collect this data today? How?
5. Are there data elements you currently collect that you do not need?

DEFINE PURPOSE, AIM AND SCOPE

A clear purpose and well-defined aims are the key to establishing a common understanding of
the project’s scope and limitations, and to being able to communicate the process of developing
and running a Tracker program internally and externally.

• Define the primary and secondary purposes of the Tracker program.

• Identify the tracked entities, the scope of data collection, and the health cadres involved in
data collection.
• Determine how to uniquely identify members of the target population, (e.g., use of unique
identification numbers or a combination of attributes).
• Clarify initial expectations among the core team, as well as other stakeholders and system
users.
• Brainstorm and discuss key issues and areas of concern to be addressed during the
development phase.
• Prepare to conduct a development phase: Develop a timeline and incorporate contingency
plans for unexpected events that incur delays. Articulate anticipated problems and discuss
how to mitigate.

FORMATIVE PHASE

Gain a clear understanding of the health system (or other system that the Tracker program will
cover, for non-health implementations) to understand the “pain points” of the current system,

17
4 Building your Tracker Program(s) 4.3 Determining your M&E Framework

identify opportunities for improvement, and ultimately develop a useful and suitable system that
addresses these issues and opportunities. This includes understanding health workers, the data
they collect, their clinical workflows, and their supervisory and reporting systems.

• Prepare and undertake field visits to map clinical workflows and supervisory and reporting
demands with the participation of all cadres of health staff who would use the Tracker.
• Prepare and undertake stakeholder meetings to inform, explore and get feedback.
• Verify existing national (clinical) guidelines relevant to the scope of the Tracker.
• Map the existing documentation workflow: Document what workers currently do and
ensure your design supports their work practices rather than making them more
cumbersome.
• Map indicators and associated data points for reporting.
• Consider whether there is a need for revision of guidelines or reporting points. If so, make
parallel plans for revision of guidelines and reporting.

DEVELOPMENT PHASE

• Get an overview of current clinical guidelines, interventions, indicators and algorithms.

• Based on current guidelines – as well as indicators and data points for reporting –
formulate algorithms and data points for electronic tracking.
• Define the target groups and level of complexity of decision support. According to the level
of workflow support, create rules for the support and communicate this to software
developers in an agreed-upon requirements format.
• Enable an iterative review process to ensure that the developers’ translation is consistent
with the health care providers’ needs.

CUSTOMIZATION AND TEST PHASE

This phase is an iterative process of working with stakeholders, software developers,

implementers and users and incorporating their feedback.

• Establish a structured and easily accessible digital system for comprehensive and
immediate feedback channels among the core working group.
• Ensure that content development is in line with the expectations of stakeholders, system
users and funders.
• Maintain ongoing, open-minded discussions about translation, use of information buttons,
etc., to avoid misinterpretation.
• Make sure that there are continuous, parallel processes that involve and promote
information flow among all user groups in these phases.
• Define milestones for developers, implementers and users.
• Establish a structured and easily accessible online digital system for comprehensive and
detailed feedback from end users.

Link to WHO package design documentation

4.3 Determining your M&E Framework

Intro
What does a mature tracker implementation look like?
Maintain and evaluate data collection
Maintain and evaluate data use practices
Maintain and evaluate keep up with new DHIS 2 versions
Maintain and evaluate user admin
Maintain and evaluate security
Maintain and evaluate hosting
Maintain and evaluate user support
Maintain and evaluate training

18
4 Building your Tracker Program(s) 4.4 Real-time vs secondary data entry

4.4 Real-time vs secondary data entry

Carefully evaluate whether the data should be entered real time as this has several implications
for how you structure your project. Trackers are used to track individuals through defined
programs with associated data elements and rules. The data can be captured by health
personnel during the consultation (real time point of care), or at the end of the day (or when they
have time to enter it). The two different approaches naturally have consequences for what the
Tracker is used for: If the data is entered at point of care - during the consultation - it is possible
to provide decision support and validate data and avoid double data entry. However, it also
introduces challenges with regards to connectivity, usability, increased number of devices, etc.

Entering data in real time also requires that the the setup of the Tracker matches the clinical
(other domain) workflow. Hence it is critical to have clear SOPs for backup paper files, easy
navigation to find clients and mechanisms to prevent errors (such as rules that make it
impossible to enter a date in the future).

Link to WHO package design documentation

4.5 Mobile vs Web

Consider how and when the people doing data entry can access the Internet There are contexts
or locations where accessing the online central DHIS2 server through a computer is challenging
or even impossible. The DHIS2 Android Capture App has been designed and developed to
respond to those situations. However, introducing mobile devices into a DHIS2 implementation
will impact your project on many levels, so it is a decision that needs to be made in an informed
and conscious manner.

Web or Mobile?
There are two main aspects that should be taken into account when considering a mobile
component for your Tracker implementation: internet availability and the mobility of your health
posts. A given Tracker implementation may need to address only one of these two aspects, or
both at the same time. We will attempt to define them and help you analyse your situation in this
section.

• Mobility: There are teams that provide their services in different locations through a
mobile unit. In the locations visited by the mobile unit, there could be a facility with a
proper work station for data collection, but sometimes data entry is done in a more
dynamic environment or in the vehicle itself. In these cases it is not always easy to carry a
laptop and it may be more suitable to use a mobile device instead.

• Internet availability: There are many locations where access to the Internet is challenging.
The different possible scenarios can be summarized in two main cases: Internet
connection is unstable or limited, and Internet connection is not available.

◦ When the Internet connection is unstable or limited scenario is confined to certain

moments in the day, it is possible to consider the use of either mobile or web for
data entry. DHIS2 web data entry allows for the continuation of data entry when the
Internet is interrupted. The data entered will be stored locally in the web browser
cache, and the next time the user gets online the data, it will be automatically
uploaded. Is important to note that this offline support depends on web browser
storage and will only work while the browser window remains open. If a user is
collecting data offline and closes the window where s/he is working while still offline,
the data will unfortunately be lost. Offline support absorbs the impact of
intermittent Internet connectivity interruptions to provide a smooth and stable work
experience, but is not a full offline solution.

19
4 Building your Tracker Program(s) 4.5 Mobile vs Web

When Internet connection is not available, you should consider using the DHIS2
◦ Android Capture App, which provides full offline support for data collection. This app
can be used with both mobile devices and tablets, and it is also possible to run it on
other devices such as Chromebooks. The Android Capture App can thus be suitable
for those cases where you have Internet availability challenges but not challenges to
mobility of the individuals doing the data collection.

Implications of the use the Android App

The DHIS2 Android Capture App facilitates offline use of Tracker data collection, but also brings
with it implications that must be considered from the early phases of the project. Having a
mobile component in your implementation could impact your planning, budget, training,
configuration and deployment strategy, among other aspects.

• DHIS2 configuration: When configuring Tracker for use with mobile devices you need to
pay special attention to the configuration of mobile users, their access to data entry and
organisation units. Mobile users are typically envisioned to be physically collecting data in
the most remote and inaccessible areas, hence a mobile user is not expected to collect
data from a high number of facilities, such as the organisation unit hierarchy of the entire
country. While there is no maximum number of organisation units allowed in the App,
large numbers can have impact in performance depending on the resources on the device
(memory, processor). In general, below 250 organisation units should be safe, but that is
still a very large number for a typical mobile use case.
It is also very important to pay attention to the configuration of program rules and
program indicators. The Android App aims to support all Tracker web functionalities,
however some of them might behave slightly differently in Android, or be in the app
development roadmap awaiting implementation. A detailed list of the behavior of program
rules and program indicators in Android can be found in the Program Rules and Program
indicators sections of the Android App documentation.

• Visual representation of data collection: The user experience of the Android App has been
designed to be very visual and intuitive. Icons and colors can be used to configure the data
entry forms and how they are displayed. Visual representation is configurable by the
system administrator. There is an icon library of over four hundred images and a color
palette, and both icons and colors are assignable to most metadata objects: Options, Data
Elements, Attributes, Programs / Data Sets. More information for the visual configuration
of DHIS2 can be found in the Visual Configurations section of the Android App
documentation.

• Testing : Testing is a very important phase in any DHIS2 implementation. You should test
the Android App in parallel with your server configuration, to make sure that all
configuration made in the server is properly reflected and working in the app. This is
especially important during the configuration of the program rules. More information on
the different types of testing and how to plan testing phases for your project can be found
in the Testing section of the DHIS2 Mobile Implementation Guidelines.

• Security : Depending on your Tracker configuration, you may be storing personal data on
mobile devices, and there may be tension between the health system’s need for
identifiable data, and the patient’s right to privacy. Ensuring that personal data is only
accessible by authorized health staff is of utmost importance. Proper management of
personal data is a critical component of user education, and it is vital to establish SOPs that
describe the security measures to be applied, and to ensure these SOPs are shared with
and followed by all users. System administrators also play an important role when
configuring a user’s access level, by ensuring that data access is appropriate for each user
and never unnecessarily excessive. Recommendations for an adequate security / privacy
approach for any DHIS2 mobile implementation can be found in the Data Security and

20
4 Building your Tracker Program(s) 4.6 Human Resources and IT Support

Privacy section of the DHIS 2 Mobile Implementation Guidelines.

TODO; add link to security section in this document!

• Purchasing mobile devices: Mobile devices acquisition is a key aspect to a mobile

deployment and needs to be considered for planning, budgeting and logistics. A good
strategy is to get the best and newest devices that you can afford, such that they will last
longer over the life of your project. In this sense, it is good practice to delay the bulk of the
acquisition (in other words, any devices not required for initial testing and pilot phase) as
much as possible, instead of purchasing all devices early in the planning process.
Technology – and particularly mobile devices – evolves very rapidly. A given model is
normally refreshed on an annual cycle, giving consumers access to significant technical
improvements year-on-year at a similar price point. Specifications for mobile devices that
can be used with the DHIS2 Capture Android App can be found here.
When you have performed all testing and completed your pilot, you are ready to scale up
your deployment with the acquisition of hardware and necessary services. You can find
guidance for your mobile acquisition in the Scale Up section of the DHIS2 Mobile
Implementation Guidelines. We summarize below the key aspects to consider in this
phase:

1. Purchasing of devices vs BYOD (bring your own device): The advantage of BYOD is
that it avoids the large initial cost for acquisition and reduces administrative costs
and logistics considerations. On the other hand, using the BYOD model leads to the
challenge of managing a very heterogeneous hardware environment, meaning
different devices and Android OS versions, which can result in different end users
having different capabilities for capturing and reviewing data, and can ultimately
lead to challenges with upgrading the core Tracker instance, as newer versions may
have limited backward compatibility with older app versions. The primary advantage
of purchasing devices for end users is uniformity of devices and app versions, but
this approach increases hardware costs and involves logistics challenges related to
distributing the mobile devices, as well as maintaining and replacing them over time.

2. Distribution of the app: you can manually install the Android Capture App by using
the APK available in Github or use the Google Play store. With Google Play it is easier
to update the app on all your devices, however you are forced to automatically
install all updates of the app. Installing the APK allows you to control when to update
and to which version, but it requires a more complex process for updating all your
devices and is not recommended for projects not using Mobile Device Management
software (see next item).

3. Telecommunication contracts: The process of selecting and signing a contract with a

mobile provider varies by country, and will also depends on the procurement
procedures of your organization.

• Management and Maintenance of devices: Mobile Device Management (MDM) refers to

software used for the administration of mobile devices. MDM software is necessary to
support hundreds of devices, control the APK file distribution across all of these devices,
provide tech support and enforce institutional policies. More information on the desirable
features of an MDM, available options and guidance on the selection of the right MDM for
your project can be found in the Mobile Device Management section of the DHIS2 Mobile
Implementation Guidelines.

4.6 Human Resources and IT Support

No Tracker implementation will be successful over time without the right people on board.
Before starting a tracker project it is important to make sure the right personnel with the right
competence are available.

21
4 Building your Tracker Program(s) 4.6.1 IT support unit

Here are a few considerations when building your team:

1. Aim for long-term engagement. The people that will maintain the Tracker implementation
over time should be part of the project from the start

2. In-country resources at all levels of the (health) system need to be involved from the very
beginning. Handovers of project history, decisions and established routines from external
consultants to permanent staff are often challenging.

3. If you already have an aggregate DHIS2 instance, remember that the people who are
managing aggregate are not automatically “qualified” for the Tracker project, as Tracker is
different from aggregate reporting.

Role Responsibilities/tasks
Project manager Manage the Tracker project
Config/development lead Lead development work
Security manager Responsible for security, policy ++
Training manager Organize training
Test lead Lead test work
Trainers Conduct training with end users
Support lead Lead support efforts
Distributed support staff Receive requests for support and help users

4.6.1 IT support unit

Support should be available close to the user, which often requires creating a new IT support
structure at the district or sub-district level. If Tracker is used in real time, technical support
should always be available during business hours to resolve and report issues. If Tracker will
support clinical decisions, the IT staff should understand clinical workflow, and its represented in
the technical system. Therefore, the Tracker IT support team may have different skill sets and
backgrounds than other health information officers, and may be an entirely new and different
cadre of worker within your health system.

Team structure and administration

Each member of the IT support unit should be trained before the first end user, and must
demonstrate a high level of knowledge of the system and how it works. Often, the IT support unit
consists of the same people leading the end-user training. At the very least, support staff should
be introduced to the end users during training to develop rapport and trust from the start. A
large component of support staff work is “supportive supervision” on the job. Effective support
staff must also be knowledgeable, respected, and respectful, but are generally not in a position of
direct authority over the end user, as this might reduce a user’s willingness to ask technical
questions and report problems with the system.

Once the team is in place, an internal working hierarchy can be established, from increasing
technical ability up the hierarchy (e.g. system administrator at top of the hierarchy), and
increasing access to the end users down the hierarchy (e.g. direct supervisor of end user, field
support staff). During this staffing organization phase, standard operating procedures for
reporting and responding to issues from end users needs to be developed.

22
4 Building your Tracker Program(s) 4.7 Hosting

Essential tools for any IT support unit

• Frequently Asked Questions (FAQ) document: A simple paper depicting in graphics and/or
local language the standard operating procedures for data entry and what to do in case of
bugs. A FAQ should be distributed during all trainings, and it should be regularly updated
by the IT support unit and shared with end users as the Tracker system evolves.

• Mobile device management: To protect patient-level data, a separate case management

system must be implemented for tracking which users have access to which device to
identify lost/stolen devices and follow up the case. This system can be as simple as a
spreadsheet, but in larger and more complex instances an enterprise-level MDM system
can be used to track device location, and can wipe an individual device remotely if needed.

• User management: The IT support unit should be able to document and manage basic
system administration tasks such as creating new user accounts, de-activating inactive user
accounts, or resetting passwords.

• Monitoring platform to track key system indicators: These key indicators include new
enrollments by organisation unit, inactive users, server downtime, etc. At a minimum, the
IT support unit should have access to aggregated indicators in a dedicated DHIS2
dashboard, where they can view implementation progress by time and region.

• Case management platform for registering bugs and tickets: These platforms (e.g. JIRA)
allows members of the IT support staff to enter, edit, assign, track, and resolve bugs and
other tickets, and allow supervisors to have oversight over important service-related
factors, such as number of open tickets and unresolved bugs, average response time, etc.

• Knowledge management platform: This is a repository where employees can learn from
previous tickets (thus building a knowledge base). The IT support unit understands the
user’s real-world experience with Tracker better than any other implementer or system
administrator, and their perspective can be invaluable to adapting Tracker to better meet
the user’s needs. A knowledge platform–either electronic, or regular meetings among
staff–can share common experiences, frustrations, or ideas for potential improvements

• Hotline to report bugs: This hotline can come in many forms. For example, it could be a
phone number for support staff employees that is shared with each user, or an email
address where users can send notes and screenshots. Regardless of format, there must be
an SOP in place for entering bugs reported through the hotline into the case management
platform mentioned above.

• Public chat groups: Many support teams find creating chat groups between staff and end
users can support peer-to-peer learning (e.g. Whatsapp or Wechat to share screenshots,
voice messages, or creative solutions for common problems).

References:

• Principles of Digital Development

4.7 Hosting

The tracker program itself and the collected data needs to be hosted on a server. This can be
done locally (for example at the ministry), through a local professional service provider or in the
cloud. The different options have pros and cons, e.g. hosting a tracker implementation in the
cloud means administrator does not need to worry about server capacity, down time and so
forth, but at the same time there might be legislative issues with hosting the data outside the
country borders, unless you have a local provider. Regardless of hosting strategy - security is a
key consideration. This entails identity management, authentication and authorization (restricting
access to data or services) as well as protection of servers.

23
4 Building your Tracker Program(s) 4.7 Hosting

Additionally you have to decide if you want to configure the tracker in a separate or same
instance as your aggregate system. A big advantage to having one instance is the possibility to
directly generate your reports from tracker data. However, having the two in the same instance
requires stricter SOPs for maintaining user accounts to ensure access to patient data is restricted
properly.

10 principles for hosting and security

1. Operating system is a LTS (long term service edition)

2. There is an automatic process for applying OS security patches
3. Host based firewall configured allowing minimal access
4. Access is via ssh according to agreed policy - keys, no root access etc
5. DHIS2 version is not more than 3 versions behind latest release. Process exists to apply
patch releases regularly.
6. Automated backup system is in place and regularly tested, including offsite.
7. Postgresql database access controls allow minimal access
8. Web-proxy server is properly (ssllabs test A+) configured with SSL
9. Database data is on separate data partition (allowing encryption at rest, performance
settings)
10. Monitoring and alerting system is in place (wide range of options depending on
environment. eg. boombox might be fine with email + logwatch + munin )

Enough/stable electricity to charge devices

In case of Android - network with a certain amount of uptime in order to sync.
In case of web based - stable network

1. Servers/network/hosting

2. Hardware

Experience shows you need X number of devices per user

You need X % of devices for backup

Devices needs to rotate

• Database diagram (including virtual machines and physical networks)

• Minimum specifications for hardware…
◦ Servers
◦ PCs
◦ Android / M### Hosting & Securityobile
◦ Other connected devices (e.g. fingerprint readers)
• Other infrastructure
◦ Network access
◦ Electricity access
◦ SMS and data costs
◦ Shared resources with other projects or ministries (e.g. government contract with
SMS gateway provider)
• Cloud-based vs Locally hosted: Depends on the regulatory environment of PII
• Management and sustainability of the IT systems.
• Documentation exists on security plans and protocols. Both at high-level (non-jargon, but
stating the principles) as well as technical procedures. Especially critical for locally-hosted
systems without a “security first” culture.
• One individual needs to be responsible of developing, maintaining and implementing the
security plan. Another security manager committed to identifying and mitigating risks.
Both roles require experience, capacity, and incentive.
• Ensure that there is a documented set of technical controls mandated

24
4 Building your Tracker Program(s) 4.8 Training and Rollout

• Ensure that there is audit process against those controls

• SOP for operational, network, and physical security (locking PCs, strong passwords, data
encryption, etc)
• SOP for monitoring and response if system is down or system breach
• Disaster recovery plan and routine drills
• Troubleshooting – process for “an external solution” in case of urgent crisis when situation
cannot be resolved locally.
• What is process for granting database or ssh access to servers?
• Access control and rules
• Where should management of the IT system fall within the framework?

References:

• Security Guidelines for Country Implementers

4.8 Training and Rollout

Plan for high-quality, continual training. Capacity building is crucial for a Tracker program to
succeed, and it must be both high quality and continue periodically throughout the lifetime of the
program. It is not sufficient to provide user training only once – your training plan should provide
for initial and refresher training over time. Frontline Tracker users are typically ground level
health workers who may be less comfortable with technology than district staff who work more
often with aggregated data. A strong emphasis on training will include time for familiarizing
trainees with the tools as well as how to integrate Tracker into their workflow.

A key principle is to develop training material in collaboration with users. Working closely with
users when you design the training material will allow you to understand what concepts are
difficult for users to understand, so you can refine your material and timing for the training
agenda. Do an initial entire training run with a group of real users to fine-tune your course.

Identify the appropriate training approach: There are multiple options for delivering your training
(e.g. video, online test, on-site, meetings), which can be used individually or in conjunction with
each other.

Involve health staff and not just IT staff in the trainings in order to explain and emphasise the
health reasons behind the data entry processes. This is particularly relevant for configurations
that involve decision support. Doing this helps end users to get a better understanding of why
the Tracker program is significant, which can lead to more complete and accurate data entry, and
thus a greater likelihood that the program will succeed in its goals. Revise the material based on
feedback from those attending the course, or if there are revisions of the Tracker program that
cause the old training materials to become inaccurate.

Logistics
Plan training of Tracker users as a series of training steps, such that they receive refresher
training after some time. The refresher training schedule should ideally align with revision cycles
of the Tracker software, to facilitate the introduction of end users to changes and new features in
the program.

Note that training a large group of users (especially spread out over a large geographical area)
will often require that you first train other trainers (at a Training of Trainers, or ToT) early on, to
help scale your training capacity. Keep track of which Tracker users have been trained in
spreadsheet, list, or other centralized database, and establish and SOP to update this list when
new staff members join, or when existing staff members quit or are relocated. New/untrained
staff members should be provided with training at the earliest possible opportunity. Choose a
training venue with care. Training can take place either on site (at or close to the users’ work
environment) or in centralized trainings that bring larger groups of users from various
workplaces to one centralized location. Both approaches have positive and negative aspects.

25
4 Building your Tracker Program(s) 4.9 Relating Tracker to your Aggregate Data System

Regardless of where the training takes place, the person responsible for planning the training will
need to organize logistical details such as the venue, transport, food and drink, computers,
Internet access, etc.

If possible, train users on the devices they will use in their work. Don’t underestimate the time it
takes for people to log in and familiarize themselves with the device – it can take a significant
amount of time at the beginning of the training program to get all participants ready from a
technical standpoint. It is recommended to have several members of the training team available
to help troubleshoot these issues as they arise. Schedule follow up regular/onsite training /
refresher training

Training in low bandwidth settings

If Internet connectivity is too slow, unreliable, or non-existent at your training location, you will
need to install a local Tracker instance and configure it for training on a machine/local server, and
set it up for the training such that participants can connect through a common local network
environment, an IP address, or localhost client. Even in settings where Internet access is generally
good, having a large number of users access the web-based Tracker instance through one WiFi
network or Internet access point can lead to network issues. It is therefore generally advisable to
have a training instance available as a backup in these cases.

4.9 Relating Tracker to your Aggregate Data System

Make sure to cover the basic reporting requirements from the HMIS when designing the tracker
to avoid double reporting. The data entered into tracker forms a basis for generating aggregate
numbers. E.g. 4 patient entries = 2 with condition X and 2 with condition Y. Tracker should
support the aggregate system, rather than be an extra burden on data collectors. System design
should take into consideration how to meet aggregate data requirements using the data entered
through tracker.

There are different options to consider, either through automation or manually with the help of
tools. You need a clear work flow, tools and governance model for data quality and completeness
assurance and the data authorization process. In other works who can approve and process data
from individual to aggregate data and how does this happen.

When you design the integration with the HMIS, make sure that the aggregation process is well
thought through.

• review the indicators

• create the reports
• create a governance model for data quality and publishing
• ensure the data revision processes are working (who owns the process and the data and
what happens if you discover faulty data after deadlines)

It is important to make sure that care providers understand the indicators and are able to input
into how they are calculated. Involve Ministry/policy-makers in the process so that they
understand the fundamental differences between how reporting happened before vs. now in a
tracker or eRegistry.

Feeding into the HMIS

The data that is entered into tracker forms a basis for generating aggregate numbers. E.g. 4
patient entries = 2 with condition X and 2 with condition Y. Tracker should support the aggregate
system, rather than be an extra burden on data collectors. System design should take into
consideration how to meet aggregate data requirements using the data entered through tracker.
In other words the workflow should avoid additional work for your health workers. They should
not have to aggregate data manually and enter manually into the HMIS.

26
4 Building your Tracker Program(s) 4.9 Relating Tracker to your Aggregate Data System

Difference between aggregate data collection system, where the final numbers are input into
online reporting forms vs. a tracker/an eRegistry that does automated reporting

Significantly more effort in software design to cover all reporting and indicator needs

Important to define indicators and understand what is to be measured: what is the numerator,
what is the denominator

Default denominator in an eRegistry: patients/clients

Removing traditional paper reporting can be time-consuming, behavior-change takes time

Important to make sure that care providers understand the indicators and are able to input into
how they are calculated

Involve Ministry/policy-makers in the process so that they understand the fundamental

differences between how reporting happened before vs. now in an eRegistry

References:
Venkateswaran M: Attributes and consequences of health information
systems data for antenatal care – health status, health system
performance and policy, PhD dissertation, University of Bergen
Venkateswaran M, Mørkrid K, Khader KA, Awwad T, Friberg IK, Ghanem
B, Hijaz T, Frøen JF: Comparing individual-level clinical data from
antenatal records with routine health information systems indicators
for antenatal care in the West Bank: A cross-sectional study. PloS one
2018, 13(11): e0207813

27