Principes généraux de conception du RHIS intégré¶
Ce document décrit brièvement les principes généraux de conception qui ont été suivis lors de la configuration des packages de métadonnées standard de DHIS2 pour le compte de la boîte à outils de données numériques sur la santé de l'OMS. En plus de ce document, un autre document détaillé sur la conception du système est disponible pour chaque package de domaine ou de programme sanitaire.
Analyse des données¶
La partie de la configuration consacrée à l'analyse des données est centrée sur les indicateurs et les tableaux de bord. Les packages agrégés (versions tableau de bord/analyse et terminé) contiennent un ou plusieurs tableaux de bord.
Les tableaux de bord contenus dans les packages agrégés sont exclusivement basés sur des indicateurs. Cela signifie que même s'il existe un élément de données équivalent pour un concept (par exemple, Visites de CPN), un indicateur sera créé et utilisé dans l'élément du tableau de bord (tableau croisé dynamique, graphique ou carte). Ceci ne s'applique qu'aux tableaux de bord, car les indicateurs sont utilisés pour établir des correspondances avec des éléments de données existants dans l'instance DHIS2 d'un pays. L'inconvénient avec cette approche est que nous créons des doublons de métadonnées qui ne sont pas vraiment nécessaires. Cependant, elle présente des avantages importants qui l'emportent sur cette duplication. L'avantage le plus important est qu'il permet d'utiliser les mêmes tableaux de bord dans les packages de configuration agrégé et tableau de bord uniquement, sans modifications. Étant donné que les configurations standard sont alignées sur un programme de formation, le fait que les tableaux de bord implémentés soient aussi similaires que possible est un avantage. Les mêmes variables d'analyse seront disponibles, qu'il s'agisse du package 'agrégé' ou du package 'tableau de bord uniquement'. De plus, il est souvent plus facile pour les utilisateurs finaux d'accéder à toutes les données qu'ils souhaitent analyser au sein d'un groupe d'indicateurs dans les applications d'analyse, plutôt que de passer d'un groupe d'éléments de données à un groupe d'indicateurs. L'on n'attend pas de ces utilisateurs finaux qu'ils fassent la distinction entre un élément de données DHIS2 et un indicateur DHIS2.
De la même manière que seuls les indicateurs sont utilisés dans les tableaux de bord, seuls les groupes d'options de catégorie et les ensembles de groupes d'options de catégorie sont utilisés pour appliquer les désagrégations aux résultats d'analyse. Ce raisonnement s'applique également à la décision d'utiliser uniquement des indicateurs : les groupes d'options de catégorie peuvent être mis en correspondance avec les options de catégorie existantes.
Enfin, tous les résultats d'analyse (favoris : tableaux croisés dynamiques, graphiques, cartes) utilisent des unités d'organisation et des périodes relatives. Cela est nécessaire pour qu'ils soient transférables d'une instance à l'autre et sur le long terme. Dans certains cas, des modifications sont nécessaires pour les adapter au contexte. La documentation renseigne mieux sur ce point.
Rapport agrégé¶
La composante de rapport agrégé des packages de métadonnées comprend :
- des ensembles de données
- un élément de données
- des catégories d'éléments de données, des options de catégorie, des combinaisons de catégories
- des règles de validation
Les ensembles de données sont tous basés sur les recommandations et les exemples de bonnes pratiques de l'OMS ou sur des cadres de notification publiés (tels que ["Définitions et cadre de notification pour la tuberculose"] (http://www.who.int/tb/publications/definitions/en/)). Dans de nombreux cas, ces ensembles de données devront être adaptés aux systèmes nationaux de notification, à des degrés divers. D'une part, il se peut que des variables supplémentaires, importantes dans un contexte national, doivent être ajoutées. D'autre part, certaines informations peuvent tout simplement ne pas être disponibles pour la déclaration, par exemple si les données ne sont pas saisies dans les registres des cas au niveau clinique. Par conséquent, l'implémentation de ces ensembles de données de référence sera souvent un projet à plus long terme. Même dans les contextes où ils ne sont pas utilisés directement, ils peuvent servir de modèles pour déterminer quelles données peuvent être collectées à l'aide de DHIS2 pour différents domaines/programmes de santé et comment la collecte peut se faire.
Bien que les packages de configuration standard soient spécifiques à un domaine ou à un programme de santé, les métadonnées sous-jacentes ont été harmonisées et utilisées dans la mesure du possible pour tous les programmes de santé. Par exemple, si un élément de données ou une désagrégation s'applique à plus d'un ensemble de données, les métadonnées de DHIS2 seront réutilisées.
Une lacune courante observée dans de nombreuses instances DHIS2 nationales est que les règles de validation ne sont pas appliquées de manière cohérente : soit elles ne sont pas utilisées, soit elles sont parfois utilisées pour signaler des problèmes de qualité des données qui sont peu probables, mais possibles. Dans les packages de configuration standard, un effort a été fait pour ajouter des règles de validation partout où c'est possible, mais seulement pour les contrôles liés à la qualité des données (par exemple, les tests effectués par rapport aux tests positifs).
Principes transversaux¶
Dans la mesure du possible, tous les objets de métadonnées, allant des ensembles de données et des éléments de données aux favoris des cartes, devraient avoir une bonne description. Afin de faciliter l'harmonisation du SIGS, les métadonnées agrégées telles que les éléments de données et les combinaisons de catégories sont partagées autant que possible. Par exemple, si le package 'Paludisme' comporte un élément de données 'Nombre de visites de CPN' comme dénominateur d'un indicateur, cet élément de données sera partagé avec le package 'RMNCAH' dans les packages agrégés terminés.
Tracker¶
La suite sera bientôt disponible !