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

Système d'Information sur la Santé Communautaire (CHIS) - Document de Conception du Système¶

{ #chis-agg-design }

Introduction¶

Un Système d'Information sur la Santé Communautaire ( CHIS ) normalisé et fonctionnel est essentiel pour le suivi de la santé, des besoins et des pratiques au niveau de la communauté. L'ensemble de métadonnées des Systèmes d'Information sur la Santé Communautaire ( CHIS ) est conçu pour faciliter la saisie et l'analyse d'un ensemble d'indicateurs de base pour les services de santé communautaires. Le kit de métadonnées CHIS accompagne le document [Analyse et utilisation des données communautaires de l'OMS : Guide pour le suivi des services de santé communautaires] (https://www.healthdatacollaborative.org/working-groups/community-data/guidance-for-community-health-worker-strategic-information-and-service-monitoring/). Ces directives répondent à la résolution WHA72.3 de l'Assemblée Mondiale de la Santé de 2019 qui appelle à: a) aligner les données et les efforts numériques pour optimiser les programmes des Agents de Santé Communautaire (ASC), et b) générer une base de données probantes plus solide pour l'impact des ASC.

Ce kit a été conçu pour répondre à la nécessité d'harmoniser les efforts visant à améliorer les programmes communautaires, de surveiller leur impact et de procéder à des ajustements politiques fondés sur des données probantes en fonction des besoins réels des communautés ciblées. La conception du système s'appuie sur des années de collaboration entre HISP et le ministère de la santé pour la mise en œuvre de DHIS2 pour la gestion des données des services de santé communautaires. Un [guide pratique] (https://drive.google.com/file/d/0B5Jsq_TjUPGjdFNVTzZNYnhlYzQ/view?resourcekey=0-mU2mmaaahcyHEaJ7e2_aqg) est également disponible pour les décideurs nationaux et locaux impliqués dans la conception, la planification, le déploiement, la gouvernance et la mise à l'échelle d'un système d'information sur la santé basé sur DHIS2. Ce guide (élaboré par HISP UiO, Akros Zambia et Health Data Collaborative) complète les orientations normatives de l'OMS par un examen approfondi des questions clés à prendre en considération lors de l'examen des problèmes liés à la gouvernance, à la conception, au développement et à l'utilisation du SISC à grande échelle.

Aperçu de la conception du système¶

Structure modulaire¶

Les agents de santé communautaire (ASC) sont responsables d'un grand nombre de tâches et d'activités en fonction des pays et des contextes. C'est pourquoi le kit SISC et les lignes directrices de l'OMS/UNICEF ont été organisés selon une approche modulaire. Une telle proposition permet une plus grande flexibilité car elle peut être modifiée pour une utilisation dans le pays en fonction du niveau de maturité du SISC et de l'étendue des services fournis au niveau de la communauté.

Le kit SISC comprend 21 modules et 37 ensembles de données avec une périodicité mensuelle et/ou annuelle de la collecte des données.

Le principe de flexibilité se reflète également dans la présence des mêmes éléments de données et indicateurs dans différents modules. Ceux-ci ont été répartis en fonction de I'éventualité théorique de la présence de certaines activités associées à des modules spécifiques.

Par exemple, l'élément de données "CH041a - Personnes diagnostiquées pour des troubles MNS/affections MH" appartient à une section sur l'évaluation des besoins en matière de santé mentale dans la communauté. Comme cette activité peut faire partie de plusieurs activités, elle est incluse dans six modules (santé mentale, maladies tropicales négligées, santé maternelle, santé des adolescents, VIH, tuberculose). En fonction de la nature des services fournis par les réseaux d'ASC, cet élément de données peut être redistribué, modifié ou supprimé. Étant donné que le mapping d'un ensemble étendu tel que celui du SISC peut prêter à confusion, le document de conception du système pour chaque module indique les modules et les ensembles de données où l'on peut trouver le même élément de données et/ou l'indicateur.

Ce kit contient des métadonnées pour les rapports mensuels et annuels de données et d'analyses agrégées. Il n'inclut donc pas de métadonnées au niveau individuel. Ce paquet de métadonnées n'est pas conçu pour soutenir les consultations individuelles des ASC, mais pour faciliter les rapports agrégés de routine dans le HMIS.

Hiérarchie des unités d'organisation et intégration des ASC¶

Dans le contexte du HMIS, la hiérarchie des unités d'organisation est généralement établie au niveau national, suivi par les provinces, les districts ou les établissements de santé. Ces unités d'organisation jouent un rôle crucial dans la facilitation de divers processus liés aux données, y compris la saisie des données, la garantie de la sécurité des données, la saisie des résultats et l'analyse des données. En particulier, cette structure permet l'agrégation des données au fur et à mesure qu'elles progressent dans la hiérarchie. De même, lors de la conception d'un système d'information sur la santé communautaire ( SISC), il est possible d'adopter une structure similaire. Toutefois, il est essentiel d'envisager l'inclusion des agents de santé communautaire (ASC) dans la hiérarchie des rapports, car cela garantit l'intégration efficace des ASC dans la structure des rapports pour faciliter l'attribution des données et des efforts en fonction de leur domaine de service. Compte tenu du nombre potentiellement important d'ASC impliqués, cette décision revêt une importance fondamentale dans la conception globale du CHIS. Le [Guide d'implémentation du SISC] (https://docs.dhis2.org/en/implement/chis-implementation/sustainable-design-and-architecture.html)fournit des questions essentielles pour l'évaluation de la hiérarchie du SISC :

La hiérarchie permet-elle de saisir les données par rapport à une unité organisationnelle qui représente le lieu et la personne à laquelle les données sont associées ?
La hiérarchie permet-elle de mettre en place des contrôles de sécurité et d'accès ?
L'agrégation produit-elle les résultats souhaités : indicateurs, analyses, tableaux de bord, cartes, etc. ?
Les données peuvent-elles être associées à un seul ASC ?

Le guide a testé plusieurs scénarios et en recommande certains pour cette implémentation. Toutefois, il est important que votre implémentation fasse l'objet d'une évaluation approfondie et que l'option la plus appropriée à votre cas d'utilisation soit envisagée.

Option 1 : les données communautaires sont transmises par l'intermédiaire d'un établissement de santé¶

Le paquet de métadonnées actuel est conçu sur la base de cette option. Il suppose que les données de tous les ASC desservant différentes communautés seront agrégées et qu'un rapport unique sera soumis pour chaque période de déclaration aux établissements de santé affiliés. Cependant, cette option ne permet pas d'associer les données à des ASC spécifiques et aux communautés qu'ils desservent, puisqu'ils ne sont pas inclus dans la structure de rapport pour l'attribution. Bien que cette approche ne réponde pas aux critères d'association des données aux ASC, nous reconnaissons que de nombreux pays optent pour cette implémentation, car elle constitue un moyen pratique d'intégrer les données communautaires dans le HMIS. Pour cette option, les ensembles de données seront attachés au niveau de l'établissement de santé, comme le montre la structure ci-dessous :

Option 2: Un ou plusieurs ASC travaillent au sein d'une seule communauté¶

Cette option suppose un scénario dans lequel un ou plusieurs ASC sont affectés à une seule structure communautaire sous l'égide d'un établissement de santé, sans qu'il y ait chevauchement des communautés par les ASC. Dans cette structure, chaque ASC est censé soumettre son rapport individuel pour une période donnée. Cette configuration garantit que les données collectées sont attribuées à un ASC spécifique et qu'elles correspondent à une communauté particulière sans être mélangées. Par conséquent, il n'aura accès qu'aux données qu'il a personnellement collectées. L'agrégation des données à chaque niveau permettra d'accumuler des informations aux niveaux suivants : les ASC, les communautés, les établissements, les régions et le niveau national. Pour cette option, les ensembles de données seraient attachés au niveau des ASC, comme indiqué dans la structure hiérarchique ci-dessous :

Option 3: L' ASC travaille dans plusieurs communautés, qu'il ne partage pas avec d'autres.¶

Cette option suppose un scénario dans lequel un seul ASC est chargé de desservir plusieurs communautés au sein d'un établissement de santé, sans qu'il y ait de chevauchement des communautés par les ASC. Dans cette structure, chaque ASC est tenu de soumettre des rapports individuels pour chacune des communautés qu'il dessert. Cela garantit que les données sont attribuées à la communauté spécifique où elles ont été collectées et qu'elles appartiennent explicitement à l'ASC concerné.

Chaque ASC sera affecté à sa propre unité organisationnelle au niveau 5 de la hiérarchie. Il aura accès aux données appartenant à son unité d'organisation et à ses subordonnées au niveau 6. Dans ce cas, les subordonnées font référence aux communautés dans lesquelles l'ASC travaille. Par conséquent, l'ASC ne peut accéder qu'aux données qu'il a personnellement collectées. Ces données peuvent être agrégées à chaque niveau : village, ASC, établissement, région et niveau national. Dans le cadre de cette option, les ensembles de données seront rattachés au niveau communautaire, comme indiqué dans la structure hiérarchique ci-dessous :

Option 4: ASC comme attributs d'option de catégorie¶

Dans ce scénario, les ASC ont la possibilité de travailler dans n'importe quelle communauté, et il peut arriver que plusieurs ASC desservent la même communauté. Cependant, chaque fois qu'un ASC soumet un rapport, quelle que soit la communauté qu'il a servie, il peut être attribué à cet ASC spécifique. Pour ce faire, on utilise les options de catégorie, qui permettent de créer une liste des ASC pouvant être générée en tant que combinaison de catégories et jointe aux ensembles de données. La structure hiérarchique inclura les communautés où l'ensemble de données est attaché, mais pas les ASC. Les options de partage peuvent également être définies pour permettre aux utilisateurs d'accéder uniquement aux options qui leur sont attribuées, ce qui réduit les erreurs dans la saisie des données. Les données peuvent être saisies au niveau de la Communauté, et une relation peut être établie entre les données et l'ASC en utilisant la catégorie de l'ASC comme filtre. Les données peuvent être agrégées à chaque niveau : communauté, établissement, région et niveau national. Les données peuvent être désagrégées par ASC en utilisant la Catégorie comme filtre, ce qui permet de répartir les données spécifiques à chaque ASC.

REMARQUE: Il est important de noter que cette configuration pourrait ne pas être extensible aux grands SISC disposant d'un nombre important d'ASC.

Exemple de configuration selon l'option 4

Déroulement¶

Les types de services que les agents de santé communautaire fournissent dans les communautés sont très hétérogènes d'un pays à l'autre. Chaque module comprend une liste d'indicateurs standardisés qui doivent être revus, adaptés et adoptés en fonction des tâches des ASC dans le système de santé du pays, de la charge de travail et de la maturité du système d'information sur la santé. Les lignes directrices de l'OMS/UNICEF proposent une approche en plusieurs étapes pour le mapping des stratégies nationales et l'identification des modules/indicateurs nécessaires au suivi et à l'évaluation des activités communautaires, comme illustré ci-dessous :

Utilisateurs cibles¶

Le paquet a été développé en tenant compte des profils d'utilisateurs suivants :

Les gestionnaires de programmes nationaux et sous-nationaux responsables de l'analyse des données et du suivi des performances
Les responsables de district et les superviseurs chargés de diriger et de contrôler les activités communautaires
Les agents de santé communautaire fournissent des services de santé, procèdent aux évaluations communautaires, collectent et communiquent des données sur les activités de santé communautaire

Groupes d'utilisateurs¶

Dans le cadre de la configuration du paquet, des groupes d'utilisateurs ont été créés pour gérer les paramètres de partage dans les métadonnées de tous les modules. Les métadonnées de base qui utilisent ces paramètres de partage comprennent principalement les ensembles de données, les tableaux de bord, les indicateurs et les éléments de données. Les 3 groupes d'utilisateurs créés sont les suivants :

Administrateur du SISC - les utilisateurs de ce groupe ont accès à la visualisation / modification des métadonnées et à un accès restreint à la visualisation uniquement des valeurs de données dans les ensembles de données.
Accès au SISC - les utilisateurs de ce groupe ont l'accès en mode visualisation uniquement des métadonnées et des valeurs de données dans les ensembles de données.
Saisie dans le SISC - les utilisateurs de ce groupe ont un accès en mode visualisation uniquement des métadonnées et un accès en mode visualisation/modification des valeurs de données dans les ensembles de données.

Bien qu'il soit important de conserver ces groupes d'utilisateurs lors de l'installation de ce paquet, n'hésitez pas à les réviser en fonction de la configuration ou de la politique existante en matière de groupes d'utilisateurs dans l'instance hôte.

Intégration Établissement - Communauté¶

Lors de l'adoption de ce paquet, il est essentiel d'envisager l'intégration des données du SISC et du HMIS. Les exigences et les besoins en matière d'intégration varieront en fonction des mises en œuvre existantes : les bases de données peuvent déjà être intégrées, mais les différents ensembles de données pour les données du SISC et du HMIS ou les bases de données peuvent être séparées. Il est également possible que le SISC soit un domaine de suivi et que le HMIS soit un domaine de données agrégées. Il est également possible que le HMIS ou le SISC utilisent d'autres plates-formes logicielles différentes de DHIS2. Chacun de ces scénarios présente des complexités uniques pour l'intégration. Pour ce paquet de métadonnées, nous recommandons deux approches pour l'intégration : les indicateurs composites et l'utilisation de l'application d'échange de données, comme expliqué dans les sections suivantes.

Configurer les indicateurs composites¶

Les indicateurs composites consistent à créer des indicateurs qui utilisent des éléments de données provenant à la fois du SISC et du HMIS. Cette approche permet d'obtenir un aperçu complet, une triangulation et une analyse de routine transparente de l'ensemble des informations sur la santé. Alors que l'ensemble de données HMIS se concentre principalement sur la collecte de données au niveau de l'établissement, l'ensemble de métadonnées du SISC est spécifiquement conçu pour collecter et analyser un ensemble d'indicateurs de base pour les services de santé communautaires. Il est important de noter que les ensembles agrégés HMIS et SISC couvrent des domaines de santé similaires, tels que le VIH, la tuberculose, le paludisme, la nutrition, le PEV et les maladies non transmissibles, entre autres, et qu'ils partagent souvent des éléments de données et des indicateurs communs. Lorsque les packages du HMIS et du SISC sont installés dans la même instance, il devient possible de développer des indicateurs composites pour ces éléments de données partagés dans l'ensemble du système. Comme l'illustre le tableau ci-dessous, de simples indicateurs de résultats peuvent être créés, et il est également possible d'établir des indicateurs de couverture au niveau infranational. Toutefois, il convient d'être prudent lors de la détermination des dénominateurs, en particulier si les communautés se chevauchent et s'étendent au-delà des unités infranationales. Si l'on n'en tient pas compte, les estimations de la couverture pour les indicateurs composites risquent d'être inexactes. De même, pour garantir une analyse pertinente, la période de collecte des données doit être alignée de manière à couvrir une période complète pour les deux sources. En outre, des mesures de contrôle de la qualité des données et des vérifications doivent être mises en place afin de minimiser les doubles déclarations au niveau des établissements et des communautés, comme cela est susceptible de se produire.

Vous trouverez ci-dessous quelques exemples qui vous permettront d'apprendre et de créer d'autres indicateurs composites au fur et à mesure que le paquet du SISC est adopté. N'hésitez pas à utiliser ces exemples comme référence et à explorer d'autres indicateurs composites au fur et à mesure que vous intégrez le paquet du SISC dans vos processus d'analyse de données.

Tableau 1 : Exemples d'indicateurs composites possibles pour certains programmes du SISC.

Programme	Établissement + Communauté = Numérateur	Dénominateur	Exemple d'indicateurs composites
Tuberculose	[Nouveaux, cas de rechute et cas dont les antécédents thérapeutiques sont inconnus] + [CH128b - Cas de tuberculose notifiés] dans la zone de collecte]	N/A	Cas de tuberculose notifié dans l'établissement et dans la communauté
VIH	[VIH - Tests de dépistage du VIH effectués] + [CH028b - Tests de dépistage du VIH rendus]	N/A	Tests de dépistage du VIH effectués dans l'établissement et dans la communauté
Paludisme	[PAL - Test de dépistage du paludisme (TDR)] + [CH119a - Cas fébriles testés par TDR]	N/A	Cas de paludisme testés à l'aide d'un TDR au niveau de l'établissement et de la communauté
	[PAL - Cas de paludisme positifs au TDR] + [CH121 - Cas de paludisme confirmés]	[PAL - Test de dépistage du paludisme (TDR)] + [CH119a - Cas fébriles testés par TDR]	Taux de positivité au test TDR pour le paludisme dans l'établissement et la communauté (%)
