SIM - Guide d'installation du package Surveillance intégrée des maladies¶

Ce document comprend un guide d'installation pour le package agrégé de SIM

Langue par défaut du système : anglais

Traductions disponibles : Français

Aperçu¶

Les fichiers metadata reference et metadata json fournissent des détails techniques sur la version et le contenu du package.

Le package de métadonnées se compose des modules suivants :

• Surveillance intégrée des maladies
• Surveillance intégrée des maladies (tableau de bord)

Installation¶

L'installation du module se fait en plusieurs étapes :

1. Préparation du fichier de métadonnées avec les métadonnées DHIS2
2. Importation des métadonnées dans DHIS2
3. Configuration des métadonnées importées
4. Adaptation du programme après importation

Nous vous recommandons de lire tout d’abord chaque section du guide d’installation avant de commencer le processus d’installation et de configuration dans le système DHIS2. Identifiez les sections applicables en fonction du type d’importation :

1. importation dans une instance DHIS2 vide
2. importation dans une instance DHIS2 avec des métadonnées existantes.

Les étapes décrites dans ce document doivent être testées dans une instance DHIS2 de test/transit avant d’être appliquées à un environnement de production.

Conditions requises¶

Pour installer le module, vous devez avoir un compte administrateur dans le système DHIS2.

Il est important de s’assurer que le serveur et l’application DHIS2 sont bien sécurisés et de configurer les droits d’accès aux données collectées. Les détails sur la sécurisation d’un système DHIS2 sortent du cadre de ce document. Veuillez consulter le site Documentation sur le DHIS2.

Fichiers de métadonnées¶

Bien que ce ne soit pas toujours nécessaire, il peut souvent être avantageux d'apporter certaines modifications au fichier de métadonnées avant son importation dans DHIS2.

Préparation du fichier de métadonnées¶

Dimension de données par défaut¶

Dans les premières versions du système DHIS2, les UID des dimensions de données par défaut étaient générés automatiquement. Ainsi, bien que toutes les instances du système DHIS2 possèdent une option de catégorie par défaut, une catégorie d’élément de données, une combinaison de catégories et une combinaison d’options de catégorie, les UID de ces valeurs par défaut peuvent être différents. Les versions ultérieures du système DHIS2 utilisent des UID codés en dur pour la taille par défaut, lesquels sont utilisés dans les packages de configuration.

Pour éviter tout conflit lors de l’importation des métadonnées, nous vous recommandons de rechercher et de remplacer toutes les occurrences de ces objets par défaut dans l’ensemble du fichier .json, en remplaçant les UID du fichier .json par ceux de l’instance dans laquelle le fichier sera importé. Le tableau 1 présente les UID à remplacer, ainsi que les points de terminaison d’API permettant d’identifier les UID existants.

Identifiez les UID des tailles par défaut de votre instance à l’aide des requêtes API affichées et remplacez les UID dans le fichier .json par ceux de l’instance.

N.B.

Notez que cette opération de recherche et de remplacement doit être effectuée via un éditeur de texte brut, et non un traitement de texte comme Microsoft Word.

Types d'indicateurs¶

Le type d’indicateur est également un type d’objet susceptible de créer un conflit lors de l’importation, car certains noms sont utilisés dans différentes bases de données DHIS2 (par ex. « Pourcentage »). Comme les types d’indicateurs sont définis par leur facteur (y compris 1 pour les indicateurs « numérateur seulement »), ils ne laissent aucune ambiguïté et peuvent être remplacés en recherchant et remplaçant des UID. Cette méthode permet d’éviter les éventuels conflits d’importation et empêche le responsable de la mise en œuvre de créer des doublons de types d’indicateurs. Le tableau ci-dessous contient les UID pouvant être remplacés, ainsi que les points de terminaison d’API permettant d’identifier les UID existants :

Visualisations utilisant l'UID de l'unité d'organisation racine¶

