Vers un système d’information intégré pour les Maladies

Rares en France

Kankoé SALLAH ¹

¹ Faculté de Médecine Université de la Méditerranée, Marseille, France

Abstract

Le but de ce mémoire est de montrer quelle place occupent les systèmes d’information
dans la gestion des maladies rares en France en montrant ce qui a déjà été réalisé et ce
qui reste à faire pour intégrer et rendre interopérable les divers systèmes mis en place.
Chaque maladie rare étant très spécifique en termes de pathologie et chaque centre de
référence étant labellisé pour une maladie donnée, divers systèmes d’informations ont été
développés de façon séparée et adaptée à chaque centre de référence. Ultérieurement, est
apparue l’idée d’intégrer les différentes bases de données déjà existantes. Ce travail donne
d’abord un aperçu des outils existants ainsi que des initiatives prises dans le sens le leur
intégration. Il fait ensuite des propositions visant à améliorer cette intégration dans le but
d’aboutir à un système d’information unifié, homogène et plus efficient pour la prise en
charge des patients, le recherche médicale et l’aide à la décision en administration
sanitaire.

Keywords

Information Systems; Rare Diseases; Medical Informatics

1 Introduction
Les maladies rares englobent un groupe d’affections caractérisées par leur faible
prévalence. En France, une maladie est dite rare lorsqu’elle atteint moins d’une personne
sur 2000.
Le gouvernement Français a pris conscience de l’attention à accorder aux maladies rares et
a mis en place en 2003 le premier Plan National Maladies Rares[1] qui s’est étalé jusqu’en
2008. Bien avant ce plan, une collaboration entre équipes de recherche et acteurs de santé
et associations de malades avait donné naissance en 1996 au projet ORPHA.NET [2] avec
une composante en système d’information notable sur les maladies rares. La question des
maladies rares est encore d’actualité aujourd’hui puisqu’un 2ème plan Maladies Rares est
prévu être lancé en 2010. Le premier plan Maladies Rares a conduit à la mise en place de
plus d’une centaine de structures cellulaires appelées Centres de Références qui sont
chacune spécialisées dans une maladie rare spécifique. Récemment, se sont rajoutés les
centres de compétence affiliés aux centres de référence. Chacune de ces structures peut
développer un système d’information particulier, spécifique de la maladie dont elle est

1
référente. Il s’agit chaque fois d’une pathologie différente même si l’on peut tenter de
regrouper les centres de référence de façon transversale. Par exemple, 4 centres de
référence ont été labellisés pour maladies rénales rares. Ce sont les centres de :
- Maladies héréditaires rénales et du métabolisme ( Lyon, 2004)
- Maladies rénales héréditaires (Hôpital Necker-Enfants Malades, 2004)
- Maladies rénales rares (Toulouse, 2005)
- Syndrome néphrotique idiopathique (Créteil, 2006)
Les bases de données développées dans ces divers centres n’étaient pas prévues pour être
intégrées en une plateforme commune. Les outils utilisés sont très variables d’un centre à
l’autre. De plus ces systèmes d’information variés évoluent constamment vers de nouvelles
fonctionnalités correspondant aux besoins spécifiques de chaque centre. Une initiative
intéressante sera lancée en 2003 à travers le projet CEMARA[3] (Centre des maladies
rares) qui a pour finalité principale de contribuer à l’élaboration et à l’évaluation de
stratégies sanitaires visant à améliorer de la prise en charge des maladies rares et l’aide à la
décision en Santé Publique pour les maladies rares. Ce projet prend appui sur les nouvelles
méthodes de gestion, de stockage et d’exploitation numérique pour traiter les données
provenant des divers centres de référence. Mais comment intégrer les données hétérogènes
provenant de sites géographiques différents ? Comment réaliser une gestion combinée de
données cliniques, de laboratoires et d’imagerie ? L’hétérogénéité des données à intégrer
est aggravée par les disparités de systèmes d’exploitation et de logiciels de recueil de
données utilisés, les systèmes architecturaux choisis dans les différents lieux ainsi que les
langages de programmation utilisés, les protocoles de communication qui peuvent être
utilisés entre les différents sites.
Le codage des données est un élément très important dès lors qu’on désire intégrer les
données en provenance de diverses applications. Si des règles de codification commune
n’avaient pas été dictées par une consigne de départ, il va falloir se servir de transcodages
adéquats pour harmoniser les données. Ce qui est certain dans ce cadre-ci, c’est que tous
les centres de référence n’ont pas construit leur système d’information en s’appuyant sur la
codification CIM10 qui d’ailleurs ne fournit pas actuellement tout le support
informationnel adapté pour les maladies rares. De surcroit, il semble que la CIM10 soit peu
adaptée à un domaine où la nosologie évolue très rapidement [3]. En effet près de 300
nouvelles entités nosologiques sont découvertes chaque année. Le transcodage
d’informations devrait donc être inévitable si l’on veut agréger les données.
L’éloignement géographique des centres exige que soit mis en place un protocole
d’échange d’informations adéquat avec prise en compte des aspects éthiques et de
confidentialité à l’égard des données jugées sensibles impliquant le cryptage avant
transfert.

