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

Conventions d'appellation¶

Ce document décrit les conventions de dénomination et les recommandations générales pour la création de métadonnées DHIS2 dans le cadre d'un SIS intégré (tracker ou agrégat). Dans la mesure du possible, ces conventions sont appliquées à l'ensemble des kits de configuration développés par l'UiO.

Conseils généraux relatifs à la dénomination des objets DHIS2¶

Le principe général est de concevoir des éléments de données et des indicateurs qui peuvent être utilisés efficacement pour l'analyse. En général, le nombre d'utilisateurs finaux interagissant avec ces éléments sera beaucoup plus élevé que celui des administrateurs de systèmes. Par conséquent, les principes de conception suggérés visent à rendre les éléments plus faciles à reconnaître et à trouver. * Abréger et simplifier les noms / noms courts dans la mesure du possible ; par exemple, il n'est généralement pas nécessaire d'inclure "Nombre de..." et des phrases similaires, en particulier pour les éléments de données agrégées où pratiquement tout est en chiffres. * Fournir un nom significatif et concis : placer les informations clés au début du nom, à condition que cela ne complique pas la compréhension de la signification du nom * Pensez aux utilisateurs qui verront les noms ou les noms abrégés des différents objets, et aux applications avec lesquelles ils interagissent. N'oubliez pas que les utilisateurs peuvent configurer leur compte utilisateur pour afficher les noms longs ou courts dans les applications. * Les noms (noms longs) doivent inclure un préfixe et un suffixe, le cas échéant, afin de faciliter l'ordre des métadonnées et le filtrage pour les utilisateurs analytiques et les administrateurs. * Les noms courts sont limités à 52 caractères ; rendez-les aussi significatifs que possible en tenant compte de l'utilisateur final qui a accès à ces objets par l'intermédiaire des applications d'analyse. * Noms de formulaires : les noms de formulaires pour les éléments de données doivent être optimisés pour l'utilisateur qui saisit les données. Ces noms apparaissent dans les applications de saisie des données et doivent être suffisamment explicites et clairs pour la personne qui saisit les données. La longueur de ces noms doit également être prise en compte. Pour les applications Android, les implémenteurs doivent tenir compte de la manière dont ces noms s'affichent sur un appareil mobile * La plupart des utilisateurs d'outils d'analyse interagissent principalement avec des éléments de tableau de bord, des éléments de données, des indicateurs, des combinaisons de catégories configurées comme une dimension de données, des ensembles de légendes.

Programme specific vs generic/shared metadata¶

DHIS2 est largement utilisé comme un SIG intégré, combinant des données et des métadonnées provenant de plusieurs domaines et programmes de santé en un seul système. Il est donc important de préciser à quelle maladie ou à quel programme se rapportent certaines métadonnées. Par exemple, un nom comme "Taux d'incidence des cas pour 100 000 habitants" peut faire référence au paludisme, à la tuberculose, au choléra, etc. Toutefois, il est également important de veiller à ce que certaines métadonnées puissent être partagées entre les maladies/domaines de la santé.

Pour faciliter l'harmonisation des métadonnées, nous recommandons d'appliquer les préfixes suivants aux noms longs des objets de métadonnées tels que les éléments de données et les indicateurs (mais pas aux "noms courts" ou aux "noms de formulaires"), selon que les métadonnées sont spécifiques à un certain programme ou partagées entre plusieurs programmes. * Les métadonnées spécifiques à un programme de santé ou à une maladie doivent être précédées d'un code préfixe cohérent représentant le programme de santé ou la maladie ou tout autre regroupement logique des métadonnées : * ex : Tuberculose, Paludisme, VIH, PEV, RMNCAH, CRVS, etc. * Les métadonnées partagées entre les domaines/programmes de santé devraient avoir un préfixe plus générique pour désigner les métadonnées qui sont généralement considérées comme réutilisables ou partagées * Ex : les kits de métadonnées du HIS de l'UiO utilisent le préfixe "GEN"

Examples of naming¶

Exemple de bonnes pratiques de nomenclature pour un élément de données : Veiller à ce que la partie la plus importante du nom soit celle qui détermine l'ordre des éléments de données dans une liste ordonnée :

CPN 1ère visite
CPN 2ème visite
CPN 3ème visite
CPN 4ème visite

Cela permettra aux éléments d'apparaître ensemble au sein d'une zone thématique ; ils sont également classés dans l'ordre prévu, du premier au dernier.

Si le choix se porte sur une nomenclature connue pour les formes abrégées courantes dans un programme (généralement pour les éléments de données ou les indicateurs), il convient de sélectionner une méthode uniforme pour toutes les métadonnées (par exemple, P., Pl. ou Plasmodium).

Exemple de mauvaise pratique de nomenclature pour un élément de données : Nombre de femmes enceintes qui effectuent leur première visite de CPN.

La mention Nombre de n'est généralement pas nécessaire. Il est clair qu'il s'agit d'un nombre figurant dans un rapport mensuel, ce qui augmente la longueur du nom.
Le terme " femmes enceintes " est redondant. Seules les femmes enceintes effectuent des visites de CPN.
La première visite de CPN est l'information clé et ne doit pas figurer à la fin du nom.
Idéalement, la première partie du nom devrait vous permettre de regrouper des éléments de données similaires dans une liste ordonnée.

