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

Suivi en temps réel des campagnes de vaccination - Mise en œuvre¶

Ce chapitre se concentre sur les aspects des stratégies de mise en œuvre de DHIS2 et sur les décisions qui doivent généralement être prises par pays/par campagne pour s'adapter au contexte local. Le guide est destiné aux implémenteurs de DHIS2 afin qu'ils connaissent les stratégies de déploiement et les approches permettant de mettre en œuvre une campagne solide et adaptée à l'objectif visé avec DHIS2.

Sélection des modes de collecte des données¶

DHIS2 permet plusieurs modes de saisie des données, y compris un client natif DHIS2 Android, et peut prendre en charge des implémentations hybrides qui s'appuient sur une combinaison de rapports papier et électroniques adaptés aux cadres hors ligne.

Les éléments suivants doivent être pris en compte dans le plan de mise en œuvre :

Saisie de données en temps réel ou saisie de données secondaires/rétrospectives
Niveau de collecte des données primaires : quels utilisateurs collectent les données primaires, à l'aide de quels outils ?
Niveau de notification électronique : dans le cas d'une collecte de données primaires sur papier ou hybride, les implémenteurs doivent définir à quel niveau les données doivent être saisies dans le système en fonction de la faisabilité, du contexte et des exigences en matière d'analyse des données.
Connexion au site de vaccination et aux unités opérationnelles du sous-district
Modes de déclaration électronique
Web
DHIS2 Systèmes de saisie de données [mobiles] (https://docs.dhis2.org/en/implement/android-implementation/about-this-guide.html)Android
SMS, USSD et autres modes de transmission de données

Le principal avantage de cette flexibilité est qu'aucune solution d'interopérabilité n'est nécessaire - une fois les données saisies dans le système, DHIS2 devient un référentiel des données de la campagne. En outre, la possibilité de saisir les données hors ligne (éventuellement sur un appareil mobile) et de les synchroniser dans un second temps permet de saisir les données directement sur le terrain sans avoir à les noter au préalable sur papier.

Tracker¶

L'utilisation de DHIS2 Tracker pour le suivi en temps réel doit être examinée avec soin en fonction de la disponibilité de l'infrastructure (c'est-à-dire un hébergement robuste et extensible), de la connexion Internet au niveau des utilisateurs finaux et de la faisabilité de la formation du personnel chargé de la saisie des données pour collecter les données dans Tracker en temps réel. De nombreux pays ont été confrontés à d'importants problèmes de saisie de données dans le système Tracker au cours de la distribution du vaccin COVID-19, en raison de ressources limitées pour la saisie des données, d'une connectivité réseau limitée et d'autres problèmes fondamentaux. Si la saisie des données en temps réel n'est pas possible, le système DHIS2 Tracker peut également être mis en œuvre parallèlement à une solution de surveillance agrégée en temps réel, à condition qu'il y ait suffisamment de ressources pour la saisie des données secondaires.

Il est vivement recommandé d'examiner le guide de mise en œuvre de Tracker et de procéder à une évaluation rapide de l'état de préparation à Tracker afin de s'assurer que les éléments fondamentaux et les facilitateurs sont en place pour un déploiement réussi du Tracker.

Envoi de données par SMS et USSD¶

Le [Module SMS] (https://docs.dhis2.org/en/develop/developing-with-the-android-sdk/sms-module.html)peut être utilisé comme méthode de secours pour télécharger des données lorsqu'il n'y a pas de connexion internet. DHIS2 prend en charge la réception de données par SMS, mais le SMS doit être structuré selon une certaine syntaxe pour être interprété et introduit dans DHIS2. L'application Android DHIS2 agit comme une couche transparente pour envoyer les informations par SMS, l'utilisateur n'ayant pas à se préoccuper de l'écriture du SMS. Pour envoyer des SMS avec l'application Android, la passerelle SMS doit être correctement configurée.

Pour plus d'informations sur [la saisie de données par SMS et la configuration],(https://docs.dhis2.org/en/manage/performing-system-administration/dhis-core-version-master/using-gateways-for-sms-reporting.html) veuillez consulter les liens ci-dessous.

Autres outils mobiles de saisie de données¶

La collecte de données à l'aide d'applications et d'outils mobiles autres que DHIS2, tels que ODK et KoboToolbox, est possible, mais la solution nécessite la présence d'une équipe technique solide dans le pays afin de faciliter l'[interopérabilité] (https://docs.dhis2.org/en/implement/implementing-dhis2/integration-concepts.html)et de superviser la mise en place d'une solide gouvernance des métadonnées dans les deux systèmes afin de garantir la compatibilité des données collectées.

Tests d'infrastructure et de performance¶

Planification à l'échelle¶

Pour les campagnes à grande échelle et à volume élevé, il est généralement recommandé d'utiliser une instance DHIS2 dédiée pendant la campagne et d'intégrer les données clés de la campagne, telles que les taux de couverture, dans le système d'information sur les ménages après la triangulation et l'utilisation. Il s'agit de préserver la stabilité du HMIS de routine et d'éviter toute perturbation des rapports de routine, sachant que de nombreuses instances HMIS nationales agrégées sont hébergées sur place ou sur des serveurs locaux - souvent avec un seul serveur disponible.

L'infrastructure d'hébergement doit être planifiée dès les premières étapes. Lorsque les politiques nationales le permettent, il est fortement recommandé d'utiliser des ressources en nuage. L'hébergement dans le nuage permet généralement d'améliorer les performances et la modularité, car un réseau de serveurs physiques ou virtuels peut être utilisé. Des outils de surveillance des serveurs doivent être déployés pour garantir que les administrateurs de serveurs disposent en temps voulu d'informations précises sur les performances tout au long de la campagne et qu'ils peuvent procéder à des ajustements en réponse aux goulets d'étranglement qui peuvent se produire. Voir les [conseils techniques sur l'hébergement, l'administration et la surveillance des serveurs] (https://docs.dhis2.org/en/implement/tracker-implementation/tracker-performance-at-scale.html#server-hosting-administration-and-monitoring).

Questions d'orientation pour la planification des infrastructures :

Mode de saisie des données : saisie de données agrégées ou de données de suivi ?
Si Tracker est utilisé :
- Combien d'entités suivies attendez-vous ?
- Quel est le nombre d'attributs d'entité suivie que chaque entité suivie possède-t-elle ?
- Quel est le nombre d'inscriptions ?
- Quel est le nombre d'événements ?
Quel est le nombre d'unités d'organisation ?
Comment sont-elles réparties dans la hiérarchie (équilibrées ou avec un grand nombre de sous-unités dans certaines parties ?)
Quel est le nombre de niveaux ?
Les données sont-elles saisies à différents niveaux de l'UO, ou seulement au niveau le plus bas ?
Certaines UO sont-elles plus actives que d'autres ou l'activité est-elle répartie uniformément sur toutes ?
Quel est le nombre d'utilisateurs simultanés ?
Répartition des utilisateurs en fonction de leur fonction/rôle : par exemple, combien d'utilisateurs sont configurés avec des rôles leur permettant de saisir des données agrégées ou des données de suivi, combien d'utilisateurs sont configurés avec des rôles leur permettant uniquement d'accéder aux tableaux de bord/applications d'analyse ?
Tous les utilisateurs ont-ils accès à toutes les UO, ou existe-t-il des limitations ? Si oui, lesquelles ?
Quel est le nombre de valeurs de données attendues ?
Tracker ou agrégat ?

Exemple

DHIS2 EN UTILISATION:

La campagne de masse contre la rougeole au Bangladesh a dû prendre en charge et maintenir un total de 403 765 UO liées au microplan, des données de vaccination quotidiennes et un total de 16 000 ID d'utilisateur. Avec une telle ampleur, la campagne a fourni aux développeurs du noyau de DHIS2 un cas d'utilisation réel [scénario difficile permettant de tester les performances et les tests de résistance] (https://community.dhis2.org/t/bangladesh-is-the-first-country-to-use-dhis2-in-planning-implementing-and-monitoring-mr-campaign-in-largest-scale/42408) contre de grandes bases de données. Le résultat de ces évaluations s'est traduit par une amélioration significative de l'utilisation de la mémoire de l'API et des correctifs de performance sur le tracker (en combinaison avec les UO et l'accès des utilisateurs) en tant qu'impact secondaire en cascade des tests primaires sur l'agrégat.

Gestion de l' utilisateur¶

La planification de la manière dont le personnel impliqué dans l'AVS pourra accéder à l'information est également un aspect essentiel à évaluer lors de la phase de planification précédant la campagne, car cela reflétera également les rôles et les responsabilités pendant et après les activités.

Tous les packages mondiaux sont publiés avec certains utilisateurs principaux - administrateurs, collecteurs de données et contrôleurs de données. Ces [utilisateurs et leurs rôles] (https://docs.dhis2.org/en/implement/maintenance-and-use/users-and-user-roles.html)peuvent être conservés et adaptés au contexte local ou être complètement modifiés en fonction du type de mise en œuvre et de la répartition de la charge de travail.

Le contrôle d'accès décentralisé et la gestion des utilisateurs sont essentiels au fonctionnement d'un système d'information. Déjà avec les données de routine du HMIS, les utilisateurs des districts peuvent voir leurs comptes gérés et leur accès limité à leur district. Il est donc essentiel de souligner que, en particulier pendant les campagnes de vaccination, lorsque la tentation est grande de prendre des raccourcis et de partager les utilisateurs entre différentes personnes et différents postes ou d'avoir un seul utilisateur par niveau hiérarchique supérieur avec une série de rôles, la principale recommandation serait d'attribuer un seul rôle par poste/personne, ou un ensemble fixe de rôles par poste. Cela signifie qu'il n'y a pas de partage d'utilisateurs et que les rôles sont très spécifiques en fonction du type de travail dans les données et le flux de travail de la campagne. Cette approche est très importante pour aligner la configuration de l'AVS dans le système sur les lois/réglementations nationales relatives au stockage, à la protection et à la sécurité des données dans le pays. En outre, cela pourrait également être un outil précieux pour maintenir une bonne supervision des agents de santé et des commis à la saisie des données et contrôler la qualité des performances et des données au fil du temps.

Si l'institution adéquate des utilisateurs et de leurs rôles est essentielle au bon fonctionnement et à la supervision du déroulement de la campagne, il peut y avoir des problèmes de confidentialité des données car de multiples parties prenantes peuvent avoir accès à des données numérisées qui peuvent donc être facilement partagées. Cette préoccupation est particulièrement importante lorsqu'un tracker est mis en œuvre, bien que les réglementations et les lois locales doivent être appliquées à la fois pour les données agrégées et les données individuelles.

Les [lignes directrices de DHIS2 sur les aspects liés à la sécurité] (https://docs.dhis2.org/en/implement/implementing-dhis2/security-considerations.html)fournissent une série de conseils contextuels et de mesures pragmatiques qui peuvent être mises en œuvre et contrôlées pour la gestion de la sécurité.

Test d'acceptation par l'utilisateur¶

Il est recommandé d'effectuer un test d'acceptation par l'utilisateur (UAT) avec un échantillon restreint mais représentatif d'utilisateurs finaux avant la formation des utilisateurs afin d'optimiser la convivialité de la configuration. Les implémenteurs, les testeurs et les concepteurs doivent mapper chaque flux de travail de l'utilisateur final et tester la configuration en interne avant le test d'acceptation par l'utilisateur. L'UAT peut comprendre :

L'observation des utilisateurs qui parcourent le flux de travail étape par étape
L'enregistrement du temps nécessaire à la réalisation du flux de travail, ainsi que la prise en compte de toute étape inutile, de tout retard ou de toute erreur constatée au cours du processus de saisie des données.
la documentation du processus et sa répétition avec un échantillon d'utilisateurs de chaque groupe d'utilisateurs (c'est-à-dire le test de chaque flux de travail de l'utilisateur final)
Le test à nouveau des flux de travail après l'optimisation de la configuration