2 Analyse de l’existant

2.1 Systèmes d’information des centres de référence

Tous les centres de référence n’ont pas développé un système informatisé de collecte des
données patient. Certains attendent de développer un système qui leur soit propre. D’autres
utilisent les systèmes d’information des hôpitaux ou laboratoires de recherche qui les
abritent. Les autres ont développé des systèmes de recueil et de traitement des données
patients. A titre d’exemple, le CRPP (Centre de référence en Pathologies Plaquettaires)
utilise une application PHP/MySQL alors que le Centre de référence national pour les
vascularites nécrosantes et la sclérodermie systémique utilise ACCESS/VBA. A Clermont-

2
Ferrand, au centre de référence des leucodystrophies, c’est le système d’information
hospitalier médicalisé qui est utilisé. Certains centres de références rentrent dans un
système d’information spécifique d’un projet d’étude. C’est le cas par exemple du Centre
de Référence « Syndromes Drépanocytaires majeurs » qui participe au projet INFORARE
qui expérimente un système d’information impliquant le patient au moyen de l’utilisation
par ce dernier d’une carte individuelle sécurisée.
Les patients recueillis dans un centre de référence ne sont pas forcement du même secteur
géographique. La plupart sont adressés aux centres de référence après un parcours à travers
des systèmes de soins et peuvent provenir de régions géographiques éloignées ou d’autres
centres de référence où ils avaient parfois déjà été enregistrés à tord ou à juste titre pour
une autre maladie rare.
Parmi les outils de collecte de données retrouvés dans les centres de référence, on trouve
divers bases de données relationnelles traitant des requêtes SQL. Les interfaces utilisent
divers langages de programmation qui permettent de communiquer avec la base de
données. Les procédures de stockage et de recherche d’information ne sont pas dans la plupart
des cas basés sur l’utilisation d’un vocabulaire commun servant de référentiel. Dans plusieurs
cas, le « langage médical naturel » été utilisé au lieu d’une quelconque Classification de
Référence.

2.2 ORPHA.NET
Depuis 1997 ORPHA.NET met à la disposition des professionnels de santé une base de
données de plus de 4000 maladies rares, une base de données sur les médicaments indiqués
dans les pathologies rares, une encyclopédie sur plus de 2000 maladies ainsi qu’un
répertoire sur les consultations spécialisées dans les centre de référence, les laboratoires de
diagnostic, les recherches en cours et les associations de malades. En étroite collaboration
avec l’OMS, ORPHANET fait régulièrement des propositions allant dans le sens de
l’insertion / rectification des maladies rares au sain de la Classification Internationale des
Maladies dont la prochaine version CIM11 est en cours d’élaboration. ORPHA.NET
n’abrite pas de données Patient. Des droits d’accès sont définis selon les différents profils
d’utilisateurs.

3 L’apport du projet CEMARA