Les visualisations, les rapports d’événements, les tableaux de rapports et les cartes affectés à un niveau d’unité d’organisation spécifique ou à un groupe d’unités d’organisation comportent un renvoi à l’unité d’organisation de base (niveau 1). Ces objets, s’ils sont présents dans le fichier de métadonnées, contiennent une balise <OU_ROOT_UID>. Utilisez la fonction de recherche de l’éditeur de fichiers .json pour trouver cette balise et la remplacer par l’UID de l’unité d’organisation de niveau 1 dans l’instance cible.

Codes d'option¶

Selon les conventions d'affectation de noms du système DHIS2, les codes de métadonnées utilisent des lettres majuscules, des caractères de soulignement et aucun espace. Certaines exceptions susceptibles de survenir sont spécifiées dans la documentation du package correspondant. Tous les codes inclus dans les objets de métadonnées du package actuel correspondent aux conventions d'affectation de noms. Il peut arriver que les codes des objets de métadonnées existants utilisés dans la base de données cible utilisent des caractères minuscules. Dans ce cas, il est important de mettre à jour ces valeurs directement dans la base de données.

Important

Pendant l’importation, les codes d’option existants seront remplacés par les nouveaux codes en majuscules. Afin de mettre à jour les valeurs des données existantes dans la base de données, vous devez mettre à jour les valeurs stockées dans la base de données en utilisant les commandes de la base de données. Assurez-vous de mapper les anciens codes d’option et les nouveaux avant de remplacer les valeurs. Utilisez d’abord l’instance de transit, avant d’effectuer des modifications sur le serveur de production.

Pour les valeurs des éléments de données, utilisez :

UPDATE programstageinstance
SET eventdatavalues = jsonb_set(eventdatavalues, '{"<affected data element uid>","value"}', '"<new value>"')
WHERE eventdatavalues @> '{"<affected data element uid>":{"value": "<old value>"}}'::jsonb
AND programstageid=<database_programsatgeid>;

Ordre de tri pour les options¶

Vérifiez si l’ordre de tri sortOrder des options de votre système correspond à celui inclus dans le package de métadonnées. Cela ne s’applique que si le fichier .json et l’instance cible contiennent des options et des ensembles d’options avec le même UID.

Après l’importation, assurez-vous que l’ordre de tri des options d’un ensemble d’options commence par 1. Les valeurs de l’ordre de tri ne doivent avoir aucun écart (par exemple 1, 2, 3, 5, 6).

L’ordre de tri peut être modifié dans l’application Maintenance.

1. Accédez à l’ensemble d’options applicable
2. Ouvrez la section « Options »
3. Utilisez « TRIER PAR NOM », « TRIER PAR CODE/VALEUR » ou « TRIER MANUELLEMENT » comme alternative.

Le package SIM contient un ensemble d'options et deux options :

{
    "optionSets": [
        {
            "name": "YES/NO (numeric)",
            "id": "TdDqpX1kdd2",
            "code": "YES_NO_NUM",
            "valueType": "INTEGER_ZERO_OR_POSITIVE",
            "options": [
                {
                    "id": "VavIEUmBv8j"
                },
                {
                    "id": "Xu8ieCbS7jH"
                }
            ]
        }
    ],
    "options": [
        {
            "name": "Yes",
            "id": "VavIEUmBv8j",
            "code": "1",
            "sortOrder": 1,
            "optionSet": {
                "id": "TdDqpX1kdd2"
            }
        },
        {
            "name": "No",
            "id": "Xu8ieCbS7jH",
            "code": "0",
            "sortOrder": 2,
            "optionSet": {
                "id": "TdDqpX1kdd2"
            }
        }
    ]
}

Cet ensemble d'options Oui/Non est basé sur des valeurs d'option "ENTIER_ZÉRO_OU_POSITIVE" qui sont attribuées à deux éléments de données et évaluées dans un prédicteur indiqué ci-dessous :

Données sur la population¶

Le package SIM comprend des éléments de données, des indicateurs et d'autres objets de métadonnées relatifs aux données de population.

