For the complete DHIS2 documentation index, see llms.txt.

À propos des dimensions de donnée¶

Dimensions de donnée : Éléments de base du DHIS2¶

Une valeur de données dans DHIS2 est caractérisé par au moins trois dimensions : 1) élément de donnée, 2) unité d'organisation et 3) période. Ces dimensions constituent les éléments de base du modèle de données.

Par exemple, si vous voulez savoir le nombre d'enfants ayant été vaccinés contre la rougeole au Gerehun CHC en décembre 2014, les trois dimensions qui décrivent cette valeur sont l'élément de donnée "Doses de rougeole administrées", l'unité d'organisation "Gerehun CHC" et la période "décembre 2014". Toutes les valeurs des données ont au moins ces trois dimensions décrivant quoi, où et quand.

En plus des dimensions d'élément de donnée, d'unité d'organisation et de période, les valeurs de données peuvent également être associées à des dimensions de données supplémentaires. Une utilisation courante de cette fonctionnalité consiste à décrire des valeurs de données déclarées par plusieurs partenaires au même endroit pour le même élément de donnée et la même période. En principe, elle peut être utilisée comme une dimension "libre", pour décrire des observations multiples des mêmes phénomènes au même endroit et au même moment. Pour plus d'informations à ce sujet, voir le chapitre 34 : Dimensions supplémentaires des données.

Unité d'organisation	Élément de données	Période	Valeur
Gerehun CHC	Doses de rougeole administrées	Dec-09	22
Tugbebu CHP	Doses de rougeole administrées	Dec-09	18

Éléments de données : la dimension quoi¶

Catégories d'éléments de données¶

L'élément de donnée mentionné ci-dessus, "Doses de rougeole administrées", peut être subdivisé en plusieurs catégories d'éléments de donnée. Chaque administrateur du système DHIS2 est libre de définir les dimensions des catégories d'éléments de donnée pour les éléments de données. Il existe cependant certaines bonnes pratiques qui devraient généralement être suivies.

Lorsque vous prenez l'exemple de la vaccination contre la rougeole, si vous voulez savoir si ces vaccins ont été administrés dans l'établissement (fixe) ou dans la communauté dans le cadre des services de proximité, vous pouvez ajouter une dimension appelée par exemple "Lieu de service" avec les deux options possibles "Fixe" et "De proximité". Ensuite, toutes les données collectées sur la vaccination contre la rougeole devraient être ventilées selon ces options. En outre, vous pourriez être intéressé de savoir combien de ces enfants étaient âgés de moins d'un an ou de plus d'un an. Si tel est le cas, vous pouvez alors ajouter une dimension Âge à l'élément de donnée avec les deux options possibles "\<1 y" and ">1 y". Cela implique qu'l faut préciser davantage le processus de collecte des données. Vous pouvez également appliquer les deux catégories "Lieu de service" et "Âge" et les combiner en une combinaison de catégories d'éléments de données, par exemple appelée "Désagrégation du PEV". Vous pourrez alors examiner quatre valeurs différentes plus détaillées au lieu d'une seule comme dans l'exemple ci-dessus pour l'élément de donnée "Doses de vaccin anti-rougeoleux administrées" : 1) "Fixe et \<1 y, 2) Fixe et >1 y, 3) De proximité et \<1 y, et 4) De proximité et >1 y. Cela rend plus complexe la collecte des données par les établissements de santé, mais ouvre en même temps de nouvelles possibilités d'analyse détaillée des données relatives à l'immunisation contre la rougeole.

Tableau : Exemple de stockage détaillé des valeurs de données lors de l'utilisation des catégories d'éléments de données "Lieu de service" et "Âge" (simplifié pour une meilleure lisibilité comparé au tableau de la base de données réelle)

Unité d'organisation	Élément de données	Lieu de service	Âge	Période	Valeur
Gerehun CHC	Doses de rougeole administrées	Fixe	\<1 y	Dec-09	12
Gerehun CHC	Doses de rougeole administrées	Proximité	\<1 y	Dec-09	4
Gerehun CHC	Doses de rougeole administrées	Fixe	>1 y	Dec-09	4
Gerehun CHC	Doses de rougeole administrées	Proximité	>1 y	Dec-09	2
Tugbebu CHP	Doses de rougeole administrées	Fixe	\<1 y	Dec-09	10
Tugbebu CHP	Doses de rougeole administrées	Proximité	\<1 y	Dec-09	4
Tugbebu CHP	Doses de rougeole administrées	Fixe	>1 y	Dec-09	3
Tugbebu CHP	Doses de rougeole administrées	Proximité	>1 y	Dec-09	1

Ensemble de groupes d'éléments de donnée¶

Alors que les catégories d'élément de donnée et leurs options décrites ci-dessus fournissent le niveau de détail (désagrégation) au point de collecte des données et la manière dont les valeurs des données sont stockées dans la base de données, les ensembles et groupes de groupes d'éléments de données peuvent être utilisés pour ajouter plus d'informations aux éléments de données après la collecte des données. Par exemple, si vous analysez plusieurs éléments de données en même temps dans un rapport, vous pourrez souhaiter les regrouper en fonction de certains critères. Au lieu d'examiner toutes les données saisies dans un formulaire pour la vaccination et la nutrition, vous pouvez séparer ou regrouper les éléments de données selon une dimension du programme (connue sous le nom d'ensemble de groupes d'éléments de données dans le DHIS2) où "Vaccination" (ou PEV) et "Nutrition" seraient les deux groupes.

L'élargissement du champs du rapport pour inclure des données provenant d'autres programmes ou des thèmes plus larges de données sanitaires signifierait que davantage de groupes seraient concernés par cette dimension, notamment le "Paludisme", la "Santé reproductive", les "Stocks". Pour cet exemple, vous créeriez un ensemble de groupes d'éléments de donnée appelé "Programme" (ou tout autre nom que vous jugerez approprié), et pour représenter les différents programmes dans cette dimension, vous définiriez des groupes d'éléments de donnée appelés "PEV", "Nutrition", "Paludisme", "Santé reproductive", etc. et ajouteriez tous ces groupes à l'ensemble de groupes "Programme". Pour lier ou marquer l'élément de données "Doses de vaccins antirougeoleux administrées" à une telle dimension, vous devez (dans notre exemple) l'ajouter au groupe "PEV". Les groupes auxquels vous ajoutez "Doses de vaccins antirougeoleux administrées" n'affectent pas la manière dont les établissements de santé collectent les données, mais ajoutent plus de possibilités à votre analyse des données. Ainsi, pour les dimensions de l'ensemble de groupes, il existe trois niveaux : l'ensemble de groupes (par exemple "Programme"), le groupe (par exemple "PEV") et l'élément de donnée (par exemple "Doses de vaccins antirougeoleux administrées").

