Embed Size (px)
Citation preview
DHIS2 Android
Implementation Guide
DHIS2 Documentation Team
Copyright © 2008-2021 DHIS2 Team
Dernière mise à jour: 2021-08-10
Warranty: THIS DOCUMENT IS PROVIDED BY THE AUTHORS ‘’AS IS’’ AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS MANUAL AND PRODUCTS
MENTIONED HEREIN, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
License: Permission is granted to copy, distribute and/or modify this document under the terms of
the GNU Free Documentation License, Version 1.3 or any later version published by the Free
Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
A copy of the license is included in the source of this documentation, and is available here online:
http://www.gnu.org/licenses/fdl.html
DHIS2 Android Implementation Guide
2
Table des matières
Executive Summary
Contexte
Objectives
Target Audience
Carte de document
DHIS 2 Capture Android overview
Easier Login and enhanced data protection
Configurable App theme and Icon
Attractive, user friendly navigation
Fully functional while offline: intelligent sync
Tracker dashboard
Integrated search for tracker
Pictorial Data Entry
Event Completeness
DHIS 2 Server Requirements
Data Security and Privacy
Mobile Device Specifications
Configuration DHIS2 en vue de l'utilisation de l'application Android
Considérations en matière de sécurité
Création d'un utilisateur Android
Configuration visuelle : Comprendre le quoi et le pourquoi
Configuration des règles du programme
Définition des indicateurs et des légendes des programmes
Identifiants réservés
Installing the new DHIS 2 Capture App
Migrating from the old apps
Login into the app
Test
General Recommendations for Testing an Android App
Internal testing and UAT testing
Field Testing/Pilot
Mise à l'échelle
Acquisitions
Mobile Device Management
Formation
Déploiement
Mobile Implementation Checklist
Table des matières
3
Executive Summary
Contexte
En réponse à la croissance des taux d'adoption des smartphones en Afrique subsaharienne et
dans les pays en développement, à laquelle s'ajoute la nette évolution du marché de l'Android,
l'Université d'Oslo a décidé de créer une nouvelle application mobile DHIS 2 Android, DHIS 2
Capture Android, lancée en septembre 2018. Ce travail fait suite aux enseignements tirés des
précédentes applications mobiles DHIS 2 Android : Data Capture (Capture de données), Tracker
Capture (Saisie Tracker), Event Capture (Capture d'événements) et Dashboard (Tableau de
bord).
L'application DHIS 2 Capture Android est conçue dans l'optique de faciliter le travail dans des
environnements à faible connectivité ou sans connectivité, puisqu'elle permet à l'utilisateur de
travailler hors ligne et de synchroniser les données plus tard, lorsque la connectivité sera
disponible. Elle facilite la collecte de données en regroupant tous les modèles de données DHIS
2 dans une seule application consolidée. Elle est destinée à être utilisée par les professionnels
de santé (travailleurs de première ligne, prestataires de services, personnel des centres de
santé...) dans les établissements de santé et dans le cadre d'un travail effectué directement au
niveau communautaire.
L'application DHIS 2 Capture Android se distingue de l'application DHIS 2 basée sur le web.
L'application DHIS 2 basée sur le web est destinée à être utilisée lorsque les utilisateurs ont
accès à des écrans plus grands et à une bonne connexion internet. Quant à l'application Android,
elle a été conçue en tenant compte de l'expérience des utilisateurs disposant d'écrans plus petits
et d'une connectivité faible ou nulle.
Les recherches indiquent qu'une application mobile dans le domaine de santé en ligne peut être
facilement intégrée dans les soins, ce qui contribue à améliorer la productivité. L'application
devrait faciliter le suivi des clients, la communication des données et la prise de décision.
Toutefois, la faisabilité et la convivialité de l'application peuvent être affectées par le nombre
élevé de bénéficiaires, le manque de personnel et les problèmes liés aux logiciels et aux
appareils. Pour réussir l'intégration des applications mobiles de données clients pour les
travailleurs de la santé en première ligne dans les zones rurales et les milieux pauvres en
ressources, il faudra donc un suivi en temps réel, un investissement dans le programme ainsi que
des ressources humaines adéquates [Rothstein JD1 et al. 2014] (https://www.hindawi.com/
journals/ijta/2016/2515420/).
Objectives
Ce document a pour objectif de fournir un ensemble de lignes directrices relatives au déploiement
de l'application Android Mobile DHIS 2 Capture. Les étapes du déploiement, qui seront décrites
en détail plus loin dans le document, comprennent notamment :
Aspects liés à la sécurité et à la protection des données
Conditions relatives aux appareils mobiles
Installation et configuration
Tests (test en interne et test d'acceptation des utilisateurs)
Tests sur le terrain et Pilotage
Développement (distribution de l'application, gestion des appareils mobiles, formation)
Déploiement
On y retrouve également une carte des documents regroupant les sections du document selon
les phases d'un projet de mise en œuvre mobile. Tous les aspects représentés ici doivent être
pris en compte au début du projet et planifiés en conséquence. Cette représentation illustre dans
quelle phase du projet ils seront d'une grande importance, ce qui résume ses aspects clés et
1.
2.
3.
4.
5.
6.
7.
Executive Summary Contexte
4
facilite le suivi de ces directives dans votre projet. Il convient donc de souligner que le cycle
représenté dans la carte des documents considère le processus de collecte des exigences
comme terminé. Vous trouverez la carte des documents dans la première section.
Dans la dernière section, vous trouverez une liste de contrôle qui résume ses principaux aspects
et facilite le suivi de ces lignes directrices dans votre projet.
Target Audience
Ce document est destiné aux responsables du processus de déploiement depuis ses premières
phases, et doit être partagé avec les acteurs impliqués dans le processus.
Executive Summary Target Audience
5
Carte de document
Carte de document Target Audience
6
DHIS 2 Capture Android overview
Ce document porte essentiellement sur la mise en œuvre mobile utilisant la nouvelle application
DHIS 2 Capture Android. Pour obtenir de plus amples informations sur les différentes applications
DHIS 2 Android, veuillez consulter l'App Store et la Documentation sur le site web. Les
applications DHIS 2 Android développées précédemment sont actuellement en cours de
dépréciation et font uniquement l'objet d'une maintenance corrective :
Application Tableau de bord : Abandonnée depuis mars 2020
Applications Tracker et Événement : Dépréciées depuis juin 2020
Application de Capture de données: Dépréciation prévue à compter de septembre 2020
La nouvelle application DHIS 2 Capture Android permet la collecte de données hors ligne pour
tous les modèles de données DHIS 2*. Les données et les métadonnées sont automatiquement
synchronisées dès qu'il y a un accès à Internet, de manière à toujours conserver les données les
plus importantes pour l'utilisateur connecté sur l'appareil local.
Easier Login and enhanced data protection
L'URL du serveur peut être définie via un code QR. L'application mémorise également les URL et
les noms d'utilisateur utilisés précédemment. Une fois qu'un utilisateur est connecté, il peut entrer
un code PIN à quatre chiffres pour sécuriser l'application avec une déconnexion progressive.
Configurable App theme and Icon
La présentation de l'application, y compris l'icône et la couleur, dépend de la configuration de
votre serveur. Vous pouvez créer un raccourci vers l'application avec le logo de votre institution
dans l'écran d'accueil de l'appareil mobile via l'Application Widget.
Attractive, user friendly navigation
Tous les programmes et ensembles de données* accessibles à l'utilisateur connecté sont intégrés
dans le nouvel écran "Accueil" . Chaque programme ou ensemble de données sont affichés avec
l'icône et la couleur qui leur sont associées.
•
•
•
DHIS 2 Capture Android overview Easier Login and enhanced data protection
7
Fully functional while offline: intelligent sync
Une base de données locale intégrée à l'appareil mobile permet de conserver une copie
synchronisée des programmes et des ensembles de données DHIS 2 accessibles à l'utilisateur
connecté. Les données les plus importantes sont également synchronisées de façon
automatique.
Entités suivies : par défaut, un maximum de 500 inscriptions actives, en donnant la priorité
à la plus récente mise à jour de l'unité ou des unités d'organisation assignée(s) à
l'utilisateur pour la saisie des données.
Événements et Ensembles de données : par défaut, les 1 000 événements ou 500
ensembles de données les plus récents.
N.B. Ces paramètres sont configurables
Tracker dashboard
Le puissant modèle de données de suivi du système DHIS 2 est entièrement opérationnel dans le
petit écran. Le tableau de bord du tracker intègre des commentaires, des relations, des
indicateurs et des notes.
L'application met en œuvre une logique de suivi en prenant en charge la plupart des règles du
programme, donnant la possibilité d'ajouter, de programmer ou de renvoyer de nouveaux
événements, selon la configuration du serveur.
•
•
DHIS 2 Capture Android overview Fully functional while offline: intelligent sync
8
Integrated search for tracker
Avant d'ajouter une nouvelle entité suivie, l'application effectue automatiquement une recherche.
En mode hors ligne, la recherche s'effectue sur la base de données locale synchronisée. En
mode connecté, l'application propose des enregistrements à télécharger, en fonction de la
configuration de recherche de l'unité d'organisation de l'utilisateur. Cette fonctionnalité permet de
limiter les doublons potentiels, même lorsque l'utilisateur est hors ligne.
Pictorial Data Entry
L'Application Saisie de données s'anime - il est possible d'utiliser des icônes et des couleurs pour
illustrer les réponses aux questions. Disponible pour les éléments de données avec les
ensembles d'options associés dans les programmes de suivi et d'événement unique.
Event Completeness
Lors de la saisie des données, l'application affichera des informations relatives à l'état
d'avancement actuel pour une phase du programme. Ceci est utile pour les enquêtes complexes
comportant plusieurs sections.
DHIS 2 Capture Android overview Integrated search for tracker
9
DHIS 2 Server Requirements
La nouvelle application DHIS 2 Capture Android nécessite une instance de DHIS 2 2.29 ou
supérieure fonctionnant dans un serveur web. L'instance DHIS 2 peut être hébergée sur un
serveur local, une machine virtuelle ou peut être achetée au titre de logiciel-service
(hébergement géré). Pour plus d'informations sur les différentes options d'hébergement DHIS 2,
veuillez consulter le site https://www.DHIS2.org/hosting.
Cette section présente les orientations de base pour la configuration du serveur DHIS 2, que
vous devrez effectuer dans les deux premiers scénarios (sur site et machine virtuelle). Dans le
troisième scénario d'hébergement géré, vous devez informer votre fournisseur du déploiement de
l'application Android et avoir une discussion franche sur les meilleures façons de configurer le
serveur. Vous devriez commencer par partager ces orientations avec votre fournisseur
d'hébergement géré.
Le serveur DHIS 2 doit être conçu et configuré en tenant compte des éléments suivants : flux de
collecte des données, analyse des données prévues et interface visuelle prévue. Il faudra au
moins trois serveurs pour un déploiement DHIS 2 : Test, Production et Formation.
Le serveur Test sera celui sur lequel vous pourrez modifier les configurations du serveur et tester
les résultats de ces configurations. Une fois que vous êtes satisfait de la configuration, la
formation des utilisateurs devrait avoir lieu dans un environnement différent de celui de la
production. Un serveur Formation dédié est l'environnement idéal dans lequel vous formerez vos
utilisateurs. Vous créerez des utilisateurs DHIS 2 pour tous les stagiaires et vous veillerez à ce
que chacun comprenne et se sente à l'aise avec les nouvelles configurations. La dernière étape,
une fois que vous aurez testé les configurations et formé les utilisateurs, consistera à déployer la
configuration dans l'environnement Production. Ne modifiez jamais la configuration ou ne formez
jamais vos utilisateurs directement dans l'environnement Production.
DHIS 2 est sous licence BSD ; il s'agit d'une licence libre et gratuite que chacun peut installer et
utiliser. Cependant, la gestion d'une instance DHIS 2 implique bien plus que la mise en place d'un
puissant serveur web. Le déploiement d'un système fiable et évolutif comprend au moins les
aspects suivants :
Des ressources humaines disposant de compétences dans les technologies adaptées
telles que les serveurs web et les systèmes de bases de données.
Une sauvegarde fiable de votre système, y compris un stockage sécurisé sur un serveur
distant.
Utilisation de SSL (HTTPS / cryptage) pour sécuriser les informations privées telles que les
mots de passe.
Surveillance des ressources du serveur et des performances des applications.
Une connectivité Internet stable et à haut débit.
Une alimentation électrique stable y compris une solution d'alimentation de secours.
Un environnement serveur sécurisé pour éviter les accès non autorisés, les vols et les
incendies.
Un matériel puissant pouvant évoluer avec l'utilisation accrue du système.
L'application DHIS 2 Capture Android fonctionne sur les appareils mobiles, y compris les
smartphones, les tablettes et les ordinateurs portables. Il est important de veiller au nombre de
programmes, d'éléments de données et de règles de programme disponibles pour l'utilisateur sur
ces appareils mobiles. Vous devez également prévoir suffisamment de temps pour créer les
traductions nécessaires à la configuration de vos métadonnées. Pour les dialogues de
l'application, les menus et autres messages, si l'application n'est pas traduite dans la langue dont
vous avez besoin, veuillez nous envoyer un message dans la [communauté DHIS 2] (https://
community.dhis2.org) et nous vous indiquerons la marche à suivre pour contribuer aux
traductions de l'application.
•
•
•
•
•
•
•
•
DHIS 2 Server Requirements Event Completeness
10
Caution
In addition to the DHIS2 Server requirements listed here note that the
DHIS2 Android App might require connections to additional services and
by blocking those the application might not fully function. This can apply
in implementations where you might use strict firewall rules like in a
zero-rate URL environment by an agreement with an ISP provider. In
those cases you might want to include in the list of allowed URLs the
following:
Your DHIS2 URL server
Mapbox addresses
The public and/or private Matomo server for statistics as explained
in the guide
•
•
•
DHIS 2 Server Requirements Event Completeness
11
Data Security and Privacy
Avec la nouvelle application Android Capture de DHIS 2, les utilisateurs pourront collecter des
données individuelles au lieu de prestation de services, ce qui constitue le niveau le plus bas de
saisie directe de données puisqu'il implique le bénéficiaire direct. Cette façon de capturer les
données permet une analyse en amont sans compromettre les détails, rend possible une analyse
en aval, réduit les erreurs et permet une analyse post hoc pour répondre aux questions
identifiées après la collecte des données et la conception du système. Toutefois, les données
individuelles posent des défis supplémentaires aux systèmes d'information, notamment en ce qui
concerne la sécurité et la confidentialité, l'état de préparation et la capacité, car les personnes
ayant de faibles connaissances informatiques en matière de collecte de données disposent
d'outils numériques et les complications supplémentaires concernant l'analyse, le stockage et la
réactivité du système.
La nécessité de mettre en place une pratique globale en matière de sécurité des données fait
l'objet d'un large consensus. Cette pratique globale de sécurité devrait prendre en compte non
seulement la confidentialité et l' intégrité, mais aussi la disponibilité des données. L'Initiative
humanitaire de Harvard a [déclaré] (https://hhi.harvard.edu/publications/signal-code-ethical-
obligations-humanitarian-information-activities) que l'information elle-même, y compris sa
production, sa communication et sa réception, représente un besoin humanitaire de base qui
devrait bénéficier d'une protection égale à celle des autres besoins classiques tels que la
nourriture, l'eau, le logement et les soins médicaux. La feuille de route de la Measurement and
Accountability for Results in Health (MA4Health), estime que "La santé publique et les soins
cliniques ne peuvent être fournis en toute sécurité, avec une qualité élevée et de façon
rationnelle, sans des échanges de données et d'informations transparents, durables et sûrs à
tous les niveaux du système de santé". Néanmoins, la saisie et le stockage de données
personnelles identifiables présentent des risques et impliquent une obligation de respecter des
pratiques rigoureuses en matière de confidentialité.
L'Université d'Oslo s'engage en faveur de ce qui suit :
Veiller à ce que le processus de développement et de lancement du logiciel DHIS 2 soit
soumis à un plan de vérification de sécurité transparent et rigoureux ;
À travers une approche de recherche-action, l'université cherche à apprendre en
travaillant en collaboration avec d'autres ;
S'efforcer de développer, d'apprendre et de partager des informations et des outils
appropriés, opportuns et utiles en vue de promouvoir les bonnes pratiques en matière de
sécurité ;
L'accès à toutes les informations relatives à la santé dans le cadre de notre travail sera
régi par un accord strict et mutuel ;
Utiliser les actions de l'université pour proposer de bons exemples de pratiques
sécuritaires.
Il peut y avoir une tension entre le besoin du système de santé de disposer de données
identifiables et le droit du patient à la vie privée. En l'absence d'une législation claire régissant la
collecte et le stockage des données personnelles identifiables, il existe des concepts importants
qui devraient être compris et promus par les propriétaires et les responsables de la mise en
œuvre du système. Ces concepts sont entre autres :
Droit d'accès :
Le droit d'accès sera défini par la réglementation en matière de protection des données en
vigueur dans chaque pays. De manière générale, il comprend des informations sur les finalités du
traitement, les catégories de données à caractère personnel traitées, les destinataires ou
catégories de destinataires, la durée de conservation, des informations sur les droits de la
personne concernée tels que la rectification, l'effacement ou la limitation du traitement, le droit
1.
2.
3.
4.
5.
Data Security and Privacy Event Completeness
12
d'opposition, des informations sur l'existence d'un processus de décision automatisé, y compris le
profilage, etc. Avant donc de commencer la collecte des données, veuillez prendre connaissance
des réglementations spécifiques à votre région et vous assurer que vous êtes prêt à vous y
conformer.
Droit d'effacement :
Le droit d'effacement est également défini par la réglementation sur la protection des données en
vigueur dans chaque pays. En général, les données à caractère personnel doivent être effacées
immédiatement lorsque celles-ci ne sont plus nécessaires aux fins de leur traitement initial, ou si
la personne concernée a retiré son consentement et qu'il n'existe aucun autre motif légal de
traitement. Là encore, assurez-vous de bien comprendre les réglementations en vigueur dans
votre région et soyez prêt à vous y conformer.
Minimisation des données :
Le principe fondamental de la minimisation des données réside dans le fait que le traitement des
données ne doit utiliser que la quantité de données nécessaire pour accomplir une tâche
donnée. Cela implique également que les données collectées à une fin donnée ne peuvent pas
être utilisées à une autre fin que celle du traitement initial sans un nouveau consentement.
Pseudonymisation :
Il s'agit d'une procédure de gestion des données qui rend les données personnelles moins
identifiables tout en permettant leur analyse et leur traitement. Elle peut être réalisée en
remplaçant la valeur de certains des champs de données par un ou plusieurs identifiants
artificiels, ou pseudonymes. Les données rendues anonymes peuvent être restaurées pour
rendre les individus à nouveau identifiables, tandis que les données rendues anonymes ne
peuvent jamais être restaurées dans leur état d'origine. En fonction de la réglementation en
vigueur dans votre région, vous pouvez définir une stratégie de pseudonymisation conforme à la
réglementation et adaptée à vos besoins.
Traçabilité :
Pour une utilisation efficace des données, nous devons garantir leur intégrité. Pour ce faire, il est
important de contrôler ces données lorsqu'elles sont collectées, traitées et déplacées. Vous
devez comprendre les éléments suivants : "quoi", "quand", "pourquoi" et "qui". Les organisations
qui tirent parti de la traçabilité, sont en mesure de trouver les données plus rapidement et sont
plus à même de répondre aux exigences en matière de sécurité et de respect de la vie privée.
En fonction de la réglementation en vigueur dans votre pays et de la complexité de votre projet, y
compris le niveau de risque potentiel, vous devez mettre en œuvre les mesures techniques et
organisationnelles appropriées, telles que la pseudonymisation, la minimisation des données, les
journaux d'audit, les restrictions de recherche, le partage granulaire, etc, et intégrer les garanties
nécessaires dans le traitement des données afin de répondre aux exigences de la réglementation
en vigueur dans votre région.
L'adoption d'une approche adéquate en matière de sécurité et de confidentialité pour toute mise
en œuvre du système DHIS2 permettant de saisir des données personnelles identifiables devrait
s'accompagner de l'élaboration d'une politique claire désignant une ou plusieurs personnes ayant
un accès complet au système et chargées de veiller au respect de la consigne suivante : Pour
tout appui technique concernant les bases de données sensibles, un accord de confidentialité
signé avec une date d'expiration claire devrait être exigé pour les tiers.
Data Security and Privacy Event Completeness
13
Mise en œuvre pratique éventuelle
Droit d'accès et Droit d'effacement La possibilité de donner au patient l'accès à son
dossier par voie électronique pour le consulter ou le
supprimer n'est pas disponible dans DHIS 2 (2.32).
Vous devez donc veiller à mettre en place d'autres
méthodes permettant à un patient de demander une
copie de son dossier pour pouvoir le consulter et
demander des modifications ou sa suppression.
Lorsque cette suppression n'est pas possible, vous
devez rendre le dossier anonyme en supprimant /
remplaçant tous les points de données identifiables.
Minimisation des données : S'assurer qu'il existe une raison valable de collecter
des données personnelles identifiables. Éviter de
collecter des détails inutiles qui ne servent pas un
objectif pratique en termes d'analyse des données
ou de nécessité de finalité d'un dossier patient. Par
exemple, si la nécessité d'un suivi du patient est
déterminée par un résultat de test positif, ne
recueillez pas le nom du patient si le résultat est
négatif.
Pseudonymisation : Envisager l'utilisation de valeurs alternatives pour
enregistrer des informations relatives à certaines
procédures ou conditions d'un patient. Par exemple,
vous pouvez avoir une liste de procédures
médicales / de comportements personnels /
d'actions sous forme de liste colorée. Cela permet
de réaliser des analyses, sans révéler ce qui
pourrait constituer une procédure/action/
comportement stigmatisé au sein d'un territoire
donné.
Traçabilité : Le DHIS 2 propose un journal d'audit détaillé pour
chaque point de données. Cela inclut le traçage
des données saisies via ses outils web (à partir de
la version 2.22), ainsi que des données importées
ou via Android (à partir de la version 2.27).
Actuellement (2.32), DHIS 2 ne propose pas
d'option d'exportation de suppression/
anonymisation complète, puisque la suppression
d'une valeur préserve les données précédentes
dans le journal d'audit. Par conséquent, tout
partage de données exportées vers l'extérieur doit
être accompagné d'une suppression manuelle des
données sensibles/identifiables.
La section Considérations sur la sécurité et la protection des données propose des
recommandations pratiques sur la configuration de DHIS 2 en vue de garantir la protection et la
sécurité des données.
Data Security and Privacy Event Completeness
14
Mobile Device Specifications
Si vous envisagez d'acquérir un grand nombre d'appareils, il est conseillé de remettre à plus tard
la plus grande partie de ces achats. Le but est en effet de vous permettre de disposer d'appareils
de meilleure qualité. La technologie, et en particulier les appareils mobiles, évolue très
rapidement. Un modèle donné est normalement renouvelé selon un cycle annuel, ce qui permet
aux consommateurs de profiter des améliorations techniques importantes d'une année sur l'autre,
mais à un prix similaire. Vous trouverez d'autres recommandations sur les acquisitions dans la
section Mise à l'échelle section.
Specifications for mobile devices to use the DHIS 2 Android App deployment are included in the
following table. Please, note that these recommendations are very generic as performance of the
device will be hihgly impacted by your configuration. For example, having a tracker program with
hundres of program rules will require a more powerful device than in an implementation where
you are only collecting a small set of aggregate data.
In general terms when having to choose different versions of Android aim for the higher. Also,
acquiring devices from well known brands might be an indicator of having better after sales
services like repairing and/or updates.
Mobile phones Tablets Chromebooks
Construction Probably the most important feature: this device is going to be doing a lot of field
work, and it needs to last 2+ years
Brand If you are going to be responsible for managing a lot of devices, it is easier to
stick to one brand
OS Minimum Supported: Android 4.4 (to be deprecated
Apr 2022)
Minimum Recommended for new devices: Android
7.X
Recommended for new devices: Android 8.X or
superior
Chrome OS devices
are updatable to the
latest version of
Chrome OS for at least
5 years after release.
Check here
Processor Recommended: 4 cores, 1.2GHz various
RAM Minimum: 1Gb
Recommended: 2Gb or
more
Minimum: 1.5Gb
Recommended: 3Gb or
more
Minimum: 4Gb
Recommended: 4-8Gb
Storage Minimum: 8Gb
Recommended: 32Gb
DHIS 2 app do not uses much space. However,
storage of personal images & videos uses a lot of
space
Minimum: 16Gb
Recommended:
32-128Gb
Screen Size Minimum: 4"
Recommended: from
5.5"
Minimum: 7" 11" - 14"
Camera Minimum: 5Mpx, with flash
Recommended: at least 8Mpx, flash
optional
Accessories *Case,
Keyboard, External
power*
Consider an appropriate external cover and a
screen protector. For tablets, consider an external
keyboard for desk operation
Consider supplying an external power bank (10,000
mAh - 20,000 mAh)
USB 3G/4G modem
Mouse
WebCam
Mobile Device Specifications Event Completeness
15
Mobile phones Tablets Chromebooks
Connectivity 4G (LTE)/ 3G radio, unlocked. If importing devices,
check the compatibility of frequency bands with
local mobile operators
Bluetooth 4.0 or better. WiFi 2.4 GHz & 5 GHz
Bluetooth 4.0 or better.
WiFi 2.4 GHz & 5 GHz
External USB 3G/4G
dongle or Wifi hotspot
N.B.
Veuillez noter qu'actuellement, l'application DHIS2 Mobile dépend de
certains (Services Google Play) [https://developers.google.com/android/
guides/overview] et ne fonctionnera donc pas sur les appareils ne
disposant pas de ces services. Cette situation est fréquente lorsqu'il
s'agit des nouveaux téléphones Huawei et des appareils AOSP.
Ce fichier n'est plus géré ici mais figure dans le (Guide d'administration du système)[https://
github.com/dhis2/dhis2-docs/tree/master/src/commonmark/en/content/sysadmin]
Mobile Device Specifications Event Completeness
16
Configuration DHIS2 en vue de l'utilisation de l'application Android
Ce chapitre présente les principaux aspects de la configuration pour une utilisation réussie de
l'application Android et permet de mieux comprendre les implications liées à l'utilisation de la
composante mobile de DHIS 2. Pour une mise en œuvre complète et réussie, veuillez consulter la
[documentation] détaillée et actualisée (https://www.dhis2.org/android-documentation) pour
obtenir toutes les informations sur la configuration du serveur DHIS 2 en vue de son utilisation
avec l'application DHIS 2 Android Capture.
Voici les différents éléments de configuration de la nouvelle application DHIS 2 Capture Android
contenus dans ce document :
Considérations en matière de sécurité
Création d'un utilisateur Android
Configuration visuelle
Configuration des règles du programme
Définition des indicateurs et des légendes des programmes
Identifiants réservés
Considérations en matière de sécurité
Utilisation de la fonctionnalité partage DHIS 2 et Restrictions de partage
Dans cette section, nous vous proposons des conseils sur la façon d'utiliser la fonctionnalité de
partage du DHIS 2 et les restrictions en matière de partage afin de s'assurer que seuls les
utilisateurs autorisés ont accès aux dossiers contenant des informations identifiables.
Voici un exemple pratique de partage granulaire et de restrictions en matière de recherche dans
le contexte d'un Centre de santé spécialisé dans les soins maternels et néonatals :
Rôle utilisateur de la sage-femme :
Peut effectuer une recherche sur trois programmes dans toutes les unités d'organisation
du district
Peut inscrire les nouvelles femmes enceintes au programme de CPN
Peut ajouter/modifier des événements à la phase du programme d'évaluation clinique
Peut visualiser toutes les données de CPN dans sa propre unité d'organisation
Rôle utilisateur du technicien de laboratoire
Peut effectuer des recherches dans les unités d'organisation d'un programme du district
Peut ajouter/modifier des événements à la phase du programme de laboratoire
Ne peut pas visualiser la phase d'évaluation clinique
Rôle utilisateur du superviseur du ministère de la santé
Peut visualiser uniquement le tableau de bord
Dans le cadre de votre stratégie de protection des données, vous devez absolument disposer de
procédures opérationnelles standard (POS).
Une PSO est un ensemble d'instructions détaillées compilées par votre organisation pour vous
permettre d'effectuer des opérations de routine complexes comme celles liées à la sécurité des
données.
Les POS permettent à votre organisation de gagner en efficacité, en qualité et en cohérence, tout
en respectant la réglementation en matière de protection des données.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Configuration DHIS2 en vue de l'utilisation de l'applicationAndroid
Considérations en matière desécurité
17
Lorsque vous définissez vos PSO en matière de protection des données, vous devez répondre à
des questions telles que :
Quelle est la législation en vigueur en la matière ?
Qui est le contrôleur nommé ? Le responsable de traitement ? Le délégué à la protection
des données ?
Qui est chargé d'examiner les journaux d'audit ?
Comment procédez-vous à la suppression des anciens utilisateurs ?
Vous apportez vos propres appareils ?
Sécurité du matériel informatique est-elle garantie ?
Accords mutuels de confidentialité
Nous présentons ici quelques exemples de bonnes pratiques de POS tirés du document [DHIS 2
Community Health Information System Guidelines] (https://s3-eu-west-1.amazonaws.com/
content.dhis2.org/Publications/CHIS+Guidelines+En.pdf) publié par l'université d'Oslo :
Harmoniser plusieurs programmes pour obtenir un seul protocole de saisie de données.
Développer des POS pour chaque projet communautaire individuel, surtout en cas de flux
de données multiples.
Transformer les POS en affiches illustrées et les faire afficher sur les murs par le personnel
de l'établissement pour permettre au public de les voir.
Imprimer les PSO et s'assurer que tous les ASC, le personnel de l'établissement et le
personnel du district en disposent d'une copie
Signature des PSO par les différents acteurs à l'issue de la formation.
Participation des partenaires à la création et à l'approbation des POS. Les POS doivent
permettre d'institutionnaliser des meilleures pratiques et du flux de travail des acteurs du
SISC. Faire participer tous les acteurs concernés au processus d'élaboration des POS.
S'assurer que tous les éléments de données et les indicateurs sont saisis. Les ASC doivent
parfaitement comprendre la signification et la mesure de chaque élément de données et
indicateur afin de lever toute ambiguïté
Adopter les directives relatives à la saisie des données lors des formations. Pour renforcer
le principe de responsabilité, les ASC et le personnel des établissements doivent être
conscients du fait qu'ils font partie d'un système plus vaste. Ils doivent également être
informés de la manière dont leurs données sont utilisées pour la planification à des niveaux
supérieurs et pour la mise en œuvre d'actions spécifiques à des niveaux inférieurs.
Demander aux ASC d'expliquer les directives de saisie de données. Cette méthode
d'apprentissage est une pratique efficace pour la formation des adultes. Le fait d'expliquer
les directives de saisie de données renforce la crédibilité de l'ASC auprès du comité de la
santé.
Produire des directives en langue locale, simples à utiliser. Les ASC et le personnel des
établissements doivent disposer de guides et d'instructions sur la marche à suivre.
Envisager la possibilité de créer des affiches ou des petits guides laminés de saisie de
données portables que les ASC et les établissements pourront afficher ou emporter avec
eux et qui décrivent leur rôle et responsabilités selon les directives de saisie de données.
Faites signer les directives par les ASC, le personnel de l'établissement, du district et le
personnel national. Il s'agit d'une mesure d'"engagement" symbolique. L'objectif est de
s'assurer qu'ils en ont pris connaissance, qu'ils comprennent leurs responsabilités en
matière de rapports, telles que définies dans les directives de saisie de données, et qu'ils
s'acquitteront de ces responsabilités.
Réaliser des vidéos ou des fichiers audio simples et les télécharger sur des téléphones.
Les responsabilités et les actions à mener lors de chaque événement sont simplifiées
grâce à des vidéos ou des audioguides simples, en langue locale, auxquels le personnel
de l'établissement et les ASC peuvent se référer.
•
•
•
•
•
•
•
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Configuration DHIS2 en vue de l'utilisation del'application Android
Utilisation de la fonctionnalité partage DHIS 2 etRestrictions de partage
18
Directives pratiques en matière de sécurité des données
Pour veiller à ce que les données personnelles stockées sur les appareils mobiles ne soient
accessibles qu'au personnel de santé autorisé, il faut commencer par éduquer les utilisateurs sur
la manière d'utiliser ces données et veiller à ce qu'elles soient toujours conservées en toute
sécurité. Les lignes directrices ci-après sont extraites du manuel "Monitoring and Evaluation
Standard Operating Procedures for Keeping Client Data Secure & Confidential" (Procédures
opérationnelles standard de suivi et d'évaluation visant à assurer la sécurité et la confidentialité
des données des clients) de PSI.
Les administrateurs de système jouent un rôle important dans la configuration du niveau d'accès
des utilisateurs, en veillant à ce que leur accès aux données soit approprié et ne soit jamais
inutilement abusif. Les lignes directrices ci-après sont également contenues dans le manuel
"Keeping Client Data Secure & Confidential Administrators Guide" (Guide de l'administrateur :
Garantir la sécurité et la confidentialité des données des clients) de PSI
.
Configuration DHIS2 en vue de l'utilisation del'application Android
Directives pratiques en matière de sécuritédes données
19
Création d'un utilisateur Android
Créer un rôle
Pour créer un utilisateur, vous devez d'abord définir un rôle d'utilisateur DHIS 2. L'application
DHIS2 Android Capture ne requiert aucune des autorisations définies dans un rôle d'utilisateur.
La sécurité d'un programme ou d'un ensemble de données DHIS 2 est définie en tant qu'accès
aux données du programme ou de l'ensemble de données.
Afin de résoudre les problèmes de débogage du web avec vos utilisateurs, il est recommandé de
créer et d'attribuer un rôle d'utilisateur avec une fonctionnalité de saisie de données, qui devrait
comprendre :
Les applications Saisie Tracker, Capture d'événements et/ou Saisie de données
Tableau de bord (pour pouvoir se connecter)
Cache Cleaner (vous aurez besoin de nettoyer le cache)
•
•
•
Configuration DHIS2 en vue de l'utilisation de l'application Android Création d'un utilisateur Android
20
Note
When users enter a TEI and while it is not synced to the server they will
be able to delete the TEI and the enrollment even if they have not been
asigned the specific authorities. This is by design and to allow users
rolling back in case of having entered wrong data (TEI and/or
enrollment) and thus preventing it reaching the server and requiring
another user with higher privileges to fix the issue.
Créer un utilisateur
En second lieu, vous devez créer un utilisateur, pour lequel vous devrez ajouter quelques détails
de base tels que le nom de l'utilisateur et lui attribuer le rôle.
Nom d'utilisateur : name.android
Exemple : belen.android
Attribution du rôle d'utilisateur : attribuez au rôle que vous avez créé à la première étape.
Attribuer des unités d'organisation
La troisième étape consiste à attribuer des unités d'organisation à l'utilisateur que vous venez de
créer.
•
•
•
Configuration DHIS2 en vue de l'utilisation de l'application Android Créer un utilisateur
21
On distingue trois types d'affectation des unités d'organisation :
Data capture: Datasets and well as program creation of TEI, Enrollments and Events. Data
pre-downloaded in the app at first login will be the one belonging to these org units.
Mobile users are not expected to access the org. unit hierarchy of a whole country.
Maximum number of org units is difficult to set,as the App does not set the limit, but the
resources on the device (memory, processor). We could say below 250 org units should be
safe, but still believe that is a very big number for a mobile use case.
Sortie des données : pour l'analyse des données. Non applicable au système Android.
Search Org. Units: Expands TEI search (when online) across further Org Units. Individual
records can be downloaded for offline use.
When configuring search org. units, make sure that your capture org. units are contained in
your search org.units, to do that capture org. units have to be selected as well as search
org. units.
Configuration visuelle : Comprendre le quoi et le pourquoi
L'administrateur du système peut configurer les informations affichées ainsi que leur mode
d'affichage. Il existe une bibliothèque d'icônes de plus de quatre cents images. Les icônes
peuvent être attribuées à la plupart des objets de métadonnées : Options, Éléments de données,
Attributs, Programmes / Ensembles de données. Les images ne sont pas téléchargées pendant le
processus de synchronisation des métadonnées - seul le nom de l'icône est téléchargé. Toutes
les icônes existent déjà sous forme d'images vectorielles hautement efficaces dans l'APK de
l'application.
À l'avenir, vous pourrez télécharger vos propres fichiers en format gif/jpeg/png (50 000 ou moins
- à confirmer). L'inconvénient de cette option sera l'utilisation de la bande passante et le temps
de synchronisation, car l'application devra télécharger les images pendant la synchronisation des
métadonnées.
Voici un exemple montrant comment attribuer des icônes et des couleurs aux métadonnées :
•
•
•
•
•
Configuration DHIS2 en vue de l'utilisation del'application Android
Configuration visuelle : Comprendre le quoi etle pourquoi
22
Le tableau suivant indique à quel endroit vous pouvez utiliser les icônes aujourd'hui :
Attribuer Rendu Android Rendu Web
TrackedEntityType
(Type d'entité suivie)
2.30 bientôt
Programme 2.30 (événements
simples, 2.30)
Étape du programme 2.30 (événements
simples, 2.30)
Ensemble de données 2.31 bientôt
Élément de données 2.30 -
Attribut 2.30 -
Indicateurs 2.32 bientôt
Indicateur Prg 2.32 bientôt
Ensemble d'options 2.30 (événements
simples, 2.31)
Pour les phases du programme, les sections peuvent être rendues en trois différents modes :
Liste, Séquentiel et Matrice. Les résultats de chacun de ces modes sont présentés ci-dessous :
Configuration DHIS2 en vue de l'utilisation del'application Android
Configuration visuelle : Comprendre le quoi etle pourquoi
23
Un administrateur de système peut décider de la méthode de rendu des informations dans
chaque section d'étape du programme en définissant le type de rendu mobile, comme indiqué sur
la capture d'écran ci-dessous.
Configuration des règles du programme
Nous recommandons de tester l'application Android en parallèle avec la configuration des règles
de votre programme, ceci afin de s'assurer que les modifications apportées au serveur sont
correctement prises en compte et fonctionnent dans l'application.
La première chose à faire lors de la définition des règles du programme est de définir le contexte
et la priorité de leur exécution. Le contexte définit l'exécution de la règle pour un programme
spécifique et éventuellement pour une étape spécifique. Quant à la priorité, elle définit un ordre
Configuration DHIS2 en vue de l'utilisation de l'applicationAndroid
Configuration des règles duprogramme
24
d'exécution des règles, ce qui est utile lorsque l'exécution d'une ou de plusieurs règles dépend
du résultat d'autres règles.
Une fois le contexte et la priorité définis, il faut maintenant écrire l'expression de la règle du
programme en utilisant les variables intégrées, les variables (attributs de TEI / éléments de
données d'une phase du programme) et les fonctions. Les variables doivent être définies par
l'administrateur pour pouvoir évaluer les informations saisies pour un attribut de TEI ou un
élément de données d'une phase du programme.
Nous devons ensuite décider de l'action ou des actions à exécuter lorsque l'expression de la
règle du programme est vraie
Configuration DHIS2 en vue de l'utilisation de l'applicationAndroid
Configuration des règles duprogramme
25
Lorsque vous définissez les règles de votre programme, vous devez savoir ce que prend en
charge l'application Android DHIS 2. Vous trouverez la liste actualisée dans le [guide de
configuration] (https://docs.dhis2.org/master/en/dhis2_android_capture_app/about-this-
guide.html).
Définition des indicateurs et des légendes des programmes
Les indicateurs à afficher dans l'application peuvent être calculés à partir des données de
l'inscription de l'instance d'entité suivie (TEI). Notez que les calculs s'appliqueront à la TEI ainsi
qu'à l'inscription en cours.
Les types d'agrégation ne sont pas disponibles, et seule la dernière valeur peut être utilisée dans
le calcul de l'indicateur. Tous les éléments de données et les constantes peuvent être utilisés
dans les calculs. Les variables sont prises en charge comme l'indique le tableau suivant :
Vous pouvez vérifier les informations actualisées sur les éléments pris en charge lors de
l'utilisation des indicateurs de programme dans le [guide de configuration] (https://docs.dhis2.org/
master/en/dhis2_android_capture_app/program-indicators.html). Les limites des périodes
d'analyse ne sont pas prises en charge, ni prévues pour une prise en charge future, puisqu'elles
s'appliquent à plusieurs TEI.
Pour afficher un indicateur de programme dans l'application, vous devez cocher la case "Afficher
sous forme" dans l'assistant de configuration d'indicateurs du serveur DHIS 2.
Configuration DHIS2 en vue de l'utilisation del'application Android
Définition des indicateurs et des légendes desprogrammes
26
Après avoir créé votre indicateur, vous pouvez alors lui associer une légende. Dans votre serveur
DHIS 2, allez à Maintenance > Autres > Légendes pour créer une nouvelle légende.
{ .center }
{ .center }
Une fois que vous avez créé la légende, vous pouvez l'attribuer à l'indicateur. Vous pouvez
également attribuer une légende déjà existante. En dessous de la case à cocher permettant
d'afficher l'indicateur dans l'application, vous trouverez la section réservée à la recherche et à
l'attribution de la légende.
Configuration DHIS2 en vue de l'utilisation del'application Android
Définition des indicateurs et des légendes desprogrammes
27
Identifiants réservés
Si vous travaillez sur des programmes de suivi et que vous utilisez des attributs uniques d'entités
suivies générés automatiquement (voir documentation DHIS 2), vous devez comprendre comment
l'application gère la création de valeurs. Les valeurs sont téléchargées à l'avance à partir du
serveur, et sont donc disponibles lorsque l'application fonctionne hors ligne. Ces valeurs sont
marquées comme réservées du côté du serveur.
Dès la première synchronisation, l'application téléchargera 100 valeurs, lesquelles seront
marquées comme réservées du côté du serveur. À partir de ce moment, l'utilisateur peut
commencer à utiliser les valeurs au fur et à mesure que de nouvelles instances d'entités suivies
sont créées.
Chaque fois que l'utilisateur utilise une valeur (enregistre une instance d'entité suivie),
l'application :
Vérifiera si le nombre de valeurs restantes est suffisant et les remplira à nouveau si
nécessaire (si moins de 50 valeurs sont disponibles).
Attribuera la première valeur disponible à l'instance d'entité suivie et la supprimera de la
liste des valeurs disponibles.
Chaque fois que l'application est synchronisée, celle-ci :
Supprimera les valeurs réservées expirées.
Vérifiera si le nombre de valeurs restantes est suffisant et les remplira à nouveau si
nécessaire (si moins de 50 valeurs sont disponibles).
Une valeur est considérée comme " expirée " lorsqu'une des conditions suivantes est vérifiée :
"expirationDate" (date d'expiration) est dépassée. Par défaut, le serveur fixe la période
d'expiration à 2 mois.
Si le schéma de l'attribut est fonction du temps, c'est-à-dire qu'il contient le segment
`CURRENT_DATE(format)`, l'application calcule alors une date d'expiration supplémentaire
en fonction de ce schéma.
Attention
Lorsque vous utilisez des valeurs uniques générées automatiquement
et contenant des dates comme éléments du schéma, la date d'expiration
de ces valeurs sera fonction de ce schéma de dates, ce qui pourrait
entraîner un comportement inattendu si le schéma n'est pas bien défini.
Exemple : La valeur UniqueID a été configurée selon un modèle du type
CURRENT_DATE(MM)-SEQUENTIAL(###) et nous sommes aujourd'hui
le 31 janvier. L'application téléchargerait donc 100 valeurs (du 01-001
au 01-101) pour pouvoir fonctionner hors ligne et avoir suffisamment de
valeurs ; par contre, demain, 1er février, l'application n'aura aucune
valeur disponible puisque toutes auront été marquées comme étant
expirées et elle affichera donc un message à cet effet.
Avec l'application, l'utilisateur peut également vérifier les valeurs disponibles et les recharger
dans le menu des paramètres.
1.
2.
1.
2.
•
•
Configuration DHIS2 en vue de l'utilisation de l'application Android Identifiants réservés
28
Lorsque l'application est à court de valeurs et que le serveur ne peut pas en fournir davantage,
l'utilisateur reçoit un message sur le formulaire de saisie des données lui indiquant qu'il n'y a plus
de valeurs disponibles. Vous devriez alors y remédier du côté serveur.
Configuration DHIS2 en vue de l'utilisation de l'application Android Identifiants réservés
29
Installing the new DHIS 2 Capture App
Vous pouvez télécharger et installer cette application à partir de deux sources :
Google Play: - Cette version ne permet pas la diffusion d'écran ou la réalisation de
captures d'écran.
GitHub - There are two versions available in Github:
Production no_sms version: The same version than Google Play, it does not allow screen
broadcasting or taking screenshots
Production version: The same version than Google Play but including SMS capability
(currently blocked by Google Play), it does not allow screen broadcasting or taking
screenshots
Training version: With screen broadcasting and possibility to take screenshots (the one
named with the suffix _training.apk)
N.B.
Quand vous installez l'APK de formation, vous devrez peut-être
autoriser les installations par des tiers
Veuillez lire la section consacrée à la distribution des applications pour comprendre les
implications liées à l'utilisation des différents canaux de distribution.
Migrating from the old apps
Avant de commencer l'installation de la nouvelle application DHIS 2 Capture Android sur le
terrain, il est important de noter que vos utilisateurs doivent suivre les étapes suivantes s'ils
utilisent déjà l'ancienne version de DHIS 2 Android Event Capture ou Tracker Capture :
Synchroniser les données de l'application DHIS 2 que vous utilisez actuellement
Télécharger et installer la nouvelle application DHIS 2 Android Capture
Connectez-vous à l'aide de vos identifiants.
Attention
La suppression de l'application sans synchronisation peut entraîner une
perte d'informations.
Login into the app
Pour vous connecter, vous aurez besoin de l'URL du serveur DHIS 2, du nom d'utilisateur et du
mot de passe de l'utilisateur que vous venez de créer. Pour les tests, vous pouvez également
utiliser les serveurs de test et les identifiants :
URL Utilisateur Mot de passe
Version la plus récente du DHIS
2
https://play.dhis2.org/android-
current
android Android123
Version antérieure du DHIS 2
https://play.dhis2.org/android-
previous1
android Android123
•
•
•
•
•
1.
2.
3.
Installing the new DHIS 2 Capture App Migrating from the old apps
30
URL Utilisateur Mot de passe
Deuxième version antérieure du
DHIS 2
https://play.dhis2.org/android-
previous2
android Android123
Installing the new DHIS 2 Capture App Login into the app
31
Test
Maintenant que le serveur DHIS 2 est configuré et que vous avez installé l'application sur un ou
plusieurs appareils, vous pouvez procéder aux tests. Pendant que vous planifiez vos tests, vous
devez être informé des prochaines versions. Il est donc important de rejoindre la communauté sur
https://community.dhis2.org/ et d'utiliser JIRA, l'outil de gestion de logiciels utilisé par UiO. Cela
vous permettra de prendre connaissance des problèmes en suspens en termes de fonctionnalités
et de correction de bogues pour lesquels des versions ultérieures sont prévues.
Il est conseillé de tester l'application Android en parallèle avec votre configuration, afin de
s'assurer que les modifications apportées au serveur sont correctement prises en compte et
fonctionnent dans l'application. Ceci est particulièrement important lors de la configuration des
règles du programme. Outre ce test étape par étape, il existe différents types de tests que vous
devez effectuer avant le déploiement de l'application.
Il existe une première série de tests qui devraient être effectués en interne avec des groupes
plus restreints pour s'assurer que les configurations sont effectuées correctement, que la
fonctionnalité est bien en place et que l'aspect et la convivialité sont adéquats. Dans le cadre de
cette phase initiale de tests, vous effectuerez ce que l'on appelle des tests internes, suivis par les
tests UAT (Tests d'acceptation des utilisateurs). Plus loin dans cette section, nous expliquerons
plus en détail en quoi consistent ces types de tests et comment les réaliser. Ensuite, vous
effectuerez vos tests sur le terrain et votre test pilote. Dans cette phase des tests, vous
effectuerez une série de tests avec des groupes plus importants afin de garantir, entre autres,
que vos flux de travail, votre infrastructure et votre architecture sont corrects. Nous reviendrons
plus loin sur ces types de tests et sur la manière de les réaliser.
Les graphiques ci-après indiquent que les prochaines étapes sont de nature itérative, y compris
les nouvelles configurations de serveur basées sur les résultats des tests. Vous devrez
probablement effectuer plusieurs séries de tests et de reconfiguration avant de pouvoir passer à
la mise à l'échelle et au déploiement.
Test Login into the app
32
General Recommendations for Testing an Android App
Avant d'aborder les différentes phases de test, nous allons présenter quelques recommandations
générales applicables au test d'une application Android. Globalement, le processus de test peut
se résumer aux étapes suivantes :
Examiner. La première étape consiste à examiner les informations relatives à l'application
elle-même en vous rendant à https://www.DHIS 2.org/android-documentation. Vous y
trouverez des informations concernant le pourquoi et le quoi ou encore sur vos tests. Elle
devrait vous aider à déterminer si l'application répond à vos exigences, ce qu'elle peut et
ne peut pas faire et vous aider à analyser les divergences. Elle devrait également vous
aider à identifier les nouvelles fonctionnalités et les nouveaux paramètres ainsi que les
fonctionnalités prises en charge.
Planifier. À cette étape, vous devez déterminer le moment des tests en tenant compte du
calendrier de votre propre mise en œuvre. Lors de cette phase de planification, vous devez
créer une liste détaillée des exigences et les classer comme obligatoires (DOIT avoir) ou
souhaitables.
Design. In this step you must develop the test cases, decide the number of test interactions
and the tools you will be using for your testing.
1.
2.
3.
Test General Recommendations for Testing an Android App
33
Example of testing tools - Jira
Example of testing tool - Excel
Every test case should include the following sections. The level of detail and the content of
the test to be performed will depend on the level of experience-profile of the user.
Identification: Cycle number / ID, Test ID, version, test summary.
4.
5.
6.
◦
Test General Recommendations for Testing an Android App
34
Description: details, steps to reproduce
Status report: Date of execution, executed by, expected vs actual result, execution
status report ID.
Exécuter. Lors de l'exécution de vos tests, veuillez tenir compte de deux points importants
:
Configuration des métadonnées : Vérifiez les paramètres du programme sur le web et
consultez la documentation pour vous familiariser avec les fonctionnalités de l'application.
Cela permettra d'identifier les véritables bogues par rapport aux problèmes issus de la
configuration ou aux fonctionnalités non prises en charge.
Matrice d'achèvement : Vérifiez vos progrès en fonction des échéances que vous avez
fixées à la phase de planification. Veillez aussi à prendre soigneusement des notes pour
être en mesure de signaler un bogue.
Rapport. Votre rapport doit présenter trois caractéristiques importantes
L'erreur signalée doit être reproduisible
L'information doit être spécifique et descriptive
The report must separate facts from speculations
{ .center width=80% }
The table below summarises a good Bug Reporting with some examples:
{ .center width=80% }
◦
◦
7.
8.
9.
10.
11.
12.
13.
14.
Test General Recommendations for Testing an Android App
35
Internal testing and UAT testing
Que testez-vous ?
Vous testez la configuration de votre serveur DHIS 2 et l'application Android elle-même.
Que recherchez-vous ?
Règles du programme, formulaires, interface visuelle, indicateurs... Bugs, améliorations,
nouvelles spécifications, etc.
Comment ?
Les méthodes et les périodes de tests varient d'un groupe à l'autre, mais les tests doivent être
itératifs, flexibles et réalisés dès les premières phases du processus de déploiement. Vous devez
donc prendre le temps de décider des personnes qui participeront au test, élaborer un plan de
test et disposer d'une stratégie pour recueillir les avis. Il existe différents outils permettant de
signaler et de suivre les bogues et les problèmes. Selon la complexité de votre test, vous pouvez
utiliser trello, JIRA, etc.
Il est important de bien préparer vos tests en interne pour améliorer la qualité et l'efficacité des
séances de test. Ces recommandations s'appliquent à tous les tests que vous aurez à effectuer.
UAT Testing
Que testez-vous ?
Vous testez la configuration de votre système (entrée), votre interface visuelle et vos icônes, la
facilité d'utilisation et vos sorties. Vous pouvez également tester à ce stade l'expérience utilisateur
avec différents appareils (smartphone, tablette, clavier externe, chromebook).
Test Internal testing and UAT testing
36
Que recherchez-vous ?
Les modifications apportées aux points précédents ainsi que les problèmes liés au matériel. C'est
un moment propice pour commencer à identifier ceux qui pourront contribuer aux phases
ultérieures. L'objectif principal de l'UAT est d'avoir des gens aux expériences variées en accord
avec la configuration pour l'exécution des tests sur le terrain. La réussite de cette étape est la
condition pour passer à la phase suivante, à savoir les tests sur le terrain
Comment ?
Utiliser un environnement contrôlé. Trouver des utilisateurs ayant peu d'exposition à la
technologie, qui ne sont pas nécessairement associés aux pratiques professionnelles. Vos
utilisateurs pourraient être : 1) Expert dans le domaine sanitaire, 2) Agent de terrain, 3) Utilisateur
sur le terrain.
La taille du groupe variera en fonction du type de projet pour lequel l'application est mise en
œuvre. La taille moyenne d'un groupe de test UAT varie entre 5 et 10 personnes.
Lorsque vous décidez des personnes qui participeront à votre test, pensez à tous les différents
types d'utilisateurs et à leurs rôles. Sélectionnez vos testeurs en tenant compte de cet aspect.
Vous devez fournir à vos testeurs des informations et des conseils appropriés. Ils doivent être
bien informés des méthodes que vous utiliserez pour le test, des attentes et des objectifs
généraux du test. Il est conseillé, dans la mesure du possible, d'organiser des séances de test
avec un ou deux responsables, où les testeurs peuvent échanger des informations et avoir la
possibilité de poser des questions et d'obtenir de l'aide sur place de la part des responsables. Un
autre aspect important à considérer est celui des données du test. Vous devez disposer de
suffisamment de données dans votre serveur de test pour permettre de tester différents cas de
test.
Field Testing/Pilot
Que testez-vous ?
Vous testez vos POS et vos flux opérationnels.
Vous testez votre infrastructure/architecture.
Vous testez les différents appareils.
Vous testez vos méthodes et matériels de formation.
•
•
•
•
Test Field Testing/Pilot
37
Que recherchez-vous ?
Ajustements relatifs aux éléments précédents.
Adéquation des appareils sélectionnés à l'espace et à l'environnement de travail.
Évaluer votre solution
Identifier les promoteurs.
Comment ?
20 à 30 utilisateurs. 2 mois recommandés (prévoir à l'avance !). Décidez de la distribution (lieux).
Ne pas opter pour le plus simple ou le plus complexe. Faites simple, mais remettez en question
votre solution.
Considérations relatives à l'évaluation de votre projet pilote
Vous devez définir vos indicateurs pour évaluer vos résultats et décider de votre stratégie de
pilotage du système. Vous pouvez utiliser votre système actuel et le nouveau système
simultanément pendant quelques mois ou simplement le remplacer. Les deux stratégies
présentent des avantages et des inconvénients et vous devez les analyser soigneusement avec
votre équipe avant le pilotage.
Voici quelques avantages de la mise en parallèle du système actuel et du nouveau système :
Vous pouvez avoir des preuves que le nouveau système est meilleur que l'ancien en
termes de rapidité ou de qualité des données, par exemple ; ces paramètres dépendent de
l'objectif de votre projet spécifique.
Votre ancien système sert de mécanisme de secours lorsque quelque chose ne fonctionne
pas comme prévu
Il renforce la confiance des utilisateurs lorsqu'ils comparent les deux résultats.
Voici quelques inconvénients :
Vous mettez en place un mécanisme de double reporting ; celui-ci double le temps et le
niveau d'effort de vos utilisateurs. Les services informatiques se doivent donc de traiter
cette question avec sensibilité et préparer les éventuelles ressources humaines de soutien
en cas de besoin.
La possibilité pour les utilisateurs de comparer les deux systèmes en parallèle pourrait être
une arme à double tranchant, car certains utilisateurs ont tendance à résister au
changement.
•
•
•
•
•
•
•
•
•
Test Field Testing/Pilot
38
Mise à l'échelle
Acquisitions
Maintenant que vous avez effectué tous vos tests et votre projet pilote, vous êtes enfin prêt à
intensifier votre déploiement. Pour cela, vous devrez procéder à l'acquisition du matériel et des
services nécessaires. Vous devrez donc prendre des décisions en matière de :
Achat d'appareils vs BYOD (apportez votre propre appareil)
Distribution de l'application (maintenant et ultérieurement)
Contrats de télécommunications
Achat d'appareils vs BYOD (apportez votre propre appareil)
Dans un premier temps, vous devriez acheter différents appareils pour permettre aux utilisateurs
de les évaluer et de vous donner leur avis. Une fois que le choix de l'appareil que vous utiliserez
est fait, vous ne devriez acheter que 10 unités ou moins, ou ce dont vous aurez besoin pour les
phases de test et de pilotage. Ce n'est qu'à l'issue de la phase pilote que vous devez acheter
l'équipement pour les 6 prochains mois de déploiement. Certains projets très importants
nécessiteront des années pour un déploiement national, et votre plan d'acquisition de matériel
devrait s'étendre sur plusieurs années. Le chapitre Spécifications des appareils mobiles présente
des recommandations relatives aux spécifications techniques des appareils.
Vous devez envisager la possibilité de recourir à une stratégie BYOD - ce format permet aux
utilisateurs de venir avec leurs propres appareils, à condition qu'ils répondent à un minimum de
normes techniques, que vous aurez définies pour votre projet. Vous proposerez normalement
une forme de motivation, probablement sous la forme d'eCash ou de temps de connexion. Les
avantages de cette approche sont évidents : elle évite le coût initial élevé de l'acquisition, tout en
réduisant les frais administratifs et les contraintes logistiques. D'autre part, vous devez faire face
au défi que représente un environnement matériel très hétérogène, c'est-à-dire des appareils et
des versions de systèmes d'exploitation Android différents. Cela affecte principalement le
processus de débogage.
Distribution de l'application (maintenant et ultérieurement)
L'application DHIS 2 Android est mise à jour toutes les deux semaines. Chaque nouvelle version
comporte des corrections de bogues et peut proposer de nouvelles fonctionnalités. Elle peut
également comporter de nouveaux bogues. Les nouvelles versions sont publiées dans GitHub
ainsi que dans Google Play store. Github n'est qu'un référentiel : vous téléchargerez un APK
spécifique que vous installerez sur votre appareil. Pour installer un APK, vous devrez autoriser
l'utilisation de permissions provenant de tiers. Une fois qu'un APK est téléchargé depuis GitHub
ou par une autre méthode, la version installée ne sera jamais mise à jour automatiquement. Par
contre, si vous l'installez à partir de Google Play, il se met normalement à jour automatiquement
avec la dernière version. Il est possible de désactiver la mise à jour automatique dans Google
Play si vous le souhaitez.
Une fois que vous avez terminé vos tests, que les documents de formation sont prêts et que vous
avez commencé le déploiement, vous ne devez pas modifier la version de l'application pour les
utilisateurs, à moins que vous n'ayez testé la nouvelle version à nouveau. Les changements de
version peuvent entraîner une modification de l'interface utilisateur, des comportements erronés
ou une incompatibilité avec la version de votre serveur DHIS 2. Vous devez donc effectuer des
tests approfondis sur les nouvelles versions avant de les proposer à vos utilisateurs, afin de vous
assurer que la nouvelle version ne pose aucun problème à votre configuration, qu'elle nécessite
une nouvelle formation ou que votre configuration nécessite des modifications.
•
•
•
Mise à l'échelle Acquisitions
39
En résumé, pour toute installation impliquant un nombre important d'appareils, vous devez éviter
d'utiliser Google Play et recourir plutôt à une solution de Gestion des appareils mobiles (MDM),
abordée dans [ce chapitre] (#scale_up_mdmt). Si vous n'avez pas accès à cette option, vous
pouvez envisager d'utiliser Google Play, mais vous devez désactiver la mise à jour automatique
pour l'application androïde DHIS 2. La procédure à suivre varie en fonction de la version
d'Android OS - veuillez chercher sur Google "comment désactiver la mise à jour automatique
d'Android par application sous Android X.X".
Contrats de télécommunications
Si vous envisagez d'inclure l'utilisation des SMS pour transmettre des enregistrements
sélectionnés par SMS en l'absence de données mobiles, vous devrez conclure un contrat avec
un agrégateur local qui pourra vous fournir un numéro permettant de recevoir les SMS. Vous
devez configurer votre serveur de manière à pouvoir recevoir et envoyer des SMS - veuillez
consulter la [documentation DHIS 2] (https://docs.dhis2.org/master/en/user/html/
mobile_sms_service.html#) sur les connexions SMS. Vous devrez estimer le nombre de messages
par mois pour pouvoir prévoir le coût mensuel.
Le processus de sélection et de signature d'un contrat avec un fournisseur de SMS varie selon
les pays et dépend des procédures de passation de marchés appliquées au sein de votre
organisation.
Planning large acquisitions
Chaque projet nécessitera une variété de types d'appareils : téléphones, tablettes et
Chromebooks. La plupart des appareils mobiles seront probablement réservés à un utilisateur
spécifique. Les éléments à prendre en compte seront notamment la nature de la tâche. Par
exemple, les travailleurs communautaires utiliseront des smartphones ou des tablettes. Mais les
agents de santé exerçant dans un établissement peuvent préférer une tablette dotée d'un clavier
externe ou un Chromebook.
Il convient de remettre autant que possible à plus tard l'acquisition à grande échelle. Dans un
premier temps, il est recommandé d'acheter le moins d'appareils possible pour tester la
configuration et de laisser un minimum de choix aux futurs utilisateurs. Une fois que la décision
de passer à un projet pilote est prise, le second achat devrait idéalement se limiter aux appareils
nécessaires à la mise en œuvre de ce projet pilote. Si le plan de déploiement s'étend sur un an,
l'acquisition des appareils devrait également être répartie dans le temps : de meilleurs appareils
au même niveau de prix sont constamment proposés par les fabricants sur des cycles qui varient
entre 12 et 18 mois.
Exemple d'une acquisition totale de 100 à 1000 appareils.
Mois du projet Phase Acquisition # d'appareils
Mois 2 Conception et
configuration initiale
Choisissez 3 ou 4
facteurs de forme
possibles. Achetez
auprès d'un ou deux
fabricants
2-8
Mois 4-6 Phase pilote Acheter uniquement
les appareils
nécessaires à la
réalisation de la phase
pilote
10-30
Mois 6-12 Déploiement - phase 1 Première acquisition
de masse
50-500
Mise à l'échelle Planning large acquisitions
40
Mois du projet Phase Acquisition # d'appareils
Mois X Déploiement - Phase X → 50-500
Mois 36-48 Mise à niveau ou
remplacement
Remplacer les
appareils
X
Mobile Device Management
La gestion des terminaux mobiles désigne les logiciels utilisés pour assurer le fonctionnement des
terminaux mobiles. Vous aurez besoin d'un logiciel de MDM lorsque vous aurez à prendre en
charge des centaines d'appareils et qu'il sera nécessaire de contrôler la distribution des fichiers
apk sur les appareils, de fournir une assistance technique et d'appliquer les politiques
institutionnelles. La plupart des options sont proposées sous forme de services à tarif mensuel.
Certaines applications gratuites proposent un mode kiosque, mais font payer des frais mensuels
pour la gestion élémentaire à distance.
Les fonctionnalités attendues d'un logiciel de MDM peuvent être classées en deux catégories :
les fonctionnalités de base et les fonctionnalités avancées. Voici donc une liste des
fonctionnalités utiles :
Fonctionnalités de base :
Exiger un mot de passe pour le verrouillage de l'écran
Mise à disposition des applications autorisées
Verrouiller les dispositifs et effacer les informations en cas de perte ou de vol
Contrôler la mise à jour de l'application Android
Appliquer les politiques de sauvegarde
Fonctionnalités avancées :
Mettre en œuvre des politiques de protection des mots de passe
Faire appliquer les politiques d'utilisation du réseau
Suivi de la localisation de l'appareil
Limiter l'accès aux paramètres et aux fonctions (exemple - wifi/réseau, capture d'écran)
Pour choisir le logiciel de MDM le mieux adapté à vos besoins, vous devez essayer de répondre
aux questions suivantes :
Combien d'appareils me faut-il pour gérer ?
À quelle fréquence ai-je un accès physique à l'appareil ?
Quelles sont les fonctionnalités dont j'ai vraiment besoin ?
Quelles sont les politiques que je dois mettre en œuvre ?
Quelles seront les difficultés auxquelles il faudra faire face lors de l'installation et de la
maintenance ?
Comment cela affectera-t-il l'expérience de l'utilisateur ?
Faut-il autoriser l'option BYOD ? (Apportez votre propre appareil)
Quel sera l'impact sur l'appareil ?
À la page suivante, vous trouverez une liste des logiciels de MDM disponibles (veuillez noter que
les prix et les conditions changeront au fil du temps).
Mobilock Free (incapable de mettre à jour les logiciels)
SOTI (MobiControl) (can be expensive - $2.20/device/month)
Miradore (pas de prise en charge à distance)
Applock (ne peut contrôler la mise à jour des logiciels)
AcDisplay (ne peut contrôler la mise à jour des logiciels)
F-Droid (ne peut limiter la consommation de données)
APPDroid (ne peut limiter la consommation de données)
Master List (ne peut contrôler la mise à jour des logiciels)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Mise à l'échelle Mobile Device Management
41
Firebase (ne peut limiter la consommation de données)
Intunes (les utilisateurs doivent utiliser MS Office 365)
MobileIron (peut être coûteux - 3,15 USD /appareil/mois + 2,368 USD pour le déploiement)
IBM Maas360 (trop cher - 1,60 USD /appareil/mois + 0,50 USD /appareil/mois pour
l'assistance à distance, pour 3.000 appareils)
AirWatch (ne répond pas et peut être coûteux - 3,80 USD /appareil/mois pour 3 000
appareils pendant 3 ans)
XenMobile (Citrix) (peut être coûteux - 2,03 USD /appareil/mois pour 3 000 appareils)
Good for Enterprise (Blackberry) (peut être coûteux - 2 USD /appareil/mois + 2500 USD
pour le déploiement)
Note
Check the specific Mobile Device Management Guideline for more
information about this topic.
Formation
La formation des utilisateurs et, si nécessaire, celle des équipes de soutien aux utilisateurs, est
une étape importante avant le déploiement. Il existe de nombreuses stratégies de formation que
vous pouvez suivre et cela dépendra de la taille du groupe à former, de son niveau de
compétence, du temps disponible, du budget, etc. Il est important de consacrer du temps et de
l'énergie à la conception de votre stratégie de formation et de prévoir suffisamment de temps
pour atteindre vos objectifs de formation. Le fait d'avoir des utilisateurs bien formés et informés
réduira l'anxiété des utilisateurs ainsi que les problèmes d'adoption et augmentera également la
qualité des données recueillies.
Technical Preparations for the Training
Lors de la préparation de la formation, assurez-vous que toutes les exigences techniques
pratiques sont respectées. Cela implique notamment que les tablettes/appareils mobiles soient
disponibles, avec la nouvelle application DHIS 2 Capture Android installée. En fonction de la
disponibilité de la connectivité Internet dans la zone où se déroulera la formation, vous pourriez
synchroniser toutes les tablettes avec le serveur, afin de disposer de suffisamment de données et
de la bonne configuration pour la formation. Avant la formation, les exercices doivent être testés
pour s'assurer que tout fonctionne. Les problèmes détectés lors des tests doivent être résolus
afin de les éviter pendant la formation. Vous pouvez effectuer un deuxième cycle de test pour
repérer les problèmes manqués lors du premier cycle.
Au terme de la formation, si la formation est effectuée à partir de données et d'une configuration
pré-synchronisées, assurez-vous que les stagiaires se familiarisent avec l'application en
accédant au serveur DHIS 2 à distance. Cela permettra aux stagiaires de faire l'expérience d'une
synchronisation réelle, qui peut impliquer des retards dans le réseau. Si les stagiaires n'ont
aucune idée des retards dans le réseau, ils pourront plus tard les interpréter comme des
défaillances de leur appareil.
Training Budget
Vous trouverez ci-dessous quelques lignes directrices relatives à la préparation du budget, tirées
des [DHIS 2 Community Health Information System Guidelines (Lignes directrices du DHIS 2
relatives au système d'information sur la santé communautaire)] (https://s3-eu-
west-1.amazonaws.com/content.dhis2.org/Publications/CHIS+Guidelines+Fr.pdf) publiées par
l'université d'Oslo :
Respectez les politiques organisationnelles en utilisant les modèles de budget et les taux
approuvés (indirects, ASQ, etc.) pour toutes les dépenses, y compris :
•
•
•
•
•
•
•
•
Mise à l'échelle Formation
42
Voyages (par exemple, carburant, location de voiture, hébergement)
Personnel (par exemple, indemnités journalières, frais de repas)
Lieu (par exemple, salle de conférence, pauses-café)
Matériel (par exemple, impression, hardware et projecteurs)
Articles divers
Établir un budget sur la base de calculs effectués à l'aide de feuilles de calcul portant sur
les ressources nécessaires, le coût unitaire de ces ressources et le nombre d'unités
nécessaires. Vous pouvez également intégrer des multiplicateurs supplémentaires pour
illustrer le nombre d'unités par participant. Cela permet de faire preuve de souplesse dans
l'actualisation du budget si les coûts unitaires changent ou si le nombre de participants
augmente ou diminue.
Budgétisez les dépenses prévues en monnaie locale, avec un taux de conversion intégré
(qui peut être mis à jour si nécessaire) pour les convertir dans la monnaie souhaitée par
votre organisation ou votre institution de financement(2).
Training Agenda
Dans le document DHIS 2 Community Health Information System Guidelines rédigé par
l'université d'Oslo, il est recommandé de prendre en compte les éléments suivants :
Le type de mobilier dont vous avez besoin (table ronde, bureaux individuels, etc.).
Exigences en matière de technologie (ordinateurs pour tous, bande passante Wi-Fi, etc.),
Financement des honoraires du centre de conférence, de la nourriture et des boissons des
participants
Les formateurs ont besoin de se déplacer pour observer et assister chaque participant.
Informez-vous du nombre de participants attendus à chaque formation, puisque vous devrez
prévoir suffisamment de matériel et de place. L'espace disponible pour l'événement doit être
suffisamment grand pour le groupe et également adapté aux activités prévues.
Training Materials
Le même document contient également des recommandations relatives au matériel de formation,
que nous présentons ici. Le matériel dont vous aurez besoin pour vos formations dépendra de
vos activités. Afin de vous assurer que tout est bien planifié, parcourez votre programme de
formation avec un partenaire, et discutez de ce qui sera réalisé pour chaque partie de la
formation, en tenant compte du matériel requis.
Le programme des sessions de formation doit être défini bien avant la formation et figurer dans
les documents qui seront distribués aux participants.
La documentation destinée aux utilisateurs doit être présentée sous la forme de Manuels
sommaire. Ces manuels expliquent une tâche de travail spécifique (par exemple, saisir les
données mensuelles du registre de santé du village ou comparer la santé de votre village avec
celle des villages voisins). Après avoir expliqué la tâche de travail, le manuel sommaire fournit des
instructions numérotées, étape par étape, avec des captures d'écran, pour permettre aux
utilisateurs de savoir exactement quoi faire. Notez que les manuels sommaires n'expliquent PAS
séparément les fonctionnalités de l'application, comme le ferait un manuel d'utilisation typique
d'un fournisseur. Étant donné que les utilisateurs préfèrent pratiquer et non lire, les manuels
doivent être aussi brefs que possible tout en contenant toutes les étapes.
•
•
•
•
•
•
•
1.
2.
3.
4.
Mise à l'échelle Training Agenda
43
Déploiement
À ce stade, vous devez être en mesure de déployer les appareils et l'application auprès de vos
utilisateurs finaux. Vous devrez alors préparer et coordonner la mise en service, et décider si
vous conserverez des systèmes parallèles au cas où vous utiliseriez d'autres applications ou si
vous les remplacerez directement. En ce qui concerne les processus papier et manuels, vous
devrez également décider si vous souhaitez les éliminer, les reproduire ou en conserver un
doublon. Assurez-vous de choisir judicieusement le moment de mise en service. Choisissez un
moment où les équipes seront disponibles pour consacrer le temps et les efforts supplémentaires
nécessaires pour s'adapter à l'utilisation de la nouvelle application et assurez-vous également
qu'une assistance supplémentaire sera disponible pendant les phases initiales.
Vous trouverez ci-dessous des recommandations relatives à cette phase de mise en œuvre tirées
du document DHIS 2 Community Health Information System Guidelines élaboré par l'Université
d'Oslo.
Les utilisateurs finaux de la nouvelle application devraient disposer d'un seul point d'appui.
Idéalement, leur superviseur peut leur fournir ce soutien. Étant donné que les utilisateurs
connaissent bien leur superviseur et bénéficient d'un soutien par rapport à d'autres questions, le
soutien de l'application par les superviseurs constitue alors un avantage.
Vous avez peut-être déjà mis en place un système de soutien à plusieurs niveaux pour le DHIS 2
basé sur le web et vous pouvez peut-être l'utiliser pour assurer également le soutien de
l'application. Le système à plusieurs niveaux implique que les questions simples peuvent être
traitées par des superviseurs de niveau inférieur et que les questions plus difficiles ou complexes
sont traitées par des superviseurs de niveau supérieur jusqu'à ce qu'elles soient traitées par une
personne capable de les traiter. La grande majorité des questions nécessitant une assistance
seront des questions simples qui devraient pouvoir être traitées par le premier niveau
d'assistance. Ce premier niveau est souvent celui des superviseurs directs de l'utilisateur. Ce
niveau devrait être en mesure de traiter les problèmes matériels et logiciels simples. Si les
superviseurs ne peuvent pas résoudre le problème, il faudra alors le faire remonter à un niveau
supérieur. Les demandes du deuxième niveau sont souvent traitées par les responsables des
systèmes d'information au niveau du district ou au niveau infranational, lesquels sont formés pour
gérer les problèmes liés à la configuration du système et tous les problèmes avancés concernant
l'interface utilisateur, les importations et les exportations de données. Les demandes de niveau
trois sont généralement traitées par les personnes chargées de l'assistance informatique au
niveau central. Ils doivent être en mesure de répondre à toute demande de maintenance en aval.
Les niveaux de soutien peuvent varier en fonction de la complexité et de la taille de votre projet.
Quel que soit le nombre de niveaux, il est indispensable que les demandes de soutien soient
soumises par n'importe quel utilisateur directement par le web, par téléphone ou par courrier
électronique. Une fois qu'une demande de soutien est envoyée à l'équipe technique, celle-ci doit
accuser réception de la demande dans un bref délai, par exemple 12 heures (2).
Déploiement Training Materials
44
Vous devriez maintenant avoir un plan de suivi des appareils que vous confiez à vos équipes.
Voici quelques bonnes pratiques que vous pourriez adopter dans le cadre du suivi des appareils
(2) :
Numérotez chaque boîte de téléphone (tablette) et faites deux copies du contrat de
téléphonie (c'est-à-dire #1 sur une boîte et sur les deux formulaires de contrat) et remettez
les deux à un superviseur de l'agent de santé communautaire qui remplira les formulaires
en fonction des détails de ce téléphone.
Veillez à ce que les téléphones et les boîtes ne soient pas confondus.
Rassemblez les formulaires d'engagement, faites signer et cacheter les deux exemplaires
par un conseil. Un exemplaire sera conservé par le district, et l'autre sera renvoyé au
partenaire et conservé dans le classeur du bureau du district.
Utilisez un générateur de code QR pour générer un code QR avec les informations du
téléphone (numéro, ACS, numéro de SIM, quartier, etc.). Vous pouvez ensuite imprimer ce
code QR sur une étiquette autocollante résistante et l'appliquer à l'arrière du téléphone ou
à l'intérieur du téléphone dans le compartiment de la batterie.
Si vous fournissez des cartes SIM avec des téléphones, indiquez la carte SIM et le
téléphone correspondants.
Pour éviter toute tentative d'altération de la carte SIM fournie avec le téléphone, collez la
carte SIM dans le téléphone en la plaçant dans le téléphone et en appliquant de la colle à
l'arrière.
Vous devriez également vous pencher sur la question de la Propriété et de l'Utilisation des
appareils. Il est important de clarifier la "propriété" des appareils (téléphones, tables, etc.) au
moment même où vous les remettez aux utilisateurs, ainsi que les responsabilités en matière
d'entretien, de maintenance et de perte. La confusion règne souvent lorsqu'il s'agit de savoir si
l'appareil appartient à l'institution ou à l'individu, et quelles sont les responsabilités respectives.
Cependant, si les utilisateurs finaux sont censés utiliser des appareils personnels, il est d'autant
plus important de clarifier les questions relatives au coût du temps de connexion/données ainsi
que le mécanisme de remboursement (2).
•
•
•
•
•
•
Déploiement Training Materials
45
Mobile Implementation Checklist
Tâche Terminée
Analyse de la technologie Android App et des
exigences relatives aux serveurs
☐
Stratégie pour la sécurité et la confidentialité des
données
☐
Installation et configuration du serveur DHIS 2 ☐
Instances du serveur DHIS 2 ☐
Éléments de données, Ensembles d'options,
Programmes...
☐
Configuration visuelle ☐
Définir les indicateurs et les légendes des
programmes
☐
Configuration des règles du programme ☐
Création d'un utilisateur Android ☐
Paramètres de partage et considérations de
sécurité
☐
Installation et configuration de l'Application ☐
Installation de l'application ☐
Connexion à l'applicatioon ☐
Test ☐
Tests effectués en interne ☐
Tests d'acceptation de l'utilisateur ☐
Test sur le terrain / Projet pilote ☐
Projet pilote ☐
Mise à l'échelle ☐
Acquisition de matériel ☐
Stratégie de distribution de l'application ☐
Stratégie de gestion des appareils mobiles ☐
Contrats de télécommunications ☐
Formation ☐
Préparations techniques ☐
Budgétisation ☐
Programme et Participants ☐
Matériel ☐
Plan de déploiement ☐
Mobile Implementation Checklist Training Materials
46