Le programme CEMARA a pour objectif d’améliorer l’aide à la décision en Santé
Publique pour les maladies rares en s'appuyant sur les nouvelles méthodes de gestion, de
stockage et d’exploitation de données. Il s’agit donc de développer ou de transposer aux
problématiques liées à la recherche en Santé Publique, un ensemble d’approches
méthodologiques et technologiques autour de la notion de “Système d’Information
Décisionnel” (SID) accessible par Internet. Le détail des objectifs met en avant les axes
suivants, à savoir :
• Fournir des statistiques descriptives des maladies rares et de leur prise en charge
• Etre un outil d’évaluation et d’aide à la décision en matière de santé publique
• Etre un outil pour la recherche clinique épidémiologique et en économie de santé.
L’application permet un recueil de données délocalisé, tout en assurant un contrôle de
qualité de ces dernières mais aussi un contrôle d’exhaustivité. Grâce à son entrepôt de
données, CEMARA permettra par le biais de requête sur cet entrepôt, de visualiser les
données dans un Système d’Information Géographique pour les Maladies Rares
(SIGMARA). Les accès sont sécurisés. Les centres adhérents partagent un tronc commun

3
d’informations avec des données d’identification. A ce niveau, il a été prévu un statut de
diagnostic qui peut être : probable, confirme, en cours, infirmé, non déterminé ou non
classable. Un tiers des 30119 dossiers dans la base de CEMARA correspondent à un
diagnostic non-déterminé. Des mots clés supplémentaires peuvent être rajoutés pour des
patients présentant un diagnostic encore inconnu ou non étiquetable. Un thésaurus a été
mis en place en partenariat avec ORPHANET et GENATLAS garantissant ainsi un
vocabulaire commun. Pour certaines maladies, des informations complémentaires peuvent
êtres colligées dans des « pétales » (figure1) spécifiques rattachés au noyau commun de
données. Les pétales sont développés de façon modulaire pour être facilement attachés au
tronc commun de la base de données. Un entrepôt de données et un système d’information
géographique permettent de mettre à la disposition des utilisateurs des données agrégées.
Le développement de ce programme a reposé sur les principes de modularité,
d’échelonnement, de portabilité, de fiabilité, d’accessibilité et de coût-efficacité via
l’utilisation des logiciels libres.

Figure 1 : Tronc commun et pétales spécifiques

3.1 Le thésaurus
ORPHANET ayant déjà conçu un thésaurus spécifique dédié aux maladies rares, et la
CIM 10 étant peu documentée au sujet des maladies rares, CEMARA a choisi de
collaborer avec ORPHANET pour prévoir une ontologie pour le thésaurus du projet avec
un caractère lexical unique pour la labellisation de chaque maladie avec gestion des
synonymes, éponymes et polysémie. De plus, de part sa nature, la CIM10 est un
compromis entre les classifications basées sur l’étiologie, la localisation anatomique et les
circonstances d’apparition. Elle ne permet pas de coder des détails cliniques pour un
patient. Des systèmes de codification plus élaborés de terminologie médicale ont été
développés. C’est le cas du système READ au Royaume Uni. Ces systèmes posent
néanmoins souvent des difficultés d’intégrations par rapport aux systèmes préexistants.
CEMARA n’a pas choisi s’y référer.
En ce qui concerne les mutations génétiques, le plus souvent en cause dans les maladies
rares, le thésaurus (figure 2) se fonde sur GENATLAS qui est une base de données de
cartographie génique et de maladies génétiques.

4
La granularité syndromique a été préférée à la granularité au niveau des symptômes.
La profondeur de l’arborisation du thésaurus n’est pas la même suivant les différentes
maladies rares.
Tous ces éléments de thésaurus sont communiqués aux partenaires des centres de référence
pour garantir un vocabulaire commun.

Figure 2 : Thésaurus : d’après P. Landais

3.2 La structure du système d’information

L’architecture de base est N-Tier (figure 3). Via un navigateur web, le client se connecte à
un « middle-tier », qui est relié à plusieurs bases de données : la base de données de
production, le dictionnaire géographique et la base de données thésaurus. Un entrepôt de
données et un système d’information géographique permettant des requêtes s’ajoute à cette
structure. Le « middle-tier » contient des conteneurs Web et de la logique Métier. Du côte
client, une machine connectée à internet suffit. La base de données de production respecte
les impératifs de confidentialité, de sécurité des données ainsi que de suppression des
doublons d’identité [4].

5
 Figure 3 : Architecture de l’application CEMARA (d’après P.Landais)