Les indicateurs peuvent être regroupés en groupes d'indicateurs et plus loin en ensembles de groupes d'indicateurs (dimensions) exactement de la même manière que les éléments de données.

Unité d'organisation	Élément de données	Programme	Période	Valeur
Gerehun CHC	Doses de rougeole administrées	PEV	Dec-09	22
Gerehun CHC	Vitamine A administré	Nutrition	Dec-09	16
Tugbebu CHP	Doses de rougeole administrées	PEV	Dec-09	18
Tugbebu CHP	Vitamine A administré	Nutrition	Dec-09	12
Gerehun CHC	Nouveaux cas de paludisme	Paludisme	Dec-09	32
Tugbebu CHP	Nouveaux cas de paludisme	Paludisme	Dec-09	23

Unités d'organisation : la dimension * où*¶

Les unités d'organisation du DHIS2 doivent généralement représenter un lieu, tel qu'un centre de santé communautaire ou des hôpitaux de référence, ou une unité administrative comme le "Ministère de la santé de la Sierra Leone", le "district de Bo" ou la "chefferie de Baoma". Dans les applications de secteurs autre que la santé, il peut s'agir d'"écoles" ou de "points d'eau". Les unités sont représentées dans une hiérarchie par défaut, généralement la hiérarchie administrative par défaut d'un pays ou d'une région, et se voient donc attribuer un niveau organisationnel. Par exemple, la Sierra Leone a quatre niveaux d'unités d'organisation : national, district, chefferie et USP, et toutes les unités d'organisation sont liées à l'un de ces niveaux. Une unité d'organisation dans DHIS2 peut avoir n'importe quel nombre de niveaux. Normalement, les données sont collectées au niveau le plus bas, celui de l'établissement de santé, mais elles peuvent être collectées à n'importe quel niveau de la hiérarchie, par exemple au niveau des districts ou de l'établissement.

Lors de la conception de rapports à des niveaux supérieurs à partir des données agrégées au niveau du district ou de la province, le DHIS2 utilisera la structure hiérarchique pour agréger toutes les données des établissements de santé pour une unité donnée à n'importe quel niveau. Le niveau de l'unité d'organisation saisissant les données représente toujours le niveau de détail le plus bas pouvant être d'utilisé dans l'analyse des données, et les niveaux d'organisation définissent les niveaux d'agrégation disponibles selon une dimension géographique.

Ensembles de groupes d'unités d'Organisation et groupes¶

Alors que le niveau d'établissement est généralement le niveau géographique le plus bas pour la désagrégation dans le DHIS2, il existe des moyens de regrouper de manière flexible les unités d'organisation en un nombre quelconque de dimensions en utilisant les groupes d'unités d'organisation et la fonctionnalité d'ensemble de groupes. Par exemple, si tous les établissements sont d'un type officiel comme "Centre de santé communautaire" ou "Hôpital de district", il est alors possible de créer un ensemble de groupes d'unités d'organisation appelé "Type" et d'ajouter des groupes portant les noms des types mentionnés ci-dessus. Pour que les ensembles de groupes fonctionnent correctement dans l'analyse, chaque unité d'organisation doit être membre d'un seul groupe (obligatoire et exclusif) au sein d'un ensemble de groupes. En d'autres termes, un établissement ne doit pas être à la fois un "Centre de santé communautaire" et un "Hôpital de district".

Hériter des valeurs d'un ensemble de groupes d'unités d'organisation¶

Vous pouvez améliorer l'exhaustivité de vos données agrégées en héritant des paramètres d'une unité d'organisation "mère" dans la hiérarchie de votre unité d'organisation. Ceci est particulièrement utile si vous agrégez les données de plus de 100 unités d'organisation. Voir la documentation de l'application Maintenance pour plus de détails.

Hiérarchies alternatives des unités d'organisation - utilisation avancée des ensembles de groupes et des groupes¶

Une utilisation plus poussée des ensembles de groupes d'unités d'organisation consiste à créer des hiérarchies alternatives, par exemple en utilisant les frontières administratives d'autres ministères. En Sierra Leone, cela pourrait signifier une hiérarchie alternative de 1 : ministère de la santé, 2 : districts et 3 : conseils locaux, au lieu de la hiérarchie à quatre niveaux avec des chefferies et des USP. Par exemple, si toutes les USP sont liées à un conseil municipal spécifique, il serait possible d'examiner les données agrégées par conseil municipal au lieu de la chefferie. Il faudrait alors créer un ensemble de groupes appelé "Conseil municipal", puis créer un groupe d'unités d'organisation pour chaque conseil municipal, et enfin relier toutes les USP à leur groupe de conseils municipaux correspondant.

District	Type d'unité d'organisation	Élément de données	Période	Valeur
Bo	CHC	Doses de rougeole administrées	Dec-09	121
Bo	CHP	Doses de rougeole administrées	Dec-09	98
Bo	MCHP	Doses de rougeole administrées	Dec-09	87
Bombali	CHC	Doses de rougeole administrées	Dec-09	110
Bombali	CHP	Doses de rougeole administrées	Dec-09	67
Bombali	MCHP	Doses de rougeole administrées	Dec-09	59

Meilleure pratique en matière d'utilisation des ensembles et des groupes¶

Comme mentionné ci-dessus, toutes les unités d'organisation doivent être membres d'un seul groupe au sein d'un ensemble de groupes. Si une unité d'organisation n'est présente dans aucun groupe ou est présente dans plusieurs membres d'un groupe dans un ensemble de groupes, cela peut alors entraîner des résultats inattendus dans les modules d'analyse. DHIS2 comporte des vérifications d'intégrité pour identifier les unités d'organisation qui ne sont présentes dans aucun membre de l'ensemble de groupes d'unités d'organisation, ou qui sont présentes dans plusieurs groupes.

