Configuration de DHIS2 Tracker pour la surveillance des épidémies

DHIS2 Tracker est l'un des outils de suivi de cas individuels les plus performants à la disposition des systèmes de santé nationaux. Déployé correctement, il comble le fossé entre un cas suspect dans un établissement de soins de santé primaires et une réponse coordonnée au niveau de l'État ou au niveau national. Déployé incorrectement, il devient un autre système qui génère des rapports que personne ne lit.

Pourquoi suivre, et non agréger ?

Avant de configurer quoi que ce soit, la question qu'il vaut la peine de poser est de savoir si DHIS2 Tracker est le bon module. DHIS2 dispose de deux modèles de données primaires : agrégé (données récapitulatives périodiques) et tracker (données de cas longitudinales au niveau individuel). Pour la déclaration de routine de la surveillance des maladies, les dénombrements hebdomadaires des cas par agrégat d'installations sont suffisants et beaucoup plus simples à gérer.

Tracker devient nécessaire lorsque vous devez :

• Suivre un cas individuel à travers plusieurs rencontres cliniques

• Enregistrer les liens de recherche des contacts (cas source aux contacts)

• Déclencher des alertes automatiques lorsque les seuils de cas sont dépassés

• Désagréger les résultats par attributs au niveau individuel (âge, sexe, statut vaccinal, historique de voyage)

• Suivre le statut d'investigation et la clôture pour chaque cas confirmé

Pour la surveillance des épidémies spécifiquement, la capacité de Tracker à lier les cas aux contacts, à enregistrer les délais d'investigation et à générer des rapports de cas individuels qui alimentent les systèmes nationaux de notification justifie l'investissement supplémentaire en configuration.

Étape 1 : Conception du programme avant la configuration

L'erreur la plus courante dans l'implémentation de Tracker est d'ouvrir DHIS2 et de commencer à construire avant que la conception du programme ne soit terminée. Avant la création d'un seul élément de données, clarifiez :

• Qui capture quoi, et quand ? Cartographiez le cycle de vie du cas, de l'identification du cas suspect à la clôture du cas. Chaque étape du flux de travail d'investigation correspond à une étape de programme Tracker.

• Quelles décisions les données doivent-elles orienter ? Travaillez à rebours à partir des décisions importantes. Si le seuil d'alerte est de trois cas en une seule semaine dans une seule installation, ce seuil doit être intégré à la logique du programme et non rapporté à un superviseur qui décide manuellement.

• Quel est l'ensemble de données minimal viable ? Les implémentations de Tracker s'effondrent fréquemment sous la charge de la collecte de données. Définissez l'ensemble minimum d'éléments de données qui permet les décisions requises, et résistez à la tentation d'en ajouter davantage simplement parce que le système le permet.

Étape 2 : Configuration des étapes du programme

Pour la surveillance des épidémies, un programme Tracker bien conçu utilise généralement quatre étapes :

Étape 1 : Enregistrement des cas et notification initiale

Capture les informations disponibles au premier contact. Les éléments de données requis comprennent la date de début, la date de la première consultation, l'établissement déclarant, les identifiants du patient, la constellation symptomatique primaire et la classification initiale du cas. Gardez cette étape courte : les équipes de terrain devraient la compléter en moins de cinq minutes. L'objectif est la détection précoce du signal, et non la documentation clinique.

Étape 2 : Investigation des cas

L'enquête épidémiologique détaillée, réalisée par un agent formé. Capture la chronologie complète des symptômes, l'historique d'exposition, le statut vaccinal, la liste des contacts, les détails de la collecte des échantillons et le résultat clinique au moment de l'enquête.

Étape 3 : Résultats de laboratoire

Conçue pour recevoir les résultats directement du système d'information de laboratoire où l'intégration existe, ou via la saisie manuelle là où elle n'existe pas. Le champ clé est le statut de l'échantillon (en attente, reçu, testé, résultat), qui pilote la mise à jour de la classification du cas.

Étape 4 : Clôture des cas