Si l'instance cible dispose déjà d'une infrastructure de métadonnées, qui est utilisée pour la collecte de Données de population, veuillez vous référer aux étapes énumérées ci-dessous :

1. Choisir la stratégie permettant d'aligner les métadonnées de population dans l'instance cible et dans le fichier .json.
2. Option 1 : Remplacer les UID des éléments de données et de toutes leurs occurrences dans le fichier json par les UID du système cible

3. Option 2 : Envisager de remplacer les UID de ces éléments de données dans le système cible par les UID du fichier json. Les éléments de données GEN font partie de la bibliothèque de métadonnées de base DHIS2 et sont utilisés dans d'autres packages de métadonnées.

4. Les indicateurs qui utilisent les données de population agrégeront les données au(x) niveau(x) où elles sont saisies.

5. Un mappage et une configuration supplémentaires peuvent être nécessaires après l'importation du package. Reportez-vous à la section [configuration des ensembles de données] (#rehab-dataset-config).

N.B.

Lorsque vous mettez à jour l'UID d'un élément de métadonnées dans l'instance DHIS2 existante, vous devez exécuter une commande SQL dans la base de données et remplacer en outre toutes les occurrences et références de son UID dans d'autres objets de métadonnées : prédicteurs, indicateurs, expressions de règles de validation, etc.

Prédicteurs¶

Le package comprend les prédicteurs suivants :

Les métadonnées du prédicteur comprennent les niveaux d'unité d'organisation utilisés pour l'agrégation des valeurs des données. Le fichier de métadonnées du package contient des caractères de remplacement qui doivent être remplacés par les UID des niveaux d'unités d'organisation correspondants dans la base de données cible.

Les étapes à suivre pour préparer les prédicteurs à l'importation sont décrites ci-dessous :

1. Identifier l'UID de l'organisationUnitLevel (niveau d'unité d'organisation) du niveau de district auquel les données des prédicteurs seront agrégées. Utiliser le point de terminaison d'API suivant pour identifier l'UID requis : ../api/organisationUnitLevels.json?fields=id,name.
2. Trouver les caractères génériques organisationUnitLevel suivants dans le fichier json : <OU_LEVEL_DISTRICT_UID>
3. Remplacer les caractères génériques par l'UID du niveau de l'établissement identifié dans l'instance cible.

Règles de validation¶

Toutes les règles de validation incluses dans le package sont listées dans le fichier de référence des métadonnées.

Les groupes d'unités d'organisation pour toutes les règles de validation sont définis au niveau du district. La valeur du niveau du district se trouve dans la propriété "organisationUnitLevels" de chaque règle de validation. Elle est fixée à 3 par défaut. Ajustez ces niveaux dans le fichier de métadonnées pour qu'ils correspondent au niveau du district dans l'instance cible avant l'importation du package.

Notifications des règles de validation¶

Toutes les notifications de validation incluses dans le package sont listées dans le fichier de référence des métadonnées.

Notez que toutes les notifications de règles de validation pour ce package sont toutes configurées pour être envoyées sous forme de "notification unique". Cela signifie qu'une notification est envoyée pour chaque combinaison d'unité d'organisation/périodes lorsqu'une notification est déclenchée. Ceci peut également être configuré comme un "synthèse collective". La stratégie d'envoi de ces notifications se trouve dans la propriété "sendStrategy" (stratégie d'envoi) de chaque notification de validation. Elle est définie par défaut sur SINGLE_NOTICIATION (NOTIFICATION UNIQUE). Ajustez ces valeurs à COLLECTIVE_SUMMARY (SYNTHÈSE COLLECTIVE) dans le fichier de métadonnées si vous souhaitez modifier cette stratégie avant l'importation du package.

NB: Note that you can also change this in maintenance for each validation rule notification at any time after they are imported as you may want to demonstrate or test both strategies to select one that is appropriate for your own setting.

Importation de métadonnées¶

