Destiné à être utilisé avec la version master - Équipe de documentation DHIS2 December 2020 - DHIS2 Documentation

Page created by Dana Lowe
 
CONTINUE READING
Destiné à être utilisé avec la version master - Équipe de documentation DHIS2 December 2020 - DHIS2 Documentation
Tuberculosis

Destiné à être utilisé avec la version
master

Équipe de documentation DHIS2
December 2020
Destiné à être utilisé avec la version master - Équipe de documentation DHIS2 December 2020 - DHIS2 Documentation
Tuberculosis                                                Destiné à être utilisé avec la version master

    Copyright © 2006-2020 Équipe de documentation DHIS2

    December 2020

      Historique des révisions
      master@1f3b736                              2020-12-18 12:31:28 +0100

    Garantie: CE DOCUMENT EST FOURNI PAR LES AUTEURS ’’ EN L’ETAT ’’ ET TOUTE GARANTIE
    EXPRESSE OU IMPLICITE, Y COMPRIS, MAIS SANS S’Y LIMITER, LES GARANTIES IMPLICITES DE
    QUALITÉ MARCHANDE ET D’ADÉQUATION À UN USAGE PARTICULIER SONT DÉCLINEES. EN
    AUCUN CAS, LES AUTEURS OU CONTRIBUTEURS NE PEUVENT ÊTRE TENUS RESPONSABLES DES
    DOMMAGES DIRECTS, INDIRECTS, ACCESSOIRES, SPÉCIAUX, EXEMPLAIRES OU ACCESSOIRES (Y
    COMPRIS, MAIS SANS S’Y LIMITER, L’ACHAT DE MARCHANDISES OU DE SERVICES SUBSTITUÉS;
    PERTE D’UTILISATION, DE DONNÉES OU DE PROFITS; INTERRUPTION COMMERCIALE) TOUTEFOIS
    CAUSÉE ET SUR TOUTE THÉORIE DE LA RESPONSABILITÉ, QU’IL SOIT DU CONTRAT, UNE
    RESPONSABILITÉ STRICTE OU UN LAC (Y COMPRIS LA NÉGLIGENCE OU AUTREMENT) DÉCOULANT
    DE TOUTE MANIÈRE DE L’UTILISATION DE CE MANUEL ET DES PRODUITS MENTIONNÉS DANS CE
    DOCUMENT, MÊME SI MIS À JOUR, TELS DOMMAGES.

    Licence: L’autorisation est donnée de copier, distribuer ou modifier ce document selon les
    termes de la licence GNU de documentation libre, dans sa version 1.3 ou dans toute version
    ultérieure publiée par la Free Software Foundation ; sans Section Invariante, sans Texte De
    Première De Couverture, et sans Texte De Quatrième De Couverture. Une copie de cette licence
    est incluse dans la section intitulée “Licence GNU de documentation libre”: https://www.april.org/
    files/gfdl.1.3-js.fr.html

2
Destiné à être utilisé avec la version master - Équipe de documentation DHIS2 December 2020 - DHIS2 Documentation
Table des matières                                         Destiné à être utilisé avec la version master

  Table des matières
        1 TB Aggregate System Design
              1.1 Introduction
              1.2 Aperçu
              1.3 Data set structure and design
                     1.3.1 TB case registration
                     1.3.2 Lab activity and TB/HIV
                     1.3.3 TB treatment outcomes
                     1.3.4 TB treatment outcomes - second line
                     1.3.5 RR/MDR-TB case detection and treatment
                     1.3.6 [old records only] TB case registration by smear results
        2 TB Case Surveillance Program (Tracker)
              2.1 Summary
              2.2 Purpose & Intended Audience
              2.3 Contexte
              2.4 System Design Overview
                     2.4.1 Use Case
                     2.4.2 Program Structure
              2.5 Tracker Program Configuration
                     2.5.1 Program Details
                     2.5.2 Enrollment Details
                     2.5.3 Les attributs
                     2.5.4 Stage 1: TB Registration
                     2.5.5 Stage 2: Laboratory Results
                     2.5.6 Stage 3: Treatment
                     2.5.7 Stage 4: Outcome
                     2.5.8 Program Rules
                     2.5.9 Top Bar Widget
                     2.5.10 Feedback Widget
              2.6 Additional features
                     2.6.1 Les constantes
              2.7 Analytics and program indicators
                     2.7.1
                     2.7.2 Reporting case-based data into aggregate TB reports
                     2.7.3 Dashboard
              2.8 User Groups
              2.9 Références
        3 TB Case Surveillance Tracker Installation Guide
              3.1 Aperçu
              3.2 Installation
              3.3 Conditions requises
              3.4 Préparation du fichier de métadonnées
                     3.4.1 Default data dimension (if applicable)
                     3.4.2 Types d’indicateurs
                     3.4.3 Type d’entité suivie
              3.5 Importation de métadonnées
                     3.5.1 Gestion des conflits d’importation
                     3.5.2 Configuration supplémentaire
                     3.5.3 Partage
                     3.5.4 Rôles des utilisateurs
                     3.5.5 Unités d’Organisation
                     3.5.6 Métadonnées dupliquées
                     3.5.7 Les constantes

                                                                                                      3
Table des matières                                       Destiné à être utilisé avec la version master

                    3.5.8 Configuring tracker capture interface, widgets and top bar
                    3.5.9 Reporting case-based data into aggregate TB reports
              3.6 Adapter le programme tracker

4
1 TB Aggregate System Design                                                             1.1 Introduction

 1 TB Aggregate System Design
 1.1 Introduction

 This document describes the system design for the TB configuration package for aggregate
 reporting, focusing on how the data collection part of the configuration has been designed in
 DHIS2 (i.e. data sets and data elements).

 1.2 Aperçu

 The TB configuration package for aggregate reporting is based on the WHO Definitions and
 reporting framework for tuberculosis. It contains a total of 7 data sets, as described in table 1.

    Name                              Periodicity     Objectif
    TB case registration              Quarterly       Reporting of new cases of TB (notifications)
    TB treatment outcomes             Quarterly       Reporting of treatment outcomes of first line
                                                      treatment
    TB treatment outcomes -           Yearly          Reporting of treatment outcomes of second
    second line                                       line treatment
    RR/MDR-TB case detection          Yearly          Reporting of new cases of drug-reistant TB
    and treatment
    [old records only] TB case        Quarterly       Reporting of new cases of TB (notifications),
    registration by smear                             based on the 2006 reporting framework
    results
    [old records only] TB             Quarterly       Reporting of treatment outcomes of first line
    treatment outcomes - by                           treatment, based on the 2006 reporting
    smear results                                     framework
    [old records only] TB             Yearly          Reporting of treatment outcomes of second
    treatment outcomes -                              line treatment, based on the 2006 reporting
    second line                                       framework

 As the name implies, the last 3 of the data sets show in the above table are only included for the
 purpose of keeping historical data according to the previous reporting guidelines. This is
 important because the tuberculosis epidemiology changes relatively slowly, and analysis of TB
 data requires looking at multi-year trend. Where possible, the same data elements have been
 used for the new and old forms. Indicators included the configuration package are linked to data
 elements from both current and old forms, to make it possible to compare data collected using
 the two different frameworks.

 Note: These [old records only] data set should not be used for prospective data entry.

 1.3 Data set structure and design

 This section will for each data set present the main sections (tables) of the data sets (reporting
 forms), explaining how and why they have been configured.

 The [old records only] will not be described in detail as they are relatively close to the current
 forms, except for the age disaggregation of the case registration form.

                                                                                                       5
