2. Cahier des charges applicartion informatique quatre réseaux · Des échanges autour de...

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


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


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.



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


jour dont la saisie a été réalisée se colore d’un feu vert. Différents boutons permettent au MLP de :


able. Cette tâche sera en revanche réalisée une

ur cet intervalle de temps.



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é


Accéder à la fiche déclarée précédemment ;

Ajouter une fiche de déclaration à la semaine sélectionnée.


d’urgence ou même selon chaque utilisateur, de choisir entre une saisie journalière ou hebdom

Syndrome sous surveillance


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 à


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



tre une saisie journalière ou hebdoma-


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.


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


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


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


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.


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


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


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-


Les données collectées puis transmisses chaque semaine sont ensuite monitorées, validées et analy-


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


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


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.


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


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


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-


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


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


Stratégie préconisée pour le déploiement de l’outil


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


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



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.

2. Cahier des charges applicartion informatique quatre réseaux · Des échanges autour de...

Documents

Transcript of 2. Cahier des charges applicartion informatique quatre réseaux · Des échanges autour de...