3.3 Interopérabilité
Etant donné que plusieurs centres de référence disposaient déjà de leurs propres bases de
données et que certains utilisaient les systèmes d’information hospitaliers existants pour
recueillir leurs données, il faudrait trouver le moyen de partager leurs données sans avoir à
effectuer de nouvelles saisies. CEMARA utilise XML comme format d’échange.

3.4 Atouts technologiques de CEMARA

L’architecture N-Tier utilisé par CEMARA est une extension de l’architecture Client-
serveur dans un modèle distribué.
Un des avantages importants de l’architecture adoptée par CEMARA réside dans
l’amélioration de la sécurité des données, en supprimant le lien direct entre le client et les
données. Le serveur a pour tâche, en plus des traitements purement métiers, de vérifier
l'intégrité et la validité des données avant de les envoyer dans la couche de données.
D’autre part, cette architecture ouverte permet également de répartir les objets sur
différents serveurs d'application. Ceci permet dans le cas présent de prendre en compte
l’hétérogénéité des données.

4 Discussion et perspectives

4.1 Sur l’aspect planification de projet

Si le premier Plan Maladies Rares avait mis en place un projet précis de système
d’information avec un schéma directeur et des spécifications à respecter, l’intégration des
différents systèmes d’information développés dans les différents centres aurait été plus
simple. Les différentes bases auraient été dès leur conception prévues pour « fédérées » en

6
une même structure finale. Le coût d’intégration des applications hétérogènes peut
largement dépasser le coût d’un système préconçu de façon verticale.

4.2 Le type de SGBD utilisé

L’utilisation d’un SGBDR relationnelle peut être discutée, ces systèmes se prêtant
difficilement à la gestion des données temporelles et à la gestion des objets complexes
comme des textes ou des images. Les modèles orientés objet peuvent mieux se prêter à ce
type de données. Pour de tels types de projets, certaines institutions ont même été amenées
par le passé à développer leur propre système de gestion de base de données.

4.3 Le protocole de transmission des données

Le protocole HTTP est utilisé pour les échanges de données. Cela limite le type de données
transmissibles sous ce projet. Les images de tomodensitométrie et d’IRM ne peuvent pas
être convenablement transmises sous ce procédé. Il est néanmoins possible d’envisager
d’utiliser des protocoles plus spécifiques aux échanges de données médicales comme
ASTM ou HL7 ou encore le standard DICOM pour la communication d’images
radiologiques. Il semble qu’à l’heure actuelle, le projet ne prévoit pas la transmission et le
stockage des données numériques de grande taille

4.4 Le thesaurus
Au sujet du langage médical et du système de classification adopté et qui est basé sur le
thésaurus mis en place par ORPHANET, il faut espérer que ledit thésaurus trouve une
place de plus en plus conventionnelle dans les systèmes de classification internationale
comme (CIM 11 à venir, SNOMED, MeSH ou UMLS). Cela garantirait la pérennité du
Système d’Information sans nécessité ultérieure de transcodage. On connaît les
nombreuses difficultés que présenterait un tel transcodage et c’est pour cette raison qu’il
est vivement recommandé d’adopter une classification largement diffusée et dont les
révisions sont assurées au fil du temps par un organisme international reconnu et
compétent. Le leadership international d’ORPHANET dans le domaine des maladies rares
apparaît plutôt comme un atout en ce sens.

4.5 La sécurité et la protection des données et les aspects juridiques

Dès lors qu’il s’agit d’échanger des données médicales, il faudra veiller à la confidentialité
et à la protection, en particulier lorsque ces données transitent par internet.
Le cryptage des données avant envoi et leur décryptage à la réception paraît
incontournable. L’information, même si elle venait à être interceptée par une personne non
autorisée, reste inexploitable pour cet utilisateur ne disposant pas de droit de décryptage.
Dans le même souci de confidentialité il serait judicieux de mettre en place un dispositif de
surveillance des transactions effectuées sur le système. Ce dispositif serait dissuasif pour
l’intrusion illicite puisqu’il garde la trace des accès réalisés sur le système [5].
La mise en place des bases de données médicales est régie par la loi du 1er Juillet 1994
relative au traitement de données nominatives ayant pour fin la recherche dans le domaine
de la santé et modifiant la loi n° 78-17 du 6 janvier 1978 relative et consolidée dans sa
version du 13 juillet 2001. D’autres dispositions de la Loi Informatique et Libertés gérées
par la CNIL sont également à prendre en compte.