1 TB Aggregate System Design                                                      1.3.1 TB case registration

    1.3.1 TB case registration

    1.3.1.1 Case registration

                                               Case registration

    The case registration table has been set up as 12 individual data elements. This table could
    conceivable also have been set up as three data elements with “Previous anti-TB treatment staus”
    as a data element category. There are a few reasons why a “flat” structure with individual data
    elements was chosen:

         • As noted above, it has been important to have a structure for the TB configuration package
           that allows comparisons with the previous reporting framework. Using a flat structure
           allow certain fields (data elements) in this section to be reused in the previous version of
           the case registration form.
         • Analysis of this data is often done on specific combinations of these rows and columns,
           which have been defined as indicators. Using a category for treatment status would make
           it easier to replicate the above table “as-is”, but this seems less relevant. If necessary, this
           could be re-created using data element group sets.
         • A “previous anti-TB treatment status” category would only apply to 3 data elements. While
           including a similar concept/classification of previous treatment, both the data set for drug
           resistant TB and the previous reporting framework is structured differently so that the
           cateogry could not be used there.

    1.3.1.2 Case registration by age and sex

                                        Case registration by age and sex

6
1 TB Aggregate System Design                                            1.3.2 Lab activity and TB/HIV

 This section/table has been configured as a single data element, with an “age and sex” category
 combination. Even though the age category only applies to a single data element, this allows
 maximum flexibility in the analysis tools, as shown in the example below:

                                       Pivot table example

 1.3.1.3 Data validation

 A validation rule has been configured that checks the number of new and relapse cases reported
 in the “Case registration” to the number reported by age and sex.

 1.3.2 Lab activity and TB/HIV

                                                                                                   7
1 TB Aggregate System Design                                                 1.3.3 TB treatment outcomes

                                     Lab diagnostic activity and TB/HIV

    These two sections/tables have been configured as individual data elements.

    1.3.2.1 Data validation

    Validation rules have been configured for these checks:

         • Lab examinations done ≥ positive results
         • HIV status known ≥ status positive
         • HIV status positive ≥ CPT/ART

    1.3.3 TB treatment outcomes

    1.3.3.1 Treatment outcomes

                                           Treatment outcomes

    The treatment outcomes table (which applies to first line treatment only) is categorised by the
    type of TB case (bacteriological confirmed, clinical, previously treated, HIV positive). For each
    category of patient, the table includes the number of cases registered (i.e. the treatment cohort)
    and the treatment outcome. Each category of patients is configured in DHIS2 as one data
    element for the cases registered/cohort, and one for treatment outcomes. The treatment
    outcome data elements have a “TB treatment outcome” category with each of the 6 treatment
    outcomes.

    First of all, it is clear that having one data element for each category of TB case would not make
    sense, as it would include both the cohort and the number of reported outcomes, i.e. the total of
    the category would not make sense, which is the general rule. However, the table could have
    been set up with each field being an individual data element. The reason why a category was
    chosen includes:

         • The general recommendations for categories is that the sum of all options should make
           sense, as it is the total that is showed by default in the reporting tools. While the total in
           this case might not be particularly useful (it is essentially the total number of evaluated
           outcomes), it is a meaningful number. For comparison, a common example of a category
           that most often does not make sense is “cases and deaths”.
         • When including current and old forms, first and second line, the treatment outcome
           category applies to 13 case categories. Using a category thus helps reduce the number of
           data elements from 78 to 13.
         • Using a category maximises the flexibility when analysing the treatment outcome data. For
           example, the total number of outcomes with “treatment success” (which is defined as the

8
1 TB Aggregate System Design                                     1.3.4 TB treatment outcomes - second line

        sum of “cured” and “treatment completed”) can be shown simply by setting up a filter with
        two category options.

 1.3.3.2 Data validation

 Validation rules have been set up verifying that the size of the cohort (cases registered) is the
 same as the number of treatment outcomes reported.

 1.3.3.3 TB/HIV

                                             TB/HIV Activities

 The TB/HIV section/table of the treatment outcomes data set closely resembles the TB/HIV
 section of the case registration form. It is included because often the HIV status of a significant
 proportion of cases may not yet be known at the time the quarterly notification report is
 compiled. The TB/HIV section of the treatment outcomes report enables collection of the
 complete information about HIV status. It has the similar variables related to HIV status, but uses
 separate data elements with a “(by time of outcome)” postfix to separate them. The same
 validation rules apply here as on the TB/HIV table in the Case registration dataset.

 1.3.4 TB treatment outcomes - second line

 1.3.4.1 Treatment outcomes

                                         Treatment outcomes

                                                                                                         9
1 TB Aggregate System Design                          1.3.5 RR/MDR-TB case detection and treatment

 The treatment outcomes for cases on second-line regimen has been configured in the same way
 as described above, and with the same validation rules.

 1.3.5 RR/MDR-TB case detection and treatment

 1.3.5.1 Case detection

                                          Case detection

 The case detection section/table is configured with individual data elements.

 1.3.5.2 Data validation

 A data validation rule checks that the number RR-TB or MDR-TB cases is more than the number
 of MDR-TB cases only.

 1.3.5.3 Treatment

                                            Treatment

 The treatment section/table is configured with individual data elements.

