انتقل إلى المحتوى
For the complete DHIS2 documentation index, see llms.txt.
متعقب التنفيذ

Is My Project Ready For Tracker?

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?

  • 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&

General considerations

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 healthcare. These kinds of features can also help secure donor buy-in and cross-donor financing, as the system can satisfy multiple objectives.

References:

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 salariesmake sure
  • 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:

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. 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:

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:

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 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.

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. 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 a security posture. It should indicate the principles that are important to the organisation and the processes which are in place to identify, monitor and mitigate risk on an ongoing basis and various. The security plan can include other processes such as acceptable use policies (for employees); Non-Disclosure Agreements (for contracters); access policies; 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 absence of strong regulation, weak IT institutions and management structures, and a 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. There are various strategies that can satisfy security concerns, some of which are documented in the DHIS2 Installation Guide. 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 DHIS2 system administrators, which can be a useful way to ask and answer questions. (to join, email Lamin - laminbjawara@gmail.com ). 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 person in this role 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 - 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. Ensure that 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. 5. DHIS2 Tracker systems should be audited regularly. This can be officially conducted by an auditor general; peer-to-peer within the DHIS2 community; or by engaging the services of an external auditor. Audits are the best way to ensure that systems remain aligned with secuirty policies.