 Merci à tout le monde, bientôt nous allons commencer et on attend jusqu'à certaines personnes, puis c'est une rejoindre d'abord. Bienvenue pour ce troisième jour, je me suis Mike Foster et puis je suis en charge du tracking, de la partie tracking ici à l'université de Oslo. Maintenant je vais laisser la parole à mon collègue Bob pour qu'il commence à parler. Pour vous expliquer ce que nous allons faire, nous allons vous demander où est-ce que DHS2 puisse soit un matière de gestion d'information sanitaire par exemple. Donc il y a souvent des requêtes qui nous parviennent pour savoir comment est-ce que nous catégorisons DHS2 pour savoir si nous sommes plus dans le domaine sanitaire ou si cela peut être agir avec d'autres systèmes. Il est vrai que c'est très difficile de définir cela. Il y a beaucoup d'efforts qui est consenti de la part du monde entier et avec nos SPR, même s'il y a DHS2. Donc on travaille toujours ensemble, donc la plupart du temps notre mission c'est d'abord de donner du soutien au ministère de la Santé partout dans le monde et c'est un aspect très important de la raison pour laquelle DHS2 est un succès. C'est pour cela que nous travaillons pour pouvoir aussi répondre aux exigences des uns et des autres. Donc voilà ce que je veux dire mais il ne faut pas oublier que cela peut s'appliquer à d'autres domaines. C'est aussi important de savoir que DHS2 est ouvert avec tous les sources open source pour pouvoir interagir avec ce dernier. Donc dans tous les pays, dans tous les environnements, partout il y a une architecture ou une entreprise où je fais de mettre en contact plusieurs systèmes nous mettons en place un système qui permet à DHS2 de pouvoir intégrer d'autres logiciels dans différents pays. Donc nous avons une nouvelle page web dhs2.org slash interopérabilité non non c'est slash intégration. Mais en français donc aller là-bas vous allez avoir beaucoup d'informations sur cette session avec les détails et vous allez voir aussi que nous allons faire des mises à jour là-bas en donnant les ressources et les lignes en matière d'interopérabilité et notre intention c'est de faire en sorte que DHS2 puisse répondre à votre besoin dans votre pays dans votre projet. Donc Bob Joliefe va commencer à nous parler. Il a travaillé depuis en tant que ingénieur pour la mise en place de DHS2 à Oslo pendant plus de 20 ans et il travaille en tant que sorte avec le leader en matière d'interopérabilité pour la prise de décision et pour donner les réponses dans le moment et il aide aussi à former les administrateurs du système dans vos pays différents et ça permet il aide aussi à bâtir une communauté forte en reliant des utilisateurs DHS2. Donc il nous rappelle à plus part du temps le besoin d'être aligné avec, d'être en conformité avec les normes dans le monde entier. Donc nous allons lui donner la parole et il va faire sa présentation parce que c'est pour nous un honneur de recevoir Bob aujourd'hui. Pour cette session il va nous parler de son expérience. Comment est-ce que nous allons intégrer DHS2 dans le système sanitaire. Donc avoue la parole Bob. Merci Mike pour cette introduction, cette présentation. Bonjour, vous avez tous les bienvenus, bonsoir, bon après-midi selon à vous vous trouvez. Oui, comme il a dit, ce que je vais faire c'est donner un peu de background, de contexte de là où nous venons en termes de comment est-ce que nous percevons l'intérêt opérabilité. Et je veux utiliser cette session comme un appel et j'espère qu'il y aura des réactions venant de tout un chacun de vous. Donc sans plus tarder, nous allons commencer. Je n'ai pas mis de titre, quelques seuls pour, je ne vais pas parler du titre, nous allons aller directement au fond du sujet. Mais sachant que ça va avec l'écosystème de l'information sanitaire. Donc, merci. Vous êtes les bienvenus. Nous allons vous montrer deux diapos sur l'intérêt opérabilité, les fonctionnalités de DHS2 et nous aurons aussi des compréhensions des métadonnées. Les principes d'intérêt opérabilité aussi. Nous allons présenter les principes de l'intérêt opérabilité. Commençons par l'écosystème. J'espère que l'image ne dérange pas certains parce que je trouve ça intéressant. L'écosystème, c'est un concept biologique. Définie sur Wikipedia comme un organisme, une communauté d'organismes vivants dans une conjonction avec des composantes non vivantes dans leur environnement. Mais ils interagissent tous ensemble dans un même système. Nous allons commencer. Le concept d'écosystème numérique vient du concept biologique d'abord. C'est le sujet à voir avec les problèmes de compétition et de collaboration des personnes qui sont dans les grandes organismes. L'écosystème numérique est intéressé dans les propriétés des organisations de la durabilité et la résilience. Il est souvent utilisé dans le contexte des API et des plateformes. Par exemple, DHS2 est une plateforme qui facilite la croissance d'un écosystème qui l'entoure. Je veux un peu revenir en arrière pour vous expliquer que cette métaphore d'écosystème a beaucoup de sens. Premièrement, savoir avec les systèmes d'information sanitaire précisément l'architecture de ce système. Ils sont produits par les actions délivrées des hommes. Quand vous voyez la production, vous devez prendre en considération qui est en train de faire la production et en train de produire pour qui. L'objectif du système, c'est de renforcer la capacité des employés sanitaires pour améliorer les réponses en matière sanitaire. Ça n'a pas trop à voir avec le fait de faire accroître les affaires. La métaphore est très intéressante. Ça peut nous aider à atteindre nos objectifs et à améliorer les raisons d'être de cet écosystème. Nous ne voyons pas la création de l'écosystème comme une fin en soi ménouvence, comme une sorte de proposition pour pouvoir nous en sortir dans plusieurs domaines. L'interoperabilité n'a pas à voir avec la création d'écosystèmes, mais ça peut aussi signifier comment nous l'utilisons et comment nous procédons. Ce système est un peu différent du système traditionnel que nous utilisons pour nos projets. Tout le monde est assez familier avec les projets collaboratifs dans leurs différents pays. Ces projets ont à voir avec l'action humaine. C'est une action sociale et humaine à la fois. Ça permet de comprendre que c'est ça qui mène au projet collaboratif. C'est quoi le projet collaboratif en DHS2 ? La plupart des gens qui sont au courant de la méthodologie et l'histoire de HISP doivent bien comprendre ce qu'on veut dire en parlant de projets collaboratifs. Cela implique la formation des projets collaboratifs entre les différents acteurs, que ce soit les travailleurs, les fonctionnaires de santé, ainsi de suite. HISP a été caractérisé par des projets collaboratifs mis en place au sein de HISP comme entité et le ministère de la Santé dans les différents pays et surtout en Afrique. Ce concept nous permet de comprendre cette notion de projets collaboratifs qui impliquent la solidarité. La solidarité était, je crois, une base fondamentale de la collaboration, de la raison d'être. Pourquoi est-ce que nous apportons ces projets collaboratifs dans le monde ? Un autre concept qui fait partie du folklore de HISP, c'est les réseaux d'action. C'est une recherche faite par Eric Monteiro, dont on peut voir le lien à l'écran, qui a reconnu le projet collaboratif comme une entité en soi qui doit être perçue de manière un peu plus globale. Il faut alors des projets collaboratifs un peu plus larges dans les différents pays et dans les différents secteurs. Donc, la notion première du projet collaboratif était centrale à notre mode d'action. Récemment, le domaine d'intervention des collaborations et des projets collaboratifs en général engage plusieurs et donc c'est devenu plus complexe. À un moment donné, nous étions impliqués dans différents types de projets de manière simultanée, certains très larges et certains très petits. Je pense aux projets collaboratifs, des fois, comme l'un des prototypes le plus facile. Ça suffit tout simplement le fait de travailler ensemble, de mettre des gens ensemble qui décident de travailler. C'est un concept que les humains connaissent parce qu'on a toujours travaillé depuis des millénaires jusqu'à aujourd'hui. Cependant, les gens viennent ensemble, se remettent ensemble avec des raisons pour collaborer sur des différentes activités. Et présentement, en matière de collaboration à grande échelle, nous avons l'OMS, PEPFAR, l'UNICEF, entre autres, qui collaborent avec des producteurs d'applications ou de programmes numériques comme OpenHI, OpenMRS, Daivoc qui travaille par exemple sur la certification COVID, RapidPro, qui a aussi une longue histoire de collaboration avec ses organisations. Je pense que c'est le fait de collaborer tout simplement, donc il est question. Nous parlons ici aussi des API qui voient un peu ce qu'il y a à faire et comment le faire. Et cette initiative était un succès et c'est pour cela que nous encourageons cela parce que nous savons que les API travaillent avec les documentations et nous avons vu comment est-ce que cela a été bénéfique. Parfois, nous sommes engagés dans des interactions face à face avec des différents producteurs pour pouvoir avoir une approche commune, des paramètres communs. C'est assez cher, je pense, et les années dernières, on a eu plusieurs discussions avec RapidPro, par exemple, pour pouvoir s'entendre sur ce qu'il y a à faire. Donc c'était une opportunité que nous avons pour pouvoir collaborer. Nous avons aussi, avec Bivoc, eu des discussions. C'est vrai que c'est très cher de pouvoir collaborer avec ces institutions-là parce qu'il y a un risque, parfois, quand on est en train de discuter entre nous qui développent des applications parce qu'on ne le sait pas très bien comment est-ce que l'application peut être bien utilisée dans un contexte, mais nous reviendrons sur le sujet un peu plus tard. C'est sûr et c'est important de noter que les relations avec les autres parties sont très importantes. En troisième point, les types d'engagement ou le niveau d'engagement, ça montre que nous avons des perspectives architecturales à très long terme. Quand nous avons parlé avec Open Echaï depuis le début, ça montre quand même que nous avons un projet à long terme. Ça fait de cela plus d'une décennie que nous sommes en contact avec eux. Mais ce qui a dit ici, c'est que dès le début, lorsque le projet collaboratif a commencé, que c'était simple et caractérisé par ce que nous avons dit, ces collaborations sont devenues un peu plus complexes à travers le ton. Mais parmi les difficultés, nous allons parler, je crois que ça fait environ 20 diapos, mais bon, nous allons essayer de les résumer premièrement. Donc le fait de garder les projets collaboratifs assez solidaires avec les ministères de la Santé est très central dans notre engagement. Et des fois dans l'excitation d'avoir de nouvelles technologies nous excite tellement qu'on en oublie l'essence de la solidarité. Le fait de rester en contact avec la base est très important pour les groupes HISP, précisément ces derniers qui ont une meilleure compréhension de l'architecture, des problèmes sur le terrain, qui en plus de connaissances que nous qui sommes à Oslo. Donc nous faisons tout pour pouvoir rester en contact avec les communautés de base aussi. La rationalisation du temps et de l'effort, nous avons parlé de beaucoup plus de recrutement, le besoin de plus d'interruptabilité avec les ingénieurs entre autres. Cela peut nous faire perdre beaucoup de temps, cependant nous faisons tout en ayant des discussions face à face avec des personnes ressources pour pouvoir prendre des décisions appropriées. Nous avons aussi des difficultés en matière de normes parce que de notre perspective, nous pensons que c'est très important de pouvoir simplifier l'intégration d'interruptabilité. Et nous avons participé dans EDX qui est un comédie technique du développement des objectifs, des données agrégées et aussi DOGESON, WMS slash TMS aussi. Donc nous avons tous fait pour leur apporter notre soutien. Nous avons quelques difficultés toujours quand même avec FHCR, mais nous allons bientôt, je laisse faire trouver des solutions parce que cela n'a jamais été facile. L'autre difficulté que nous avons, c'est que plusieurs personnes savent que DHS2 peut faire beaucoup de choses même si on n'a pas pour ambition de tout faire à la fois. Nous travaillons quand même pour nous améliorer. Donc nous travaillons avec un groupe logistique qui essaie de faire une démarcation entre les LMIS qui nous fait comprendre comment est-ce que avoir une interface aussi claire comme DHS2 qui est interagée avec les autres systèmes est très profitable. En termes de fonctionnalité d'interruptabilité, pardonnez-moi. La chose la plus importante, c'est de parler de REST API qui est une fonctionnalité de DHS2 qui est exposée au travers des appui. Ça a pris forme aux environnes de 2011-2012 et les API exposent la plupart du temps les fonctionnalités de DHS2 parce que c'est souvent utilisé par les sous-applications de DHS2 et les fonctionnalités sont bien affichées. La documentation est en cours de production et présentement nous pouvons dire que nous avons assez de données et c'est assez complet. Mais nous ne pouvons pas nous vanter du fait que c'est complet à 100%. Ce qui est sûr, c'est que c'est acceptable pour qu'on puisse avoir accès à des fonctionnalités d'interruptabilité. Cependant, nous allons le faire pour être beaucoup plus rigoureux. Donc, il y a DHS2, un modèle de méthode de données très flexible et c'est une bénédiction. C'est un aspect très pertinent pour l'aspect d'interruptabilité. Nous avons pris plusieurs identifiants pour être capables de faciliter encore ce modèle. Nous avons beaucoup de perspectives pour les notifications. Ce que nous pouvons faire avant, nous ne pouvons pas envoyer des SMS. Avant, pardonnez-moi, nous pouvons seulement envoyer des SMS et des mails. Mais maintenant, nous avons essayé d'insérer beaucoup plus de logiciels parallèles permettant de pouvoir échanger plus facilement. Présentement, ZAPI, c'est comme de la crème, mais vous avez besoin de quelque chose pour pouvoir en quelque sorte léchir cette crème. Donc, pour cela, comme nous avons, c'est Webhooks qui permettent de pouvoir gérer des événements dans le système. À part le niveau syntaxique, qui sont les API, entre autres, l'interruptabilité pour que cela fonctionne, vous devez entrer dans la sémantique elle-même, de ce qu'est les données. Ce qui est clair, c'est que quand vous partagez les données entre plusieurs systèmes, vous devez faire des prépositions et il y a une certaine compréhension mutuelle du pourquoi de la structure des métadonnées. Et cela consiste dans la facilitation des identifiants. C'est toujours un début d'essayer d'échanger les données entre deux systèmes ou cinq. Nous avons besoin d'avoir une bonne compréhension de comment identifier ces établissements d'abord. Dans les éléments de données qu'on essaie de traquer et tous ces paramètres-là, pour les facilités, il faut avoir une meilleure compréhension des fonctionnellements des systèmes qui interagissent. Toutes nos communautés, pas que ceux qui sont proches de nous, mais tous les utilisateurs de l'HIS2, ont fait face à ces difficultés dont nous parlons en matière de la structure des métadonnées durant les années précédentes. Donc l'enregistrement des établissements était assez lent par le passé et ce n'était pas très facile. Nous n'allons pas trop détailler cela, mais nous tous connaissons l'historique de ce qui est l'enregistrement des établissements. Pour les services de terminologie et puis la normalisation des systèmes de code, il y a ICD-11, et MEDRA qui nous ont permis à utiliser par les tant que cours les systèmes de code qui répondent aux normes. Les métadonnées que nous avons ne répondent pas toujours au code standard qui existe sur le marché. Mais nous travaillons en quelque sorte pour éviter ces conflits qu'il y a entre les codes et les licences que nous détenons afin de permettre aux métadonnées de pouvoir être bien utilisés et bien gérés. DHS-2 durant les dernières années, ce que vous savez je pense, c'est que ces paquets ont commencé avec les collaborations entre l'Université de Slo et l'OMS et l'objectif selon moi c'est qu'on a autorisé des configurations très simples et rapides de DHS-2 selon les guides de l'OMS en matière de tuberculose, paludisme et de VIH. Et les bénéfices de cela c'est que tous les utilisateurs qui utilisent ces paquets, peuvent tirer profit de ces indicateurs pré-designés comme les graphiques et les tableaux de bord qui sont dans la version normalisée des métadonnées. Il y a eu quand même des effets négatifs et désirables, c'est qu'on voit les nombres de systèmes qui ont quasiment le même packaging de métadonnées et ce n'est pas facile de désigner les flux d'échange des données. Ce que nous allons faire c'est qu'avec EDX, DHS-2 et même avec FHCR, quand vous avez une sorte de standardisation ou de normes, cela devient en quelque sorte un objectif d'interroberabilité pour pouvoir intégrer ces variables. Nous en avons parlé les années précédentes. Ce que nous avons vu aussi concernant les paquets de COVID et de VIH, c'est de tout faire pour apporter les données au comité de la santé publique pour pouvoir prendre des décisions. Il y a un travail qui est en cours dans l'équipe de package qui essaie de voir comment et dans quelle mesure on va améliorer la terminologie standard. Vous savez parfois c'est difficile de trouver le juste milieu. Maintenant on va parler un peu de FHCR, qui est appris de la valeur durant les cinq dernières années. Je sais que les gens qui voyagent par bon et moi ont investi beaucoup de temps et d'effort durant les cinq dernières années pour découvrir ce que c'est. C'est très intéressant de voir que plusieurs personnes travaillent avec cette organisation, avec le FHCR, pour pouvoir modéliser et même comprendre son fonctionnement. Ce n'est pas facile de prendre en considération tous les variables. Il y a plusieurs domaines comme l'éducation mais aussi dans la sécurité alimentaire tout en prenant en considération le package de FHCR qui n'est cependant pas en conformité avec tous nos cas d'études. Il y a un adaptateur FHCR qui a été développé à 2019 pour l'équipe d'intégration dont nous allons parler dans la session interoperabilité qui viendra bientôt mon collègue à développer plusieurs scripts d'interoperabilité. Donc je pense que c'est ça qui a permis la présentation des valeurs d'un DHS2. Malheureusement nous avons vu peu d'adoption sur le terrain. Les échanges entre DHS2 et FHCR ça donne l'impression qu'on se perd un peu parce que les modèles de données ne sont pas toujours signés à 100% mais pour le moment la plupart des interoperabilités qui se produisent se limitent la plupart du temps sur les périphéries et cela peut changer avec le temps mais ce n'est pas encore le moment. Donc nous suivons le travail qui est en cours avec l'OMS en matière de guide. Maintenant je vais parler de OpenHI parce qu'on peut parler d'interoperabilité sans mentionner OpenHI. Une des choses que je trouve assez importante c'est qu'il n'y a pas le DHS2 et OpenHI parce que quand on ouvre le DHS2 c'est un peu de variation. On a vu dans OpenHI que ce n'est pas ce à quoi on peut s'attendre dès le départ. Nous avons commencé à collaborer avec eux un peu au début de leurs activités et OpenHI est très pertinent pour engager des discussions et voir l'architecture qui est très important parce que c'est perçu comme le travail même de l'architecture. OpenHI a été une plateforme très importante qui a amené les architectes ensemble pour harmoniser les procédures et résoudre des problèmes assez complexes. OpenHI c'est beaucoup plus en matière d'architecture. On ne voit pas toujours le logiciel mais c'est pas un logiciel qu'on peut télécharger et installer mais je pense que ça peut être dans l'heure perspective. Dans le DHS2 il y a cette partie concernant l'enregistrement des établissements et des HMIS dans les sous-communités. Récemment j'ai essayé de l'expliquer pour qu'on comprenne. Nous avons vu beaucoup d'engagement des autres équipes avec les différentes communautés dans les systèmes d'information de gestion sanitaire et les équipes de packaging lors de certaines sessions où on a essayé de s'entendre parce que parfois je n'ai pas mentionné les utilisateurs. Il faut comprendre que c'est une collaboration long terme en matière de systèmes d'information et de gestion sanitaire. C'est des discussions en matière d'architecture de forme que nous avons pour le moment. J'aimerais parler de certains exemples d'interoperabilité avant même de penser au fait que très bientôt nous allons commencer la saison suivante donc il faudrait aller un peu plus vite. Il y a des présentations très intéressantes qui vont suivre avec les cas au Burkina Faso où il y a eu des utilisations assez intéressantes, des données périphériques jusqu'aux données adrégées. C'est des cas d'utilisation concernant les maillards et ces présentations auxquelles nous avons assisté plus tard. Nous avons essayé de travailler ensemble parce que c'est le seul moyen pour pouvoir nous améliorer. Voilà un peu ce que nous allons dire dans la session interoperabilité. Les sessions suivantes sont un peu plus intéressantes. Je suis sûr parce qu'on va parler du Open Function, donc la fonction ouverte qui permet d'intégrer beaucoup de logiciels. Il est très possible que nous allons terminer, finir par utiliser ces supports open source comme logiciels qui nous permettent de pouvoir résoudre les difficultés numériques en matière de gestion des épidémies comme la COVID-19. Je vais bientôt terminer ma présentation, mon exposé, en vous donnant des principes qui vont commencer par nos galvanisies en tant que communauté d'HIS2. Ce serait intéressant d'avoir des feedbacks venant de vous. Dans les dernières années, nous avons vu plusieurs développements parce que nous étions impliqués dans plusieurs projets et certains d'entre vous ici présents, je suis sûr, sont au courant de cela. Et l'HIS2 est très loin d'être parfait. C'est l'un des parfaits, il y a beaucoup de travail à faire encore, mais nous espérons bien que nous sommes dans la bonne direction parce que nous galvanisons les équipes sur les six principes de notre entreprise. Je crois que nous allons nous arrêter ici, mais d'abord je veux voir ce que je suis en train de faire. Ce qu'il y a à dire, c'est que le rôle de l'HIS2 et de l'HIS2 a eu une mission historique durant les 25 dernières années en matière de solidarité avec les équipes dans le monde. Je vais retourner un peu sur la page concernant les principes pour vous aider à mieux comprendre ce dont il est question. Nous pouvons voir, je crois que c'est un diapo numéro 4 au numéro 11. Permettez-moi de mettre un mot de plein écran. Voici les principes et j'espère qu'on les voit. Dans le premier principe, je crois que c'est le plus important, c'est que nous voulons rester devant en matière d'interopérabilité. Parce que l'HIS2 a pour objectif de pouvoir rester solidaire avec les partenaires dans les différents pays. Parce que le fait de rester en contact avec nos partenaires dans les pays est très fondamental pour qu'on puisse atteindre notre objectif. Donc si nous avons pu identifier les valeurs d'interopérabilité avec les utilisateurs finons. Nous avons vu malheureusement trop de projets d'interopérabilité où les données ont fini par cracher une raison ou pour une autre. Mais nous essayons alors de garder tout cela de manière centrale dans un même serveur en quelque sorte pour pouvoir mieux sauvegarder les données. Parce que la plupart du temps, les gens disent que nous préférons ce système par rapport à l'autre. Mais il faut savoir ce pourquoi nous faisons tout pour que ce soit plus facile à manipuler pour les utilisateurs finaux. Nous essayons de garder cet équilibre à notre niveau pour voir le type d'engagement qu'on veut voir. Et on essaie d'encourager nos partenaires HISP partout dans le monde pour qu'ils puissent nous faire aussi des retours concernant leur objectif. Ensuite, c'est que quand on parle d'intégration, on commence à discuter avec les vendeurs d'application ou les développeurs d'application. Il fait mieux d'abord de commencer à avoir des discussions de données avec les contrôleurs de données, les gestionnaires de programmes en ce qui concerne l'utilité des flux des données. Donc il faut mettre un accent très clair sur l'utilisation des données et c'est ce qui renforce l'interrobéabilité. Et c'est ce qui permet d'avoir plus de discussions avec les vendeurs de l'OICL pour savoir ce dont vous avez le plus besoin. Une chose encore importante au niveau en matière d'architecture, c'est le niveau d'architecture du pays et savoir qui est en charge de cette architecture dans les équipes HISP. Donc nous travaillons avec les architectes des pays qui sont plus ou moins en charge dans nos équipes HISP pour pouvoir faciliter les activités. Parce que nous avons des équipes HISP dans tous les pays et nous faisons tout pour qu'ils soient impliqués dans les discussions d'architecture et qu'ils ne se vocalisent pas uniquement sur l'utilisation de données HISP et numéro 6. Nous trouvons que c'est très bénéfique pour nous de participer dans les collaborations à l'échelle mondiale pour pouvoir avoir plus d'assises sur le terrain. Nous collaborons dans tous les processus que sont en matière d'interrobéabilité, que de l'architecture, que d'aide. Donc c'est ce que j'avais à vous présenter. Ce que je trouve intéressant ici, c'est essayer d'avoir certaines réactions, surtout sur nos six principes, pour voir si cela vous êtes profitable ou si vous avez besoin de plus d'élaboration. Mais je crois que c'est tout ce que j'ai à dire pour le moment. Merci Mike. Nous avons aussi John Lewis qui a levé la main. John, tu peux enlever le point, enlever le silence et puis dire s'il a tort ou pas. Vous savez, il n'a pas tort. Ce six principes sont très intéressants. Nous l'avons accepté dans la communauté de la CS2, mais je pense qu'il faudrait mettre un jour en quelque sorte pour que chacun puisse comprendre les normes dont il est question, que son matière de reconnaissance, que les autres. Ce qu'il y a, c'est que quand on est dans le ministère de la Santé, par exemple, dans notre pays, on voit qu'ils pensent que les normes, voici peut-être telle norme, qui s'applique peut-être à vous à DHSU, donc pour eux, ils pensent la plupart du temps que je vais vendre des logiciels, que c'est des normes uniquement appliquées à DHSU. Or, ce n'est pas nos normes. C'est des normes dans le monde entier qui demandent comment gérer les données. Nous, à DHSU, on essaie juste d'adopter ces normes-là. Nous n'inventons pas des normes. En tant que communauté, nous avons des paquets, comme celui de l'OMS. Si il est possible, on a des normes à côté parce qu'il y a les normes à l'échelle mondiale, comme on voit ce qu'il est de l'enregistrement des établissements, ou l'enregistrement des données en matière de COVID. C'est la meilleure chose à faire de retourner dans 20 ans, essayer de mettre en place des normes qui ne répondent pas aux exigences de notre siècle. Dans certains de nos pays, le message n'arrive pas là-bas. Quand on essaie de leur parler aux équipes RISP, ils ont l'impression que c'est des principes ou des normes de DHSU et non des normes mondiales. C'est ce qu'il faut quand même noter. Quand vous parlez de normes ou de principes, c'est ça. Je crois qu'il faut comprendre que ces principes, ce n'est pas inter à DHSU, mais c'est plus à un titre mondial, il faut vivre en donnant l'exemple, je pense. Quand on essaie de parler, certains croient que, comme faisons la promotion de DHSU, c'est pour cela que nous mettons en place ces principes. Ce n'est pas le cas comme l'institution PSI qui ont aussi leur manière de fonctionner, mais pourtant y comprennent et sentent bien au courant de ces principes et de ces normes. Mais ce n'est pas le cas avec les ministères de la santé qui ne comprennent pas et font aux certains développements au niveau de leur entreprise locale qui décident comment est-ce que télécharger les données et comment les gérer. C'est le genre de problème auquel on fait face dans certains pays. Je pense qu'il faudrait bien gérer cette question. Donc nous ne travaillons pas que pour le bien ou le bénéfice, le bien-être de DHSU. Nous prenons en considération les normes, les standards du monde. C'est vrai, nous travaillons d'abord pour que ce soit profitable pour nous, mais c'est clair que c'est énorme à l'échelle mondiale. Je crois que les gens sur le terrain peuvent mieux comprendre ce dont il est question. Je ne suis pas sûr qu'il y ait besoin d'explications là-dessus, mais une question venant du chat, c'est que les principes que vous avez dit ne commençaient pas la discussion avec les vendeurs d'applications. Est-ce que DHSU se considère comme vendeur d'application, ou c'est pas le cas au niveau du principe numéro 4? Je n'ai pas un meilleur mot pour dire cela. Nous nous produisons aussi des produits comme DHSU, open source que les gens peuvent utiliser, mais il y a un sens unique dans lequel nous sommes des vendeurs, mais il n'y a pas un meilleur mot pour cela. Nous sommes des producteurs de systèmes, mais je ne sais pas trop comment le dire. J'utilise le mot vendeur de logiciels. Je crois qu'on va se classer dans cette catégorie, mais je ne l'utilise pas dans le sens vulgaire de vendeur d'application. Parce que le mot vendeur donne une implication commerciale. Je pense de mon côté que nous sommes aussi de l'Université d'Oslo, et on se considère comme université d'ailleurs, où il y a ce programme de recherche. Cela ne signifie pas que votre équipe, vous devez faire confiance en cela, parce que c'est un angle où il faut comprendre qu'il y a des principes que nous essayons de promouvoir. Les gens peuvent prendre ou refuser notre application, notre plateforme, mais il y a des gens que ce soit l'intérieur de l'essieu. Vous voyez que l'Université d'Oslo, nous faisons tout quand même pour tout faire, pour que DHS2 soit performant, tout qu'on le fait, je crois que nous sommes tous confortables en disant que ne faites pas juste confiance à l'aveugle de DHS2, essayez de voir ce dont il est question, essayez de comprendre, voyez ce dont vous avez besoin, les données dont vous avez besoin chez vous, vous avez vérifié sur ces marches. Nous ne disons pas que DHS2 est en train de couvrir tous les cas d'études ou tous les aspects de la vie courante. Non, je suis très ouvert aux suggestions pour utiliser le meilleur mot ou le de vendeur du système comme on voit dans le principe du monopère. Il y a un sens dans lequel les autres sont des vendeurs du système, ce serait pour moi un plaisir d'utiliser un autre mot pour définir cela. Il y a une main levée. Adam, tu veux dire quelque chose ? Merci beaucoup pour cette présentation. Je crois que c'est bienvenue, surtout vu les contextes dans lesquels nous sommes, surtout dans les pays, en Afrique de l'Ouest et en Afrique centrale, où les gens croient que l'interopérabilité est maintenant une sorte de mot magique pour fuir en quelque sorte les critiques ou poursuivre et dupliquer le système ou le fait d'implementer les écosystèmes frappementés dans leur logiciel. Je pense et j'espère que nous avons beaucoup de partenaires dans ce domaine et dans cette session en particulier. Et sur les principes que vous venez d'évoquer, ce que je suggérerai, c'est que, premièrement, nous avons besoin d'une sorte de liste pour pouvoir vérifier l'opérabilité des logiciels pour savoir ce dont on a besoin, pour appliquer l'interopérabilité dans un pays et savoir si le pays est prêt pour cela. Parce que quand ces initiatives viennent, la plupart du temps, ils ne savent pas qui parler dans les pays. On se demande si c'est à la partie technique qu'il faut parler ou les décideurs. À partir de ce que vous avez dit dans cette présentation, il est clair que nous devons parler à plusieurs personnes à la fois, ceux qui gèrent les programmes, les utilisateurs, les informaticiens et des fois les politiciens, etc. Il faudrait que cela soit mis en place pour qu'on aide les gens, pour que les gens comprennent ce dont il est question et à qui parler. L'autre point remarque que j'ai concernant ces six principes, c'est que c'est une bonne tentative, mais comme nous savons tous, la barrière que nous avons pour ce genre d'arène est très élevée, parce que cela n'est pas donné aux gens dans les pays et même dans les pays de faire partie de ce genre d'initiative. Parce qu'il se retrouve dans les problèmes, je sais qu'il n'y a pas de solution magique, il n'y a pas de baguette magique pour enlever cela, cependant nous allons voir de quelle manière est-ce que nous allons rendre cela possible. Merci. Merci beaucoup, Edem. Vous avez parlé de l'opérationnalisation que je n'ai pas trop touché dans cette présentation quand vous avez parlé de cette liste de contrôles, cette checklist pour l'architecture, mais nous travaillons dans cette lancée et sur cette lancée pour le moment. Merci. Je crois que nous avons le temps pour une autre question, il y a quelqu'un ici à l'université d'Oslo qui a eu une question, donc on lui laisse la parole. Je ne suis pas contre.