DHIS2 implementation

guide

Implement

DHIS2 Documentation Team

DHIS2 implementation guide Implement

Copyright © 2008-2023 DHIS2 Team

[Link]: 2024-04-22

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

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

2
[Link] Implement

[Link]
Un guide rapide sur l'implémentation du DHIS2
Planification et organisation
Adaptation du DHIS2
Renforcement des capacités
Directives sur la budgétisation et la planification stratégique pour des systèmes DHIS2
résiliants
DHIS2 Maturity Profile Tool
Considérations budgétaires
Planification et budgétisation du renforcement des domaines fondamentaux
Principes de conception
Toutes les méta-données peuvent être ajoutées et modifiées via l'interface utilisateur
Un modèle de données flexible permet à différentes sources de données d’être intégrées
dans un référentiel de données unique
Entrée de données != Sortie des données
Analyse de données et rapports basés sur les indicateurs
Maintenir les données des établissements agrégées dans la base de données
Soutenir l'analyse des données à tous les niveaux du système de santé
Installation d'une nouvelle base de données
Stratégies de mise en route
Processus ouvert ou contrôlé?
Étapes à suivre pour l'élaboration d'une base de données
Considérations en matière de sécurité{ #security-considerations }
Contexte d'utilisation
Mesures
Hébergement du serveur DHIS2{ #dhis2-server-hosting }
Architecture
Élaboration d'un plan{ #making-a-plan }
Environnement physique
Compétences requises
Maintenance
Installation et configuration du logiciel{ #software-installation-and-configuration }
DHIS2 comme entrepôt de données
Les entrepôts de données et les systèmes opérationnels
Stratégie d'agrégation dans DHIS2{ #aggregation-strategy-in-dhis2 }
Approches pour le stockage de données
DHIS2 en tant que plateforme
Portails Web
Applications
Systèmes d'information
Concepts d'intégration
Intégration et interopérabilité
Objectifs de l'intégration
Échange d'informations sur la santé{ #Health_information }
Données agrégées et transactionnelles
Différents scénarios d'intégration du DHIS2{ #different-dhis2-integration-scenarios }
Modèle de maturité du DHIS2
Étapes de mise en œuvre pour une intégration réussie des données et des systèmes{
#implementation-steps-for-successful-data-and-system-integration }
Cas d'utilisation spécifiques d'intégration et d'interopérabilité{ #specific-integration-and-
interoperability-use-cases }
Principes de qualité des données
Mesure de la qualité des données

3
[Link] Implement

Saisie des données agrégées

Conception de la saisie des données
Règles de validation
Valeurs min-max
Évaluation de la qualité des données
Complétude et ponctualité{ #completeness-and-timeliness }
Cohérence de données associées
Cohérence au fil du temps
Outil de Qualité des Données de l'OMS
Implémentation de fonctionnalités et de procédures relatives à la qualité des données{
#implementing-data-quality-functionality-and-procedures }
Analyse automatique de la qualité des données
Normes minimales de qualité des données
procédure opérationnelle normalisée relative à la qualité des données
Opérations clés de maintenance
Unités d’Organisation
Conception de la hiérarchie de l'unité d'organisation
Groupes d'unités d'organisation et ensembles de groupes
Éléments de données et dimensions personnalisées
Eléments de données
Catégories
Combinaisons d'attributs
Ensembles de groupes et dimensions analytiques
Groupes d'éléments de données
Ensemble de groupes d'éléments de donnée
Ensembles de données et formulaires
Qu'est-ce qu'un ensemble de données?
Qu'est-ce qu'un formulaire de saisie de données ?
Du papier au formulaire électronique - Leçons tirées de l'expérience
Indicateurs
Qu'est-ce qu'un indicateur
Les buts des indicateurs
La collecte de données axée sur les indicateurs
Gestion des indicateurs dans DHIS 2
Procédures de gestion des métadonnées
Instances de développement indisponibles ou mal utilisées
Procédures opérationnelles normalisées pour l'ajout de métadonnées ou la modification
de la configuration
Manque de coordination lors de l'ajout de nouvelles métadonnées
Hypothèses incorrectes lors de l'ajout de packages de données numériques
Révisions des outils de collecte de données au fil du temps
Intégrité et qualité des métadonnées
Évaluation de l'intégrité et la qualité des métadonnées
Examen manuel des métadonnées{ #metadata_assessment_manual }
Utilisation de l'outil d'évaluation des métadonnées
ANNEXE A - Paramètres de l'outil d'évaluation des métadonnées{
#metadata_assessment_tool_annex_a }
Utilisateurs et rôles d'utilisateurs
À propos de la gestion des utilisateurs
Déroulement
Exemple : gestion des utilisateurs dans un système sanitaire
Lignes directrices pour la saisie de données hors ligne à l'aide du DHIS 2{ #offline_data_entry }
Cas et solutions correspondantes

4
[Link] Implement

Intégration des données du tracker et des données agrégées

Approches alternatives{ #alternative-approaches }
Choisir une méthode
Mode opératoire : enregistrement des données tracker agrégées en tant que valeurs de
données agrégées{ #how-to-saving-aggregated-tracker-data-as-aggregate-data-values }
Aperçu des outils d’analyse de données
Les outils d'analyse de données
Localisation du DHIS 2{ #localization-of-dhis-2 }
Concepts de localisation du DHIS 2
Localisation de l'interface utilisateur
Traduction des métadonnées / de la base de données
Guide sur la documentation du DHIS 2
Présentation du système de documentation du DHIS 2
Introduction
Premiers pas avec GitHub
Obtenir la source du document
Modifier la documentation
Bibliographie du DHIS 2
Gestion d'une documentation multilingue
Validation de vos modifications sur GitHub
Prise en charge du Markdown et extensions
Soumission rapide des corrections de documents
Correction de fautes d'orthographe
Utilisation de JIRA pour les problèmes liés à DHIS2
Inscrivez-vous à JIRA - c'est ouvert à tous!
Signaler un problème{ #report-an-issue }
Recherche de problèmes
A propos des filtres
Création d'un filtre
Ajoutez un filtre à votre profil{ #add-a-filter-to-your-profile }
Suppression des termes du filtre de recherche de votre recherche{ #remove-search-
filter-terms-from-your-search }
Nous contacter
Aide
Page d'accueil : [Link]
Plate-forme de collaboration : [Link]
Signaler un problème
Suivi du développement : [Link]{ #development-tracking-jiradhis2org }
Code source: [Link]/dhis2

5
Un guide rapide sur l'implémentation du DHIS2 Planification et organisation

Un guide rapide sur l'implémentation du DHIS2

Toute implémentation du DHIS2 doit viser la mise la place de systèmes durables et flexibles pour
répondre aux besoins changeants du secteur sanitaire. Il est important de reconnaître que cela
prendra plusieurs années, avec des structures continues pour le renforcement des capacités, le
partage des bonnes pratiques et l'innovation. Ce guide rapide donne un aperçu très sommaire des
différentes facettes de l'implémentation du DHIS2.

Planification et organisation

Structures nécessaires

• Une équipe centrale du DHIS (DCT) de 4 à 5 personnes sera nécessaire pour administrer un
HMIS national. Leurs responsabilités et les compétences requises doivent être clairement
définies. Le DCT participera aux académies DHIS2, organisera la formation et l'appui aux
utilisateurs finaux pour différents groupes d'utilisateurs dans le pays.

• Un comité de pilotage technique, ou équivalent, sera nécessaire pour piloter la coordination

entre les programmes de santé, d'autres systèmes informations, les partenaires de
développement et universités. Ils dirigeront les efforts d’intégration et prendront des décisions
sur l'architecture générale des systèmes d'information.

Efforts d'intégration

• Tout au long de l'implémentation, des efforts simultanés d'intégration des systèmes

d'information et d'échange de données doivent être menés. Le principe directeur de ce travail
doit être la création d'un système axé sur les décisions et les indicateurs.

Équipement et Internet

• Une évaluation doit être menée pour définir les besoins en matériel. Ordinateurs de bureau, les
ordinateurs portables, les tablettes et les téléphones portables ont tous des qualités différentes.
généralement, ces technologies sont combinées dans le cadre des programmes.

• Les solutions de serveur et d'hébergement doivent faire l'objet d'un examen minutieux quant à
la capacité, aux contraintes liées aux infrastructures, au cadre juridique et aux exigences en
matière de sécurité et de confidentialité

• Une connexion Internet pour tous les utilisateurs sera nécessaire. Internet mobile sera la
solution adéquate pour la plupart des utilisateurs qui effectue la collecte de données et et des
analyses régulières.

• Les options pour les utilisateurs de téléphones mobiles, les offres SMS, etc., doivent être
examinées si nécessaire.

Stratégie de déploiement

• La DCT jouera ici un rôle clé et chaque membre devra avoir des responsabilisés bien définies
dans le cadre du déploiement : appui aux utilisateurs, formation des utilisateurs, interaction
avec les programmes de santé, etc.

• Des structures d'appui plus étendues doivent être mises en place pour fournir appui,
supervision and communication avec un réseau mondial/régional d'experts et de développeurs.

6
Un guide rapide sur l'implémentation du DHIS2 Adaptation du DHIS2

L'utilisation de l'information doit être un domaine prioritaire dès le début et être un à la fois lors
• de la conception initiale du système et lors la première session de formation des utilisateurs. La
collecte et la qualité des données ne s'amélioreront qu'avec la valeur réelle de l'information. Les
réunions d'évaluation de district et équivalents doivent être soutenu par des informations et des
formations appropriées.

• La formation constituera le principal investissement au fil du temps, et nécessite des structures

pour des opportunités continues. Planifiez une approche de formation à long terme qui répond
à un processus continu d'intégration de nouveaux utilisateurs et de nouvelles fonctionnalités du
système.

• La supervision et l'évaluation de la qualité des données doivent être fréquentes.

Adaptation du DHIS2

Champ d'application du système

• Sur la base des décisions que le système doit prendre en charge (champ d'application du
système) ; la personnalisation et l'adaptation de la plateforme seront nécessaires pour le DHIS2
agrégé, tracker et/ou événements. Chaque action nécessitera une compétence particulière et
devrait être dirigée par la DCT.

• Une évaluation des utilisateurs et bénéficiaires prévus est nécessaire, par exemple en fonction
de leurs besoins en informations, en matériel et en réseau en réseau.

• Une compréhension de l'architecture générale du HIS (l'"écosystème du HIS") est nécessaire ;

quels sont les autres systèmes et comment doivent-ils interagir avec DHIS2 ? Prenez en
compte les besoins d'interopérabilité entre les systèmes électroniques.

• Si des besoins ne sont pas actuellement pris en charge par le DHIS2, un une évaluation du
développement de logiciels supplémentaires est nécessaire. Cela peut se faire localement avec
le développement d'une application Web personnalisée ou en s'inscrivant dans le processus
général de la feuille de route de développement de la plate-forme principale organisé par l'UiO.

Configuration du DHIS2

• Unités de déclaration : mise en œuvre des différentes unités de déclaration (points de service)
et des hiérarchies incluant des groupes.

• Besoins en matière de collecte de données : quels indicateurs sont nécessaires, quelles

variables de données entreront dans leur calcul, et comment ces données doivent-elles être
collectées ? Concevoir des éléments de données, des catégories de désagrégation, des
éléments de données, et des formulaires de collectes.

• Informations pour l'action (indicateurs, tableaux de bord, autres résultats) : Quels sont les
produits d’informations dont les utilisateurs auront besoin ? Tableaux, graphiques, cartes,
tableaux de bord. Diffusion et partage.

• Gestion des utilisateurs : création des rôles et des groupes d'utilisateurs, gestion des
utilisateurs au quotidien, définition des accès aux fonctionnalités et partage approprié des
contenus.

• Document de gouvernance de DHIS2 (rôles par profil, modification des métadonnées et dans
quelles conditions requises). dans quelles conditions requises).

Hébergement

• L'hébergement de DHIS2 à l'échelle nationale est une tâche considérable qui nécessite
planification, approvisionnement, contrôle et gestion de ressources matérielles et/ou sur le

7
Un guide rapide sur l'implémentation du DHIS2 Renforcement des capacités

cloud potentiellement complexes. Pour connaître les avantages et inconvénients des

différentes approches, consultez la section Hébergement du serveur.

Renforcement des capacités

Équipe centrale du DHIS (DCT)

• La DCT aura besoin de toutes les compétences nécessaires pour un système durable et
évolutif. Cela inclut des compétences techniques (adaptation du DHIS2, maintenance du
serveur), connaissance du système (architectures et principes conception), gestion
organisationnelle (stratégies d’intégration) et des projets (organisation d’une assistance
structurée et des formations).

• Les membres de la DCT doivent assister aux Académies DHIS2 régionales/mondiales

fréquemment (par exemple deux fois par an) pour s'assurer une formation de haute qualité, une
communication continue avec la communauté globale d’experts, et pour s'assurer que l'équipe
locale est à jour avec les nouvelles fonctionnalités et améliorations apportées aux versions
récentes de DHIS2. La DCT sera responsable de l'adaptation et de la diffusion de ce
programme de formation régional à un plus grand nombre d'utilisateurs à l'intérieur du pays.

Stratégies nationales de formation

• la DCT doit proposer des formations en rapport avec l'implémentation, et de façon continu, pour
répondre aux demandes croissantes, aux mises à jour du système et à la rotation du personnel.

• Adapter et développer du matériel de formation et des guides de référence qui reflètent les
besoins d'information locaux et le contenu du système local.

Possibilités de formation en continu{ #continuous-training-opportunities }

• À mesure que l'utilisateur acquière de l'expérience, une formation plus avancée doit être
proposée. La formation des médecins de district et des responsables des programmes de
santé sur l'utilisation des informations est cruciale dès le début. Cela permet d'inciter les parties
prenantes à utiliser les informations dans leur prise de décisions.

8
Directives sur la budgétisation et la planification stratégique pour des systèmes DHIS2 Maturity Profile
DHIS2 résiliants Tool

Directives sur la budgétisation et la planification stratégique pour des

systèmes DHIS2 résiliants
Une bonne budgétisation et planification est une activité importante pour maintenir une conception
durable du système dans le temps tout en veillant à ce que le système DHIS2 se développe de
manière saine, soit fréquemment mis à jour, réponde aux besoins des utilisateurs et fonctionne
conformément aux règles et réglementations. Cela implique de s'assurer que le système répond aux
besoins des utilisateurs finaux en termes de collecte de données, de contrôle de la qualité des
données, d'analyse et de présentation des données, et reste pertinent pour tous les programmes clés
de santé en prenant en compte tous les niveaux du système de santé (de établissement/communauté
au niveau national).

Pour mettre en œuvre le système DHIS2 de manière solide, résiliente et qui s'adapte à l'évolution des
besoins programmatiques, il est nécessaire de mettre en place un certain nombre de fonctions
transversales et d'en assurer le bon fonctionnement. Nous les appelons les domaines fondamentaux,
qui comprennent notamment le leadership et la gouvernance, la sécurité et l'infrastructure. Il s'agit
d'éléments de base importants permettant de soutenir les systèmes de données, tant au niveau
agrégé qu'individuel. L'illustration ci-dessous présente les fondements du DHIS2. Ils nécessiteront
tous un soutien financier interne et souvent externe sous forme de renforcement organisationnel et
des capacités, d'une assistance technique et de coûts opérationnels locaux.

Maturity profile domains

Cette section vise à fournir des conseils sur la planification et la budgétisation des activités de
renforcement du système DHIS2, en mettant l'accent sur les domaines fondamentaux. Il n'est pas
évident de fournir des conseils clairs sur le coût de chaque domaine dans ce modèle, puisque
certaines activités varieront grandement en fonction de l'état actuel ou du stade de maturité du
domaine, de la capacité de l'équipe centrale locale de DHIS2 et des niveaux de coûts locaux. Comme
il est impossible de fournir une estimation des coûts génériques en valeur réelle (dollars), nous allons
plutôt présenter les catégories de coûts et les facteurs à prendre en compte pour établir un budget.

DHIS2 Maturity Profile Tool

Il existe un outil ("Profil de maturité DHIS2") permettant de mapper le stade de maturité de la mise en
œuvre du système DHIS2 dans un pays afin d'aider à identifier les domaines ayant besoin d'être
renforcés. L'outil d'évaluation est structuré comme un ensemble de questions propre à chaque

9
Directives sur la budgétisation et la planification stratégique pour des systèmes Considérations
DHIS2 résiliants budgétaires
domaine, comme présenté dans l'illustration ci-dessus. Il fournit un aperçu du stade de maturité
actuelle du DHIS2 dans un pays. Cette évaluation est destinée à être réalisée régulièrement en
collaboration avec les experts DHIS2/groupes DHISP et les ministères de la Santé et fournit des
résultats et des recommandations dans un rapport de synthèse.

Le profil de maturité DHIS2 aide les pays à :

• évaluer et comprendre si le pays fait des progrès pour renforcer son système d'information
sanitaire, en plus de faire une synthèse des activités réalisées ;
• encourager les investissements dans les capacités de base du DHIS2 (c'est-à-dire les
domaines fondamentaux) qui contribuent à créer un système d'information sanitaire durable
soutenant les programmes de santé ;
• aligner les investissements/interventions des donateurs ;
• aider à la planification des activités de mise en œuvre et de renforcement du système DHIS2 ;
et
• identifier les domaines nécessitant une évaluation ou un suivi plus approfondi.

Le profil de maturité DHIS2 est un outil important pour mettre en place et calculer le coût des plans
DHIS2 coordonnés et résilients dans un pays.

Considérations budgétaires

Les coûts se répartissent grosso modo comme suit :

• Frais de personnel locaux (équipe principale de DHIS2 et renforcement des capacités)

• Coûts de l'assistance technique (des groupes HISP ou autres, y compris les honoraires et les
frais de déplacement)
• Coûts opérationnels locaux (par exemple, frais de formation, équipements, hébergement,
assistance aux utilisateurs finaux)

Les investissements les plus importants dans le renforcement du système DHIS2 sont associés au
développement et au maintien de la capacité locale dans le pays, mais pour les nouvelles mises en
œuvre, des frais sont à prévoir pour aider à bien démarrer, pour aider à la configuration initiale, pour
assurer la formation, etc.

Les coûts sont généralement les plus élevés lors du démarrage et de la première mise à l'échelle du
système DHIS2. Certains coûts sont ponctuels, c'est-à-dire qu'ils ne se produiront qu'une fois, comme
la collecte des besoins et la configuration du système initial, mais la plupart des coûts sont récurrents
chaque année. Par exemple, un investissement initial dans l'achat d'ordinateurs ou d'appareils
mobiles doit être soutenu par un plan à long terme pour remplacer un certain de ces appareils chaque
année, et ce indéfiniment. De même, il faut prévoir un plan et un budget pour la formation des
nouveaux employés, les cours de perfectionnement, l'hébergement des serveurs, les audits de
sécurité réguliers, la maintenance et l'amélioration continues des systèmes, etc. Il est très important
de s'assurer qu'il existe un financement à long terme pour soutenir le système.

Selon l'état de l'équipe principale ou le stade de maturité du pays, la nature de l'assistance changera.
Au début d'une mise en œuvre, il peut être nécessaire d'obtenir une aide extérieure, même pour des
activités relativement routinières ou basiques. Au fur et à mesure du développement des capacités
locales et de la constitution d'une équipe principale solide, la plupart des activités peuvent être gérées
en interne. L'expertise extérieure prendra alors principalement la forme de conseils et de renforcement
des capacités dans de nouveaux domaines ou pour de nouvelles fonctionnalités.

Les orientations générales sur la budgétisation se trouvent ici. Notez que les orientations couvrent
principalement les dépenses ponctuelles, mais nous recommandons aux pays de planifier sur du long
terme et de prendre en compte les dépenses récurrentes.

10
Directives sur la budgétisation et la planification Planification et budgétisation du renforcement
stratégique pour des systèmes DHIS2 résiliants des domaines fondamentaux
Planification et budgétisation du renforcement des domaines fondamentaux

Dans la section suivant, vous aurez une description des fondements de DHIS2, des éléments à
prendre en compte en matière de budgétisation et de planification, ainsi que quelques ressources
pertinentes. Plus loin, vous trouverez des conseils pour planifier, budgétiser et construire/maintenir
des programmes agrégés et des programmes de suivi

Leadership et gouvernance

De solides mécanismes de gouvernance et de coordination sont essentiels pour soutenir un HMIS qui
soit cohérent, quel que soit le programme, mais également à jour et bien entretenu. L'objectif est de
mettre en place un comité de direction interministériel réunissant les principales parties prenantes
traitant l'information sanitaire au sein du ministère chargé de prendre des décisions stratégiques de
haut niveau sur le contenu et la portée du DHIS2. Ce groupe devrait être composé de représentants
de tous les principaux programmes de santé, possédant un leadership à la fois technique et en santé
publique, et devrait recevoir un mandat clairement défini. En outre, un groupe de travail technique
peut se réunir plus fréquemment et avoir le mandat de prendre des décisions sur des questions
pratiques.

Bien qu'il ne s'agisse pas d'une solution rapide dans un pays, quel qu'il soit, les conseils et
l'assistance technique des groupes HISP sur la manière d'établir et de gérer de tels mécanismes de
coordination peuvent être utiles. Ils peuvent également aider à préparer ou à participer à de telles
réunions.

Ressources

• Liens vers les directives/les directives de mise en œuvre

• Champ d'action générique

Stratégie et investissement

Avoir une stratégie et des investissements coordonnés consiste à établir des stratégies numériques
qui abordent les domaines où DHIS2 est utilisé, comme le HMIS (données agrégées), la surveillance,
la surveillance basée sur les cas et les données communautaires. Les pays doivent procéder à des
évaluations régulières des besoins en matière de HMIS et élaborer des plans de travail chiffrés. La
pérennité du financement et des investissements en HMIS dans le temps indique également une mise
en œuvre mature du système DHIS2. Cela inclut la planification du renforcement du système DHIS2,
mais aussi la planification des besoins en personnel dans l'ensemble de la « chaîne de données »,
comme le personnel de santé ayant le temps et les compétences nécessaires pour traiter les
données, les responsables de l'information sanitaire des districts, les statisticiens, etc.

Il pourrait y avoir des coûts associés à l'assistance pour soutenir ce travail de développement de la
stratégie, et ce, en effectuant une évaluation des besoins et en rédigeant des plans chiffrés.

Ressources

• Liens vers les directives/les directives de mise en œuvre

Sécurité et conformité du système DHIS2

Les implémentations du DHIS2 doivent se conformer à la législation locale et être protégées contre
les violations et les pertes de données. Cela nécessite un personnel compétent, des politiques bien
définies, des procédures d'audit et des outils et documents de sécurité clés utilisés régulièrement. Il
faudra que le responsable de la mise en application de la politique de sécurité du DHIS2 soit haut
placé au sein du ministère de la santé. Si cette responsabilité n'est pas définie ou si la personne n'est
pas assez haut placée, la supervision et l'application d'autres mesures de sécurité seront
compliquées. De même, la propriété des données et la propriété technique doivent être clairement

11
Directives sur la budgétisation et la planification stratégique pour Équipe principale chargée de la
des systèmes DHIS2 résiliants maintenance du DHIS2
établies et définies pour le système DHIS2. Le propriétaire des données est la personne ou l'unité
responsable de la sauvegarde des données et de la politique de conservation, ainsi que des contrôles
d'accès. Le propriétaire technique est responsable de l'infrastructure, de la gestion du changement et
de la maintenance du système.

Un document décrivant la politique de sécurité du système DHIS2, à savoir les processus et les
procédures de mise en œuvre et de gestion de la sécurité au niveau du serveur, de l'instance et des
données, doit être établi. Un audit interne et/ou externe régulier (par exemple annuel) du système
DHIS2 doit être réalisé afin de s'assurer de la conformité de la mise en œuvre à cette politique qui est
définie. L'audit doit également vérifier si le serveur et les instances du système DHIS2 rencontrent des
problèmes de sécurité.

Enfin, les outils et documents de sécurité clé doivent être disponibles et utilisés selon les besoins.
Parmi ces outils et documents, on peut citer les registres des risques, le modèle de menace,
l'évaluation des facteurs relatifs à la vie privée, les accords de non-divulgation et les plans
d'intervention en cas d'incident.

La sécurité et la conformité dépendent dans une large mesure des politiques et de la délégation de
responsabilités. En outre, on doit tenir compte des ressources permettant au personnel concerné
d'assumer les responsabilités qu'on leur a octroyées dans les coûts de ce domaine. Si aucune
politique et aucun outil et document clés n'est mis pas en place, il peut être nécessaire de prévoir un
budget pour l'assistance technique, et ce, afin de les développer et de les mettre en œuvre. De même,
un plan et un budget doivent être établis au titre des audits réguliers.

Ressources

• Considérations de sécurité lors de la mise en œuvre de DHIS2

• Champ d'action générique

Équipe principale chargée de la maintenance du DHIS2

L'identification d'une équipe centrale, qui est au cœur du déploiement du système DHIS2 et est
responsable de la maintenance quotidienne et du développement ultérieur du système national
DHIS2, constitue une composante vitale de toute mise en œuvre du système DHIS2. Cette équipe
sera une composante essentielle de la pérennité à long terme du système et pour garantir
l'appropriation locale. Elle doit être mise en place dès le début de la mise en œuvre du système
DHIS2 et mener le processus de personnalisation locale.

Le financement d'une équipe peut provenir soit des frais de détachement de personnel auprès
d'organisations externes au ministère de la Santé, soit de salaires annuels si le ministère de la Santé
dispose déjà d'un personnel (entre les programmes et les départements). Pour inciter les gens à
participer et à s'engager à long terme, on peut organiser régulièrement des réunions avec l'équipe
principale, par exemple des ateliers de configuration, des réunions de coordination, des séances de
formation (dans les académies DHIS2 nationales et régionales) pour l'équipe principale.

Afin de renforcer les capacités de l'équipe principale du système DHIS2, il est essentiel que toutes les
activités d'assistance technique soient planifiées de manière à permettre à l'équipe locale d'être
impliquée et de tirer profit d'une expertise extérieure dans la mesure du possible. Le renforcement de
l'équipe principale constitue donc une préoccupation transversale qui doit être prise en compte
lorsque des experts extérieurs sont impliqués, et ce, afin de renforcer l'un des domaines
fondamentaux.

Les coûts incluront les salaires ou le personnel détaché, les déplacements et les indemnités
journalières associés aux ateliers, une assistance technique pour fournir un soutien au renforcement
des capacités, ainsi que les parrainages de l'académie DHIS2.

12
Directives sur la budgétisation et la planification Métadonnées et unités d'organisation de DHIS2{
stratégique pour des systèmes DHIS2 résiliants #dhis2-metadata-and-org-units }
Ressources

• Lien vers la description des rôles/compétences nécessaires au sein de l'équipe principale

• Exemple de plan de renforcement des capacités
• Champ d'action générique

Métadonnées et unités d'organisation de DHIS2{ #dhis2-metadata-and-org-units }

La qualité des métadonnées fait référence à la qualité de la configuration du DHIS2, comme la façon
dont les éléments de données, les indicateurs, les formulaires de rapport (ensembles de données) et
les sorties analytiques (tableaux de bord) sont configurés. Il s'agit, par exemple, de savoir s'il existe
des erreurs de configuration susceptibles de créer des erreurs dans le système ou si les métadonnées
sont organisées de manière à faciliter l'utilisation des informations par les utilisateurs finaux.

La qualité de la hiérarchie des unités organisationnelles (par exemple, les districts, les établissements
de santé) fait allusion à leur représentation complète dans le système DHIS2, dont les secteurs public,
privé et non gouvernemental, et à la mise à jour des informations associées.

Bien que la maintenance des métadonnées et des orgunits fasse en général partie intégrante des
activités courantes de l'équipe principale de DHIS2, il sera souvent nécessaire de prévoir de temps à
autre des évaluations et des exercices de nettoyage des métadonnées. À cet effet, une assistance
technique extérieure peut être nécessaire, car le traitement de certains types de problèmes peut être
très difficile sur le plan technique.

Ressources

• Directives sur la qualité et l'intégrité des métadonnées

• Outil d'évaluation des métadonnées
• Champ d'action générique

Formation des utilisateurs finaux

La formation des utilisateurs finaux du DHIS2 à tous les niveaux du système de santé constitue une
composante essentielle pour réussir de la mise en œuvre du système DHIS2. Les pays doivent
disposer d'un plan pour former systématiquement les nouveaux employés, proposer régulièrement
des cours de perfectionnement et combler les lacunes en matière de formation concernant la saisie, la
validation et l'utilisation des données. L'utilisation des données au niveau local est un problème
courant et un domaine à fort potentiel. Des enquêtes approfondies et une documentation sur les
pratiques locales d'utilisation des données dans les districts sélectionnés sont nécessaires à cet effet.
Sur la base de ces enquêtes, les prochaines étapes peuvent être l'adaptation des outils d'analyse aux
pratiques et aux politiques sur les données locales (y compris les données sur les dénominateurs à
chaque niveau), la conception et la configuration de produits d'analyse de données au niveau local et
la distribution de ces outils à d'autres districts.

Les groupes HISP organisent généralement une formation des formateurs pour aider les pays à
organiser leur propre formation des utilisateurs finaux. Les coûts associés à la formation incluent
l'assistance technique et les frais de déplacements pour les groupes HISP, ainsi que les coûts locaux
pour accueillir et prendre part à la formation en cascade, tels que le lieu, les formateurs, le matériel de
formation, les indemnités journalières, les frais de déplacement, etc.

Ressources

• Liens vers les directives/les directives de mise en œuvre

• Champ d'action générique

13
Directives sur la budgétisation et la planification stratégique pour des Profil des établissements et de la
systèmes DHIS2 résiliants population
Profil des établissements et de la population

Afin d'assurer une vue d'ensemble de la population cible, ainsi que des services et du personnel
disponibles, il est important de disposer de données complètes et à jour sur la population et les
établissements. Lorsque les données sur les registres et les statistiques d'état civil (par exemple, les
naissances et les décès) sont disponibles et complètes, elles peuvent être reliées au système DHIS2
et utilisées pour calculer les dénominateurs. Les données sur la population (dénominateurs)
provenant des données de recensement sont plus généralement utilisées dans DHIS2 et devraient
pouvoir être utilisées au niveau infranational. Les estimations du recensement peuvent ne pas être
disponibles ou convenir à tous les niveaux pertinents utilisés dans DHIS2. De ce fait, des procédures
d'utilisation normalisées et des routines doivent être mises en place, afin de pouvoir utiliser les
projections au niveau local.

Une liste ou un registre des établissements doit être disponible dans DHIS2 et couvrir tous les
établissements pertinents, y compris les unités communautaires lorsque celles-ci sont déclarées.
Cette liste doit être tenue à jour, ce qui, dans la plupart des cas, signifie qu'il existe un processus pour
impliquer le niveau infranational (par exemple, le district) dans la mise à jour de la liste des
établissements. Les données relatives aux ressources humaines (effectifs) doivent également être
liées aux établissements et inclure des informations mises à jour régulièrement sur le type et le
nombre d'employés.

Outre les besoins permanents en personnel pour maintenir ces informations à jour et pertinentes dans
DHIS2, le principal poste de dépenses est l'assistance technique pour intégrer les types de données
pertinents dans DHIS2, soit comme une opération ponctuelle, soit en établissant une certaine forme
d'interopérabilité avec les registres et les statistiques d'état civil, la liste principale des établissements
ou les systèmes de gestion des ressources humaines.

Ressources

• Liens vers les directives/les directives de mise en œuvre

• Champ d'action générique

Infrastructure

On entend par infrastructure adéquate, le fait que le système soit hébergé dans un environnement sûr
et stable (sur site ou dans le nuage), que les utilisateurs finaux disposent de suffisamment d'appareils
fonctionnels et qu'en cas de besoin, le service d'assistance informatique soit disponible. Les besoins
en matière d'infrastructure varient selon les projets et les programmes. Certains pays saisissent les
données sur papier au niveau de l'établissement et les numérisent au niveau du district, tandis que
d'autres utilisent les appareils personnels des agents de santé pour mettre en œuvre des solutions
numériques à grande échelle. En plus de l'infrastructure proprement dite, il existe des coûts associés
tels que la gestion et l'inventaire des appareils mobiles.

Il existe de nombreuses options différentes pour l'hébergement d'un système en ligne, que ce soit
l'endroit où placer le serveur (par exemple, en interne ou dans le nuage) ou la personne chargée de
gérer le serveur (par exemple, en interne ou en externe). Les serveurs et solutions d'hébergement
alternatifs doivent faire l'objet d'un examen critique en ce qui concerne la capacité, les problèmes
d'infrastructure, les cadres juridiques, la sécurité et les questions de confidentialité. Il peut être
nécessaire de revoir ces décisions au moins une fois par an, car la complexité du serveur, les types
de données (par exemple, agrégat ou patient) et la capacité locale peuvent évoluer au fil du temps. Il
est important de prévoir un budget pour le remplacement des appareils, car ceux-ci finissent par
tomber en panne ou être égarés.

Ressources

• Présentation des stratégies de déploiement

14
Directives sur la budgétisation et la planification Améliorer ou implémenter un nouveau programme/
stratégique pour des systèmes DHIS2 résiliants ensemble de données - données agrégées
• Outils et guide d'installation du serveur DHIS2 (ébauche)
• Champ d'action générique

Améliorer ou implémenter un nouveau programme/ensemble de données - données agrégées

Le stade de maturité d'une mise en œuvre globale du système DHIS2 peut être mesuré en examinant
des paramètres tels que l'exhaustivité, les délais de production et la cohérence des rapports, s'il existe
des directives ou des forums sur l'utilisation des données, mais aussi en examinant les descriptions
de poste du personnel traitant des données. Les outils de collecte de données, les indicateurs et les
produits d'utilisation des données doivent également être revus à intervalles réguliers, et ces outils
doivent généralement être conformes aux normes internationales en vigueur (par exemple l'OMS)
dans le domaine de la santé. L'amélioration de certains de ces éléments peut nécessiter une
formation de l'équipe principale ou des utilisateurs finaux ou bien une assistance technique pour
configurer le système DHIS2.

L'élargissement du champ d'application de la mise en œuvre du système DHIS2 à de nouveaux

domaines de santé, incluant la collecte de données agrégées, requiert une étude approfondie du
statut et de la maturité des domaines fondamentaux. L'ajout de nouveaux domaines, tels que
l'inclusion de programmes de santé supplémentaires, la surveillance des maladies ou les rapports de
service par localité (CHIS), exerce des pressions supplémentaires sur les domaines fondamentaux. Si
les domaines fondamentaux sont déjà faibles, la probabilité de l'échec de l'élargissement augmente.

En général, les domaines fondamentaux doivent tous avoir atteint un niveau minimum acceptable
avant que des domaines agrégés supplémentaires ne soient mis en œuvre. Ils doivent, par exemple,
obtenir un score d'au moins « Early progress » (Progrès rapides) lors de l'utilisation de l'outil Profil de
maturité. Lors de la planification et de la budgétisation de la mise en œuvre de nouveaux domaines
agrégés, il est essentiel que les plans prévoient également le renforcement des domaines
fondamentaux qui ont besoin d'être améliorés. Il est important de garder à l'esprit que l'ajout de
nouveaux rapports agrégés peut même avoir des effets négatifs sur les domaines fondamentaux qui
étaient auparavant performants et que cela doit être compensé dans le plan de mise en œuvre. Par
exemple, un serveur/système d'hébergement peut ne plus suffire si des centaines de nouveaux
utilisateurs sont introduits, et le modèle de formation des utilisateurs finaux qui est utile aux utilisateurs
au niveau de l'établissement peut ne plus convenir si des rapports au niveau de la communauté sont
introduits.

Il existe différentes approches pour incorporer un nouveau domaine de santé dans le système DHIS2.
Lorsque le système DHIS2 est introduit en tant qu'outil de collecte des données, cela peut se faire sur
la base d'un flux d'informations existant et en utilisant les outils de collecte de données primaires
existants (par exemple, les registres et les formulaires papier), ou dans le cadre d'une révision du
système global d'établissement des rapports. Des paquets de configuration de métadonnées globales
peuvent éventuellement être utilisés pour certaines parties de ce processus. Par ailleurs, un autre
système peut être utilisé pour la collecte des données et intégré au DHIS2 par le biais d'une solution
d'interopérabilité. Ces différents scénarios ont des répercussions sur la planification et la
budgétisation. En général, un projet visant à introduire de nouveaux domaines de santé dans le
système DHIS2 nécessitera des réunions d'orientation, un processus de collecte des exigences, la
configuration du système DHIS2, des tests et des formations. En outre, des coûts locaux sont
associés aux appareils du personnel, à leurs salaires, à leur formation, etc., comme décrit ci-dessus.

Ressources

• Kits des données sanitaires de l'OMS

• Packages de métadonnées
• Guide de mise en œuvre du CHIS
• Conception du système d'agrégats
• Champ d'action

15
Directives sur la budgétisation et la Améliorer ou implémenter un nouveau programme/ensemble de
planification stratégique pour des données - données individuelles /tracker{ #improving-or-
systèmes DHIS2 résiliants implementing-a-new-programmedata-set-individual-datatracker }
Améliorer ou implémenter un nouveau programme/ensemble de données - données individuelles /
tracker{ #improving-or-implementing-a-new-programmedata-set-individual-datatracker }

Le développement et la mise en œuvre de systèmes de suivi au niveau individuel peuvent être plus
compliqués que le traitement des données agrégées. La conception du système peut nécessiter plus
de travail et de tests, car elle touche à des processus opérationnels concrets et implique
généralement des ensembles de données et une logique commerciale plus importants. En outre, les
utilisateurs sont plus nombreux, ce qui signifie qu'il faut davantage de formation, d'appareils et de
soutien.

La création et l'amélioration des systèmes de suivi appliquent les mêmes catégories de coûts que les
systèmes agrégés. Cependant, pour développer et mettre en œuvre un programme de suivi, l'équipe
principale de DHIS2 doit travailler en étroite collaboration avec le personnel clinique afin de
comprendre et d'adapter leurs processus de travail. Cela prend beaucoup de temps de concevoir et
de construire un bon programme de suivi pour les personnes chargées de la mise en œuvre et pour le
personnel clé qui fournit les exigences. Qu'il s'agisse de construire un programme de suivi à partir de
zéro ou d'adapter un paquet de configuration de métadonnées, une collaboration étroite avec les
utilisateurs finaux est nécessaire. Le programme de suivi doit être testé sur le terrain dans un cadre
réaliste et ajusté en fonction des résultats des tests. Les directives à distance et l'assistance technique
sur place peuvent faciliter ce processus.

Un programme de suivi touche généralement un grand nombre d'utilisateurs, et la formation des

formateurs, celle des utilisateurs finaux, les appareils et la connectivité sont des postes budgétaires
importants. Il est donc généralement plus coûteux d'ajouter un nouveau programme de suivi qu'un
nouvel ensemble de données pour les rapports agrégés. Dans la plupart des cas, un programme de
suivi doit être chiffré par programme.

Vous trouverez d'autres ressources sur les considérations relatives au suivi dans le Guide de mise en
œuvre du Tracker.

En général, avant la mise en œuvre de programmes de suivi supplémentaires, les domaines

fondamentaux doivent tous avoir un niveau minimum acceptable, c'est-à-dire un score d'au moins
« Early progress » (Progrès rapides) et de préférence « Adequate » (Adéquat) lors de l'utilisation de
l'outil Profil de maturité. Aucun domaine fondamental dans l'outil Profil de maturité ne devrait avoir le
score « Not yet achieved » (Pas encore atteint) avant le lancement d'un programme de suivi, et la
sécurité et la conformité du système DHIS2 devraient toujours avoir au moins le score « Adequate »
(Adéquat). Comme pour les systèmes agrégés, lors de la planification et de la budgétisation de la
mise en œuvre de nouveaux domaines de données individuelles, il est essentiel d'inclure dans les
plans, le renforcement des domaines fondamentaux qui ont besoin d'être améliorés. Le plan de projet
doit clairement identifier les actions visant à améliorer les éléments fondamentaux du système DHIS2
tout en planifiant de nouveaux programmes de suivi. Il est également essentiel de ne pas perdre de
vue les rapports agrégés lorsqu'un pays se lance dans des programmes de suivi avancés. Souvent,
c'est la même équipe qui travaille sur les deux programmes.

Ressources

• Kits des données sanitaires de l'OMS

• Packages de métadonnées
• Guide de mise en œuvre du Tracker
• Champ d'action

16
Principes de Toutes les méta-données peuvent être ajoutées et modifiées via l'interface
conception utilisateur

Principes de conception
Ce chapitre présente quelques principes clés de la conception du logiciel DHIS2. Connaître et
comprendre ces principes permettra à l'utilisateur de mieux utiliser le logiciel lors de la
personnalisation d'une base de données locale. Alors que ce chapitre présente les principes, les
chapitres suivants expliquent en détail comment ils se traduisent dans le processus de conception de
lbase de données.

Les principes de conception suivants seront présentés dans ce chapitre :

• Toutes les méta-données peuvent être ajoutées et modifiées via l'interface utilisateur

• Un modèle de données flexible prend en charge différentes sources de données. dans un

référentiel de données unique

• Entrée de données != Sortie des données

• Analyse de données et rapports basés sur les indicateurs

• Maintenir les données des établissements agrégées dans la base de données

• Soutenir l'analyse des données à tous les niveaux du système de santé

Dans les sections qui suivent, chaque principe est décrit plus en détail.

Toutes les méta-données peuvent être ajoutées et modifiées via l'interface utilisateur

L'application DHIS2 contient un ensemble d'outils génériques utilisés pour la collecte, la validation, la
déclaration et l'analyse des données, mais le contenu de la base de données, c'est-à-dire les données
à collecter, leur provenance et leur format, dépendra du contexte d'utilisation. Ces métadonnées
doivent être ajoutées à l'application avant son utilisation. L'opération peut être effectuée via l'interface
utilisateur et ne nécessite aucune programmation. Ceci permet aux experts du domaine d'être plus
directement impliqués et de comprendre les détails du système d'information sanitaire que le logiciel
prendra en charge.

Le logiciel sépare les métadonnées clés qui décrivent les données brutes stockées dans la base de
données, c'est-à-dire les métadonnées stratégiques qui ne doivent pas beaucoup changer au fil du
temps (pour éviter la corruption des données), et les métadonnées de haut niveau telles que les
formules d'indicateurs, les règles de validation et les groupes utilisés pour l'agrégation, ainsi que les
différentes présentations des formulaires de collecte et des rapports, qui ne sont pas si stratégiques et
peuvent être modifiées au fil du temps sans que les données brutes n'en soient affectées. Étant donné
que ces métadonnées de haut niveau peuvent être ajoutées et modifiées au fil du temps sans affecter
les données brutes, un processus de personnalisation en continu est pris en charge. De nouvelles
fonctionnalités sont généralement ajoutées au fil du temps, au fur et à mesure que l'équipe locale
chargée de l'implémentation apprend d'autres fonctionnalités et que les utilisateurs réclament des
analyses de données et des rapports plus avancés.

Un modèle de données flexible permet à différentes sources de données d’être

intégrées dans un référentiel de données unique

La conception du DHIS2 repose sur une approche intégrée du SIS et prend en compte l'intégration de
différentes sources de données dans une base de données unique, souvent appelée référentiel de
données intégré ou entrepôt de données.

Etant donné que le logiciel DHIS2 est un outil doté uniquement d'une ossature, sans formulaires ni
rapports prédéfinis, il peut prendre en charge un grand nombre de sources de données agrégées
différentes. Rien ne limite réellement son utilisation dans le secteur de la santé, bien que son
utilisation dans d'autres secteurs soit encore très limitée. Tant que les données sont collectées par

17
Principes de conception Entrée de données != Sortie des données

une unité d'organisation, c'est-à-dire un élément de données (avec éventuellement certaines

catégories de désagrégation), et peuvent être représentées par une fréquence de période prédéfinie,
elles peuvent être collectées et traitées dans DHIS2. Cette flexibilité fait du DHIS2 un outil puissant
pour la mise en place de systèmes intégrés qui regroupent les outils de collecte, les indicateurs et les
rapports de plusieurs programmes, services ou initiatives de santé. Une fois que les données sont
définies, puis collectées ou importées dans une base de données DHIS2, il est possible de les
analyser ensemble avec les autres données de la même base, quelle que soit la manière dont elles
ont été collectées et le responsable de cette collecte. En plus de favoriser l'analyse intégrée des
données et l'établissement de rapports, cette approche intégrée permet également de rationaliser la
collecte des données et de réduire les doublons.

Entrée de données != Sortie des données

Le logiciel DHIS2 présente en trois dimensions, les données agrégées collectées et stockées dans la
base de données : le "où" - unité d'organisation, le "quoi" - élément de données, et le "quand" - la
période. L'unité d'organisation, l'élément de données et la période sont les trois dimensions de base
qui permettent de décrire toute valeur de données dans DHIS2, que ce soit dans un formulaire de
collecte de données, un graphique, une carte ou un rapport de synthèse agrégé. Lorsque les données
sont collectées dans un formulaire électronique, parfois par le biais d'une image miroir des formulaires
papier utilisés sur les lieux de collecte, chaque champ du formulaire peut être décrit en fonction de ces
trois dimensions. Le formulaire lui-même n'est qu'un outil qui organise le processus de collecte des
données. Il ne décrit pas les valeurs individuelles des données collectées et stockées dans la base de
données. Le fait de pouvoir décrire une à une chaque valeur de données en définissant un élément de
données (par exemple, doses de vaccin contre la rougeole administrées \<1 an) rend flexible le
traitement, la validation et l'analyse des données, et permet de comparer les données entre les
formulaires de collecte et les programmes de santé.

Par cette approche de la conception ou du modèle de données, DHIS2 se distingue des nombreuses
applications logicielles SIS traditionnelles qui utilisent les formulaires de collecte de données comme
principaux outils d'analyse. La figure ci-dessous montre l'importance particulière d'une conception plus
fine du DHIS2, qui s'articule autour du concept d'éléments de données. Elle montre également la
séparation entre l'entrée (la collecte des données) et la sortie (l'analyse des données), qui permet une
analyse et une diffusion des données plus flexibles et variées. L'élément de données ‘doses de vaccin
contre la rougeole administrées \<1 an’ est collecté dans un formulaire de collecte de données sur la
vaccination des enfants. Il peut toutefois être utilisé à titre individuel en tant qu'indicateur (une formule)
appelé ‘Couverture du vaccin contre la rougeole \<1 an’ où il est combiné avec l'élément de données
‘Population \<1 an’, collecté via un autre formulaire de collecte. Cette valeur calculée de l'indicateur
peut ensuite être utilisée pour l'analyse des données à travers l'établissement de rapports, tels que
des rapports personnalisés avec des graphiques, des tableaux croisés dynamiques ou sur une carte
dans le module SIG.

18
Principes de conception Analyse de données et rapports basés sur les indicateurs

Analyse de données et rapports basés sur les indicateurs

L'élément de données susmentionné, c'est-à-dire la dimension clé qui décrit ce qui est collecté, est
parfois qualifié d'indicateur dans d'autres contextes. Dans le DHIS2, il faut distinguer les éléments de
données, qui décrivent les données brutes, par exemple les chiffres collectés, des indicateurs, qui
sont basés sur des formules et décrivent des valeurs calculées, par exemple les taux de couverture
ou d'incidence utilisés pour l'analyse des données. Les valeurs des indicateurs ne sont pas collectées
de la même manière que les valeurs des (éléments) de données, mais sont calculées par l'application
sur la base de formules définies par les utilisateurs. Ces formules sont composées d'un facteur (par
exemple 1, 100, 100, 100 000), d'un numérateur et d'un dénominateur, les deux derniers étant des
expressions basées sur un ou plusieurs éléments de données. Par exemple, l'indicateur "Couverture
vaccinale contre la rougeole \<1 an" est défini par une formule avec un facteur 100, un numérateur
("doses de vaccin contre la rougeole administrées aux enfants de moins d'un an") et un dénominateur
("population cible âgée de moins d'un an"). L'indicateur "Taux d'abandon du Penta 1 au Penta 3" est
une formule de 100 % x ("doses de Penta 1 administrées" - "doses de Penta 3 administrées") /
("doses de Penta 1 administrées"). Ces formules peuvent être ajoutées et modifiées via l'interface
utilisateur par un utilisateur même peu formé, car elles sont faciles à configurer et n'interfèrent pas
avec les valeurs de données stockées dans la base de données (l'ajout ou la modification d'un
indicateur n'est donc pas une opération critique).

Les indicateurs représentent peut-être la fonction d'analyse de données la plus puissante du DHIS2,
et tous les outils de rapport prennent en charge l'utilisation des indicateurs, comme le montre le
rapport personnalisé dans la figure ci-dessus. La possibilité d'utiliser des données démographiques
comme dénominateur permet de comparer les performances en matière de santé dans des zones
géographiques avec des populations cibles différentes, ce qui est plus utile que de se contenter des
chiffres bruts. Le tableau ci-dessous utilise à la fois les valeurs des données brutes (Doses) et les
valeurs des indicateurs (Cov) pour les différents vaccins. Si l'on compare par exemple les deux
premières unités d'organisation de la liste, le comté de Taita Taveta et le comté de Kilifi, pour la

19
Principes de conception Maintenir les données des établissements agrégées dans la base de données

vaccination au Penta-1, on constate que si les chiffres bruts (659 contre 2088) indiquent que
beaucoup plus de doses sont administrées à Kilifi, les taux de couverture (92,2 % contre 47,5 %)
montrent que Taita Taveta vaccine mieux sa population cible âgée de moins d'un an. Si l'on examine
la dernière colonne (Immuniz. Compl. % ou % de complétude de la vaccination) qui indique la
complétude du rapport du formulaire de vaccination pour la même période, on constate que les
chiffres sont plus ou moins les mêmes dans les deux comtés comparés, ce qui nous indique que les
taux de couverture entre ces deux comtés peuvent être comparés de façon raisonnable.

Maintenir les données des établissements agrégées dans la base de données

Lorsque les données sont collectées et stockées dans le DHIS2, elles restent désagrégées dans la
base de données avec le même niveau de détail que lors de leur collecte. Un système de base de
données pour le SIS offre un avantage majeur par rapport à un système basé sur du papier ou une
feuille de calcul. Le système est conçu pour stocker de grandes quantités de données et permet
toujours d'accéder au niveau le plus détaillé possible, qui n'est limité que par la manière dont les
données ont été collectées ou importées dans la base de données DHIS2. Dans la perspective d'un
SIS national, il est recommandé de garder les données désagrégées au niveau de l'établissement de
santé, qui est souvent le niveau le plus bas dans la hiérarchie de l'unité d'organisation. Cela peut se
faire par le biais d'un système hybride (papier et ordinateur). Les données peuvent être transmises par
les établissements de santé aux bureaux de district sur papier (par exemple sur des formulaires de
synthèse mensuels pour un établissement spécifique), puis le bureau de district saisit toutes les
données de l'établissement dans DHIS2 au moyen des formulaires électroniques de collecte de
données, établissement par établissement. Cela permettra aux équipes de gestion sanitaire des
districts d'analyser les données par établissement et de fournir, par exemple, des copies imprimées
des rapports de retour d'information générés par DHIS2, y compris des comparaisons entre
établissements, aux responsables des établissements dans leur district.

Soutenir l'analyse des données à tous les niveaux du système de santé

Bien que le nom DHIS2 indique une focalisation sur le district, l'application fournit les mêmes outils et
fonctionnalités à tous les niveaux du système de santé. Dans tous les outils de rapports, les
utilisateurs peuvent sélectionner l'unité d'organisation ou le niveau d'unité d'organisation à analyser et
les données affichées seront automatiquement agrégées jusqu'au niveau sélectionné. DHIS2 utilise la
hiérarchie des unités d'organisation pour agréger les données vers les niveaux supérieurs et fournit
des données pour toutes les unités d'organisation de cette hiérarchie. La plupart des rapports sont
effectués de manière à inviter les utilisateurs à sélectionner une unité d'organisation, ce qui permet de
réutiliser les mêmes présentations de rapport, quel que soit le niveau. Vous pouvez également, si
vous le souhaitez, adapter les présentations des rapports à un niveau spécifique du système de santé
si les besoins entre niveaux diffèrent.

Dans le module SIG, les utilisateurs peuvent analyser les données au niveau infranational, par
exemple, puis, en cliquant sur la carte (sur une région ou une province, par exemple), descendre au

20
Principes de conception Soutenir l'analyse des données à tous les niveaux du système de santé

niveau suivant et continuer ainsi jusqu'à la source des données au niveau de l'établissement. Les
tableaux croisés dynamiques d'Excel associés à la base de données DHIS2 offrent une fonctionnalité
d'exploration similaire.

Pour accélérer les performances et réduire le temps de réponse lors de la fourniture de données
agrégées, qui peuvent inclure plusieurs calculs (par exemple, l'addition des données de 8 000
établissements), DHIS2 calcule au préalable toutes les valeurs agrégées possibles et les stocke dans
ce que l'on appelle un datamart (entrepôt de données). Ce datamart peut être programmé pour être
exécuté (reconstitué) à un intervalle de temps donné, par exemple tous les soirs.

21
Installation d'une nouvelle base de données Stratégies de mise en route

Installation d'une nouvelle base de données

L'application DHIS2 dispose d'un ensemble d'outils utilisé pour la collecte, la validation, les rapports et
l'analyse des données. Cependant, le contenu de la base de données, par exemple les données à
collecter, leur provenance et leur format, dépendra du contexte d'utilisation. Pour pouvoir être
utilisées, ces métadonnées doivent d'abord être introduites dans l'application. Cela ne nécessite
aucune programmation et peut être fait via l'interface utilisateur. Pour cela, il faut avoir une
connaissance approfondie du contexte du système d'information sanitaire local, ainsi qu'une
compréhension des principes de conception du système DHIS2 (voir chapitre « Principes de
conception clé du système DHIS2 »). Nous appelons ce processus initial la conception ou la
personnalisation de la base de données. Ce chapitre fournit un aperçu du processus de
personnalisation et explique brièvement la marche à suivre, afin de donner à l'implémenteur une idée
de ce que ce processus exige. Les autres chapitres de ce manuel vont aborder plus en profondeur
certaines étapes spécifiques.

Stratégies de mise en route

La section suivante présente une liste de conseils pour bien commencer le développement d'une
nouvelle base de données.

1. Alimenter rapidement une base de données de démonstration avec des exemples de rapports,
de graphiques, tableau de bord, SIG, formulaires de saisie de données. Utiliser des données
réelles, idéalement des données à l’échelle nationale, mais pas nécessairement au niveau des
établissements.

2. Mettre la base de données de démonstration en ligne. L'hébergement du serveur peut être

assuré par un opérateur externe, ce qui peut accélérer le processus, mais si c'est temporaire.
Cela constitue une excellente plateforme collaborative et un outil de diffusion efficaces pour
obtenir l’adhésion des parties prenantes.

3. L'étape suivante est un processus de conception de base de données plus élaboré. Certaines
parties de la démo peuvent être réutilisées si nécessaire.

4. Disposer d'une équipe locale avec une variété de compétences et de parcours : santé publique,
administration de données, informatique et gestion de projet.

5. Aborder la phase de personnalisation et de conception de la base de données comme un

processus d'apprentissage et de formation qui vise le renforcement des capacités locales grâce
à l’apprentissage par la pratique.

6. L'équipe du pays doit diriger le processus de conception de la base de données mais avec
l'assistance d'implémenteurs expérimentés.

Processus ouvert ou contrôlé?

Étant donné que le processus de personnalisation de DHIS2 est souvent et doit être un processus
collaboratif, il est également important de savoir quelles parties de la base de données sont plus
critiques que d'autres, par exemple pour éviter qu'un utilisateur non formé ne corrompe les données.
En règle générale, il est beaucoup plus important de personnaliser une base de données qui contient
déjà des valeurs de données que de travailler avec des métadonnées sur une base de données
"vide". Bien que cela puisse paraître étrange, une bonne partie de la personnalisation a lieu après le
début de la collecte ou de l'importation des données, par exemple lors de l'ajout de nouvelles règles
de validation, d'indicateurs ou de modèles de rapports. L'erreur la plus grave serait de modifier les
métadonnées qui décrivent directement les valeurs des données, à savoir, les éléments de données
et les unités d'organisation, comme nous l'avons vu plus haut. En modifiant ces définitions, il est
important de réfléchir à la manière dont cette modification affectera les valeurs de données déjà
présentes dans le système (collectées à l'aide des anciennes définitions). Il est recommandé de limiter

22
Installation d'une nouvelle base de données Étapes à suivre pour l'élaboration d'une base de données

l'accès à la modification de ces métadonnées fondamentales par le biais des rôles des utilisateurs,
afin que l'accès soit réservé à une équipe de personnalisation restreinte.

La manipulation des autres parties du système qui ne sont pas directement liées aux valeurs de
données est moins problématique. De plus, ici, du moins dans les premières phases, on devrait
encourager les utilisateurs à essayer de nouvelles technafin de développer l'apprentissage du
système. Cela vaut pour les groupes, les règles de validation, les formules d'indicateurs, les
graphiques et les rapports. Tous ces éléments peuvent facilement être supprimés ou modifiés
ultérieurement sans affecter les valeurs de données concernées, et ne sont donc pas des éléments
essentiels dans le processus de personnalisation de la base de données.

Bien sûr, plus tard dans le processus de personnalisation, notamment lors de la phase de production,
il faudra être plus vigilant quant à l'attribution des droits d'accès pour la modification des
métadonnées, étant donné que tout changement, même sur les métadonnées les moins critiques,
pourrait affecter la façon dont les données sont agrégées ou présentées dans un rapport (bien que les
données brutes concernées soient toujours sécurisées et correctes).

Étapes à suivre pour l'élaboration d'une base de données

La section suivante décrit concrètement les étapes à suivre pour concevoir une base de données de A
à Z.

La hiérarchie organisationnelle

La hiérarchie organisationnelle définit l'organisation qui utilise le DHIS2, les établissements de santé,
les zones administratives et les autres zones géographiques qui entre en jeu dans la collecte et
l'analyse des données. Cette dimension des données est définie comme une hiérarchie avec une
unité racine (par exemple, le ministère de la santé) et plusieurs niveaux et nœuds inférieurs. Chaque
nœud de cette hiérarchie est appelé unité d'organisation dans le DHIS2. La conception de cette
hiérarchie déterminera les unités géographiques d'analyse disponibles pour les utilisateurs, car les
données sont collectées et agrégées selon cette structure. Il ne peut y avoir qu'une seule hiérarchie
organisationnelle à la fois, c'est pourquoi sa structure nécessite une attention particulière.

Des hiérarchies supplémentaires (par exemple, des frontières administratives parallèles au secteur
des soins de santé) peuvent être modélisées à l'aide de groupes d'organisations et d'ensembles de
groupes, mais la hiérarchie organisationnelle est le principal moyen d'agrégation des données sur la
dimension géographique. En règle générale, les hiérarchies organisationnelles nationales dans le
domaine de la santé publique comportent 4 à 6 niveaux, mais le nombre de niveaux reste flexible. La
hiérarchie est constituée de relations mère-fille, c'est-à-dire qu'un pays ou une unité du ministère de la
santé (la racine) peut avoir, par exemple, 8 unités filles (provinces), et chaque province (au niveau 2)
peut avoir 10 à 15 districts comme unités filles. Normalement, les établissements de santé sont situés
au niveau le plus bas, mais ils peuvent également être situés à des niveaux plus élevés, par exemple
des hôpitaux nationaux ou provinciaux, de sorte que des structures organisationnelles asymétriques
sont possibles (par exemple, un nœud feuille peut être positionné au niveau 2 alors que la plupart des
autres nœuds feuilles se trouvent au niveau 5).

Éléments de donnée

L'élément de données est peut-être la composante la plus importante d'une base de données DHIS2.
Il représente la dimension quoi et indique ce qui est collecté ou analysé. Dans certains contextes, on
parle d'indicateur, mais dans DHIS2, nous appelons cette unité de collecte et d'analyse un élément de
données. L'élément de données représente souvent un comptage, et son nom décrit ce qui est
compté, par exemple "Doses de BCG administrées" ou "Cas de paludisme". Lorsque des données
sont collectées, validées, analysées, rapportées ou présentées, ce sont les éléments de données ou
les expressions construites à partir des éléments de données qui décrivent le QUOI des données.
Ainsi, les éléments de données deviennent importants pour tous les aspects du système et
déterminent non seulement la manière dont les données sont collectées, mais surtout la manière dont

23
Installation d'une nouvelle base de données Ensemble de données et formulaires de saisie de données

les valeurs des données sont représentées dans la base de données, ce qui détermine également la
manière dont les données peuvent être analysées et présentées.

Lors de la conception des éléments de données, il convient de considérer les éléments de données
comme des unités d'analyse des données et pas seulement comme des champs du formulaire de
collecte des données. Chaque élément de données est autonome dans la base de données,
complètement détaché du formulaire de collecte. Les rapports et autres résultats sont basés sur les
éléments de données et les expressions/formules composées d'éléments de données et non sur les
formulaires de collecte de données. Par conséquent, ce sont les besoins en matière d'analyse des
données qui doivent conditionner le processus, et non l'apparence des formulaires de collecte de
données.

Ensemble de données et formulaires de saisie de données

Toute la saisie de données dans DHIS2 est organisée à l'aide d'ensembles de données. Un ensemble
de données est une collection d'éléments de données regroupés pour la collecte de données. Dans le
cas d'installations distribuées, ils définissent également des blocs de données destinés à l'exportation
et à l'importation entre des instances de DHIS2 (ex. d'une installation locale d'un bureau
d'arrondissement vers un serveur national). Les ensembles de données ne sont pas directement liés
aux valeurs de données, mais uniquement par le biais de leurs éléments de données et de leurs
fréquences. De ce fait, un ensemble de données peut être modifié, supprimé ou ajouté à tout moment
sans affecter les données brutes déjà stockées dans le système, même si ces modifications vont sans
doute affecter la façon dont les nouvelles données seront collectées.

Une fois que vous avez assigné un ensemble de données à une unité organisationnelle, cet ensemble
de données sera disponible dans Data Entry (Saisie des données) (sous Services) pour les unités
organisationnelles où vous l'avez assigné et pour les périodes valides selon le type de période de
l'ensemble de données. Un formulaire de saisie de données par défaut s'affichera alors. Il s'agit
simplement d'une liste des éléments de données appartenant à l'ensemble de données qui inclut une
colonne pour la saisie des valeurs. Si votre ensemble de données contient des éléments de données
avec des catégories telles que les tranches d'âge ou le sexe, de nouvelles colonnes seront
automatiquement générées dans le formulaire par défaut en fonction des catégories. En plus du
formulaire de saisie de données par défaut basé sur une liste, on a également le formulaire basé sur
des sections et le formulaire personnalisé. Les formulaires à section offrent un peu plus de flexibilité
lorsqu'il s'agit de présenter les données sous forme de tableau. Ils sont rapides et simples à
concevoir. Souvent, votre formulaire de saisie de données aura besoin de plusieurs tableaux avec des
sous-titres, et parfois, vous devez désactiver (griser) quelques champs du tableau (par exemple,
lorsque certaines catégories ne s'appliquent pas à tous les éléments de données), ces deux fonctions
sont prises en charge dans les formulaires à section. Si le formulaire que vous souhaitez concevoir
est trop compliqué pour les formulaires par défaut ou les formulaires à section, vous pouvez utiliser un
formulaire personnalisé. Cela prend plus de temps, mais vous disposez d'une totale liberté de
conception. Le système DHIS2 intègre un éditeur HTML (FcK Editor) destiné au concepteur de
formulaire. Vous pouvez soit concevoir le formulaire dans l'interface utilisateur, soit coller votre html
directement (en utilisant la fenêtre Source dans l'éditeur).

Règles de validation

Elements de Données

Indicateurs

Les indicateurs représentent peut-être la plus puissante fonctionnalité d'analyse de données de

DHIS2. Alors que les éléments de données représentent les données brutes (comptes) collectées, les
indicateurs représentent des formules fournissant des taux de couverture, des taux d'incidence, des
ratios et d'autres unités d'analyse basées sur une formule. Un indicateur est composé d'un facteur
(Exemple : 1,100, 100, 100 000), d'un numérateur et d'un dénominateur. Les deux derniers sont tous

24
Installation d'une nouvelle base de données Tableaux et rapports

deux des expressions basées sur un ou plusieurs éléments de données. Exemple : l'indicateur
"Couverture du BCG \<1 an" est défini par une formule avec un facteur 100, un numérateur ("Les
doses BCG administrées aux enfants de moins de 1") et un dénominateur ("Population cible de moins
de 1 an"). L'indicateur "Taux d'abandon de DPT1 à DPT3" est une formule de 100% x ("Doses de
DPT1 administrées" - "Doses de DPT3 administrées") / ("Doses de DPT1 administrées").

La plupart des modules de rapport dans DHIS2 prennent en charge les éléments de données et les
indicateurs et vous pouvez également les combiner dans des rapports personnalisés, mais la
différence et la puissance des indicateurs par rapport aux données brutes (valeurs de données de
l'élément de donnée) réside dans la possibilité de comparer des données entre différentes zones
géographiques (par exemple les zones très peuplées ou rurales), la population cible pouvant être
utilisée comme dénominateur.

Toutes les saisies de données dans DHIS 2 se font à travers les ensembles de données. Un
ensemble de données est une collection d'éléments de données regroupées pour la collecte de
données, et dans le cas d'installations distribuées, ils définissent également des morceaux de
données pour l'exportation et l'importation entre instances de DHIS 2 (par exemple exportation d'une
installation locale au bureau de district vers l'installation sur le serveur national). Les ensembles de
données ne sont pas liés directement aux valeurs de données, mais à travers les éléments de
données qui les constituent et les fréquences de collecte; en tant que tel un ensemble de données
peut être modifié, supprimé ou ajouté à moment sans affecter les données brutes déjà saisies dans le
système. De telles modifications auront toutefois une incidence sur la façon dont les nouvelles
données seront collectées.

Tableaux et rapports

Les rapports standards dans DHIS2 constituent un moyen très flexible de présenter les données
collectées. Les données peuvent être agrégées par n'importe quel niveau ou unité d'organisation, par
élément de donnée, par indicateur, ainsi que dans le temps (mensuellement, trimestriellement,
annuellement). Les tableaux de rapports représentent des sources de données personnalisées pour
les rapports standards. Ils peuvent être définis de manière flexible dans l'interface utilisateur, puis
accessibles via des concepteurs de rapports externes tels que iReport ou via des rapports HTML
personnalisés. Ces conceptions de rapport peuvent ensuite être configurées comme des rapports
facilement accessibles en un clic avec des paramètres afin que les utilisateurs puissent exécuter les
mêmes rapports comme par exemple, tous les mois, lorsque de nouvelles données sont saisies. Elles
peuvent également répondre aux besoins des utilisateurs à tous les niveaux, puisque l'unité
d'organisation peut être sélectionnée au moment de l'exécution du rapport.

SIG (Cartes

Dans le module SIG intégré, vous pouvez facilement afficher vos données sur des cartes, à la fois sur
des polygones (zones) et sous forme de points (structures sanitaires), et soit en tant qu'éléments de
données ou en tant qu'indicateurs. En fournissant les coordonnées de vos unités d'organisation au
système, vous pouvez rapidement vous adapter à ce module. Consultez la section SIG pour plus de
détails sur la façon de vous y prendre.

Diagrammes et tableau de bord

L'un des moyens les plus faciles d'afficher les données de votre indicateur est d'utiliser des
graphiques. Un dialogue de diagramme facile à utiliser vous guidera dans la création de divers types
de graphiques avec des données sur les indicateurs, les unités d'organisation et les périodes de votre
choix. Ces graphiques peuvent facilement être ajoutés à l'une des quatre sections de votre tableau de
bord et sont facilement disponibles immédiatement après votre connexion. Assurez-vous de définir le
module du tableau de bord comme module de démarrage dans les paramètres utilisateur.

25
Considérations en matière de sécurité{ #security-considerations } Contexte d'utilisation

Considérations en matière de sécurité{ #security-considerations }

L'objectif de ces directives est d'aider les responsables de la mise en œuvre du système DHIS2 et les
propriétaires du système à prendre des mesures raisonnables et appropriées pour identifier et gérer
les risques associés à l'exploitation du système DHIS2. Nous espérons qu'elles seront
particulièrement utiles aux propriétaires du système qui sans cela pourraient avoir du mal à définir et à
imposer des contraintes techniques aux responsables de la mise en œuvre.

Le système DHIS2 est mis en œuvre par de nombreux types d'organisations différentes, à des
échelles différentes et à des fins différentes. Le principal propriétaire du système auquel nous
pensons ici est un service ou un ministère de la Santé. Cependant, un grand nombre de principes
directeurs devraient également être applicables aux ONG et aux organisations du secteur privé.

En tant que système basé sur le web, le système DHIS2 est exploité à 100 % lorsqu'il est accessible
en ligne pour les agents de santé, quel que soit l'appareil utilisé ou le fournisseur de services Internet
disponible (par exemple, les systèmes de téléphonie mobile 4G). Nous avons vu comment, en utilisant
un tel modèle ouvert, il est possible de déployer des systèmes nationaux dans les pays, ainsi que des
programmes en quelques mois au lieu de plusieurs années.

Malheureusement, au cours de la même période, nous avons également constaté que les systèmes
basés sur Internet sont confrontés à des menaces croissantes de la part de gouvernements et de
criminels. Les attaques sont devenues plus fréquentes et plus sophistiquées. La nécessité de faire
preuve de plus de rigueur et d'intelligence est beaucoup plus évidente de nos jours, contrairement à
10 ans auparavant, lors du déploiement des premières versions Web de DHIS2.

Une pratique de sécurité globale concerne la CONFIDENTIALITÉ, l'INTÉGRITÉ et la DISPONIBILITÉ

des données.

Le système DHIS2 a remarquablement réussi à être adapté et maintenu dans de nombreux pays en
tant que système national d'information sanitaire, et en général, en tant que système agrégé
d'établissement régulier de rapports.Même si la confidentialité des données de routine ne constitue
sans doute pas une préoccupation très importante, l'intégrité et la disponibilité des données
deviennent plus importantes à mesure que le système s'institutionnalise. L'impact en cas de perte de
données, en particulier, devient plus sérieux.

La nature des données collectées dans le système DHIS2 est également devenue plus sensible. Une
base de données DHIS2 contient de plus en plus une quantité importante d'informations personnelles
identifiables (PII) ou de données personnelles. Il peut s'agir de données démographiques sur les
patients, mais aussi de données personnelles sur le personnel de santé (e-mail, téléphone, adresse,
messages) saisies en tant qu'informations utilisateur. Des mesures appropriées doivent être mises en
place pour assurer la confidentialité de ces données et la vie privée des personnes concernées.

Contexte d'utilisation

Contexte juridique et réglementaire{ #legal-and-regulatory-context }

Il n'existe aucun ensemble universel de lois, de pratiques et de principes qui s'appliquent dans tous
les pays. Par exemple, dans l'Union européenne, la principale législation récente en matière de
confidentialité est le RGPD (General Data Protection Regulation, in force from May 2018). This
legislation introduces a set of guiding principles and accompanying terminology which differs in scope,
justificatory narrative and intent from the U.S. HIPAA (Health Insurance Portability and Accountability
Act), qui est la principale législation régissant les données médicales dans ce pays.

Ces deux textes législatifs sont relativement nouveaux et complexes. Les pays exploitant le système
DHIS2 ne sont généralement pas soumis aux règlementations HIPAA ou RGPD, mais beaucoup ont
élaboré ou sont en train d'élaborer une législation nationale dans ce domaine, par exemple la Loi sur
la protection des données à caractère personnel de 2013 en Afrique du Sud, et le projet de loi sur la

26
Considérations en matière de sécurité{ #security-considerations } Contexte humain et organisationnel

protection des données à caractère personnel de 2019 en Inde. Les responsables de la mise en
œuvre et les propriétaires du système doivent s'efforcer de se familiariser pleinement avec la
législation en vigueur dans leur juridiction d'utilisation. Le CNUCED gère une page mise à jour
régulièrement permettant de visualiser les lois sur la protection de la vie privée appliquées par chaque
pays du monde.

Pour les systèmes du secteur public (qui représentent peut-être la majorité des cas d'utilisation du
système DHIS2), des politiques supplémentaires et des procédures opérationnelles standard liées à la
sécurité des systèmes et des données peuvent également avoir force de loi.

Dans la plupart des cas, plaider la méconnaissance de la loi n'est pas une défense.

Il est difficile d'opérer en dehors du contexte de toute législation et politique pertinente, mais dans les
contextes où l'environnement réglementaire existant est obsolète ou inadéquat, des contrôles
appropriés doivent être établis par consensus dans le cadre même du système DHIS2.

Contexte humain et organisationnel

Les économies capitalistes « développées » se caractérisent par une division du travail très
développée. Cela se voit clairement dans le secteur informatique en Europe et aux États-Unis, où il
existe des distinctions très nettes entre les administrateurs système, les programmeurs, les ingénieurs
réseau, les utilisateurs finaux de l'information, ainsi que les structures, les rôles et les pratiques de
gestion informatique très développés, en particulier dans les grandes organisations.

Il est insensé de s'attendre à retrouver le même type de structures et de rôles dans tous les pays, en
particulier lorsque le système DHIS2 pourrait être le premier, ou du moins le plus important, système
national d'un ministère de la Santé. La mise en œuvre d'un système complexe basé sur le Web,
comme DHIS2, mais sans une base relativement moderne de gestion et une main-d'œuvre qualifiée,
comporte des risques et des défis uniques. Le développement de formes organisationnelles
appropriées pour gérer le risque et permettre au système de s'épanouir et de se maintenir est au
moins aussi important que toute considération technique.

Ce problème est aggravé lorsqu'on a plusieurs ministères, organisations partenaires et donateurs,

tous différents, ne peuvent pas tous partager les mêmes perspectives et priorités en matière de
sécurité et de confidentialité.

Mesures

Mesures organisationnelles

Face aux défis organisationnels auxquels les propriétaires du système peuvent être confrontés, il
devient plus important pour ces derniers de développer un plan approprié pour gérer la sécurité du
système. Vous trouverez ci-dessous un petit recueil de conseils pratiques.

Disposer d'un plan de gestion de la sécurité est la première étape pour revendiquer une quelconque
forme de propriété sur le système. Lorsque le ministère de la Santé est un utilisateur passif d'un
système développé et géré par des organisations partenaires, il n'en revendique pas la propriété.

La sécurité est une question de gestion. Vous ne pouvez pas la déléguer cette question à un
technicien expérimenté et situé au plus bas de l'échelon de l'organisation (ce qui est courant) ni la
confier à un partenaire technique (ce qui est également courant). Vous vous appuierez très
certainement sur ces ressources, mais il est important que les motivations viennent de la direction.

Dans un monde idéal, vous pouvez employer un chef de la sécurité (CSO) ayant une expérience
professionnelle dans l'un des nombreux cadres de sécurité et de gouvernance (TOGAF, ITIL,
ISO27000x, etc.). Il est beaucoup plus probable que ce ne soit pas le cas et qu'il faut que les
personnes concernées établissent un plan plus agile avec les ressources dont ils disposent.
L'improvisation peut être la clé. Il vaut mieux avoir un mauvais plan de gestion de la sécurité, ou du

27
Considérations en matière de sécurité{ #security-considerations } Mesures de configuration du système

moins un plan mal élaboré, que ne pas en avoir du tout. Un mauvais plan peut être amélioré et
développé.

Nous recommandons aux organisations d'adopter une partie de la méthodologie de la norme

ISO27002 (gestion de la sécurité de l'information), sans nécessairement s'engager sur la voie de la
conformité à la norme ISO27000. Au minimum, cela impliquerait ce qui suit :

1. Vous disposez d'une déclaration de haut niveau résumant le niveau de

sécurité de votre organisation. Dans un document d'une page, il doit être
indiqué les principes et les intentions, ainsi que l'engagement de la haute
direction envers le processus.
2. Vous avez clairement identifié un membre (raisonnablement plus
expérimenté) de votre équipe qui sera chargé de développer, de maintenir
et de mettre en œuvre le plan de sécurité. Cette personne sera appelée le
chef de la sécurité.
3. Le gestionnaire de sécurité s'engage dans un processus visant à
identifier, documenter et atténuer les risques. Il s'agit d'un processus
continu qui porte généralement sur la tenue d'un registre des risques,
lequel fait l'objet d'un examen régulier.
4. Un processus est en place (y compris le temps et le budget) pour
assurer un audit interne et/ou externe régulier du déploiement, de la
configuration et des métadonnées du système DHIS2, y compris le plan de
sécurité de l'organisation.
5. Les parties ont conclu un accord de partage de données qui définit les
données à traiter, à quelles fins et comment, fixe des limites claires pour
éviter toute violation des données des patients et assure l'intégrité ainsi que
la confidentialité des données.
6. La propriété des données et des technologies est établie pour le système
DHIS2.

De nombreux autres artefacts et processus envisagés dans un cadre, tel que l'ISO 27000, pourraient
émerger naturellement de ce cycle. Par exemple, s'il n'existe pas de plan de reprise après sinistre ou
de stratégie de sauvegarde, cela sera mis en évidence comme un risque majeur dans le registre. La
constitution et la tenue d'un tel registre permettent à l'équipe d'identifier et de hiérarchiser les tâches à
accomplir et d'évaluer les progrès accomplis pour être plus efficace.

Les documents suivants devraient être au moins créés pour commencer à établir un programme de
sécurité : - Inventaire des actifs - Évaluation des risques/document du registre des risques - Politique
de sauvegarde - Politique de reprise après sinistre - Plan d'intervention en cas d'incident - Plan de
gestion des identités et des accès

To help implementers to kick-start their security programs, we have developed a set of templates
anyone can use and adapt to their own needs, called Security Starter Kit.

Mesures de configuration du système

Il existe également un certain nombre de mesures qui peuvent être prises pour améliorer la sécurité
au niveau de la configuration du système DHIS2, par exemple pour garantir un accès approprié au
système et aux données. Un projet de liste présentant les 10 meilleures mesures de configuration du
système est disponible ici :

Administration du système

28
Considérations en matière de sécurité{ #security-considerations } Mesures de configuration du système

1. Il y a un nombre limité (moins de 5) personnes ayant un accès

superutilisateur (complet) au système. Peut être facilement évaluée à
travers l'API: /api/[Link]?
filter=[Link]:!in:
[_ALL_]&filter=[Link]:in:
\[ALL]
2. Les administrateurs de système ne sont autorisés à exécuter que les
fonctions qui relèvent de leur rôle d'administrateur de système. Par
exemple, un administrateur responsable de la gestion des graphiques et
des tableaux de bord n'a pas besoin de droits pour modifier les unités
d'organisation.
3. Le compte utilisateur DHIS2 par défaut (nom d'utilisateur "admin") est
supprimé ou désactivé. Le compte admin ne doit être utilisé que lors du
premier démarrage de DHIS2, pour configurer un superutilisateur
personnel. Il doit ensuite être désactivé et/ou supprimé. Le statut du
compte administrateur peut être vérifié à l'aide de l'API: /api/
[Link]?
filter=[Link]:eq:admin&fields=name,userCredentials\
[name,disabled\]

Gestion des utilisateurs

4. Des procédures sont en place pour désactiver ou supprimer les comptes
utilisateurs des personnes qui quittent le département. Des procédures
claires doivent être mises en place pour désactiver/supprimer les comptes
d'utilisateur des personnes qui quittent le département (de la santé). Des
indications à ce sujet peuvent être tirées de l'API, en examinant les
comptes d'utilisateurs qui ne sont pas désactivés et qui ne se sont pas
connectés au système, par exemple au cours de l'année en cours.: /api/
[Link]?
filter=[Link]:eq:false&filter=[Link]:l
2021
5. Tous les comptes d'utilisateur du système sont personnels, c'est-à-dire
qu'ils ne sont pas partagés par plusieurs personnes. Les comptes
d'utilisateurs ne doivent pas être partagés par plusieurs personnes, car cela
rend l'audit impossible. Ceci est particulièrement important si Tracker est
utilisé pour des données au niveau individuel.
6. Les rôles et les groupes d'utilisateurs sont clairement définis, avec des
conseils sur les rôles et les groupes à utiliser en fonction de la position de
l'utilisateur au sein du département (de santé).
7. Si l'auto-enregistrement des utilisateurs est activé, le rôle attribué à ces
derniers doit être très limité, par exemple à uniquement consulter les
tableaux de bord publics.
8. La désactivation des comptes peut être un bon moyen de limiter l'accès
à certains utilisateurs qui ont été oubliés dans le système. Le DHIS2 fournit
une tâche planifiée pour automatiser cette opération. Cependant, il faut
savoir que cela peut avoir des conséquences (entraînant la perte de
données) lors de l'utilisation d'appareils Android, comme expliqué dans la
[documentation officielle] ([Link]
dhis-core-version-master/[Link]#mgt_user).

Tracker

29
Considérations en matière de sécurité{ #security-considerations } Mesures de configuration du système

9. L'accès aux données de Suivi est limité aux utilisateurs ayant un besoin
légitime de modifier/visualiser les données grâce à une utilisation
appropriée du partage et des groupes d'utilisateurs. Aucun programme de
suivi destiné à enregistrer des informations sur des personnes individuelles
n'est configuré sur la base d'un accès public. Les données de suivi sont
généralement liées à des individus et doivent donc être réservées aux
utilisateurs qui en font un usage légitime. S'il est souhaitable que les
données agrégées soient accessibles à tous les utilisateurs, ce n'est pas le
cas des données de suivi.
10. Les programmes de suivi sont configurés de manière à ce que les
utilisateurs ne puissent rechercher et accéder qu'aux données des
personnes qu'ils ont une raison légitime de consulter. Par exemple, un
utilisateur travaillant dans un établissement de santé ne doit pas être
affecté à un district. L'"unité d'organisation de recherche d'entités suivies"
ne doit pas être plus étendue que ce qui est nécessaire en pratique, si elle
est utilisée.

Android
L'utilisation d'appareils mobiles (Android) dans le DHIS2 est de plus en plus
courante en raison de leurs capacités hors ligne et de leur capacité à être
utilisés sur le dernier kilomètre. Toutefois, elle s'accompagne d'exigences
supplémentaires à prendre en compte du point de vue de la sécurité, car
l'exposition augmente lors du passage d'un serveur contenant des
informations à de multiples appareils susceptibles de contenir des
informations sensibles.
Si des informations sensibles sont stockées dans les appareils, il convient
de s'en préoccuper par le biais d'une formation et/ou d'une documentation.
Les administrateurs de système pourraient vouloir activer différentes
mesures susceptibles de réduire les risques pour lesquels l'application Web
des paramètres Android (ASWA) est disponible.
L'ASWA permet aux administrateurs de système (entre autres) de:

• Forcer le cryptage de la base de données locale DHIS2 sur les

appareils afin d'empêcher la fuite de données par des acteurs
malveillants en cas d'accès à un appareil.
• Autoriser/interdire les fonctionnalités de capture d'écran réduit (mais
ne limite pas) le risque de fuite d'informations confidentielles.

Une section de la documentation officielle (DHIS2 Android App) décrit tous

ces éléments en détail.
En outre, l'application Android peut être configurée individuellement afin de
demander un code PIN comme couche de sécurité supplémentaire à la
paire nom d'utilisateur/mot de passe.
Dans les implémentations où le risque de perte ou de vol des appareils
existe, les administrateurs de système peuvent vouloir ajouter une autre
couche de sécurité apportée par des outils tels que la gestion des appareils
mobiles qui pourrait permettre une suppression à distance, une localisation,
etc. Un guide spécifique est disponible dans la documentation officielle :
gestion des appareils mobiles.

30
Considérations en matière de sécurité{ #security- Mesures techniques{ #technical-measures
considerations } }
Mesures techniques{ #technical-measures }

Il existe de nombreuses façons de mettre en service un système DHIS2, notamment dans différents
environnements physiques (sur site, en colocalisation, sur un Cloud privé, sur un Cloud public), en
utilisant différents systèmes d'exploitation, des conteneurs, le partage de charge, la réplication, etc. Il
existe différents ensembles détaillés de contrôles de sécurité qui peuvent et doivent être appliqués en
fonction des choix de conception effectués lors de la mise en service.

Dans le sens le plus général, ces éléments doivent être présents :

• un ensemble documenté de contrôles techniques mandatés ; et

• un processus d'audit de ces contrôles.

Des organisations telles que le Centre for Internet Security ([Link] consignent en détail
des points de référence pour les produits logiciels qui peuvent être utilisés pour compiler un ensemble
de contrôles dans le cadre de votre mise en œuvre. Dans la plupart des cas, vous ne les appliquerez
pas tous, mais sélectionnerez ceux qui sont les plus pertinents. Dans la liste disponible sur le site
[Link] vous devez télécharger et étudier les points de référence
pour Apache Tomcat, Postgresql, nginx (ou Apache2). En outre, en fonction de vos choix
technologiques, vous pourrez trouver des points de référence pour Ubuntu linux, lxd, Docker ou
Microsoft Windows, qui sont pertinents pour votre mise en œuvre.

Voici le projet de liste présentant les 10 meilleures mesures techniques à mettre en place :

1. Le système d'exploitation est une édition LTS (édition du service à long

terme).
2. Il existe un processus automatique d'application des patchs de sécurité
du système d'exploitation..
3. Pare-feu configuré au niveau de l'hôte et/ou du réseau, n'exposant au
réseau que les services nécessaires.
4. L'accès administratif au serveur DHIS2 se fait via SSH conformément
aux bonnes pratiques convenues - authentification par clés uniquement,
pas d'accès root, liste explicite d'utilisateurs autorisés, faible nombre de
tentatives d'authentification maximales.
5. La version du DHIS2 n'est pas décalée de plus de 3 versions par rapport
à la dernière parution. Il existe un processus permettant d'appliquer
régulièrement les versions corrigées.
6. Un système de sauvegarde automatisé est en place et régulièrement
testé, même hors site.
[Link] utilisateurs de Postgres et du système suivent le principe du moindre
privilège : ils n'accordent que des autorisations et des accès minimaux.
8.DHIS2 est accessible via un serveur web-proxy configuré avec TLS/SSL
(doit obtenir un minimum de A dans ssllabs).
9. Les données de la base de données se trouvent dans un endroit séparé
(partition de données, disque dur, stockage en nuage, etc.), ce qui permet
le chiffrement au repos.
10. Des systèmes de surveillance et d'alerte sont en place pour les
mesures du système (CPU, mémoire, disque, réseau, base de données,
proxy web au minimum) avec des mécanismes d'authentification adéquats
(par exemple 2FA, SSO, exigences de mots de passe solides) et un accès
basé sur les rôles.

31
Hébergement du serveur DHIS2{ #dhis2-server-hosting } Architecture

Hébergement du serveur DHIS2{ #dhis2-server-hosting }

Ce chapitre présente les défis liés à la mise en place d'un système DHIS2 en production. Il décrit les
différentes approches que l'on rencontre couramment dans la pratique et examine d'un œil critique les
avantages et les inconvénients de chacune d'entre elles. Il vise à fournir des conseils pratiques et
pragmatiques aux organisations qui planifient la mise en œuvre de DHIS2. Le document se réfère à
un ministère national de la santé (MDS) en tant que propriétaire potentiel du système, mais la plupart
des considérations s'appliquent également à d'autres types d'organisations.

Architecture

Installation la plus basique de DHIS2

DHIS2 est une application web Java soutenue par une base de données qui peut être configurée pour
fonctionner très simplement, en utilisant simplement un moteur de servlet Java tel que tomcat ou jetty
et un serveur de base de données postgresql. Une personne ayant des compétences techniques
raisonnables peut lire le guide de référence de DHIS2 et configurer les deux paquets ainsi que la
connexion à la base de données qui les relie de manière relativement simple sur un ordinateur
portable. Ce type d'installation est assez courant pour les développeurs ou les personnes qui
souhaitent simplement essayer DHIS2 localement et voir à quoi il ressemble. Le fichier de l'application
web DHIS2 (le fichier WAR) est téléchargé à partir de la page [Link] la
connexion à la base de données est configurée dans [Link] et l'application DHIS2 est accessible
via un navigateur web se connectant au serveur tomcat en cours d'exécution.

Simple architecture

La mise en place et le fonctionnement de DHIS2 en production impliquent bien plus que les
composants logiciels connectés. Les ressources matérielles doivent être approvisionnées et gérées.

32
Hébergement du serveur DHIS2{ #dhis2-server-hosting } DHIS2 en production

Les logiciels doivent être installés en tenant compte de la sécurité, des performances et de la facilité
de maintenance. Dans la plupart des cas, il y aura plus d'un système DHIS2 et potentiellement
d'autres systèmes au sein de l'architecture. Il faudra tenir compte de l'infrastructure environnante
(systèmes de surveillance, systèmes de messagerie, composants d'interopérabilité, etc.) Et surtout,
un mélange considérable de compétences techniques et d'expérience (warmware) est nécessaire
pour concevoir, installer et gérer le système.

DHIS2 en production

La planification d'un serveur DHIS2 qui fonctionne dans un environnement de production est un
exercice beaucoup plus long et laborieux, car : - en général, l'application devra être disponible en
permanence, avec très peu de temps d'arrêt planifiés ou non - les données qu'il contiendra sont
précieuses et potentiellement sensibles - les grands sites peuvent compter des dizaines de milliers
d'utilisateurs et avoir des millions de registres - le système devra être activement entretenu et mis à
jour pendant de nombreuses années

Tous ces éléments donnent lieu à des exigences assez complexes en matière d'infrastructure
physique, de contraintes de sécurité et de performance, ainsi qu'à un large éventail de compétences
techniques, qui n'apparaissent pas immédiatement à la vue de l'architecture simple ci-dessus. Il est
essentiel que l'implémentation du serveur soit correctement planifiée lors de la phase de planification
d'une implémentation afin de pouvoir mobiliser les ressources physiques et humaines nécessaires
pour répondre à ces exigences.

Élaboration d'un plan{ #making-a-plan }

Sécurité

Il est toujours judicieux d'avoir la sécurité à l'esprit dès le départ. Dans la pratique, cela pourrait
signifier que vous avez prévu un budget : 1. intégrer un chargé de sécurité au sein de l'équipe
centrale. Une grande partie du rôle du chargé de sécurité consistera à élaborer un plan de gestion de
la sécurité, par exemple en suivant les lignes directrices de la norme ISO27001. 2. pour procéder à un
audit annuel interne ou, de préférence, externe du système. Vous trouverez plus de détails sur la
sécurité dans ce guide à la section qui lui est dédiée.

Sauvegardes et archivage{ #backups-and-archiving }

Les considérations détaillées ici doivent découler du plan de sécurité et être mises en place
conformément au processus d'installation. Nous attirons particulièrement l'attention sur ce point car,
d'après notre expérience au fil des ans, les " désastres " les plus courants que nous observons sont
liés à des sauvegardes inadéquates, qui entraînent souvent une perte irrémédiable de données.

Les aspects importants du plan de sauvegarde à prendre en compte sont les suivants: 1. Quels sont
les objectifs de récupération ponctuels (combien de données pouvez-vous vous permettre de
perdre) ? 2. Automatisation. Un plan de sauvegarde qui dépend de l'intervention humaine pour
effectuer les sauvegardes n'est pas un plan fiable 3. Archivage hors site. Le stockage des
sauvegardes sur la même machine présente un certain intérêt, mais il faut tenir compte de la
possibilité d'une défaillance catastrophique de la machine (ou des machines voisines). Cela inclut les
machines virtuelles en nuage. Il faut également tenir compte du coût de la capacité des disques à
grande vitesse. Pour ceux qui le peuvent, l'archivage hors site à l'aide du stockage d'objets
(compatible S3) est désormais disponible auprès d'une série de fournisseurs de services en nuage et
constitue généralement le moyen le moins cher et le plus simple pour gérer l'archivage. 4. Test. Les
sauvegardes doivent être testées périodiquement (de préférence de manière automatisée) pour
s'assurer que les fichiers que vous estimez avoir été sauvegardés le sont réellement.

33
Hébergement du serveur DHIS2{ #dhis2-server-hosting } Environnement physique

Le plan de sauvegarde comporte d'autres aspects, mais le point important à souligner est qu'il doit
être sérieusement envisagé dès le début d'un projet plutôt qu'après réflexion. Il y a toujours des
compromis budgétaires à faire, donc tout plan de sauvegarde doit être correctement évalué en tenant
compte des exigences de conservation par rapport au budget.

Environnement physique

L'une des parties les plus importantes de votre plan consistera à prendre des décisions sur
l'environnement physique dans lequel vos serveurs fonctionneront. Le premier grand choix consiste à
posséder son propre équipement et ses propres installations d'hébergement ou à faire appel à un
fournisseur de services en nuage et à payer pour l'utilisation des ressources et éventuellement
d'autres services tels que la gestion des applications. Il n'y a pas de bonne ou de mauvaise réponse
et votre choix sera déterminé par des facteurs tels que le coût, les compétences disponibles,
l'infrastructure existante, la conformité réglementaire, etc. Le DHIS2 a été mis en œuvre avec succès
à l'aide d'une variété de modèles de déploiement, bien que chacun d'entre eux s'accompagne de son
propre ensemble de risques et de défis. Dans cette section, nous proposons quelques réflexions sur
chacun d'entre eux et terminons par un bref tableau récapitulatif des facteurs à prendre en compte.

A la base

Cette description légèrement ironique fait référence aux organisations qui achètent des équipements
de serveur et les installent dans une salle de serveur dans le bâtiment. Le fait d'avoir tout à portée de
main maximise le sentiment de contrôle sur les ressources, mais ce contrôle s'accompagne d'une plus
grande responsabilité.

Cette approche est de loin la plus difficile à mettre en œuvre. Les défis courants sont les suivants :

1. des contrôles de sécurité incendie insuffisants

2. un risque de dégât des eaux dû à des climatiseurs et/ou à une plomberie environnante en
mauvais état
3. la présence d'un circuit électrique indépendant du réseau électrique du bâtiment
4. un contrôle insuffisant ou inexistant de la poussière
5. des câbles endommagés dus à une infestation de rongeurs
6. la difficulté à accéder physiquement et à tout moment aux bâtiments gouvernementaux en
dehors des heures de bureau

Les considérations architecturales à elles seules constituent une proposition assez coûteuse. Placer
des équipements et des racks de classe serveur dans un environnement non réglementé réduira la
durée de vie fonctionnelle et annulera les garanties.

En raison des coûts et des risques encourus, nous déconseillons dans la plupart des cas d'emprunter
cette voie. Un plus grand nombre de compétences techniques sont également requises, notamment
en matière d'ingénierie des centres de données, de réseau et de sécurité, ce qui peut être évité en
utilisant l'une des approches ci-dessous.

Centre de données d'un ministère ou du gouvernement

Conscients des difficultés susmentionnées, de nombreux pays ont adopté une stratégie consistant à
concentrer les besoins d'hébergement dans des centres de données spécialement construits à
l'échelle du gouvernement ou du ministère.

• le mode de gestion varie

• les compétences en matière de logiciels libres ne sont pas toujours répandues (utilisation
fréquente de Windows, hyperV et vmware)
• l'accès aux services et les modifications de la configuration du réseau, entre autres, peuvent
être très lourds sur le plan administratif

34
Hébergement du serveur DHIS2{ #dhis2-server- Co-location ou hébergement virtuel au sein d'un
hosting } pays
• les machines virtuelles surdimensionnées rencontrent des problèmes de performance, en
particulier au niveau du disque des serveurs de bases de données

Co-location ou hébergement virtuel au sein d'un pays

Certains pays ont fait appel avec succès à des fournisseurs locaux de centres de données pour
héberger des serveurs physiques (colocation) ou pour louer des ressources virtuelles. Cette approche
présente l'avantage de répondre aux exigences en matière de géolocalisation des données (par
exemple, toutes les données doivent être stockées dans le pays). Par ailleurs, le gouvernement a
tendance à avoir plus d'influence sur ces entreprises que sur les grands fournisseurs commerciaux
mondiaux - ils sont moins susceptibles d'être coupés lorsque le paiement de la facture est en retard !

Les risques potentiels de cette approche sont les suivants : - en raison des économies d'échelle,
l'hébergement local a tendance à être plus coûteux que les entreprises Cloud mondiales - lorsque
l'État a imposé qu'une entreprise donnée soit désignée comme « fournisseur privilégié », des
problèmes de performance et de service à la clientèle sont souvent constatés

Fournisseurs de services en nuage

• infrastructure générique en tant que service (linode, aws, azure, etc.)

• prestataires de services spécialisés DHIS2 - Logiciel en tant que service (BAO, BlueSquare,
HISP SA, etc.)

Approche Description Coût Compétences Sécurité

Au sous-sol Le serveur est Les coûts Un haut niveau de La sécurité

installé dans le d'installation compétences est physique et la
ministère, peuvent être requis, allant de sécurité du
généralement élevés, pour l'administration réseau sont des
dans une salle mettre la salle aux système à défis
reconvertie normes en l'administration supplémentaires
matière réseau en
d'électricité, de passant par des
climatisation, etc. connaissances en
gestion des
centres de
données

Centre de Les applications Le coût pour le Les compétences Les

données du ministère de la ministère de la requises pour préoccupations en
gouvernemental Santé sont santé varie en faire fonctionner matière de
au niveau national hébergées dans fonction des le système se sécurité sont
un centre de mécanismes de limitent à partagées par les
données construit recouvrement des l'administration du responsables de
à cet effet et géré coûts du centre système. Le la mise en œuvre
comme un service de données. Il centre de et le fournisseur
intergouverneme varie de zéro à données doit du centre de
ntal beaucoup plus disposer d'autres données
élevé que celui du compétences
cloud commercial. liées aux réseaux
ainsi qu'à la
gestion et à
l'approvisionnem
ent des machines
virtuelles.

35
Hébergement du serveur DHIS2{ #dhis2-server-hosting } Compétences requises

Approche Description Coût Compétences Sécurité

Cloud commercial Le ministère de la En général, c'est Il suffit d'avoir des Les

1 (Infrastructure Santé possède un l'option la moins compétences préoccupations en
en tant que compte auprès coûteuse. d'administrateur matière de
service) d'une entreprise Variations système pour sécurité sont
commerciale de considérables des mettre en place et partagées entre
Cloud et paie pour plans de faire fonctionner les responsables
l'utilisation des tarification sur le le système. Des de la mise en
ressources du marché processus de œuvre et le
serveur gestion doivent fournisseur de
être mis en place services Cloud
pour gérer le
budget et
s'assurer que les
factures sont
payées.

Cloud commercial Le ministère de la Plus coûteux que Des processus de La plupart des
2 (logiciel en tant Santé possède un l'infrastructure en gestion doivent problèmes de
que service) compte auprès tant que service, être mis en place sécurité sont
d'une société mais supprime la pour gérer le gérés par le
commerciale qui nécessité de budget et garantir prestataire de
propose la verser un salaire le paiement des services
solution DHIS2 en onéreux pour un factures
tant que service administrateur
système

Compétences requises

DHIS2 est un système relativement complexe à administrer. L'équipe chargée de l'administration du

système devra disposer d'une expertise et d'une expérience dans les domaines suivants: - ubuntu
linux - Proxy web Apache2 ou nginx - Apache tomcat - Base de données Postgresql Si cette
expérience n'est pas disponible en interne, le ministère serait bien avisé de confier une partie de la
gestion à une entité locale disposant d'un tel portefeuille de compétences, même si cela est considéré
comme un arrangement transitoire.

Maintenance

Au-delà de l'installation, les activités courantes consistent en général à : 1. fournir des instances de
mise en scène, de test et de formation, au besoin 2. le contrôle des performances et l'adaptation du
logiciel à la situation 3. gérer et tester les sauvegardes 4. la proposition de correctifs (fréquence
typique de 4 à 6 semaines) pour les mises à jour de versions mineures 5. planifier et exécuter la mise
à niveau majeure de l'instance DHIS2 (tous les ans) 6. proposer des mises à niveau majeures du
système d'exploitation et du serveur de base de données (tous les 2 ou 3 ans)

L'UIO peut fournir une formation sur l'architecture globale et tout ce qui est spécifique à DHIS2 et
également relier les responsables de la maintenance à la communauté mondiale de pratique dans
l'administration du système DHIS2. Il est à noter qu'il existe des exigences préalables en ce qui
concerne les compétences énumérées ci-dessus. Il n'est ni pratique ni judicieux de dépendre des
administrateurs de système qui n'ont pas l'expérience requise.

36
Hébergement du serveur DHIS2{ #dhis2- Installation et configuration du logiciel{ #software-installation-
server-hosting } and-configuration }
Installation et configuration du logiciel{ #software-installation-and-configuration }

L'équipe de l'UiO met à votre disposition un certain nombre de ressources pour faciliter l'installation :

• Le [guide] ([Link] référence définitif de DHIS2 est

tenu à jour par les développeurs de DHIS2 et il est important de le lire attentivement pour
obtenir une description complète de la configuration et de la fonctionnalité de DHIS2 du point
de vue du backend. Un administrateur système expérimenté peut y trouver ce dont il a besoin
pour concevoir une installation DHIS2 prête pour la production. Il y a beaucoup de travail
supplémentaire à faire pour approvisionner, surveiller et sécuriser l'environnement ambiant.
• Idéalement, l'installation devrait être automatisée, plutôt qu'une œuvre d'art réalisée à la main.
Nous fournissons des [outils] ([Link] pour automatiser au moins la plupart des aspects
de l'installation à l'aide de conteneurs LXD. Ces outils se sont avérés utiles pour de
nombreuses implémentations et s'inspirent des documents de référence ci-dessus et d'autres
documents pour coder les bonnes pratiques par défaut.
• L'objectif actuel du project est de moderniser le mode d'installation ci-dessus et de la
réimplémenter pour utiliser des playbooks Ansible et dépendre moins des conteneurs LXD.

37
DHIS2 comme entrepôt de données Les entrepôts de données et les systèmes opérationnels

DHIS2 comme entrepôt de données

Ce chapitre abordera le rôle et la place de l'application DHIS2 dans le contexte de l'architecture du
système. Il montrera que DHIS2 peut servir à la fois d'entrepôt de données et de système
opérationnel.

Les entrepôts de données et les systèmes opérationnels

Un entrepôt de données est généralement considéré comme une base de données utilisée à des fins
d'analyse. Les données sont généralement téléchargées à partir de divers systèmes opérationnels/
transactionnels. Avant d'être chargées dans l'entrepôt de données, les données passent
généralement par différentes étapes au cours desquelles elles sont nettoyées pour détecter les
anomalies et les redondances, et transformées pour se conformer à la structure globale de la base de
données intégrée. Les données sont ensuite mises à disposition pour être utilisées dans le cadre
d'une analyse, également connue sous des termes tels que*data mining* (extraction de données) et
online analytical processing (traitement analytique en ligne). La conception de l'entrepôt de données
est optimisée pour accélérer la recherche et l'analyse des données. Pour améliorer les performances,
le stockage des données est souvent redondant, c'est-à-dire que les données sont stockées à la fois
sous leur forme la plus granulaire et sous une forme agrégée (résumée).

Un système transactionnel (ou système opérationnel du point de vue de l'entrepôt de données) est un
système qui collecte, stocke et modifie des données de bas niveau. Ce système est généralement
utilisé au quotidien pour la saisie et la validation des données. La conception est optimisée pour des
performances d'insertion et de mise à jour rapides.

La gestion d'un entrepôt de données présente plusieurs avantages, dont les suivants:

• Cohérence: elle fournit un modèle de données commun pour toutes les données pertinentes et
agit comme une abstraction sur un nombre potentiellement élevé de sources de données et de
systèmes d'alimentation, ce qui la rend beaucoup plus facile à exécuter l'analyse.

• Fiabilité: Il est détaché des sources d'où proviennent les données et n'est donc pas affecté si
les données des systèmes opérationnels sont purgées ou perdues.

• Performance d'analyse: Il est conçu pour une performance maximale pour l'extraction et
l'analyse des données, contrairement aux systèmes opérationnels qui sont souvent optimisés
pour la saisie de données.

Cependant, l'approche axée sur l'entrepôt de données pose également des problèmes importants :

• Coût élevé: Le transfert de données provenant de différentes sources vers un entrepôt de

données commun est très coûteux, en particulier lorsque les systèmes opérationnels ne sont
pas de même nature. Souvent, les systèmes existants à long terme (appelés systèmes
patrimoniaux) imposent de lourdes contraintes au processus de transformation des données.

• Validité des données: Le processus de transfert des données dans l'entrepôt de données est
souvent complexe et n'est donc pas exécuté à intervalles réguliers et en temps voulu. Ceci
aboutira à ce que les utilisateurs de données disposent de données périmées et non
pertinentes, inadaptées à la planification et à la prise de décision éclairée.

En raison des défis mentionnés, il est devenu de plus en plus populaire de fusionner les fonctions de
l'entrepôt de données et du système opérationnel, soit dans un système unique qui exécute les deux
tâches, soit avec des systèmes étroitement intégrés hébergés ensemble. Avec cette approche, le
système fournit des fonctionnalités pour la saisie et la validation des données ainsi que pour l'analyse
des données et gère le processus de conversion des données atomiques de bas niveau en données
agrégées adaptées à l'analyse. Cela impose des normes levées au système et à sa conception, car il
doit fournir des performances appropriées pour ces deux fonctions ; cependant, les progrès réalisés

38
DHIS2 comme entrepôt de données Stratégie d'agrégation dans DHIS2{ #aggregation-strategy-in-dhis2 }

dans le domaine du matériel et du traitement parallèle rendent cette approche de plus en plus
réalisable.

À cet égard, l'application DHIS2 est conçue pour servir d'outil à la fois pour la saisie, la validation,
l'analyse et la présentation des données. Elle fournit des modules pour tous les aspects mentionnés, y
compris la fonctionnalité de saisie des données et un large éventail d'outils d'analyse tels que les
rapports, les graphiques, les cartes, les tableaux croisés dynamiques et les tableaux de bord.

Par ailleurs, DHIS2 fait partie d'une suite de systèmes d'information de santé interopérables qui
couvrent un large éventail de besoins et sont tous des logiciels libres. DHIS2 met en œuvre la norme
d'échange de données et de métadonnées dans le domaine de la santé appelée SDMX-HD. Il existe
de nombreux exemples de systèmes opérationnels qui mettent également en œuvre cette norme et
qui peuvent potentiellement alimenter le DHIS2 en données :

• iHRIS : Système de gestion des données relatives aux ressources humaines. Voici quelques
exemples de données pertinentes pour un entrepôt de données national, saisies par ce
système : "nombre de médecins", "nombre d'infirmières" et "nombre total de membres du
personnel". Ces données sont intéressantes pour comparer, par exemple, les performances
des districts.

• OpenMRS : Système de dossiers médicaux utilisé à l'hôpital. Ce système peut potentiellement

agréger et exporter des données sur les maladies des patients hospitalisés vers un entrepôt de
données national.

• OpenELIS : Système d'information d'entreprise de laboratoire. Ce système peut générer et

exporter des données sur le nombre et les résultats des tests de laboratoire.

Stratégie d'agrégation dans DHIS2{ #aggregation-strategy-in-dhis2 }

Les outils d'analyse du DHIS2 lisent des données agrégées à partir de tables data mart. Un data mart
est un magasin de données optimisé pour répondre aux demandes les plus courantes des utilisateurs

39
DHIS2 comme entrepôt de données Approches pour le stockage de données

en matière d'analyse de données. La base de données DHIS2 contient des données agrégées dans
la* dimension spatiale* (la hiérarchie des unités d'organisation), la dimension temporelle (sur plusieurs
périodes) et pour les formules d'indicateurs (expressions mathématiques comprenant des éléments de
données). L'extraction de données directement à partir des datamarts offre de bonnes performances,
même dans les environnements à forte concentration de données, car la plupart des demandes
d'analyse peuvent être satisfaites par une simple et unique interrogation de la base de données à
partir du datamart. Le moteur d'agrégation du DHIS2 est capable de traiter les données de bas niveau
par millions et de gérer la plupart des bases de données nationales, et l'on peut dire qu'il fournit un
accès en temps quasi réel aux données agrégées.

DHIS2 permet de définir des tâches d'agrégation programmées qui, en règle générale, actualisent et
alimentent le datamart avec des données agrégées chaque nuit. Vous pouvez choisir d'agréger les
données des 12 derniers mois chaque nuit ou d'agréger les données des 6 derniers mois chaque nuit
et les données des 6 à 12 derniers mois chaque samedi. Les tâches planifiées peuvent être
configurées sous "Planification" dans le module "Administration des données". Il est également
possible d'exécuter des tâches arbitraires sous "Data mart" dans le module "Rapports".

Approches pour le stockage de données

Il existe deux approches principales pour le stockage des données dans un entrepôt de données, à
savoir l'approche normalisée et l'approche dimensionnelle. Le DHIS2 s'inspire un peu de la première,
mais surtout de la seconde. Dans l'approche dimensionnelle, les données sont divisées en
dimensions et en faits. Les faits font généralement référence à des données numériques
transactionnelles, tandis que les dimensions sont les données de référence qui donnent un contexte
et une signification aux données. Les règles strictes de cette approche permettent aux utilisateurs de
comprendre facilement la structure de l'entrepôt de données et offrent de bonnes performances étant
donné que peu de tables doivent être combinées pour produire une analyse significative, alors qu'elles
pourraient rendre le système moins flexible et plus difficile à modifier.

Dans DHIS2, les faits correspondent à l'objet valeur de données dans le modèle de données. La
valeur des données saisit les données sous forme de nombres, de oui/non ou de texte. Les
dimensions obligatoires qui donnent un sens aux faits sont les dimensions élément de données,
hiérarchie de l'unité d'organisation et période. Ces dimensions sont qualifiées d'obligatoires car elles
doivent être fournies pour tous les enregistrements de données stockées. Le DHIS2 dispose
également d'un modèle dimensionnel personnalisé qui permet de représenter n'importe quel type de
dimensionnalité. Ce modèle doit être défini avant la saisie des données. DHIS2 dispose également
d'un modèle flexible de groupes et d'ensembles de groupes qui permet d'ajouter une dimensionnalité
personnalisée aux dimensions obligatoires après la saisie des données. Pour en savoir plus sur la
dimensionnalité dans le DHIS2, voir le chapitre du même nom.

40
DHIS2 comme entrepôt de données Approches pour le stockage de données

41
DHIS2 en tant que plateforme Approches pour le stockage de données

DHIS2 en tant que plateforme

Le DHIS2 peut être perçu comme une plate-forme à plusieurs niveaux. Tout d'abord, la base de
données de l'application est conçue de manière à être flexible. Les structures de données telles que
les éléments de données, les unités d'organisation, les formulaires et les rôles des utilisateurs peuvent
être définis en toute liberté par l'interface utilisateur de l'application. Cela permet d'adapter le système
à une multitude de contextes locaux et de cas d'utilisation. Nous avons vu que le DHIS2 prend en
charge la plupart des principales exigences de saisie et d'analyse de données de routine qui
apparaissent dans les mises en œuvre nationales. Il permet également à DHIS2 de servir de système
de gestion pour des domaines tels que la logistique, les laboratoires et les finances.

Deuxièmement, grâce à sa conception modulaire, le système DHIS2 peut être étendu par des
modules logiciels supplémentaires. Ces modules des logicielles peuvent cohabiter avec les modules
de base du système DHIS2 et peuvent être intégrés dans le portail et le système de menu du système
DHIS2. Il s'agit d'une fonction puissante car elle permet d'étendre le système avec des fonctionnalités
supplémentaires si nécessaire, généralement pour des besoins spécifiques à un pays, comme indiqué
précédemment.

L'inconvénient de l'extensibilité du module logiciel est qu'elle impose plusieurs contraintes au

processus de développement. Les développeurs qui créent les fonctionnalités supplémentaires sont
limités à la technologie DHIS2 en termes de langage de programmation et de cadres logiciels, en plus
des contraintes imposées à la conception des modules par la solution de portail DHIS2. En outre, ces
modules doivent être inclus dans le logiciel DHIS2 lorsque le logiciel est construit et déployé sur le
serveur web, et non de manière dynamique pendant l'exécution.

Afin de surmonter ces limitations et de parvenir à un couplage plus souple entre la couche de service
DHIS2 et les artefacts logiciels supplémentaires, l'équipe de développement du DHIS2 a décidé de
créer une API Web. Cette API Web est conforme aux règles du style architectural REST. Cela implique
que :

• L'API Web fournit une interface navigable et lisible par machine pour le modèle de données
complet du DHIS2. Par exemple, on peut accéder à la liste complète des éléments de données,
puis naviguer à l'aide de l'hyperlien fourni vers un élément de données particulier qui nous
intéresse, puis naviguer à l'aide de l'hyperlien fourni vers la liste des formulaires dont cet
élément de données fait Par exemple, les clients n'effectueront des transitions d'état qu'en
utilisant les hyperliens qui sont intégrés dynamiquement dans les réponses.

• L'accès aux données s'effectue par le biais d'une interface uniforme (URL) utilisant un protocole
bien connu. Il n'y a pas de formats ou de protocoles de transport fantaisistes, mais simplement
le protocole HTTP, qui a été testé et qui est bien compris, et qui est le principal élément
constitutif du Web aujourd'hui. Cela signifie que les développeurs tiers peuvent mettre au point
des logiciels utilisant le modèle de données et les données DHIS2 sans connaître la
technologie spécifique de DHIS2 ou se conformer aux contraintes de conception de DHIS2.

• Toutes les données, y compris les métadonnées, les rapports, les cartes et les graphiques,
appelés ressources dans la terminologie REST, peuvent être récupérées dans la plupart des
formats de représentation populaires du web d'aujourd'hui, tels que HTML, XML, JSON, PDF et
PNG. Ces formats sont largement pris en charge par les applications et les langages de
programmation et offrent aux développeurs tiers un vaste champ d'options de mise en œuvre.

42
DHIS2 en tant que plateforme Portails Web

Il existe plusieurs scénarios dans lesquels des artefacts logiciels supplémentaires peuvent se
connecter à l'API Web DHIS2.

Portails Web

Tout d'abord, les portails Web peuvent être construits au-dessus de l'API Web. Un portail Web, à cet
effet, est un site Web qui fonctionne comme un point d'accès aux informations provenant d'un grand
nombre potentiel de sources de données qui partagent généralement un thème commun. Le rôle du
portail web est de rendre ces sources de données facilement accessibles de manière structurées sous
une apparence commune et de fournir une vue d'ensemble des données aux utilisateurs finaux.

Référentiel de données agrégées : Un portail web destiné au domaine de la santé peut utiliser le
DHIS2 comme source principale de données agrégées. Le portail peut se connecter à l'API Web et
communiquer avec des ressources importantes telles que les cartes, les graphiques, les rapports, les
tableaux et documents statiques. Ces vues de données peuvent afficher dynamiquement des
données agrégées basées sur des requêtes sur la dimension unité d'organisation, indicateur ou
période. Le portail peut apporter une valeur ajoutée à l'accessibilité de l'information de plusieurs
façons. Il peut être structuré de manière conviviale et rendre les données accessibles aux utilisateurs
inexpérimentés. Il peut fournir différentes approches relatives aux données, notamment :

• Thématique - regroupement d'indicateurs par thème. Des exemples de ces thèmes sont la
vaccination, les soins maternels, les maladies à déclaration obligatoire et la santé
environnementale.

43
DHIS2 en tant que plateforme Applications

Géographique - regroupement des données par province. Cela permettra de comparer

• facilement les performances et la charge de travail.

Application composite : Le portail Web n'est pas limité à la consommation de données provenant
d'une seule API Web.- Il peut être connecté à un nombre illimité d'API et être utilisé pour fusionner des
données provenant de systèmes auxiliaires dans le domaine de la santé. S'il est disponible le portail
peut intégrer des données spécialisées provenant de systèmes logistiques de suivi et de gestion des
médicaments ARV, de systèmes financiers gérant les paiements aux établissements de santé et des
systèmes de laboratoire qui suivent les tests de laboratoire pour les maladies transmissibles. Les
données provenant de toutes ces sources pourraient être présentées de manière cohérente et
significative afin de fournir un meilleur aperçu de la situation du domaine de la santé.

Dépôt de documents : Le portail web peut faire office de référentiel documentaire en lui-même
(également appelé système de gestion de contenu). Les documents pertinents tels que les rapports
publiés, les données d'enquête, les plans opérationnels annuels et les FAQ peuvent être téléchargés
et gérés en termes de propriété, de contrôle des versions et de classification. Le portail devient ainsi
un point central pour le partage de documents et la collaboration. L'émergence de solutions de dépôt
et de CMS de haute qualité et à code source ouvert, telles que Alfresco et Drupal rend cette approche
plus réalisable et plus convaincante.

Gestion des connaissances : La gestion des connaissances fait référence aux pratiques permettant
d'identifier, de matérialiser et de partager les connaissances et l'expérience. Dans notre contexte, elle
concerne tous les aspects de la mise en œuvre et de l'utilisation des systèmes d'information, tels que :

• la conception de la base de données

• l'utilisation du système d'information et guides méthodologiques

• les directives pour la conduite de formations destinées aux utilisateurs finaux

• l'utilisation des données, leur analyse et interprétation

Les connaissances et l'apprentissage dans ces domaines peuvent être matérialisés sous forme de
manuels, d'articles, de livres, de jeux de diapositives, de vidéos, de textes d'aide intégrés au système,
de sites d'apprentissage en ligne, de forums, de FAQ, etc. Tous ces artefacts peuvent être publiés et
rendus accessibles à partir du portail web.

Forum : Le portail peut fournir un forum pour accueillir des discussions entre utilisateurs
professionnels. Le sujet peut aller de l'aide à l'exécution d'opérations de base dans le système
d'information de santé à des discussions sur l'analyse et l'interprétation des données. Un tel forum
peut servir de source d'information interactive et évoluer naturellement vers des archives précieuses.

Applications

Deuxièmement, les clients logiciels tiers fonctionnant sur des appareils tels que les téléphones
mobiles, les smartphones et les tablettes peuvent se connecter à l'API Web DHIS2 et lire et écrire
dans les ressources pertinentes. Par exemple, les développeurs tiers peuvent créer un client
fonctionnant sur le système d'exploitation Android sur des appareils mobiles destinés aux agents de
santé communautaires qui ont besoin de garder une trace des personnes à visiter, enregistrer les
données vitales pour chaque rencontre et recevoir des rappels des dates d'échéance pour les soins
aux patients tout en se déplaçant librement dans la communauté. Une telle application client pourrait
interagir avec les ressources de patients et de plans d'activité exposées par l'API Web du DHIS2. Le
développeur n'aura pas besoin d'une connaissance approfondie de l'implémentation interne du
DHIS2, mais plutôt des compétences de base en programmation HTTP/Web et quelques
connaissances du modèle de données DHIS2. La compréhension du modèle de données DHIS2 est
facilitée par la nature navigable de l'API Web.

44
DHIS2 en tant que plateforme Systèmes d'information

Systèmes d'information

Troisièmement, les développeurs de systèmes d'information visant à créer de nouvelles façons

d'afficher et de présenter des données agrégées peuvent utiliser l'API Web du DHIS2. comme couche
de service de leur système. L'effort nécessaire pour développer de nouveaux systèmes d'information
et les maintenir dans le temps est souvent grandement sous-estimés. Au lieu de partir de zéro, une
nouvelle application peut être construite au-dessus de l'API Web. L'attention des développeurs peut
être orientée vers la création de nouvelles représentations et visualisations de données, innovantes et
créatives, sous la forme, par exemple, de tableaux de bord, de SIG et de composants graphiques.

45
Concepts d'intégration Intégration et interopérabilité

Concepts d'intégration
DHIS2 est une plateforme ouverte et ses implémenteurs contribuent activement aux initiatives
d'interopérabilité, telles que openHIE. La base de données de l'application DHIS2 est conçue dans un
souci de flexibilité. Les structures de données telles que les éléments de données, les unités
d'organisation, les formulaires et les rôles des utilisateurs peuvent être définis en toute liberté via
l'interface utilisateur de l'application. Cela permet d'adapter le système à une multitude de contextes
locaux et de cas d'utilisation. Le DHIS2 répond à de nombreuses exigences en matière de saisie et
d'analyse des données de routine qui apparaissent dans les mises en œuvre nationales, à la fois pour
les scénarios HMIS et en tant que système de collecte et de gestion des données de base dans des
domaines tels que [la logistique, la gestion des laboratoires et les finances]
(#Intégration_et_interopérabilité).

Intégration et interopérabilité

Sur la base de l'approche de sa plate-forme, le DHIS2 est en mesure de recevoir et d'héberger des
données provenant de différentes sources et de les partager avec d'autres systèmes et mécanismes
de rapport. Une distinction importante des concepts d'intégration est la différence entre l'intégration
des données et l'interopérabilité des systèmes:

• Lorsque l'on parle d'intégration, on pense au processus qui vise à faire apparaître différents
systèmes d'information comme un seul, à mettre les données électroniques à la disposition de
tous les utilisateurs concernés, ainsi qu'à l'harmonisation des définitions et des dimensions afin
qu'il soit possible de combiner les données d'une manière utile.

• Un concept apparenté est l'interopérabilité, qui est une des stratégies permettant l'intégration.
Nous considérons que DHIS2 est interopérable avec d'autres applications logicielles en raison
de sa capacité à échanger des données. Par exemple, DHIS2 et OpenMRS sont
interopérables, car ils permettent de partager des définitions de données et des données entre
eux. L'interopérabilité dépend des normes relatives aux formats de données, aux interfaces,
aux codes et aux terminologies. Dans l'idéal, il s'agirait de normes convenues au niveau
international, mais dans la pratique, il peut également s'agir de normes de facto (qui sont
largement acceptées et utilisées, mais qui ne font pas nécessairement l'objet d'un vote formel
au sein d'un organisme de normalisation) et d'autres accords plus locaux dans un contexte
particulier.

DHIS2 est souvent utilisé comme un entrepôt de données intégré, car il contient des données
(agrégées) provenant de diverses sources, telles que [la santé de la mère et de l'enfant, le programme
de lutte contre le paludisme, les données de recensement et les données sur les stocks et les
ressources humaines] (#Objectifs_de_l'intégration). Ces sources de données partagent la même
plateforme, DHIS2, et sont disponibles au même endroit. Ces sous-systèmes sont donc considérés
comme intégrés dans un seul système.

L'interopérabilité permettra en outre d'intégrer des sources de données provenant d'autres

applications logicielles. Par exemple, si les données de recensement sont stockées dans un [registre
d'état civil ou dans un système d'événements vitaux] spécialisé (#Information_Santé), l'interopérabilité
entre cette base de données et le DHIS2 signifierait que les données de recensement seraient
également accessibles dans le DHIS2.

Enfin, l'activité d'intégration la plus fondamentale (qui n'est pas toujours prise en compte dans le débat
sur l'interopérabilité) est la possibilité d'intégrer dans le DHIS2 des données provenant de systèmes
sur support papier existants ou de systèmes verticaux parallèles. Les données seront saisies
directement dans DHIS2 sans passer par une autre application logicielle. Ce processus est basé sur
la création de définitions d'indicateurs cohérentes et peut déjà réduire considérablement la
fragmentation et améliorer l'analyse des données grâce à un référentiel de données intégré.

46
Concepts d'intégration Objectifs de l'intégration

Objectifs de l'intégration

Dans la plupart des pays, on trouve de nombreux systèmes isolés d'information sur la santé, ce qui
pose de nombreux problèmes de gestion de l'information. Les Systèmes d'Information de Santé
Publique ont connu une croissance explosive et souvent non coordonnée au cours des dernières
années. Les technologies modernes de l'information rendent moins coûteuse la mise en œuvre de
solutions ICT4D, ce qui peut conduire à une grande diversité de solutions. Un exemple stupéfiant a
été la déclaration du moratoire sur la mSanté du ministère ougandais de la santé en 2012, en réaction
à une avalanche d'environ [50 solutions de mSanté] ([Link]
mhealth-moratorium-good-thing) qui ont été mises en œuvre en l'espace de quelques années. La
plupart de ces solutions étaient des approches autonomes qui ne partageaient pas leurs données
avec les systèmes nationaux et qui ont rarement été développées au-delà du statut de projet pilote.

Cela peut conduire à la conclusion que tous les systèmes devraient être connectés ou que
l'interopérabilité est un objectif en soi. Cependant, le DHIS2 est souvent utilisé dans des contextes
où l'infrastructure est faible et où les ressources nécessaires pour faire fonctionner les systèmes de
base de manière fiable sont rares. La fragmentation est un problème sérieux dans ce contexte, mais
les approches d'interopérabilité ne peuvent résoudre qu'une partie des problèmes de fragmentation -
et souvent les approches d'interopérabilité entraînent une couche supplémentaire de complexité.

Exemple
Complexité des solutions logistiques au Ghana Dans le domaine de la
logistique ou de la gestion de la chaîne d'approvisionnement, on trouve
souvent une multitude de solutions logicielles parallèles. Celles-ci se
chevauchent ou se font concurrence au sein d'un même pays. Comme
l'indique le site Étude de JSI en 2012, il a été rapporté que dix-huit
(18!) outils logiciels différents ont été utilisés dans la chaîne
d'approvisionnement de santé publique, rien qu'au Ghana.

L'interopérabilité des systèmes semble donc être une possibilité d'éliminer la fragmentation et les
redondances et de donner aux agents de santé publique une image concise et équilibrée des sources
de données disponibles. Toutefois, l'effort nécessaire pour connecter de nombreuses solutions
logicielles redondantes serait très important et semble donc discutable. Dans un premier temps,
l'accent devrait être mis sur la réduction du nombre de systèmes parallèles et sur l'identification
des systèmes les plus performants, qui pourront ensuite être intégrés.

Sur cette base, nous souhaitons définir les principaux objectifs des approches d'intégration du DHIS2 :

• Calcul des indicateurs : De nombreux indicateurs sont basés sur des numérateurs et des
dénominateurs provenant de différentes sources de données. Les exemples sont notamment
les taux de mortalité, avec certaines données sur la mortalité comme numérateur et des
données sur la population comme dénominateur, les taux de couverture du personnel et de
charge de travail du personnel (données sur les ressources humaines et données sur la
population et les effectifs), les taux de vaccination, et ainsi de suite. Pour le calcul, vous avez
besoin des données du numérateur et du dénominateur, qui doivent donc être intégrées dans
un entrepôt de données unique. Plus il y a de sources de données intégrées, plus il est
possible de générer des indicateurs à partir du référentiel central.

• Réduire le traitement manuel et la saisie des données : Les différentes données étant
regroupées au même endroit, il n'est pas nécessaire d'extraire et de traiter manuellement les
indicateurs, ni de réintroduire les données dans l'entrepôt de données. L'interopérabilité entre
les systèmes de différents types de données (tels que les registres de patients et les entrepôts
de données agrégées) permet aux logiciels des sous-systèmes de calculer et de partager des
données par voie électronique. Cela réduit le nombre d'étapes manuelles impliquées dans le
traitement des données, ce qui améliore la qualité des données.

47
Concepts d'intégration Échange d'informations sur la santé{ #Health_information }

Réduire les redondances : Souvent, les données qui se chevauchent et qui sont redondantes
• sont saisies par les différents systèmes parallèles. Par exemple, les éléments de données
relatifs au VIH/SIDA seront-ils saisis à la fois par les multiples programmes généraux de conseil
et de dépistage et par le programme spécialisé sur le VIH/SIDA. L'harmonisation des outils de
collecte de données de ces programmes réduira la charge de travail totale des utilisateurs
finaux. Ceci signifie que ces sources de données peuvent être intégrées dans DHIS2 et
harmonisées avec les éléments de données existants, ce qui implique des exigences en
matière de saisie et d'analyse des données.

• Améliorer les aspects organisationnels : Si toutes les données peuvent être traitées par une
seule unité au sein du ministère de la santé, au lieu de divers sous-systèmes gérés par les
différents programmes de santé, cette unité peut être professionnalisée. Avec un personnel
dont la seule responsabilité est la gestion, le traitement et l'analyse des données, des
compétences plus spécialisées peuvent être développées et le traitement de l'information peut
être rationalisé.

• Intégration de programmes verticaux : Le domaine typique de la santé publique comporte de

nombreux acteurs et systèmes existants. Une base de données intégrée contenant des
données provenant de diverses sources est plus précieuse et plus utile que des bases de
données fragmentées et isolées. Par exemple, lorsque l'analyse des données épidémiologiques
est combinée avec des données spécialisées sur le VIH/SIDA, la tuberculose, les ressources
financières et humaines, ou lorsque l'immunisation est combinée avec des données sur la
logistique/le stock, on obtient une image plus complète de la situation.

DHIS2 peut contribuer à la rationalisation et à la simplification de l'architecture du système, en

répondant à des questions telles que : Quel est l'objectif de l'effort d'intégration ? Le DHIS2 peut-il
contribuer à réduire le nombre de systèmes ? L'intégration du DHIS2 peut-elle contribuer à fournir des
informations de gestion pertinentes à moindre coût, à plus grande vitesse et avec une meilleure
qualité de données que les systèmes existants ? Le DHIS2 est-il le meilleur outil pour remplacer
d'autres systèmes, ou une autre solution adaptée et interopérable avec le DHIS2 est-elle plus
appropriée ? Des informations plus pratiques sur la définition de ces objectifs sont disponibles dans la
*[ÉTAPE 1 du guide de mise en œuvre en 6 étapes *] ([Link]

Échange d'informations sur la santé{ #Health_information }

Étant donné qu'il existe différents cas d'utilisation des informations sur la santé, il existe différents
types d'applications logicielles fonctionnant dans le secteur de la santé. Nous utilisons le terme
d'architecture de l'information sur la santé pour décrire un plan ou un aperçu des différentes
applications logicielles, de leurs utilisations spécifiques et des connexions de données. L'architecture
sert de plan pour coordonner le développement et l'interopérabilité des différents sous-systèmes au
sein d'un système d'information sur la santé plus vaste. Il est conseillé d'élaborer un plan qui couvre
tous les composants, y compris les domaines qui n'utilisent actuellement aucun logiciel, afin d'être en
mesure de voir de manière adéquate les exigences en termes de partage des données. Ces
exigences devraient ensuite faire partie des spécifications du logiciel une fois qu'il est développé ou
acheté.

Le [openhealth information exchange (openHIE)] ([Link] est une interprétation

interopérable de cette architecture, dans laquelle un HMIS ou le DHIS2 joue souvent un rôle
important. Le cadre openHIE a été développé avec un accent particulier mis sur les pays à faibles
ressources, grâce à la participation de plusieurs institutions et partenaires de développement, y
compris le programme HISP d'Oslo.

L'aperçu schématique ci-dessous montre les principaux éléments du cadre openHIE, qui comprend
une couche de composants, une couche de services d'interopérabilité et des systèmes externes. La
couche de composants openHIE couvre les métadonnées ou données de référence (terminologie,
clients, établissements), les données personnelles (personnel, antécédents des patients) et les

48
Concepts d'intégration 1:1 intégration

statistiques nationales sur la santé. L'objectif est de garantir la disponibilité des mêmes métadonnées
dans tous les systèmes qui participent à l'échange de données correspondant (par exemple, les
définitions des indicateurs, la dénomination des établissements, le codage et la classification). Dans
certains cas, comme celui du registre principal des établissements, les données peuvent également
être utilisées pour fournir des informations au grand public par l'intermédiaire d'un portail web. Alors
que la couche d'interopérabilité assure le courtage des données entre les différents systèmes, la
couche des systèmes externes contient plusieurs sous-systèmes, dont la plupart se situent au niveau
des points de service, dont les fonctions se chevauchent souvent.

Il existe différentes approches pour définir une architecture de cybersanté. Dans le contexte de la
ligne directrice DHIS2, nous distinguons les approches basées sur une connexion 1:1 par rapport aux
approches basées sur une connexion n:n (many-to-many).

1:1 intégration

Dans de nombreux pays, un HMIS national est souvent le premier système à être déployé dans un
grand nombre d'établissements et à gérer un grand nombre de données sur une base mensuelle ou
trimestrielle. Lorsque les pays commencent à développer l'architecture de leur système de santé,
DHIS2 est souvent connecté à d'autres systèmes. Cette connexion se fait souvent directement par un
simple script qui automatise le transfert des données.

On parle de connexion 1:1 parce qu'elle est limitée à deux systèmes. Dans le cas d'une intégration
LMIS/HMIS, un LMIS transférera des données au DHIS2 omme défini dans le script. Cette approche
pratique représente souvent une première étape et constitue l'un des cas d'utilisation les plus courants
sur la voie d'une architecture openHIE interopérable. Toutefois, cette simplicité présente également
des inconvénients : Dans le cas où un deuxième système logistique souhaiterais transférer des
données à DHIS2 (par exemple, des données sur les produits pour un programme de lutte contre une
maladie spécifique), un deuxième script devra être écrit pour effectuer cette tâche. Ces deux scripts
s'exécuteraient alors indépendamment l'un de l'autre, ce qui donnerait lieu à deux connexions 1:1
distinctes.

Intégration n:n.{ #nn }

Une autre approche consiste à placer un logiciel spécialement conçu pour servir de couche
d'interopérabilité ou d'approche BUS, gérant le transfert de données entre plusieurs systèmes
possibles de part et d'autre (n:n). Cela pourrait être le cas si, par exemple, vous vouliez collecter des
données au niveau des stocks par le biais de différentes applications du LMIS, puis les partager avec
un LMIS d'entrepôt central, le HMIS et un système de programmes verticaux de lutte contre les
maladies. Le logiciel de référence openHIE qui assume ce rôle est ["OpenHIM"] ([Link]
mais des systèmes tels que ["MOTECH"] ([Link] ont également été utilisés à cet
effet, comme nous le verrons plus bas.

Bien que cette approche puisse entraîner un effort initial plus important, elle promet de faciliter les
projets d'intégration ultérieurs, car la couche d'interopérabilité est alimentée par des définitions et des
mappings qui peuvent être réutilisés pour connecter les futurs systèmes.

49
Concepts d'intégration Architecture, normes et mapping

Dans la pratique, cette approche pose certains problèmes. L'activation des API nécessite un effort
considérable de la part de ressources qualifiées et, à chaque nouvelle version d'un système impliqué,
les flux de données doivent être testés à nouveau et, le cas échéant, adaptés. En outre, pour réussir,
ces projets de mise en œuvre doivent généralement passer par une série d'étapes complexes, telles
que l'accord sur une approche de l'interopérabilité intégrée dans la stratégie nationale de cybersanté,
la définition de normes de données et d'une structure de maintenance durable, et l'obtention d'un
consensus entre les parties prenantes sur la propriété des données et les politiques de partage.
L'interconnexion des données et des systèmes peut avoir des conséquences à long terme : elle crée
de nouveaux rôles, emplois et tâches qui n'existaient pas auparavant et qui n'avaient peut-être pas
été prévus (gouvernance des métadonnées, administration de systèmes complexes, négociateurs de
limites, etc.)

Exemple
Couche intermédiaire Grameen DHIS2/CommCare au Sénégal Dans les
notions d'intégration, MOTECH sert de couche intermédiaire technique
entre un système LMIS pour la collecte de données mobiles au niveau des
établissements de santé (CommCare) et DHIS2. On va ainsi l'utiliser pour
définir le mappage des données, les règles de transformation et les
contrôles de qualité des données. L'interface est configurée pour transférer
les données de CommCare Supply vers DHIS2 chaque fois que des
données sont enregistrées dans un formulaire CommCare dans les
établissements. Pour chaque produit de base, les données relatives à la
consommation, au stock disponible, aux pertes et aux ruptures de stock
sont transférées de CommCare vers DHIS2. La hausse de l'investissement
initial de l'approche sénégalaise laisse entrevoir une architecture système
plus ambitieuse à long terme, en prévision du fait que la plateforme
MOTECH peut être utilisée pour accueillir d'autres tâches d'interopérabilité
à l'avenir. Cependant, nous observons qu'aucune des activités nationales
n'est étroitement intégrée dans une architecture de cybersanté, ce qui
définirait clairement les domaines prioritaires, les systèmes principaux pour
chaque priorité, ainsi que les relations et les API qui en découlent entre ces
différents composants. On peut affirmer que les projets d'interopérabilité
reposent sur des bases fragiles en l'absence de consensus préalable sur
un plan directeur architectural. D'un autre côté, il est également utile de
permettre aux initiatives du système de se développer organiquement, tant
qu'elles sont ancrées dans des besoins nationaux bien fondés.

Architecture, normes et mapping

Un élément important d'une architecture de cybersanté est l'inclusion de normes internationales de

cybersanté. Les normes sont particulièrement importantes pour les connexions n:n, et le sont moins
pour les connexions directes (1:1).

Certaines normes se situent au niveau technique (par exemple, les méthodes de transmission),
d'autres au niveau du contenu (par exemple, les 100 indicateurs de base de l'OMS). L'alignement
progressif des initiatives des systèmes nationaux sur ces normes peut permettre aux pays d'accéder à
des solutions avérées, en bénéficiant de l'innovation médicale et technologique.

Exemple
PEV du Ghana Le cas du Ghana illustre comment les exigences de l'OMS
en matière d'établissement de rapports du PEV servent à définir des
données standard dans DHIS2. Cette normalisation au niveau des
ensembles de données et de la terminologie est la base de l'intégration du

50
Concepts d'intégration Données agrégées et transactionnelles

système. Concernant le système DHIS2, des travaux sont en cours avec

l'OMS pour développer des ensembles de données normalisés, qui
pourraient à l'avenir ouvrir de nouvelles possibilités d'interopérabilité et
améliorer l'efficacité en s'assurant que les métadonnées restent
relativement cohérentes entre les systèmes, et en encourageant également
les pays à réutiliser les solutions existantes.

Au niveau linguistique, il est nécessaire d'être cohérent dans les définitions. Si vous disposez de
deux sources de données pour les mêmes données, elles doivent être comparables. Par exemple, si
vous recueillez des données sur le paludisme auprès de cliniques standard et d'hôpitaux, ces
données doivent décrire la même chose si elles doivent être combinées pour les totaux et les
indicateurs. Si un hôpital rapporte les cas de paludisme par sexe mais pas par groupe d'âge, et que
d'autres cliniques les rapportent par groupe d'âge mais pas par sexe, ces données ne peuvent être
analysées en fonction de l'une ou l'autre de ces dimensions (même s'il est possible de calculer le
nombre total de cas). Il est donc nécessaire de se mettre d'accord sur des définitions uniformes.

Outre des définitions uniformes dans les différents sous-systèmes, des normes d'échange de
données doivent être adoptées si les données doivent être partagées par voie électronique. Les
différentes applications logicielles en ont besoin pour se comprendre. DHIS2 prend en charge
plusieurs formats de données lors de l'importation et de l'exportation, y compris la norme la plus
courante, ADX. D'autres applications logicielles prennent également en charge ce format, qui permet
le partage des définitions de données et des données agrégées entre elles. Pour DHIS2, cela signifie
qu'il prend en charge l'importation de données agrégées fournies par d'autres applications, telles que
[OpenMRS] ([Link] (pour la gestion des patients) et [iHRIS] ([Link] (pour
la gestion des ressources humaines).

Un élément crucial de l'architecture est la manière d'organiser le mapping des données.

Généralement, les métadonnées des différents systèmes ne correspondent pas exactement. À moins
qu'un ministère de la santé n'ait mis en œuvre une politique conséquente de normalisation des
données, différents systèmes auront des codes et des étiquettes différents pour un établissement. Un
système peut l'appeler Hôpital de district - 123, l'autre système peut l'appeler Centre de traitement du
paludisme - 15. Pour pouvoir transférer des données, il faut stocker à un endroit donné les
informations correspondant à ces deux établissements.

Dans le cas d'une connexion 1:1, cette correspondance doit être établie et maintenue pour chaque
connexion ; dans le cas d'une approche d'interopérabilité n:n, un côté des définitions peut être
réutilisé.

Afin de garantir la fluidité des données, vous devez définir clairement les responsabilités de part et
d'autre du système en ce qui concerne la maintenance des données et la résolution des problèmes.
Par exemple, des procédures standard doivent être définies au préalable pour des activités telles que
l'ajout, le changement de nom, la désactivation temporaire ou la suppression d'une installation dans
l'un ou l'autre des deux systèmes. Les modifications des champs de la base de données qui sont
inclus dans un enregistrement de données transféré doivent également être coordonnées de manière
systématique.

Données agrégées et transactionnelles

Le système DHIS2 a étendu sa portée à de nombreux systèmes de santé. Partant de ses bases
familières d'ensembles de données agrégées pour les données de routine, il a inclus des données
relatives aux patients, puis des données dans les domaines des RH, des finances, de la logistique et
de la gestion des laboratoires, pour évoluer vers des données opérationnelles ou transactionnelles.

Nous pouvons faire la différence entre les données transactionnelles et les données agrégées. Un
système transactionnel (ou système opérationnel du point de vue de l'entrepôt de données) est un
système qui collecte, stocke et modifie des données précises. Ce système est généralement utilisé au

51
Concepts d'intégration Données agrégées et transactionnelles

jour le jour pour la saisie et la validation des données. Le design est optimisé pour améliorer les
performances des insertions et des mises à jour. Le système DHIS2 peut incorporer des données
agrégées provenant de sources de données externes, normalement agrégées dans la dimension
spatiale (la hiérarchie des unités organisationnelles), la dimension temporelle (sur plusieurs périodes)
et pour les formules des indicateurs (expressions mathématiques comprenant des éléments de
données).

Lorsque nous envisageons un système transactionnel, tel qu'un logiciel de logistique pour l'ensemble
de la chaîne d'approvisionnement ou certaines de ses parties, nous devons prendre une décision
fondamentale : Avez-vous besoin de suivre toutes les transactions détaillées à tous les niveaux, y
compris les opérations telles que les retours, les transferts entre installations, la lecture des codes-
barres, la gestion des lots et des dates de péremption ? Ou bien pouvez-vous obtenir la plupart des
résultats nécessaires à la prise de décision en utilisant des données agrégées ?

Les chaînes d'approvisionnement peuvent souvent être bien contrôlées et, dans une certaine mesure,
gérées, pour autant que les données soient disponibles de manière fiable à l'endroit et au moment où
elles sont nécessaires pour les décisions opérationnelles et à des fins de contrôle. Les principaux
indicateurs entrée, consommation et niveau des stocks en fin de période peuvent être gérés sans
transactions électroniques et suffisent souvent à donner une vue d'ensemble des performances du
système, ce qui peut réduire les besoins d'investissement dans le système.

Il est important d'être réaliste quant aux données à collecter, à leur fréquence et qui les utilisera, afin
de ne pas créer des systèmes qui échouent en raison d'un manque d'utilisation ou d'attentes
irréalistes quant à la manière dont les données seront utilisées. Les systèmes numériques de gestion
de la logistique fonctionnent bien lorsqu'ils sont pleinement intégrés dans les flux de travail habituels
et qu'ils sont conçus pour faciliter le travail des utilisateurs ou le rendre plus efficace.

Remarque
L'attente selon laquelle des données plus détaillées conduisent à une
meilleure gestion logistique n'est pas toujours satisfaite. Parfois, la tentative
ambitieuse de collecter régulièrement des données sur les transactions
logistiques se traduit par une baisse de la qualité des données, par
exemple parce que l'enregistrement des données, qui devrait se faire sur
une base quotidienne plutôt que mensuelle ou trimestrielle, n'est pas
effectué de manière fiable. En revanche, si le système transactionnel est
bien entretenu et contrôlé, des données plus détaillées peuvent aider à
identifier les inexactitudes et les problèmes de qualité des données, à
réduire le gaspillage (dû à la péremption ou à la défaillance du CCE), à
soutenir un rappel, à gérer les performances et à améliorer la prise de
décision au sein de la chaîne d'approvisionnement. L'analyse de données
détaillées peut aider à découvrir les causes profondes de certains
problèmes et à améliorer la qualité des données à long terme.

Le DHIS2 peut jouer différents rôles dans les scénarios d'interopérabilité. Un scénario
d'interopérabilité courant consiste à ce que le DHIS2 reçoive des données agrégées d'un système
opérationnel, dans lequel le système opérationnel additionne les transactions avant de les transmettre
au DHIS2. Toutefois, le DHIS2 pourrait aussi, dans une certaine mesure, être configuré pour stocker
des données transactionnelles détaillées, qu'il reçoit de systèmes externes ou qui sont saisies
directement dans le DHIS2.

Sur cette base, nous tentons d'établir une vue d'ensemble comparative, en comparant la gestion des
données agrégées du DHIS2 avec la gestion des données d'un système spécialisé externe. Cela peut
servir d'orientation approximative, mais n'est pas statique puisque les capacités du DHIS2 et son
interprétation par les implémenteurs s'élargissent presque à chaque version.

52
Concepts d'intégration Données agrégées et transactionnelles

Zone DHIS2 agrégé Systèmes spécialisés externes

Logistique Des données agrégées, par La gestion de la chaîne

exemple les niveaux mensuels d'approvisionnement soutient les
des stocks des établissements, opérations du système logistique
peuvent être envoyées via le et peut suivre les mouvements de
DHIS2. Le système DHIS2 peut stocks en détail (émission,
produire des rapports simples sur réapprovisionnement, affectation,
les niveaux de stock ainsi que la gaspillage) et enregistrer des
consommation. informations telles que les
numéros de lot de production.
Les systèmes MSC créent des
rapports de prévision, de
réapprovisionnement et de
contrôle élaborés, rendant ainsi
possible le suivi en temps réel
des niveaux de stock, des
notifications (stock insuffisant,
gestion du flux de travail,
défaillance du matériel
frigorifique, etc.), des prévisions
étayées et des commandes
d'urgence.

Finances Des données agrégées, comme Les systèmes de gestion

par exemple les dépenses totales financière permettent une
ou le niveau des liquidités, traçabilité complète des
peuvent être envoyées via le transactions financières
DHIS2. Le système DHIS2 peut conformément aux exigences
produire des rapports simples de légales, notamment la
synthèse financière sur les budgétisation, les transferts, les
budgets restants par exemple. annulations, les remboursements,
etc. Le marquage
multidimensionnel des
transactions permet d'établir des
rapports analytiques.

Suivi des patients Les données relatives aux Les systèmes de gestion
maladies ou aux programmes hospitalière spécialisés peuvent
sont collectées via le DHIS2. Le couvrir et optimiser des flux de
DHIS2 Tracker permet également travail complexes entre différents
d'obtenir une vue longitudinale services (par exemple, réception,
simplifiée des dossiers médicaux, comptoir de paiement, salles,
y compris l'historique du patient services de consultations
et les cheminements cliniques externes, services
multi-étapes. d'hospitalisation, laboratoire,
imagerie, salle de stockage,
administration des finances et
des ressources humaines,
maintenance des dispositifs
médicaux, etc.)

53
Concepts d'intégration Différents scénarios d'intégration du DHIS2{ #different-dhis2-integration-scenarios }

Zone DHIS2 agrégé Systèmes spécialisés externes

Ressources humaines Le système DHIS2 collecte des Un système spécialisé de gestion

indicateurs liés aux ressources des ressources humaines peut
humaines, par exemple les assurer le suivi des informations
postes prévus et les postes détaillées sur le statut et les
vacants par établissement. mutations d'un agent de santé
(accréditation, promotion, congé
sabbatique, changement de
poste, changement de lieu,
formation complémentaire). Ce
système prévoit des rapports
prédéfinis permettant de
superviser et de planifier les
opérations.

Différents scénarios d'intégration du DHIS2{ #different-dhis2-integration-scenarios }

Les différents objectifs décrits ci-dessus conduisent à différents scénarios d'intégration. Le système
DHIS2 peut assumer plusieurs rôles dans une architecture de système:

• Saisie des données : saisie des données (hors ligne, mobile), importation des données
(données transactionnelles, données agrégées)

• Stockage, visualisation et analyse des données à l'aide d'outils intégrés (DWH, rapports, SIG)

• Partage des données avec des outils externes (comme DVDMT), via des API ou des
applications web

Dans les paragraphes suivants, nous examinons les approches de saisie et de partage des
données, puis nous présentons l'exemple de l'intégration verticale dans laquelle le DHIS2 joue
souvent tous ces rôles.

Le rôle du DHIS2 dans le stockage, la visualisation et l'analyse des données est abordé
séparément dans la section sur l'entrepôt de données.

Saisie des données

La manière dont le DHIS2 traite l'entrée des données comporte plusieurs aspects. Au niveau le plus
élémentaire, le DHIS2 sert à remplacer ou au moins à refléter les formulaires de collecte de données
sur support papier, en intégrant les données par voie électronique. Il en résultera des activités de
saisie manuelle des données au niveau de l'établissement ou de l'administration de la santé.
L'option suivante consiste à importer des données. Le DHIS2 permet d'importer des données par le
biais d'une interface utilisateur, ce qui est une méthode nécessitant peu de connaissances techniques,
mais qui doit être exécutée manuellement chaque fois que des données doivent être mises à
disposition. Une description détaillée des fonctions d'importation est disponible dans les [guides de
l'utilisateur DHIS2] ([Link]
dhis2_user_manual_en_full.html#import).

Conseil
La saisie manuelle des données et l'approche d'importation nécessitent
relativement peu d'efforts techniques. Elles peuvent également être
utilisées temporairement pour piloter une approche d'intégration de
données. Cela permet à l'utilisateur de tester des indicateurs et des
rapports, sans avoir à employer des ressources techniques dédiées au

54
Concepts d'intégration Partage de données{ #data-sharing }

développement de fonctions d'interopérabilité automatisées, que ce soit par

une connexion 1:1 ou n:n.

Partage de données{ #data-sharing }

Il existe trois scénarios de partage, (1) un simple exportation de données, (2) DHIS2 et (3) les
applications ou sites web externes qui se connectent à l'application DHIS Web API. Comme pour les
fonctions d'importation décrites dans la section sur la saisie des données, la manière la plus
accessible de partager les données est d'utiliser les fonctions d'exportation de données disponibles
dans le menu utilisateur, ce qui ne nécessite que peu de connaissances techniques.

Grâce à sa conception modulaire, le DHIS2 peut être complété par des modules logiciels
supplémentaires, qui peuvent être téléchargés à partir du DHIS2[App store] (https://
[Link]/appstore). Ces modules logiciels peuvent coexister avec les modules de base du
DHIS2 et être intégrés dans le portail et le système de menus du DHIS2. Il s'agit d'une caractéristique
importante, car elle permet d'étendre le système avec des fonctionnalités supplémentaires en cas de
besoin, généralement pour répondre aux exigences spécifiques d'un pays, comme cela a été souligné
précédemment.

L'inconvénient de l'extensibilité du module logiciel est qu'elle impose plusieurs contraintes au

processus de développement. Les développeurs qui créent les fonctionnalités supplémentaires sont
limités à la technologie DHIS2 en termes de langage de programmation et de cadres logiciels, en plus
des contraintes imposées à la conception des modules par la solution de portail DHIS2. En outre, ces
modules doivent être inclus dans le logiciel DHIS2 lorsque le logiciel est construit et déployé sur le
serveur web, et non de manière dynamique pendant l'exécution.

Afin de surmonter ces limitations et de parvenir à un couplage plus souple entre la couche de service
DHIS2 et les artefacts logiciels supplémentaires, l'équipe de développement du DHIS2 a décidé de
créer une API Web. Cette API Web est conforme aux règles du style architectural REST. Cela
suppose que :

• L'API Web fournit une interface navigable et lisible par machine pour le modèle de données
complet du DHIS2. Par exemple, on peut accéder à la liste complète des éléments de données,
puis naviguer à l'aide de l'hyperlien fourni vers un élément de données particulier qui nous
intéresse, puis naviguer à l'aide de l'hyperlien fourni vers la liste des formulaires dont cet
élément de données fait Par exemple, les clients n'effectueront des transitions d'état qu'en
utilisant les hyperliens qui sont intégrés dynamiquement dans les réponses.

• L'accès aux données s'effectue par le biais d'une interface uniforme (URL) utilisant un protocole
bien connu. Il n'y a pas de formats ou de protocoles de transport fantaisistes, mais simplement
le protocole HTTP, qui a été testé et qui est bien compris, et qui est le principal élément
constitutif du Web aujourd'hui. Cela signifie que les développeurs tiers peuvent mettre au point
des logiciels utilisant le modèle de données et les données DHIS2 sans connaître la
technologie spécifique de DHIS2 ou se conformer aux contraintes de conception de DHIS2.

• Toutes les données, y compris les métadonnées, les rapports, les cartes et les graphiques,
appelés ressources dans la terminologie REST, peuvent être récupérées dans la plupart des
formats de représentation populaires du web d'aujourd'hui, tels que HTML, XML, JSON, PDF et
PNG. Ces formats sont largement pris en charge par les applications et les langages de
programmation et offrent aux développeurs tiers un vaste champ d'options de mise en œuvre.

Cette API Web peut être accessible par différents systèmes d'informations externes. Les efforts
nécessaires pour développer de nouveaux systèmes d'informations et les maintenir à long terme sont
souvent largement sous-estimés. Au lieu de partir de zéro, une nouvelle application peut être
construite sur la base de l'API Web.

55
Concepts d'intégration Modèle de maturité du DHIS2

Les systèmes externes peuvent offrir différentes options de visualisation et de présentation des
données DHIS2, par exemple sous forme de tableaux de bord, de composants SIG et de composants
graphiques. Les portails Web destinés au domaine de la santé peuvent utiliser le système DHIS2
comme principale source de données agrégées. Le portail peut se connecter à l'API Web et
communiquer avec des ressources pertinentes telles que des cartes, des graphiques, des rapports,
des tableaux et des documents statiques. Ces vues de données peuvent visualiser dynamiquement
des données agrégées basées sur des requêtes sur la dimension unité organisationnelle, indicateur
ou période. Le portail peut apporter une valeur ajoutée à l'accessibilité des informations de plusieurs
manières. Il peut être structuré de manière conviviale et rendre les données accessibles aux
utilisateurs inexpérimentés. Le portail Web Tanzania HMIS en est un exemple.

Modèle de maturité du DHIS2

En tenant compte de tous les éléments ci-dessus sur l'architecture du système et les types de
données, les responsables de la mise en œuvre de DHIS2 peuvent aborder les mises en œuvre de
plusieurs manières :

• Se concentrer sur les données transactionnelles ou agrégées

• Se concentrer sur l'intégration des données ou l'interopérabilité des systèmes

Compte tenu des efforts requis pour mettre en œuvre l'interopérabilité des systèmes, de nombreux
ministères de la santé optent pour le raccourci pragmatique consistant à intégrer des données telles
que les données de base sur les stocks directement dans leur système DHIS2 national existant.
En tant que plateforme à évolution rapide, DHIS2 a ajouté de nombreuses fonctionnalités au cours
des dernières années, en particulier dans DHIS2 Tracker. Si l'on prend l'exemple des données
logistiques, les principales fonctions suivantes sont actuellement disponibles :

• Le formulaire de saisie des données reflète le formulaire papier largement utilisé pour les
rapports et les demandes (R\&R). La saisie des données par les établissements est possible
via un navigateur de bureau ou une application mobile, également en mode hors ligne. Ces
formulaires électroniques peuvent être remplis par le personnel sur la base des fiches de stock
papier, qui sont normalement placées à côté des produits dans la salle de stockage.

• DHIS2 peut ensuite produire des rapports pour le suivi des performances au niveau central,
permettant aux gestionnaires de produits et de programmes de comprendre le fonctionnement
du système logistique. Selon le mode de fonctionnement du système logistique, ces données
peuvent également soutenir la prise de décision opérationnelle, bien qu'une analyse plus
complète des processus opérationnels logistiques et des utilisateurs devrait d'abord être
effectuée.

• Les données relatives aux stocks peuvent être transformées en indicateurs logistiques, qui
peuvent être mis en contexte avec d'autres indicateurs du programme, par exemple en croisant
le nombre de patients traités pour une pathologie spécifique et la consommation de
médicaments correspondante.

Bien que chaque pays étudié dans les cas d'utilisation ait sa propre voie de développement vers
l'intégration des systèmes, certains enseignements communs peuvent être tirés de leurs expériences.
Le modèle de maturité ci-dessous décrit une approche évolutive pour faire face aux défis de
l'intégration et de l'interopérabilité, permettant aux différents acteurs d'un système de santé national
d'acquérir des habitudes professionnelles en matière d'analyse et d'utilisation des données.

56
Concepts Étapes de mise en œuvre pour une intégration réussie des données et des systèmes{
d'intégration #implementation-steps-for-successful-data-and-system-integration }
Le modèle de maturité suggère de passer des données agrégées aux données transactionnelles et
des systèmes autonomes aux systèmes interopérables (en utilisant l'exemple des données
logistiques).

1. Le DHIS2 est souvent l'un des premiers systèmes à couvrir l'administration de la santé et
plusieurs niveaux d'établissements d'un pays. Dans un premier temps, des indicateurs de base
sur les maladies sont couverts (correspondant par exemple aux 100 Indicateurs de Santé de
Base de l'OMS).

2. Dans une seconde phase, les différentes parties prenantes cherchent à compléter les données
relatives aux maladies et à la prestation de services qu'elles communiquent avec les données
de base du LMIS. Cela peut se faire sur une base agrégée dans le DHIS2, par exemple en
incluant les niveaux de stock et la consommation dans les rapports périodiques. Cela fournira
des informations de haut niveau sur la performance du système logistique, mais pourra ou non
fournir des informations suffisantes pour soutenir l'amélioration des opérations du système
logistique.

3. À un stade plus avancé, il peut y avoir un besoin légitime de systèmes logistiques spécialisés,
en particulier lorsqu'une vue transactionnelle très détaillée est souhaitée pour avoir un contrôle
plus granulaire (par exemple, les retours, les transferts entre installations, les numéros de lots
et les dates d'expiration, etc.). DHIS2 Tracker peut offrir certaines fonctions de gestion des
données relatives aux événements ou aux patients, mais ne peut pas toujours atteindre le
degré de soutien au flux de travail fourni par d'autres solutions plus spécialisées.

4. Dans un environnement technologique et managérial mature, les transactions logistiques

peuvent être partagées avec le DHIS2 sous une forme agrégée, passant ainsi d'un scénario
autonome à un scénario intégré.

Étapes de mise en œuvre pour une intégration réussie des données et des systèmes{
#implementation-steps-for-successful-data-and-system-integration }

L'objectif de ce guide de mise en œuvre du DHIS2, étape par étape, est de fournir aux implémenteurs
une méthodologie pour créer et soutenir un scénario d'intégration du DHIS2. Le guide est basé sur les
meilleures pratiques et les leçons apprises. Il préconise une approche itérative, agile et axée sur le
pays, qui commence par la collecte de témoignages d'utilisateurs et d'exigences fonctionnelles. Le
guide est conçu comme un cadre qui peut être adapté au contexte spécifique de chaque pays. Le
contenu décrit des exemples spécifiques pour chaque étape, détaillant les témoignages des
utilisateurs, les spécifications des données, les outils de travail et les listes de contrôle pour guider
l'utilisation du logiciel de mise en œuvre de référence. La structure de base, y compris les 6 étapes,
est basée sur la [méthodologie de mise en œuvre de l'OpenHIE] ([Link]
documents/OpenHIE+Planning+and+Implementation+Guides) :

Étape 1 : Identifier les partenaires et les facteurs de motivation pour l'amélioration des données des
établissements

Étape 2 : Documenter les spécifications du registre des établissements et les témoignages des
utilisateurs

Étape 3 : Configurer l'instance initiale

Étape 4 : Identifier les lacunes et le développement itératif via les tests utilisateurs

Étape 5 : Étendre la mise en œuvre du registre

Étape 6 : Apporter un soutien continu

Outre ces étapes liées à l'interopérabilité, il convient également de se reporter à certaines expériences
générales en matière de mise en œuvre du système DHIS2 et aux meilleures pratiques présentées

57
 Étape 1 : Définition de la stratégie, des parties prenantes et des objectifs en matière
Concepts
d'utilisation des données{ #step-1-define-strategy-stakeholders-and-data-usage-
d'intégration
objectives }
dans les sections concernées dans les documents Recommandations pour la mise en œuvre d'une
solution HIS au niveau national et Configuration d'une nouvelle base de données. également vitale
pour les projets d'interopérabilité, l'approche participative est couramment utilisée pour mettre en
œuvre un système DHIS2. Cette approche met l'accent sur l'inclusion, dès le début du projet, d'une
équipe locale ayant des compétences et des antécédents différents, afin que ses membres puissent
entrer en fonction dès que possible.

Étape 1 : Définition de la stratégie, des parties prenantes et des objectifs en matière d'utilisation des
données{ #step-1-define-strategy-stakeholders-and-data-usage-objectives }

Dans un premier temps, les objectifs du projet d'intégration seront définis. Comme pour tout projet
technologique, il doit y avoir un consensus clair sur les objectifs stratégiques et fonctionnels.
L'innovation technologique et la faisabilité ne doivent pas être les seules forces motrices, mais plutôt
un objectif organisationnel clairement défini. C'est pourquoi cette étape vise également à répondre à
la question suivante : "Pourquoi voulons-nous connecter des systèmes ou intégrer des données
provenant de différentes sources avec DHIS2 ?"

D'un point de vue pratique, cela conduit à des questions sur l'approche de l'intégration des données.
telles que :

• Souhaitez-vous éliminer les formulaires papier ou même les ensembles de données

redondants ou inutiles ?

• Pouvez-vous intégrer les données (agrégées) dans le système DHIS2 ?

• Pouvez-vous intégrer les données détaillées (par exemple au niveau du patient ou au niveau
transactionnel) dans DHIS2, en utilisant les fonctions de suivi de DHIS2 ?

• Si vous souhaitez créer une connexion d'échange de données entre DHIS2 et un autre
système, comment définissez-vous la propriété et les responsabilités ?

Les activités visant à répondre à cette question sont décrites ci-dessous et poseront les bases d'un
projet d'interopérabilité du DHIS2.

Identification des parties prenantes et de leurs motivations{ #identify-stakeholders-and-motivations }

La nature des projets d'interopérabilité veut qu'il y ait plus d'une partie prenante. Les parties prenantes
de différents domaines doivent se mettre d'accord sur une approche commune du système, par
exemple l'équipe responsable du HMIS national (par exemple le département S&E ou le département
de la planification) et le département de la logistique dans le cas de la mise en œuvre d'un LMIS
(système de gestion et d'information logistiques). Ces deux domaines principaux ont souvent des
sous-divisions, par exemple, dans le domaine de la logistique, l'unité d'approvisionnement, l'unité
d'entreposage, l'unité de transport. En outre, les parties prenantes des programmes spécifiques aux
maladies auront leurs propres régimes et gestionnaires de produits. Outre ces acteurs locaux, les
partenaires internationaux (agences, donateurs, ONG internationales, cabinets de conseil) sont
souvent impliqués dans le processus de prise de décision.

Il est donc judicieux de se pencher sur les principales motivations des parties prenantes et sur la
manière d'atténuer les risques résultant d'intérêts potentiellement divergents.

• Les départements centraux du ministère de la santé, tels que **M\&E&**Planning, sont souvent
les principaux acteurs de la normalisation des indicateurs et des systèmes informatiques

• Les services informatiques centraux s'intéressent de manière générale aux choix et à la

propriété des technologies (souvent contrôlés au niveau local), ainsi qu'à l'achat de matériel et
de logiciels. Ils s'occupent souvent des questions de réseau et de matériel, mais manquent
d'expérience en ce qui concerne les architectures et les échanges de données complexes
basés sur le web.

58
 Étape 1 : Définition de la stratégie, des parties prenantes et des objectifs en matière
Concepts
d'utilisation des données{ #step-1-define-strategy-stakeholders-and-data-usage-
d'intégration
objectives }
Les programmes de lutte contre les maladies spécialisées sont souvent soumis à des
• pressions pour obtenir des indicateurs très spécifiques, à la fois pour leur propre gestion et
pour répondre aux approches des donateurs. Ils peuvent également se sentir plus à l'aise pour
contrôler leur propre système informatique afin de s'assurer que leurs besoins sont prioritaires.

• Les domaines fonctionnels spécialisés (tels que les ressources humaines, la logistique, la
gestion des hôpitaux) sont souvent dans une position en sandwich, devant répondre aux
besoins d'information de plusieurs parties prenantes différentes, tout en essayant d'atteindre
l'efficacité opérationnelle avec des ressources limitées.

En identifiant les personnes intéressées par la fourniture ou l'utilisation des données, les responsables
de la mise en œuvre peuvent commencer à former une équipe de projet pour orienter les travaux de
conception et de mise en œuvre. Une méthode pour caractériser les parties prenantes consiste à
regrouper les parties intéressées selon leurs rôles fonctionnels. L'infrastructure et les procédures
existantes sont également importantes pour comprendre les options de gouvernance et de
conservation. Comprendre les parties prenantes et leurs systèmes correspondants est une première
étape cruciale.

Inventaire du système de cybersanté{ #ehealth-system-inventory }

Il est important d'avoir une vision claire du contexte global des systèmes informatiques. Cela permet
de s'assurer que les investissements dans l'interopérabilité sont réalisés pour renforcer les principaux
systèmes et qu'ils contribuent à une simplification de l'architecture du système. Par exemple, si
l'inventaire des systèmes montre qu'il y a beaucoup de systèmes fonctionnels redondants, par
exemple plus de 10 systèmes ou modules logistiques différents dans un pays, le projet
d'interopérabilité devrait essayer de contribuer à une rationalisation à moyen ou long terme de cette
situation. Il pourrait s'agir de participer à un processus national de recherche de consensus afin
d'identifier les solutions les plus sûres pour l'avenir, de désigner des "champions" nationaux pour
chaque spécialité et d'élaborer une feuille de route pour l'alignement de ces systèmes ou données et
la suppression des systèmes sous-utilisés ou redondants.

Dans ce contexte, il est également intéressant d'analyser si des indicateurs simples peuvent être
collectés et gérés dans le DHIS2 lui-même et comment cela peut compléter les efforts d'amélioration
du système logistique (comme cela est expliqué plus loin dans un exemple de SIMT). Une fois que les
systèmes stables et durables ont été identifiés, la planification d'un échange de données avec le
DHIS2 peut commencer.

Exploration des opportunités et des défis

Les motivations qui président à la mise en œuvre peuvent être détaillées en fonction des opportunités
ou des défis perçus par les parties prenantes. Il peut s'agir du désir de partager des données entre les
systèmes liés aux établissements de santé pour la gestion de la chaîne d'approvisionnement, le suivi
et l'évaluation, la prestation de services de santé et bien d'autres systèmes. Les témoignages des
utilisateurs et les cas d'utilisation seront documentés en profondeur au cours de l'étape 2, mais il est
également nécessaire d'avoir une vision de haut niveau des motivations qui poussent à s'engager
avec les partenaires.

Organisation et RH

Des politiques nationales claires sur l'intégration des données, la propriété des données, les routines
de collecte, de traitement et de partage des données doivent être mises en place dès le début du
projet. L'intégration perturbe souvent le flux normal des données pendant un certain temps, ce qui fait
que, pour beaucoup, les perspectives à long terme d'un système plus efficace doivent être évaluées à
leur juste valeur par rapport à la perturbation à court terme. L'intégration est donc souvent un
processus par étapes, où des mesures doivent être prises afin qu'elle se déroule le plus
harmonieusement possible.

59
Concepts Étape 2 : Documenter les spécifications et les exigences{ #step-2-document-
d'intégration specifications-and-requirements }

Exemple
CHIM du Ghana

• Coopération des parties prenantes : Le Centre de gestion de

l'information sur la santé (Centre for Health Information Management
ou CHIM) du Ghana a une position claire à l'égard des programmes
verticaux et d'autres partenaires dotés d'initiatives logicielles
appropriées. Pour le CHIM, le système DHIS2 constitue une option de
collecte de données attrayante, qui aide les autres parties prenantes
du GHS à se connecter à DHIS2 et à travailler sur une stratégie
d'interopérabilité commune, faisant ainsi évoluer le système DHIS2 en
fonction des besoins des parties prenantes. Cela inclut également
les accords d'échange de données.
• Sentiment fort d'appropriation du système : Le CHIM est fortement
déterminé à développer le savoir-faire nécessaire au sein de l'équipe
du CHIM pour configurer et entretenir le système. L'équipe du CHIM
est composée d'agents d'informations sanitaires, ayant des
compétences en santé publique et en gestion des données.

De même, le fait de disposer de procédures de maintenance et de mise à jour du système

clairement définies peut certainement aider à gérer l'interopérabilité.

Exemple
CHIM du Ghana À titre d'exemple, dans le cas du système DHIS2 au
Ghana, un cycle annuel clair de mise à jour du système est en place : Vers
la fin de chaque année, de nouveaux indicateurs sont créés et les
formulaires papier correspondants sont émis. Le personnel reçoit une
formation et se prépare à saisir des données. Le nouveau formulaire pour
les données du PEV a été inclus dans ce cycle de mise à jour et le
personnel du PEV est prêt à saisir les données dans le cadre de ce
processus. Cette procédure systématique permet au GHS de répondre
rapidement aux besoins des parties prenantes telles que le programme
PEV et de satisfaire leurs besoins en matière de données et de rapports
avec un investissement limité et prévisible. Elle met le CHIM en position de
contribuer à la rationalisation et à la simplification de l'architecture du
système de santé national, en intégrant progressivement la gestion des
données pour des programmes plus verticaux, tant du côté de la saisie
que de l'analyse des données.

Un principe clé de HISP est d'impliquer l'équipe locale dans la construction du système dès le début,
avec l'aide d'experts externes si nécessaire, et de ne pas retarder le transfert de connaissances vers
la fin de la mise en œuvre. L'appropriation passe avant tout par la construction du système et la
maîtrise de chaque étape du processus.

Étape 2 : Documenter les spécifications et les exigences{ #step-2-document-specifications-and-

requirements }

• Collecter les métadonnées existantes

• Documenter les spécifications des données

• Recueillir les témoignages des utilisateurs

60
Concepts d'intégration Étape 3 : Mener à bien les spécifications et identifier les lacunes

Étape 3 : Mener à bien les spécifications et identifier les lacunes

• Mettre en œuvre les spécifications

• Identifier et prioriser les témoignages des utilisateurs incomplets

Étape 4 : Itération et Test de l'Utilisateur{ #step-4-iteration-and-user-testing }

• Développement agile et itératif

• Test utilisateur

• Collecter, rapprocher et télécharger les données

Étape 5 : Mise à l'échelle

• Confirmer les rôles et responsabilités des utilisateurs

• Former les utilisateurs

• Intégrations critiques

Étape 6 : Soutien continu{ #title_nxr_lxp_41b }

Si, pendant la phase de mise en œuvre, une structure de soutien temporaire doit être disponible, une
structure de soutien permanente doit être mise en place par la suite. Le principal défi consiste à définir
clairement les responsabilités. Dans une situation idéale, nous avons affaire à deux systèmes stables
qui ont déjà chacun leur propre structure de soutien clairement définie.

Cependant, dans la réalité, certains défis récurrents doivent être relevés: de nombreux systèmes de
santé publique connaissent des évolutions dynamiques, entraînant des changements dans les
besoins de collecte de données ou le calcul des indicateurs.

L'interopérabilité tend à être une charge technique et organisationnelle fastidieuse. Les trois initiatives
décrites ont consommé un effort considérable de ressources qualifiées pour activer les API. En outre,
à chaque nouvelle version d'un système impliqué, les flux de données doivent être testés à nouveau
et, si nécessaire, adaptés. Pour réussir, ces projets de mise en œuvre doivent généralement passer
par une série d'étapes complexes, telles que l'accord sur une approche de l'interopérabilité intégrée
dans la stratégie nationale de cybersanté, la définition de normes de données et d'une structure de
maintenance durable, et l'obtention d'un consensus entre les parties prenantes sur la propriété des
données et les politiques de partage. L'interconnexion des données et des systèmes peut avoir des
conséquences à long terme: elle crée de nouveaux rôles, tâches et catégories de travail qu'il
convient de prévoir (gouvernance des métadonnées, administration de systèmes complexes,
négociateurs de frontières, etc.) Une solution pourrait consister à discuter au préalable des nouvelles
responsabilités, en les attribuant à des descriptions de poste, à des équipes et à des postes
spécifiques.

Responsabilité des métadonnées

Un autre domaine important est celui de la gouvernance des métadonnées, en particulier dans les
scénarios d'utilisation secondaire des données. Dans une configuration autonome, les métadonnées,
telles que les codes d'installation ou de produit, peuvent être gérées sans grande considération pour
les besoins des autres parties prenantes. Mais dans un environnement d'interopérabilité, les
changements de métadonnées auront des effets en dehors du système individuel. La gouvernance
des métadonnées peut être très formalisée grâce à des registres ou plus manuelle grâce à des
processus humains.

Afin de déterminer l'approche appropriée, il est utile d'estimer l'effort de maintenance des
métadonnées prévu et les conséquences de métadonnées non synchronisées entre différents

61
Concepts Cas d'utilisation spécifiques d'intégration et d'interopérabilité{ #specific-integration-and-
d'intégration interoperability-use-cases }
systèmes. Dans le cas des intégrations LMIS/DHIS2, il existe potentiellement des milliers d'identifiants
d'installations qui pourraient être désynchronisés. Cependant, les identifiants des établissements ne
changent normalement pas souvent, car l'infrastructure physique de la plupart des systèmes de santé
publique est relativement constante. En ce qui concerne les produits, bien que les régimes et les
médicaments prioritaires puissent changer au fil du temps, le nombre d'ensembles de données est
relativement restreint : la liste des produits d'un programme contient souvent moins de 20 produits.
Par conséquent, il peut être souvent pratique de mettre à jour un produit manuellement et de ne pas
investir dans des solutions d'interopérabilité telles qu'une synchronisation automatisée des
métadonnées.

Cas d'utilisation spécifiques d'intégration et d'interopérabilité{ #specific-integration-

and-interoperability-use-cases }

DHIS2 a étendu son champ d'action à de nombreux systèmes de santé. Partant de la base familière
des ensembles de données agrégées pour les données de routine, il a inclus des données relatives
aux patients, puis des données dans les domaines des ressources humaines, des finances, de la
logistique et de la gestion des laboratoires. Cette évolution est conforme au développement du DHIS2
dans de nombreux pays, où les implémenteurs poussent l'utilisation au-delà de son champ
d'application initial.

Cela se reflète également dans l'architecture globale du système. Étant donné que l'extension des
fonctionnalités du DHIS2 réduit l'urgence d'introduire ou de maintenir d'autres systèmes spécialisés, le
nombre d'interfaces de données potentielles diminue. Cette réduction de la complexité de
l'architecture du système est certainement un avantage pour un Système de Santé dont les
ressources sont limitées.

Depuis plusieurs années, DHIS2 a développé ses activités de gestion de données de manière
organique, permettant à l'utilisation effective de déboucher sur des solutions parfois imprévues.
Cependant, il y a aussi des limites aux domaines dans lesquels l'utilisation de DHIS2 semble utile.
Dans les sections suivantes, des systèmes spéciaux seront décrits.

Gestion de la logistique

a) Introduction

Les systèmes de gestion logistique (LMIS) ou les systèmes de gestion de la chaîne

d'approvisionnement (SCM) servent à remplacer les systèmes sur support papier afin d'accroître la
normalisation, la transparence, la rapidité de l'approvisionnement, l'efficacité, la sécurité, la rentabilité
et de réduire les déchets. Les SCMS/LMIS nationaux peuvent couvrir des fonctions telles que la
planification des produits, la budgétisation, l'approvisionnement, le stockage, la distribution et le
réapprovisionnement des médicaments essentiels et des consommables.

b) Mise en œuvre du LMIS dans le système DHIS2

Les chaînes d'approvisionnement peuvent souvent être bien contrôlées à l'aide de données agrégées
uniquement, à condition que les données soient fournies de manière fiable par tous les niveaux
concernés et qu'elles fassent l'objet d'un suivi. Les principaux indicateurs que sont l'apport, la
consommation et le niveau des stocks en fin de période peuvent être gérés sans transactions
électroniques et suffisent souvent à donner une vue d'ensemble, ce qui réduit les besoins
d'investissement dans le système. En tant que plateforme évoluant très rapidement, DHIS2 a ajouté
de nombreuses fonctionnalités au cours des dernières années, en particulier dans DHIS2 Tracker. Les
principales fonctions suivantes sont actuellement disponibles :

• Le formulaire de saisie des données reflète le formulaire papier largement utilisé pour les
rapports et les demandes (R\&R). La saisie des données par les établissements est possible
via le navigateur de bureau ou une application mobile, y compris en mode hors ligne. En mode
en ligne, le formulaire peut calculer les propositions de réquisition, offrant au gestionnaire de

62
Concepts d'intégration Gestion de la logistique

l'établissement la possibilité de modifier la demande et de la commenter. Ces formulaires

électroniques peuvent être remplis par le personnel sur la base des fiches de stock papier, qui
sont normalement placées à côté des produits dans la salle de stockage.

• DHIS2 peut alors produire des rapports pour la prise de décision centrale, donnant aux
gestionnaires de produits et de programmes la possibilité d'accepter ou de modifier les
suggestions de livraison.

• Les données relatives aux stocks peuvent être transformées en indicateurs logistiques, qui
peuvent être mis en contexte avec d'autres indicateurs du programme, par exemple en croisant
le nombre de patients traités pour une pathologie spécifique et la consommation de
médicaments correspondante.

c) Options d'interopérabilité

Le LMIS est un domaine où une multitude de solutions logicielles parallèles, qui se chevauchent ou
qui se font concurrence, peuvent être trouvées dans un seul pays. Comme l'a montré une étude JSI
réalisée en 2012 ( Ministère de la santé du Ghana, juillet 2013 : Analyse du panorama des outils de
gestion de la chaîne d'approvisionnement utilisés), dix-huit (18!) outils logiciels différents ont été
documentés comme étant utilisés dans la chaîne d'approvisionnement de la santé publique
uniquement au Ghana.

Bien qu'une configuration de base du LMIS basée sur des données agrégées puisse vous mener très
loin, dans certains cas, un LMIS transactionnel est nécessaire si vous devez suivre des opérations
aussi détaillées que les retours, les transferts entre établissements, la lecture des codes-barres, la
gestion des lots et des dates d'expiration. De même, certaines fonctions spécialisées du siège, telles
que la création de rapports de prévision, de réapprovisionnement et de contrôle élaborés, sont
souvent réalisées à l'aide d'outils spécialisés.

Le DHIS2 a intégré des données agrégées provenant de systèmes externes tels que openLMIS et
CommCare par le biais d'interfaces de données automatisées. En conséquence, les données sur les
stocks sont disponibles dans des tableaux de bord partagés, qui affichent les services de santé et
stock les données les unes à côté des autres.

63
Principes de qualité des données Mesure de la qualité des données

Principes de qualité des données

L'approche de DHIS2 en matière de qualité des données est conforme aux [lignes directrices de
l'OMS sur l'Assurance Qualité des Données (AQD)] ([Link]
health-service-data/data-quality-assurance-dqa). Pour obtenir de meilleurs résultats lors de la mise en
œuvre des fonctions de qualité des données de DHIS2, il est recommandé de consulter ces lignes
directrices en référence à la présente boîte à outils. Les lignes directrices de l'AQD définissent
plusieurs fréquences pour l'examen des données :

Contrôle de routine

Ces contrôles doivent être réguliers (hebdomadaires, mensuels, etc. en fonction de la fréquence de la
collecte des données) et s'inscrire dans le cadre du HMIS ou d'autres systèmes d'établissement de
rapports dans le cadre d'un cycle de retour d'information qui identifie les erreurs en temps quasi réel
afin qu'elles puissent être corrigées dès qu'elles se produisent. Ce contrôle de routine des données
peut être plus holistique, transversal ou spécifique à un programme, et peut être effectué par différents
utilisateurs de données (par exemple, les responsables du HMIS, les responsables de programmes,
etc.)

Évaluations discrètes

Ces évaluations sont nécessaires pour examiner la qualité des données des établissements de santé
utilisées à la fois pour jauger la performance du secteur de la santé et à des fins de politique et de
planification. Ces évaluations doivent être réalisées avant un cycle de planification, par exemple avant
un examen annuel du secteur de la santé (la périodicité est propre à chaque pays, mais elle est
probablement plus comparable à un cycle annuel).

Contrôle périodique

Ils doivent être axés sur une seule maladie ou un seul domaine de programme et doivent être
programmés de manière à répondre aux besoins de planification du programme spécifique (par
exemple, avant les évaluations de programme).

DHIS2 est en mesure de prendre en charge ces différentes fréquences de contrôle de qualité des
données. Cette boîte à outils est axée sur les mesures impliquées dans le contrôle de routine de
qualité des données, car les observations générales indiquent qu'il peut être difficile de les mettre en
œuvre dans la pratique. Ces pratiques de routine peuvent être développées et utilisées à des fins de
contrôle discret et périodique, selon les besoins.

Mesure de la qualité des données

Lors d'un contrôle classique de la qualité des données, 4 mesures de la qualité des données sont
généralement évaluées :

1. Complétude et respect des délais

2. Cohérence interne
3. Cohérence externe
4. Cohérence des données du dénominateur

Complétude et Ponctualité{ #completeness-and-timeliness }

L'exhaustivité est évaluée soit en examinant les taux de déclaration pour l'ensemble d'un formulaire
de déclaration/d'un ensemble de données, soit en examinant l'exhaustivité d'éléments de données
spécifiques dans les formulaires de déclaration lorsqu'une précision supplémentaire est requise.

Exhaustivité de l'ensemble des données - taux de déclaration

64
Principes de qualité des données Cohérence interne

Dans DHIS2, le taux d'exhaustivité des rapports = Rapports reçus/rapports attendus x 100 %.

• Rapports reçus : le nombre d'ensembles de données pour une période et une unité
d'organisation données qui ont été marqués comme terminés par l'employé chargé de la saisie
des données, en utilisant le bouton "terminé" dans l'application de saisie des données

• Rapports attendus : le nombre d'unités d'organisation auxquelles un ensemble de données est

assigné sur la base de la période de rapport sur laquelle l'ensemble de données doit être
rapporté. Pour un ensemble de données mensuel attribué à 100 établissements, nous
attendons 100 rapports par mois.

Actualité de l'ensemble des données

Délais d'établissement des rapports : Rapports reçus à temps/rapports attendus x 100%

• Rapports reçus à temps : nombre d'ensembles de données pour une période et une unité
d'organisation données qui ont été marqués comme terminés dans un délai spécifié pour cet
ensemble de données particulier.

La notion de "ponctualité" dépend de la configuration d'un pays ou d'une organisation et repose

souvent sur des procédures définies localement. Par exemple, dans un formulaire de déclaration
mensuelle, le délai peut être défini comme étant de 15 jours après la fin du mois de déclaration
précédent. Dans ce cas, la soumission des données au 15 juin pour les données de mai serait
considérée comme ponctuelle.

Exhaustivité des éléments de données

L'objectif d'un taux de déclaration d'un élément de données est d'évaluer la cohérence de la
déclaration d'une variable unique. Ceci ne s'applique qu'aux éléments de données agrégés.

Exhaustivité de l'élément de données = Nombre de valeurs reçues / Nombre de valeurs attendues x

100%.

Cette section de la boîte à outils décrit plus en détail les mesures d'exhaustivité et d'actualité dans
DHIS2.

Cohérence interne

La cohérence interne vise à comparer les sources de données internes afin de déterminer s'il existe
des variations significatives basées sur des règles statistiques ou des comparaisons logiques. Dans
DHIS2, nous pouvons soutenir le contrôle de la cohérence interne par le biais de plusieurs mesures,
notamment :

• Cohérence entre les variables connexes

• Cohérence dans le temps
• Analyse des valeurs atypiques
• Grâce à l'utilisation de règles de validation
• Analyse min-max

Cohérence externe

La cohérence externe a pour but de comparer vos données avec des données provenant d'autres
sources. Par exemple, vous pouvez comparer les données d'un système d'information sanitaire de
routine avec des données collectées dans le cadre d'une enquête. Si ces données externes sont
importées dans DHIS2, plusieurs mesures comparatives peuvent être utilisées pour examiner la
cohérence externe via le visualiseur de données, l'application de qualité des données de l'OMS et
l'utilisation de règles de validation.

65
Principes de qualité des données Cohérence des données du dénominateur

Cohérence des données du dénominateur

Cette mesure permet d'examiner les dénominateurs utilisés pour calculer la couverture. Cela peut
impliquer des aspects de cohérence interne et externe. Par exemple, la comparaison des estimations
démographiques issues du recensement, telles que l'estimation du nombre de femmes enceintes,
l'estimation du nombre de naissances vivantes et l'estimation de la population âgée d'1 an, serait une
comparaison interne, tandis que la comparaison de ces mesures de recensement avec les
estimations démographiques de l'ONU serait un exemple de cohérence externe.

66
Saisie des données agrégées Conception de la saisie des données

Saisie des données agrégées

Dans la mesure du possible, les problèmes de qualité des données doivent être détectés et traités le
plus tôt possible. Au moment où les données sont saisies dans DHIS2, elles ont souvent été
enregistrées d'abord sur des cartes ou des registres de patients, puis comptées manuellement sur des
feuilles de pointage, avant d'être agrégées en valeurs hebdomadaires, mensuelles ou trimestrielles et
consignées dans des formulaires de rapport agrégés de l'établissement. Enfin, les données de ces
formulaires agrégés sont saisies dans DHIS2. La conception et la qualité de ces différents outils, ainsi
que la formation dispensée au personnel et le temps qui lui est alloué pour effectuer correctement ces
activités de collecte de données, sont essentiels pour assurer la qualité des données.

Conception de la saisie des données

La conception des formulaires de collecte de données est un élément souvent négligé pour assurer la
qualité des données. La conception d'outils et de formulaires de collecte de données sur papier est
au-delà du champ d'application du présent document, mais des formulaires sur papier bien conçus et
faciles à remplir par le personnel chargé de la collecte des données constituent un facteur important
pour l'amélioration de la qualité des données. Les formulaires extrêmement complexes peuvent être
difficiles à remplir sur papier, ce qui peut entraîner des erreurs de transcription sur le formulaire papier
original. Ces erreurs peuvent ensuite se propager au format numérique (c.-à-d. DHIS2) lors de la
saisie électronique des données.

Dans DHIS2, les [formulaires de saisie] ([Link]

master/configuring-the-system/[Link]#manage_data_set) peuvent être générés
automatiquement (formulaires par défaut ou formulaires de section) ou être personnalisés (formulaires
personnalisés). À l'aide de HTML et de JavaScript, les implémenteurs du DHIS2 peuvent créer des
formulaires personnalisés complexes qui peuvent imiter de très près la mise en page et la conception
d'un formulaire papier. Les formulaires dits de section sont générés automatiquement par DHIS2 et
sont composés de sections de données qui partagent un même type de désagrégation. Les
formulaires de section sont généralement plus faciles à gérer et fonctionnent bien sur les appareils
mobiles tels qu'Android. Les formulaires de section devraient être l'option préférée lorsque c'est
possible. Cependant, les formulaires de section peuvent ne pas correspondre à la conception des
formulaires papier, ce qui peut compliquer le processus de saisie des données, entraînant ainsi une
plus grande probabilité d'erreurs au cours du processus de transcription.

Les formulaires personnalisés sont parfois nécessaires pour pouvoir créer un formulaire de saisie de
données qui facilite le passage du papier au numérique ; toutefois, les formulaires personnalisés sont
sensibles aux modifications des métadonnées sous-jacentes (par exemple, les éléments de données
et les dimensions des catégories). Cela peut conduire à la saisie de données dans une combinaison
incorrecte d'éléments de données et d'options de catégories sans que l'utilisateur s'en aperçoive. Les
formulaires personnalisés compliqués peuvent également nécessiter un travail supplémentaire pour
que la "tabulation" entre les cellules fonctionne correctement, ce qui est important pour une saisie de
données efficace et sans erreurs.

En général, les formulaires de saisie de données trop volumineux (tels que les tableaux de + 100
lignes x + 10 colonnes, ce qui n'est pas rare pour l'enregistrement des données de morbidité)
présentent le risque que l'utilisateur ne sache plus dans quelle ligne/colonne (par exemple, maladie et
ventilation par âge/sexe) les données sont saisies.

Bien que nous ne couvrions pas ici tous les aspects de la création de formulaires de saisie de
données, il convient de prendre en compte certains de ces éléments dans votre conception avant de
configurer tout ensemble de données dans DHIS2, car cela peut contribuer à réduire certains
problèmes potentiels de qualité des données avant qu'ils ne se posent.

• Quels sont les éléments de données présents dans le formulaire ?

• Quelle est la période de collecte du formulaire ?

67
Saisie des données agrégées Règles de validation

• Les éléments de données doivent-ils faire l'objet d'une désagrégation ?

• Quelles sont les unités d'organisation qui doivent régulièrement établir des rapports sur le
formulaire ?
• Y a-t-il des éléments qui peuvent être automatiques - par exemple des indicateurs ou des
totaux calculés ?
• Y a-t-il des éléments que nous devrions collecter par d'autres moyens (données
démographiques, totaux cumulés, etc.)
• Concevez vos dimensions en gardant à l'esprit l'utilisation des données, et non leur collecte.
◦ Cela signifie que la désagrégation des valeurs des données au moment de la collecte
doit pouvoir être facilement agrégée selon les différentes dimensions, c'est-à-dire qu'elle
doit permettre d'obtenir un total cohérent.
• Réutiliser les dimensions autant que possible car cela augmente la capacité à comparer les
données désagrégées (par exemple, les groupes d'âge, les services fixes/de proximité, le sexe,
etc.)

Il est également essentiel que les éléments de données soient configurés avec les types de valeurs
appropriés, afin que seuls les bons types de valeurs de données soient enregistrés. Par exemple, il
faut s'assurer que les éléments de données utilisés pour saisir l'utilisation de la prestation de services,
les cas/décès, le nombre de tests, etc. sont configurés comme des zéros ou des nombres entiers
positifs, afin d'éviter les nombres négatifs ou les décimales.

Règles de validation

Les [règles de validation] ([Link]

configuring-the-system/[Link]#about_validation_rule) sont un élément essentiel pour garantir
que les valeurs des données individuelles qui sont liées suivent des modèles définis. À titre
d'exemple, il n'est pas possible d'avoir plus de personnes testées positives au paludisme que de
personnes qui ont été testées pour le paludisme. De même, s'il y a des personnes dont le test est
positif pour le paludisme, il doit y avoir au moins autant de personnes qui ont été testées.

Dans DHIS2, les règles de validation se composent de deux valeurs (un côté gauche et un côté droit)
qui sont comparées à l'aide d'un opérateur mathématique (moins que, plus que, etc.) pour produire un
résultat logique vrai ou faux. Les règles de validation comparent des valeurs qui se trouvent dans
DHIS2, au niveau de la saisie et de la périodicité définis par la règle de validation. Si l'on reprend les
exemples ci-dessus, une règle de validation dans DHIS2 peut ressembler à ce qui suit :

Si ces données sont collectées mensuellement au niveau de l'établissement, elles peuvent être
comparées au moins tous les mois au niveau de l'établissement, et peuvent en outre être exploitées à
des niveaux supérieurs et à des fréquences inférieures si nécessaire (par exemple, au niveau du
district pendant un an).

Notez que les règles de validation ne sont pas déclenchées lorsque vous travaillez hors ligne dans
l'application de saisie de données basée sur le web ; cependant, elles fonctionnent hors ligne lorsque
vous utilisez l'application DHIS2 android sur un appareil mobile.

68
Saisie des données agrégées Configuration des règles de validation

Configuration des règles de validation

Créons l'exemple de règle de validation que nous avons mentionné précédemment dans DHIS2.
Comme les tests de dépistage du paludisme peuvent être effectués à l'aide de différentes méthodes,
nous allons créer cette règle spécifiquement pour les tests TDR.

1. Ouvrez en premier lieu l'application Maintenance et sélectionnez l'onglet Validation.

1. Créez une nouvelle règle en sélectionnant l'icône "+" sous la règle de validation.

69
Saisie des données agrégées Configuration des règles de validation

1. Passez en revue les champs qui seront utilisés pour décrire la règle. Vous devrez saisir un
nom, sélectionner le type d'importance et de période et définir au minimum le côté gauche, le
côté droit et l'opérateur.

2. Ajouter un nom. Ce nom doit être unique parmi les règles de validation du système. Essayez de
le rendre descriptif afin de comprendre ce qu'il représente. Dans cet exemple, nous pourrions
utiliser le nom "MAL - Positif ( TDR) <= Testé (TDR)".

3. Ajouter une instruction. Ce champ n'est pas obligatoire, mais c'est ce que l'utilisateur verra à la
fois dans l'analyse de validation et lors de l'examen des règles de validation dans la saisie des
données. C'est pourquoi il est recommandé de toujours prévoir une instruction pour indiquer
clairement à l'utilisateur comment vérifier la règle de validation.

4. (Facultatif) Attribuer à la règle un nom court, un code, une description.

1. Sélectionner une importance : Élevée, Moyenne ou Faible. Il s'agit d'une description de la règle
de validation qui sera affichée à l'utilisateur et qui n'affecte pas la priorité ou le fait qu'elle soit
exécutée ou non.

2. Sélectionner un type de période. Notez que vous ne pouvez pas sélectionner un type de
période inférieur à la fréquence de saisie des données. Si vos données sont collectées
mensuellement, vous ne pouvez pas définir une période comme hebdomadaire, par exemple.

3. Créer le côté gauche de l'expression :

1. Cliquez sur Côté gauche.

2. Sélectionnez Fenêtre coulissante si vous souhaitez afficher les données relatives à la
période que vous comparez. Voir aussi "À propos des règles de validation"

70
Saisie des données agrégées Configuration des règles de validation

3. Sélectionnez une stratégie de valeur manquante. Cette sélection détermine comment le

système évalue une règle de validation si des données sont manquantes.

Option Description

Ne jamais ignorer La règle de validation ne sera jamais ignorée en cas

de données manquantes, et tous les opérandes
manquants seront traités comme des zéros. Il s'agit
de l'option par défaut. Sélectionnez toujours cette
option si vous utilisez l'opérateur Paire exclusive ou
Paire obligatoire.

Ignorer si toutes les valeurs sont manquantes La règle de validation ne sera ignorée que si tous les
opérandes qui la composent sont manquantes.

Ignorer si une valeur est manquante La règle de validation sera ignorée si l'une des
valeurs composant l'expression est manquante.

4. Tapez une Description.

5. Construisez une expression basée sur les

éléments de données, les objets de programme, les
unités d'organisation, les comptes et les constantes
disponibles. Pour ce faire, dans le volet de droite,
double-cliquez sur les objets de données que vous
souhaitez inclure dans l'expression. Combinez-les
avec les opérateurs mathématiques situés sous le
volet gauche.

Remarque:

Il est recommandé d'utiliser les éléments de données désagrégés plutôt que l'élément de données
total comme indiqué dans la figure ci-dessus, c'est-à-dire tous les cas positifs de paludisme
par âge et par sexe comme nous le voyons ici. En effet, lors de l'analyse des règles de
validation, si l'élément de données total a été sélectionné, les détails seront vides et il ne
sera pas possible d'identifier l'origine du problème.

1. Lorsque vous ajoutez vos éléments de données du volet droit au volet gauche, vous verrez
#{élément de données [Link]égorie option combo uid}. Cela n'a peut-être pas beaucoup de
sens, mais si vous faites défiler l'écran vers le bas, vous verrez le nom en texte clair.

71
Saisie des données agrégées Configuration des règles de validation

1. Une fois que vous avez sélectionné toutes les entrées requises, sélectionnez Enregistrer. La
description du côté gauche devrait apparaître après avoir sauvegardé le côté gauche.

1. Sélectionnez un Opérateur : Paire obligatoire, Égale à, Couple exclusive, Supérieur à,

Supérieur ou égale à ou Non égale à.

1. L'opérateur Paire obligatoire vous permet d'exiger que les valeurs des données soient
saisies pour un formulaire à la fois pour les côtés gauche et droit de l'expression, ou pour
aucun des deux côtés. Cela signifie que vous pouvez exiger que si un champ d'un
formulaire est rempli, alors un ou plusieurs autres champs que vous avez sélectioné
doivent également être remplis.
2. L'opérateur de la paire exclusive nous permet d'affirmer que si une valeur existe sur le
côté gauche, alors il ne devrait y avoir aucune valeur sur le côté droit (ou vice versa).
Cela signifie que les éléments de données qui composent la règle de chaque côté
doivent être mutuellement exclusifs l'un de l'autre, pour une combinaison donnée période
/ unité organisationnelle / option d'attribut.
3. Dans cet exemple, nous sélectionnerons inférieur ou égal à

72
Saisie des données agrégées Configuration des règles de validation

1. Créer le côté droit de l'expression en suivant le même processus que pour le côté gauche
(point 9 ci-dessus).
2. Lorsque vous avez sélectionné le côté gauche, l'opérateur et le côté droit, vous devriez voir les
descriptions et les opérateurs pour chacun de ces éléments dans l'écran de gestion de
validation.

73
Saisie des données agrégées Configuration des règles de validation

1. (Facultatif) Choisissez les Niveaux d'unité d'organisation pour lesquels cette règle doit être
évaluée. Si vous laissez ce champ vide, la règle de validation sera alors évaluée à tous les
niveaux et représente l'option la plus fréquemment utilisée.

2. (Facultatif) Cliquez sur Ignorer cette règle lors de la validation du formulaire pour éviter de
déclencher cette règle lors de la saisie des données. Normalement, cette option n'est pas
sélectionnée afin que l'utilisateur puisse également consulter cette règle de validation lors de la
saisie des données.

3. Cliquez sur Enregistrer pour sauvegarder la règle de validation

Création de groupes de règles de validation

Après avoir créé nos règles de validation, nous devons les regrouper. Le regroupement de règles de
validation similaires est particulièrement utile lorsque les règles de validation sont examinées
ensemble dans le cadre d'une analyse globale.

Allez dans Maintenance> Validation> Groupe de validation

Sélectionnez le bouton Ajouter et remplissez les détails du groupe de validation (le nom, le code et la
description).

74
Saisie des données agrégées Configuration des règles de validation

Ajoutez toutes les règles de validation connexes que vous avez regroupées en les sélectionnant dans
le volet gauche et en les déplaçant vers le volet droit. Une fois que vous avez ajouté toutes les règles
au groupe, sélectionnez "Enregistrer". La meilleure façon de définir les groupes dépend de la manière
dont les éléments et les ensembles de données sont structurés dans une implémentation particulière.
Toutefois, des exemples sont possibles :

• Créer un lien entre un groupe contenant toutes les règles de validation et les éléments de
données d'un ensemble de données spécifique (par exemple, un ensemble de données
mensuelles pour la déclaration des cas de paludisme)
• Créer un groupe avec toutes les règles de validation liées à l'élément de données dans une
section particulière de l'ensemble de données (par exemple une section paludisme d'un
ensemble de données intégré HMIS).
• Créer un groupe avec toutes les règles de validation liées à l'élément de données dans
plusieurs ensembles de données connexes (par exemple dans des ensembles de données
distincts pour le dépistage du paludisme et le traitement du paludisme)

Examiner les violations des règles de validation lors de la saisie des données

Chaque système ayant une configuration différente, des règles de validation devront être établies
comme indiqué dans la section "Configuration des règles de validation" du présent document avant de
procéder à l'examen des violations. Une fois que vous aurez établi toutes les règles de validation dont
vous avez besoin, vous souhaiterez les utiliser pour vérifier vos données de manière régulière. Les
règles de validation peuvent être examinées à la fois lors de la saisie des données et lors de l'analyse
de validation [LIEN DE SECTION]. Lors de l'examen des règles de validation, nous ne serons avertis
que des règles qui sont violées, et non de celles qui passent les contrôles que nous avons créés.

Reprenons notre exemple

75
Saisie des données agrégées Configuration des règles de validation

Nous pouvons commencer par revoir nos règles de validation dans l'application de saisie des
données. Nous avons fixé la période de la règle de validation que nous avons définie comme étant
"mensuelle" car les données relatives au paludisme sont collectées tous les mois. Dans notre
exemple, les données proviennent du tableau suivant

Afin de vérifier si nos données présentent un problème en fonction des règles de validation que nous
avons définies, nous pouvons faire défiler l'ensemble des données en haut ou en bas de l'application
de saisie des données et sélectionner "Exécuter la validation" [Remarque : les règles de validation
seront également exécutées si vous sélectionnez " Terminé " en bas de l'écran de saisie des
données].

Cette opération permet d'exécuter toutes les règles de validation qui utilisent des éléments de
données dans l'ensemble de données que vous avez sélectionné.

Nous pouvons voir les résultats dans une fenêtre contextuelle qui nous montre les règles de validation
qui ont été violées lorsqu'elles ont été vérifiées lors de la saisie des données.

76
Saisie des données agrégées Configuration des règles de validation

Nous pouvons voir qu'il y a plusieurs violations, y compris la règle qui a été créée précédemment. Il
serait bon de revoir chacune de ces règles pour s'assurer que les valeurs des données de cet
ensemble de données ont été saisies correctement avant de finaliser le processus de saisie des
données. Si possible, les valeurs incorrectes devraient être modifiées afin de minimiser les erreurs au
niveau de la source de collecte.

En examinant notre exemple, nous pouvons voir une erreur évidente et nous voudrions la corriger
pour obtenir la valeur correcte

Si nous passons en revue et corrigeons toutes les erreurs identifiées dans le cadre de la validation de
cet ensemble de données, de cette période et de cette combinaison d'unités d'organisation et que
nous relançons la validation, nous allons obtenir un message indiquant que la validation s'est déroulée
avec succès.

77
Saisie des données agrégées Configuration des règles de validation

Idéalement, nous devrions nous efforcer de créer les règles de validation avant de dispenser la
formation à la saisie des données pour un programme particulier, car cela vous permettrait de
dispenser la formation sur les violations de la validation et de les corriger pendant la formation.
Pendant la formation, vous devez alors vous assurer que tous les ensembles de données passent
avec succès la validation, dans la mesure du possible, avant d'être soumis.

Examiner les violations des règles de validation lors de la saisie des données (beta)

Les règles de validation peuvent également être exécutées dans la nouvelle application de saisie des
données (disponible à partir de la version 2.39). Pour ce faire, il suffit de sélectionner "Exécuter la
validation" à tout moment ou " Cocher terminé " si l'ensemble de données est censé être terminé.

Les résultats s'affichent sur le côté droit de l'application de saisie des données, indiquant le nombre
d'infractions de priorité élevée, moyenne et faible, ainsi que la liste des infractions surlignées dans la
couleur appropriée en fonction de la priorité qui leur a été attribuée. Nous verrons que la nouvelle
application affiche les infractions légèrement différemment de l'ancienne application de saisie des

78
Saisie des données agrégées Notifications des règles de validation

données, en montrant l'instruction, puis le côté gauche avec sa valeur, l'opérateur, et le côté droit avec
sa valeur.

Nous devrions suivre un processus similaire à celui décrit pour l'application de saisie des données et
examiner chacune des valeurs associées à ces règles afin de déterminer si une correction peut être
apportée avant de procéder à d'autres opérations dans DHIS2.

Notifications des règles de validation

Les notifications de règles de validation permettent de créer des messages qui peuvent être envoyés
en réponse à la violation d'une règle de validation. Ces notifications se composent de la ou des règles
de validation qui déclenchent la notification, du ou des destinataires et du message lié à la violation.
Les notifications peuvent être envoyées sous forme de messages aux destinataires prévus à l'aide de
trois mécanismes de DHIS2 : le courrier électronique, les SMS et le service de messagerie interne de
DHIS2. Pour plus d'informations sur la configuration de [e-mail], veuillez vous référer à la
documentation.([Link]
system/[Link]?h=system+settings+master+use#system_email_settings) and SMS.
Voici un exemple de notification de règle de validation envoyée par e-mail.

79
Saisie des données agrégées Notifications des règles de validation

En ce qui concerne la création et l'utilisation des notifications de règles de validation, nous devons
veiller à ce que les résultats contenus dans un message ne soient pas ignorés. Habituellement, nous
sommes prudents quant au nombre de notifications que nous créons afin que les utilisateurs ne
reçoivent pas trop de messages. L'expérience montre que lorsque c'est le cas, les utilisateurs ont
tendance à ignorer ces messages et les points qui posent problème ne sont pas corrigés. En général,
il convient de créer des notifications pour les points à corriger en priorité et de s'assurer que ces
notifications ne sont envoyées qu'aux utilisateurs qui ont besoin de les voir. D'autres violations
peuvent être identifiées par le biais des procédures habituelles d'examen de qualité des données.

Pour créer une notification de règle de validation, les groupes d'utilisateurs sont utilisés pour définir les
destinataires. Veuillez consulter la [documentation sur les groupes d'utilisateurs] (https://
[Link]/en/use/user-guides/dhis-core-version-master/configuring-the-system/users-roles-and-
[Link]#mgt_usergroup) pour savoir comment créer un groupe d'utilisateurs dans DHIS2.

Configuration des notifications de validation

Allez dans Maintenance> Validation> Notification de validation

Sélectionnez le bouton Ajouter pour examiner les détails d'une nouvelle notification de validation. Il
existe un certain nombre de champs que nous pouvons décomposer.

1. Nom : Il s'agit du nom de la notification de validation que vous créez.

2. Code : Vous pouvez également ajouter un code si nécessaire. Le code peut être utilisé pour
identifier de manière unique la notification au lieu de l'UID par exemple.

80
Saisie des données agrégées Notifications des règles de validation

1. Règles de validation : Dans cette section, vous décidez des règles de validation que vous
souhaitez ajouter à votre notification. Bien que vous puissiez ajouter plusieurs règles de
validation à votre notification, il est généralement recommandé de ne conserver qu'une seule
règle de validation dans votre notification afin de faciliter l'interprétation des messages.
N'oubliez pas qu'il peut y avoir plusieurs violations au cours d'une période donnée si les
utilisateurs qui reçoivent la notification ont accès à plusieurs unités d'organisation, et que
chaque violation pourra être identifiée dans le message que vous envoyez.

1. Groupes d'utilisateurs : Cette section définit qui recevra la notification que vous créez. Vous
devez disposer de groupes d'utilisateurs créés pour pouvoir utiliser les notifications de
validation. Vous pouvez consulter [cette section dans la documentation] ([Link]
en/use/user-guides/dhis-core-version-master/configuring-the-system/users-roles-and-
[Link]#mgt_usergroup) pour savoir comment créer des groupes d'utilisateurs. En fonction
de la méthode utilisée pour envoyer le message, l'utilisateur doit remplir les informations
pertinentes correspondantes. Par exemple, si vous envoyez des notifications par e-mail, les
utilisateurs du groupe d'utilisateurs que vous avez sélectionné doivent renseigner leur e-mail,
faute de quoi ils ne recevront pas la notification. Vous pouvez sélectionner plusieurs groupes
d'utilisateurs si nécessaire, mais gardez à l'esprit que vous ne devez envoyer la notification qu'à
ceux qui ont besoin de recevoir cette information plutôt que d'essayer de cibler un grand
nombre d'utilisateurs qui risqueraient d'ignorer le message.

81
Saisie des données agrégées Notifications des règles de validation

1. Stratégie de notification : Nous décidons ici de comment nos notifications doivent être
envoyées lorsque plusieurs violations de validation sont détectées (par exemple sur plusieurs
unités d'organisation et/ou périodes de temps).
1. Résumé collectif : cette option permet de générer un résumé de toutes les violations
détectées pour la ou les période(s)/d'unité(s) d'organisation que vous contrôlez au cours
de votre examen des règles de validation. Par exemple, si vous détectez 10 violations,
elles seront toutes résumées dans un seul message e-mail/SMS/DHIS2.
2. Notification unique : Dans ce cas, un message sera envoyé pour chaque violation de
validation détectée pour les unités d'organisation et les périodes que vous examinez. Par
exemple, si vous détectez 10 violations, 10 messages distincts seront envoyés. Utilisez
cette option avec modération pour les violations à grande priorité.

1. Notifier uniquement les utilisateurs de la hiérarchie :

2. Modèle de message : Dans cette section, nous définissons à quoi ressemblera le message
lorsqu'il sera envoyé à nos destinataires. Le modèle peut être composé de variables de modèle
et de texte brut. Les variables du modèle seront remplacées par les valeurs collectées dans
DHIS2.

82
Saisie des données agrégées Recommandation sur la configuration des règles de validation

Nous pouvons examiner un exemple de message généré pour voir comment les variables de modèle
et le texte brut apparaissent dans une notification lorsqu'elle est envoyée.

1. Il s'agit du modèle de sujet du message. Pour chaque violation, cet élément s'affichera avant de
vous montrer le contenu du modèle de message.
2. Dans le modèle lui-même, nous avons un mélange de texte libre et de variables. La première
variable est la description du côté gauche. Dans le message, elle est remplacée par Positif
(TDR) .
3. Il s'agit de la valeur gauche. Elle est remplacée dans le message actuel par la valeur issue de
DHIS2.
4. Il s'agit de l'opérateur de la règle de validation
5. Il s'agit de la description du côté droit, remplacée par Testé (TDR) dans le message.
6. Il s'agit de la valeur du côté droit, issue de DHIS2.
7. Il s'agit de l'unité d'organisation
8. Il s'agit de la période

Nous constatons qu'il est possible d'utiliser un certain nombre de variables différentes pour créer notre
message et fournir des résultats corrects à la personne qui consulte la notification.

Pour créer le modèle, remplissez le message avec un mélange de texte libre et en sélectionnant les
variables appropriées à droite de l'écran.

Une fois que vous avez rempli ces champs, sélectionnez "Enregistrer" pour sauvegarder la
notification.

Recommandation sur la configuration des règles de validation

Les règles de validation sont un outil puissant pour éviter les erreurs de saisie, mais si elles ne sont
pas configurées de manière appropriée, elles peuvent également être une source d'erreur si elles
incitent les utilisateurs à " corriger " les erreurs.

83
Saisie des données agrégées Valeurs min-max

Dans certains cas, il se peut que vous souhaitiez créer des règles de validation qui sont _ le plus
souvent_ de véritables problèmes de qualité des données, mais qui peuvent être signalées à tort par
DHIS2. Un exemple est la comparaison entre les femmes qui effectuent leur première (CPN1) et leur
quatrième visite de soins prénatals (CPN4). Si nous considérons la population dans son ensemble,
nous pouvons dire que le nombre de visites CPN1 devrait être supérieur ou égal au nombre de visites
CPN4. Chaque femme qui effectue une quatrième visite a également effectué la première visite, mais
il est inévitable que certaines femmes ne se présentent pas à leur quatrième rendez-vous. Ainsi, la
CPN4 devrait toujours être inférieure ou égale à la CPN1 ; cependant, cette règle de validation n'est
pas appropriée, car les visites de CPN sont réparties sur plusieurs mois et les femmes peuvent
effectuer des visites différentes dans des établissements de santé différents. Par exemple, un
établissement de santé peut avoir 100 visites de CPN 1 et 74 visites de CPN 4 au cours d'une année
(CPN 1 ≥ CPN 4), mais au cours d'un mois donné, il peut y avoir 9 femmes qui effectuent leur
quatrième visite et seulement 8 qui effectuent leur première visite (CPN 1 &lt ; CPN 4). Il ne s'agit pas
d'un problème de qualité des données, mais il serait enregistré comme tel avec une règle de
validation comparant la CPN1 et la CPN4.

Nous recommandons de ne pas créer de règles de validation dans ces cas, car l'utilisateur qui saisit
les données peut être dérouté par l'avertissement de la règle de validation et, dans le pire des cas, il
peut modifier les données pour satisfaire aux critères de la règle de validation. Si vous créez ce type
de règle de validation, le message adressé aux utilisateurs doit clairement indiquer que
l'avertissement de la règle de validation doit être examiné, mais qu'il ne s'agit pas nécessairement
d'un problème de qualité des données dans tous les cas.

Le [kit de données sur la santé] ([Link] - en particulier les différents

ensembles de métadonnées agrégées - contient des règles de validation pour les différents
programmes de santé.

Valeurs min-max

La fonction "Min-Max" de DHIS2 est un ensemble de caractéristiques qui vous permet de vérifier les
valeurs aberrantes dans les données pendant la saisie des données. La valeur min-max est basée sur
la définition de valeurs minimales et maximales acceptées pour une combinaison d'éléments de
données, une combinaison d'options de catégorie et une unité d'organisation. Lors de la saisie des
données, les valeurs en dehors de ces seuils minimum et maximum sont mises en évidence dans
l'écran de saisie des données. Comme pour les règles de validation, si une valeur de données se
situe en dehors des limites définies par les valeurs minimales et maximales, DHIS2 autorisera tout de
même la sauvegarde de la valeur de données en question. Toutefois, la valeur sera surlignée dans
l'écran de saisie des données et une boîte de dialogue s'affichera, et qui devra être validée par
l'utilisateur.

La fonction min-max présente deux avantages principaux :

• Elle permet de détecter et de signaler les problèmes de qualité des données au moment de la
saisie, de sorte que l'utilisateur qui saisit les données puisse immédiatement les vérifier,
corriger les fautes de frappe, etc.

• Contrairement aux règles de validation, qui ne peuvent être définies que lorsqu'il existe
plusieurs éléments de données ayant une relation logique entre eux, les valeurs min-max
peuvent être définies pour tout élément de données numériques pour lequel un minimum de
données historiques est disponible.

Remarque : pour les ensembles de données désagrégés avec une combinaison de catégories
d'attributs, les valeurs min-max s'appliquent à toutes les combinaisons d'options d'attributs.

84
Saisie des données agrégées Configuration des valeurs min/max

Configuration des valeurs min/max

Les valeurs minimales et maximales peuvent être définies manuellement dans l'application de saisie
des données ou à l'aide de méthodes de calcul des valeurs minimales et maximales basées sur des
méthodes statistiques à partir de données historiques. Pour les raisons exposées plus en détail ci-
dessous, nous ***ne *** recommandons pas l'utilisation de l'outil intégré à DHIS2 pour générer des
valeurs min-max. Nous discutons de ces restrictions [ici] (#limitations-with-minmax-values).

Configuration et visualisation des valeurs min/max

Les valeurs min-max ne peuvent actuellement être visualisées que dans l'application saisie des
données ; la composante dédiée à "l'analyse min-max" de l'application Qualité des données a été
supprimée.

Visualisation et configuration des valeurs min/max dans l'application de saisie de données

Dans l'application saisie de données, un double clic dans un champ de saisie (c'est-à-dire les cellules
pour la saisie de données) ouvre une fenêtre contextuelle avec des informations sur cette
combinaison particulière d'éléments de données et d'options de catégorie.

La section située dans le coin supérieur droit de la fenêtre indique toutes les limites minimales et
maximales actuellement définies et permet aux utilisateurs disposant des autorisations appropriées de
supprimer et/ou d'enregistrer de nouvelles valeurs minimales et maximales. Comme expliqué ci-
dessous, ces valeurs seront alors applicables à cette combinaison particulière d'élément de données,

85
Saisie des données agrégées Configuration des valeurs min/max

de combinaison d'options de catégorie et d'unités d'organisation. Le graphique Historique de l'élément

de données indique également la valeur maximale lorsqu'elle est définie.

Visualisation et configuration des valeurs min/max dans l'application de saisie de données (beta)

Dans l'application de saisie des données (bêta), les informations sur les valeurs min-max sont
affichées en mettant en évidence un champ de saisie (c'est-à-dire les cellules pour la saisie des
données) et en cliquant sur le bouton Afficher les détails dans la barre d'outils au bas de l'application.

Cela ouvre un panneau de Détails sur le côté droit de l'écran, avec une section dédiée aux limites
mini-maxi. Tout utilisateur peut voir les valeurs mini-maxi définies actuellement, et les utilisateurs
disposant des autorisations appropriées peuvent également les modifier ou les supprimer.

Générateur intégré

DHIS2 comprend une fonctionnalité permettant de générer et de supprimer des valeurs min-max en
masse pour un ou plusieurs ensembles de données pour une sélection d'unités d'organisation. Cette
fonctionnalité se trouve dans l'application Administration des données. Suivez les étapes suivantes
pour générer ou supprimer des valeurs min-max en vrac :

1. Naviguer vers l'application d'administration des données

2. Sélectionnez la section Génération de valeurs min-max

86
Saisie des données agrégées Configuration des valeurs min/max

3. Sélectionnez un ou plusieurs ensembles de données pour lesquels vous souhaitez générer des
valeurs min-max. Les valeurs mini-maxi seront générées/supprimées pour tous les éléments de
données avec des combinaisons d'options de catégorie dans cet ensemble de données.
4. Sélectionnez la limite de l'unité d'organisation pour laquelle des valeurs doivent être générées.
Les valeurs minimales et maximales seront générées/supprimées pour toutes les unités
d'organisation situées en dessous de l'unité d'organisation sélectionnée, y compris l'unité
d'organisation elle-même.
5. Sélectionnez Générer ou Supprimer les valeurs min-max.

Remarque : les valeurs min-max ne sont générées que pour les combinaisons d'éléments de
données, de combinaisons d'options de catégories et d'unités d'organisation pour lesquelles des
données existent déjà, et ce indépendamment de la manière dont l'ensemble de données est assigné.

DHIS2 génère des valeurs min-max en déterminant la moyenne de toutes les valeurs de données
existantes (pour une combinaison donnée d'élément de données/catégorie/option/unité
d'organisation), puis en calculant des limites inférieures et supérieures basées sur un certain nombre
d'écarts-types par rapport à cette moyenne. Le nombre d'écarts types utilisé est basé sur une
propriété de réglage du système appelée Data analysis std dev factor (facteur d'écart type de
l'analyse des données). La valeur par défaut utilisée est de 2 écarts types. Cette valeur peut être
modifiée dans l'application Paramètres du système, dans la section Généralités.

87
Saisie des données agrégées Configuration des valeurs min/max

Limites des valeurs min/max

En règle générale, nous ne recommandons pas l'utilisation de l'outil de génération de valeurs min-
max dans sa fonctionnalité actuelle, car il présente plusieurs limitations majeures qui l'amènent à
générer des valeurs min-max trop restrictives. Cela signifie que trop de valeurs seront signalées
comme potentiellement erronées dans l'application de saisie des données, ce qui peut à la fois gêner
le personnel chargé de la saisie des données et l'amener à modifier incorrectement les valeurs pour
qu'elles se situent dans les limites fixées.

Dans certains cas, cette fonctionnalité peut fonctionner suffisamment bien pour être utilisée : s'il y a
suffisamment de données historiques sur lesquelles baser l'analyse statistique, si les données sont
raisonnablement distribuées normalement (c'est-à-dire qu'elles ne sont pas saisonnières et ne
changent pas au fil du temps) et s'il n'y a pas d'installations qui rapportent toujours des chiffres très
bas. En réalité, il y a très peu de cas où c'est le cas. Dans la pratique, une ou plusieurs de ces
conditions ne sont le plus souvent pas remplies :

• Certains petits établissements de santé déclarent régulièrement des chiffres très bas chaque
mois. Dans l'exemple hypothétique d'un établissement de santé qui déclare des valeurs de 2 ou

88
Saisie des données agrégées Configuration des valeurs min/max

3 tous les deux mois au cours d'une année, le seuil basé sur deux écarts types au-dessus/au-
dessous de la moyenne sera de 1,5 et 3,5. En d'autres termes, si l'établissement déclare 1 ou 4
au cours d'un mois, il se situe en dehors du seuil.

• Très souvent, les données ne sont pas réparties normalement. L'exemple type est celui des
données associées aux saisons des pluies, comme le paludisme. Cependant, même les
données qui ne sont pas typiquement considérées comme saisonnières auront certains mois
de l'année avec des chiffres plus ou moins élevés, par exemple la santé reproductive (y
compris, par conséquent, les vaccinations, la PTME, etc.)

• Les valeurs minimales et maximales seront générées pour toutes les combinaisons d'éléments
de données, de combinaisons d'options de catégories et d'unités d'organisation pour lesquelles
il existe une valeur. Ainsi, par exemple, même si un établissement de santé n'a commencé à
déclarer dans DHIS2 que récemment et que les données n'existent que depuis quelques mois,
des valeurs minimales et maximales seront générées, mais sur une base très limitée.

• Comme la génération min-max intégrée ne peut se faire que sur la base de la moyenne des
données existantes, elle est sensible à toutes les valeurs aberrantes existantes.

Génération personnalisée des valeurs min-max

Il existe une [API DHIS2] ([Link]

[Link]?h=2.40#webapi_min_max_data_elements) qui permet de sauvegarder et de
supprimer les valeurs min-max. Il est donc possible de générer les valeurs min-max à l'extérieur en
utilisant d'autres outils, puis de les importer via l'API. Cette approche est limitée par le fait que l'API ne
permet que de POSTER ou de SUPPRIMER des valeurs individuelles (pour un élément de données,
une combinaison d'options de catégorie, une combinaison d'unités d'organisation). Toutefois, étant
donné que cette valeur minimale n'a pas besoin d'être mise à jour fréquemment (contrairement aux
analyses, par exemple), il est possible de contourner cette limitation.

Outil prototype pour la génération min-max

Un prototype permettant de tester des méthodes améliorées de génération de valeurs min-max a été
développé. Il s'agit d'un outil python créé dans l'optique d'une plus grande flexibilité pour la génération
de valeurs min-max. Une documentation détaillée sur l'utilisation de cet outil est disponible dans le
dépôt github.

Cet outil est conçu pour remédier aux principales lacunes de la fonctionnalité intégrée de génération
de valeurs min-max :

• Il permet de définir différents paramètres en fonction des valeurs médianes rapportées par les
unités ; par exemple, les valeurs minimales et maximales pour les petites installations peuvent
être définies sur la base des valeurs les plus élevées précédentes plutôt que sur la base des
écarts types, et les installations plus grandes peuvent disposer d'un seuil plus strict.

• Il permet de définir un niveau minimum d'exhaustivité des données pour une unité avant
d'essayer de générer des valeurs minimales et maximales.

• Il permet de normaliser les données à l'aide de la transformation box-cox avant de définir les
valeurs min-max, afin de mieux travailler avec des données qui ne sont pas réparties
normalement.

• Il permet d'utiliser la médiane en plus de la moyenne pour fixer les seuils.

89
Saisie des données agrégées Configuration des valeurs min/max

Remarque : l'outil n'est pour l'instant qu'un prototype et doit être testé de manière
approfondie dans un environnement de test avant d'être utilisé dans un environnement de
production.

Vérifier les valeurs min/max lors de la saisie des données

Aucune action de l'utilisateur n'est nécessaire pour vérifier les valeurs min-max dans l'application de
saisie de données : lorsqu'un nombre en dehors de la valeur min-max spécifiée est saisi, une fenêtre
contextuelle apparaît immédiatement avec un message d'avertissement, et la cellule est surlignée en
orange foncé.

Lorsque l'on marque l'ensemble de données comme étant terminé ou que l'on utilise le bouton
Exécuter la validation, les violations des valeurs minimales et maximales sont également répertoriées
de la même manière que les violations des règles de validation.

90
Saisie des données agrégées Configuration des valeurs min/max

Examiner les valeurs min-max dans l'application Qualité des données

Les valeurs minimales et maximales peuvent être examinées par lots dans le cadre de la détection
des valeurs aberrantes dans l'application Qualité des données. Min-max est disponible comme l'un
des "Algorithmes" disponibles.

Pour effectuer une analyse des valeurs en dehors des seuils min-max :

1. sélectionnez un ou plusieurs ensembles de données à analyser

2. Sélectionnez une ou plusieurs unités d'organisation.
3. préciser les dates de début et de fin
4. Sélectionnez les valeurs Min-max comme algorithme
5. Cliquez sur Démarrer

Le résultat est présenté sous la forme d'une liste indiquant l'élément de données, la période et l'unité
d'organisation pour lesquels une valeur dépassant les seuils minimal et maximal a été déclarée.

91
Saisie des données agrégées Configuration des valeurs min/max

La colonne Valeur correspond à la valeur des données déclarées, la colonne Déviation indique de
combien le nombre est supérieur au seuil maximum ou inférieur au seuil minimum, et les colonnes
Min et Max indiquent les seuils minimum et maximum pour l'élément de données et l'unité
d'organisation en question. Le tableau est trié par écart, car les violations ayant l'écart le plus élevé
ont l'impact le plus important sur l'ensemble des données. Le suivi permet de marquer des valeurs de
données pour le suivi ; elles peuvent ensuite être examinées à l'aide de la fonctionnalité [Analyse de
suivi] ([Link]
[Link]?h=follow-up+anal+master+use#about-follow-up-analysis).

92
Évaluation de la qualité des données Complétude et ponctualité{ #completeness-and-timeliness }

Évaluation de la qualité des données

DHIS2 dispose d'une large gamme de fonctions pour l'évaluation de la qualité des données,
disponibles dans différentes applications et fonctions. Cette section en donne un aperçu. Elle est
structurée selon trois types de mesures de la qualité des données :

• Complétude et ponctualité des données

• Cohérence des données entre variables associées
• Cohérence des données au fil du temps

Complétude et ponctualité{ #completeness-and-timeliness }

La complétude des rapports renseigne sur la proportion des données attendues qui ont été
effectivement rapportées. Dans DHIS2, la plupart des contrôles de complétude sont basés sur
l'évaluation de la complétude des ensembles de données, c'est-à-dire le nombre d'ensembles de
données (formulaires) qui ont été soumis par unité d'organisation et par période. Pour déterminer si
les données ont été transmises dans les délais, le système utilise un paramètre appelé "Jours après la
fin de la période pour une transmission des données dans les délais".

La fonctionnalité intégrée pour la complétude et la ponctualité des données dans DHIS2, par exemple
ce qui est intégré dans les applications Visualiseur de données, Rapports et Cartes, se réfère aux
taux de déclaration des ensembles de données. Cependant, nous pouvons également configurer
DHIS2 pour évaluer la proportion d'établissements qui produisent régulièrement des rapports, ainsi
que la complétude des éléments de données individuels.

Complétude et ponctualité des ensembles de données

Les rapports de complétude montreront également les unités d'organisation d'une zone qui déclarent
leurs données à temps, ainsi que le pourcentage d'établissements qui déclarent leurs données dans
les délais et dans une zone donnée.

La complétude et la ponctualité des données peuvent être examinées dans l'application Rapports
ainsi que dans les applications de visualisation de base (Visualiseur de données et Cartes). Les
applications de visualisation de base vous permettent d'examiner la complétude et la ponctualité des
données de manière plus détaillée à travers plusieurs unités d'organisation et périodes. Cependant,
l'application Rapports offre une expérience utilisateur simplifiée qui a été validée par son utilisation
très répandue par rapport à d'autres applications de DHIS2.

Utilisation de l'application Rapports

Afin de vérifier la complétude et la ponctualité des données dans l'application Rapports, accédez à
Applications -> Rapports.

93
Évaluation de la qualité des données Complétude et ponctualité des ensembles de données

À partir de là, sélectionnez "Obtenir un rapport" sous l'en-tête Récapitulatif du Taux de Déclaration.

Commencez par la sélection de vos entrées :

1. Les unités d'organisation que vous voulez examiner. Lorsque vous sélectionnez l'unité
d'organisation racine, toutes ses unités filles seront également sélectionnées (ainsi que le
résultat global de l'unité d'organisation sélectionnée).

2. Sélectionnez l’ensemble de données dont vous voulez examiner la complétude et la ponctualité

des informations.

3. Sélection de la période de déclaration, suivie de la période elle-même/

94
Évaluation de la qualité des données Complétude et ponctualité des ensembles de données

Si vous sélectionnez Afficher plus d'options, vous pouvez utiliser un ensemble de groupes d'unités
d'organisation pour sélectionner des groupes d'unités d'organisation afin de filtrer davantage votre
rapport ; cependant, cela est facultatif.

Après avoir sélectionné toutes vos entrées, sélectionnez "Obtenir un rapport" pour produire le rapport.

95
Évaluation de la qualité des données Complétude et ponctualité des ensembles de données

Cela produira un rapport avec les colonnes suivantes

1. Nom : le nom de l'unité d'organisation

2. [Nom de l'ensemble de données] - Rapports produits : il s'agit du nombre de rapports marqués

comme terminés au cours de la période que vous avez sélectionnée.

3. [Nom de l'ensemble de données] - Rapports attendus : il s'agit du nombre de rapports attendus

au cours de la période que vous avez sélectionnée. Ce nombre est automatiquement calculé
en fonction de la dimension temporelle et de l'affectation de l'ensemble de données aux unités
d'organisation.

4. [Nom de l'ensemble de données] - Taux de déclaration : Il s'agit du taux de déclaration :

rapports produits/rapports attendus x 100 %

5. [Nom de l'ensemble de données] - Rapports produits à temps : il s'agit du nombre de rapports

au cours de la période que vous avez sélectionnée qui ont été marqués comme terminés dans
l'intervalle de temps défini comme "à temps" pour l'ensemble de données sélectionné

6. [Nom de l'ensemble de données] - Taux de déclaration à temps : Ce taux = rapports produits +

rapports à temps / rapports attendus x 100 %

Utilisation de Visualiseur de données

Dans Visualiseur de données, vous pourrez examiner les mesures de complétude et de ponctualité
des ensembles de données de la même manière que dans l'application Rapports. Mais ici, vous
pouvez sélectionner plusieurs ensembles de données, périodes et unités d'organisation à la fois. Vous
pouvez également ajouter des mesures de complétude et de ponctualité aux graphiques et aux
tableaux qui incluent d'autres données, telles que les données relatives à la fourniture de services de
santé, afin de vérifier que les données que vous examinez reflètent la situation dans le pays avec
lequel vous travaillez. Cette application vous offre plus de flexibilité que l'application "Rapports" ;
cependant, les options supplémentaires peuvent la rendre moins accessible que l'application
"Rapports". En principe, ces visualisations sont préparées à l'avance et placées sur un tableau de
bord que les utilisateurs peuvent consulter régulièrement. Toutefois, certains utilisateurs doivent savoir
créer des sorties à l'aide de ces mesures dans Visualiseur de données.

96
Évaluation de la qualité des données Complétude et ponctualité des ensembles de données

Dans Visualiseur de données, sélectionnez "Données" comme entrée, et "Ensemble de données"

comme type de données. Cela vous permettra de rechercher ou d'ajouter des filtres pour l'ensemble
de données et le type de mesure que vous voulez ajouter à votre visualisation.

Voici un exemple de graphique qui compare les doses de BCG administrées avec le taux de
déclaration de l'ensemble de données de vaccination.

97
Évaluation de la qualité des données Complétude et ponctualité des ensembles de données

Nous pouvons tout de suite constater que plusieurs districts ont des taux de déclaration < 80 % et
que, par conséquent, les données affichées peuvent ne pas refléter entièrement la situation du pays. Il
peut s'avérer important de vérifier cela au moyen d’une analyse plus détaillée où sont examinés les
établissements qui attribuent cette valeur et/ou en utilisant la complétude des éléments de données.

Nous pouvons passer en revue quelques exemples de tableaux et de graphiques que vous pourriez
créer lors de l'examen de la complétude et de la ponctualité dans l'application Visualisation de
données.

Exemple 1 : Tableau croisé dynamique comparant la complétude et la ponctualité sur plusieurs

ensembles de données, périodes et unités d'organisation

Sélectionnez "Tableau croisé dynamique" comme type de sortie

98
Évaluation de la qualité des données Complétude et ponctualité des ensembles de données

• Sélectionnez "Données" et définissez le type de données sur "Ensembles de données"

• Sélectionnez les mesures que vous voulez ajouter à votre tableau

Masquez ou actualisez le sélecteur de données et procédez à la modification de vos périodes et

unités d'organisation.

99
Évaluation de la qualité des données Complétude et ponctualité des ensembles de données

Après avoir effectué toutes vos sélections, modifiez la présentation de votre tableau et mettez ce
dernier à jour

Le tableau devrait maintenant s'afficher avec les entrées que vous avez sélectionnées.

100
Évaluation de la qualité des données Complétude et ponctualité des ensembles de données

Exemple 2 : Graphique linéaire comparant la complétude et la ponctualité sur plusieurs périodes

Sélectionnez "Linéaire" comme type de sortie

• Sélectionnez "Données" et définissez le type de données sur "Ensembles de données"

• Sélectionnez les mesures que vous voulez ajouter à votre graphique. Une seule est
sélectionnée ici mais vous pouvez en utiliser autant que nécessaire.

• Masquez ou actualisez le sélecteur de données et procédez à la modification de vos périodes

et unités d'organisation.

101
Évaluation de la qualité des données Complétude et ponctualité des ensembles de données

• Modifiez la présentation de votre graphique et mettez-le à jour lorsque vous avez terminé.

102
Évaluation de la qualité des données Complétude et ponctualité des ensembles de données

Exemple 3 : Un graphique à 2 axes comparant les données de service avec la complétude de l'ensemble
de données

Sélectionnez "Colonne" comme type de sortie

• Sélectionnez "Données" et définissez le type de données sur "Ensembles de données".

Sélectionnez la ou les mesure(s) que vous voulez ajouter à votre graphique

103
Évaluation de la qualité des données Complétude et ponctualité des ensembles de données

• Changez le type de données. Les éléments de données sont utilisés dans cet exemple, mais
vous pouvez combiner la mesure de la complétude et de la ponctualité avec n'importe quel type
de données DHIS2 existants dans le Visualiseur de données.

• Masquez ou actualisez le sélecteur de données et procédez à la modification de vos périodes

et unités d'organisation.

104
Évaluation de la qualité des données Complétude et ponctualité des ensembles de données

• Modifiez la présentation de votre graphique et mettez-le à jour lorsque vous avez terminé.

• Pour déplacer l'un des éléments vers le 2nd axe, sélectionnez Options, puis Série. Modifiez les
éléments de données pour qu'ils apparaissent sur les axes souhaités en utilisant le type de
visualisation approprié et mettez à jour votre graphique.

105
Évaluation de la qualité des données Complétude et ponctualité des ensembles de données

• Des options supplémentaires, telles que le classement des éléments du graphique et l'ajout de
titres aux graphiques, peuvent ensuite être ajoutées au graphique à l'aide du bouton Options
dans l'application Visualiseur de données.

106
Évaluation de la qualité des données Complétude et ponctualité des ensembles de données

107
Évaluation de la qualité des données Complétude et ponctualité des ensembles de données

Configuration de la complétude de l'ensemble de données

La complétude de l'Ensemble de Données est basée sur l'affectation de votre ensemble de données
aux unités d'organisation. Cela détermine la valeur de vos rapports attendus, en fonction de la
périodicité de l'ensemble de données. La configuration se fait dans l'application Maintenance.

Accédez à Maintenance -> Ensemble de données -> et sélectionnez ou créez l'ensemble de données
souhaité. Dans cet ensemble de données, défilez vers le bas pour trouver l'unité ou les unités
d'organisation d'affectation.

Vous pouvez affecter votre ensemble de données à des unités d'organisation en les sélectionnant
individuellement ou en utilisant des niveaux ou des groupes.

108
Évaluation de la qualité des données Complétude et ponctualité des ensembles de données

Ce qui compte ici, c'est de s'assurer que l'ensemble de données NE SOIT PAS affecté à des unités
d'organisation qui ne sont pas censées produire des rapports sur cet ensemble de données. Dans le
cas contraire, le nombre de rapports attendus sera systématiquement erroné. Par exemple, dans la
capture d'écran ci-dessus, cet ensemble de données est affecté à 185 unités d'organisation.
Supposons que cet ensemble de données fasse l'objet d'un rapport mensuel. Chaque mois, 185
rapports sont attendus. Si seules 160 unités d'organisation produisent des rapports sur cet ensemble
de données, votre taux de complétude ne dépassera jamais 160/185 x 100 % = 86 % par mois. Cela
est dû au fait que les 25 autres unités d'organisation ne produiront pas de rapports sur cet ensemble
de données, car elles ne sont pas sensées le faire. C'est un aspect important à prendre en
considération afin de garantir une affectation correcte des ensembles de données aux unités
d'organisation.

Configuration de la ponctualité des ensembles de données

La ponctualité est également configurée dans l'application Maintenance lors de la création ou de la

modification d'un ensemble de données. pour ce faire, utilisez le champ "Jours après la période pour
une transmission des données dans les délais".

109
Évaluation de la qualité des données Complétude des éléments de données

Dans l'exemple ci-dessus, l'ensemble de données est collecté mensuellement et la ponctualité est
fixée à 15. Cela signifie que l'ensemble de données doit être terminé dans les 15 jours suivant la fin
du mois précédent pour que sa soumission soit dans les délais.

Complétude des éléments de données

La complétude et la ponctualité des ensembles de données sont des mesures permettant de surveiller
la performance globale du système en matière de déclaration des données. Cependant, plusieurs

110
Évaluation de la qualité des données Complétude des éléments de données

conditions doivent être remplies pour que la complétude d'un ensemble de données donne une
indication qui reflète la complétude des données au sein de cet ensemble de données :

• Les utilisateurs doivent marquer l'ensemble de données comme "terminé" après que les
données soient saisies.

• Les utilisateurs doivent effectivement saisir les données dans le formulaire avant de les
marquer comme terminés

• L'affectation des ensembles de données aux unités d'organisation (établissements) doit être
correcte.

Souvent, une ou plusieurs de ces conditions ne sont pas remplies, ce qui signifie qu'il faut également
procéder à une analyse supplémentaire de la complétude du rapport. Dans cette section, nous
montrons

• Comment analyser la proportion d'établissements qui produisent régulièrement des rapports sur
les valeurs des éléments de données au cours d'une période de temps donnée, et

• Comment analyser la complétude d'un élément de données individuel

Le point commun des approches décrites est qu'elles nous obligent à configurer des métadonnées
supplémentaires pour chaque variable que nous voulons évaluer. En pratique, cela signifie qu’elles ne
s'appliquent qu'à un ensemble limité d’éléments de données. La section Implémentation traite du sujet
plus en détail.

Rapports réguliers des unités d'organisation

L'évaluation de la proportion d'établissements qui produisent régulièrement des rapports au cours

d'une période de temps donnée est une mesure de la complétude qui ajoute une nouvelle dimension à
notre compréhension de la complétude des données par rapport à la complétude des ensembles de
données. Lorsqu'un sous-ensemble d'établissements ne déclare leurs données que par intermittence,
il est important de connaître le pourcentage d'établissements de santé qui produisent régulièrement
des rapports au cours d'une période de temps donnée, par exemple sur une année. Par exemple, si
au cours d'un mois, un dispensaire déclare ses données et qu'un hôpital de district ne le fait pas, et
que le mois suivant, c'est l'inverse, les chiffres concernant la complétude resteront constants, mais les
données sur la prestation de services seront probablement très différentes au sein de ce district.

Nous avons défini les établissements qui produisent régulièrement des rapports comme suit : 100 X
(établissements qui produisent des rapports pour chaque période au cours d'une période de temps
donnée)/(établissements qui produisent des rapports pour une période donnée au cours d'une période
de temps donnée)

Cette vérification pourrait en principe être effectuée sur la base du rapport général de l'ensemble de
données ou sur la base d'un élément de données au sein de l'ensemble de données. Dans l'exemple
fourni ici, nous montrons comment procéder, car l'évaluation au niveau de l'ensemble de données
pourrait être réalisée en examinant le taux de déclaration annuel des ensembles de données pour
chaque établissement.

Configuration de la cohérence des rapports

Nous montrerons comment créer un indicateur pour le pourcentage d'unités d'organisation

(établissements) qui produisent régulièrement des rapports pour un élément de données particulier. Il
n’est pas possible de le calculer directement comme indicateur, nous utiliserons donc des prédicteurs.

Cela signifie que nous allons configurer :

111
Évaluation de la qualité des données Complétude des éléments de données

Éléments de données :

• Etablissements produisant des rapports pour toutes les périodes au cours de la période de
temps
• Etablissements produisant des rapports pour une période donnée au cours de la période temps

Prédicteurs :

• Etablissements produisant des rapports pour toutes les périodes au cours de la période de
temps
• Etablissements produisant des rapports pour une période donnée au cours de la période temps

Indicateur :

• Etablissements produisant régulièrement des rapports sur l'élément de données au cours de la

période de temps (%), par exemple "CPN 1 - établissements produisant régulièrement des
rapports au cours des 12 derniers mois (%)

De plus, des visualisations doivent être crées et partagées avec les utilisateurs, et nous suggérons
d'organiser les métadonnées en groupes, et si possible les éléments de données en ensembles de
données. L'appartenance de ces groupes à des groupes dédiés à la qualité des données ou à des
groupes existants pour chaque programme de santé (ou les deux) dépend des normes de
configuration et des PON en vigueur pour une implémentation particulière. Pour plus de clarté,
l'instance de démonstration où un exemple de cette configuration peut être examiné utilise des
groupes dédiés.

Dans ce qui suit, nous utiliserons comme exemple la CPN 1 (c’est-à-dire les femmes enceintes
effectuant leur première visite de soins prénatals).

Création d'éléments de données

Les éléments de données sont nécessaires pour contenir les données agrégées générées par les
deux prédicteurs qui effectuent les calculs pour cet indicateur. Les éléments de données doivent être
nommés conformément à la convention d'appellation en vigueur dans la localité, être dans le domaine
des données agrégées et (dans la plupart des cas) avoir une valeur de type Positive ou Entier (zéro
inclus).

112
Évaluation de la qualité des données Complétude des éléments de données

Pour La CPN 1, nous pourrions créer ces deux éléments de données :

• DQ - CPN 1 ayant fait l'objet d'un rapport par les unités d'organisation pour chacun des
12 derniers mois
• DQ - CPN 1 ayant fait l'objet d'un rapport par les unités d'organisation pour un des 12 derniers
mois

113
Évaluation de la qualité des données Complétude des éléments de données

Création de prédicteurs

Ensuite, nous devons configurer deux prédicteurs pour le calcul des données pour nos deux éléments
de données. La documentation sur les prédicteurs est disponible ici

1. Donnez un nom (obligatoire), un nom court, un code et une description au prédicteur

1. Spécifiez l'élément de données de sortie ; il doit se rapporter aux éléments de données que
nous avons créés à l'étape précédente

1. Spécifiez le type de période du prédicteur ; il doit correspondre au type de période de l’élément

de données que nous évaluons. Dans cet exemple, nous évaluons la CPN 1, que nous
supposons être collecté mensuellement.

2. Spécifiez le niveau de l'unité d'organisation. Pour cet indicateur de la qualité des données, il
doit s'agir du niveau où les données sont collectées, généralement au niveau de
l'établissement. \ Nous devons également effectuer une sélection dans "Unités d'organisation
fournissant des données", qui doit être "Au(x) niveau(x) sélectionné(s) uniquement", puisque
nous calculons la cohérence des rapports uniquement sur la base du niveau que nous avons
sélectionné comme niveau de collecte des données.

114
Évaluation de la qualité des données Complétude des éléments de données

3. Ensuite, nous devons spécifier le Générateur. C'est ici que nous allons définir l'expression
utilisée pour calculer la cohérence des rapports.

1. Pour calculer le prédicteur de "nombre d'unités organisations ayant produit des rapports
pour chacun des 12 derniers mois", nous utilisons la formule "si(
somme( si(n'estPasNul([élément de données]), 1, 0)) == 12, 1, 0)"

1. si(n'estPasNul([élément de données]), 1, 0), et produit un 1 si une valeur existe,

et un 0 sinon
2. somme( si(n'estPasNul([élément de données]), 1, 0)** )** additionne le nombre de
périodes pour lesquelles l'instruction si(n'estPasNul()) renvoie 1. Il ajoute donc 1
pour chaque période au cours de laquelle une valeur a été déclarée.
3. si( somme(si(n'estPasNul([élément de données]), 1, 0))** == 12, 1, 0) **vérifie si
le nombre de périodes additionnées par 'somme()' est égal au nombre de
périodes que nous évaluons. Si nous évaluons un ensemble de données qui
nécessite un rapport chaque mois, pour une période d'un an, nous le comparons à
12. Si le nombre de périodes avec une valeur correspond à 12, le prédicteur
produit un 1, ce qui indique que l'unité d'organisation a produit des rapports au
cours des 12 mois précédents.

115
Évaluation de la qualité des données Complétude des éléments de données

2. Pour calculer le prédicteur de "nombre d'unités d'organisation déclaré des données pour
un des 12 derniers mois", nous utilisons la formule "si(n'estPasNul([éléments de
données]),1,0) »

1. si(n'estPasNul([élément de données]), 1, 0), et produit un 1 si une valeur existe

pour l'une des périodes, et un 0 sinon. 1 indique que l'unité d'organisation a
déclaré des données pour _au moins un _des 12 mois précédents.

116
Évaluation de la qualité des données Complétude des éléments de données

4. Enfin, nous devons spécifier le nombre d'échantillons et de sauts (skip). Le test de saut
d'échantillon ne doit pas être activé. Le nombre d'échantillons séquentiels doit correspondre au
nombre de périodes pour lesquelles nous voulons calculer la cohérence des rapports. Pour les
données mensuelles que nous voulons évaluer pendant un an, nous devons fixer le nombre
d'échantillons séquentiels à 12. Cela signifie que les 12 mois précédant la période pour laquelle
nous générons le prédicteur seront examinés. \ Le nombre d'échantillons annuels et le nombre
d'échantillons séquentiels doivent tous deux être égaux à 0.

117
Évaluation de la qualité des données Complétude des éléments de données

Création de l'indicateur

Lorsque les deux éléments de données et les deux prédicteurs ont été définis, nous pouvons définir
l'indicateur qui produit la mesure de la qualité des données qui nous intéresse : le pourcentage
d'établissements qui ont régulièrement produit des rapports sur un élément de données spécifique au
cours de la dernière année.

1. Le nom de l’indicateur, le nom court, le code et la description doivent être spécifiés

conformément aux conventions locales d'appellation et de codage.

118
Évaluation de la qualité des données Complétude des éléments de données

1. L'indicateur ne doit** pas** être annualisé et le type d'indicateur doit être Pourcentage (facteur
= 100)

2. L'expression du numérateur doit être Établissements ayant produit des rapports pour tous les
12 mois précédents (en partant du principe que les données sont mensuelles).

3. L'expression du dénominateur doit être : Établissements ayant produit des rapports pour un des
12 mois précédents (en partant du principe que que les données sont mensuelles).

119
Évaluation de la qualité des données Complétude des éléments de données

Après la génération des prédicteurs et la réalisation des analyses générales (voir ci-dessous,
l'indicateur peut être utilisé dans les applications Visualiseur de données et Cartes.

Calcul de la complétude des éléments de données

Dans certaines implémentations de DHIS2, il a été observé que les rapports sur tous les éléments de
données au sein d'un ensemble de données n'étaient pas cohérents. Par défaut, DHIS2 n'évalue que
les taux de déclaration des ensembles de données et non des éléments de données individuels de cet
ensemble. L'objectif du taux de déclaration d'un élément de données est d'évaluer la cohérence de la
déclaration d'une valeur unique. Ceci ne concerne que les éléments de données agrégés.

120
Évaluation de la qualité des données Complétude des éléments de données

Le calcul du taux de déclaration se décline comme suit : 100 x (Nombre de valeurs reçues / Nombre
de valeurs attendues)

Pour calculer le taux de déclaration d'un élément de données, nous devons définir un indicateur avec
un numérateur (nombre de valeurs reçues), un dénominateur (nombre de valeurs attendues) et un
facteur de 100 (type d'indicateur de pourcentage). Alors que le numérateur est toujours le nombre de
données, il existe différentes options pour définir le dénominateur, et le choix de l'option appropriée
doit se faire en fonction de la situation locale.

La configuration de la complétude des éléments de données dans DHIS2 dépend également de la

version de DHIS2 : pour définir le numérateur et le dénominateur, l'on utilise souvent les prédicteurs
comme étape intermédiaire dans le calcul, en particulier dans les versions 2.37 et inférieures. Notez
que les prédicteurs devront être programmés pour s'exécuter sur le serveur. Consultez la section
finale pour obtenir des instructions à ce sujet.

Configuration du numérateur - valeurs reçues

Revoyons d'abord comment définir le numérateur de notre indicateur de complétude d'éléments de

données. Comme expliqué ci-dessus, il s'agit toujours du nombre de données qui ont été déclarées
pour un élément de données spécifique. Certains paramètres doivent toutefois être pris en compte.

Stockage des valeurs nulles

Pour plusieurs raisons, il est généralement recommandé de ne pas enregistrer les valeurs nulles
rapportées pour les éléments de données, à moins qu'il n'y ait une raison claire à cela (par exemple,
avec un "type d'agrégation" pour lequel les valeurs nulles sont pertinentes, comme avec la moyenne).
Cela a des implications sur l'examen de la complétude des éléments de données, puisqu'avec les
éléments de données pour lesquels les valeurs nulles ne sont pas saisies et enregistrées, nous ne
pouvons pas faire la différence entre les établissements qui n'ont rien à déclarer et ceux qui ne l'ont
pas fait. Une option consiste à activer l'enregistrement des valeurs nulles pour les éléments de
données pour lesquels vous voulez définir des indicateurs de complétude d'éléments de données.
Toutefois, cette option est difficile à appliquer dans la pratique, car les utilisateurs chargés de la saisie
des données doivent savoir pour quels champs spécifiques un 0 est attendu. Une option plus pratique
consiste à axer la configuration de la complétude des éléments de données sur les éléments de
données pour lesquels tous ou presque tous les établissements sont censés avoir une valeur > 0 à
déclarer, et à indiquer explicitement dans les descriptions de l'indicateur et les visualisations que l'on
ne s'attend pas nécessairement à ce que la complétude des éléments de données atteigne les 100 %.

Désagrégations

Il est essentiel de prendre en considération toute désagrégation susceptible d'être appliquée à

l'élément de données, car cela affecte la configuration des expressions d'indicateurs et l'utilisation ou
non de prédicteurs. Par exemple, si un élément de données pour une campagne de vaccination
d'enfants comme le BCG est désagrégé par < 1 an et 1+ an, la complétude de l'élément de données
doit-elle être basée sur :

• Une combinaison d’options de catégorie spécifique. Par exemple, "déclaré" signifie avoir
déclaré des données pour "BCG doses < 1 an".

• Les deux combinaisons d’options de catégorie. Par exemple, "déclaré" signifie avoir déclaré
des données pour "BCG doses < 1 an" ou "BCG doses < 1 an".

• L’une ou l’autre des combinaisons d’options de catégorie. Par exemple, "déclaré" signifie avoir
déclaré des données pour "BCG doses < 1 an" ou "BCG doses < 1 an".

Le choix dépend de l'élément de données et de la désagrégation. Pour les vaccinations d'enfants, la

tranche d'âge ciblée est < 1 an, et il peut arriver qu'il n'y ait pas de données à déclarer pour la tranche

121
Évaluation de la qualité des données Complétude des éléments de données

d'âge de 1+ an. Il serait donc logique de définir une complétude spécifique pour la tranche d'âge 1+
an. D'autre part, si les "cas confirmés de paludisme" sont désagrégés en < 5 ans et 5+ ans, on peut
s'attendre à ce que les établissements disposent de valeurs pour chaque tranche d'âge et il serait
logique de considérer ces deux valeurs comme attendues. Dans ce cas, le dénominateur doit être
ajusté en conséquence.

La même considération s'applique lorsque les ensembles de données sont désagrégés avec une
[combinaison d'options d'attribut] (#à-propos-de-dimensions-de-données-supplémentaires), bien que
cela soit moins courant.

Le tableau suivant présente les approches alternatives de configuration du numérateur, en tenant

compte du fait que l'élément de données est désagrégé ou non, de la manière d'évaluer la
complétude des désagrégations, le cas échéant, et de la possibilité de les configurer directement dans
les indicateurs ou d'utiliser d'abord des prédicteurs.

Version 2.38 et les versions Version 2.37 et les versions

supérieures inférieures

Élément de données sans Indicateur (avec sousExpression) Prédicteur

désagrégation

Élément de données avec Indicateur (avec sousExpression) Prédicteur

désagrégation - analyse d'une
combinaison d'options de
catégorie

Élément de données avec Indicateur (avec Prédicteur

désagrégations - chaque sousExpression) ; multiplication
combinaison d'options de du dénominateur par le nombre
catégorie avec une valeur comme de combinaisons d'options de
est considérée comme "déclarée" catégorie

Élément de données avec Prédicteur Prédicteur

désagrégation - toutes les
combinaisons d'options de
catégorie doivent avoir une valeur
pour que l'élément de données
soit considéré comme "déclaré"

Élément de données avec Prédicteur Prédicteur

désagrégation : si une
combinaison d'options de
catégorie a une valeur, l'élément
de données est considéré comme
"déclaré"

Nous allons d'abord expliquer comment configurer les options qui peuvent l'être directement avec les
indicateurs, puis nous nous pencherons sur la configuration avec les prédicteurs

Configuration du numérateur avec indicateur et sousExpressions

Comme expliqué ci-dessus, le numérateur doit être le nombre de valeurs pour un élément de données
(avec ou sans désagrégation). A partir de la version 2.38, la configuration peut être effectuée
directement dans un indicateur agrégé en utilisant une sousExpression avec une instruction
conditionnelle n'estPasNul dans l'expression. Une valeur 1 sera renvoyée chaque fois qu'un nombre
(y compris zéro) est saisi pour cet élément de données. Ci-dessous, un exemple.

122
Évaluation de la qualité des données Complétude des éléments de données

• si(n'estPasNul([Identifiant de l'élément de données]**), 1, 0) ** elle renverra 1 pour chaque

valeur de cet élément de données, 0 sinon.

◦ Si l'élément de données n'a pas de désagrégation, elle renverra 1 ou 0 selon que les
données ont été déclarées.

◦ Si l'identifiant spécifié dans n'estPasNul() inclut une combinaison d'options de catégorie

spécifique (par exemple n'estPasNul(#{TWWbtMMWD51.JKuWbG5bWAu})),
l'expression renverra 1 ou 0 selon que des données ont été déclarées pour cet élément
de données et cette combinaison d'options de catégorie spécifiques.

◦ Si l'élément de données est désagrégé, mais qu'aucune combinaison d'options de

catégorie n'est spécifiée, l'expression renverra 1 pour chaque donnée dans la
combinaison d'options de catégorie. Ainsi, si un élément de données a une
désagrégation > 1 an, 1 + an et qu'un établissement a déclaré une valeur pour les deux
désagrégations, l'expression renverra 2. Dans ce cas, le dénominateur doit être ajusté
adéquatement.

• sousExpression si(n'estPasNul([Identifiant de l'élément de données])** ) **garantit l'exécution

de l'instruction si(n'estPasNul()) au niveau de collecte de données, avant que l'expression ne
soit agrégée au fil du temps et au sein de la hiérarchie des unités d'organisation.

Pour résumer, ce qu’il faut utiliser comme expression pour le numérateur est :

Expression avec exemple

Méthode
d'élément de données

Élément de données sans Indicateur sousExpression( si( n'estPasNul(

désagrégation #{TWWbtMMWD51}), 1, 0))

Élément de données avec Indicateur sousExpression (si (n'estPasNul

désagrégation - analyse d'une (#{TWWbtMMWD51.JKuWbG5b
combinaison d'options de WAu}), 1, 0))
catégorie

Élément de données avec Indicateur; le dénominateur doit sousExpression( si( n'estPasNul(

désagrégations - chaque être ajusté #{TWWbtMMWD51}), 1, 0))
combinaison d'options de
catégorie avec une valeur comme
est considérée comme "déclarée"

123
Évaluation de la qualité des données Complétude des éléments de données

Configuration du numérateur - avec prédicteur

Les versions 2.37 et les versions inférieures ne prennent pas en charge les sousExpressions dans les
indicateurs. Il vous faudra donc créer un prédicteur qui utilise les instructions conditionnelles
n'estPasNul() dans le générateur.

Comme expliqué ci-dessus, le fait que l'élément de données soit désagrégé ou non et la manière de
représenter la désagrégation en termes de complétude, dictent exactement la manière dont
l'expression du générateur doit être définie. Le tableau suivant présente chacune des approches
alternatives et l'expression de générateur à utiliser :

Expression de générateur avec exemple

d'élément de données

Élément de données sans désagrégation si( n'estPasNul(#{OWk2WulfJYQ}), 1, 0)

Élément de données avec désagrégation - analyse si( n'estPasNul(#{TWWbtMMWD51.JKuWbG5bWAu

d'une combinaison d'options de catégorie }), 1, 0)

Élément de données avec désagrégations - chaque si( n'estPasNul(#{TWWbtMMWD51.JKuWbG5bWAu

combinaison d'options de catégorie avec une valeur }), 1, 0) + si(
comme est considérée comme "déclarée" n'estPasNul(#{[Link]}), 1,
0)

Élément de données avec désagrégation - toutes les si( n'estPasNul(#{TWWbtMMWD51.JKuWbG5bWAu

combinaisons d'options de catégorie doivent avoir }) &&
une valeur pour que l'élément de données soit n'estPasNul(#{[Link]}), 1,
considéré comme "déclaré" 0)

Élément de données avec désagrégation : si une si( n'estPasNul(#{OWk2WulfJYQ}), 1, 0)

combinaison d'options de catégorie a une valeur,
l'élément de données est considéré comme "déclaré"

Après avoir décidé de l'approche à suivre, suivez ces étapes pour créer le prédicteur :

1. Créez votre élément de données de sortie.

2. Attribuez l'élément de données de sortie à votre prédicteur.

3. Définissez le type de période (généralement mensuelle).

4. Attribuez le niveau d'unité d'organisation pour l'analyse (généralement l'établissement).

5. Configurez le générateur comme suit.

6. Réglez le nombre d’échantillons séquentiels sur 0

7. Réglez le nombre d’échantillons annuels sur 0

8. N'inscrivez rien dans le champ consacré au nombre de sauts séquentiels.

9. Définissez le générateur à l'aide de l'une des expressions décrites ci-dessus.

124
Évaluation de la qualité des données Complétude des éléments de données

1. Créez un groupe de prédicteurs et ajoutez ce prédicteur à ce groupe.

Configuration du dénominateur - valeurs attendues

Bien que le numérateur d’un indicateur sur la complétude des éléments de données corresponde
toujours au nombre de données reçues (avec quelques variations dans la gestion des
désagrégations), il existe plusieurs façons de définir le dénominateur des "rapports attendus reçus".
Ces options sont :

1. Nombre d'unités d'organisation auxquelles le ou les ensembles de données dont l'élément de

données fait partie, est (sont) attribué(s)

2. Nombre d'unités d'organisations pour lesquelles le ou les ensembles de données dont fait
partie l'élément de données, a ou ont été marqué(s) comme "terminés" (déclarés)

3. Nombre de valeurs d'un autre élément de données déclarées faisant partie du même ensemble
de données

4. Nombre d'unités d'organisation ayant déjà produit des rapports sur l'élément de données

Le choix de ces options dépend de plusieurs facteurs contextuels, tels que le degré d'exactitude et de
mise à jour de l'affectation de l'ensemble de données et le fait de savoir si l'objectif est d'examiner la
complétude globale de l'élément de données (quelle proportion de la valeur réelle a été saisie) ou la
complétude au sein d'un ensemble de données (quel est le degré de complétude du formulaire de
rapport rempli par le personnel de l'établissement et les employés chargés de la saisie des données).
Chaque option est décrite ci-dessous, avec des instructions pour la configuration dans les versions
2.38 et supérieures, et 2.37 et inférieures.

Option 1 – Nombre d'unités d'organisation auxquelles le ou les ensembles de données dont l'élément de
données fait partie, est (sont) attribué(s)

La première option consiste à utiliser l’affectation de l’ensemble de données dont fait partie l’élément
de données comme base de calcul de la complétude. Cette mesure est assez similaire au
fonctionnement de la complétude de l'ensemble de données (taux de déclaration) [décrit ci-dessus]
(#configuration-de-la-complétude-de-l'élément-de-données). Cette option est facile à configurer,
puisque les "rapports attendus" d'un ensemble de données sont disponibles pour être utilisés

125
Évaluation de la qualité des données Complétude des éléments de données

directement dans les expressions d'indicateurs. La principale contrainte à l'utilisation des rapports
attendus pour un ensemble de données comme dénominateur pour la complétude des éléments de
données est que l'affectation de l'ensemble de données est supposée correcte et à jour.

Pour utiliser ceci comme dénominateur, choisissez simplement la variable rapports attendus qui est
disponible lors de la configuration du dénominateur de l'indicateur :

L'expression du dénominateur est R{[identifiant de l'élément de données].RAPPORTS_ATTENDUS},

par exemple R{tQc4Gv2Jwco.RAPPORTS_ATTENDUS}

Des précautions particulières doivent être prises dans les cas où le même élément de données est
déclaré dans plusieurs ensembles de données. Si les ensembles de données ne sont pas utilisés
dans les mêmes unités d'organisation, l'addition des rapports attendus pour chaque ensemble de
données donnera un dénominateur correct. Toutefois, s'il est possible que les mêmes unités
d'organisation se voient attribuer deux ensembles de données contenant un même élément de
données, cette option ne fournira pas de dénominateur fiable.

Option 2 – Nombre d'unités d'organisation pour lesquelles le ou les ensembles de données ont été reçus

L'option 2 est similaire à l'option 1, à la différence qu'elle utilise les rapports réels comme
dénominateur plutôt que les rapports attendus. En choisissant les rapports réels, on obtient un
indicateur qui évalue la complétude de l'élément de données parmi les unités d'organisation qui ont
déclaré des données, c'est-à-dire une mesure de la fréquence à laquelle un élément de données
particulier est alimenté dans les ensembles de données soumis.

126
Évaluation de la qualité des données Complétude des éléments de données

ici aussi, des précautions particulières doivent être prises dans les cas où le même élément de
données est déclaré dans plusieurs ensembles de données. Si les ensembles de données ne sont
pas utilisés dans les mêmes unités d'organisation, l'addition des rapports attendus pour chaque
ensemble de données donnera un dénominateur correct. Toutefois, s'il est possible que les mêmes
unités d'organisation se voient attribuer deux ensembles de données contenant un même élément de
données, cette option ne fournira pas de dénominateur fiable.

Option 3 – Nombre de valeurs d'un autre élément de données déclarées

Cette option repose sur l'utilisation du nombre de valeurs déclarées pour un autre élément de
données comme "valeurs attendues" dans le calcul de la complétude. Cet autre élément de données
peut être choisi en fonction de différents critères, décrits ci-dessous. Il convient de noter que lorsque
l'on examine la complétude d'un élément de données sur la base d'autres éléments de données, les
résultats doivent être analysés en même temps que la complétude globale de l'ensemble des
données.

En fonction d'un élément de données dans le même ensemble de données

Cette option est similaire à la précédente, à la différence qu'elle utilise un élément de données déclaré
dans le même ensemble de données ou la même section d'ensemble de données que l'élément de
données pour lequel vous calculez le taux de déclaration (numérateur) - sans qu'il y ait
nécessairement un lien logique entre eux. Avec cette approche, vous devez choisir un élément de
données qui est toujours (ou souvent) déclaré dans le même ensemble de données. Par exemple,
dans un ensemble de données sur la santé maternelle, il est probable que le nombre d'établissements

127
Évaluation de la qualité des données Complétude des éléments de données

de santé qui déclarent un élément de données pour les "premières visites de soins prénatals" soit plus
élevé que celui de l'"accouchement assisté", et les "premières visites de soins prénatals" constituent
donc une meilleure estimation du nombre de déclarations attendues.

En fonction d'un indicateur de base

Si l'élément de données pour lequel vous souhaitez obtenir un taux de déclaration est utilisé dans le
calcul d'un indicateur de performance clé avec des données régulièrement déclarées dans le
dénominateur, il est recommandé d'utiliser le nombre de valeurs déclarées pour le dénominateur afin
de calculer leur complétude. Cette option n'est pas viable si l'élément de données n'est pas utilisé
dans le calcul d'un indicateur ou si le dénominateur repose sur une estimation de la population ou une
autre valeur qui n'est pas déclarée avec la même périodicité que le numérateur.

À titre d'exemple, considérons l'indicateur Cas suspects de Paludisme testés (%) :

100 x (Paludisme cas testés / Cas suspects)

Dans ce cas, il peut être utile d'examiner la complétude de "Paludisme cas testés" avec le nombre de
cas suspects comme dénominateur.

L’avantage de cette option est qu’elle fournit une bonne indication de la complétude/cohérence des
données utilisées pour calculer un indicateur de base particulier.

En fonction d'un élément de données associé

Cette option est similaire à la précédente, à la différence qu'elle utilise un élément de données
étroitement lié à l'élément de données du numérateur pour calculer le dénominateur. Par exemple, si
vous voulez obtenir un taux de déclaration pour les cas de paludisme chez les patients hospitalisés de
moins de 5 ans (numérateur), vous pouvez envisager d'utiliser en guise de dénominateur le nombre
de cas de paludisme chez les patients hospitalisés de 5 ans et plus, de décès dus au paludisme chez
les patients hospitalisés, de cas de paludisme chez les patients non hospitalisés ou d'autres éléments
similaires.

Configuration

Veuillez vous référer à la section qui traite de la configuration du numérateur[LIEN] si vous utilisez un
élément de données associé en guise de dénominateur. Les mêmes considérations et étapes de
configuration s’appliquent.

Option 4 – Nombre d'unités d'organisation ayant déjà produit des rapports sur l'élément de données

La dernière option consiste à utiliser en guise de dénominateur le nombre d'établissements qui ont
déjà produit des rapports sur l'élément de données en question dans un délai donné. Ce
dénominateur est similaire à celui utilisé pour l'indicateur ["établissements produisant des rapports
réguliers"] (#unités-d'organisation-produisant-des rapports-réguliers). Il peut s'agir d'une bonne
estimation du nombre de rapports attendus, en particulier dans les cas où l'affectation de l'ensemble
des données n'est pas précise : si un établissement a déjà produit un rapport sur un élément de
données particulier, cela signifie généralement que l'établissement fournit le service/diagnostic
représenté par l'élément de données et que l'on peut s'attendre à ce qu'il produise régulièrement des
rapports sur cet élément. Toutefois, les résultats doivent être analysés en même temps que la
complétude de l'ensemble des données, car ils n'incluront pas les établissements censés produire des
rapports, mais qui ne l'ont pas fait au cours de la période donnée.

128
Évaluation de la qualité des données Complétude des éléments de données

Pour calculer le nombre de fois qu'une unité d'organisation a déclaré l'élément de données que vous
évaluez au cours de l'un des 12 derniers mois, nous devons utiliser un prédicteur et un élément de
données supplémentaire. Il s'agit du même calcul que pour le dénominateur décrit ci-dessus dans la
section [Etablissements produisant des rapports réguliers] (#unités-d'organisation-produisant-des
rapports-réguliers). En résumé, un prédicteur disposant d'un générateur

si(n'estPasNul([élément de données]**), 1, 0) **

et d'un nombre d'échantillons séquentiels défini en fonction du nombre de périodes précédentes que
vous voulez évaluer produira le nombre à utiliser comme dénominateur.

Analyse ad hoc de la complétude de plusieurs éléments de données

Les approches de calcul de la complétude des éléments de données décrites ci-dessus offrent
plusieurs possibilités quant à la définition exacte du numérateur et du dénominateur, et nous
permettent de générer des indicateurs pouvant être utilisés dans des graphiques, des cartes et des
tableaux sur un tableau de bord. Toutefois, étant donné que nous devons ajouter au moins un nouvel
objet de métadonnées pour chaque variable que nous voulons évaluer, il est préférable de les
configurer pour un sous-ensemble d'éléments de données clés.

Pour mieux comprendre la complétude des éléments de données pour un grand nombre d'éléments
de données au sein d'un ensemble de données, nous pouvons produire ceci dans l'application
Visualiseur de données sous forme de tableau croisé dynamique ou de graphique en suivant les
étapes suivantes :

1. Ouvrez Visualiseur de données et choisissez Tableau croisé dynamique comme type de

graphique
2. Comme Dimension de données, choisissez :
1. Les rapports attendus ou existants pour un ensemble de données particulier
2. Tout ou partie des éléments de données au sein du même ensemble de données,
utilisant l'option "Détails uniquement" pour la désagrégation
3. Modifiez la présentation en plaçant les Périodes sous forme de colonnes (par exemple pour les
12 derniers mois) et les Données sous forme de lignes.

1. Ouvrez le menu Options et

2. Activez les Totaux de ligne

3. Dans la section Avancé, définissez le type d'agrégation sur "Nombre"

4. Mettez à jour la visualisation et triez éventuellement la colonne des totaux de haut en bas
(remarque : le total des "rapports attendus" indiquera NaN, mais restera en haut).

129
Évaluation de la qualité des données Complétude des éléments de données

Le tableau obtenu affiche désormais sur la ligne supérieure le "dénominateur" de la complétude des
éléments de données, c'est-à-dire les rapports attendus pour l'ensemble de données (les rapports
existants peuvent également être utilisés). Les autres lignes affichent le "numérateur" de la
complétude des éléments de données pour chaque élément de données (avec désagrégation). Ce
tableau vous permet d'examiner rapidement la complétude d'un grand nombre d'éléments de données
au sein d'un ensemble de données.

En suivant la même approche (en utilisant le type d'agrégation "Nombre"), si vous examinez une seule
période, un graphique à barres trié de haut en bas donnera un aperçu rapide de la complétude des
éléments de données.

130
Évaluation de la qualité des données Cohérence de données associées

Cohérence de données associées

Nuages de points dans Visualiseur de données

131
Évaluation de la qualité des données Nuages de points dans Visualiseur de données

Il s'agit d'un nuage de points dans lequel une analyse est effectuée pour les valeurs atypiques ou pour
deux variables associées au niveau de l'établissement. Les deux variables sur ce graphique sont liées
l'une à l'autre - CPN 1 et CPN 4 - et c'est la raison pour laquelle plusieurs valeurs sont étroitement
regroupées en vert.

L'analyse des valeurs atypiques dans Visualiseur de données à l'aide de nuages de points vous
permet de savoir si des valeurs associées s'inscrivent dans un modèle attendu ou si elles s'en
écartent d'une manière ou d'une autre. Les valeurs en rouge sur le graphique ne correspondent pas
au modèle attendu, et plus ces valeurs en rouge sont éloignées des lignes de valeurs atypiques, plus
il est probable qu'un problème sous-jacent empêche ces valeurs de correspondre correctement au
modèle attendu.

Ces nuages de points peuvent utiliser différentes méthodes pour identifier ces valeurs atypiques, et
chacune de ces méthodes a différents niveaux de sensibilité (c'est-à-dire que chacune détectera plus
ou moins les valeurs atypiques en fonction de leur calcul). Les différentes méthodes actuellement
disponibles sont

• Écart interquartile
• Z-score
• Z-score modifié

Le Z-score a été inclus car il s'agit d'une méthode bien comprise ; cependant, c'est la moins sensible
des 3 méthodes.

Créer un nuage de points

Des nuages de points peuvent être créés dans l'application Visualiseur de données.

Démarrez le processus en sélectionnant le nuage de points dans le sélecteur de visualisation dans

Visualiseur de données.

Vérifiez la présentation après avoir sélectionné ce type de graphique. Certains éléments sont
verrouillés, ce qui le différencie d'autres graphiques. Vous devez sélectionner des éléments de
données pour les axes vertical (Y) et horizontal (X) du graphique. Les points représenteront toujours

132
Évaluation de la qualité des données Nuages de points dans Visualiseur de données

les unités d'organisation. Comme indiqué, pour ce type de graphique, vous devez sélectionner des
éléments de données associés. Si vous sélectionnez des éléments de données non associés, il est
peu probable que votre résultat soit pertinent.

Sélectionnez vos données verticales et horizontales. Nous sélectionnerons CPN 1 et CPN 4 car ils
sont associés (par exemple, vous verrez généralement moins de CPN 4 que de CPN 1 sur une
période identifiée).

Sélectionnez votre unité d'organisation (dans ce cas, tous les établissements)

133
Évaluation de la qualité des données Nuages de points dans Visualiseur de données

Sélectionnez votre période

Mettez à jour votre graphique.

134
Évaluation de la qualité des données Nuages de points dans Visualiseur de données

Vous verrez maintenant le nuage de points entre ces deux éléments liés. Nous pouvons voir à quel
point elles sont étroitement regroupées dans le coin inférieur gauche du graphique, car c’est là que se
trouvent la majorité des valeurs. Nous n'avons pas encore ajouté nos valeurs atypiques à ce
graphique ; nous pouvons le faire comme prochaine étape.

Ajouter des valeurs atypiques

Pour ajouter des valeurs atypiques, sélectionnez les options du graphique et la section "valeurs
atypiques"

Activez à la fois l’analyse des valeurs atypiques et les lignes extrêmes.

Pour l’analyse des valeurs atypiques, nous utiliserons la méthode de l'écart interquartile. Il s'agit d'une
méthode de détection des valeurs atypiques qui peut être appliquée aux données de nuages de
points. Pour plus d'informations, consultez la référence ci-après : [Link]
outliers-in-data-and-ways-to-detect-them-1c3a5f2c6b1e

Vous n’avez pas besoin de comprendre complètement cette méthode de détection de valeurs
atypiques. Notez simplement que les 3 méthodes détecterons les valeurs atypiques en vérifiant si
elles correspondent à un modèle tel que décrit par les différentes méthodes sélectionnées.

Vous pouvez également sélectionner l’option "Lignes extrêmes". Cela vous aidera à identifier les
valeurs atypiques les plus extrêmes, lesquelles contiennent souvent des erreurs.

135
Évaluation de la qualité des données Nuages de points dans Visualiseur de données

Après avoir sélectionné ces options, mettez à jour votre graphique.

Voyons comment nous pouvons interpréter notre sortie. Tout d’abord, agrandissons l'écran (zoom) sur
notre groupe de valeurs pour les examiner de plus près. Nous pouvons le faire en faisant glisser le
curseur de notre souris sur la zone que nous voulons agrandir.

136
Évaluation de la qualité des données Nuages de points dans Visualiseur de données

Nous pouvons revenir à l'écran normal si nécessaire en sélectionnant "réinitialiser le zoom".

Examinez l’une des valeurs atypiques mise en évidence en rouge

Le modèle de ces données est très étroit (c'est-à-dire que la plupart des valeurs sont étroitement
regroupées). Cependant, certaines valeurs sont très éloignées des limites des valeurs atypiques.
Aucune de ces valeurs ne peut être considérée comme atypique en soi (il existe d'autres valeurs de
CPN 1 et de CPN 4 qui sont plus élevées). Cependant, cette paire de valeurs que nous avons mise en
évidence sur le graphique ci-dessus se situe en dehors de la fourchette de 1 % du total des valeurs y
(qui représente la CPN 1). Cela s'explique par le fait qu'une valeur de CPN 4 typique dans cette
fourchette a une valeur de CPN 1 beaucoup plus faible par rapport à la majorité des autres données.

En examinant ce type de graphique, vous devez donc examiner la relation entre les deux éléments
comparés et également comparer les valeurs au groupe qui se situe dans les limites du modèle des
valeurs atypiques. Dans ce cas, les valeurs de CPN 1 ou de CPN 4 pourraient être incorrectes (si
nous diminuons les valeurs de CPN 1 OU si nous augmentons les valeurs de CPN 4, cet

137
Évaluation de la qualité des données Analyse des règles de validation

établissement s'intégrera probablement dans le modèle en conséquence) ; ou il pourrait simplement

s'agir d'une anomalie caractérisée par un ratio différent entre CPN 1 et CPN 4, supérieur au seuil de
l'écart interquartile de 1,5 qui a été défini (c'est-à-dire que ces valeurs sont correctes et n'ont pas
besoin d'être modifiées). Il est cependant plus probable que la valeur de CPN 1 soit à l'origine du
problème, car la majorité des valeurs de CPN 4 dans cette fourchette ont une valeur de CPN 1
inférieure. Cependant, comme il s'agit d'une valeur atypique très élevée par rapport au reste des
données (étant donné sa distance par rapport à la limite des valeurs atypiques et le fait qu'elle se situe
en dehors de la ligne de 1% des valeurs y), il convient de vérifier si ces valeurs sont correctes au sein
de cet établissement.

Analyse des règles de validation

Les règles de validation sont intégrées dans les applications de saisie de données de DHIS2 et
peuvent être consultées pendant la saisie des données [LIEN vers la section ci-dessus]. Les violations
des règles de validation peuvent également être visualisées dans la section Analyse des règles de
validation de l'application Qualité des données. Au lieu de les examiner pour une unité d'organisation,
une période et un ensemble de données spécifiques, vous pouvez les examiner pour un grand
nombre d'unités d'organisation sur une période donnée. Cela permet également aux utilisateurs qui ne
saisissent pas de données, ou qui n'ont même pas accès à l'application Saisie de données, d'analyser
et de contrôler les violations des règles de validation.

Lorsque vous examinez les règles de validation avec cette méthode, il est préférable de diviser vos
règles de validation en groupes de règles de validation. La configuration de ces groupes est présentée
dans la section consacrée aux groupes de règles de validation.

Pour exécuter l'analyse des règles de validation, ouvrez l'application Qualité des données et
sélectionnez "Exécuter la validation"

Applications -> Qualité des données

Sélectionnez "Exécuter la validation" sous l'en-tête "Analyse des règles de validation"

138
Évaluation de la qualité des données Analyse des règles de validation

À partir de là, vous devrez sélectionner vos entrées. Cela comprend les éléments suivants :

• L'unité d'organisation
• La date de début et la date de fin. Elles définissent la période que vous examinez.
◦ Pour la période, les dates de début et de fin doivent couvrir entièrement la période que
vous voulez examiner. Si vous voulez consulter des données mensuelles, votre date de
début devra être le 1er du mois, et votre date de fin le 1er du mois suivant. Par exemple,
sur cette capture d'écran, les données de juin 2023 à août 2023 sont en cours d'examen.
• Le groupe de règles de validation. Il doit contenir les règles de validation que vous voulez
examiner
• Envoyer des notifications : cela enverra toutes les notifications de validation en fonction des
violations de validation trouvées
• Conserver les nouveaux résultats

Une fois les données d'entrée sélectionnées, cliquez sur "Valider". L'exécution de l'analyse de
validation peut prendre un certain temps en fonction de la quantité de données que vous avez choisi
d'examiner. Si vous prévoyez d'examiner beaucoup de données à la fois (par exemple, plusieurs
unités d'organisation sur plusieurs périodes, y compris plusieurs règles de validation), l'analyse des
règles de validation prendra plus de temps que si vous l'exécutez pour moins de données.

Si aucune violation des règles de validation n'a été détectée, vous verrez un message "Validation
réussie". Par contre, si des violations sont détectées, elles seront présentées dans une liste comme
suit :

139
Évaluation de la qualité des données Analyse des règles de validation

Pour consulter les détails de la validation, sélectionnez le bouton d'information sous la colonne des
détails.

Une fenêtre contextuelle s'ouvrira avec plus d'informations sur la violation.

140
Évaluation de la qualité des données Analyse des règles de validation

Nous pouvons voir l'importance de l'analyse des règles de validation dans l'examen des violations
pour plusieurs unités d'organisation/périodes à la fois, car tous les éléments constitutifs de la violation
sont également présentés. Cela peut nous permettre d'identifier exactement quelle valeur est
incorrecte et nécessite un suivi plus approfondi.

Les détails de validation affichent le nom et la description de la violation ainsi que tous les éléments
de données qui font partie de la règle de validation ainsi que leurs valeurs.

Vous pouvez également télécharger ces violations de règles de validation. Vous pourrez vous y
référer et effectuer un suivi des valeurs pour les corriger au fil du temps. Pour ce faire, sélectionnez
l'un des types de fichiers dans l'angle supérieur droit après avoir exécuté l'analyse de validation.

141
Évaluation de la qualité des données Cohérence au fil du temps

Cohérence au fil du temps

[section à venir]

Graphiques annuels

Il s'agit d'un graphique annuel (linéaire). Ce type de graphique est utilisé pour évaluer la cohérence au
fil du temps pour un type de données spécifique (élément de données, indicateur, etc.). Dans cet
exemple, nous affichons les données relatives aux visites de CPN 1 pour les 12 mois de l'année pour
les années 2023, 2022 et 2021. Ce graphique nous permet d'identifier facilement les valeurs
atypiques évidentes, car nous sommes en mesure de voir les augmentations ou les diminutions (si
elles existent) assez facilement par rapport aux données actuelles et précédentes. À titre d'exemple,
vous pouvez voir des valeurs atypiques évidentes en janvier 2023, mai 2022 et septembre 2023 en
examinant chacune des lignes de ce graphique et en les comparant à leurs propres tendances
historiques. L'étape suivante consistera à prendre ce graphique et à approfondir la hiérarchie pour ces
périodes spécifiques afin de trouver la source de ces valeurs atypiques. Ces graphiques pourraient
être placés sur un tableau de bord pour les principales variables de votre flux de travail afin de
permettre au personnel de les examiner régulièrement en fonction de la fréquence à laquelle les
données sont collectées.

Pour créer cette visualisation, vous utiliserez l'application Visualiseur de données

142
Évaluation de la qualité des données Graphiques annuels

Sélectionnez "d'une année sur l'autre" (linéaire) pour commencer à créer ce graphique

L'interface - Sélection des périodes et filtre

Après avoir sélectionné ce type de graphique, nous constatons que la catégorie et la série sont
automatiquement renseignées avec des types de période. La sélection des périodes dans le menu de
gauche, où d'autres dimensions sont sélectionnées, est également grisée. Les unités d'organisation et
les données sont automatiquement placées dans le filtre. C'est pourquoi ce type de graphique
fonctionne mieux lorsqu'un seul élément de données est sélectionné pour comparaison. Toutefois,
plusieurs unités d'organisation peuvent être utilisées dans le filtre en fonction de ce que vous voulez
afficher (les données appartenant à ces unités d'organisation seront filtrées).

143
Évaluation de la qualité des données Graphiques annuels

L'interface - Catégorie

Dans cet exemple, la catégorie détermine les périodes qui seront affichées le long de l'axe des x et
regroupera les données. Ainsi, en sélectionnant "mois par an", tous les mois d'une année, de janvier à
décembre, seront affichés. Si nous sélectionnons "Trimestres par an", les 4 trimestres d'une année
seront affichés le long de l'axe des x.

Vous remarquerez que les sélections dans les catégories sont toutes des périodes relatives. Vous ne
pouvez donc pas sélectionner par exemple des mois spécifiques dans la catégorie dans ce type de
graphique.

144
Évaluation de la qualité des données Graphiques annuels

L'interface - Série

La série détermine les années pour lesquelles vous afficherez les données. Si je sélectionne cette
année et l'année dernière, elles seront affichées respectivement en fonction de la date actuelle. Je
peux également spécifier des années plutôt qu'une période relative, par exemple 2021, 2022 et 2023.

145
Évaluation de la qualité des données Graphiques annuels

Avec ces deux options sélectionnées, je peux maintenant créer un graphique qui affichera les
données de janvier à décembre (en raison de la sélection de catégorie) le long de l'axe des x. Et avec
2021, 2022 et 2023 sélectionnés comme série, les données de ces 3 années seront affichées par
mois sur le graphique "annuel".

L'interface - Données

Lors de la sélection des données, il est préférable de ne sélectionner qu'un seul élément de données.
Vous pouvez aussi choisir des groupes ou des désagrégations pour filtrer davantage les données.
Cependant, étant donné que les données sélectionnées sont automatiquement ajoutées au filtre et ne
peuvent pas être déplacées, l'ajout de plus d'une donnée n'affectera pas le graphique.

146
Évaluation de la qualité des données Valeurs statistiques atypiques dans les séries chronologiques

Mettre à jour et réviser le graphique

Nous pouvons maintenant mettre à jour notre graphique. Dans ce cas, nous utilisons l'unité
d'organisation du pays par défaut, mais nous pouvons la modifier si nécessaire.

Nous pouvons voir comment le graphique a été généré sur la base de notre sélection de catégorie et
de période de série ainsi que de la sélection de notre élément de données (dans ce cas, CPN 1ère
visite).

La série détermine les années pour lesquelles nous affichons les données, tandis que la catégorie
détermine comment regrouper les données le long de l'axe des x.

Valeurs statistiques atypiques dans les séries chronologiques

Les "valeurs atypiques extrêmes" sont des valeurs très suspectes dont l'exactitude doit être vérifiée.
Elles diffèrent des valeurs normalement déclarées par un établissement de santé. Si les valeurs
atypiques extrêmes s'avèrent incorrectes, elles doivent être modifiées conformément aux procédures

147
Évaluation de la qualité des données Valeurs statistiques atypiques dans les séries chronologiques

locales qui définissent la manière dont les valeurs des données doivent être modifiées. Dans cette
section, nous montrons comment les valeurs atypiques dans la dimension temporelle peuvent être
identifiées dans DHIS2 à l'aide de prédicteurs et de la fonction analyse des valeurs atypiques. Nous
précisons au fil du temps pour marquer la différence avec les valeurs atypiques décrites dans la
section sur les [nuages de points] (#nuages-de-points dans-Visualiseur-de-données), lesquelles
identifient les unités d'organisation qui sont des valeurs atypiques pour une seule période.

Les deux fonctions présentées pour identifier les valeurs atypiques présentent chacune certains
avantages. L'application DHIS2 Qualité des données permet d'effectuer des analyses en masse
(c'est-à-dire pour un grand nombre de variables en même temps) sans configuration préalable. Elle
permet aux utilisateurs de choisir différentes méthodes statistiques pour le calcul des valeurs
atypiques et de les exécuter sur tout ensemble de données et toute combinaison de périodes. Elle est
donc à la fois flexible et puissante, mais les utilisateurs doivent ouvrir l'application, choisir les
paramètres appropriés et attendre que l'analyse se termine. En utilisant les prédicteurs pour calculer
les seuils des valeurs atypiques et les éléments de données et indicateurs associés, nous pouvons
générer des notifications, consulter ces valeurs sur le tableau de bord ou les utiliser en combinaison
avec d'autres fonctionnalités de DHIS2, telles que les règles de validation. Il en résulte une plus
grande flexibilité dans la manière de mettre les résultats de l'analyse des valeurs atypiques à la
disposition des utilisateurs, mais cela nécessite la configuration de plusieurs objets de métadonnées
pour chaque variable que nous voulons évaluer. Les deux méthodes doivent donc être considérées
comme complémentaires.

Analyse des valeurs atypiques avec des prédicteurs et des indicateurs

Note
Dans le cadre d'une implémentation réelle, les prédicteurs peuvent
nécessiter beaucoup de ressources et il convient de prendre des
précautions particulières pour tester le système DHIS2 afin de s'assurer
qu'il est en mesure de générer des prédicteurs de manière continue et
régulière, à mesure que de nouvelles données sont ajoutées, avant
l'implémentation réelle. En outre, même après la génération de nouvelles
données par le prédicteur, les données ne seront pas visibles tant que le
système d'analyse n'aura pas été mis à jour ; il s'agit là d'une autre étape
qui peut prendre beaucoup de temps en fonction de la taille du système.
Par conséquent, il faudra probablement faire preuve de patience et
marquer de longues pauses la première fois que vous suivrez ces
instructions. Il est important de reproduire et de tester les prédicteurs
sur des systèmes de développement en premier lieu, afin qu'ils
puissent être testés en profondeur sans affecter un système de
production.

Prédicteurs fournit des fonctionnalités génériques dans DHIS2, et nous montrerons comment les
appliquer à des fins de détection et d'analyse de valeurs atypiques. Bien que le processus initial de
création de prédicteurs puisse prendre du temps, une fois que vous avez configuré avec succès un
élément de données/indicateur et confirmé que les sorties résultantes sont correctes, le processus de
configuration de chaque élément de données ou indicateur subséquent devrait prendre moins de
temps.

148
Évaluation de la qualité des données Valeurs statistiques atypiques dans les séries chronologiques

La configuration des prédicteurs pour la détection des valeurs atypiques nécessite deux ensembles de
prédicteurs :

• un prédicteur pour calculer le seuil de valeurs atypiques. Ceci est défini à partir de l'analyse des
données précédemment déclarées et de la définition de seuils au-delà desquels les valeurs
sont considérées comme atypiques (pour une combinaison d'éléments de données et d'unités
d'organisation).

• un ou plusieurs prédicteurs qui utilisent le seuil de valeurs atypiques dans d'autres calculs, par
exemple dans le comptage du nombre d'établissements qui ont déclaré des valeurs atypiques,
dans l'attribution de valeurs atypiques ou non à des éléments de données distincts pour
analyse, etc.

Étant donné que les prédicteurs produisent des valeurs de données qui doivent être stockées avant
d'être utilisées dans d'autres calculs, chaque nouveau prédicteur doit être associé à un élément de
données. Ces éléments de données pourraient être organisés en un ou plusieurs nouveaux
ensembles de données.

Il existe plusieurs possibilités concernant les prédicteurs, les éléments de données et les indicateurs
qui peuvent être configurés pour chacune des variables que vous voudriez analyser/surveiller :

• Seuil de valeurs atypiques (prédicteur/élément de données)

• Nombre de valeurs qui sont atypiques (prédicteur/élément de données)

• Nombre de valeurs qui ne sont pas atypiques (prédicteur/élément de données)

• Valeurs atypiques (%) (indicateur)

• Valeurs qui sont atypiques (prédicteur/élément de données)

• Valeurs qui ne sont pas atypiques (prédicteur/élément de données)

• Données excluant des valeurs atypiques (indicateur)

Ils sont définis et expliqués plus en détail ci-dessous. Tout d'abord, il est important de comprendre
comment se déroule le flux de données pour ces objets de métadonnées, comme le montre la figure
ci-dessous.

Les prédicteurs doivent être programmés par le système, tout comme le processus analytique. La
programmation est donc essentielle pour que cela fonctionne. Pour que les indicateurs soient
disponibles pour les utilisateurs finaux, nous devons d'abord exécuter le premier ensemble de

149
Évaluation de la qualité des données Valeurs statistiques atypiques dans les séries chronologiques

prédicteurs (calcul des seuils), puis le deuxième ensemble de prédicteurs, et enfin le processus
d'analyse normal pour que les ensembles de données et les indicateurs soient disponibles dans
Visualiseur de données et d'autres outils d'analyse. Ce point est abordé plus en détail [ici]
(#programmation).

Prédicteur du seuil de valeurs aberrantes

Nous commençons par la configuration du prédicteur et de l'élément de données qui calcule le seuil
de valeurs atypiques pour une variable particulière, qu'il s'agisse d'un élément de données (par
défaut/total) ou d'une désagrégation particulière (combinaison d'options de catégorie). Dans l'exemple
suivant, nous utiliserons Paludisme cas confirmés.

Étapes de configuration

1. Créez un élément de données pour stocker la valeur du seuil de valeur atypique :

◦ Nom : "DQ - Paludisme seuil de valeurs atypiques des cas confirmés (moyenne + 3
écarts-types)"

◦ Description : "Généré automatiquement à partir du prédicteur. Seuil de valeurs atypiques

pour l'élément de données Paludisme cas confirmés (total pour toutes les
désagrégations), basé sur la moyenne + 3 écarts-types au cours des 12 mois
précédents. Cela peut être utilisé pour identifier les potentielles valeurs atypiques.

◦ Type : Agrégé

◦ Type de valeur : Entier positif ou nul

2. Créez un nouveau prédicteur avec des propriétés de base :

◦ Nom : "DQ - Paludisme seuil de valeurs atypiques des cas confirmés (moyenne + 3
écarts-types)"

◦ Description : "Génère le seuil de valeurs atypiques pour Paludisme cas confirmés, défini
comme la moyenne + 3 écarts-types, sans compter les valeurs du mois dernier."

3. Définissez l’Élément de données de sortie pour qu’il renvoie à l’élément de données créé à
l’étape 1.

4. Définissez le Type de période pour qu'il corresponde à la fréquence de collecte de données de

l'élément de données que nous évaluons. Pour notre exemple Paludisme cas confirmés, la
collecte est Mensuelle.

5. Définissez les Niveaux d'unités d'organisation sur le niveau où les données sont collectées.
Dans la plupart des cas, ce sera Établissement.

150
Évaluation de la qualité des données Valeurs statistiques atypiques dans les séries chronologiques

1. Configurez le Générateur, qui est l'expression qui définit le calcul effectué par le prédicteur.

◦ Définissez la Stratégie de valeurs manquantes sur Ignorer si toutes les valeurs sont
manquantes.

◦ L'expression dans ce cas devrait être :

avg({élément_de données_uid}) + (3 * stddevPop({élément_de données_uid}))

avg() nous donne la moyenne de l'élément de données au cours des périodes que nous évaluons
(définies à l'étape suivante). stddevPop() nous donne l'écart-type basé sur la population pour l'élément
de données au cours des périodes que nous évaluons, et nous le multiplions par 3 puisque nous
voulons que les seuils soient de 3 écarts-types au-dessus de la moyenne. Nous utilisons 3 ici parce
qu'il est souvent utilisé comme définition des valeurs atypiques extrêmes, mais d'autres valeurs
peuvent être utilisées.

151
Évaluation de la qualité des données Valeurs statistiques atypiques dans les séries chronologiques

1. Enfin, définissez le Nombre d'échantillons séquentiels. Ceci définit le nombre de périodes de

données antérieures à inclure dans le calcul. Dans ce cas, les données sont mensuelles
(définies à l'étape 4), et nous voulons utiliser 1 an de données antérieures pour calculer le seuil.
Nous fixons donc cette valeur à 12. Le nombre d'échantillons annuels et le nombre de sauts
séquentiels doivent être 0 (valeur par défaut).

152
Évaluation de la qualité des données Valeurs statistiques atypiques dans les séries chronologiques

Prédicteurs pour les mesures de valeurs atypiques

Lorsque le seuil de valeurs atypiques est défini et stocké en tant que valeur d'élément de données,
nous pouvons créer des prédicteurs supplémentaires pour effectuer des calculs plus spécifiques. Ces
prédicteurs sont configurés de la même manière, à l'exception de l'expression du générateur. Nous
décrivons les étapes générales de la création des prédicteurs une fois, tandis que l'expression réelle
pour chacun des prédicteurs spécifiques est fournie dans le tableau ci-dessous.

Nous verrons comment créer quatre prédicteurs/éléments de données différents à l'aide du seuil de
valeurs atypiques :

Élément de données excluant les valeurs atypiques Valeurs d'éléments de données qui ne sont pas
atypiques

Valeurs atypiques d'éléments de données Valeurs d'éléments de données qui sont atypiques.

Nombre de valeurs non atypiques d'éléments de données Nombre de valeurs d'éléments de données
qui ne sont pas atypiques.

Nombre de valeurs atypiques d’éléments de données Nombre de valeurs d’éléments de données qui
sont atypiques.

L'exemple suivant (avec CPN 1ère visite comme élément de données que nous évaluons) montre
pour une série chronologique quel résultat les différents prédicteurs sont censés produire

Jan Fév Mar Avr Mai juin Juillet

CPN 1 165 196 214 204 219 4243 195

CPN 1 253 265 253 244 242 246 4716

seuil de
valeurs
atypiques

CPN 1 165 196 214 204 219 195

excluant
les
valeurs
atypiques

CPN 1 4243
valeurs
atypiques

CPN 1 1 1 1 1 1 1
nombre
de
valeurs
non
atypiques

CPN 1 1
nombre
de
valeurs
atypiques

153
Évaluation de la qualité des données Valeurs statistiques atypiques dans les séries chronologiques

Pour configurer ces prédicteurs, suivez ces étapes générales après avoir créé des éléments de
données auxquels les valeurs peuvent être attribuées :

1. Créez un nouveau prédicteur

2. Définissez l'Élément de données de sortie pour qu'il renvoie à l'élément de données qui a été
créé.

3. Définissez le Type de période pour qu'il corresponde à la fréquence de collecte de données de

l'élément de données que nous évaluons.

4. Définissez les Niveaux d'unités d'organisation sur le niveau où les données sont collectées.
Dans la plupart des cas, ce sera Établissement.

5. Configurez le Générateur, en utilisant l'expression appropriée du tableau ci-dessous

6. Définissez le Nombre d'échantillons séquentiels sur 1, le Nombre d'échantillons annuels sur 0

et le Nombre de sauts séquentiels sur 0.

Ce tableau fournit les expressions qui doivent être utilisées dans le Générateur des différents
prédicteurs :

Prédicteur Expression Exemple Explication

Élément de données si ({DE} <= {DE seuil}, si(#{KV1LlPytf4f} Si la valeur de l'élément

excluant les valeurs {DE}, 0) <=#{dx8Y0ZrHji7}, de données est
atypiques #{KV1LlPytf4f}, 0) inférieure au seuil,
utilisez la valeur de
l'élément de données,
sinon 0.

Valeurs atypiques si( {DE} > {DE seuil}, si(#{KV1LlPytf4f} > Si la valeur de l'élément
d'éléments de données {DE}, 0) #{dx8Y0ZrHji7}, de données est
#{KV1LlPytf4f}, 0) supérieure au seuil,
utilisez la valeur de
l'élément de données,
sinon 0.

Nombre de valeurs non- si ({DE} <= {DE seuil}, si(#{KV1LlPytf4f} Si la valeur de l'élément
atypiques d'éléments 1, 0) <=#{dx8Y0ZrHji7}, 1, 0) de données est
de données inférieure au seuil,
renvoyez 1, sinon 0.

Nombre de valeurs si ({DE} > {DE seuil }, 1, si(#{KV1LlPytf4f} Si la valeur de l'élément

atypiques d'éléments 0) >#{dx8Y0ZrHji7}, 1, 0) de données est
de données supérieure au seuil,
renvoyez 1, sinon 0.

Les éléments de données alimentés par ces prédicteurs peuvent être utilisés directement dans les
visualisations et les tableaux de bord, par exemple en comparant les valeurs déclarées au seuil, en
affichant un compteur du nombre de valeurs atypiques signalées au cours du mois précédent ou en
générant des tableaux qui mettent en évidence les valeurs atypiques spécifiques par établissement.

154
Évaluation de la qualité des données Valeurs statistiques atypiques dans les séries chronologiques

Indicateurs pour l'analyse des valeurs atypiques{ #indicators-for-outlier-analysis }

Lorsque les prédicteurs et les éléments de données sont configurés pour la mesure de la qualité de
ces éléments de données de base présents ci-dessus, nous pouvons définir deux indicateurs :

Pourcentage de valeurs atypiques pour un élément de données particulier :

Numérateur : nombre de valeurs atypiques

Dénominateur : nombre de valeurs atypiques + nombre de valeurs non atypiques

Facteur : 100

Objectif : mesure de la qualité des données ; peut être utilisé pour examiner des comparaisons
géographiques ou des changements au fil du temps

Valeur excluant les valeurs atypiques en pourcentage de la valeur globale pour un élément de
données particulier.

Numérateur : les valeurs de l'élément de données qui ne sont pas atypiques

Dénominateur : toutes les valeurs de l'élément de données

Facteur : 100

Objectif : mesure de l'importance des valeurs atypiques sur la valeur globale d'un élément de
données. Elle peut être utilisée à la fois pour les tendances temporelles et les comparaisons
géographiques. Elle montre également l'importance des valeurs atypiques sur les données en
général, ce qui est un aspect à prendre en compte lors de l'analyse des données.

La configuration de ces indicateurs est simple une fois que les prédicteurs/éléments de données sous-
jacents sont disponibles (les options a et b ci-dessous font référence à chacun des indicateurs ci-
dessus)

1. Créez un nouvel indicateur avec un nom et une description appropriés. La description est
importante ici car ces indicateurs peuvent être nouveaux pour la plupart des utilisateurs.

2. Définissez le type d'indicateur sur Pourcentage (le nom exact peut varier, mais le facteur du
type d'indicateur doit être 100)

3. Configurez le numérateur

a. Nombre de valeurs atypiques (exemple : Paludisme nombre de valeurs atypiques pour les
cas confirmés)

b. Valeurs excluant les valeurs atypiques (exemple : Paludisme cas confirmés excluant les
valeurs atypiques)

4. Configurez le dénominateur

155
Évaluation de la qualité des données Valeurs statistiques atypiques dans les séries chronologiques

a. Nombre de valeurs atypiques + nombre de valeurs non atypiques (exemple : Paludisme

nombre de valeurs atypiques pour les cas confirmés + Paludisme nombre de valeurs non
atypiques pour les cas confirmés)

b. Valeurs des éléments de données (exemple : Paludisme cas confirmés)

5. Sauvegardez l'indicateur et attribuez-le aux groupes appropriés

Ces indicateurs peuvent désormais être utilisés dans des visualisations et des tableaux de bord. Les
utilisateurs peuvent ainsi surveiller facilement les tendances des valeurs atypiques, effectuer des
comparaisons géographiques et surveiller l'impact global des valeurs atypiques sur l'élément de
données en question.

Analyse des valeurs atypiques dans DHIS2

Il n’est pas réaliste de configurer un ensemble de prédicteurs, d’éléments de données et d’indicateurs

pour chaque élément de données. L'analyse des valeurs atypiques dans l'application Qualité des
Données permet d'exécuter une analyse des valeurs atypiques sur des ensembles de données et
constitue donc un complément utile aux contrôles des valeurs atypiques sur la base des prédicteurs.

Pour exécuter une analyse des valeurs atypiques, ouvrez l'application Qualité des Données et cliquez
sur "Analyser" situé sous "Détection des valeurs atypiques".

Commencez par sélectionner les paramètres clés pour l’analyse :

• Ensemble de données : choisissez un ou plusieurs ensembles de données à inclure dans

l'analyse.

• Unités d'organisation : choisissez une ou plusieurs unités d'organisation à inclure dans

l'analyse. Toutes les unités d'organisation situées en dessous des unités sélectionnées seront
incluses.

• Dates de début et de fin - les périodes comprises dans cette fourchette de dates seront
incluses. Notez que ce sont les périodes que nous analysons pour détecter les données
atypiques. Les données de toutes les périodes pour une unité d'organisation et un élément de
données particuliers sont incluses dans le calcul de la moyenne et de l'écart-type, sauf
indication contraire (voir les options avancées ci-dessous).

156
Évaluation de la qualité des données Valeurs statistiques atypiques dans les séries chronologiques

Ensuite, spécifiez les méthodes et paramètres statistiques à utiliser pour l’analyse.

• Algorithme :

◦ Z-score - détection des valeurs atypiques sur la base des écarts types par rapport à la
moyenne. Pour plus d'informations [[sur le z-score]{.ul}], visitez cette page (https://
[Link]/wiki/Standard_score).

◦ Z-score modifié - détection des valeurs atypiques sur la base des écarts types par
rapport à la médiane.

◦ Min-max - basées sur les valeurs minimum et maximum, abordées ici

• Seuil - le nombre d'écarts types qu'une valeur doit avoir par rapport à la moyenne/médiane
avant qu'elle soit considérée comme atypique. La valeur par défaut est 3, qui est souvent
utilisée comme définition par défaut d'une valeur atypique "extrême".

• Max results - le nombre maximum de valeurs atypiques qui seront incluses dans le tableau des
résultats.

157
Évaluation de la qualité des données Valeurs statistiques atypiques dans les séries chronologiques

À titre facultatif, modifiez les options avancées :

• Dates de début et de fin des données : elles vous permettent de limiter les données utilisées
comme base pour calculer la moyenne/médiane et les écarts types, en remplaçant les options
par défaut qui elles incluent toutes les données. A noter qu'un certain nombre de périodes sont
nécessaires pour que les calculs statistiques soient significatifs.

• Trier par – spécifie comment les résultats sont triés, avec deux options

◦ Écart absolu par rapport à la médiane/moyenne (par défaut) - ceci permet de trier le
tableau des valeurs atypiques en fonction de l'écart absolu entre la valeur atypique et la
médiane/moyenne. En général, cela signifie que les valeurs atypiques les plus
significatives/ayant le plus d'impact sur le résultat sont affichées en premier.

◦ Z-score/Z-score modifié - cette fonction trie le tableau en fonction du z-score, c'est-à-dire

du " caractère extrême " de la valeur atypique. Cela signifie qu'une valeur relativement
faible (provenant d'un petit établissement) peut être affichée avant une valeur beaucoup
plus importante (provenant d'un grand établissement), si la valeur la plus faible est plus
éloignée de la moyenne/ médiane.

Enfin, cliquez sur "Démarrer" pour exécuter l'analyse. En fonction des paramètres sélectionnés et de
la taille de la base de données, cela peut prendre un certain temps. Le tableau de résultats répertorie
toutes les valeurs atypiques qui ont été détectées (jusqu'aux résultats maximaux autorisés), avec des
informations sur :

• Élément de données

158
Évaluation de la qualité des données Outil de Qualité des Données de l'OMS

Période
•
• Unité d'organisation

• Valeur - la valeur qui a été identifiée comme étant atypique

• Z-score - le z-score de la valeur atypique

• Déviation - la déviation de la valeur atypique, c'est-à-dire la différence entre la moyenne/

médiane et la valeur réelle

• Std Dev (écart-type) - la valeur d'un écart type.

• Médiane/moyenne - valeur médiane/moyenne, selon la méthode utilisée

• Min et Max - valeurs minimales et maximales de l'élément de données, basées sur le nombre
d'écarts types défini dans la section des paramètres.

• Suivi - case à cocher qui permet de marquer les valeurs pour le suivi, ce qui signifie qu'elles
peuvent être listées à l'aide de la fonction "Analyse de suivi" de l'application Qualité des
données.

Outil de Qualité des Données de l'OMS

L'Outil de qualité des données de l'OMS est une application disponible dans [DHIS2 App Hub] (https://
[Link]/), qui prend en charge un ensemble de fonctionnalités d'analyse de la qualité des
données basées sur le cadre d'Examen de la qualité des données de l'OMS. Lors de sa sortie en
2016, la plupart des fonctionnalités d'analyse de la qualité des données n'étaient pas disponibles dans
les applications de DHIS2 Central. Mais la situation a changé au fil des années. Désormais, la plupart
des analyses peuvent être effectuées dans DHIS2 Central. D'ici un à deux ans, l'application de Qualité
des données de l'OMS ne sera plus mise à jour pour les nouvelles versions de DHIS2. Une nouvelle
application moderne est en cours de développement pour combler les lacunes de fonctionnalité
restantes, notamment en ce qui concerne la génération automatique des rapports annuels sur la
qualité des données.

Le tableau ci-dessous donne un aperçu des fonctionnalités disponibles dans l'Outil de qualité des
données de l'OMS et dans DHIS2 Central (à partir de la version 2.38).

159
Évaluation de la qualité des données Outil de Qualité des Données de l'OMS

Outil de qualité de données de

Fonctionnalité d'analyse Applications de DHIS2 Central
l'OMS

Complétude et ponctualité des Pris en charge Pris en charge

ensembles de données

Complétude et ponctualité des Prise en charge limitée (dans le Pris en charge

éléments de données rapport annuel uniquement)

Analyse des règles de validation Pas pris en charge Pris en charge

Analyse des valeurs atypiques Pas pris en charge Pris en charge

minimales et maximales

Cohérence des données Pris en charge Pris en charge

associées à l'aide de nuages de
points

Analyse des taux d'abandon Pris en charge Pris en charge

négatifs

Graphiques annuels Pris en charge Pris en charge

Analyse des valeurs atypiques Pris en charge Pris en charge

(séries chronologiques)

Cohérence au fil du temps à Pris en charge Pas pris en charge

l'aide de nuages de points

Génération automatique du Pris en charge Pas pris en charge

rapport annuel sur la qualité des
données

Un [manuel d'utilisation] dédié ([Link]

[Link]#how-to-configure-the-dhis2 -based-who-data-quality-tool) ainsi
qu'un package de formation sont disponibles pour l'Outil de qualité des données de l'OMS. Ses
fonctionnalités ne sont donc pas abordées dans ce guide.

160
Implémentation de fonctionnalités et de procédures relatives à la qualité des Analyse automatique de la
données{ #implementing-data-quality-functionality-and-procedures } qualité des données

Implémentation de fonctionnalités et de procédures relatives à la qualité

des données{ #implementing-data-quality-functionality-and-procedures }
Comme indiqué dans les sections sur les caractéristiques de la qualité des données relatives à la
[saisie des données] ([Link]) et à l'[analyse] ([Link]), il
existe une multitude de fonctionnalités permettant d'assurer la qualité des données dans DHIS2.
Toutefois, l'existence de fonctionnalités ne conduit pas automatiquement à leur utilisation. Cette
section aborde les approches visant à accroître leur adoption. Trois thèmes sont abordés à cet effet :

1. Automatisation de l'analyse de la qualité des données grâce à des tableaux de bord et des
notifications de validation
2. [Exigences minimales pour l'implémentation de la fonctionnalité de qualité des données dans
DHIS2] (#minimum-standards-for-data-quality)
3. [Procédures opérationnelles standard (SOP) sur la qualité des données à utiliser à différents
niveaux du système de santé] (#standard-operating-procedures)

Analyse automatique de la qualité des données

Pour encourager les utilisateurs à vérifier régulièrement la qualité des données, la fonctionnalité de
qualité des données doit être facilement accessible et " orientée " vers les utilisateurs dans la mesure
du possible. Dans DHIS2, il existe principalement deux façons de procéder :

• Configurer et partager avec les utilisateurs des tableaux de bord qui fournissent des analyses
de qualité des données prêtes à l'emploi.
• Utilisation de la fonctionnalité de notification des règles de validation pour informer les
utilisateurs des notifications de règles de validation strictes.

Tableaux de bord sur la qualité des données

Les tableaux de bord contenant des mesures de qualité des données constituent le principal moyen
d'offrir aux utilisateurs une analyse automatique de la qualité des données. Comme nous le verrons
plus en détail dans la section normes minimales, différents groupes d'utilisateurs devraient avoir accès
à l'analyse automatique de la qualité des données au moyen de tableaux de bord conçus
spécifiquement pour leurs besoins. Lors de la planification et de la conception de tableaux de bord
pour différents groupes d'utilisateurs, plusieurs aspects doivent être pris en considération.

Sélection des indicateurs de base

La plupart des mesures de qualité des données plus approfondies que nous pouvons définir dans
DHIS2 nécessitent un travail de configuration important et des métadonnées supplémentaires (telles
que des prédicteurs, des éléments de données pour stocker les calculs et des indicateurs) pour
chaque variable de base que nous souhaitons être en mesure d'évaluer. Cela signifie que de telles
mesures ne peuvent être réalisées que pour un ensemble d'indicateurs de base. Le [kit d'outils AQD
de l'OMS] ([Link]
dqa) fournit une liste d'indicateurs de base pour certains programmes de santé, qui, avec les
indicateurs de base définis dans les plans nationaux de suivi et d'évaluation, constituent un bon point
de départ pour déterminer les variables à classer par ordre de priorité. Cela signifie également que si
les tableaux de bord peuvent donner un aperçu des problèmes de qualité des données et des
informations plus approfondies pour certaines variables clés, les utilisateurs doivent toujours être
[formés] ((#normes minimales de qualité des données)) à l'utilisation d'autres fonctionnalités de qualité
des données, et il doit y avoir des SOPs décrivant les activités liées à la qualité des données qu'ils
doivent effectuer régulièrement.

161
Implémentation de fonctionnalités et de procédures relatives à la qualité des Tableaux de bord sur la
données{ #implementing-data-quality-functionality-and-procedures } qualité des données
Orientation opérationnelle ou analytique

Le deuxième élément à prendre en compte est de savoir dans quelle mesure les tableaux de bord
automatiques doivent être conçus pour être des outils opérationnels ou analytiques, ou une
combinaison des deux. Au niveau du district et de l'établissement, où les utilisateurs sont directement
responsables de la saisie de données exactes en temps voulu, les tableaux de bord peuvent être
conçus pour être plus opérationnels. Par exemple, ils peuvent mettre en évidence des valeurs de
données spécifiques signalées comme potentiellement aberrantes, ou des établissements individuels
qui n'ont pas encore présenté de rapport pour la période en cours. Pour les analystes au niveau
national, les besoins sont plus susceptibles d'être liés à l'évaluation de la qualité des données afin de
prendre des décisions éclairées sur la base de celles-ci. Il est donc moins important de voir les
valeurs aberrantes individuelles, mais une mesure de la proportion des valeurs de données déclarées
qui sont des valeurs aberrantes potentielles est pertinente pour l'analyse. L'analyse peut également
avoir un objectif opérationnel à des niveaux plus élevés, comme la possibilité de suivre les tendances
ou de faire des comparaisons géographiques des problèmes de qualité des données afin que des
interventions puissent être effectuées.

Personnaliser pour des groupes d'utilisateurs

Les tableaux de bord doivent être adaptés et partagés avec des groupes d'utilisateurs ayant des
besoins d'information et des rôles similaires en ce qui concerne la qualité des données. D'un point de
vue technique, il est facile de donner à tous les utilisateurs de DHIS2 l'accès à un grand nombre de
tableaux de bord en utilisant la fonctionnalité sharing pour les rendre publics (pour tous les
utilisateurs) ; cependant, alors qu'un ensemble de tableaux de bord publics pourrait être développé
pour couvrir tous les aspects clés de la qualité des données, il est peu probable que les utilisateurs
trouvent et examinent les informations disponibles dans un ensemble de tableaux de bord si seul un
petit sous-ensemble de ces informations est pertinent pour eux. Il convient donc d'identifier des
groupes clés d'utilisateurs pour lesquels des analyses automatiques et personnalisées peuvent être
développées sous la forme de tableaux de bord.

Deux dimensions sont essentielles pour définir ces groupes d'utilisateurs : le niveau du système de
santé auquel les utilisateurs sont basés (national, district, établissement, etc.) et le(s) domaine(s) de
santé pour lequel (lesquels) ils travaillent. Ces deux dimensions sont étroitement liées, car les
utilisateurs des niveaux supérieurs sont généralement plus spécialisés en termes de domaines/
programmes de santé, tandis que les utilisateurs des niveaux inférieurs ont des responsabilités plus
étendues. Par exemple, dans un petit établissement, une ou deux personnes peuvent être
responsables des données et des rapports pour tous les services de santé, dans le district, il peut y
avoir des personnes responsables à la fois des rapports HMIS transversaux et des points focaux plus
spécialisés pour des programmes spécifiques, tandis qu'au niveau national, chaque programme de
santé peut disposer d'une équipe d'analystes de données.

Lors de l'examen des groupes d'utilisateurs à cibler en termes d'exigences relatives aux tableaux de
bord de la qualité des données dans DHIS2, il est important de garder à l'esprit que les utilisateurs
individuels peuvent faire partie de plusieurs groupes d'utilisateurs - à la fois dans leur travail réel et
techniquement en termes de groupes d'utilisateurs dans DHIS2. Par exemple, si deux tableaux de
bord de qualité des données ont été développés spécifiquement pour contrôler la qualité des données
sur le paludisme et pour fournir des mesures clés de qualité des données pour les districts, les
utilisateurs travaillant dans un district qui sont également responsables de la lutte contre le paludisme
devraient avoir accès aux deux tableaux de bord (c'est-à-dire qu'ils devraient faire partie des groupes
"utilisateurs du district" et "utilisateurs du programme de lutte contre le paludisme"). En supposant que
les unités d'organisation relatives et les [périodes relatives] ([Link]
dhis-core-version-master/understanding-the-data-model/[Link]?
h=relative+master+use#relative-periods) soient utilisées conformément aux meilleures pratiques de
visualisation et de conception des tableaux de bord, les mêmes tableaux de bord peuvent souvent
être réutilisés au niveau national et sous-national. L'exception se situe au niveau de l'établissement,

162
Implémentation de fonctionnalités et de procédures relatives à la qualité des Tableaux de bord sur la
données{ #implementing-data-quality-functionality-and-procedures } qualité des données
car toute analyse impliquant des comparaisons entre plusieurs unités d'organisation ne pourra pas
fonctionner convenablement pour les utilisateurs de l'établissement.

Exemples de tableaux de bord sur la qualité des données

Pour illustrer comment la fonctionnalité de qualité des données du DHIS2 peut être mise en œuvre,
des exemples de tableaux de bord de qualité des données sont disponibles dans l'environnement
intégré de la [base de données de démonstration du HMIS] ([Link]
dashboard/#/c6L3VVdHTGK) géré par le centre HISP. Ces tableaux de bord respectent généralement
les principes de qualité des données énoncés dans la section [principes de qualité des données]
([Link]) et le [cadre AQD de l'OMS] ([Link]
tools/health-service-data/data-quality-assurance-dqa) ; toutefois, étant donné que l'accent est mis sur
le suivi routinier (par exemple, mensuel/trimestriel), les contrôles de qualité des données concernant
la cohérence du dénominateur et la cohérence externe (par exemple, avec les enquêtes sur les
ménages) ne sont pas inclus, car ils changent au maximum une fois par an dans des circonstances
normales.

Outre les contrôles de cohérence externes, les exemples de tableaux de bord fournissent des
mesures sur chacune des dimensions clés de la qualité des données :

• l'exhaustivité et l'actualité des données, au niveau des ensembles et des éléments de données

• cohérence entre les données connexes

• cohérence dans le temps (détection des valeurs aberrantes)

Quatre indicateurs sont utilisés dans les tableaux de bord proposés en exemple, sur la base des
indicateurs de base recommandés dans le [cadre du AQD de l'OMS] ([Link]
collection-tools/health-service-data/data-quality-assurance-dqa) (le cinquième indicateur de base, les
notifications de tuberculose, n'a pas été inclus dans la version initiale des tableaux de bord en raison
des limites des données disponibles dans la base de données de démonstration du système
d'information sur les marchés du logement).

Du niveau national au niveau du district

Le tableau de bord " QD - Qualité des données de base " est disponible dans la [base de données de
démonstration HMIS] ([Link] à l'aide
des détails de connexion suivants : - Nom d'utilisateur : demo_en / Mot de passe : District1# - Nom
d'utilisateur : demo_dq_district / Mot de passe : District1#

La meilleure façon de consulter le tableau de bord est de se connecter à DHIS2, mais un résumé des
principaux éléments du tableau de bord est fourni ici.

L'exhaustivité

Graphiques linéaires montrant la tendance sur 12 mois des indicateurs de base :

• Exhaustivité de déclaration (par ensemble de données)

• Établissements établissant des rapports régulièrement au cours des 12 derniers mois

Graphiques à valeur unique pour chaque indicateur de base, pour le mois dernier :

• Exhaustivité des éléments de données

• Établissements établissant des rapports régulièrement au cours des 12 derniers mois

163
Implémentation de fonctionnalités et de procédures relatives à la qualité des Tableaux de bord sur la
données{ #implementing-data-quality-functionality-and-procedures } qualité des données
Tableaux présentant les principales mesures d'exhaustivité/de respect des délais pour le mois dernier,
comparant les unités d'organisation (au niveau de l'utilisateur et à un niveau inférieur). Un tableau est
inclus pour chaque indicateur de base. Utilise une légende personnalisée pour colorer les cellules en
fonction de l'exhaustivité.

Consistance des données connexes

Diagrammes de dispersion montrant les variables de base par rapport à une variable connexe, dans
plusieurs unités d'organisation (un niveau en dessous de l'utilisateur). La détection des valeurs
aberrantes est activée, mettant en évidence les unités d'organisation dont la valeur se situe à plus de
3 écarts-type de la médiane, à l'aide d'une méthode de z-score modifiée.

164
Implémentation de fonctionnalités et de procédures relatives à la qualité des Tableaux de bord sur la
données{ #implementing-data-quality-functionality-and-procedures } qualité des données

Taux d'abandon (pour les variables le cas échéant) au cours des 12 derniers mois, présentés sous
forme de diagramme à colonnes trié de bas en haut avec les valeurs négatives mises en évidence et
un tableau correspondant répertoriant les unités d'organisation ayant des valeurs négatives.

Cohérence dans le temps

Graphiques de variation annuelle pour chaque variable, montrant les valeurs mensuelles pour l'année
en cours et les 5 années précédentes.

165
Implémentation de fonctionnalités et de procédures relatives à la qualité des Tableaux de bord sur la
données{ #implementing-data-quality-functionality-and-procedures } qualité des données

Valeur excluant les valeurs aberrantes pour chacune des quatre variables :

• Graphiques de valeurs individuelles du mois dernier

• Tableau de valeurs des 12 derniers mois, avec ensemble de légendes appliqué

Tableau des grandes valeurs aberrantes pour chacune des variables au cours des 3 derniers mois
pour les unités inférieures au niveau de l'utilisateur, avec légende appliquée en fonction de la taille de
la valeur aberrante.

Niveau de l'Établissement

Le tableau de bord " QD - Qualité des données de base " est disponible dans la [base de données de
démonstration HMIS] ([Link] à
l'aide des identifiants de connexion suivants : - Nom d'utilisateur : district_qd_établissement / Mot de
passe : District1#

166
Implémentation de fonctionnalités et de procédures relatives à la qualité des Tableaux de bord sur la
données{ #implementing-data-quality-functionality-and-procedures } qualité des données
La meilleure façon de consulter le tableau de bord est de se connecter à DHIS2, mais un résumé des
principaux éléments du tableau de bord est fourni ici.

L'exhaustivité

Tableaux avec les principales mesures d'exhaustivité/de respect des délais des 12 derniers mois (un
tableau pour chaque indicateur de base), montrant :

• Ensemble de données des déclarations attendues : 1 si l'établissement est censé faire une
déclaration, 0 sinon

• Rapports effectifs sur l'ensemble des données : 1 si l'établissement a marqué l'ensemble de

données comme terminé, 0 sinon

• Déclarations effectives de l'ensemble de données dans les délais : 1 si l'établissement a

marqué l'ensemble de données comme terminé avant la date limite de déclaration, 0 sinon

• Valeur de la variable (par ex. CPN 1ère visite) : la valeur réelle des données, pour évaluer
directement l'exhaustivité de l'élément de données.

Utilise une légende personnalisée pour mettre en évidence les valeurs égales à 0, mais dans une
couleur neutre, car certains établissements ne sont pas censés fournir des informations sur toutes les
variables clés.

Consistance des données connexes

Taux d'abandon (pour les variables le cas échéant) au cours des 12 derniers mois, présentés sous la
forme d'un graphique à colonne unique avec les valeurs négatives surlignées et un tableau
correspondant répertoriant les unités d'organisation présentant des valeurs négatives.

Cohérence dans le temps

167
Implémentation de fonctionnalités et de procédures relatives à la qualité des Tableaux de bord sur la
données{ #implementing-data-quality-functionality-and-procedures } qualité des données
Graphiques de variation annuelle pour chaque variable, montrant les valeurs mensuelles pour l'année
en cours et les 5 années précédentes.

Tableau comprenant de grandes valeurs aberrantes (valeurs de + 10 uniquement) pour chacune des
variables au cours des 12 derniers mois pour l'unité d'organisation de l'utilisateur, avec un ensemble
de légendes appliquées en fonction de la taille de la valeur aberrante.

Graphiques comparant les valeurs déclarées à la valeur aberrante calculée pour chacune des
variables au cours des 12 derniers mois pour l'unité d'organisation de l'utilisateur.

168
Implémentation de fonctionnalités et de procédures relatives à la qualité des Notifications des règles
données{ #implementing-data-quality-functionality-and-procedures } de validation

Tableaux de bord des boîtes à outils de l'OMS

Comme partie intégrante des boîtes à outils sur les données de santé, se trouvent des tableaux de
bord relatifs à la qualité des données pour des programmes de santé spécifiques. Il s'agit de
ressources précieuses qu'il convient d'examiner lors de la mise en œuvre des tableaux de bord relatifs
à la qualité des données dans chaque domaine respectif. Actuellement, le [tableau de bord sur la
qualité des données relatives au paludisme] ([Link]
malaria-hmis/[Link]#malaria-data-quality-dashboard) a été publié et est disponible dans la [base
de données de démonstration HMIS] ([Link]
xRjeIawqMbW). Les tableaux de bord relatifs à la tuberculose et au VIH sont en cours d'élaboration et
seront publiés et mis à disposition dans la base de données de démonstration HMIS d'ici la fin de
l'année 2023.

Notifications des règles de validation

Les tableaux de bord sont le principal moyen de fournir aux utilisateurs une analyse automatique de la
qualité des données. Toutefois, les notifications de règles de validation peuvent également être
utilisées à cette fin et constituer un complément utile si elles sont configurées correctement. Selon la
configuration de DHIS2, les notifications de règles de validation peuvent être paramétrées de manière
à ce que les utilisateurs reçoivent des messages dans DHIS2, des courriels ou des SMS si un certain
test logique est vrai. Pour la qualité des données, cela signifie qu'une valeur est supérieure à un
certain seuil et qu'elle est signalée comme une valeur aberrante potentielle.

L'implémentation de cette fonctionnalité doit être gérée avec soin, car l'envoi d'un trop grand nombre
de messages peut amener les gens à ne plus prêter attention à ce qu'ils disent. Ceci est
particulièrement vrai si les notifications :

• sont envoyés à des personnes pour lesquelles le message n'est pas pertinent (c'est-à-dire
qu'elles n'ont pas la responsabilité de vérifier/corriger l'erreur potentielle)

• comportent trop de faux positifs (c'est-à-dire des valeurs qui s'avèrent ne pas être des erreurs
de qualité des données)

• ne sont pas suffisamment importants pour justifier l'envoi d'un message spécifique

169
Implémentation de fonctionnalités et de procédures relatives à la Référence - mesures de qualité des
qualité des données{ #implementing-data-quality-functionality- données{ #reference-data-quality-
and-procedures } metrics }
Les notifications de règles de validation doivent donc être utilisées avec prudence dans le cadre du
contrôle qualité des données et conviennent mieux aux variables hautement prioritaires pour
lesquelles des problèmes de qualité des données ont été régulièrement constatés.

Référence - mesures de qualité des données{ #reference-data-quality-metrics }

Vous trouverez ci-dessous une liste de référence des mesures de qualité des données et des
analyses qui peuvent être configurées dans DHIS2 et fournies sous forme d'analyse automatique par
le biais de tableaux de bord ou de notifications push, pour une seule variable.

L'exhaustivité

• L'exhaustivité et le respect des délais de l'ensemble des données.

• Complétude des éléments de données. Peut être configuré avec différentes unités de mesure
pour le dénominateur ("rapports attendus").

• Les unités d'organisations/établissements font des rapports réguliers.

cohérence entre les données connexes

• Diagrammes de dispersion, contre une variable connexe

• Graphiques mettant en évidence les taux d'abandon négatifs (le cas échéant)

Cohérence dans le temps

• Graphiques de variation annuelle permettant d'identifier visuellement les valeurs aberrantes

• Mesure des valeurs aberrantes

◦ Valeur globale excluant les valeurs aberrantes

◦ Nombre et proportion de valeurs aberrantes

◦ Listes des valeurs aberrantes par période/unités d'organisation

• Notifications (message DHIS2, e-mail ou SMS) si les valeurs dépassent le seuil des valeurs
aberrantes.

Normes minimales de qualité des données

DHIS2 dispose d'un large éventail de fonctionnalités permettant de garantir et d'évaluer la qualité des
données ; toutefois, une grande partie de ces fonctionnalités doit être configurée par l'équipe centrale
de DHIS2 et doit être mise à la disposition des utilisateurs finaux. Au-delà de la configuration de
DHIS2, il est essentiel que la formation dispensée aux utilisateurs finaux de DHIS2 comprenne la
fonctionnalité de qualité des données et qu'il existe des SoPs (procédures opérationnelles standard)
pour le personnel à tous les niveaux, qui définissent clairement leur rôle dans l'assurance de la bonne
qualité des données. Cette section présente ce que nous considérons comme un minimum de normes
de configuration et de mise en œuvre pour garantir la qualité des données.

Configuration de la saisie des données

• Règles de validation configurées pour tous les ensembles de données actuellement utilisés,
couvrant tous les éléments de données pour lesquels il est possible de définir des
comparaisons logiques conformément aux bonnes pratiques en matière de règles de validation.

◦ Les boîtes à outils relatives aux données de santé fournissent une référence avec des
règles de validation recommandées pour plusieurs programmes de santé.

170
Implémentation de fonctionnalités et de procédures relatives à la qualité des Tableaux de bord et
données{ #implementing-data-quality-functionality-and-procedures } indicateurs
Les ensembles de données qui ont été utilisés régulièrement pendant au moins un an et dont
• les rapports sont raisonnablement exhaustifs doivent être pris en considération pour la
génération de valeurs min-max.

◦ Il convient d'utiliser d'autres méthodes que la fonction intégrée de "génération de valeurs

min-max".

Tableaux de bord et indicateurs

• Les indicateurs de qualité des données doivent être configurés pour (au moins) les indicateurs
prioritaires du ministère de la santé/programme de santé :

◦ Exhaustivité des éléments de données

◦ Les établissements qui font des rapports réguliers

◦ Données excluant les valeurs aberrantes

• Des tableaux de bord sur la qualité des données devraient être élaborés et mis à la disposition
de tous les utilisateurs, en fonction de leurs besoins en matière d'analyse de la qualité des
données.

◦ Les tableaux de bord sur la qualité des données provenant des boîtes à outils des
données sur la santé devraient être examinés comme référence.

Rôles des utilisateurs et accès

• Les utilisateurs doivent avoir accès à l'application principale "Qualité des données" et à d'autres
applications de qualité des données installées/configurées (par exemple, l'outil de qualité des
données de l'OMS). Il s'agit notamment de :

◦ Au minimum, tous les utilisateurs responsables de la saisie et de la validation des

données

◦ En l'absence d'arguments clairs en ce sens, les autres utilisateurs ayant accès à

l'analyse des données

Autre configuration

• L'outil de qualité des données de l'OMS est installé et configuré de façon à supporter les
examens annuels de qualité des données.

• La notification de la règle de validation est envisagée (en fait, la mise en œuvre de cette règle
n'est pas considérée comme faisant partie d'une norme minimale de qualité des données).

◦ Options de notification ( email et/ou SMS) configurées si les notifications des règles de
validation sont utilisées.

Formation et aides de travail

• Le programme et le matériel de formation du personnel qui utilise DHIS2 devraient couvrir

l'utilisation de la fonctionnalité de qualité des données.

• Les aides de travail, les manuels d'utilisation et les autres ressources mises à la disposition des
utilisateurs doivent couvrir la fonctionnalité de la qualité des données.

171
 Procédures
Implémentation de fonctionnalités et de procédures relatives à la qualité des
opérationnelles
données{ #implementing-data-quality-functionality-and-procedures }
normalisées
Procédures opérationnelles normalisées

• Les procédures opérationnelles normalisées relatives à la qualité des données doivent être
définies et mises à la disposition des utilisateurs.

◦ Il peut s'agir d'un SOP dédié à la qualité des données, ou la qualité des données peut
être intégrée dans les SOP pour la collecte et/ou l'analyse des données.

procédure opérationnelle normalisée relative à la qualité des données

Des procédures opérationnelles normalisées couvrant la qualité des données doivent être mises à la
disposition des utilisateurs qui travaillent avec des données à tous les niveaux des systèmes de santé.
Les procédures opérationnelles normalisées doivent indiquer qui doit faire quoi, quand - et comment
cela doit être fait. Cela signifie que les rôles clés liés à la qualité des données doivent être définis,
ainsi que les responsabilités de chacun. Voici quelques exemples d'activités liées à la qualité des
données qui doivent être décrites :

• Quelles sont les mesures à prendre en cas de violation des règles de validation ou des valeurs
min/max lors de la saisie des données ?

• Quand les données doivent-elles être communiquées et quand doivent-elles être contrôlées ?

• Quelles sont les mesures à prendre par les différents niveaux du système de santé pour
contrôler les données ?

• Que faire lorsqu'une valeur incorrecte ou aberrante est identifiée ?

Les procédures opérationnelles normalisées relatives à la qualité des données doivent être élaborées
en fonction du contexte et des procédures établies dans chaque mise en œuvre. Toutefois, un modèle
de procédure opérationnelle normalisée relatif à la qualité des données est disponible [ici] (https://
[Link]/document/d/1w9bhvCEgewrKLSNsizfpPBoAv2WCd3aM9wzbt3x4yHE/edit?
usp=sharing) et peut servir de point de départ à l'élaboration d'une version spécifique à chaque pays.

Opérations clés de maintenance

Pour que la fonctionnalité de qualité des données décrite ici fonctionne comme prévu, certaines
fonctionnalités sous-jacentes doivent également être mises en place.

Programmation

Plusieurs mesures de qualité des données reposent sur l'utilisation de prédicteurs pour effectuer les
calculs sous-jacents. Dans le cas des valeurs aberrantes, deux ensembles de prédicteurs sont
nécessaires : d'abord pour calculer les seuils de valeurs aberrantes, puis pour évaluer les données
par rapport à ces seuils. Les prédicteurs doivent être planifiés à l'aide de l'application [Scheduler app]
([Link]
[Link]?h=scheduler+master+use#scheduling), et doivent être exécutés de manière à ce
qu'ils soient terminés avant que le travail de génération de la table d'analyse n'ait lieu, généralement
tous les soirs.

Les tâches planifiées ne peuvent pas être enchaînées de sorte qu'une tâche démarre lorsque la
précédente est terminée. Ainsi, pour s'assurer que les tâches requises s'exécutent dans le bon ordre,
vous devez mesurer le temps nécessaire pour que chaque tâche se termine et les planifier en
conséquence.

Voici un exemple de génération des prédicteurs et de leur utilisation dans le cadre d'une analyse

172
Implémentation de fonctionnalités et de procédures relatives à la qualité des Paramètres des notifications
données{ #implementing-data-quality-functionality-and-procedures } par e-mail et par SMS

Dans ce deuxième exemple, nous pouvons ajouter la tâche de suivi pour l'utilisation des règles de
validation et des notifications.

Dans l'exemple ci-dessous, les prédicteurs chargés de calculer les seuils de qualité des données
commencent à 23h00 et se terminent en 15 minutes environ. Les prédicteurs chargés de calculer
d'autres mesures de qualité des données démarrent à 23 h 30 et durent 45 minutes. Enfin, les tâches
de mise à jour de la table d'analyse démarrent à 02:00. Les tests sont effectués avec soin dans un
système de développement afin de déterminer le temps nécessaire à chaque tâche et les
planifier en conséquence.

Paramètres des notifications par e-mail et par SMS

Les messages, qu'il s'agisse de messages directs envoyés par les utilisateurs, de notifications de
validation ou de notifications du système, sont par défaut envoyés en tant que messages internes de
DHIS2. Pour que ces messages soient également transmis par e-mail et/ou SMS, DHIS2 doit être
configuré de manière appropriée et l'utilisateur doit activer les notifications par e-mail/SMS.

Configuration de l'e-mail

Pour que DHIS2 puisse envoyer des notifications par e-mail, un serveur SMTP doit être configuré
dans les [paramètres du système] ([Link]
configuring-the-system/[Link]?h=smtp+2.38#system_email_settings). Tout fournisseur

173
Implémentation de fonctionnalités et de procédures relatives à la qualité des Paramètres des notifications
données{ #implementing-data-quality-functionality-and-procedures } par e-mail et par SMS
de messagerie offrant un service SMTP peut en principe être utilisé à cette fin. [Un tutoriel] (https://
[Link]/en/topics/tutorials/[Link]?h=smtp+tutorials#setting-up-email-on-a-
server) est également disponible pour configurer un service de courrier électronique sur le serveur
hôte DHIS2.

Configuration des SMS

Pour que DHIS2 puisse envoyer (et recevoir) des messages SMS, une [passerelle SMS] (https://
[Link]/wiki/SMS_gateway) doit être configurée. D'autres options de passerelles SMS pour
DHIS2 sont présentées ici. L'utilisation d'un appareil Android comme passerelle est techniquement
possible, mais n'est recommandée que pour les essais et les projets pilotes à petite échelle. Les
passerelles SMS dédiées sont généralement proposées par des fournisseurs commerciaux ou des
opérateurs de téléphonie mobile (moyennant un paiement), et ces fournisseurs de services fourniront
les paramètres nécessaires à la configuration de la passerelle.

Les étapes spécifiques de la configuration des passerelles SMS dans DHIS2 sont décrites [ici] (https://
[Link]/en/use/user-guides/dhis-core-version-238/maintaining-the-system/[Link]?
h=#sms-configuration-gateways), avec des détails supplémentaires [ici] ([Link]
user-guides/dhis-core-version-238/maintaining-the-system/[Link]#mobile_sms_service).

Activation et désactivation des notifications

Il appartient à chaque utilisateur de choisir d'activer/désactiver le transfert de ces messages vers les
SMS ou les e-mails (en supposant qu'ils aient été configurés comme décrit ci-dessus). Pour ce faire,
ouvrez les Paramètres utilisateurs dans la barre de menu de DHIS2 et activez ou désactivez chaque
option pour les SMS et les e-mails (réglez les paramètres sur "Oui" pour les activer).

174
Implémentation de fonctionnalités et de procédures relatives à la qualité des Paramètres des notifications
données{ #implementing-data-quality-functionality-and-procedures } par e-mail et par SMS

175
Unités d’Organisation Conception de la hiérarchie de l'unité d'organisation

Unités d’Organisation
Dans le DHIS2, l'emplacement des données, le contexte géographique, est représenté par des unités
organisationnelles. Les unités organisationnelles peuvent être soit un établissement de santé ou un
département/sous-unité fournissant des services, soit une unité administrative représentant une zone
géographique (par ex, un district de santé).

Les unités d'organisation sont situées dans une hiérarchie, également appelée arbre. La hiérarchie
reflète la structure administrative de la santé et ses niveaux. Les niveaux typiques d'une telle
hiérarchie sont le niveau national, le niveau de la province, le niveau du district et le niveau de
l'établissement. Dans le DHIS2, il n'existe qu'une seule hiérarchie organisationnelle. Par conséquent,
la manière dont elle est définie et mappée à la réalité doit faire l'objet d'une attention particulière. Les
zones géographiques et les niveaux définis dans la hiérarchie organisationnelle principale auront un
impact majeur sur la facilité d'utilisation et les performances de l'application. En outre, il existe des
moyens d'aborder des hiérarchies et des niveaux alternatifs, comme expliqué dans la section intitulée
Groupes d'unités d'organisation et ensembles de groupes plus bas.

Conception de la hiérarchie de l'unité d'organisation

Le processus de conception d'une hiérarchie d'unités d'organisation efficace comporte de nombreux

aspects :

• Englobe tous les établissements de santé déclarants: Tous les établissements de santé qui
contribuent à la collecte de données nationales doivent être inclus dans le système. Les
établissements de tous types d'appartenance doivent être inclus, y compris les établissements
privés, publics, les ONG et les établissements confessionnels. Souvent, les établissements
privés représentent la moitié du nombre total d'établissements dans un pays et se voient
imposer des politiques de communication des données, ce qui signifie qu'il est nécessaire
d'incorporer les données de ces établissements pour obtenir des chiffres agrégés nationaux
réalistes.

• Mettre l'accent sur la hiérarchie administrative en matière de santé: Un pays possède

généralement plusieurs hiérarchies administratives qui ne sont souvent ni bien coordonnées ni
harmonisées. Lors de la conception de la base de données DHIS2, il convient de garder à
l'esprit les domaines les plus intéressants et ceux qui seront le plus souvent demandés pour
l'analyse des données. DHIS2 gère principalement des données sur la santé et effectue des
analyses basées sur la structure administrative de la santé. Cela signifie que même si des
ajustements peuvent être apportés pour tenir compte de domaines tels que les finances et
l'administration locale, le point de départ de la hiérarchie des unités d'organisation du DHIS2
devrait être les régions administratives de la santé.

• Limiter le nombre de niveaux hiérarchiques des unités d'organisation: Pour répondre aux
besoins d'analyse provenant de divers organismes tels que le gouvernement local et le trésor, il
est tentant d'inclure tous ces domaines en tant qu'unités d'organisation dans la base de
données DHIS2. Cependant, pour des raisons de performance, il convient d'essayer de limiter
les niveaux de la hiérarchie des unités d'organisation au plus petit nombre possible. La
hiérarchie est utilisée comme base pour l'agrégation des données à présenter dans l'un ou
l'autre des outils de rapport, de sorte que lors de la production de données agrégées pour les
niveaux supérieurs, l'application DHIS2 doive rechercher et additionner les données
enregistrées pour toutes les unités d'organisation situées plus bas dans la hiérarchie.
L'augmentation du nombre d'unités d'organisation aura donc un impact négatif sur les
performances de l'application et un nombre excessivement élevé pourrait devenir un problème
important à cet effet.

Par ailleurs, la plupart des outils d'analyse de DHIS2 reposent sur la sélection dynamique de
l'unité d'organisation "mère" de celles qui doivent être incluses. Par exemple, il est possible de

176
Unités d’Organisation Groupes d'unités d'organisation et ensembles de groupes

sélectionner une province et d'inclure dans le rapport les districts appartenant à cette province.
Si le niveau du district est le plus utile du point de vue de l'analyse et qu'il existe plusieurs
niveaux hiérarchiques entre ce niveau et celui de la province, ce type de rapport sera
inutilisable. Lors de la constitution de la hiérarchie, il convient de se concentrer sur les niveaux
qui seront fréquemment utilisés dans les rapports et l'analyse des données et de laisser de côté
les niveaux qui sont rarement ou jamais utilisés, car cela aura un impact à la fois sur les
performances et la maniabilité de l'application.

• Éviter les relations individuelles: Un autre principe directeur pour la définition de la hiérarchie
est d'éviter de relier des niveaux qui ont des rapports parents-enfants presque individuels, ce
qui signifie que, par exemple, un district (parent) devrait avoir en moyenne plus d'une
collectivité locale (enfant) au niveau inférieur avant qu'il ne soit logique d'ajouter un niveau de
collectivité locale à la hiérarchie. Les rapports parents-enfants de 1:4 ou plus sont beaucoup
plus utiles pour l'analyse des données, car ils permettent d'examiner, par exemple, comment
les données d'un district sont réparties dans les différents sous-domaines et comment elles
varient. De tels exercices d'approfondissement ne sont pas très utiles lorsque le niveau
inférieur a la même population cible et les mêmes établissements de santé que le parent.

L'omission de niveaux géographiques lors du mapping de la réalité sur la hiérarchie des unités
d'organisation de DHIS2 peut s'avérer difficile et susciter la résistance de certaines parties
prenantes, mais il faut garder à l'esprit qu'il existe des moyens de produire des rapports basés
sur des niveaux géographiques qui ne font pas partie de la hiérarchie organisationnelle de
DHIS2, comme il sera expliqué dans la section suivante.

Groupes d'unités d'organisation et ensembles de groupes

Dans DHIS2, les unités d'organisation peuvent être regroupées en groupes d'unités d'organisation, et
ces groupes peuvent être organisés en ensembles de groupes. Combinés, ils peuvent imiter une
hiérarchie organisationnelle alternative qui peut être utilisée lors de la création de rapports et d'autres
résultats de données. Outre le fait qu'ils représentent des lieux géographiques alternatifs ne faisant
pas partie de la hiérarchie principale, ces groupes sont utiles pour attribuer des systèmes de
classification aux établissements de santé, par exemple sur la base du type ou de la propriété des
établissements. Un nombre quelconque d'ensembles de groupes et de groupes peut être défini dans
l'application via l'interface utilisateur, et tous ces ensembles sont définis localement pour chaque base
de données DHIS2.

Un exemple illustre le mieux ce point : En règle générale, on souhaite fournir une analyse basée sur la
propriété des établissements. Dans ce cas, il faudra créer un groupe pour chaque type de propriété,
par exemple " Ministère de la santé ", " privé " et " ONG ". Tous les établissements figurant dans la
base de données doivent alors être classés et affectés à l'un de ces trois groupes. Ensuite, l'on créera
un ensemble de groupes appelé "Propriété" auquel les trois groupes ci-dessus sont assignés, comme
illustré dans la figure ci-dessous.

177
Unités d’Organisation Groupes d'unités d'organisation et ensembles de groupes

De même, il est possible de créer un ensemble de groupes pour un niveau administratif

supplémentaire, par ex. les collectivités locales. Toutes les collectivités locales doivent être définies en
tant que groupes d'unités d'organisation, puis affectées à un ensemble de groupes appelé
"Collectivités locales". La dernière étape consiste à affecter tous les établissements de santé à un et
un seul des groupes de collectivités locales. Cela permet au DHIS2 de produire des rapports agrégés
pour chaque collectivité locale (en additionnant les données de tous les établissements de santé
assignés) sans devoir inclure le niveau de la collectivité locale dans la hiérarchie organisationnelle
principale. La même approche peut être suivie pour tout niveau administratif ou géographique
supplémentaire nécessaire, en définissant un groupe par niveau supplémentaire. Avant de passer à la
conception de ce niveau dans le DHIS2, il est nécessaire d'établir un mapping entre les zones du
niveau géographique supplémentaire et les établissements de santé de chaque zone.

Une propriété essentielle du concept d'ensemble de groupes dans DHIS2 à comprendre est
l'exclusivité, qui implique qu'une unité d'organisation ne peut être membre que d'un seul des groupes
d'un ensemble de groupes. Une violation de cette règle entraînerait une duplication des données lors
de l'agrégation des données sur les établissements de santé par les différents groupes, car un
établissement affecté à deux groupes dans le même ensemble de groupes erait compté deux fois.

À partir de cette structure, DHIS2 peut fournir des données agrégées pour chacun des types de
propriété des unités d'organisation grâce au "Rapport sur les groupes d'unités d'organisation" dans le
module "Rapports" ou grâce à l'outil tiers "tableau croisé dynamique" d'Excel. Par exemple, il est
possible de visualiser et de comparer les taux d'utilisation agrégés selon les différents types de
propriété (par exemple, le ministère de la santé, le secteur privé, les ONG). En outre, DHIS2 peut
fournir des statistiques sur la répartition des établissements dans le "Rapport sur la répartition des
unités d'organisation" du module "Rapports". Par exemple, il est possible de voir combien
d'établissements existent sous une unité d'organisation donnée dans la hiérarchie pour chacun des
différents types de propriété. Dans le module SIG, étant donné que les coordonnées des
établissements de santé ont été enregistrées dans le système, il est possible de visualiser
l'emplacement des différents types d'établissements de santé (avec des symboles différents pour
chaque type) et de combiner ces informations avec une autre couche cartographique montrant les
indicateurs, par ex. par district.

178
Éléments de données et dimensions personnalisées Eléments de données

Éléments de données et dimensions personnalisées

Ce chapitre traite en premier lieu d'une composante importante de la construction du système :
l’élément de données. Il traite ensuite du modèle de catégorie et de la façon dont il peut être utilisé
pour bâtir une structure de métadonnées hautement personnalisée pour le stockage des données.

Eléments de données

L'élément de données est, avec l'unité d'organisation, la composante la plus importante d'une base de
données DHIS2. Il représente la dimension quoi et indique ce qui est collecté ou analysé. Si dans
certains contextes, on parle d'indicateur, dans DHIS2, cet élément de métadonnées utilisé pour la
collecte et l'analyse des données est appelé "élément de données". L'élément de données représente
souvent un nombre et son nom décrit ce qui est compté, par exemple "Doses de BCG administrées"
ou "Cas de paludisme". Lorsque des données sont collectées, validées, analysées ou présentées, ce
sont les éléments de données ou les expressions qui en découlent qui décrivent le phénomène,
l'événement ou le cas pour lequel ces données sont enregistrées. Les éléments de données jouent
donc un rôle important dans tous les aspects du système. Ils définissent non seulement la manière
dont les données sont collectées, mais aussi et surtout la manière dont elles sont représentées dans
la base de données et comment elles peuvent être analysées et présentées.

Un principe important à prendre en compte lors de la conception des éléments de données est de se
représenter les éléments de données comme une description autonome d'un phénomène ou d'un
événement et non comme un champ dans un formulaire de saisie de données. Chaque élément de
données est autonome dans la base de données, complètement détaché et indépendant du formulaire
de collecte. Il est important de savoir que les éléments de données sont utilisés directement dans des
rapports, graphiques et autres outils d'analyse de données, dans lesquels le contexte des formulaires
de saisie n'est ni précisé ni pertinent. Autrement dit, l'élément de données doit permettre d'identifier
clairement l'événement qu'il représente, rien qu'avec son nom. Sur cette base, il est recommandé de
créer pour l'élément de données un nom qui se suffit à lui-même. Tout utilisateur, en lisant le nom, doit
pouvoir comprendre l'événement qu'il représente, même s'il n'a pas accès au contexte du formulaire
de saisie des données.

Par exemple, un élément de données appelé " Paludisme " peut sembler concis dans un formulaire de
saisie de données sur la mortalité, sur les stocks de médicaments ou sur les données relatives aux
consultations externes. Toutefois, dans un rapport et sans le contexte du formulaire de saisie, il est
impossible de déterminer l'événement que cet élément de données représente. Si le nom de l'élément
de données avait été "Décès dus au paludisme", "Stock de médicaments antipaludiques reçus" ou
"Prophalaxie antipaludique administrée", l'utilisateur aurait clairement compris le sens du rapport.
Dans le cas présent, nous avons affaire à trois éléments de données différents avec une sémantique
complètement différente.

Catégories

La saisie de données nécessite parfois de montrer clairement la dimension qui décrit l'événement
étudié. Prenons l'exemple du nombre de "cas de paludisme répartis par genre et par tranche d'âge,
tels que "femmes", "hommes", "< 5 ans" et "> 5 ans". La particularité de ces données est que cette
répartition est très souvent utilisée avec d'autres éléments de données "basiques" : On serait par
exemple tenté de réutiliser cette répartition avec d'autres éléments de données tels que la
"tuberculose" et le "VIH". Pour que les métadonnées soient plus dynamiques, réutilisables et
analysables, il est préférable de définir les maladies mentionnées comme éléments de données et de
créer un modèle propre aux attributs de la répartition. Pour ce faire, le modèle de catégorie, décrit ci-
après, peut être utilisé.

179
Éléments de données et dimensions personnalisées Catégories

Le modèle de catégorie comporte quatre éléments principaux qui sont mieux décrits à l'aide de
l'exemple ci-dessus :

1. Options de catégorie: Elles correspondent à « Femme », « Homme » et « \< 5 ans » et « > 5

ans ». Les options de catégorie sont des attributs bien détaillés et liées entre elles. years” and
“> 5 years”. Category options are the fine grained

2. Catégorie correspond au « Genre » et à la « Tranche d’âge ». Les catégories sont utilisées

pour regrouper les options de catégories associées dans un même contexte.

3. Une combinaison de catégories, consiste à combiner plusieurs catégories Dans l'exemple ci-
dessus, nous pouvons utiliser les catégories "Genre" et "Âge" pour former une une
combinaison de catégories "Âge/Genre".

4. Les combinaisons d'options de catégorie résultent de toutes les combinaisons possibles avec
toutes les options de catégorie dans une combinaison de catégories.

Dans l'exemple ci-dessus, les combinaisons d'options de catégorie suivantes peuvent être créées :
"Femme/ <5 ans", "Femme/> 5 ans, "Homme/ <5 ans", "Homme/> 5 ans"

Il est à noter que le modèle de catégorie est totalement différent du modèle de l'élément de données.
L'association entre les éléments de données et les catégories est souple, en ce sens qu'elle peut être
modifiée à tout moment sans perte de données. Pour reprendre l'exemple pratique ci-dessus, il est
peut-être nécessaire de collecter des données sur les cas de paludisme avec des tranches d'âge plus
granulaires. Au lieu de se limiter à "\<5" et "/>5", une nouvelle catégorie pourrait être créée pour "\<1",
"1-5", ">5" afin de décrire les tranches d'âge plus en détail. Cette catégorie pourrait ensuite être
associée à l'élément de données dans un nouveau formulaire de saisie afin de collecter les données à
un niveau plus granulaire. L'avantage avec cette approche est que le même élément de données est
utilisé, ce qui simplifie l'analyse des données au fil du temps.

Il n'est généralement pas recommandé de modifier simplement ou fréquemment l'association entre les
éléments de données et leurs combinaisons de catégories en raison d'une éventuelle incompatibilité
entre les données collectées à partir de combinaisons de catégories différentes. Dans une autre
section de ce document, nous allons examiner des approches de solutions qui utilisent des
"ensembles de groupes d'options de catégories".

Notez que le système ne fixe pas de limite au nombre d'options de catégorie dans une catégorie ni au
nombre de catégories dans une combinaison de catégories. Toutefois, une limite naturelle survient
lorsque la structure devient désordonnée et difficile à manier. Les combinaisons de catégories
volumineuses avec plusieurs options peuvent rapidement augmenter en taille au point de générer des
milliers de combinaisons d'options de catégories, ce qui peut avoir un impact négatif sur les
performances.

Une paire d'éléments de données et de combinaisons de catégories peut désormais être utilisée pour
représenter n'importe quel niveau de désagrégation. Ce qui se passe en réalité, c'est qu'un certain
nombre de dimensions personnalisées sont attribuées aux données. De même que l'élément de
données représente une dimension indispensable pour les valeurs de données, les catégories y
ajoutent des dimensions personnalisées. Dans l'exemple ci-dessus, nous pouvons désormais, grâce
aux outils de sortie de DHIS2, effectuer une analyse en fonction du "genre" et de la "tranche d'âge"
pour ces éléments de données, de la même manière qu'il est possible d'effectuer une analyse en
fonction des éléments de données, des unités d'organisation et des périodes.

Ce modèle de catégorie peut être utilisé aussi bien dans les formulaires de saisie de données que
dans les rapports d'analyse et les rapports tabulaires. Pour des besoins d'analyse, DHIS2 va calculer
automatiquement des sous-totaux et des totaux pour chaque élément de données associé à une
combinaison de catégories. La règle pour ce calcul est que l'addition des données de toutes les
options de catégorie donnent un total qui fasse sens. Le total de l'exemple ci-dessus est exact

180
Éléments de données et dimensions personnalisées Combinaisons d'attributs

puisqu'en additionnant les "cas de paludisme" saisis pour "Femme < 5 ans", "Homme < 5 ans",
"Femme > 5 ans" et "Homme > 5 ans", l'on obtient le nombre total de "cas de paludisme".

Pour la saisie des données, DHIS2 peut générer automatiquement des formulaires de saisie
tabulaires dans lesquels les éléments de données sont représentés sous forme de lignes et les
combinaisons d'options de catégorie sous forme de colonnes. Cela permet, dans bien des situations,
d'obtenir de bons formulaires avec un minimum d'efforts. Toutefois, nous faisons ici face à un
dilemme, car ces deux préoccupations sont parfois incompatibles. Par exemple, on peut vouloir créer
rapidement des formulaires de saisie de données en utilisant des catégories qui ne respectent pas la
règle du total qui fait sens. Nous estimons toutefois que cette solution est préférable à celle qui
consiste à maintenir deux modèles autonomes et distincts pour la saisie et l'analyse des données.

Un aspect important du modèle de catégorie est que les valeurs des données sont conservées et
associées à une combinaison d'options de catégorie. Cela implique que l'ajout ou la suppression de
catégories dans une combinaison de catégories rend ces combinaisons invalides et qu'une action doit
être menée au niveau inférieur de la base de données pour les corriger. Il est donc recommandé de
bien réfléchir aux désagrégations utiles et de ne pas les modifier trop souvent.

Combinaisons d'attributs

Toutes les données agrégées dans DHIS2 sont toujours associées à quatre dimensions de base :

• Les éléments de données et les combinaisons de catégories représentent la dimension quoi.

• Les unités d'organisation représentent la dimension où.
• Les périodes représentent la dimension quand.

Pour des besoins de saisie et d'analyse des données, l'on peut avoir besoin de plus de catégories.
Les implémenteurs disposent également d'une dimension supplémentaire, appelée "combinaison
d'attributs". Les combinaisons d'attributs sont très similaires aux combinaisons de catégories en ce qui
concerne la manière dont elles sont implémentées dans le système. La différence est qu'elles ne sont
pas directement associées à des éléments de données individuels, mais plutôt à des groupes
d'éléments de données.

Reprenons l'exemple précédent de l'élément de données "Cas de paludisme". Supposons qu'on

veuille collecter des données dans la même unité d'organisation et pour la même période, pour deux
partenaires différents qui travaillent dans cet établissement. Pour attribuer des données à ces
partenaires, nous pourrions créer une catégorie appelée "Partenaire" qui va contenir les noms de
chaque partenaire en tant qu'options de catégorie. Cette catégorie pourrait ensuite être utilisée
comme combinaison d'attributs pour l'ensemble de données dont fait partie l'élément "Cas de
paludisme". Lors de la saisie des données, une option supplémentaire sera disponible. Elle permet à
l'utilisateur de choisir le partenaire concerné par les données.

Ainsi, bien que dans la forme, les combinaisons d'options d'attributs soient équivalentes aux
combinaisons d'options de catégories, elles sont utilisées pour désagréger les données au niveau de
l'ensemble de données. Toutes les valeurs de données qui font partie d'un ensemble de données
associé à une combinaison d'attributs devront être enregistrées et désagrégées avec une cinquième
dimension supplémentaire, en plus des quatre dimensions de base mentionnées ci-dessus. Il n'existe
aucune restriction sur la manière dont une combinaison d'attributs peut être construite, ce qui permet
aux implémenteurs de concevoir des dimensions arbitraires pour des ensembles de données
spécifiques.

Ensembles de groupes et dimensions analytiques

Les combinaisons de catégories et d'attributs sont utilisées lors de la saisie des données pour
effectuer certaines désagrégations, par exemple en fonction de l'âge et du genre. Plus tard, lorsque

181
Éléments de données et dimensions personnalisées Groupes d'éléments de données

les données seront analysées, il peut s'avérer nécessaire de les agréger ou de les regrouper de
différentes manières. Prenons l'exemple d'une catégorie comportant les tranches d'âge suivantes:

• \< 1 an
• 1-4 ans
• 5-10 ans
• 10-15 ans
• 15-19 ans
• 20-29 ans
• 30-49 ans
• 49+ ans

Les données peuvent être saisies en fonction de ces tranches d'âge, mais lorsqu'elles sont analysées
dans les applications d'analyse de DHIS2, il peut s'avérer nécessaire de les regrouper en fonction de
tranches d'âge plus grandes. En utilisant un ensemble de groupes d'options de catégories, nous
pourrions créer deux groupes de catégories, par exemple \<15 et 15+. Chacune des options de
catégorie initiales pourra alors être placée dans le groupe d'options de catégorie qui lui correspond.
Chaque groupe peut ensuite être associé à un ensemble de groupes d'options de catégorie, lequel
sera disponible en tant que nouvelle dimension dans les applications d'analyse.

Les ensembles de groupes d'options de catégorie sont particulièrement utiles pour regrouper à un
niveau supérieur des options de catégorie usuelles. Cette approche est souvent utilisée pour
combiner des éléments de données qui ont pu être collectés en fonction de combinaisons de
catégories associées, mais différentes.

Groupes d'éléments de données

Les éléments de données associés peuvent être regroupés dans un groupe d'éléments de données.
Les groupes d'éléments de données sont très flexibles en ce qui concerne leurs noms et les éléments
qu'ils contiennent.

Les groupes facilitent la recherche et l'affichage de données associées et peuvent également être
utilisés pour agréger les valeurs saisies pour les éléments de données du groupe. Le lien entre les
groupes et les éléments de données n'est pas très important. De plus, les groupes ne sont pas
directement associés aux valeurs des données, ce qui signifie qu'ils peuvent être modifiés et ajoutés à
tout moment sans que les données qu'ils contiennent ne soient affectées.

Ensemble de groupes d'éléments de donnée

À l'instar des ensembles de groupes d'options de catégories, les ensembles de groupes d'éléments de
données peuvent également être utilisés pour regrouper des éléments de données associés.
Supposons qu'on veuille déterminer le nombre total de maladies transmissibles et non transmissibles
à partir d'un ensemble de données sur la morbidité. Un ensemble de groupes d'éléments de données
pourrait être créé avec deux groupes : "Maladies transmissibles" et "Maladies non transmissibles". Les
éléments de données pourraient être répartis dans chacun de ces groupes.

Au cours d'une analyse par tableau croisé dynamique, l'ensemble de groupes d'éléments de données
peut permettre d'agréger les données par groupe d'éléments de données au sein de l'ensemble de
groupes.

This approach allows for highly flexible types of analyses where the exact defintion of the combination
of data elements are not known or which may be difficult to define in the form of an indicator.

182
Ensembles de données et formulaires Qu'est-ce qu'un ensemble de données?

Ensembles de données et formulaires

Ce chapitre traite des ensembles de données et des formulaires, des types de formulaires disponibles
et décrit les bonnes pratiques à suivre lors du passage des formulaires papier aux formulaires
électroniques.

Qu'est-ce qu'un ensemble de données?

Toute la saisie de données dans DHIS2 est organisée à l'aide d'ensembles de données. Un ensemble
de données est une collection d'éléments de données regroupés pour la collecte de données. Dans le
cas d'installations distribuées, ils définissent également des blocs de données destinés à l'exportation
et à l'importation entre des instances de DHIS2 (ex. d'une installation locale d'un bureau
d'arrondissement vers un serveur national). Les ensembles de données ne sont pas directement liés
aux valeurs de données, mais uniquement par le biais de leurs éléments de données et de leurs
fréquences. De ce fait, un ensemble de données peut être modifié, supprimé ou ajouté à tout moment
sans affecter les données brutes déjà stockées dans le système, même si ces modifications vont sans
doute affecter la façon dont les nouvelles données seront collectées.

Un ensemble de données possède un type de période qui contrôle la fréquence de collecte des
données; elle peut être quotidienne, hebdomadaire, mensuelle, trimestrielle, semestrielle ou annuelle.
Les éléments de données à inclure dans l'ensemble de données et le type de période sont définis par
l'utilisateur, ainsi qu'un nom, un prénom et un code. Si des champs calculés sont nécessaires dans le
formulaire de collecte (et pas seulement dans les rapports), alors des indicateurs peuvent également
être affectés à l'ensemble de données, mais ceux-ci ne peuvent être utilisés que dans les formulaires
personnalisés (voir plus bas).

Pour utiliser un ensemble de données dans la collecte de données pour le compte d'une unité
d'organisation spécifique, l'utilisateur doit affecter cette unité d'organisation à l'ensemble de données.
Ce mécanisme détermine quelles unités d'organisation peuvent utiliser quels ensembles de données
et définit simultanément les valeurs cibles pour la complétude des données ( ex. combien
d'établissements de santé dans un district sont censés soumettre l'ensemble de données RCH tous
les mois?)

Un élément de donnée peut appartenir à plusieurs ensembles de données, mais cela nécessite une
réflexion approfondie, car il peut entraîner un chevauchement et une inconstance des données
collectées si les ensembles de données ont par exemple des fréquences différentes et sont utilisés
par les mêmes unités d'organisation.

Qu'est-ce qu'un formulaire de saisie de données ?

Une fois que vous avez affecté un ensemble de données à une unité d'organisation, cet ensemble de
données sera disponible dans Saisie de données (sous Service) pour les unités d'organisation
auxquelles vous l'avez affecté et pour les périodes valides, en fonction du type de période de
l'ensemble des données. Un formulaire de saisie de données par défaut s'affichera. Il s'agit tout
simplement d'une liste d'éléments de données appartenant à l'ensemble de données et comportant
une colonne pour la saisie des valeurs. Si votre ensemble de données contient des éléments de
données avec des catégories telles que des groupes d'âge ou de sexe, des colonnes supplémentaires
seront automatiquement générées dans le formulaire par défaut en fonction des catégories. En plus
du formulaire de saisie de données basé sur une liste par défaut, il existe deux alternatives
supplémentaires : le formulaire par section et le formulaire personnalisé.

Types de formulaires de saisie de données

Le DHIS2 propose à ce jour trois types de formulaires différents, qui sont décrits ci-après.

183
Ensembles de données et formulaires Types de formulaires de saisie de données

Formulaires par défaut

Un formulaire de saisie par défaut est simplement une liste des éléments de données appartenant à
l'ensemble de données ainsi qu'une colonne pour la saisie des valeurs. Si votre ensemble de données
contient des éléments de données dont la combinaison de catégories n'est pas par défaut, comme les
groupes d'âge ou de sexe, des colonnes supplémentaires seront automatiquement générées dans le
formulaire par défaut sur la base des différentes options/dimensions. Si vous utilisez plus d'une
combinaison de catégories dans un ensemble de données, vous obtiendrez un tableau par
combinaison de catégories dans le formulaire par défaut, avec des titres de colonnes différents pour
les options.

Formulaires à section

Les formulaires à section offrent plus de flexibilité lorsqu'il s'agit d'utiliser des formes tabulaires et sont
rapides et simples à concevoir. Votre formulaire de saisie de données nécessite souvent plusieurs
tableaux avec sous-titres, et vous devez parfois désactiver (griser) quelques champs du tableau
(Exemple : certaines catégories ne s'appliquent pas à tous les éléments de données). Ces deux
fonctions sont prises en charge dans les formulaires à section. Après avoir défini un ensemble de
données, vous pouvez définir ses sections avec des sous-ensembles d'éléments de données, une en-
tête et d'éventuels champs gris dans le tableau de la section. L'ordre des sections dans un ensemble
de données peut également être défini. Dans Saisie de Données, vous pouvez maintenant
commencer à utiliser le formulaire à Section ( qui devrait apparaître automatiquement lorsque des
sections sont disponibles pour l'ensemble de données sélectionné). La plupart des formulaires de
saisie de données tabulaires doivent pouvoir être réalisés à l'aide de formulaires de section.
L'utilisation de formulaires par section ou par défaut rend la vie plus facile car il n'est pas nécessaire
de maintenir une conception de formulaire fixe qui inclut des références à des éléments de données.
Si ces deux types de formulaires ne répondent pas à vos exigences, la troisième option est le
formulaire de saisie de données personnalisé, totalement flexible, bien qu'il prenne plus de temps.

Formulaires personnalisés

Lorsque le formulaire que vous souhaitez concevoir est trop compliqué pour les formulaires par défaut
ou les formulaires de section, votre dernière option est l'utilisation d'un formulaire personnalisé. Cette
option prend plus de temps, mais vous offre une flexibilité totale en termes de conception. Dans
DHIS2, le concepteur de formulaire dispose d'un éditeur HTML intégré (CK Editor) qui vous permet
soit de concevoir le formulaire dans l'interface graphique, soit de coller directement votre code HTML
(en utilisant la fenêtre "source" de l'éditeur). Dans le formulaire personnalisé, vous pouvez insérer du
texte statique ou des champs de données (liés à des éléments de données + combinaison d'options
de catégorie) à n'importe quel endroit du formulaire et vous êtes totalement libre de concevoir la mise
en page du formulaire. Une fois qu'un formulaire personnalisé a été ajouté à un ensemble de
données, il sera disponible dans la saisie de données et utilisé automatiquement.

Lors de l'utilisation d'un formulaire personnalisé, des champs calculés peuvent être utilisés pour
afficher, par exemple, des totaux courants ou d'autres calculs basés sur les données saisies dans le
formulaire. Cela peut s'avérer utile, par exemple, dans le cas de formulaires de stock ou de logistique
qui requièrent le solde des articles, les articles nécessaires pour la période suivante, etc. Pour ce
faire, l'utilisateur doit d'abord définir les expressions calculées en tant qu'indicateurs, puis affecter ces
indicateurs à l'ensemble de données en question. Dans le concepteur de formulaires personnalisés,
l'utilisateur peut ensuite affecter des indicateurs au formulaire de la même manière que les éléments
de données. La limite de l'expression calculée est que tous les éléments de données utilisés dans
l'expression doivent être disponibles dans le même ensemble de données puisque les calculs sont
effectués à la volée dans le formulaire et ne sont pas basés sur des valeurs de données déjà stockées
dans la base de données.

184
Ensembles de données et formulaires Du papier au formulaire électronique - Leçons tirées de l'expérience

Du papier au formulaire électronique - Leçons tirées de l'expérience

Lors de la mise en place d'un système d'information de santé informatisé, le système devant être
remplacé est souvent basé sur des rapports papiers. Le processus de migration vers la collecte
électronique de données et l'analyse comporte quelques défis. Les sections suivantes indiquent les
meilleures pratiques sur la façon de les relever.

Identifier les éléments de données autonomes

Généralement, la conception d'un ensemble de données dans DHIS2 est basée sur certaines
exigences d'un formulaire papier déjà utilisé. La logique des formulaires papier n'est pas la même que
le modèle d'élément de donnée et d'ensemble de données du système DHIS2 ; par exemple, un
champ dans un formulaire papier tabulaire est souvent décrit à la fois par des en-têtes de colonnes et
du texte sur chaque ligne, et parfois aussi avec un titre de tableau d'introduction qui fournit plus de
contexte. Dans la base de données, cela est saisi dans un élément de donnée atomique sans
référence à une position dans un format de tableau visuel. Il est donc important de s'assurer que
l'élément de donnée avec les catégories d'éléments de donnée facultatives reflète la pleine
signification de chaque champ individuel dans le formulaire papier.

Laisser les calculs et les répétitions à l'ordinateur - ne capturer que les données brutes

Un autre aspect important à prendre en considération lors de la conception des ensembles de

données est que l'ensemble de données et le formulaire de saisie correspondant (qui est un ensemble
de données avec une mise en page) est un outil de collecte de données et non un outil de rapport ou
d'analyse. Il existe d'autres outils bien plus sophistiqués pour la production des données et
l'établissement de rapports dans le DHIS2 que les formulaires de saisie. Les formulaires papier sont
souvent conçus en tenant compte à la fois de la collecte des données et des rapports et vous pouvez
donc voir des éléments tels que les valeurs cumulées (en plus des valeurs mensuelles), la répétition
des données annuelles (les mêmes données démographiques déclarées chaque mois) ou même des
valeurs des indicateurs telles que les taux de couverture dans le même formulaire que les données
brutes mensuelles. Lorsque vous stockez les données brutes dans la base de données DHIS2 chaque
mois et que vous disposez de toute la puissance de traitement nécessaire dans l'outil informatique, il
n'est pas nécessaire (en fait, ce serait inadmissible et très probablement source d'incohérence)
d'enregistrer des valeurs calculées manuellement telles que celles mentionnées ci-dessus. Vous
devez uniquement saisir les données brutes dans vos ensembles de données/formulaires et laisser
les calculs à l'ordinateur, ainsi que la présentation de ces valeurs aux outils de rapport du DHIS.
Grâce à la fonctionnalité des rapports sur les ensembles de données, tous les formulaires à section
tabulaire seront automatiquement dotés de colonnes supplémentaires à l'extrême droite, indiquant les
valeurs totales et partielles pour chaque ligne (élément de données).

185
Indicateurs Qu'est-ce qu'un indicateur

Indicateurs
Ce chapitre traite des sujets suivants:

• Qu'est-ce qu'un indicateur

• Les buts des indicateurs

• La collecte de données axée sur les indicateurs

• Gestion des indicateurs dans DHIS2

La section suivante décrit ces sujets plus en détail.

Qu'est-ce qu'un indicateur

Dans DHIS2, l'indicateur est un élément central de l'analyse des données. Un indicateur est une
formule calculée basée sur une combinaison d'éléments de données, d'options de catégories,
éventuellement de constantes et d'un facteur. Il existe deux types d'indicateurs : ceux qui ont un
dénominateur et ceux qui n'en ont pas. Les totaux calculés, qui peuvent être composés de plusieurs
éléments de données, n'ont pas de dénominateur. Les indicateurs de couverture (ratios,
pourcentages, etc.) sont composés de deux formules d'éléments de données, l'une représentant le
numérateur et l'autre le dénominateur.

Les indicateurs sont donc constitués de formules d'éléments de données et d'autres composants et
sont toujours multipliés par un facteur (par exemple 1, 100, 100, 100 000). Le facteur est
essentiellement un nombre qui est multiplié par le résultat du numérateur divisé par le dénominateur.
A titre d'exemple concret, l'indicateur "Couverture BCG <1 an" est défini par une formule avec un
acteur 100 (afin d'obtenir un pourcentage), un numérateur ("doses de BCG administrées à des
enfants de moins d'un an") et un dénominateur ("population cible de moins d'un an"). L'indicateur
"Taux d'abandon du DPT1 au DPT3" est une formule de 100 % x ("doses de DPT1 administrées" -
"doses de DPT3 administrées") / ("doses de DPT1 administrées").

Tableau : exemples d'indicateurs

Indicateur Formule Numérateur Dénominateur Facteur

Couverture des Entièrement Entièrement Population < 1 100

<1 an entièrement vacciné/ vacciné (Pourcentage)
vaccinés Population <1 an
x 100

Taux de mortalité Décès maternels/ Décès maternels Naissances 100 000 (le TMM
maternelle naissances vivantes se calcule par
vivantes x tranche de
100 000 100 000)

186
Indicateurs Les buts des indicateurs

Indicateur Formule Numérateur Dénominateur Facteur

Nombre total de Nombre total de Nombre total de Aucun 1

personnes personnes participants à des
participant à des participant à des programmes de
programmes de programmes de soins (Homme
soins soins x 1 âgé de < 18 ans)
+ Nombre total de
participants à des
programmes de
soins (Homme
âgé de plus de
18 ans) + Nombre
total de
participantes à
des programmes
de soins (Femme
âgée de < 18 ans)
+ Nombre total de
participantes à
des programmes
de soins (Femme
âgée de plus de
18 ans)

Les buts des indicateurs

Les indicateurs définis avec des numérateurs et des dénominateurs sont généralement plus utiles
pour l'analyse. Comme il s'agit de proportions, ils sont comparables dans le temps et dans l'espace,
ce qui est très important puisque les unités d'analyse et de comparaison, telles que les districts,
varient en taille et évoluent dans le temps. Un district de 1000 habitants pourrait avoir moins de cas
d'une maladie donnée qu'un district de 10 000 habitants. Cependant, les valeurs d'incidence d'une
maladie donnée seront comparables entre les deux districts en raison de l'utilisation des populations
respectives de chaque district.

Les indicateurs permettent donc des comparaisons et constituent le principal outil d'analyse des
données. DHIS2 devrait fournir des indicateurs pertinents pour l'analyse de tous les programmes de
santé, et pas seulement des données brutes. La plupart des modules de rapport de DHIS2 prennent
en charge les éléments de données aussi bien que les indicateurs, et vous pouvez également les
combiner dans des rapports personnalisés.

La collecte de données axée sur les indicateurs

Étant donné que les indicateurs se prêtent mieux à l'analyse que les éléments de données, le calcul
des indicateurs devrait être le principal moteur de la collecte de données. Il arrive souvent que de
nombreuses données soient collectées mais ne soient jamais utilisées dans un indicateur, ce qui
réduit considérablement la possibilité d'utiliser les données. Soit les éléments de données collectés
devraient être inclus dans les indicateurs utilisés pour la gestion, soit ils ne devraient probablement
pas être collectés du tout.

Dans le cadre de la mise en œuvre, une liste d'indicateurs utilisés pour la gestion devrait être définie
et mise en œuvre dans le DHIS2. Pour l'analyse, la formation devrait se concentrer sur l'utilisation des
indicateurs et sur les raisons pour lesquelles ils sont mieux adaptés que les éléments de données à
cette fin.

187
Indicateurs Gestion des indicateurs dans DHIS 2

Gestion des indicateurs dans DHIS 2

Les indicateurs peuvent être ajoutés, supprimés ou modifiés à tout moment dans DHIS2 sans affecter
les données. Les indicateurs ne sont pas stockés sous forme de valeurs dans DHIS2, mais sous
forme de formules, qui sont calculées chaque fois que l'utilisateur en a besoin. Par conséquent, une
modification des formules n'entraînera qu'un appel à des éléments de données différents lors de
l'utilisation de l'indicateur à des fins d'analyse, sans que les valeurs des données sous-jacentes ne
soient modifiées. Pour plus d'informations sur la gestion des indicateurs, veuillez vous référer au
chapitre sur les indicateurs dans la documentation utilisateur de DHIS2.

188
Procédures de gestion des métadonnées Instances de développement indisponibles ou mal utilisées

Procédures de gestion des métadonnées

Cette section traite des procédures et des recommandations relatives à la maintenance à long terme
des métadonnées dans le cadre de l'implémentation du DHIS2. Elle décrit les défis procéduraux
associés à la coordination des processus de configuration à long terme et fournit des exemples de
procédures opérationnelles normalisées qui peuvent être adaptées et utilisées pour une meilleure
coordination de ces processus.

Les problèmes de procédure pouvant entraîner des complications lors de la gestion des métadonnées
sont entre autres

• Instances de développement indisponibles ou mal utilisées

• Lacunes dans les procédures opérationnelles normalisées (PON) pour ajouter des
métadonnées ou modifier de la configuration
• Manque de coordination lors de l'ajout de nouvelles métadonnées
• Hypothèses incorrectes lors de l'ajout de packages de données numériques basés sur des
normes reconnues ou celles de l'OMS
• Révisions des outils de collecte de données au fil du temps

Instances de développement indisponibles ou mal utilisées

Lorsque vous travaillez sur votre configuration DHIS2, il est recommandé de disposer d'au moins une
instance de développement. Si vous avez plus d'une instance de production, vous devriez envisager
d'avoir une copie de chacune de ces instances à des fins de création de nouvelles métadonnées ou
de modification de votre configuration (figure 1).

développement_vs_production

Figure 1

De nombreux problèmes liés aux métadonnées résultent du fait que les utilisateurs ajoutent des
métadonnées directement dans un système de production. Ces métadonnées ne sont pas configurées
comme il se doit ou ne sont pas utilisées par le système, ce qui entraîne des modifications qui devront
être corrigées lorsqu'elles seront identifiées.

189
Procédures de gestion des Procédures opérationnelles normalisées pour l'ajout de métadonnées ou la
métadonnées modification de la configuration
L'utilisation d'un système de développement permet d'éviter ces problèmes, car les éléments du
système de développement peuvent être supprimés s'ils ne sont pas nécessaires, et ce, sans aucune
incidence sur la configuration ou les données du système de production.

Procédures opérationnelles normalisées pour l'ajout de métadonnées ou la

modification de la configuration

Les PON permettant d'ajouter des métadonnées doivent être disponibles pour toutes les
implémentations de DHIS2. Vous pouvez consulter des exemples de procédures opérationnelles
normalisées pour l'ajout de métadonnées agrégées et d'utilisateurs respectivement.

Lors de l'implémentation des procédures opérationnelles normalisées, il convient de proposer une

formation sur chaque procédure spécifique et de continuer à évaluer son implémentation jusqu'à ce
que la procédure définie devienne une norme. Ces procédures vont souvent au-delà de la
personnalisation/modification des métadonnées et exigent que ceux qui font des ajouts ou modifient la
configuration examinent attentivement la manière dont les éléments sont ajoutés et l'effet l'effet qui en
résulte sur la facilité de fonctionnement du système dans son ensemble.

Manque de coordination lors de l'ajout de nouvelles métadonnées

Au-delà des procédures spécifiques applicables à l'ajout de métadonnées ou à la modification de la

configuration, ces actions doivent être menées de manière coordonnée. Cette coordination peut être
simple, comme des discussions en interne entre les membres de l'équipe, ou plus complexe, comme
un comité qui a une vue d'ensemble sur tous les projets planifiés et qui peut programmer des
modifications en conséquence ; et elle dépendra du contexte d'implémentation.

Le manque de coordination peut souvent entraîner la création de doublons pour les métadonnées. Par
exemple, si deux administrateurs ajoutent le même nouveau formulaire d'agrégation dans un système
sans se tenir mutuellement informés, il est probable que certains éléments de métadonnées soient
dupliqués dans le système.

Dans ce genre de situation, disposer d'un mécanisme de coordination qui informe les personnes
chargées de configurer le système DHIS 2 de ce qui se passe, peut faire gagner du temps et de
l'énergie par la suite, car la suppression de ces doublons peut s'avérer un processus long et
fastidieux.

Hypothèses incorrectes lors de l'ajout de packages de données numériques

Les [paquages de l'OMS] ([Link] ou autres configurations basées sur des normes qui
sont importées dans un système peuvent entraîner l'ajout d'une quantité importante de métadonnées
dupliquées. Par exemple, les packages utilisent uniquement des indicateurs dans leur tableau de
bord. Ces indicateurs peuvent être des doublons d'éléments de données existants. De plus, si les
éléments d'un système existant contenant des métadonnées ne sont pas harmonisés avant
l'importation d'un package basé sur des normes, cela peut entraîner la création d'éléments en double
(tels que des options de catégorie, des ensembles d'options, etc.)

En règle générale, lors de l'importation d'un package basé sur des normes, essayez de réutiliser
autant de métadonnées existantes que possible. Il vous faudra probablement modifier le fichier JSON
du package avant de l'importer afin que les identifiants du fichier d'importation correspondent aux
identifiants qui existaient déjà dans le système vers lequel vous effectuez l'importation.

Pour les tableaux de bord, les indicateurs dupliqués peuvent ne pas poser de problème, surtout s'ils
sont correctement regroupés. Cela doit être jugé au cas par cas afin de déterminer leur impact sur le
système avant d'importer le package.

**Remarque : L'importation de packages doit toujours être effectuée en premier lieu dans un système
de développement. Ce n'est que lorsque tous les problèmes ont été résolus qu'ils peuvent être
importés dans un système de production **

190
Procédures de gestion des métadonnées Révisions des outils de collecte de données au fil du temps

Révisions des outils de collecte de données au fil du temps

Lorsque les outils de collecte de données sont mis à jour au fil du temps, des mesures peuvent être
prises en faveur d'une réutilisation de certains objets plutôt que d'en créer des doublons.

Programmes

Dans la mesure du possible, n'hésitez pas à réutiliser des métadonnées entre différents programmes
d'événements et de tracker. Ces métadonnées sont toujours associées au programme spécifique en
cours de création et maintiendront la séparation requise au sein du système.

Ensembles de données

Concernant les ensembles de données agrégées, la réutilisation de métadonnées peut s'avérer moins
évidente. Un problème est souvent rencontré lorsque les désagrégations sont modifiées d'un
formulaire à l'autre. Considérons l'exemple présenté à la figure 2.

aggregate_form_comparison.png

Figure 2

Ce formulaire révèle que les désagrégations de chaque élément de données ont été modifiées. Plutôt
que de créer de nouveaux éléments de données auxquels seront appliquées ces nouvelles
désagrégations, vous pouvez utiliser une fonction appelée "Category combination override" (écraser
une combinaison de catégories). Cette fonction permet d'associer un élément de données à plusieurs
combinaisons de catégories sur la durée.

Pour écraser la combinaison de catégories, ouvrez votre ensemble de données à partir de

l'application de maintenance. À l'endroit où vous ajoutez vos éléments de données, vous verrez une
petite icône de clé à molette. Lorsque vous la survolez, le message suivant apparaît : "Ecraser la
combinaison de catégories de l'élément de données" (figure 3).

191
Procédures de gestion des métadonnées Ensembles de données

catcombo_override

Figure 3

De là, vous ouvrirez un menu qui répertorie vos éléments de données sur le côté gauche et vous
permet d'écraser les combinaisons de catégories sur le côté droit (Figure 4)

192
Procédures de gestion des métadonnées Ensembles de données

écraser_une sélection_de combinaison de catégories

Figure 4

Sélectionnez simplement la combinaison de catégories pour l'élément de données que vous souhaitez
écraser à l'aide de ce menu.

Remarque : Il vous faudra peut-être créer de nouvelles options de catégorie, catégories et

combinaisons de catégories. Si vous avez à le faire, veuillez consulter l'exemple [procédure
d'agrégation des métadonnées].([Link]
1VXnF5KPfiD45h6wH04kUNShQVno--TmckMHMyLqZm5I/edit?usp=sharing)

Cette fonction présente un avantage particulier : elle vous permet d'examiner les données contenues
dans ces éléments de données réutilisés sur de plus longues durées. Toutes les données saisies dans
ces éléments de données à l'aide de l'ancien formulaire peuvent encore être examinées et comparées
avec les périodes au cours desquelles le nouveau formulaire (et les nouvelles désagrégations) sont
utilisés.

193
Procédures de gestion des métadonnées Taux de déclaration agrégés

Taux de déclaration agrégés

Lorsque vous créez un nouvel ensemble de données destiné à remplacer un ensemble de données
existant, vous devez penser à rationaliser vos taux de déclaration si nécessaire, étant donné que le
nouvel ensemble de données que vous créez n'est associé par défaut à aucun des taux de
déclaration existants. Si vous souhaitez conserver les taux de déclaration dans un même
emplacement, vous pouvez les exporter/importer de l'ancien ensemble de données vers le nouveau. Il
est recommandé de tester ce processus dans une instance de développement avant de l'exécuter
avec votre système de production. Prenez toujours soin de sauvegarder vos données avant de
procéder à des importations.

Afin de récupérer les taux de déclaration existants, vous pouvez interagir avec la ressource /
completeDataSetRegistrations (terminer l'enregistrement de l'ensemble de données) et utiliser la
requête suivante

api/completeDataSetRegistrations?
dataSet=XA8e9AVn8Vo&startDate=2000-01-01&endDate=2017-07-01&orgUnit=mPlB2jqKNP0&children=true

NB : Vous devez remplacer l'ID de l'ensemble de données qui se trouve dans cet exemple par l'ID de
l'ensemble de données de votre propre système, les dates par les dates dont vous avez besoin et les
ID d'unités d'organisations par vos propres ID. Dans cet exemple, nous sélectionnons les taux de
déclaration de toutes les unités d'organisation d'enfants ; vous remplacerez donc l'ID de l'unité
d'organisation par l'ID de parent.

Un résultat sera renvoyé, composé des paramètres suivants pour chaque période pris en compte
dans votre requête.

{completeDataSetRegistrations :
[{"period":"201408","dataSet":"XvcWsuHBsGA","organisationUnit":"ZUwksatWvE8","attributeOptionCombo":"HllvX50cXC0",
stockéPar":"automatique"}]}

Une fois que vous avez récupéré les taux de déclaration, vous pouvez les intégrer au nouvel
ensemble de données à l'aide d'une requête POST adressée au point de terminaison suivant

api/completeDataSetRegistrations

NB : Vous devez remplacer les ID des ensemble de données renvoyés dans la requête initiale par l'ID
du nouvel ensemble de données vers lequel vous importez ces taux de déclaration. Faites-le avant de
publier les informations dans la ressource completeDataSetRegistrations.

Relier les données historiques à l'aide d'indicateurs

Lorsque vous créez de nouveaux éléments de données pour représenter un concept qui était déjà
partiellement représenté, il peut être judicieux de créer des indicateurs qui relient ces éléments de
données. Les données peuvent ainsi être visualisées dans le sens longitudinale au fil du temps (c'est-
à-dire que vous pouvez visualiser les données des nouveaux et des anciens formulaires dans une
même variable lorsque vous créez une sortie). Ce principe repose sur l'hypothèse selon laquelle les
données des anciens et des nouveaux éléments de données ne se chevauchent pas (c'est-à-dire
qu'elles ne sont pas collectées au cours de la même période, ce qui donnerait à l'indicateur une valeur
incorrecte/dupliquée).

Pour ce faire, créez un nouvel indicateur et ajoutez le(s) élément(s) de données ancien(s) au(x)
nouvel(aux) élément(s) de données. Cela vous permettra de créer diverses sorties, avec dans une

194
Procédures de gestion des métadonnées Relier les données historiques à l'aide d'indicateurs

même sortie les données historiques et les données actuelles représentées par la même variable. Si
vous ne le faites pas, il vous faudra sélectionner les 2 (ou plus) éléments de données différents qui
représentent désormais ce concept lors de l'analyse. Cela semblerait également désordonné car ils
seraient représentés par des lignes différentes dans un graphique, des lignes ou des colonnes
différentes dans un tableau, etc., avec des données affichées uniquement pour les variables pendant
la période de collecte.

195
Intégrité et qualité des métadonnées Relier les données historiques à l'aide d'indicateurs

Intégrité et qualité des métadonnées

Bien que la qualité des métadonnées puisse être subjective, certains principes clés peuvent être
évalués objectivement et devraient être respectés dans toutes les implémentations du DHIS2. Pour
évaluer la qualité des métadonnées, une évaluation des métadonnées peut être réalisée. Dans ce
contexte, nous pouvons définir l'évaluation des métadonnées comme l'examen de la qualité de la
configuration d'une implémentation spécifique. Malgré l'étendue du champ d'application, notre objectif
est de décomposer le processus d'évaluation en éléments gérables qui peuvent être examinés,
classés par ordre de priorité et corrigés au fil du temps. L'évaluation régulière des métadonnées et
leur mise à jour permanente constituent une part importante de la configuration et de la maintenance
à long terme de DHIS2. Si les tâches de configuration peuvent souvent être exécutées rapidement
grâce à un certain nombre de mécanismes différents, sans une coordination adéquate, la
configuration des systèmes DHIS2 peut se heurter à un certain nombre de difficultés au fil du temps.
Quelques exemples des effets de ces défis de configuration sont :

• L'impossibilité de trouver les éléments corrects lors de la création des sorties de données
• L'incapacité à désagréger correctement les données lors de la création des sorties de données
• Une incapacité à accéder aux éléments corrects lors de la saisie ou de la création de sorties de
données
• Les défis liés à la qualité des données (quelques exemples : inexactitudes significatives dans
les tendances à long terme des données et des taux de déclaration, possibilité de stocker des
valeurs de données non valides, variables multiples représentant le même concept et stockant
des valeurs de données différentes).
• Difficulté à identifier les éléments à utiliser lors de la configuration des mécanismes d'échange
de données
• Des erreurs lors de la mise à jour des versions de DHIS2
• Gestion d'une quantité énorme de métadonnées non valides

L'objectif de ce guide est de fournir des outils et des méthodes permettant d'identifier les problèmes
liés aux métadonnées. Un guide distinct sur la maintenance des métadonnées est en cours
d'élaboration ; il traite des pratiques de configuration susceptibles d'entraîner des problèmes de
qualité des métadonnées et des moyens de les éviter, par exemple en évitant d'effectuer des travaux
de configuration dans les systèmes de production et en établissant des SoP (procédure d'opération
standardisée) pour les modifications de métadonnées. Enfin, une future section sur le travail avec les
métadonnées fournira des conseils sur comment traiter les problèmes de métadonnées, tels que la
suppression des objets qui ne sont plus utilisés.

La maintenance et l'évaluation des métadonnées doivent être considérées comme des processus
connexes qui s'alimentent mutuellement.

1. Processus réactif : En raison des défis posés par la configuration, un système DHIS2 devra
être révisé et nettoyé en conséquence.
2. Processus proactif : Pour éviter les problèmes de configuration, des processus peuvent être
mis en place afin que la configuration du DHIS2 reste efficace au fil du temps.

196
Intégrité et qualité des métadonnées Évaluation de l'intégrité et la qualité des métadonnées

modèles_de_gestion

Évaluation de l'intégrité et la qualité des métadonnées

Les processus réactifs consistent à évaluer les métadonnées afin d'identifier les problèmes potentiels
et de les résoudre. Il peut s'agir d'un processus exigeant qui doit être correctement planifié, avec du
temps et des ressources consacrés à l'identification et à la résolution des problèmes. Bien que la
planification et l'exécution d'une évaluation des métadonnées soient brièvement abordées [ci-
dessous] (#metadata_assessment_planning), ce guide se focalise sur les aspects plus pratiques et
techniques de l'évaluation des métadonnées et de la résolution des problèmes courants.

Ce guide se focalise principalement sur deux méthodes d'évaluation des métadonnées :

1. par un [examen manuel des métadonnées] (#metadata_assessment_manual)

2. par un [outil d'évaluation des métadonnées] (#metadata_assessment_tool) qui peut être
connecté directement au DHIS2, afin d'effectuer des vérifications des métadonnées

Ces deux méthodes sont décrites ci-dessous.

Planifier et effectuer une évaluation des métadonnées

Pour réaliser l'évaluation, vous pouvez commencer par obtenir l'adhésion d'une grande variété de
parties prenantes. Pour ce faire, il peut être utile de documenter l'étendue des questions abordées
dans ce guide en produisant des statistiques récapitulatives sur les problèmes qui ont été identifiés.
Ces statistiques peuvent être très utiles à présenter à un grand public et peuvent être utilisées pour
soutenir l'adhésion en fournissant de brèves explications sur les problèmes qui ont été identifiés. Dans
le Guide de référence pour l'évaluation des métadonnées, vous trouverez des outils qui vous
aideront à créer des comptes récapitulatifs rapides des problèmes que vous trouvez dans votre propre
implémentation, ainsi que des outils qui génèrent des rapports plus détaillés sur chaque élément
spécifique qui nécessite une attention particulière. Nous recommandons que l'évaluation comporte les
éléments suivants :

1. Définition du champ d'application de l'évaluation et partage de celui-ci avec les parties

prenantes concernées
2. Identification de l'étendue des problèmes au sein d'une implémentation en générant et en
documentant des statistiques récapitulatives de ce qui a été trouvé.
3. Présentation de ces résultats au groupe de parties prenantes
4. Identification des éléments individuels qui posent problème et élaboration de stratégies visant à
les atténuer ou à les corriger, si nécessaire.
5. Détails et priorités des corrections
6. Implémentation de ces corrections sur les systèmes de développement puis de production

197
Intégrité et qualité des métadonnéesExamen manuel des métadonnées{ #metadata_assessment_manual }

Examen manuel des métadonnées{ #metadata_assessment_manual }

L'utilisation de l'[outil d'évaluation des métadonnées] (#metadata_assessment_tool) et des [contrôles

d'intégrité des données] intégrés (#data_admin_data_integrity) est un moyen efficace d'identifier de
nombreux problèmes de métadonnées dans le DHIS2, mais certains processus d'examen ne peuvent
pas être automatisés. Il s'agit notamment de l'examen de :

• Convention d'appellation
• Formule d'indicateurs
• Objets de métadonnées dupliqués
• Sources de données dupliquées
• Configuration des éléments du tableau de bord
• Affectation de l'unité d'organisation du programme et de l'ensemble de données
• Partage des programmes et des données

Problèmes de documentation{ #documenting-issues }

L'examen des métadonnées en vue d'identifier les éventuels problèmes doit toujours être effectué
dans le but de résoudre ces problèmes. Il est parfois possible d'y remédier immédiatement, mais dans
de nombreux cas, cela est impossible. Par exemple, il peut être nécessaire de se concerter avec
différentes parties prenantes pour identifier la source de données ou les définitions de métadonnées
appropriées, ou bien la résolution des problèmes est techniquement compliquée et nécessite des
tests et un examen appropriés. Il est donc important de mettre en place un mécanisme de
recensement des problèmes identifiés, afin d'en assurer le suivi et d'élaborer un plan pour y remédier.

Conventions d'appellation

Pour une analyse complète des principes qui régissent les bonnes conventions de nomenclature,
veuillez consulter cette ressource. Dans la mesure du possible, vous devriez envisager de les
implémenter dans le(s) système(s) que vous êtes en train d'examiner.

Pour mettre à jour les noms de vos métadonnées en vrac, envisagez d'utiliser l'[éditeur de
métadonnées DHIS2] ([Link]
672531419470). Cela vous permettra de modifier toutes vos métadonnées dans une feuille Google et
de synchroniser vos informations avec le serveur. Vous pouvez consulter le guide complet de l'éditeur
de métadonnées [ici] ([Link]
1Y4u78llIOTb5gNPHLJks528kbz8czXH9O6yKMEaLFI0/edit?usp=sharing).

Formule d'indicateurs

Un examen manuel de la formule des indicateurs peut être nécessaire pour déterminer si la formule
des indicateurs est correcte. Bien qu'il s'agisse potentiellement d'une question de configuration,
l'examen de la formule des indicateurs peut affecter la qualité des données et les résultats des
données si des hypothèses incorrectes sont formulées au sujet de la formule. Voici quelques
exemples de points à vérifier lors de l'examen de la formule des indicateurs :

1. S'assurer que les bons éléments de données font partie du numérateur et du dénominateur
respectivement en comparant les éléments de données avec les descriptions du numérateur et
du dénominateur.
2. S'assurer que le bon type d'indicateur a été sélectionné pour l'indicateur examiné
3. Dans la mesure du possible, vérifier que le dénominateur est défini correctement (toutefois, il
peut s'agir plutôt d'un problème de qualité des données, qui doit faire l'objet d'un examen plus
détaillé de la qualité des données)

Vous pouvez utiliser l'[éditeur de métadonnées DHIS2] ([Link]

app/d2_metadata_review_tool/672531419470) pour passer en revue certaines formules si vous êtes
familier avec sa configuration, mais une méthode plus traditionnelle de navigation dans les indicateurs

198
Intégrité et qualité des métadonnées Sources des donnés dupliquées

à travers l'interface utilisateur peut être utilisée à l'aide de l'[application de navigation dans les
métadonnées de l'OMS] ([Link]

Sources des donnés dupliquées

La duplication de données est due au fait que plusieurs variables d'un système DHIS2 produisent des
rapports sur le même sujet. Il existe généralement 3 types de sources de données dupliquées que
vous pouvez rencontrer dans DHIS2 :

• Des variables dupliquées au sein d'un même formulaire de collecte de données

• Des variables dupliquées entre différents programmes (généralement sur des formulaires
différents)
• Des variables dupliquées dans des programmes (sur le même formulaire ou sur des
formulaires différents)

Variables dupliquées sur un même formulaire de collecte de données

Cela se produit lorsqu'un ou plusieurs éléments de données fournissent un total en doublon avec un
ou plusieurs autres éléments de données sur le même formulaire. À titre d'exemple, nous pouvons
examiner les formulaires disponibles dans la figure 1.

duplicate_vars_same_form

Figure 1

Dans ce cas, il est difficile de déterminer la valeur correcte.

Variables dupliquées entre différents programmes

Cela se produit lorsque deux ou plusieurs programmes au sein d'un système intégré collectent les
mêmes informations (figure 2). Dans certains cas, les programmes ne parviennent pas à se mettre
d'accord sur la valeur et celle-ci doit être maintenue telle quelle. Cette situation devient toutefois
problématique lorsqu'il s'agit de déterminer une valeur nationale convenue, car les valeurs peuvent
être différentes d'un programme à l'autre et il n'est pas recommandé de les conserver intactes.

199
Intégrité et qualité des métadonnées Sources des donnés dupliquées

duplicate_vars_different_programs

Figure 2

Variables dupliquées dans des programmes (sur le même formulaire ou sur des formulaires différents)

Cela se produit lorsque les mêmes informations sont collectées dans le cadre d'un même programme
(Figure 3). Cela peut être problématique car il devrait y avoir une concordance entre les valeurs si
possible (ce qui n'est pas toujours le cas lorsque ce problème est constaté).

duplicate_vars_same_programs

Figure 3

Résoudre le problème de duplication des données

Comme pour les problèmes liés à la définition des dénominateurs, ce point devra peut-être faire l'objet
d'un examen plus détaillé en matière de qualité des données. Étant donné que ces découvertes
nécessiteront souvent un examen/une révision des formulaires dans les différents programmes afin de
rationaliser ces sources de données en doublon, ce problème ne sera probablement pas résolu par
une modification immédiate de la configuration. Il est important d'identifier ces problèmes et de
travailler avec les programmes pour les résoudre sur la base des procédures locales.

200
Intégrité et qualité des métadonnées Configuration des éléments du tableau de bord

Configuration des éléments du tableau de bord

Deux éléments sont à prendre en considération lors de l'examen des éléments du tableau de bord :

1. L'élément du tableau de bord doit-il être partagé pour être vu par les groupes d'utilisateurs avec
lesquels le tableau de bord est partagé
2. L'élément du tableau de bord doit-il être associé à des unités d'organisation ou à des périodes
relatives afin de pouvoir être réutilisé ou mis à jour régulièrement

Lorsqu'un élément du tableau de bord doit afficher des données pour une période ou une unité
d'organisation fixe, il n'est pas nécessaire d'appliquer une quelconque relativité à l'élément. Si
l'élément doit être régulièrement mis à jour avec de nouvelles données, ou si les utilisateurs avec
lesquels le tableau de bord est partagé n'ont pas accès aux unités d'organisation fixes sélectionnées
dans l'élément, ces éléments doivent être revus et mis à jour avec des sélections correctes de
périodes relatives et d'unités d'organisation, comme il convient.

Affectation des unités d'organisation des programmes et des ensembles de données{ #program-
and-data-set-organisation-unit-assignment }

Vérifiez que les programmes et les ensembles de données ne sont attribués qu'aux unités
d'organisation qui sont censées établir des rapports à leur sujet. Pour les ensembles de données, cela
peut entraîner des problèmes d'exhaustivité du taux de déclaration (le nombre de déclarations
attendues peut être plus élevé qu'il ne devrait l'être) et des données peuvent être saisies là où elles ne
devraient pas l'être ; tandis que dans le cas des programmes, vous pourriez avoir suivi des entités et/
ou des événements enregistrés dans des unités d'organisation qui ne devraient pas l'être.

Partage des programmes et des ensembles de données{ #program-and-data-set-sharing }

Vérifiez que les paramètres de partage des métadonnées et des données ont été appliqués
correctement aux programmes et aux ensembles de données. En particulier, si des utilisateurs ou des
groupes d'utilisateurs ne peuvent pas effectuer des opérations sur les programmes ou les ensembles
de données alors qu'ils devraient pouvoir le faire, il peut être nécessaire de modifier ces paramètres
de partage.

Une description plus détaillée de l'application des paramètres de partage aux programmes et aux
ensembles de données est disponible dans la documentation ainsi que par un certain nombre de
vidéos sur [YouTube] ([Link]
list=PLo6Seh-066RwslDmyZkiKjejgMCKNaJTC).

Contrôles liés aux catégories{ #category-related-checks }

Options de catégories dupliquées

Les options de catégorie peuvent et doivent être réutilisées dans plusieurs catégories pour
représenter le même concept (par exemple, un groupe d'âge). En plus de réduire l'encombrement et
la confusion potentielle liés à l'existence de plusieurs options pour le même concept, cela facilite
l'analyse des données puisque les éléments de données utilisant la même option de catégorie
peuvent être présentés ensemble avec la même désagrégation dans les outils de visualisation.

Si des options de catégories dupliquées sont identifiées et qu'elles sont incluses dans des catégories
qui font partie de combinaisons de catégories déjà associées à des données, n'essayez pas de les
dédupliquer. Toutefois, si l'une des options de catégorie n'a pas encore été utilisée, elle peut être
supprimée et les autres options peuvent être utilisées.

Désagrégations par catégories{ #category-disaggregations }

Les options de catégorie dans une catégorie d'élément de données doivent en général aboutir à un
total significatif, comme indiqué dans la [section sur la conception du système d'agrégation]

201
Intégrité et qualité des métadonnées Utilisation de l'outil d'évaluation des métadonnées

(#catégories-et-dimensions-personnalisées). C'est le total de la catégorie qui est affiché par défaut si

l'on examine la valeur d'un élément de données désagrégé par cet élément de données. Un exemple
de cette mauvaise pratique est la création d'une catégorie "Patients externes" avec les options "Cas"
et "Décès", qui est appliquée aux éléments de données pour différents diagnostics tels que
"Paludisme". Par défaut, un utilisateur consultant l'élément de données "Paludisme" obtiendra la
somme des "Cas de paludisme" et des "Décès dus au paludisme", un chiffre qui n'a pas de sens.

Dans certains cas, il peut être judicieux de s'écarter de cette règle générale, notamment lorsque
l'utilisation d'une telle catégorie peut réduire considérablement le nombre d'éléments de données
requis. Dans ces cas, l'option "Ignorer le total de la catégorie dans les rapports" doit être activée pour
la combinaison de catégories dont fait partie la catégorie.

Utilisation de l'outil d'évaluation des métadonnées

Bien que des contrôles manuels soient nécessaires pour un certain nombre de questions, un [outil
d'évaluation des métadonnées] ([Link] a également été
développé pour automatiser un certain nombre de contrôles de la qualité des données. Cela inclut la
possibilité d'obtenir les résultats sommaires (nombre de violations) des [contrôles d'intégrité des
données] intégrés (#data_admin_data_integrity). L'outil d'évaluation des métadonnées n'est
actuellement pas intégré au DHIS2 lui-même, mais il s'agit d'un outil autonome basé sur R. Cette
section explique comment interpréter et utiliser les résultats de l'outil d'évaluation, tandis que le
téléchargement, l'installation et l'exécution de l'outil sont décrits sur le dépôt GitHub de l'outil. Une liste
avec des descriptions des contrôles de métadonnées inclus dans l'outil est décrite dans l'Annexe A.

L'outil d'évaluation des métadonnées est principalement basé sur les vues SQL de DHIS2 : l'outil
importe un ensemble de vues SQL dans la base de données DHIS2 évaluée (deux pour chaque
mesure de la qualité des données), accède aux résultats de ces vues SQL via l'API Web et les
présente aux utilisateurs. De plus, l'outil présente certains résultats basés directement sur les
requêtes de l'API Web (liées aux utilisateurs), et peut également afficher les résultats des contrôles
intégrés de l'intégrité des données.

Avertissement L'outil ne doit pas être utilisé directement dans les bases de
données de production. Bien que la seule modification apportée par l'outil à
une base de données soit l'importation de vues SQL, certaines vérifications
peuvent être longues et couteuses et peuvent affecter les utilisateurs qui
interagissent avec le système. Un paramètre est disponible pour désactiver
les requêtes lentes.

Le rapport{ #the-report }

Le rapport lui-même est organisé en quatre sections.

Tableau récapitulatif

Le tableau récapitulatif "Problèmes de métadonnées" donne un aperçu de tous les différents

paramètres de qualité des métadonnées et permet de les trier et de les filtrer. Cette fonction est utile
pour obtenir un aperçu rapide des résultats (par exemple s'il y a des problèmes "critiques" ou
"graves"), ou pour rechercher des problèmes spécifiques (par exemple s'il y a des problèmes liés à
des unités d'organisation).

202
Intégrité et qualité des métadonnées Le rapport{ #the-report }

Tableau récapitulatif

Utilisateurs

La section "Utilisateurs" fournit des mesures clés relatives aux utilisateurs du système. Outre les
informations de base sur le nombre total d'utilisateurs et le nombre d'utilisateurs qui se connectent au
cours d'une période donnée, elle comprend également des informations qui peuvent servir de base à
des changements dans les pratiques de gestion des utilisateurs:

• ◦ Les utilisateurs qui ne se sont jamais connectés* : Lorsqu'un grand nombre de comptes
d'utilisateurs n'ont jamais été utilisés, cela indique que des problèmes existent dans le
processus d'invitation/création de comptes. Si ces comptes ont été créés avec un mot de
passe par défaut, ils pourraient également poser un problème de sécurité.
• Pourcentage d'utilisateurs désactivés : Associé au nombre total d'utilisateurs et à celui des
utilisateurs qui se sont connectés récemment, ce chiffre peut indiquer si les comptes
d'utilisateurs sont désactivés lorsque, pour différentes raisons, les utilisateurs n'ont plus besoin
ou ne doivent plus avoir accès au système (par exemple, parce qu'ils quittent leur poste).
• Nombre/pourcentage d'utilisateurs qui sont des superutilisateurs : Seuls quelques utilisateurs
devraient avoir des droits de superutilisateur (l'autorité " TOUT ").

En outre, deux graphiques montrant la répartition dans le temps de la dernière connexion des
utilisateurs, et la répartition des utilisateurs dans la hiérarchie de l'unité d'organisation peuvent être
utiles pour comprendre si l'affectation et la gestion des utilisateurs sont gérées correctement.

203
Intégrité et qualité des métadonnées Le rapport{ #the-report }

Utilisateurs

Orientations{ #guidance }

La section Orientations présente les mêmes données métriques que le tableau récapitulatif (et les
reprend dans l'annexe A), mais accompagnées d'une explication et d'une recommandation d'action.
Elle est organisée en sections par thème.

204
Intégrité et qualité des métadonnées Interprétation des résultats{ #interpreting-the-results }

Orientatons

Interprétation des résultats{ #interpreting-the-results }

Lors de l'interprétation des résultats du rapport, il est important de garder à l'esprit que tous les
problèmes énumérés dans le rapport ne sont pas nécessairement avérés. Par conséquent, la rigueur
des différents contrôles est de mise :

• Info indique que le contrôle est intégré principalement pour fournir des informations
contextuelles utiles, par exemple pour indiquer le nombre total d'un certain type d'objet.
• Avertissement s'applique aux contrôles qui signalent des points potentiellement problématiques
ou indiquent que les métadonnées ne sont pas bien gérées, mais qui n'entraîneront
généralement pas de problèmes de fonctionnement du système.
• Des problèmes graves peuvent peuvent survenir, par exemple des résultats d'analyses qui
affichent des chiffres erronés ou n'affichent aucune donnée.
• Les problèmes critiques sont divers. Ils peuvent par exemple provoquer l'échec du processus
de génération des tableaux d'analyses.

Bien que les différentes mesures de la qualité des données comportent chacune une recommandation
sur la façon de traiter le problème particulier, elles n'entrent généralement pas dans le détail des
mesures techniques à prendre pour résoudre le problème. Il n'est pas possible de donner des conseils
clairs pour tous les problèmes, qui vont du plus élémentaire (comme le regroupement d'éléments de
données) au plus complexe (par exemple, des combinaisons d'options de catégories en doublon dans
une combinaison de catégories). En général, il est recommandé de résoudre les problèmes via
l'interface utilisateur du DHIS2 ou l'API Web dans la mesure du possible, car cela permet de valider
les modifications apportées. Ce n'est qu'en dernier recours que les problèmes doivent être
correctement corrigés dans la base de données. Toutes les modifications, à l'exception des plus
élémentaires (telles que le regroupement d'éléments de données), doivent être testées
minutieusement dans un système de non-production.

Une section distincte du guide d'implémentation est en cours d'élaboration. Elle fournira davantage
d'exemples et de conseils sur le traitement des problèmes courants liés aux métadonnées, tels que
les modifications par lots, la suppression d'éléments de données avec des données, etc.

205
Intégrité et qualité des ANNEXE A - Paramètres de l'outil d'évaluation des métadonnées{
métadonnées #metadata_assessment_tool_annex_a }
ANNEXE A - Paramètres de l'outil d'évaluation des métadonnées{
#metadata_assessment_tool_annex_a }

Mis à jour le 14.02.2022.

Catégories

Catégories sans options de catégorie.

Les catégories doivent toujours avoir au moins une option de catégorie.

Gravité: Avertissement

Recommandation: Toutes les catégories sans options de catégorie devraient être supprimées du
système si elles ne sont pas utilisées. Dans le cas contraire, des options de catégorie appropriées
devraient être ajoutées à la catégorie.

Combinaisons d'options de catégorie par défaut supplémentaires basées sur l'option de catégorie.

Le système ne doit comporter qu'une seule combinaison d'options de catégorie "par défaut".
L'existence de plusieurs combinaisons d'options de catégories par défaut peut entraîner des
irrégularités tant au niveau de la saisie des données que des résultats d'analyses.

Gravité : Critique

Recommandation: Toutes les références à une combinaison supplémentaire d'options de catégorie

par défaut doivent être remplacées par la combinaison d'options de catégorie par défaut souhaitée.

Options de catégorie sans catégories.

Toutes les options de catégorie doivent appartenir à au moins une catégorie.

Gravité: Avertissement

Recommandation: Les options de catégorie qui ne font partie d'aucune catégorie devraient être
supprimées ou ajoutées à une catégorie appropriée.

Combinaisons d'options de catégorie avec des associations disjointes.

Dans certaines circonstances, des combinaisons d'options de catégorie peuvent exister dans le
système, mais n'avoir aucune association directe avec les options de catégorie qui sont associées aux
combinaisons de catégorie. Cette situation se produit généralement lorsque des options de catégorie
ont été ajoutées à une catégorie et que cette dernière est ensuite ajoutée à une combinaison de
catégories. De nouvelles combinaisons d'options de catégorie sont alors créées dans le système. Si
l'une des options de catégorie est ensuite supprimée dans l'une des catégories sous-jacentes, il peut
en résulter une combinaison d'options de catégorie dite disjointe. Il s'agit d'une combinaison d'options
de catégorie qui n'a pas de lien direct avec les options de catégorie d'aucune des catégories.

Gravité : Grave

Recommandation: Les combinaisons d'options de catégories disjointes devraient être supprimées du

système si possible. Toutefois, si des données sont associées à la combinaison d'options de
catégorie, il faudra déterminer comment traiter ces données.

Combinaisons d'options de catégorie avec une cardinalité incorrecte.

Toutes les combinaisons d'options de catégorie doivent avoir exactement le même nombre
d'associations d'options de catégorie que le nombre de catégories dans la combinaison de catégories.

206
Intégrité et qualité des métadonnées Catégories

Si une combinaison de catégories comporte deux catégories, chaque combinaison d'options de

catégorie doit comporter exactement deux options de catégorie.

Gravité : Grave

Recommandation: Les combinaisons d'options de catégorie dont la cardinalité est incorrecte seront
ignorées par le système d'analyse DHIS2 et devraient être supprimées.

Options de catégorie avec plus d’un élément

Nulla vitae feugiat blandit natoque placerat elementum pharetra senectus et aenean faucibus
pellentesque. Quam, donec auctor in et mi penatibus penatibus. Mauris massa mauris sem vehicula
eu hac fermentum odio mattis sed. Habitant convallis, pellentesque aenean, a nunc vitae non sapien
eu suspendisse. Amet nisi sed quam hac.

Gravité : Grave

Recommandation : Bibendum pellentesque nibh nisl vitae rutrum quis vestibulum feugiat porta et
netus parturient mauris. Nec nascetur libero lacinia id vel mauris pulvinar à augue pharetra.
Elementum urna eget mauris magnis proin. Risus sed sapien ante himenaeos. Hac vitae vestibulum
vestibulum nulla vestibulum ut non consectetur vel lectus ultricies euismod. Suscipit sed sed orci.

Combinaisons de catégories sans catégories.

Toutes les combinaisons de catégories doivent être associées à une ou plusieurs catégories.

Gravité: Avertissement

Recommandation: Les combinaisons de catégories sans catégories ne sont pas utilisables par
DHIS2. Elles doivent soit être supprimées, soit les catégories correctes doivent être ajoutées à la
combinaison de catégories.

Combinaisons d'options de catégorie sans combinaison de catégorie.

Toutes les combinaisons d'options de catégories doivent être associées à une combinaison de
catégories. Dans certains cas, lorsque des combinaisons de catégories sont supprimées, le lien entre
une combinaison d'options de catégorie et une combinaison de catégories peut être corrompu.

Gravité: Avertissement

Recommandation: Vérifiez si des données sont associées aux combinaisons de catégories en

question. Il est probable que les données soient supprimées ou migrées vers une combinaison
d'options de catégorie valide. Toute donnée associée à l'une de ces combinaisons d'options de
catégorie ne sera pas disponible ni dans les modules de saisie de données, ni dans les applications
analytiques.

Combinaisons d'options de catégorie dupliquées au sein d'une combinaison de catégories.

Chaque combinaison de catégories doit comporter un ensemble unique de combinaisons d'options de

catégories. Dans certaines circonstances, des doublons de combinaisons d'options de catégorie
peuvent exister dans le système. Cela résulte généralement de modifications apportées aux
combinaisons de catégories après leur création ou d'une manipulation directe des différents tableaux
de catégories dans la base de données. Il peut en résulter que certaines combinaisons d'options
d'éléments de données/catégories n'apparaissent pas ou ne sont pas disponibles dans les écrans de
saisie des données et/ou dans les applications d'analyse.

Gravité : Grave

207
Intégrité et qualité des métadonnées Graphiques

Recommandation: Les doublons de combinaisons d'options de catégories dans une combinaison de

catégories vous obligeront à fusionner les combinaisons d'options de catégories. Cette opération
nécessite une manipulation directe de la base de données et doit toujours être effectuée dans un
environnement de test. Ce n'est qu'après avoir testé votre procédure de manière approfondie et vous
être assuré qu'elle fonctionne que vous devez l'exécuter dans votre environnement de production.
L'équipe chargée de l'implémentation du DHIS2 a créé une série de fonctions SQL pour vous aider à
supprimer ces COC doublonnés de votre système.

Catégories avec les mêmes options de catégorie

Les catégories ayant exactement les mêmes options doivent être considérées comme fusionnées. Les
catégories ayant exactement les mêmes options de catégorie peuvent être facilement confondues par
les utilisateurs lors de l'analyse.

Gravité: Avertissement

Recommandation: Si des combinaisons de catégories ont déjà été créées avec des catégories
dupliquées, il est recommandé de ne pas prendre de mesures, mais de s'assurer que les utilisateurs
comprennent qu'il peut y avoir deux catégories répétées.

Si l'une des catégories n'est utilisée dans aucune combinaison de catégories, elle devrait être
supprimée du système.

Graphiques

Tableaux qui n'ont pas été consultés au cours des 12 derniers mois{ #charts-which-have-not-been-
viewed-in-the-past-12-months }

Les tableaux doivent être consultés régulièrement dans le système. Dans de nombreux cas, les
utilisateurs créent des tableaux à titre temporaire et ne les suppriment jamais. Cela peut conduire à un
manque d'ordre dans le système. Les tableaux peuvent alors être difficiles à trouver dans l'application
de visualisation.

Gravité: Avertissement

Recommandation: Les tableaux inutilisés peuvent être supprimés directement à l'aide de l'application
de visualisation des données par un utilisateur disposant d'une autorité suffisante. Si les tableaux font
partie d'un tableau de bord, ils devront également être supprimés du tableau de bord.

Tableaux de bord

Nombre total de tableaux de bord dans le système

Nombre total de tableaux de bord dans le système. Gravité : Info

Recommandation: DHIS2 devrait contenir des tableaux de bord utiles pour les utilisateurs.

Tableaux de bord ayant fait l'objet d'une ou de plusieurs visualisations au cours des trois dernières
années{ #dashboards-with-1-or-fewer-views-over-the-past-three-years }

Lorsque des tableaux de bord ne sont pas visualisés par les utilisateurs, cela peut signifier une faible
utilisation des données, que les tableaux de bord n'ont pas été conçus pour être réutilisés (par
exemple dans le cadre d'un exercice de formation ou d'une analyse de données ponctuelle), ou que
l'utilisateur propriétaire du tableau de bord n'est plus actif.

Gravité: Avertissement

208
Intégrité et qualité des métadonnées Éléments de données (agrégés){ #data-elements-aggregate }

Recommandation: Si les tableaux de bord sont pertinents et utiles mais ne sont pas visualisés, des
efforts doivent être consentis pour accroître l'utilisation des données (par exemple, revoir les
paramètres de partage, communiquer avec les utilisateurs, planifier des exercices de formation, etc.)
Dans d'autres cas, les utilisateurs disposant d'une autorisation de superutilisateur devraient être en
mesure de supprimer des tableaux de bord en recherchant leur nom ou en procédant par lots. Il
convient également de s'assurer que le tableau de bord n'est pas en cours d'utilisation dans le cadre
d'une analyse poussée avant de le supprimer du système.

Tableaux de bord non visualisés au cours de l'année écoulée.

Lorsque des tableaux de bord ne sont pas visualisés par les utilisateurs, cela peut signifier une faible
utilisation des données, que les tableaux de bord n'ont pas été conçus pour être réutilisés (par
exemple dans le cadre d'un exercice de formation ou d'une analyse de données ponctuelle), ou que
l'utilisateur propriétaire du tableau de bord n'est plus actif.

Gravité: Avertissement

Recommandation: Si les tableaux de bord sont pertinents et utiles mais ne sont pas visualisés, des
efforts doivent être consentis pour accroître l'utilisation des données (par exemple, revoir les
paramètres de partage, communiquer avec les utilisateurs, planifier des exercices de formation, etc.)
Dans d'autres cas, les utilisateurs disposant d'une autorisation de superutilisateur devraient être en
mesure de supprimer des tableaux de bord en recherchant leur nom ou en procédant par lots. Il
convient également de s'assurer que le tableau de bord n'est pas en cours d'utilisation dans le cadre
d'une analyse poussée avant de le supprimer du système.

Nombre total de tableaux de bord sans éléments.{ #total-number-of-dashboards-with-no-items }

Tous les tableaux de bord doivent avoir du contenu. Les tableaux de bord sans contenu ne servent à
rien et peuvent rendre plus difficile la recherche de tableaux de bord importants avec du contenu.

Gravité : Info

Recommandation: Les tableaux de bord sans contenu qui n'ont pas été modifiés au cours des 14
derniers jours, par exemple, devraient être envisagés à être supprimés.

Éléments de données (agrégés){ #data-elements-aggregate }

Nombre total d'éléments de données agrégées

Aperçu du nombre d'éléments de données agrégées dans le système. Gravité : Info

Recommandation: DHIS2 devrait contenir des éléments de données utiles pour les utilisateurs.

Eléments de données agrégés non utilisés dans aucun favori (directement ou via des indicateurs){
#aggregate-data-elements-not-used-in-any-favourites-directly-or-through-indicators }

Tous les éléments de données agrégées saisis dans DHIS2 doivent être utilisés pour produire un
certain type de résultats d'analyse (graphiques, cartes, tableaux). Il peut s'agir d'une utilisation directe
dans un résultat ou d'une contribution au calcul d'un indicateur utilisé dans un résultat.

Gravité: Avertissement

Recommandation: Les éléments de données qui ne sont pas examinés pendant l'analyse, que ce
soit directement ou indirectement via les indicateurs, devraient être examinés pour déterminer s'ils
doivent encore être collectés. S'ils sont destinés à être utilisés dans le cadre d'un examen de routine,
des résultats associés doivent être créés à partir de ces éléments. Si l'utilisation de ces éléments de
données n'est prévue pour un aucun examen d'informations, il pourront être archivés ou supprimés.

209
Intégrité et qualité des métadonnées Éléments de données (agrégés){ #data-elements-aggregate }

Eléments de données agrégés attribués à une ou plusieurs unités d'organisation (via des ensembles de
données).{ #aggregate-data-elements-assigned-to-1-or-less-orgunit-through-data-sets }

Les éléments de données qui font partie d'un ensemble de données agrégées doivent être attribués à
au moins une unité d'organisation.

Gravité: Avertissement

Recommandation: Si l'ensemble de données est actif, il faut alors revoir les affectations des unités
d'organisation. Si l'ensemble de données n'est pas actif, l'ensemble de données et les éléments de
données associés doivent être supprimés du système.

Eléments de données agrégés ne faisant partie d’aucun groupe d’éléments de données.

Tous les éléments de données doivent figurer dans un groupe d'éléments de données. Cela permet
aux utilisateurs de trouver plus facilement les éléments de données dans les applications d'analyse et
contribue également à rendre des ensembles de groupes d'éléments de données plus complets. Les
opérations de maintenance peuvent également être plus efficaces en appliquant des paramètres de
masse (par exemple, le partage) à tous les éléments de données d'un groupe d'éléments de données.

Gravité: Avertissement

Recommandation: Les éléments de données qui ne font pas partie d'un groupe d'éléments de
données doivent être ajoutés à un groupe d'éléments de données important. Si les éléments de
données ne sont pas nécessaires, ils doivent être supprimés.

Agrégation des éléments de données qui n'ont pas été modifiés au cours des 100 derniers jours et qui
n'ont aucune valeur de données.{ #aggregate-data-elements-that-have-not-been-changed-in-last-100-
days-and-do-not-have-any-data-values }

Éléments de données "abandonnés". Il s'agit d'éléments de données qui n'ont pas été modifiés depuis
au moins 100 jours et auxquels aucune valeur n'est associée. Il s'agit souvent de configurations
nouvelles ou modifiées qui ont été abandonnées à un moment donné.

Gravité: Avertissement

Recommandation: Les éléments de données qui ne sont pas associés à des données et qu'il n'est
pas prévu d'utiliser pour la collecte de données devraient être supprimés.

Agrégation des éléments de données SANS valeurs de données.{ #aggregate-data-elements-with-no-data-

values }

En règle générale, les éléments de données doivent toujours être associés à des valeurs de données.
Si des éléments de données existent dans un ensemble de données actif, mais qu'aucune valeur de
données ne leur est associée, ils peuvent ne pas faire partie des écrans de saisie des données.

Gravité: Avertissement

Recommandation: Envisager de supprimer les éléments de données qui n'ont pas de valeurs de
données.

Agrégation des éléments de données sans valeur au cours des trois dernières périodes (en fonction du
type de période de l'ensemble de données).{ #aggregate-data-elements-with-no-data-values-in-the-last-3-
periods-based-on-data-set-period-type }

Les éléments de données qui n'ont pas de valeurs de données récentes sont susceptibles
d'appartenir à l'une des deux catégories suivantes : 1) ils ont été utilisés précédemment et contiennent
des données utiles/importantes, 2) ils n'ont pas été utilisés de manière significative (par exemple, les

210
Intégrité et qualité des métadonnées Éléments de données (tracker)

valeurs des données proviennent de tests effectués lors de la configuration ou d'un petit projet pilote)
et les données ne sont pas utiles/importantes.

Gravité: Avertissement

Recommandation: Si les éléments de données contiennent des données historiques utiles, ils
doivent être conservés. pensez à renommer les éléments de données et/ou les ensembles de
données pour indiquer clairement qu'ils ne sont plus utilisés pour la collecte de données.

Éléments de données (tracker)

Nombre total d'éléments de données tracker{ #total-count-of-tracker-data-elements }

Aperçu du nombre d'éléments de données tracker dans le système. Gravité: Info

Recommandation: DHIS2 devrait contenir des éléments de données utiles pour les utilisateurs.

Eléments de données tracker ne faisant partie d'aucun groupe d'éléments de données.

Tous les éléments de données doivent figurer dans un groupe d'éléments de données. Cela permet
aux utilisateurs de trouver plus facilement les éléments de données dans les applications d'analyse et
contribue également à rendre des ensembles de groupes d'éléments de données plus complets. Les
opérations de maintenance peuvent également être plus efficaces en appliquant des paramètres de
masse (par exemple, le partage) à tous les éléments de données d'un groupe d'éléments de données.

Gravité: Avertissement

Recommandation: Les éléments de données qui ne font pas partie d'un groupe d'éléments de
données doivent être ajoutés à un groupe d'éléments de données important. Si les éléments de
données ne sont pas nécessaires, ils doivent être supprimés.

Ensembles de données

Nombre total d'ensembles de données.

Nombre total d'ensembles de données dans le système. Gravité : Info

Recommandation: DHIS2 devrait contenir des ensembles de données utiles pour la saisie des
données.

Ensembles de données qui n'ont pas été modifiés au cours des 100 derniers jours et qui sont attribuées à
au plus 1 unité d'organisation.{ #data-sets-that-have-not-been-changed-in-last-100-days-and-are-
assigned-to-1-or-less-orgunits }

Les ensembles de données doivent généralement être attribués à plusieurs unités d'organisation s'ils
sont utilisés, ou ont été modifiés récemment (par exemple au cours des 100 derniers jours) s'ils sont
en cours de développement. Les ensembles de données inutilisés encombrent inutilement la base de
données et peuvent perturber les utilisateurs et les administrateurs. Les ensembles de données
associés à des données historiques, par exemple les formulaires de rapport des années précédentes
qui ne sont plus utilisés, et les ensembles de données conçus pour être utilisés dans une seule unité
d'organisation (par exemple au niveau national) font exception à cette règle.

Gravité: Avertissement

Recommandation: Les ensembles de données qui ne sont pas activement utilisés ou qui sont en
cours de développement devraient être supprimés du système afin de réduire l'encombrement du
système et la taille des métadonnées. Avant de supprimer les ensembles de données, vérifiez qu'ils
ne sont pas associés à des données historiques et conservés pour cette raison.

211
Intégrité et qualité des métadonnées Général

Ensembles de données ne contenant aucune valeur de données au cours des 3 dernières périodes (en
fonction du type de période de l'ensemble de données).{ #data-sets-with-no-data-values-in-the-last-3-
periods-based-on-data-set-period-type }

Les ensembles de données auxquels aucune valeur récente n'est associée sont susceptibles
d'appartenir à l'une des deux catégories suivantes : 1) ils ont été utilisés précédemment et contiennent
des données utiles / importantes, 2) ils n'ont pas été utilisés de manière significative (par exemple, les
valeurs des données proviennent de tests effectués lors de la configuration ou d'un petit projet pilote)
et les données ne sont pas utiles / importantes.

Gravité: Avertissement

Recommandation: Si les éléments de données contiennent des données historiques utiles, ils
doivent être conservés. Envisagez de renommer les éléments de données et/ou les ensembles de
données pour indiquer clairement qu'ils ne sont plus utilisés pour la collecte de données. Les
éléments de données qui ne sont pas activement utilisés et auxquels aucune donnée utile n'est
associée.

Sections de l'ensemble de données avec un ordre de tri incorrect

Les sections d'un ensemble de données sont utilisées pour regrouper certaines sections apparentées
dans un formulaire de saisie de section. Elles peuvent également être ordonnées. L'ordre des sections
peut être corrompu si des sections sont ajoutées ou supprimées.

Gravité: Avertissement

Recommandation: Il est possible de corriger l'ordre de tri des sections des ensembles de données
en utilisant la fonction SQL fixSortOrder disponible dans le référentiel Github dhis2-utils (https://
[Link]/dhis2/dhis2-utils/tree/master/resources/sql). En utilisant ce script, vous pouvez corriger
l'ordre de tri pour chaque section d'éléments de données affectée.

Général

Noms d'objets identifiables comportant des espaces initiaux.{ #names-of-identifiable-objects-which-have-

leading-spaces }

Les objets identifiables portant un nom ne doivent pas contenir des espaces initiaux.

Gravité: Avertissement

Recommandation: Ces objets pourraient être corrigés via l'interface utilisateur de DHIS2. Ils peuvent
également être corrigés directement dans la base de données à l'aide du langage SQL. Vous pouvez
utiliser le code SQL suivant comme modèle pour vous aider à créer la requête exacte dont vous avez
besoin :

UPDATE chart as a SET name = b.name_new from ( SELECT chartid,REGEXP_REPLACE(name,'^\s+','') as

name_new from chart where name ~ '^\s+') b where [Link] = [Link];

Noms d'objets identifiables comportant des espaces finals

Les objets identifiables portant un nom ne doivent pas contenir des espaces finales.

Gravité: Avertissement

212
Intégrité et qualité des métadonnées Indicateurs

Recommandation: Ces objets pourraient être corrigés via l'interface utilisateur de DHIS2. Ils peuvent
également être corrigés directement dans la base de données à l'aide du langage SQL. Vous pouvez
utiliser le code SQL suivant comme modèle pour vous aider à créer la requête exacte dont vous avez
besoin :

UPDATE chart as a SET name = b.name_new from ( SELECT chartid,REGEXP_REPLACE(name,'\s+$','')

as name_new from chart where name ~ '\s+$') b where [Link] = [Link];

Noms d'objets identifiables comportant plusieurs espaces.{ #names-of-identifiable-objects-which-have-

multiple-spaces }

Les objets identifiables portant un nom ne doivent pas contenir des espaces initiaux.

Gravité: Avertissement

Recommandation: Ces objets pourraient être corrigés via l'interface utilisateur de DHIS2. Ils peuvent
également être corrigés directement dans la base de données à l'aide du langage SQL. Vous pouvez
utiliser le code SQL suivant comme modèle pour vous aider à créer la requête exacte dont vous avez
besoin :

UPDATE categorycombo as a SET name = b.name_new from ( SELECT

categorycomboid,REGEXP_REPLACE(name,'\s{2,}',' ') as
name_new from categorycombo where name ~ '\s{2,}') b where [Link] =
[Link];

Indicateurs

Nombre total d'indicateurs.

Aperçu du nombre d'indicateurs dans le système. Gravité : Info

Recommandation: DHIS2 devrait contenir des indicateurs utiles pour les utilisateurs.

Indicateurs ne figurant dans aucun groupe.{ #indicators-not-in-any-groups }

Tous les indicateurs doivent faire partie d'un groupe d'indicateurs. Cela permet aux utilisateurs de
trouver plus facilement les indicateurs dans les applications d'analyse et contribue également à rendre
les ensembles de groupes d'indicateurs plus complets. Les opérations de maintenance peuvent
également être renforcées par la mise en application de paramètres de masse (par exemple; le
partage, le filtrage) à tous les indicateurs d'un groupe d'indicateurs.

Gravité: Avertissement

Recommandation: Les indicateurs qui ne font pas partie d'un groupe d'indicateurs devraient être
ajoutés à un groupe d'indicateurs approprié. Si les indicateurs ne sont pas nécessaires, ils doivent
être supprimés.

Indicateurs non utilisés dans les objets d'analyses OU dans les ensembles de données.{ #indicators-not-
used-in-analytical-objects-or-data-sets }

Tous les indicateurs calculés doivent concourir à l'obtention d'un certain type de résultats d'analyses
(graphiques, cartes, tableaux) ou fournir un retour d'information lors de la saisie des données, du fait
de leur présence dans un ensemble de données.

Gravité: Avertissement

213
Intégrité et qualité des métadonnées Ensembles d'options

Recommandation: Les indicateurs qui ne sont pas régulièrement examinés pendant les analyses,
que ce soit dans un résultat ou dans un ensemble de données, devraient être examinés afin de
déterminer s'ils doivent encore être calculés. S'ils doivent être utilisés dans le cadre d'un examen de
routine, il convient de produire des résultats associés à ces indicateurs. Si ces indicateurs ne seront
pas utilisés pour un examen d'informations, ils peuvent être archivés ou supprimés.

Indicateurs non utilisés dans les objets d'analyses.

Les indicateurs doivent être utilisés pour produire un certain type d'analyse (graphiques, cartes,
tableaux). Remarque : les indicateurs utilisés dans les ensembles de données pour fournir un retour
d'information pendant la saisie des données ne sont pas comptabilisés comme étant utilisés dans les
objets analytiques.

Gravité: Avertissement

Recommandation: Les indicateurs qui ne sont pas régulièrement examinés lors des analyses
devraient être examinés afin de déterminer s'ils sont utiles et nécessaires. S'ils seront utilisés dans le
cadre d'un examen de routine, des résultats associés doivent être créés à partir de ces indicateurs. Si
ces indicateurs ne sont pas destinés à être utilisés pour un quelconque type d'examen d'informations
et ne sont pas utilisés dans les ensembles de données pour un retour d'information lors de la saisie
des données, il convient d'envisager leur suppression.

Ensembles d'options

Ensembles d'options non utilisés.

Les séries d'options doivent être utilisées dans un certain but, que ce soit avec des attributs, des
éléments de données ou des commentaires.

Gravité: Avertissement

Recommandation: Envisagez la suppression des ensembles d'options inutilisées ou s'assurer qu'ils

ont été correctement attribuées.

Ensembles d'options vides

Tous les ensembles d'options doivent généralement comprendre au moins deux éléments. Les
ensembles d'options vides ne servent à rien.

Gravité: Avertissement

Recommandation: Il faut soit ajouter des options à l'ensemble options, soit le supprimer.

Ensembles d'options avec un ordre de tri potentiellement erroné.

Les ensembles d'options contiennent des options qui peuvent être ordonnées. La propriété sort_order
(ordre de tri) doit toujours commencer par 1 et être séquentielle. Si l'ensemble d'options contient trois
options, l'ordre de tri doit être 1,2,3. Dans certaines circonstances, des options peuvent être
supprimées d'un ensemble d'options et l'ordre de tri peut être corrompu. Cela peut conduire à une
situation où il devient impossible de mettre à jour l'ensemble d'options à partir de l'application
Maintenance, et peut causer des problèmes lors de l'utilisation de l'ensemble d'options dans
l'application de saisie des données.

Gravité : Grave

Recommandation: S'il est possible d'ouvrir la série d'options dans l'application de maintenance, vous
pouvez recourir à la série d'options, ce qui devrait corriger le problème. Une autre solution possible
est de mettre à jour directement la propriété sort_order (ordre de tri) de la table optionset (série

214
Intégrité et qualité des métadonnées Unités d’organisation

d'options) dans la base de données, en s'assurant qu'une séquence valide est présente pour toutes
les options de la série d'options.

Unités d’organisation

Unités d'organisation ne figurant pas dans tous les ensembles de groupes d'unités d'organisation
obligatoires{ #orgunits-that-are-not-in-all-compulsory-orgunit-group-sets }

Les groupes d'unités d'organisation marqués comme obligatoires doivent contenir toutes les unités
d'organisation du système. Si certaines unités d'organisation sont absentes des groupes de
l'ensemble de groupes, cela peut entraîner des irrégularités dans les résultats d'analyses, telles que
l'absence de certaines données.

Gravité : Grave

Recommandation: Ajouter toutes les unités d'organisation à un seul groupe au sein d'un groupe
d'unités d'organisation obligatoire.

Unités d'organisation dont la date d'ouverture vient après à la date de clôture.{ #organisation-units-
which-have-an-opening-date-later-than-the-closed-date }

Si une date de clôture a été définie pour une unité d'organisation, elle doit toujours être postérieure à
la date d'ouverture (si une telle date a été définie).

Gravité : Grave

Recommandation: Modifier la date d'ouverture ou de clôture de toutes les unités d'organisation

concernées de sorte que la date de fermeture soit postérieure à la date d'ouverture.

Les unités d'organisation ne devraient pas comporter d'espaces finales.{ #organisation-units-should-not-

have-trailing-spaces }

Les espaces de fin dans les unités d'organisation sont superflus.

Gravité: Avertissement

Recommandation: Si le nombre d'unités d'organisation affectées est faible, la solution la plus simple
consiste à les corriger directement à partir de l'interface utilisateur. Une autre option possible serait de
remplacer tous les espaces multiples en utilisant SQL.

Les unités d'organisation ayant des coordonnés en points doivent être contenues dans leurs unités
mères.{ #organisation-units-with-point-coordinates-should-be-contained-by-their-parent }

Les établissements sont souvent représentés sous forme de points dans la hiérarchie DHIS2. La
géométrie de leurs unités d'organisation mères doit contenir tous les établissements qui leur sont
associés.

Gravité: Avertissement

Recommandation: Souvent, les fichiers de délimitations sont simplifiés lorsqu'ils sont téléchargés
dans DHIS2. Ce processus peut conduire à une situation où des établissements situés à proximité de
la frontière d'un district donné se retrouvent hors du district lorsque la frontière est simplifiée. Ce
problème est plutôt d'ordre esthétique pour la plupart des établissements de DHIS2, mais il pourrait
être sérieux si une analyse géospatiale était tentée sur la base des limites et des coordonnées en
points.

Dans les cas où l'établissement se trouve hors des limites de son unité mère, vous devez confirmer
l'exactitude des coordonnées. Si l'emplacement est proche de la délimitation, vous pouvez

215
Intégrité et qualité des métadonnées Unités d’organisation

reconsidérer la manière dont les fichiers de délimitation ont été simplifiés. Dans le cas contraire, si
l'emplacement de l'établissement est totalement incorrect, il faudra le rectifier.

Unités d'organisation situées à moins de 100 km de Null Island (0,0).{ #organisation-units-located-

within-100-km-of-null-island-00 }

Un problème courant lors de l'importation de coordonnées est l'inclusion de coordonnées situées

autour du point de [Null Island] ([Link] Il s'agit du point de la
surface terrestre où le méridien d'origine et l'équateur se croisent avec une latitude de 0 et une
longitude de zéro. Ce point est également situé au milieu de l'océan. Cette requête identifie tous les
points situés dans un rayon de 100 km autour du point dont la latitude et la longitude sont égales à
zéro.

Gravité : Grave

Recommandation: Mettre à jour les coordonnées de l'unité d'organisation affectée pour qu'elles
correspondent à la bonne localisation.

Les unités d'organisation ne doivent pas comporter plusieurs espaces dans leur nom.{ #organisation-
units-should-not-have-multiple-spaces-in-their-names }

Les noms des unités d'organisation ne devraient pas contenir plusieurs espaces. Ils sont superflus et
peuvent compliquer la localisation des unités d'organisation lors d'une recherche.

Gravité: Avertissement

Recommandation: Si le nombre d'unités d'organisation affectées est faible, la solution la plus simple
consiste à les corriger directement à partir de l'interface utilisateur. Une autre option possible serait de
remplacer tous les espaces multiples en utilisant SQL.

Unités d'organisation avec une géométrie invalide.

DHIS2 utilise l'extension de base de données PostGIS pour gérer les informations géographiques
associées aux unités d'organisation. Les géométries peuvent être considérées comme non valides
pour diverses raisons, notamment les auto-inclusions, les auto-intersections et les polygones en
pointillés. Veuillez consulter la documentation de PostGIS pour une analyse plus approfondie de ce
sujet.

Gravité : Critique

Recommandation: Mettre à jour la géométrie des unités d'organisation affectées avec une géométrie
valide. Il peut être possible d'utiliser la fonction PostGIS ST_MakeValid (rendre valide) pour résoudre
automatiquement le problème. Cependant, dans d'autres cas, il peut être nécessaire de modifier la
géométrie dans un outil SIG, puis de la mettre à jour à nouveau dans DHIS2.

La hiérarchie de l'unité d'organisation doit avoir une racine unique.

Chaque système DHIS2 doit avoir une seule unité d'organisation racine. Il s'agit d'une unité
d'organisation unique à partir de laquelle toutes les autres branches de la hiérarchie sont issues.

Gravité : Critique

Recommandation: Une fois que vous avez décidé quelle unité d'organisation doit être la véritable
racine de la hiérarchie des unités d'organisation, vous devez mettre à jour l'unité d'organisation
parente. Cela peut être fait en utilisant l'API DHIS2 ou en mettant à jour la valeur directement dans la
table organisationunit (unité d'organisation).

216
Intégrité et qualité des métadonnées Unités d’organisation

Unités d'organisation sans coordonnées.

Normalement, toutes les unités d'organisation contenues dans la hiérarchie DHIS2 devraient disposer
d'un ensemble de coordonnées valides. En général, pour toutes les unités d'organisation situées au-
dessus du niveau établissement, ces coordonnées doivent constituer un polygone qui délimite l'unité
d'organisation. Pour les établissements, elles sont généralement représentées sous forme de
coordonnées en points.

Il peut évidemment y avoir des exceptions à cette règle. Les établissements de santé mobiles peuvent
ne pas avoir d'emplacement fixe. Les agents de santé communautaires ou les services inférieurs au
niveau établissement peuvent également ne pas avoir de coordonnées définies ou définissables.

Ce contrôle vous permet de passer en revue toutes les unités d'organisation qui n'ont pas de
coordonnées et de déterminer si elles doivent être mises à jour.

Gravité: Avertissement

Recommandation: Si nécessaire, mettez à jour la géométrie de chaque unité d'organisation de

manière à ce qu'elle soit valide. Vous pouvez être amené à contacter le bureau du gouvernement local
approprié pour obtenir une copie des limites du district, communément appelées "fichiers de forme".
Une autre possibilité consiste à utiliser les fichiers de délimitation disponibles gratuitement auprès du
GADM ([Link]

Si des coordonnées manquent, le personnel de l'établissement peut les fournir en utilisant un

smartphone pour obtenir les coordonnées. Les images de Google Maps peuvent également être
utilisées pour estimer la position d'un établissement, à condition d'avoir une résolution suffisante et de
connaître son emplacement exact.

Unités d'organisation orphelines

Les unités d'organisation orphelines sont celles qui n'ont pas d'unité mère et sont vides. Cela signifie
qu'elles n'ont aucune relation avec la hiérarchie principale des unités d'organisation. Elles peuvent
être créées pendant des importations de métadonnées erronées ou du fait d'une manipulation directe
de la base de données.

Gravité : Critique

Recommandation: Les unités d'organisation orphelines doivent être attribuées à une unité mère ou
être supprimées du système. Il est recommandé d'utiliser l'API du DHIS2 pour accomplir cette tâche,
si possible. Si ce n'est pas possible, elles peuvent être supprimées via SQL direct sur la base de
données DHIS2.

Unités d'organisation appartenant à plusieurs groupes dans un ensemble de groupes.{ #organisation-

units-which-belong-to-multiple-groups-in-a-group-set }

Les unités d'organisation doivent appartenir à un seul groupe dans chaque ensemble de groupes
d'unités d'organisation dont elles sont membres. Si l'unité d'organisation appartient à plusieurs
groupes, les résultats de l'analyse seront imprévisibles.

Gravité : Grave

**Recommandation:**A l'aide de l'application Maintenance, attribuez les unités d'organisation de la

liste des détails à exactement un groupe dans chaque ensemble de groupes.

217
Intégrité et qualité des métadonnées Périodes

Périodes

Périodes ayant les mêmes dates de début et de fin{ #periods-with-the-same-start-and-end-dates }

Des périodes différentes ne devraient pas avoir exactement les mêmes dates de début et de fin.

Gravité : Critique

Recommandation: Toutes les références aux périodes dupliquées devraient être supprimées du
système et réaffectées. Il est recommandé d'utiliser la période dont l'identifiant est le plus bas.

Périodes qui se situent à plus de trois ans dans le futur.{ #periods-which-are-more-than-three-years-in-

the-future }

Dans DHIS2, les périodes sont générées automatiquement par le système. Lorsque de nouvelles
données sont introduites dans le système, de nouvelles périodes sont automatiquement créées. Dans
certains cas, des périodes peuvent être créées par erreur lorsque des données sont envoyées à
DHIS2 pour des périodes situées dans un avenir lointain. Certains clients de saisie de données
peuvent ne pas valider les périodes qui se situent dans le futur, et donc toute période située dans le
futur devrait être réexaminée. Dans certains cas, les données peuvent être valables pour des dates
futures, par exemple pour les objectifs fixés pour l'année fiscale suivante.

Gravité: Avertissement

Recommandation: Si dans le système, des périodes existent au futur, vous devriez examiner les
données brutes soit directement dans le tableau des valeurs de données, soit à travers les tableaux
croisés dynamiques pour vous assurer que ces données sont correctes.

Dans de nombreux cas, les clients peuvent vouloir transmettre des données pour janvier 2021, mais
en raison d'erreurs de saisie, c'est janvier 2031 qui est sélectionné. Par conséquent, toute donnée
concernant un avenir lointain devrait être examinée afin de s'assurer qu'elle ne résulte pas d'une
erreur de saisie.

Périodes situées dans un passé lointain.

Dans DHIS2, les périodes sont générées automatiquement par le système. Lorsque de nouvelles
données sont introduites dans le système, de nouvelles périodes sont automatiquement créées. Dans
certains cas, des périodes peuvent être créées par erreur lorsque des données sont envoyées à
DHIS2 pour des périodes situées dans un passé lointain. Certains clients de saisie de données
pourraient ne pas valider les périodes situées dans un passé lointain, et ces périodes devraient être
examinées minutieusement pour s'assurer que des données ne leur ont pas été attribuées par erreur.

Gravité: Avertissement

Recommandation: Si dans le système, des périodes existent pour un passé lointain, vous devriez
examiner les données brutes soit directement dans le tableau des valeurs de données, soit à travers
les tableaux croisés dynamiques pour vous assurer que ces données sont correctes.

Dans de nombreux cas, les clients peuvent vouloir transmettre des données pour janvier 2021, mais
en raison d'erreurs de saisie, c'est janvier 2031 qui est sélectionné. Par conséquent, toute donnée
concernant un avenir lointain devrait être examinée afin de s'assurer qu'elle ne résulte pas d'une
erreur de saisie.

Règles de programme

Règles de programme sans action.

Toutes les règles du programme devraient comporter une action.

218
Intégrité et qualité des métadonnées Utilisateurs

Gravité : Grave

Recommandation: En utilisant l'interface utilisateur du DHIS2, attribuez une action à chacune des
règles de programme qui n'en a pas. Si la règle de programme n'est pas utilisée, envisagez sa
suppression.

Règles de programme sans priorité.

Toutes les règles du programme devraient disposer d'une priorité.

Gravité : Grave

Recommandation: A l'aide de l'interface utilisateur DHIS2, attribuez une priorité à chacune des règles
du programme qui n'en a pas.

Actions de règles de programme qui doivent envoyer ou programmer un message sans modèle de
message.

Les actions de règles de programme de type "Envoyer un message" ou "Programmer un message"

doivent être associées à un modèle de message.

Gravité : Grave

Recommandation: A l'aide de l'interface utilisateur DHIS2, attribuez un modèle de message à chaque

action de règle de programme qui envoie ou planifie des messages mais qui n'est pas associée à un
modèle de message.

Utilisateurs

Nombre d'utilisateurs dans le système{ #number-of-users-in-the-system }

Le nombre total d'utilisateurs dans le système.

Gravité : Info

Recommandation: Information uniquement.

Utilisateurs non connectés au cours des 30 derniers jours{ #users-who-have-not-logged-in-during-the-

past-30-days }

Tous les utilisateurs doivent se connecter régulièrement, soit pour saisir des données, soit pour
consulter des analyses. Cet indicateur quantifie le nombre d'utilisateurs qui sont activés, mais qui ne
se sont pas connectés au cours des 30 derniers jours.

Gravité: Avertissement

Recommandation: Vérifiez si ces utilisateurs devraient être actifs, sinon envisager la désactivation
des comptes.

Utilisateurs non connectés au cours de l'année écoulée{ #users-who-have-not-logged-in-over-the-past-

year }

Seuls les utilisateurs qui accèdent régulièrement au système devraient avoir un compte d'utilisateur
actif. Les utilisateurs non connectés au cours de l'année écoulée peuvent ne pas utiliser le système ou
ne pas avoir besoin d'y accéder, ils peuvent avoir quitté leur poste et devraient le faire, ou le compte
pourrait être le résultat d'une invitation à enregistrer un compte qui n'a pas été utilisé.

Gravité: Avertissement

219
Intégrité et qualité des métadonnées Règles de validation

Recommandation: Les comptes d'utilisateurs qui ne sont pas associés à des utilisateurs réels et
actifs devraient au moins être désactivés, ou à défaut supprimés.

Règles de validation

Toutes les expressions des règles de validation devraient avoir une stratégie de valeurs manquantes.{
#all-validation-rule-expressions-should-have-a-missing-value-strategy }

Les règles de validation sont composées d'une expression de gauche et d'une expression de droite.
Dans certains systèmes, la stratégie de la valeur manquante peut ne pas être définie. Cela peut
entraîner une exception lors de l'analyse des règles de validation. Les règles de validation concernées
doivent être corrigées en utilisant une stratégie de valeur manquante appropriée.

Gravité : Grave

Recommandation: En utilisant les résultats de la vue SQL détaillée, identifiez les règles de validation
concernées et le volet de la règle pour lequel la stratégie de valeur manquante n'a pas été spécifiée. A
l'aide de l'application de maintenance, effectuez les corrections appropriées et sauvegardez la règle.

220
Utilisateurs et rôles d'utilisateurs À propos de la gestion des utilisateurs

Utilisateurs et rôles d'utilisateurs

À propos de la gestion des utilisateurs

Plusieurs utilisateurs peuvent accéder simultanément au DHIS2 et chaque utilisateur peut avoir des
différents types d'autorisations. Vous pouvez donc régler ces autorisations de manière à ce que
certains utilisateurs ne puissent que saisir des données, tandis que d'autres ne peuvent que générer
des rapports.

• Vous pouvez créer autant d'utilisateurs, de rôles d'utilisateurs et de groupes d'utilisateurs que
vous souhaitez.

• Vous pouvez attribuer des pouvoirs spécifiques à des groupes d'utilisateurs ou à des
utilisateurs individuels via des rôles d'utilisateur.

• Vous pouvez créer plusieurs rôles d'utilisateur, chacun disposant de ses propres autorités.

• Vous pouvez attribuer des rôles d'utilisateur aux utilisateurs pour leur accorder les autorités
correspondantes.

• Vous pouvez attribuer à chaque utilisateur des unités d'organisation. L'utilisateur peut ensuite
saisir des données pour les unités d'organisation qui lui sont attribuées.

Tableau: Termes et définitions relatifs à la gestion des utilisateurs

Terme Définition Exemple

Autorisations Une autorisation pour effectuer Créer un nouvel élément de

une ou plusieurs tâches données
spécifiques
Mettre à jour une unité
d'organisation

Consulter un rapport

Utilisateur Le compte utilisateur DHIS2 administrateur

d'une personne
traore

invité

Rôle de l'utilisateur Un groupe d'autorités Commis à la saisie des données

Administrateur du système

Accès au programme de soin

prénatal

Groupe d’utilisateurs Un groupe d'utilisateurs Personnel du Kenya

Destinataires des feedbacks

Coordinateurs du programme VIH

L'application Utilisateurs vous permet de gérer les utilisateurs, les rôles des utilisateurs et les
groupes d'utilisateurs.

Tableau : Objets dans l'application "Utilisateurs"

221
Utilisateurs et rôles d'utilisateurs À propos des utilisateurs

Type d'objet Fonctions disponibles

Utilisateur Créer, modifier, inviter, cloner, désactiver, afficher par

unité d'organisation, supprimer, afficher les détails

Rôle de l'utilisateur Créer, modifier, partager, supprimer et afficher les

détails

Groupe d’utilisateurs Créer, modifier, rejoindre, quitter, partager, supprimer

et afficher les détails

À propos des utilisateurs

Chaque utilisateur dans DHIS2 doit avoir un compte d'utilisateur identifié par un nom d'utilisateur.
Vous devez enregistrer un prénom et un nom de famille pour chaque utilisateur ainsi que des
informations de contact, par exemple une adresse électronique et un numéro de téléphone.

Vous devez enregistrer les bonnes coordonnées. DHIS2 utilise ces informations pour contacter
directement les utilisateurs, par exemple pour envoyer des courriels afin de les informer d'événements
importants. Vous pouvez également utiliser les informations de contact pour partager, par exemple,
des tableaux de bord et des tableaux croisés dynamiques.

Un utilisateur de DHIS2 est associé à une unité d'organisation. Vous devez donc attribuer l'unité
d'organisation où l'utilisateur travaille.

Lorsque vous créez un compte d'utilisateur pour un responsable de l'enregistrement du district, vous
devez lui attribuer le district où il travaille comme unité d'organisation.

L'unité organisationnelle assignée influence la manière dont l'utilisateur peut utiliser le DHIS2 :

• Dans l'application Saisie de données, un utilisateur ne peut saisir des données que pour l'unité
d'organisation à laquelle il est associé et pour les unités d'organisation qui lui sont
subordonnées dans la hiérarchie. Par exemple, un responsable de l'enregistrement du district
ne pourra enregistrer des données que pour son district et les établissements qui lui sont
subordonnés.

• Dans l'application Utilisateurs, un utilisateur ne peut ajouter de nouveaux utilisateurs que pour
l'unité d'organisation à laquelle il est associé, ainsi que pour les unités d'organisation qui lui
sont subordonnées dans la hiérarchie.

• Dans l'application Rapports, un utilisateur ne peut consulter que les rapports de son unité
d'organisation et de celles qui lui sont subordonnées. (C'est un point que nous envisageons
d'ouvrir pour permettre de faire des rapports de comparaison.)

Une aspect important de la gestion des utilisateurs consiste à contrôler quels utilisateurs sont
autorisés à créer de nouveaux utilisateurs et avec quelles autorités. Dans le système DHIS2, vous
pouvez contrôler quels utilisateurs sont autorisés à effectuer cette tâche. Le principe clé est qu'un
utilisateur ne peut accorder des autorités et un accès à des ensembles de données que s'il y a accès
lui-même. Le nombre d'utilisateurs au niveau national, provincial et du district est souvent relativement
peu élevé et peut être créé et géré par les administrateurs du système. Si la grande majorité des
établissements saisit directement les données dans le système, le nombre d'utilisateurs peut devenir
trop important. Il est donc recommandé de déléguer et de décentraliser cette tâche aux responsables
de district, ce qui rendra le processus plus efficace et permettra de mieux soutenir les utilisateurs des
établissements.

À propos des rôles des utilisateurs

Un rôle d'utilisateur dans le DHIS2 est un groupe d'autorités. Une autorité signifie l'autorisation
d'effectuer une ou plusieurs tâches spécifiques.

222
Utilisateurs et rôles d'utilisateurs À propos des groupes d'utilisateurs

Un rôle d'utilisateur peut contenir des autorités permettant de créer un nouvel élément de donnée,
mettre à jour une unité d'organisation ou visualiser un rapport.

Un utilisateur peut avoir plusieurs rôles d'utilisateur. Dans ce cas, les autorités de l'utilisateur seront la
somme de toutes les autorités et de tous les ensembles de données contenus dans les rôles
d'utilisateur. Cela signifie que vous pouvez mélanger et faire correspondre les rôles d'utilisateur à des
fins particulières au lieu de n'en créer que de nouveaux.

Un rôle d'utilisateur est associé à une collection d'ensembles de données. Cela concerne l'application
Saisie de données : un utilisateur ne peut saisir que les données des ensembles de données
enregistrés pour son rôle d'utilisateur. Cela peut être utile lorsque, par exemple, vous souhaitez
autoriser agents des programmes de santé à ne saisir que les données de leurs formulaires de saisie
concernés.

Recommandations :

• Créer un rôle d'utilisateur pour chaque poste au sein de l'organisation.

• Créer les rôles des utilisateurs en définissant parallèlement quel utilisateur effectue quelles
tâches dans le système.

• Ne donnez aux rôles d'utilisateur que les pouvoirs exacts dont ils ont besoin pour effectuer leur
travail, pas plus. Seules les personnes censées effectuer une tâche doivent avoir le pouvoir de
l'exécuter.

À propos des groupes d'utilisateurs

Un groupe d'utilisateurs est un groupe composés uniquement d'utilisateurs. Vous utilisez les groupes
d'utilisateurs lorsque vous configurez le partage d'objets ou de notifications, par exemple les rapports
push ou les notifications de programmes.

Voir également :

Partage

Gérer les notifications du programme

Gérer les rapports push

Déroulement

1. Définissez les postes dont vous avez besoin pour votre projet et identifiez les tâches que les
différents postes effectueront.

2. Créez plus ou moins un rôle d'utilisateur pour chaque poste.

3. Créez des utilisateurs.

4. Attribuez des rôles d'utilisateur aux utilisateurs.

5. Affectez les utilisateurs à des unités d'organisation.

6. (Facultatif) Regrouper les utilisateurs en groupes d'utilisateurs.

7. Partager des ensembles de données avec des utilisateurs ou des groupes d'utilisateurs via la
boîte de dialogue Partage dans la section Gestion des ensembles de données de l'application
Maintenance.

Conseil

223
Utilisateurs et rôles d'utilisateurs Exemple : gestion des utilisateurs dans un système sanitaire

Pour permettre aux utilisateurs de saisir des données, vous devez donc les
ajouter à un niveau d'unité d'organisation et partager avec eux un
ensemble de données.

Exemple : gestion des utilisateurs dans un système sanitaire

Dans un système de santé, les utilisateurs sont logiquement regroupés en fonction de la tâche qu'ils
accomplissent et du poste qu'ils occupent.

1. Définir les utilisateurs qui doivent jouer le rôle d'administrateur du système. Ils font souvent
partie de la division nationale du HIS et devraient avoir toute autorité dans le système.

2. Créez plus ou moins un rôle d'utilisateur pour chaque poste.

Voici des exemples de positions courantes :

Autorités
Position Tâches spécifiques Commentaire
recommandées

Administrateurs Configurer la structure Ajoutez, mettez à jour Seuls les

système de base (métadonnées) et supprimez les administrateurs du
du système. éléments de base du système doivent
système, par exemple modifier les
les éléments de métadonnées.
données, les Si vous autorisez des
indicateurs et les séries utilisateurs à modifier
de données. les métadonnées, alors
qu'ils ne font pas partie
de l'équipe des
administrateurs du
système, cela peut
entraîner des
problèmes de
coordination.

Les mises à jour du

système ne doivent être
effectuées que par les
administrateurs du
système.

Directeur national de la Suivi et analyse des Accès au module de Vous n'avez pas besoin
santé données rapports, aux d'accès pour entrer des
applications Cartes, Qu données, modifier des
Directeur provincial de alité des données et éléments de données
la santé au tableau de bord. ou des séries de
données.

224
Utilisateurs et rôles d'utilisateurs Exemple : gestion des utilisateurs dans un système sanitaire

Autorités
Position Tâches spécifiques Commentaire
recommandées

Responsables de la Entrer les données Accès à toutes les -

division du système provenant des applications d'analyse
national d'information établissements qui ne et de validation
sanitaire (HISO) sont pas en mesure de
le faire directement Accès à l'application En
Responsables des trée de Données.
archives et de Surveiller, évaluer et
l'information sanitaires analyser les données
de district (DHRIO)

Responsables des
archives et de
l'information sanitaires
des établissements
(HRIO)

Commis à la saisie de - - -
données

225
Lignes directrices pour la saisie de données hors ligne à l'aide du Exemple : gestion des utilisateurs dans
DHIS 2{ #offline_data_entry } un système sanitaire

Lignes directrices pour la saisie de données hors ligne à l'aide du DHIS

2{ #offline_data_entry }
La méthode standard de facto pour le déploiement du DHIS 2 est désormais en ligne, ce qui signifie
qu'une seule instance de l'application est installée sur un serveur connecté à Internet et que tous les
utilisateurs se connectent à l'application à l'aide d'un navigateur web sur internet. Ceci a été rendu
possible grâce à l'augmentation constante de la disponibilité de l'internet (principalement l'internet
mobile), les offres de ressources informatiques en nuage aisément disponibles et bon marché
combiné au fait que DHIS 2 ne demande pas un débit important. Ces développements permettent
d'accéder à des serveurs en ligne même en zone rurale, à l'aide de modems Internet mobiles
(également appelés dongles).

Ce mode de déploiement en ligne a d'énormes implications positives pour le processus

d'implémentation et la maintenance de l'application par rapport au style traditionnel hors ligne et
autonome:

Matériel : Les exigences en matière de matériel du côté de l'utilisateur final se limitent à un ordinateur
/ordinateur portable raisonnablement moderne et à une connectivité Internet la connectivité par le
biais d'une ligne fixe ou d'un modem mobile. Il n'est pas nécessaire d'avoir un serveur spécialisé pour
chaque utilisateur, n'importe quel ordinateur connecté à Internet sera suffisant. Un serveur sera
nécessaire pour les déploiements en ligne, mais comme il n'y a qu'un (ou plusieurs) serveur(s) à
acheter et à entretenir, cela est nettement plus simple (et moins cher) que de maintenir de nombreux
serveurs séparés dans des lieux disparates. Étant donné que le prix des ressources informatiques en
nuage continue de diminuer constamment tout en augmentant la puissance de calcul, la mise en
place d'un serveur puissant dans le nuage est bien moins coûteuse que l'achat de matériel.

Plate-forme logicielle: Les utilisateurs finaux n'ont besoin que d'un navigateur web pour se connecter
au serveur en ligne. Tous les systèmes d'exploitation courants sont aujourd'hui livrés avec un
navigateur web et il n'y a pas d'exigence particulière quant au type ou à la version. Cela signifie qu'en
cas de problèmes graves tels que des infections par des virus ou la corruption de logiciels, on peut
toujours recourir au reformatage et à l'installation du système d'exploitation de l'ordinateur ou obtenir
un nouvel ordinateur/ordinateur portable. L'utilisateur peut continuer à saisir les données là où elles
ont été laissées et aucune donnée ne sera perdue.

Application logicielle: Le style de déploiement de serveur central signifie que l'application peut être
mise à niveau et maintenue de manière centralisée. Lorsque de nouvelles versions des applications
sont publiées avec de nouvelles fonctionnalités et des corrections de bogues, elles peuvent être
déployées sur le serveur unique en ligne. Toutes les modifications seront alors répercutées du côté
client lors de la prochaine connexion des utilisateurs finaux sur Internet. Cela a évidemment un impact
positif énorme sur le processus d'amélioration du système car les nouvelles fonctionnalités peuvent
être distribuées aux utilisateurs immédiatement, tous les utilisateurs accèdent à la même version de
l'application, et les bogues et les problèmes peuvent être triés et déployés à la volée..

Maintenance de la base de données: Comme pour le point précédent, les modifications des
métadonnées peuvent être effectuées sur le serveur en ligne de manière centralisée et se
propageront automatiquement à tous les clients lors de leur prochaine connexion au serveur. Cela
permet d'éviter les problèmes liés à la maintenance d'un ensemble de métadonnées mis à jour et
normalisé, comme c'est le cas pour le déploiement traditionnel hors ligne. C'est extrêmement pratique
par exemple pendant la phase initiale de développement de la base de données et pendant les
processus annuels de révision de la base de données, car les utilisateurs finaux auront accès à une
base de données cohérente et normalisée même si les changements sont fréquents.

Bien qu'une implémentation du DHIS 2 peut être décrite comme un système en ligne, il convient de
noter qu'un tel déploiement peut ne pas être purement en ligne et peut présenter certaines variations
locales en fonction des contraintes locales. Par exemple, alors que la plupart des utilisateurs dans les
pays bénéficient d'un accès facile à leur instance DHIS 2 nationale en utilisant leur internet mobile ou

226
Lignes directrices pour la saisie de données hors ligne à l'aide du DHIS 2{ Cas et solutions
#offline_data_entry } correspondantes
mieux, certains ont malheureusement encore du mal à accéder au système, que ce soit pour la saisie
ou l'analyse des données, dans les endroits où la connectivité Internet est instable ou absente
pendant de longues périodes. Pour ces utilisateurs en difficulté, il faut trouver d'autres moyens
d'interagir avec le système.

Cette ligne directrice vise à fournir des conseils sur la manière d'atténuer l'effet du manque de réseau
internet fiable dans les environnements difficiles.

Cas et solutions correspondantes

Dans cette section, nous examinerons les cas difficiles possibles et décrirons les moyens de les
résoudre ou de minimiser leurs effets sur les utilisateurs et l'ensemble du système à court terme. Il est
évident que les solutions proposées dans ces lignes directrices doivent être adaptées à chaque
contexte tout en tenant compte de nombreux autres paramètres tels que la sécurité, les pratiques et
règles locales, etc. L'idée de ces lignes directrices n'est pas de prescrire des solutions miracles qui
peuvent fonctionner partout, mais de proposer des moyens de résoudre les problèmes de connectivité
dans certains endroits du pays.

Nous avons identifié trois (3) scénarios principaux :

1. Une disponibilité internet limitée et des formulaires de saisie de données de petite taille
2. L'accès à Internet est limité et les formulaires de saisie de données sont très volumineux
3. Internet n'est pas du tout disponible

Nous reconnaissons que ces scénarios sont très simplistes car, dans la pratique, un établissement de
santé peut avoir, par exemple, un petit formulaire hebdomadaire pour la surveillance des maladies, un
grand formulaire pour le rapport d'activité mensuel et un formulaire de taille moyenne pour un
programme de santé. Le nombre de scénarios possibles pour un environnement donné est donc plus
important que ce qui est décrit [Link] appartiendra donc à chaque équipe d'implémentation de discuter
avec les parties prenantes pour faire des choix simples qui répondent à tous les scénarios dans un
contexte donné. Dans la plupart des cas, environ 80 à 95% des districts (ou des établissements de
santé si la saisie des données se fait à ce niveau) auront la même configuration en ce qui concerne la
disponibilité de l'internet et seuls les 5 à 20 % restants auront besoin d'autres alternatives pour obtenir
leurs données dans le DHIS 2.

1. Disponibilité limitée de l'internet (instabilité du signal ou données mobiles limitées) et petits

formulaires de saisie des données.

Par disponibilité limitée de l'internet, nous entendons le cas où :

• le signal du réseau est disponible et bon, mais il n'y a pas suffisamment de ressources
nécessaires à l'achat de données mobiles pour travailler en ligne de manière continue
• le réseau est bon mais instable ou n'est disponible qu'à une période donnée de la journée
• le signal du réseau est faible mais s'améliore de temps en temps et permet de se connecter au
DHIS 2

Et par petit formulaire de saisie, nous entendons un formulaire de saisie ayant moins cent champs.

Ainsi, si la connectivité internet est limitée et que les formulaires de saisie de données sont petits,
deux possibilités s'offrent à vous pour résoudre le problème de connectivité : L'application de saisie de
données Android, et la saisie de données sur le web hors ligne.

227
 1. Disponibilité limitée de l'internet (instabilité du signal
Lignes directrices pour la saisie de données hors
ou données mobiles limitées) et petits formulaires de
ligne à l'aide du DHIS 2{ #offline_data_entry }
saisie des données.
Utilisation d'une application Android de saisie de données :{ #use-of-android-data-capture-app }

L'application Saisie de données du DHIS 2 permet aux utilisateurs d'entrer des données dans un
serveur DHIS 2 à l'aide d'un appareil Android. L'application télécharge les instances de formulaires
nécessaires à la saisie des données du serveur et les stocke sur l'appareil. Cela signifie que les
utilisateurs peuvent saisir des données hors ligne pour les établissements auxquels ils sont affectés,
puis les télécharger sur le serveur DHIS 2 lorsqu'ils disposent d'une une couverture réseau.

Pour ce faire, les utilisateurs devront se rendre sur Google Play à partir de leur appareil Android et de
taper DHIS 2 data capture (saisie de donnée de DHIS2) et de voir apparaître l'écran suivant.

Installez ensuite l'application Data Capture for DHIS 2.(saisie de donnée de DHIS2)

Une fois l'application installée et lancée, l'utilisateur devra fournir l'url de son DHIS 2 national, son nom
d'utilisateur et son mot de passe et appuyez sur LOG IN.(Connexion)


Après une connexion réussie, l'application téléchargera automatiquement les formulaires et les unités
d'organisation auxquels l'utilisateur est affecté et les stockera localement pour la saisie des données.
A partir de là, toute utilisation ultérieure de l'application pour pour la saisie de données ne nécessitera
pas de connexion internet car les instances de formulaires sont déjà stockées localement. La
connexion internet ne sera nécessaire que pour synchroniser les données avec le serveur. Cette
opération peut être effectuée lorsque l'internet est disponible localement.

 

228
 1. Disponibilité limitée de l'internet (instabilité du signal
Lignes directrices pour la saisie de données hors
ou données mobiles limitées) et petits formulaires de
ligne à l'aide du DHIS 2{ #offline_data_entry }
saisie des données.
En ce qui concerne l'administration du système, l'organisation du formulaire de saisie des données en
sections dans DHIS 2 rendra la saisie des données plus fluide, et plus agréable.

En ce qui concerne la synchronisation, lorsque la connectivité internet n'est pas disponible l'utilisateur
emporte son appareil mobile au district - pendant la réunion de district - ou à l'endroit le plus proche
où l'internet est disponible.

Utilisation de la fonctionnalité hors ligne du module de saisie des données sur le web du DHIS 2{ #use-of-
the-offline-capability-of-dhis-2-web-data-entry-module }

Le module de saisie de données sur le web est le module de DHIS 2 qui permet la saisie de données
à l'aide du navigateur web. C'est la méthode habituelle de saisie des données en ligne dans DHIS 2.
Cependant, il dispose également d'une capacité "hors ligne" qui permet de poursuivre la saisie des
données même lorsque l'internet est interrompu. Cela signifie que si l'utilisateur veut saisir des
données à la fin du mois, il doit d'abord se connecter à l'internet, se connecter au DHIS 2 et ouvrir les
formulaires de saisie pour au moins l'une des installations auxquelles il est affecté. À partir de cette
étape, il peut se déconnecter à l'internet et poursuivre la saisie des données pour toutes ses
structures et pour les périodes qu'il souhaite, aussi longtemps que la fenêtre de la page web de saisie
des données n'est pas fermée dans le navigateur web. Après avoir terminé la saisie des données, il
peut fermer le navigateur et éteindre son ordinateur. Les données saisies seront stockées localement
dans le cache du navigateur et la prochaine fois que l'utilisateur se connectera au DHIS 2, il lui sera
demandé de cliquer sur un bouton pour les télécharger.

Dans ce cas, il est possible d'utiliser soit l'application de saisie de données androïde, soit la fonction
web semi-offline du DHIS 2, ou les deux, en fonction de la taille des formulaires de saisie. Toutefois, la
suppression du cache du navigateur entraînera la perte des données stockées localement. Il est donc
recommandé de ne pas vider la mémoire cache sans s'assurer que les données stockées localement
ont bien été synchronisées.

Lorsque l'utilisateur est connecté et que l'internet est coupé (délibérément ou non)

Lorsque l'internet est rétabli et que l'utilisateur se connecte au DHIS 2

229
Lignes directrices pour la saisie de
2. Accès à Internet limité et formulaires de saisie de données
données hors ligne à l'aide du DHIS 2{
volumineux{ #offline_data_entry_cases_huge }
#offline_data_entry }

2. Accès à Internet limité et formulaires de saisie de données volumineux{

#offline_data_entry_cases_huge }

Lorsque l'internet mais la disponibilité est limitée mais que le formulaire d'entrée de données contient
plusieurs centaines de champs, cela limite les solutions envisageables. Dans ce cas, il n'est pas
conseillé d'utiliser la saisie androïde pour deux raisons :

• il peut régulièrement se planter car il n'est pas conçu pour traiter des formulaires de très grande
taille
• il peut s'avérer fastidieux et épuisant pour les utilisateurs car l'écran est petit et ne permet pas
une saisie rapide des données

La seule option possible est donc d'utiliser le module de saisie de données sur le web hors ligne décrit
ci-dessus ou de se rendre à l'endroit le plus proche où Internet est disponible lorsque l'utilisateur ne
peut pas se permettre d'attendre la prochaine fois que l'internet sera disponible dans sa région.

3. Internet n'est pas du tout disponible

Dans ce cas, trois options sont possibles :

• L'utilisation de l'application Android pour la saisie des données au niveau local et la

synchronisation des données au niveau supérieur où l'internet est disponible si l'utilisateur
assiste régulièrement à des réunions à cet endroit. Cette solution n'est envisageable que si les
formulaires sont de petite taille
• Déménager dans le lieu le plus proche (si cela est possible) ou profiter d'une réunion régulière
au niveau supérieur pour saisir des données à l'aide du module de saisie de données en ligne.
Dans ce cas, en fonction de la connectivité internet, l'utilisateur peut travailler en ligne ou
utiliser la capacité hors ligne décrite dans la section [ci-dessus]
(#offline_data_entry_cases_small).
• Demandez au niveau supérieur là où l'internet est disponible pour la saisie des données, quelle
que soit la taille du formulaire. Bien que la saisie des données se fasse au niveau supérieur, les
données peuvent toujours être saisies pour chaque établissement de santé.

230
Intégration des données du tracker et des données Approches alternatives{ #alternative-approaches
agrégées }

Intégration des données du tracker et des données agrégées

Ce guide propose différentes approches pour combiner les données collectées dans le cadre des
programmes tracker avec les données agrégées, afin qu'elles puissent être analysées et être utilisées
ensemble. Les données de suivi et les données agrégées sont collectées et stockées séparément
dans le DHIS2, mais il existe de nombreux cas où il est utile de combiner les deux types de données:

• Les données collectées par les programmes tracker et les ensembles de données agrégées
peuvent être complémentaires. Par exemple, si le programme de suivi est utilisé comme
registre électronique de vaccination, le calcul des couvertures vaccinales exige que les
données sur les services collectées grâce au programme tracker soient combinées avec les
estimations de la population généralement disponibles sous forme de données agrégées
(annuelles).
• Dans de nombreux cas, les implémentations de trackers se font par étapes, en commençant
par certains types d'établissements de santé ou par zone géographique. Par conséquent, les
mêmes données peuvent être collectées grâce au tracker dans certains endroits et sous forme
de données agrégées dans d'autres, et l'obtention d'un aperçu complet des données nécessite
de combiner les données du tracker et les données agrégées. De telles approches
différenciées ou hybrides peuvent également être permanentes.
• Les données collectées grâce au tracker peuvent partiellement se superposer dans les rapports
globaux établis. Par exemple, un rapport mensuel sur les activités liées au paludisme peut
inclure des informations à la fois sur les cas de paludisme et sur les activités préventives telles
que la distribution de moustiquaires. Si le tracker est utilisé pour enregistrer les cas de
paludisme, le rapport mensuel sur le paludisme peut être partiellement complété sur la base
des données du tracker, tout en exigeant des rapports globaux sur les activités préventives.
• Lorsque le suivi est lancé dans un domaine programmatique (vaccination, VIH, etc.) où des
données agrégées ont déjà été collectées, il est nécessaire, pour garantir la comparaison des
données dans le temps, de combiner les données agrégées et les données de suivi afin de
permettre une analyse longitudinale des données.
• Certains contrôles de qualité des données dans DHIS2 ne sont disponibles que pour les
données agrégées. Pour appliquer ces contrôles aux données de suivi, il faut donc d'abord les
agréger et les stocker en tant qu'éléments de données agrégées.

Il existe plusieurs façons d'y parvenir, en fonction des objectifs visés. Chacune de ces approches
présente des avantages et des inconvénients. Dans la [section suivante] (approches - alternatives),
trois approches générales pour combiner les données de suivi et les données agrégées sont
présentées, suivies d'une section sur le [choix d'une approche] (#choosing-an-approach) qui présente
des considérations et des exemples de cas où chacune de ces approches peut être appropriée.
Ensuite, un [guide pratique] (#How-to-saving-aggregated-tracker-data-as-aggregate-data-values) est
fourni pour l'approche basée sur l'enregistrement des données du tracker en tant que valeurs de
données agrégées.

Approches alternatives{ #alternative-approaches }

Les données de suivi et les données agrégées peuvent être combinées dans DHIS2 :

• en affichant des données de suivi et des données agrégées en parallèle dans le même
graphique, tableau, carte ou tableau de bord ;
• en combinant les données agrégées et les données de suivi à l'aide d'indicateurs agrégés ;
• en enregistrant les valeurs calculées sur la base des données de suivi en tant que valeurs de
données agrégées.

Cette section présente un résumé des trois approches, avec les avantages et les inconvénients de
chacune d'entre elles.

231
Intégration des données du tracker et des données Afficher les données de suivi et les données agrégées
agrégées en parallèle
Afficher les données de suivi et les données agrégées en parallèle

Les données agrégées et les données de suivi peuvent être affichées et analysées ensemble si elles
sont incluses dans les mêmes graphiques ou tableaux de Visualisation des données. En outre, des
visualisations de données de suivi peuvent être créées dans les applications Rapport d'événement et
Visualiseur d'événement, et combinées avec des visualisations de données agrégées dans les
tableaux de bord. Tout utilisateur ayant accès aux deux types de données dans les applications
analytiques du DHIS2 peut utiliser cette méthode.

Avantages:

• facile à installer
• Bien adapté à la présentation et à l'analyse de données
complémentaires
• des données détaillées peuvent être incluses (par exemple, des listes
de cas)

Inconvénients:
*dimensionnalité limitée dans l'analyse des données de suivi, c'est-à-dire
pour afficher les désagrégations par âge/sexe * pas totalement intégrées/
comparables avec les données agrégées, par exemple les mêmes
désagrégations ne peuvent pas être appliquées dans une visualisation
unique même si elles sont disponibles dans les données sous-jacentes *
exige que le tracker et les données agrégées se trouvent dans la même
instance DHIS2

Combiner des données avec des indicateurs agrégés

Les indicateurs agrégés peuvent être basés à la fois sur des données agrégées et des données de
suivi, séparément ou combinées en un seul indicateur agrégé. Les éléments de données de suivi, les
attributs des entités suivies et les indicateurs de programme peuvent tous être inclus dans le calcul
des indicateurs agrégés.

Cette méthode peut s'avérer utile dans plusieurs cas de figure :

• Les mêmes données sont collectées à partir d'un ensemble de données agrégées et de
programmes tracker dans différents établissements de santé, c'est-à-dire que certains
collectent des données agrégées et d'autres des données individuelles à l'aide d'un tracker.
• Les mêmes données sont disponibles en tant que valeurs de données agrégées et valeurs de
données de suivi sur des périodes différentes, par exemple si les données collectées en ce
moment par le biais du suivi ont été collectées au cours des années précédentes en tant que
données agrégées.
• Lorsque des indicateurs sont nécessaires sur la base d'une combinaison de données, par
exemple des données sur les services collectées par le biais d'un système de suivi, combinées
à des dénominateurs disponibles sous forme de données agrégées.

Avantages:

• relativement facile à installer

• peut potentiellement dissimuler aux utilisateurs finaux la complexité de
l'intégration des données agrégées et des données de suivi

232
Intégration des données du Enregistrer les agrégats de données de suivi en tant que données
tracker et des données agrégées agrégées{ #saving-aggregates-of-tracker-data-as-aggregate-data }
Inconvénients:

• les données des trackers ne peuvent pas être analysées avec des
désagrégations telles que l'âge/le sexe en tant que dimensions de
données distinctes
• difficile à gérer dans les cas où il peut y avoir des données qui se
superposent
• exige que le tracker et les données agrégées se trouvent dans la
même instance DHIS2

Enregistrer les agrégats de données de suivi en tant que données agrégées{ #saving-aggregates-of-
tracker-data-as-aggregate-data }

Les données du Tracker peuvent être agrégées, par exemple en valeurs hebdomadaires ou
mensuelles, et ces valeurs peuvent être enregistrées en tant que valeurs d'éléments de données
agrégées dans DHIS2. Cela correspond à ce qui est souvent fait manuellement dans les
établissements de santé lorsque les registres sont compilés chaque mois pour produire des rapports
mensuels. Les indicateurs de programme peuvent être définis de manière à produire des chiffres
agrégés basés sur les données du Tracker, correspondant à des éléments de données agrégés. La
valeur de l'indicateur de programme doit représenter la même valeur que l'agrégat (par exemple,
nombre de nouveaux cas de tuberculose et de cas de rechute notifiés ou nombre de doses de BCG
administrées à des enfants de moins d'1 an). Le transfert de données peut être effectué sur une base
Ad-hoc, selon les besoins, ou dans le cadre d'un processus de routine où les données sont
transférées (automatiquement) à des intervalles fixes (voir la figure ci-dessous).

Exemple : Flux d'informations entre une instance DHIS2 avec des programmes de suivi et une
instance DHIS2 HMIS avec des données agrégées.

233
Intégration des données du Enregistrer les agrégats de données de suivi en tant que données
tracker et des données agrégées agrégées{ #saving-aggregates-of-tracker-data-as-aggregate-data }

Exemple : Ensemble de données agrégées (in the data entry app) which has been automatically
filled by the data pushed from tracker program indicators.

Le transfert effectif des données des indicateurs de programme vers les éléments de données
agrégées, peut s'effectuer de plusieurs manières. Il s'agit notamment de:

• de façon manuelle ou via un script adressant une requête à l'API DHIS2 pour exporter les
valeurs des indicateurs de programme et les importer ensuite dans DHIS2 à l'aide de
l'application d'importation/exportation ou de l'API ;
• l'automatisation de l'exportation et de l'importation des données de l'API à l'aide d'un script ;
• l'utilisation d'une des applications développées par la communauté DHIS2 et disponibles sur le
[DHIS2 App Hub] ([Link]) pour exporter et importer les données ;
• l'installation de [Prédicteurs] (#manage_predictor), qui peuvent être programmés pour
transférer régulièrement les valeurs des indicateurs de programme dans les éléments de
données agrégés.

Cette méthode est décrite plus en détail ci-dessous, en insistant sur comment automatiser le
processus à l'aide de scripts.

Avantages:

• les données peuvent être analysées selon la même dimension que les
données agrégées (voir l'exemple de la capture d'écran ci-dessous)
• les données peuvent encore être combinées avec les données
détaillées des trackers (c'est-à-dire la première méthode)
• garantit qu'il n'y a pas de superposition entre les données du tracker et
les données agrégées
• fonctionne lorsque les données du tracker et les données agrégées
sont collectées dans des instances DHIS2 distinctes
• peut améliorer l'efficacité et réduire la charge du serveur DHIS2 en
matière d'analyse, étant donné que les demandes de données pré-

234
Intégration des données du Enregistrer les agrégats de données de suivi en tant que données
tracker et des données agrégées agrégées{ #saving-aggregates-of-tracker-data-as-aggregate-data }
agrégées sont souvent moins exigeantes que l'agrégation à la volée
des données du tracker

Inconvénients:

• plus complexe à installer, et peut nécessiter beaucoup plus d'entretien

continu
• nécessite généralement des outils/scripts externes pour transférer des
données via l'API
• un mapping des données entre le tracker et les données agrégées doit
être développé et entretenu
• si les données sont déplacées entre deux instances DHIS2, les unités
d'organisation doivent également être harmonisées et synchronisées
entre les instances

Exemple : Suivi des cas de tuberculose pour agréger les rapports trimestriels sur la tuberculose
pour les notifications relatives à la tuberculose. Valeurs des données des indicateurs de
programme à partir des données du système de suivi(data elements/disaggregation can be
produced, but not pivoted by dimensions as gender, age group)

235
Intégration des données du tracker et des données agrégées Choisir une méthode

Exemple : Tableau de bord agrégé (with ability to pivot male/female as a data dimension)

Choisir une méthode

Chacune de ces trois méthodes présente des avantages et des inconvénients, comme indiqué ci-
dessus. Pour une seule implémentation, plusieurs d'entre elles peuvent être nécessaires. Par
exemple, il peut être utile de présenter certaines données de suivi avec des mises à jour fréquentes (
par exemple, le nombre quotidien d'enfants vaccinés), en transférant également les valeurs agrégées
des indicateurs de programme, en valeurs agrégées des éléments de données chaque mois, afin que
les données puissent être comparées avec les établissements qui n'utilisent pas encore le tracker, ou
avec une dimensionnalité supplémentaire (telle que les désagrégations par âge/sexe) qui ne peut pas
facilement être effectuée directement avec des données agrégées.

Les deux premières méthodes sont relativement simples à appliquer, grâce aux applications standard
intégrées à DHIS2. Alors que la configuration des indicateurs agrégés (deuxième méthode) doit être
effectuée par un administrateur système ayant accès à la configuration de ces indicateurs, tout
utilisateur ayant accès aux applications d'analyse de DHIS2 et aux données elles-mêmes peut utiliser
ces méthodes. Cependant, une limite majeure est la nécessité d'avoir le tracker et les données
agrégées dans la même instance de DHIS2.

La troisième méthode, qui consiste à enregistrer les données du tracker en tant que valeurs de
données agrégées, présente certains avantages en termes d'analyse. Toutefois, il s'agit également de
la seule méthode permettant d'intégrer des données de suivi à des données agrégées dans des
instances DHIS2 distinctes. De nombreux pays disposent d'une instance DHIS2 mature et stable,
utilisée principalement pour la saisie de données agrégées dans le cadre de programmes de santé
dans un environnement intégré (par exemple, un Système d'Information sur la Gestion de la Santé,
HMIS). Lors de l'implémentation du tracker DHIS2 pour la collecte de données au niveau individuel, il
est généralement recommandé de le faire dans une instance DHIS2 distincte dédiée au déploiement
du tracker. En séparant le tracker et les instances agrégées de DHIS2, les performances peuvent être
mieux contrôlées par les administrateurs du système, les mises à jour de DHIS2 peuvent être
effectuées de manière indépendante et les principes de gouvernance des données peuvent être
appliqués pour garantir que les données personnelles identifiables recueillies par le tracker peuvent
être protégées conformément aux politiques nationales et aux cadres de gouvernance.

Lorsqu'il existe un système de rapports agrégés de routine à partir des données du DHIS2, il est
clairement avantageux de pouvoir exploiter la collecte de données individuelles à l'aide d'un tracker

236
Intégration des données du Mode opératoire : enregistrement des données tracker agrégées en tant que
tracker et des données valeurs de données agrégées{ #how-to-saving-aggregated-tracker-data-as-
agrégées aggregate-data-values }
pour "rapporter" automatiquement des données agrégées au HMIS de routine. L'alternative est
souvent que cela soit fait manuellement par les établissements de santé, puisque ces résumés
agrégés sont importants pour la gestion des établissements de santé individuels, et que le rapport de
routine des données agrégées est souvent obligatoire. La saisie de données individuelles par le biais
du système de suivi DHIS2 peut améliorer la qualité des données communiquées dans le système
d'information sur les ménages HMIS, tout en permettant une analyse ad hoc des données
individuelles du système de suivi, selon les besoins.

Techniquement, il existe plusieurs façons de procéder. Dans la section "Comment faire" ci-dessous,
l'accent est mis sur les étapes nécessaires à l'installation d'une migration automatisée des données
du tracker vers des valeurs de données agrégées.

Mode opératoire : enregistrement des données tracker agrégées en tant que valeurs
de données agrégées{ #how-to-saving-aggregated-tracker-data-as-aggregate-data-
values }

Cette section décrit la méthode recommandée pour enregistrer les données de suivi sous forme de
valeurs d'éléments de données agrégées. Bien qu'elle nécessite un outil ou un script externe dans le
cadre du transfert des données, cette méthode s'appuie autant que possible sur les fonctionnalités
existantes de DHIS2, de sorte que le script puisse être relativement simple. La méthode décrite ici est
également celle adoptée dans les paquets de configuration de l'OMS pour le DHIS2, qui comprend le
mapping des variables entre les programmes de suivi et les ensembles de données agrégées, le cas
échéant. Cette méthode est examinée plus en détail [ci-dessous] (#dhis2-digital-data-packages-and-
linking-tracker-and-aggregate-data).

La méthode décrite ici est recommandée comme solution automatisée à long terme pour sauvegarder
les données du tracker en tant que valeurs de données agrégées. Techniquement, il existe plusieurs
autres façons d'agréger et de transférer les données, notamment en utilisant des prédicteurs, en
exportant les données et en les transformant à l'aide d'autres logiciels (par exemple Excel), ou par le
biais d'applications DHIS2 personnalisées (dont certaines sont disponibles dans le [DHIS2 App Hub]
([Link]). Bien qu'ils ne soient pas décrits dans ce guide, ces outils et méthodes peuvent être
utiles dans de nombreux cas, notamment en combinaison avec la démarche décrite ici. Par exemple,
s'il est nécessaire d'effectuer uniquement des transferts ad hoc de données de temps en temps, ou
lors d'une phase initiale d'implémentation d'un tracker, lorsque les données sont transférées
principalement à des fins de test et que la configuration est encore en cours de modification.

Considérations d'implémentation

L'intégration des données collectées au moyen du tracker avec les flux de rapports agrégés existants
( par exemple le HMIS) nécessite de prendre des décisions relatives à la gouvernance des données,
et cela affecte l'accès aux données, la gestion des systèmes et bien d'autres choses encore.
Quelques aspects clés sont présentés ici.

Transfert de données

Il y a deux aspects essentiels à prendre en compte en matière de transfert de données :

**Quelle est la fréquence de transfert des données agrégées du tracker vers les valeurs de données
agrégées ? ** Lorsque le transfert est automatisé, la fréquence du transfert peut être quotidienne ou
unique par période de rapport/d'agrégation (par exemple, hebdomadaire, mensuelle, trimestrielle).
Des mises à jour plus fréquentes signifient que les données deviennent disponibles en tant que
valeurs de données agrégées et peuvent être utilisées et analysées plus rapidement, et qu'elles sont
mises à jour au fur et à mesure que de nouvelles informations à jour sont reçues. L'utilité de ces
données dépend du programme tracker en question. Par exemple, la mise à jour quotidienne des
données au cours d'une période de déclaration peut être une information utile si elle est mise à la
disposition du personnel de l'établissement, mais elle est moins utile si l'objectif de l'agrégation est

237
Intégration des données du tracker et des données agrégées Considérations d'implémentation

principalement de faciliter et d'automatiser la déclaration de routine du HMIS à des niveaux plus

élevés.

Combien de temps faut-il remonter pour ajouter des données et les mettre à jour? En plus de la
décision sur la fréquence de transfert des données, il faut décider jusqu'à quand (combien de
périodes) les données doivent être mises à jour, et s'il faut ou non transférer les données pour la
période en cours (pour laquelle les données ne seront pas complètes, voir le point précédent). Cette
décision devra peut-être s'aligner sur les pratiques potentiellement existantes en matière de données
agrégées, telles que le moment ou la manière dont elles sont validées et le fait qu'elles soient ou non
verrouillées à un moment donné pour être modifiées, comme nous le verrons ci-dessous. Dans le
même ordre d'idées, on peut se demander s'il convient d'établir une distinction entre la migration de
nouvelles valeurs de données et la mise à jour de valeurs déjà déclarées.

Les échanges sur ces questions doivent tenir compte du fait que les données des systèmes de suivi
sont souvent saisies rétroactivement sur la base de registres papier, plutôt que directement pendant la
prestation de services ou les rencontres avec les patients. En outre, les données peuvent être
corrigées et éditées pendant un certain temps après l'événement, par exemple si, lors d'une visite de
suivi, une erreur est détectée dans les données de la visite précédente.

À moins qu'il n'y ait de raisons valables de procéder autrement, il est suggéré que les mises à jour et
les vérifications soient effectuées en remontant aussi loin dans le temps qu'il y ait des chances
raisonnables que des ajouts et des mises à jour soient apportés aux données de suivi sous-jacentes.
Cela permet de s'assurer que les informations utilisées sont les plus correctes et les plus récentes,
même si cela peut nécessiter des changements dans les normes de gestion des données du système
HMIS, par exemple en ce qui concerne la validation et le verrouillage des données.

Qualité et validation des données{ #data-quality-and-validation }

Garantir la qualité des données est une préoccupation majeure tant pour les données du tracker que
pour les données agrégées, et la liaison des deux, introduit de nouveaux dilemmes potentiels dans ce
domaine. Il existe des outils et des méthodes permettant de limiter les risques d'erreurs lors de la
collecte des données du tracker. Néanmoins, il y a toujours un risque que des erreurs surviennent.
Pendant la période au cours de laquelle les données agrégées basées sur le tracker sont encore
mises à jour régulièrement (comme décrit dans la section précédente), les corrections apportées aux
données du tracker se transfèrent automatiquement aux données agrégées. Toutefois, il existe deux
scénarios pour lesquels il convient de décider comment traiter les corrections apportées aux données
:

Si des erreurs sont détectées et corrigées dans le tracker, après la période au cours de laquelle
les données sont régulièrement transférées et/ou après que les données agrégées ont été validées et/
ou verrouillées. Les moyens possibles pour résoudre ce problème sont les suivants : - la mise en
place d'un système de gestion de l'information :

• vivre avec la divergence dans les données agrégées (si l'erreur est mineure) ;
• effectuer un transfert ad hoc des données pour les périodes concernées ;
• corriger manuellement les données agrégées.

Si des problèmes de qualité des données sont détectés dans les données agrégées. Ce
scénario est moins probable, car seules des erreurs relativement importantes ou systématiques dans
les données du tracker seront visibles lorsque les informations sont agrégées, ou si les données sont
manifestement incomplètes. Les moyens possibles de résoudre ce problème sont les suivants :

• corriger les données sources dans le tracker, puis retransférer les données (si possible) ;
• corriger/éditer les données agrégées (si possible) et accepter la divergence.

Un autre aspect pertinent de la qualité des données lors de l'agrégation des données de suivi
concerne l'actualité et la complétude des données, qui sont des mesures clés de la qualité des

238
Intégration des données du tracker et des données agrégées Considérations d'implémentation

données pour les rapports agrégés (par exemple, dans le HMIS). Lorsque les données agrégées sont
communiquées directement par l'intermédiaire du DHIS2, les utilisateurs cliquent sur un bouton pour
indiquer qu'un ensemble de données particulier (formulaire de rapport) a été déclaré dans son
intégralité. Ces données servent de base au calcul de l'actualité (soumissions dans un délai précis) et
de la complétude des données. Lorsque les données agrégées sont générées sur la base des
données de suivi, aucune information sur la complétude et l'actualité des données n'est disponible.
Plusieurs méthodes peuvent être envisagées à cet effet :

• Dans certains cas, il ne pose pas de problème qu'il n'y ait pas de règles de complétude et
d'actualité des données. Il n'y a généralement pas d'informations sur la complétude et l'actualité
des données du tracker, et les valeurs des données agrégées générées à partir des données
du tracker peuvent être considérées de la même manière. C'est le cas, par exemple, si les
données sont transférées principalement pour faciliter l'analyse des données avec une
dimensionnalité additionnelle, ou pour utiliser des outils d'analyse pour les données agrégées.
• Si les données constituent un sous-ensemble d'un ensemble particulier de données
régulièrement déclarées, où d'autres parties sont saisies directement en tant que données
agrégées, les informations relatives à la complétude des données de suivi, pourraient être
vérifiées et déclarées dans le cadre de la complétude de l'ensemble des données.
• L'information sur la complétude et la promptitude peut être gérée manuellement par l'utilisateur
responsable de la soumission des données agrégées. Cela peut se faire dans le cadre d'un
processus de validation, où l'utilisateur vérifie les données (dans l'application de saisie des
données agrégées) et confirme ensuite que les données sont complètes. Bien que ceci
permette une étape de validation supplémentaire, ceci nécessite également plus de
ressources, et une véritable validation des données exigerait dans une certaine mesure un
certain degré de comptage manuel qui va en partie à l'encontre de l'objectif de l'automatisation
de l'agrégation des données de suivi.
• Un script ou un outil peut assez facilement être développé dans le but de marquer
automatiquement les ensembles de données comme étant complets si une certaine quantité
(c'est-à-dire un nombre spécifié de valeurs d'éléments de données) a été rapportée. Cela
convient parfaitement à l'identification des établissements de santé pour lesquels quelques
données ont été déclarées, mais ce processus automatisé ne permet pas de déterminer si les
déclarations sont en fait complètes au sens propre du terme.

En général, lorsque les données de suivi sont utilisées pour produire des valeurs de données
agrégées, il s'agit d'une forme d'utilisation secondaire des données au-delà de ce pour quoi elles ont
été collectées à l'origine. Il est important de communiquer clairement aux utilisateurs comment les
questions de validation et de correction des données sont gérées, comment les questions telles que la
" complétude " sont traitées, et que la " source de vérité " pour les données est clairement définie.

Accès aux données et propriété

L'accès aux données de suivi et aux données agrégées dans DHIS2 est contrôlé par le partage, sur la
base de groupes d'utilisateurs. Le partage des données de suivi et des valeurs de données agrégées
générées à partir des données de suivi peut donc être différent et, dans le scénario courant où les
deux types de données sont hébergés dans des instances DHIS2 différentes, les mêmes utilisateurs
peuvent ne pas avoir accès au système du tout. Cela présente certains avantages, par exemple, les
valeurs des données agrégées peuvent être partagées plus largement que les données de suivi sans
que cela n'ait d'incidence sur la vie privée ou la sécurité. Par ailleurs, il est nécessaire de mettre en
place un partage de données approprié dans deux instances différentes, et les utilisateurs peuvent
également avoir besoin d'accéder à deux systèmes différents. (Il est possible d'utiliser OpenID
Connect pour permettre aux utilisateurs de partager leur nom d'utilisateur et leur mot de passe entre
les deux instances).

En lien avec *l'accès * aux données, la question de la propriété des données se pose, une question
également liée à la qualité et à la validation des données. Des procédures claires doivent être mises

239
Intégration des données du tracker et des données agrégées Hypothèses et étapes clés

en place pour indiquer qui est responsable et "propriétaire" à la fois du tracker et des valeurs de
données agrégées générées par le tracker. Ceci est particulièrement important dans les scénarios où
plusieurs programmes de santé sont impliqués. Par exemple, si un programme tracker des
vaccinations alimente en données un ensemble de données HMIS intégrées, agrégées, pour
lesquelles une unité HMIS distincte est responsable.

Maintenance

La méthode décrite ici exige que des capacités techniques soient disponibles, tant pour le
développement initial et la configuration d'une solution de transfert de données que pour la
maintenance continue qui peut être nécessaire, par exemple en cas de modification de l'infrastructure
du serveur DHIS2. Par ailleurs, si les métadonnées de l'instance de suivi ou de l'instance agrégée du
HMIS sont modifiées, le mapping des indicateurs de programme vers les éléments de données
agrégés pourrait nécessiter une mise à jour en conséquence.

Période de transition

Lorsque les données de suivi sont agrégées dans le but de remplacer les rapports agrégés existants
(tels que les rapports HMIS de routine), il est souvent utile de prévoir une période de maintien des
rapports parallèles, de 6 mois par exemple. Au cours de cette période, les chiffres agrégés générés
par le tracker et par les procédures manuelles existantes doivent être comparés. Il est peu probable
qu'ils soient totalement identiques, mais de telles comparaisons sont utiles parce qu'elles :

• devrait déclencher une discussion sur l'origine des divergences, par exemple en cas de
problèmes de qualité des données (dans l'une ou l'autre des sources de données).
• Renseigne sur les décisions à prendre lorsque les données du système de suivi sont aussi
complètes ou de meilleure qualité que les rapports manuels, de sorte que les rapports
parallèles puissent être interrompus.

Techniquement, cela peut être réalisé en ayant un ensemble de données "shadow" distinct avec des
éléments de données distincts dans l'instance d'agrégat, de sorte que deux ensembles parallèles de
données agrégées puissent être conservés et comparés à cet endroit. Il est également possible de
conserver une copie de l'ensemble de données agrégées dans l'instance de suivi et de l'utiliser pour
les comparaisons.

Hypothèses et étapes clés

Lorsque les données de suivi et les données agrégées sont gérées dans des instances DHIS2
distinctes, ce qui est généralement recommandé, la migration des données entre les deux instances
nécessite que les unités d'organisation soient les mêmes ou qu'elles aient au moins un ensemble
d'identifiants communs. Étant donné que les unités d'organisation sont souvent réutilisées lorsque de
nouvelles instances DHIS2 sont installées, cela peut ne pas poser de problème dans un premier
temps. Toutefois, le maintien de la synchronisation des unités d'organisation entre deux ou plusieurs
instances DHIS2 au fil du temps nécessite une gestion minutieuse, que les changements soient gérés
manuellement ou par le biais d'un processus automatisé. Les prochains guides d'implémentation
aborderont cette question plus en détail. Aux fins du présent guide, il est indispensable que les unités
d'organisation soient harmonisées et qu'elles disposent d'un ensemble commun d'identifiants dans les
deux instances. Dans les cas où les données de suivi sont migrées vers des valeurs de données
agrégées au sein des mêmes instances DHIS2, la synchronisation des unités d'organisation n'est pas
un problème.

D'un point de vue conceptuel, les étapes de la migration des agrégats de données de suivi vers des
valeurs de données agrégées sont les suivantes :

1. Établir un mapping entre les indicateurs du programme et les éléments de données

correspondants ainsi que les combinaisons d'options de catégories, en utilisant des codes.

240
Intégration des données du
Mapping des indicateurs de programme avec les éléments de données
tracker et des données
agrégées{ #mapping-program-indicators-with-aggregate-data-elements }
agrégées
2. Exporter les valeurs des indicateurs de programme sous la forme d'un ensemble de valeurs de
données agrégé
3. Importer l'ensemble de valeurs de données en tant que valeurs d'éléments de données
agrégées

Les sections suivantes expliquent (1) comment établir un mapping entre les indicateurs de programme
et les éléments de données, (2) les API du DHIS2 pertinentes pour l'importation/exportation des
valeurs de données, et (3) les aspects à prendre en compte lors de l'automatisation du processus
d'importation et d'exportation.

Mapping des indicateurs de programme avec les éléments de données agrégées{ #mapping-
program-indicators-with-aggregate-data-elements }

Pour produire des valeurs de données agrégées à partir des données de suivi, des indicateurs de
programme doivent être définis pour chaque point de données. Chacune de ces valeurs de données
correspond à un élément de données et, au besoin, à une combinaison d'options de catégorie. Un
mapping utilisant un identifiant est donc nécessaire pour spécifier quel indicateur de programme se
rapporte à quel élément de données spécifique (avec une combinaison d'options de catégorie). Bien
qu'elle ne soit pas abordée en détail ici, le mapping peut également inclure des combinaisons
d'options d'attributs.

Illustration du mapping des données de suivi en données agrégées à l'aide d'indicateurs de

programme.

Il est recommandé d'utiliser les codes comme identifiant pour ce mapping, et cela est présenté ici.

Remarque Bien que la méthode décrite ici soit basée sur le mapping des
données dans le système source (par le biais d'indicateurs de programme),
elle pourrait, dans d'autres scénarios, être réalisée dans le système cible
où les données sont importées, ou dans un logiciel intermédiaire ou une
couche d'interopérabilité entre ces deux systèmes.

241
Intégration des données du
Mapping des indicateurs de programme avec les éléments de données
tracker et des données
agrégées{ #mapping-program-indicators-with-aggregate-data-elements }
agrégées
Coder des éléments de données

Étant donné que les codes des combinaisons d'éléments de données et d'options de catégories
seront ajoutés en tant qu'attributs aux indicateurs de programme, la première étape consiste à créer
et/ou à ajouter un code aux éléments de données et aux combinaisons d'options de catégories. Cette
opération doit être effectuée dans l'instance DHIS2 dans laquelle les valeurs des données agrégées
seront sauvegardées. Si les éléments de données et les combinaisons d'options de catégorie ont déjà
des codes, ceux-ci peuvent être utilisés. Il est également possible de définir des attributs
personnalisés et de les affecter aux éléments de données à des fins de mapping, mais dans le cadre
de ce guide, nous utiliserons le code intégré de l'élément de données.

Bien que cela ne soit pas strictement nécessaire, il peut être conseillé d'ajouter les éléments de
données à un ensemble de données s'ils ne le sont pas déjà. Cet ensemble de données (ou ces
ensembles) définit le type de période des données à transférer (par exemple, hebdomadaire,
mensuel) et, lors de l'importation, les données agrégées du tracker seront validées par rapport à ce
type de période. En outre, cette affectation peut servir de base au calcul ultérieur de la complétude
des données.

Coder des indicateurs de programme{ #coding-program-indicators }

Les indicateurs de programme ont un attribut fixe utilisé spécifiquement pour l'identifiant de la
combinaison d'options de catégorie (et de la combinaison d'options d'attributs) qui est utilisé lorsque la
valeur de l'indicateur de programme est exportée sous la forme d'un ensemble de valeurs de
données.

Champs d'indicateurs de programme pour la combinaison d'options de catégorie et d'attributs

Toutefois, il n'existe par défaut aucun champ correspondant permettant de spécifier l'identifiant (ex :
code) de l'élément de données. En principe, le code de l'indicateur de programme lui-même pourrait
être utilisé, mais cela échouera dans le scénario courant où plusieurs indicateurs de programme sont
liés au même élément de données (avec différentes combinaisons d'options de catégorie). Il est donc
recommandé de créer un attribut attribué aux indicateurs de programme.

L'attribut personnalisé doit être du type Text. Il ne doit pas être obligatoire, car tous les indicateurs de
programme ne seront pas liés à des éléments de données agrégés. Il ne doit pas être unique, puisque
plusieurs indicateurs de programme peuvent pointer vers le même code d'élément de données. Enfin,
il ne doit s'appliquer qu'à l'"indicateur de programme", puisqu'il n'est pas utile ailleurs. D'autres
propriétés telles que le nom, la description et le code peuvent être définies en fonction de la
convention de dénomination des métadonnées de l'implémentation en question. La capture d'écran ci-
dessous montre comment l'attribut personnalisé inclus dans les paquets de métadonnées de l'OMS
est configuré. Si cet attribut personnalisé a déjà été importé dans l'instance DHIS2 en question, il peut
être réutilisé.

242
Intégration des données du L'API Web DHIS2 pour l'exportation et l'importation d'ensembles de valeurs
tracker et des données de données (dataValueSets){ #dhis2-web-api-for-export-and-import-of-
agrégées datavaluesets }

Exemple de définition d'un attribut personnalisé permettant de relier les indicateurs de

programme et les éléments de données agrégées.

Une fois que l'attribut personnalisé est attribué aux indicateurs de programme, il apparaît comme un
nouveau champ/attribut lors de l'ajout ou de la modification d'indicateurs de programme dans
l'application Maintenance. Chaque indicateur de programme pour lequel des données doivent être
transférées vers des éléments de données agrégés doit être créé et/ou modifié pour inclure le code de
l'élément de données correspondant et le code de la combinaison d'options de catégorie.

L'ajout des indicateurs de programme à migrer vers un groupe d'indicateurs de programme peut
s'avérer utile à la gestion d'un grand nombre d'indicateurs de programme. Par exemple, un script de
migration des données peut cibler tous les indicateurs de programme dans un groupe d'indicateurs de
programme, ce qui simplifie la configuration.

L'API Web DHIS2 pour l'exportation et l'importation d'ensembles de valeurs de données

(dataValueSets){ #dhis2-web-api-for-export-and-import-of-datavaluesets }

Une fois que le mapping entre les indicateurs de programme et les éléments de données
correspondants et les combinaisons d'options de catégorie a été effectué, les données agrégées des
indicateurs de programme peuvent être exportées en tant que dataValueSet à partir du point de

243
Intégration des données du L'API Web DHIS2 pour l'exportation et l'importation d'ensembles de valeurs
tracker et des données de données (dataValueSets){ #dhis2-web-api-for-export-and-import-of-
agrégées datavaluesets }
terminaison de l'API analytique et importées par la suite en tant que valeurs de données agrégées.
Comme indiqué dans l'introduction, nous supposons, aux fins de ce guide, que les unités
d'organisation sont identiques ou ont un identifiant commun dans l'instance DHIS2 dans laquelle les
données doivent être importées et exportées.

Exportation

Pour exporter des données à partir de l'API Web DHIS2, on utilise le point de terminaison /api/
analytics/dataValueSet, décrit plus en détail dans la [documentation du développeur] (https://
[Link]/en/develop/using-the-api/dhis-core-version-master/
[Link]#webapi_analytics_data_value_set_format). Ce point d'accès peut renvoyer des
données en représentation JSON ou XML. Il nécessite la spécification de trois paramètres :

• Données (dx) - qui sont les indicateurs de programme pour lesquels les données doivent être
exportées.
• Période (pe) - la période pour laquelle les données doivent être exportées, laquelle doit
correspondre au type de période des éléments de données agrégées vers lesquels les
données doivent migrer.
• Unité d'organisation (uo) - les unités d'organisation pour lesquelles les données doivent être
exportées.

Le format de ces paramètres est décrit en détail dans la [documentation du développeur] (https://
[Link]/en/develop/using-the-api/dhis-core-version-master/
[Link]#webapi_analytics_dimensions_and_items).

En plus de spécifier les données, la période et les unités d'organisation de la requête, il est également
nécessaire de spécifier que les attributs personnalisés contenant les codes des éléments de données
doivent être utilisés comme identifiant pour les valeurs de données dans l'ensemble de valeurs de
données exporté. Pour ce faire, le paramètre facultatif outputIdScheme (schéma de sortie) doit
pointer vers l'UID de l'attribut personnalisé. Les objets sans cet attribut (par exemple les unités
d'organisation) seront ramenés à l'utilisation des UID.

Un appel API complet peut donc se présenter comme suit :

/api/analytics/[Link]?dimension=dx:Uvn6LCg7dVU;OdiHJayrsKo&dimension=pe:LAST_MONTH
&dimension=ou:lc3eMKXaEfw&outputIdScheme=ATTRIBUTE:vudyDP7jUy5

Cette requête renverra un fichier (au format JSON dans cet exemple) contenant les valeurs des
données agrégées.

Comme indiqué dans la documentation sur le point de terminaison API /analytics/

dataValueSet(analyse/ensemble de données), lors de l'utilisation de schémas d'identification basés
sur les attributs pour l'exportation (comme dans ce guide), il y a un risque de produire des valeurs de
données dupliquées. Cela peut se produire si plusieurs indicateurs de programme se sont vu attribuer
la même combinaison d'éléments de données et de codes de combinaison d'options de catégorie. Le
paramètre de requête booléen duplicatesOnly (doublons uniquement) peut être utilisé pour
effectuer un débogage afin de ne renvoyer que les valeurs de données dupliquées, et cette
vérification est recommandée après toute modification du mapping entre les indicateurs de
programme et les éléments de données agrégées.

/api/analytics/[Link]?dimension=dx:Uvn6LCg7dVU;OdiHJayrsKo
&dimension=pe:LAST_MONTH&dimension=ou:lc3eMKXaEfw&duplicatesOnly=true

244
Intégration des données du tracker et des données Rédaction de scripts pour automatiser la migration des
agrégées données
Étant donné que l'exportation repose sur l'API analytique, seules les données incluses dans les
[tableaux analytiques] ([Link]
maintaining-the-system/[Link]#scheduling_analytics_table) sont incluses. Par exemple, si
les tableaux d'analyse sont programmés pour être mis à jour à minuit tous les jours et que le transfert
est programmé à 23:00 tous les jours, les données de la journée en cours ne seront pas incluses.

Importation

Lorsqu'un fichier contenant des valeurs de données agrégées a été exporté depuis le point de
terminaison /api/analytics/dataValueSet avec les paramètres appropriés décrits ci-dessus, il
peut être importé directement dans l'instance DHIS2 vers laquelle les données doivent migrer. A des
fins de test, le fichier de données peut être importé à l'aide de la fonction [Import/Export app] (https://
[Link]/en/use/user-guides/dhis-core-version-master/maintaining-the-system/importexport-
[Link]), ou via l'API Web DHIS2. Nous présentons ici comment utiliser l'API.

Le point de terminaison de l'API pour l'importation d'ensembles de valeurs de données est "/api/
dataValueSets" (api/ensembles de valeurs de données), décrit plus en détail dans la [documentation
destinée aux développeurs] ([Link]
[Link]#webapi_data_values). Les différents [paramètres d'importation] ([Link]
develop/using-the-api/dhis-core-version-master/[Link]#webapi_data_values_import_parameters)
sont particulièrement importants et doivent être adaptés à nos besoins, comme décrit ici :

• dataElementIdScheme (schéma de données) et categoryOptionComboIdScheme

(schéma d'options de catégorie) doivent avoir la valeur code, car nous utilisons des codes pour
mapper les valeurs des indicateurs de programme aux éléments de données agrégés et aux
combinaisons d'options de catégorie.
• orgUnitIdScheme(schéma d'unité d'organisation) doit être défini de manière appropriée pour
chaque cas particulier.
• dryRun (exécution à blanc) permet d'obtenir un résumé de l'importation sans importer les
données, ce qui peut être utile pour les tests.
• importStrategy( Stratégie d'importation) devrait dans la plupart des cas être réglé sur
CREATE_AND_UPDATE( Créer et mettre à jour), ce qui signifie que les nouvelles valeurs de
données seront importées et que les valeurs existantes seront mises à jour. Dans certains cas,
il peut être judicieux de ne mettre que CREATE (créer) ou UPDATE (mettre à jour), par exemple
si l'on décide de ne pas mettre à jour les données existantes après un certain temps, mais
d'autoriser l'ajout de nouvelles données. Ce point a été discuté plus en détail dans les
[considérations de l'implémentation] (#implementation-considerations).

Cet exemple montre comment spécifier les paramètres appropriés lors de l'importation de données à
l'aide de l'API :

/api/dataValueSets/
dataElementIdScheme=CODE&categoryOptionComboIdScheme=CODE&importStrategy=CREATE_AND_UPDATE&dryRun=false

Rédaction de scripts pour automatiser la migration des données

Un modèle de script permettant d'automatiser la migration de routine des données du tracker vers
l'agrégat, au sein d'une même instance ou entre des instances DHIS2 distinctes, sera bientôt mis à
disposition. Qu'il s'agisse d'adapter ce modèle ou de développer des outils ou des scripts
personnalisés pour effectuer la migration, certaines recommandations doivent être suivies.

• Séparer le script exécutant l'exportation et l'importation de la configuration des données à

migrer. Cela permet de modifier plus facilement la configuration sans risquer d'introduire des
erreurs dans la logique du script et facilite également la mise en place de configurations
multiples (c'est-à-dire une pour chaque programme tracker).

245
Intégration des données du Packages de données numériques DHIS2 et liens entre les données du
tracker et des données tracker et les données agrégées{ #dhis2-digital-data-packages-and-linking-
agrégées tracker-and-aggregate-data }
• Le script doit produire un journal contenant des événements et des informations clés, tels que
le moment où le script a été lancé, un résumé des résultats de l'importation (en cas de succès)
ou les détails de l'erreur (en cas d'échec).
• Un système doit être mis en place pour informer les personnes chargées de la migration des
données en cas d'erreur, par exemple par le biais d'un serveur de messagerie configuré sur le
serveur, ou en utilisant la fonctionnalité de messagerie du DHIS2 lui-même (accessible via l'API
Web).
• Étant donné que l'exportation des données repose sur le point de terminaison analytique, il peut
être utile que le script déclenche l'analyse et l'exportation une fois que ce processus est
terminé.

Packages de données numériques DHIS2 et liens entre les données du tracker et les données
agrégées{ #dhis2-digital-data-packages-and-linking-tracker-and-aggregate-data }

Les ensembles de données numériques du DHIS2 ont été développés pour favoriser la production de
rapports et d'analyses agrégés, ainsi que la saisie de données du tracker et l'analyse au niveau de
l'établissement. De plus amples informations sont disponibles sur [[Link]/who] ([Link]
who).

Des ensembles de données numériques agrégées (y compris des tableaux de bord agrégés standard)
sont disponibles pour les programmes de santé tels que la tuberculose, le VIH, le paludisme, le
RMNCAH et le suivi des maladies. Les ensembles de données agrégées comprennent:

1. Ensemble de données, éléments de données et ensembles d'options de catégorie ("cible" pour

l'envoi de données de suivi)
2. Codes de métadonnées conformes à ADX et permettant le mapping des valeurs de données du
tracker vers l'agrégat "cible".

En outre, des ensembles de données de suivi sont en cours d'élaboration pour un nombre croissant
de cas d'utilisation, tels que les registres électroniques de vaccination et le suivi basé sur les cas pour
la tuberculose, le VIH et les rapports intégrés sur les maladies. Lorsque les ensembles de données de
suivi sont conçus pour saisir des données qui peuvent être agrégées et soumises à l'ensemble de
données agrégé correspondant, nous avons inclus les éléments suivants dans les ensembles de
données numériques de suivi :

1. Les indicateurs de programme configurés pour produire des valeurs de données correspondant
aux éléments de données et aux désagrégations inclus dans les données du pack de données
numériques agrégées.
2. Attribut personnalisé pour "Code de l'élément de données agrégé".
3. Attributs par indicateur de programme, alimentés par les codes des éléments de données et le
code de combinaison des options de catégorie de l'ensemble des données numériques
agrégées.

Résumé

Etapes pour faire migrer les données de suivi vers des valeurs de données agrégées :

1. Définir une liste des variables pour lesquelles les données doivent être générées et transférées.
2. S'assurer que les éléments de données agrégées auxquels les données seront associées
existent et ont un code.
3. Veiller à ce que les combinaisons d'options de catégorie attribuées à ces éléments de données
aient un code.
4. Créer un attribut personnalisé affecté aux indicateurs de programme.
5. Assurez-vous que les indicateurs de programme produisant les valeurs des données agrégées
existent, et attribuez-leur le code de la combinaison d'éléments de données et d'options de
catégorie correspondante.

246
Intégration des données du tracker et des données agrégées Problèmes connus

6. Exporter les valeurs des indicateurs de programme en tant qu'ensemble de valeurs de données
en utilisant le point de terminaison de l'API Web /api/analytics/dataValueSet(analyse/
ensemble de valeurs de données) dans l'instance DHIS2 qui héberge les données du tracker.
7. Importez l'ensemble de valeurs de données vers le point de terminaison /api/
dataValueSet(api/ensemble de valeurs de données) de l'API Web dans l'instance DHIS2 qui
contiendra les données agrégées.

Problèmes connus

• Il existe un bug dans les versions antérieures 2.33-36 qui empêche les attributs personnalisés
d'être exposés dans l'interface utilisateur (Jira 8755). Ce problème est résolu dans les
dernières versions corrigées de DHIS2.
• Il y a un bug (Jira 8868) qui fait que l'outil metadata-dependency-export (métadonnées-
dépendance-exportation) échoue lorsque des attributs personnalisés sont affectés à des
indicateurs de programme.

247
Aperçu des outils d’analyse de données Les outils d'analyse de données

Aperçu des outils d’analyse de données

Ce chapitre présente un aperçu des outils disponibles pour l'analyse des données fournis par le
DHIS2, ainsi qu'une description de l'objectif et des avantages de chacun. Si vous recherchez un guide
détaillé sur l'utilisation de chaque outil, nous vous recommandons de continuer à lire le guide de
l'utilisateur après avoir terminé ce chapitre. La liste suivante présente les différents outils :

1. **SIG:**Le SIG intégré à DHIS 2 permet de présenter et d'analyser vos données à l'aide de
cartes géographiques à thèmes. Vous pouvez y visualiser aussi bien les éléments de données
que les indicateurs ; et en supposant que vous disposiez des coordonnées de toutes vos unités
d’organisation, vous pouvez parcourir votre hiérarchie organisationnelle et faire apparaitre des
cartes pour tous les niveaux à l’aide de polygones ou de points. Toutes les informations
affichées sur les cartes sont générées par DHIS 2 ; tout ce que vous devez faire est de
procéder à l’enregistrement des coordonnées de vos unités d'organisation pour que les cartes
deviennent disponibles. Voir le chapitre spécifique qui traite du SIG pour obtenir plus de détails.

2. Les rapports d'ensemble de données

3. Les rapports de complétude de données

4. Les rapports statiques

5. Les rapports de distribution d'unité d'organisation

6. Les tableaux de rapport

7. Graphiques

8. Les tableaux croisés dynamiques Web

9. SIG

Les outils d'analyse de données

La section suivante donne une description de chaque outil.

**SIG:**Le SIG intégré à DHIS 2 permet de présenter et d'analyser vos

données à l'aide de cartes géographiques à thèmes. Vous pouvez y visualiser aussi bien les éléments
de données que les indicateurs ; et en supposant que vous disposiez des coordonnées de toutes vos
unités d’organisation, vous pouvez parcourir votre hiérarchie organisationnelle et faire apparaitre des
cartes pour tous les niveaux à l’aide de polygones ou de points. Toutes les informations affichées sur
les cartes sont générées par DHIS 2 ; tout ce que vous devez faire est de procéder à l’enregistrement
des coordonnées de vos unités d'organisation pour que les cartes deviennent disponibles. Voir le
chapitre spécifique qui traite du SIG pour obtenir plus de détails. { #standard-reports }

Les rapports standard sont des rapports dont la conception est prédéfinie. Cela signifie que les
rapports sont facilement accessibles en quelques clics et peuvent être consultés par des utilisateurs
de tous niveaux d'expérience. Le rapport peut contenir des statistiques en forme de tableaux et de
graphiques et peut être adapté à la plupart des besoins. La solution de rapport dans DHIS2 est basée
sur JasperReports et les rapports sont le plus souvent conçus avec le concepteur de rapport iReport.
Même si la conception du rapport est figée, les données peuvent être chargées dynamiquement dans
le rapport en fonction de n'importe quelle unité d'organisation au sein de la hiérarchie et avec une
variété de périodes de temps.

248
Aperçu des outils d’analyse de données Les rapports d'ensemble de données

Les rapports d'ensemble de données

Les rapports sur les ensembles de données affichent la conception des formulaires de saisie de
données sous la forme d'un rapport alimenté par des données agrégées ( à l'opposé des données de
bas niveau saisies). Ce rapport est facilement accessible à tous les types d'utilisateurs et permet un
accès rapide aux données agrégées. L'affichage des formulaires de saisie sous forme de rapports est
souvent une nécessité héritée du passé, à laquelle cet outil répond efficacement. Le rapport sur les
ensembles de données prend en charge tous types de formulaires de saisie de données, y compris
les formulaires de section et les formulaires personnalisés.

Les rapports de complétude de données

Le rapport sur la complétude des données produit des statistiques sur le degré de complétude des
formulaires de saisie. Les données statistiques peuvent être analysées par ensemble de données
individuel ou par liste d'unités d'organisation ayant un parent commun dans la hiérarchie. Il fournit une
valeur en pourcentage pour la complétude totale et pour la complétude des soumissions dans les
délais. Plusieurs définitions de la complétude peuvent servir de base aux statistiques : La première est
basée sur le nombre d'ensembles de données marqués manuellement comme étant terminés par
l'utilisateur qui saisit les données. Deuxièmement, en se basant sur le fait que tous les éléments de
données définis comme obligatoires sont en cours de remplissage pour un ensemble de données. La
troisième est basée sur le pourcentage du nombre de valeurs renseignées par rapport au nombre total
de valeurs dans un ensemble de données.

Les rapports statiques

Les rapports statiques proposent deux méthodes pour créer des liens vers des ressources existantes
dans l'interface utilisateur. Tout d'abord, il offre la possibilité d'établir un lien vers une ressource sur
Internet à travers une URL. Deuxièmement, il permet de télécharger des fichiers dans le système et
de créer un lien vers ces fichiers. Les fichiers à télécharger peuvent être tout type de document,
d'image ou de vidéo. Les enquêtes sanitaires, les documents politiques et les plans annuels sont des
exemples utiles de documents vers lesquels établir un lien. Les URL peuvent renvoyer à des sites
web pertinents tels que la page d'accueil du ministère de la santé ou des sources d'informations
relatives à la santé. En outre, ils peuvent servir d'interface avec des outils tiers d'analyse basés sur le
web en renvoyant à des ressources spécifiques. Un exemple est le renvoi à une URL de rapport fourni
par le cadre de rapport BIRT.

Les rapports de distribution d'unité d'organisation

Le rapport sur la répartition des unités d'organisation fournit des statistiques sur les installations
(unités d'organisation) de la hiérarchie en fonction de leur classification. La classification est basée sur
les groupes d'unités d'organisation et les ensembles de groupes. Par exemple, les installations
peuvent être classées par type grâce à l'affectation au groupe approprié à partir de l'ensemble de
groupes pour le type d'unité d'organisation. Le rapport de répartition indique le nombre d'installations
pour chaque classe et peut être généré pour toutes les unités d'organisation et tous les ensembles de
groupes du système.

Les tableaux de rapport

Les tableaux de rapports sont des rapports basés sur des données agrégées dans un format
tabulaire. Un tableau de rapport peut être utilisé comme rapport autonome ou comme source de
données pour une conception de rapport standard plus sophistiquée. Le format tabulaire peut être
croisé avec un nombre quelconque de dimensions apparaissant sous forme de colonnes. Il peut
contenir des données agrégées sur les indicateurs et les éléments de données, ainsi que des
données sur la complétude des ensembles de données. Il peut contenir des périodes relatives, afin de
permettre la réutilisation du rapport dans le temps. Il peut contenir des paramètres sélectionnables par
l'utilisateur pour les unités d'organisation et les périodes afin de permettre la réutilisation du rapport
pour toutes les unités d'organisation de la hiérarchie. Le tableau du rapport peut être limité aux

249
Aperçu des outils d’analyse de données Graphiques

premiers résultats et trié par ordre croissant ou décroissant. Une fois générées, les données du
tableau de rapport peuvent être téléchargées sous forme de PDF, de classeur Excel, de fichier CSV et
de rapport Jasper.

Graphiques

Le composant graphique offre une grande variété de graphiques, y compris les graphiques standard à
barres, linéaires et circulaires. Les graphiques peuvent contenir des indicateurs, des éléments de
données, des périodes et des unités d'organisation sur les axes x et y, ainsi qu'une ligne cible
horizontale fixe. Les graphiques peuvent être consultés directement ou en tant que partie intégrante
du tableau de bord, comme nous l'expliquerons plus loin.

Les tableaux croisés dynamiques Web

Le tableau croisé dynamique web offre un accès rapide aux données statistiques dans un format
tabulaire et permet de "faire pivoter" un nombre quelconque de dimensions telles que les indicateurs,
les éléments de données, les unités d'organisation et les périodes pour les faire apparaître sur les
colonnes et les lignes afin de créer des vues personnalisées. Chaque cellule du tableau peut être
visualisée sous la forme d'un diagramme à barres.

SIG

Le module SIG permet de consulter des données agrégées sur des cartes. Le module SIG peut
fournir un mapping thématique de polygones tels que les provinces et les districts et de points tels que
les installations dans des couches séparées. Les couches mentionnées peuvent être affichées
ensemble et combinées avec des superpositions personnalisées. De telles visualisations de cartes
peuvent être facilement parcourues dans l'historique, sauvegardées pour un accès facile à un stade
ultérieur et sauvegardées sur un disque sous la forme d'un fichier image. Le module SIG fournit des
ruptures de classes automatiques et fixes pour un mapping thématique, des jeux de légendes
prédéfinis et automatiques, la possibilité d'afficher des étiquettes (noms) pour les éléments
géographiques et la possibilité de mesurer la distance entre les points de la carte. Le mapping peut
être consulté pour n'importe quel indicateur ou élément de données et pour n'importe quel niveau
dans la hiérarchie de l'unité d'organisation. Il existe également une couche spéciale pour l'affichage
des établissements sur la carte où chacune est représentée par un symbole en fonction de son type.

250
Localisation du DHIS 2{ #localization-of-dhis-2 } Concepts de localisation du DHIS 2

Localisation du DHIS 2{ #localization-of-dhis-2 }

Concepts de localisation du DHIS 2

La localisation suppose l'adaptation d'une application à un lieu spécifique. Lors de l'implémentation du

DHIS 2 dans un pays donné, des ressources adéquates doivent être allouées pour traduire et localiser
l'application si nécessaire. La traduction des éléments de l'interface utilisateur, des messages, de la
présentation, des formats de date et d'heure, des devises et d'autres aspects doit être envisagée.
Outre la traduction de l'interface utilisateur elle-même, le contenu des métadonnées de la base de
données doit également être traduit.

Les traductions d'interface sont compilées dans le système lui-même, de sorte que les nouvelles
traductions ne soient accessibles qu'avec une version plus récente du DHIS 2. Les traductions de
base de données, quant à elles, sont spécifiques à votre implémentation et peuvent être ajoutées à
votre instance DHIS 2 existante.

Ces deux aspects sont gérés de façon distincte et les processus et outils sont décrits ci-dessous.

Localisation de l'interface utilisateur

Aperçu

DHIS 2 prend en charge l'internationalisation (i18n) de l'interface utilisateur grâce à l'utilisation de

chaînes de propriétés Java et de fichiers PO. Les fichiers de propriétés Java sont utilisés lorsque les
messages proviennent du serveur Java back-end, tandis que les fichiers PO sont utilisés pour les
applications front-end développées en JavaScript. Les applications Android du DHIS 2 utilisent un
format XML spécifique.

Remarque
Le traducteur ne doit pas se préoccuper des différents formats de fichiers
ressource ; la plate-forme de traduction masque ces détails et n'affiche que
les chaînes avec les caractères à traduire. Par exemple, la figure ci-
dessous montre les chaînes source et cible lors de la traduction d'une
ressource en français.

Tous les messages du DHIS 2 devraient toujours comporter une chaîne en anglais. Lorsque
l'utilisateur sélectionne une langue donnée et qu'une traduction est disponible dans cette langue, la
traduction est affichée. Toutefois, si la chaîne n'est pas disponible dans la langue souhaitée, des
règles de récupération seront appliquées. Lorsque deux traductions données, telles que le portugais
et le portugais brésilien, ont des messages communs, il n'est pas nécessaire d'effectuer une
traduction complète dans la variante linguistique. Seuls les messages différents doivent être traduits.
Les règles de récupération sont alors appliquées comme suit (en supposant que l'utilisateur ait
sélectionné le portugais brésilien :

1. Afficher le message en portugais brésilien s'il existe.

2. S'il n'existe pas dans la variante linguistique, utiliser le message en portugais, s'il existe.

251
Localisation du DHIS 2{ #localization-of-dhis-2 } Plateforme de traduction{ #translation-server }

S'i le message n'existe ni dans la langue de base ni dans la variante, choisissez la langue par
3. défaut, l'anglais.

Important
Certaines chaînes sources telles que "dd MMM yyyy 'to '" qui sont utilisées
pour le formatage date/heure dans DHIS2. Une partie de la valeur ne doit
pas être traduite car il s'agit d'un champ de formatage spécial utilisé par
Java ou JavaScript pour insérer ou formater une chaîne. Dans cet exemple,
la partie de la valeur qui peut être traduite serait "to", par exemple "a" en
espagnol. La chaîne spéciale qui ne doit pas être traduite est "dd MMM
yyyy". Si ce type de chaînes de format date sont traduites, cela peut
entraîner des erreurs dans l'application ! Important
Certaines variables spéciales (par exemple {0} ) utilisent des crochets. Cela
indique une variable qui sera remplacée par un nombre ou une autre valeur
par l'application. Vous devez placer cette notation de variable au bon
endroit et veiller à ne pas la modifier.

Plateforme de traduction{ #translation-server }

DHIS2 utilise désormais [transifex] ([Link] comme plateforme principale de

gestion des traductions. Vous pouvez accéder aux ressources du DHIS2 sur le site
[Link], ou directement sur le serveur [Link]

Comment puis-je participer aux traductions ?

S'inscrire en tant que traducteur

La première étape consiste à accéder au projet. Il existe deux façons d'y parvenir :

1. Accéder à la plateforme et créez un compte transifex, puis

◦ demander l'accès à notre organisation "HISP UiO" en tant que membre de l'équipe de
traduction "DHIS 2 Core Apps". Transifex propose quelques instructions utiles ici :
[Débuter en tant que traducteur] ([Link]

2. Envoyez un e-mail à l'équipe DHIS2 à l'adresse translate@[Link] pour demander l'accès.

Veuillez fournir :

◦ le nom, l'adresse e-mail et la langue de traduction du ou des utilisateurs auxquels vous

voulez que nous accordions l'accès, et

252
Localisation du DHIS 2{ #localization-of-dhis-2 } Comment puis-je participer aux traductions ?

◦ quelques informations sur les raisons pour lesquelles vous souhaitez contribuer aux
traductions du DHIS2

Traduire

Une fois que vous avez obtenu l'accès en tant que traducteur, vous pouvez commencer à traduire à
l'aide de l'éditeur Web transifex.

Transifex propose un guide utile ici : [Traduire en ligne avec l'éditeur Web] ([Link]
translation/translating-with-the-web-editor)

Dans la mesure du possible, les projets représentent les applications DHIS 2 à l'identique. Par
exemple, le projet APP : Data Visualizer contient les chaînes de traduction de l'application
Visualiseur de données.

Nos projets transifex pour l'interface utilisateur DHIS2 ont l'un des éléments suivants en début de
nom :

• APP: indique que le projet contient des chaînes pour une application spécifique
• APP-COMPONENT: indique que le projet est une bibliothèque de composants utilisée par les
applications.
• ANDROID: indique que le projet est une application Andriod

De plus, APP: Server-Side Resources (Ressources du serveur) contient des chaînes utilisées par
plusieurs applications, à savoir : - "Saisie de données" - "Maintenance" - "Tableaux croisés
dynamiques" - "Rapports"

Dans les projets, nous avons des ressources qui représentent des fichiers de localisation dans le code
source. Afin de prendre en charge plusieurs versions de DHIS2 avec les mêmes fichiers de
localisation, la version est associée à chaque instance du fichier. Ainsi, pour APP : Data Visualizer
(visualiseur de données), la liste des ressources se présente comme suit dans l'éditeur Web :

Par exemple, il n'y a qu'une seule ressource source pour l'application ([Link]), mais nous avons
ajouté la version 2.31 (v31) et toutes les versions suivantes jusqu'à la dernière version développée
(master). La version est affichée dans le champ "Catégorie", et est également visible en tant que
préfixe du nom de la ressource, par exemple v31--en-pot.

253
Localisation du DHIS 2{ À quel moment les nouvelles traductions seront-elles disponibles dans le
#localization-of-dhis-2 } système ?{ #when-will-new-translations-be-available-in-the-system }

Remarque
En général, nous demandons aux traducteurs de se concentrer sur la
ressource "master" ; elle contient généralement toutes les chaînes des
versions précédentes, et lorsque des traductions sont ajoutées, la plate-
forme ajoutent également les traductions correspondantes au niveau des
versions précédentes. Voir la section localisation de notre site web.

Astuce
Pour une langue et une version DHIS2 données, vous pouvez voir les
parties traduites. En plus, des liens directs vous conduisent vers toutes les
ressources concernées sur transifex, à partir de la section localisation de
notre site web.

À quel moment les nouvelles traductions seront-elles disponibles dans le système ?{ #when-will-
new-translations-be-available-in-the-system }

Nous avons un service de nuit qui extrait les nouvelles traductions de la plateforme transifex et ouvre
une demande d'extraction sur le code source.

Le service passe en revue tous les projets et toutes les langues prises en charge et effectue les
opérations suivantes :

1. Extraction des fichiers de localisation de transifex (lorsqu'au moins 20% de la ressource est
traduite)
2. Lancement d'une demande d'extraction au niveau du code source si des modifications sont
détectées pour la langue.

Les demandes d'extraction sont examinées et intégrées dans la base du code dans le cadre du
processus de développement normal.

Information
Les traductions ajoutées dans transifex seront intégrées dans la prochaine
version stable disponible et dans toutes les versions de DHIS2 prises en
charge.> Pour vous assurer de l'intégration de vos traductions dans la
prochaine version stable, contactez-nous (translate@[Link]) et
expliquez vos besoins. Nous vous dirons ce que nous pouvons faire.

Astuce
Les traductions que vous ajoutez dans transifex devraient être visibles dans
toutes les versions de démonstration de développement sur notre serveur
Play ([Link] le plus souvent pour un délai de quelques jours.

Comment ajouter une nouvelle langue ?{ #how-do-i-add-a-new-language }

Veuillez nous contacter par courriel translate@[Link], ou sur la [Communauté de pratique] (https://
[Link]/c/translation) et nous ajouterons cette langue aux projets sur transifex.

Une fois que les ressources de cette langue auront été traduites à plus de 20 %, elles commenceront
à être intégrées dans le système. Elles seront alors visibles dans les versions de démonstration de
développement et disponibles dans les versions ultérieures.

254
Localisation du DHIS 2{ #localization-of-dhis-2 } Traduction des métadonnées / de la base de données

Remarque
DHIS2 gère l'emplacement des métadonnées (base de données) sans
recourir à l'interface utilisateur (IU). Voir la section suivante.

Traduction des métadonnées / de la base de données

En plus de la traduction de l'interface utilisateur, DHIS 2 prend également en charge la localisation du

contenu des métadonnées dans la base de données. Il est possible de traduire des objets individuels
via l'application Maintenance, mais afin de mieux prendre en charge un flux de travail de traduction
standard, une application spécialisée a été développée.

De nouveaux emplacements de métadonnées peuvent être ajoutés dans Maintenance >

Emplacements.

Application de Traduction du DHIS 2{ #translations-app }

L' Application de Traduction de DHIS 2 peut être utilisée pour traduire toutes les métadonnées
(éléments de données, catégories, unités d'organisation, etc.) dans n'importe quelle langue disponible
dans la base de données.

Pour commencer, il suffit de choisir Application de Traduction dans le menu supérieur.

1. Choisissez le type d'objet que vous voulez traduire dans le menu déroulant Objet, par exemple
"Éléments de données".

2. Assurez-vous que vous avez défini la bonne langue comme Langue cible.

3. Choisissez le type d'objet que vous voulez traduire, et traduisez toutes les propriétés (Nom,
Nom abrégé, Description, etc). Ces propriétés varient d’un objet à l’autre.

4. Cliquez sur "Enregistrer" lorsque vous avez terminé la traduction de l'objet pour enregistrer vos
modifications.

Remarque
Vous pouvez rechercher un terme spécifique à l'aide de la fonction de
recherche située dans le coin supérieur droit de l'application.

255
Guide sur la documentation du DHIS 2 Présentation du système de documentation du DHIS 2

Guide sur la documentation du DHIS 2

Présentation du système de documentation du DHIS 2

Le DHIS 2 est un système de gestion de l'information basé sur le web, qui fait l'objet d'un
développement très actif, avec généralement deux versions majeures par an. Chaque version
comprend généralement quelques nouveautés et des fonctionnalités supplémentaires. Compte tenu
de la rapidité du développement, du grand nombre d'utilisateurs et de la distribution du système à
l'échelle mondiale, un système de documentation détaillé est requis.

Dans ce chapitre, nous allons décrire le système de documentation du DHIS 2 et comment vous
pouvez y contribuer.

Introduction

La documentation du DHIS 2 est rédigée au format Markdown [Commonmark] (https://

[Link]). L'un des principaux avantages du format Markdown est que le contenu et la
présentation sont totalement séparés. Commonmark est une spécification fortement définie et
hautement compatible du format Markdown. Étant donné que le format Markdown peut être
transformé en une grande variété de formats (HTML, PDF, etc.) et qu'il est basé sur du texte, il est
idéal pour la documentation du système.

Il existe une large gamme d'éditeurs de texte qui peuvent être utilisés pour la création de fichiers
Markdown. Pour Linux et Windows, ghostwriter est une bonne option ; il est gratuit et prend en charge
l'aperçu par page double et les feuilles de style personnalisées.

L'un des concepts clés à prendre en compte lors de la conception d'une documentation au format
Markdown ou dans d'autres formats de présentation neutre est que le contenu du document doit être
traité en premier lieu. La présentation du document se fera dans une étape de transformation
distincte, au cours de laquelle le texte source sera rendu dans différents formats, tels que HTML et
PDF. Le document doit donc être bien organisé et structuré, en tenant compte des balises et des
éléments de structure appropriés.

Il est conseillé de subdiviser le document en plusieurs sections à l'aide des en-têtes de section. De
cette façon, les chapitres très complexes pourront être subdivisés en éléments plus petits et plus
faciles à gérer. Ce concept est pratiquement identique à celui de Microsoft Word ou d'autres
programmes de traitement de texte. Le processus se chargera automatiquement de la numérotation
des sections lors de la conception du document.

Premiers pas avec GitHub

Le système de documentation du DHIS 2 est géré sur [GitHub] ([Link] à travers

une variété de dépôts de code source. GitHub est une plateforme qui permet à plusieurs personnes
de collaborer sur des projets de logiciels. Pour ce faire, un système de contrôle de version est
nécessaire pour gérer toutes les modifications que les utilisateurs peuvent apporter. GitHub utilise le
système de contrôle de source git. Bien que ce document ne décrive pas les fonctionnalités de git, les
utilisateurs qui souhaitent produire de la documentation devront au minimum comprendre les principes
de base du fonctionnement du système. Une orientation de base est fournie à cet effet dans la section
suivante. Le lecteur est invité à consulter le [git manual] ([Link] pour plus
d'informations.

Pour pouvoir commencer à faire des ajouts ou à apporter des modifications à la documentation, vous
devez d'abord procéder à une extraction du code source. Si vous n'avez pas encore de compte
GitHub, vous devez en créer un. Vous pouvez le faire [ici] ([Link] Une fois inscrit sur
GitHub, vous devrez demander l'accès au groupe dhis2-documenters si vous souhaitez modifier
directement le code source de la documentation. Cependant, tout le monde peut cloner la
documentation dans son propre référentiel, lui apporter des modifications et demander à ce que ces

256
Guide sur la documentation du DHIS 2 Obtenir la source du document

modifications soient intégrées au code source de la documentation via une demande de fusion (pull
request) au référentiel principal.

La structure du site de documentation est définie dans le référentiel de construction dhis2-docs-

builder. Si vous souhaitez apporter votre contribution à la structure, des modifications seront requises
; cela ne concerne généralement que l'équipe interne du DHIS2.

Conseil
La meilleure façon de trouver la source du document que vous souhaitez
modifier est de le chercher sur le site Web [Link]. Lorsque vous le
trouvez, cliquez sur l'icône "Modifier" en haut de la page.

Obtenir la source du document

Pour pouvoir modifier la documentation, vous devez télécharger la source de la documentation sur
votre ordinateur. GitHub utilise un système de contrôle de version appelé Git. Il existe différentes
méthodes pour faire fonctionner Git sur votre système, en fonction du système d'exploitation que vous
utilisez. Un bon guide détaillé sur les systèmes d'exploitation Microsoft peut être consulté [ici] (https://
[Link]/articles/getting-started-with-github-for-windows). Par ailleurs, si la ligne de commande
vous convient, vous pouvez télécharger Git à partir de cette page. Si vous utilisez Linux, vous devrez
installer Git sur votre système via votre gestionnaire de packages ou à partir du code source. Une
référence très complète sur l'utilisation de git est disponible sous plusieurs formats différents ici.

Une fois que vous avez installé Git sur votre système, vous devrez télécharger la source du
document. Suivez cette procédure :

1. Assurez-vous que Git est installé.

2. Dans les systèmes Windows, visitez l'URL du dépôt concerné et cliquez sur "Cloner dans le
bureau". Si vous utilisez la ligne de commande, tapez simplement git clone
git@[Link]:dhis2/[Link] (notez que dans cet exemple dhis2 est le
propriétaire du dépôt et dhis2-docs est le nom du dépôt)

3. Le processus de téléchargement devrait commencer et tous les fichiers source de la

documentation seront téléchargés dans le dossier que vous avez spécifié.

4. Une fois que vous avez les sources, assurez-vous de créer votre propre branche pour l'éditer.
Exécutez simplement git checkout -b mybranch où mybranch est le nom de la branche
que vous souhaitez créer.

Modifier la documentation

Lorsque vous rédigez ou modifiez la documentation, il existe quelques conventions clés spécifiques
au projet dont vous devez tenir compte. Elles sont décrites dans cette section. De plus, plusieurs
extensions Markdown sont implémentées et présentées pour des raisons pratiques dans la section
[Markdown support and extensions] (Prise en charge du Markdown et extensions)
(#markdown_support_and_extensions) plus loin dans ce document.

Utiliser les images

Les ressources images doivent être placées dans un sous-dossier en lien avec document en cours
d'édition. Par exemple, pour le chapitre content/android/[Link],
les images se trouvent dans le dossier content/android/resources/images/<rest-of-
path> et sont référencées de la manière suivante 

257
Guide sur la documentation du DHIS 2 Utiliser les images

modeler les images

Si vous souhaitez contrôler l'alignement et la taille des images, vous pouvez profiter d'une extension
Markdown que nous utilisons. Il vous permet de définir des attributs tels que la largeur, la hauteur et la
classe entre accolades à la fin de la définition de l'image. Par exemple:

{ largeur=50% }

fera de votre image 50 % de la largeur de la page (il est préférable d'utiliser des pourcentages pour
prendre en charge une variété de formulaires de sortie), tandis que

{ .largeur du centre=50% }

va également centrer l'image sur la page (en raison de la définition de la classe .center en css).

Lorsque les images sont écrites comme


C'est-à-dire qu'avec la mention entre crochets, ils sont rendus sous forme de figures avec des
mentions. Ceux-ci sont centrés par défaut, avec une mention centrée en italique.

Faire des captures d'écran

Pour les captures d'écran de l'interface Web de DHIS 2, nous vous recommandons d'utiliser le
navigateur Chrome, avec les deux extensions suivantes : 1. Window Resizer. Utilisez ceci pour régler
la résolution sur 1440x900 2. Fireshot. Utilisez ceci pour créer rapidement un instantané de la partie
visible

Fireshot peut même capturer toute la page, c'est-à-dire en la faisant défiler,

si vous le souhaitez. Il peut également capturer uniquement une zone
sélectionnée (mais la largeur maximale doit toujours être de 1440px)

Lorsque vous faites des captures d'écran avec l'application Android, la taille doit être définie sur
360x640.

Localiser les images

La localisation des images est possible si les versions d'une image spécifiques à une langue sont
stockées à côté de l'image d'origine. Le nom du fichier doit être le même que celui de la version
originale en anglais, mais doit inclure _ plus le code de la langue à la fin du nom, avant l'extension.

Par exemple, si vous voulez avoir une version française de ressources/images/

my_screenshot.png Vous pouvez simplement créer la version française et l'enregistrer sous
ressources/images/my_screenshot_fr.png

Le lien dans la documentation doit toujours renvoyer à l'image originale. Lorsque le site de la
documentation prend en charge chacune des langues, les images localisées seront identifiées et
utilisées à la place des images originales en anglais.

258
Guide sur la documentation du DHIS 2 Références de section

Le code de langue est la première partie de l'URL que vous voyez après
"[Link]/" lorsque vous consultez la version localisée de la
documentation. Au moment de la rédaction, par exemple, nous avons fr,
es_419, pt, cs et zh.

Références de section

Afin de fournir des références fixes (ancres) dans la documentation, nous pouvons définir une chaîne
de texte fixe qui sera appliquée à toutes les sections. Avec notre processeur Markdown, cela se fait
par ajout d'un identifiant de hachage entre les crochets, à la fin de la ligne comportant le titre de la
section, par exemple

## Validation { #webapi_validation }

Pour générer un résumé de validation des données, vous pouvez faire interagir ...

Définit l'identifiant de section de l'en-tête de niveau 2 Validation sur "webapi_validation", qui peut
alors être référencé comme "#webapi_validation" à partir de tout fichier html.

Remarque
Afin de permettre la création de liens par référence d'ancre à partir d'autres
documents, essayez de garder les identifiants de section uniques. Par
exemple, si "#webapi_validation" est unique dans toute la documentation,
vous pouvez y faire référence à partir de n'importe quelle autre partie de la
documentation en utilisant simplement [nom du lien]
(#webapi_validation). Si l'identifiant de la section référencée n'est
pas unique, le processeur document tentera de résoudre l'ancre la plus
proche avec ce nom. Lorsque le fichier de liaison appartient à une version
spécifique, le processeur ignorera les ancres appartenant à des versions
différentes.

Attention
Notre documentation est compilée à la fois en pages et en documents
complets. Pour cette raison, il n'est pas conseillé d'inclure des chemins
d'accès dans les références inter-documents. Veuillez utiliser des
identifiants de section uniques, comme décrit ci-dessus, afin que les liens
soient correctement définis dans les deux types de documents.

Veuillez suivre la convention des lettres minuscules et des traits de soulignement, afin de créer des
identifiants qui servent également de noms de fichiers lorsque nous procédons à un fractionnement
des fichiers comme partie intégrante du processus de génération du document.

Tableaux

En tant qu'extension du Commonmark pur, sont également pris en charge les tableaux GFM (définis
avec des canaux de communication|), tels que:

| Type de tableau | Descriptif |

|:--|:----|
|Commonmark (HTML)| Tableaux décrits en HTML pur |

259
Guide sur la documentation du DHIS 2 Bibliographie du DHIS 2

|Github Flavour Markdown (GFM) | Tableaux décrits avec des canaux de communication : plus
faciles à lire/éditer, mais limités en complexité |

qui produit une sortie comme:

Type de tableau Description

Commonmark (HTML) Tableaux décrits en HTML pur

Github Flavour Markdown (GFM) Tableaux décrits avec des canaux de

communication : plus faciles à lire/éditer, mais limités
en complexité

Les tableaux simples sont bien plus faciles à utiliser. Ils se limitent à une seule ligne de texte (c'est-à-
dire que chaque rangée doit occuper une seule ligne), mais vous pouvez, par exemple, utiliser les
tags <br> pour créer des sauts de ligne et si nécessaire, scinder les paragraphes à l'intérieur des
cellules. Vous pouvez également continuer à utiliser les tableaux HTML lorsque vous avez vraiment
besoin d'une plus grande complexité (mais vous pouvez également vous demander s'il existe une
meilleure façon de présenter les données).

Bibliographie du DHIS 2

Pour l'instant, les références bibliographiques ne sont pas prises en charge dans la version Markdown
de la documentation DHIS 2.

Gestion d'une documentation multilingue

La documentation DHIS 2 a été traduite dans plusieurs langues différentes, notamment le français,
l'espagnol et le portugais. Si vous souhaitez
traduire la documentation ou contribuer à l'une des traductions existantes, veuillez contacter l'équipe
chargée de la documentation du DHIS 2 via l'e-mail fourni à la fin de ce chapitre.

Validation de vos modifications sur GitHub

Après avoir édité votre document, vous devez valider vos modifications sur GitHub. Ouvrez une invite
de commande sur Windows ou un shell sur Linux, et accédez au dossier dans lequel vous avez placé
votre documentation. Si vous avez ajouté de nouveaux fichiers ou dossiers à votre répertoire local,
vous devrez les ajouter à l'arborescence source avec la commande git add, suivie du/des nom(s)
du/des dossier(s) ou du/des fichier(s) que vous avez ajouté. Assurez-vous d'inclure un commentaire
descriptif lors de votre validation.

git commit -m "Documentation améliorée sur les importations d'unités

d'organisation avec CSV."

Enfin, vous devez pousser les modifications vers votre référentiel avec la commande git push
origin mybranch, où "mybranch" est le nom de la branche que vous avez créée lorsque vous avez
extrait le document source ou sur laquelle vous êtes en train de travailler. Pour ce faire, vous aurez
besoin des autorisations requises pour confirmer vos modifications dans le référentiel. Une fois les
modifications confirmées, [vous pouvez faire une demande de fusion] ([Link]
docs/pulls) pour qu'elles soient fusionnées avec la branche principale (master branch). Vos
modifications seront examinées par l'équipe chargée de la documentation principale et testées pour
s'assurer de leur pertinence, ainsi que de leur qualité. Comme mentionné précédemment, vous
pouvez également ajouter vos modifications à votre propre référentiel GitHub, si vous n'avez pas
accès au référentiel principal, et faire une demande d'intégration pour que vos modifications soient
intégrées à la branche principale.

260
Guide sur la documentation du DHIS 2 Prise en charge du Markdown et extensions

Si vous avez des questions ou si vous avez du mal à vous en sortir, posez simplement une question
sur notre communauté de pratique de développement.

Prise en charge du Markdown et extensions

Cette section tente de capturer le Markdown et les extensions qui sont prises en charge dans le cadre
de la documentation du DHIS 2, et de fournir un aperçu des styles appliqués.

Titre h3

Titre h4

Titre h5

Titre h6

Corps du texte.

Règles horizontales

___

---

***

Importance{ #emphasis }

Ce texte est en gras

Ce texte est en gras

Ce texte est en italique

Ce texte est en italique

Barré

Blocs de citations

Exemples

Les blocs de citations peuvent également être insérés...

...en utilisant d'autres signes supérieurs côte à

côte...

... ou avec des espaces

entre les flèches.

Markdown

261
Guide sur la documentation du DHIS 2 Code

> Les blocs de citations peuvent également être insérés...

>> ...en utilisant d'autres signes supérieurs côte à côte...
> > > ... ou avec des espaces entre les flèches.

Code

code incorporé

Code incorporé mis en évidencevar test = 0; fait dans

`#!js var test = 0;`

Code indenté

// Certains commentaires
ligne 1 du code
ligne 2 du code
ligne 3 du code

Code de bloc "clôtures"

Texte d'exemple ici...

Mise en évidence de la syntaxe

var foo = fonction (barre) {

barre de retour++;
};

[Link](foo(5));

Longues lignes

Buffle buffle (les animaux appelés "buffle" de la ville de Buffle) [qui] Buffle buffle buffle
(que les animaux de la ville intimident) buffle Buffalo buffle (intimident ces animaux dans
cette ville).

Mise en surbrillance de lignes spécifiques

Rendu

def bubble_sort(items):
for i in range(len(items)):
for j in range(len(items) - 1 - i):
if items[j] > items[j + 1]:
items[j], items[j + 1] = items[j + 1], items[j]

Markdown

262
Guide sur la documentation du DHIS 2 Listes

``` py hl_lines="2 3"

def bubble_sort(items):
for i in range(len(items)):
for j in range(len(items) - 1 - i):
if items[j] > items[j + 1]:
items[j], items[j + 1] = items[j + 1], items[j]
```

Ajouter un titre

Rendu
bubble_sort.py

def bubble_sort(items):
for i in range(len(items)):
for j in range(len(items) - 1 - i):
if items[j] > items[j + 1]:
items[j], items[j + 1] = items[j + 1], items[j]

Markdown

``` py hl_lines="2 3" title="bubble_sort.py"

def bubble_sort(items):
for i in range(len(items)):
for j in range(len(items) - 1 - i):
if items[j] > items[j + 1]:
items[j], items[j + 1] = items[j + 1], items[j]
```

Listes

Non ordonné

• Créez une liste en commençant une ligne par +, - ou *

• Les sous-listes sont générées en indentant 2 espaces :

◦ Le changement de caractère marqueur force le début d'une nouvelle liste :

▪ Ac tristique libero volutpat at

▪ Facilisis in pretium nisl aliquet

an indented code block

▪ Nulla volutpat aliquam velit

▪ Très facile!

Ordonné

1. Lorem ipsum dolor sit amet

2. Consectetur adipiscing elit

3. Integer molestie lorem at massa

263
Guide sur la documentation du DHIS 2 Tableaux

Vous pouvez utiliser des numéros séquentiels...

4.
5. ... ou conservez tous les numéros comme au 1.

Commencer la numérotation avec un décalage ? :

1. foo
2. bar

Multi-niveaux

1. premier élément
2. encore premier niveau
1. deuxième niveau
2. encore deuxième
1. troisième niveau

a block of code at the third level

2. encore troisième niveau

3. à nouveau deuxième niveau
3. retour au premier niveau
1. deuxième
1. Oh, arrêtez !

Tableaux

Paramètre de retour Description

aoc Identifiant de combinaison d'options d'attributs

pe Identifiant de période

ou Identifiant d'unité d'organisation

autorisations Les autorisations : 'mayApprove' (peut approuver),

'mayUnapprove'(peut désapprouver), 'mayAccept'
(peut accepter), 'mayUnaccept' (peut ne pas
accepter) et 'mayReadData' (peut lire les données)
(mêmes définitions que pour obtenir le statut
d'approbation unique.)

État Un des états d'approbation des données (comme

pour obtenir un statut d'approbation unique.)

wf Identifiant du workflow d'approbation des données

Colonnes alignées à droite et centrées

Paramètre de retour Description

aoc Identifiant de combinaison d'options d'attributs

pe Identifiant de période

ou Identifiant d'unité d'organisation

264
Guide sur la documentation du DHIS 2 Liens

Paramètre de retour Description

autorisations Les autorisations : 'mayApprove' (peut approuver),

'mayUnapprove'(peut désapprouver), 'mayAccept'
(peut accepter), 'mayUnaccept' (peut ne pas
accepter) et 'mayReadData' (peut lire les données)
(mêmes définitions que pour obtenir le statut
d'approbation unique.)

État Un des états d'approbation des données (comme

pour obtenir un statut d'approbation unique.)

wf Identifiant du workflow d'approbation des données

Liens

link text

lien avec le titre

Lien converti automatiquement [Link]

Images

Les images sont affichées en taille réelle avec une largeur maximale de 100 %


265
Guide sur la documentation du DHIS 2 Youtube

L'ajout d'un titre rend automatiquement le résultat sous forme de figure. Les classes et les styles
incorporés peuvent être ajoutés entre accolades.

{ .largeur du centre=50% }

Le titre

Youtube

Les vidéos Youtube peuvent être intégrées de la même manière que les images. Mettez simplement le
lien d'intégration de la vidéo Youtube au lieu d'un fichier image

![]([Link]

Remarque
Assurez-vous d'utiliser le lien d'"intégration" youtube!

Comme avec les images, l'ajout d'un titre rendra la vidéo sous forme de figure

266
Guide sur la documentation du DHIS 2 Avertissements{ #admonitions }

![DHIS2 : Informations pour l'action]([Link]

DHIS2 : Informations pour l'action

Avertissements{ #admonitions }

Les avertissements suivants sont pris en charge, avec des styles prédéfinis, en plus des blocs de
citations généraux.

Remarque

Remarque

Remarque
Une note contient des informations supplémentaires qui doivent être prises
en compte ou une référence vers plus d'informations potentiellement utiles.

Markdown

> **Note**
>
> A note contains additional information which should be considered or a
> reference to more information which may be helpful.

Conseil

Astuce

Astuce
Une astuce peut être utile, par exemple comment effectuer une tâche
particulière plus efficacement.

Markdown

> **Tip**
>
> A tip can be a useful piece of advice, such as how to perform a
> particular task more efficiently.

Important

Important

Important
Les informations importantes ne doivent pas être ignorées. Elles indiquent
généralement des éléments nécessaires à l'application.

Markdown

267
Guide sur la documentation du DHIS 2 Avertissements{ #admonitions }

> **Important**
>
> Important information should not be ignored, and usually indicates
> something which is required by the application.

Attention

Attention

Attention
Les informations contenues dans ces sections doivent être pris en compte.
Dans le cas contraire, des résultats inattendus peuvent survenir dans
l'analyse, la performance ou les fonctionnalités.

Markdown

> **Caution**
>
> Information contained in these sections should be carefully
> considered, and if not heeded, could result in unexpected results in
> analysis, performance, or functionality.

Avertissement

Avertissement

Attention
Si les informations contenues dans ces sections ne sont pas prises en
compte, cela pourrait entraîner une perte permanente des données ou
rendre moins facile l'utilisation du système en général.

Markdown

> **Warning**
>
> Information contained in these sections, if not heeded, could result
> in permanent data loss or affect the overall usability of the system.

Travail en cours

Travail en cours

Travail en cours
Les informations contenues dans ces sections indiqueront les problèmes
ou erreurs sur lesquels nous travaillons actuellement.

Markdown

> **Work In Progress**

>

268
Guide sur la documentation du DHIS 2 Équations mathématiques

> Information contained in these sections, will indicate that these are issues or errors we are
currently working on.

Exemple

Exemple

Exemple
Une façon de porter une attention particulière aux exemples.
Les avertissements peuvent inclure des blocs de code

var foo = fonction (barre) {

barre de retour++ ;
} ;

[Link](foo(5));

Markdown

> **Example**
>
> A way to bring special attention to examples.
>
> Admonitions can include a code blocks
>
> ```js
> var foo = function (bar) {
> return bar++;
> };
>
> [Link](foo(5));
> ```

Équations mathématiques

MathJax permet d'afficher du contenu mathématique dans le navigateur en prenant en charge la

composition mathématique sous diverses formes (par exemple LaTeX, MathML, AsciiMath).

Les blocs doivent être entourés de \[ ... \] ou $$ ... $$ ou \commencer{} ... \se
terminer{} sur des lignes séparées. Les blocs incorporés doivent être entourés de $...$ ou \
(...\).

Équations
Indicateur = {\frac{BcgVaccinationsMoinsD'unAn}{PopulationCibleMoinsD'unAn}} \times 100
3<4
\begin{align} p(v_i=1|\mathbf{h}) & = \sigma\left(\sum_j w_{ij}h_j + b_i\right) \\ p(h_j=1|\mathbf{v}) & =
\sigma\left(\sum_i w_{ij}v_i + c_j\right) \end{align}

L'équation d'onde pour u est

\begin{équation} \frac{\partial^2u}{\partial t^2} = c2\nabla2u \end{équation}

où \nabla^2 est le laplacien spatial et c est constant.

Cette équation p(x|y) = \frac{p(y|x)p(x)}{p(y)} est inline.

269
Guide sur la documentation du DHIS 2 Remplacements typographiques

L'homomorphisme f est injectif si et seulement si son noyau n'est que l' ensemble singleton e_G, car
sinon \existe a,b\in G avec a\neq b tel que f(a)=f(b).

Markdown

\[
Indicator = {\frac{BcgVaccinationsUnder1Year}{TargetPopulationUnder1Year}} \times 100
\]

\[3 < 4\]

\begin{align}
p(v_i=1|\mathbf{h}) & = \sigma\left(\sum_j w_{ij}h_j + b_i\right) \\
p(h_j=1|\mathbf{v}) & = \sigma\left(\sum_i w_{ij}v_i + c_j\right)
\end{align}

The wave equation for \( u \) is

\begin{equation}
\frac{\partial^2u}{\partial t^2} = c^2\nabla^2u
\end{equation}

where \( \nabla^2 \) is the spatial Laplacian and \( c \) is constant.

This equation $p(x|y) = \frac{p(y|x)p(x)}{p(y)}$ is inline.

The homomorphism $f$ is injective if and only if its kernel is only the
singleton set $e_G$, because otherwise $\exists a,b\in G$ with $a\neq b$ such that $f(a)=f(b)$.

Remplacements typographiques

Markdown Résultat

(tm) ™

(c) (c)

(r) ®

c/o ℅

+/- ±

--> →

<-- ←

<--> ↔

=/= ≠

1/4, etc. ¼, etc.

1er 2ème etc. 1er 2ème etc

Indice inférieur / Indice supérieur

- 19^th^
- H~2~O

• 19th
• H2 O

270
Guide sur la documentation du DHIS 2 Notes de bas de page

++Texte inséré++

Texte marqué

Notes de bas de page

Lien de la note de bas de page 1[^premier].

Lien de la note de bas de page 2[^deuxième].

Définition de la note de bas de page inline ^ [Texte de la note de bas de page inline].

Référence de note de bas de page dupliquée[^deuxième].

Listes des définitions

Terme 1
Définition 1 avec une continuation paresseuse.
Terme 2 avec balisage inline
Définition 2

{ quelques codes font partie de la définition 2 }

Troisième paragraphe de la définition 2.

Keys

Keys une extension qui facilite la saisie et le design des touches du clavier. D'un point de vue
syntaxique, les touches sont constituées autour du symbole +. Une touche ou une combinaison de
touches est entourée de ++, chaque touche étant séparée des autres par un +.

Exemple
Sortie
++ctrl+alt+suppr++.
Markdown
++ctrl+alt+suppr++

Le rendu de clé suivant est pris en charge.

Modificateur
Nom Affichage Pseudonymes

alt Alt

left-alt Left Alt lalt

right-alt Right Alt ralt

alt-graph AltGr altgr

command Cmd cmd

left-command Left Command lcommand, lcmd, left-cmd

right-command Right Command rcommand, rcmd, right-cmd

control Ctrl ctrl

left-control Left Ctrl lcontrol, lctrl, left-ctrl

right-control Right Ctrl rcontrol, rctrl, right-ctrl

271
Guide sur la documentation du DHIS 2 Keys

Nom Affichage Pseudonymes

function Fn fn

meta Meta

left-meta Left Meta lmeta

right-meta Right Meta rmeta

option Option opt

left-option Left Option loption, lopt, left-opt

right-option Right Option roption, ropt, right-opt

shift Shift

left-shift Left Shift lshift

right-shift Right Shift rshift

super Super

left-super Left Super lsuper

right-super Right Super rsuper

windows Win win

left-windows Left Win lwindows, left-win, lwin

right-windows Right Win rwindows, right-win, rwin

Fonction
Nom Affichage Pseudonymes

f1 F1

f2 F2

f3 F3

f4 F4

f5 F5

f6 F6

f7 F7

f8 F8

f9 F9

f10 F10

f11 F11

f12 F12

f13 F13

f14 F14

f15 F15

f16 F16

f17 F17

f18 F18

f19 F19

f20 F20

f21 F21

f22 F22

272
Guide sur la documentation du DHIS 2 Keys

Nom Affichage Pseudonymes

f23 F23

f24 F24

Alphanumérique
Nom Affichage Pseudonymes

0 0

1 1

2 2

3 3

4 4

5 5

6 6

7 7

8 8

9 9

a A

b B

c C

d D

e E

f F

g G

h H

i I

j J

k K

l L

m M

n N

o O

p P

q Q

r R

s S

t T

u U

v V

w W

x X

y Y

z Z

273
Guide sur la documentation du DHIS 2 Keys

Nom Affichage Pseudonymes

espace ++espace++ spc

Ponctuation

Nom | Affichage | Pseudonymes

--------------- | ----------------- | ------- barre oblique inverse | ++barre oblique inverse++ | bar | | |
barre verticale accolade gauche | ++accolade-gauche++ | accolade ouverte accolade
droite | ++accolade droite++ | fermer la parenthèse parenthèse-gauche | ++parenthèse-
gauche++ | parenthèse ouverte parenthèse droite | ++parenthèse-droite++ | fermer la
parenthèse deux points | ++deux-points++ | virgule | ++virgule++ | guillemets doubles |
++guillemet double++ | dblquote égal | ++égal++ | exclamation | ! | exclamation grave | ` |
accent grave plus grand | ++plus grand++ | supérieur à, gt moins | ++moins++ |
inférieur à, lt moins | ++moins++ | trait d'union période | ++période++ | plus | + |
question | ? | point d'interrogation point-virgule | ++point-virgule++ | guillemet
simple | ++apostrophe++ | barre oblique | ++barre oblique++ | tilde | ~ | tiret bas | ++tiret
bas++ |

Navigation
Name Affichage Pseudonymes

flèche vers le haut ++flèche vers le haut++ vers le haut

flèche vers le bas ++flèche vers le bas++ vers le bas

flèche-gauche ++flèche-gauche++ gauche

flèche-droite ++flèche-droite++ droit

page précédente ++page précédente++ prior, page précédente, pg-

up

page suivante ++page suivante++ suivant, page-dn, pg-dn

accueil ++accueil++

fin ++fin++

onglet ++onglet++ tabulateur

Édition
Nom Affichage Pseudonymes

retour arrière ++retour arrière++ retour, bksp

supprimer ++supprimer++ sup

insérer ++insérer++ ins

Action
Nom Affichage Pseudonymes

pause Pause annuler

verrouillage des ++verrouillage des majuscules++ capitale, cplk

majuscules

clair Clear clr

éjecter ++éjecter++

entrer Enter retourner

échapper ++échapper++ éch

274
Guide sur la documentation du DHIS 2 Keys

Nom Affichage Pseudonymes

aide ++aide++

écran d'impression ++écran d'impression++ prtsc

arrêt-défilement Scroll Lock faire défiler

Clavier numérique
Nom Affichage Pseudonymes

num0 Num 0

num1 Num 1

num2 Num 2

num3 Num 3

num4 Num 4

num5 Num 5

num6 Num 6

num7 Num 7

num8 Num 8

num9 Num 9

num-astérisque ++num-astérisque++ multiplier

num-clair ++num-clair++

num-supprimer ++num-supprimer++ num-sup

num-égal ++num-égal++

verrouillage numérique ++verr-num++ numlk, numlock

num-moins ++num-moins++ soustraire

num-plus Num + ajouter

num-séparateur ++num-séparateur++ décimal, séparateur

num-slash Num / diviser

num-entrer ++num-entrer++

Clés supplémentaires
Nom Affichage Pseudonymes

backtab Back Tab bktab

navigateur-retour ++navigateur-retour++

favoris du navigateur ++ favoris du navigateur ++ favoris

navigateur-avant ++navigateur-avant++ avant

accueil-navigateur ++accueil-navigateur++

rafraîchissement- ++ rafraîchissement-navigateur + rafraîchir

navigateur +

recherche-navigateur ++recherche-navigateur++ rechercher

navigateur-arrêt ++navigateur-arrêt++

copier ++copier++

menu contextuel ++menu contextuel++ applications, menu

empreinte digitale ++empreinte digitale++ empreinte digitale

275
Guide sur la documentation du DHIS 2 Émojis

Nom Affichage Pseudonymes

mail Mail lancer-mail

média ++média++ lancer-media

media-piste-suivante ++media-piste-suivante++ piste suivante

média-pause Pause mettre en pause

lecture-media ++lecture-media++ lecture

media-lecture-pause ++media-lecture-pause++ lecture-pause

media-piste-précédente ++media-piste-précédente++ piste-précédente

media-arrêt ++media-arrêt++ arrêter

pouvoir ++pouvoir++

imprimer ++imprimer++

réinitialiser ++réinitialiser++

sélectionner ++sélectionner++

veille ++veille++

volume-bas ++volume-bas++ vol-bas

volume-muet ++volume-muet++ muet

augmenter-volume ++augmenter-volume++ augmenter-volume

zoomer ++zoomer++

Souris
Nom Affichage Pseudonymes

bouton gauche ++bouton-gauche++ lbouton

bouton du milieu ++bouton du milieu++ mbouton

bouton droit ++bouton droit++ rbouton

bouton-x1 ++x-bouton1++ xbouton1

x-bouton2 ++x-bouton2++ xbouton2

Émojis

Plusieurs ensembles d'emojis sont pris en charge en saisissant le nom de l'emoji entouré de deux-
points: par exemple, :smile:. Vous trouverez ci-dessous la liste des ensembles communs ; ceux qui
n'ont pas de résultats ne sont actuellement pas pris en charge.

Personnes

:bowtie:
:neckbeard:

:person_with_pouting_face: :person_frowning:
:person_with_blond_hair:

Nature

276
Guide sur la documentation du DHIS 2 Mermaid

:octocat: :squirrel:

Objets

Lieux

Symboles

:black_square: :white_square: :shipit:

Mermaid

Les diagrammes [Link] sont désormais pris en charge.

Organigrammes

Flowcharts sont des diagrammes qui représentent les charges de travail ou processus. Les étapes
sont rendues sous forme de nœuds de différents types et sont reliées par des arêtes, décrivant l'ordre
approprié des étapes:

Exemple

graphique LR
A[Début] --> B{Erreur ?} ;
B -->|Oui| C[Hum...] ;
C --> D[Débogage] ;
D --> B ;
B ---->|Non| E[Yay !] ;

Markdown

277
Guide sur la documentation du DHIS 2 Mermaid

``` mermaid
graph LR
A[Start] --> B{Error?};
B -->|Yes| C[Hmm...];
C --> D[Debug];
D --> B;
B ---->|No| E[Yay!];
```

Diagrammes de séquence

Les Diagrammes de séquence décrivent un scénario spécifique comme les interactions séquentielles
entre plusieurs objets ou acteurs, y compris les messages échangés entre ces acteurs:

Exemple

%%{init: {'mirrorActors': false } }%%

sequenceDiagram

autonumber
participant G as package URL<br><br>(github/S3)
participant M as metatran
participant T as transifex
participant F as filesystem<br><br>(path)
G->>M: package file
T->>M: pull latest translation strings
opt
note over M: swap base language
end

opt
note over M: include/exclude languages
end
M->>+F: New package file

Markdown

``` mermaid
%%{init: {'mirrorActors': false } }%%

sequenceDiagram

autonumber
participant G as package URL<br><br>(github/S3)
participant M as metatran
participant T as transifex
participant F as filesystem<br><br>(path)
G->>M: package file
T->>M: pull latest translation strings
opt
note over M: swap base language
end

opt
note over M: include/exclude languages
end

278
Guide sur la documentation du DHIS 2 Mermaid

M->>+F: New package file

```

graphiques git

Les Graphiques Git fournissent une représentation graphique des commits git et des actions git sur
diverses branches.

Exemple

%%{init: { 'logLevel': 'debug', 'theme': 'dark', 'gitGraph': {

'showBranches': true,
'showCommitLabel':false,
'mainBranchName': 'master'}}
}%%

gitGraph
commit
commit
branch "2.39"
checkout "2.39"
commit
checkout master
commit
checkout "2.39"
branch "patch/2.39.0"
checkout "patch/2.39.0"
commit
checkout master
commit
checkout "2.39"
commit
checkout "patch/2.39.0"
commit tag: "2.39.0"
checkout master
commit
checkout "2.39"
commit
commit
checkout "master"
commit
checkout "2.39"
branch "patch/2.39.1"
checkout "patch/2.39.1"
commit
commit tag: "2.39.1"
checkout "2.39"
commit
checkout "patch/2.39.1"
branch "hotfix [Link]"
commit tag: "[Link]"

Markdown

``` mermaid
%%{init: { 'logLevel': 'debug', 'theme': 'dark', 'gitGraph': {
'showBranches': true,
'showCommitLabel':false,
'mainBranchName': 'master'}}

279
Guide sur la documentation du DHIS 2 Mermaid

}%%

gitGraph
commit
commit
branch "2.39"
checkout "2.39"
commit
checkout master
commit
checkout "2.39"
branch "patch/2.39.0"
checkout "patch/2.39.0"
commit
checkout master
commit
checkout "2.39"
commit
checkout "patch/2.39.0"
commit tag: "2.39.0"
checkout master
commit
checkout "2.39"
commit
commit
checkout "master"
commit
checkout "2.39"
branch "patch/2.39.1"
checkout "patch/2.39.1"
commit
commit tag: "2.39.1"
checkout "2.39"
commit
checkout "patch/2.39.1"
branch "hotfix [Link]"
commit tag: "[Link]"
```

280
Soumission rapide des corrections de documents Correction de fautes d'orthographe

Soumission rapide des corrections de documents

Pour les petites modifications apportées à un document, il est en fait très facile pour n'importe qui de
soumettre des modifications sans passer par le processus complet de création d'un problème JIRA
contre DHIS 2. Cela peut être fait directement dans GitHub et ne nécessite aucune connaissance de
git. Tout ce dont vous avez besoin, c'est d'un compte GitHub!.

Cette section est conçue comme un guide pour effectuer des modifications simples.

Correction de fautes d'orthographe

Dans ce scénario, nous lisons la documentation et trouvons une faute d'orthographe (le mot manditory
devrait être mand**a**tory) :

Une erreur orthographique dans la documentation de l'application Capture

Ceci se trouve dans le chapitre "Utilisation de l'application Capture" du manuel de l'utilisateur DHIS 2.
Nous voulons résoudre ce problème, alors...

1. Nous nous connectons à GitHub : [Link]

Si vous n'avez pas de compte, suivez le lien S'inscrire sur le site GitHub. (les comptes
publics sont gratuits)

Se connecter à GitHub

2. Nous devons maintenant trouver le chapitre que nous voulons modifier dans GitHub. Il suffit
d'aller sur la page que nous voulons modifier sur le site de documentation DHIS2 et de faire
défiler la page jusqu'en haut. Sur le côté droit, au-dessus du contenu principal, se trouve une

281
Soumission rapide des corrections de documents Correction de fautes d'orthographe

icône (crayon) éditer. Pour les pages ayant plusieurs versions, nous sélectionnons celle que
nous voulons avant de l'éditer ; ici nous avons sélectionné la version master.

Page du site de la documentation

3. En cliquant sur l'icône éditer sur le site des documents, nous accédons directement au fichier
correspondant sur GitHub.

Chapitre de l'application de Saisie sur GitHub

4. A ce stade, nous pouvons choisir d'éditer le fichier (icône crayon). Un panneau d'édition
s'affiche :

Ici, nous avons trouvé et mis en évidence le mot erroné !

282
Soumission rapide des corrections de documents Correction de fautes d'orthographe

Éditer

> Don't worry about the blue warning at the top that says we don't have
write access to the file!

Nous pouvons effectuer la modification et la prévisualiser dans l'onglet Aperçu des

modifications si nous le souhaitons. en voici l'aperçu :

Aperçu

283
Soumission rapide des corrections de documents Correction de fautes d'orthographe

1. Pour terminer, nous pouvons soumettre notre modification en tant que demande de
modification (Pull Request (PR)). Nous ajoutons un titre à la modification (et une description
optionnelle) et cliquons sur Proposer une modification de fichier

Soumettre la modification

a. Nous obtenons un résumé de nos modifications et cliquons sur Create pull request
(créer une demande d'extraction):

284
Soumission rapide des corrections de documents Correction de fautes d'orthographe

Envoyer la modification

2. Tout est terminé!

Une demande d'insertion est maintenant dans le système, qui peut être facilement examinée et
acceptée par l'équipe DHIS 2.

285
Soumission rapide des corrections de documents Correction de fautes d'orthographe

Envoyer la modification

Once accepted, the change will appear in the next build of the documentation!

286
Utilisation de JIRA pour les problèmes liés à DHIS2 Inscrivez-vous à JIRA - c'est ouvert à tous!

Utilisation de JIRA pour les problèmes liés à DHIS2

Inscrivez-vous à JIRA - c'est ouvert à tous!

1. Visitez le site : [Link]

2. Créez un compte avec votre nom et votre adresse électronique.

Signaler un problème{ #report-an-issue }

Astuce
Vous ne savez pas s'il s'agit d'une fonctionnalité manquante, d'un bogue ou
d'une fonctionnalité obsolète ? Nous apprécierions que vous posiez la
question sur la page de la liste des développeurs avant de signaler un
bogue directement. Merci !

1. Cliquez sur Créer dans le menu principal.

2. Sélectionnez un Projet dans la liste.

3. Sélectionnez un Type de problème :

◦ Amélioration - si vous souhaitez nous faire part de quelque chose qui pourrait être
amélioré, par exemple des suggestions en matière de facilité à l'utilisation ou de
conception.

◦ Nouvelle fonctionnalité - si vous souhaitez suggérer une fonctionnalité.

◦ Tâche - si vous avez été invité à travailler sur une tâche DHIS2.

◦ Bug - si vous avez trouvé quelque chose qui doit être corrigé.

◦ Epic - si vous souhaitez soumettre une idée pour un nouveau champ DHIS2 comme une
application. Epic est utilisé pour les questions plus complexes que les nouvelles
fonctionnalités.

4. Cliquez sur CRÉER.

Tip
To create several issues in one go, select Create another.

5. Remplissez le formulaire de demande. Donnez-nous beaucoup de détails sur le contexte!

Incluez les journaux du serveur, les journaux de la console JavaScript, la version de DHIS2 et
le navigateur web que vous utilisez.

287
Utilisation de JIRA pour les problèmes liés à DHIS2 Recherche de problèmes

Recherche de problèmes

Cliquez sur Issues > Search for issues.(problèmes, Recherche de problèmes)

Si vous cliquez sur Avancé, vous pouvez ordonner vos critères de recherche en utilisant les champs
prédéfinis. Vous pouvez également saisir des termes de recherche dans le champ de recherche. Voir
aussi : Syntaxe de recherche pour les champs.

288
Utilisation de JIRA pour les problèmes liés à DHIS2 A propos des filtres

A propos des filtres

Vous pouvez enregistrer vos résultats de recherche sous forme de filtres pour y revenir plus
rapidement. Un filtre est très similaire à un favori. Nous avons créé des filtres pour les fonctionnalités
prévues pour les numéros de version 2.26, 2.27 et 2.28 et pour tous les bogues ouverts.

Création d'un filtre

1. Pour créer un filtre, allez sur Issues > Search for issues. (Problèmes; Recherche de
problèmes)

289
Utilisation de JIRA pour les problèmes liés à Ajoutez un filtre à votre profil{ #add-a-filter-to-your-profile
DHIS2 }
Ajoutez des filtres à votre recherche, tels que:
2.
◦ Projet - le projet principal de logiciel est DHIS 2.

◦ Type - vous pouvez filtrer par Types de Problèmes Standard tels que de Nouvelles
Fonctionnalités, Améliorations, Bogues ou Epic ou Types de problèmes liés aux Sous-
Tâches.

◦ Status - filtrer par To Do (à faire) (non commencé) et Done(fait), pour exemple.

◦ Version - cliquez sur En savoir plus > Tous les critères > Corriger la version pour
filtrer par numéro de version DHIS2.

◦ Interne- cliquez sur Plus> de fonctionnalités internes pour exclure les fonctionnalités
de bas niveau (back-end) de votre recherche.

3. Cliquez sur Enregistrer sous. Ce bouton se trouve au-dessus du volet de Recherche.

4. Saisissez un nom pour votre filtre de recherche et cliquez sur Soumettre. Votre filtre est
maintenant disponible dans Filtres favoris. Utilisez la flèche pour modifier votre filtre. Votre
filtre est également disponible sur le Tableau de bord du système.

Ajoutez un filtre à votre profil{ #add-a-filter-to-your-profile }

Pour ajouter un filtre à votre profil, cliquez sur Issues > Manage filters (Problèmes, Gérer les filtres)
et cliquez sur l'icône en forme d'étoile à côté de chaque filtre.

290
Utilisation de JIRA pour les Suppression des termes du filtre de recherche de votre recherche{
problèmes liés à DHIS2 #remove-search-filter-terms-from-your-search }

Suppression des termes du filtre de recherche de votre recherche{ #remove-search-

filter-terms-from-your-search }

Cliquez sur la croix pour supprimer les termes du filtre de recherche que vous avez précédemment
ajoutés à votre recherche.

Nous contacter

Pour partager des informations, clarifier les exigences ou discuter des détails relatifs à un problème,
utilisez la fonction Formuler des commentaires.

1. Sélectionnez le problème que vous souhaitez commenter.

2. Dans la fenêtre Détails du problème, cliquez sur ** Commentaire** et entrez votre texte.

Pour envoyer un courriel à d'autres personnes à propos de votre commentaire, il vous suffit de
saisir @Nom de l'Utilisateur dans le champ de commentaire. Un courriel sera envoyé aux
adresses électroniques des utilisateurs enregistrés dans leurs comptes JIRA.

3. Cliquez sur Ajouter.

291
Aide Page d'accueil : [Link]

Aide
La communauté DHIS2 utilise un ensemble de plateformes de collaboration et de coordination pour
l'information et la fourniture de téléchargements, de documentation, de développement, de code
source, de spécifications de fonctionnalité, de suivi des bogues. Ce chapitre les décrit plus en détail.

Page d'accueil : [Link]

La page d'accueil de DHIS2 se trouve à l'adresse [Link] La page Téléchargements

fournit des liens pour télécharger les fichiers WAR de DHIS2, l'application de Saisie mobile Android, le
code source, des exemples de bases de données, ainsi que des liens vers des ressources et des
guides supplémentaires. Veuillez noter que nous fournissons des mises à jour de maintenance pour
les trois dernières versions de DHIS2. Nous vous recommandons de consulter régulièrement la page
de téléchargement et de mettre à jour votre serveur en ligne avec un patch stable correspondant à
votre version de DHIS2. Les informations sur la version et la révision de la construction peuvent être
trouvées sous la page A propos de DHIS2 à l'intérieur de votre instance DHIS2.

Le menu de navigation fournit des descriptions claires du contenu du site, et un champ de recherche
dans l'en-tête vous permet d'effectuer facilement des recherches dans le site.

Plate-forme de collaboration : [Link]

La principale plateforme de collaboration de DHIS2 est la Communauté de pratique DHIS2. Le site est
accessible à l'adresse [Link] et est basé sur la plateforme de Discussion.

La Communauté de Pratique est utilisée pour faciliter le soutien de la communauté aux problèmes des
utilisateurs de DHIS2, ainsi que pour aider à identifier les bogues potentiels dans les versions
existantes du logiciel et les demandes de fonctionnalités pour les versions futures. C'est également un
endroit où les membres de la communauté peuvent partager des histoires, des bonnes pratiques et
des défis liés à la mise en œuvre de DHIS2, collaborer avec d'autres ur des projets et proposer leurs
services à l'ensemble de la communauté. Les utilisateurs peuvent configurer leur compte de
Communauté de Pratique en fonction de leurs préférences individuelles en matière de paramètres de
notification, et peuvent répondre aux questions existantes par e-mail.

La section Assistance de la Communauté de Pratique comprend tous les sujets qui ont été créés en
utilisant l'ancienne plateforme de collaboration du DHIS2, Launchpad, qui n'est plus active.

Les bogues identifiés au sein de la Communauté de Pratique doivent être soumis à l'équipe principale
de DHIS2 sur Jira

Signaler un problème

Si vous rencontrez un problème lors de l'utilisation du DHIS2, veuillez suivre les étapes suivantes :

• Effacez complètement le cache du navigateur web (également appelé historique ou données

de navigation) (vous pouvez utiliser l'application Nettoyage du cache du navigateur dans DHIS2
; sélectionnez toutes les options avant de procéder à la suppression).

• Vider le cache de l'application DHIS2 : Allez dans Administration des données -> Maintenance,
Vider le cache de l'application DHIS2 : Allez dans Administration des données -> Maintenance,

Si le problème persiste, rendez-vous dans la Communauté de pratique et utilisez des termes clés pour
rechercher des sujets que d'autres utilisateurs ont publiés et qui décrivent des problèmes similaires,
afin de savoir si votre problème a déjà été signalé et résolu. Si vous ne parvenez pas à trouver un fil
de discussion décrivant un problème similaire, vous devez créer un nouveau sujet dans la catégorie
Assistance. Les membres de la communauté et l'équipe DHIS2 vous répondront pour tenter de vous
aider à résoudre votre problème.

292
Aide Suivi du développement : [Link]{ #development-tracking-jiradhis2org }

Si la réponse que vous avez reçue dans la communauté de pratique indique que vous avez identifié
un bogue, vous devez publier un rapport de bogue sur DHIS2 Jira.

Suivi du développement : [Link]{ #development-tracking-jiradhis2org }

Jira est le site où l'on peut signaler des problèmes et suivre les exigences, les progrès et la feuille de
route du logiciel DHIS2. Le site DHIS2 Jira est accessible à l'adresse [Link]

Si vous trouvez un bogue dans DHIS2, vous pouvez le signaler sur Jira en vous rendant sur la page
d'accueil Jira de DHIS2, en cliquant sur créer dans le menu supérieur, en sélectionnant "bogue"
comme type de problème et en renseignant les champs requis.

Pour que les développeurs puissent vous aider, vous devez fournir autant d'informations utiles que
possible :

• Version DHIS2 : Consultez la page d'aide - > A propos de DHIS2 et indiquez la version et la
révision du logiciel.

• Navigateur web, version comprise.

• Système d'exploitation, version comprise.

• Conteneur de servlets / journal Tomcat : Indiquez toute sortie dans le journal Tomcat
(typiquement [Link]) liée à votre problème.

• Console du navigateur web : Dans le navigateur web Chrome, cliquez sur F12, puis sur
"Console", et recherchez les exceptions liées à votre problème.

• Actions menant au problème : décrivez aussi clairement que possible les mesures que vous
avez prises et qui ont mené au problème ou à cette exception.

• Description du problème : Décrivez clairement le problème, pourquoi vous pensez qu'il s'agit
d'un problème et quel est le comportement que vous attendez du système.

Votre rapport de bogue sera examiné par l'équipe de test et d'assurance qualité, qui lui attribuera un
statut. S'il est valide, son statut sera défini comme "À FAIRE" et sera visible par l'équipe de
développement ans sa planification des étapes et des versions. Il peut alors être confié à un
développeur et être corrigé. Notez que les corrections de bogues sont incorporées dans la branche
principale et dans les branches des trois dernières versions (supportées) du DHIS2 - ainsi, plus de
tests et de retours aux équipes de développeurs conduisent à une meilleure qualité de votre logiciel.

Si vous souhaitez suggérer une nouvelle fonctionnalité à mettre en œuvre dans DHIS2, vous devez
d'abord lancer une discussion sur la communauté de pratique afin d'obtenir des avis sur votre idée et
de confirmer que la fonctionnalité que vous suggérez n'existe pas déjà. Une fois ces étapes franchies,
vous pouvez soumettre une demande de fonctionnalité sur DHIS2 Jira en cliquant sur "Créer" dans le
menu supérieur et en sélectionnant "Fonctionnalité" comme type de problème. Votre demande de
fonctionnalité sera examinée par l'équipe de développement et, si elle est acceptée, un développeur
et une version de lancement lui seront attribués. Les utilisateurs du DHIS2 peuvent voter pour
apporter leur soutien aux demandes de fonctionnalités qui ont été soumises. Les demandes de
fonctionnalités existantes peuvent être consultées en utilisant la fonction "filtre" de Jira.

Code source: [Link]/dhis2

Les différentes branches du code source, y compris les branches ''master'' et ''release'', peuvent être
consultées à l'adresse [Link]

1. La note de bas de page peut avoir un balisage

293
Aide Code source: [Link]/dhis2

et plusieurs paragraphes. ↩

2. Texte de la note de bas de page. ↩

294