Utilisez l’application DHIS2 Import/Export pour importer des packages de métadonnées. Nous vous recommandons d’utiliser la fonction « test » pour identifier les problèmes avant de tenter d’effectuer une importation réelle des métadonnées. Si le « test » signale des problèmes ou des conflits, consultez la section conflits lors de l’importation ci-dessous. Si aucune erreur n’est signalée lors de l’importation « test »/« validée », essayez d’importer les métadonnées. Si l’importation s’est déroulée sans erreur, vous pouvez passer à la configuration du module. Dans certains cas, les conflits ou les problèmes d’importation n’apparaissent pas pendant le test, mais durant l’importation réelle. Dans ce cas, le résumé de l’importation indiquera les erreurs à résoudre.

Gestion des conflits d'importation¶

REMARQUE

Si vous importez le package dans une nouvelle instance du système DHIS2, il n’y aura aucun conflit lors de l’importation, car ia base de données cible ne contient aucune métadonnée. Après avoir importé les métadonnées, passez à la section « Configuration ».

Différents types de conflit peuvent survenir, mais le plus courant est le fait que le nom, le nom abrégé et/ou le code des objets de métadonnées du package de configuration existent déjà dans la base de données cible. Il existe plusieurs solutions alternatives à ces problèmes, chacun avec ses avantages et ses inconvénients. La solution la plus appropriée dépend, par exemple, du type d’objet à l’origine du conflit.

Option 1¶

Renommez l'objet existant dans votre base de données DHIS2 pour lequel il existe un conflit. L'avantage de cette approche est qu'il n'est pas nécessaire de modifier le fichier .json, les changements étant effectués par l'interface utilisateur de DHIS2. Il est probable que cela soit moins sujet à des erreurs. Cela signifie également que le paquet de configuration est laissé tel quel, ce qui peut être un avantage, par exemple lorsque des mises à jour du package sont publiées. Les objets du package d'origine sont également souvent référencés dans le matériel de formation et la documentation.

Option 2¶

Renommez l'objet pour lequel il y a un conflit dans le fichier .json. L'avantage de cette approche est que les métadonnées DHIS2 existantes sont laissées telles quelles. Cela peut être un facteur lorsqu'il y a du matériel de formation ou de la documentation, comme les procédure normale d'exploitation des dictionnaires de données liés à l'objet en question, et cela n'implique aucun risque de confusion pour les utilisateurs lors de la modification des métadonnées qui leur sont familières.

Notez que pour les deux options 1 et 2, la modification peut être aussi simple que l'ajout d'un petit pré/post-fixe au nom, pour minimiser le risque de confusion.

Option 3¶

Une troisième approche, plus complexe, consiste à modifier le fichier .json pour réutiliser les métadonnées existantes. Par exemple, dans les cas où un ensemble d'options existe déjà pour un certain concept (par exemple "sexe"), cet ensemble d'options pourrait être supprimé du fichier .json et toutes les références à son UID remplacées par l'ensemble d'options correspondant existant déjà dans la base de données. Le grand avantage de cette méthode (qui n'est pas limitée aux seuls cas où il y a un conflit d'importation directe) est d'éviter de créer des métadonnées dupliquées dans la base de données. Il y a des aspects essentiels à prendre en compte lors de ce type de modification :

• il nécessite une connaissance approfondie de la structure détaillée des métadonnées du DHIS2
• Cette approche ne fonctionne pas pour tous les types d'objets. En particulier, certains types d'objets ont des dépendances compliquées à résoudre de cette manière, par exemple en ce qui concerne les désagrégations.
• il sera compliqué de procéder aux futures mises à jour du package de configuration.

Configuration¶

Une fois que toutes les métadonnées sont importées avec succès, des étapes doivent être mises en oeuvre avant que le module ne soit fonctionnel.

Partage¶

Tout d'abord, vous devrez utiliser la fonctionnalité Partage de DHIS2 pour configurer quels utilisateurs (groupes d'utilisateurs) doivent voir les métadonnées et les données associées au programme ainsi que qui peut enregistrer/saisir des données dans le programme. Par défaut, le partage a été configuré pour ce qui suit :