Période : la dimension du quand¶

La dimension Période devient ainsi un facteur important lors de l'analyse des données dans le temps, par exemple lors de l'examen de données cumulées, lors de la création de rapports agrégés trimestriels ou annuels, ou lors de l'analyse combinant des données avec différentes caractéristiques comme les données de routine mensuelles, les données annuelles de recensement/démographiques ou les données semestrielles sur le personnel.

Les types de période¶

Dans le DHIS2, les périodes sont organisées selon un ensemble de types de périodes fixes décrites ci-dessous. La liste suivante concerne le type de calendrier ISO 8601 par défaut.

Quotidien
Hebdomadaire : Le système prend en charge différents types de périodes hebdomadaires, avec le lundi, le mercredi, le jeudi, le samedi et le dimanche comme premier jour de la semaine. Vous collectez les données par le biais d'ensembles de données configurés pour utiliser le type de période hebdomadaire souhaité. Le moteur d'analyse attribue les données hebdomadaires au mois qui contient au moins quatre jours de la semaine.
Bihebdomadaire : Périodes de deux semaines commençant la première semaine de l'année.
Mensuel : Se réfère aux mois civils standard.
Bimensuel : Périodes de deux mois commençant en janvier.
Trimestriel : Trimestre norme ISO, à partir de janvier.
Semestriel : Périodes de six mois commençant en janvier
Annuel : Il s'agit d'une année civile.
Exercice financier avril : Exercice financier commençant le 1er avril et se terminant le 31 mars de l'année civile suivante
Exercice financier juillet : Exercice commençant le 1er juillet et se terminant le 31 juin de l'année civile suivante
Exercice Octobre : Période d'exercice commençant le 1er octobre et se terminant le 31 septembre de l'année civile suivante
Semestrielle Avril : Périodes de six mois commençant le 1er avril et d'une durée de six mois civils.

En règle générale, toutes les unités d'organisation doivent collecter les mêmes données en utilisant la même fréquence ou périodicité. On devra associer un formulaire de saisie à un seul type de période afin de s'assurer que les données sont toujours collectées selon la bonne et la même périodicité dans tout le pays.

Il est toutefois possible de collecter les mêmes éléments de données en utilisant différents types de période en affectant les mêmes éléments de données à plusieurs ensembles de données avec différents types de période, mais il devient alors important de s'assurer qu'aucune unité d'organisation ne collecte des données en utilisant les deux ensembles de données/types de période car cela créerait un chevauchement et une duplication des valeurs de données. S'il est configuré correctement, le service d'agrégation du DHIS2 regroupera les données, par exemple les données mensuelles d'une partie du pays avec les données trimestrielles d'une autre partie du pays, dans un rapport trimestriel national. Par souci de simplicité et pour éviter la duplication des données, il est conseillé d'utiliser le même type de période pour toutes les unités d'organisation pour les mêmes éléments de données lorsque cela est possible.

Périodes relatives¶

En plus des types de périodes fixes décrits dans la section précédente, DHIS2 prend également en charge les périodes relatives pour une utilisation dans les modules d'analyse.

Lors de la création de ressources analytiques dans DHIS2, il est possible d'utiliser la fonctionnalité des périodes relatives. Le scénario le plus simple est celui où vous souhaitez concevoir un rapport mensuel pouvant être réutilisé chaque mois sans avoir à modifier le modèle de rapport pour tenir compte des changements de période. La période relative appelée "Dernier mois" permet de le faire, et l'utilisateur peut, au moment de la production du rapport, sélectionner le mois à utiliser dans le rapport grâce à un paramètre de rapport.

Un cas d'utilisation un peu plus avancé est celui où vous souhaitez produire un rapport mensuel de synthèse pour la vaccination et où vous voulez examiner les données du mois (de déclaration) en cours ainsi qu'une valeur cumulative pour l'année jusqu'à présent. La période relative "Cette année" fournit une telle valeur cumulée par rapport au mois de déclaration sélectionné lors de l'exécution du rapport. Les autres périodes relatives sont les périodes des 3, 6 ou 12 derniers mois, qui sont des valeurs cumulées calculées à partir du mois de déclaration sélectionné. Si vous souhaitez créer un rapport avec des données agrégées par trimestre (celles qui sont passées depuis le début de l'année), vous pouvez sélectionner "Quatre derniers trimestres". D'autres périodes relatives sont décrites dans la section du manuel consacrée au tableau de déclaration.

Unité d'organisation	Élément de données	Mois du rapport	A ce jour	Nom du mois du rapport
Gerehun CHC	Doses de rougeole administrées	15	167	Oct-09
Tugbebu CHP	Doses de rougeole administrées	17	155	Oct-09

Agrégation des périodes¶

Bien que les données doivent être collectées à une fréquence donnée afin de normaliser la collecte et la gestion des données, cela ne limite pas les types de périodes peuvant être utilisées dans l'analyse des données et les rapports. Tout comme les données sont agrégées vers le haut de la hiérarchie d'organisation, elles sont également agrégées selon une hiérarchie de périodes, de sorte que vous pouvez créer des rapports trimestriels et annuels basés sur les données collectées sur une base mensuelle. Le type de période défini pour un formulaire de saisie de données (ensemble de données) définit le plus bas niveau de détail de la période possible dans un rapport.

Somme et agrégation moyenne sur la dimension de la période¶

Lors de l'agrégation des données relative à la dimension de la période, il existe deux options en ce qui concerne le mode de calcul, à savoir la somme ou la moyenne. Cette option est spécifiée pour chaque élément de données dans DHIS2 grâce à l'utilisation de l'attribut "opérateur d'agrégation" dans la boîte de dialogue Ajouter/Modifier des éléments de données.

La plupart des données collectées en routine devraient être agrégées en additionnant les mois ou les semaines, par exemple pour créer un rapport trimestriel sur l'immunisation contre la rougeole, on pourrait additionner les trois valeurs mensuelles pour les "Doses de vaccin antirougeoleux administrées".