Si nous examinons les visites 1 à 4 de la CPN, nous pouvons utiliser :

Première visite de CPN
Deuxième visite de CPN
Troisième visite de CPN
Quatrième visite de CPN

Toutefois, lorsqu'ils sont combinés dans une liste ordonnée (telle que celle qui apparaîtrait dans les applications d'analyse de DHIS2) avec d'autres éléments de données, ils ne seront ni ordonnés ni regroupés.

Numbers as part of names¶

Inférieur (ou égal) : utilisez 0-4, et non 0 - 4, < ; 5, <= 4, ≤ 5
Plus que (ou égal) : utilisez 15+, et non >14, >= 15, ≥ 15
Intervalles : utiliser 5-14 et non 5 - 14

Éléments de donnée¶

Les noms des éléments de données doivent être précédés de l'acronyme/du code du programme/domaine de santé, ex. TB, PAL, VIH, PEV, etc.
Les éléments de données représentent généralement un nombre brut de valeurs. Par conséquent, si un élément de données n'a pas de postfixe indiquant de quel type de valeur il s'agit, on suppose qu'il s'agit d'un nombre brut (par exemple, première visite de CPN - aucun postfixe n'est présent, nous pouvons donc supposer que vous déclarez le nombre de visites de CPN).
Si vous collectez un type de taux, de proportion, etc. directement en tant que valeur de données non calculée (c'est-à-dire en tant que valeur brute dans le cadre d'un processus de collecte de données), il convient de l'indiquer en ajoutant un postfixe court entre parenthèses à la fin du nom de l'élément de données.
Nous pouvons, dans la mesure du possible, supprimer le texte brut d'un élément de données s'il n'est pas manifestement significatif lorsqu'il est examiné en tant que résultat, afin de raccourcir le nom (par exemple, "Nombre de cas de paludisme positifs au moyen d'un TDR" peut être remplacé par "Cas de paludisme positifs (TDR)") pour obtenir un résultat plus lisible lors de l'analyse.

Indicateurs¶

Les noms des éléments de données doivent être précédés de l'acronyme/du code du domaine/programme de santé, ex TB, PAL, VIH, PEV, etc.
Les indicateurs sont des calculs qui utilisent une combinaison d'éléments de données pour créer un résultat à analyser.
L'appellation est souvent différenciée des éléments de données par le nom de l'indicateur lui-même (par exemple, CPN 1ère visite vs. couverture CPN 1ère visite (%))
Ils peuvent être légèrement plus longs que les noms des éléments de données en raison de l'ajout d'un postfixe indiquant le type d'indicateur dont il s'agit.
Les indicateurs ne doivent pas commencer par un % au début de leur nom. Dans une liste, ils seront désorganisés.
(assets/indicator_perc_prefix.png)
Les noms longs tels que proportion ou pourcentage peuvent être utilisés dans les descriptions, mais ne doivent pas être inclus dans le nom de l'indicateur. Nous pouvons voir que cela ajoute du texte supplémentaire au début du nom. Il regroupe également les éléments par "proportion de/pourcentage de" plutôt que par la caractéristique d'identification (c'est-à-dire les foyers, les cas de paludisme, le type d'espèce de paludisme).

Si nous ajoutons un % comme postfixe, les éléments sont organisés de manière plus significative, le nom est raccourci et les espaces inutiles au début du nom sont supprimés

Favoris¶

Noms favoris : Préfixer les noms favoris avec le nom de la zone de santé/du programme et le trait d'union, par exemple Tuberculose - Notifications de cas..., Paludisme - Taux d'incidence...
Titres favoris : Les titres n'ont pas besoin de préfixe, car ils ne sont pas utilisés pour la recherche.

Ensembles d'options¶

Les ensembles d'options génériques/réutilisables doivent avoir des noms génériques dans la mesure du possible. Par exemple, si un ensemble d'options est nécessaire pour les résultats du test VIH avec les options "Positif" et "Négatif", il doit être nommé "Positif/Négatif" plutôt que "Résultat du test VIH" afin de pouvoir être réutilisé. Dans les cas où plusieurs objets risquent d'être confondus ou sont similaires mais pas identiques, il convient de le préciser, par exemple "Résultat du traitement de la tuberculose", "Résultat du traitement du paludisme".

Codes¶

Tous les codes doivent être précédés de l'acronyme/code du programme de lutte contre la maladie/domaine et d'un trait de soulignement, ex TB_, PAL_, VIH_, PEV_, etc.
Les codes doivent être mis en majuscules.
Lorsqu'il existe des codes pour un programme ou une maladie en particulier, il convient de les utiliser. Toutefois, ils doivent toujours être précédés de l'acronyme/code de ce domaine et écrits en majuscules).
Si de nouveaux codes sont créés, ils doivent suivre ces lignes directrices :
- Seuls les caractères alphanumériques et les traits de soulignement doivent être utilisés.
- Dans la mesure du possible, les codes doivent être significatifs (par exemple, " VIH_TEST_POS " plutôt que " VIH_T01_ ").