NUT	[NUT - Réception de compléments contenant du fer lors des consultations prénatales dans l'établissement] + [CH037 - Les femmes reçoivent des compléments de fer pendant la CPN]	N/A	Les femmes reçoivent des compléments de fer dans le cadre de la CPN au niveau de l'établissement et de la communauté
	[NUT - Complément de vitamine A, routine de 6-59 mois dans l'établissement] + [CH061a - Enfants (6-59m) ayant reçu de la vitamine A au cours des semestres 1 et 2 - routine]	Nombre d'enfants (6-59m)	Enfants (6-59m) recevant de la vitamine A dans l'établissement et dans la communauté

Utilisation de Data Exchange ( Échange de données)¶

Dans le cas où le module du SISC est installé sur une instance distincte de celle du HMIS, ou même dans la même base de données mais avec des ensembles de données différents, un service [d'échange de données agrégées] (https://docs.dhis2.org/en/develop/using-the-api/dhis-core-version-239/data-exchange.html) et une [application d'échange] (https://docs.dhis2.org/en/use/user-guides/dhis-core-version-239/exchanging-data/data-exchange.html) peuvent être utilisés pour faciliter le transfert de données entre les plates-formes du SISC et du HMIS. Ce service et cette application ont été introduits dans la version 2.39 de DHIS2, qui exige que l'instance source de DHIS2 soit la version 2.39 ou une version ultérieure, tandis que l'instance cible doit être la version 2.38 ou une version ultérieure. Dans l'hypothèse d'instances distinctes pour le SISC et le HMIS, il est donc possible de configurer le service, d'installer et d'utiliser l'application pour transférer les données entre les instances, comme illustré dans la figure ci-dessous. Une fois les données du SISC transférées dans l'instance du HMIS, vous pouvez également créer des indicateurs composites, comme indiqué dans la section précédente de ce guide. Vous trouverez ci-dessous les étapes à suivre pour configurer le service :

1) Mettre à jour les métadonnées (indicateurs) dans l'instance source ( SISC) dont les données doivent être échangées. Il est important de s'assurer que ces indicateurs ont des codes de métadonnées qui permettront un échange de données réussi. 2) Mettre à jour les métadonnées (éléments de données) dans l'instance cible (HMIS) pour les aligner sur les métadonnées source. Cela implique d'établir des codes similaires dans les métadonnées de l'instance cible pour correspondre au système d'identification des codes utilisé dans l'instance source. Notez que le service d'échange actuel ne prend en charge que les éléments de données sans catégories ou les données non désagrégées. 3) Créer la charge utile d'échange de données au format JSON. Cette charge utile doit inclure toutes les configurations nécessaires à l'installation, y compris les informations sur l'instance cible, les exigences en matière d'authentification et le schéma d'identification à utiliser. Une fois créée, cette configuration doit être téléchargée dans l'instance du SISC. 4) Installer l'application d'échange de données disponible dans DHIS2 App Hub dans l'instance du SISC. Cette application permettra le transfert de données de l'instance du SISC vers l'instance du HMIS à l'aide des paramètres et de la charge utile configurés.