D'autres types de données ayant une validité plus permanente dans le temps, comme le "Nombre d'employés dans l'USP" ou une estimation annuelle de la population "Population de moins d'un an", doivent être agrégées différemment. Ces valeurs sont statiques pour tous les mois tant qu'il existe des données valables. Par exemple, l'"Estimation de la population de moins de 1 an", calculée à partir des données du recensement ,est la même pour tous les mois d'une année donnée, ou le nombre d'infirmières travaillant dans un établissement donné est le même pour chaque mois de la période de 6 mois pour laquelle le nombre est déclaré.

Cette différence devient importante lors du calcul d'une valeur annuelle pour l'indicateur de la charge de morbidité des services pour un établissement. Les effectifs mensuels sont additionnés pour les 12 mois afin d'obtenir l'effectif annuel, tandis que le nombre de membres du personnel de l'USP est calculé comme étant la moyenne des deux valeurs semestrielles indiquées dans le rapport semestriel du personnel. Ainsi, dans cet exemple, l'élément de données "Effectif de l'OPD" aurait l'opérateur d'agrégation "SOMME" et l'élément de données "Nombre des effectifs" aurait l'opérateur "MOYENNE".

Le concept de période de validité est une autre caractéristique importante des éléments de données moyennes. Les valeurs moyennes des données sont des valeurs permanentes pour tout type de période dans les limites de la période pour laquelle elles sont enregistrées. Par exemple, une estimation annuelle de la population suivant l'année civile, aura la même valeur pour toute période comprise dans cette année, quel que soit le type de période. Si la population de moins de 1 an pour un établissement donné est de 250 pour l'année 2015, cela signifie que la valeur sera de 250 pour Q3-15, pour la 12e semaine de 2015 et pour toute période comprise dans l'année 2015. Cela a des implications sur la manière dont les indicateurs de couverture sont calculés, car la population annuelle complète sera utilisée comme valeur de dénominateur même lors de rapports mensuels. Si vous souhaitez examiner une valeur de couverture annuelle estimée pour un mois donné, vous aurez la possibilité de régler l'indicateur sur "Annualisé", ce qui signifie qu'une valeur de couverture mensuelle sera multipliée par un facteur de 12, une valeur trimestrielle par 4, afin de générer un total annuel effectif. La fonction d'indicateur annualisé peut donc être utilisée pour imiter l'utilisation des estimations mensuelles de la population.

Collecte de données et Analyse de données¶

Collecte et stockage des données¶