• Tableaux de bord
• Visualisations, cartes, rapports d’événement et tableaux de rapports
• Des ensembles de données
• Les options de catégorie

Veuillez consulter le site Documentation du DHIS2 pour plus d’informations sur le partage.

Trois groupes d'utilisateurs de base sont inclus dans le package :

• Accès SIM ( visualisation des métadonnées / visualisations les données)
• Admin SIM (visualisation et modification des métadonnées/aucun accès aux données)
• Alertes SIM (visualisation des métadonnées/capture et visualisation des données)

Les utilisateurs sont attribués au groupe d’utilisateurs approprié en fonction de leur rôle dans le système. Le partage des autres objets du package peut être ajusté en fonction de la configuration. Consultez le site Documentation sur le partage de DHIS2 pour plus d’informations.

Rôles des utilisateurs¶

Les utilisateurs auront besoin de rôles utilisateur pour pouvoir utiliser les différentes applications du DHIS2. Les rôles minimums suivants sont recommandés :

1. Analyse de données agrégées : Peut accéder aux tableaux de bord, au visualiseur de données, aux tableaux croisés dynamiques, aux rapports et aux cartes.
2. Saisie de données agrégées : peut accéder à l'application de saisie de données et ajouter/modifier les valeurs des données

Consultez le site Documentation de DHIS2 pour plus d’informations sur la configuration des rôles des utilisateurs.

Affectation aux unités d'organisation{ #organisation-unit-assignment }¶

Les ensembles de données doivent être affectés à des unités d'organisation dans la hiérarchie existante de sorte qu'ils soient accessibles au personnel chargé de la saisie et de l'analyse des données.

Création de tâches dans le planificateur¶

Vous devrez utiliser l'application de planification pour pouvoir bénéficier des composantes prédicteur et notification de validation du package. Vous aurez besoin d'au moins 3 tâches dans l'ordre suivant :

1. Prédicteur
2. Tableau analytique
3. Surveillance

Vous voudrez que chaque tâche soit terminée avant d'exécuter la suivante (par exemple, les prédicteurs doivent tous être créés avant le début de l'analyse ; la tâche de surveillance ne doit être lancée qu'après la fin de l'analyse). Chaque implémentation de DHIS2 devra revoir sa configuration pour déterminer le temps nécessaire à l'exécution de chacune de ces tâches et les programmer en conséquence. Il est recommandé de les exécuter tard dans la nuit, lorsqu'il n'y a pas beaucoup d'activité dans votre instance DHIS2, car il s'agit généralement d'opérations nécessitant beaucoup de ressources.

Quelques conseils pour chaque type de tâche :

Prédicteur¶

Predictor jobs consist of a relative start and end date. This means you can run your predictors for the most recent period to generate the latest data that you need. This should be useful if your previous data is not being changed, as the other predicted values will already be generated and stored (and thus this process will not necessarily need to occur once more for those already generated values that are still valid). This is a particularly resource heavy operation, and if your previous data is not routinely changing, generating data for the most recent period that you need data for is the recommended approach.

Vous pouvez également sélectionner des prédicteurs ou des groupes de prédicteurs spécifiques à exécuter pendant la tâche. Le groupe de prédicteurs pour ce package est simplement appelé SIM. Si vous sélectionnez plusieurs groupes, les prédicteurs seront exécutés dans l'ordre dans lequel les groupes sont sélectionnés. Pour en savoir plus, reportez-vous à la documentation DHIS2.

Cette tâche doit être la première de votre séquence et doit se terminer avant que la tâche suivante (analyse) ne commence.

Analytics table¶

La tâche du tableau analytique prend toutes les données brutes saisies et leur applique l'agrégation nécessaire en fonction de votre configuration. Si vous utilisez un système intégré avec plusieurs programmes dans votre instance, il est possible qu'une tâche du tableau analytique soit déjà programmée pour s'exécuter à intervalles réguliers. Si c'est le cas, vous devrez peut-être modifier la période d'exécution pour qu'elle puisse être exécutée après la fin de la tâche du prédicteur.

