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

Santé animale - Conception de la surveillance basée sur les événements¶

Introduction¶

Selon les estimations, 60 % des maladies infectieuses émergentes trouvent leur origine chez les animaux, qu'ils soient domestiques ou sauvages ([OMS, 2023] (https://www.who.int/news-room/fact-sheets/detail/one-health)). Le risque élevé de propagation des zoonoses aux populations humaines exige une collaboration, une communication et une coordination étroites entre les secteurs de la santé animale et de la santé publique. Alors que des investissements et des ressources considérables ont aidé les agences de santé publique et les ministères de la santé des pays à renforcer les systèmes de surveillance pour les humains, les ressources disponibles pour améliorer la surveillance de la santé animale restent beaucoup plus limitées.

Le Kit de DHIS2 sur la Santé Animale est conçu afin d'être mis en œuvre par les Ministères de l'Agriculture et de l'Élevage pour améliorer la surveillance systématique des populations animales, grâce au soutien catalytique du CDC's Center for Global Health (Centre pour la Santé Mondiale). Ce document décrit un programme tracker DHIS2 pour la surveillance basée sur les événements de santé animale. Le programme tracker de la santé animale est basé sur la conception du [système EMPRES-i de la FAO] (https://EMPRES-i.apps.fao.org/) pour la notification et l'alerte précoce au niveau mondial. Les métadonnées publiées dans le cadre de cette boîte à outils sont alignées sur les métadonnées recommandées par la FAO pour les systèmes d'alerte précoce afin de faciliter l'interopérabilité entre DHIS2, EMPRES-i et d'autres systèmes. Le système DHIS2 pour la santé animale peut fonctionner comme une plateforme de surveillance indépendante pour les ministères de l'élevage et les acteurs qui travaillent dans le domaine de la santé vétérinaire et animale ; ou il peut être intégré dans une plateforme DHIS2 avec les données de surveillance de la santé publique pour améliorer le partage des données pour les maladies zoonotiques.

L'approche One Health, qui reconnaît que la santé des humains, des animaux, des plantes et de l'environnement au sens large est étroitement liée et interdépendante, met l'accent sur la collaboration intersectorielle à tous les niveaux pour protéger nos écosystèmes et relever les défis sanitaires tels que l'émergence de maladies infectieuses, la résistance aux antimicrobiens et la sécurité alimentaire (OMS). La boîte à outils sur la santé animale s'appuie sur les leçons tirées de plus d'une décennie de mise en œuvre de systèmes de surveillance de la santé publique dans DHIS2 avec plus de 40 ministères de la santé et vise à faire progresser les approches collaboratives et intersectorielles afin d'améliorer la santé pour tous. Ces efforts s'inscrivent dans le [cadre de la surveillance collaborative] de l'OMS (https://www.who.int/publications/i/item/9789240074064), qui vise à renforcer l'architecture mondiale de la préparation, de la riposte et de la résilience aux situations d'urgence sanitaire (HEPR).

Remarque:

Pour plus d'informations sur les cas d'utilisation de DHIS2 par One Health, visitez notre page web: dhis2.org/one-health

Remerciements¶

La boîte à outils de DHIS2 pour la santé animale a été financée par les CDC dans le cadre de l'initiative OneHealth. Le centre HISP remercie les CDC, l'Organisation des Nations unies pour l'alimentation et l'agriculture (FAO), l'Organisation mondiale de la santé animale (OMSA) et l'Organisation mondiale de la santé (OMS) pour leur expertise technique et leurs conseils dans le cadre de l'élaboration de cette boîte à outils.

Conception du système¶

Architecture¶

La boîte à outils de DHIS2 pour la santé animale est conçue pour :

Permettre l'utilisation de DHIS2 aux niveaux national, infranational et communautaire en tant que plateforme électronique pour la surveillance de routine de la santé animale et des éventuels événements sanitaires liés aux populations animales
Faciliter la notification d'éventuelles maladies animales et d'événements liés à la santé animale et permettre aux autorités d'examiner et de vérifier les événements signalés par la communauté et d'autres sources
Relier les résultats de laboratoire et les mesures d'intervention aux événements de santé animale signalés, le cas échéant et si possible
Permettre aux vétérinaires et aux épidémiologistes d'accéder aux informations relatives aux événements de santé animale afin d'analyser, d'évaluer et de mettre en place des mesures de réponse ou des notifications aux agences mondiales, le cas échéant
Faciliter l'échange d'informations sur la santé animale avec le secteur de la santé publique (et vice versa) afin d'améliorer la coopération en matière de détection des menaces liées aux zoonoses

Sur la base de l'analyse paysagère des systèmes nationaux existants pour One Health et la santé animale, il existe de multiples scénarios pour la mise en œuvre de DHIS2 afin de soutenir les fonctions de surveillance de la santé animale. La boîte à outils pour la santé animale est flexible et adaptable en fonction de l'architecture et des systèmes nationaux existants.

Exemple d'architecture pour les systèmes de One Health

Cas d'utilisation¶

Systèmes d'alerte précoce pour la santé animale¶

Ce document de conception se concentre spécifiquement sur l'utilisation de DHIS2 pour signaler et rassembler les informations relatives aux menaces sur la santé animale. Ces données peuvent ensuite être partagées en amont avec d'autres systèmes, tels que les plateformes nationales One Health, le système EMPRES-i de la FAO pour l'alerte précoce, ou l'envoi de données clés aux systèmes de surveillance DHIS2 gérés par le ministère de la santé afin d'alerter le personnel de santé publique sur d'éventuelles menaces de zoonoses.

Alerte précoce en matière de santé animale

Le programme tracker de DHIS2 présenté ici est conçu pour soutenir l'alerte précoce et emprunte les principes des approches de surveillance basées sur les événements. La surveillance basée sur les événements vise à détecter les événements inhabituels, les maladies, les décès ou d'autres événements qui pourraient signaler une éventuelle flambée [CDC] (https://www.cdc.gov/globalhealth/healthprotection/gddopscenter/event-based-surveillance.html).

La surveillance basée sur les événements peut intégrer de nombreux types de sources, y compris des données publiques et non structurées. Dans ce cas d'utilisation, nous mettons principalement l'accent sur l'utilisation de DHIS2 pour :

Les rapports à base communautaires d'information sur un éventuel événement de santé publique sont signalés par des personnes de la communauté à travers une ligne téléphonique ou un autre système de messagerie, par exemple par des agriculteurs, des agents de santé communautaires, des membres de la communauté, des para-vétérinaires, etc.
Les établissements de santé : ils signalent des événements inhabituels ou inattendus concernant des patients qui se présentent dans les établissements, ou des groupes de pathologies inhabituelles.
Les vétérinaires, les travailleurs agricoles et les éleveurs qui ont des contacts fréquents avec les animaux domestiques et parfois sauvages.

Ces « événements » peuvent inclure des signaux, tels que ceux signalés par la communauté, qui sont vérifiés par un personnel de surveillance qualifié. Par exemple, un agriculteur peut signaler la présence inhabituelle d'un groupe d'animaux morts, ce qui incite les autorités sanitaires locales à vérifier et à enquêter sur l'existence d'une éventuelle menace pour la santé. Les rapports des vétérinaires, des membres de la communauté, des travailleurs agricoles et des éleveurs sont particulièrement importants pour détecter les événements susceptibles d'entraîner la propagation de zoonoses.

Personas ( les Utilisateurs du Système)¶

La conception du système de surveillance de la santé animale vise à répondre aux besoins des utilisateurs finaux à tous les niveaux du système de santé animale, y compris les responsables de la mise en œuvre et de la gestion de plateformes intégrées telles que One Health. Ces utilisateurs peuvent être:

Les responsables de la surveillance de la santé animale (au niveau national et sous-national) : il s'agit des utilisateurs de données chargés de la collecte des données, de l'analyse de routine des données, de l'utilisation des données pour améliorer les opérations et les stratégies du programme, et de la fourniture d'un retour d'information fondé sur les données au personnel du programme
Les Gestionnaires de données de surveillance de la santé animale: il s'agit des utilisateurs chargés de superviser la collecte, la gestion et la qualité des données, ainsi que les fonctions d'analyse et d'établissement de rapport pour le département national de surveillance de la santé animale.
Les Administrateurs de système: Il s'agit de l'équipe centrale de DHIS2 chargée de maintenir et d'améliorer les systèmes de données pour les programmes de santé animale, d'intégrer les flux de données collectées avec des outils distincts tels qu'EMPRES-i dans les plateformes nationales, de fournir un soutien technique pour la conception du système, l'adaptation et le soutien aux utilisateurs finaux, et de maintenir le système DHIS2 à long terme.
Les Utilisateurs de la plateforme intersectorielle: Il s'agit des utilisateurs issus de différents domaines, tels que la santé humaine et l'environnement, qui peuvent avoir besoin d'accéder aux données de surveillance de la santé animale à des fins d'analyse intersectorielle dans le cadre de l'approche de One Health
Les Partenaires de mise en œuvre: Il s'agit des organisations qui fournissent une assistance technique à la plateforme nationale de surveillance de la santé animale, ils collectent et analysent des données pour le compte de la stratégie nationale globale et peuvent être chargés de l'exploitation des réseaux de prestation de services.

Principaux éléments & Fonctionnalités¶

Le système de surveillance de la santé animale de DHIS2 est composé de deux éléments principaux :

Un programme tracker: un programme tracker de DHIS2 a été configuré pour la collecte de données au niveau de l'événement sur la base des variables de données d'alerte précoce saisies par le système [EMPRES-i] de la FAO (https://EMPRES-i.apps.fao.org).
**Un tableau de bord : ** un tableau de bord standard avec des cartes et des graphiques pour visualiser la distribution et la fréquence des différents types d'événements de santé animale signalés, ainsi que les types d'animaux affectés, les maladies confirmées et d'autres données.

Le programme tracker de DHIS2 fournit une structure de base pour la saisie des données clés conformément aux recommandations mondiales. Il peut prendre en charge la notification directe de la surveillance de la santé animale dans DHIS2, par exemple par les agents de santé communautaires et les vétérinaires qui utilisent des applications mobiles. Par ailleurs, la structure du programme tracker peut être utilisée pour rassembler simplement les données collectées dans d'autres systèmes afin d'en améliorer l'accessibilité et l'analyse. Le programme tracker standard peut être adapté aux flux de travail locaux en fonction du niveau de saisie des données, des types d'utilisateurs et des niveaux de vérification ou d'approbation des données.

Des fonctionnalités supplémentaires de DHIS2 peuvent encore améliorer l'utilisation du système. Il s'agit notamment de :

L'application Android de DHIS2 pour la collecte mobile de données, y compris la collecte de données hors ligne sur le terrain ou par les agents communautaires.
Les notifications paramétrables : les notifications peuvent être configurées en fonction de certaines conditions pour envoyer automatiquement des messages et des alertes aux utilisateurs. Elles peuvent être envoyées par courrier électronique, par le widget de messages DHIS2 ou par SMS lorsque la passerelle SMS DHIS2 est configurée. Par exemple, un cas confirmé de zoonose dans les populations animales peut déclencher l'envoi d'un message au personnel de surveillance de la santé publique au niveau du district afin d'alerter les établissements locaux et de lancer une enquête conjointe.
Les flux de travail configurables : selon que le programme Tracker de DHIS2 est utilisé à un niveau centralisé (saisie des données au niveau national ou du district) ou dans un flux de travail décentralisé (comme les agents communautaires qui envoient des signaux/rapports initiaux qui sont triés et vérifiés par le personnel de surveillance et étudiés par les équipes de surveillance), les pays peuvent réorganiser l'ordre des étapes du programme et des variables de données, et attribuer différents accès aux individus ou groupes d'utilisateurs pour la visualisation et l'édition des données.

Interopérabilité et échange de données¶

En tant que plateforme robuste d'interopérabilité dotée d'une API REST bien documentée, le système DHIS2 facilite l'établissement de rapports ascendants à partir de DHIS2 vers des bases de données mondiales telles que EMPRES-i ou le système WAHIS de l'OMSA. Par ailleurs, DHIS2 peut être utilisé simplement pour recevoir et stocker des données de surveillance de la santé animale en tant que référentiel à partir d'autres outils de collecte de données existants. Cette capacité permet à DHIS2 de rassembler des données provenant des secteurs de la santé animale et de la santé publique (et au-delà !) afin d'améliorer la prévention et la détection précoce des débordements et des maladies zoonotiques.

Tracker¶

La structure du programme tracker est la suivante, privilégier la simplicité en ce qui concerne le nombre d'étapes du programme. Ces étapes peuvent être adaptées en fonction des flux de travail des pays.

Étape	Description
Inscription	L'étape de l'inscription permet de recueillir les informations de base relatives à l'événement sanitaire signalé, telles que l'identifiant de l'événement, la date d'observation, le nom et les coordonnées de l'agriculteur concerné et le lieu de l'événement. Le type d'entité suivie pour le programme de santé animale est "événement sanitaire". L'étape n'est pas répétable : un signal ou un événement est censé être signalé une fois et suivi dans le temps. Tout événement subséquent sera considéré comme sa propre TEI dans DHIS2.
Épidémiologie	L'étape est générée automatiquement après l'inscription par la collecte d'informations clés sur la situation épidémiologique de l'événement, telles que les caractéristiques des animaux et le nombre relatif d'animaux affectés, les signes cliniques et les lésions nécrosiques, le type de surveillance et la source de l'infection L'étape est répétable
Diagnostic	L'étape recueille des informations relatives au diagnostic, au type, à l'état et à la classification de la maladie. L'étape est répétable
Laboratoire	Cette étape permet de collecter des informations sur le laboratoire qui analyse l'échantillon, l'identification de l'échantillon et les détails du test. Un identifiant de laboratoire unique est inclus dans cette étape pour permettre de relier les échantillons et les résultats. Cette étape est répétable car plusieurs échantillons peuvent être prélevés et plusieurs tests et résultats de laboratoire peuvent être disponibles pour un échantillon donné.
Mesures et traitement	Cette étape permet de collecter des informations sur le traitement fourni lors de l'événement sanitaire et sur les mesures de contrôle mises en œuvre. Cette étape n'est pas répétable car elle est destinée à inclure toutes les mesures d'intervention mises en œuvre pour l'événement de la santé animale.

TrackedEntityType (Type d'entité suivie)¶

Le programme tracker de surveillance de la santé animale de DHIS2 permet l'enregistrement d'un type d'entité suivie (TET) "Événement de santé". Cette conceptualisation est basée sur la définition des CDC et sur le flux général du système de dépistage précoce. Dans ce contexte, un événement est une manifestation de la maladie ou un événement qui crée un risque de maladie, qui peut être d'origine infectieuse, zoonotique, alimentaire, chimique, radiologique ou nucléaire et qui peut être transmis par des personnes, des vecteurs, des animaux, des biens ou par l'environnement CDC.

La définition de ce qui constitue un "Événement Sanitaire" ou la détermination d'une terminologie plus appropriée doit être décidée au niveau national avec les parties prenantes. La terminologie utilisée ici se veut aussi générique que possible, mais dans la pratique, elle peut donner lieu à différentes interprétations, telles qu'une unité géographique délimitée ou un groupe d'individus (humains ou animaux) qui sont tous affectés par le même agent pathogène ou qui présentent les mêmes caractéristiques syndromiques.

Inscription¶

Lorsqu'un nouvel "événement" possible de santé animale est enregistré dans le programme de santé animale en tant qu'Instance d'Entité Suivie ( TEI ), les Attributs d'Entité Suivie ( TEA ) sont enregistrés pour former le profil de l'événement.

La date d'inscription est considérée comme la « date de déclaration », c'est-à-dire la date à laquelle le signal ou l'événement a été initialement déclaré (par exemple par un membre de la communauté, un vétérinaire, un agriculteur ou une autre autorité).

L'attribut ID de l'événement est un identifiant unique généré automatiquement à l'aide de la syntaxe textPattern SEQUENTIAL(#######) et doit être personnalisé avant la mise en œuvre en fonction du contexte local. L'ID de l'événement est configuré de manière à permettre aux utilisateurs de rechercher un événement qui a été déclaré et qui est généré automatiquement. L'identifiant unique généré par le système permet de suivre l'événement tout au long de l'enquête, des données de laboratoire, de la riposte, etc.

L'attribut date d'observation fait référence à la date à laquelle l'événement sanitaire s'est produit et peut être utilisé pour contrôler la qualité du système de surveillance par rapport à la TEA "Date de déclaration".

L'attribut Commentaire général est utilisé pour collecter des informations descriptives et non structurées sur l'événement. Ces informations peuvent fournir un contexte essentiel aux épidémiologistes vétérinaires, aux chargés de surveillance et à d'autres experts pour trier et vérifier le signal en vue d'un examen plus approfondi.

Étape 1 : Épidémiologie [répétable]¶

Cette étape est générée automatiquement lors de l'enregistrement du rapport d'événement initial (par exemple, lorsqu'un événement de surveillance animale a été initialement signalé par un membre de la communauté, un vétérinaire, un agriculteur ou un autre utilisateur). Cette étape permet d'enregistrer des informations épidémiologiques de base sur l'événement relatif à la santé animale.

Remarque:

L'étape est répétable car il est prévu que l'utilisateur remplisse ce formulaire pour chaque espèce animale affectée. Par exemple, si un agriculteur constate une série inhabituelle de décès de porcs et de poulets dans sa ferme, le formulaire doit être rempli pour chaque espèce animale.**

Épidémiologie¶

Dans les sections, des informations épidémiologiques qualitatives et quantitatives de base sont collectées sur l'espèce animale, la quantité d'animaux concernés et le système de production.

Les options de l'élément de données Espèce animale sont remplies par des Groupes d'Options. Un ensemble de règles de programme basées sur la valeur sélectionnée dans l'élément de données Classe d'animaux réduit la liste des options sur la base d'une relation hiérarchique entre la classe d'animaux et l'espèce animale.

Il convient de noter que dans ce cas d'utilisation, le Système de Production Un englobe diverses pratiques d'élevage et de gestion des animaux basées sur les environnements et les objectifs spécifiques pour lesquels les animaux sont détenus. Ces catégories reflètent les divers contextes d'élevage, allant des petites structures informelles aux structures spécialisées. Il ne s'agit pas du système de production au sens des systèmes d'information.

L'élément de données Système de Production Deux catégorise la production animale sur la base des objectifs principaux et des caractéristiques opérationnelles associés aux différents types d'élevage. Ce système se concentre sur les objectifs de production spécifiques, tels que la production de viande, d'œufs ou de laine, ainsi que sur les différentes pratiques de marché et de gestion impliquées.

Signes cliniques et lésions nécrosiques¶

Plusieurs signes cliniques et lésions nécrosiques peuvent être saisis ici. Par défaut, le programme est conçu pour saisir jusqu'à cinq (5) signes/lésions ; la possibilité d'en ajouter d'autres nécessitera un ensemble d'éléments de données et de règles de programme supplémentaires.

Chaque groupe de cinq éléments de données (pour les signes cliniques et les lésions nécrosiques, respectivement) partage un ensemble d'options commun.

Surveillance et source d'infection¶

Cette section du programme indique le type de surveillance effectué et les sources d'infection.

Plusieurs sources possibles d'infection peuvent être saisies ici ; cinq d'entre elles ont été préconfigurées et d'autres peuvent être ajoutées à l'aide d'une série d'éléments de données supplémentaires et de règles de programme.

Commentaires¶

Dans cette section de l'étape du programme, les utilisateurs peuvent ajouter du texte libre pour fournir des commentaires supplémentaires et des informations contextuelles. Cette fonction est particulièrement utile pour la surveillance basée sur les événements, lorsqu'un événement inhabituel est détecté et que les autorités locales ont besoin d'informations qualitatives pour vérifier que le signal est bien un événement.

Étape 2 : Diagnostic [répétable]¶

Au cours de cette étape, les principales informations - le type de diagnostic, l'état de base et le type de maladie - sont collectées. Cette étape est répétable car les experts vétérinaires recommandent qu'il y ait un diagnostic principal et plusieurs diagnostics différentiels. Le type de diagnostic (principal ou différentiel) est spécifié dans l'élément de données Type de diagnostic.

Grâce à un ensemble de règles de programme et à un élément de données masqué, et une fois que l'option Diagnostic principal est sélectionnée pour l'élément de données Type de diagnostic dans un événement, l'unique option disponible dans les sélections subséquentes sera Diagnostic différentiel. Cela permet d'éviter que l'utilisateur ne saisisse accidentellement plus d'un diagnostic principal pour un événement de santé donné (inscription au DHIS2).

Lorsque le diagnostic principal a déjà été sélectionné, seul le diagnostic différentiel reste disponible.

Dans le cas où une confirmation de laboratoire est disponible, l'utilisateur devra mettre à jour le Statut du diagnostic une fois qu'il aura reçu le résultat du laboratoire qui confirmera ou non le diagnostic suspecté.

Le Sous-type de la maladie n'est visible que pour un ensemble spécifique de maladies et les options sont remplies par des groupes d'options et un ensemble de règles de programme basées sur le sous-type sélectionné.

Étape 3 : Données de laboratoire [répétable]¶

La date de l'événement de l'étape du programme est conceptualisée comme la « date de déclaration », qui indique la date à laquelle les données de laboratoire ont été saisies. Cette étape du programme est configurée comme étant répétable afin de permettre l'ajout de plusieurs tests et résultats de laboratoire à l'enregistrement. L'inclusion d'un élément de données Identifiant de l'échantillon permet de lier plusieurs tests ou résultats à un échantillon donné.

Informations sur le laboratoire¶

L'élément de données Laboratoire contient un ensemble d'options rassemblées par la FAO dans son système Empres-i. Il contient des laboratoires nationaux de référence ainsi que des laboratoires internationaux. Les pays peuvent avoir besoin de mettre à jour cet ensemble d'options pour inclure les laboratoires appropriés disponibles dans leur pays pour les tests. Ce champ permet aux utilisateurs, en particulier au niveau national, de savoir quel laboratoire analyse et fournit des résultats sur l'échantillon.

Identification de l'échantillon¶

Informations sur l'ID, la maladie et l'espèce affectée de l'échantillon. L'identification de l'échantillon est fondamentale pour la bonne gestion des données et l'association échantillon-événement, et la variable sélectionnée pour la maladie et l'espèce affectée doit coïncider avec celles sélectionnées aux étapes Épidémiologie et Diagnostic.

Détails de l'échantillon et du test¶

Cette section recueille des informations sur le test, la date d'échantillonnage et le résultat. Ces informations peuvent être communiquées par le laboratoire lui-même ou par un agent de surveillance ou une autre personne compétente au niveau national. Des éléments de données de type "date" sont disponibles pour saisir la date de prélèvement et la date de résultat (lorsque les résultats du laboratoire ont été mis à disposition), ce qui permettra d'effectuer des analyses temporelles supplémentaires, telles que le temps écoulé entre la déclaration d'un événement et la disponibilité d'un résultat de laboratoire.

Étape 4 : Mesures de contrôle et de traitement [non répétable]¶

L'étape des mesures de contrôle et du traitement n'est pas répétable car toutes les actions entreprises sont destinées à être enregistrées après la riposte à l'événement sanitaire (inscription au DHIS2). Ceci peut être adapté en fonction du contexte local si les données sur les différents types de mesures de contrôle sont saisies en temps réel.

Plusieurs sources possibles de Mesures de contrôle et de Traitements peuvent être saisies ici. Tout comme les éléments de données Signes cliniques, ceux-ci sont représentés par cinq éléments de données clonés qui partagent le même ensemble d'options. Des éléments de données et des règles de programme supplémentaires peuvent être ajoutés si nécessaire.

Éléments de données¶

Tous les éléments de données configurés pour le Tracker sont également intégrés dans le groupe d'éléments de données "Surveillance Animale [iMNcm8NLZSJ]. Ce groupe sert de dictionnaire de données DHIS2 pour le cas d'utilisation du suivi de la Surveillance des Animaux. Il permet d'exporter les éléments de données de DHIS2 et de les utiliser indépendamment de la configuration du programme Tracker, par exemple dans le cas où une implémentation reconçoit son Tracker à partir de zéro pour les flux de travail locaux et souhaite toujours utiliser les métadonnées conformes aux variables de données recommandées par la FAO.

Attention:

Les éléments de données configurés pour ce package sont conformes à la version d'EMPRES-i datant du 28 février 2024. Le dictionnaire de données et les métadonnées d'EMPRES-i peuvent évoluer dans le temps, ce qui nécessite des mises à jour, une maintenance ou un nouveau mapping pour les pays qui mettent en œuvre des solutions d'échange de données.

Éléments de données clonés pour la sélection d'options multiples¶

Dans les étapes du programme qui concernent l' "Épidémiologie" et les "Mesures et traitements", un certain nombre d'éléments de données sont clonés afin de rendre possible la sélection de plusieurs options pour un concept donné, lesquelles options appartiennent à un même ensemble d'options. Cette conception est implémentée comme suit :

Clonage des éléments de données éligibles pour un choix multi-options
Le nombre de clones de l'élément de données doit être le même que le nombre d'options présentes dans l'ensemble d'options correspondant
Chaque élément de données cloné a son propre UID, son propre nom et son propre code
Règles de programme
Masquer les Éléments de Données conséquents si les précédents n'ont pas été sélectionnés
Afficher une erreur si la même Option a été sélectionnée plus d'une fois dans le même groupe des Eléments de Données

Analyse¶

Un [tableau de bord] de surveillance des animaux (https://demos.dhis2.org/hmis/dhis-web-dashboard/#/FHh9NTsTjQY) a été développé sur la base de l'expérience acquise dans le cadre de la mise en œuvre dans les pays et des rapports utilisés par les acteurs internationaux tels que la FAO et le OMSA. Les tableaux de bord sont principalement représentés à l'aide d'indicateurs de programme, qui ont été configurés pour agréger les chiffres basés sur les conditions enregistrées dans le programme tracker.

Résumé des événements, cas et décès signalés par période et répartition géographique¶

Listes de lignes et classification des animaux¶

Diagnostics et cas confirmés¶

Résultats des tests de laboratoire, type, mesures de contrôle et traitements¶

Groupes d'utilisateurs¶

Les groupes d'utilisateurs suivants sont inclus dans le fichier téléchargeable des metadonnées

Groupe d'utilisateurs	Les métadonnées :	Les données :
AH_EBS - Administrateur	Lecture et saisie	Aucun accès
AH_EBS - Accès	Lecture seule	Lecture seule
AH_EBS - Saisie des données	Lecture seule	Peut saisir et visualiser

Notifications¶

La détection précoce et la riposte aux maladies zoonotiques peuvent être améliorées à travers le partage des données de surveillance pertinentes entre les secteurs de la santé animale et de la santé publique. Comment DHIS2 peut-il déclencher et générer des alertes en fonction de la nature, du moment et du lieu d'un éventuel événement sanitaire ? Dans cette section, nous décrivons comment configurer et utiliser les fonctionnalités de base de DHIS2 afin d'améliorer le partage d'informations entre ces secteurs.

Les fonctions de notification de DHIS2 permettent d'automatiser les alertes et le partage d'informations à partir de DHIS2 en fonction de conditions ou de règles préconfigurées. Ces fonctions vous permettent de :

Configurer des conditions et des expressions pour déclencher une notification ou une communication sortante en se basant sur quoi, quand et où : les notifications peuvent être générées sur la base d'une combinaison de facteurs tels que les données agrégées ou les données du domaine de suivi, le niveau géographique (niveau de l'unité d'organisation), les groupes d'utilisateurs, la période de temps, les variables fixes et d'autres éléments.
Affecter des utilisateurs ou des groupes d'utilisateurs à différents niveaux administratifs pour recevoir des notifications en fonction des conditions et des règles définies.
Personnaliser les modèles de messages avec des paramètres fixes et variables pour fournir des informations concises et des actions recommandées aux destinataires ciblés en fonction du type d'événement sanitaire survenu, du moment et du lieu.
Automatiser l'envoi de notifications du système à des groupes d'utilisateurs définis
Mettre en place des mécanismes de partage de la notification, par exemple par courrier électronique ou SMS ou par interopérabilité avec d'autres outils tels que Rapid Pro

Figure : interactions entre les systèmes de surveillance intersectoriels pour la zoonoses

Cas d'utilisation¶

Dans le contexte de One Health et du partage des données de surveillance et d'alerte précoce entre les secteurs de la santé animale et de la santé publique, la mise en place des notifications dans DHIS2 dépend de la manière dont DHIS2 est utilisé dans le contexte national, de la personne qui gère le système (par exemple, le ministère de la santé, le ministère de l'élevage, le bureau One Health), des données saisies et des protocoles mis en place pour les notifications et le partage d'informations intersectorielles. Nous présentons ici trois exemples illustrant la manière dont DHIS2 est utilisé dans le pays :

Cas d'utilisation A : DHIS2 est utilisé pour les données de surveillance de la santé publique (telles que le eIDSR). Des alertes et des notifications peuvent être déclenchées depuis le secteur de la santé publique vers des utilisateurs ou des acteurs du secteur de la santé animale. Exemple : si un seuil de cas suspects de rage chez l'homme est dépassé, une notification peut être envoyée au vétérinaire du district ; un hôpital signale un cas suspect d'anthrax qui est ensuite confirmé par le laboratoire et qui doit être notifié au bureau national de One Health .

Pour le cas d'utilisation relatif à la surveillance de la santé publique, veuillez consulter la documentation sur l'intégration des alertes et des notifications d'épidémies :

Cas d'utilisation B : DHIS2 est utilisé comme système d'alerte précoce pour la santé animale (comme dans le guide de conception de la santé animale). Les alertes et les notifications peuvent être déclenchées du secteur de la santé animale vers le secteur de la santé publique. Exemple : une épidémie de brucellose a été détecté dans une population bovine voisine ; les agents de santé des établissements de santé voisins reçoivent une notification afin d'être plus vigilants dans le dépistage des symptômes chez les patients.

Cas d'utilisation C : DHIS2 est utilisé comme une surveillance intégrée basée sur les événements (EBS) ou une plate-forme de gestion des événements. Les alertes et les notifications peuvent être analysées sur la base des données saisies et redirigées pour le tri et la vérification des signaux. Exemple : un ASC signale un groupe inhabituel de vaches mortes près de son village à l'aide de l'application mobile DHIS2, ce qui déclenche une alerte auprès du vétérinaire ; un ASC signale des morsures de chien provenant d'un animal présumé enragé et une alerte est envoyée à la fois aux établissements de santé voisins et au vétérinaire du district.

Flux de travail de la configuration¶

Dans cette section, nous fournissons des exemples pratiques et un flux de travail pour personnaliser les notifications dans DHIS2 pour le cas d'utilisation du partage des données de DHIS2 avec les acteurs des secteurs de la santé animale et de la santé publique. Ces fonctionnalités vous permettent de définir quelles informations partager avec quels types d'acteurs, dans quelles conditions et comment les informations doivent être diffusées.

Pour les données de suivi, la fonction notifications de programme est utilisée. Pour les données agrégées, les notifications de règles de validation sont utilisées.

Nous recommandons aux chargés de la mise en œuvre de tenir compte des éléments ci-après avant de suivre les étapes qui suivent pour définir et configurer les notifications dans DHIS2 en fonction du contexte local :

Définir le protocole de notification : quand, quoi, où, qui ?
Créer un groupe d'utilisateurs
Configurer la règle de validation ou la notification d'étape de programme
Créer le contenu du message de notification
Planifier des tâches automatisées
Définir la méthode de distribution
Maintenance : utilisateurs, groupes d'utilisateurs, travaux programmés

Étape 1 : Définir le protocole de notification : quand, quoi, où, qui¶

Dans quelle(s) condition(s) le système doit-il déclencher une notification ? À qui ? Les protocoles pertinents doivent être consultés et vérifiés avec les acteurs des secteurs de la santé publique et de la santé animale et du bétail afin de définir et de mapper les conditions d'envoi de notifications basées sur des données collectées dans DHIS2 par un secteur à des contacts d'un autre secteur.

Quand : La notification est partagée lorsqu'une condition spécifique est remplie, qui peut être basée sur :
Nombre de cas : 1 ou plus
Période : hebdomadaire, mensuelle, etc.
Lieu : établissement de santé, district, etc
Quoi : Contenu de la notification, quelles variables ?
Où : quels niveaux (établissement, district ?) doivent recevoir une notification - à l'intérieur ou à l'extérieur de leur unité/niveau ?
Qui : les destinataires de la notification - les utilisateurs de DHIS2 et les non-utilisateurs de DHIS2

Exemple de cas d'utilisation (A) : DHIS2 est utilisé par les établissements de santé pour la déclaration hebdomadaire globale SIMR des maladies infectieuses prioritaires et pour la déclaration immédiate des cas de maladies à déclaration obligatoire. Il s'agit notamment de la déclaration de plusieurs zoonoses présumées, comme la rage et le charbon bactéridien, qui doivent également être notifiées au responsable de la santé vétérinaire du district en vue d'une enquête plus approfondie. Le vétérinaire de district (DVO) n'est pas un utilisateur habituel de DHIS2 ; cependant, lorsque 1 ou plusieurs cas de rage humaine sont signalés dans la SIMR hebdomadaire de DHIS2 par un centre de santé, le DVO doit recevoir une notification par courrier électronique.

Étape 2 : Configurer les utilisateurs et les groupes d'utilisateurs¶

En fonction du protocole de notification défini à l'étape 1, de nouveaux groupes d'utilisateurs peuvent être nécessaires. Lorsque les destinataires de la notification sont déjà des utilisateurs de DHIS2, il peut suffire de les ajouter à un groupe d'utilisateurs approprié. Si les destinataires cibles ne sont pas des utilisateurs de DHIS2, ils peuvent être configurés en tant qu'utilisateurs ou un utilisateur peut être configuré dans DHIS2 pour représenter des listes de diffusion gérées dans d'autres plates-formes. Enfin, si une solution d'intégration est appliquée, un utilisateur dédié peut être nécessaire et doit être discuté au cas par cas. Pour recevoir des notifications par courrier électronique de DHIS2, l'utilisateur n'a pas besoin d'accéder à d'autres parties du système DHIS2.

Exemple de cas d'utilisation (A): Les Agents Vétérinaires de District (DVO) ne sont pas des utilisateurs typiques de DHIS2. Ils reçoivent uniquement des notifications de DHIS2, mais ne sont pas censés se connecter pour saisir ou analyser des données. Un groupe d'utilisateurs d'agents vétérinaires de district est configuré dans DHIS2 afin de configurer et d'envoyer des notifications. Un compte d'utilisateur DHIS2 pour chaque district est configuré avec l'accès approprié aux unités d'organisation pour faciliter les notifications à l'adresse électronique désignée du DVO, mais l'utilisateur n'a pas accès à la saisie, à la visualisation ou à l'analyse des données dans DHIS2.

Étape 3 : configurez votre notification de programme ou votre notification de validation¶

Based on the conditions defined in Step 1, configure a program notification (for tracker data) or validation notification (for aggregate data and outbreak thresholds). These conditions will depend on the existing configuration and what data is being captured in DHIS2.

Dans le domaine agrégé, les notifications de règles de validation peuvent être configurées pour déclencher une alerte lorsqu'un seuil de maladie donné est atteint pour une zone géographique et une période données. Pour plus d'informations, **consultez la documentation notifications des règles de validation. ** Rappelez-vous que vous devrez peut-être d'abord créer votre règle de validation afin d'établir la condition d'un seuil.

Dans le domaine du tracker, les notifications de programme et les notifications d'étape de programme peuvent déclencher une notification sur la base d'une gamme flexible de variables saisies dans le programme tracker de DHIS2. Pour plus d'informations, consultez la documentation sur les [notifications de programme] (https://docs.dhis2.org/en/use/user-guides/dhis-core-version-master/configuring-the-system/programs.html#create-a-program-stage-notification). Rappelez-vous que vous devrez peut-être d'abord créer une règle de programme pour établir la condition.

Exemple de cas d'utilisation (A) : Notification de validation

Nous voulons configurer une alerte pour le vétérinaire de district lorsque 1 ou plusieurs cas de rage humaine sont signalés dans l'ensemble de données de la SIMR hebdomadaire.

Créez une règle de validation pour représenter la condition de votre seuil. Dans ce cas, attribuez à l'élément de données de l'opérateur de gauche la valeur "Cas de rage", à l'opérateur la valeur "inférieur à" et à l'opérateur de droite la valeur "1". Lorsque la période de temps est fixée à une semaine et que l'unité d'organisation est fixée au niveau de l'établissement, la règle permet de déclencher une notification chaque fois qu'un établissement signale plus d'un cas de rage au cours d'une période hebdomadaire donnée.

Conseil : N'oubliez pas de cocher la case « Ignorer cette règle lors de la validation du formulaire » si vous ne souhaitez pas que cette règle soit évaluée lors de la saisie des données !

Créer une notification de règle de validation.

Sélectionnez la règle de validation souhaitée ("sous quelle condition vais-je envoyer une notification ?")

Sélectionnez le groupe d'utilisateurs destinataires souhaité ("qui recevra cette notification ?")

Exemple de cas d'utilisation (A) : Notification de programme

Nous voulons configurer une alerte pour le vétérinaire de district lorsqu'un cas suspect de rage signalé dans un programme tracker des cas reçoit une confirmation de laboratoire.

Sélectionnez le programme dont les données déclencheront une notification. Dans ce cas, nous utilisons une notification d'étape de programme parce que nous voulons utiliser les valeurs de l'ensemble d'options Résultats de laboratoire collectées en tant qu'élément de données dans l'étape de programme Résultats de laboratoire pour déclencher notre notification.
Configurez "quoi envoyer" à l'aide du contenu du message de notification (également décrit à l'étape 4).

Configurez "quand envoyer" la notification. Dans ce cas, nous voulons que le déclenchement soit basé sur une règle de programme existante qui filtre les événements dont les résultats de laboratoire sont confirmés.

Conseil : N'oubliez pas qu'il peut être nécessaire de configurer d'abord une règle de programme à l'aide de ProgramRuleActionType.SENDMESSAGE pour que ce déclencheur fonctionne.

Configurez "à qui l'envoyer". Sélectionnez les groupes d'utilisateurs, les utilisateurs affectés à l'unité d'organisation ou d'autres paramètres pertinents (par exemple, les crochets web peuvent favoriser l'interopérabilité avec d'autres outils de messagerie). Dans ce cas, nous l'enverrons au groupe d'utilisateurs "Agents vétérinaires de district", en limitant la notification à l'unité d'organisation parente. En effet, nous voulons envoyer la notification à un utilisateur au niveau du district pour un cas signalé dans n'importe quel établissement du district parent dans la hiérarchie de l'UO DHIS2.

Conseil : vous pouvez également décider de ne notifier que les utilisateurs de la hiérarchie ou que l'unité d'organisation parente (par exemple : un district dans le cas X ne doit être envoyé qu'aux utilisateurs de sa province parente, la province Y).

Étape 4 : Créer le contenu du message de notification¶

Lors de la configuration d'une notification de validation ou d'une notification de programme, vous définirez votre modèle de message de notification.

Conseil : veillez à ce que le modèle de notification de votre message comprenne des points d'action et des rappels à l'intention de l'utilisateur cible en fonction des protocoles locaux.

Les variables de modèle peuvent être utilisées pour générer des messages dynamiques basés sur des paramètres tels que l'unité d'organisation, la date du jour et la période.

Figure : Modèles de variables pour les règles de validation

Les variables du modèle s'affichent dynamiquement dans le message destiné à l'utilisateur cible. Dans cet exemple, nous pouvons voir que les cas de rage ont été signalés par l'hôpital Mahosot (unité d'organisation déclarante) au cours de la semaine du 28 2024 (basé sur un ensemble de données hebdomadaire).

Étape 5: Programmer des tâches automatisés¶

Plusieurs tâches doivent être exécutées en séquence afin d'automatiser les notifications de validation (elles peuvent également être exécutées manuellement). Voir la [documentation sur la planification] (https://docs.dhis2.org/en/implement/health/disease-surveillance/ids-aggregate/installation.html#idsr-scheduling) et les tâches de séquençage pour automatiser ce processus.

Étape 6 : Définir la méthode de distribution¶

Les destinataires des notifications déclenchées par DHIS2 peuvent être ou non des utilisateurs ayant accès à d'autres sections du système. La fonctionnalité principale de DHIS2 prend en charge les mécanismes de notification suivants :

Service de messagerie interne de DHIS2
SMS (en configurant une passerelle SMS) ou USSD
Email (emails des comptes utilisateurs de DHIS2, voir plus d'informations sur configurer l'email)

Des flux de notifications plus solides et plus complexes ou la prise en charge d'autres types de plateformes de communication peuvent être réalisés grâce à [l'intégration] (https://dhis2.org/integration/) avec DHIS2 et d'autres outils tels que:

Rapid Pro (voir vidéo et code)
Les Chatbots et les plateformes de médias sociaux (voir vidéo)
Autres innovations tirant parti de l'API DHIS2 et d'autres caractéristiques d'extensibilité telles que les crochets web

Étape 7 : Maintenance¶

Un administrateur système doit être désigné pour assurer la maintenance de la solution au fil du temps. Cet administrateur peut être géré par l'équipe centrale de DHIS2 du ministère ou une équipe similaire :

Gérer les comptes d'utilisateurs et les groupes d'utilisateurs (en coordination avec le secteur de la santé animale pour obtenir des listes/contacts à jour : créer de nouveaux utilisateurs, les affecter à un groupe d'utilisateurs, les désactiver)
Continuez à vérifier que les tâches programmées s'exécutent comme prévu, dans l'ordre
Configurer de nouvelles notifications, de nouveaux messages, de nouvelles conditions et de nouveaux groupes d'utilisateurs en fonction de nouvelles exigences (telles que les conditions et les seuils de priorité en cas de maladie) et de changements dans les protocoles de notification.
Pendant les mises à jour de DHIS2 : tester la fonctionnalité de votre configuration