10
1 TB Aggregate System Design                  1.3.6 [old records only] TB case registration by smear results

 1.3.6 [old records only] TB case registration by smear results

 1.3.6.1 Cases by sex and age (legacy)

                                         Cases by sex and age (legacy)

 The [old records only] data sets are not discussed in detail, but the “cases by sex and age”
 section/table deserves a special comment. The previous TB reporting framework (2006 version)
 allowed some variations in how notifications where disaggregated by age. Consequently,
 different countries use a few different age disaggregations. Because the TB configuration
 package is designed to be used in different countries/contexts, the “cases by sex and age” section
 uses a sex category that includes “unknown sex”, and an age category that includes a few
 different, overlapping age options. For example, it includes both 0-4 years, 5-14 years and 0-14
 years. This is in general not a recommended approach as 1) the category total does not make
 sense, and 2) there is a risk for double counting if all age brackets are used. However, this was
 done here for the following reasons:

      • It is only used for the historical data, which is not intended to be typed in manually (and if
        typed manually
      • Since it is designed for use with already existing data, there should not be any case where
        data exists for any of the overlapping
      • Including only one set of age options and leaving it to each country to add the once they
        need could work, but would require updates to indicator formulas as new category option
        combos would be generated.
      • Individual category options can be re-used, both the current and the old frameworks.
        When using category option groups, it is possible to define age disaggregations that work
        over time even as the reported age brackets change.
      • Quite a large number of countries have saved their historical data in a global DHIS2
        database maintained by the WHO GTB, where this category is used (for the above reasons).
        If a different category was used for the historical data in the TB configuration package,
        moving this data into the national DHIS2 database would be more complicated.

                                                                                                         11
2 TB Case Surveillance Program (Tracker)                                                  2.1 Summary

  2 TB Case Surveillance Program (Tracker)
  DHIS2 Version compatibility 2.33

  2.1 Summary

  The TB Case Surveillance Tracker digital data package for DHIS2 is based on the WHO recording
  and reporting framework from 2013. It provides a set of recommended metadata (data elements,
  program rules, etc) to enable electronic capture of individual/case-based TB surveillance data.
  The tracker metadata is configured to ensure that aggregated standard quarterly TB report
  indicators on notifications, first-line outcomes and second-line outcomes as defined by theWHO
  Definitions and reporting framework for TB (2013) can be automatically generated from the
  individual data captured. The TB Case Surveillance Tracker is not intended to support patient
  management or patient care. This requires more detailed analysis of roles, responsibilities,
  workflows and decision-making within the settings in which such systems would be
  implemented.

  2.2 Purpose & Intended Audience

  This document describes the conceptual design, content and functionality for a standard DHIS2
  tracker program for case-based surveillance of tuberculosis (TB) based on WHO technical
  guidance and metadata requirements.

  This document is intended for audiences responsible for implementing TB data systems and/or
  HMIS in countries, including:

      1. System admins/HMIS focal points: those responsible for installing metadata packages,
         designing and maintaining HMIS and/or TB data systems
      2. TB program focal points responsible for overseeing data collection, management, analysis
         and reporting functions of the national TB programme
      3. Implementation support specialists, e.g. those providing technical assistance to the TB
         programme or the core HMIS unit to support & maintain DHIS2 as a national health
         information system and/or TB data system

  The system design document explains how the tracker program was configured to meet the data
  entry and analysis requirements and support a typical workflow. The document does not include
  an exhaustive listing of all metadata captured. This document also does not consider the
  resources and infrastructure needed to implement such a system, such as servers, power,
  internet connections, backups, training and user support. More information on the TB
  programme technical aspects informing this system design is available in the WHO publication on
  electronic recording and reporting for tuberculosis care and control. Supplementary
  implementation guidance for DHIS2 can be found in the DHIS2 Implementation guide [general]
  and DHIS2 tracker implementation guide

  2.3 Contexte

  Reliable epidemiological data is required for staff at all levels of a national TB programme to plan
  and provide effective tuberculosis care and control services, as well as monitor the performance
  of programmatic actions. A case-based surveillance system has clear advantages over an
  aggregate data collection system. Like an aggregate surveillance system a minimum set of
  epidemiological indicators can be captured, validated, aggregated, calculated and displayed but
  these can be disaggregated by any combination of time, location/area, age, sex, case type,
  previous treatment history, HIV status, drug resistance status and treatment regimens. This helps
  us to understand TB epidemiology in depth and monitor changes over time.

12
2 TB Case Surveillance Program (Tracker)                                  2.4 System Design Overview

  It is expected that case-based electronic data will result in improved data quality because the
  number of data entry steps are reduced, automatic calculations and validations can be built into
  the system, inconsistent, erroneous or incomplete data can be corrected or completed rapidly for
  an individual record and de-duplication can be carried out to remove duplicate records. A case-
  based surveillance system should also allow the linking of surveillance records to the same case
  even if a TB case is transferred or referred between facilities during the course of treatment.

  At the national level, case-based data can either be matched routinely to other data sources, such
  as HIV or diabetes databases, to measure the burden of co-morbidities and improve patient care,
  or to other TB data sources to quantify the level of under-reporting of TB cases to the NTP.
  Matching TB clinical data to TB genotyping data from the laboratory can also lead to the
  detection and investigation of outbreaks for public health action.

  Finally case-based data can be used in epidemiological observational research studies support
  making informed decisions on programmatic changes based on scientific evidence. The data
  captured should not exceed the purposes outlined.

  See principle 2.4, page 16, of Policy on the Protection of personal Data of Persons of Concern to
  UNHCR (http://www.refworld.org/docid/55643c1d4.html)

  2.4 System Design Overview

  2.4.1 Use Case

  The TB Case Surveillance Tracker enables registration and longitudinal tracking of TB cases from
  the point of notification to final case outcome, inclusive of laboratory results. The program
  captures a minimum set of data points required for epidemiological analysis of case surveillance
  data as described in the background section. These include baseline and demographic
  information about the case, risk factors, laboratory results, drug resistance type classification,
  treatment regimens provided, and case outcome. This tracker program is not designed to
  support clinical management nor patient care. The program serves as an electronic registry that
  supports decentralized electronic data capture of case surveillance data down to health facility
  level; parts of the tracker program are also configured to allow data entry directly by
  laboratories. Depending on infrastructure and resource availability in-country, data entry can
  also be conducted at the district or higher levels based on paper registers.

  Workflows in countries may vary and the case surveillance program should be adapted as
  needed to local context. For example, this design assumes that a case is first entered into the
  DHIS2-based electronic registry when baseline information and risk factors become available at a
  clinical visit. However, the program stages can be re-ordered in contexts where a case may first
  be entered into the electronic system when a laboratory result becomes available and baseline
  information entered retrospectively.

  2.4.2 Program Structure

  The structure of the program in DHIS2 is as follows:

                                                                                                       13
2 TB Case Surveillance Program (Tracker)                             2.5 Tracker Program Configuration

                                            System Design

  2.5 Tracker Program Configuration

  2.5.1 Program Details

  The Tracked Entity Type for this program is a ‘person’. Tracked entity types are often shared
  across programs in an integrated DHIS2 instance. The program is configured to require the user
  to search a minimum 1 attribute before registering a new TEI.

  2.5.1.1 Accès

  The access level is configured as protected in order to protect personally identifiable data from
  unauthorized access, The user may search and read tracked entity instances that are owned by
  the organisation unit to which the user is assigned data capture access. If a user searches for a
  TEI that exists outside of their organisation unit, that the user does not have data capture
  authority for, the user is presented with the option to access the patient record by first recording
  a reason. This approach to privacy is known as ‘breaking the glass’, since it allows the user to
  perform their work without outside permission or assistance, but leaves a clear trail to be
  audited. Once the user gives a reason for breaking the glass, then gain temporary ownership of
  the tracked entity instance (see the Tracker User Guide for more information.)

  2.5.2 Enrollment Details

  The enrollment date is conceptualized as the ‘date of TB diagnosis’. A TEI is allowed to have
  multiple enrollments, as it is possible that a case would enter the system more than once
  (i.e. recovers and becomes a case again). In situations where a case was previously enrolled in a
  TB Case Surveillance tracker, it is possible to see Enrollment History using the Enrollment Widget.

14
2 TB Case Surveillance Program (Tracker)                                              2.5.3 Les attributs

  2.5.3 Les attributs

  When a case is enrolled into the TB case surveillance as a tracked entity instance (TEI), TEI
  attributes are recorded to form the case profile. Note that where the TB tracker program is
  installed alongside other programs in a DHIS2 instance, these common attributes may be shared
  across different programs (e.g. first name, last name, date of birth).

  2.5.4 Stage 1: TB Registration

  The TB registration stage captures baseline information, risk factors and comorbidities including
  HIV status. This is a non-repeatable program stage. While most of the information on the
  baseline stage should be completed when a case is first enrolled, this stage can be updated at
  any point during the enrollment if new information is available (most notably updates to the site
  of disease or HIV status).

  The event date for TB Registration is the date of data capture (or reporting) in DHIS2.

  The TB Registration Event is automatically generated after the enrollment stage.

                                                                                                      15
2 TB Case Surveillance Program (Tracker)                                2.5.4 Stage 1: TB Registration

                                            Enrollment

  The data element [Current Address (on map)] is configured as type ‘coordinates’ to enable
  geospatial analysis in the Maps app.

  The data element [History of Previous Treatment] follows the standard WHO definitions:

     New           New patients have never been treated for TB or have taken anti-TB drugs for
                   less than 1 month
     Relapse       Previously treated patients have received 1 month or more of anti-TB drugs in
                   the past. Relapse patients have previously been treated for TB, were declared
                   cured or treatment completed at the end of their most recent course of
                   treatment, and are now diagnosed with a recurrent episode of TB (either a
                   true relapse or a new episode of TB caused by reinfection).

16
2 TB Case Surveillance Program (Tracker)                                   2.5.5 Stage 2: Laboratory Results

    Treatment       Previously treated patients have received 1 month or more of anti-TB drugs in
    after           the past. Treatment after failure patients are those who have previously been
    failure of      treated for TB and whose treatment failed at the end of their most recent
    first-line      course of treatment.
    treatment
    Treatment       Previously treated patients have received 1 month or more of anti-TB drugs in
    after           the past. Treatment after failure patients are those who have previously been
    failure of      treated for TB and whose treatment failed at the end of their most recent
    second-         course of treatment.
    line
    treatment
    Treatment       Previously treated patients have received 1 month or more of anti-TB drugs in
    after lost      the past. Treatment after loss to follow-up patients have previously been
    to follow-      treated for TB and were declared lost to follow-up at the end of their most
    up              recent course of treatment. (These were previously known as treatment after
                    default patients.
    Other           Previously treated patients have received 1 month or more of anti-TB drugs in
    previously      the past. Other previously treated patients are those who have previously
    treated         been treated for TB but whose outcome after their most recent course of
                    treatment is unknown or undocumented.
    Unknown         Patients with unknown previous TB treatment history do not fit into any of
                    the categories listed.

  Several program rules have been configured in this stage to improve data quality and ease of
  data entry. If the case is not listed with an HIV diagnosis and has not been tested more in more
  than 6 months, a program rule will show the following warning to prompt re-testing:

                                           Warning HIV retesting

  2.5.5 Stage 2: Laboratory Results

  This stage is repeatable. Data can be entered by clinicians, facility staff, lab staff or district TB
  staff depending on country context. The event date is the ‘date of sample collection.’

  Results for multiple test types for the same sample collection can be entered in one event.

  The TB Case Surveillance Tracker package allows capturing data for 14 types of diagnostic tests.
  Data elements captured for each type of test are specific to the test, including which type of test
  was conducted, the date of lab results, specimen number, and case whether resistance was
  detected. Relevant tests can be included in or excluded from the Laboratory Results stage in
  DHIS2 depending on their availability in the National Reference Laboratory (NRL) in the
  implementing country. Similarly, the list of drugs for Phenotypic DST can be adapted according to
  first- and second-line drugs relevant to the country. In both cases, this is done through Constants
  during initial configuration of the package. (See Section Constants)

                                                                                                          17
2 TB Case Surveillance Program (Tracker)                             2.5.5 Stage 2: Laboratory Results

  A sample of the data entry form for select test types is shown below:

                                     Sputum Smear Microscopy

                                           Xpert MTB/RIF

                                                 DST

18
2 TB Case Surveillance Program (Tracker)                                        2.5.6 Stage 3: Treatment

                                                       LPA

  Data entered in the Laboratory Stage are used to calculate case and resistance classification
  using program rules, which can also be displayed in the Top Bar Widget and Feedback widget in
  the Tracker Capture App. Program uses data elements automatically filled by program rules,
  including a DE ‘resistance classification’ based on laboratory results. DE’s also include the date
  when resistance to rifampicin was detected, when resistance was ‘first detected’ in the case of
  multiple tests in the Status section. These dates are required for specific indicator calculations.

  2.5.6 Stage 3: Treatment

  The treatment stage is a repeatable stage that should be limited to two events to account for one
  change of treatment regimen. Program rules are used to ensure that the same regimen cannot
  be entered twice. The event date is the ‘date of treatment initiation’. If there is a change in
  treatment regimen, a second event will be recorded and the date of treatment initiated reflects
  the initiation of the new treatment regimen. The ‘expected date of treatment initiation’ is
  automatically scheduled three days from enrollment; it can be rescheduled manually.

                                                   Treatment

  2.5.6.1 Section: TB Drug Resistance Type Classification

  This section allows a user to overwrite the DE [Resistance Classification] that was automatically
  generated by a Program Rule based on laboratory results in the system. For example, a doctor/
  clinician may determine classification status other than the one automatically calculated by the
  formulas included in this program.

                                                                                                        19
2 TB Case Surveillance Program (Tracker)                                      2.5.6 Stage 3: Treatment

                                       Assigning resistance classification

  2.5.6.2 Section: Treatment Regimen

  The program supports first-ling and second-line treatment regimens, with a complete list of
  drugs that can be modified according to national availability and treatment guidelines. The use of
  Constants helps an implementer to enable/disable the treatments from appearing for the data
  entry user.

  2.5.6.3 Start dates for treatment

  Capturing treatment start dates are important because outcomes for cases with second-line
  treatment are evaluated based on the date started on second-line treatment; while outcomes for
  cases on first-line treatment are evaluated based on the enrollment (the date of diagnosis). First-
  line and second-line treatment start dates are automatically calculated based on program rules
  and included in this stage as data elements to ensure they can be used properly for analysis
  (e.g. to calculate number of days delay in receiving treatment, for example).

  2.5.6.4 Outcome due dates

  A DE ‘outcome due’ automatically calculates a date using a program rule based on the type of
  treatment (first-line or second-line) and treatment initiation date. When a treatment regimen is
  selected, the “Outcome Due” date is calculated and assigned according to the length of that
  treatment (for first-line treatments, outcome due date is scheduled 9 months from treatment
  initiation date; for second-line treatment, the outcome date is scheduled for 24 months from
  treatment initiation date).

20
2 TB Case Surveillance Program (Tracker)                                        2.5.7 Stage 4: Outcome

                                           Outcome due date

  2.5.7 Stage 4: Outcome

  2.5.7.1 Outcome date and due date

  The outcome stage is completed at the end of the enrollment. The event date for this program
  stage is conceptualized as the ‘date of outcome’. The event due date is configured with the
  description ‘expected date of outcome. By default, the due date for outcome section is scheduled
  for 180 days after enrollment date’. Current functionality of DHIS2 v 2.33 does not allow assigning
  the calculated DE ‘Outcome Due’ from the Treatment stage as the due date for the Outcome
  stage. The Outcome stage due date may be changed manually, but can only be rescheduled
  once. For a user, this may be done after Treatment has been initiated and the DE in the
  Treatment stage ‘Outcome Due’ has been generated. When an Outcome stage is overdue (the
  current date is later than the calculated DE ‘Outcome due’ from the Treatment stage, a message
  is displayed in the Feedback Widget.

  2.5.7.2 Treatment Outcome

  When an outcome is selected as part of the option set, program rules show the user the WHO
  outcome definition to help ensure that correct outcome definitions are recorded. These program
  rules take into account the type of treatment (first-line or second-line) in order to display the
  proper outcome definition.

  In addition, outcomes ‘cured’, ‘completed’ and ‘not evaluated’ can only be entered after 6 months
  have passed from the Enrollment Date (date of diagnosis). A treatment outcome of ‘failed’ can
  only be entered 5 months after the Enrollment Date (date of diagnosis).

                                               Outcome

  2.5.7.3 Denotifying a TB Case

  This stage also allows a user to ‘denotify’ the TB case. For example, if laboratory results for a
  clinically diagnosed TB case are negative, a user may denotify the case because it is not TB. The

                                                                                                        21
2 TB Case Surveillance Program (Tracker)                                          2.5.8 Program Rules

  denotification can also be used if a duplicate case is found in the system. When the ‘Denotify
  case’ DE is checked, the user is prompted to select a reason for denotifying from the option set
  and provide additional evidence for denotification or provide duplicate TB record number in case
  of duplication. When a case has been denotified for any reason, the case is excluded from
  analysis of TB cases.

  2.5.7.4 Completing Outcome Stage

  A prompt Select an outcome or specify if this is not a TB case. appears next to the Treatment
  Outcome triggered by a program rule. It is not possible for the user to complete the Outcome
  stage without specifying an outcome or denotifying the case. The Outcome stage is configured to
  block data entry after the stage is completed.

                                       Completing outcome stage

  2.5.8 Program Rules

  Program rules are used extensively in the TB Case Surveillance Program to show/hide data
  elements to optimize the data entry form, show warnings/feedback to the data entry user and
  autocalculate & assign data values to data elements. Selected program rules for understanding
  the configuration of this program for TB Case Surveillance are described below. A complete list of
  program rules can be found in the Metadata Reference File.

  2.5.8.1 Limit Number of Treatment Events

  For TB Case surveillance, only one Treatment event should be captured for each change in
  treatment regimen (e.g. from first-line to second-line). Program rules are used to limit the
  number of events to one change in treatment regimen. To ensure that the same regimen cannot
  be entered twice, an event that has first-line treatment will only allow selection of second-line
  treatment regimen in a second event and vice versa.

  2.5.8.2 Limit Outcome options and Show outcome definitions

  In the Outcome stage, program rules are configured to ‘show warning’ that provides the data
  entry user with the WHO case outcome definition depending on whether first- or second-line
  treatment was provided.

     Outcome         Cured
     Definition      A pulmonary TB patient with bacteriologically confirmed TB at the beginning
     (First-line     of treatment who was smear- or culture-negative in the last month of
     Treatment)      treatment and on at least one previous occasion.

22
2 TB Case Surveillance Program (Tracker)                                          2.5.8 Program Rules

    Definition      Treatment completed as recommended by the national policy without
    (Second-        evidence of failure AND three or more consecutive cultures taken at least 30
    line            days apart are negative after the intensive phase. For Treatment failed, lack
    Treatment)      of conversion by the end of the intensive phase implies that the patient
                    does not convert within the maximum duration of intensive phase applied
                    by the programme. If no maximum duration is defined, an 8-month cut-off
                    is proposed. For regimens without a clear distinction between intensive and
                    continuation phases, a cut-off 8 months after the start of treatment is
                    suggested to determine when the criteria for Cured, Treatment completed
                    and Treatment failed start to apply.
    Règles du       1. Option is not available for outcomes that are recorded within the period
    programme       of 6 months after enrollment. 2. Option is not available for cases that are
                    clinically diagnosed. 3. Option is not available for extra-pulmonary TB cases
                    undergoing second-line treatment (Error message is displayed).
    Outcome         Completed
    Definition      A TB patient who completed treatment without evidence of failure BUT with
    (First-line     no record to show that sputum smear or culture results in the last month of
    Treatment)      treatment and on at least one previous occasion were negative, either
                    because tests were not done or because results are unavailable.
    Definition      Treatment completed as recommended by the national policy without
    (Second-        evidence of failure BUT no record that three or more consecutive cultures
    line            taken at least 30 days apart are negative after the intensive phase. For
    Treatment)      Treatment failed, lack of conversion by the end of the intensive phase
                    implies that the patient does not convert within the maximum duration of
                    intensive phase applied by the programme. If no maximum duration is
                    defined, an 8-month cut-off is proposed. For regimens without a clear
                    distinction between intensive and continuation phases, a cut-off 8 months
                    after the start of treatment is suggested to determine when the criteria for
                    Cured, Treatment completed and Treatment failed start to apply.
    Règles du       Option is not available for outcomes that are recorded within the period of
    programme       6 months after enrollment.
    Outcome         Failed
    Definition      A TB patient whose sputum smear or culture is positive at month 5 or later
    (First-line     during treatment.
    Treatment)

                                                                                                    23
2 TB Case Surveillance Program (Tracker)                                          2.5.8 Program Rules

     Definition     Treatment terminated or need for permanent regimen change of at least
     (Second-       two anti-TB drugs because of: lack of conversion by the end of the intensive
     line           phase, or bacteriological reversion in the continuation phase after
     Treatment)     conversion to negative, or evidence of additional acquired resistance to
                    fluoroquinolones or second-line injectable drugs, or adverse drug reactions
                    (ADRs). For Treatment failed, lack of conversion by the end of the intensive
                    phase implies that the patient does not convert within the maximum
                    duration of intensive phase applied by the programme. If no maximum
                    duration is defined, an 8-month cut-off is proposed. For regimens without a
                    clear distinction between intensive and continuation phases, a cut-off 8
                    months after the start of treatment is suggested to determine when the
                    criteria for Cured, Treatment completed and Treatment failed start to apply.
                    The terms “conversion” and “reversion” of culture as used here are defined
                    as follows: Conversion (to negative): culture is considered to have converted
                    to negative when two consecutive cultures, taken at least 30 days apart, are
                    found to be negative. In such a case, the specimen collection date of the first
                    negative culture is used as the date of conversion. Reversion (to positive):
                    culture is considered to have reverted to positive when, after an initial
                    conversion, two consecutive cultures, taken at least 30 days apart, are found
                    to be positive. For the purpose of defining Treatment failed, reversion is
                    considered only when it occurs in the continuation phase.
     Règles du      Option is not available for outcomes that are recorded within the period of
     programme      5 months after enrollment.
     Outcome        Died
     Definition     A TB patient who dies for any reason before starting or during the course of
     (First-line    treatment.
     Treatment)
     Definition     A patient who dies for any reason during the course of treatment.
     (Second-
     line
     Treatment)
     Règles du      -/-
     programme
     Outcome        Lost to follow-up
     Definition     A TB patient who did not start treatment or whose treatment was
     (First-line    interrupted for 2 consecutive months or more.
     Treatment)
     Definition     A patient whose treatment was interrupted for 2 consecutive months or
     (Second-       more.
     line
     Treatment)
     Règles du      -/-
     programme
     Outcome        Not evaluated
     Definition     A TB patient for whom no treatment outcome is assigned. This includes
     (First-line    cases “transferred out” to another treatment unit as well as cases for whom
     Treatment)     the treatment outcome is unknown to the reporting unit.

24
2 TB Case Surveillance Program (Tracker)                                               2.5.8 Program Rules

    Definition          A patient for whom no treatment outcome is assigned. (This includes cases
    (Second-            “transferred out” to another treatment unit and whose treatment outcome
    line                is unknown).
    Treatment)
    Règles du           Option is not available for outcomes that are recorded within the period of
    programme           6 months after enrollment.

  2.5.8.3 Auto-assigned data element values

  Data values (options within an option set) are automatically assigned to the data elements Case
  Classification and Resistance Classification when data is entered in the laboratory stage. These
  classification data elements are also displayed in the top bar as part of the TEI dashboard for
  easy access when a user has the data entry forms open for a given TEI in theTracker Capture app.

  Case Classification (DE)

  This data element is automatically populated by program rules based on the following criteria.
  The Case Classification is assigned a value as ‘clinically diagnosed’ until lab data are entered upon
  enrollment in the program.

    Clinically               Default classification status when enrolling a case in TB Case
    diagnosed                Surveillance.
    Bacteriologically        If Laboratory Results are entered in DHIS2 for the following types of
    confirmed                tests: Positive results for Sputum Smear Microscopy or Culture; MTB/
                             Drug Resistance detected by WHO Rapid Diagnostic Tests or LPA. The
                             program does not prevent users from entering DST results prior to
                             entering results of preceding tests in the Lab stage. Entering only DST
                             results does not change the confirmation method from “Clinically
                             diagnosed” to “Bacteriologically confirmed” since DST testing is
                             dependent on Culture.

  Resistance Classification (DE)

  This data element is automatically populated by program rules based on the following criteria.
  However, in practice a data entry user can manually change the classification (e.g. if a doctor/
  clinician has determined the case is DR).

    DS (Drug            Default classification when enrolling a case in TB Case Surveillance. The
    susceptible)        Classification is automatically assigned the option ‘DS (drug susceptible)’
                        until additional lab data are entered.
    DR (Drug            Resistance to any drug
    resistant)
    Mono Res            Resistance to one first-line anti-TB drug only
    (Mono-
    resistant)
    Poly Res            Resistance to more than one first-line anti-TB drug, other than both
    (Poly-              isoniazid and rifampicin
    resistant)
    RR                  Resistance to rifampicin detected using phenotypic or genotypic methods,
    (Rifampicin         with or without resistance to other anti-TB drugs. It includes any resistance
    resistant)          to rifampicin, in the form of mono-resistance, poly-resistance, MDR or XDR.

                                                                                                          25
2 TB Case Surveillance Program (Tracker)                                                2.5.8 Program Rules

     MDR                Resistance to at least both isoniazid and rifampicin
     (Multidrug
     resistant)
     XDR                Extensive drug resistance (XDR): resistance to any fluoroquinolones
     (Extensive         (levofloxacin or moxifloxacin, and one second-line injectable drug
     drug               (amikacin), in addition to multidrug resistance
     resistant)
     RR/MDR             Not-laboratory confirmed cases that began on second-line treatment (More
                        information in the Treatment section).

  Treatment Initiation & Outcome Due Dates

  Program rules are used to assign the event date of the Treatment Program stage as DEs for ‘First-
  line treatment start’ and ‘Second-line treatment start.’ In addition, a DE ‘Expected date of
  outcome’ is completed by a program rule and included in both the Treatment and Outcome
  stages. For first-line treatment, the expected outcome date is 9 months from treatment initiation
  date. For second-line treatment, the expected outcome date is 24 months from treatment
  initiation. The dates are also used for analysis. For example, the number of days delay in
  treatment is calculated based on the time between diagnosis and initiation of treatment.

  2.5.8.4 Illustrative Scenarios

  In the context of TB Case Surveillance, combinations of program rules apply the following to
  difference case scenarios:

     No laboratory                 Available outcomes in the Outcome       If the case is not TB, it is
     results or                    stage: died, lost to follow up.         possible to “denotify” the
     treatment for the                                                     case in the Outcome stage.
     case has been                                                         This will remove the case
     recorded                                                              from analytics processes.
     No laboratory                 First-line treatment start date is      When adding a second
     results have been             recorded in the status section. An      Treatment event, the user
     recorded. The case            expected date of treatment              will be prevented from
     is placed on first-           outcome (9 months from treatment        selecting first-line treatment
     line treatment and            initiation date) is also displayed in   in the treatment regimen.
     no previous                   the Status section in the Treatment
     treatment event               stage.
     has been
     registered.
     Laboratory results            First-line treatment start date is      When adding a second
     have been                     recorded in the status section. An      Treatment event, the user
     recorded and drug             expected date of treatment              will be prevented from
     resistance has                outcome (9 months from treatment        selecting First-line
     been detected. The            initiation date) is also displayed in   treatment in the treatment
     case is placed on             the status section. A warning           regimen.
     first-line Treatment          message is displayed in the
     and no previous               Feedback Widget: Drug resistance
     treatment event               detected and patient is on first-line
     has been                      treatment.
     registered.

26
2 TB Case Surveillance Program (Tracker)                                         2.5.9 Top Bar Widget

    No laboratory          The case is registered as a clinically   Once laboratory results are
    results have been      diagnosed RR/MDR case. Second-           entered in the Laboratory
    recorded and no        line treatment start date is             Results stage the
    previous treatment     recorded in the status section.          classification is
    recorded, but the      Expected date of treatment               automatically reassigned by
    case is placed on      outcome (24 months from                  the system. When adding a
    second-line            treatment initiation date) is            second Treatment event,
    treatment              displayed in the status section.         the user is prevented from
                                                                    selecting Second-line
                                                                    treatment in the treatment
                                                                    regimen.
    Laboratory results     Second-line treatment start date is      When adding a second
    have been              recorded in the status section.          Treatment event, the user
    recorded in DHIS2      Expected date of treatment               will be prevented from
    and drug               outcome (24 months from                  selecting Second-line
    resistance has         treatment initiation date) is            treatment in the treatment
    been detected. No      displayed in the status section.         regimen.
    previous treatment
    event is registered.
    The case is placed
    on second-line
    treatment
    No laboratory          Second-line treatment start date is      It is not possible to create
    results have been      recorded in the status section.          new Treatment events.
    recorded in DHIS2.     Expected date of treatment
    Previous treatment     outcome (24 months from
    event was first-line   treatment initiation date) is
    treatment. The         displayed in the status section.
    case is placed on
    second-line
    treatment.
    Laboratory results     Second-line treatment start date is      It is not possible to create
    have been              recorded in the status section.          new Treatment events.
    recorded in DHIS2      Expected date of treatment
    and drug               outcome (24 months from
    resistance has         treatment initiation date) is
    been detected.         displayed in the status section.
    Previous treatment
    event was First-line
    Treatment. The
    case is placed on
    Second-line
    Treatment.

  2.5.9 Top Bar Widget

  The top bar widget within the Tracker Capture app is useful for the data entry user to have a
  snapshot overview of information about the TEI (case) every time the TEI enrollment is opened
  for this program.

  The table below summarizes program indicators and variables displayed in the Top Bar Widget
  and how they are calculated. “Type” refers to whether a particular variable is configured as a

                                                                                                   27
2 TB Case Surveillance Program (Tracker)                                         2.5.10 Feedback Widget

  program indicator with the “display in form” option enabled, or if it is calculated and displayed
  using program rules.

     Variable          Type         Calculation
     Current age       Program      Number of years between current date and the “Date of birth
     (years)           indicator    (age)” tracked entity attribute.
     Months            Program      Number of months from enrolment in the program
     since             indicator    (notification date) to the current date.
     enrolment
     Treatment         Program      Showing the current (latest) treatment regimen recorded
     regimen           rule         (initial first-line, retreatment first-line, second line)
     Case              Program      If no positive culture, smear or Xpert MTB result is recorded in
     classification    rule         the lab stage, the classification is “clinically diagnosed”. If a
                                    positive result is recorded for any of the tests, the
                                    classification is “Bacteriologically confirmed”.
     Resistance        Program      Based on Xpert RIF results and any resistance results from the
     classification    rule         DST program stage, the case is classified as drug susceptible
                                    (DS), or with different types of drug resistance (DR, RR, MDR,
                                    XDR). The case is classified as a “Non-lab confirmed DR” case if
                                    this is selected on the treatment page AND no drug resistance
                                    results are recorded.
     Resistance        Program      Lists the drugs for which drug resistance have been detected
                       rule         through Xpert RIF or DST testing.

  2.5.10 Feedback Widget

  The following feedback messages are configured to display in the Feedback Widget when certain
  conditions are met as outlined in the table below:

     Message                         Condition
     Drug resistance detected        Patient is on first-line treatment, despite having lab/DST
     and the patient is on first-    results indicating drug resistance.
     line treatment.
     GeneXpert MTB not               Xpert MTB results are “Not detected”, which indicate that
     detected. This may not be a     this is not a TB case
     TB case.
     No drug resistance              Patient is on second-line treatment, without lab/DST results
     detected, but patient is on     indicating drug resistance.
     second-line treatment.
     Only two treatment events       User adds a third treatment event. Only two are supported,
     can be added.                   to account for initial treatment regimen, and one change in
                                     regimen.
     Outcome is overdue.             If the current date is later than the calculated DE ‘Outcome
                                     due’ in the treatment section, then the message appears in
                                     the feedback widget.
     Please immediately              The “Not TB” checkbox is completed, indicating that a case
     complete the treatment          is not TB and the enrollment should be closed.
     outcome.

28
2 TB Case Surveillance Program (Tracker)                                          2.6 Additional features

    Message                            Condition
    Positive smear result              A positive smear result has been recorded, but the value
    recorded. Review the               entered for “Site of disease” does not include “Pulmonary”.
    reported “Site of disease”.

  2.6 Additional features

  2.6.1 Les constantes

  TB Case Surveillance Tracker package includes a set of tests and a list of drugs that can be
  modified by the implementing country according to national context (e.g. which drugs and tests
  are used/available in country). The use of constants enables a system admin in an implementing
  country to easily ‘turn on’ or ‘turn off’ types of drugs and tests depending on availability in
  country. When the complete package is installed into a DHIS2 instance, all data elements for all
  tests and drugs included in this package are included in the system. By default, all constants are
  set to ‘1’ (enabling the related data elements for data entry) and can be configured to ‘2’ by an
  implementer or system admin according to country context if not needed (disabling the related
  data elements for data entry). If a test or drug later becomes available in the country, an admin
  can simply re-enable the data elements by changing the constant from a value of ‘2’ to a value of
  ‘1’.

                                                 Constants

  2.7 Analytics and program indicators

  This section describes the program indicators and analytics that have been configured for an
  analytics user.

  2.7.1

          • Program indicators aggregating
          • Specific program indicators for case-based systems [defined in the draft spec]

  2.7.2 Reporting case-based data into aggregate TB reports

  The TB case-based surveillance tracker captures data that can be fed into standard, aggregate
  reporting (i.e. monthly, quarterly, or more frequently as determined by the country). An
  aggregate TB system design in DHIS2 can be accessed at who.dhis2.org/documentation/#tb.

  In addition, the package comes with a set of indicators that can be fed into a GTB Report form.

  2.7.3 Dashboard

  A subset of data visualizations from the WHO Aggregate TB Package have been recreated using
  program indicators. These visualizations display data from the Tracker program. These

                                                                                                       29
2 TB Case Surveillance Program (Tracker)                                                2.8 User Groups

  visualizations were selected by WHO as the most useful for monitoring at a facility level more
  frequently, e.g. in between submitting monthly/quarterly aggregate reports to the HMIS. These
  visualizations may also support the facility or district level user to compare the TB case
  surveillance data captured in the Tracker Program with the aggregated data submitted to the
  HMIS.

  2.8 User Groups

  The following user groups are included in the TB Case Surveillance Tracker Package:

      • TB Admin: can edit/view metadata; no access to data [all program stages]
      • TB Data capture: can view metadata, can capture data [all program stages]
      • TB Access: cam view metadata, can view data [all program stages]
      • TB Lab data capture: can view metadata, can capture data [TB registration stage and
        Laboratory stage only]

  2.9 Références

      • Definitions and reporting framework for tuberculosis (2013 revision, updated December
        2014). (http://www.who.int/tb/publications/definitions/en)
      • Understanding and using tuberculosis data. (http://www.who.int/tb/publications/
        understanding_and_using_tb_data/en)
      • Standards and benchmarks for tuberculosis surveillance and vital registration systems:
        Checklist and user guide. (http://www.who.int/tb/publications/standardsandbenchmarks/
        en)
      • Assessment of Uganda DHIS2 MDR-TB case-based module (Report by Arax Hovhanisyan
        following an assessment and visit conducted in June 2017)
      • Assessment of Ghana DHIS2 case-based tracker (Report by Arax Hovhanisyan following an
        assessment and visit conducted in August 2018)
      • Assessment of Tanzania case-based tracker (ETL) (Report by Laura Anderson, Tomas Matas
        and Debora Pedrazzoli following an assessment and visit conducted in July 2018)
      • Electronic recording and reporting for tuberculosis care and control (http://www.who.int/
        tb/publications/electronic_recording_reporting/en)
      • Digital health for the End TB Strategy: developing priority products and making them work
        (http://erj.ersjournals.com/content/48/1/29), especially item 2.2 (Digital notification of TB
        cases) in the online supplement (http://erj.ersjournals.com/content/erj/suppl/
        2016/05/26/13993003.00424-2016.DC1/ERJ-00424-2016_supplement.pdf)
      • Principles for digital development (https://digitalprinciples.org/), in particular the sections
        on ‘Design With the User’ (https://digitalprinciples.org/principle/design-with-the-user/), ‘Be
        Data Driven’ (https://digitalprinciples.org/principle/be-data-driven/) and ‘Address Privacy
        and Security’ (https://digitalprinciples.org/principle/address-privacy-security/)
      • Policy on the Protection of personal Data of Persons of Concern to UNHCR (http://
        www.refworld.org/docid/55643c1d4.html), particularly chapter 2.
      • Ethics guidance for the implementation of the End TB Strategy http://www.who.int/tb/
        publications/2017/ethics-guidance), pages 40-41 and 53-54 on privacy and security.
      • WHO guidelines on ethical issues in public health surveillance (http://www.who.int/ethics/
        publications/public-health-surveillance)

30
3 TB Case Surveillance Tracker Installation Guide                                              3.1 Aperçu

  3 TB Case Surveillance Tracker Installation Guide
  Last updated 04/08/2020

  Package Version 1.0.0

  DHIS2 Version compatibility 2.33.5 and above

  Demo: https://who-demos.dhis2.org/tracker_demo

  Username: TB_Demo Password: TBDemo2020!

  3.1 Aperçu

  The TB Case Surveillance tracker package was developed using DHIS2.33.5. This was done in
  order to support some of the latest features in DHIS2. In order to use the package, it is
  recommended that you install it into a DHIS2 instance using DHIS2 2.33.5 or above. If you will be
  setting this up on a new instance, please refer to the DHIS2 installation guide. This document
  covers the installation of the following packages:

      1. TB Case Surveillance tracker program

  You will have to follow the instructions to ensure that the package is installed and configured
  correctly.

  3.2 Installation

  L’installation du module se fait en plusieurs étapes :

      1. Preparing the metadata file.
      2. Importer le fichier de métadonnées DHIS2.
      3. Configurer les métadonnées importées.
      4. Adapter le programme après son importation

  Il est recommandé de lire d’abord chaque section avant de commencer le processus d’installation
  et de configuration dans le DHIS2. Les sections non applicables ont été identifiées, selon que
  vous importiez dans une nouvelle instance de DHIS2 ou dans une instance de DHIS2 ayant déjà
  des métadonnées. La procédure décrite dans le présent document doit être testée dans un
  environnement de test et de simulation avant d’être répétée ou transférée dans une instance de
  production du système de DHIS2.

  3.3 Conditions requises

  Pour installer le module, il faut nécessairement un compte d’utilisateur administrateur sur DHIS2.
  La procédure décrite dans le présent document doit être testée dans un environnement de test
  et de simulation avant d’être exécutée sur une instance de production du DHIS2.

  Il convient de veiller à ce que le serveur lui-même et l’application DHIS2 soient bien sécurisés,
  afin de limiter l’accès aux données collectées. Les détails relatifs à la sécurisation d’un système
  DHIS2 ne sont pas abordés dans le présent document, et nous renvoyons donc à la
  [documentation DHIS2] (http://dhis2.org/documentation).

  3.4 Préparation du fichier de métadonnées

  NOTE: If you are installing the package on a new instance of DHIS2, you can skip the “Preparing
  the metadata file” section and move immediately to the section Importing a metadata file into
  DHIS2

                                                                                                        31
You can also read