Cette tâche doit être la deuxième de votre séquence, et doit se terminer avant le début de la tâche suivante (surveillance).

Surveillance¶

À l'instar du prédicteur, la tâche de surveillance consiste également en une date relative de début et de fin. Si vos données ne changent pas au cours des périodes précédentes, vous pouvez exécuter la tâche de surveillance uniquement pour la période que vous devez examiner.

Vous pouvez spécifier des groupes de règles de validation pour la tâche de surveillance. Créez une tâche de surveillance qui s'exécute chaque semaine, en utilisant le groupe de règles de validation SIM - Hebdomadaire

Si vous voulez envoyer les notifications de validation, assurez-vous que l'élément "Envoyer les notifications" est sélectionné.

Sending out notifications¶

Par défaut, les notifications seront envoyées via l'application de messagerie du DHIS2.

Pour envoyer des notifications par SMS ou par e-mail, vous devez configurer une [passerelle SMS] (https://docs.dhis2.org/en/use/user-guides/dhis-core-version-master/maintaining-the-system/configure-sms.html#sms-configuration-gateways) et/ou une [configuration e-mail] (https://docs.dhis2.org/en/use/user-guides/dhis-core-version-master/configuring-the-system/system-settings.html#system_email_settings) dans votre instance DHIS2. Les paramètres nécessaires varient selon les implémentations et il est préférable de consulter les liens de documentation fournis ici pour plus d'informations.

Métadonnées dupliquées¶

NOTE

This section only applies if you are importing into a DHIS2 database in which there is already meta-data present. If you are working with a new DHIS2 instance, please skip this section and go to Adapting the program. If you are using any third party applications that rely on the current metadata, please take into account that this update could break them”

Même lorsque les métadonnées sont importées avec succès sans aucun conflit d'importation, il peut y avoir des doublons dans les métadonnées - éléments de données, attributs d'entités suivies ou ensembles d'options qui existent déjà. Comme indiqué dans la section ci-dessus sur la résolution des conflits, il est important de garder à l'esprit que les décisions relatives à la modification des métadonnées dans le DHIS2 doivent également tenir compte d'autres documents et ressources associés de différentes manières aux métadonnées existantes et aux métadonnées importées par le biais du package de configuration. La résolution des doublons ne consiste donc pas seulement à "nettoyer la base de données", mais aussi à s'assurer que cela est fait sans, par exemple, briser le potentiel d'intégration avec d'autres systèmes, la possibilité d'utiliser du matériel de formation, la rupture des SOP, etc. Cela dépend beaucoup du contexte.

Il est important de garder à l’esprit que le DHIS2 dispose d’outils pouvant dissimuler certaines des complexités des duplications potentielles dans les métadonnées. Par exemple, lorsqu’il existe des ensembles d’options en double, ils peuvent être masqués pour des groupes d’utilisateurs par le biais de Partage.

Adaptation du programme¶

Une fois le programme importé, il est possible que vous souhaitiez y apporter certaines modifications. Voici quelques exemples d'adaptations locales que vous pourrez effectuer :

• Ajout de variables supplémentaires au formulaire.
• Adaptation des noms des éléments de données en fonction des conventions en vigueur au niveau national.
• Ajout des traductions aux variables et/ou au formulaire de saisie des données.
• Modification des indicateurs en fonction des définitions de cas au niveau local
• Ajout de tableaux de bord/items de tableau de bord

Toutefois, il est fortement recommandé de faire preuve d'une grande prudence si vous décidez de modifier ou de supprimer l'un des formulaires/métadonnées inclus. Il y a donc un risque que des modifications brisent des fonctionnalités, par exemple les prédicteurs et les notifications.

Suppression des métadonnées¶

Pour maintenir votre instance propre et éviter les erreurs, il est recommandé de supprimer les métadonnées inutiles de votre instance. La suppression des métadonnées inutiles nécessite une connaissance avancée de DHIS2 et de ses différentes ressources.