Enregistre la classification finale, le résultat (rétablissement, décès, perdu de vue) et un résumé narratif de l'enquête. Cette étape déclenche le retrait du cas du tableau de bord de surveillance active. Aucun cas ne doit rester ouvert indéfiniment.

Étape 3 : Configuration des éléments de données

Trois propriétés comptent le plus pour la surveillance : le type de valeur, l'ensemble d'options et le type d'agrégation.

• Types de valeurs : Utilisez TEXT uniquement lorsque le texte libre est réellement nécessaire. Préférez INTEGER, DATE, BOOLEAN, ou OPTION_SET pour toutes les données structurées. Les champs de texte libre ne peuvent pas être agrégés, filtrés ou utilisés dans les règles de programme.

• Ensembles d'options : Construisez soigneusement les ensembles d'options et réutilisez-les dans plusieurs programmes. Un ensemble d'options de Classification des cas utilisé de manière cohérente dans chaque programme de maladie permet une analyse transversale des maladies. Des ensembles d'options incohérents rendent cela impossible.

• Type d'agrégation : Définissez la plupart des éléments de données sur COUNT ou SUM. Définissez NONE pour les champs d'identifiant qui ne doivent pas être agrégés.

Étape 4 : Règles de programme pour la qualité des données au point d'entrée

Les règles de programme sont le mécanisme de DHIS2 pour appliquer la logique au niveau du formulaire. Pour la surveillance des épidémies, elles ne sont pas facultatives. Les règles de programme essentielles comprennent :

• Logique des dates : Empêcher l'enregistrement de la date de début après la date de clôture du cas. Empêcher l'enregistrement de la date d'investigation avant la date d'enregistrement.

• Validation de la définition de cas : Calculer si les symptômes saisis correspondent à la définition épidémiologique du cas et afficher le résultat à l'agent de saisie des données.

• Application des champs obligatoires : Rendre la date de collecte des échantillons obligatoire lorsque le type d'échantillon est saisi. Rendre la date du résultat de laboratoire obligatoire lorsque le résultat est saisi.

• Alerte de doublon : Activer la détection de doublons intégrée de DHIS2 sur la correspondance du nom, de la date de naissance et de l'établissement.

Étape 5 : Tableaux de bord conçus pour la prise de décision

Une implémentation de DHIS2 sans tableau de bord fonctionnel est un entrepôt de données. Pour la surveillance des épidémies, le tableau de bord principal doit afficher en temps réel :

• Nombre de cas actifs par district : Une carte thématique avec les cas codés par couleur selon la densité

• Pipeline du statut des cas : Combien de cas se trouvent à chaque étape de l'investigation

• Délai d'investigation : Moyenne des jours entre l'enregistrement du cas et la fin de l'investigation, par LGA

• Courbe épidémique : Cas par date de début, affichant la trajectoire de l'épidémie

• Indicateur d'alerte : Districts atteignant le seuil d'épidémie suspectée

Concevez des tableaux de bord pour la personne qui doit prendre une décision à 7h du matin un lundi, et non pour la personne qui a construit le système. Pour le cadre complet de conception de tableau de bord, voir Bonnes pratiques des tableaux de bord DHIS2.

Étape 6 : Contrôle d'accès et attribution d'unité organisationnelle

Les données de Tracker sont individuellement identifiables. L'accès doit être restreint par unité organisationnelle et rôle d'utilisateur. La structure recommandée :

• Utilisateurs au niveau de l'établissement : Peuvent enregistrer des cas et saisir les données de l'Étape 1 uniquement pour leur propre établissement

• Agents de surveillance des LGA : Peuvent consulter tous les cas dans leur LGA et saisir les données de l'Étape 2

• Épidémiologistes de l'État : Peuvent consulter tous les cas dans l'État et accéder aux tableaux de bord de la courbe épidémique

• Responsables de programme nationaux : Peuvent consulter les données agrégées mais ne peuvent pas accéder aux dossiers de cas individuels en dessous du niveau de l'État.

Étape 7 : Considérations relatives au déploiement réel