Remerciements¶

Le paquet du SISC a été développé avec l'UNICEF et l'OMS avec le soutien du Fonds mondial de lutte contre le SIDA, la tuberculose et le paludisme.

Références¶

[Analyse et utilisation des données sur les services de santé à base communautaire. Guide pour les agents de santé communautaire, l'information stratégique et le suivi des services] (https://www.healthdatacollaborative.org/fileadmin/uploads/hdc/Documents/Working_Groups/Community_Data/210305_UNICEF_CHW_Guidance_EN.pdf). Mars 2021. Publié par le Fonds des Nations Unies pour l'enfance (UNICEF)

[Lignes directrices pour les systèmes d'information sur la santé communautaire de DHIS2] (https://drive.google.com/file/d/0B5Jsq_TjUPGjdFNVTzZNYnhlYzQ/view?resourcekey=0-mU2mmaaahcyHEaJ7e2_aqg). 2017. Programme de systèmes d'information sur la santé de l'Université d'Oslo

[Échange de données agrégées] (https://docs.dhis2.org/en/develop/using-the-api/dhis-core-version-239/data-exchange.html). 2023. Université d'Oslo, Programme des systèmes d'information sur la santé

[Conception et architecture durables du SISC de DHIS2] (https://docs.dhis2.org/en/implement/chis-implementation/sustainable-design-and-architecture.html). 2022. Université d'Oslo, Programme des systèmes d'information sur la santé