Les ensembles de données déterminent les données brutes disponibles dans le système, car ils décrivent la manière dont les données sont collectées en termes de périodicité et d'étendue spatiale. Les ensembles de données définissent les dimensions constitutives des données à saisir et à stocker dans DHIS2. Pour chaque dimension de données, nous décidons du niveau de détail auquel les données doivent être collectées, à savoir 1) l'élément de données (par exemple, le diagnostic, le vaccin ou tout autre événement) et ses catégories (par exemple, l'âge et le sexe), 2) la dimension de la période/fréquence, et 3) la dimension de l'unité d'organisation. Pour tout rapport ou analyse de données, il est impossible d'extraire des données plus détaillées que celles définies dans les ensembles de données, ainsi la conception des ensembles de données et les formulaires de saisie correspondants (les outils de collecte de données) déterminent le type d'analyse de données possible.

L'entrée n'est pas égale à la sortie¶

Il est important de comprendre que les formulaires de saisie de données ou les ensembles de données eux-mêmes ne sont pas intrinsèquement liés à la valeur des données sous- jacentes et que la signification des données n'est décrite que par l'élément de donnée (et ses catégories). Il est donc parfaitement sécurisé de modifier les ensembles de données et les formulaires sans altérer les données (tant que les éléments de données restent les mêmes). Ce couplage lâche entre les formulaires et les données rend le système DHIS2 flexible lorsqu'il s'agit de concevoir et de modifier de nouveaux formulaires et de fournir exactement le type de formulaire souhaité par les utilisateurs.

Un autre avantage de la liaison uniquement des données à des éléments de données et non à des formulaires est la flexibilité de créer des indicateurs et des règles de validation basés sur des éléments de données, et aussi de fournir tout type de rapport de sortie (dans des tableaux croisés dynamiques, des graphiques, des cartes, etc.) pouvant combiner des données individuellement ou dans plusieurs formulaires, par exemple pour corréler des données provenant de différents programmes de santé. En raison de cette flexibilité qui permet l'intégration de données provenant de différents programmes (formulaires) et sources (de routine et semi-permanentes (population, personnel, équipement)), une base de données DHIS2 est utilisée comme un dépôt de données intégré pour de nombreuses parties ou toutes les parties des données agrégées dans un SIS plus large. La figure ci-dessous illustre cette flexibilité.

Dans cet exemple, nous voyons que des éléments de données provenant de plusieurs formulaires peuvent être combinés pour créer un indicateur donné. Pour donner un exemple plus concret, on pourrait collecter "Population de moins d'un an" dans un ensemble de données annuelles par district, puis recueillir un élément de donnée comme "Enfants entièrement vaccinés" par mois au niveau de l'établissement. En annualisant la population, nous pouvons générer une approximation de la population mensuelle effective, et en combinant cela avec le total agrégé du nombre d'enfants complètement vaccinés par mois, il serait possible de générer un indicateur "Couverture vaccinale complète", consistant en le total agrégé des enfants complètement vaccinés, divisé par la population mensuelle réelle.

Plus d'exemples d'éléments de données et de formulaires¶

Le tableau ci-dessous combine les éléments de donnée des deux groupes Diagnostic (toutes les maladies) et Morbidité/Mortalité (Nouveaux cas, Suivi, Orientation, Décès) avec la catégorie d'éléments de données PHU/Communauté. Les décès sont saisis dans un formulaire séparé avec d'autres dimensions (par exemple, l'USP/Communauté) que la morbidité.

Ce tableau de sortie combine les deux catégories d'éléments de données VIH_Age et Sexe avec l'ensemble d'éléments de données Groupe TAR. Le groupe permet d'obtenir des sous-totaux pour les points d'étape et d'entrée qui résument les éléments de données dans ce groupe. Les sous-totaux pour les deux groupes d'âge et le sexe seraient d'autres colonnes que vous pourrez facilement inclure ici.

Son fonctionnement dans les tableaux croisés dynamiques¶

Lorsque l'on analyse des données dans des tableaux croisés dynamiques Excel ou tout autre outil OLAP, les dimensions deviennent extrêmement puissantes losqu'il s'agit de proposer de nombreuses vues différentes des données. Chaque catégorie ou groupe d'éléments de données devient un alors champ pivot, et les options ou groupes deviennent des valeurs dans chacun de ces champs. En fait, les catégories et les groupes sont traités exactement de la même manière dans les tableaux croisés dynamiques, tout comme les unités, les périodes et les éléments de données. Tous ces éléments deviennent des dimensions de la valeur des données peuvant être utilisées pour réorganiser, faire pivoter, filtrer les donnée et les analyser plus en détail. Nous présentons ici quelques exemples de la manière dont les dimensions des données sont utilisées dans les tableaux croisés dynamiques.

En utilisant l'exemple des données de morbidité et de mortalité, un tableau croisé dynamique peut montrer comment les dimensions peuvent être utilisées pour visualiser les données pour différents niveaux d'agrégation.

Le nombre entièrement agrégé est affiché lorsqu'aucun des champs pivot n'est disposé dans la zone du tableau, en tant que champ de colonne ou de ligne, mais qu'il est répertorié au-dessus du tableau lui-même en tant que champ de page (filtre).

Nous avons choisi ici d'examiner le total de la morbidité. Les différents éléments de données sur la morbidité ont été classés dans les _principaux_groupes Morbidité (nous reviendrons plus tard sur la Mortalité). Les champs au-dessus du tableau lui-même sont tous réglés sur "Tous", ce qui signifie que les totaux du tableau contiendront les données de tous les pays, districts, chefferies, ou_type, année, mois, les différentes catégories telles qu'elles sont énumérées dans les champs rouges, et tous les éléments de données du groupe Morbidité.

Comme nous l'avons vu, cette représentation n'est pas très utile, puisque la Morbidité est organisée en nouveaux cas, en suivis, en renvois, puis à nouveau en tranches d'âge. De plus, nous ne voyons pas les différents diagnostics. La première étape consiste à inclure le champ des diagnostics (qui est un ensemble de groupes), ce qui se fait en faisant glisser le champ "diagnostic" vers le bas pour qu'il devienne un champ de ligne, comme le montre la figure ci-dessous, et à ajouter l'ensemble de groupes appelé "morbidité-mortalité" dans le champ de colonne pour afficher les nouveaux cas, les suivis et les renvois.

Comparez ce chiffre ci-dessus à celui ci-dessous.

Elles présentent toutes deux les mêmes données (certaines lignes ont été coupées dans la capture d'écran en raison de la taille de l'image), quoique d'une manière différente.

Le champ " élément de données ", utilisé dans la figure ci-dessous, affiche chaque diagnostic sous la forme de trois éléments : un suivi, un nouveau et une orientation. C'est ainsi que les éléments de données ont été définis dans DHIS2, ce qui est logique pour l'agrégation. Il n'est pas souhaitable d'agréger les suivis et les nouveaux diagnostics, c'est pourquoi ils n'ont pas été classés en catégories, l'objectif étant de faciliter l'agrégation et la désagrégation.
Le groupe "diagnostic" a été créé pour regrouper ces trois groupes (suivi, nouveau, orientations), qui peuvent ensuite être séparés avec un autre groupe, à savoir celui appelé "morbidité-mortalité". Cela nous permet d'organiser les données comme dans la première des deux figures, où nous avons le diagnostic unique par ligne, et les groupes nouveaux, suivi, orientations comme lignes.

L'idée derrière l'utilisation des ensembles de groupes est que vous pouvez combiner, dans n'importe quel ensemble, différents éléments de données. Ainsi, si nous ajoutons les données sur la mortalité (en les vérifiant dans le menu déroulant du champ _groups_principaux, et en déplaçant ce champ hors du tableau), nous pouvons également voir les décès, puisque les éléments de données sur la mortalité ont été inclus comme groupe "décès" dans l'ensemble de groupes "morbidité-mortalité". Le résultat est présenté ci-dessous.

Le résultat est un tableau croisé dynamique beaucoup plus convivial. Maintenant, une autre figure montre la relation entre les ensembles de groupes et les éléments (ce sont de fausses valeurs de données).

Ce petit détail du tableau croisé dynamique montre comment les éléments de données réels sont liés aux ensembles de groupes :

Les quatre éléments de données, tels qu'ils sont définis dans DHIS2, sont le décès dû à la rougeole, le suivi de la rougeole, les nouveaux cas de rougeole et l'orientation
Ils font tous partie de l'ensemble de groupes "diagnostic", où ils sont regroupés dans le groupe Rougeole
L'ensemble de groupes "morbidité/mortalité" contient les groupes Nouveaux cas, Suivi, Renvois et Décès.
Seule l'élément de données Décès dus à la rougeole contient des données relatives au groupe Décès, et c'est donc là que la valeur (20) est indiquée, dans le coin supérieur droit. Il en va de même pour les nouveaux cas de rougeole ; la valeur (224) est indiquée à l'intersection de l'élément de données Nouveaux cas de rougeole et du groupe Nouveaux cas (dans l'ensemble de données morbidité-mortalité)
Toutes les intersections où l'élément de données n'est pas lié aux groupes de morbidité-mortalité sont laissées vides. Ainsi, dans ce cas, nous obtiendrions un tableau intéressant si nous excluons l'élément de données du tableau et si nous nous contentons du diagnostic et du groupe morbidité-mortalité, comme dans la figure présentée plus haut

Voyons maintenant comment les catégories d'éléments de données peuvent être utilisées. Dans le formulaire de saisie des données sur la morbidité, les nouveaux cas et les suivis utilisent une catégorie d'âge, les données de référence une autre, et les données sur la mortalité une troisième ventilation par âge. Ces données sont donc disponibles sous la forme de trois champs de groupes d'âge individuels dans les tableaux croisés dynamiques appelés âge de_morbidité, âge de_référence et âge de_mortalité. Il n'est pas logique de les utiliser en examinant ces données ensemble (comme dans les exemples ci-dessus), mais par exemple, si nous ne voulons examiner que les nouveaux cas, nous pouvons remettre le champ Groupesmortalitémorbidité dans un champ de page et y sélectionner le groupe Nouveaux cas comme filtre. Ensuite, nous pouvons faire glisser le champ Âge de_morbidité vers le bas dans la zone de la colonne et nous obtenons la vue ci-après :

Le tableau suivant illustre les avantages de la réutilisation des catégories d'éléments de données dans les ensembles de données et les combinaisons de catégories. Les données relatives à la VCCT, au TAR et à la PTME sont collectées dans trois ensembles de données différents, les deux premiers avec une ventilation par sexe et par âge, et le troisième avec l'âge de la PTME uniquement (le sexe est indiqué). Les trois partagent les mêmes groupes d'âge et il est donc possible de visualiser les éléments de données de ces trois ensembles de données dans le même tableau et d'utiliser la dimension Âge. Dans l'exemple précédent avec les données sur la morbidité et la mortalité, cela n'était pas possible car les nouveaux cas, les renvois et les décès ont tous des groupes d'âge différents.

Dans le tableau ci-dessous, les données relatives à la PTME ont été supprimées du tableau et la catégorie de sexe a été ajoutée dans la zone de colonnes pour vous permettre d'analyser les données relatives à la VCCT et au TAR par âge et par sexe. Un sous-total facultatif pour le sexe a également été ajouté, ainsi qu'un grand total pour tous les âges et sexes.

Étude de cas : Des formulaires papier aux ensembles de données multidimensionnelles - les enseignements tirés¶

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.

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 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 stupide et très probablement source d'incohérence) d'enregistrer des valeurs calculées manuellement telles que celles mentionnées ci-dessus. Vous devez seulement saisir les données brutes dans vos ensembles de données/formulaires et laisser les calculs à l'ordinateur, et la présentation de ces valeurs aux outils de déclaration dans le système DHIS2.

Des tableaux aux combinaisons de catégories - concevoir des ensembles de données multidimensionnelles¶

Comme nous l'avons vu dans les exemples ci-dessus, les catégories d'éléments de données et les options de catégories sont utiles pour représenter des données tabulaires, lorsqu'il s'agit d'ajouter des dimensions à un champ dans un formulaire papier. Nous avons également vu comment l'élément de données est l'une des dimensions requises qui décrivent les données dans le DHIS2. Comme nous le verrons dans l'exemple ci-dessous, il y a souvent plus d'une façon de représenter un formulaire papier dans le DHIS2, et il peut être difficile de savoir quelle dimension représenter avec un nom d'élément de donnée et laquelle représenter sous forme de catégories, ou même de groupes comme nous l'avons vu ci-dessus. Voici quelques enseignements d'ordre général tirés du travail à partir des combinaisons d'éléments de données et de catégories :

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 le long des différentes dimensions, afin d'obtenir un total significatif.
Réutiliser les dimensions autant que possible afin d'améliorer la capacité à comparer les données désagrégées (par exemple, groupes d'âge, fixe/atteinte, sexe).
Les dimensions de la désagrégation doivent être additionnées pour obtenir un total. Dans certains cas, les éléments de données peuvent être collectés en tant que sous-ensembles les uns des autres. Dans ce cas, il n'est pas nécessaire d'utiliser des catégories pour désagréger l'élément de données. Par exemple, nous pourrions collecter le "nombre de cas de paludisme confirmés" et le désagréger en "moins de 5 ans" et "plus de 5 ans". Un troisième élément de données "Nombre de cas de paludisme confirmés inférieurs à 1" pourrait également figurer sur le formulaire. Il semblerait alors raisonnable de créer trois groupes d'âge : moins de 1 an, moins de 5 ans et plus de 5 ans, pour décrire la désagrégation. Cependant, le groupe des moins de 1 an est en fait un sous-ensemble du groupe des moins de 5 ans et, une fois totalisé, il y aurait double emploi. Par conséquent, les catégories devraient généralement être composées d'options de catégories mutuellement exclusives, de sorte que la somme des options de catégories individuelles aboutisse à un total cohérent.
Différents niveaux de dimensions : 1) désagrégation et 2) regroupement. Les dimensions de désagrégation déterminent la manière dont vous collectez et stockez vos données, c'est pourquoi elles doivent être planifiées avec soin. La dimension de groupe est plus flexible et peut être modifiée et complétée même après la collecte des données (pensez-y comme un étiquetage).
Il est préférable, de penser à la manière dont les données seraient utilisées dans un référentiel de données intégré et non à la manière dont elles seront effectivement collectées dans les formulaires ou par les programmes lors de la conception du modèle de métadonnées. Idéalement, le même type de désagrégation devrait être utilisé dans les formulaires et les ensembles de données pour les éléments de données qui seront analysés ensemble ou utilisés pour construire des indicateurs. Réutiliser les définitions afin que la base de données puisse s'intégrer même si les formulaires eux-mêmes peuvent être dupliqués (ce qui, dans la pratique, est souvent le cas).