7
4.6 Intégration à un système d’information hospitalier
Les centres de référence (c’est la grande majorité) ayant déjà enregistré l’essentiel de leurs
données dans un système d’information hospitalier, sont ceux qui ont le plus de difficultés
à rentrer dans un projet intégrateur.
Il s’agirait de rentre accessible une partie du système d’information d’un hôpital à une
autre structure hospitalière ou non via un réseau internet. Les problèmes de sécurisation et
d’interopérabilités posés sont alors plus accrus. Dans le cas présent il s’agirait d’intégrer en
un tout des partis de divers systèmes d’information hospitaliers médicalisés. Les
expériences ayant déjà été faites dans le sans de l’intégration de divers systèmes
hospitaliers ont révélé ces nombreuses difficultés.

4.7 Biais possibles dans l’information géographique

Si l’on se base sur les informations en provenance des centres de référence pour construire
un système d’information géographique, il faudra bien sur bien prendre en compte la
mobilité géographique des patients, motivée par la localisation des centres de référence
spécialisés dans leurs pathologies. Il n’existe en France qu’un seul Centre de références en
Pathologies Plaquettaires par exemple. Il s’en suivra une migration plus ou moins explicite
des patients. Ce biais doit pouvoir être pris en compte.

4.8 Promouvoir la télémédecine

Elle permettait, sur ce type de pathologie qui nécessite souvent un degré d’expertise élevé
dans les spécialités médicales, de favoriser une collaboration constructive entre spécialistes
éloignés géographiquement.

5 Conclusion
Le premier Plan Maladies rares n’a pas donné de directive précise en ce qui concerne la
mise en place de systèmes d’information pour les Centres de références auxquels il a donné
naissance. Le travail qui s’impose aujourd’hui quand l’on désire cerner les aspects
épidémiologiques de ces pathologies rares est celui de l’intégration des différentes sources
de données existantes. Le projet CEMARA a tenté de réaliser cette intégration à travers
une architecture N-Tier s’appuyant sur le réseau internet. Le système structuré par cette
application permet en plus de l’analyse épidémiologique, de présenter une information
géographique utile à la décision en santé publique. Des perspectives d’amélioration sont
néanmoins possibles et devraient être les bienvenus à la veille du lancement du 2ème plan
Maladies Rares prévu pour cette année 2010. Ce 2ème plan préconise dans son 1er axe le
déploiement d’un système d’information à l’échelle nationale qui devrait s’inspirer du
modèle CEMARA.

Remerciements
A M. Le Pr FIESCHI qui bien voulu réorienter à plusieurs reprises ce sujet pour lui
permettre de demeurer dans le champ d’intérêt des systèmes d’information en Santé.

8
Références

[1] Orpnanet http://www.orpha.net/actor/Orphanews/2009/doc/eval_sante_pnmr.pdf:

Date d’accès : 12/01/2010
[2] Aymé S. Orphanet, an information site on rare diseases. Soins 2003; 672: 46-7
[3] Messiaen C, Le Mignot L, Rath A, Richard JB, Dufour E, Ben Said M, Jais JP,
Verloes A, Le Merrer M, Bodemer C, Baujat G, Gerard-Blanluet M, Bourdon-
Lanoy E, Salomon R, Ayme S, Landais P.CEMARA: a Web dynamic application
within a N-tier architecture for rare diseases. Stud Health Technol Inform 2008; 136:
51-6.
[4] Le Mignot L, Mugnier C, Ben Saïd M, Jais JP, Richard JB, Le Bihan-Benjamin C,
Taupin P, Landais P. Avoiding doubles in distributed nominative medical databases:
optimization of the Needleman and Wunsch algorithm. Stud Health Technol Inform.
2005 116: 83-8.
[5] In : Informatique médicale Degoulet P, Fieschi M. (eds) Paris : Masson, 1998 ; pp :
207

Adresse de correspondance
Kankoé SALLAH
Etudiant Master1 EISIS
121 Av d’Arès Appt8 33200 Bordeaux
Email : kankoe@sallah.org
kankoe.sallah@etumel.univmed.fr