A propos du serveur de démonstration, du cluster D2 et de la conception de la base de données¶

Utilisation du serveur de démonstration de DHIS2¶

L'équipe DHIS2 dispose d'un serveur de démonstration à l'adresse https://play.dhis2.org/demo. C'est de loin la moyen le plus simple pour essayer DHIS2. Il suffit d'ouvrir le lien dans votre navigateur web et vous connecter nom d'utilisateur = admin et mot de passe = district.

Note

Toutes les modifications effectuées sur ce serveur sont supprimées chaque nuit, donc n'enregistrez pas de travail important sur ce serveur. Il est strictement réservé à des fins de démonstration!

Démarrage d'une instance locale de DHIS2 à l'aide de D2 Cluster¶

Exécution de D2 Cluster¶

L'utilisation de serveurs Docker pour exécuter un cluster d2 est un moyen facile de commencer à utiliser DHIS2 sur votre ordinateur local. Cette approche est appropriée pour une installation autonome et des démonstrations. Suivez simplement le guide [ici] (https://developers.dhis2.org/docs/guides/spin-up-local-instance).

Pré-requis pour l'exécution de D2 Cluster¶

Vous devez vous assurer que vous avez installé Yarn et Nodejs. Une version actuelle de Docker doit également être installée sur votre machine. Veuillez vous référer au guide pour des informations détaillées.

Télécharger et installer la version serveur¶

La dernière version stable de la version serveur peut être téléchargée à partir de ce site web. Pour plus d'informations sur son installation, veuillez vous reférer au chapitre sur l'installation dans le manuel de mise en œuvre.

Se connecter à DHIS2¶

Que vous ayez installé la version serveur ou exécuté une instance locale de DHIS2, vous devrez utiliser un navigateur web pour vous connecter à l'application. DHIS2 devrait être compatible avec les versions récentes de navigateurs. Cependant, vous devez vous assurer que Java Script est activé.

Pour vous connecter à l'application, entrez simplement http://localhost:8080/dhis si vous utilisez le paquet DHIS2 Live, ou remplacez localhost par le nom ou l'adresse IP du serveur sur lequel la version serveur est installée.

Dès que vous avez démarré DHIS2, connecté ou déconnecté, l'écran qui s'affiche vous invite à entrer votre nom d'utilisateur et mot de passe enregistrés. Après avoir entré les informations nécessaires, cliquez sur le bouton de connexion pour vous connecter à l'application. Le nom d'utilisateur et mot de passe par défaut sont 'admin' et 'district'. Ils doivent être modifiés dès la première connexion.

Vous pouvez sélectionner la langue dans laquelle vous souhaitez utiliser DHIS2 à partir de la boîte de dialogue "Changer de langue" en bas de l'écran. Il faut toutefois noter que certaines langues ne sont pas disponibles.

Au cas où vous avez oublié votre mot de passe, vous pouvez cliquer sur le lien "Mot de passe oublié". Vous devez avoir préalablement entré votre adresse électronique sur DHIS2 et le serveur doit être correctement configuré pour envoyer des emails.

