Aller au contenu
For the complete DHIS2 documentation index, see llms.txt.

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

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

Cette approche permet d'effectuer des analyses plus facilement, lorsque la définition exacte de la combinaison des éléments de données n'est pas connue ou lorsque sa définition sous la forme d'un indicateur peut s'avérer difficile.