Destiné à être utilisé avec la version master - Équipe de documentation DHIS2 December 2020 - DHIS2 Documentation
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Tuberculosis Destiné à être utilisé avec la version master Équipe de documentation DHIS2 December 2020
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
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
3Table 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
41 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.
51 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
61 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
71 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
81 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
91 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.
101 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.
112 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.
122 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:
132 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.
142 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.
152 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).
162 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)
172 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
182 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.
192 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).
202 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
212 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.
222 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)
232 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.
242 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.
252 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.
262 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
272 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.
282 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
292 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)
303 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
31You can also read