Pour mieux expliquer l'approche et les possibilités, nous présentons un exemple de formulaire papier et nous le parcourons étape par étape en concevant des éléments de données, des catégories, des options de catégories et des combinaisons de catégories.

Ce formulaire comporte de nombreux tableaux et chacun d'entre eux représente potentiellement une combinaison de catégories d'éléments de données (désormais appelée catcombo). Ainsi, il n'existe pas de restriction à ce qu'un ensemble de données n'ait qu'une seule série de dimensions ou catcombo. Il peut en avoir plusieurs et, comme nous l'avons souligné ci-dessus, cela est nécessaire car les dimensions sont très différentes d'un tableau à l'autre. Dans les paragraphes suivants, nous analyserons comment décomposer ce formulaire en ses éléments constitutifs et proposerons un cheminement de mise en œuvre dans DHIS2.

Tableau CPN. Ce tableau dans le coin supérieur gauche est l'un des plus simples de ce formulaire. Il a deux dimensions, la première colonne qui contient l'activité ou le service de CPN (1ère visite, 2ème dose de TPI etc.) et la deuxième et troisième colonnes qui représentent le lieu où le service a été fourni avec les deux options "Fixe" et "De proximité". Étant donné que le service de CPN est le phénomène clé à analyser ici, et qu'il est souvent nécessaire d'examiner le total des "1ères visites de CPN", quel que soit le lieu où elles ont effectivement eu lieu, il est très logique d'utiliser cette dimension comme dimension de l'élément de donnée.