Si vous souhaitez créer votre propre compte (ce que l'administrateur du serveur permet), cliquez simplement sur "Créer un compte" et suivez les instructions.

Une fois connecté à DHIS2, reportez-vous aux sections spécifiques de ce manuel pour savoir les différentes fonctionnalités disponibles.

Se déconnecter de DHIS2¶

Cliquez simplement sur Profil puis sur "Se déconnecter" en haut à droite dans le menu de DHIS2.

Brève introduction à la conception d'une base de données DHIS2¶

DHIS2 offre un ensemble de divers outils puissant pour la collecte, la validation, le reporting et l'analyse de données, mais le contenu de la base de données, c.-à-d. ce qu'il faut collecter, par qui et sous quel format, dépendra du contexte d'utilisation. Cependant, pour utiliser DHIS2, vous devez d'abord créer des métadonnées. Les métadonnées, ou données sur les données, décrivent ce qui doit être collecté (éléments de données et catégories), là où cela doit être collecté (unités d'organisation) et à quelle fréquence il doit être collecté (périodes). Ces métadonnées doivent être créées dans la base de données DHIS2 pour qu'elles puissent être utilisées. Cela peut se faire à partir de l'interface de l'utilisateur et ne nécessite pas de programmation ni de compétences techniques approfondies, mais requiert une bonne connaissance des processus à partir desquels vous souhaitez collecter des données.

Cette section est une introduction brève et rapide à la conception d'une base de données DHIS2. Elle explique également les différentes étapes nécessaires à la préparation d'un nouveau système DHIS2 prêt à être utilisé. Les spécificités de chaque étape sont expliquées dans différents autres chapitres, et les meilleures pratiques en matière de choix de conception sont expliquées dans le manuel d'implémentation. Les étapes à suivre sont donc les suivantes :

1. Configurez une hiérarchie organisationnelle

2. Définissez les éléments de données

3. Définissez les ensembles de données ainsi que les modèles de saisie de données

4. Définissez les règles de validation

5. Définissez les indicateurs

6. Définissez les tableaux de rapports et concevez les rapports

7. Configurez le module SIG

8. Concevez des graphiques et personnalisez le tableau de bord

La hiérarchie organisationnelle¶

La hiérarchie organisationnelle définit l'organisation à l'aide de l'application DHIS2, des structures sanitaires, zones administratives et autres zones géographiques utilisées dans la collecte et l'analyse de données. Cette dimension où de données est définie comme hiérarchie ayant une unité mère (ex. Ministère de la santé) et un nombre quelconque de niveaux et de nœuds en-dessous. Chaque nœud dans cette hiérarchie est appelé unité d'organisation dans DHIS2.

La conception de cette hiérarchie détermine les unités géographiques d'analyse disponibles à l'utilisateur puisque les données sont collectées et agrégées dans cette structure. Il ne peut y avoir qu'une seule hiérarchie d'organisation à la fois, il faut donc faire attention à sa structure. Des hiérarchies supplémentaires (ex. regroupements administratifs parallèles comme les "Propriétaires d'établissements") peuvent être modélisées à l'aide de regroupements organisationnels et d'ensembles de regroupements, mais la hiérarchie organisationnelle représente le principal moyen d'agrégation de données sur la dimension géographique. Les hiérarchies organisationnelles nationales typiques dans le domaine de la santé publique ont 4-6 niveaux, mais peuvent prendre en charge n'importe quel nombre de niveaux. La hiérarchie est constituée de relations parents-enfants, ex. Un pays ou une unité MoH (la racine) peut avoir par exemple 8 unités parents (provinces), et chaque province (au niveau 2) peut avoir 10-15 arrondissements comme enfants. Normalement, les structures sanitaires sont localisées dans les niveaux les plus bas, mais elles peuvent également être placées à des niveaux plus élevés comme par exemple, les hôpitaux nationaux ou provinciaux. Les arborescences asymétriques sont donc également supportées (ex. un nœud feuille peut être placé au niveau 2 alors que la plupart des nœuds feuilles sont au niveau 5).

Il existe généralement une hiérarchie géographique définie par le système de santé. Exemple : où se situent les bureaux administratifs (ex. Ministère de la santé, province, arrondissement) ? Cependant, il existe souvent d'autres limites administratives dans le pays qui peuvent être ajoutées ou pas, selon la façon dont elles pourront influencer l'analyse des données. Lors de la conception de la hiérarchie, le nombre d'enfants de toute unité d'organisation peut indiquer l'utilité de la structure. Par exemple, avoir une ou plusieurs relations 1-1 entre deux niveaux n'est pas très utile car les valeurs seront les mêmes pour le niveau enfant et le niveau parent. D'autre part, un très grand nombre d'enfants dans le milieu de la hiérarchie (ex. 50 arrondissements dans la même province) peut nécessiter l'ajout d'un niveau supplémentaire pour augmenter l'utilité de l'analyse des données. Au niveau le plus bas, les établissements médicaux auront souvent un grand nombre d'enfants (10-60), mais pour les autres niveaux plus haut dans la hiérarchie, il est recommandé d'avoir environ 5-20 enfants. Trop peu ou trop d'enfants pourrait indiquer qu'un niveau doit être supprimé ou ajouté.

Il convient de noter qu'il est facile et pratique d'apporter ultérieurement des modifications aux niveaux supérieurs de la hiérarchie. Le seul problème reste la modification des unités organisationnelles pour lesquelles on collecte des données (les nœuds feuilles), ex. la scission ou la fusion de structures sanitaires. L'agrégation dans la hiérarchie s'effectue à tout moment en fonction de la hiérarchie actuelle et reflète toujours les modifications les plus récentes apportées à la structure organisationnelle. Reportez-vous au chapitre sur les unités d'organisation pour apprendre à créer des unités d'organisation et construire la hiérarchie.

Éléments de données¶

L'élément de données est peut-être l'élément le plus important d'une base de données DHIS2. Il représente la dimension quoi, il explique 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 de quelque chose, 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, les éléments de données ou les expressions construites à partir des éléments de données décrivent ce que sont les données. En tant que tels, les éléments de données deviennent importants pour tous les aspects du système et ils déterminent non seulement la manière dont les données sont collectées, mais surtout la manière dont 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.

Il est possible d'ajouter plus de détails à cette dimension quoi grâce à la dimension de désagrégation appelée catégories d'éléments de données. Les catégories les plus courantes sont l'âge et le genre, mais l'utilisateur peut ajouter n'importe quelle catégorie et la lier à des éléments de données spécifiques. La combinaison du nom d'un élément de données et de la catégorie qui lui est attribuée définit la plus petite unité de collecte et d'analyse disponible dans le système et décrit donc les données brutes de la base de données. Il est possible de procéder à des agrégations en effectuant un zoom arrière sur cette dimension, mais il n'est pas possible d'aller plus loin, de sorte que la conception des éléments de données et des catégories définit le détail de l'analyse dont dispose le système (sur la dimension quoi). Les modifications apportées aux éléments de données et aux catégories à un stade ultérieur du processus peuvent s'avérer compliquées car elles changeront la signification des valeurs de données déjà saisies dans la base de données (s'il y en a). Cette étape est donc l'une des plus décisives et des plus prudentes du processus de conception de la base de données.

L'une des meilleures méthodes de conception d'éléments de données consiste à les considérer comme une unité d'analyse de données et non seulement comme un champ dans le formulaire de collecte de données. Chaque élément de données vit indépendamment dans la base de données, complètement détaché du modèle de collecte. Les rapports et autres résultats sont basés sur des éléments de données et des expressions/formules composées d'éléments de données et non sur les modèles de collecte de données. Les besoins en analyse de données devraient donc guider le processus, et non les modèles de collecte de données. Une règle simple est que le nom de l'élément de données doit être autonome et pouvoir décrire la valeur de données même en dehors du contexte de son modèle de collecte. Par exemple, un nom d'élément de données tel que "références totales" parait logique lorsque vous le regardez soit sous l'angle de modèle "RCH" ou de modèle "OPD" , mais le nom tout seul ne décrit pas uniquement les phénomènes (qui sont ces référés ?), et devrait plutôt être appelé "Références totale de Maternité" ou "Références totales de OPD". Deux éléments de données différents avec des significations différentes, bien que le champ du modèle de saisie indique uniquement "Références totales" puisque l'utilisateur du modèle saura toujours d'où viennent ces références. Dans une base de données ou un référentiel d'éléments de données, ce contexte n'est plus valide et les noms des éléments de données deviennent donc importants dans la description des données.

Les propriétés communes des éléments de données peuvent être modélisées à partir de ce qu'on appelle des groupes d'éléments de données. Ces groupes sont complètement flexibles car leurs noms et la composition de leurs membres sont définis par l'utilisateur. Les groupes sont utiles non seulement pour parcourir et présenter des données connexes, mais il peuvent également être utilisés pour agréger des éléments de données. Les groupes sont faiblement couplés de façon lâche aux éléments de données et ne sont pas directement liés aux valeurs de données, ce qui signifie qu'ils peuvent être modifiés et ajoutés à tout moment sans interférer avec les données brutes.

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.

Un ensemble de données a un type de période, qui contrôle la fréquence de collecte des données, qui 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 nom court et un code.

Pour utiliser un ensemble de données dans la collecte des données pour le compte d'une unité d'organisation spécifique, cette dernière doit être affectée à l'ensemble de données. Ce mécanisme détermine quelles unités d'organisation peuvent utiliser quels ensemble de données et défini simultanément les valeurs cibles pour la complétude des données (exemple : combien de structures sanitaires sont censées soumettre des 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.

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

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 ( il devrait apparaître automatiquement lorsque des sections sont disponibles pour l'ensemble de données sélectionné). Vous pouvez basculer entre le formulaire par défaut et le formulaire à section dans dans le coin supérieur droit de l'écran de saisie. La plupart des formulaires de saisie de données tabulaires doivent être possibles avec des modèles à section, et plus vous utilisez les formulaires à section (ou formulaires par défaut) plus cela devient facile. Au cas où ces deux types de formulaires ne répondent pas à vos exigences, la troisième option est le formulaire de saisie de données personnalisé, plus flexible même s'il prend beaucoup plus de temps.

Formulaires personnalisés¶

Lorsque le formulaire que vous souhaitez concevoir est trop compliqué pour les formulaires par défaut ou à section, votre dernière option reste l'utilisation d'un formulaire personnalisé. Cela prend plus de temps, mais vous donne une flexibilité totale en termes de conception. DHIS2 dispose d'un éditeur HTML intégré (FcK Editor) pour le concepteur de formuaire qui permet de concevoir le formulaire dans l'IU (interface utilisateur) ou de coller directement votre code HTML à l'aide de la fenêtre Source dans l'éditeur. Dans le formulaire personnalisé, vous pouvez insérer un texte statique ou des champs de données (liés à des éléments de données + la catégorie) à n'importe quelle position sur le formulaire et vous êtes totalement libre de concevoir la mise en page du formulaire. Une fois qu'un formulaire personalisé a été ajouté à un ensemble de données, il sera disponible dans la saisie de données et pourra être utilisé automatiquement. Vous pouvez revenir aux formulaires par défaut ou à section (s'il en existe) dans le coin supérieur droit de l'écran de saisie.

Règles de validation¶

Une fois que vous avez configuré la partie du système relative à la saisie de données et commencé à collecter des données, il est donc temps de définir des règles de contrôle de la qualité des données permettant d'améliorer la qualité des données collectées. Vous pouvez alors ajouter autant de règles de validation que vous voulez. Celles-ci sont composées d'expressions de gauche et de droite qui, elles aussi, sont composées d'éléments de données, avec un opérateur entre les deux côtés. Les règles typiques consistent à comparer les totaux partiels aux totaux de quelque chose. Si vous avez par exemple deux éléments de données "Tests de dépistage du VIH" et "Résultat positif du test de dépistage", vous savez alors que dans le même formulaire (pour la même période et la même unité d'organisation), le nombre total de tests doit toujours être supérieur ou égal au nombre de tests positifs. Ces règles doivent être des règles absolues, ce qui signifie qu'elles sont mathématiquement correctes et non pas simplement des hypothèses ou sont "la plupart du temps correctes". Les règles peuvent être exécutées lors de la saisie de données, après le remplissage de chaque formulaire, ou dans un processus plus complexe dans plusieurs formulaires à la fois. Exemple : pour toutes les structures sanitaires du mois précédent, les résultats des tests listeront toutes les violations et les valeurs détaillées pour chaque côté de l'expression où la violation s'est produite pour faciliter le retour à la saisie des données et corriger les valeurs.

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

Les indicateurs peuvent être ajoutés, modifiés et supprimés à tout moment sans interférer avec les valeurs de données contenues dans la base de donné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¶

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.