Faible bande passante : Configurez et testez le mode PWA de DHIS2 Tracker pour la capture de données hors ligne avant le déploiement, et non après la première épidémie.

Formation : Concevez la formation autour du flux de travail minimal viable – de l'enregistrement à la clôture – et développez les compétences sur celui-ci avant d'introduire la complexité.

Boucles de rétroaction sur la qualité des données : Intégrez une revue mensuelle de la qualité des données au calendrier du programme, couvrant l'exhaustivité, la rapidité et l'exactitude. Sans boucle de rétroaction, la qualité des données se dégrade silencieusement.

Intégration avec les systèmes nationaux : Assurez-vous que les éléments de données de votre programme d'État s'alignent sur la hiérarchie de l'instance nationale de DHIS2. Un désalignement interrompt l'alimentation des données nationales.

L'architecture est l'intervention

L'amélioration de 40 % de la sensibilité de la surveillance de la polio dans les programmes de l'OMS au Nigeria n'est pas venue de meilleurs formulaires de collecte de données. Elle est venue de la refonte de l'architecture – le flux de données, les déclencheurs d'action, les tableaux de bord qui rendaient la bonne information visible à la bonne personne au bon moment. C'est ce que DHIS2 Tracker, bien configuré, rend possible.

Continuer la lecture

• Qu'est-ce que DHIS2 ? Un guide en langage clair pour les professionnels des systèmes de santé

• Bonnes pratiques des tableaux de bord DHIS2

• Qualité des données DHIS2 : Comment construire des systèmes qui produisent des données fiables

• Surveillance intégrée des maladies et riposte : Une perspective systémique

Foire aux questions

À quoi sert DHIS2 Tracker ?

DHIS2 Tracker est utilisé pour le suivi des cas individuels, la recherche des contacts et le suivi longitudinal dans les programmes de santé. Contrairement à la déclaration agrégée de DHIS2, qui recueille des dénombrements récapitulatifs périodiques par établissement, Tracker enregistre les données pour chaque patient individuel à travers plusieurs rencontres cliniques. Il est utilisé pour la surveillance des épidémies, le suivi de l'immunisation, la gestion des cas de VIH et tout programme où les données au niveau individuel orientent les décisions cliniques ou de santé publique.

Quelle est la différence entre DHIS2 agrégé et Tracker ?

DHIS2 agrégé recueille des données récapitulatives : combien de cas ont été signalés dans un établissement au cours d'une semaine donnée. DHIS2 Tracker recueille des données de cas individuels : le patient spécifique, la chronologie de son investigation, les résultats de laboratoire, les contacts et le résultat. L'agrégé est plus simple à configurer et suffisant pour la déclaration de surveillance de routine. Tracker est approprié lorsque vous devez suivre un cas à travers plusieurs rencontres, lier des cas à des contacts ou désagréger les résultats par attributs au niveau individuel.

Comment configure-t-on les étapes de programme dans DHIS2 Tracker ?

Les étapes de programme représentent les étapes du cycle de vie du cas. Pour la surveillance des épidémies, une configuration standard utilise quatre étapes : l'enregistrement des cas et la notification initiale, l'investigation des cas, les résultats de laboratoire et la clôture des cas. Chaque étape contient les éléments de données minimaux nécessaires à cette étape, les règles de programme qui garantissent la qualité des données à l'entrée et les contrôles d'accès restreignant qui peut saisir ou consulter les données à chaque étape.

Que sont les règles de programme DHIS2 ?

Les règles de programme DHIS2 appliquent la logique au point de saisie des données. Elles peuvent afficher ou masquer des champs en fonction de valeurs précédemment saisies, calculer automatiquement les résultats, appliquer des champs obligatoires de manière conditionnelle, afficher des avertissements lorsque les saisies semblent incohérentes et déclencher des alertes lorsque les définitions de cas sont respectées. Pour la surveillance des épidémies, les règles de programme appliquent la logique des dates, valident les définitions de cas et préviennent les problèmes de qualité des données qui s'accumulent lorsque les données sont collectées sous pression opérationnelle.