Ainsi, tous les éléments de la première colonne, de la "1ère visite de CPN" à la "2ème dose de TPI administrée par TBA", sont représentés sous forme d'éléments de données individuels. La dimension où est représentée comme une catégorie d'élément de donnée (désormais appelée catégorie) avec le nom "fixe/de proximité" avec les deux options de catégorie d'éléments de données (désormais catoptions) "Fixe" et "De proximité". Il n'y a pas d'autre dimension ici et nous allons donc ajouter une nouvelle catcombo ayant pour nom "Fixe/De proximité" avec une catégorie "Fixe/De proximité". À proprement parler, ce tableau contient une autre dimension, à savoir la dimension À l'USP ou Par TBA, qui est répétée pour les deux doses de TPI, mais étant donné qu'aucun des autres services de CPN répertoriés ne possède cette dimension, il ne semble pas judicieux de séparer deux éléments de données de ce tableau et de leur donner une autre combinaison avec les deux catégories "Fixe/De proximité" et "À l'USP/Par TBA". La réutilisation de la même combinaison pour tous les services de CPN est plus logique car il sera plus facile de les examiner ensemble dans les rapports, etc. et aussi parce qu'il n'y a pas grand-chose à perdre avec la répétition des informations À l'USP ou Par TBA dans le nom de l'élément de donnée alors qu'elles ne concernent que quatre éléments de données dans un tableau de onze éléments de données.

Tableau Accouchement Ce tableau est plus délicat puisqu'il contient assez d'informations et vous pouvez constater que toutes les lignes n'ont pas les mêmes colonnes (certaines colonnes sont fusionnées et un champ est grisé/désactivé). Si nous commençons par examiner la première colonne "Accouchements assistés par", cela semble être une dimension, mais seulement jusqu'à la ligne "Accoucheuse traditionnelle non formée", car les trois autres lignes ne sont pas du tout liées à la personne ayant assisté à l'accouchement. Une autre dimension est le lieu de l'accouchement, soit dans l'USP, soit dans la Communauté, comme indiqué dans les en-têtes de la colonne supérieure. Ces accouchements sont ensuite divisés en fonction du résultat de l'accouchement, qu'il s'agisse d'une naissance vivante ou d'une mortinaissance, ce qui semble être une autre dimension. Ainsi, si l'on ne tient pas compte des trois lignes du bas, il semble y avoir trois dimensions ici : 1) assisté par, 2) le lieu de l'accouchement et 3) le résultat de l'accouchement. La décision clé à prendre est de savoir quel élément de donnée utiliser, la dimension principale, le total que vous utiliserez le plus souvent et que vous souhaitez voir facilement disponible dans les rapports et les analyses de données.

Dans ce cas, la dimension Résultat "Total des naissances vivantes" est une valeur très couramment utilisée dans de nombreux indicateurs (taux de mortalité maternelle, naissances assistées par du personnel de santé qualifié, etc.). Dans ce cas, la dimension "Assistée par" aurait également pu être utilisée sans problème, mais la valeur ajoutée d'obtenir facilement les informations sur les naissances vivantes totales a été le point décisif pour nous. Cela signifie que dans ce tableau (ou sous-tableau des lignes 1 à 6), il n'y a que deux éléments de données : "Naissances vivantes" et "Morts- nés".

Ensuite, il y a deux autres dimensions, l'"USP/Communauté" avec ses deux options et un "Accouchements assistés par" avec des options ("Aides SMI", "SECHN", "Sages-femmes", "CHO", "TBA qualifiée", "TBA non qualifiée"). Ces deux catégories constituent la catcombo "Naissances" qui est attribué aux deux éléments de données "Naissances vivantes" et "Mortinaissancess". En considérant les trois dernières lignes du tableau d'accouchement, nous pouvons voir que "Accouchements compliqués" n'a pas la dimension Assistés par, mais a les dimensions Lieu et Résultat. L'élément "Faible poids à la naissance" n'a pas non plus la dimension Assistés par et n'a pas non plus la dimension Résultat. Le MILD donné après l'accouchement n'a pas de dimension supplémentaire du tout. Étant donné qu'aucune des trois lignes ne peut partager la catcombo avec une autre ligne, nous avons décidé de représenter ces champs comme des éléments de données plats, c'est-à-dire des éléments de données sans aucune catégorie, et d'ajouter simplement les informations supplémentaires des en-têtes de colonne au nom de l'élément de donnée, ce qui nous a permis d'obtenir les éléments de données suivants avec la catcombo par défaut (identique à aucun) ; "Accouchements compliqués dans une USP Naissances vivantes", "Accouchements compliqués dans une USP Mortinaissances", "Accouchements compliqués dans une communauté naissances vivantes", "Accouchements compliqués dans une communauté Mortinaissances", "Faible poids à la naissance dans une USP", "Faible poids à la naissance dans une communauté" et "MILD donné après l'accouchement".

Tableau des soins postnatals Il s'agit ici d'un tableau simple et nous avons utilisé la même approche que celle utilisée pour le tableau de CPN. 3 éléments de données énumérés dans la première colonne, puis nous les relions à la catcombo appelée "Fixe/De proximité". La réutilisation de la même catégorie Fixe / Proche pour ces éléments de données permet d'effectuer une analyse sur Fixe /De proximité à partir des données de CPN et d'autres données utilisant la même catégorie.

