 Nous allons commencer pour cette dernière séance, on ne va pas aborder tout ça. Il y a différentes approches pour intégrer les données, agager les données du tracker, pourquoi c'est important. On va avoir une entrediction par rapport à cet outil Kamel, espérons qu'on aura aussi le temps pour les questions. L'expérience par rapport à la tibiaquilosa, ce sera une autre séance demain. Alors pourquoi c'est vraiment utile d'abord, nous analysons l'analyse des données au niveau des données d'HST. Il est très utile de comparer les données qui viennent des modules agrégées et des modules du tracker. Par exemple, si vous avez des registres de vaccination dans le tracker, vous avez les données agrégées et vous aimeriez comparer les données sur la vaccination et les données du tracker. Donc c'est important, vous devez impliquer différents programmes composants et sanitaires, différents programmes. Avec le tracker, ça prend du temps pour avoir la couverture géographique. Vous avez souvent des trackers dans différents établissements sanitaires et vous avez les modules agrégées dans d'autres. Vous devez analyser les données des deux sources pour avoir une meilleure compréhension. Des fois, on a un tracker agrégé sur deux différents modules d'HST. Et si vous voulez les analyser ensemble, ça va vous prendre du temps. Alors ce que nous avons constaté avec toute la pandémie de COVID, il y a eu des implementations du tracker à grande échelle et il y a eu beaucoup de problèmes avec les analyses du tracker ou vous atteignez des millions de personnes. Voilà les trois approches que j'ai proposées pour vous lier les données du tracker et les données agrégées. D'abord, si vous avez vos données, vous pouvez montrer le tracker et les données agrégées ensemble dans des graphiques et dans des tables de bords. Vous pouvez utiliser les indicateurs agrégés pour combiner les données agrégées. Et en dernier lieu, vous pouvez exporter vos données agrégées. Et je vais brièvement parler et le reste de la session va se focaliser sur le troisième point. Je vais parler des premiers points. D'abord, quelques exemples où nous avons les données de COVAQ qui combinent les indicateurs de programme avec les doses de vaccins qui ont été administrées ainsi que le reporting agrégé. Nous avons une partie dans le tableau de bords où nous avons des données basées sur le cas avec les chiffres agrégés sur les causes de décis. Nous avons aussi la possibilité des indicateurs agrégés de combiner les modèles des données agrégées du tracker. C'est ce que nous voulons pour faire la couverteur. Nous avons besoin de données du tracker avec les données du service. Mais c'est aussi possible de l'utiliser si vous avez des lieux géographiques différents. Vous pouvez combiner les différents chiffres que vous voulez analyser dans les indicateurs agrégés pour avoir une meilleure couverture géographique avec les mêmes indicateurs. Si vous êtes en train de transiter vers le tracker, vous pourrez avoir des données historiques et agrégées. Vous pouvez commencer à utiliser le tracker et vous pouvez combiner les indicateurs agrégés pour cette transition. Nous allons nous focaliser dans cette séance. Nous allons voir comment nous allons prendre les données basées sur les cas, les données du tracker et les données agrégées. Comme je l'ai déjà indiqué, nous sommes focalisés beaucoup plus sur la performance à cause des implementations du tracker. Nous avons eu du mal avec les journalistes du tracker. Si vous pensez au système de formation sanitaire sous une perspective générale pour faire le reporting et de routine, vous allez implémenter le tracker dans un domaine spécifique et vous cherchez à tout mettre ensemble. Ce qu'il faut regarder à l'esprit, c'est comment cela est vraiment implémenté au niveau de pays. Si vous utilisez seulement le tracker, vous avez vos instances du tracker et c'est là où cela va se passer. Dans certains endroits, vous allez combiner vos données trackers et vos données agrégées. Par exemple, vous aurez une instance parallèle. La norme qui est recommandée, c'est d'avoir des instances séparées pour le tracker et les données agrégées. Vous faites votre reporting de routine dans un endroit donné. Pour ce qui est de ces différentes approches dont j'ai parlé tout à l'heure, c'est seulement la troisième, extraire les données du tracker et les enregistrer et les sauvegarder comme des données agrégées. C'est ce que vous pouvez faire au niveau du troisième cas d'espèces. Pourquoi le faire? J'ai déjà introduit cela. D'abord, les avantages. Cela va permettre l'intégration des données trackers avec les systèmes d'emporting agrégés. Cela va soutenir l'analyse intégrée à travers les différents programmes de santé. Cela va soutenir aussi l'implémentation hybride et progressive. Cela va également soutenir les instances agrégées trackers séparées. Il y a aussi l'utilisation des données. Vous êtes entré d'installer des indicateurs de programmes pour analyser les données sur les enfants dans les programmes et de vaccination dans les programmes liés au pallidisme. Vous pouvez mettre en place des indicateurs de programmes comme ce que vous voyez ici. Mais il n'y a pas de catégorie comme c'est le cas avec les données agrégées. Lorsque vous avez les données agrégées et les données trackers et que vous voulez mettre dans un même tableau, cela ne marche pas parce que les données agrégées et les données trackers sont différentes. Si vous les mettez dans un modèle agrégé, vous pouvez avoir les cas de pallidisme des moins de cinq dans une catégorie avec les données collectées comme des données agrégées dans un seul tableau. Il n'y a pas de performance et je vais en parler un peu plus tard. Il y a quelques défis. Cela pourrait être compliqué. Il n'y a pas de fonctionnalité. Incorporé dans DHIC-2, la dernière diapositive n'est-ce pas concernée. C'est ce point pour voir comment on peut intégrer cette fonctionnalité. Vous avez besoin de nos typos pour transférer les données. Vous devez aussi cartographer vos données du tracker pour qu'elles soient agrégées pour connaître les indicateurs de programmes pour faire correspondre les différentes catégories. Nous avons les différentes fonctionnalités et je pense que ce sera beaucoup plus facile. Tant que vous avez les instances de DHIC-2, vous devez garder les unités d'organisation ce qui pourrait être un grand problème dépendant de l'implémentation ou du nombre d'unités organisationnelles que vous avez. Voilà le flux des données, les données du tracker qui sont collectées jusqu'à ce que vous soyez capables de les avoir au niveau de la visualisation des données, comme des données agrégées. Vous voyez, il y a les données qui arrivent et qui sont enregistrées différentes sources. Et puis il y a le processus d'analyse du tracker. Et puis ce n'est pas encore au niveau de l'agrégation, lorsque nous définissons les indicateurs du programme, par exemple les comptées et le nombre d'enfants qui reçoivent les 12. Et la demande par rapport aux analyses du données du tracker, c'est un peu long. Même si nous sommes déjà en train d'analyser les données du tracker, on n'a pas encore son nombre. Alors par rapport à la performance, voilà l'étape qui est problématique avec ces implementations du tracker qui sont vraiment immenses. Ce que le indicateur du programme est défini, nous pouvons extraire les valeurs des indicateurs du programme comme des valeurs des assemblées de données qui sont utilisées par des HST pour les données agrégées. Et nous pouvons les importer comme des éléments de données agrégées. Et puis nous pouvons analyser et nous pouvons utiliser cela pour produire des cartes, des visualisations et des tables de bord. Donc on voit là le processus pour aller des données du tracker vers les données agrégées. Il s'agit de l'exportation et de l'importation. Bien sûr, si vous changez quelque chose au niveau du tracker ou au niveau de la configuration des données agrégées, vous devez vous assurer que ça reste synchronisé. Dépendamment de la manière dont les modules sont implémentés, il va y avoir différents processus. Si vous avez des instances tracker et agrégées séparées, il y a plusieurs options. Vous pouvez exporter et importer dans la même instance. Vous avez votre instance, vous faites l'extraction et puis vous importez les données dans votre base de données agrégées. Ce que nous voyons comme la meilleure approche dans plusieurs situations. D'abord, vous faites l'agrégation dans votre instance agrégée pour avoir les données agrégées dans l'instance agrégée. Et puis vous faites le transfert un peu plus tard. Maintenant, les raisons qui expliquent cela. Maintenant, les avantages d'avoir les données du tracker dans la base de données agrégées. Vous avez, n'est-ce pas, des valeurs agrégées qui sont disponibles pour les utilisateurs du tracker pour l'analyse et la validation. Il y a aussi tracker vers l'étape agrégée. C'est plus facile pour contrôler et faire aussi la gestion. Maintenant, il y a également un certain nombre d'inconvénients. D'abord, je vais vous parler un peu de quelque chose de moins technique lié à l'implémentation. Vous avez participé à certaines académies sur le tracker. N'a pas pour l'intégration des données du tracker avec un système agrégé comme HMIS. Il y a un certain nombre de défis. D'abord, souvent, lorsque vous avez des formulés de reporting mensuels et que vous avez un programme du tracker qui couvre certaines régions, ce n'est pas facile. Pendant que vous avez des données sur la vaccination au niveau du tracker, vous aurez aussi des informations sur la communauté. Même si vous avez le tracker et que vous pouvez remplacer votre reporting de routine, ce ne suffit pas. Une autre chose dont j'ai déjà parlé, peut-être que vous n'aurez pas la même convertie géographique du tracker et d'HMIS. Il y a également différentes décisions qui ont été prises par rapport aux transferts de données d'agrégé vers le tracker. Comment on le fait ? Est-ce qu'on devrait le faire ébdomadèrement, mensuellement ? Est-ce qu'on devrait mettre à jour les données après trois mois par rapport à l'harmonisation des données du tracker et des données à l'agrégé ? Beaucoup de pays vont, n'est-ce pas, essayer de mettre à jour les données ? Le même type de questions par rapport à la qualité des données. Est-ce que vous devez analyser la qualité des données ? Il y a cette routine de générer le reporting agrégé à partir du tracker. Comment vous harmoniser cela ? Peut-être que vous allez mettre à jour vos données du tracker. Comment vous allez aller un an hier ? Il y a également cette question d'exhaustivité et de la punctualité dans le reporting. Comment vous allez savoir si vos données du tracker sont vraiment exhaustives ? Plusieurs questions qu'on se pose. Il y a également la question d'accès aux données et de l'appropriation. Qu'est-ce qui se passe là ? Est-ce que c'est agrégé ? Ça fait partie de la routine. Est-ce que ce sont les personnes qui sont responsables des données agrégées ou des données du tracker ? Comment les personnes vont avoir accès aux relations des données ? Plusieurs questions qu'on se pose. Il est aussi important de garder à l'esprit que si vous êtes en train de faire la transition pour avoir un reporting basé sur les cas. Vous aurez une période de transition où vous allez faire les deux types de reporting en parallèle, par exemple, ici je parle du reporting manuel et du reporting basé sur les données agrégées. Vous ne devez, n'est-ce pas, comparer les différentes instances et puis, j'ai déjà parlé de ça, c'est la problématique de vous assurer que vos configurations sont séchronisées. C'est quelque chose que vous devez garder à l'esprit. Et pour le moment, comme je l'ai déjà dit, on n'a pas vraiment de liste et encore pas aidant des HS2. Vous devez avoir des outils en dehors de des HS2 pour faire l'amélioration. Vous devez configurer cela, maintenir et mettre à jour un plus de des HS2. Et il pourrait y avoir des changements au niveau de des HS2 que vous devez prendre en compte. Il va y avoir des améliorations dans les prochaines versions et il faudra vous mettre à jour. Maintenant, parlons des packages de metadata. Vous en avez déjà entendu parler. Nous sommes entrés à essayer d'impuyer la cartographie dans les données, les régions et les données du tracker. Par exemple, les packages TB, nous avons déjà quelques outils qu'on utilise de ce sens. Je vais donner la parole à Claude pour ne pas vous en dire plus par rapport à cet outil, tracker to aggregate. C'est un outil qui n'a été développé par l'équipe d'interruptabilité. Est-ce que vous pouvez m'entendre? Super. Bon après-midi à tout le monde. Je m'appelle Claude et je suis un ingénieur informatique qui a contribué à la création de cet outil. C'est l'ISP, qui a commencé le travail sur tout ça. C'est un outil qu'on appelle TTA. Le tracker to aggregate, c'est un outil que nous utilisons pour récupérer les indicateurs de programme à partir de l'ISP et nous les renvoyons comme des valeurs d'ensemble de données. Il faut avoir Java et une machine que vous allez utiliser pour exécuter l'application. Vous voyez cet icône de l'heure. C'est vraiment un travail qui prend du temps. L'une des raisons que vous avez utilisé cet outil, c'est pour éviter les personnes qui ont déjà vu ce genre d'images pour éviter les problèmes et les utilisateurs mécontents. C'est probablement un server des HS2 sur George S qui pourrait avoir un impact sur d'autres opérations. On ne doit n'est-ce pas éviter un certain nombre de problèmes. Je parle de quelques packages qui ont déjà pris en compte ceci. On a essayé d'abriger ceci pour que ce soit facile à m'amoriser pour tout un chacun. On va essayer de créer un attribut PI. On va essayer de créer un attribut PI. On va essayer de créer un attribut PI. On peut créer des éléments de données agrégées pour les indicateurs de programme. On peut également essayer de mettre en place les programmes qu'il faut pour les données agrégées créées à l'état précédent avant de pouvoir assigner les indicateurs de programme pour les groupes de la salle et pour la salle. On va essayer de les dégager en un peu comment ça se passe. Maintenant, étape 1, 2, 3. Voilà un peu comment ça se passe. Maintenant on va essayer de parcourir chaque étape. Je sais que c'est un peu tard le soir pour l'indicateur de le programme, vous entrez dans la partie de DHS2, vous cliquez sur Attribute ou Attribue et ensuite, vous entrez les informations, vous faites créer un attribut EPI et vous continuez, j'espère que nous sommes tous familiarisés avec l'écran ici, donc c'est très simple. On a cela pour la diapo suivante. Après avoir fini la première étape, il faut maintenant créer des éléments de données agrégées. Ceux-ci, ces éléments-là seront utilisés plus tard dans l'indicateur de programme et dans ce cas, on crée un élément de données agrégées qu'on appelle CBC, BARD-8, EER, BARD-2-8, AGG, BARD-2-8, PPL, BARD-2-8, ST, BARD-2-8, DOS. Il faut garder ce code à l'esprit parce que ce sera utilisé à la prochaine étape. Donc le type est agrégé et j'espère qu'on est quand même en train de suivre parce que la plupart des éléments du tracker sont agrégés. Merci. La prochaine étape, il faut pouvoir cartographier les indicateurs du programme pour que cela devienne aider les éléments de données agrégées. Vous voyez ici, on répète encore le même code. Je vous ai parlé et j'ai attiré votre attention là-dessus. Le code ici en bas, ça vient de cette deuxième diapo, c'est revenu sur la troisième diapo également. Et la dernière étape, la configuration d'un DHS-2, c'est pour assigner les indicateurs du programme au groupe. Il peut avoir un nouveau groupe que vous avez créé ou un groupe qui existe déjà. Vous allez voir qu'on va essayer de référencer les identifiants dans le groupe. Donc je vais essayer de répéter les étapes parce que je pense que cela est déposanté dans les packages déjà. Je vais me répéter un peu et permettre moi d'entrer dans les spécificités. Maintenant, sur la partie logistique, il faut partir sur la page guitare de DHS-2. Vous cliquez, vous tapez ETA et puis vous cliquez sur la première chose qui vient. Vous partez sur la page et vous cliquez le JAR. Vous pouvez voir qu'il y a la flèche qui montre exactement sur quoi il faut cliquer. Maintenant, une fois que vous avez téléchargé cela, vous êtes sûr que Java est installé dans votre ordinateur ou vous allez le lancer, vous pouvez le lancer de cette manière. Il faut prêter très attention à ce qui est affiché à l'écran. J'assure que chacun peut bien voir les paramètres qui sont à l'écran. Ce n'est pas très compliqué, c'est assez large. Donc voilà le nombre de paramètres pour pouvoir quitter des données, voir le traqueur agrégé. Nous avons le API Web de DHS-2. Ils ont le nom d'utilisateur et c'est un mot de passe. Ensuite, probablement cela va changer en une sorte de token API dans la prochaine version parce que c'était la recommandation pour que les gens puissent s'identifier avant d'entrer dans DHS-2. Donc maintenant, vous voyez l'indicateur de programme au niveau de org-unit. Ici, en particulier, le traqueur-to-aggregate va faire l'exportation. Dans ce cas précis, nous sommes en train d'extraire les indicateurs de programme au troisième niveau de l'unité d'organisation. Et la même chose s'applique pour les périodes. Pour quelle période est-ce qu'on va faire l'exportation ? Ici, on voit des périodes qui sont affichées, mais ça peut être absolu ou limité. C'est à vous de décider. Ensuite, il y a l'identifiant des programmes de groupes en bas. Donc ici, c'est tous les indicateurs de programme dans ce groupe. Et donc, ce sera extrait aussi, ce sera exporté. Voilà comment est-ce que cela marche. Maintenant, il y a des paramètres optionnels. Ça, c'est un job. Il faut garder ceci en tête. Je crois que vous pouvez bien apprécier ce qui est affiché. Il y a un site web où on peut traduire le temps en expression croon. Également, on peut lancer de manière manuelle le job ou le travailler. Vous pouvez entrer l'application dans le HTTP, dans le navigateur web. Et également, vous pouvez spécifier l'adresse du job. S'il vous plaît, il ne faut pas exposer cette application au monde entier. Il faut que ça se fasse dans un HTTP sécurisé. Parce que, si ce n'est pas le cas, il y a des choses inattendues qui se produisent, comme des gens qui vont à chaque fois relancer la même activité encore et encore. Maintenant, ce travail peut prendre beaucoup de temps. Mais on l'a fait espérer pour éviter que le serveur ne soit pas surchargé ou que le serveur ne soit pas détruit. Donc, ça prend beaucoup de temps pour pouvoir accomplir cette tâche. Ça dépend du nombre d'entités traités que vous entrez et des expressions PIA et que vous avez. Et le nombre de périodes que vous avez également, même que les unités d'organisation. Pour avoir un bon temps, on a mis des paramètres qui permettent de réduire la communication qu'il y a du tracker vers l'agrégat. Nous avons trouvé comment réduire un peu le temps. Vous voyez un exemple de comment on utilise une shell, une unité organisationnelle, où on essaie d'extraire chaque API pour chaque unité d'organisation. Et à chaque fois, nous faisons des exportations, des indications de programme pour les unités d'organisation à chaque fois. Donc, vous pouvez le faire autant que vous faîtes le peu. Mais, s'il vous plaît, vous pouvez détruire le serveur si vous répétez l'action encore et encore sans s'assurer que chaque activité est menée à son terme. Donc, il faut attendre que l'activité se termine avant de lancer une autre. Pour ceux qui aient des périodes, j'ai oublié un peu ce dont parle la diapo. Je vais m'attendre à réfléchir un peu. Pour ceux qui aient des périodes, c'est là par défaut. Ça va extraire des API à chaque fois. Ça va envoyer des messages, des requêtes à chaque fois. Si vous laissez ce qui est là par défaut, ça va agriger les demandes ou les requêtes en une seule requête pour également réduire la période. Également, vous pouvez utiliser pour réduire le temps d'exécution. Je vous dis encore de faire très attention. Il faut éviter de surcharger le serveur pour que le chargeur ne puisse pas cracher. Il y a d'autres paramètres encore, mais je ne vais pas en parler parce que je ne veux pas qu'on puisse s'ennoler devant la présentation. Je peux vous dire que quand on part dans le DHQS2, on peut voir ce que j'ai expliqué avec l'application à côté. On peut mieux comprendre en détails ce dont je viens de parler. Je vous en remercie. Merci beaucoup. Il y a une seule diapo qui reste. Elle concerne la fée de route pour comment faire ceci dans le DHQS2. La fonctionnalité backend pour faire le transfert tracker vers l'aggregat. C'est prévu pour la version 2.39. C'est une fonctionnalité backend. L'Oscura et UI, on va confirmer cela. Le plan ici, c'est la configuration de cette cartographie pour faire le tracker to aggregate pour qu'on puisse importer et exporter les métadonnées dans DHQS2. C'est pour permettre que nous ayons des éléments qui sont autonomes. Les avantages, c'est que cela s'exécute de manière interne et pour que ce soit encore plus performant. Cela ne passe pas par les API du web. Cela fait en sorte qu'on peut prévoir le tracker to aggregate dans le DHQS2 pour ce qui est des activités ou des jobs. Cela nous permet de pouvoir exécuter plusieurs activités de manière parallèle pour une meilleure performance. C'est fait avec cette fonctionnalité du DHQS2. Nous avons prévu des possibilités pour l'autopartitionnage des indicateurs de programme pour utiliser moins de mémoire. Comme je le disais, pour les questions d'authentification, il faut éviter que ce ne soit pas fait en dehors de DHQS2. Cette fonctionnalité nous permet de le faire dans une instance comme dans une autre. Cela signifie qu'il faut désormais des mots de passe pour pouvoir y avoir accès. Voici un peu le plan. Est-ce que vous avez des questions concernant ce que vous venez de suivre si vous êtes toujours vivant avec nous? En réalité, nous aussi, on fait un truc assez similaire. Il a donné à voir que j'ai demandé, il n'y avait pas de soutien pour les attributs. Est-ce que maintenant ce serait disponible dans le nouvel outil dont vous avez parlé? On devait faire l'implémentation cette semaine, mais ce sera probablement la semaine prochaine pour l'implémentation. Merci. Je comprends le bénéfice de pouvoir combiner les traqueurs avec les données agrégées, mais la question c'est de demander le bénéfice pour ce qui est de la meilleure action de l'efficacité du tableau de bord. Je pense que si vous avez un traqueur large qui ne prend pas en compte les données agrégées, je pense que ça ne va pas vous aider parce que quand on essaie de rendre les données agrégées, ça vous aide pour ce qui est du traqueur plus tard. Le micro de l'orateur s'il vous plaît. Nous avons dit que l'exécution est unique, on n'a pas besoin de repartir à chaque fois dans l'API, et puis les tables de bord c'est une diapo que j'aurais dû ajouter, mais dans le tableau de bord vous lancez les éléments de le faire via l'API. Donc on parle du traqueur vers l'agrégat, c'est-à-dire que vous exécutez le programme une fois pour les éléments de données et l'API, et puis on utilise les données dans les analyses. Je crois que vous avez parlé également de données agrégées, mais nous faisons le face au combo de catégorie. Oui, je veux dire que c'est dans les indicateurs du programme, c'est l'un des attributs pour les programmes, c'est-à-dire que ça prend en compte les combos pour pouvoir les exporter, et également ça fait partie des indicateurs du programme. Maintenant, les attributs défendent les éléments de données, et nous réussissons à en tirer le meilleur. Une autre question en ligne qui nous demande comment est-ce que, si on peut parler plus de Apache Camel. Bon, pour ce qui est de Camel, on peut l'utiliser pour améliorer la performance des opérations en parallèle, c'est-à-dire qu'on peut diviser les opérations dans Camel et ça exécute les opérations de manière parallèle, et c'est à dire qu'il y a une autre personne qui demande de mettre la diapo sur Sked, donc oui, ça sera fait. A Kato Gluget a utilisé à plusieurs endroits, c'est pas nouveau, mais on a plusieurs solutions, donc vous nous avez démontré une solution, mais ça signifie qu'on exécute cela en arrière, avant de lancer cela. On ne demande pas que les attributs créent la cartographie, donc on utilise un predictor pour faire la cartographie, parce qu'avec le predictor, on peut déterminer les données qui doivent être prises en compte, de même que les différents combos. Donc on utilise cela pour la cartographie et maintenant des services externes, on essaie de mettre les données ensemble. Donc ce que je voulais savoir, c'est que, qu'en est-il les predicteurs et les performances, selon vous? Ce qui est sûr, je pense que quand on compte la cartographie, ce serait une bonne solution quand même. Oui, je suis parfaitement d'accord avec vous, c'est très possible d'utiliser les predicteurs pour pouvoir diviser et définir les indicateurs de programme et spécifier les éléments de données. Et la raison pour laquelle on est vus de faire les choses à l'extérieur, c'est que la performance n'était pas comme l'espérant dans les versions en s'est rendu compte qu'on pouvait faire de l'amélioration. Je crois maintenant qu'on peut créer les predicteurs, donc je ne pense pas que ce serait de l'effort. Je devais parler de la cartographie également, qui aide à générer les indicateurs de programme lorsque vous avez des agrégations, ça vous permet d'éviter de répéter les expressions d'indicateurs de programme encore et encore. Et Pete a fait un travail là-dessus qui est disponible pour éviter que vous puissiez répéter de manière manuelle les équisitions des indicateurs de programme. Comme vous dites qu'on peut retrouver cela sur la plateforme, je voulais quand même demander qu'on ait dit de la création des groupes de programmes pour l'importation et l'exportation des données. Je pense que c'est très possible quand même. Est-ce qu'il y a une dernière question ? Non, je crois que nous sommes arrivés à la fin de cette session. Je vous en remercie.