View
2
Download
0
Category
Preview:
Citation preview
Caractéristiques techniques
«Système d’information d’épidémio-surveillance
de maladies en Tunisie : Acquisition et la mise en
œuvre d’une application de gestion de
l’information pour le renforcement du système
de veille sanitaire »
2/29
Sommaire
I. Note introductive............................................................................................................................. 4
II. Spécifications générales du besoin .................................................................................................. 4
A. Un outil en ligne ........................................................................................................................... 5
B. Solution évolutive ........................................................................................................................ 5
C. Technologies Open Source .......................................................................................................... 6
D. Sécurité de l’application et des données ..................................................................................... 6
III. Description du système d’information nécessaire ...................................................................... 6
A. Schéma de l’organisation générale ............................................................................................. 6
B. Les utilisateurs ............................................................................................................................. 8
1. Différents acteurs, différentes catégories : gestion des droits ............................................... 8
a) Médecins Libre Pratique et Services des Urgences ..................... Erreur ! Signet non défini.
b) Coordinateurs de l’ONMNE ................................................................................................. 9
2. Pyramide sanitaire : gestion des groupes ................................................................................ 9
3. Administration des utilisateurs .............................................................................................. 10
C. Module de recueil et de collecte des données .......................................................................... 10
1. Page d’accueil ........................................................................................................................ 10
a) MLP : Saisie journalière ..................................................................................................... 10
b) SU : Saisie hebdomadaire .................................................................................................. 11
2. Syndrome sous surveillance .................................................................................................. 12
3. Données agrégées ................................................................................................................. 13
4. Relance des non répondants ................................................................................................. 14
5. Rétro-saisie et validation des données transmises à la coordination ................................... 14
D. Module d’analyse et rapports ................................................................................................... 15
1. Choix de l’outil de statistique ................................................................................................ 15
2. Automatisation du plan d’analyses ....................................................................................... 16
3. Rapport d’analyses, tableaux de bord, courbes épidémiques .............................................. 16
a) Premier niveau de rétro-information ................................................................................ 16
b) Second niveau de rétro-information ................................................................................. 17
E. Sécurité des données ................................................................................................................. 17
1. Sécurisation des flux .............................................................................................................. 17
2. Authentification ..................................................................................................................... 17
3. Sauvegarde et chiffrement .................................................................................................... 17
4. Sécurisation physique des locaux hébergeant les serveurs .................................................. 18
F. Elargissement du réseau ............................................................................................................ 18
1. Ajout de nouveaux membres du réseau................................................................................ 18
3/29
2. Ajout de nouveaux syndromes .............................................................................................. 18
3. Plateforme de questionnaires en ligne pour des enquêtes ponctuelles ............................... 19
G. Documentation et Animation du réseau ................................................................................... 21
H. Contexte d’utilisation sur le terrain ........................................................................................... 21
IV. Ressources humaines ................................................................................................................ 22
A. Profil informatique technique ................................................................................................... 22
B. Profil épidémiologie ................................................................................................................... 22
C. Profil santé technique ................................................................................................................ 22
V. Transfert de compétences et accompagnement........................................................................... 23
A. Formation administrateur ......................................................................................................... 23
1. Formation des coordinateurs responsables du système et du réseau .................................. 23
2. Formation de l’ingénieur informatique responsable du serveur et de la salle serveur ........ 23
B. Formation utilisateurs finaux ..................................................................................................... 24
C. Déploiement et accompagnement ............................................................................................ 24
VI. Spécifications techniques préconisées du serveur hébergeant le système .............................. 25
A. Configurations techniques requises .......................................................................................... 25
B. Infrastructure préconisée .......................................................................................................... 25
C. Stratégie préconisée pour le déploiement de l’outil ................................................................. 26
VII. Contraintes règlementaires ....................................................................................................... 27
VIII. Calendrier prévisionnel de réalisation ....................................................................................... 28
IX. Livrables ..................................................................................................................................... 29
4/29
I. Note introductive
L’Observatoire National des Maladies Nouvelles et Emergentes (ONMNE) est actuellement en phase
de mise en place de quatre réseaux de surveillance en Tunisie :
1. Le réseau sentinelle basé sur les urgences,
2. Le réseau sentinelle basé sur les médecins de libre pratique,
3. Le réseau de surveillance des infections neuro-invasives virales,
4. Le réseau de surveillance basé sur les événements.
L’objectif des réseaux mis en place consiste à générer des alertes sanitaires afin de détecter préco-
cement des épidémies et de mettre en place des mesures de riposte immédiates.
Suite aux ateliers présidés par l’ONMNE l’année 2015, les principaux axes des protocoles de surveil-
lance pour ce système d’alerte ont pu être discutés et actés avec les représentants de chaque réseau.
Des échanges autour de l’outil informatique permettant la collecte des données ont également per-
mis d’amorcer les premières grandes fonctionnalités du système d’information cible.
II. Spécifications générales du besoin
L’outil nécessaire à la mise en place du système de surveillance de veille et d’alerte devra répondre
aux objectifs suivants :
‒ Collecter hebdomadairement les données agrégées par deux groupes d’âge et relatives aux
syndromes pris en charge par les réseaux ;
‒ Centraliser la collecte réalisée à travers le pays dans une base de données unique avec une
compartimentation totale par réseau ;
‒ Faciliter l’analyse centralisée des données transmises chaque semaine à l’équipe de l’ONMNE
coordinatrice des réseaux ;
‒ Permettre la publication de la rétro-information hebdomadaire de premier et second ni-
veau :
o Nombre de cas déclarés ;
o Mise en ligne de courbes présentant un ensemble d’indicateurs par semaine, par
syndrome, par groupe d´âge et par région (ex : nombre de cas déclarés, nombre de
médecins déclarants, nombre de services d’urgences, morbidité proportionnelle,
etc.) ;
o Mise en ligne des alertes sanitaires ;
o Mise en ligne des bulletins mensuels épidémiologiques.
L’adhésion à chaque réseau est fondée sur du volontariat, ce qui implique que l’ergonomie et la sim-
plicité du système sont les facteurs clé de la réussite du réseau. Chaque membre de l’un des réseaux
doit pouvoir inclure dans son travail quotidien la saisie hebdomadaire des cas rencontrés sans com-
plexité ni surcharge.
De plus, l’outil qui sera finalement choisi devra rester en cohérence avec les outils déjà utilisés au
sein de l’ONMNE et pour lesquels une compétence interne a éventuellement déjà été formée.
5/29
A. Un outil en ligne
Le système d’alerte sanitaire étant fondé sur des réseaux de médecins privés, urgentistes labora-
toires et direction régionales de santé à travers tout le territoire Tunisien, l’outil développé
s’appuiera sur des technologies web et le réseau internet.
Le choix d’un outil accessible en ligne se justifie principalement par les arguments suivants :
‒ La saisie des données sera multi-centrique et se déroulera à l’échelle nationale avec un
échantillon d’utilisateurs dans chaque région de Tunisie ;
‒ La saisie et la transmission des données à la coordination doivent être immédiates afin
d’être en mesure de déclencher une alerte sanitaire le plus rapidement possible ;
‒ L’analyse des données doit être centralisée et la plus automatisée possible afin de faciliter
la production de résultats hebdomadaires et le déclenchement de l’alerte et la riposte ;
‒ La rétro-information doit être publiée très rapidement et être accessible simplement pour
les membres des réseaux car elle est un moteur à l’adhésion de chacun ;
‒ Le système doit être indépendant du matériel informatique utilisé par l’utilisateur ;
‒ Le système ne doit pas nécessiter d’installation sur le poste informatique permettant la sai-
sie ;
‒ Le stockage et l’accès aux données saisies doivent être sécurisés.
Les contraintes qui en résultent se résument à :
‒ L’accessibilité de chaque utilisateur à du matériel informatique connecté ;
‒ La couverture et la stabilité du réseau internet.
Pour une première phase du projet, ces conditions matérielles semblent tout à fait envisageables par
le réseau. Si par la suite des blocages surviennent et entrainent une démotivation des membres du
réseau, une portabilité sur tablette connectée en 3G à l’outil de collecte sera envisagée. L’application
développée sera compatible à l’utilisation sur tablette.
Enfin, dans une seconde phase du projet, un développement supplémentaire de l’outil pourra per-
mettre aux membres du réseau la saisie des données hors ligne, sans connexion internet.
B. Solution évolutive
Le système d’information permettant la collecte des données, leur analyse et la rétro-information
aux membres des réseaux devra être une solution évolutive. En effet, les réseaux des SU et des MLP
ainsi que leur système de surveillance sont encore en phase de mise en place, de développement et
de consolidation. En conséquence, l’outil devra être adaptable et devra accompagner les évolutions
du système de surveillance comme :
‒ L’élargissement du nombre de membres, évolution du nombre d’utilisateurs
(ajout/modification/suppression) ;
‒ L’ajustement de leurs droits respectifs au fil du temps ;
‒ L’adaptation des formulaires de saisie ;
‒ L’activation/Désactivation des syndromes en étude et des évènements de santé à surveil-
ler ;
‒ L’évolution des plans d’analyse, de la définition des alertes et des seuils.
6/29
C. Technologies Open Source
L’outil informatique développé se basera sur des technologies web Open-Source. Un tel choix permet
de s’affranchir d’achat de licences logiciel, et de favoriser un transfert de compétences vers des res-
sources locales.
D. Sécurité de l’application et des données
Les données collectées, analysées et plus généralement manipulées sont des données médicales et
confidentielles qui revêtent une sensibilité particulière. L’outil informatique développé devra garantir
un niveau de sécurité des couches applicatives et des bases de données. Une certification ou un
agrément attestant de ce niveau de sécurité est un plus.
III. Description du système d’information nécessaire
Ce chapitre décrit chaque module de la solution logicielle qui sera développée conjointement pour
les réseaux SU et MLP et la coordination de l’ONMNE.
A. Schéma de l’organisation générale
Le système de surveillance des maladies déployé sur le territoire tunisien, sera fondé sur quatre ré-
seaux distincts :
1. Le réseau sentinelle basé sur les urgences,
2. Le réseau sentinelle basé sur les médecins de libre pratique,
3. Le réseau de surveillance des infections neuro-invasives virales,
4. Le réseau de surveillance basé sur les événements.
Malgré des pratiques et un travail quotidien sensiblement différents, les quatre réseaux observeront
une organisation commune. Le schéma ci-après illustre l’organisation générale du système de surveil-
lance qui sera mis en place :
� les membres des réseaux saisissent les cas syndromiques rencontrés parmi leurs consulta-
tions de la semaine ;
� Les données agrégées saisies en ligne sont centralisées sur la base de données de
l’ONMNE à Tunis, monitorées, validées et analysées;
� Des courbes, listings, seuils d’alerte sont mis en ligne et publiés chaque semaine aux
membres des réseaux.
Figure : Schéma de l’organisation générale des réseaux autour du système d’information
Investigations, alertes sanitaires et ripostes
des réseaux de surveillance
Une équipe de coordination
‒ L’administration du serveur hébergeant les données dans les locaux de l
d’une autre structure
‒ La gestion de la salle serveur (panne électrique, onduleur, climatisation, etc
‒ Le monitoring des données saisies, les contrôles de cohérence
‒ Le retour vers les médecins et urgentistes en cas d’erreur de saisie
‒ La relance en cas de retard de saisie ;
‒ La validation des données
‒ Les analyses hebdomadaires
‒ La publication de la rétro
‒ Les investigations d’épidémies suspectées, le déclenchement des alertes sanitaires et
l’organisation de la riposte
‒ Le support aux utilisateurs
‒ L’évolution du système
pement des syndromes)
: Schéma de l’organisation générale des réseaux autour du système d’information
Investigations, alertes sanitaires et ripostes seront dans un second temps menées par
: l’ONMNE.
ne équipe de coordination devra donc être identifiée au sein de l’Observatoire
L’administration du serveur hébergeant les données dans les locaux de l
d’une autre structure (mise à jour, gestion des pannes, relance, sécurité, etc
La gestion de la salle serveur (panne électrique, onduleur, climatisation, etc
Le monitoring des données saisies, les contrôles de cohérence, la qualit
Le retour vers les médecins et urgentistes en cas d’erreur de saisie ;
en cas de retard de saisie ;
La validation des données ;
Les analyses hebdomadaires ;
La publication de la rétro-information et des bulletins épidémiologiques
Les investigations d’épidémies suspectées, le déclenchement des alertes sanitaires et
l’organisation de la riposte ;
Le support aux utilisateurs ;
L’évolution du système de surveillance (gestion des utilisateurs, gestion des droits, dévelo
yndromes).
7/29
: Schéma de l’organisation générale des réseaux autour du système d’information
dans un second temps menées par la coordination
devra donc être identifiée au sein de l’Observatoire afin d’assurer :
L’administration du serveur hébergeant les données dans les locaux de l’ONMNE ou au sein
(mise à jour, gestion des pannes, relance, sécurité, etc.) ;
La gestion de la salle serveur (panne électrique, onduleur, climatisation, etc.) ;
, la qualité des données ;
information et des bulletins épidémiologiques ;
Les investigations d’épidémies suspectées, le déclenchement des alertes sanitaires et
surveillance (gestion des utilisateurs, gestion des droits, dévelop-
Figure : exemple de
B. Les utilisateurs
Chaque utilisateur de l’outil de collecte se verra attribuer un compte unique et personnel et
permettra de s’identifier.
Un compte utilisateur sera défini par
‒ Un login (ex : p.nom
‒ Un mot de passe sécurisé répondant idéalement aux critères suivants
o Au moins 8 caractères dont au minimum une lettre majuscule et un chiffre ;
o Différent du login ;
o Durée de validité limitée et paramétrée par l’
o Obligation de changer le mot de passe lors de l'expiration ;
o Obligation de fournir un mot de passe différent des trois derniers mots de passe ;
o Les mots de passe sont chiffrés de façon irréversible.
‒ Une catégorie : un ensemble de droits li
‒ Un groupe : un compartiment de la base de données
1. Différents acteurs
a)
Les membres des réseaux seront des utilisateurs de l’outil de collecte de données bénéficiant des
mêmes droits d’accès décrit
‒ Page d’accueil avec état des lieux de la saisie hebdomadaire
‒ Module permettant la
‒ Documentation en ligne
‒ Rétro-information de premier et second niveau
• Liste des cas déclarés les semaines passés (line listing)
exemple de Schéma des flux d’informations des membres des réseaux
Chaque utilisateur de l’outil de collecte se verra attribuer un compte unique et personnel et
sera défini par :
p.nom) ;
sécurisé répondant idéalement aux critères suivants
Au moins 8 caractères dont au minimum une lettre majuscule et un chiffre ;
Différent du login ;
Durée de validité limitée et paramétrée par l’administrateur ;
Obligation de changer le mot de passe lors de l'expiration ;
Obligation de fournir un mot de passe différent des trois derniers mots de passe ;
Les mots de passe sont chiffrés de façon irréversible.
: un ensemble de droits limités ;
un compartiment de la base de données.
ifférents acteurs, différentes catégories : gestion des droits
Les membres des réseaux
seront des utilisateurs de l’outil de collecte de données bénéficiant des
mêmes droits d’accès décrits ci-après :
Page d’accueil avec état des lieux de la saisie hebdomadaire ;
permettant la saisie des données de la semaine ;
Documentation en ligne : définition des cas, charte du réseau, manuel utilisateur, etc.
information de premier et second niveau :
Liste des cas déclarés les semaines passés (line listing) ;
8/29
des membres des réseaux
Chaque utilisateur de l’outil de collecte se verra attribuer un compte unique et personnel et qui lui
sécurisé répondant idéalement aux critères suivants :
Au moins 8 caractères dont au minimum une lettre majuscule et un chiffre ;
administrateur ;
Obligation de fournir un mot de passe différent des trois derniers mots de passe ;
: gestion des droits
seront des utilisateurs de l’outil de collecte de données bénéficiant des
: définition des cas, charte du réseau, manuel utilisateur, etc.
• Possibilité d’exporter leurs propres données au format directement
Excel ou STATA
• Courbes du nombre de cas déclarés par réseau, par syndrome, par région
• Bulletin hebdomadaire épidémiologique, etc.
b)
L’équipe de coordination du réseau bénéficiera d’un accès
‒ Accès aux fiches de déclaration de chaque réseau
‒ Accès au monitoring (liste des évènements qui ont eu lieu sur la base de données)
‒ Module d’analyse en ligne
‒ Module d’export des données
2. Pyramide sanitaire
Une pyramide sanitaire pourra être implémentée
La compartimentation des données dans la base pourra ainsi respecter
et l’analyse des données pourra être présentée de manière segmentée ou groupée selon le niveau
d’agrégation géographique.
Figure : Schématisation de la c
Chaque utilisateur du système d’information sera donc affecté à un groupe
A titre d’exemple, un médecin de libre pratique sera affecté à un Gouvernorat, lui
un CROM de Tunisie. Par cette compartimentation, chaque utilisateur ne pourra consulter que les
Possibilité d’exporter leurs propres données au format directement
Excel ou STATA ;
Courbes du nombre de cas déclarés par réseau, par syndrome, par région
Bulletin hebdomadaire épidémiologique, etc.
Coordinateurs de l’ONMNE
L’équipe de coordination du réseau bénéficiera d’un accès dont les droits seront
Accès aux fiches de déclaration de chaque réseau : consultation, modification
Accès au monitoring (liste des évènements qui ont eu lieu sur la base de données)
Module d’analyse en ligne ;
Module d’export des données.
Pyramide sanitaire : gestion des groupes
pyramide sanitaire pourra être implémentée selon l’organisation du territoire tunisien.
Figure : Exemple de pyramides sanitaires
La compartimentation des données dans la base pourra ainsi respecter la pyramide
des données pourra être présentée de manière segmentée ou groupée selon le niveau
.
Schématisation de la compartimentation de la base de données
Chaque utilisateur du système d’information sera donc affecté à un groupe de la pyramide sanitaire.
xemple, un médecin de libre pratique sera affecté à un Gouvernorat, lui
Par cette compartimentation, chaque utilisateur ne pourra consulter que les
9/29
Possibilité d’exporter leurs propres données au format directement exploitable sous
Courbes du nombre de cas déclarés par réseau, par syndrome, par région ;
seront plus larges :
: consultation, modification ;
Accès au monitoring (liste des évènements qui ont eu lieu sur la base de données) ;
nisation du territoire tunisien.
pyramide sanitaire retenue,
des données pourra être présentée de manière segmentée ou groupée selon le niveau
ompartimentation de la base de données
de la pyramide sanitaire.
xemple, un médecin de libre pratique sera affecté à un Gouvernorat, lui-même rattaché à
Par cette compartimentation, chaque utilisateur ne pourra consulter que les
10/29
données qui lui sont propres : un médecin ne verra que les déclarations qu’il a réalisées ; un urgen-
tiste ne verra que les déclarations réalisées dans son service d’urgence. De plus, il serait envisageable
de créer un utilisateur affecté au niveau hiérarchique du CROM, par exemple celui de Beja, et qui
aurait ainsi accès en lecture uniquement aux courbes épidémiologiques et aux dernières alertes de
son CROM.
3. Administration des utilisateurs
Les comptes utilisateurs pourront être créés, modifiés, désactivés, en toute autonomie par un coor-
dinateur de l’ONMNE. Un transfert de compétence sur l’administration des comptes devra être réali-
sé.
C. Module de recueil et de collecte des données
1. Page d’accueil
Une fois son login et son mot de passe saisis, l’utilisateur est dirigé vers la page d’accueil du système
d’information. Selon son profil, celle-ci pourra présenter quelques variantes parmi les modules sui-
vants :
‒ Une bannière contenant le logo de l’ONMNE ainsi que le numéro d’une ligne directe en cas
de blocage sur le logiciel ou en cas d’alerte sanitaire hors syndromes surveillés ;
‒ Un menu contenant les fonctionnalités disponibles selon chaque profil utilisateur (MLP, SU,
ONMNE) ;
‒ Un bandeau contenant un message du coordinateur ;
‒ Un module de collecte : hebdomadaire ou journalier ;
‒ Un lien vers la rétro-information et les tableaux de bord.
La charte graphique de l’application existante « West Nile » pourra être valorisée et servir de socle
commun aux deux applications en ligne afin de garantir une certaine homogénéité.
L’ergonomie est un des facteurs clés de l’application et des maquettes seront étudiées et travaillées
avec les utilisateurs afin de minimiser au maximum la navigation d’un écran à l’autre lors de la re-
cherche d’une information ou d’une fonctionnalité sur l’outil.
Médecins de libre pratique et Urgentistes auront un accès privilégié à l’état de leur saisie respective
pour la semaine en cours.
Un code couleur permettra de distinguer les semaines (ou les jours) renseignées (vert) de celles tou-
jours en attente de saisie (orange). A l’issue de la saisie de chaque semaine (ou chaque jour), un bou-
ton « Transmettre les données à la Coordination » permettra de valider la saisie et activera ainsi la
coloration du bouton.
a) MLP : Saisie journalière
Dans le contexte organisationnel des Médecins de Libre Pratique, un planning journalier leur permet
de suivre leurs consultations réalisées dans la semaine. La saisie journalière des cas rencontrés au
cours de la journée peut donc facilement s’intégrer dans leurs tâches quotidiennes : à chaque fin de
journée, ou entre deux consultations, le médecin peut se connecter à l’outil de collecte pour saisir
ses données de surveillance du jour.
La page d’accueil associée à ce planning journalier de la saisie pourrait se présenter selon la m
quette ci-dessous :
Figure : Maquette page d’accueil Médecins de Libre Pratique
Le module de collecte présente un bouton par jour de la semaine. Sur la semaine en cours, chaque
jour dont la saisie a été réalisée se colore d’un feu vert. Différents boutons permettent au MLP
Accéder à la fiche déclarée précédemment
Ajouter une fiche de déclaration
Déclarer une absence de consultation pour le jour donné
b)
Dans le contexte organisationnel des Services d’Urgence, la saisie journalière des données par une
personne dédiée au sein du service n’est pas
fois par semaine, et les données seront alors agrégées s
La page d’accueil de l’urgentiste responsable de la saisie présentera un bouton par semaine à saisir.
De la même manière que pour les MLP, chaque semaine validée sera colorée d’un feu vert.
La page d’accueil associée à ce planning journalier de la saisie pourrait se présenter selon la m
: Maquette page d’accueil Médecins de Libre Pratique
Le module de collecte présente un bouton par jour de la semaine. Sur la semaine en cours, chaque
jour dont la saisie a été réalisée se colore d’un feu vert. Différents boutons permettent au MLP
Accéder à la fiche déclarée précédemment ;
ne fiche de déclaration pour le jour sélectionné ;
Déclarer une absence de consultation pour le jour donné.
SU : Saisie hebdomadaire
Dans le contexte organisationnel des Services d’Urgence, la saisie journalière des données par une
personne dédiée au sein du service n’est pas envisageable. Cette tâche sera
fois par semaine, et les données seront alors agrégées sur cet intervalle de temps.
La page d’accueil de l’urgentiste responsable de la saisie présentera un bouton par semaine à saisir.
De la même manière que pour les MLP, chaque semaine validée sera colorée d’un feu vert.
11/29
La page d’accueil associée à ce planning journalier de la saisie pourrait se présenter selon la ma-
: Maquette page d’accueil Médecins de Libre Pratique
Le module de collecte présente un bouton par jour de la semaine. Sur la semaine en cours, chaque
jour dont la saisie a été réalisée se colore d’un feu vert. Différents boutons permettent au MLP de :
Dans le contexte organisationnel des Services d’Urgence, la saisie journalière des données par une
able. Cette tâche sera en revanche réalisée une
ur cet intervalle de temps.
La page d’accueil de l’urgentiste responsable de la saisie présentera un bouton par semaine à saisir.
De la même manière que pour les MLP, chaque semaine validée sera colorée d’un feu vert.
Figure
Les services d’urgences étant opérationnels 7/7 jours
fonctionnalité pertinente dans ce contexte. En revanche, la personne dédiée à la saisie disposera des
actions suivantes :
Accéder à la fiche déclarée précédemment
Ajouter une fiche de déclaration à la semaine sélectionnée
Une option pourra être implémentée afin de permettre, selon l’organisation de chaque service
d’urgence ou même selon chaque utilisateur, de choisir en
daire.
2. Syndrome sous surveillance
Les données collectées par chaque réseau de surveillance permettront d’alerter quant à l’occurrence
plus ou moins fréquente de certains syndromes parmi leur patient.
Chaque réseau surveille 5 syndromes différents. Ces syndromes peuvent éventuellement avoir des
signes cliniques communs (ex
tient aux urgences). Cependant, ils restent tout à fait indépendants
Pour chaque réseau, une interface permettra de visualiser sur un unique écran les 5 syndromes à
surveiller avec un bouton par syndrome (cf. figure ci
nombre de cas déclarés pour la semaine (ou journée) en
de syndromes Méningite/Méningoencéphalite le même jour, ce qui illustre une alerte sanitaire ce
taine).
Figure : Maquette page d’accueil Service des Urgences
Les services d’urgences étant opérationnels 7/7 jours, la déclaration de non activité
fonctionnalité pertinente dans ce contexte. En revanche, la personne dédiée à la saisie disposera des
Accéder à la fiche déclarée précédemment ;
Ajouter une fiche de déclaration à la semaine sélectionnée.
Une option pourra être implémentée afin de permettre, selon l’organisation de chaque service
d’urgence ou même selon chaque utilisateur, de choisir entre une saisie journalière ou hebdom
Syndrome sous surveillance
Les données collectées par chaque réseau de surveillance permettront d’alerter quant à l’occurrence
plus ou moins fréquente de certains syndromes parmi leur patient.
ille 5 syndromes différents. Ces syndromes peuvent éventuellement avoir des
signes cliniques communs (ex : Etat grippal chez un médecin vs. Etat grippal sévère qui mène le p
tient aux urgences). Cependant, ils restent tout à fait indépendants d’un réseau à
Pour chaque réseau, une interface permettra de visualiser sur un unique écran les 5 syndromes à
surveiller avec un bouton par syndrome (cf. figure ci-dessous). Une vignette pourra indiquer le
nombre de cas déclarés pour la semaine (ou journée) en cours (cf. la figure ci
de syndromes Méningite/Méningoencéphalite le même jour, ce qui illustre une alerte sanitaire ce
12/29
vice des Urgences
, la déclaration de non activité n’est pas une
fonctionnalité pertinente dans ce contexte. En revanche, la personne dédiée à la saisie disposera des
Une option pourra être implémentée afin de permettre, selon l’organisation de chaque service
tre une saisie journalière ou hebdoma-
Les données collectées par chaque réseau de surveillance permettront d’alerter quant à l’occurrence
ille 5 syndromes différents. Ces syndromes peuvent éventuellement avoir des
: Etat grippal chez un médecin vs. Etat grippal sévère qui mène le pa-
d’un réseau à l’autre.
Pour chaque réseau, une interface permettra de visualiser sur un unique écran les 5 syndromes à
dessous). Une vignette pourra indiquer le
cours (cf. la figure ci-dessous présente 2 cas
de syndromes Méningite/Méningoencéphalite le même jour, ce qui illustre une alerte sanitaire cer-
Pour chaque syndrome, deux actions seront mises à disposition
� Accéder à la déclaration
Déclarer l’absence de cas pour ce syndrome, pour chaque tranche d’âge
Accéder à la déclaration
Une documentation pourra
disposition de l’utilisateur un rappel de la définition de chaque cas.
3. Données agrégées
Conjointement entre les membres des réseaux
seront agrégées et ne contiendront aucune donnée nominative
té).
Le système de collecte recueillera
‒ Nombre de consultations par semaine du MLP
‒ Nombre de consultations par semaine par tranche d
‒ Nombre de consultations par syndrome, par tranche d’âge, par semaine
‒ Nombre de passage
‒ Nombre de passages aux urgences de la semaine par tranche d’âge pour le SU (
ans)
‒ Nombre de passages aux urgences des cas hospitalisés/référés/décédés, par tranche d’âge,
de la semaine pour le SU (sévérité)
‒ Nombre de passages aux urgences par syndrome, par sévérité, par tranche d’âge pour le SU.
Figure : Maquette page des syndromes
Pour chaque syndrome, deux actions seront mises à disposition :
Accéder à la déclaration du syndrome en cliquant sur la vignette associée
l’absence de cas pour ce syndrome, pour chaque tranche d’âge
à la déclaration du nombre de cas pour ce syndrome.
a également être téléchargeable sur cette même interface afin d’avoir à
disposition de l’utilisateur un rappel de la définition de chaque cas.
Données agrégées
membres des réseaux, les données de surveillance collectées
seront agrégées et ne contiendront aucune donnée nominative (ex : sexe, date de naissance, local
Le système de collecte recueillera en revanche par exemple :
Nombre de consultations par semaine du MLP
Nombre de consultations par semaine par tranche d’âge du MLP ( ≤14ans
Nombre de consultations par syndrome, par tranche d’âge, par semaine
Nombre de passages aux urgences de la semaine pour le SU
Nombre de passages aux urgences de la semaine par tranche d’âge pour le SU (
Nombre de passages aux urgences des cas hospitalisés/référés/décédés, par tranche d’âge,
de la semaine pour le SU (sévérité)
Nombre de passages aux urgences par syndrome, par sévérité, par tranche d’âge pour le SU.
13/29
en cliquant sur la vignette associée ;
l’absence de cas pour ce syndrome, pour chaque tranche d’âge ;
sur cette même interface afin d’avoir à
, les données de surveillance collectées par syndrome
: sexe, date de naissance, locali-
≤14ans ; >14 ans)
Nombre de consultations par syndrome, par tranche d’âge, par semaine du MLP.
Nombre de passages aux urgences de la semaine par tranche d’âge pour le SU ( ≤14ans ; >14
Nombre de passages aux urgences des cas hospitalisés/référés/décédés, par tranche d’âge,
Nombre de passages aux urgences par syndrome, par sévérité, par tranche d’âge pour le SU.
Les données collectées seront struc
(gouvernorat d’appartenance du médecin ou urgentiste), personne (tranche d’âge).
L’interface de saisie pour chaque syndrome pourra se présenter selon la maquette ci
champ texte libre « Points saillants
tions supplémentaires pertinentes à la coordination
Figure
4. Relance des non répondants
Conformément à l’organisation de la collecte des données décrite dans les paragraphes précédents,
les membres des réseaux pourront saisir leurs données respectives soit une fois par semaine, soit au
fil de l’eau au cours de la semaine.
données devront être saisies et validées
De cette façon, dès le Mardi matin 8h00 des mails de relance automatiques seront générés par le
système de collecte.
5. Rétro-saisie et validation des données transmises à la coordination
Les formulaires de déclaration antérieurs à la date du jour seront accessibles en modific
tion/correction pendant un mois
revanche, au-delà de ce délai, les données ne seront plus modifiables et seront accessibles uniqu
ment en lecture seule par l’utilisateur.
Si le médecin ou l’urgentiste détecte, malgré toute cette vigilance, une erreur de saisie sur les do
nées verrouillées, la modification ne pourra être réalisée que par le niveau central.
l’ONMNE (mail, téléphone) où les coordinateurs du réseau seront à même d’accéder et
les données. Les analyses hebdomadaires devront ensuite être regénéré
Les données collectées seront structurées sur les axes temps (semaine/jour de déclaration), lieu
(gouvernorat d’appartenance du médecin ou urgentiste), personne (tranche d’âge).
L’interface de saisie pour chaque syndrome pourra se présenter selon la maquette ci
Points saillants » permettra au médecin ou à l’urgentiste d’ajouter des inform
tions supplémentaires pertinentes à la coordination, hors statistiques hebdomadaires.
Figure : Maquette de saisie des données agrégées
Relance des non répondants
ent à l’organisation de la collecte des données décrite dans les paragraphes précédents,
pourront saisir leurs données respectives soit une fois par semaine, soit au
fil de l’eau au cours de la semaine. Cette saisie sera rythmée par une date butoir récurrente
données devront être saisies et validées avant chaque Lundi de la semaine au plus tard
De cette façon, dès le Mardi matin 8h00 des mails de relance automatiques seront générés par le
saisie et validation des données transmises à la coordination
Les formulaires de déclaration antérieurs à la date du jour seront accessibles en modific
un mois, même si ceux-ci ont été transmis et validés par l’utilisateur. En
delà de ce délai, les données ne seront plus modifiables et seront accessibles uniqu
ment en lecture seule par l’utilisateur.
Si le médecin ou l’urgentiste détecte, malgré toute cette vigilance, une erreur de saisie sur les do
ées, la modification ne pourra être réalisée que par le niveau central.
l’ONMNE (mail, téléphone) où les coordinateurs du réseau seront à même d’accéder et
les données. Les analyses hebdomadaires devront ensuite être regénérées si besoin.
14/29
temps (semaine/jour de déclaration), lieu
(gouvernorat d’appartenance du médecin ou urgentiste), personne (tranche d’âge).
L’interface de saisie pour chaque syndrome pourra se présenter selon la maquette ci-dessous. Un
» permettra au médecin ou à l’urgentiste d’ajouter des informa-
hors statistiques hebdomadaires.
ent à l’organisation de la collecte des données décrite dans les paragraphes précédents,
pourront saisir leurs données respectives soit une fois par semaine, soit au
une date butoir récurrente : les
au plus tard à 18h00.
De cette façon, dès le Mardi matin 8h00 des mails de relance automatiques seront générés par le
saisie et validation des données transmises à la coordination
Les formulaires de déclaration antérieurs à la date du jour seront accessibles en modifica-
ci ont été transmis et validés par l’utilisateur. En
delà de ce délai, les données ne seront plus modifiables et seront accessibles unique-
Si le médecin ou l’urgentiste détecte, malgré toute cette vigilance, une erreur de saisie sur les don-
ées, la modification ne pourra être réalisée que par le niveau central. Il devra contacter
l’ONMNE (mail, téléphone) où les coordinateurs du réseau seront à même d’accéder et de modifier
es si besoin.
Un module de type « post-it
logue serait alors dédiée à la saisie et l’envoi d’un message au coordinateur du réseau.
D. Module d’analyse et rapports
1. Choix de l’outil
Les données collectées puis transmisses chaque semaine sont ensuite monitorées, validées et anal
sées au niveau central. Les coordinateurs de l’ONMNE pourront réaliser et automatiser une partie de
ces tâches. Plusieurs outils s’offrent à eu
‒ Les coordinateurs de l’ONMNE disposeront d’un module d’export de données sur la base
centrale. Cet export pourra s’adapter à plusieurs formats
• Format STATA
immédiate des dates, de
• Format EpiInfo
• Format CSV
‒ R : un module d’analyse
rectement connecté
rectement en ligne, sans export de données. Les scripts R permettront donc des analyses a
tomatisées et toujours à jour, s’appuyant sur l
Figure : Exemple de script R permettant l’analyse de données
it » pourra être développée pour répondre à ce besoin. Une boite de di
logue serait alors dédiée à la saisie et l’envoi d’un message au coordinateur du réseau.
Module d’analyse et rapports
Choix de l’outil de statistique
Les données collectées puis transmisses chaque semaine sont ensuite monitorées, validées et anal
sées au niveau central. Les coordinateurs de l’ONMNE pourront réaliser et automatiser une partie de
ces tâches. Plusieurs outils s’offrent à eux :
es coordinateurs de l’ONMNE disposeront d’un module d’export de données sur la base
centrale. Cet export pourra s’adapter à plusieurs formats :
Format STATA : fichier csv accompagné d’un script (dofile) permettant la conversion
immédiate des dates, des étiquettes, etc.
Info : fichier .rec directement exploitable sous Epi
Format CSV : fichier csv directement exploitable sur Excel.
un module d’analyse en ligne (utilisant l’outil statistique R http://www.r
connecté à la base de données centrale permettra de réaliser
rectement en ligne, sans export de données. Les scripts R permettront donc des analyses a
tomatisées et toujours à jour, s’appuyant sur les données validées à l’instant de l’analyse
: Exemple de script R permettant l’analyse de données
15/29
» pourra être développée pour répondre à ce besoin. Une boite de dia-
logue serait alors dédiée à la saisie et l’envoi d’un message au coordinateur du réseau.
Les données collectées puis transmisses chaque semaine sont ensuite monitorées, validées et analy-
sées au niveau central. Les coordinateurs de l’ONMNE pourront réaliser et automatiser une partie de
es coordinateurs de l’ONMNE disposeront d’un module d’export de données sur la base
: fichier csv accompagné d’un script (dofile) permettant la conversion
: fichier .rec directement exploitable sous EpiInfo.
http://www.r-project.org/) di-
à la base de données centrale permettra de réaliser des statistiques di-
rectement en ligne, sans export de données. Les scripts R permettront donc des analyses au-
s données validées à l’instant de l’analyse.
: Exemple de script R permettant l’analyse de données
Figure : Exemple d’histogramme généré à partir du module R
2. Automatisation du plan d’a
La conception des tableaux de bord et des rapports d’analyse pourra éventuellement être réalisée en
deux phases :
‒ Phase 1 : Analyse des données en dehors du système et rétro
1) Le coordinateur de l’ONMNE exporte les données d’inté
2) Il réalise l’analyse à l’extérieur du système, en utilisant le logiciel de son choix (ST
TA, SPSS, SAS, Excel, R, etc.).
3) Les tableaux de bord et rapport d’analyse sont développés, puis compilés dans un
document word, PDF, etc.
4) Le coordinateur de l’ONM
l’espace dédié à la rétro
5) Un module d’upload/download permet d’une part au coordinateur de
documents, et d’autre part aux membres des réseaux de les télécharger en ligne.
‒ Phase 2 : Analyse des données directement en ligne sur la base de données centralisée et a
tomatisation de la rétro
Le module d’analyse en ligne, s’appuyant
ragraphe précédent
courbes et les tableaux constituant les rapports. L’intégration de ce module sur l’outil de co
lecte permettra ainsi
L’adjonction de ce module s’accompagnera d’une formation et d’un transfert de compétence
technique à l’utilisation de cet outil R. Cette session de travail permettra également le par
métrage de quelques analyses d
3. Rapport d’analyses
a)
La rétro-information de premier niveau sera assurée par la mise à disposition de listing des déclar
tions à l’utilisateur. Ces listings s’adapteront aux d
que les déclarations qu’il a réalisées, alors qu’un coordinateur visualisera l’ensemble des données
compartimentation décrite au chapitre III.B.2)
: Exemple d’histogramme généré à partir du module R
Automatisation du plan d’analyses
La conception des tableaux de bord et des rapports d’analyse pourra éventuellement être réalisée en
Analyse des données en dehors du système et rétro-information semi
Le coordinateur de l’ONMNE exporte les données d’intérêt.
Il réalise l’analyse à l’extérieur du système, en utilisant le logiciel de son choix (ST
TA, SPSS, SAS, Excel, R, etc.).
Les tableaux de bord et rapport d’analyse sont développés, puis compilés dans un
document word, PDF, etc.
Le coordinateur de l’ONMNE se connecte à l’application en ligne, et dépose dans
l’espace dédié à la rétro-information les documents d’intérêt.
Un module d’upload/download permet d’une part au coordinateur de
documents, et d’autre part aux membres des réseaux de les télécharger en ligne.
Analyse des données directement en ligne sur la base de données centralisée et a
tomatisation de la rétro-information.
Le module d’analyse en ligne, s’appuyant sur le logiciel de statistique R
ragraphe précédent, permet de concevoir directement en ligne les scripts générant les
courbes et les tableaux constituant les rapports. L’intégration de ce module sur l’outil de co
tra ainsi l’automatisation de la rétro-information.
L’adjonction de ce module s’accompagnera d’une formation et d’un transfert de compétence
technique à l’utilisation de cet outil R. Cette session de travail permettra également le par
métrage de quelques analyses de base.
Rapport d’analyses, tableaux de bord, courbes épidémiques
Premier niveau de rétro-information
information de premier niveau sera assurée par la mise à disposition de listing des déclar
tions à l’utilisateur. Ces listings s’adapteront aux droits de chaque utilisateur
que les déclarations qu’il a réalisées, alors qu’un coordinateur visualisera l’ensemble des données
compartimentation décrite au chapitre III.B.2).
16/29
: Exemple d’histogramme généré à partir du module R
La conception des tableaux de bord et des rapports d’analyse pourra éventuellement être réalisée en
information semi-manuelle.
Il réalise l’analyse à l’extérieur du système, en utilisant le logiciel de son choix (STA-
Les tableaux de bord et rapport d’analyse sont développés, puis compilés dans un
NE se connecte à l’application en ligne, et dépose dans
information les documents d’intérêt.
Un module d’upload/download permet d’une part au coordinateur de déposer les
documents, et d’autre part aux membres des réseaux de les télécharger en ligne.
Analyse des données directement en ligne sur la base de données centralisée et au-
sur le logiciel de statistique R et décrit dans le pa-
, permet de concevoir directement en ligne les scripts générant les
courbes et les tableaux constituant les rapports. L’intégration de ce module sur l’outil de col-
L’adjonction de ce module s’accompagnera d’une formation et d’un transfert de compétence
technique à l’utilisation de cet outil R. Cette session de travail permettra également le para-
, tableaux de bord, courbes épidémiques
information de premier niveau sera assurée par la mise à disposition de listing des déclara-
roits de chaque utilisateur : un médecin ne verra
que les déclarations qu’il a réalisées, alors qu’un coordinateur visualisera l’ensemble des données (cf.
17/29
Des exports seront également mis à disposition si nécessaire à l’ensemble des utilisateurs. Par la
segmentation des données, un utilisateur ayant la possibilité de récupérer des extractions n’aura
accès qu’à ses propres données et à celles des groupes auxquels un droit d’accès lui a été donné.
b) Second niveau de rétro-information
Le second niveau de rétro-information pourra présenter de nombreux indicateurs, conformément au
protocole de surveillance de chaque réseau :
‒ Indicateurs de performance hebdomadaires
‒ Indicateurs de surveillance hebdomadaires
‒ Courbes par syndrome, par période de temps, par région
Le module d’analyse en ligne basé sur l’outil statistique R permettra de mettre en ligne automati-
quement, auprès de tous les membres du réseau, les courbes et tableurs présentant ces indicateurs.
Les analyses réalisées à partir d’exports de la base de données vers STATA, pourront quant à elles
être mises en ligne manuellement par les coordinateurs de l’ONMNE chaque semaine dans l’espace
dédié.
E. Sécurité des données
La gestion des données médicales, même agrégées, nécessite un certain niveau de sécurité. Ce cha-
pitre décrit différents aspects de la sécurité préconisée pour un tel système.
1. Sécurisation des flux
Les accès des utilisateurs finaux à la plateforme se font par authentification et sécurisation des accès
par l’utilisation du protocole HTTPS pour la connexion réseau.
2. Authentification
L'authentification des utilisateurs est réalisée par le biais d'un login unique et d'un mot de passe as-
socié, individuels, attribués par le serveur et diffusés individuellement par l’administrateur systèmes
et réseaux.
‒ L’envoi du login et du mot de passe se fait par le biais d’un email pour le login et d’un SMS
(ou d’un courrier recommandé) pour le mot de passe dans la mesure du possible ;
‒ Le mot de passe doit avoir une longueur de 8 caractères minimum et contenir au moins une
majuscule et un chiffre ;
‒ Un haché des 3 derniers mots de passe est conservé. Un nouveau mot de passe ne peut être
contenu dans les 3 derniers mots de passe connus ;
‒ Le mot de passe possède une date limite de validité modifiable par l’administrateur.
3. Sauvegarde et chiffrement
Le plan de sauvegarde garantit la capacité de sauvegarder et de restaurer tout ou partie des élé-
ments hébergés sur la plate-forme d’hébergement.
La sauvegarde comprend :
18/29
‒ les données de l’application ;
‒ les applications elles-mêmes
‒ ainsi que la configuration des différents systèmes de la plateforme.
Les sauvegardes sont effectuées toutes les nuits sur un serveur distant. Les données sont chiffrées
avec une clé asymétrique puis stockées. La clé permettant de déchiffrer les données n’est accessible
que par le responsable de la sécurité et à son suppléant.
Le rythme et le cycle de sauvegarde permettent de prévenir la perte de données engendrée par un
incident matériel ou l’erreur de manipulation d’un opérateur. Les données récoltées sont conservées
selon le principe suivant :
‒ Sauvegarde quotidienne incrémentale, rétention sur la semaine.
‒ Sauvegarde complète le week-end, rétention de 4 semaines au minimum.
Un exemple de cryptage des sauvegardes est décrit ci-dessous :
‒ Les sauvegardes effectuées quotidiennement sont des archives complètes ou différentielles
chiffrées de tous les fichiers contenant des données à caractère médical.
‒ Le chiffrement est réalisé par la suite logicielle cryptographique conforme au RFC 4880
(OpenPGP Message Format) GPG.
‒ Le chiffrement utilisé peut être CAST5, mais la suite logicielle utilisé permet l’utilisation
d’autres chiffrements (Camellia, Triple DES, AES, Blowfish, et Twofish).
4. Sécurisation physique des locaux hébergeant les serveurs
En plus de la sécurité de la solution applicative, des mesures de sécurité relatives à l’hébergement
physique des données médicales sont à prendre. Les salles informatiques hébergeant les infrastruc-
tures respectent les bonnes pratiques en termes de sécurité physique : environnement hygromé-
trique, température optimale, système de climatisation, système électrique, système anti-incendie.
F. Elargissement du réseau
Le paramétrage de l’application décrit dans le chapitre ci-après étant sensible, l’interface dédiée à
l’élargissement du réseau ne sera accessible que par les coordinateurs de l’ONMNE ayant bénéficié
d’une formation et d’un transfert de compétences sur ces différentes fonctionnalités. Un login et un
mot de passe dédié sera alors paramétré à cet effet.
1. Ajout de nouveaux membres du réseau
Les coordinateurs de l’ONMNE devront être en parfaite autonomie à la gestion des utilisateurs du
système d’information suite à un transfert de compétences sur l’outil et son utilisation.
Cette fonctionnalité est primordiale pour l’adaptation de l’outil informatique aux évolutions et au
développement des réseaux dans les mois et années à venir.
2. Ajout de nouveaux syndromes
De la même manière, un back-office au sein du système d’information permettra la gestion des don-
nées collectées afin :
19/29
‒ D’adapter et faire évoluer si nécessaire les variables de la base de données ;
‒ D’adapter les formulaires de saisies (positionnement des variables, texte d’aide à la saisie,
etc.) ;
‒ D’activer la surveillance de nouveaux syndromes ;
‒ De désactiver la surveillance de syndromes obsolètes.
3. Plateforme de questionnaires en ligne pour des enquêtes ponctuelles
Le système de surveillance permettra à la coordination de l’ONMNE de détecter précocement des
alertes sanitaires, de déclencher des investigations, et de mener à bien les ripostes associées. L’outil
informatique ainsi implémenté pourra s’appuyer sur une plateforme de génération de questionnaires
en ligne pour supporter :
‒ Des investigations ;
‒ Des projets d’étude (ex : augmentation des suicides en Tunisie et questionnaire sur leurs
causes et origines) ;
‒ Des questionnaires individuels de satisfaction des membres du réseau sur la qualité des bul-
letins hebdomadaires, etc.
La plateforme de génération de questionnaire supportera un ensemble de fonctionnalités permet-
tant de paramétrer finement les interfaces de saisie des questionnaires en ligne. Les administrateurs
pourront créer et modifier des formulaires de façon autonome:
• Construction rapide d’une enquête en ligne :
○ Création et paramétrage de plusieurs formulaires de saisie dans une même enquête,
paramétrage de l’enchainement des écrans ;
○ Ajout des questions de différents types :
■ champ texte libre ;
■ date ;
■ entier ;
■ chiffre flottant ;
■ heure ;
■ dictionnaire : liste de réponses prédéfinies (simple ou multiple).
○ Création des utilisateurs et de leurs droits ;
○ Partage de l’enquête ou verrouillage de l’ensemble des accès ;
○ Gestion de la compartimentation des données saisies par groupe ;
○ Exports, analyse, module d’aide à l’étude et à la valorisation des données recueillies.
• Mise en page avancée des formulaires :
○ Définition des pages et onglets, et de la navigation ;
○ Découpage d’une page en bloc et sous-blocs ;
○ Positionnement des variables, modalités d’affichage des listes de réponses (case à
cocher, liste déroulante, champ de recherche avec auto-complétion) ;
○ Champ en lecture seule ;
○ Affichage conditionnel d’un ou plusieurs champs selon la valeur prise par un ou plu-
sieurs autres champs (saut conditionnel) ;
○ Rappel de valeurs issues de tables en amont ou en aval ;
○ Largeur du libellé affiché ;
○ Textes d’aide (cf. Figure- Enquête : Bulle d’aide).
• Adjonction de champs d’upload de documents annexes et pièces jointes. Tout format de fi-
chier est autorisé dans ce module d’upload/download. Cependant il serait possible de
n’autoriser qu’une liste précise d’extensions.
20/29
• Affectation d’une saisie à un groupe donné (permet à un coordinateur aux droits plus larges,
ou à un responsable de pôle par exemple, de saisir pour le compte d’un groupe inférieur au
sien si nécessaire).
• Des contrôles à la saisie peuvent être paramétrés par l’administrateur afin d’assister
l’utilisateur et de l’alerter en cas d’anomalie. Les contrôles à la saisie sont de quatre types :
○ Obligation de saisie : Dans le paramétrage des fiches, il est possible d’activer le ca-
ractère obligatoire d’une ou plusieurs variables ;
○ Borne minimum et maximum : Ces bornes sont paramétrables pour les variables de
type date, entier ou décimal. Elles permettent d’éviter l’enregistrement de valeurs
incohérentes ;
○ Saisie conditionnelle : La saisie d’un champ peut être paramétrée comme condition-
nelle à la valeur prise par un ou plusieurs champs précédents du formulaire ;
○ Contrôles de cohérence : Il s’agit de contrôles dynamiques applicables à une ou plu-
sieurs variables qui s’allument lors de la saisie. Il est ainsi possible de contrôler la va-
leur prise par une variable en regard de la valeur prise par d’autres variables. Ces
contrôles peuvent être soit :
■ Bloquants : dans ce cas ils empêchent l’enregistrement de la fiche par
l’utilisateur tant que l’incohérence reste vraie ;
■ Non bloquants : dans ce cas ils constituent un simple avertissement à
l’utilisateur.
Chacun de ces contrôles est paramétrable avec adjonction d’un message explicatif.
Le degré de complexité du contrôle n’est pas limité puisque la syntaxe SQL est libre
et permet d’impliquer autant de variables que souhaité.
• Un module de gestion des langues permet l’adjonction de fichiers de traduction pour
l’ensemble des libellés de l’interface : libellés des champs, messages d’aide, messages ac-
compagnant les contrôles de cohérence...etc. Le paramétrage du fichier de langue est réalisé
en dehors de l’application, avec le logiciel open source Poedit (http://poedit.net/).
L’application peut ainsi être traduite en de nombreuses langues. Chaque utilisateur para-
mètre la langue associée à son compte ;
• Un moteur de monitoring trace intégralement les actions opérées sur les enregistrements
sur le principe du Qui a fait Quoi, Quand et Où (quelle unité ou quel centre de rattachement).
L’historisation concerne les actions suivantes :
○ Accès et Consultation ;
○ Modification ;
○ Création ;
○ Suppression.
• Des analyses descriptives simples utiles à la gestion quotidienne de la base de données sont
disponibles et peuvent être paramétrées et pré-enregistrées par l’utilisateur :
o Listing des données ;
o Tableaux de fréquences ;
o Tableau de dispersion d’une variable quantitative ;
o Tableau croisé ;
o Graphiques en barre, Camemberts.
• Un ou plusieurs filtres multicritères peuvent être paramétrés et associés à chacun des outils
mises à disposition dans les analyses descriptives.
Il est à noter que certaines compétences internes à l’ONMNE ont déjà été formées en 2013 sur un
outil analogue dans le cadre du développement de l’application de surveillance de l’infection à virus
West Nile.
21/29
G. Documentation et Animation du réseau
Un espace documentaire dédié sera également mis à disposition des utilisateurs du système de sur-
veillance. Différents composants peuvent être imaginés :
‒ Lien vers un forum qui sera mis en place sur le site web de l’ONMNE par les coordinateurs du
réseau : http://www.onmne.tn/
‒ Document PDF listant les questions et réponses les plus fréquemment posées sur le forum ;
‒ Manuel utilisateur du logiciel ;
‒ Charte des différents réseaux ;
‒ Lien vers la page Facebook du projet et des deux réseaux de surveillance.
L’animation du réseau est en effet un facteur de clé de réussite et l’accent doit être mis sur ces outils
de communication.
H. Contexte d’utilisation sur le terrain
L’outil de collecte devra être accessible directement depuis les sites des réseaux de surveillance :
‒ le cabinet du Médecin de Libre Pratique ;
‒ les salles des Services des Urgences hospitalières.
‒ Les laboratoires d’analyse biologique
‒ les autres membres des réseaux
Dans cette première phase du projet, chacun aura à sa disposition un ordinateur connecté à internet
et permettant d’accéder à l’outil de collecte en ligne sans difficulté et à n’importe quel moment de la
journée.
Cependant, si au cours du développement des réseaux de surveillance :
‒ le réseau filaire internet s’avère trop peu stable pour assurer une accessibilité 7j/24h ;
‒ le développement du réseau et des syndromes nécessite la possibilité de déclarer directe-
ment depuis les couloirs des SU, ou chez un particulier lors d’une consultation à domicile ;
Une utilisation de l’outil de collecte directement sur tablette disposant d’une connexion 3G pourra
être envisagée.
Dans un second temps, la saisie des données et leur transmission à l’ONMNE sans connexion internet
sera un module qui pourra être étudié. Ce travail n’est pas décrit dans le présent cahier des charges
pour cette première phase du projet.
22/29
IV. Ressources humaines
Ce chapitre liste l’ensemble des profils nécessaires à la mise en place et au suivi du système
d’information nécessaire aux réseaux MLP et SU. Une liste de tâches est affectée à chaque profil.
A. Profil informatique technique
Liste des tâches :
‒ L’administration du serveur hébergeant les données dans les locaux de l’ONMNE :
o mise à jour du serveur (Apache, MySQL, etc.) ;
o mise à jour du système d’information (maintenance corrective, déploiement de nou-
velles fonctionnalités, etc.) ;
o gestion des pannes ;
o relance du système ;
o garantie de la sécurité des accès, etc.
‒ La gestion de la salle serveur :
o panne électrique ;
o onduleur ;
o climatisation, etc.
B. Profil épidémiologie
Liste des tâches :
‒ La validation des données ;
‒ Les analyses hebdomadaires ;
‒ La publication de la rétro-information et des bulletins épidémiologiques ;
‒ Les rapports, les publications, et communications scientifiques ;
‒ Les investigations d’épidémies suspectées, le déclenchement des alertes sanitaires et
l’organisation de la riposte ;
‒ L’animation du réseau.
C. Profil santé technique
Liste des tâches :
‒ Le monitoring des données saisies, les contrôles de cohérence ;
‒ Le retour vers les médecins et urgentistes en cas d’erreur de saisie ;
‒ La relance en cas de retard de saisie ;
‒ Le support aux utilisateurs ;
‒ L’évolution du système de surveillance (gestion des utilisateurs, gestion des droits, dévelop-
pement des syndromes).
23/29
V. Transfert de compétences et accompagnement
Dans le cadre du déploiement du réseau et de la mise en service de l’outil informatique, une session
de formation sera nécessaire d’une part aux coordinateurs pour l’administration du système, et
d’autre part aux membres du réseau, utilisateurs finaux de l’application.
Les sessions de formation et d’accompagnement se dérouleront sur site et pourront accueillir un
nombre déterminé de participants.
A l’issue de chacune de ces sessions de transfert de compétences, l’équipe de coordination de
l’ONMNE sera autonome à la rédaction d’un manuel utilisateur, ultérieurement remis aux membres
des réseaux.
A. Formation administrateur
1. Formation des coordinateurs responsables du système et du réseau
Afin de garantir l’autonomie de l’ONMNE dans l’administration de leur outil, une formation permet-
tra un transfert de compétences sur les points suivants :
‒ Gestion des utilisateurs et de leurs droits
� Création d’un nouvel utilisateur du système ;
� Gestion de mot de passe perdu ;
� Gestion des droits ;
� Gestion de la pyramide sanitaire ;
‒ Module d’analyse et export ;
‒ Formation à l’utilisation du module R ;
‒ Adaptation de l’outil de collecte au fil de l’eau :
� Administration des formulaires ;
� Ajout et modification de variables ;
� Activation/désactivation de syndromes ;
� Ajout et modification de contrôles à la saisie simples.
‒ Déploiement d’enquêtes supplémentaires ponctuelles sur la plateforme en ligne.
2. Formation de l’ingénieur informatique responsable du serveur et de la salle ser-
veur
La phase de projet correspondant à l’installation de l’outil de collecte sur le serveur de l’ONMNE
(Phase 2 décrite au paragraphe VI. C. Stratégie préconisée pour le déploiement de l’outil) pourra
s’accompagner d’une formation de l’ingénieur informatique en charge du serveur.
Les compétences couvertes par la formation seront axées autour de trois points :
‒ L’installation de l’application (configuration des serveurs, déploiement de mises à jour logi-
ciel, instauration de règles de sécurité, etc.) ;
‒ L’administration du serveur Linux (OS Linux, gestion des pannes et relances du système, ges-
tion des accès, etc.) ;
‒ La gestion de la salle serveur.
Cette formation sera donc comprise dans le module et la facturation d’installation de l’application
dans les locaux tunisiens de l’ONMNE.
24/29
B. Formation utilisateurs finaux
Deux jours de formation seront organisés en deux sessions, dédiées chacune à un réseau de surveil-
lance.
La journée dédiée aux MLP serait préférentiellement organisée un samedi afin de faciliter leur déta-
chement. Un maximum de 15 personnes pourra être formé par un facilitateur. Au-delà, un second
facilitateur sera requis.
C. Déploiement et accompagnement
Une mission sur site permettra d’assurer l’installation, le déploiement de la solution, ainsi que la
formation des utilisateurs et coordinateurs finaux.
Les principales tâches à réaliser au sein de cette mission sont les suivantes :
‒ Installation à distance, avec le support du prestataire, de l’application sur le serveur de
l’ONMNE par l’ingénieur en charge du serveur ;
‒ Vérification sur site de l’installation réalisée précédemment et résolution des problèmes si
nécessaires ;
‒ Formation au déploiement des mises à jour du système ;
‒ Vérification du bon fonctionnement et de l’efficacité du système : affichage du formulaire,
saisie des données, validation du questionnaire ;
‒ Vérification de la connectivité et de la bande passante ;
‒ Formation des coordinateurs et utilisateurs ;
‒ Session de questions-réponses à l’issue de la formation.
Un transfert de compétences techniques à l’équipe de l’ONMNE permettra le bon suivi du projet.
25/29
VI. Spécifications techniques préconisées du serveur hébergeant le sys-
tème
Ce chapitre liste les différents éléments de prestation attendus pour l’hébergement des données
dans le cadre de la mise en place du système de surveillance des maladies en Tunisie.
A. Configurations techniques requises
Le système de surveillance décrit dans ce présent cahier des charges est une application web déve-
loppée en PHP et fonctionnant avec la base MySQL.
Voici la configuration minimale requise pour un serveur web hébergeant une telle solution :
• Caractéristiques techniques :
‒ Bi ou quadri processeur ;
‒ 4Go de RAM ;
‒ 50Go minimum de disque dur ;
‒ HTTPS : achat d’un certificat SSL pour le nom de domaine utilisé.
• Configuration & Installation :
‒ OS Unix/Linux (EpiConcept utilise la dernière Debian stable sur sa propre infrastruc-
ture) ;
‒ Apache 2.x ;
‒ MySQL 5.x ;
‒ PHP > 5.2.6 (5.4 conseillé) ;
‒ Sauvegardes.
Types de disque recommandés : Raid 5
Bande passante consommée: Elle reste relativement faible et sera inférieure à 1 Mbps.
Une formation pourra être dispensée à l’ingénieur informatique en charge du serveur hébergeant les
données et de la salle serveur. L’ensemble des configurations et librairies requises seront constituées
lors de ce transfert de compétences, puis fournies dans une documentation technique contenant
également un ensemble de conseils en matière de monitoring.
B. Infrastructure préconisée
Dans le cadre de ce projet, la disponibilité du système et la sécurité des données sont deux aspects
fondamentaux pour le développement des réseaux MLP et SU.
Celle-ci est assurée en doublant deux serveurs : l’un hébergeant la base et les données, l’autre hé-
bergeant l’application.
Caractéristiques du serveur frontal :
‒ 2 Go de RAM ;
‒ 4 à 8 cores.
Caractéristiques du serveur base de données séparés :
‒ 8 à 16 Go de RAM pour la base de données ;
‒ 4 à 8 cores.
Figure
Sauvegardes quotidienne incrémentale et hebdomadaire complète. Rétention 3 mois maximum, 1
mois minimum.
Monitoring du serveur et information des interruptions de service auprès de la cellule
Communication au client des interruptions planifiées
Installation de l'applicatif et de ses mises à jour sur la base d'une documentation et d'un tran
compétences. Cette mise à jour ne devrait pas être réalisée plus de 4 fois par an
l’ONMNE.
Monitoring et supervision : En plus de la supervision classique liée à son infrastructure, il est attendu
de l’ONMNE une surveillance de l’utilisation des ressources allouées pour anticiper les évolutions
nécessaires.
C. Stratégie préconisée pour le déploieme
Afin de permettre un développement de l’outil informatique dans les plus brefs délais, ainsi qu’un
hébergement des données immédiat et présentant la sécurité requise
té, nous préconisons l’organisation suivante
‒ Phase 1 : Hébergement temporaire des données du système d’information chez un hébe
geur de données (ex
o disposant d’un niveau de sécurité suffisant pour répondre aux exigences de
l’Instance Nationale de Protection des Do
o garantissant un débit de connexion suffisant
Figure : Schématisation de l’infrastructure préconisée
Sauvegardes quotidienne incrémentale et hebdomadaire complète. Rétention 3 mois maximum, 1
Monitoring du serveur et information des interruptions de service auprès de la cellule
client des interruptions planifiées.
Installation de l'applicatif et de ses mises à jour sur la base d'une documentation et d'un tran
. Cette mise à jour ne devrait pas être réalisée plus de 4 fois par an
: En plus de la supervision classique liée à son infrastructure, il est attendu
de l’ONMNE une surveillance de l’utilisation des ressources allouées pour anticiper les évolutions
Stratégie préconisée pour le déploiement de l’outil
Afin de permettre un développement de l’outil informatique dans les plus brefs délais, ainsi qu’un
hébergement des données immédiat et présentant la sécurité requise en terme de données de sa
, nous préconisons l’organisation suivante :
Hébergement temporaire des données du système d’information chez un hébe
(ex : hébergeur professionnel en Tunisie) :
d’un niveau de sécurité suffisant pour répondre aux exigences de
Instance Nationale de Protection des Données à Caractère Personnel (
garantissant un débit de connexion suffisant ;
26/29
Schématisation de l’infrastructure préconisée
Sauvegardes quotidienne incrémentale et hebdomadaire complète. Rétention 3 mois maximum, 1
Monitoring du serveur et information des interruptions de service auprès de la cellule.
Installation de l'applicatif et de ses mises à jour sur la base d'une documentation et d'un transfert de
. Cette mise à jour ne devrait pas être réalisée plus de 4 fois par an, par autorisation de
: En plus de la supervision classique liée à son infrastructure, il est attendu
de l’ONMNE une surveillance de l’utilisation des ressources allouées pour anticiper les évolutions
Afin de permettre un développement de l’outil informatique dans les plus brefs délais, ainsi qu’un
en terme de données de san-
Hébergement temporaire des données du système d’information chez un héber-
d’un niveau de sécurité suffisant pour répondre aux exigences de
nnées à Caractère Personnel (INPDCP) ;
27/29
o garantissant un rétablissement des accès en cas d’incident.
‒ Phase 2 : Accompagnement de l’ONMNE à la monté en compétence requise pour
l’hébergement des données dans leurs locaux.
‒ Phase 3 : Migration de l’application sur les serveurs de l’ONMNE pour une autonomie com-
plète.
VII. Contraintes règlementaires
Une demande d’autorisation auprès de l’Instance Nationale de Protection des Données à Caractère
Personnel (INPDCP) devra être réalisée par l’équipe de coordination de l’ONMNE.
Les éléments techniques concernant l’hébergement, la sécurité, les droits et les modalités d’accès,
seront fournis pour répondre aux exigences de l’INPDCP Tunisienne.
VIII. Calendrier prévi
Le projet est prévu pour une durée de
Figure
A titre d’exemple, le lancement du projet en Août 2015 permettrait de
l’application courant Novembre 2015.
La phase de développement se déroulera de manière itérative
tion permet des phases de développement relativement courtes
nécessite une certaine disponibilité de l’équipe de coordination de l’ONMNE
validée par des sessions de
sont intégrés au cours de l’itération suivante.
Lors de la finalisation de l’outil informatique et suite à son déploiement et sa mise en production, la
phase pilote de déploiement
d’urgence.
A l’issue de cette phase pilote, l’ONMNE sera
seau à l’échelle nationale.
prévisionnel de réalisation
et est prévu pour une durée de 4 mois et pourra s’organiser selon le calendrier ci
Figure : Calendrier prévisionnel de réalisation du projet
A titre d’exemple, le lancement du projet en Août 2015 permettrait de planifier un déploiement de
l’application courant Novembre 2015.
La phase de développement se déroulera de manière itérative : module par module. Cette organis
tion permet des phases de développement relativement courtes et peu espacées dans le temps
nécessite une certaine disponibilité de l’équipe de coordination de l’ONMNE
sessions de test en conditions réelles auprès des coordinateurs.
de l’itération suivante.
la finalisation de l’outil informatique et suite à son déploiement et sa mise en production, la
de déploiement se déroulera auprès d’un nombre restreint de médecins et de services
e phase pilote, l’ONMNE sera autonome pour assurer le développement de son r
28/29
s’organiser selon le calendrier ci-dessous :
: Calendrier prévisionnel de réalisation du projet
planifier un déploiement de
module par module. Cette organisa-
et peu espacées dans le temps, mais
nécessite une certaine disponibilité de l’équipe de coordination de l’ONMNE. Chaque itération est
auprès des coordinateurs. Les retours de tests
la finalisation de l’outil informatique et suite à son déploiement et sa mise en production, la
se déroulera auprès d’un nombre restreint de médecins et de services
nome pour assurer le développement de son ré-
29/29
IX. Livrables
L’ensemble des livrables attendus sont repris de façon exhaustive dans le tableau ci-après :
Nom Descriptif du livrable
Lot 1 Gestion de projet.
Lot 2 Page d’accueil, questionnaires en ligne et fonctionnalités de base.
Lot 3 Module de planification et relance des saisies non réalisées.
Lot 4 Gestion documentaire : mise en ligne de documents référents, de définitions de
cas, de publications, de manuels utilisateur, de liens internet (forum, FAQ, etc.).
Lot 5 Transfert de compétence :
‒ Formation de l’équipe de coordination de l’ONMNE ;
‒ Formation des utilisateurs finaux.
Lot 6 Maintenance de l’application.
OPTION 1 Module d’aide à la saisie hebdomadaire pour le SU : possibilité d’un décompte
journalier.
OPTION 2 Module d’analyse en ligne à partir de l’outil statistique R :
‒ Automatisation de la rétro-information de second niveau ;
‒ Formation au module R.
OPTION 3 Module d’activation/désactivation de syndromes à suivre au sein du réseau.
Package
d’installation
sur site
Configuration et installation de l’application sur les serveurs de l’ONMNE :
‒ Configuration des serveurs ;
‒ Installation ;
‒ Déploiement sur place ;
‒ Formation de l’ingénieur informatique en charge du serveur ;
‒ Manuel ;
‒ Accompagnement.
Recommended