Tableau des vaccins TT Ce tableau est un peu plus complexe que ceux utilisés dans les exemples précédents. Nous avons donc décidé d'utiliser les vaccins "TT1", "TT2" ... "TT5" comme éléments de données, ce qui permet d'obtenir facilement le total de chacun d'entre eux. Il y a ici une dimension Fixe/De proximité, mais il y a aussi la dimension "En milieu scolaire" qui ne s'applique qu'aux filles non enceintes, ou plus exactement à l'une des deux, puisque la vaccination en milieu scolaire est effectuée que les filles soient enceintes ou non. Nous avons consulté les responsables du programme chargés de la gestion du formulaire et nous avons découvert qu'il serait acceptable d'enregistrer toutes les vaccinations TT en milieu scolaire comme étant non enceintes, ce qui simplifie un peu le modèle puisque nous pouvons réutiliser les éléments de données "TT1" à "TT5". Nous nous sommes donc retrouvés avec une nouvelle catégorie appelée "Lieu de TT" avec les trois options (Fixe, De proximité, En milieu scolaire), et une autre catégorie appelée "Enceinte/Non enceinte" avec deux options. La nouvelle catcombo "TT" est alors une combinaison de ces deux options et est appliqué aux 5 éléments de données de TT. Comme nous avons convenu de placer toutes les vaccinations en milieu scolaire dans la catégorie "Non-Enceinte", la combinaison d'options (Enceinte+ En milieu scolaire) ne sera jamais utilisée dans aucun formulaire de saisie de données, et deviendra donc une éventuelle combo d'options, ce qui est correct. Tant que le formulaire est conçu sur mesure, vous pouvez choisir les combinaisons d'options à utiliser ou non, et il n'y a donc aucun problème à avoir de telles catoptions passives ou non utilisées. Le fait d'avoir l'école comme option dans la catégorie Lieu de TT simplifie le modèle et nous avons donc pensé que cela valait la peine. L'alternative serait de créer 5 éléments de données supplémentaires pour "TT1 en milieu scolaire" ... "TT5 en milieu scolaire", mais il serait alors un peu déroutant de les additionner avec "TT1" ... "TT5" plus la catcombo TT . Avoir des écoles comme lieu dans la catégorie Lieu de TT rend beaucoup plus facile d'obtenir le total des vaccin TT1 ...TT5 administrés, qui sont les chiffres les plus importants et les valeurs les plus souvent utilisées pour l'analyse des données.

Tableaux de complications de la grossesse précoce et tardive et des accouchements Nous traitons ces deux tables comme étant une seule, et nous expliquerons pourquoi. Ces deux tableaux sont un peu déroutants et ne sont pas les mieux conçus. Les données les plus importantes qui ressortent de ces tableaux sont les complications de la grossesse et les décès maternels. Ces éléments de données contiennent des détails supplémentaires sur la cause de la complication ou du décès (première colonne des deux tableaux), ainsi que le lieu du décès (dans l'USP ou la communauté), et le résultat de la complication (lorsqu'il ne s'agit pas d'un décès) qui peut être soit "Géré à l'USP" soit " Référé". Nous avons décidé de créer deux éléments de données pour ces deux tableaux : "Complications de la grossesse" et "Décès maternels", et deux combinaisons de catégories, une pour chacun des éléments de données. Pour l'élément de donnée "Complications de la grossesse", il y a deux dimensions supplémentaires, la cause de la complication (la liste combinée de la première colonne des deux tableaux) et le résultat (géré à l'USP ou "Référé"), ce sont donc les catégories et les options qui constituent cette combinaison de catégories. Pour l'élément de donnée "Décès maternels", on utilise la même catégorie avec les différentes causes, puis une autre catégorie pour le lieu du décès (dans l'USP ou dans la communauté). Ainsi, les deux éléments de données peuvent partager une même catégorie et il sera facile de calculer le nombre total de complications de la grossesse et de décès maternels. Alors que la liste des complications sur le formulaire papier est divisée en deux (précoce et tardive/travail), vous pouvez constater que, par exemple, le paludisme au 2ème et 3ème trimestre sont énumérés sous précoce, mais en fait sont pour une phase ultérieure de la grossesse. Il n'y a pas de distinction claire entre les complications précoces et tardives dans le formulaire, et nous avons donc renoncé à essayer de faire cette distinction dans la base de données.

Tableau des services de planning familial Ce tableau comporte 2 dimensions, à savoir la méthode de planning familial (contraceptif) et le fait que le client soit nouveau ou existant. Nous n'avons obtenu qu'un seul élément de donnée "Clients des services de planning familial", puis nous avons ajouté deux catégories "Méthode de PF" avec tous les contraceptifs en option, et une autre catégorie "Type de client de PF" avec les nouveaux clients ou les clients existants en option. De cette façon, il sera facile d'obtenir le nombre total de clients des services de planning familial, ce qui est la principale valeur à prendre en compte dans l'analyse des données, et de là, vous pourrez facilement obtenir les détails sur la méthode ou le nombre de nouveaux clients.

Une approche progressive de la conception des ensembles de données¶

Identifier les différents tableaux (ou sous-ensembles de données) du formulaire papier qui partagent les mêmes dimensions
Pour chaque tableau, identifiez les dimensions qui décrivent les champs de données
Identifier la dimension clé, celle qui a le plus de sens lorsqu'elle est considérée isolément (lorsque les autres sont regroupées, résumées). Il s'agit de la dimension de l'élément de données, le point de départ et le cœur de votre modèle multidimensionnel (sous-ensemble de données). La dimension de l'élément de données peut être une fusion de deux dimensions ou plus si cela s'avère plus judicieux pour l'analyse des données. L'essentiel est d'identifier le total qui a le plus de sens pour être examiné seul lorsque les autres dimensions sont fusionnées.
Pour toutes les autres dimensions/additionnelles, identifiez leurs options et trouvez des noms explicites pour les dimensions et leurs options.
Chacune de ces dimensions supplémentaires constituera une catégorie d'éléments de données et leurs options seront des options de catégorie.
Combinez toutes les catégories de chaque sous-ensemble de données en une seule combinaison de catégories et affectez-la à tous les éléments de données de votre tableau (ou sous-ensemble de données si vous le souhaitez).
Lorsque vous avez terminé avec tous les tableaux (sous-ensembles de données), créez un nouvel ensemble de données et ajoutez-y tous les éléments de données que vous avez identifiés (dans le formulaire papier complet).
Votre ensemble de données sera alors constitué d'un ensemble d'éléments de données liés à une ou plusieurs combinaisons de catégories.